bug#54447: cuirass: missing derivation error

[Ludovic Courtès]

Ludovic Courtès  skribis:

> In addition to the mcron job, Cuirass’s own ‘register-gc-roots’
> procedure periodically deletes GC roots older than ‘%gc-roots-ttl’ (30
> days in practice).  That’s okay, except that it would be safer to delete
> GC roots for a .drv if and only if it’s been built already.

Fixed in Cuirass commit 55af0f70c0d4938b8eda777382bbc4d8f5698a37.

Ludo'.

bug#54447: cuirass: missing derivation error

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Looking at the nginx and ‘guix publish’ logs, I found that the missing
> substitute is not that of 4r1wij3bzj9zv75ds82a93jl7bcman2x (the .drv
> itself) but rather that of a dependency of that .drv:
>
>   [14/Oct/2023:23:22:09 +0200] "GET /wqqzcxrhbnv0nzg64iiiqd5grr4vk2zg.narinfo 
> HTTP/1.1" 404 58 "-" "GNU Guile"
>
> That item’s size is above the cache bypass threshold of 100 MiB as
> currently configured on berlin:
>
> $ du -hs /gnu/store/wqqzcxrhbnv0nzg64iiiqd5grr4vk2zg-guix-5a6b1a5
> 124M/gnu/store/wqqzcxrhbnv0nzg64iiiqd5grr4vk2zg-guix-5a6b1a5
>
> The immediate fix/workaround is to raise that threshold.

I raised the threshold to 150 MiB in maintenance.git commit
213384e43de63ce3a5a55599e8fb89891ffef7eb.

I reconfigured berlin and restarted ‘guix publish’ seconds ago.
Hopefully next time installation tests won’t have that problem.

Ludo’.

bug#54447: cuirass: missing derivation error

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> Mathieu Othacehe  skribis:
>
>> A lot of builds, among them ~20 system tests[1], are failing with:
>> "cannot build missing derivation
>> ?/gnu/store/hs6kp1lqgymhyp3jndc0dsp0pn4psgv0-gui-installed-desktop-os-encrypted.drv?"
>> errors.
>>
>> Those derivations are present on the CI head node. This means that the
>> errors occur during substitution. This is most likely caused by some
>> issue with the publish server, because:
>>
>> - The publish server serves a 404 error. We should get rid once and for
>>   all of this 404 thing, pushing something like:
>>   https://issues.guix.gnu.org/50040.
>>
>> or
>>
>> - The publish server is not fast enough and hits an Nginx timeout that
>>   closes the communication.
>
> Also being discussed at .

I got confirmation that the cache-bypass-threshold hypothesis holds, at
least for system tests.

Namely, looking at ,
which ends like this:

--8<---cut here---start->8---
@ substituter-succeeded /gnu/store/qh2876i5l1wvxgwhg9fbl9zmb3px3n2m-gc-roots.drv
fetching path 
`/gnu/store/fh9dnmrfsz429pwqmvsjnk0snlm959kc-xdg-mime-database-builder'...
@ substituter-started 
/gnu/store/fh9dnmrfsz429pwqmvsjnk0snlm959kc-xdg-mime-database-builder substitute
Downloading 
http://141.80.167.131/nar/lzip/fh9dnmrfsz429pwqmvsjnk0snlm959kc-xdg-mime-database-builder...
. xdg-mime-database-builder3.6MiB/s 00:00 | 3KiB 
transferred. xdg-mime-database-builder1.9MiB/s 00:00 | 
3KiB transferred

@ substituter-succeeded 
/gnu/store/fh9dnmrfsz429pwqmvsjnk0snlm959kc-xdg-mime-database-builder
cannot build missing derivation 
‘/gnu/store/4r1wij3bzj9zv75ds82a93jl7bcman2x-installed-extlinux-os.drv’
--8<---cut here---end--->8---

Looking at the nginx and ‘guix publish’ logs, I found that the missing
substitute is not that of 4r1wij3bzj9zv75ds82a93jl7bcman2x (the .drv
itself) but rather that of a dependency of that .drv:

  [14/Oct/2023:23:22:09 +0200] "GET /wqqzcxrhbnv0nzg64iiiqd5grr4vk2zg.narinfo 
HTTP/1.1" 404 58 "-" "GNU Guile"

That item’s size is above the cache bypass threshold of 100 MiB as
currently configured on berlin:

--8<---cut here---start->8---
$ du -hs /gnu/store/wqqzcxrhbnv0nzg64iiiqd5grr4vk2zg-guix-5a6b1a5
124M/gnu/store/wqqzcxrhbnv0nzg64iiiqd5grr4vk2zg-guix-5a6b1a5
--8<---cut here---end--->8---

The immediate fix/workaround is to raise that threshold.

A better solution would be for system tests to depend on a fixed-output
derivation for the Guix source instead of the “source” above (I use
“source” as it is used in the context of ).

Thanks,
Ludo’.

bug#53406: union-build incorrectly handles grafts

[John Kehayias via Bug reports for GNU Guix]

Hi Ludo’,

Long time since I've thought about this bug, but with all the recent
grafts I thought to return to it. I'll have to make a new example to
dig again, but wanted to think through where we might look to see
what's happening first.

On Tue, Jan 25, 2022 at 02:47 PM, Ludovic Courtès wrote:

> Hi John,
>
> John Kehayias  skribis:
>
[...]
>> Perhaps I was too hasty in noting this "problem" which like I said
>> was not the error I originally encountered. I was using a package
>> that constructs both the 64- and 32-bit libraries to put in a
>> container (say, a /lib32 and /lib64 or something similar to an FHS
>> environment). A collision was happening between a file and
>> directory, one being a good symlink and the other broken, rather
>> than a "real" mismatch in file vs directory. Anyway, going back to
>> that what I see is that one link is broken for the above reasons,
>> but the good one is good because it is to the *ungrafted* library
>> store path. I don't know now if these 2 things are connected other
>> than one led me to the other, but I turn now to what demonstrates my
>> original problem.
>>
>> I don't know why this happens or if it is something in this building
>> process that is not correct, but I did come up with a minimal
>> example (attached). The code is a bit odd in its stripped down form,
>> though hopefully is clear in what way this would be used to do
>> something useful (again, like an FHS environment or other
>> container). Apologies for the old style and lack of gexps which I'm
>> finally getting used to. The example package just tries to make a
>> dummy package that has, for illustration, a "/lib64" and "/lib32"
>> which link to the respective union-build inputs (of a single library
>> for simplicity). I don't think the actual package being made matters
>> so much, or how it is constructed, but that two inputs are
>> union-builds of the same library (x86_64 and i686) which should have
>> a graft of expat. Just my guess though.
>>
>> Doing:
>>
>> ls -la $(guix build -f graft-test.scm)/lib64/lib/libexpat*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.la
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so*
>> lrwxrwxrwx 1 root root 73 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1*
>> lrwxrwxrwx 1 root root 77 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1.8.1
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1
>>
>> is what we saw already: libexpat is the newer (replacement, 2.4.3)
>> version, with the full version symlink broken since the version
>> number is wrong. Likewise in other pieces that have the version
>> number, like share/doc. Okay, that's expected. But now, in the
>> i686-linux union-build input:
>>
>> ls -la $(guix build -f graft-test.scm)/lib32/lib/libexpat*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.la
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.la*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so*
>> lrwxrwxrwx 1 root root 73 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1*
>> lrwxrwxrwx 1 root root 77 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1.8.1
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1.8.1*
>>
>> all the links are good and to the original (version 2.4.1) expat. In
>> other words, the constructed union64 and union32 inputs (in the
>> sample code) do not both get grafted, even though doing just the
>> fhs-union command on it's own (not building both for another
>> package) does graft for either architecture. At least that seems
>> like the most obvious difference between the earlier example and
>> this new one.
>>
>> Why? Does the grafting just happen "once" somehow and misses the
>> "same" input again (but built for different system)? Is this
>> expected or just a weird/wrong way to do this kind of build which is
>> causing this? I'm not sure if this is just with union-build or if it
>> would happen just with inputs of the same library but different
>> architectures. I didn't know how to do that quickly off hand, so I
>> haven't tried it yet.
>
> Woow, it’s a 

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Maxim Cournoyer  writes:

> tags 61882 = moreinfo unreproducible
> quit
>
> Hi,
>
> Csepp  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> Hi,
>>>
>>> Csepp  writes:
>>>
 Maxim Cournoyer  writes:

> tags 61882 +notabug
> quit

 I don't think notabug applies until we actually know the root
 cause.
>>>
>>> Sadly I don't think there's anything actionable here until you can
>>> reproduce the problem and share the recipe with us, so I wanted to
>>> close
>>> the issue without it being marked as "resolved".
>>
>> Neither "resolved" nor "notabug" are applicable. If stalled incident
>> reports / issues are a problem, they should probably be marked as
>> stalled, or needinfo, for easy filtering. Marking it as notabug is
>> just
>> going to make the job of the next person harder when they search for
>> issues related to these symptoms.
>
> I don't think a bug as particular as 'my profile got corrupted'
> without
> any way to recreate it has much value; it's also the first time I've
> heard of such a report. That's why I'd prefer to treat it as an oddity
> and close it; if it reproduces (by you or others) let's reopen it,
> with
> fresh and clear information.
>
>> I appreciate all the work going into closing old issues, but I don't
>> think chasing a low open issue count should be a goal unto itself
>> See https://fvsch.com/stale-bots .
>
> To be clear, I wholly agree.  I've now tagged it as moreinfo and
> unreproducible.

It could be a file system bug, but while there are reports of BTRFS
being unstable in certain RAID modes, I would be very surprised if there
was a data corruption issue in the default single device mode.

My hunch is that Guix's profile update logic is not actually as atomic
as it's advertised and I interrupted it at the wrong moment.

bug#65924: [PATCH core-updates 3/3] gnu: git-minimal: Add coreutils and sed to PATH.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> Fixes .
>>
>> * gnu/packages/version-control.scm (git-minimal)
>> [arguments] : New field.
>> : Augment with (ice-9 match), (ice-9 textual-ports) and (guix
>> search-paths).
>> : Add patch-commands phase.
>> [inputs]: Add coreutils-minimal and sed.
>
> [...]
>
>> +  #:imported-modules `(,@%gnu-build-system-modules
>> +   ,@(source-module-closure '((guix search-paths
>
> I think we should avoid the dependency on (guix search-paths) here, to
> avoid situation such as that described in
> .

OK, I can see how that could be annoying, especially since (guix
search-paths) will see frequent new search paths additions.

I think the best course to avoid a repeat may be to document that only
modules part of the (guix build ...) prefix should be used on the build
side, with the list of exception modules, if there are any; what do you
think?

>> +  (add-after 'unpack 'patch-commands
>> +(lambda* (#:key inputs #:allow-other-keys)
>> +  (define (prepend-string-to-file text file)
>> +"Prepend TEXT to FILE."
>
> Nitpick: no need to add a docstring to internal defines because it’s
> optimized out and inaccessible (you can use a comment instead).

I think I did so here in case it's ever moved to (guix build utils) or
the likes; it seems a useful procedure to have around.  Thanks for the
bit of knowledge!

>> +(let ((content (call-with-input-file file
>> + (cut get-string-all <>
>> +  (call-with-output-file file
>> +(lambda (port)
>> +  (display text port)
>> +  (display content port)
>> +
>> +  (define PATH-variable-definition
>> +(let ((value
>> +   (match (evaluate-search-paths
>> +   (list $PATH)
>> +   (list #$(this-package-input 
>> "coreutils-minimal")
>> + #$(this-package-input "sed")))
>> + (((spec . value))
>> +  value
>> +  (string-append
>> +   (search-path-definition $PATH value
>> +   #:kind 'prefix) "\n\n")))
>> +
>> +  ;; Ensure that coreutils (for basename) and sed are on PATH
>> +  ;; for any script that sources the 'git-sh-setup.sh' file.
>> +  (prepend-string-to-file PATH-variable-definition
>> +  "git-sh-setup.sh")
>
> How about something along these lines instead:
>
>   ;; Instead PATH definition at the top of the file.
>   (substitute* "git-sh-setup.sh"
> (("^unset CDPATH" all)
>  (string-append "PATH=" (dirname (search-input-file inputs 
> "bin/basename"))
> ":$PATH\nexport PATH\n" all)))

I'd like to preserve prepending the shell expression to the beginning of
the file, as substitute* doesn't error when it doesn't match anything,
which could lead to silent breakage in the future (if that 'unset
CDPATH' line is ever moved/deleted).  The rest looks good, except we'd
have to add sed to the PATH as well.

I can send a new patch to that effect.

-- 
Thanks,
Maxim

bug#65924: [PATCH core-updates 1/3] gnu: git: Remove labels and use gexps.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> * gnu/packages/version-control.scm (git)
>> [native-inputs, inputs]: Remove labels.
>> [arguments]: Use gexps.  Use gexp variables input searching procedures where
>> it makes sense.
>
> [...]
>
>> +;; Tell 'git-send-email' where perl modules are.
>> +(wrap-program git-se*
>> +  `("PERL5LIB" ":" prefix
>> +,(search-path-as-list
>> +  '("lib/perl5/site_perl")
>> +  '#$(delete-duplicates
>> +  (append-map
>> +   (compose last 
>> package-transitive-propagated-inputs)
>> +   (list (this-package-input "perl-authen-sasl")
>> + (this-package-input "perl-net-smtp-ssl")
>> + (this-package-input 
>> "perl-io-socket-ssl")))
>> +;; Tell 'gitweb.cgi' where perl modules are.
>> +(wrap-program (string-append out "/share/gitweb/gitweb.cgi")
>> +  `("PERL5LIB" ":" prefix
>> +,(search-path-as-list
>> +  '("lib/perl5/site_perl")
>> +  '#$(delete-duplicates
>> +  (append-map
>> +   (compose last 
>> package-transitive-propagated-inputs)
>> +   (list (this-package-input "perl-cgi")))
>
> I wonder if this could be simplified, but I don’t have a good idea.
>
> Otherwise LGTM!

Thanks; this was merged some days ago to core-updates.  We can still
refine it though.

bug#54447: cuirass: missing derivation error

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Another example: https://ci.guix.gnu.org/build/1982454/details
>
> substitute: 
> substitute: [Kupdating substitutes from 'http://10.0.0.1'...   0.0%
> substitute: [Kupdating substitutes from 'http://10.0.0.1'... 100.0%
> cannot build missing derivation 
> ?/gnu/store/vwhgs9dkj9spryglb180j27dr5vidjxv-ecl-23.9.9.drv?

This one is from Sep. 9, which is before I deployed the remote-worker
fixes, so I’ll dismiss it (happy to look at more recent ones though!).

Tip of the day: M-: (build-farm-build 1982454)

Ludo’.

bug#63194: Fixed: OpenMoji font is drawn invisibly

[Timo Wilken]

This issue does not occur any more for me. Closing.

bug#66553: Request to merge rust-team

[Efraim Flashner]

On Sun, Oct 15, 2023 at 02:30:07PM +0200, Csepp wrote:
> 
> Efraim Flashner  writes:
> 
> > [[PGP Signed Part:Undecided]]
> > IMO rust-team branch is ready to merge. We've updated rust to 1.70,
> > librsvg to 2.56.4 and many new and updated packages. We've added a
> > phase
> > to the cargo-build-system to fail if it detects pre-built files and
> > we've set the cargo-build-system to skip the test phase by default,
> > allowing us to make sure that the packages have the correct inputs.
> > With
> > these changes I've gotten 100% of the packages built using the
> > cargo-build-system to build successfully.
> >
> > We're looking forward to this merge so we can continue bumping the
> > rust
> > version, work on cross-compilation and try to reduce the number of
> > packages which skip the build phase entirely.
> 
> Is the new build system still being worked on?

I haven't started working on integrating it yet.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66553: Request to merge rust-team

[Csepp]

Efraim Flashner  writes:

> [[PGP Signed Part:Undecided]]
> IMO rust-team branch is ready to merge. We've updated rust to 1.70,
> librsvg to 2.56.4 and many new and updated packages. We've added a
> phase
> to the cargo-build-system to fail if it detects pre-built files and
> we've set the cargo-build-system to skip the test phase by default,
> allowing us to make sure that the packages have the correct inputs.
> With
> these changes I've gotten 100% of the packages built using the
> cargo-build-system to build successfully.
>
> We're looking forward to this merge so we can continue bumping the
> rust
> version, work on cross-compilation and try to reduce the number of
> packages which skip the build phase entirely.

Is the new build system still being worked on?

bug#66537: configure: error: The Guile bindings of GnuTLS are missing

[Hiep Pham via Bug reports for GNU Guix]

Hi,

I'm on Fedora and started a shell with:

```
guix shell -D guix help2man git strace --pure
```

And then:

```
./bootstrap
./configure --localstatedir=/var
```

And it showed me this error:

```
[snip]
checking for guile-3.0 >= 3.0.3... yes
checking for guile-3.0... yes
checking if (gnutls) is available... no
configure: error: The Guile bindings of GnuTLS are missing; please 
install them.
```

I started the shell again with some dependencies but no luck :(

```
guix shell -D guix git strace guile-gnutls gnutls --pure
```

My current (guix describe):

```
   guix 8e8d20b
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: 8e8d20b6b35d3ab529f9045cc8a779cdcec9c471
```

-- 
Hiep

bug#66461: [PATCH] guix: import: opam: Handle list of licenses.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* guix/import/opam.scm (opam->guix-package): Handle lists of licenses.
---
Hello Simon,

Here's a quick fix.

Best,
Josselin

 guix/import/opam.scm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/guix/import/opam.scm b/guix/import/opam.scm
index e67146e593..86e82cde59 100644
--- a/guix/import/opam.scm
+++ b/guix/import/opam.scm
@@ -379,8 +379,10 @@ (define* (opam->guix-package name #:key (repo '("opam")) 
version #:allow-other-k
   (synopsis ,(metadata-ref opam-content "synopsis"))
   (description ,(and=> (metadata-ref opam-content "description")
beautify-description))
-  (license ,(spdx-string->license
- (metadata-ref opam-content "license"
+  (license ,(match (metadata-ref opam-content "license")
+  ((('string-pat strs) ...)
+   `(list ,@(map spdx-string->license strs)))
+  ((? string? str) (spdx-string->license str)
(filter
  (lambda (name)
(not (member name '("dune" "jbuilder"

base-commit: d2923babf3ac44cb6faa88317f77c98f3016820d
-- 
2.41.0

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Ulf Herrman]

Ludovic Courtès  writes:

> Hello,
>
> Ulf Herrman  skribis:
>
>> That and a growing thirst for a nuclear option for package rewriting
>> brought about by trying to debug deep transformations while
>> simultaneously experimenting with rewriting a manifest of around 270
>> packages.
>
> On that topic of a catch-all option for rewriting: there’s an unused
> procedure called ‘map-derivation’, which performs rewriting at the level
> of derivations.  It’s harder to use, more expensive, but who knows,
> perhaps we’ll find a motivating use case…  (Allowing for graph rewriting
> has been a major goal for me since the beginning.)
>
>> There are really several distinct issues at play here:
>> 1. The case of #:qtbase and #:guile being invisible to package-mapping.
>>This is what I first noticed, and cannot be fixed without modifying
>>the build systems.  This is what prompted looking for packages in
>>package and bag arguments, and recursing into lists therein (just in
>>case an argument took a list of packages).
>
> How are #:qtbase and #:guile invisible to package mapping?
>
> They appear in the bag inputs and thus are definitely visible to
> ‘package-mapping’, as a I showed with the CMake and Python examples in
> this thread.

"Invisible to package-mapping" was perhaps not the clearest phrasing;
"not completely replaced by package-mapping" might be better.  qtbase
does indeed go in the bag inputs, but replacing the bag inputs has no
effect on the bag arguments, and even if we replaced it in the bag
arguments as well, it might not even be in there to begin with, in which
case the bag-builder would introduce a default that is only visible at
the level of derivations.

>
> For good measure :-) here’s an example with #:qtbase:
>
> $ ./pre-inst-env guix build qgit -n
> substitute: updating substitutes from 'http://192.168.1.48:8123'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> 0.4 MB would be downloaded:
>   /gnu/store/7b20q17yg90b62404chgbnwgvd6ry1qf-qgit-2.10
> $ ./pre-inst-env guix build qgit -n --with-latest=qtbase
> following redirection to 
> `https://mirrors.ocf.berkeley.edu/qt/official_releases/qt/'...
> following redirection to 
> `https://mirrors.ocf.berkeley.edu/qt/official_releases/qt/6.6/'...
> guix build: warning: cannot authenticate source of 'qtbase', version 6.6.0
>
> Starting download of /tmp/guix-file.CTehnY
> From 
> https://mirrors.ocf.berkeley.edu/qt/official_releases/qt/6.6/6.6.0/submodules/qtbase-everywhere-src-6.6.0.tar.xz...
>  …-src-6.6.0.tar.xz  46.1MiB  
>   
> 12.9MiB/s 00:04 ▕██▏ 100.0%
> substitute: updating substitutes from 'http://192.168.1.48:8123'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 
> 100.0%
> The following derivations would be built:
>   /gnu/store/paixxkdaakv55bffggxx4l9hiknl8i5r-qgit-2.10.drv
>   /gnu/store/f9fdjk1g1s1aqmlmi4clla2kqns7283v-qtbase-6.6.0.drv
> 0.4 MB would be downloaded:
>   /gnu/store/nl9dadzfmjm9wg7v3r31jkx773dl683x-module-import-compiled
>   /gnu/store/6zryxmypw0wygayc9pvhyxkx47w0lyci-gperf-3.1
>   /gnu/store/a57n7wy8mdi7l52pr4zg07132blgj5xp-qgit-2.10-checkout

And if you do a quick 'cat
/gnu/store/paixxkdaakv55bffggxx4l9hiknl8i5r-qgit-2.10.drv'...

--
Derive
([("out","/gnu/store/z8qrhfmicylxy2mwvcvh9sizfhd3x4d3-qgit-2.10","","")]
 ,[("/gnu/store/0jk33gpzyicyppbnh458213007v0qjhs-mesa-23.1.4.drv",["out"])
   ,("/gnu/store/0njvvgjlb52abhqnmb4rx22sfkxm2h9c-gcc-11.3.0.drv",["out"])
   ,("/gnu/store/0p1sns81qbgr8ayiv02fv4rm5drcycd7-libxdamage-1.1.5.drv",["out"])
   ,("/gnu/store/14a2ban238fng3c8632lrfkmz54y7m2c-binutils-2.38.drv",["out"])
   ,("/gnu/store/1n39zcbr528b7rh9bf1pwfrm7mv8nr8m-bzip2-1.0.8.drv",["out"])
   
,("/gnu/store/2pv3mjjiwh37b0m3m1hijxifnchrw76i-libpciaccess-0.16.drv",["out"])
   ,("/gnu/store/3fy3bf7wysi1n1qz9jz8xzx11sgy8m6d-git-2.41.0.drv",["out"])
   ,("/gnu/store/3r0r8j76l0qvxasmb7rgn7lvpikjdyn1-libxdmcp-1.1.3.drv",["out"])
   ,("/gnu/store/4jfy1ca1d5772z15jcyk1v8wdwdcllbi-gzip-1.12.drv",["out"])
   ,("/gnu/store/5nvwagz2hphvlax2bnj93smr1rgrzr8l-libx11-1.8.1.drv",["out"])
   ,("/gnu/store/64vwaah2spd7q66hji6sm1j2fl6pd1rn-diffutils-3.8.drv",["out"])
   ,("/gnu/store/6k4xxkp725r09vkn7rz2gc50asjjhpkk-xorgproto-2022.2.drv",["out"])
   ,("/gnu/store/91b6yraa6qax7lq7riqg1ag6lql2gfzi-tar-1.34.drv",["out"])
   ,("/gnu/store/9kcv1x0lrf6fdck2j42zarxrvjzxxznv-coreutils-9.1.drv",["out"])
   ,("/gnu/store/9piaq0aaf202r1gq7crig1cr131kx8zn-file-5.44.drv",["out"])
   
,("/gnu/store/9y28bf3ywai2ybhr92c904s3cxsc8apx-libpthread-stubs-0.4.drv",["out"])
   ,("/gnu/store/ak17xsjb4zcw7sf0r0lxxiy4xmh57i2h-findutils-4.9.0.drv",["out"])
   

bug#66553: Request to merge rust-team

[Efraim Flashner]

IMO rust-team branch is ready to merge. We've updated rust to 1.70,
librsvg to 2.56.4 and many new and updated packages. We've added a phase
to the cargo-build-system to fail if it detects pre-built files and
we've set the cargo-build-system to skip the test phase by default,
allowing us to make sure that the packages have the correct inputs. With
these changes I've gotten 100% of the packages built using the
cargo-build-system to build successfully.

We're looking forward to this merge so we can continue bumping the rust
version, work on cross-compilation and try to reduce the number of
packages which skip the build phase entirely.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature