bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux

[Christopher Baines]

Richard Sent  writes:

> Christopher Baines  writes:
>
>> This derivation seems to have been built fine by the bordeaux build
>> farm:
>>
>>   
>> https://data.guix.gnu.org/gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv
>
> You're right. It looks like the derivation itself built fine based on
> that, but something seems off when the nar is sent. Assuming I
> understand the following correctly:
>
> --8<---cut here---start->8---
> ~/code/cloned/guix/guix $ guix build linux-libre --system=aarch64-linux
> substitute: updating substitutes from 'http://10.1.2.2:80'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivations will be built:
>   /gnu/store/v471590wpsw1fcnqrrr9bwh52skbb5rn-linux-libre-6.8.10.drv
>   
> /gnu/store/1wi10rg7236ck8k5vdrdfap5l7a9s9z0-linux-libre-6.8.10-guix.tar.xz.drv
> 143.1 MB will be downloaded:
>   /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz
> substituting 
> /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz...
> downloading from 
> https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz
>  ...
>  linux-libre-6.8.10-guix.tar.xz  136.5MiB 
>  23.9MiB/s 00:06 ▕█▋▏  
> 98.0%guix substitute: error: corrupt input while restoring 
> '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' 
> from #
> substitution of 
> /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz 
> failed
> guix build: error: some substitutes for the outputs of derivation 
> `/gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv'
>  failed (usually happens due to networking issues); try `--fallback' to build 
> derivation from source 
> --8<---cut here---end--->8---
>
> Even though the derivation was built, the substitution fails.

Yeah, something's up here specifically with the bordeaux build farm,
feel free to open a new issue.

You can tell something is wrong just by looking at the narinfo:

  https://bordeaux.guix.gnu.org/y813phs2n9xnb7zbcr07g0j9509bzbsb.narinfo

Given there's no compression here, the file size should be the same as
the nar size, but it's not, it's missing a few bytes.


signature.asc
Description: PGP signature

bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux

[Christopher Baines]

Richard Sent  writes:

> On aarch64 platforms, the linux-libre-guix.tar.xz.drv build times out
> [1].
>
> This package is known to have a long build time [2].
>
> Users can work around this by running the build locally with a (very,
> very large) max-silent-time (~28800 seconds on my machine). Given the
> impact of this issue (unable to build linux-libre on 64-bit Arm without
> running a multi-hour build), I think it's worth revisiting if the
> substitute server timeout should be increased again.
>
> Alternatively, perhaps we could fetch the officially released
> Linux-libre tarballs instead of computing them ourselves [3].
>
> [1]: https://ci.guix.gnu.org/build/4711550/log/raw
> [2]: https://mail.gnu.org/archive/html/guix-devel/2021-08/msg00077.html
> [3]: http://linux-libre.fsfla.org/pub/linux-libre/releases/
>
> CC'ing Christopher Baines since this deals with substitutes.

This derivation seems to have been built fine by the bordeaux build
farm:

  
https://data.guix.gnu.org/gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv

This is the timeout configuration for the bordeaux ARM build machines:

  (max-silent-time (* 12 3600))
  (timeout (* 72 3600))

e.g. 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/hatysa.scm#n262

The ci.guix.gnu.org Honeycomb timeouts are different, but don't look too
short. Maybe this build happened on an Overdrive system though.


signature.asc
Description: PGP signature

bug#71144: Interactive prompt opened upon shepherd config file error

[Christopher Baines]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> I think we should change the above to log and gracefully handle failure
>> to load an individual service file.
>
> With the change below, every service except the offending one is loaded
> and started as expected:
>
> --8<---cut here---start->8---
> [   22.450515] shepherd[1]: Service root running with value #t.
> [   22.454624] shepherd[1]: Service root has been started.
> [   22.711738] shepherd[1]: Exception caught while loading 
> '/gnu/store/fjis6iqpjfcnr90fy8rsg9v4j828jslv-shepherd-gwl-web.go': 
> #< components: (#<> #< origin: 
> #f> #< message: "Unbound variable: ~S"> #< irri
> [   22.711839] tants: (make-forkexec-constructor/container)> 
> #< kind: unbound-variable args: (#f "Unbound 
> variable: ~S" (make-forkexec-constructor/container) #f)>)>
> [   22.755146] shepherd[1]: starting services...
> [   22.756491] shepherd[1]: Configuration successfully loaded from 
> '/gnu/store/mq7y31xnjcjwjkyf6w7qiaq61g6n9f5x-shepherd.conf'.
> Uncaught exception in task:
> In fibers.scm:
> 172:8  7 (_)
> In ice-9/exceptions.scm:
>406:15  6 (_)
> In ice-9/boot-9.scm:
>   1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
> In shepherd/service.scm:
>824:39  4 (_)
> In oop/goops.scm:
>   1567:11  3 (cache-miss #f)
>1585:2  2 (_ _ _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1683:16  0 (raise-exception _ #:continuable? _)
> ice-9/boot-9.scm:1683:16: In procedure raise-exception:
> No applicable method for #< one-shot-service? (1)> in call 
> (one-shot-service? #f)
> [   22.798737] shepherd[1]: Starting service user-file-systems...
> [   22.800361] shepherd[1]: Starting service root-file-system...
> [   22.802015] shepherd[1]: Starting service host-name...
> [   22.803688] shepherd[1]: Starting service pam...
> [   22.805372] shepherd[1]: Starting service sysctl...
> [   22.806926] shepherd[1]: Starting service loopback...
> [   22.808225] shepherd[1]: Starting service firewall...
> --8<---cut here---end--->8---
>
> (There’s still this scary-looking but harmless backtrace in the middle:
> that’s because (start-in-the-background '(something-that-does-not-exist))
> throws like that as of 0.10.4.)
>
> Once booted, shepherd is fine and you can interact normally with it; the
> only thing missing is, in this case, the ‘gwl-web’ service, which we
> failed to load.
>
> I think that’s a significant improvement.
>
> Thoughts?

That looks good to me, the "Arrange to spawn a REPL if something goes
wrong" comment needs removing/updating, but that's the only thing I
spotted.


signature.asc
Description: PGP signature

bug#70932: FAIL tests/guix-shell.sh

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> ++ guile -c '(use-modules (guix utils))
>>   (display (%current-system))'
>> + this_system=x86_64-linux
>> ++ guile -c '(use-modules (guix utils))
>>   (display (if (string=? "riscv64-linux" (%current-system))
>> "x86_64-linux"
>> "riscv64-linux"))'
>> + other_system=riscv64-linux
>> + cat
>> + guix shell -D -f t-guix-shell-19847/some-package.scm -n
>> hint: Consider passing the `--check' option once to make sure your shell 
>> does not
>> clobber environment variables.
>>
>> + false
>
> This is in ‘tests/guix-shell.sh’ a test that checks that unsupported
> packages are rejected.  The ‘guix shell -D -f -t …’ command above is
> supposed to fail (non-zero exit code), but in your case it succeeded,
> hence the test failure.
>
> “make check TESTS=tests/guix-shell.sh” passes for me though with
> 9c3a8a380bcfebdb77af61532e7bfec523d7bde8.

I can just about see what's happening on this line now, I'm still not
sure why the exit status means the test fails.

I think I knew when I submitted the issue that the test was flaky as it
passed on the second attempt.


signature.asc
Description: PGP signature

bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

[Christopher Baines]

Maxim Cournoyer  writes:

> Hello,
>
> Liliana Marie Prikler  writes:
>
>> Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
>>> I've seen this when updating systems, but it seems like something is
>>> wrong with the handling of nss-certs.
>>> 
>>> I'm on a guix revision with nss-certs by default, and when I add
>>> nss-certs to my system packages (to simulate not removing it when
>>> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
>>> doesn't work).
>> I can confirm this on three machines (two of my own, one from a
>> relative): Having nss-certs in the packages field unexpectedly breaks
>> all known certificates.
>>
>>> My reading of the operating-system-packages code suggests that adding
>>> nss-certs shouldn't have any effect, but this doesn't seem to be
>>> working.
>> It would be really nice to detect the mismatching versions if it's
>> based on that.  IIUC we graft nss-certs now, so that we can hot-swap
>> stuff like pythons certifi package.  Is this use case broken by any
>> chance?
>
> Apparently having multiple nss-certs of the same version is no problem
> (they get deduped later).  The original problem would thus only exist
> when there are multiple versions of nss-certs listed in packages, as
> could happen for installer-generated configs that use
> '(specification->package "nss-certs"), which would pick the latest
> version and clash with the one in %base-packages.
>
> My code could call delete even in the first case, which would clear
> *all* nss-certs because they were the same object.  That's now guarded
> against in 35ae95061e1b843e1df069693177519f22f9a16d ("system: Do not
> delete all nss-certs packages when they are the same object."), which
> I've just pushed.

Great, thanks for fixing this Maxim!

Chris


signature.asc
Description: PGP signature

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

[Christopher Baines]

Simon Tournier  writes:

> On Wed, 22 Nov 2023 at 11:19, Ludovic Courtès  wrote:
>
>> As in:
>>
>>   (open-connection
>> #:assume-available-builtin-builders '("download"))
>
> Instead, why not check in ’git-fetch’?  Currently, the test is done
> against the local daemon, right?
>
> --8<---cut here---start->8---
> (define* (git-fetch ref hash-algo hash
> #:optional name
> #:key (system (%current-system))
> guile git)
>   "Return a fixed-output derivation that fetches REF, a 
> object.  The output is expected to have recursive hash HASH of type
> HASH-ALGO (a symbol).  Use NAME as the file name, or a generic name if #f."
>   (mlet %store-monad ((builtins (built-in-builders*)))
> (if (member "git-download" builtins)
> (git-fetch/built-in ref hash-algo hash name
> #:system system)
> (git-fetch/in-band ref hash-algo hash name
>#:system system
>#:guile guile
>#:git git
> --8<---cut here---end--->8---
>
> For example, why not a test as:
>
> (if (and SOMETHING
>  (member "git-download" builtins))
>
> And this SOMETHING could be a global variable, as
> %assume-builtin-builder, set to true by default and turn to false with
> an environment variable, as GUIX_ASSUME_BUILTIN.

I can think of a couple of reasons not to do this via an environment
variable.

Having the logic in git-fetch via an environment variable would mean
that if other builtins are added, the code generating derivations using
them would also have to check the environment variable. Specifying the
builtin's that are available on a store connection would work
automatically in the case of new builtins being added..

There's also trade-offs in control when using environment variables, or
deciding when to take the value from an environment variable and switch
to passing the value around through arguments or other means. Consider
the case where you have a single process which has multiple store
connections open and it wants to specify different available builtin's
on particular store connections. This would become quite difficult when
using an environment variable, but work easily when specifying the
builtins available on the store connection.


signature.asc
Description: PGP signature

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Hi,
>>
>> Christopher Baines  skribis:
>>
>>> The bordeaux build farm depends on computing the derivations on one
>>> machine, then potentially building them on a different machine.
>>>
>>> Some of the build machines don't have a new enough guix-daemon that
>>> understands builtin:git-download, so derivations that use this are
>>> sometimes failing (e.g. [1])
>>>
>>> 1: https://bordeaux.guix.gnu.org/build/10cc5622-6b1f-4f28-ad9a-41cf796d7a15
>>>
>>> One potential approach to address this is somehow have the data service
>>> indicate that it wants compatible derivations when computing them,
>>> rather than to have guix do feature detection against the guix-daemon
>>> that is being used at the point the derivations are being computed.
>>
>> Would it work for you if we added a keyword argument to
>> ‘open-connection’ in (guix store) that would let you select which
>> builtins to use?
>>
>> As in:
>>
>>   (open-connection
>> #:assume-available-builtin-builders '("download"))
>
> Yep, that would at least allow freezing the available builtins going
> forward and separating it from the running daemon.

I've now sent some patches which add this option to #71038.


signature.asc
Description: PGP signature

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

"pelzflorian (Florian Pelz)"  writes:

> Hello Christopher.
>
> Christopher Baines  writes:
>> Had the changes waited for longer, then these failures should have been
>> spotted by QA, I would guess that the revision might have failed to be
>> processed, and if it was processed successfully, the nss failures should
>> have shown up, so maybe we should start requiring [5] that not only are
>> changes sent to guix-patc...@gnu.org, but that QA processes them (to
>> some extent) before merging?
>>
>> 5: 
>> https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html#
>
> Yes, though note that the nss change did provide security fixes:
>
> commit e584ff08b162c46ef587daca438e97d56bc20b32
> Author: Maxim Cournoyer 
> Date:   Wed Apr 24 11:22:30 2024 -0400
>
> gnu: nss: Graft with version 3.98 [security fixes].
>
> This fixes CVE-2023-5388, CVE-2023-6135 and CVE-2024-0743.
>
> * gnu/packages/nss.scm (nss) [replacement]: New field.
> (nss-3.98): Rename variable to...
> (nss/fixed): ... this.  Make it a hidden package.
> * gnu/packages/librewolf.scm (librewolf) [inputs]: Replace nss-3.98 with
> nss/fixed.
>
> Change-Id: I8cc667c53a270dfe00738bf731923f1342036624
>
> I suppose the requirement to wait for QA should apply to security fixes
> as well?

Well, there's a risk in not testing things across multiple
machines/architectures at least. The value of getting a security fix
merged quickly is reduced if users on some architectures/systems can't
use it.

There's always going to be trade offs, and that's fine, but the question
is more what can be done to try and improve things for the future.


signature.asc
Description: PGP signature

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

Maxim Cournoyer  writes:

>> Before closing this bug, it would be good to understand more about how
>> this happened and from that try to think if anything can be done to
>> prevent similar issues in the future?
>>
>> At least from what I can see on the issues, the problem was introduced
>> with the update to 3.98.0 [3] and then continued with the update to 3.99
>> [4]. Given the changes in 70662 were sent to guix-patches and then
>> merged less than 24 hours later, I'd imagine that wasn't sufficient time
>> for data.qa.guix.gnu.org to fail attempting to build nss.
>
> I think in [3] you meant https://issues.guix.gnu.org/70569, not #70662.

Ah, yep.

> Since this was security sensitive, I built it on x86_64, tested it there
> to ensure that IceCat worked as expected, had others confirmed it worked
> for them on #guix then pushed.
>
> In the past, I've had more patience waiting for QA to build things, but
> since this is not guaranteed (it sometimes never happened), it seems
> reasonable to me to promptly push security fixes that were manually
> built & tested and adjust for any breakage later, if there is any.

I think pushing security fixes quickly is good, but this does set a
precedent on architecture support (only x86_64-linux matters).

For some packages (including nss in this instance), not looking at non
x86_64-linux support doesn't just affect users, the data service and
ci.guix.gnu.org were particularly affected, so for some packages it's
important to test across the "supported" systems just to ensure the
projects own tooling doesn't break.

>> 3: https://issues.guix.gnu.org/70662
>> 4: https://issues.guix.gnu.org/70618
>>
>> Had the changes waited for longer, then these failures should have been
>> spotted by QA, I would guess that the revision might have failed to be
>> processed, and if it was processed successfully, the nss failures should
>> have shown up, so maybe we should start requiring [5] that not only are
>> changes sent to guix-patc...@gnu.org, but that QA processes them (to
>> some extent) before merging?
>
> I have some apprehensions about that; given the QA build farm is
> somewhat under-resourced for builds, I fear security changes could be
> gated for longer periods of time than is reasonable to wait.  If we go
> that route, I think we should dedicate more hardware first.

I think that's reasonable, I have been putting time in to the hardware,
but it's not been particularly easy going. The data service instances
are also still stuck on hardware I'm renting as well. In terms of QA
speed, there's the resources for data.qa.guix.gnu.org and there's the
hardware available for the bordeaux build farm.

There's also the potential to try and add more prioritisation. Currently
the data service prioritises branch revisions over patches, and newer
revisions more generally, but I guess it could prioritise security
related things. I'm not sure how to make that happen yet though, QA can
probably come up with the priorities, but I don't know how to convey
that to the data service.


signature.asc
Description: PGP signature

bug#70932: FAIL tests/guix-shell.sh

[Christopher Baines]

When attempting to update the guix package, I got this failure. The test
log makes no sense though, as it's trying to test for errors, so I have
no idea where to start in working out what is wrong.

I thought maybe the issue was here:

  guix shell: error: package intelmetool@4.7 does not support armhf-linux

But apparently that's expected? There's nothing in the log to indicate
that it's going to try something that should fail though.



FAIL: tests/guix-shell
==

+ guix shell --version
guix shell (GNU Guix) 1.4.0-20.37719d3
Copyright (C) 2024 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ configdir=t-guix-shell-config-19847
+ tmpdir=t-guix-shell-19847
+ trap 'rm -r "$tmpdir" "$configdir"' EXIT
+ mkdir t-guix-shell-19847 t-guix-shell-config-19847 
t-guix-shell-config-19847/guix
++ realpath t-guix-shell-config-19847
+ 
XDG_CONFIG_HOME=/tmp/guix-build-guix-1.4.0-20.37719d3.drv-0/source/t-guix-shell-config-19847
+ export XDG_CONFIG_HOME
+ guix shell --bootstrap --pure guile-bootstrap -- guile --version
accepted connection from pid 19864, user nixbld
guile (GNU Guile) 2.0.9
Copyright (C) 2013 Free Software Foundation, Inc.

License LGPLv3+: GNU LGPL 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ guix shell --bootstrap guile-bootstrap -S /dummy=bin/guile
hint: Consider passing the `--check' option once to make sure your shell does 
not
clobber environment variables.

guix shell: error: '--symlink' cannot be used without '--container'
+ guix shell --ad-hoc guile-bootstrap
guix shell: error: ad-hoc: unrecognized option
+ guix shell -s armhf-linux intelmetool -n
hint: Consider passing the `--check' option once to make sure your shell does 
not
clobber environment variables.

accepted connection from pid 19896, user nixbld
guix shell: error: package intelmetool@4.7 does not support armhf-linux
++ echo /proc/19847/fd/0 /proc/19847/fd/1 /proc/19847/fd/2 /proc/19847/fd/255 
/proc/19847/fd/3
+ initial_fd_list='/proc/19847/fd/0 /proc/19847/fd/1 /proc/19847/fd/2 
/proc/19847/fd/255 /proc/19847/fd/3'
++ guix shell --bootstrap guile-bootstrap -- bash -c 'echo /proc/$$/fd/*'
+ fd_list='/proc/19918/fd/0 /proc/19918/fd/1 /proc/19918/fd/2 /proc/19918/fd/3'
++ echo /proc/19918/fd/0 /proc/19918/fd/1 /proc/19918/fd/2 /proc/19918/fd/3
++ wc -w
++ echo /proc/19847/fd/0 /proc/19847/fd/1 /proc/19847/fd/2 /proc/19847/fd/255 
/proc/19847/fd/3
++ wc -w
+ test 4 -le 5
+ cat
+ cd t-guix-shell-19847
++ type -P true
+ SHELL=/gnu/store/a5i8avx826brw5grn3n4qv40g514505c-coreutils-9.1/bin/true
+ guix shell --bootstrap
+ grep 'not authorized' t-guix-shell-19847/stderr
guix shell: error: not loading 
'/tmp/guix-build-guix-1.4.0-20.37719d3.drv-0/source/t-guix-shell-19847/guix.scm'
 because not authorized to do so
+ rm t-guix-shell-19847/stderr
++ realpath t-guix-shell-19847
+ echo /tmp/guix-build-guix-1.4.0-20.37719d3.drv-0/source/t-guix-shell-19847
+ cd t-guix-shell-19847
+ guix shell --bootstrap -- true
accepted connection from pid 19942, user nixbld
guix shell: warning: no packages specified; creating an empty environment
+ mv t-guix-shell-19847/guix.scm t-guix-shell-19847/manifest.scm
+ cd t-guix-shell-19847
+ guix shell --bootstrap -- true
guix shell: warning: no packages specified; creating an empty environment
+ rm t-guix-shell-19847/manifest.scm
+ cat
+ cat
+ chmod +x t-guix-shell-19847/fake-shell.sh
++ cd t-guix-shell-19847
+++ realpath fake-shell.sh
++ 
SHELL=/tmp/guix-build-guix-1.4.0-20.37719d3.drv-0/source/t-guix-shell-19847/fake-shell.sh
++ guix shell --bootstrap
guix shell: loading environment from 
'/tmp/guix-build-guix-1.4.0-20.37719d3.drv-0/source/t-guix-shell-19847/manifest.scm'...
hint: Consider passing the `--check' option once to make sure your shell does 
not
clobber environment variables.

accepted connection from pid 19971, user nixbld
+ profile1=/tmp/guix-tests/store/vqrwmdf81v9wb4gb70g6v8b4xnm8l5ih-profile
++ guix shell --bootstrap guile-bootstrap -- 
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh -c 'echo 
$GUIX_ENVIRONMENT'
+ profile2=/tmp/guix-tests/store/vqrwmdf81v9wb4gb70g6v8b4xnm8l5ih-profile
+ test -n /tmp/guix-tests/store/vqrwmdf81v9wb4gb70g6v8b4xnm8l5ih-profile
+ test /tmp/guix-tests/store/vqrwmdf81v9wb4gb70g6v8b4xnm8l5ih-profile = 
/tmp/guix-tests/store/vqrwmdf81v9wb4gb70g6v8b4xnm8l5ih-profile
+ rm t-guix-shell-19847/manifest.scm
+ echo 'Broken manifest.'
+ cd t-guix-shell-19847
++ realpath fake-shell.sh
+ 
SHELL=/tmp/guix-build-guix-1.4.0-20.37719d3.drv-0/source/t-guix-shell-19847/fake-shell.sh
+ guix shell --bootstrap -q
hint: Consider passing the `--check' option once to make sure your shell does 
not
clobber environment variables.

guix shell: warning: no packages 

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

Christopher Baines  writes:

> nss@3.99 is really hard to build, it's so hard and so important that
> data.guix.gnu.org is still after two days trying to process [1]. I say
> so important because you have to build nss@3.99 to compute the channel
> instance derivations for Guix.
>
> 1: https://data.guix.gnu.org/revision/72308f262c910977e40c2c9f350dc563c0a8437a
>
> Looking at the next revision which has been processed [2], it's been
> built on riscv64-linux as the testsuite is disabled, and it has also
> built on aarch64-linux, but there's no successful build for any other
> architecture.
>
> 2: 
> https://data.guix.gnu.org/revision/9f183c3627a006e8fd3bb9708448bc05a6204e6d/package/nss/3.99.0?locale=en_US.UTF-8
>
> I think there's two issues here, was this spotted before merging, and
> what if anything can be done about this now. Where there's not a
> substitute available for nss@3.99, this will affect guix pull/guix
> time-machine, e.g.
>
>   → guix time-machine --commit=72308f262c910977e40c2c9f350dc563c0a8437a -- 
> describe
>   Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>nss-3.99.tar.xz  55.2MiB   
>   13.7MiB/s 00:04 
> ▕██▏ 100.0%
>   building /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv...

So with the changes in #70693 merged, this issue should be fixed going
forward, but the revisions with the broken nss are going to be affected
forever and thus the impact is going to drag on for a while. For
example, data.guix.gnu.org is going to be struggling to process the
revisions with the broken nss for a long while to come.

Before closing this bug, it would be good to understand more about how
this happened and from that try to think if anything can be done to
prevent similar issues in the future?

At least from what I can see on the issues, the problem was introduced
with the update to 3.98.0 [3] and then continued with the update to 3.99
[4]. Given the changes in 70662 were sent to guix-patches and then
merged less than 24 hours later, I'd imagine that wasn't sufficient time
for data.qa.guix.gnu.org to fail attempting to build nss.

3: https://issues.guix.gnu.org/70662
4: https://issues.guix.gnu.org/70618

Had the changes waited for longer, then these failures should have been
spotted by QA, I would guess that the revision might have failed to be
processed, and if it was processed successfully, the nss failures should
have shown up, so maybe we should start requiring [5] that not only are
changes sent to guix-patc...@gnu.org, but that QA processes them (to
some extent) before merging?

5: 
https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html#

Thanks,

Chris


signature.asc
Description: PGP signature

bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

[Christopher Baines]

I've seen this when updating systems, but it seems like something is
wrong with the handling of nss-certs.

I'm on a guix revision with nss-certs by default, and when I add
nss-certs to my system packages (to simulate not removing it when
upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
doesn't work).

My reading of the operating-system-packages code suggests that adding
nss-certs shouldn't have any effect, but this doesn't seem to be
working.


signature.asc
Description: PGP signature

bug#70838: guix pull fails

[Christopher Baines]

Simon Tournier  writes:

> I think ’nss’ is substitutable, so I guess you are rebuilding from
> source, right?
>
> Well, the build of ’nss’ works for me.
>
> --8<---cut here---start->8---
> $ guix build /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv 
> --check
>
> [...]
>
> successfully built /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv
> guix build: error: derivation
> `/gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv' may not
> be deterministic: output
> `/gnu/store/wkdc0z86av7jfkig7g4xphp6k52y82am-nss-3.99.0' differs
> --8<---cut here---end--->8---
>
> Hum, I do not know what could be the origin of the failure.  Maybe on
> your side (free space).  Or maybe hardware specific?

See https://issues.guix.gnu.org/70663 , that nss derivation is really
hard to build so it's not surprising it failed.

The issue is now fixed on master.


signature.asc
Description: PGP signature

bug#70456: Process gnome-team before core-updates

[Christopher Baines]

block 70456 by 70766
thanks

I think being able to merge core-updates is still a few weeks away, so I
think there's time to build and merge gnome-team without delaying
core-updates.

If it does become a problem, we can always switch approach and wait
until after core-updates is merged to look at gnome-team.


signature.asc
Description: PGP signature

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi Chris,
>
> Christopher Baines  writes:
>
>> nss@3.99 is really hard to build, it's so hard and so important that
>> data.guix.gnu.org is still after two days trying to process [1]. I say
>> so important because you have to build nss@3.99 to compute the channel
>> instance derivations for Guix.
>
> I agree that the nss test suite takes a ridiculous amount of time to run
> (multiple hours on a fast machine IIRC).  Are we missing a '--fast' test
> flag or something to make it run in a more reasonable amount of time?

I did read some of the all.sh script used for the tests and there is
some environment variables you can set here:

  https://github.com/nss-dev/nss/blob/master/tests/all.sh#L70-L82

It seems like there are 4 "cycles", maybe we could just run the standard
cycle or at least check how long they each take.


signature.asc
Description: PGP signature

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

Christopher Baines  writes:

> nss@3.99 is really hard to build, it's so hard and so important that
> data.guix.gnu.org is still after two days trying to process [1]. I say
> so important because you have to build nss@3.99 to compute the channel
> instance derivations for Guix.
>
> 1: https://data.guix.gnu.org/revision/72308f262c910977e40c2c9f350dc563c0a8437a
>
> Looking at the next revision which has been processed [2], it's been
> built on riscv64-linux as the testsuite is disabled, and it has also
> built on aarch64-linux, but there's no successful build for any other
> architecture.
>
> 2: 
> https://data.guix.gnu.org/revision/9f183c3627a006e8fd3bb9708448bc05a6204e6d/package/nss/3.99.0?locale=en_US.UTF-8
>
> I think there's two issues here, was this spotted before merging, and
> what if anything can be done about this now. Where there's not a
> substitute available for nss@3.99, this will affect guix pull/guix
> time-machine, e.g.
>
>   → guix time-machine --commit=72308f262c910977e40c2c9f350dc563c0a8437a -- 
> describe
>   Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>nss-3.99.tar.xz  55.2MiB   
>   13.7MiB/s 00:04 
> ▕██▏ 100.0%
>   building /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv...

Looking at the build failures for x86_64-linux, it seems that there's
just one test failure. There's a threshold of less than 5 seconds, and
it takes 5 to 7 seconds to complete. This probably isn't helped by using
faketime.

Here's an upstream bug [3] where they raised the threshold a bit, but
this isn't enough for our use case.

3: https://bugzilla.mozilla.org/show_bug.cgi?id=1835357

I've sent a patch here which increases the threshold by a lot:

  https://issues.guix.gnu.org/70693


signature.asc
Description: PGP signature

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

nss@3.99 is really hard to build, it's so hard and so important that
data.guix.gnu.org is still after two days trying to process [1]. I say
so important because you have to build nss@3.99 to compute the channel
instance derivations for Guix.

1: https://data.guix.gnu.org/revision/72308f262c910977e40c2c9f350dc563c0a8437a

Looking at the next revision which has been processed [2], it's been
built on riscv64-linux as the testsuite is disabled, and it has also
built on aarch64-linux, but there's no successful build for any other
architecture.

2: 
https://data.guix.gnu.org/revision/9f183c3627a006e8fd3bb9708448bc05a6204e6d/package/nss/3.99.0?locale=en_US.UTF-8

I think there's two issues here, was this spotted before merging, and
what if anything can be done about this now. Where there's not a
substitute available for nss@3.99, this will affect guix pull/guix
time-machine, e.g.

  → guix time-machine --commit=72308f262c910977e40c2c9f350dc563c0a8437a -- 
describe
  Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
  substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
100.0%
  substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
100.0%
  substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
100.0%
   nss-3.99.tar.xz  55.2MiB 
13.7MiB/s 00:04 ▕██▏ 
100.0%
  building /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv...


signature.asc
Description: PGP signature

bug#70662: Problems building nss@3.98.0

[Christopher Baines]

nss@3.98.0 seems really difficult to build, currently on the bordeaux
build farm it's failed all attempts to build it on all architectures
except riscv64-linux and aarch64-linux [1].

1: 
https://data.guix.gnu.org/revision/9593750698394b6fecd73e7fca00409ea1ffa2e3/package/nss/3.98.0?locale=en_US.UTF-8

The 3.88.1 version seemed to have built fine, so what's up here?


signature.asc
Description: PGP signature

bug#69466: Wrong colours for QA

[Christopher Baines]

Andreas Enge  writes:

> Am Mon, Apr 22, 2024 at 05:27:58PM +0100 schrieb Christopher Baines:
>> When implementing this I chose to have the review trump any other status
>> since hopefully any failing builds will have been taken in to account by
>> the reviewer.
>
> My impression is that reviews happen often before the package has reached
> the status of being built on QA.

I think that's fine too, QA is meant to be helpful not limiting.

I do still take this in to account when merging, not pushing things to
master if I'd like to see more things build, either just for substitute
availability, or because I'm on the lookout for build failures.


signature.asc
Description: PGP signature

bug#69466: Wrong colours for QA

[Christopher Baines]

Andreas Enge  writes:

> it looks like the dark green colour is wrongly chosen in QA,
> for instance here:
>https://qa.guix.gnu.org/issue/69441
> The issue has been reviewed, but "Comparison unavailable
> Yet to process revision".
>
> I think dark green should only appear when the package is reviewed
> AND builds correctly (so would be light green without reviewing).

When implementing this I chose to have the review trump any other status
since hopefully any failing builds will have been taken in to account by
the reviewer.

I think it's useful to highlight when there's a review regardless of the
other information that QA has.

1: 
https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/issue.scm#n163


signature.asc
Description: PGP signature

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi,
>
> Christopher Baines  writes:
>
>> Christopher Baines  writes:
>>
>>> I'm also really confused by what commits appear to be on the branch,
>>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
>>> core-updates, but it's a duplicate of
>>> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
>>> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
>>> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
>>> master.
>>
>> I've worked out at least when these two werid commits turned up on
>> core-updates.
>>
>> 12b15585a7 is mentioned here:
>>   https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html
>>
>> and 28d1413095 is mentioned here:
>>   https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html
>>
>>
>> With the changes last month in March, I was going to suggest deleting
>> the branch and then re-creating from f205179ed2 and trying to re-apply
>> the changes that should be on core-updates, while avoiding any
>> "duplicate" commits. However, I'm not even sure where to being with the
>> ~5000 commits pushed in September, at least one of them is a duplicate
>> of a commit on master, but I'm not sure how many of the other ~5000 are.
>>
>> For comparison, I did a merge of master in to core-updates today, and
>> this is what it shows up like on guix-commits:
>>
>>   https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html
>>
>> There are only two new revisions, the ed update I pushed, and the merge
>> commit, which is what a merge should look like as far as I'm aware.
>
> I think probably what happened is that in the middle of a merge of
> master -> core-updates (which entails sometimes painful conflicts
> resolution), a new commit pushed to core-updates, and to be able to push
> the resulting local branch (including the thousands of commits from the
> merge commit) got rebased on the remote core-updates.
>
> Perhaps another merge commit appeared on the remote around the same
> time, which would explain the duplicates.
>
> While I agree it's messy to have 5000 of duplicated commits, I'm not
> sure attempting to rewrite the branch, which has seen a lot of original
> commits, is a good idea (it'd be easy to have some good commits fall
> into cracks, leading to lost of work).

I think it's important to weigh up the cost and risks associated with
either merging these commits, or somehow avoiding doing so. I think the
potential impact is more than just a bit of messy Git history.

Assuming we merge core-updates without doing anything about these
duplicate commits, and taking the cwltool package as a semi-random
example, if you do:

  git log -p gnu/packages/bioinformatics.scm

You're going to see two commits for the update to 3.1.20240112164112,
that's maybe confusing, but not a big issue I guess since they look the
same, just different hashes.

But say you're looking at the Git history because you want that specific
version of cwltool and you're going to use guix time-machine or an
inferior looking at that revision. Well, it's a lucky dip. If you pick
the original master commit, you're in luck, you'll probably get
substitutes for cwltool. But if you pick the other seemingly identical
commit, you're effectively checking out core-updates as it was last
month and the chance of substitutes is much less likely. I also can't
really think how you'd work out which commit is best to use once
core-updates is merged? The easiest way would probably be to check the
signature, but that will only work most of the time.

This isn't a new issue, it's already problematic for substitute
availability to use intermediate commits (commits that weren't directly
pointed to by master). But there are over 1000 packages who's versions
are being changed on core-updates currently, or at least it looks like
this because of the duplicate commits, and if I'm correct about how
people are using the git history to find commits for specific versions
of packages, then having these duplicates in the Git history for master
forever more is going to catch people out for as long as those versions
remain relevant.


signature.asc
Description: PGP signature

bug#70456: Status of ‘core-updates’

[Christopher Baines]

Ludovic Courtès  writes:

> What’s the status of ‘core-updates’?  What are the areas where help is
> needed?
>
> I know a lot has happened since the last update¹, which is roughly when
> I dropped the ball due to other commitments, but I’m not sure where we
> are now.

I haven't really been following core-updates, but I have had a look
since there's a request to merge it now [1].

I'm really concerned by the commits on the branch though, assuming I'm
using Git right, there are 6351 commits on the branch:

  git log --pretty=oneline core-updates ^master | wc -l

Somehow, I think there's been a couple of pushes of commits to
core-updates that have partially duplicated lots of commits from master,
I put some more details in:

  https://issues.guix.gnu.org/70456#3

I think keeping the Git commit history clean and representative is
really important, so to me at least this means core-updates can't be
merged to master in it's current form, even if the changes overall from
these 6351 commits are reasonable.

I'm really not sure how to move forward though, I had a go at trying to
rebuild the branch without introducing the thousands of duplicate
commits and that produced a branch with 765 commits over master, which
still seems a lot, but a big improvement over 6351:

  https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt

That was really hard going though, as there's plenty of merge conflicts
along the way, and I'm pretty sure I solved some of them
incorrectly. The resulting branch also differs from core-updates.

Maybe someone with more time, care and attention could do a better job,
but it might be more worthwhile just starting fresh and rather than
trying to produce a like for like branch just without the thousands of
duplicate commits, effectively manually rebase the branch (without the
duplicate commits) on master and try to get the commits in to a usable
state.

Any ideas?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

Christopher Baines  writes:

> I'm also really confused by what commits appear to be on the branch,
> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
> core-updates, but it's a duplicate of
> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
> master.

I've worked out at least when these two werid commits turned up on
core-updates.

12b15585a7 is mentioned here:
  https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html

and 28d1413095 is mentioned here:
  https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html


With the changes last month in March, I was going to suggest deleting
the branch and then re-creating from f205179ed2 and trying to re-apply
the changes that should be on core-updates, while avoiding any
"duplicate" commits. However, I'm not even sure where to being with the
~5000 commits pushed in September, at least one of them is a duplicate
of a commit on master, but I'm not sure how many of the other ~5000 are.

For comparison, I did a merge of master in to core-updates today, and
this is what it shows up like on guix-commits:

  https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html

There are only two new revisions, the ed update I pushed, and the merge
commit, which is what a merge should look like as far as I'm aware.


signature.asc
Description: PGP signature

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

Hey,

Thanks for raising this issue Steve, given the branch has been going for
around 9 months (since [1]) now, I think it's well overdue to start
looking at building and merging it.

1: https://lists.gnu.org/archive/html/guix-commits/2023-07/msg00332.html

I pushed a single commit plus a merge from master today, and that was
pretty difficult. There was plenty of conflicts, and I probably have
resolved some wrongly, and there's potentially some things that Git
didn't raise as conflicts but might have broken with merging in master.

I'm also really confused by what commits appear to be on the branch,
take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
core-updates, but it's a duplicate of
e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
master.

Putting aside the functional changes on core-updates, it's doesn't seem
good to merge these seemingly duplicate commits on to master. I'm not
sure how this happened though, or how to fix it.

Chris


signature.asc
Description: PGP signature

bug#70284: @ancronym not recognized as valid Texinfo in description

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi,
>
> Using an acrynym such as @acronym(SNES, Super Nintendo Entertainment
> System) currently throws an "invalid Texinfo markup" error at build
> time.

I think I've used acronyms in descriptions, seems like diffr in
rust-apps uses one for example.

The brackets are different though.


signature.asc
Description: PGP signature

bug#68439: [bug#69793] [PATCH] gnu: icewm: Update to 3.4.6

[Christopher Baines]

Andy Tai  writes:

> * gnu/packages/wm.scm (icewm): Update to 3.4.6
>
> Change-Id: Ieff1fc5417cfe164fa7886774e8855fd95248c8f
> ---
>  gnu/packages/wm.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks both, I've pushed this to master as
8cc450e59a4c83fa39097964f62c2b2c84e0aee3.

Chris


signature.asc
Description: PGP signature

bug#68561: Guix wrongfully claims there is no space left

[Christopher Baines]

Lars Rustand  writes:

> Guix is claiming that there is no space left on the device when none of
> my devices are in fact full. As you can see from the output of df -h
> there is more than enough space on all filesystems:
>
>
> Filesystem  Size  Used Avail Use% Mounted on
> none7.8G 0  7.8G   0% /dev
> /dev/nvme0n1p7  250G  159G   79G  67% /
> /dev/nvme0n1p1  2.0G  428K  2.0G   1% /boot/efi
> tmpfs   7.8G  281M  7.5G   4% /dev/shm
> efivarfs184K  137K   43K  77% /sys/firmware/efi/efivars
> none7.8G   24K  7.8G   1% /run/systemd
> none7.8G 0  7.8G   0% /run/user
> tmpfs   1.6G  8.0K  1.6G   1% /run/user/1000

Check df -i, it could be that some filesystem has run out of inodes.


signature.asc
Description: PGP signature

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> The bordeaux build farm depends on computing the derivations on one
>> machine, then potentially building them on a different machine.
>>
>> Some of the build machines don't have a new enough guix-daemon that
>> understands builtin:git-download, so derivations that use this are
>> sometimes failing (e.g. [1])
>>
>> 1: https://bordeaux.guix.gnu.org/build/10cc5622-6b1f-4f28-ad9a-41cf796d7a15
>>
>> One potential approach to address this is somehow have the data service
>> indicate that it wants compatible derivations when computing them,
>> rather than to have guix do feature detection against the guix-daemon
>> that is being used at the point the derivations are being computed.
>
> Would it work for you if we added a keyword argument to
> ‘open-connection’ in (guix store) that would let you select which
> builtins to use?
>
> As in:
>
>   (open-connection
> #:assume-available-builtin-builders '("download"))

Yep, that would at least allow freezing the available builtins going
forward and separating it from the running daemon.


signature.asc
Description: PGP signature

bug#67305: Build bffe.x86_64-linux on master is broken.

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi,
>
> cuir...@gnu.org (Cuirass) writes:
>
>> The build bffe.x86_64-linux for specification master is 
>> broken. You can find the detailed information about this build > href="https://ci.guix.gnu.org/build/2664791/details;>here.
>>
>> https://ci.guix.gnu.org/build/2664791/details
>
> Seems this new failure was triggered by an upgrade to
> guix-build-coordinator.

Indeed, but it looks to me to be a design issue/bug with CI covered by
#54447:

substitute:
substitute: updating substitutes from 'http://141.80.167.131'...   0.0%
substitute: could not fetch 
http://141.80.167.131/57337hc8rl2ljilf0xbbjrpiknjwqda7.narinfo 504
substitute: updating substitutes from 'http://141.80.167.131'... 100.0%
cannot build missing derivation 
‘/gnu/store/57337hc8rl2ljilf0xbbjrpiknjwqda7-bffe-0-2.722c37e.drv’


signature.asc
Description: PGP signature

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

[Christopher Baines]

Simon Tournier  writes:

> Hi Chris,
>
> On Fri, 17 Nov 2023 at 21:39, Christopher Baines  wrote:
>
>> The bordeaux build farm depends on computing the derivations on one
>> machine, then potentially building them on a different machine.
>>
>> Some of the build machines don't have a new enough guix-daemon that
>> understands builtin:git-download, so derivations that use this are
>> sometimes failing (e.g. [1])
>
> Do you mean that the drv file is generated using a new daemon then this
> drv file is “offloaded” to another machine using an older daemon and
> thus fails to build it?

Roughly, yep.

>> One potential approach to address this is somehow have the data service
>> indicate that it wants compatible derivations when computing them,
>> rather than to have guix do feature detection against the guix-daemon
>> that is being used at the point the derivations are being computed.
>
> Other solutions are: downgrade the daemon of one of the machine or
> update the daemon of other machines, no?
>
> Why would the latter not be possible?

It's possible, just difficult. Because with the current guix-daemon, the
build coordinator can only build things that can be GC'd, some machines
deliberately run older daemons to allow building newer things without
hitting this issue.


signature.asc
Description: PGP signature

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

[Christopher Baines]

The bordeaux build farm depends on computing the derivations on one
machine, then potentially building them on a different machine.

Some of the build machines don't have a new enough guix-daemon that
understands builtin:git-download, so derivations that use this are
sometimes failing (e.g. [1])

1: https://bordeaux.guix.gnu.org/build/10cc5622-6b1f-4f28-ad9a-41cf796d7a15

One potential approach to address this is somehow have the data service
indicate that it wants compatible derivations when computing them,
rather than to have guix do feature detection against the guix-daemon
that is being used at the point the derivations are being computed.


signature.asc
Description: PGP signature

bug#66997: nar-herder uses 10 GiB of resident memory, 100% CPU on hydra-guix-129

[Christopher Baines]

Maxim Cournoyer  writes:

> I was looking at top on the hydra-guix-129 node, which runs nar-herder,
> and saw this:
>
> 4772 nar-her+  20   0   28.9g  11.5g 100.0   6.1 55,55 S .nar-herder-rea
>
> 11.5 GiB of memory seems a bit excessive, no?  Its cumulated processing
> time is also at the top of the table, and it seems stuck at 100% of CPU
> usage.
>
> Is this expected of the nar-herder, or has it gone awry?

I think hydra-guix-129 was running an older version of the nar-herder,
so I've updated it and I think that's improved the situation.

I've just reconfigured the machine to use a specific commit at the
moment, but it would be good to bump the commit that the Guix package is
using.


signature.asc
Description: PGP signature

bug#39310: MariaDB reproducibility issue

[Christopher Baines]

Ludovic Courtès  writes:

> Hi!
>
> Marius Bakke  skribis:
>
>> Josh  writes:
>>
>>> Hi Guix,
>>>
>>> I ran into this issue when building mariadb 10.1.38. I've attached the
>>> last 300 lines of the log. Thanks
>>
>> I can reproduce this failure by checking out Guix 1.0.1 in a "time
>> machine" and trying to build MariaDB.  The problem is that the failing test
>> expects the current time to be earlier than 2020-01-21 15:32:22.
>
> I was trying to run:
>
>   guix time-machine --commit=0791437 -- build mariadb
>
> where commit 0791437f972caa7e48de91ad5cb150a614f617c2 is from Jan. 2019,
> and stumbled upon the test failure that Josh reported.
>
> Following your advice on IRC, Marius, I built that derivation,
> /gnu/store/p2d7i5258vi0rd9ydbpr9c1vb3sxcz6h-mariadb-10.1.37.drv, on a
> machine whose clocked I had switched back to 2018… and it worked!
>
> (I used one of the berlin build machines, so now there are substitutes
> for this particular derivation.)

This seems like this issue is addressed at least, and guix challenge
says mariadb is reproducible, so I'm going to mark this as done:

→ guix challenge --diff=simple mariadb

1 store items were analyzed:
  - 1 (100.0%) were identical
  - 0 (0.0%) differed
  - 0 (0.0%) were inconclusive


signature.asc
Description: PGP signature

bug#22304: Julia

[Christopher Baines]

Just checking this, looks like 1.8.3 is still not reproducible, just one
file differs though:

→ guix challenge --diff=simple julia
/gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3 contents differ:
  no local build for '/gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3'
  
https://ci.guix.gnu.org/nar/lzip/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3: 
0jzli7ym7ihj7zhqwqp8lgwn6c38n44ld1rdn39pa7n8qp1q154r
  
https://bordeaux.guix.gnu.org/nar/lzip/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3:
 0616kaa8pbhzrkvcnj191yw1pcd4gy73rvmcr2cv6j7pfxyrzj7y
  differing file:
/lib/julia/sys.so


signature.asc
Description: PGP signature

bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary.

[Christopher Baines]

Ludovic Courtès  writes:

> Fixes .
>
> This fixes a bug whereby libgit2-managed checkouts would keep growing as
> we fetch.
>
> * guix/git.scm (packs-in-git-repository, maybe-run-git-gc): New
> procedures.
> (update-cached-checkout): Use it.
> ---
>  guix/git.scm | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> Hi!
>
> This is a radical fix/workaround for the unbounded Git checkout growth
> problem, shelling out to ‘git gc’ when it’s likely needed (“too many”
> pack files around).
>
> I thought we might be able to implement a ‘git gc’ approximation using
> the libgit2 “packbuilder” interface, but I haven’t got around to doing
> it: .
>
> Once again, shelling out is not my favorite option, but it’s a bug we
> should fix sooner rather than later, hence this compromise.
>
> Thoughts?

This sounds good to me, the data service has this problem as well of
cached checkouts that grow to be too large and this sounds like it'll
address it.


signature.asc
Description: PGP signature

bug#63414: Evaluation comparison on cuirass

[Christopher Baines]

Ludovic Courtès  writes:

> Hello,
>
> Andreas Enge  skribis:
>
>> When working on a branch and deciding whether to merge it, we need a way
>> of comparing its status with that of the master branch. As far as I can see,
>> there is currently no way in cuirass to compare arbitrary evaluations and
>> get a list (or a dashboard) of builds that fail in one, but not the other.
>
> Going back to this, I agree with Josselin that the Data Service does an
> excellent job at comparing the status of different revisions; I think we
> should leverage that rather than try to implement something similar in
> Cuirass.
>
> Perhaps one thing we can improve though is the information flow from
> Cuirass to the Data Service.  ISTR that Christopher mentioned that the
> Data Service couldn’t easily get information about substitute
> availability from ci.guix, or something like that.

Substitute availability is easy to get, but there's some difficulties
around build information.

> Is there still a problem here, Chris?  If we need a new HTTP endpoint in
> Cuirass to address that, I’m happy to give a hand.

The data service used to poll ci.guix.gnu.org for builds and build
status information, but I stopped that quite a while ago after the data
got messy when the Cuirass database was deleted and recreated. Since the
data service stores and uses the build IDs from Cuirass, it's confusing
when they're reused.

Anyway, even ignoring that, I'm unsure if polling worked well. That's
why I started to look at pushing data from Cuirass to the data
serivce. I did implement that, but the code on the Cuirass side was
never used. It's that same endpoint though that the build coordinator
uses to send build information to the data service (both instances).

The other blocker to making use of Cuirass data in the data service is
making sure it's high quality, in particular that if it says a build has
failed, I at least want to know it's started to build that
derivation. We don't want things showing up on QA as problems when it's
just Cuirass being unable to start builds.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#65858: mumi crashes

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi Christopher,
>
> Christopher Baines  writes:
>
> [...]
>
>>> Here's a fresh crash (on berlin):
>>>
>>> 2023-10-24 06:22:58 GET
>>> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065806%29%20%7B%0A%20%20%20%
>>> 20open%0A%20%20%7D%0A%7D%0A=%7B%7D 200
>>> 2023-10-24 06:22:58 GET /issue/29433/attachment/1/ 200
>>> 2023-10-24 06:22:58 GET
>>> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065853%29%20%7B%0A%20%20%20%
>>> 20open%0A%20%20%7D%0A%7D%0A=%7B%7D 200
>>> 2023-10-24 06:22:58 GET
>>> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065869%29%20%7B%0A%20%20%20%
>>> 20open%0A%20%20%7D%0A%7D%0A=%7B%7D 200
>>> 2023-10-24 06:23:15 GET Uncaught exception in task:
>>> 2023-10-24 06:23:15 In procedure port-auxiliary-write-buffer: Wrong
>>> type argument in position 1 (expecting
>>>  open port): #
>>> 2023-10-24 06:23:15 In fibers.scm:
>>> 2023-10-24 06:23:15 172:8  6 (_)
>>> 2023-10-24 06:23:15 In ice-9/boot-9.scm:
>>> 2023-10-24 06:23:15   1752:10  5 (with-exception-handler _ _ #:unwind? _ # 
>>> _)
>>> 2023-10-24 06:23:15 In fibers/web/server.scm:
>>> 2023-10-24 06:23:15214:25  4 (_)
>>> 2023-10-24 06:23:15 In ice-9/suspendable-ports.scm:
>>> 2023-10-24 06:23:15  83:4  3 (write-bytes # 
>>> #vu8(47 42 …) …)
>>> 2023-10-24 06:23:15 In unknown file:
>>> 2023-10-24 06:23:152 (port-write # 
>>> #vu8(47 42 # …) …)
>>> 2023-10-24 06:23:15 In ice-9/boot-9.scm:
>>> 2023-10-24 06:23:15   1685:16  1 (raise-exception _ #:continuable? _)
>>> 2023-10-24 06:23:15   1685:16  0 (raise-exception _ #:continuable? _)
>>> 2023-10-24 06:23:15 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> 2023-10-24 06:23:15 In procedure fport_write: Broken pipe
>>
>> I think this is kind of expected. If NGinx hits the proxy_read_timeout
>> it'll return a 504 to the client and close the connection to Mumi I
>> think. I think what you're seeing here is Mumi trying to respond to a
>> request from NGinx that NGinx has closed.
>
> If it's expected, we should handle it and produce a useful warning
> instead of crashing, right?

As you can see from the above stack trace, this doesn't involve Mumi,
it's more of an issue for the guile-fibers web server. But yes, it would
be nice not to have this clutter in the logs.

That being said, if there are ways of having the application internally
timeout before NGinx times out, that can help to avoid this kind of
issue. Maybe that's not that easy for Mumi though.

I think I remember Ricardo doing some investigating and experimenting
with switching to non-suspendable ports when writing responses, and I
think that might have exhibited different behaviour.

It's probably worth trying to reproduce this in isolation, and double
checking if the ports implementation has any effect (obviously
suspendable ports are better, but this might be informative).



signature.asc
Description: PGP signature

bug#65858: mumi crashes

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi,
>
> Maxim Cournoyer  writes:
>
>> Hi Arun,
>>
>> Arun Isaac  writes:
>>
>>> Hi Maxim,
>>>
>>> I have made a number of changes to mumi and reconfigured berlin with the
>>> latest mumi. Here is a quick summary of the main changes to mumi.
>>>
>>> - We now log the complete URI and the response code for every request to
>>>   mumi.
>>> - We now handle HEAD requests correctly. This should eliminate some of
>>>   the crashes we saw in the mumi log.
>>
>> Thanks!  Let's keep an eye on things.
>
> Here's a fresh crash (on berlin):
>
> 2023-10-24 06:22:58 GET 
> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065806%29%20%7B%0A%20%20%20%
> 20open%0A%20%20%7D%0A%7D%0A=%7B%7D 200
> 2023-10-24 06:22:58 GET /issue/29433/attachment/1/ 200
> 2023-10-24 06:22:58 GET 
> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065853%29%20%7B%0A%20%20%20%
> 20open%0A%20%20%7D%0A%7D%0A=%7B%7D 200
> 2023-10-24 06:22:58 GET 
> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065869%29%20%7B%0A%20%20%20%
> 20open%0A%20%20%7D%0A%7D%0A=%7B%7D 200
> 2023-10-24 06:23:15 GET Uncaught exception in task:
> 2023-10-24 06:23:15 In procedure port-auxiliary-write-buffer: Wrong type 
> argument in position 1 (expecting
>  open port): #
> 2023-10-24 06:23:15 In fibers.scm:
> 2023-10-24 06:23:15 172:8  6 (_)
> 2023-10-24 06:23:15 In ice-9/boot-9.scm:
> 2023-10-24 06:23:15   1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
> 2023-10-24 06:23:15 In fibers/web/server.scm:
> 2023-10-24 06:23:15214:25  4 (_)
> 2023-10-24 06:23:15 In ice-9/suspendable-ports.scm:
> 2023-10-24 06:23:15  83:4  3 (write-bytes # 
> #vu8(47 42 …) …)
> 2023-10-24 06:23:15 In unknown file:
> 2023-10-24 06:23:152 (port-write # 
> #vu8(47 42 # …) …)
> 2023-10-24 06:23:15 In ice-9/boot-9.scm:
> 2023-10-24 06:23:15   1685:16  1 (raise-exception _ #:continuable? _)
> 2023-10-24 06:23:15   1685:16  0 (raise-exception _ #:continuable? _)
> 2023-10-24 06:23:15 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2023-10-24 06:23:15 In procedure fport_write: Broken pipe

I think this is kind of expected. If NGinx hits the proxy_read_timeout
it'll return a 504 to the client and close the connection to Mumi I
think. I think what you're seeing here is Mumi trying to respond to a
request from NGinx that NGinx has closed.


signature.asc
Description: PGP signature

bug#63445: guix-build-coordinator guile-gnutls segfault

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Hi,
>>
>> Christopher Baines  skribis:
>>
>>> I've seen the build coordinator on bayfront crash a couple of times, and
>>> it seems to be segfaulting, maybe in gnutls?
>>>
>>> May 11 14:31:39 localhost vmunix: [15795370.287670]
>>> build-submitted[6013]: segfault at 0 ip 7f1e2e796415 sp
>>> 7f1b86ffd640 error 4 in
>>> guile-gnutls-v-2.so.0.0.0[7f1e2e79+17000]
>>> May 11 14:31:39 localhost vmunix: [15795370.287692] Code: 01 00 41
>>> 0f b7 14 24 48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89
>>> ef e8 d5 9d ff ff 4c 8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0
>>> 7f 48 83 f8 7d 74 3a 31 f6 bf 10 00 00 00 e8 c2
>>
>> Did you manage to get a backtrace?
>
> Not yet, I've been trying to change the core file size limit with the
> prlimit command, but I haven't seen any core dump files yet, so I'm not
> sure if I've missed something.

I've finally managed to get core dumps working for this now, and I've
reported the problem upstream.


signature.asc
Description: PGP signature

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

[Christopher Baines]

Christopher Baines  writes:

> Christopher Baines  writes:
>
>> Christopher Baines  writes:
>>
>>> I'm seeing this in the build coordinator agent, but it can be reproduced
>>> by tweaking the guix build script as below. The build coordinator uses
>>> suspendable ports as this is required to set timeouts for some I/O
>>> operations.
>>>
>>> I'm guessing this is maybe a bug within Guile, but I thought I'd start
>>> reporting it here anyway.
>>
>> I've sent a patch now to guile-devel that should fix this issue
>> https://lists.gnu.org/archive/html/guile-devel/2023-03/msg00014.html
>
> I've also now sent an update to the Guile package used by guix and the
> guix-build-coordinator to include the patch sent upstream:
>
>   https://issues.guix.gnu.org/62243

Delayed marking as done.


signature.asc
Description: PGP signature

bug#65434: https://data.guix.gnu.org/statistics is bogus

[Christopher Baines]

Maxime Devos  writes:

> That page contains:
>
> Guix revisions
> #
> Derivations
> #
>
> I think some code forgot to actually call these procedures.

Haha, that's a werid issue.

I haven't looked at that page for a long while as I don't think it was
performing well when you have any more than a few derivations in the
database. It probably just needs removing.


signature.asc
Description: PGP signature

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

[Christopher Baines]

Artyom Poptsov  writes:

> Hello,
>
> Sorry for the late reply!
>
> I removed
>   http_proxy=http://127.0.0.1:9080 https_proxy=http://127.0.0.1:9080
> from my "Environment" variable in "guix-daemon.service" and after I restarted
> the Guix daemon "guix pull" and "guix upgrade" went flawlessly.
>
> Thank you for your help.

I'm glad to hear you managed to resolve the issue.

Chris


signature.asc
Description: PGP signature

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

[Christopher Baines]

Artyom Poptsov  writes:

> Besides, I run GNU Guix on Ubuntu 22.04.2 LTS.
> Please find my SystemD Guix service attached.
>
> As you can see, I'm using a substitution service through Yggdrasil
> network: http://ci.guix.ygg.trop.in
> Also there's a proxy server configured.

The downloading of the nar will pass through the proxy you've got
configured, so I guess that could be involved.

I've now pushed a change to the code for downloading these nars so that
it outputs errors that it encounters. If you've got a checkout of
guix.git, you'll need to pull then do:

  ./pre-inst-env guix build -S texlive-hyphen-complete

or:

  ./pre-inst-env guix build --check -S texlive-hyphen-complete

Hopefully that output will include information about why the nar
couldn't be downloaded from bordeaux. You could also try configuring
wget to use the same proxy and trying the download that way.


signature.asc
Description: PGP signature

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

[Christopher Baines]

Artyom Poptsov  writes:

> Hello Christopher,
>
> I tried to build "texlive-hyphen-complete" using a local Guix clone
> with the following commands:
>
> $ cd guix
> $ guix shell -D guix
> $ ./bootstrap
> $ make -j$(nproc)
> $ guix build -K texlive-hyphen-complete
>
> Also I tried to build the derivation directly as you suggested:
> $ guix build 
> /gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
>
> I've got the same error in both cases.

I've included the output I get when building this derivation below, and
it does use bordeaux for me. Are you able to download [1]?

1: 
http://bordeaux.guix.gnu.org/nar/lzip/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout



→ guix build --check 
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
The following derivation will be built:
  
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
building 
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv...
guile: warning: failed to install locale
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_ALL is en_US.utf8
svn: warning: please check that your locale name is correct
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/CHANGES
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/INSTALL
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/LICENSE.data
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/LICENSE.documentation
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/README
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/dehyph-exptl.bib
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/dehyph-exptl.pdf
A
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic/dehyph-exptl/dehyph-exptl.tex
Exported revision 66594.
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_ALL is en_US.utf8
svn: warning: please check that your locale name is correct
svn: E155000: Destination directory exists; please remove the directory or use 
--force to overwrite
svn: E155000: 
'/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic'
 already exists
command "/gnu/store/z9g39lq591kzpvjj9apxzccd431pfjsz-subversion-1.14.2/bin/svn" 
"export" "--non-interactive" "--trust-server-cert" "-r" "66594" 
"--ignore-keywords" "--ignore-externals" 
"svn://www.tug.org/texlive/tags/texlive-2023.0/Master/texmf-dist//doc/generic/elhyphen"
 
"/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout/doc/generic"
 failed with status 1
Trying content-addressed mirror at bordeaux.guix.gnu.org...
 texlive-hyphen-complete-66594-checkout  2.3MiB 0B/s 00:00 [  ] 
  0.0%Downloading from 
http://bordeaux.guix.gnu.org/nar/lzip/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout
 (2.28 MiB)...
 texlive-hyphen-complete-66594-checkout  2.3MiB 3.4MiB/s 00:01 
[##] 100.0%successfully built 
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
successfully built 
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
/gnu/store/phsfa94n95wadi79fn7aqavc5qd3570d-texlive-hyphen-complete-66594-checkout


signature.asc
Description: PGP signature

bug#64872: guix pull: po4a: build failed

[Christopher Baines]

Artyom Poptsov  writes:

> Huh, it seems that the problem not in "po4a" itself but in
> "texlive-hyphen-complete".
>
> When I try to access
>   
> https://www.tug.org/texlive/tags/texlive-2023.0/Master/texmf-dist//doc/generic/elhyphen
> I get 404 error.

Ok, well maybe try building
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
and post the log.

Since quite recently, the subversion downloads should fallback to
talking to bordeaux.guix.gnu.org, which should be able to provide a nar
for this, even if you get a 404 from www.tug.org, but it would be good
to see if that is attempted.


signature.asc
Description: PGP signature

bug#64872: guix pull: po4a: build failed

[Christopher Baines]

Artyom Poptsov  writes:

> Hello, Guixers.
>
> Recently I started to see this error on "guix pull" -- please see
> the logs attached.

Are you able to share the end of the build log for
/gnu/store/qcjl6wfiy662s9knwvkb24vkrviw3jdn-po4a-0.68.drv ?

It has been built at least, so you should be able to substitute it as
well. You can try from bordeaux.guix.gnu.org if you can't use
ci.guix.gnu.org.


signature.asc
Description: PGP signature

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

[Christopher Baines]

Christopher Baines  writes:

> To confirm that this is an issue with the supported systems as reported
> by Guix, I had the data service print out the transitive supported
> systems for the guix package:
>
>   debug: Starting getting derivations for (i686-linux . #f)
>   looking at guix package (supported systems: (), system supported: #f, 
> target supported: #t
>   debug: Finished getting derivations for (i686-linux . #f), took 12  seconds
>
>   debug: Starting getting derivations for (armhf-linux . #f)
>   looking at guix package (supported systems: (), system supported: #f, 
> target supported: #t
>   debug: Finished getting derivations for (armhf-linux . #f), took 41 seconds

I realised that this could be non-deterministic because the order in
which the data service processes derivations is non-deterministic, from
the order of the systems returned by (guix platforms).

That led me to a reproducer:

  (use-modules (gnu packages) (guix packages) (gnu packages package-management))

  (fold-packages (lambda (pkg result)
   (package-transitive-supported-systems pkg "i586-gnu")
   #f)
 #f)

  (peek "guix package supported systems" (package-transitive-supported-systems 
guix "i686-linux"))

If you look at the %final-inputs packages, there's an issue with libc:

  (use-modules (ice-9 match)
   (gnu packages) (guix packages) (gnu packages package-management)
   (gnu packages commencement))

  (fold-packages (lambda (pkg result)
   (package-transitive-supported-systems pkg "i586-gnu")
   #f)
 #f)

  (for-each
   (match-lambda
 ((name pkg rest ...)
  (peek name
(package-transitive-supported-systems
 pkg
 "i686-linux"
   (%final-inputs "i686-linux"))

I think this could be because %final-inputs is cached based on system,
but doesn't seem to use system. Setting %current-system to system seems
to help, so I've sent a patch for that [1].

1: https://issues.guix.gnu.org/64763


signature.asc
Description: PGP signature

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

[Christopher Baines]

Hey,

I spotted this issue a few days ago, but I'm still pretty confused by
it. Both instances of the data service have sometimes been reporting
only a small number of package derivations for i686-linux and
armhf-linux.

I think the first revisions to exhibit this on the master branch for the
two data service instances are [1] and [2]. Given that for each of these
revisions, the other data service instance reports an expected number of
derivations, this issue seems to be non-deterministic.

1: https://data.guix.gnu.org/revision/67fb8efdf782592c133726a1ab7bc6692259e385
2: 
https://data.qa.guix.gnu.org/revision/09e73683a2c303016fa57bf5d84a8e997d4c0a30

To confirm that this is an issue with the supported systems as reported
by Guix, I had the data service print out the transitive supported
systems for the guix package:

  debug: Starting getting derivations for (i686-linux . #f)
  looking at guix package (supported systems: (), system supported: #f, target 
supported: #t
  debug: Finished getting derivations for (i686-linux . #f), took 12  seconds

  debug: Starting getting derivations for (armhf-linux . #f)
  looking at guix package (supported systems: (), system supported: #f, target 
supported: #t
  debug: Finished getting derivations for (armhf-linux . #f), took 41 seconds

This log output is from https://data.qa.guix.gnu.org/job/47888

This isn't just a one off thing though, it seems to happen quite
frequently for many revisions.

Any ideas?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#64609: Failure to "guix pull" at ddbfef2 on aarch64-linux

[Christopher Baines]

Michael Ford  writes:

> This morning when attempting to guix pull, on arch64-linux machines:
>
> guix pull
> Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to ddbfef2 (32 new commits)...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.gitddbfef2

...

> In gnu/packages/hurd.scm:
>740:35  3 (arguments #)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1780:13  1 (_ #< components: (#<> #)
> In unknown file:
>0 (backtrace #)
>
> (exception match-error (value "match") (value "no matching pattern")
> (value "aarch64-linux"))

Thanks for reporting this Michael, I've pushed a workaround as
5f7c714c63dd4313dbc0ba466ac73c7fb68966db.

Chris


signature.asc
Description: PGP signature

bug#64297: [Cuirass] Remote server not picking up job, losing workers

[Christopher Baines]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> The problem is most likely with the connection-to-port caching in
>> squee’s ‘connection-socket-port’, as can be seen in this other trace
>> where I added ‘pk’ calls in ‘connection-socket-port’:
>
> Confirmed, with a fix!
>
>   https://notabug.org/cwebber/guile-squee/pulls/8

I've merged that change, updated guile-squee in Guix, pulled on berlin,
reconfigured and restarted Cuirass now.

It seems to be building some now stuff at least.


signature.asc
Description: PGP signature

bug#64197: Segmentation fault while building ‘guix-cli-core.drv’

[Christopher Baines]

Ludovic Courtès  writes:

> I’ve seen this “failure to process the revision” on qa.guix due to a
> segfault while building Guix (from
> , commit
> f3ec19edf3c3bb902a06ac597e5954b35ee41bce):
>
> loading... 89.7% of 39 files[ 36/ 78] loading...   92.3% of 39 files[ 37/ 
> 78] loading...   94.9% of 39 files[ 38/ 78] loading...   97.4% of 39 files[ 
> 39/ 78] loading...  100.0% of 39 files[ 39/ 78] compiling...  0.0% of 
> 39 files[ 40/ 78] compiling...  2.6% of 39 files[ 41/ 78] 
> compiling...  5.1% of 39 files[ 42/ 78] compiling...  7.7% of 
> 39 files[ 43/ 78] compiling... 10.3% of 39 files[ 44/ 78] 
> compiling... 12.8% of 39 files[ 45/ 78] compiling... 15.4% of 
> 39 files[ 46/ 78] compiling... 17.9% of 39 files[ 42/400] loading...  
>  21.0% of 200 files[ 43/400] loading...  21.5% of 200 files[ 44/400] 
> loading...  22.0% of 200 files[ 45/400] loading...  22.5% of 200 filesbuilder 
> for `/gnu/store/c9crr8vmiid4cgld1bmxqwcrmicr5572-guix-cli-core.drv' failed 
> due to signal 11 (Segmentation fault)
> @ build-failed /gnu/store/c9crr8vmiid4cgld1bmxqwcrmicr5572-guix-cli-core.drv 
> - 1 builder for 
> `/gnu/store/c9crr8vmiid4cgld1bmxqwcrmicr5572-guix-cli-core.drv' failed due to 
> signal 11 (Segmentation fault)
> cannot build derivation 
> `/gnu/store/9d5as8x5k7z7vipmdvblbid261jpl3r5-guix-cli-core-modules.drv': 1 
> dependencies couldn't be built

This job looks to have failed at: 2023-06-19T13:54:13.047441

Looking at the logs on beid, I see this:

Jun 19 14:54:08 localhost vmunix: [4845598.954703] GC-marker-1[27719]: segfault 
at 170 ip 77e19a25 sp 76ad6c70 error 4 in 
libgc.so.1.5.1[77e1
2000+1c000] likely on CPU 15 (core 15, socket 0)
Jun 19 14:54:08 localhost vmunix: [4845598.954734] Code: 00 00 00 00 00 49 89 
f9 48 89 c8 41 54 41 81 e1 ff 0f 00 00 55 48 89 fd 83 e7 0f 53 4c 89 c9 48 89 
f3 48
 8b 70 30 48 c1 e9 04 <0f> b7 34 4e 49 89 f2 49 09 fa 75 4f 48 8d 4c 08 40 0f 
b6 31 40 84


signature.asc
Description: PGP signature

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hi,
>>>
>>> Christopher Baines  skribis:
>>>
>>>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and 
>>>> (defined? (quote transient?)) (map (# ?) ?)).
>>>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression 
>>>> (register-services (primitive-load "/gnu/st?") ?).
>>>> May 24 11:17:03 localhost shepherd[1]: Service host-name has been started.
>>>> May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started.
>>>> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1
>>>> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1
>>>> May 24 11:18:41 localhost shepherd[1]: Exiting shepherd...
>>>> May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; 
>>>> sending -337 SIGKILL.
>>>> May 24 11:23:55 localhost shepherd[1]: Service root is not running.
>>>
>>> The grace period expiration thing is probably due to the fact that
>>> shepherd is no longer processing signals, as I described here:
>>>
>>>   https://issues.guix.gnu.org/63736
>>>
>>> Could you share all of /var/log/messages (possibly privately, and
>>> limiting to “shepherd” lines) starting from when the machine booted?
>>> I’d like to see if there are hints of something that went wrong.
>>
>> The machine is hamal (one of the HoneyComb's) and I've added a user for
>> you now and added the SSH key from maintenance.git.
>>
>> So you should be able to: ssh l...@hamal.cbaines.net
>
> Doesn’t work right now; anything in the logs?

I believe I sorted access for Ludo, but nothing was found when looking
at the logs.


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> I've seen this happen with the build coordinator agent now (on
>> milano-guix-1):
>>
>>   2023-06-02 18:59:55 2023-06-02 18:59:55 (DEBUG):
>> fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: checking the availability of
>> build inputs
>>   2023-06-02 18:59:55 2023-06-02 18:59:55 (INFO ):
>> fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: setup successful, building:
>> /gnu/store/7fbrli2a8nzn676q8gz2b0i0y0lr9nxv-r-quasr-1.40.0.drv
>>   2023-06-02 19:00:46 Signals delivery fails constantly at GC #55
>>   2023-06-02 19:01:22 Signals delivery fails constantly
>>   2023-06-02 19:01:29 locale is en_US.utf8
>>   2023-06-02 19:01:29 (gnutls version: 3.7.7, guix version: 1.4.0-6.dc5430c)
>>
>> Which is a bit more concerning, since the build coordinator agent is
>> intentionally quite simple (no SQLite for example).
>
> The closure of (guix-build-coordinator agent) seems to be quite large
> still.
>
> Could you check what .so files are loaded by that code, perhaps via
> /proc/PID/maps?

I think I see these (that's on milano-guix-1 currently):

/gnu/store/0i81lpfnn05pmjc5f43q4nfvd27r08f7-guile-gnutls-3.7.12/lib/guile/3.0/extensions/guile-gnutls-v-2.so.0.0.0
/gnu/store/0jk7sl5xqwwdkzjpp9sxgz9z0d48a3vy-libunistring-1.0/lib/libunistring.so.2.2.0
/gnu/store/1r1azdi4hvfypnx14d01n60p4aa7g2im-libidn2-2.3.4/lib/libidn2.so.0.3.8
/gnu/store/1w1r6r56z9lhg8ghcb7lxss6mkn7d5l1-libgc-8.2.2/lib/libgc.so.1.5.1
/gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/lib/libguile-3.0.so.1.6.0
/gnu/store/8y0pwifz8a3d7zbdfzsawa1amf4afx1s-libgcrypt-1.10.1/lib/libgcrypt.so.20.4.1
/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/libgcc_s.so.1
/gnu/store/c2fx42ial6lr60s96xcbml5hd8vwaxq3-nettle-3.8.1/lib/libhogweed.so.6.6
/gnu/store/c2fx42ial6lr60s96xcbml5hd8vwaxq3-nettle-3.8.1/lib/libnettle.so.8.6
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libcrypt.so.1
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so.6
/gnu/store/ib2n2vzqpchc3bhh9i712w5sq9zapn8d-gmp-6.2.1/lib/libgmp.so.10.4.1
/gnu/store/j5kzdjan6mnf2ngmkc50fia8vrbpqi9b-libtasn1-4.19.0/lib/libtasn1.so.6.6.3
/gnu/store/k0p01a6b7hsxjfr65ga4f2gh6lh92aiq-lzlib-1.13/lib/liblz.so.1.13
/gnu/store/m9wi9hcrf7f9dm4ri32vw1jrbh1csywi-libgpg-error-1.45/lib/libgpg-error.so.0.33.0
/gnu/store/slzq3zqwj75lbrg4ly51hfhbv2vhryv5-zlib-1.2.13/lib/libz.so.1.2.13
/gnu/store/vq7dxp5la2lnhsvniwv38j0ggvsmzim7-p11-kit-0.24.1/lib/libp11-kit.so.0.3.0
/gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4/lib/libffi.so.8.1.2
/gnu/store/yr4lbvdyc4dgs76yij1dw2w2z8s84af8-gnutls-3.7.7/lib/libgnutls.so.30.34.1


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Christopher Baines  skribis:
>>
>>> Since the recent core-updates merge, I've seen the build coordinator
>>> using less memory, but it's also been crashing in a new way, up to 10
>>> times a day.
>>>
>>> In the log, you see something like:
>>>
>>>   2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
>>>   2023-05-07 09:15:42 Signals delivery fails constantly
>>>
>>> I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
>>> do with this.
>>
>> Normally on GNU/Linux libgc has:
>>
>>   #define SIG_SUSPEND SIGPWR
>>
>> The Coordinator fiddles with SIGALRM, SIGUSR1, SIGINT, and SIGPIPE,
>> which should normally be fine.
>>
>> Is there anything else that might interfere with libgc?
>
> I've seen this issue in both the build coordinator and nar-herder, both
> of which use guile-sqlite, so I wonder if that could have something to
> do with it.

I've seen this happen with the build coordinator agent now (on
milano-guix-1):

  2023-06-02 18:59:55 2023-06-02 18:59:55 (DEBUG): 
fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: checking the availability of build inputs
  2023-06-02 18:59:55 2023-06-02 18:59:55 (INFO ): 
fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: setup successful, building: 
/gnu/store/7fbrli2a8nzn676q8gz2b0i0y0lr9nxv-r-quasr-1.40.0.drv
  2023-06-02 19:00:46 Signals delivery fails constantly at GC #55
  2023-06-02 19:01:22 Signals delivery fails constantly
  2023-06-02 19:01:29 locale is en_US.utf8
  2023-06-02 19:01:29 (gnutls version: 3.7.7, guix version: 1.4.0-6.dc5430c)

Which is a bit more concerning, since the build coordinator agent is
intentionally quite simple (no SQLite for example).


signature.asc
Description: PGP signature

bug#63794: Acknowledgement (Bad error reporting in case of 404 during downloading)

[Christopher Baines]

Maxime Devos  writes:

> From: Christopher Baines
>> I think the key bits here might be a duplicate of #63634
>
> Looks like I need to upgrade my Guix system to fix substitution
> ... but "guix system build" is currently failing, which needs
> [cycle!].
>
> This time when doing "guix system build" I have a new error:
>
> [...]
> /gnu/store/qsb7s87y575f42zf79hyjih6adsdwpxb-python-fontmath-0.9.3
> vervangen...
> aan het downloaden van
> https://ci.guix.gnu.org/nar/lzip/l0xjgpcglms6ragxdpmjpkln7k4hjhd3-guix-1.4.0-6.dc5430c...
>  guix-1.4.0-6.dc5430c  44.3MiB 4.7MiB/s 00:04 ▕▏ ▏
>  45.5%guix substitute: waarschuwing: tijdens het binnenhalen van
>  
> https://ci.guix.gnu.org/nar/lzip/9y974g8k1rwv8bwxmshc4fl2dzm6cfij-upower-1.90.0:
>  de server is een beetje traag
> guix substitute: waarschuwing: probeer ‘--no-substitutes’ als het
> probleem hardnekkig is
> retrying download of
> '/gnu/store/9y974g8k1rwv8bwxmshc4fl2dzm6cfij-upower-1.90.0' with other
> substitute URLs...
> [...]
> retrying download of
> '/gnu/store/s94ng28j332my12r3qwvndk4w8kg7awx-openbios-qemu-ppc-1.1-1.af97fd7'
> with other substitute URLs...
> guix substitute: waarschuwing: tijdens het binnenhalen van
> https://ci.guix.gnu.org/nar/lzip/crsnsry2c0q55vi58g53qh2fr9ndb9qn-module-import-compiled:
> de server is een beetje traag
> guix substitute: waarschuwing: probeer ‘--no-substitutes’ als het
> probleem hardnekkig is
> guix substitute: waarschuwing: tijdens het binnenhalen van
> https://ci.guix.gnu.org/nar/lzip/qsb7s87y575f42zf79hyjih6adsdwpxb-python-fontmath-0.9.3:
> de server is een beetje traag
> guix substitute: waarschuwing: probeer ‘--no-substitutes’ als het
> probleem hardnekkig is
> retrying download of
> '/gnu/store/crsnsry2c0q55vi58g53qh2fr9ndb9qn-module-import-compiled'
> with other substitute URLs...
> retrying download of
> '/gnu/store/qsb7s87y575f42zf79hyjih6adsdwpxb-python-fontmath-0.9.3'
> with other substitute URLs...
>  guix-1.4.0-6.dc5430c  44.3MiB 3.1MiB/s 00:09 ▕███▊  ▏
>  65.6%guix substitute: waarschuwing: tijdens het binnenhalen van
>  
> https://ci.guix.gnu.org/nar/lzip/9y974g8k1rwv8bwxmshc4fl2dzm6cfij-upower-1.90.0:
>  de server is een beetje traag
> guix substitute: waarschuwing: probeer ‘--no-substitutes’ als het
> probleem hardnekkig is
> guix substitute: fout: failed to find alternative substitute for
> '/gnu/store/9y974g8k1rwv8bwxmshc4fl2dzm6cfij-upower-1.90.0'
> vervanging van
> /gnu/store/9y974g8k1rwv8bwxmshc4fl2dzm6cfij-upower-1.90.0 mislukt
> guix system: fout: beschadigde invoer tijdens het terugplaatsen van
> het archief uit #
>
> I haven't seen this ‘failed to alternative substitute for [...]’
> before and it seems unrelated to #63634. There is also bad error
> reporting here: failing to find a substitute is not a form of
> ‘corrupted/damaged input’.
>
> I'll do the usual tricks (*) to work-around for now, to get the fix in
> #63634 even though it doesn't fix everything.
>
> (*): while :; do guix system build /etc/config.scm -M1; done

The one workaround I'd suggest is cleaning the guix-daemon's substitute
cache (/var/guix/substitute/cache). That alone should be sufficient to
work around any missing zstd nars.


signature.asc
Description: PGP signature

bug#63794: Bad error reporting in case of 404 during downloading

[Christopher Baines]

Maxime Devos  writes:

> Problems:
>   * The server not having a file is not an exceptional situation;
> it should just skip this server or just report that there
> is no available location for this resource instead of
> a backtrace.
>
>   * It claims ‘corrupt input while restoring ...’, but it isn't
> corrupt -- non-existence is not a form of corruption.
>
>   * ‘1.46Gi’ should be ‘1.46GiB’ or ‘1.46GiB/s’ -- Gi is just a prefix,
> it's missing a unit.

I think the key bits here might be a duplicate of #63634


signature.asc
Description: PGP signature

bug#63794:

[Christopher Baines]

"N. Y."  writes:

> Are there any workarounds, for an inexperienced user who does not know much 
> about guix? I am getting 404's for
>
> - 
> https://bordeaux.guix.gnu.org/nar/zstd/arnx6fnjq85wscmr894d64cj3529r3h1-wxPython-4.2.0.tar.xz
> - 
> https://bordeaux.guix.gnu.org/nar/zstd/26q8viimh3r73549drqigvz07kl9v6pr-webkitgtk-2.40.1.tar.xz
>
> After a recent guix pull to 3807876 of 
> https://git.savannah.gnu.org/git/guix.git

Yep, clearing the guix-daemon's substitute cache should workaround these
issues.

On my system, that can be done by running:

  sudo rm -r /var/guix/substitute/cache/


signature.asc
Description: PGP signature

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and 
>> (defined? (quote transient?)) (map (# ?) ?)).
>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression 
>> (register-services (primitive-load "/gnu/st?") ?).
>> May 24 11:17:03 localhost shepherd[1]: Service host-name has been started.
>> May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started.
>> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1
>> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1
>> May 24 11:18:41 localhost shepherd[1]: Exiting shepherd...
>> May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; 
>> sending -337 SIGKILL.
>> May 24 11:23:55 localhost shepherd[1]: Service root is not running.
>
> The grace period expiration thing is probably due to the fact that
> shepherd is no longer processing signals, as I described here:
>
>   https://issues.guix.gnu.org/63736
>
> Could you share all of /var/log/messages (possibly privately, and
> limiting to “shepherd” lines) starting from when the machine booted?
> I’d like to see if there are hints of something that went wrong.

The machine is hamal (one of the HoneyComb's) and I've added a user for
you now and added the SSH key from maintenance.git.

So you should be able to: ssh l...@hamal.cbaines.net

Your users password is also in your home directory.


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> Since the recent core-updates merge, I've seen the build coordinator
>> using less memory, but it's also been crashing in a new way, up to 10
>> times a day.
>>
>> In the log, you see something like:
>>
>>   2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
>>   2023-05-07 09:15:42 Signals delivery fails constantly
>>
>> I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
>> do with this.
>
> Normally on GNU/Linux libgc has:
>
>   #define SIG_SUSPEND SIGPWR
>
> The Coordinator fiddles with SIGALRM, SIGUSR1, SIGINT, and SIGPIPE,
> which should normally be fine.
>
> Is there anything else that might interfere with libgc?

I've seen this issue in both the build coordinator and nar-herder, both
of which use guile-sqlite, so I wonder if that could have something to
do with it.


signature.asc
Description: PGP signature

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't
>> reboot or halt.
>>
>> root@hamal ~# halt
>> Service root is not running.
>
> Hey, why halt it if it’s not running?
>
> Seriously though, any insight from /var/log/messages?  I upgraded a
> bunch of machines and didn’t hit this particular problem.  Bruno
> reported a similar problem with 0.9.3, but this had nothing to do with
> the upgrade:
>
>   https://issues.guix.gnu.org/62619
>
> Could it be the same problem?  Do you see:
>
>   Assertion (eq? (canonical-name new) (canonical-name old)) failed.
>
> in /var/log/messages?

I don't see that, but I think these are the relevant log messages:

May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and 
(defined? (quote transient?)) (map (# ?) ?)).
May 24 11:17:02 localhost shepherd[1]: Evaluating user expression 
(register-services (primitive-load "/gnu/st?") ?).
May 24 11:17:03 localhost shepherd[1]: Service host-name has been started.
May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started.
May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1
May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1
May 24 11:18:41 localhost shepherd[1]: Exiting shepherd...
May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; 
sending -337 SIGKILL.
May 24 11:23:55 localhost shepherd[1]: Service root is not running.
May 24 11:24:16 localhost last message repeated 2 times
May 24 11:30:49 localhost syslogd (GNU inetutils 2.3): restart
May 24 11:30:49 localhost vmunix: [0.00] Booting Linux on physical CPU 
0x00 [0x410fd083]
May 24 11:30:49 localhost vmunix: [0.00] Linux version 
6.3.3-arm64-generic (guix@guix) (gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38) 
#1 SMP PREEMPT 1


signature.asc
Description: PGP signature

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

[Christopher Baines]

Hey!

On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't
reboot or halt.

root@hamal ~# halt
Service root is not running.

1: /gnu/store/y6w0xix15cq08qasmq75f04yzgbl98jx-shepherd-0.9.3


signature.asc
Description: PGP signature

bug#63634: nar 404 leads to hard ‘guix substitute’ crash

[Christopher Baines]

Ludovic Courtès  writes:

> Simon Tournier  skribis:
>
>> 2. :
> "https://bordeaux.guix.gnu.org/nar/zstd/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x-rust-base64-0.13.1.tar.xz:
> HTTP download failed: 404 (\"Not Found\")"
>
> Look:
>
> $ wget -qO- 
> https://bordeaux.guix.gnu.org/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x.narinfo
> StorePath: 
> /gnu/store/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x-rust-base64-0.13.1.tar.xz
> NarHash: sha256:0pynnlsiiq03h7ysfkzw53wkf6hfmplb63haz6bjqdc686rnf4q1
> NarSize: 49128
> References: 
> System: x86_64-linux
> Deriver: qcpzwblzpa2wprc4vwlm128bwckfj8rj-rust-base64-0.13.1.tar.xz.drv
> Signature: 
> 1;bayfront;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjRUE2MTcwNUZENjNCOTU1NzcwNjIxN0EyQjczN0U5NzI2RjM4Rjk1NkQwRTRCQjI4MjVBRTA2MTdDQjcxMDQ1MyMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDNGRjU3ODU1RTNERDMxQkJFMUY2NDEyMkU0MzNBNzcwMEZGNkI1ODExRUQ0NTBCQzVEQTcwMkQyNDk3ODZEMCMpCiAgIChzICMwN0ZCQjREN0YwNTExQTlBNzZENzBFNzUxQTc2NTM1MzE0MzU1Mzk1RUUwNzgzODU3REM2NEYxRDIxMTEzQjMxIykKICAgKQogICkKIChwdWJsaWMta2V5IAogIChlY2MgCiAgIChjdXJ2ZSBFZDI1NTE5KQogICAocSAjN0Q2MDI5MDJEM0EyREJCODNGOEEwRkI5ODYwMkE3NTRDNTQ5M0IwQjc3OEM4RDFERDRFMEY0MURFMTRERTM0RiMpCiAgICkKICApCiApCg==
> URL: nar/lzip/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x-rust-base64-0.13.1.tar.xz
> Compression: lzip
> FileSize: 49781
>
> See? zstd’s gone!  This confirms my hypothesis.
>
> BTW, ‘guix publish’ has provisions to not compress already-compressed
> files, as in the case above.  We should really share code, Chris.

I'm not sure if this is what you have in mind regarding code sharing,
but I'll use compressed-file? from (guix utils) in the nar-herder to
avoid generating cached compressions for these kind of files in the
future.


signature.asc
Description: PGP signature

bug#63634: nar 404 leads to hard ‘guix substitute’ crash

[Christopher Baines]

Ludovic Courtès  writes:

> So it seems ‘guix substitute’ picked /nar/zstd, even though
> bordeaux.guix is not advertising that.
>
> Or is it?
>
> $ sudo cat 
> /var/guix/substitute/cache/kzwjeblndsbkjzmjailrt4bnhguil7tqjmewzcyw22hgajbhfy3q/apw1y9nf8rqgxvjnlr1isbhpd502bcs5
> (narinfo (version 2) (cache-uri "https://bordeaux.guix.gnu.org;) (date 
> 1683633757) (ttl 15552000) (value "StorePath: 
> /gnu/store/apw1y9nf8rqgxvjnlr1isbhpd502bcs5-gcc-cross-aarch64-linux-gnu-11.3.0\nNarHash:
>  sha256:1am3v254jr9dpgd9r4dkjqxfgbp1xm0vl1hxl49cmmh97dg117z8\nNarSize: 
> 144790464\nReferences: 8rz7yh6zdzp4b78f4n9wqj3hav2md4d4-isl-0.24 
> 930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib 
> apw1y9nf8rqgxvjnlr1isbhpd502bcs5-gcc-cross-aarch64-linux-gnu-11.3.0 
> brzrf6qx5d83j1zvirc1xk14wrhyx4hf-binutils-cross-aarch64-linux-gnu-2.38 
> cinj0g8krh5s428jawsazawlfarp912k-gcc-cross-aarch64-linux-gnu-11.3.0-lib 
> cs3hw1wnxgijjzsd61whc8ar3qy9wjd6-mpfr-4.2.0 
> gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35 
> ib2n2vzqpchc3bhh9i712w5sq9zapn8d-gmp-6.2.1 
> rbjq50q2ik8c1glkj5f0ksnwfz64g16g-mpc-1.3.1 
> rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16 
> rjgpaj54q1q9n3hcvpzyp29fgi2nx6ls-ld-wrapper-aarch64-linux-gnu-0 
> slzq3zqwj75lbrg4ly51hfhbv2vhryv5-zlib-1.2.13 
> y4ndp9n5krkaiwgvw58c61n7h8ls9b0f-glibc-cross-aarch64-linux-gnu-2.35\nSystem: 
> x86_64-linux\nDeriver: 
> fqb09jygm70cmq03xmjm7al6gzajp1p5-gcc-cross-aarch64-linux-gnu-11.3.0.drv\nSignature:
>  
> 1;bayfront;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjNzA2MTI1QUFGMjcxQzM2MDM3RkY2MTIwMzI0NzI2NTVDMkU3OEY2NTA3OUY0MzgxMzY4NDhDQzA0OTVFRTIxRiMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDg1RTA2ODE3RTFENTdCQzE1NTAxOUNGNjA0QTQxMTlFRjNBREVGQ0VFOTE4NjQzMDIzQTExQzk4RDM3REVBOCMpCiAgIChzICMwMUIwMkQyNjI0MDhCMDIzMUMxMUVDODI1Q0Q2MTkzNTU5NDRCQUNBMzg4NjEwRDIxOEIzNTVCNjM1NjFCQjk3IykKICAgKQogICkKIChwdWJsaWMta2V5IAogIChlY2MgCiAgIChjdXJ2ZSBFZDI1NTE5KQogICAocSAjN0Q2MDI5MDJEM0EyREJCODNGOEEwRkI5ODYwMkE3NTRDNTQ5M0IwQjc3OEM4RDFERDRFMEY0MURFMTRERTM0RiMpCiAgICkKICApCiApCg==\nURL:
>  
> nar/lzip/apw1y9nf8rqgxvjnlr1isbhpd502bcs5-gcc-cross-aarch64-linux-gnu-11.3.0\nCompression:
>  lzip\nFileSize: 24767829\nURL: 
> nar/zstd/apw1y9nf8rqgxvjnlr1isbhpd502bcs5-gcc-cross-aarch64-linux-gnu-11.3.0\nCompression:
>  zstd\nFileSize: 39822104"))ludo@ribbon ~/src/guix [env]$
>
> So it seems that bordeaux.guix did advertise zstd at some point (and
> that narinfo is still in cache) but no longer does.
>
> Chris, can you confirm?

Yeah, this would have been a consequence of reducing the cache size [1].

1: 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=ce8d3000fda6b80c0cf3e6f8204e0ee293024e6b


signature.asc
Description: PGP signature

bug#63445: guix-build-coordinator guile-gnutls segfault

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> I've seen the build coordinator on bayfront crash a couple of times, and
>> it seems to be segfaulting, maybe in gnutls?
>>
>> May 11 14:31:39 localhost vmunix: [15795370.287670]
>> build-submitted[6013]: segfault at 0 ip 7f1e2e796415 sp
>> 7f1b86ffd640 error 4 in
>> guile-gnutls-v-2.so.0.0.0[7f1e2e79+17000]
>> May 11 14:31:39 localhost vmunix: [15795370.287692] Code: 01 00 41
>> 0f b7 14 24 48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89
>> ef e8 d5 9d ff ff 4c 8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0
>> 7f 48 83 f8 7d 74 3a 31 f6 bf 10 00 00 00 e8 c2
>
> Did you manage to get a backtrace?

Not yet, I've been trying to change the core file size limit with the
prlimit command, but I haven't seen any core dump files yet, so I'm not
sure if I've missed something.


signature.asc
Description: PGP signature

bug#63414: Evaluation comparison on cuirass

[Christopher Baines]

Josselin Poiret via Bug reports for GNU Guix  writes:

> Hi Andreas,
>
> Andreas Enge  writes:
>
>> When working on a branch and deciding whether to merge it, we need a way
>> of comparing its status with that of the master branch. As far as I can see,
>> there is currently no way in cuirass to compare arbitrary evaluations and
>> get a list (or a dashboard) of builds that fail in one, but not the other.
>>
>> Andreas
>
> I guess that this is one of the features that the Build Coordinator was
> built for (and it is pretty damn good at this).  Maybe we could start
> considering whether it makes sense to duplicate effort on Cuirass and
> the Build Coordinator?  I don't know how "production-ready" the build
> coordinator is, compared to Cuirass?  Maybe we could target getting the
> Build Coordinator up to feature parity with Cuirass so that it may be
> used on a wider scale?  If this is something we want to focus on, we
> could create a team around it and set clear goals, which would probably
> lessen the burden that's on Chris currently.
>
> I understand that Cuirass is general enough to support much more than
> Guix, but the coordinator is a wonderful piece of software and our
> workflows might be outgrowing it.

There's some pedantic bits here to bring up. The build coordinator
doesn't have anything to do with comparing revisions (it doesn't even
really know what builds correspond to which revisions), it's just for
performing builds potentially across many machines, and doing something
useful with the results.

The data service however is meant for comparing revisions. There's a
circular relationship between the two as well, since the data service
can provide substitutes for derivations, which enables the build
coordinator to easily build them, and then report the results of those
builds back to the data service. This information about builds is
important since that can then factor in to comparisons between
revisions.

On the bit about "feature parity with Cuirass" though, this is a bit
misleading as the build coordinator exists because I wanted something
with very different design decisions to Cuirass. In terms of core
features, the build coordinator was complete back in late 2020
[1]. There's obviously lots that Cuirass does that the build coordinator
does not, but adding features without looking at the bigger picture can
be detrimental in the long term.

1: https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00417.html

This is not to say there aren't things to work on in the build
coordinator. There are some ideas in the README and I'm more than happy
to try and help people get more involved.


signature.asc
Description: PGP signature

bug#63445: guix-build-coordinator guile-gnutls segfault

[Christopher Baines]

I've seen the build coordinator on bayfront crash a couple of times, and
it seems to be segfaulting, maybe in gnutls?

May 11 14:31:39 localhost vmunix: [15795370.287670] build-submitted[6013]: 
segfault at 0 ip 7f1e2e796415 sp 7f1b86ffd640 error 4 in 
guile-gnutls-v-2.so.0.0.0[7f1e2e79+17000]
May 11 14:31:39 localhost vmunix: [15795370.287692] Code: 01 00 41 0f b7 14 24 
48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89 ef e8 d5 9d ff ff 4c 
8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0 7f 48 83 f8 7d 74 3a 31 f6 bf 10 
00 00 00 e8 c2


May 11 14:47:31 localhost vmunix: [15796321.750945] build-submitted[697]: 
segfault at 0 ip 7f2194716415 sp 7f1ee3ffe5f0 error 4 in 
guile-gnutls-v-2.so.0.0.0[7f219471+17000]
May 11 14:47:31 localhost vmunix: [15796321.750968] Code: 01 00 41 0f b7 14 24 
48 3b 10 0f 85 85 00 00 00 49 8b 6c 24 08 48 89 f3 48 89 ef e8 d5 9d ff ff 4c 
8b 68 08 41 f6 c5 06 75 0d <49> 8b 45 00 83 e0 7f 48 83 f8 7d 74 3a 31 f6 bf 10 
00 00 00 e8 c2


signature.asc
Description: PGP signature

bug#63331: Guile-GnuTLS/Git circular dependency

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> It seems to build for me, but I'm having problems cross building. There
>> were warnings before about protocol/ssl3 being undefined, but now this
>> seems to result in an error when building extra.scm:
>>
>>
>>   GUILEC   modules/gnutls.go
>> gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
>> gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
>> gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
>>   GUILEC   modules/gnutls/extra.go
>
> [...]
>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Unbound variable: protocol/ssl3
>> make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1
>
> Is it a regression or did we already have that problem?

A regression I think, the data service doesn't have recent data, but it
does know about builds that worked:

  
https://data.guix.gnu.org/repository/1/branch/master/package/guile-gnutls/output-history?output=out=x86_64-linux=riscv64-linux-gnu

> That comes from this bit in (gnutls):
>
>   ;; Renaming.
>   (define protocol/ssl-3 protocol/ssl3)
>   (define protocol/tls-1.0 protocol/tls1-0)
>   (define protocol/tls-1.1 protocol/tls1-1)
>
> When cross-compiling, the .so cannot be loaded (understandably; see also
> GNUTLS_GUILE_CROSS_COMPILING) so ‘protocol/ssl3’ above is undefined.
> The problem is that when compiling (gnutls extra), we end up loading
> (gnutls) and thus evaluating the lines above, which fail.
>
> In Guile-Avahi I worked around it like so:
>
>   (define protocol/unspecified
> (and (defined? 'protocol/unspec) protocol/unspec))
>
> I guess we could do that as well

That sort of makes sense, although I don't know why this wasn't failing
in the same way in the past. Build logs are available though, so maybe
this makes sense to someone.


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Christopher Baines  writes:

> Since the recent core-updates merge, I've seen the build coordinator
> using less memory, but it's also been crashing in a new way, up to 10
> times a day.
>
> In the log, you see something like:
>
>   2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
>   2023-05-07 09:15:42 Signals delivery fails constantly
>
> I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
> do with this.

I think I've found a workaround. I found a list of environment variables
[1] you can set to affect the GC behaviour, and the first one I tried
(GC_RETRY_SIGNALS=0) seems to have had the desired affect, in that the
crashes/restarts have stopped.

1: https://github.com/ivmai/bdwgc/blob/master/docs/README.environment

I've sent a patch [2] to apply this setting as part of the service.

2: https://issues.guix.gnu.org/63417


signature.asc
Description: PGP signature

bug#63331: Guile-GnuTLS/Git circular dependency

[Christopher Baines]

Simon Josefsson via Bug reports for GNU Guix  writes:

> [[PGP Signed Part:Undecided]]
> Ludovic Courtès  writes:
>
>> We need to solve that.  For now, the only fix I can think of is having
>> ‘guile-gnutls’ built from a “make dist”-provided tarballs.  Apparently
>> we can add assets at ; would you
>> like to upload a tarball and accompanying signature, Simon?
>
> I published a release of gnutls-guile 3.7.12, this time built on my Guix
> development machine to test that the release machinery (README-release)
> works under Guix as well; the only "interesting" dependency was ncftp
> but you had that packaged and it worked fine.
>
> https://gitlab.com/gnutls/guile/-/releases/v3.7.12

Thanks so much for this Simon.

I've had a go at updating the Guix guile-gnutls package and sent an
initial patch to https://issues.guix.gnu.org/63388 .

It seems to build for me, but I'm having problems cross building. There
were warnings before about protocol/ssl3 being undefined, but now this
seems to result in an error when building extra.scm:


  GUILEC   modules/gnutls.go
gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
  GUILEC   modules/gnutls/extra.go
Backtrace:
In ice-9/psyntax.scm:
  1229:36 19 (expand-top-sequence (#) ?)
  1221:19 18 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   259:10 17 (parse _ (("placeholder" placeholder)) (()) _ c (# #) #)
In ice-9/eval.scm:
   293:34 16 (_ #)
In ice-9/boot-9.scm:
   3411:4 15 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2595:24 14 (call-with-deferred-observers #)
  3424:24 13 (_)
   222:17 12 (map1 (((gnutls
  3327:17 11 (resolve-interface (gnutls) #:select _ #:hide _ #:prefix ?)
In ice-9/threads.scm:
390:8 10 (_ _)
In ice-9/boot-9.scm:
  3253:13  9 (_)
In ice-9/threads.scm:
390:8  8 (_ _)
In ice-9/boot-9.scm:
  3544:20  7 (_)
   2836:4  6 (save-module-excursion #)
  3564:26  5 (_)
In unknown file:
   4 (primitive-load-path "gnutls" #)
In ice-9/eval.scm:
   626:19  3 (_ #)
   223:20  2 (proc #)
In unknown file:
   1 (%resolve-variable (7 . protocol/ssl3) #)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: protocol/ssl3
make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1
make[3]: Leaving directory 
'/tmp/guix-build-guile-gnutls-3.7.12.drv-0/guile-gnutls-3.7.12/guile'
make[2]: *** [Makefile:754: all-recursive] Error 1
make[2]: Leaving directory 
'/tmp/guix-build-guile-gnutls-3.7.12.drv-0/guile-gnutls-3.7.12/guile'
make[1]: *** [Makefile:471: all-recursive] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-guile-gnutls-3.7.12.drv-0/guile-gnutls-3.7.12'
make: *** [Makefile:403: all] Error 2
error: in phase 'build': uncaught exception:


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Since the recent core-updates merge, I've seen the build coordinator
using less memory, but it's also been crashing in a new way, up to 10
times a day.

In the log, you see something like:

  2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
  2023-05-07 09:15:42 Signals delivery fails constantly

I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
do with this.


signature.asc
Description: PGP signature

bug#56625: [core-updates] libaio test fails on powerpc64le-linux due to kernel bug

[Christopher Baines]

Thiago Jung Bauermann via Bug reports for GNU Guix  writes:

> On the core-updates branch, libaio has been updated to version 0.3.113.
> This version contains a new test which fails on guixp9 (one of the
> powerpc64le-linux builders) due to a bug present in the kernel it is
> running:

...

> So long story short, we need to update guixp9's kernel so that we can
> build core-update's libaio. I suggest we take the opportunity to update
> all of the Debian packages as well.

Thanks so much for reporting this. I think the berlin connected machines
were handled via guix-devel, and I've just updated polaris (which builds
powerpc64le-linux) for the bordeaux build farm.

I'm going to close this issue.


signature.asc
Description: PGP signature

bug#62943: Locale issue when rebooting from installation system

[Christopher Baines]

root@gnu ~# reboot
warning: failed to delete 
/mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny.pem:
 No such file or directory
warning: failed to delete 
/mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl/certs: 
Directory not empty
warning: failed to delete 
/mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl: Directory 
not empty
warning: failed to delete 
/mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc: Directory not 
empty
warning: failed to delete 
/mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile: Directory not empty
warning: failed to delete /mnt/tmp/guix-inst: Directory not empty

bug#61879: Patch

[Christopher Baines]

Andreas Enge  writes:

> Am Fri, Apr 14, 2023 at 09:20:03AM +0100 schrieb Christopher Baines:
>> I haven't tried this yet, but I've had a quick look. I'm not sure
>> search-patches will work where it is, since that'll be running in the
>> build environment, without any access to the patches in the Guix git
>> repository.
>
> Good point. But is this not exactly like your previous commit, which
> I understood you had tested? But you are right:
>https://ci.guix.gnu.org/build/909454/log/raw
> error: in phase 'patch-powerpc': uncaught exception:
> unbound-variable #f "Unbound variable: ~S" (search-patch) #f 
> phase `patch-powerpc' failed after 0.0 seconds
> I will revert (the good news: it indeed did not break any other
> architecture).
>
> If we do not have access to the patch during build, we would need to
> replace it by an invocation of substitute*, with a lot of escaping of
> special characters like line ends, which would be annoying to test
> (well, one could test on x86_64 on a dummy package with the same source
> as gcc-11).

The changes I muddled together differed in that the search-patches bit
was ungexp'ed, so the patch file was handled through that mechanism. The
other important change is the actual patch itself differed as well (ec
needs moving up a bit).

I've made those changes to the commit you pushed earlier and pushed to
core-updates now.


signature.asc
Description: PGP signature

bug#61879: Patch

[Christopher Baines]

Andreas Enge  writes:

> Am Thu, Apr 13, 2023 at 06:57:41PM +0200 schrieb Andreas Enge:
>> attached is a new commit in old syntax, mixing both our commits.
>> I have confirmed that it does not change the gcc-11 build on x86_64 and i686.
>> But do we need "--force" for patching?
>> Could you maybe check again whether this builds gcc-11 on powerpc?
>
> I just pushed it, since it cannot break much... If CI shows it does not
> work, we can still revert it.

I haven't tried this yet, but I've had a quick look. I'm not sure
search-patches will work where it is, since that'll be running in the
build environment, without any access to the patches in the Guix git
repository.


signature.asc
Description: PGP signature

bug#61879: Powerpc on core-updates

[Christopher Baines]

Andreas Enge  writes:

> In the file
>libstdc++-v3/src/c++17/floating_from_chars.cc
> previous functions have code like this:
> #if _GLIBCXX_USE_CXX11_ABI
>   buffer_resource mr;
>   pmr::string buf();
> #else
>   string buf;
>   if (!reserve_string(buf))
> return make_result(first, 0, {}, ec);
> #endif
>
> while here we only have:
>   buffer_resource mr;
>   pmr::string buf();
>
> So my guess would be that we should simply replace this snippet with the
> one above.
>
> Could someone with access to a powerpc machine try out this change?

Thanks for figuring this out Andreas! I've managed to apply this change
in the relevant place, and it appears to work.

I tried to apply it in a way that only affected powerpc64le-linux, but
I'm not sure I was successful. I've got no idea where it's best to apply
this patch, or how describe it, but at least this is a step forward.

From 382862fc06085ba80380977caf2a1f9c3203a12d Mon Sep 17 00:00:00 2001
From: Christopher Baines 
Date: Thu, 13 Apr 2023 14:45:14 +0100
Subject: [PATCH] WIP

---
 gnu/packages/gcc.scm   | 108 ++---
 gnu/packages/patches/foo.patch |  20 ++
 2 files changed, 80 insertions(+), 48 deletions(-)
 create mode 100644 gnu/packages/patches/foo.patch

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a511cdbc45..6f6f2caa5e 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -853,56 +853,68 @@ (define-public (make-libstdc++ gcc)
 (inherit gcc)
 (name "libstdc++")
 (arguments
- `(#:out-of-source? #t
-   #:modules ((srfi srfi-1)
+ (list
+  #:out-of-source? #t
+  #:modules `((srfi srfi-1)
   (srfi srfi-26)
   ,@%gnu-build-system-modules)
-   #:phases
-   (modify-phases %standard-phases
- ,@(if (version>=? (package-version gcc) "11")
-   `((add-after 'unpack 'hide-gcc-headers
-   (lambda* (#:key native-inputs inputs #:allow-other-keys)
- (let ((gcc (assoc-ref (or native-inputs inputs)
-   ,(if (%current-target-system)
-"cross-gcc"
-"gcc"
-   ;; Fix a regression in GCC 11 where the GCC headers
-   ;; shadows glibc headers when building libstdc++.  An
-   ;; upstream fix was added in GCC 11.3.0, but it only
-   ;; hides system include directories, not those on
-   ;; CPLUS_INCLUDE_PATH.  See discussion at
-   ;; <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017>
-   ;; and the similar adjustment in GCC-FINAL.
-   (substitute* "libstdc++-v3/src/c++17/Makefile.in"
- (("AM_CXXFLAGS = ")
-  (string-append ,(if (%current-target-system)
-  "CROSS_CPLUS_INCLUDE_PATH = "
-  "CPLUS_INCLUDE_PATH = ")
- (string-join
-  (remove (cut string-prefix? gcc <>)
-  (string-split
-   (getenv
-,(if (%current-target-system)
- "CROSS_CPLUS_INCLUDE_PATH"
- "CPLUS_INCLUDE_PATH"))
-   #\:))
-  ":")
- "\nAM_CXXFLAGS = ")))
-   '())
- ;; Force rs6000 (i.e., powerpc) libdir to be /lib and not /lib64.
- (add-before 'chdir 'fix-rs6000-libdir
-   (lambda _
- (when (file-exists? "gcc/config/rs6000")
-   (substitute* (find-files "gcc/config/rs6000")
- (("/lib64") "/lib")
- (add-before 'configure 'chdir
-   (lambda _
- (chdir "libstdc++-v3"
-
-   #:configure-flags `("--disable-libstdcxx-pch"
-   ,(string-append "--with-gxx-include-dir="
-   (assoc-ref %outputs "out")
-   "/include"
+  #:phases
+  #~(modify-phases %standard-phases
+  #$@(if (and (target-ppc64le?)
+  (version>=? (package-version gcc) "11"))
+ #~((add-after 'unpack

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

[Christopher Baines]

Christopher Baines  writes:

> Christopher Baines  writes:
>
>> I'm seeing this in the build coordinator agent, but it can be reproduced
>> by tweaking the guix build script as below. The build coordinator uses
>> suspendable ports as this is required to set timeouts for some I/O
>> operations.
>>
>> I'm guessing this is maybe a bug within Guile, but I thought I'd start
>> reporting it here anyway.
>
> I've sent a patch now to guile-devel that should fix this issue
> https://lists.gnu.org/archive/html/guile-devel/2023-03/msg00014.html

I've also now sent an update to the Guile package used by guix and the
guix-build-coordinator to include the patch sent upstream:

  https://issues.guix.gnu.org/62243


signature.asc
Description: PGP signature

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

[Christopher Baines]

Christopher Baines  writes:

> I'm seeing this in the build coordinator agent, but it can be reproduced
> by tweaking the guix build script as below. The build coordinator uses
> suspendable ports as this is required to set timeouts for some I/O
> operations.
>
> I'm guessing this is maybe a bug within Guile, but I thought I'd start
> reporting it here anyway.

I've sent a patch now to guile-devel that should fix this issue
https://lists.gnu.org/archive/html/guile-devel/2023-03/msg00014.html


signature.asc
Description: PGP signature

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

[Christopher Baines]

I'm seeing this in the build coordinator agent, but it can be reproduced
by tweaking the guix build script as below. The build coordinator uses
suspendable ports as this is required to set timeouts for some I/O
operations.

I'm guessing this is maybe a bug within Guile, but I thought I'd start
reporting it here anyway.


→ git diff
diff --git a/guix/scripts/build.scm b/guix/scripts/build.scm
index 72a24f91ac..874108e482 100644
--- a/guix/scripts/build.scm
+++ b/guix/scripts/build.scm
@@ -64,6 +64,9 @@ (define-module (guix scripts build)
 register-root
 register-root*))
 
+(use-modules (ice-9 suspendable-ports))
+(install-suspendable-ports!)
+
 (define %default-log-urls
   ;; Default base URLs for build logs.
   '("http://ci.guix.gnu.org/log;))


→ ./pre-inst-env guix build --check 
/gnu/store/jz8nxdv8hx7d80vban2qq1a08pf1ilws-anthy-9100h.drv
The following derivation will be built:
  /gnu/store/jz8nxdv8hx7d80vban2qq1a08pf1ilws-anthy-9100h.drv
building /gnu/store/jz8nxdv8hx7d80vban2qq1a08pf1ilws-anthy-9100h.drv...

...

starting phase `check'
./test_anthy --help to print usage.
ANTHY_ENABLE_DEBUG_PRINT=()
ANTHY_SPLITTER_PRINT=()
SRCDIR=(.)
anthy-9100h Fri Mar 17 10:59:29 2023
1:(���Τˤ蘆)
||�ˤ蘆
(�Ǥ�:(,1000,Nk,72089)223,026 ,:(1N,1000,Nk,72089)222,744 
,�Ĥ�:(,1000,Nk,71001)210,785 ,:(g,1000,Nk,71001)197,472 
,��:(1,1000,N,64031)196,095 ,�¤�:(,1000,Nk,71001)190,816 
,�Ƥ�:(,1000,Nk,71001)190,538 ,��:(1,1000,N,64031)177,837 
,�Ť�:(,1000,Nk,71001)166,409 ,¶��:(1,1000,TM,72089)112,640 
,¶��:(1,1000,TM,72089)112,358 ,��:(1,1000,N,72089)58,573 
,��:(1,1000,N,72089)51,814 ,��:(1,1000,N,7208)8,335 ,:(1,1000,N,7208)8,307 
,:(N,0,-)1 ,):
�ˤ蘆(�:(,1000,Nk,72089)205,004 ,�ˤ蘆:(N,0,-)2 ,�˥掠:(g,0,-)2 
,�˥掠:(N,0,-)1 ,):

2:(�䴤Τ䢤�ޤäƤ���Ȥ�ޤ�)
|��||��|ޤäƤ|��ޤ�
��(:(1,1000,Nk,6553)2500,001 ,:(1,1000,N,66951)131,810 
,��:(N,0,-)2 ,��:(N,0,-)1 ,):
(���:(,1000,Nk,6553)2500,001 ,���:(,1000,Nk,72089)218,520 
,���:(,1000,Nk,72089)216,268 ,:(N,1000,Nk,72089)193,740 
,���:(,1000,Nk,72089)193,176 ,�ޤ�:(,1000,Nk,72089)191,487 
,���:(,1000,Nk,72089)166,706 ,���:(,1000,Nk,6553)15,154 
,5��:(,1000,Nk,6553)7,168 ,:(,1000,Nk,6553)7,142 ,���:(,1000,Nk,6553)7,117 
,:(g,0,-)2 ,:(N,0,-)1 ,):
��(�б���:(,1000,Nk,48773)149,368 ,�粦��:(,1000,Nk,70474)138,746 
,�ڲ���:(,1000,Nk,48773)96,022 ,��:(N,0,-)2 ,��:(g,0,-)2 
,��:(N,0,-)1 ,):
ޤäƤ(��äƤ:(,1000,Vy,72089)225,279 ,�դäƤ:(,1000,Vy,72089)216,268 
,ޤäƤ:(N,1000,Vy,72089)195,992 ,��äƤ:(,1000,Vy,6553)19,455 
,ޥåƥ:(g,0,-)2 ,ޥåƥ:(N,0,-)1 ,):
��ޤ�(�פ��ޤ�:(,1000,Ve,6553)20,479 ,�ۤ��ޤ�:(,1000,Ve,6553)20,274 
,��ޤ�:(N,1000,Ve,6553)19,660 ,��ޥ�:(N,0,-)1 ,):

3:(Ƥ令�)
|Ƥ�|
Ƥ�(��ž:(1,1000,N,72089)218,520 ,��ŷ:(1,1000,N,7208)11,038 ,Ƥ�:(N,0,-)2 
,ƥ�:(N,0,-)1 ,):
(:(1,1000,N,7208)13,290 ,:(N,0,-)2 ,:(N,0,-)1 ,):

4:(�Τ��ä�ˤ���Ǥ���)
|��|���ä���|��ˤ���Ǥ���
��(�ؤ�:(,1000,Nk,68423)213,822 ,�դ�:(,1000,Nk,68423)211,684 
,�פ�:(,1000,Nk,68423)211,417 ,��:(N,1000,Nk,68423)186,026 
,�פ�:(,1000,Nk,68423)185,758 ,���:(,1000,Nk,68423)181,749 
,�֤�:(,1000,Nk,68423)153,952 ,��:(g,0,-)2 ,��:(N,0,-)1 ,):
�����(�����:(N,1000,Nk,62560)191,591 ,��:(,1000,Nk,62560)142,716 
,�����:(g,0,-)2 ,�����:(N,0,-)1 ,):
��ˤ���Ǥ���(�ؤˤ���Ǥ���:(,1000,Ne,6553)20,479 ,�¤ˤ���Ǥ���:(,1000,Ne,6553)20,274 
,��ˤ���Ǥ���:(N,1000,Ne,6553)20,069 ,�Ĥˤ���Ǥ���:(,1000,Ne,6553)18,636 
,��ˤ���Ǥ���:(,1000,Ne,655)1,986 ,��˥���Ǥ���:(,1000,Ne,655)1,638 
,�̤���Ǥ���:(,1000,Ne,655)1,618 ,�����Ǥ���:(,1000,Ne,655)1,065 
,���Τ���Ǥ���:(,1000,Ne,655)799 ,��˥���ǥ���:(N,0,-)1 ,):

5:(���俤��ȤȤä���Ǥ���)
|���俤|�Ȥä���Ǥ���
���俤���(���忥���:(1N,1000,N,57866)177,215 ,���俤���:(N,0,-)2 ,���忥���:(g,0,-)2 ,):
�Ȥä���Ǥ���(�Ȥä���Ǥ���:(N,1000,Ne,72089)225,279 
,��ä���Ǥ���:(,1000,Ne,72089)223,026 ,���ä���Ǥ���:(,1000,Ne,72089)222,744 
,�Τä���Ǥ���:(,1000,Ne,72089)222,463 ,å�ä���Ǥ���:(,1000,Ne,72089)222,181 
,�ͤä���Ǥ���:(,1000,Ne,72089)218,520 ,Ͽ�ä���Ǥ���:(,1000,Ne,72089)216,268 
,��ä���Ǥ���:(,1000,Ne,72089)214,015 ,��ä���Ǥ���:(,1000,Ne,72089)213,733 
,���ä���Ǥ���:(,1000,Ne,72089)202,751 ,�ݤä���Ǥ���:(,1000,Ne,72089)202,469 
,��ü�Ǥ���:(,1000,Ne,7208)17,345 ,�ȥå���ǥ���:(N,0,-)1 ,):

6:(���äˤ�)
|���ä�|��
���ä�(�ع���:(,1000,Nk,70285)215,248 ,���ä�:(N,0,-)2 ,���å�:(g,0,-)2 
,���å�:(N,0,-)1 ,):
Backtrace:
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
  17 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 16 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 15 (_ #(#(#)))
In guix/ui.scm:
   2300:7 14 (run-guix . _)
  2263:10 13 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In 

bug#62051: Early detection of derivations with unreadable builder scripts

[Christopher Baines]

Currently it's quite easy to end up with packages that have builder
scripts that can't be read by Guile.

This is part of the following builder script:

  (cons "--enable-mpi-java" #)

from: /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder

And when attempting to build that derivation, you get the following
error.

  ice-9/read.scm:126:4: In procedure read-expr*:
  
/gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder:1:3820: 
Unknown # object: "#<"


It would be nice if Guix could detect this category of problems and
raise an error at the time the derivation is created, rather than the
error occuring only when you build the derivation.

This would be helpful particularly for the Guix Data Service since
currently it ends up storing these useless derivations, often many times
since the builder includes some often changing string (7f366e0cd930 in
the example above), so this is a common cause of spurious changes
between revisions (as often noted on qa.guix.gnu.org).


signature.asc
Description: PGP signature

bug#61742: icecat.desktop show ??????????

[Christopher Baines]

Maxim Cournoyer  writes:

> Interestingly, this older icecat in my store, at version 102.7.0 didn't
> have that problem:

You can bisect this by using
https://data.guix.gnu.org/repository/1/branch/master/package/icecat/output-history

I see this problem start to happen with
/gnu/store/2a67f3c5lv14bq11vyyb6k2z2aw457nk-icecat-102.8.0-guix0-preview1

So it's probably these changes here
https://data.guix.gnu.org/compare?base_commit=636b771536b95d15a2fd68b468deeebac97d6bee_commit=d318ccc36308171a74b4863ea25a3dded05a2851


signature.asc
Description: PGP signature

bug#61642: intermittent write_wait_fd error when updating

[Christopher Baines]

Simon Tournier  writes:

> Hi,
>
> On Mon, 20 Feb 2023 at 11:46, Christopher Baines  wrote:
>
>> It's not, since it relates to code in the (guix substitutes) module.
>
> Do you mean that if "https://substitutes.nonguix.org; is incorrectly
> configured, then the code in (guix substitutes) should handle the
> error instead of crash with a backtrace?

No, but to answer your question, yes.

I don't think this is a server side code/configuration issue. Also see
this older bug for the same issue https://issues.guix.gnu.org/56005


signature.asc
Description: PGP signature

bug#61642: intermittent write_wait_fd error when updating

[Christopher Baines]

Simon Tournier  writes:

> Hi,
>
> On dim., 19 févr. 2023 at 17:50, Nathan Dehnel  wrote:
>
>> 'https://substitutes.nonguix.org'...   0.0%Backtrace:
>
> [...]
>
>> "https://substitutes.nonguix.org; _ # _ …)
>
> The issue appears to be on the nonguix side, please report to them.

It's not, since it relates to code in the (guix substitutes) module.


signature.asc
Description: PGP signature

bug#54370: network problem or intentional blocking?

[Christopher Baines]

poiNt_3D  writes:

> Hello. I would like to request a clarification on the issue of
> inaccessibility of guix.gnu org from the Russian Federation.  Is the
> blocking intentional or is there some kind of networking problem?

Now that the website is hosted on bayfront, which wasn't changed
specifically to address this, but should do anyway, I'm going to close
this issue.

Things like ci.guix.gnu.org will still be inaccessible, so feel free to
open issues about those if you wish.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#60207: ci build of latest guix for armhf

[Christopher Baines]

"pelzflorian (Florian Pelz)"  writes:

> Julius Schwartzenberg  writes:
>> Op 24-12-2022 om 22:40 schreef pelzflorian (Florian Pelz):
>>> If you want `guix pull` without compiling, then look at
>>> <https://guix.gnu.org/en/manual/devel/en/html_node/Channels-with-Substitutes.html>.
>>
>> I added the lines to my personal .config/guix/channels.scm, but guix
>> pull then shows:
>> guix pull: waarschuwing: could not find available substitutes at
>> https://ci.guix.gnu.org
>>
>> And it still ends up compiling. I also tried replacing ci with
>> bordeaux in the URL, but then it shows a 404.
>>
>> I think I'm still missing something?
>
> Bah, it appears ci.guix.gnu.org currently just doesn’t build for
> armhf-linux.  Bordeaux does not offer the needed Cuirass API.
>
> I believe but do not know that Bordeaux does not actually build the
> latest guix, just the packages.

bordeaux.guix.gnu.org builds and provides substitutes for the guix pull
(channel instance) derivations, for at least some systems.

> I don’t know if offering the latest guix would even be feasible.
> Probably not?  armhf builds take a long time.
>
> Cc to Christopher Baines , Ricardo Wurmus
> .

For bordeaux.guix.gnu.org, there's some dependency on the channel
instance derivations provided by data.guix.gnu.org. Unfortunately, just
computing these derivations seems to require building things for that
system (unlike package derivations), so currently data.guix.gnu.org uses
QEMU binfmt to help with this. The arm system wasn't enabled, so these
derivations are missing for recent revisions.

I know there was some work done around the release to at least fix
things for the guix package on armhf-linux. I'll have a go add enabling
arm for QEMU on data.guix.gnu.org to see what happens.

Chris


signature.asc
Description: PGP signature

bug#60202: tests/cpio failure

[Christopher Baines]

This test seems to fail, maybe because of high inode numbers, maybe
something to with btrfs.

I saw this with the failed builds here
https://data.guix.gnu.org/gnu/store/kg93i3bmvpdfkiqyx6g9r7ywh0xpvm8w-guix-1.4.0


cbaines@milano-guix-1 ~$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (use-modules (guix cpio))
scheme@(guix-user)> (file->cpio-header "guix/guix.scm")
$1 = #< magic: 460545 ino: 5031515288 mode: 33188 uid: 1003 gid: 
998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 rdev-maj: 
0 rdev-min: 0 name-size: 14 checksum: 0>
scheme@(guix-user)> (use-modules (rnrs io ports))
scheme@(guix-user)> (define header $1)
scheme@(guix-user)> (call-with-values
(lambda ()
  (open-bytevector-output-port))
  (lambda (port get-bv)
(write-cpio-header header port)
(let ((port (open-bytevector-input-port (get-bv
  (equal? header (read-cpio-header port)
$2 = #f
scheme@(guix-user)> (call-with-values
(lambda ()
  (open-bytevector-output-port))
  (lambda (port get-bv)
(write-cpio-header header port)
(let ((port (open-bytevector-input-port (get-bv
  (equal? (peek "A" header)
  (peek "B" (read-cpio-header port))

;;; ("A" #< magic: 460545 ino: 5031515288 mode: 33188 uid: 1003 
gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 
rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>)

;;; ("B" #< magic: 460545 ino: 736547992 mode: 33188 uid: 1003 
gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 
rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>)
$3 = #f


signature.asc
Description: PGP signature

bug#58586:

[Christopher Baines]

Sharlatan Hellseher  writes:

> Hi Chris,
>
> This issue is resolved now with listed patches applied.

Great :)

For future reference, anyone can mark issues as done by emailing
x-d...@debbugs.gnu.org, where X is the issue number.

I've done that now for this issue.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Christopher Baines]

Ludovic Courtès  writes:

> Agreed!  I don’t use GNOME and I don’t even know what KgxNautilus is,
> but here’s a patch that may fix this by ensuring Nautilus doesn’t load
> the same extension twice.
>
> Could you give it a spin and lemme know if it solves this issue?\
>
> That’ll get us closer to a release.  :-)

I've tried it out and it looks to fix the issue, please push!

Thanks,

Chris


signature.asc
Description: PGP signature

bug#59363: Fw: [PATCH] flatpak: Adjustments to make --with-commit work

[Christopher Baines]

Jacob Hrbek  writes:

> CC mentors -- please review and merge if appropriate

I think patches are best sent to guix-patches, even if they relate to a
bug filed against the guix package.

Also, for some reason, I'm missing the original mail for this bug.

Anyway, --with-commit doesn't work because of the reason displayed when
you try and use it. --with-source is what you should be using:

  guix build flatpak 
--with-source=https://github.com/flatpak/flatpak/releases/download/1.15.0/flatpak-1.15.0.tar.xz


signature.asc
Description: PGP signature

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Christopher Baines]

Liliana Marie Prikler  writes:

> Am Samstag, dem 01.10.2022 um 13:29 +0200 schrieb Tobias Kortkamp:
>> Hi,
>> 
>> The problem seems to be that NAUTILUS_EXTENSION_PATH contains the
>> same path twice and that it tries to load KgxNautilus from each of
>> the paths:
>> 
>> $ echo $NAUTILUS_EXTENSION_PATH
>> /run/current-system/profile/lib/nautilus/site-
>> extensions:/run/current-system/profile/lib/nautilus/site-extensions
>> 
>> Running Nautilus like this works fine:
>> 
>> $ NAUTILUS_EXTENSION_PATH=/run/current-
>> system/profile/lib/nautilus/site-extensions nautilus
>
> I only know of one thing setting this variable, that being nautilus'
> search-path.  Do you by chance source some profile multiple times?

There might be a related issue where there's duplicates in search paths,
I've tested in a simple VM and I see the duplication in
NAUTILUS_EXTENSION_PATH.

Anyway, this probably should be something that doesn't cause nautilus to
segfault.

Chris


signature.asc
Description: PGP signature

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Christopher Baines]

Tobias Kortkamp  writes:

> I updated from c8112f3bd95269ce4aca12dedbfe61bb6b37acae to
> 0dec41f329c37a4293a2a8326f1fe7d9318ec455 and now Nautilus crashes
> with:
>
> (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:09.877: Two 
> different plugins tried to register 'KgxNautilus'.
>
> (org.gnome.Nautilus:3664): GLib-GObject-CRITICAL **: 13:25:09.877: 
> g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE 
> (instance_type)' failed
>
> (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:09.877: Two 
> different plugins tried to register 'KgxNautilusMenuItem'.
>
> ** (org.gnome.Nautilus:3664): WARNING **: 13:25:09.882: Tracker 2 migration: 
> Couldn't run `tracker3`: Failed to execute child process “tracker3” (No such 
> file or directory)
>
> (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:10.222: invalid 
> cast from 'KgxNautilus' to ''
>
> (org.gnome.Nautilus:3664): GLib-GObject-CRITICAL **: 13:25:10.222: 
> g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
>
> (org.gnome.Nautilus:3664): GLib-GObject-CRITICAL **: 13:25:10.222: 
> g_object_get: assertion 'G_IS_OBJECT (object)' failed
>
> The problem seems to be that NAUTILUS_EXTENSION_PATH contains the same
> path twice and that it tries to load KgxNautilus from each of the paths:
>
> $ echo $NAUTILUS_EXTENSION_PATH
> /run/current-system/profile/lib/nautilus/site-extensions:/run/current-system/profile/lib/nautilus/site-extensions
>
> Running Nautilus like this works fine:
>
> $ 
> NAUTILUS_EXTENSION_PATH=/run/current-system/profile/lib/nautilus/site-extensions
>  nautilus

Thanks for investigating Tobi, I've been experiencing this too, but
didn't get anywhere trying to use GDB, so thanks for tracking it down!

This NAUTILUS_EXTENSION_PATH is a Guix specific modification made to
nautilus at build time, so yeah, something is up here and it's down to
us to fix it.

Maybe the duplication of the directory in the search path is something
to fix, but I guess the code in nautilus using the search path probalbly
needs to be smarter to avoid loading plugins twice.

Chris


signature.asc
Description: PGP signature

bug#58770: guix pull: error: You found a bug: the program '/gnu/store/9kyha1l1a1ynh9nni8428bqdanajck1b-compute-guix-derivation'

[Christopher Baines]

Mark Felt  writes:

> building /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv...
> | 'build' phasebuilder for 
> `/gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv' failed with 
> exit code 1
> build of /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv failed
> Backtrace:
> View build log at 
> '/var/log/guix/drvs/5s/1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv.bz2'.

Hi Mark,

It's not obvious to me why the build of gnutls failed from the log.

It has been built by a substitute server, so providing you're fetching
substitutes from bordeaux.guix.gnu.org, you shouldn't have to build this
locally.

Chris


signature.asc
Description: PGP signature

bug#58508: gtg package (Getting Things GNOME) doesn't run

[Christopher Baines]

Pkill9  writes:

> This is the error I get when running:
>
> guix environment --ad-hoc gtg -- gtg
>
> ```
> Traceback (most recent call last):
>   File "/gnu/store/0x46vnn6nk10dmkjvg9jmzqx65pmjs4r-gtg-0.6/bin/.gtg-real", 
> line 76, in 
> gi.require_version('GtkSource', '4') 
>   File 
> "/gnu/store/vbms7iz53dpdz5iz8ik2blr77w17imva-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",
>  line 126, in require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace GtkSource not available
>
> ```

If you're up for tweaking the package definition, try adding
gtksourceview-4 as an input and see if you get the same error.

Chris


signature.asc
Description: PGP signature

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Christopher Baines]

Leo Famulari  writes:

> On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote:
>> I tried building a newer version, but there were new test suite failures
>> on both aarch64 and x86_64 :/
>
> Since the 'guix' package still does not build on aarch64, I'm reopening
> this bug.

It looks to me that there were problems with the guix package on
aarch64-linux, but it's working currently.

1: 
https://data.guix.gnu.org/repository/1/branch/master/package/guix/output-history?output=out=aarch64-linux=none

Also, substitute availability for aarch64-linux and armhf-linux is
OK. Does that mean this issue can be closed?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#57965: Problem with freecad substitute

[Christopher Baines]

Aleksandr Vityazev  writes:

> On 2022-09-21, 09:26 +0100, Christopher Baines  wrote:
>
>> Assuming you're using a recent revision of Guix, boreaux.guix.gnu.org
>> should be in the default substitute URLs and default authorized-keys.
>>
>> If you're still having problems, sharing the contents of /etc/guix/acl
>> as well as the arguments the guix-daemon is running with will help.
>>
>
> ...
>
> As I said, installing with substitutes of all but two packages,
> telegram-desktop and freecad, works fine.

Your ACL and guix-daemon arguments look fine.

Caching is one possibility, /var/guix/substitute/cache/ is usually where
substitute information gathered up by the guix-daemon is stored. It
could be that the absence of this output has been stored. You could try
deleting the contents of /var/guix/substitute/cache/.

Otherwise, dealing with the outputs directly does make debugging this
easier. If you compute the derivation, that contains the output near the
top. You can then ask guix build to substitute it.

→ guix build --no-grafts -d freecad
/gnu/store/q3pka0ql599z85zdy507fh8vrabaz5lp-freecad-0.20.1.drv

→ cat /gnu/store/q3pka0ql599z85zdy507fh8vrabaz5lp-freecad-0.20.1.drv
Derive([("out","/gnu/store/yxys4jxxgyllblm31244r2l23wvkjpv2-freecad-0.20.1","","")]...

→ guix build --substitute-urls=https://bordeaux.guix.gnu.org 
/gnu/store/yxys4jxxgyllblm31244r2l23wvkjpv2-freecad-0.20.1


signature.asc
Description: PGP signature

bug#57965: Problem with freecad substitute

[Christopher Baines]

Aleksandr Vityazev  writes:

> Hi,
>
> On 2022-09-21, 08:25 +0100, Christopher Baines  wrote:
>
>> Aleksandr Vityazev  writes:
>>
>>> I want to install freecad, substitute available but the package starts
>>> building locally.
>>
>> This is probably due to you ACL, see
>> https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html#Substitute-Server-Authorization
>>
>
> It says at the beginning of the section:
>
> Note: If you are using Guix System, you can skip this section: Guix
>  System authorizes substitutes from ‘ci.guix.gnu.org’ and
>  ‘bordeaux.guix.gnu.org’ by default.
>
>
> all packages except the ones marked are installed normally.

Ok, if you are using guix system, you need to check the configuration
for the guix-daemon, in particular the substitute URLs and ACL
(authorized-keys).

Assuming you're using a recent revision of Guix, boreaux.guix.gnu.org
should be in the default substitute URLs and default authorized-keys.

If you're still having problems, sharing the contents of /etc/guix/acl
as well as the arguments the guix-daemon is running with will help.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#57965: Problem with freecad substitute

[Christopher Baines]

Aleksandr Vityazev  writes:

> I want to install freecad, substitute available but the package starts
> building locally.

This is probably due to you ACL, see
https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html#Substitute-Server-Authorization


signature.asc
Description: PGP signature

bug#57827: Shepherd 0.9.2 possible regressions

[Christopher Baines]

Mathieu Othacehe  writes:

> Since Shepherd 0.9.2 the following tests are failing:
>
> * cgit: https://ci.guix.gnu.org/build/1427375/details
> * gitile https://ci.guix.gnu.org/build/1427377/details
>
> It seems that an unexpected # object is received on the marionette
> socket.

I had a look at the cgit system test, and it seems like this # is
coming from the NGinx pid file being empty.

Since empty files is a possibility with wait-for-file, I've sent a patch
to [1] which prevents the eof issue, plus another change to make it
easier to debug.

1: https://issues.guix.gnu.org/57850

With that change, both of the above tests seem to pass for me.

This could be related to the Shepherd upgrade, but only indirectly, as I
think the failure at least for cgit was also timing dependent.

Chris


signature.asc
Description: PGP signature

bug#57596: guix lint --checkers=derivation doesn't complete, Too many heap sections

[Christopher Baines]

Christopher Baines  writes:

> When running the derivation checker on all packages for recent guix
> revisions, it dones't seem to complete. Instead, you get an error which
> I think comes from the garbage collection implementation that Guile
> uses:
>
>   → guix lint --checkers=derivation
>   Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
>   Aborted
>
> I noticed this on data.guix.gnu.org, as it effectively does something
> similar when trying to record the lint warnings for a revision.
>
> Maybe there's enough derivations now that the process of computing them
> all is too much for Guile? Or maybe it's something in the graph that's
> forming a loop?

I've got a bit more information now, I'm guessing the changes in [1]
just tipped the balance as that's when the data service instances
started not being able to process revisions.

1: 
https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=aae98c297214f87eb45302863adb021078c41a6f...d22a5c18517d662516fc93889534367fd3a448f2

I think I've managed to work around this now in the data service [2],
but the problem still remains when running the linter through the
script.

2: 
http://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=b3d59c650a45429f90953e8fd865a3ba76a891cf


signature.asc
Description: PGP signature

bug#57596: guix lint --checkers=derivation doesn't complete, Too many heap sections

[Christopher Baines]

When running the derivation checker on all packages for recent guix
revisions, it dones't seem to complete. Instead, you get an error which
I think comes from the garbage collection implementation that Guile
uses:

  → guix lint --checkers=derivation
  Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
  Aborted

I noticed this on data.guix.gnu.org, as it effectively does something
similar when trying to record the lint warnings for a revision.

Maybe there's enough derivations now that the process of computing them
all is too much for Guile? Or maybe it's something in the graph that's
forming a loop?

Chris


signature.asc
Description: PGP signature

bug#57215: ci: Fail to evaluate Guix specification

[Christopher Baines]

Mathieu Othacehe  writes:

> Hey,
>
>> So, I think there's some involvement of grafts that mean you end up
>> building things when just trying to compute the derivation. But that's
>> as far as I got, I don't really understand why this is the case, or what
>> can be done about it.
>
> Thanks for sharing Chris, I tried to disable grafts, but I was not able
> to go any further:
>
> mathieu@berlin ~$ guix pull -s powerpc64le-linux -v3  --no-grafts
...

> guix pull: error: build of 
> `/gnu/store/z7jij9k33bl8dm50zrhy97jxqwylx1s8-compute-guix-derivation.drv' 
> failed
>
> Maybe we should open a specific bug-report for that particular issue?

I think the grafting comes in here [1], within the build-self.scm
script, and I think that the --no-grafts argument to guix pull doesn't
currently affect the behaviour at that point.

1: https://git.savannah.gnu.org/cgit/guix.git/tree/build-aux/build-self.scm#n350

That's where the patch here [2] comes in, as it makes it possible to
control the grafting behaviour at that point, at least enough to
demonstrate that there's some change in behaviour.

2: https://lists.gnu.org/archive/html/guix-devel/2022-02/txtgzexu0El5b.txt


signature.asc
Description: PGP signature