bug#40316: nss not reproducible

[Ludovic Courtès]

Hi,

Christina O'Donnell  skribis:

> Tangentially, given how long nss takes to build, do you think that
> it'd be worth shaving it down to a single test pass? Currently it runs
> each test up to 3 times, which takes ~1h on my machine with no other
> build running. Running only the standard pass takes 2.5-3x less time,
> which is a huge quality of life improvement.

Currently we run ./nss/tests/all.sh, which I suppose is what upstream
recommends to run tests.

For sure I’d be happy if the test suite could run faster, but does
upstream offer such an option?  When you say “a single pass”, is that
something upstream supports?

Thanks,
Ludo’.

bug#70726: guix-bug report

[Ludovic Courtès]

Hi,

PJ Reid  skribis:

> Authenticating channel 'guix', commits 9edb3f6 to d6a6e83 (29,432 new
> commits)...

This particular commit, d6a6e832e6e318eec0c4866fdde62ae47f29defa, would
trigger the bug you experienced when using a relatively old version of
guix-daemon:

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

Could you try again ‘guix pull’ to a newer commit?

Additionally, I strongly advise upgrading guix-daemon, as noted in the
bug report above.

HTH,
Ludo’.

bug#40316: nss not reproducible

[Ludovic Courtès]

Hi Christina,

Nice work!

Christina O'Donnell  skribis:

> I've got as far as making nss 3.98 reproducible, however updating it to 3.99
> results in 51 test failures. These are regressions, and worked correctly for
> 3.98. I'm not entirely sure what the issue is, but I've run out of time to
> debug it this week, so I'm sending this patch up as is.

Not sure if this is related, but we’re seeing test failures due to
timing issues right now with 3.98:

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

Thank you!

Ludo’.

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

[Ludovic Courtès]

Hi Chris and all,

Christopher Baines  skribis:

> 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.

Woow, impressive.  How did you go about finding which commits were
duplicates/cherry-picked from master?  Which commit did you start from?

Given everything you’ve explained, it seems to me it’s worth trying to
start from a clean branch like this.

I checked it out (commit da77ea23daa0bfa4a73290dff99b22d6825ff80b) to
get an idea of where we are and got this:

--8<---cut here---start->8---
make[2]: *** No rule to make target 
'gnu/packages/patches/glib-networking-gnutls-binding.patch', needed by 'all-am'.
make[2]: *** No rule to make target 
'gnu/packages/patches/librecad-support-for-boost-1.76.patch', needed by 
'all-am'.
--8<---cut here---end--->8---

It stopped at:

--8<---cut here---start->8---
gnu/packages/sdl.scm:72:2: error: (package (name "sdl2") (version "2.30.1") 
(source (origin (method url-fetch) (uri (string-append 
"https://libsdl.org/release/SDL2-; version ".tar.gz")) (sha256 (base32 
"0fj7gxc7rlzzrafnx9nmf7ws3paxy583fmx7bcbavi6gr3xmy881" (arguments (list 
#:tests? #f #:configure-flags (gexp (append (quote ("--disable-wayland-shared" 
"--enable-video-kmsdrm" "--disable-kmsdrm-shared")) (quote 
("--disable-alsa-shared" "--disable-pulseaudio-shared" "--disable-x11-shared" 
"LDFLAGS=-lGL" #:make-flags (gexp (cons* (string-append 
"LDFLAGS=-Wl,-rpath," (ungexp (this-package-input "eudev")) "/lib" ",-rpath," 
(ungexp (this-package-input "vulkan-loader")) "/lib") (quote ("V=1")) 
(propagated-inputs (list libx11 libcap mesa)) (native-inputs (list pkg-config)) 
(inputs (list libxrandr glu alsa-lib pulseaudio dbus eudev glib ibus-minimal 
libxkbcommon libxcursor vulkan-loader wayland wayland-protocols)) (outputs 
(quote ("out" "debug"))) (synopsis "Cross platform game development library") 
(description "Simple DirectMedia Layer is a cross-platform development library 
designed to\nprovide low level access to audio, keyboard, mouse, joystick, and 
graphics\nhardware.") (home-page "https://libsdl.org/;) (license 
license:bsd-3)): missing field initializers (build-system)
--8<---cut here---end--->8---

I guess these are merge conflicts that weren’t correctly resolved.

This branch rewrites the entire ‘core-updates’ history.  What about
rewriting starting from the first series of “duplicate” commits?  That
should solve the immediate issue while keeping the “known good” history?

Thanks,
Ludo’.

bug#66866: Grafting breaks cross-compilation

[Ludovic Courtès]

Hi,

dan  skribis:

> I spent some time digging into the rabbit hole.  After changing 
> the lower function of the copy-build-system to look more like the 
> lower function of the gnu-build-system, I'm able to cross compile 
> alsa-lib without the --no-grafts flag.  The changes I made are 
> like:
>
> diff --git a/guix/build-system/copy.scm 
> b/guix/build-system/copy.scm
> index d58931b33c..74304b4bfb 100644
> --- a/guix/build-system/copy.scm
> +++ b/guix/build-system/copy.scm
> @@ -66,13 +66,13 @@ (define* (lower name
>(bag
>  (name name)
>  (system system)
> -(host-inputs `(,@(if source
> +(build-inputs `(,@(if source
>   `(("source" ,source))
>   '())
> -   ,@inputs
> +   ,@native-inputs
> ;; Keep the standard inputs of 
> 'gnu-build-system'.
> ,@(standard-packages)))
> -(build-inputs native-inputs)
> +(host-inputs inputs)
>  (outputs outputs)
>  (build copy-build)
>  (arguments (strip-keyword-arguments private-keywords 
>  arguments
>
> Can we put everything inside build-inputs?  From my understanding, 
> copy-build-system shouldn't care about cross-compilation at all.

Intuitively, if ‘copy-build-system’ is about copying
architecture-independent files, then it should do the same thing whether
or not we are cross-compiling.

However, users can and do add phases whose result is
architecture-dependent.  Small sample:

  • ‘desec-certbot-hook’ captures a reference to curl, so it would get
the wrong one when cross-compiling if we assumed build-inputs =
host-inputs.

  • ‘chez-scheme-for-racket-bootstrap-bootfiles’ builds stuff when
cross-compiling.  Philip, could you explain the intent and what you
expect here?

So it would seem we can’t just assume everything is a native input like
https://issues.guix.gnu.org/70492 does.

Now, as David and you found out, the use of inputs in
build-system/copy.scm:lower is bogus.  It seems that it can be fixed by
following the intended definition of build/host inputs, as David
suggested:

diff --git a/guix/build-system/copy.scm b/guix/build-system/copy.scm
index d58931b33c2..cf0214320bf 100644
--- a/guix/build-system/copy.scm
+++ b/guix/build-system/copy.scm
@@ -66,13 +66,13 @@ (define* (lower name
   (bag
 (name name)
 (system system)
-(host-inputs `(,@(if source
+(build-inputs `(,@(if source
  `(("source" ,source))
  '())
-   ,@inputs
-   ;; Keep the standard inputs of 'gnu-build-system'.
-   ,@(standard-packages)))
-(build-inputs native-inputs)
+,@native-inputs
+;; Keep the standard inputs of 'gnu-build-system'.
+,@(standard-packages)))
+(host-inputs inputs)
 (outputs outputs)
 (build copy-build)
 (arguments (strip-keyword-arguments private-keywords arguments

But wait! That’s all theoretical because the bag always has (target #f)
and ‘copy-build’ bundles build and host inputs together, as if doing a
native build.

So it seems like https://issues.guix.gnu.org/70492 (putting everything
in ‘build-inputs’) is OK, after all.

But still, there seem to be some expectation that ‘copy-build-system’
can support cross-compilation for real, so maybe we should add a
‘copy-cross-build’ procedure in addition to the patch above.

Thoughts?

Ludo’.

bug#70588: hash mismatch error and stop fallback

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> Other said, hash mismatch should be raised and obviously the content
> must be discarded; then the hash mismatch should be considered as “not
> found” so let try the next strategy for downloading the content.

Agreed.  I merged it with .

Thanks,
Ludo’.

bug#70659: Too many heap sections on guix pull

[Ludovic Courtès]

Hi,

Peacememories  skribis:

> `guix pull` on a fresh install on WSL Ubuntu 24.04 fails with the
> following log.
>
> The same happened to me when trying GUIX on NixOS 23.11 via the
> `services.guix` option.
>
> ```
>
> hint: Consider installing the `glibc-locales' package and defining
> `GUIX_LOCPATH', along these lines:
>
>  guix install glibc-locales
>  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>
> See the "Application Setup" section in the manual, for more info.
>
> Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to ddf3759 (29,446 new
> commits)...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   ddf3759

[...]

> -Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
> guix pull: error: You found a bug: the program

Thanks for the report.  As someone confirmed on IRC, this was caused by
7cef6b7ba555a9dfaf6d09cb7e112b0df77d5114, which introduced a circular
dependency, but only for those systems running a version of guix-daemon
lacking “builtin:git-download” (added in Sept. 2023).

Commit df3d30819e650a490ef39dd6692740bb13263c75 fixes that; you should
be able to pull now.

I would recommend upgrading guix-daemon though, as noted in:

  https://guix.gnu.org/manual/devel/en/html_node/Upgrading-Guix.html

One of the main reasons to do so is this:

  
https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/

Thanks for reporting the bug!

Ludo’.

bug#70164: [bug#70205] [PATCH] home: services: bash: Move default PS1 prompt to bashrc

[Ludovic Courtès]

Hi Richard,

Richard Sent  skribis:

> Reported in .
>
> * home/services/shells.scm (add-bash-configuration): Move default PS1 prompt
> from .bash_profile to .bashrc.
>
> Change-Id: Ic437458ee362cc4aa803a71c9962af866749f59a

Sounds reasonable to me; thanks for the clear explanation in
.

There was one missing newline before aliases so I made the following
change (adding two newlines, for good measure).

Applied, thanks!

Ludo’.

diff --git a/gnu/home/services/shells.scm b/gnu/home/services/shells.scm
index a5b2586dde..ee6b09f17c 100644
--- a/gnu/home/services/shells.scm
+++ b/gnu/home/services/shells.scm
@@ -421,11 +421,11 @@ (define (add-bash-configuration config)
  ,@(list (file-if-not-empty
   'bashrc
   (if (home-bash-configuration-guix-defaults? config)
-  (list (plain-file-content %default-bashrc)
+  (list (plain-file-content %default-bashrc) "\n"
 ;; The host distro might provide a bad 'PS1'
 ;; default--e.g., not taking $GUIX_ENVIRONMENT into
 ;; account.  Provide a good default here when asked.
-"PS1='\\u@\\h \\w${GUIX_ENVIRONMENT:+ [env]}\\$ '"
+"PS1='\\u@\\h \\w${GUIX_ENVIRONMENT:+ [env]}\\$ '\n"
 (serialize-field 'aliases))
   (list (serialize-field 'aliases
  (file-if-not-empty 'bash-logout)

bug#70652: Download fallback fails to consider bordeaux.guix and to download nar

[Ludovic Courtès]

Hi!

Minutes ago, after someone reported the issue on IRC, I got this:

--8<---cut here---start->8---
$ guix build 
/gnu/store/cq4j0mkbni4arlw9b7d1d8jcllbdb3yf-linux-libre-5.10.35-gnu.tar.xz.drv 
--no-substitutes
The following derivation will be built:
  /gnu/store/cq4j0mkbni4arlw9b7d1d8jcllbdb3yf-linux-libre-5.10.35-gnu.tar.xz.drv
building 
/gnu/store/cq4j0mkbni4arlw9b7d1d8jcllbdb3yf-linux-libre-5.10.35-gnu.tar.xz.drv...

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>https://linux-libre.fsfla.org/pub/linux-libre/releases/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz...
download failed 
"https://linux-libre.fsfla.org/pub/linux-libre/releases/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz;
 404 "Not Found"

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From ftp://alpha.gnu.org/gnu/guix/mirror/linux-libre-5.10.35-gnu.tar.xz...
Throw to key `ftp-error' with args `(# "RETR 
linux-libre-5.10.35-gnu.tar.xz" 550 "Failed to open file.\r")'.

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>https://ftpmirror.gnu.org/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz...
following redirection to 
`https://mirror.cyberbits.eu/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz'...
download failed 
"https://mirror.cyberbits.eu/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz;
 404 "Not Found"

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>ftp://ftp.cs.tu-berlin.de/pub/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz...
In procedure getaddrinfo: Name or service not known

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>ftp://ftp.funet.fi/pub/mirrors/ftp.gnu.org/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz...
Throw to key `ftp-error' with args `(# "CWD 
5.10.35-gnu" 550 "Can't change directory to 5.10.35-gnu: No such file or 
directory\r")'.

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>http://ftp.gnu.org/pub/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz...
download failed 
"http://ftp.gnu.org/pub/gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz;
 404 "Not Found"

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>https://ci.guix.gnu.org/file/linux-libre-5.10.35-gnu.tar.xz/sha256/0q2rnchad55d49f3rajrkazz0fcjv1irwrdb1hwjnl01fzm2gjk3...
download failed 
"https://ci.guix.gnu.org/file/linux-libre-5.10.35-gnu.tar.xz/sha256/0q2rnchad55d49f3rajrkazz0fcjv1irwrdb1hwjnl01fzm2gjk3;
 404 "Not Found"

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>https://tarballs.nixos.org/sha256/0q2rnchad55d49f3rajrkazz0fcjv1irwrdb1hwjnl01fzm2gjk3...
download failed 
"https://tarballs.nixos.org/sha256/0q2rnchad55d49f3rajrkazz0fcjv1irwrdb1hwjnl01fzm2gjk3;
 404 "Not Found"

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>https://archive.softwareheritage.org/api/1/content/sha256:63ca27ea7701502b390cab659e63d89239f0bf9a59aa3c5c22ad94a620b35960/raw/...
download failed 
"https://archive.softwareheritage.org/api/1/content/sha256:63ca27ea7701502b390cab659e63d89239f0bf9a59aa3c5c22ad94a620b35960/raw/;
 404 "Not Found"

Starting download of 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz
>From 
>https://web.archive.org/web/20240429180042/https://linux-libre.fsfla.org/pub/linux-libre/releases/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz...
download failed 
"https://web.archive.org/web/20240429180042/https://linux-libre.fsfla.org/pub/linux-libre/releases/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz;
 404 "NOT FOUND"
Trying to use Disarchive to assemble 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz...

Retrieving Disarchive spec from 
https://disarchive.guix.gnu.org/sha256/63ca27ea7701502b390cab659e63d89239f0bf9a59aa3c5c22ad94a620b35960
 ...
Assembling the directory linux-libre-5.10.35-gnu
Downloading 
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz from 
Software Heritage...
SWH: object swh:1:dir:dde58dfcb25b84381794e68ad68e34e4c593aa71 could not be 
fetched from the vault
Could not resolve directory reference
failed to download 
"/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz" 
from 
("https://linux-libre.fsfla.org/pub/linux-libre/releases/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz;
 "ftp://alpha.gnu.org/gnu/guix/mirror/linux-libre-5.10.35-gnu.tar.xz; 
"mirror://gnu/linux-libre/5.10.35-gnu/linux-libre-5.10.35-gnu.tar.xz")
builder for 
`/gnu/store/cq4j0mkbni4arlw9b7d1d8jcllbdb3yf-linux-libre-5.10.35-gnu.tar.xz.drv'
 failed to produce output path 

bug#69596: ‘guix publish’ memory leak

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> It seems that ‘guix publish’ has been leaking memory noticeably I’d say
> since the beginning of the year on berlin.  After roughly 10 days, it
> has several GiB resident and needs to be restarted or it becomes too
> unresponsive.
>
> I wonder what could be causing this because we used to let it run for
> months without problems I believe.
>
> This is what’s currently running on berlin:
>
>   
> /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/libexec/guix/guile
>  \
>   /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/bin/guix \
>   publish -u guix-publish -p 3000 -C lzip:9 -C zstd:19 --nar-path=nar \
>   --listen=localhost --workers=8 --ttl=15552000s \
>   --cache=/var/cache/guix/publish --cache-bypass-threshold=157286400
>
> … coming from commit 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8.

It turned out to be a guile-lzlib leak that had always been present:

  
https://notabug.org/guile-lzlib/guile-lzlib/commit/74bd35b690801a10ed775d486fffc7372b1b341c

The reason we were seeing it more on berlin is probably because we
increased the cache-bypass-threshold, which goes through the
‘make-lzip-output-port’ code path (as opposed to
‘call-with-lzip-output-port’).

The bug could be reproduced with:

  guix publish -p 8124 … &
  while true ; do wget -q -O/dev/full 
http://localhost:8124/nar/lzip/…-coreutils-9.1 ; done

(Replace the ellipses with the actual store file name of coreutils.)

Fixed by commit 7cef6b7ba555a9dfaf6d09cb7e112b0df77d5141, which updates
guile-lzlib.

Ludo’.

bug#70278: udevd[87]: specified group 'sgx' unknown

[Ludovic Courtès]

Hi,

Liliana Marie Prikler  skribis:

> Am Donnerstag, dem 11.04.2024 um 09:58 +0200 schrieb Ludovic Courtès:
>> Ludovic Courtès  skribis:
>> 
>> > Since the recent ‘gnome-team’ merge, we get this message at boot
>> > time:
>> > 
>> >   udevd[87]: specified group 'sgx' unknown
>> > 
>> > Should we add ‘sgx’ to ‘%base-groups’?  (What is it for?)
>> 
>> Cc’ing Vivien & Liliana who might know more about this.
> This seems related to Intel's Software Guard eXtensions, or, as we in
> the free world like to call them Security paper Generator eXtensions. 

:-)

> As far as I'm aware, these ought to be disabled anyway, and we might
> want to drop the offending lines.  According to [1], there's only two
> of them anyway.

[...]

> [1] https://wiki.linuxfromscratch.org/lfs/ticket/5265

Sounds good.  (My intuition would have been to create the ‘sgx’ group to
placate udev, but removing those lines may be even better.)

Can you look into it?

Thanks,
Ludo’.

bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial

[Ludovic Courtès]

Simon Tournier  skribis:

> Hi Ludo,
>
> On Fri, 12 Apr 2024 at 11:30, Ludovic Courtès  
> wrote:
>
>> > $ guix build -S -d hg-commitsigs
>> > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> > 3,7 MB will be downloaded:
>> >   /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2
>> > substituting /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2...
>> > downloading from 
>> > https://ci.guix.gnu.org/nar/lzip/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2
>> >  ...
>> >  mercurial-6.2.2  3.5MiB   
>> > 529KiB/s 00:07 ▕██▏ 100.0%
>> >
>> > /gnu/store/pkb6zd9xfmxx6rsh4p7w3glh7xqg5sqy-hg-commitsigs-0.1.0-0.b53eb68-checkout.drv
>> >
>> > and it is unexpected.
>>
>> That running ‘hg clone’ requires Mercurial isn’t totally unexpected to
>> me.  :-)
>
> There is a misunderstanding, I guess.
>
> Running 'hg clone' requires to have a local copy of Mercurial, yes for sure. 
> :-)
>
> However, just ask what it will run (please note the dash d in guix
> build -S -d hg-commitsigs) must not require to have a local copy of
> Mercurial (binary).  If you still think yes, why is it not the case
> for fixed-output derivations relying on the old Git builder?

Oh sorry, I had missed the ‘-d’ bit.

In this case, what’s happening is grafts: Guix downloads (or builds)
Mercurial so it can compute its grafted derivation.

>> Now, the ‘guix recover’ tool (or whatever you call it) you’re working on
>> could create a different fixed-output derivation producing the same
>> result but without using Mercurial; typically, the builder of that
>> derivation would download from SWH.
>>
>> Does that make sense?
>
> Yes, it makes sense; see my very first attempt in [1] :-).

[...]

> 1: https://gitlab.com/zimoun/guix-drv

Nice!

Thanks,
Ludo’.

bug#59365: make-dynamic-linker-cache OOMs for LLVM 15 on i686-linux

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

>>   GC Warning: Failed to expand heap by 285216768 bytes
>>   GC Warning: Failed to expand heap by 268439552 bytes
>>   GC Warning: Out of Memory! Heap size: 3620 MiB. Returning NULL!
>>   Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
>>   Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
>>   Warning: Unwind-only out of memory exception; skipping pre-unwind handler.
>>
>> (excerpt from https://ci.guix.gnu.org/build/1702995/log/raw)
>>
>> Not sure why this phase uses so much memory.  Ideas?
>
> Yes: the gremlin.scm code uses ‘file-dynamic-info’, which loads the
> whole file in memory.  Ridiculous.
>
> We should instead mmap it (but there are no ‘mmap’ bindings in Guile,
> yet) or arrange to load just the relevant parts (we’ll have to check but
> maybe ‘file-dynamic-info’ can find everything it needs at the beginning
> of a file, the PT_DYNAMIC segment.)

Another instance of the problem that we just stumbled upon is ‘guix pack -RR’:
that too tries to load entire ELF files in memory, in
‘elf-loader-compile-flags’.

Mmap!

Ludo’.

bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial

[Ludovic Courtès]

Hello!

Simon Tournier  skribis:

> $ guix build -S -d hg-commitsigs
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> 3,7 MB will be downloaded:
>   /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2
> substituting /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2...
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2
>  ...
>  mercurial-6.2.2  3.5MiB   
> 529KiB/s 00:07 ▕██▏ 100.0%
>
> /gnu/store/pkb6zd9xfmxx6rsh4p7w3glh7xqg5sqy-hg-commitsigs-0.1.0-0.b53eb68-checkout.drv
>
>
> and it is unexpected.

That running ‘hg clone’ requires Mercurial isn’t totally unexpected to
me.  :-)

> I think it comes from this part:
>
>  (hg-fetch '#$(hg-reference-url ref)
>'#$(hg-reference-changeset ref)
>#$output
>#:hg-command (string-append #+hg "/bin/hg")))
>
> from ’hg-fetch’ in (guix hg-download).  Here the #+hg is not required
> because just before there is:
>
> (set-path-environment-variable "PATH" '("bin")
>(match '#+inputs
>  (((names dirs outputs ...) ...)
>   dirs)))

Maybe, but one way or another, Mercurial is necessary.

Now, the ‘guix recover’ tool (or whatever you call it) you’re working on
could create a different fixed-output derivation producing the same
result but without using Mercurial; typically, the builder of that
derivation would download from SWH.

Does that make sense?

HTH,
Ludo’.

bug#70278: udevd[87]: specified group 'sgx' unknown

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Since the recent ‘gnome-team’ merge, we get this message at boot time:
>
>   udevd[87]: specified group 'sgx' unknown
>
> Should we add ‘sgx’ to ‘%base-groups’?  (What is it for?)

Cc’ing Vivien & Liliana who might know more about this.

Ludo’.

bug#70275: Epiphany requires /run/current-system/profile/sbin/dbus-launch

[Ludovic Courtès]

Ludovic Courtès  skribis:

> (epiphany:9264): epiphany-WARNING **: 14:39:27.754: Web process crashed
>
> (process:2): libportal-CRITICAL **: 14:39:27.997: Failed to create XdpPortal 
> instance: Failed to execute child process “dbus-launch” (No such file or 
> directory)

This is a regression with the GNOME 44 upgrade; it works fine with
Epiphany from commit 28bc0e870b4d48b8e3e773382bb0e999df2e3611 (‘master’
branch from March 23rd).

bug#70278: udevd[87]: specified group 'sgx' unknown

[Ludovic Courtès]

Since the recent ‘gnome-team’ merge, we get this message at boot time:

  udevd[87]: specified group 'sgx' unknown

Should we add ‘sgx’ to ‘%base-groups’?  (What is it for?)

Ludo’.

bug#70275: Epiphany requires /run/current-system/profile/sbin/dbus-launch

[Ludovic Courtès]

Since the GNOME 44 upgrade, Epiphany no longer works for me (I’m using
EXWM, not GNOME):

--8<---cut here---start->8---
$ guix describe
Generation 299  Apr 08 2024 00:55:02(current)
  shepherd d8d96fc
repository URL: https://git.savannah.gnu.org/git/shepherd.git
branch: devel
commit: d8d96fc28c49c624323b2f9f5cb01c4fc18a4afd
  guile db7efa5
repository URL: https://git.savannah.gnu.org/git/guile.git
branch: main
commit: db7efa5d204b2e46ce9eb82f417d8c12d394858d
  guix 49f82fc
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 49f82fca4130ffcfb16aa0cf89750ab56fb99ad7
$ guix shell epiphany -- epiphany
[…]
(epiphany:9264): epiphany-WARNING **: 14:39:27.754: Web process crashed

(process:2): libportal-CRITICAL **: 14:39:27.997: Failed to create XdpPortal 
instance: Failed to execute child process “dbus-launch” (No such file or 
directory)


(epiphany:9264): epiphany-WARNING **: 14:39:28.001: Web process crashed

(process:2): libportal-CRITICAL **: 14:39:28.625: Failed to create XdpPortal 
instance: Failed to execute child process “dbus-launch” (No such file or 
directory)
^C
$ type -P dbus-launch
/home/ludo/.guix-home/profile/bin/dbus-launch
--8<---cut here---end--->8---

Stracing shows this:

  10989 execve("/run/current-system/profile/sbin/dbus-launch", ["dbus-launch", 
"--autolaunch=a6bada0da851047b698"..., "--binary-syntax", "--close-stderr"], 
0x5d7120 /* 81 vars */ 

Since I no longer have GDM either,
/run/current-system/profile/sbin/dbus-launch is gone, too (that’s
probably the main reason).

I’m not sure where this hard-coded /run/current-system/… comes from.
Should we do something about it?

Ludo’.

bug#70239: (operating-system) structure requires a kernel

[Ludovic Courtès]

Hi,

Tomas Volf <~@wolfsden.cz> skribis:

> (operating-system
>   (host-name "guix")
>   ;; Servers usually use UTC regardless of the location.
>   (timezone "Etc/UTC")
>   (locale "en_US.utf8")
>   (firmware '())
>   (initrd-modules '())
> ;  (kernel %ct-dummy-kernel)
> (kernel #f)

[...]

> In gnu/services.scm:
>   1031:29  7 (linux-builder-configuration->system-entry _)
> In guix/profiles.scm:
> 439:4  6 (packages->manifest _)
> In srfi/srfi-1.scm:
>586:17  5 (map1 (#f))
> In guix/inferior.scm:
> 549:2  4 (loop #f "out" #)
> 529:4  3 (inferior-package-input-field #f _)
>473:18  2 (inferior-package-field #f (compose (lambda (#) (…)) #))
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1 (expecting 
> struct): #f

Indeed, ‘linux-builder-configuration->system-entry’ is not prepared for
that, but we can fix it.

> The (kernel (plain-file "fake-kernel" "")) leads to a different error:
>
> building /gnu/store/idy2sylx9zbvphzlqvhnldjvg242hd2a-linux-modules.drv...
> find-files: 
> /gnu/store/jfcbq6djya5pi54yhpvzj66r18h4mp09-dummy-kernel-1/lib/modules: Not a 
> directory
> Backtrace:
>4 (primitive-load "/gnu/store/sckm34nzvmkcynhgn6zs5aq6xfs?")
> In ice-9/eval.scm:
> 619:8  3 (_ #f)
>626:19  2 (_ #)
> 159:9  1 (_ #)
> In unknown file:
>0 (car ())
>
> ERROR: In procedure car:
> In procedure car: Wrong type (expecting pair): ()

I believe this one is a regression introduced in
8f8ec56052766aa5105d672b77ad9eaca5c1ab3c.  I believe this is fixed by
this patch:

diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
index 561cfe2fd0..40ff2dc808 100644
--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -134,18 +134,23 @@ (define (flat-linux-module-directory linux modules)
  (guix build utils)
  (rnrs io ports)
  (srfi srfi-1)
- (srfi srfi-26))
+ (srfi srfi-26)
+ (ice-9 match))
 
 (define module-dir
   (string-append #$linux "/lib/modules"))
 
 (define builtin-modules
-  (call-with-input-file
-  (first (find-files module-dir "modules.builtin$"))
-(lambda (port)
-  (map file-name->module-name
-   (string-tokenize
-(get-string-all port))
+  (match (find-files module-dir (lambda (file stat)
+  (string=? (basename file)
+"modules.builtin")))
+((file . _)
+ (call-with-input-file file
+   (lambda (port)
+ (map file-name->module-name
+  (string-tokenize (get-string-all port))
+(_
+ '(
 
 (define modules-to-lookup
   (lset-difference string=? '#$modules builtin-modules))

Could you confirm?

> I think it would be best to just support (kernel #f) for container 
> deployments,
> since that would simplify it and keep it manageable.

Yes, let’s do that too.

Thanks,
Ludo’.

bug#70051: bug#70266: Failure to open LUKS devices from a Shepherd service

[Ludovic Courtès]

Hi,

aurtzy  skribis:

> On 4/7/24 19:43, Ludovic Courtès wrote:
>> Oops, sorry for not noticing it earlier!  (That was a hard-to-debug one
>> so kudos for the work you and others put in it.)
>>
>> I pushed these two commits to address the problem:
>>
>>49f82fca41 mapped-devices: luks: Specify modules needed at the top-level.
>>6062339156 mapped-devices:  can specify modules to 
>> import.
>>
>> It works well in my tests but please let me know if something’s amiss.
>
> Just pulled+reconfigured, and my machine boots just fine with the
> problem LUKS device being decrypted as expected again. Thanks!

Awesome, thanks for confirming, and apologies for introducing this
regression in the first place!

Ludo’.

bug#70051: bug#70266: Failure to open LUKS devices from a Shepherd service

[Ludovic Courtès]

Hi aurtzy,

aurtzy  skribis:

> This bug has also been reported here: https://issues.guix.gnu.org/70051
>
> I sent a patch that a few others have confirmed fixes the issue:
> https://issues.guix.gnu.org/70051#5

Oops, sorry for not noticing it earlier!  (That was a hard-to-debug one
so kudos for the work you and others put in it.)

I pushed these two commits to address the problem:

  49f82fca41 mapped-devices: luks: Specify modules needed at the top-level.
  6062339156 mapped-devices:  can specify modules to import.

It works well in my tests but please let me know if something’s amiss.

Thanks,
Ludo’.

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> root@hydra-guix-108 ~# guix gc -R $(readlink -f /run/current-system) |grep 
>> machines.scm
>> /gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm
>> root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm
>> lrwxrwxrwx 1 root root 56 Mar  7 11:53 /etc/guix/machines.scm -> 
>> /gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm
>
> Turns out that both files are identical, but:
>
>   • /gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm is built
> with
> /gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile
> (‘guile-final’ ungrafted);
>
>   • /gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm is built
> with
> /gnu/store/g49b4v7dff8xwfi7wpi8pps1ixhld3n7-guile-3.0.9/bin/guile
> (‘guile-final’ grafted).
>
> As it turns out,  (used for “machines.scm”) uses
> ‘gexp->file’, which, unlike ‘gexp->script’, does not default to
> (default-guile).  That probably explains the difference.

I believe this is fixed by b30b838d5055e36be19d030db28838fec4474d98.

Ludo’.

bug#70266: Failure to open LUKS devices from a Shepherd service

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Commit 6f9d844d2ece7b369d17bbe678978462425f869c led to a regression:
> when a ‘luks-device-mapping’ mapped device is opened from a Shepherd
> service (for instance a ‘device-mapping-XXX’ service created by
> ‘device-mapping-service-type’ because, say, /home is a separate LUKS
> partition), said service fails to start with:
>
>   Unbound variable: bytevector?
>
> This is the ‘bytevector?’ referred to in ‘open-luks-device’.

This is a situation with a non-top-level ‘use-modules’.

The problem can be illustrated like this:

--8<---cut here---start->8---
$ cat ~/src/guile-debugging/non-top-level-use-modules.scm
;; (define-module ())

(define (foo x)
  (use-modules (rnrs bytevectors))  ;bad!!
  (bytevector? x))

;; (pk '-> (foo (call-with-input-string "#vu8(1 2 3)" read)))

(pk 'foo foo)

$ guild compile -O1 ~/src/guile-debugging/non-top-level-use-modules.scm 
/home/ludo/src/guile-debugging/non-top-level-use-modules.scm:3:3: warning: 
possibly unbound variable `bytevector?'
wrote 
`/home/ludo/.cache/guile/ccache/3.0-LE-8-4.7/home/ludo/src/guile-debugging/non-top-level-use-modules.scm.go'
$ guile
GNU Guile 3.0.99-git
Copyright (C) 1995-2024 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@(guile-user)> ,m(sdf)
scheme@(sdf)> ,use(guile)
scheme@(sdf)> (load-compiled 
"/home/ludo/.cache/guile/ccache/3.0-LE-8-4.7/home/ludo/src/guile-debugging/non-top-level-use-modules.scm.go")

;;; (foo #)
$1 = #
scheme@(sdf)> ,m(guile-user)
scheme@(guile-user)> ($1 123)
;;; :7:1: warning: possibly unbound variable `$1'
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
Unbound variable: bytevector?

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to contin
--8<---cut here---end--->8---

‘use-modules’, when used this way, loads the specified modules in
(current-module) at that point (at run time).  If you change what the
current module is, as I did above, then it breaks.

Ludo’.

bug#70266: Failure to open LUKS devices from a Shepherd service

[Ludovic Courtès]

Hello,

Commit 6f9d844d2ece7b369d17bbe678978462425f869c led to a regression:
when a ‘luks-device-mapping’ mapped device is opened from a Shepherd
service (for instance a ‘device-mapping-XXX’ service created by
‘device-mapping-service-type’ because, say, /home is a separate LUKS
partition), said service fails to start with:

  Unbound variable: bytevector?

This is the ‘bytevector?’ referred to in ‘open-luks-device’.

As a result, the system just hangs at boot time because that
‘device-mapping-XXX’ service fails to start.

Ludo’.

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

[Ludovic Courtès]

Ludovic Courtès  skribis:

> root@hydra-guix-108 ~# guix gc -R $(readlink -f /run/current-system) |grep 
> machines.scm
> /gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm
> root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm
> lrwxrwxrwx 1 root root 56 Mar  7 11:53 /etc/guix/machines.scm -> 
> /gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm

Turns out that both files are identical, but:

  • /gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm is built
with
/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile
(‘guile-final’ ungrafted);

  • /gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm is built
with
/gnu/store/g49b4v7dff8xwfi7wpi8pps1ixhld3n7-guile-3.0.9/bin/guile
(‘guile-final’ grafted).

As it turns out,  (used for “machines.scm”) uses
‘gexp->file’, which, unlike ‘gexp->script’, does not default to
(default-guile).  That probably explains the difference.

Ludo’.

bug#42379: uninstaller

[Ludovic Courtès]

Hi,

David Redick  skribis:

> So I installed guix as a guest on my debian laptop as an evaluation.
>
> Unfortunately, I couldn't find an uninstaller so I modified the
> guix-install.sh to support a --uninstall parameter that would remove
> guix from the host system.

Thanks for the patch.  It’s an oft-requested feature and it seems we’d
rather have it than leaving users on their own.

I rebased and applied your patch, documented it in the manual, and
committed as dd476cfb76511063e19ac3e70afd1d5a391b47f7.  Apologies for
not adjusting the author to credit you, my bad!

Thanks,
Ludo’.

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> Some of the build nodes behind the Berlin build farm have a childhurd
> which can build packages.  Unfortunately, the symlink from
> /etc/guix/machines.scm to the generated file in the store to setup
> offloading has been garbage collected on several of the machines.

Indeed.  Here’s an example:

--8<---cut here---start->8---
root@hydra-guix-108 ~# guix gc -R $(readlink -f /run/current-system) |grep 
machines.scm
/gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm
root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm
lrwxrwxrwx 1 root root 56 Mar  7 11:53 /etc/guix/machines.scm -> 
/gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm
root@hydra-guix-108 ~# stat -L /etc/guix/machines.scm
stat: cannot statx '/etc/guix/machines.scm': No such file or directory
--8<---cut here---end--->8---

Here /etc/guix/machines.scm points to a different ‘machines.scm’ than
the one that is current.  The old one was removed last week:

--8<---cut here---start->8---
root@hydra-guix-108 ~# zgrep 1171q4xhph07ll3mlzlg7igcwg3c98i1 
/var/log/mcron.log.1.gz 
2024-03-27 03:00:05 23100 guix gc -F 150G: [46%] deleting 
'/gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm'
--8<---cut here---end--->8---

The /etc/guix/machines.scm link was created on the last deployment
though:

--8<---cut here---start->8---
root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm
lrwxrwxrwx 1 root root 56 Mar  7 11:53 /etc/guix/machines.scm -> 
/gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm
root@hydra-guix-108 ~# guix system describe
Generation 109  Mar 07 2024 11:53:30(current)
  file name: /var/guix/profiles/system-109-link
  canonical file name: /gnu/store/5m0sjf3x0pslipcbdxm9ml99h0lbh7c8-system
  label: GNU with Linux-Libre 6.6.18
  bootloader: grub-efi
  root device: label: "my-root"
  kernel: /gnu/store/jcr3d8yy531q4i6kgkfmb0r3ghw418mc-linux-libre-6.6.18/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  commit: 64d269b983b76553466ac93945d58c7865cf190e
  configuration file: 
/gnu/store/d4z76lw515padizhl62hydxwygh57p6k-configuration.scm
--8<---cut here---end--->8---

Could it be that the “wrong” activation snippet was run by ‘guix
deploy’?  Here we see the right one:

--8<---cut here---start->8---
root@hydra-guix-108 ~# grep machines.scm $(guix gc -R $(readlink -f 
/run/current-system) |grep activate-service)
/gnu/store/pgmb9swcx0pljhbw88mgd3zjagz5axvn-activate-service.scm:(eval-when 
(expand load eval) (let ((extensions (quote ())) (prepend (lambda (items lst) 
(let loop ((items items) (lst lst)) (if (null? items) lst (loop (cdr items) 
(cons (car items) (delete (car items) lst (set! %load-path (prepend 
(cons "/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import" (map (lambda 
(extension) (string-append extension "/share/guile/site/" (effective-version))) 
extensions)) %load-path)) (set! %load-compiled-path (prepend (cons 
"/gnu/store/iqbchmbmhmi34bwgv4sm14li9m24dpnl-module-import-compiled" (map 
(lambda (extension) (string-append extension "/lib/guile/" (effective-version) 
"/site-ccache")) extensions)) %load-compiled-path(begin (unless (or #f 
(file-exists? "/etc/guix/signing-key.pub")) (system* 
"/gnu/store/59y43hrlffs8hg1584vg5074jsbfhwjy-guix-1.4.0-16.aeb4943/bin/guix" 
"archive" "--generate-key")) (begin (use-modules (guix build utils)) (define 
acl-file "/etc/guix/acl") (if (file-exists? acl-file) (if (and (symbolic-link? 
acl-file) (store-file-name? (readlink acl-file))) (delete-file acl-file) 
(rename-file acl-file (string-append acl-file ".bak"))) (mkdir-p (dirname 
acl-file))) (symlink "/gnu/store/np3babd2h4xh4x4dvm51k6rp3xbsrzyl-acl" 
acl-file)) (begin (use-modules (guix build utils)) (define machines-file 
"/etc/guix/machines.scm") (if (file-exists? machines-file) (if (and 
(symbolic-link? machines-file) (store-file-name? (readlink machines-file))) 
(delete-file machines-file) (rename-file machines-file (string-append 
machines-file ".bak"))) (mkdir-p (dirname machines-file))) (symlink 
"/gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm" machines-file)))
--8<---cut here---end--->8---

To be continued…

Ludo’.

bug#54447: cuirass: missing derivation error

[Ludovic Courtès]

Hello!

News from the everlasting bug!

  cannot build missing derivation 
‘/gnu/store/dfgc46q3l8wlnymv49a1wjnxypin8p0y-plink-1.07.drv’

(From .)

Why was it missing this time?  /var/log/nginx/error.log:

--8<---cut here---start->8---
2024/04/04 17:15:03 [error] 98751#0: *152293778 upstream timed out (110: 
Connection timed out) while reading response header from upstream, client: 
141.80.167.169, server: ci.guix.gnu.org, request: "GET 
/dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo HTTP/1.1", upstream: 
"http://127.0.0.1:3000/dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo;, host: 
"141.80.167.131"
--8<---cut here---end--->8---

Oops!  (There are dozens of upstream timeouts logged on that minute.)

/var/log/guix-publish.log:

--8<---cut here---start->8---
2024-04-04 17:14:51 GET 
/nar/lzip/pz39bkq7pd1hgy5rwiynqa33gyjvpgs5-python-pygments-2.12.0
2024-04-04 17:14:51 GET /z2xxwwxswdd4b8c8iwmxhqnqbp5nwz09.narinfo
2024-04-04 17:14:51 GET /lgyck285bsxzwrnh3x5ix5dwzd3n3wga.narinfo
2024-04-04 17:14:51 GET 
/nar/zstd/jxkglr445f215m2faqz1i2lgmbans4rf-texlive-amsmath-66594-doc
2024-04-04 17:15:33 GET /qg5cxb869i42jn7x2dm6k5l41ikkz21w.narinfo
2024-04-04 17:15:33 GET 
/nar/zstd/i2hp3q2pfhsyl0al7z38am7cqpddi4qr-texlive-capt-of-66594-doc
2024-04-04 17:15:33 GET /hh0gdbljj3cjdnjbr88kfm21mhys5sy7.narinfo
2024-04-04 17:15:33 GET /dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo
2024-04-04 17:15:33 GET /yj63wifalfr6sla42h7mkqg011qrl5d0.narinfo
2024-04-04 17:15:33 GET /h2s2g2adxbnd67g34mnjnpcr6p3nhr69.narinfo
2024-04-04 17:15:33 -> GET /h2s2g2adxbnd67g34mnjnpcr6p3nhr69.narinfo: 404
2024-04-04 17:15:33 GET 
/nar/lzip/6zxlrw15b9dsv73s7v5fqabl7iv5v5il-python-exceptiongroup-1.1.1
2024-04-04 17:15:33 GET 
/nar/zstd/pychjd114abscbqlzcr3s7myf1497vw2-julia-compilersupportlibraries-jll-0.4.0%2B1
--8<---cut here---end--->8---

‘guix publish’ replied, but 40s too late (nginx has
“proxy_connect_timeout 10s;” for .narinfo URLs¹).

Notice the 40s pause time between 17:14:51 and 17:15:33.  Stop-the-world
GC?  Unlikely, because ‘guix publish’ had been running for ~3h, so even
with a leak², it’s hard to believe GC could take this long.

Ludo’.

¹ 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/berlin.scm#n103
² https://issues.guix.gnu.org/69596

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

[Ludovic Courtès]

Ludovic Courtès  skribis:

> The ‘cuirass remote-server’ process goes awry when misbehaved clients
> connect; specifically, some of its fibers crash, leaving it running but
> inactive:
>
> 2023-12-04 10:13:14 periodic update: 0 resumable, 0 failed builds
> 2023-12-04 10:13:28 error: Connection reset by peer when replying to 
> xx.xx.xx.254.
> 2023-12-04 10:13:42 error: invalid log received from xx.xx.xx.254
> 2023-12-04 10:13:42 error: EOF while receiving log from xx.xx.xx.254
> 2023-12-04 10:13:48 Uncaught exception in task:
> 2023-12-04 10:13:48 In fibers.scm:
> 2023-12-04 10:13:48186:20  8 (_)
> 2023-12-04 10:13:48145:21  7 (_)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1752:10  6 (with-exception-handler _ _ #:unwind? _ 
> #:unwind-for-type _)
> 2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
> 2023-12-04 10:13:48695:11  5 (_)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1747:15  4 (with-exception-handler # 7f982c2abd50 at ice-9/boot-9.scm:1831:7 (exn)> _ #:unwind? _ 
> #:unwind-for-type _)
> 2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
> 2023-12-04 10:13:48437:23  3 (serve-build-requests _ #< getq: 
> # 
> #))> getq-gc-co
> unter: # putq: # value: (())> putq-gc-counter: #>)
> 2023-12-04 10:13:48 In cuirass/remote.scm:
> 2023-12-04 10:13:48 466:6  2 (receive-message _ #:router? _)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1685:16  1 (raise-exception _ #:continuable? _)
> 2023-12-04 10:13:48   1685:16  0 (raise-exception _ #:continuable? _)
> 2023-12-04 10:13:48 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2023-12-04 10:13:48 Throw to key `match-error' with args `("match" "no 
> matching pattern" (# # 
> #))'.

With commit 9a1452ee021c9f773424961cfeef47ca0b7c5c5a, ‘cuirass
remote-server’ handles this situation gracefully.

I’m still curious about who’s sending us garbage: it has to be valid
zmq, just with the wrong number of parts.  From the logs, it seemed like
a port scanner or something on the MDC network was sending garbage on
all the open ports, but that would need to be a sophisticated one.

Ludo’.

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> The ‘cuirass remote-server’ process goes awry when misbehaved clients
>> connect; specifically, some of its fibers crash, leaving it running but
>> inactive:
>
> I guess what I reported in bug#67633 is a symptom of the above problem,
> perhaps?

It could be yes, if ‘remote-server’ crashed right at that moment.

Ludo’.

bug#67649: shepherd: (shepherd support) is visible for start GEXP

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> This is a Guix bug we can fix by loading each service file in a fresh
> module:

[...]

> I’ll push the patch soonish.

Pushed as 6f9d844d2ece7b369d17bbe678978462425f869c last week.

Thanks!

Ludo’.

bug#68415: User's shepherd services defined in guix home config can not start after guix pull.

[Ludovic Courtès]

Hi,

Feng Shu  skribis:

> Today, after I guix pull again and reconfig guix home, this problem
> dispear, I do not know why :-)
>
>> Feng Shu  writes:

[...]

>>> I tried, but I do not know why: unbound-variable service

I believe this problem was due to the fact that you were running
shepherd < 0.10.

Shepherd 0.10 introduce (service …) as a replacement for (make 
…) and Guix switched to that idiom in
477d4f7d241165b5a5fd315c27efd7803fad4a04, meaning that to complete your
upgrade, you effectively had to start the new shepherd (reboot or
whatever).

Closing!

Thanks,
Ludo’.

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

[Ludovic Courtès]

Tanguy LE CARROUR  skribis:

>> PS: I hear more and more long-time Python developers dismayed by the sad
>> state of packaging and code evolution in Python.  In Guile land, we
>> say: refugees welcome!  Come discover a great language and a great
>> community (together with their own set of problems).
>
> Thanks for the kind invitation, but… I have an acute form of parens-itis.
> Seeing more that a pair of parenthesis on a single line make my eyes bleed! 
> And… `#` is for comments, every other use is complete heresy and those
> who go against the creed should suffer! … isn’t that what the parentheses
> are for?! 

Worry not! As part of our refugees-welcome effort, “we” have put
together tools and guides to help you feel at home:

  https://hg.sr.ht/~arnebab/wisp
  https://www.draketo.de/py2guile

:-)

Ludo’.

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR  skribis:

> Quoting Ludovic Courtès (2024-03-26 17:04:52)

[...]

>> But then I mean, we could offer, say, ‘guix import upstream https://…’,
>> and that thing could parse ‘setup.py’ or similar to produce a package
>> definition from that.
>
> I’m not against a good-old-generic-solution®, but this one might be
> a bit… too generic. It contains no mention to Python, so the next logical step
> would be `guix import URL`. Not that I would not like it, though! 

Well, this has been on my mind for a long time.  Such a tool could
provide at least a useful package skeleton even for software using CMake
or Autotools.

> So I would say… let’s wait and see what the others think. In the
> meantime, I’ll have to dive deeper in the PEP and the actual importer
> code.

Looks like consensus among you Pythonistas has yet to be reached
regarding whether ‘pyproject.toml’ data would be a useful addition.  :-)

We’ll see!

Ludo’.

PS: I hear more and more long-time Python developers dismayed by the sad
state of packaging and code evolution in Python.  In Guile land, we
say: refugees welcome!  Come discover a great language and a great
community (together with their own set of problems).

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

[Ludovic Courtès]

Hello!

Tanguy LE CARROUR  skribis:

> I’m pretty sure you know everything that I’m about to write, but better
> say it out loud…

Nope, I know nothing (I’ve just been told about using ‘pyproject.toml’
and it seemed to kinda make sense. :-))

> For a "standard modern" project managed with Poetry, the Python source
> package contains `PKG-INFO` and `pyproject.toml ` that both contain
> the run time dependencies. The wheel package only contains `METADATA` that
> lists the dependencies. The source only contains a `pyproject.toml`.
> To make the installed package as small as possible, tests files and
> uncompiled assets are not (should not be) included.
> From a Guix stand point, it’s better to build from source to be able to
> run the test suite.
>
> For the `python-pypugjs` you used as an example, we build from source,
> so I guess the question does not arise. If we were to use the packages
> available on PyPI, what I said above is *NOT* confirmed :
> - wheel (`.whl`) only contains `METADATA` with the dependencies; **BUT**
> - source (`.tar.gz`) contains `PKG-INFO` (without dependency information),
>   `pyproject.toml` (with dep’) and `setup.py` (also with dep’).
>
> … "fun" fact, the information in `pyproject.toml` are **NOT** the same as
> the one in `setup.py`!? 勞 `pyproject.toml` says that `nose` is a run time
> dependency (which it is not), but `setup.py` properly lists it in 
> `tests_require`.

Oh my, such a mess.

> So, my answer would be: do not import from PyPI! Yes, I know, it’s radical! 
> But if you have to, rely on the wheel’s `METADATA` file.
>
> I hope this make sense. … I’m not really sure any more! 

It does!

But then I mean, we could offer, say, ‘guix import upstream https://…’,
and that thing could parse ‘setup.py’ or similar to produce a package
definition from that.  Maybe that’s what you had in mind: import
straight from upstream rather than via PyPI?

Thanks,
Ludo’.

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

[Ludovic Courtès]

Hello Python team!

Should ‘guix import pypi’ attempt to get dependency information from
‘pyproject.toml’, in addition to ‘requirements.txt’ and wheel ‘METADATA’
as it already does?

It might be more complicated than we’d like: in some cases, that file
seems to be used as a “trampoline” to Poetry.  For instance, in
python-pypugjs, the ‘requires’ bit delegates everything to Poetry:

--8<---cut here---start->8---
[tool.poetry]
name = "pypugjs"
version = "5.9.4"
description = ""
authors = ["Andy Grabow "]
license = "MIT"

[tool.poetry.dependencies]
python = "^3.8"
Jinja2 = "^3.1.1"
Mako = "^1.1.3"
tornado = "^6.0.4"
six = "^1.15.0"
coverage = "^6.3.2"
nose = "^1.3.7"
Flask = "^2.1.1"
charset-normalizer = "^2.1.0"
flake8 = "^4.0.1"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"
--8<---cut here---end--->8---

Thoughts?

Ludo’.

bug#67649: shepherd: (shepherd support) is visible for start GEXP

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> start GEXP's of services are loaded into unnamed modules. the definitions 
> from (shepherd support) are visible in these unnamed modules. see the 
> attached rerpoducer.

It’s more than (shepherd support):

--8<---cut here---start->8---
shepherd[1]: Starting service reproducer...
shepherd[1]: *** reproducer gexp speaking, current module: #, mor
face (oop goops) 7f2cf8a89c80> # 
# # 
# # 
# # 
# # # # # # # 
# # # # # # # # # # # 
# # 
# # 
# # 
# # # # # # 
# # #), ringbuffer: #
--8<---cut here---end--->8---

> is this indended? i.e. part of the shepherd API?

It’s not really intended.

In Guix, ‘shepherd-service’ instances have a ‘modules’ field.  Many,
like the one for mcron, have (shepherd support) there because they need
it for one thing or another.

Now, your ‘reproducer’ service has a default ‘modules’ field so why does
it see those modules anyway?

First, note that (current-module) called from the ‘start’ method does
*not* return the module where that ‘start’ method was defined.

Still, what we see here is that the module in which the shepherd config
file is evaluated has way more imports than expected.  This stems from
the way services get loaded on Guix System, in
‘shepherd-configuration-file’:

(register-services
 (parameterize ((current-warning-port
 (%make-void-port "w")))
   (map load-compiled '#$(map scm->go files

Thus, each one of ‘files’ augments the imports of the current module,
eventually leading to this import soup.

This is a Guix bug we can fix by loading each service file in a fresh
module:

diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index f5bcde721f..6b8527f0dc 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -383,6 +383,14 @@ (define (shepherd-configuration-file services shepherd)
   (use-modules (srfi srfi-34)
(system repl error-handling))
 
+  (define (make-user-module)
+;; Copied from (shepherd support), where it's private.
+(let ((m (make-fresh-user-module)))
+  ;; The typical configuration file wants to do '(service ...)', and
+  ;; '(register-services ...)', so provide the relevant bindings by default.
+  (module-use! m (resolve-interface '(shepherd service)))
+  m))
+
   ;; There's code run from shepherd that uses 'call-with-input-file' &
   ;; co.--e.g., the 'urandom-seed' service.  Starting from Shepherd
   ;; 0.9.2, users need to make sure not to leak non-close-on-exec file
@@ -416,7 +424,12 @@ (define (shepherd-configuration-file services shepherd)
   (register-services
(parameterize ((current-warning-port
(%make-void-port "w")))
- (map load-compiled '#$(map scm->go files))
+ (map (lambda (file)
+(save-module-excursion
+ (lambda ()
+   (set-current-module (make-user-module))
+   (load-compiled file
+  '#$(map scm->go files))
 
   (format #t "starting services...~%")
   (let ((services-to-start

There might be breakage due to services that currently get the modules
they need “by chance” (as a side effect of loading another module), but
at least this small sample works fine:

  make check-system TESTS="basic openssh nginx static-networking 
static-networking-advanced mcron hpcguix-web" -j4

I’ll push the patch soonish.

Thanks!

Ludo’.

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

[Ludovic Courtès]

Christopher Baines  skribis:

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

I’m closing it.  Let’s reopen if we stumble upon a similar issue.

Ludo’.

bug#68591: Error when using shepherd on foreign distro

[Ludovic Courtès]

Hi Einar,

Einar Largenius  skribis:

> I am setting up shepherd for use by my user account on a foreign distro. I 
> setup as described in the manual in the section "(shepherd) Managing User 
> Services". When I try to run it using shepherd, it crashes on the line:
>
>  ;; Send shepherd into the background
>  (perform-service-action 'shepherd 'daemonize)
>
> with the error:
>
> Uncaught exception while loading configuration file 
> '/home/jaadu/.config/shepherd/init.scm': (goops-error #f "No applicable 
> method for ~S in call ~S" (#< service-actions (1)> (service-actions 
> shepherd)) ())

This was a bug in the documentation, now fixed in Shepherd commit
0fbba586cd1eafa28c827641f093cc9f3cdc1d00.

Instead of the line above, you should write:

  (perform-service-action root-service 'daemonize)

Thanks!

Ludo’.

bug#67565: shepherd: FAIL: tests/close-on-exec.sh

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> this log file is with my shepherd branch, i.e. it contains much more log.

Could you check whether it happens with current ‘main’?

The test is quite sensitive to anything that would open file
descriptors, as you can imagine.

Thanks,
Ludo’.

bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`

[Ludovic Courtès]

Hi Richard and all,

Richard Sent  skribis:

> However, when fish is in charge of executing on-first-login, stdout and 
> stderr for the user shepherd get directed to a pipe instead of 
> /dev/null.
>
> fish fds, both stdout and stderr point to a pipe:
>
> $ ls -l /proc//fd)
> lr-x--   1 richardusers64 2023-11-16 14:47 0 -> 
> /dev/null
> l-wx--   1 richardusers64 2023-11-16 14:47 1 -> 
> pipe:[41039]
> l-wx--   1 richardusers64 2023-11-16 14:47 2 -> 
> pipe:[41039]
> l-wx--   1 richardusers64 2023-11-16 14:47 6 -> 
> /home/richard/.local/state/log/shepherd.log
> // ...
>
>
> fish login shell strace of herd:
>
> 21:46:43 write(1, "Spawning systemd-style service 
> /gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n", 
> 103) = -1 EPIPE (Broken pipe)

(I assume this is the strace of shepherd, not herd.)

Maybe we should unconditionally run shepherd with stdout/stderr
redirected to /dev/null?

That would sidestep the problem and it’s probably a good idea anyway.

WDYT?

Ludo’.

bug#67886: herd status does not execute in virsh and macos arm64 m1 - I can press enter multiple time

[Ludovic Courtès]

Hi Roman,

Sorry for the delay.

Roman Frołow  skribis:

> guix system image --system=aarch64-linux --image-type=uncompressed-iso9660
> /gnu/store/dgiaqzxx743na0fd88a0mzj7f8jmcj5n-guix-29c94dd52-modules/share/guile/site/3.0/gnu/system/install.scm

[...]

> I was able to install guix.
>
> After restart I can run commands like `ls` successfully. But `herd status`
> does not work. It does not execute. I can press the Enter key many times.
> It just does not return to prompt.

So you mean ‘herd status’ hangs, right?

Can you tell us exactly which revision of Guix you used to build the
image and/or which version of the Shepherd it’s running?  To answer the
latter question, run ‘herd --version’.

Thanks,
Ludo’.

bug#66705: ‘guix shell -CW’ provides a Guix command without extra channels

[Ludovic Courtès]

Hello!

I’m glad to report that this bug is fixed by
c90a4e8dcd6ac650392ffcc039273baf145aa3cc.

In these examples, you can see that all my channels are present, both in
a bare-bones ‘shell -CW’ (where bin/ is a direct symlink to the ‘guix
pull’ profile) and in ‘shell -CW coreutils’ (where bin/ fuses that of
coreutils and that of guix):

--8<---cut here---start->8---
$ guix time-machine -- shell -CW -- guix describe
  shepherd 33bcc05
repository URL: https://git.savannah.gnu.org/git/shepherd.git
branch: devel
commit: 33bcc0517c0036589aeb55633d3b8e40a7157973
  guile 54c4753
repository URL: https://git.savannah.gnu.org/git/guile.git
branch: main
commit: 54c4753dd3f7506bee2778b36d7263b613ffd579
  guix b7eb1a8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: b7eb1a8116b2caee7acf26fb963ae998fbdb4253
$ guix time-machine -- shell -CW coreutils -- guix describe
  shepherd 33bcc05
repository URL: https://git.savannah.gnu.org/git/shepherd.git
branch: devel
commit: 33bcc0517c0036589aeb55633d3b8e40a7157973
  guile 54c4753
repository URL: https://git.savannah.gnu.org/git/guile.git
branch: main
commit: 54c4753dd3f7506bee2778b36d7263b613ffd579
  guix b7eb1a8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: b7eb1a8116b2caee7acf26fb963ae998fbdb4253
--8<---cut here---end--->8---

And of course, packages from these channels are now found:

--8<---cut here---start->8---
$ guix time-machine -- shell -CW -- guix build shepherd guile -n
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0%
The following files would be downloaded:
  /gnu/store/d3kc0pww2ff9p06w0g30l0yag68ygns1-shepherd-0.10.99-tarball
  /gnu/store/k0jnqjxs43ra248rb0hqbb31yjbvb9jy-guile-3.0.99-git-debug
  /gnu/store/21q3cm08gda1yd9pi0vwrksvhgjk3qx8-guile-3.0.99-git
$ guix time-machine -- shell -CW coreutils -- guix build shepherd guile -n
The following files would be downloaded:
  /gnu/store/d3kc0pww2ff9p06w0g30l0yag68ygns1-shepherd-0.10.99-tarball
  /gnu/store/k0jnqjxs43ra248rb0hqbb31yjbvb9jy-guile-3.0.99-git-debug
  /gnu/store/21q3cm08gda1yd9pi0vwrksvhgjk3qx8-guile-3.0.99-git
--8<---cut here---end--->8---

Ludo’.

bug#69812: Python fails to build on Alpine linux

[Ludovic Courtès]

Hi!

Tomas Volf <~@wolfsden.cz> skribis:

> 0:02:13 load avg: 9.09 Re-running test_fcntl in verbose mode (matching: 
> test_fcntl_64_bit)
> struct.pack:  
> b'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
> test_fcntl_64_bit (test.test_fcntl.TestFcntl) ... ERROR
>
> ==
> ERROR: test_fcntl_64_bit (test.test_fcntl.TestFcntl)
> --
> Traceback (most recent call last):
>   File 
> "/tmp/guix-build-python-3.10.7.drv-0/Python-3.10.7/Lib/test/test_fcntl.py", 
> line 140, in test_fcntl_64_bit
> fcntl.fcntl(fd, cmd, flags)
> OSError: [Errno 22] Invalid argument

This test looks like this:

--8<---cut here---start->8---
def test_fcntl_64_bit(self):
# Issue #1309352: fcntl shouldn't fail when the third arg fits in a
# C 'long' but not in a C 'int'.
try:
cmd = fcntl.F_NOTIFY
# This flag is larger than 2**31 in 64-bit builds
flags = fcntl.DN_MULTISHOT
except AttributeError:
self.skipTest("F_NOTIFY or DN_MULTISHOT unavailable")
fd = os.open(os.path.dirname(os.path.abspath(TESTFN)), os.O_RDONLY)
try:
fcntl.fcntl(fd, cmd, flags)
finally:
os.close(fd)
--8<---cut here---end--->8---

I suspect this is due to:

  # CONFIG_DNOTIFY is not set

On Guix System, I have:

--8<---cut here---start->8---
$ zgrep CONFIG_DNOTIFY /proc/config.gz
CONFIG_DNOTIFY=y
$ uname -r
6.6.18-gnu
--8<---cut here---end--->8---

:-/

Ludo’.

bug#69609: Missing Disarchive info for isl-0.19.tar.bz2

[Ludovic Courtès]

Hello,

We have an empty Disarchive spec here:

  
https://disarchive.ngyro.com/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8
  
https://disarchive.guix.gnu.org/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8

This is for isl-0.19.tar.bz2, a dependency of GCC in Guix v1.0.0, which
can be built with
/gnu/store/f0ab8n0mnr3s4zj0qxpwfyvzvlipxjdb-isl-0.19.tar.bz2.

Fortunately, that tarball is still available at
https://bordeaux.guix.gnu.org/nar/lzip/f0ab8n0mnr3s4zj0qxpwfyvzvlipxjdb-isl-0.19.tar.bz2
(I’ve now copied it to ci.guix.gnu.org).

Thoughts?

Ludo’.

bug#68848: bug#68857: gnu: home: dotfiles: Avoid creating extra directory in $HOME.

[Ludovic Courtès]

Hi,

Giacomo Leidi  skribis:

> The current implementation of the home-dotfiles-service-type contradicts
> the Guix manual (see https://issues.guix.gnu.org/68848 ). This patch
> properly implements both the plain and Stow dotfiles directory layouts.
>
> It does so by refactoring home-dotfiles-configuration adding a new
> packages field to support GNU Stow's users workflow and introducing
> a new layout field to switch between the two directory layouts.
>
> * gnu/home/services/dotfiles (home-dotfiles-configuration): Migrate to
> (gnu services configuration);
> [packages]: new field;
> [layout]: new field;
> (strip-stow-dotfile): new variable;
> (strip-plain-dotfile): new variable;
> (home-dotfiles-configuration->files): use the new fields;
> [directory-contents]: allow for
> selecting a subset of application dotfile directories;
> * doc/guix.texi: document the new layouts.
>
> Change-Id: I2e96037608353e360828290f055ec5271cfdfd48

Applied, thanks again!

Ludo’.

bug#69596: ‘guix publish’ memory leak

[Ludovic Courtès]

It seems that ‘guix publish’ has been leaking memory noticeably I’d say
since the beginning of the year on berlin.  After roughly 10 days, it
has several GiB resident and needs to be restarted or it becomes too
unresponsive.

I wonder what could be causing this because we used to let it run for
months without problems I believe.

This is what’s currently running on berlin:

  
/gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/libexec/guix/guile
 \
  /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/bin/guix \
  publish -u guix-publish -p 3000 -C lzip:9 -C zstd:19 --nar-path=nar \
  --listen=localhost --workers=8 --ttl=15552000s \
  --cache=/var/cache/guix/publish --cache-bypass-threshold=157286400

… coming from commit 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8.

I don’t see anything that changed recently, be it in maintenance.git
(for the parameters), ‘guix publish’, guile-{lzlib,zstd}, or Guile.
Maybe we had just been lucky?  Anyone else seeing this?

Ludo’.

bug#69442: Discovered substitute servers not removed when they go offline

[Ludovic Courtès]

Hello,

Substitute servers discovered over Avahi don’t disappear when they go
off-line: they remain in /var/guix/discover/publish “forever” (?) and
‘guix substitute’ keeps trying to connect to them, in vain.

The problem AIUI is that the mDNS records are still valid according to
their TTL and thus cached by avahi-daemon; we can only notice that
things go wrong when trying to resolve:

--8<---cut here---start->8---
$ avahi-browse _guix_publish._tcp -r
+ enp0s31f6 IPv6 guix-publish-xyz_guix_publish._tcp 
  local
+ enp0s31f6 IPv4 guix-publish-xyz_guix_publish._tcp 
  local
Failed to resolve service 'guix-publish-xyz' of type '_guix_publish._tcp' in 
domain 'local': Timeout reached
Failed to resolve service 'guix-publish-xyz' of type '_guix_publish._tcp' in 
domain 'local': Timeout reached
--8<---cut here---end--->8---

(One way to reproduce that is to ‘pkill -9 avahi-daemon’ on the machine
that advertises the service.)

Problem is that ‘avahi-browse-service-thread’ attempts to resolve
services once for all; thus it never notices that services went away, at
least not until some long TTL has expired.

Ludo’.

bug#68800: Guix waits for termination of a kernel thread

[Ludovic Courtès]

Hi Tomas,

Tomas Volf <~@wolfsden.cz> skribis:

>> What about this method (from shepherd)?
>>
>> --8<---cut here---start->8---
>> (define (linux-process-flags pid)
>>   "Return the process flags of @var{pid} (or'd @code{PF_} constants), 
>> assuming
>> the Linux /proc file system is mounted; raise a @code{system-error} exception
>> otherwise."
>>   (call-with-input-file (string-append "/proc/" (number->string pid)
>>"/stat")
>> (lambda (port)
>>   (define line
>> (get-string-all port))
>>
>>   ;; Parse like systemd's 'is_kernel_thread' function.
>>   (let ((offset (string-index line #\ ;offset past 'tcomm' field
>> (match (and offset
>> (string-tokenize (string-drop line (+ offset 1
>>   ((state ppid pgrp sid tty-nr tty-pgrp flags . _)
>>(or (string->number flags) 0))
>>   (_
>>0))
>>
>> ;; Per-process flag defined in .
>> (define PF_KTHREAD #x0020);I am a kernel thread
>>
>> (define (linux-kernel-thread? pid)
>>   "Return true if @var{pid} is a Linux kernel thread."
>>   (= PF_KTHREAD (logand (linux-process-flags pid) PF_KTHREAD)))
>> --8<---cut here---end--->8---
>>
>> If it works better, we can use that in syscalls.scm as well.
>
> Yes, that does seem to work:

Pushed as 34c79c6ae8103ebae9ce08c81a9220a6b82b05f6.

Thank you!

Ludo’.

bug#69070: No releases/revisions in /snapshot endpoints?

[Ludovic Courtès]

Dear SWH,

In  I stumbled upon what might be new
behavior from the /snapshot endpoint:

> The crux of the problem is that ‘snapshot-branches’ used to return
> either a “revision” or a “release”, but now it can also return a
> “directory”:
>
> $ wget -qO- 
> https://archive.softwareheritage.org/api/1/snapshot/c405490b80fb35cc58b34260d9ec6add8248857f
>  |jq
> {
>   "id": "c405490b80fb35cc58b34260d9ec6add8248857f",
>   "branches": {
> "1.3.2": {
>   "target": "e4a4be18fae8d9c6528abff3bc9088feb19a76c7",
>   "target_type": "directory",
>   "target_url": 
> "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/;
> },
> "HEAD": {
>   "target": "1.3.2",
>   "target_type": "alias",
>   "target_url": 
> "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/;
> }
>   },
>   "next_branch": null
> }

Current documentation mentions the ‘target_types’ query parameter, which
I could use to restrict results to “revision” and “release”:

  https://archive.softwareheritage.org/api/1/snapshot/doc/

However, that’d be the empty list of the case above.

Other snapshots seem to be missing releases and revisions as well, such
as this one:

  
https://archive.softwareheritage.org/api/1/snapshot/55bda9214f962550baad25026fb3ac3ad12e3eb9/

Did anything change here?  Am I holding it wrong?  :-)

Thanks in advance,
Ludo’.

bug#65847: system container gathering entropy takes forever

[Ludovic Courtès]

Hi,

Jurij  skribis:

> Your container is running.
>
> Try to reach it, via:
> sudo nsenter -a -t  sh

Indeed.  The problem is that the “entry point” (in Docker parlance) of
images created by ‘guix system image -t docker’ is shepherd (PID 1), and
shepherd never exits.

Ludo’.

bug#69058: Failure when fallback to Disarchive+SWH

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

>> Fixed in 1610a632d4b3097282d18af27ff3e9e178d7dfcb.
>
> Cool!  Thanks.
>
> However, it means that it stays broken for all commits before this fix,
> right?  Somehow, if only SWH is available, then
>
> guix time-machine -C channels.scm -- shell -m manifest.scm
>
> will fail for all channels older than today.  Right?

Mostly, yes (“mostly” because derivations using “builtin:git-download”
will automatically be fixed once we’ve updated the ‘guix’ package, but
that only helps if you’re traveling to after September 2023 (commit
13b0cf85eb31e1b1ea674debbbfb0f35a32d1374).

> For instance, redoing your ReScience paper from 2020 using only SWH as I
> did [1] some months ago is now broken (because a change on SWH side).

Indeed.  :-/

That’s a real bummer, but that’s the nature of software: we cannot
retroactively fix bugs.

> Well, I am fine to keep this bug closed but for the posterity we need
> something like:
>
> guix swh get -C channels.scm -m manifest.scm

Exactly!  We have the demonstration of just how important that is.

Ludo’.

bug#51726: SWH: ‘lookup-origin-revision’ can miss tags

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Quoting
> <https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00291.html>:
>
>> However, I get this:
>>
>> $ guix lint -c archival sway
>> gnu/packages/wm.scm:1527:5: sway@1.5.1: scheduled Software Heritage archival

For the record, this particular problem is sidestepped by the
introduction of nar-sha256 ExtID lookup in commit
29f3089c841f00144f24f5c32296aebf22d752cc:

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

It would still be nice to fix but it’s much less critical now.

Ludo’.

bug#69058: Failure when fallback to Disarchive+SWH

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I can reproduce it with c4372f7ebfac17236299346fe60c6ca125336b1f:
>
> scheme@(guile-user)> (swh-download "https://gitlab.com/geontime/redkite.git; 
> "v0.8.0" "/tmp/redkite")
> SWH: found revision 68276b9b88491198c33b03c4188dfe7d6e5dbf2a with directory 
> at 
> 'https://archive.softwareheritage.org/api/1/directory/d14c0eb6801bca920d1e1baac7a4b9e2a0589728/'
> SWH: object swh:1:dir:d14c0eb6801bca920d1e1baac7a4b9e2a0589728 could not be 
> fetched from the vault
> $5 = #f
>
> The bug is that the Vault now returns 302 (redirect) in this case, which
> is similar to the bug I fixed in <https://issues.guix.gnu.org/68741>.

In fact it’s the exact same problem.

Fixed in 1610a632d4b3097282d18af27ff3e9e178d7dfcb.

Thanks,
Ludo’.

bug#69058: Failure when fallback to Disarchive+SWH

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> Another example using Git.  It is from v1.1.0.
>
> $ guix time-machine -q --commit=v1.1.0 -- build -S redkite
> guile: warning: failed to install locale
> The following derivation will be built:
>/gnu/store/x4hcwpmb3p8llbhjzxlfggpkpqc7n5ng-redkite-0.8.0-checkout.drv
> building 
> /gnu/store/x4hcwpmb3p8llbhjzxlfggpkpqc7n5ng-redkite-0.8.0-checkout.drv...
> guile: warning: failed to install locale
> environment variable `PATH' set to 
> `/gnu/store/i2cdl0hvrml8hjdqplqln8didnvxkgp5-gzip-1.10/bin:/gnu/store/jh17p4sns7dvbizwz58gdh953qpic144-tar-1.32/bin'
> Initialized empty Git repository in 
> /gnu/store/y7j54zw1fwhl95534zsjl6rl1rfp7z82-redkite-0.8.0-checkout/.git/
> fatal: could not read Username for 'https://gitlab.com': No such device or 
> address
> Failed to do a shallow fetch; retrying a full fetch...
> fatal: could not read Username for 'https://gitlab.com': No such device or 
> address
> git-fetch: 
> '/gnu/store/xzhkhidb2kqwvpv8b8zaqzgd3gcjs9nn-git-minimal-2.26.0/bin/git fetch 
> origin' failed with exit code 128
> Trying content-addressed mirror at berlin.guixsd.org...
> Trying content-addressed mirror at berlin.guixsd.org...
> Trying to download from Software Heritage...
> SWH: found revision 68276b9b88491198c33b03c4188dfe7d6e5dbf2a with directory 
> at 
> 'https://archive.softwareheritage.org/api/1/directory/d14c0eb6801bca920d1e1baac7a4b9e2a0589728/'
> SWH: directory d14c0eb6801bca920d1e1baac7a4b9e2a0589728 could not be fetched 
> from the vault
> builder for 
> `/gnu/store/x4hcwpmb3p8llbhjzxlfggpkpqc7n5ng-redkite-0.8.0-checkout.drv' 
> failed to produce output path 
> `/gnu/store/y7j54zw1fwhl95534zsjl6rl1rfp7z82-redkite-0.8.0-checkout'
> build of 
> /gnu/store/x4hcwpmb3p8llbhjzxlfggpkpqc7n5ng-redkite-0.8.0-checkout.drv failed
> View build log at 
> '/var/log/guix/drvs/x4/hcwpmb3p8llbhjzxlfggpkpqc7n5ng-redkite-0.8.0-checkout.drv.gz'.
> guix build: error: build of 
> `/gnu/store/x4hcwpmb3p8llbhjzxlfggpkpqc7n5ng-redkite-0.8.0-checkout.drv' 
> failed

I can reproduce it with c4372f7ebfac17236299346fe60c6ca125336b1f:

--8<---cut here---start->8---
scheme@(guile-user)> (swh-download "https://gitlab.com/geontime/redkite.git; 
"v0.8.0" "/tmp/redkite")
SWH: found revision 68276b9b88491198c33b03c4188dfe7d6e5dbf2a with directory at 
'https://archive.softwareheritage.org/api/1/directory/d14c0eb6801bca920d1e1baac7a4b9e2a0589728/'
SWH: object swh:1:dir:d14c0eb6801bca920d1e1baac7a4b9e2a0589728 could not be 
fetched from the vault
$5 = #f
--8<---cut here---end--->8---

The bug is that the Vault now returns 302 (redirect) in this case, which
is similar to the bug I fixed in .

So I’ll have to push that patch series and add a patch for ‘vault-fetch’
on top of it.

Ludo’.

bug#69070: ‘guix lint -c archival python-scikit-learn’ crashes

[Ludovic Courtès]

Hi!

Starting from a couple of weeks ago, probably around the time SWH
deployed an updated version of their infrastructure, we get crashes like
this:

--8<---cut here---start->8---
$ guix describe
Generation 290  Feb 11 2024 23:01:35(current)
  guix c4372f7
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: c4372f7ebfac17236299346fe60c6ca125336b1f
$ guix lint -c archival python-scikit-learn
Backtrace:ython-scikit-learn@1.3.2 [archival]...
  12 (primitive-load "/home/ludo/.config/guix/current/bin/gu…")
In guix/ui.scm:
   2324:7 11 (run-guix . _)
  2287:10 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  8 (for-each # …)
In guix/scripts/lint.scm:
 65:4  7 (run-checkers _ _ #:store _)
In srfi/srfi-1.scm:
634:9  6 (for-each # …)
In guix/scripts/lint.scm:
74:21  5 (_ _)
In guix/lint.scm:
   1662:4  4 (check-archival _)
877:2  3 (call-with-networking-fail-safe _ _ _)
In ice-9/boot-9.scm:
  1752:10  2 (with-exception-handler _ _ #:unwind? _ # _)
  1685:16  1 (raise-exception _ #:continuable? _)
  1683:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" 
directory)'.
--8<---cut here---end--->8---

This can be reproduced by merely evaluating:

  (lookup-origin-revision "https://github.com/scikit-learn/scikit-learn; 
"1.3.2")

The crux of the problem is that ‘snapshot-branches’ used to return
either a “revision” or a “release”, but now it can also return a
“directory”:

--8<---cut here---start->8---
$ wget -qO- 
https://archive.softwareheritage.org/api/1/snapshot/c405490b80fb35cc58b34260d9ec6add8248857f
 |jq
{
  "id": "c405490b80fb35cc58b34260d9ec6add8248857f",
  "branches": {
"1.3.2": {
  "target": "e4a4be18fae8d9c6528abff3bc9088feb19a76c7",
  "target_type": "directory",
  "target_url": 
"https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/;
},
"HEAD": {
  "target": "1.3.2",
  "target_type": "alias",
  "target_url": 
"https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/;
}
  },
  "next_branch": null
}
--8<---cut here---end--->8---

I’ll check with comrades at SWH whether this is intended.

(Note that this problem may vanish once
 has been merged.)

Ludo’.

bug#68595: VLANs in static-networking-service-type hangs shepherd

[Ludovic Courtès]

Hi,

Lars Rustand  skribis:

> Like the title says, if you add any VLAN in a
> static-networking-service-type it seems like the whole shepherd daemon
> freezes up and anything that depends on it stops responding.
> Additionally the networking does not get fully configured either.
>
> After configuring a VLAN `herd status`, `herd restart networking` and
> any other herd command hangs forever with no output. Even reboot is not
> working. The only remedy is to restart the system using the power
> button, but even after the restart the networking service still fails to
> start.

Ouch.  Could you check what /var/log/messages reports?

Once you’ve reproduced the hang, could you attach GDB to shepherd and
get a backtrace?

  gdb -p 1
  bt

(I recommend doing that in a VM rather than on your main machine!)

> 1. Add a static network with a VLAN to your system config (see below for
> minimal example)
> 2. Reconfigure your system
> 3. Restart the networking service with `sudo herd restart networking`
> 4. Observe that herd does not finish
> 5. Try to run `herd status`, `guix system reconfigure`, or `sudo reboot`.
> 6. Observe that none of the commands seem to have any effect, and that
> they hang indefinitely with no output
>
> (service static-networking-service-type
>   (list (static-networking
>  (links
>   (list (network-link
>  (name "myvlan")
>  (type 'vlan)
>  (arguments '((id . 3)
>   (link . "eth0"))
>  (addresses
>   (list (network-address
>  (device "myvlan@eth0")
>  (value "192.168.0.2/24")))

You mentioned in your other message that the example from the manual
works fine.  Could you try and reduce your config until you find which
bit makes it fail?

Cc’ing Alexey and Julien who may know more.

Thanks,
Ludo’.

bug#29365: [bug#68720] [PATCH] gnu: openmolar-1: Update to release 1.1.6-g81838c8 and partial runtime fix.

[Ludovic Courtès]

Hi,

Marco Rimoldi  skribis:

> This commit fixes https://issues.guix.gnu.org/29365.

Alright, applied!

> The package now fails to start with this error message:
>
> File 
> "/gnu/store/zzys4bqllx3a3gramwj2pyyigfb4z75b-openmolar-1.1.6-g81838c85/lib/python3.10/site-packages/openmolar/qt4gui/customwidgets/toothProps.py",
>  line 827, in shapes
> self.mesial.setPoints(
> TypeError: 'float' object cannot be interpreted as an integer
>
> I will submit a new issue if the patch is accepted.

That’d be great.

Thanks!

Ludo’.

bug#68474: [PATCH] tls: Fix openssl-1.0 check phase.

[Ludovic Courtès]

Hello,

Jean-Pierre De Jesus DIAZ  skribis:

> From: Jean-Pierre De Jesus DIAZ 
>
> * modules/past/packages/tls.scm (openssl-1.0): Fix a time bomb in
> cms-test.pl due to expired certificates.

Perfect.  Pushed, thanks!

Ludo’.

bug#68822: Channel dependencies picked at the wrong commit

[Ludovic Courtès]

Ludovic Courtès  skribis:

> When a channel is specified both implicitly, as the dependency of
> another channel, and explicitly, in the user-provided channels file, the
> “most specific” one wins—the one that has a non-#f ‘commit’ field.
>
> However, the dependencies of that channel may be read from the wrong
> one—the least-specific one.  And they can be wrong.

This is fixed by 323b58ac18af8417d5b206288d09d9bb9385d7ae.

The patch changes the order in which channels and their dependencies are
traversed from depth-first to breadth-first.  That gives more precedence
to user-supplied channels, which are likely more specific than what
appears in ‘.guix-channel’ files.  So the fix kinda sidesteps the issue
but I think it makes sense to do it that way.

Ludo’.

bug#68474: [Guix-Past]: openssl@1.0.2u does not pass tests

[Ludovic Courtès]

Hi,

Jean-Pierre De Jesus Diaz  skribis:

> And the from the error file that the test writes:
>
> $ cat /tmp/guix-build-openssl-1.0.2u.drv-0/openssl-1.0.2u/test/cms.err
> Verification failure
> 140737353281920:error:21075075:PKCS7 routines:PKCS7_verify:certificate
> verify error:pk7_smime.c:335:Verify error:certificate has expired

This is a typically “time trap”.  Options are: use libfaketime to run
“make check”, change the certificates so they don’t expire, or skip
those tests.

Would you like to give it a try?

Thanks,
Ludo’.

bug#68822: Channel dependencies picked at the wrong commit

[Ludovic Courtès]

When a channel is specified both implicitly, as the dependency of
another channel, and explicitly, in the user-provided channels file, the
“most specific” one wins—the one that has a non-#f ‘commit’ field.

However, the dependencies of that channel may be read from the wrong
one—the least-specific one.  And they can be wrong.

Here’s an example that illustrates this corner case with ‘guix
time-machine’ taken from current Guix
(ca. 65dc2d40cb113382fb98796f1d04099f28cab355).

--8<---cut here---start->8---
$ guix time-machine -C channels.pinned.scm -- describe
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'guix-hpc-non-free' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git'...
Updating channel 'guix-hpc' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc.git'...
Updating channel 'guix-science-nonfree' from Git repository at 
'https://github.com/guix-science/guix-science-nonfree.git'...
Updating channel 'guix-science' from Git repository at 
'https://github.com/guix-science/guix-science.git'...
Updating channel 'guix-past' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-past'...
Updating channel 'guix-science-nonfree' from Git repository at 
'https://github.com/guix-science/guix-science-nonfree.git'...
Updating channel 'guix-past' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-past'...
Updating channel 'guix-hpc' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc.git'...
Computing Guix derivation for 'x86_64-linux'... /
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0%
The following derivations will be built:
  /gnu/store/m54f7d5prrnilnlkp6iqr9h0wqb70pk2-profile.drv
  /gnu/store/4bkkgq25zgc93iz8d1rzjf63y394ya9d-guix-science-nonfree.drv
  /gnu/store/cnqz5j3mp0qahwvlhv0ykq5bc3m5knnx-inferior-script.scm.drv
  /gnu/store/5agf7bgp7k4sddi5ll6g972cyv5jaksq-module-import-compiled.drv
  /gnu/store/8aql4dp23w2k4dvz26dbkxxix6l2rx7v-guix-past.drv
  /gnu/store/zzb5g3lfvmhmbw9vf6zzz1pdjmy5zikl-inferior-script.scm.drv
  /gnu/store/w8ga4919913v1s3flg21pij60hwsndg4-guix-hpc-non-free.drv
  /gnu/store/lj20q8hc772fm9kh148lxi0zxdral7bv-inferior-script.scm.drv
  /gnu/store/lvmnbdl4d008dyjdf8i4dbzrd5lvbn2m-module-import-compiled.drv
  /gnu/store/yykh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv
  /gnu/store/7s850hb4zv0wn9hclpsq3gykmxmcrcbc-profile.drv
  /gnu/store/as87m36426pk6bfx7f2aix4kdsk1ials-inferior-script.scm.drv

builder for `/gnu/store/pjrgzdpndm31m0kg6jgrlmkzxnbhp0pz-guix-science' failed 
previously (cached)
build of /gnu/store/yykh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv failed
View build log at 
'/var/log/guix/drvs/yy/kh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv.gz'.
$ cat channels.pinned.scm
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "597f1cd1c46ffb92c3e0145de0071545a4c64865")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
  (channel
(name 'guix-hpc-non-free)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git;)
(branch "master")
(commit
  "372c5f471448b32c9204f79c1d46e9b984d03c07"))
  (channel
(name 'guix-science-nonfree)
(url "https://github.com/guix-science/guix-science-nonfree.git;)
(branch "master")
(commit
  "9a3f3824d8ed289832d706679410edadac1202ae")
(introduction
  (make-channel-introduction
"58661b110325fd5d9b40e6f0177cc486a615817e"
(openpgp-fingerprint
  "CA4F 8CF4 37D7 478F DA05  5FD4 4213 7701 1A37 8446"
  (channel
(name 'guix-past)
(url "https://gitlab.inria.fr/guix-hpc/guix-past;)
(branch "master")
(commit
  "1e25b23faa6b1716deaf7e1782becb5da6855942")
(introduction
  (make-channel-introduction
"0c119db2ea86a389769f4d2b9c6f5c41c027e336"
(openpgp-fingerprint
  "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
  (channel
(name 'guix-hpc)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;)
(branch "master")
(commit
  "3ffe8f79a2f128111785fb1107d5f803e00bf00c")))
$ zcat /var/log/guix/drvs/yy/kh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv.gz
(repl-version 0 1 1)
WARNING: (guix-science build bazel-build-system): imported module (guix build 
utils) overrides core binding `delete'
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 

bug#68797: Channel dependencies should be propagated

[Ludovic Courtès]

Hello!

With channels flourishing, we found a bug that’s always been there.

When channel C depends on B, which depends on A, in general you need
both A and B to be present in the build environment of C (the derivation
that compiles C when you run ‘pull’ or ‘time-machine’) because
potentially B is going to load modules from A.

However, currently only B is present in C’s environment.

To illustrate that, the script below creates three such channels.
Right now it fails like this:

--8<---cut here---start->8---
building /gnu/store/2pnfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv...
|builder for `/gnu/store/2pnfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv' 
failed to produce output path 
`/gnu/store/lix9sz9g2x2ixr3dsyrbnxhxfcqn41l7-my-channel-c'
build of /gnu/store/2pnfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv failed
View build log at 
'/var/log/guix/drvs/2p/nfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv.gz'.
cannot build derivation 
`/gnu/store/alh2yy1258206zki24z9nzi1zwrggd4d-profile.drv': 1 dependencies 
couldn't be built
guix time-machine: error: build of 
`/gnu/store/alh2yy1258206zki24z9nzi1zwrggd4d-profile.drv' failed
$ zcat /var/log/guix/drvs/2p/nfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv.gz
(repl-version 0 1 1)
(exception misc-error (value #f) (value "no code for module ~S") (value 
((my-channel-a))) (value #f))
--8<---cut here---end--->8---

Here’s the script:

--8<---cut here---start->8---
#!/bin/sh

set -ex

mkdir a
echo '(define-module (my-channel-a))' > a/my-channel-a.scm
(cd a; git init; git add .; git commit -m init)

mkdir b
cat > b/my-channel-b.scm < b/.guix-channel < c/my-channel-c.scm < c/.guix-channel < "channels.scm" 8---

Ludo’.

bug#47217: generic-html updater does not work with sqlite package

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Léo Le Bouter  skribis:
>>
>>> +   (properties
>>> +`((release-monitoring-url . "https://sqlite.org/download.html;)))
>>
>> Unfortunately this page uses JavaScript.  Without JS, you get:
>>
>>   sqlite-autoconf-3350200.tar.gz(2.82 
>> MiB)
>>
>> We’d need to find a web page that directly links to the tarball, but I
>> can’t seem to find such a page.
>
> Since the SQLite website doesn't seem amenable to discover new releases,
> perhaps we could switch the source to Git and let our git updater do its
> magic?

Switching the source to Git is probably a good idea but it has
additional implications: it adds more dependencies, and there’s a risk
of a cycle with ‘git-fetch’ for those using a daemon with
builtin:git-download, although a quick check suggests we’re fine:

--8<---cut here---start->8---
$ guix graph --path git-minimal sqlite
guix graph: error: no path from 'git-minimal@2.41.0' to 'sqlite@3.42.0'
--8<---cut here---end--->8---

Ludo’.

bug#39885: Bioconductor tarballs are not archived

[Ludovic Courtès]

Hi Timothy,

Timothy Sample  skribis:

> Hello,
>
> Ludovic Courtès  writes:
>
>> As for past tarballs, #swh-devel comrades say we could send them a list
>> of URLs and they’d create “Save Code Now” requests on our behalf (we
>> cannot do it ourselves since the site doesn’t accept plain tarballs.)
>>
>> Any volunteer to write a script that’d generate a list of Bioconductor
>> content-addressed URLs (the bordeaux.guix.gnu.org/file ones) for say the
>> past couple of years?
>
> Sorry I’m a little late to this party, but I wrote a similar script a
> while ago.  It creates a “sources.json” file of all the sources that the
> PoG database analyzed and found missing in SWH.  It only covers what PoG
> monitors (which is *almost* everything, but not quite).

Excellent!

> With some modifications, I used it to generate the attached list of
> Bioconductor sources (based off of recent, unpublished PoG data).  I’ve
> also attached the modifications in case anyone is curious or wants to
> make a similar list.  I will publish the PoG database soon (today?), so
> maybe wait for that before generating any lists.

After discussing it on #swh-devel, I filed this issue:

  https://gitlab.softwareheritage.org/swh/infra/sysadm-environment/-/issues/5222

Tim, you were planning to offer a larger list of missing sources
extracted from the PoG database, right?

Thank you!

Ludo’.

bug#68413: Ungexp doesn't work on deep lists

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> Justin Veilleux  writes:
>
>>> (define packages
>>> (list
>>>  (cons "coreutils" coreutils)
>>>  (cons "make" gnu-make)
>>>  ...))
>>>
>>> #~(for-each
>>>(lambda (f)
>>>  ... do-something)
>>>'#$packages)
>>
>> If I send a patch to "fix" this, will it be usefull or is there a reason
>> for this behavior?
>
> I think IMO that it's a bug, but it's also quite tricky to properly
> traverse deep structures like this.  The bug comes from the fact that in
> gexp->sexp, we traverse lists by matching the reference with (refs ...),
> but that doesn't match if the reference is a pair instead.  Then, it
> tries to match with ($  (? self-quoting? x)), which does
> match since self-quoting? apparently returns #t on a pair, whether or
> not its constituents are also self-quoting.

Actually, what bug are we talking about?  It seems to work for me with
this example:

--8<---cut here---start->8---
scheme@(guile-user)> (define packages `(("coreutils" ,coreutils) ("make" 
,gnu-make)))
scheme@(guile-user)> ,build (scheme-file "foo" #~(begin '#$packages))
building /gnu/store/lq9gvbilv0y2nph00zxk6bn3lvcgdxqq-foo.drv...
$7 = "/gnu/store/9ryh6v80jvjv3kwx0q782h26h9gbaclj-foo"
scheme@(guile-user)> (call-with-input-file $7 get-string-all)
$8 = "(begin (quote ((\"coreutils\" 
\"/gnu/store/mppp9hwxizx9g9pikwcvvshb2ffxyq7p-coreutils-9.1\") (\"make\" 
\"/gnu/store/9fadhs5qmwl5x7f669a0v39b3ryrmmf1-make-4.3\""
--8<---cut here---end--->8---

One of the design decisions for gexps was to ensure that substituting a
file-like object by its file name would be O(1) in most cases.

Substitution in lists as in the example above is supported, but
primarily for backward compatibility.  It should be avoided when
possible because it’s inefficient: ‘gexp->sexp’ needs to traverse the
whole list/tree in search of potential candidates.

Thanks,
Ludo’.

bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Cuirass commits 10a5117936bb51c54a362172b6e53ef5150ab909 and
> b8ee2486ce877e42a3f910610d3efa8274e2603f appear to fix issues when
> building in local build mode that most likely explain what you were
> observing.

If you run ‘guix pull’ now, you’ll get version 1.2.0-2.7bcd3d0 of the
‘cuirass’ package, which includes the fixes above.

I’m tentatively closing this issue but please do let me know if you
notice any problems.

Thanks,
Ludo’.

bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Simon Tournier  writes:
>
>> Hi Inria’s folks, :-)
>>
>> On Sat, 02 Dec 2023 at 18:13, Maxim Cournoyer  
>> wrote:
>>
>>> I'd rather we try it with a few more software such as 'dnf' to narrow it
>>> down to just 'yum', or some other issues in our Guix-generated RPM.
>>
>> have you tried with ’dnf’?  Is it similarly slow as ’yum’?
>
> I've tried it myself, and it was fast.  yum is an alias that invokes dnf
> even on an old obsolete Fedora 37 VM I had available.
>
> We could mention that other package managers than yum should be
> preferred in a "@quotation Note", due to a performance problem when
> handling modern RPMs as those made by Guix; or we could close this and
> wait for yum to have become completely irrelevant (which seems like in a
> year or so, last I checked the RHEL end-of-life dates).
>
> Is someone volunteering to add the note?  Or should we close this?

Yeah maybe let’s just a short note warning against old versions of ‘yum’
and close this issue.

Thanks for following up!

Ludo’.

bug#68378: Gawk 5.3.0 test suite fails non-deterministically

[Ludovic Courtès]

Hello,

Evaluation  of ‘core-updates’
(commit ec1ce76a3a604efdc329b482fb46fa03cd11e184) failed due to test
failures in /gnu/store/pjdg38adv5d8lad0kk7cga4dd57cpvb4-gawk-5.3.0.drv:

--8<---cut here---start->8---
--- time.ok 2023-06-14 22:13:40.0 +
+++ _time   2024-01-11 00:47:05.999386040 +
@@ -1,4 +1,4 @@
 gettimeofday - systime = 0
 sleep(1.3) = 0
-gettimeofday - systime = 0
+gettimeofday - systime = 1
  <>
make[3]: *** [Makefile:5696: diffout] Error 1
make[3]: Leaving directory '/tmp/guix-build-gawk-5.3.0.drv-0/gawk-5.3.0/test'
make[2]: *** [Makefile:2189: check] Error 1
--8<---cut here---end--->8---

However, the same derivation builds fine when I retry.

It would be nice to address that.

Ludo’.

bug#68333: Time bomb in icedtea/openjdk

[Ludovic Courtès]

Ludovic Courtès  skribis:

>>From 92561a776ad88eb73034948beedbe9e6be4077b4 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <92561a776ad88eb73034948beedbe9e6be4077b4.1704897216.git.l...@gnu.org>
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
> Date: Wed, 10 Jan 2024 15:27:47 +0100
> Subject: [PATCH] =?UTF-8?q?gnu:=20icedtea:=20Fix=20time=20bomb=20in=20?=
>  =?UTF-8?q?=E2=80=98GenerateCurrencyData.java=E2=80=99.?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Fixes <https://issues.guix.gnu.org/68333>.
>
> * gnu/packages/java.scm (icedtea-7)[drop]: Add optional ‘patches’
> parameter and honor it.
> [native-inputs]: Add patch for “jdk-drop”.
> (icedtea-8): Likewise.
> * gnu/packages/patches/jdk-currency-time-bomb.patch,
> gnu/packages/patches/jdk-currency-time-bomb2.patch: New files.
> * gnu/local.mk (dist_patch_DATA): Add them.
>
> Change-Id: I3b4cf562ce4bedb87ce0e7c289e431fbb0dbb6f8

Pushed as 5c0f77f4241c9beac0c82deae946bfdc70b49ff0.

Let’s hope there’s no similar time bomb elsewhere in the Java stack.

Thanks again,
Ludo’.

bug#68333: Time bomb in icedtea/openjdk

[Ludovic Courtès]

Hi,

Rostislav Svoboda  skribis:

> From 1e86e32825a5025b4ef439e7f678143416f622b5 Mon Sep 17 00:00:00 2001
> Message-ID: 
> <1e86e32825a5025b4ef439e7f678143416f622b5.1704815654.git.rostislav.svob...@gmail.com>
> From: Rostislav Svoboda 
> Date: Tue, 9 Jan 2024 14:08:02 +0100
> Subject: [PATCH] gnu: Fix time bomb preventing build of icedtea.
>
> Fixes .
>
> Fixes time bomb preventing build of icedtea by patching the java source code
> so that the java-RuntimeException is not thrown when 'more than 10 years ago'
> condition is true.
>
> * gnu/packages/java.scm (icedtea): Patch java source code so that the
> offending line is commented out.
>
> Change-Id: I4861ee2ffc5aaffb6a9244110d222ae64bfbdf94

Thanks for the quick investigation and patch!  I just realized that this
affects current ‘master’ so we’d rather fix it soon.

What do you think of the attached patch?  The difference is that it
patches code at its root (in the actual source tarball rather than after
it’s been copied), it does so for IcedTea 7 and 8, and there are patch
files that are slightly clearer than a substitution pattern.

It’s still building on my machine but if it works for everyone, I’d like
to push as soon as I got it built.

Ludo’.

>From 92561a776ad88eb73034948beedbe9e6be4077b4 Mon Sep 17 00:00:00 2001
Message-ID: <92561a776ad88eb73034948beedbe9e6be4077b4.1704897216.git.l...@gnu.org>
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Wed, 10 Jan 2024 15:27:47 +0100
Subject: [PATCH] =?UTF-8?q?gnu:=20icedtea:=20Fix=20time=20bomb=20in=20?=
 =?UTF-8?q?=E2=80=98GenerateCurrencyData.java=E2=80=99.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes .

* gnu/packages/java.scm (icedtea-7)[drop]: Add optional ‘patches’
parameter and honor it.
[native-inputs]: Add patch for “jdk-drop”.
(icedtea-8): Likewise.
* gnu/packages/patches/jdk-currency-time-bomb.patch,
gnu/packages/patches/jdk-currency-time-bomb2.patch: New files.
* gnu/local.mk (dist_patch_DATA): Add them.

Change-Id: I3b4cf562ce4bedb87ce0e7c289e431fbb0dbb6f8
---
 gnu/local.mk |  2 ++
 gnu/packages/java.scm| 16 ++--
 .../patches/jdk-currency-time-bomb.patch | 13 +
 .../patches/jdk-currency-time-bomb2.patch| 13 +
 4 files changed, 38 insertions(+), 6 deletions(-)
 create mode 100644 gnu/packages/patches/jdk-currency-time-bomb.patch
 create mode 100644 gnu/packages/patches/jdk-currency-time-bomb2.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 16a34065c6..22970932e9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1478,6 +1478,8 @@ dist_patch_DATA =		\
   %D%/packages/patches/java-xerces-build_dont_unzip.patch	\
   %D%/packages/patches/java-xerces-xjavac_taskdef.patch	\
   %D%/packages/patches/jbr-17-xcursor-no-dynamic.patch	\
+  %D%/packages/patches/jdk-currency-time-bomb.patch		\
+  %D%/packages/patches/jdk-currency-time-bomb2.patch		\
   %D%/packages/patches/jfsutils-add-sysmacros.patch		\
   %D%/packages/patches/jfsutils-gcc-compat.patch		\
   %D%/packages/patches/jfsutils-include-systypes.patch		\
diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index e2c2a041a9..ded73bc461 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -100,13 +100,14 @@ (define-module (gnu packages java)
 
 (define-public icedtea-7
   (let* ((version "2.6.13")
- (drop (lambda (name hash)
+ (drop (lambda* (name hash #:optional (patches '()))
  (origin
(method url-fetch)
(uri (string-append
  "http://icedtea.classpath.org/download/drops;
  "/icedtea7/" version "/" name ".tar.bz2"))
-   (sha256 (base32 hash))
+   (sha256 (base32 hash))
+   (patches patches)
 (package
   (name "icedtea")
   (version version)
@@ -614,7 +615,8 @@ (define-public icedtea-7
  "110j7jlz47x2gg6f7653x12mssan5kvj9l9h1m1c8c92drfxbqyk"))
  ("jdk-drop"
   ,(drop "jdk"
- "0d1mca38ksxvdskp9im3pp7fdijhj1n3lwq9w13r9s4v3qyskgdd"))
+ "0d1mca38ksxvdskp9im3pp7fdijhj1n3lwq9w13r9s4v3qyskgdd"
+ (search-patches "jdk-currency-time-bomb.patch")))
  ("langtools-drop"
   ,(drop "langtools"
  "0nq5236fzxn3p6x8cgncl56mzcmsj07q9gymysnws4c8byc6n0qj"))
@@ -687,13 +689,14 @@ (define-public icedtea-7
 
 (define-public icedtea-8
   (let* ((version "3.19.0")
- (drop (lambda (name hash)
+ (drop (lambda* (name hash #:optional (patches '()))
  (origin
(method url-fetch)
(uri (string-append
  "http://icedtea.classpath.org/download/drops;
  "/icedtea8/" version "/" name ".tar.xz"))
-  

bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

[Ludovic Courtès]

Hi Collin and Kjetil,

"Collin J. Doering"  skribis:

> After updating cuirass (details below), my cuirass instance no longer builds 
> anything! It continues to poll channels, run evaluations and queue builds, 
> but none of the builds ever run.
>
> Before: Cuirass 1.1.0-13.1341725 (guix checkout 
> c4cca9cb5d3e93ef146acb930a95da9d2da6fb06)
> After:  Cuirass 1.2.0-1.bdc1f9f (guix checkout 
> 25b83bd9e4ceb77f08c0caee3ecdc48263b53a46)

"Haugen, Kjetil"  skribis:

> I have the exact same issue when setting up cuirass on a foreign distro.

Cuirass commits 10a5117936bb51c54a362172b6e53ef5150ab909 and
b8ee2486ce877e42a3f910610d3efa8274e2603f appear to fix issues when
building in local build mode that most likely explain what you were
observing.

  https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/log

I’ll do some more testing before updating the ‘cuirass’ package in Guix,
but in the meantime you can test by running this from a Cuirass checkout
(assuming you’re on a distro other than Guix):

  guix package -f guix.scm

Or, if you’re on Guix System, you pull Cuirass as a channel and use its
package.

(Overall, the “--build-remote” build mechanism gets more attention
because that’s the scalable method to use as soon as you have a couple
of build machines.)

Thanks for reporting the issue!

Ludo’.

bug#68333: Time bomb in icedtea/openjdk

[Ludovic Courtès]

Hello!

Julien Lepiller  skribis:

> There seems to be a time bomb in icedtea@2 and openjdk@9. while
> building it:
>
> Error: time is more than 10 years from present: 138852720
> java.lang.RuntimeException: time is more than 10 years from present:
> 138852720 at
> build.tools.generatecurrencydata.GenerateCurrencyData.makeSpecialCaseEntry(GenerateCurrencyData.java:288)
> at
> build.tools.generatecurrencydata.GenerateCurrencyData.buildMainAndSpecialCaseTables(GenerateCurrencyData.java:227)
> at
> build.tools.generatecurrencydata.GenerateCurrencyData.main(GenerateCurrencyData.java:158)
>
> I managed to work around that by setting the date back, but we should
> investigate and fix it. icedtea@3 doesn't seem to be affected.

Confirmed:

  https://guix.bordeaux.inria.fr/build/432486/log

This is with Guix commit 7a7c8920aeddaf9ab8d68c572780bc34b404711b.

I couldn’t find ‘GenerateCurrencyData.java’ though, not sure where it
lives.

Ludo’.

bug#39885: Bioconductor URI, fallback and time-machine

[Ludovic Courtès]

Hi,

(Replying to a 1.5-year-old message…)

Ricardo Wurmus  skribis:

> I have finally taken the time to review this and implement a first draft
> of a change to the bioconductor importer and updater.
>
> There are some limitations:
>
> - we cannot use the updater to go from “url-fetch” to “git-fetch”.
>   That’s because “package-update” in (guix upstream) decides whether to
>   use package-update/url-fetch or package-update/git-fetch based on the
>   *current* package value’s origin fetch procedure.  For the switch we
>   can hack around this (adding an exception for bioconductor packages),
>   but there is no pretty way to do this in a generic fashion that could
>   be committed.
>
>   Perhaps we could operate on the url included in the 
>   instead of looking at the *current* package value.  We’re only
>   accessing “package” once in the url-fetch case, so maybe we can work
>   around this problem.

Alternatively, how about writing a custom one-shot tool to change the
‘source’ field of all the Bioconductor packages to ‘git-fetch’?

It may be easier than adjusting (guix upstream) to cater to this
probably unusual case.

> - the repositories at https://git.bioconductor.org/package/NAME do not
>   tag package versions.  The only method of organization is branches
>   that are named after *Bioconductor releases* (not package releases),
>   e.g. RELEASE_3_15.  We can only determine the package version by
>   reading its DESCRIPTION file or by looking up the version index for
>   all Bioconductor packages (we do that already).  This means that there
>   could be different commits for the same package version in the same
>   release branch — so we have to include the commit hash and a revision
>   counter in the version string.

OK, sounds acceptable.

> - the updater doesn’t work on version expressions like (git-version
>   "1.12" revision commit).  It expects to be able to replace literal
>   strings.  Because of that my changes let the importer generate a
>   string literal such as "1.12-0.cafebab" without a let-bound commit
>   string.

Maybe we can build upon Maxime’s patch at
?

> - “experiment” or “data” packages are not kept in Git.  They only exist
>   as volatile tarballs that will be overwritten.  Thankfully, they don’t
>   change all that often, so they have a good chance of making it into
>   our archives.
>
> - the above exception means that we need to litter the importer and
>   updater code with extra checks.
>
> With all these notes out of the way I’ll prepare a series of patches
> next.

I don’t think it happened but it’d still be nice.  :-)

Thanks,
Ludo’.

bug#39885: Bioconductor tarballs are not archived

[Ludovic Courtès]

Hi!

Simon Tournier  skribis:

>> I was wondering whether we’re now doing better for Bioconductor
>> tarballs.  The answer, based on small sample, seems to be “not quite”:

[...]

> but, now the past reads,
>
> $ for url in 
> https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz
>  \
>  
> https://bioconductor.org/packages/3.18/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz
>  ;  \
>   do guix download $url ;done

Thanks for investigating & explaining!

I my previous message, I wrote:

> As for past tarballs, #swh-devel comrades say we could send them a list
> of URLs and they’d create “Save Code Now” requests on our behalf (we
> cannot do it ourselves since the site doesn’t accept plain tarballs.)

Were you able to retrieve some of these?  What are the chances of
success?

> Hence the discussion we had: switch from url-fetch to git-fetch.
> However, after some investigations, it does not seem straightforward:
> The main issue being the almost automatic current updater.  See for
> details [2].

[...]

> https://issues.guix.gnu.org/msgid/878rnwuemq@elephly.net

Indeed, thanks for the link.  I agree that long-term moving to
‘git-fetch’ sounds preferable, but there are quite a few obstacles to
overcome.

Ludo’.

bug#64653: ‘static-networking’ fails to start

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> Evaluating user expression (catch #t (lambda () (load "/gnu/store/64?")) # ?).
> starting 
> '/gnu/store/gn8q7p790a9zdnlciyp1vlncpin366r0-hurd-v0.9.git20230216/hurd/pfinet
>  "--ipv6" "/servers/socket/26" "--interface" "/dev/eth0" "--address" 
> "10.0.2.15" "--netmask" "255.255.255.0" "--gateway" "10.0.2.2"'
> In ice-9/boot-9.scm:
> 142:2  7 (dynamic-wind # ?)
> In shepherd/support.scm:
>486:15  6 (_ #)
> In ice-9/read.scm:
>859:19  5 (read _)
> In unknown file:
>4 (port-filename #)
> In ice-9/boot-9.scm:
>   1685:16  3 (raise-exception _ #:continuable? _)
>   1780:13  2 (_ #< components: (#<?>)
> In ice-9/eval.scm:
> 159:9  1 (_ #(#(#) (# "port-fil?" ?)))
> In unknown file:
>0 (make-stack #t)
> #t
>
> So it’s indeed ‘read’ as called from ‘primitive-load*’ that stumbles
> upon a closed port.

Good news: this is fixed by 4e431fda5f2ec76b6d6a271be7c30b1324431329!
Silly me had introduced a ‘dynamic-wind’ there.

(The funny thing with extensible systems like the Shepherd is that the
problem can be anywhere.  :-))

Ludo’.

bug#64653: ‘static-networking’ fails to start

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> [  121.282538] shepherd[1]: Service user-homes started.
> [  121.368316] ipmi_si IPI0001:00: Using irq 10
> [  121.405790] ipmi_si IPI0001:00: IPMI message handler: Found new BMC 
> (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20)
> [  121.419871] shepherd[1]: Exception caught while starting #< 
> 7f19889012a0>: (wrong-type-arg "port-filename" "Wrong type argument in 
> position ~A: ~S" (1 #) (# 7f1981887000>))
> [  121.420074] shepherd[1]: Service user-homes running with value #t.
> [  121.420218] shepherd[1]: Service networking failed to start.

I’m seeing a similar exception in a Hurd VM running shepherd 0.10.3rc1:

--8<---cut here---start->8---
Jan  3 23:13:22 localhost shepherd[1]: Exception caught while starting 
networking: (wrong-type-arg "port-filename" "Wrong type argument in position 
~A: ~S" (1 #) (#)) 
Jan  3 23:13:22 localhost shepherd[1]: Service networking failed to start. 
--8<---cut here---end--->8---

It’s interesting because it suggests that the offending ‘port-filename’
call comes from ‘load’, not from the network-setup code being loaded
(here, the /hurd/pfinet translator has been properly set up).

Looking at the code in ‘boot-9.scm’, I *think* we end up calling
‘primitive-load’; ‘shepherd’ replaces it with its own (@ (shepherd
support) primitive-load*).

I managed to grab this backtrace:

--8<---cut here---start->8---
Evaluating user expression (catch #t (lambda () (load "/gnu/store/64?")) # ?).
starting 
'/gnu/store/gn8q7p790a9zdnlciyp1vlncpin366r0-hurd-v0.9.git20230216/hurd/pfinet 
"--ipv6" "/servers/socket/26" "--interface" "/dev/eth0" "--address" "10.0.2.15" 
"--netmask" "255.255.255.0" "--gateway" "10.0.2.2"'
In ice-9/boot-9.scm:
142:2  7 (dynamic-wind # ?)
In shepherd/support.scm:
   486:15  6 (_ #)
In ice-9/read.scm:
   859:19  5 (read _)
In unknown file:
   4 (port-filename #)
In ice-9/boot-9.scm:
  1685:16  3 (raise-exception _ #:continuable? _)
  1780:13  2 (_ #< components: (#<?>)
In ice-9/eval.scm:
159:9  1 (_ #(#(#) (# "port-fil?" ?)))
In unknown file:
   0 (make-stack #t)
#t
--8<---cut here---end--->8---

So it’s indeed ‘read’ as called from ‘primitive-load*’ that stumbles
upon a closed port.  It also happens when loading a file that simply
suspends the current fiber via ‘sleep’ or similar, but only on the Hurd
though.

To be continued…

Ludo’.

bug#67988: [Cuirass] ‘request-work’ responses received by several workers

[Ludovic Courtès]

Hello,

I’m under the impression that sometimes, when the server replies to
‘worker-request-work’ messages, its reply is received by more than just
the target worker, leading to builds being performed twice:

--8<---cut here---start->8---
ludo@berlin ~$ sudo grep lyhz5d1jb396m32dy0fs9h8vqzw95ddp 
/var/log/cuirass-remote-server.log
2023-12-23 00:15:29 141.80.167.184 (0LFowqzr): build started: 
'/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv'.
2023-12-23 00:18:41 fetching 1 outputs of 
'/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv' from 
http://141.80.167.184:5558
2023-12-23 00:18:45 build succeeded: 
'/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv'
2023-12-23 00:21:20 141.80.167.159 (oNzYXCv5): build started: 
'/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv'.
2023-12-23 00:24:31 fetching 1 outputs of 
'/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv' from 
http://141.80.167.159:5558
2023-12-23 00:24:32 build succeeded: 
'/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv'
ludo@berlin ~$ sudo ssh root@141.80.167.184 grep 
lyhz5d1jb396m32dy0fs9h8vqzw95ddp /var/log/cuirass-remote-worker.log
2023-12-23 00:12:32 0LFowqzr: building derivation 
`/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv' (system: 
x86_64-linux)
2023-12-23 00:12:54 0LFowqzr: derivation 
/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv build succeeded.
ludo@berlin ~$ sudo ssh root@141.80.167.159 grep 
lyhz5d1jb396m32dy0fs9h8vqzw95ddp /var/log/cuirass-remote-worker.log
2023-12-23 00:17:51 oNzYXCv5: building derivation 
`/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv' (system: 
x86_64-linux)
2023-12-23 00:18:17 oNzYXCv5: derivation 
/gnu/store/lyhz5d1jb396m32dy0fs9h8vqzw95ddp-cdrdao-1.2.5.drv build succeeded.
--8<---cut here---end--->8---

This is with Cuirass 1.2.0-1.bdc1f9f.

To be continued…

Ludo’.

bug#39885: Bioconductor URI, fallback and time-machine

[Ludovic Courtès]

zimoun  skribis:

> $ guix time-machine --commit=77e2de365497bf4c8b81cbd78624f78293490485 \
>-- build r-biocneighbors -S

[...]

> Trying to use Disarchive to assemble 
> /gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz...
> could not find its Disarchive specification
> failed to download 
> "/gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz" from 
> ("https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.4.1.tar.gz;
>  
> "https://bioconductor.org/packages/3.10/bioc/src/contrib/Archive/BiocNeighbors_1.4.1.tar.gz;)
> builder for 
> `/gnu/store/q9ggmh5a9bzmnr49p10x1w9sv6pzjarv-BiocNeighbors_1.4.1.tar.gz.drv' 
> failed to produce output path 
> `/gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz'

In hindsight this is not surprising: this is a Dec. 2019 commit and I
set up ,
disarchive.guix.gnu.org, and related machinery in Sep/Oct 2021.

Of course Timothy set up  earlier, but not
so much—Timothy started work on Disarchive ca. July 2020:
.

(Not that it helps but at least it’s a relief to know that this
particular problem predates our more serious efforts.)

Ludo’.

bug#39885: Bioconductor tarballs are not archived

[Ludovic Courtès]

Hello!

zimoun  skribis:

> Since 2020, I provided several examples of breakage with bug#39885 [1].
> Here another one:
>
> $ guix time-machine --commit=77e2de365497bf4c8b81cbd78624f78293490485 \
>-- build r-biocneighbors -S

[...]

> Starting download of 
> /gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz
>>From 
>>https://web.archive.org/web/20220718175152/https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.4.1.tar.gz...
> download failed 
> "https://web.archive.org/web/20220718175152/https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.4.1.tar.gz;
>  404 "NOT FOUND"
> Trying to use Disarchive to assemble 
> /gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz...
> could not find its Disarchive specification
> failed to download 
> "/gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz" from 
> ("https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.4.1.tar.gz;
>  
> "https://bioconductor.org/packages/3.10/bioc/src/contrib/Archive/BiocNeighbors_1.4.1.tar.gz;)
> builder for 
> `/gnu/store/q9ggmh5a9bzmnr49p10x1w9sv6pzjarv-BiocNeighbors_1.4.1.tar.gz.drv' 
> failed to produce output path 
> `/gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz'
> build of 
> /gnu/store/q9ggmh5a9bzmnr49p10x1w9sv6pzjarv-BiocNeighbors_1.4.1.tar.gz.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/q9/ggmh5a9bzmnr49p10x1w9sv6pzjarv-BiocNeighbors_1.4.1.tar.gz.drv.gz'.
> guix build: error: build of 
> `/gnu/store/q9ggmh5a9bzmnr49p10x1w9sv6pzjarv-BiocNeighbors_1.4.1.tar.gz.drv' 
> failed
>
> Well, several comments:
>
>  1. Berlin or Bordeaux do not have it as substitutes,
>  2. Diasarchive does not have it,
>  3. Many others neither.

I was wondering whether we’re now doing better for Bioconductor
tarballs.  The answer, based on small sample, seems to be “not quite”:

--8<---cut here---start->8---
$ guix lint -c archival $(guix package -A ^r-bioc | cut -f1)
gnu/packages/bioconductor.scm:19708:12: r-biocbaseutils@1.4.0: Disarchive entry 
refers to non-existent SWH directory '726af85395d163b5a21e52e4df1bf18aa0072f6b'
gnu/packages/bioconductor.scm:19752:12: r-bioccheck@1.38.0: Disarchive entry 
refers to non-existent SWH directory '12cfedcbc27005a3fb7e01c5c4b727e0116f596f'
gnu/packages/bioconductor.scm:16892:5: r-biocfilecache@2.10.1: Disarchive entry 
refers to non-existent SWH directory '6a2d6d909a7cedd56e96f5a98770dee8d220'
gnu/packages/bioconductor.scm:4540:12: r-biocgenerics@0.48.1: Disarchive entry 
refers to non-existent SWH directory '6f19ea14f46dbc75909b77bc08e9023daae6fb9e'
gnu/packages/bioconductor.scm:19785:5: r-biocgraph@1.64.0: Disarchive entry 
refers to non-existent SWH directory '977ff052b4e6c948af7af0fc14ae61f71427cb1a'
gnu/packages/bioconductor.scm:21524:6: r-biocio@1.12.0: Disarchive entry refers 
to non-existent SWH directory '29d8fef9a5b386384f20513c612f1e34f6118532'
gnu/packages/bioconductor.scm:13090:5: r-biocneighbors@1.20.0: Disarchive entry 
refers to non-existent SWH directory '6d3728b2dee78cceecdeba0318f3e57b6013d96f'
gnu/packages/bioconductor.scm:19957:5: r-bioconcotk@1.22.0: Disarchive entry 
refers to non-existent SWH directory '251081d4bc3f061ef8e16338eb042ad4c71ed02d'
gnu/packages/bioconductor.scm:20003:5: r-biocor@1.26.0: Disarchive entry refers 
to non-existent SWH directory '0cc9d3dcde06fb353cdd77f3b538845d16a77720'
gnu/packages/bioconductor.scm:6613:12: r-biocparallel@1.36.0: Disarchive entry 
refers to non-existent SWH directory '41e09414898f61655bcc99fdd44d69b0531c0b2d'
gnu/packages/bioconductor.scm:20030:5: r-biocpkgtools@1.20.0: Disarchive entry 
refers to non-existent SWH directory '55de8618648ed16797a8effd5b508c652a5d7cbe'
gnu/packages/bioconductor.scm:20144:5: r-biocset@1.16.0: Disarchive entry 
refers to non-existent SWH directory '1cfa6cac0cb453f2882a35c8f5ae6ddfa713ad2d'
gnu/packages/bioconductor.scm:13276:5: r-biocsingular@1.18.0: Disarchive entry 
refers to non-existent SWH directory '992d3f9d48633fa5d46b9a7640a825054e9538aa'
gnu/packages/bioconductor.scm:19806:12: r-biocstyle@2.30.0: Disarchive entry 
refers to non-existent SWH directory 'bb17c3bd9ac7c373b24782fcfecdde5fa2f0a965'
gnu/packages/bioconductor.scm:22965:5: r-biocthis@1.12.0: Disarchive entry 
refers to non-existent SWH directory '3d08f77aae1e81ce9ca9bb9ae2adf4d4c7421d11'
gnu/packages/bioconductor.scm:4521:5: r-biocversion@3.18.1: source not archived 
on Software Heritage and missing from the Disarchive database
gnu/packages/bioconductor.scm:19830:12: r-biocviews@1.70.0: Disarchive entry 
refers to non-existent SWH directory '47e0877ab988469fc09a37505dd769f9626cac2e'
gnu/packages/bioconductor.scm:20182:5: r-biocworkflowtools@1.28.0: Disarchive 
entry refers to non-existent SWH directory 
'393f3472cc27f632caea3488aef93a7675b403ef'
$ guix describe
Generation 285  Dec 17 2023 23:31:56(current)
  guix 6ab2426
repository URL: 

bug#65419: [Shepherd] Non-responding service control fiber

[Ludovic Courtès]

Hello,

Attila Lendvai  skribis:

> i think i have found the root cause of this, as documented here: 
> https://issues.guix.gnu.org/67839
>
> that issue contains patches for shepherd to reproduce it in its test suite.

Yes, it looks like this long-standing and hard-to-debug issue may well
be fixed now, thumbs up Attila!!

We have accumulated quite a few fixes by now so I think I’ll release
0.10.3 hopefully in 2023 and otherwise soon after.

Thanks,
Ludo’.

bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> Fixes <https://issues.guix.gnu.org/30948>.
>
> * guix/build/gnu-build-system.scm (separate-from-pid1): New procedure.
> (%standard-phases): Add it.
> * guix/build-system/gnu.scm (gnu-build): Add #:separate-from-pid1? and
> honor it.
> (gnu-cross-build): Likewise.
>
> Reported-by: Carlo Zancanaro 
> Change-Id: I6f3bc8d8186d1a571f983a38d5e3fd178ffa2678

I pushed this change in ‘core-updates’ as
7ebe4b72727632561ddbf8bb0c58527929682989 (together with other
world-rebuild changes.)

I’m closing this bug but please do re-open if you think the issue needs
further work.

Thanks,
Ludo’.

bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.

[Ludovic Courtès]

Hey Maxim,

Maxim Cournoyer  skribis:

> I haven't yet looked at the code, but looking at the bigger picture,
> wouldn't it be a useful behavior to have for Guile itself?  Perhaps not,
> as there already exists a Guile init manager (GNU Shepherd), but if it's
> something relatively simple/compact to implement, perhaps it could find
> its place in Guile itself, just like Bash implements correctly signal
> handling when used as a PID 1 (if I'm not mistaken).

Bash is a shell whereas Guile is a programming language, and to me that
makes a big difference: we want to be able to implement init systems in
Guile just like we implement them in C, and that means we need full
control over what to do when running as PID 1.  That’s why I wouldn’t do
anything special in Guile itself (nor in libc).

The patch I submitted fixes our immediate problem with build processes,
so I’d like to have it in ‘core-updates’.

Hopeful as I am, I see us merging ‘core-updates’ in the first half of
January.  Ambition!  :-)

Ludo’.

bug#67802: Shepherd is not able to run simple networked programs as services

[Ludovic Courtès]

Hi,

Lars Rustand  skribis:

> So, I figured this out. It had nothing to do with networking even though
> it looked like it. The problem was that I had cargo cult-copied a
> #:pid-file parameter from another service, believing that this was just
> a path were Shepherd could create a pid-file for the service, but
> Shepherd was in fact expecting the program to create the pid-file. So
> when the program did not create this pid-file then Shepherd killed the
> program.
>
> So the original bug I reported is in fact not a bug at all and can be
> closed. However, the error handling in Shepherd could be improved in
> order to make it more clear what is happening.

Good that you found the issue!  I improved logging for this particular
case as a result of this report:

  
https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=ace4a3b2dba43b826640d5c1ca970f9040d27416

Thanks for reporting it,
Ludo’.

bug#67839: shepherd: sometimes hangs on `guix system reconfigure`

[Ludovic Courtès]

Hi Attila,

Attila Lendvai  skribis:

> * modules/shepherd.scm (main): Switch with-service-registry and
> with-process-monitor.  This way the parameterize of the process monitor covers
> everything else.  This fixes the bug that caused `guix system reconfigure` to
> hang in certain situations.  Fix proposed by @emixa-d at:
> https://github.com/wingo/fibers/issues/29#issuecomment-1858922276.

[...]

> * modules/shepherd/service.scm (spawn-service-controller): Add two asserts.
> This is the bug that causes `guix system reconfigure ...` to sometimes hang,
> and subsequently all shepherd commands, because a match-error flies out from
> the service-controller of a replaced service, and thus its fiber dies.  These
> asserts get triggered without the previous commit that fixes the issue.

Good catch!!

I pushed these patches with small edits, in particular adding a test
that reproduces the bug without relying on assertion failures:

  5dbde1c support: ‘assert’ logs source location information.
  0bcf02a Update NEWS.
  c07f0a8 service: Add asserts to ensure a process monitor is running.
  9be0b7e shepherd: Make sure ‘with-process-monitor’ covers everything needed.

Thanks for the tedious but fruitful debugging work!

Ludo’.

bug#30948: [PATCH core-updates] build-system/gnu: Turn PID 1 into an “init”-style process by default.

[Ludovic Courtès]

Fixes .

* guix/build/gnu-build-system.scm (separate-from-pid1): New procedure.
(%standard-phases): Add it.
* guix/build-system/gnu.scm (gnu-build): Add #:separate-from-pid1? and
honor it.
(gnu-cross-build): Likewise.

Reported-by: Carlo Zancanaro 
Change-Id: I6f3bc8d8186d1a571f983a38d5e3fd178ffa2678
---
 guix/build-system/gnu.scm   |  4 
 guix/build/gnu-build-system.scm | 39 -
 2 files changed, 42 insertions(+), 1 deletion(-)

Hi!

This is a second attempt I’m currently testing as part of an
initially unrelated ‘core-updates’ series:

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

The principle is simple: if the build process runs as PID 1, fork
so that PID 1 does nothing but call ‘waitpid’ in a loop while the
actual build process runs as PID 2.

This is simple and robust.  The code is written in a defensive way
as an extra phase that can be disabled.

Thoughts?

Ludo’.

diff --git a/guix/build-system/gnu.scm b/guix/build-system/gnu.scm
index 0f886fe21d..6a89bcc0d8 100644
--- a/guix/build-system/gnu.scm
+++ b/guix/build-system/gnu.scm
@@ -362,6 +362,7 @@ (define* (gnu-build name inputs
 (license-file-regexp %license-file-regexp)
 (phases '%standard-phases)
 (locale "C.UTF-8")
+(separate-from-pid1? #t)
 (system (%current-system))
 (build (nix-system->gnu-triplet system))
 (imported-modules %default-gnu-imported-modules)
@@ -404,6 +405,7 @@ (define* (gnu-build name inputs
   (sexp->gexp phases)
   phases)
#:locale #$locale
+   #:separate-from-pid1? #$separate-from-pid1?
#:bootstrap-scripts #$bootstrap-scripts
#:configure-flags #$(if (pair? configure-flags)
(sexp->gexp configure-flags)
@@ -502,6 +504,7 @@ (define* (gnu-cross-build name
   (license-file-regexp %license-file-regexp)
   (phases '%standard-phases)
   (locale "C.UTF-8")
+  (separate-from-pid1? #t)
   (system (%current-system))
   (build (nix-system->gnu-triplet system))
   (imported-modules %default-gnu-imported-modules)
@@ -547,6 +550,7 @@ (define* (gnu-cross-build name
   (sexp->gexp phases)
   phases)
#:locale #$locale
+   #:separate-from-pid1? #$separate-from-pid1?
#:bootstrap-scripts #$bootstrap-scripts
#:configure-flags #$configure-flags
#:make-flags #$make-flags
diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index 39707e7ace..51b8f9acbf 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -72,6 +72,42 @@ (define (first-subdirectory directory)
 ((first . _) first)
 (_ #f)))
 
+(define* (separate-from-pid1 #:key (separate-from-pid1? #t)
+ #:allow-other-keys)
+  "When running as PID 1 and SEPARATE-FROM-PID1? is true, run build phases as
+a child process; PID 1 then becomes responsible for reaping child processes."
+  (if separate-from-pid1?
+  (if (= 1 (getpid))
+  (dynamic-wind
+(const #t)
+(lambda ()
+  (match (primitive-fork)
+(0 #t)
+(builder-pid
+ (format (current-error-port)
+ "build process now running as PID ~a~%"
+ builder-pid)
+ (let loop ()
+   ;; Running as PID 1 so take responsibility for reaping
+   ;; child processes.
+   (match (waitpid WAIT_ANY)
+ ((pid . status)
+  (if (= pid builder-pid)
+  (if (zero? status)
+  (primitive-exit 0)
+  (begin
+(format (current-error-port)
+"build process ~a exited with status 
~a~%"
+pid status)
+(primitive-exit 1)))
+  (loop
+(const #t))
+  (format (current-error-port) "not running as PID 1 (PID: ~a)~%"
+  (getpid)))
+  (format (current-error-port)
+  "build process running as PID ~a; not forking~%"
+  (getpid
+
 (define* (set-paths #:key target inputs native-inputs
 (search-paths '()) (native-search-paths '())
 #:allow-other-keys)

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Ludovic Courtès]

Hi,

Nils Landt  skribis:

>> Ludovic Courtès  hat am 06.12.2023 23:58 CET geschrieben:
>> 
>>  
>> Hi,
>> 
>> Nils Landt  skribis:
>> 
>> > I use guix home for almost everything, but I have installed glibc-locales 
>> > in my "regular" guix (just by running guix package install glibc-locales).
>> > Now, running guix package --upgrade fails with:
>> > guix package: error: package glibc-locales@2.37 does not support 
>> > x86_64-linux
>> 
>> Fixed with 4a6cef9d66ff26e96d63f2f1f886b8212154ca00.
>> 
>> The problem was that glibc-locales@2.37 is marked as supported for
>> i586-gnu only (that’s GNU/Hurd).
>
> Thank you for the quick fix! 
> But isn't the the real bug that guix package (--install, --upgrade) consider 
> an unsupported package as the version to install / upgrade to? Expected 
> behaviour for me would be that it checks for the newest version that can 
> actually be installed on the architecture.

Yes, you’re right, we should fix this.

Thanks,
Ludo’.

bug#67532: “make check” requires network

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> Running ’make check’ without network leads to errors, for instance.

[...]

> $ cat tests/derivations.log
> substitute: guix substitute: warning: ACL for archive imports seems to be 
> uninitialized, substitutes may be unavailable
> substitute: guix substitute: warning: authentication and authorization of 
> substitutes disabled!
> building path(s) 
> `/home/simon/src/guix/guix/test-tmp/store/qkg9bx9adcv98n9z40dvw68mip3vg1dg-bash'
>
> Starting download of 
> /home/simon/src/guix/guix/test-tmp/store/qkg9bx9adcv98n9z40dvw68mip3vg1dg-bash
>>From 
>>https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/i686-linux/bash?id=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e...
> In procedure getaddrinfo: Name or service not known

I had come to forget about that because for the ‘guix’ package
(obviously built in a network-less environment), we “pre-seed” the store
with the 4 or 5 files needed to run the test suite.

So I propose:

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 0833b5d32c..0072e5d42d 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -76,13 +76,13 @@ Building from Git
 hack on Guix:
 
 @example
-guix shell -D guix -CPW
+guix shell -D guix -CPWN
 @end example
 
 or even, from within a Git worktree for Guix:
 
 @example
-guix shell -CPW
+guix shell -CPWN
 @end example
 
 If @option{-C} (short for @option{--container}) is not supported on your

(And not going back to ‘--pure’ because as we know it depends too much
of the goodwill of the user’s shell.)

WDYT?

Ludo’.

bug#67044: [bug#67686] bug#67044: C.utf8 locale cannot be built

[Ludovic Courtès]

Hi Tomas,

Tomas Volf <~@wolfsden.cz> skribis:

>> (glibc-2.35)[arguments]: Delete ‘install-utf8-c-locale’ phase.
>
> I do think 2.35 should install the locale as well.  That would require to 
> change
>
> (invoke (string-append bin "/localedef")
> "--no-archive" "--prefix" locale
> "-i" "C" "-f" "UTF-8"
> (string-append locale "/C.UTF-8")
>
> into
>
> (invoke (string-append bin "/localedef")
> "-c" "--no-archive" "--prefix" locale
> "-i" "C" "-f" "UTF-8"
> (string-append locale "/C.UTF-8")
>
> however I think that is fine.  I am using locale built like that and it works
> well.  What is more, from the discussion under the other issue[0], that is
> exactly what is done during normal glibc build:
>
>> It turns out we ignore errors during the glibc build (--quiet -c).
>
> After that the drop of 'install-utf8-c-locale can be moved into some other
> version < 2.35.

I’m a bit wary of using ‘-c’ (aka. ‘--force’) unconditionally as this
could hide real problems.

But more importantly, I think it won’t matter whether glibc 2.35 ships
C.UTF-8 since it’s no longer going to be used, except for building old
locale data via ‘locale-libcs’.

> 2.
>
> I still believe it makes sense to add the -c also into the locale builder,
> because my understanding is that this change will not allow using (locale
> "C.utf8") in the operating-system definition (since that would still try to
> build it, and fail).
>
> If you are not opposed to the idea, I can send a patch if you would prefer not
> to do it yourself.

No you’re right, we could add ‘-c’ to the code in (gnu system locale),
though perhaps it would be safer to do so only in the 2.35 + C.UTF-8
case.

(We can do that independently of this patch.)

> 3.
>
>> I suspect libc builds an additional ‘localedef’ for the build machine but I’m
>> not sure where it is, hmm…
>
> I looked around a bit, and I am not sure that is true.

In the meantime I found that this is wrong indeed:

  https://issues.guix.gnu.org/67686#11

Thanks for your feedback!

Ludo’.

bug#67714: “guix build racket” different from “guix shell racket”

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> Using Guix aabfddb (Oct 2023),
>
> $ guix build racket-minimal --no-grafts -d
> /gnu/store/hcdvhp36c51f6854mzggacsylkks24jj-racket-minimal-8.10.drv
>
> $ guix shell racket-minimal --no-grafts --dry-run
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> The following derivations would be built:
>   /gnu/store/vy5y76f25ni3kxjfa8x6c3rjgvrvach1-profile.drv
>   /gnu/store/jxbm1inf8mj7fvs8z9xxxcrlqv9i1hs7-racket-minimal-8.10.drv
>
>
> Well, the derivations are not the same and their output neither.
>
> $ guix build 
> /gnu/store/hcdvhp36c51f6854mzggacsylkks24jj-racket-minimal-8.10.drv
> /gnu/store/rvvyiy90dh2dpwn52r84xx4rsvvijz8q-racket-minimal-8.10
>
> $ guix build 
> /gnu/store/jxbm1inf8mj7fvs8z9xxxcrlqv9i1hs7-racket-minimal-8.10.drv
> /gnu/store/f2vky2mswm2h7w3jjiw7s28d25kzbmrl-racket-minimal-8.10

This is likely , fixed on Oct. 27th
with commit 67effc1560fc175dfbcb58ef5b965b08b3942d6c.

I guess we can close if it’s not reproducible now?

Thanks,
Ludo’.

bug#67708: ‘guix system reconfigure’ crashes upon host name resolution failure

[Ludovic Courtès]

On a system where DNS resolution is failing, I get:

--8<---cut here---start->8---
~# guix system reconfigure /etc/config.scm
Backtrace:
In ice-9/boot-9.scm:
  1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   661:37 18 (thunk)
   1300:8 17 (call-with-build-handler # …)
  2170:25 16 (run-with-store # …)
In guix/scripts/system.scm:
  1305:15 15 (_ _)
835:5 14 (perform-action reconfigure #< name: #f format:…> …)
In guix/scripts/system/reconfigure.scm:
344:3 13 (check-forward-update _ #:current-channels _)
In srfi/srfi-1.scm:
   691:23 12 (filter-map # . #)
In guix/scripts/system/reconfigure.scm:
   351:39 11 (_ #< name: guix url: "/home/ludo/src/guix/+ve…>)
In guix/git.scm:
   475:29 10 (update-cached-checkout "https://git.savannah.gnu.org/…; …)
376:2  9 (_ git-error #< code: -1 message: "failed to…>)
In guix/utils.scm:
954:8  8 (call-with-temporary-directory #)
In guix/git.scm:
   378:10  7 (_ "/tmp/guix-directory.DF11Ls")
In guix/swh.scm:
425:0  6 (swh-download "https://git.savannah.gnu.org/git/guix.g…; …)
   255:22  5 (call "https://archive.softwareheritage.org/api/1/revi…; …)
In web/client.scm:
   476:29  4 (http-request "https://archive.softwareheritage.org/ap…; …)
   332:10  3 (open-socket-for-uri _ #:verify-certificate? _)
In unknown file:
   2 (getaddrinfo "archive.softwareheritage.org" "https" 0 # …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure getaddrinfo: Nom ou service inconnu
# guix describe
  guix 8e2f32c
URL du dépôt : https://git.savannah.gnu.org/git/guix.git
branche : master
commit : 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714
--8<---cut here---end--->8---

Not pretty.

Ludo’.

bug#67707: Fresh installation leaks details about ISO build environment

[Ludovic Courtès]

On a fresh installation of 1.4.0, we get:

--8<---cut here---start->8---
# guix system describe
Génération 108 déc. 2023 10:39:47   (actuelle)
  nom de fichier : /var/guix/profiles/system-1-link
  nom de fichier canonique : /gnu/store/d8g35zgpcg0k42jlxi3pda59nx3cgmhl-system
  étiquette : GNU with Linux-Libre 6.0.10
  chargeur de démarrage : grub
  périphérique racine : UUID : d17c4651-b142-4802-9d70-b018ee72c58e
  noyau : /gnu/store/3qdad0k7wvwl09wah246q7fvsb1hbr0x-linux-libre-6.0.10/bzImage
  canaux :
guix:
  URL du dépôt : /home/ludo/src/guix/+version-1.4.0/
  branche : version-1.4.0
  commit : 989a3916dc8967bcb7275f10452f89bc6c3389cc
  fichier de configuration : 
/gnu/store/ram19r21j1rp0pfkdadmi3a6jp24fy36-configuration.scm
--8<---cut here---end--->8---

Oops!

That the URL is wrong doesn’t have any impact because it’s not used by
‘guix pull’ or anything, but it’s obviously not great.

Ludo’.

bug#67044: C.utf8 locale cannot be built

[Ludovic Courtès]

Hello!

Tomas Volf <~@wolfsden.cz> skribis:

> On 2023-11-27 23:02:26 +0100, Ludovic Courtès wrote:

[...]

>> Now, it would also be nice if C.utf8 were built-in, shipped with the
>> ‘glibc’ package we have (to me that’s the whole point of C.utf8).  We
>> should fix that now in ‘core-updates’.  Ideas on how to do that?
>
> After short research, I do have an idea.  My knowledge of Guix's internals is
> not good enough (yet? :)) to implement it though.  And I am not even sure it
> should be done.  Anyway here it goes:
>
> 1. Add a phase after 'install that builds and installs the C.utf8 locale, as
> documented here[0].
> 2. Make glibc package add the directory into GUIX_LOCPATH.  Since it accepts :
> separated directories, it should be possible, however I am unsure how.

I decided to give it a go:

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

Please do chime in and let me know what you think!

Ludo’.

bug#67685: ‘guix shell --export-manifest’ ignores transformations for ‘-D’ packages

[Ludovic Courtès]

Hello!

‘--export-manifest’ does not apply transformations to packages preceded
by ‘-D’ (development environment):

--8<---cut here---start->8---
$ guix shell -D guile-git --with-branch=libgit2=main --export-manifest
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.
(package->development-manifest
  (specification->package "guile-git"))

$ guix shell guile-git --with-branch=libgit2=main --export-manifest
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(use-modules (guix transformations))

(define transform1
  (options->transformation
'((with-branch . "libgit2=main"

(packages->manifest
  (list (transform1 (specification->package "guile-git"

$ guix describe
Generation 283  Dec 04 2023 00:32:23(current)
  guix 6e2dd51
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 6e2dd51df5f3f51e9056dd4f2e1b036195ab3caa
--8<---cut here---end--->8---

Ludo’.

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Ludovic Courtès]

Hi,

Nils Landt  skribis:

> I use guix home for almost everything, but I have installed glibc-locales in 
> my "regular" guix (just by running guix package install glibc-locales).
> Now, running guix package --upgrade fails with:
> guix package: error: package glibc-locales@2.37 does not support x86_64-linux

Fixed with 4a6cef9d66ff26e96d63f2f1f886b8212154ca00.

The problem was that glibc-locales@2.37 is marked as supported for
i586-gnu only (that’s GNU/Hurd).

The workaround on GNU/Linux would have been to run:

  guix install glibc-locales@2.35

but of course, hard to guess given the error message.

Thanks,
Ludo’.

bug#67575: guix-daemon assertion failure upon substitution failure

[Ludovic Courtès]

Ludovic Courtès  skribis:

> 2023-11-27 07:00:58 accepted connection from pid 14007, user root
> 2023-11-27 07:01:20 guix-daemon: nix/libstore/build.cc:3322: void 
> nix::Worker::childTerminated(pid_t, bool): Assertion `i != children.end()' 
> failed.
>
>
> The corresponding build log (sent by ‘cuirass remote-worker’ to the
> server):
>
> $ zcat /var/cache/cuirass/remote/rivlxrqr10g3kj9knyz7i41aq1vzxn9z.log.gz |tail
> @ substituter-started 
> /gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz substitute
> guix substitute: warning: while fetching 
> https://ci.guix.gnu.org/nar/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz:
>  server is somewhat slow
> guix substitute: warning: try `--no-substitutes' if the problem persists
> retrying download of 
> '/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz' with 
> other substitute URLs...
> guix substitute: warning: while fetching 
> https://ci.guix.gnu.org/nar/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz:
>  server is somewhat slow
> guix substitute: warning: try `--no-substitutes' if the problem persists
> guix substitute: error: failed to find alternative substitute for 
> '/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz'
> fetching path 
> `/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz' (empty 
> status: '')

This should be fixed by 06b9c1260c72935806957bf302c40c1db6101a63.

Ludo’.

bug#66537: [bug#67366] [PATCH] doc: Recommend building in ‘guix shell -CPW’.

[Ludovic Courtès]

Ludovic Courtès  skribis:

> This was prompted by <https://issues.guix.gnu.org/66537>, where someone
> tried to build Guix within ‘guix shell --pure’ on a foreign distro and
> found that ./configure would pick software from the host system.
>
> Suggested by Hiep Pham .
>
> * doc/contributing.texi (Building from Git): Recommend ‘guix shell -CPW’.
>
> Change-Id: I7694b482d982917fef6ec404f68ddacea761f482

Pushed as 01361d46b8e0481ad56665d7a06c276b08f59c6d.

Ludo'.

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

[Ludovic Courtès]

The ‘cuirass remote-server’ process goes awry when misbehaved clients
connect; specifically, some of its fibers crash, leaving it running but
inactive:

--8<---cut here---start->8---
2023-12-04 10:13:14 periodic update: 0 resumable, 0 failed builds
2023-12-04 10:13:28 error: Connection reset by peer when replying to 
xx.xx.xx.254.
2023-12-04 10:13:42 error: invalid log received from xx.xx.xx.254
2023-12-04 10:13:42 error: EOF while receiving log from xx.xx.xx.254
2023-12-04 10:13:48 Uncaught exception in task:
2023-12-04 10:13:48 In fibers.scm:
2023-12-04 10:13:48186:20  8 (_)
2023-12-04 10:13:48145:21  7 (_)
2023-12-04 10:13:48 In ice-9/boot-9.scm:
2023-12-04 10:13:48   1752:10  6 (with-exception-handler _ _ #:unwind? _ 
#:unwind-for-type _)
2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
2023-12-04 10:13:48695:11  5 (_)
2023-12-04 10:13:48 In ice-9/boot-9.scm:
2023-12-04 10:13:48   1747:15  4 (with-exception-handler # _ #:unwind? _ #:unwind-for-type 
_)
2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
2023-12-04 10:13:48437:23  3 (serve-build-requests _ #< getq: 
# 
#))> getq-gc-co
unter: # putq: # putq-gc-counter: #>)
2023-12-04 10:13:48 In cuirass/remote.scm:
2023-12-04 10:13:48 466:6  2 (receive-message _ #:router? _)
2023-12-04 10:13:48 In ice-9/boot-9.scm:
2023-12-04 10:13:48   1685:16  1 (raise-exception _ #:continuable? _)
2023-12-04 10:13:48   1685:16  0 (raise-exception _ #:continuable? _)
2023-12-04 10:13:48 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
2023-12-04 10:13:48 Throw to key `match-error' with args `("match" "no matching 
pattern" (# # #))'.
2023-12-04 10:13:48 Uncaught exception in task:
2023-12-04 10:13:48 In fibers.scm:
2023-12-04 10:13:48 172:8  2 (_)
2023-12-04 10:13:48 In cuirass/notification.scm:
2023-12-04 10:13:48162:15  1 (_)
2023-12-04 10:13:48 In ice-9/boot-9.scm:
2023-12-04 10:13:48   1685:16  0 (raise-exception _ #:continuable? _)
2023-12-04 10:13:48 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
2023-12-04 10:13:48 Throw to key `psql-query-error' with args `(#f #f "no 
connection to the server\n")'.
2023-12-04 10:14:06 0 items queued for eventual download
2023-12-04 10:14:07 Uncaught exception in task:
2023-12-04 10:14:07 In fibers.scm:
2023-12-04 10:14:07 172:8  2 (_)
2023-12-04 10:14:07 In cuirass/scripts/remote-server.scm:
2023-12-04 10:14:07430:10  1 (_)
2023-12-04 10:14:07 In ice-9/boot-9.scm:
2023-12-04 10:14:07   1685:16  0 (raise-exception _ #:continuable? _)
2023-12-04 10:14:07 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
2023-12-04 10:14:07 Throw to key `psql-query-error' with args `(#f #f "no 
connection to the server\n")'.
2023-12-04 10:14:30 error: invalid log received from xx.xx.xx.254
2023-12-04 10:14:30 error: invalid log received from xx.xx.xx.254
2023-12-04 10:14:35 error: invalid log received from xx.xx.xx.254
--8<---cut here---end--->8---

Ludo’.

bug#67575: guix-daemon assertion failure upon substitution failure

[Ludovic Courtès]

On a build machine running ‘cuirass remote-server’ with
/gnu/store/5g4c9kii8l50lw23s7yb2a4bvc7qzw5d-guix-1.4.0-10.4dfdd82/bin/guix-daemon
(from Guix commit 2ab5e449246f98b049888dde3c310f5b4a0a64a2), I see these
‘cuirass remote-worker’ errors:

--8<---cut here---start->8---
2023-11-27 06:49:54 CwQfwEE3: building derivation 
`/gnu/store/rivlxrqr10g3kj9knyz7i41aq1vzxn9z-r-ecoregime-0.1.3.drv' (system: 
x86_64-linux)
2023-11-27 06:50:11 error: CwQfwEE3: unexpected error while building 
'/gnu/store/rivlxrqr10g3kj9knyz7i41aq1vzxn9z-r-ecoregime-0.1.3.drv': 
#< file: #f port: #>
[…]
2023-11-27 07:00:58 CwQfwEE3: building derivation 
`/gnu/store/b5qrpwpx5sbmlj5f7nx6wknnkczadjcn-r-cpp-0.1.0.drv' (system: 
x86_64-linux)
2023-11-27 07:01:20 error: CwQfwEE3: unexpected error while building 
'/gnu/store/b5qrpwpx5sbmlj5f7nx6wknnkczadjcn-r-cpp-0.1.0.drv': #< 
file: #f port: #>
--8<---cut here---end--->8---

… corresponding to these guix-daemon messages:

--8<---cut here---start->8---
2023-11-27 06:49:54 accepted connection from pid 14007, user root
2023-11-27 06:50:11 guix-daemon: nix/libstore/build.cc:3322: void 
nix::Worker::childTerminated(pid_t, bool): Assertion `i != children.end()' 
failed.
[…]
2023-11-27 07:00:58 accepted connection from pid 14007, user root
2023-11-27 07:01:20 guix-daemon: nix/libstore/build.cc:3322: void 
nix::Worker::childTerminated(pid_t, bool): Assertion `i != children.end()' 
failed.
--8<---cut here---end--->8---

The corresponding build log (sent by ‘cuirass remote-worker’ to the
server):

--8<---cut here---start->8---
$ zcat /var/cache/cuirass/remote/rivlxrqr10g3kj9knyz7i41aq1vzxn9z.log.gz |tail
@ substituter-started 
/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz substitute
guix substitute: warning: while fetching 
https://ci.guix.gnu.org/nar/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz:
 server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
retrying download of 
'/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz' with other 
substitute URLs...
guix substitute: warning: while fetching 
https://ci.guix.gnu.org/nar/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz:
 server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
guix substitute: error: failed to find alternative substitute for 
'/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz'
fetching path 
`/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz' (empty 
status: '')
@ substituter-failed 
/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz  fetching 
path `/gnu/store/gymm7n27rfhyz83zx3lw0bwg4m6alpzw-ecoregime_0.1.3.tar.gz' 
(empty status: '')
fetching path `/gnu/store/yiqzanx7vb8s0sj9h15p2llxwrkv0xzh-r-descriptio-1.2'...

$ zcat /var/cache/cuirass/remote/b5qrpwpx5sbmlj5f7nx6wknnkczadjcn.log.gz |tail
substitute: updating substitutes from 'http://194.199.1.1:5557'... 100.0%
guix substitute: warning: while fetching 
https://ci.guix.gnu.org/nar/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz: 
server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
retrying download of 
'/gnu/store/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz' with other 
substitute URLs...
guix substitute: warning: while fetching 
https://ci.guix.gnu.org/nar/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz: 
server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
guix substitute: error: failed to find alternative substitute for 
'/gnu/store/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz'
fetching path `/gnu/store/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz' 
(empty status: '')
@ substituter-failed 
/gnu/store/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz  fetching path 
`/gnu/store/iqi6s452hqy3k3n335c5v9nb6wq8h9nn-CPP_0.1.0.tar.gz' (empty status: 
'')
fetching path `/gnu/store/b7rnd5y4zsc1995h0a8w294pzdgbmhr9-mc2d_0.2.0.tar.gz'...
--8<---cut here---end--->8---

In both cases, “failed to find alternative substitute” leads ‘guix
substitute’ to exit, which guix-daemon doesn’t really cope with.

Ludo’.

bug#64665: [Shepherd] Introduce a configurable respawn delay

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> damn, i already had this in the queue for sending:
>
> https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=1d3643f2576aff1869bba084c92684c81689a0a1

D’oh, sorry about that.

> to help synchronize our efforts, here are the commits i'm working on, and 
> planning to send them once they have been polished and properly tested:
>
> https://github.com/attila-lendvai-patches/shepherd/commits/attila

Awesome.  I’ll also post what I plan to do next (if I actually manage to
do anything at all…).

Thanks for the heads-up!

Ludo’.