bug#58352: guix@1.3.0-30.17134b9 test failures on i686

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Now the ‘guix’ package needs to be updated.

Done in commit e49255ff18def1065f65194f679a1d07fd5a266e!

Ludo’.

bug#58374: GVFS depends on WebKitGTK via gnome-online-accounts

[Ludovic Courtès]

For a “system-level” package, GVFS has an unreasonable footprint:

--8<---cut here---start->8---
$ guix describe
Generation 230  Oct 03 2022 00:13:06(current)
  guix bb3b810
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bb3b810167d9ff784770a848a6f86b0cfa9cdfd8
$ guix size gvfs
store item   totalself
/gnu/store/wdm2s2si8fqsrcd5xpc29ivmpkf20s8d-mesa-21.3.8411.6   
169.6   6.8%
/gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
149.5   6.0%
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0 217.7   
145.8   5.9%
/gnu/store/9cbi3x1f0xqagpmdmjhc79acshyjkl6k-webkitgtk-2.36.7  1379.1   
127.0   5.1%
/gnu/store/a67q76vpbahf66y434pqs9c1gsj6x7ml-samba-4.16.4   491.8
93.7   3.8%
/gnu/store/492rrcrkgaq0csw1x09x6aj5kjz8xxrr-samba-4.15.3   489.4
90.1   3.6%
/gnu/store/drjnxy0jrxd084grrkyagrdkjsyv1afz-qtbase-5.15.2 1154.1
73.4   2.9%
/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9   155.3
63.7   2.6%
/gnu/store/p3hz5g4z1yzjq6bsbp7kqr9g0fmrmad8-mozjs-78.15.0  258.1
62.3   2.5%
/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
58.6   2.4%
/gnu/store/x3rwakc3z81hmgayxj5qh4a8flsj9hzw-mediasdk-22.4.4468.8
56.4   2.3%

[...]

total: 2492.4 MiB
--8<---cut here---end--->8---

The main issue is the dependency on webkitgtk:

--8<---cut here---start->8---
$ guix graph --path gvfs webkitgtk@2.36
gvfs@1.50.2
gnome-online-accounts@3.45.2
webkitgtk@2.36.7
$ guix gc --references $(guix build gnome-online-accounts)|grep webkit
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7
$ grep -r 6zpcpnywcimmia84jkixnwfcl4chhz6k $(guix build gnome-online-accounts)
grep: 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/libgoa-backend-1.0.so.1.0.0:
 binary file matches
grep: 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/goa-1.0/web-extensions/libgoawebextension.so:
 binary file matches
grep: 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/etc/ld.so.cache:
 binary file matches
$ ldd 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/libgoa-backend-1.0.so.1.0.0
 |grep webkit
libjavascriptcoregtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libjavascriptcoregtk-4.1.so.0
 (0x7f228ec0)
libwebkit2gtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libwebkit2gtk-4.1.so.0
 (0x7f228a80)
$ ldd 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/goa-1.0/web-extensions/libgoawebextension.so
 |grep webkit
libwebkit2gtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libwebkit2gtk-4.1.so.0
 (0x7f3a0a20)
libjavascriptcoregtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libjavascriptcoregtk-4.1.so.0
 (0x7f3a07c0)
--8<---cut here---end--->8---

One way to address it might be to build libgoa-backend and
libgoawebextension separately from the main libgoa.so, or to have them
in a separate output.

However, I’m not sure how libgoa-backend is supposed to be used.  It has
a .pc file, which suggests applications that need it explicitly link
against it (as opposed to having it dlopen’d), but I couldn’t find an
example.

Thoughts?

Ludo’.

bug#58352: guix@1.3.0-30.17134b9 test failures on i686

[Ludovic Courtès]

Ludovic Courtès  skribis:

> This is because gvfs now indirectly pulls in librsvg and thus Rust:

It’s not the only one:

--8<---cut here---start->8---
$ ./pre-inst-env  guix graph --path network-manager-applet librsvg -s i686-linux
network-manager-applet@1.28.0
libnma@1.10.2
gtk@4.8.1
gst-plugins-bad@1.18.5
librsvg@2.50.7
--8<---cut here---end--->8---

This part is addressed by these commits:

  31708431c5 tests: Attempt to build 'desktop.tmpl' on all major architectures.
  06deab3321 gnu: libnma: Depend on GTK 4.x only on supported platforms.
  a52f39ad0c gnu: rest@0.9.1: Remove dependency on gtksourceview and libadwaita.

Now the ‘guix’ package needs to be updated.

Ludo’.

bug#58352: guix@1.3.0-30.17134b9 test failures on i686

[Ludovic Courtès]

The guix@1.3.0-30.17134b9 package has a test failure on i686-linux:

--8<---cut here---start->8---
+ for example in gnu/system/examples/*.tmpl
+ case "$example" in
+ options=
+ guix system -n disk-image gnu/system/examples/desktop.tmpl
accepted connection from pid 25354, user nixbld
guix system: warning: 'disk-image' is deprecated: use 'image' instead
guix system: error: package gvfs@1.50.2 does not support i686-linux
+ rm -f t-guix-system-24535 t-guix-system-error-24535 
/tmp/guix-build-guix-1.3.0-30.17134b9.drv-0/t-guix-system-24535/config.scm 
/tmp/guix-build-guix-1.3.0-30.17134b9.drv-0/t-guix-system-24535/my-torrc
+ rmdir /tmp/guix-build-guix-1.3.0-30.17134b9.drv-0/t-guix-system-24535
FAIL tests/guix-system.sh (exit status: 1)
--8<---cut here---end--->8---

This is because gvfs now indirectly pulls in librsvg and thus Rust:

--8<---cut here---start->8---
$ ./pre-inst-env  guix graph --path gvfs librsvg -s i686-linux
gvfs@1.50.2
gnome-online-accounts@3.45.2
rest@0.9.1
gtksourceview@5.5.1
gtk@4.8.1
gst-plugins-bad@1.18.5
librsvg@2.50.7
--8<---cut here---end--->8---

It is surprising to see ‘rest’ (a network lib) depend on
‘gtksourceview’; that’s for a demo program:

--8<---cut here---start->8---
$ ldd /gnu/store/6ghbgz1slh70g173rsyhlvs1clgsfva4-rest-0.9.1/bin/librest-demo | 
grep sourcevi
libgtksourceview-5.so.0 => 
/gnu/store/ww28crn08wlg59ldfqhcgk1g8dhsf6cw-gtksourceview-5.5.1/lib/libgtksourceview-5.so.0
 (0x7fad0d574000)
--8<---cut here---end--->8---

I’ll probably tackle it from that angle.

Ludo’.

bug#58033: A bug in file-dynamic-info used by validate-runpath in gnu-build-system and others.

[Ludovic Courtès]

Hi Lukasz,

Lukasz Olszewski  skribis:

> Then if I run $ strip --strip-unneeded --enable-deterministic-archives
> file the files can be run fine, but if I use patchelf to add an extra
> folder to the rpath strip complains like this:
> $ strip --strip-unneeded --enable-deterministic-archives
> /home/luk/dev/backup_FileStoreTest
> strip: /home/luk/dev/stt5WKN1: warning: allocated section `.dynstr'
> not in segment
>
> Then the binary has its elf header mangled as described previously.
>
> By copying the unmodified file, modifying rpath and running strip a
> couple of times I found that there is no problem if the rpath change
> results in rpath of the same or shorter length, but adding even one
> byte to it makes 'strip' later complain and mangle the binary.

I believe PatchELF has the potential to break binaries, especially when
trying to extend RUNPATH (the data has to fit in the string table;
PatchELF is supposed to be able to grow the string table as needed, but
there might be bugs.)

It looks like a workaround is to not run ‘strip’, right?

Ludo’.

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hi!

Samuel Thibault  skribis:

> Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit:

[...]

>> Of course, the thing boots just fine on that machine when using
>> ‘exec.static’.
>
> Uh. At least you have a workaround :)

Yup.  :-)

>> So the issue might be somewhere in ld.so, or triggered by ld.so.
>> Any debugging tricks here?
>
> maybe for a start check with 
>
> show map $map2
>
> what is actually mapped, whether it's just ld.so, or also exec, etc.

On the first trap (page fault) I see:

--8<---cut here---start->8---
db> show all tasks  

 ID TASK NAME [THREADS] 

  0 f5f7cf00 gnumach [7]

  1 f5f7ce40 ext2fs [6] 

  2 f5f7cd80 exec [1]   

db> show map $map2  

Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5   

size=290816,resident:290816,wired=0 

version=14  

 map entry 0xf625ec08: start=0x0, end=0x1000

 prot=1/7/copy, object=0xf5f6a7d0, offset=0x0   

  Object 0xf5f6a7d0: size=0x1000, 1 references  

  1 resident pages, 0 absent pages, 0 paging ops

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5938968  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625ebb0: start=0x1000, end=0x26000

 prot=5/7/copy, object=0xf5f6ad70, offset=0x0   

  Object 0xf5f6ad70: size=0x25000, 1 references 

  37 resident pages, 0 absent pages, 0 paging ops   

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82780  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625eb58: start=0x26000, end=0x34000   

 prot=1/7/copy, object=0xf5f6ad20, offset=0x0   

  Object 0xf5f6ad20: size=0xe000, 1 references  

  14 resident pages, 0 absent pages, 0 paging ops   

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625eb00: start=0x34000, end=0x37000   

 prot=3/7/copy, object=0xf5f6acd0, offset=0x0   

  Object 0xf5f6acd0: size=0x3000, 1 references  

  3 resident pages, 0 absent pages, 0 paging ops

   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f826e0  

   uninitialized,temporary  internal,copy_strategy=0

   shadow=0x0 (offset=0x0),copy=0x0 

 map entry 0xf625eaa8: start=0xbfff, end=0xc000 
 

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Samuel Thibault  skribis:

> Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit:
>> such that it would stop on each trap, hopefully allowing me to see why
>> exec is not starting.
>
> Also, better use exec.static to have static addresses.

Thanks for the hint.

Of course, the thing boots just fine on that machine when using
‘exec.static’.

So the issue might be somewhere in ld.so, or triggered by ld.so.
Any debugging tricks here?

Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi!

Matthieu Haefele  skribis:

> Victory !!
>
>     (base) mhaefele@mdlspc113:tmp $ 
> /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
>     guile: warning: failed to install locale
>     guix-daemon (GNU Guix) 1.3.0-30.17134b9
>
> And the `guix pull` runs smoothly now, thanks a lot  :)

Yay, who would have thought?!  :-)

Thanks for persevering.  At lease we have a shorter path now next time
someone hits the problem.

> Now it is fixed I have two questions:
> 1. What am I doing wrong to have stuck to this old guix daemon all
> this time ? Shall I run this `sudo -i guix pull` regularly to keep my
> daemon up to date ? But then it looks like I am the only one who faced
> this issue, weird, no ? And problems should have started back in
> February, but I intensively worked on guix this summer, including some
> `guix pull`... If reasons are not too complicated, I am interested in
> getting some insights.

The daemon changes, gets bug fixes, new features, support for new
compression algorithms, optimizations, etc., but the client/daemon
interface is stable.  Thus, one rarely needs to upgrade the daemon, but
it’s a good idea to update it once in a while.

On Guix System, that happens automatically when you reconfigure your
system, but on other distros it’s easy to overlook that.  The idea of
having clients warn about old daemons was a good one, but the
implementation didn’t work in your situation.

In your case, your daemon supported nothing but gzip (and bzip2 I think)
for substitutes.  However, gzip was officially dropped a few months ago,
meaning that newer substitutes are not available as gzip from
ci.guix.gnu.org:

  https://guix.gnu.org/en/blog/2022/sunsetting-gzip-substitutes-availability/

Thus your daemon was unable to fetch substitutes for things that were
built after that time.


BTW, the gzip change was announced publicly through several channels,
but your experience demonstrates that this is not enough.

> 2. We have tried out several things. If I have a colleague in a similar 
> situation, could you confirm the following procedure:
>
>/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
># should answer something like "guix-daemon (GNU Guix) 1.0.1"
>
>
>
>guix build \
> /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
>
>  sudo -i guix package --bootstrap -p /root/.config/guix/current \
> -r guix  -i  
> /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
>
>  systemctl restart guix-daemon
>
>/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
># should answer "guix-daemon (GNU Guix) 1.2.0rc2-1.0d4b1af"
>
>sudo -i guix pull
>
>systemctl restart guix-daemon
>
>
>/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
># should answer something like "guix-daemon (GNU Guix) 1.3.0-30.17134b9"
>
> Agree ?

Yes.

Thanks again for your time!

Ludo’

bug#58149: guix pull error

[Ludovic Courtès]

zimoun  skribis:

> Well, I cannot confirm the store name as
> /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af.
> Personally, I also miss how Ludo found these items. :-)

With:

  guix time-machine --commit=a099685659b4bfa6b3218f84953cbb7ff9e88063 \
-- build guix --no-grafts

That commit corresponds to ‘v1.2.0’.

Ludo’.

bug#58333: Manual PDFs other than en and es fail to build

[Ludovic Courtès]

Hi,

 lacks its PDF, and similarly for
/de (/ru and /zh-cn don’t have the PDF either, but that’s a known
limitation).

When running ‘guix build -f doc/build.scm’, we get hard-to-decipher
clues (thanks, TeX!):

--8<---cut here---start->8---
/gnu/store/sqi9bbxd7czxcnvhmm037yd01vykcgza-texinfo-manual-source/guix.de.texi:21958:
 TeX capacity exceeded, sorry [input stack size=5000].
@par ->@endgraf @pretolerance =100 @let @par 
 @endgraf 
@par ->@endgraf @pretolerance =100 @let @par 
 @endgraf 
@par ->@endgraf @pretolerance =100 @let @par 
 @endgraf 
@par ->@endgraf @pretolerance =100 @let @par 
 @endgraf 
@par ->@endgraf @pretolerance =100 @let @par 
 @endgraf 
@par ->@endgraf @pretolerance =100 @let @par 
 @endgraf 
...
l.21958 @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}
 , das einen
/gnu/store/sqi9bbxd7czxcnvhmm037yd01vykcgza-texinfo-manual-source/guix.de.texi:21958:
  ==> Fatal error occurred, no output PDF file produced!
Transcript written on guix.de.log.

[…]

/gnu/store/sqi9bbxd7czxcnvhmm037yd01vykcgza-texinfo-manual-source/guix.fr.texi:44195:
 This command can appear only outside of any environment, not in environment 
@deftypevr.
@badenverr ->@errhelp = @EMsimple @errmessage {This command can appear only 
@inenvironment @temp , not @inenvironment @thisenv }


@checkenv #1->@def @temp {#1}@ifx @thisenv @temp @else @badenverr 
  @fi 
@chapmacro #1#2#3->@expandafter @ifx @thisenv @titlepage @else @checkenv {}
   @fi 
@let @prevchapterdefs =@currentchapterdefs @let @prevsectiondefs 
=@currentsectiondefs @gdef @currentsectiondefs {@gdef @thissectionname {}@gdef 
@thissectionnum {}@gdef @thi...
@unnumberedzzz ...obal @subsecno =0 @global @subsubsecno =0 @global @advance 
@unnumberedno by 1 @global @let @chaplevelprefix = @empty @resetallfloatnos 
@toks 0 = {#1}@message {(@the @toks 0)}@chapmacro {#1}{Ynothing}{@the 
@unnumberedno }


  
@global @let ...
@genhead ... @chapheadtype N@errmessage {@appendix... within a non-appendix 
chapter}@fi @fi @fi @ifnum @absseclevel > @unnlevel @def @headtype {U}@else 
@chardef @unnlevel = 3 @fi @fi @if @headtype U@ifcase @absseclevel 
@unnumberedzzz {#3}


  
@or @unnumber...
l.44195 @unnumbered Index de programmation
  
[721] (/tmp/guix-build-guix-pdf-manual.drv-0/guix.fr.fns
Overfull \hbox (20.40314pt too wide) in paragraph at lines 64--64
 []@smalltt enlightenment-desktop- |
[722] [723] [724]) [725] )
(@end occurred inside a group at level 1)

### semi simple group (level 1) entered at line 26480 (@begingroup)
### bottom level
(see the transcript file for additional information) <./cmr12.720pk> 

 

 <./cmss10.657pk> <./cmtt12.657pk> 

 

 

 <./cmsl10.720pk> <./cmb10.720pk> <./cmsltt10.720pk> <./cmtt12.720pk> 
<./cmtt10.720pk>{/gnu/store/fi336fykl2kzdnaq64j2zyf3f5jxrhm0-profile/share/texmf-dist/fonts/enc/dvips/cm-super/cm-super-t1.enc}
 <./cmsltt10.540pk> <./cmbx12.657pk> <./cmsltt10.657pk> <./cmb10.657pk> 
 

 <./cmti10.657pk> <./cmsl10.657pk> 

 

 <./cmtt10.657pk> <./cmmi10.657pk> <./cmmi12.720pk> <./cmbx12.864pk> 

 <./cmsy10.657pk> <./cmbx12.720pk> <./cmr10.657pk> 
<./cmbx12.1037pk>

Output written on guix.fr.pdf (736 pages, 2668969 bytes).
Transcript written on guix.fr.log.
/gnu/store/fi336fykl2kzdnaq64j2zyf3f5jxrhm0-profile/bin/texi2dvi: pdftex exited 
with bad status, quitting.


Failed to produce PDF for language 'fr'!
--8<---cut here---end--->8---

I also see things like:

--8<---cut here---start->8---
Writing index file guix.fr.cp
l.527: Unicode char @u8:. not defined for Texinfo l.527: Unicode char @u8:. not 
defined for Texinfo
Missing character: There is no  in font cmr10!
Missing character: There is no  in font cmr10!
Missing character: There is no  in font cmr10!
--8<---cut 

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hi!

As suggested by Samuel on IRC, I did that early on in kdb:

  debug traps /on

such that it would stop on each trap, hopefully allowing me to see why
exec is not starting.

--8<---cut here---start->8---
module 0: ext2fs --multiboot-command-line=${kernel-command-line} 
--host-priv-por
t=${host-port} --device-master-port=${device-port} 
--exec-server-task=${exec-tas
k} --store-type=typed --x-xattr-translator-records ${root} $(task-create) 
$(task
-resume)

module 1: exec 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hu   
 
rd/exec $(exec-task=task-create)

2 multiboot modules 

task loaded: ext2fs --multiboot-command-line=root=device:hd0s1 
root=3367134b-cfb
d-1e90-2f38-dfd13367134b 
gnu.system=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-
system gnu.load=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot 
--host-p
riv-port=1 --device-master-port=2 --exec-server-task=3 --store-type=typed 
--x-xa
ttr-translator-records device:hd0s1 

task loaded: exec 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167  
  
/hurd/exec  



start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] execkernel: Page 
fault
 (14), code=6   

Stopped at  0x1000: pushl   0x4(%ebx)   

> user space <  
> 
0x1000(bf24,0,0,1160b,0)

0x11627(bf9c,0,0,0,2)   

0x11bb()

db> show all threads

TASKTHREADS 

  0 gnumach (f5f7cf00): 7 threads:  

  0 (f5f7be18) .W..N. 0xc11dac04

  1 (f5f7bcd0) R..O..(idle_thread_continue) 

  2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4

  3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c

  4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0  

  5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74   

  6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8   

  1 ext2fs (f5f7ce40): 6 threads:   

  0 (f5f7b520) .W.O.F(mach_msg_continue) 0  

  1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0  

  2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0  

  3 (f5f7b000) .W.O..(mach_msg_continue) 0  

  4 (f67d4e20) .W.O..(mach_msg_receive_continue) 0  

  5 (f67d4cd8) .W.O..(mach_msg_continue) 0  

  2 exec (f5f7cd80): (f5f7b3d8) R.  

--8<---cut here---end--->8---

Then lots of page faults with the same stack trace, seemingly endlessly:

--8<---cut here---start->8---
db> c   

kernel: Page fault (14), code=6 

Stopped at  0x1000: pushl   0x4(%ebx)   

> user space <  
> 
0x1000(bf24,0,0,1160b,0)  

bug#58149: guix pull error

[Ludovic Courtès]

Hi,

Matthieu Haefele  skribis:

>>sudo -i guix package -r guix -i \
>>  /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
>
> I am getting an error when trying to remove the guix package as it is not 
> part of the profile, so I just try to install the package

Could you try with ‘--bootstrap’ as shown below?

   sudo -i guix package --bootstrap -r guix -i \
 /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af

Thanks in advance.  :-)

Ludo’.

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hello!

On AMD EPYC processors, as found on the build nodes of ci.guix.gnu.org,
childhurd VMs fail to boot when running with ‘qemu-system-i386
-enable-kvm’ (the kvm-amd Linux kernel module is used), with the Hurd
startup process hanging before /hurd/exec has been started:

--8<---cut here---start->8---
module 0: ext2fs --multiboot-command-line=${kernel-command-line} 
--host-priv-por
t=${host-port} --device-master-port=${device-port} 
--exec-server-task=${exec-tas
k} --store-type=typed --x-xattr-translator-records ${root} $(task-create) 
$(task
-resume)

module 1: exec 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hu   
 
rd/exec $(exec-task=task-create)

2 multiboot modules 

task loaded: ext2fs --multiboot-command-line=root=device:hd0s1 
root=3367134b-cfb
d-1e90-2f38-dfd13367134b 
gnu.system=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-
system gnu.load=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot 
--host-p
riv-port=1 --device-master-port=2 --exec-server-task=3 --store-type=typed 
--x-xa
ttr-translator-records device:hd0s1 

task loaded: exec 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167  
  
/hurd/exec  



start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec  

--8<---cut here---end--->8---

Kdb shows these two tasks:

--8<---cut here---start->8---
Stopped   at  mach
ine_idle+0x26:  nop 

machine_idle(0,c102f380,f5f7bcd0,c102e3fa)+0x26 

idle_thread_continue(f5f7ade0,36366000,f5f73868,f5f73890,0)+0x73

> user space <  
> 
db> show all threads

TASKTHREADS 

  0 gnumach (f5f7cf00): 7 threads:  

  0 (f5f7be18) .W..N. 0xc11dac04

  1 (f5f7bcd0) R.   

  2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4

  3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c

  4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0  

  5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74   

  6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8   

  1 ext2fs (f5f7ce40): 6 threads:   

  0 (f5f7b520) .W.O.F(mach_msg_continue) 0  

  1 (f5f7b290) .W.O.F(mach_msg_receive_continue) 0  

  2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0  

  3 (f5f7b000) .W.O..(mach_msg_continue) 0  

  4 (f67d3e20) .W.O..(mach_msg_receive_continue) 0  

  5 (f67d3cd8) .W.O..(mach_msg_continue) 0  

db> trace/t 0xf5f7b520  

Continuation mach_msg_continue  

> user space <  
> 
0x80ccaec() 

--8<---cut here---end--->8---

For ext2fs.static, that just means thread 0 is here:

--8<---cut here---start->8---
$ addr2line -e 

bug#58203: Cuirass fails to respect (target-x86-32?) in some circumstances

[Ludovic Courtès]

Hi Marius,

(Cc: Mathieu for the search box issue below.)

Marius Bakke  skribis:

> Ludovic Courtès  skriver:

[...]

>> The good news is that with today’s ‘staging’, everything’s fine:
>
> Not quite:
>
>   https://ci.guix.gnu.org/search?query=system%3Ai686-linux+imath
>
> Imath has no dependencies apart from CMake, so all of those should be
> the same derivation, yet some are failing.

This is for:

  /gnu/store/sdgcjk8wiv4wk69nlxwp43adppmvijpz-imath-3.1.3.drv

which has #:tests? #true… but that’s also from an evaluation from May,
even if the build is from Sep. 30:

  https://ci.guix.gnu.org/build/739643/details
  https://ci.guix.gnu.org/eval/302107

>From <https://ci.guix.gnu.org/eval/683442/dashboard?system=i686-linux>,
I found this recent build ✅:

  https://ci.guix.gnu.org/build/1324091/details

It’s a bug that we don’t get it from the search box:

  https://ci.guix.gnu.org/search?query=spec%3Astaging+system%3Ai686-linux+imath

Mathieu, any ideas?

Anyhow, the “ground truth” in general is Guix itself:

  guix time-machine --branch=staging -- \
build imath -s i686-linux --no-grafts

Thanks,
Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi Matthieu,

I figured there’s an easier option:

  guix build \
/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
  sudo -i guix package -r guix -i \
/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af

This will install Guix 1.2 in root’s profile (with
/usr/local/bin/guix-daemon pointing to it, normally).  You can then
start this new daemon:

  systemctl restart guix-daemon

At that point you have lzip support.  Thus, you should be able to
upgrade the daemon to the latest one (while at it) using the documented
procedure:

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

Let me know how it goes!

Matthieu Haefele  skribis:

>  (base) mhaefele@mdlspc113:m2-mms-hpc (master)*$ guix build --no-substitutes \
>  $(guix gc --derivers 
> /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)

[...]

> collect2: error: ld returned 1 exit status
> make[2]: *** [../../gcc-5.5.0/gcc/c/Make-lang.in:71: cc1] Error 1

I don’t see an error message in the snippet you pasted.  Could it be
OOM, or was there a clue in /var/log/messages or similar?

> Thanks for diving in this ocean of code and trying to make it manageable with 
> a reproducible process to build it :)

That’s an insightful exercise for sure.  :-)

> BTW I am watching the videos of the very interesting event organized
> for the ten years of guix. The presentation of Efraim Flashner stunted
> me. 40h of compile just for rust from the bootstrap on a RISC-V but
> still GHz processor. How can these things work in the end ... ? Life,
> as the single negentropic known process should play its role here as
> well. The minimalism wished by Pjotr Prins is the way to go if we want
> to keep the illusion of controlling what we are doing.

The bootstrapping effort is about “regaining control” of our software
stack in a way, but it shows just how much things had gotten awry.

Thanks again,
Ludo’.

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Ludovic Courtès]

Hello,

Maxim Cournoyer  skribis:

> zimoun  writes:
>
>> Hi,
>>
>> On Thu, 29 Sep 2022 at 23:10, Maxim Cournoyer  
>> wrote:
>>
>>> Wholly agreed, this thread is already too long and the original problem
>>> was fixed.  Closing.
>>
>> I disagree, the original problem is not fixed; as I explained.  Well,
>> since you consider it is, please also close the related patch#43442.
>
> Oh, from Ludovic's answer, I thought that the original issue had drifted
> to tangential problems; apologies for drawing the wrong conclusion.

Sorry for the misleading comment.

> I've now migrated the remaining packages off gforge.inria.fr; see the
> commits ending with 06201b76e5ef811245d627706c90117a0e9813d4.

Woow, you rock!!  (Would be nice to check Disarchive coverage of the
previously-used tarballs, to see how good we’re doing.)

> I tried to update ocaml-dose3, but aborted that effort, since it'd
> require packaging ocaml-parmap:

Something for the OCaml team!  :-)

Thanks,
Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi,

Matthieu Haefele  skribis:

> Le 03/10/2022 à 16:03, Ludovic Courtès a écrit :

[...]

>> You should be able to get around it by first building things locally:
>>
>>guix build --no-substitutes \
>>  $(guix gc --derivers 
>> /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)
>>
>> This is going to take a while though…
>>
>> I’m sorry this upgrade turns out to be so painful.  We know what to work
>> on next.
>>
> Problems at fetching the kernel sources apparently...
>
> (base) mhaefele@mdlspc113:m2-mms-hpc (master)*$ guix build --no-substitutes \
>> $(guix gc --derivers 
>>/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)
> The following derivations will be built:
>   /gnu/store/16c8c8hm1qdn6xz8014939mirc7c4d4j-guile-2.2.4.drv
>   /gnu/store/06pscnfdljxnyb673pqyhnvz1x5rjl1l-libgc-7.6.6.drv
> /gnu/store/4k028mc8dnnx478dirgx90rpby465jqr-ld-wrapper-boot3-0.drv
>   /gnu/store/agrwc0hhkxjb96z66nb6hakimb4a2vg3-module-import.drv

[...]

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

[...]

> Starting download of 
> /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
> From 
> https://mirror.hydra.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg...
> In procedure connect: Network is unreachable

You can fetch it with:

  wget -O linux-libre-4.14.67-gnu.tar.xz \
   
https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg
  guix download file://$PWD/linux-libre-4.14.67-gnu.tar.xz

Let’s see if you can proceed from there.

At any rate, it’s a good lesson for us developers, so thanks for
persevering.

Ludo’.

bug#58204: guix system reconfigure hangs silently when substitute server is unreachable

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> While fixing up Berlin today, I had to use '--no-substitutes' on the
> daemon started per 'info (guix)Chrooting', otherwise it'd hang up
> without printing any of the warnings (totally silent).  Using strace, I
> could see:
>
> guix substitute: warning: ci.guix.gnu.org: host not found: System error
>
> It'd be nice if these warnings were propagated all the way up so the
> user would realize what is happening and take action.

I think it’s supposed to be propagated.

In the example above, I guess there were cached ci.guix.gnu.org narinfos
for those substitutes and the “host not found” error arose when actually
trying to substitute these, right?

I’m surprised substitution didn’t just crash.

Thanks,
Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Matthieu Haefele  skribis:

>> So you’re right, we have to go a bit further back in time!  Apparently
>> v1.2.0 will do, so:
>>
>>guix pull --commit=a099685659b4bfa6b3218f84953cbb7ff9e88063
>>
> Not better unfortunately...
>
> (base) mhaefele@mdlspc113:ksp $ sudo -i guix pull 
> --commit=a099685659b4bfa6b3218f84953cbb7ff9e88063

[...]

> The following derivations will be built:
> /gnu/store/bxkxaxkk9v0br8lkb93raz9csjx2c8zd-module-import-compiled.drv
>    /gnu/store/49s0bs87gvv48x9nnjx7i8msjaxs9vwl-module-import.drv
>    /gnu/store/lybfadhfwzldw724mpsbdzakv54wwvvr-hash.scm.drv
>    /gnu/store/pl48shh9vvnd8q8909ra7hznhzlcn0gj-config.scm.drv
>    /gnu/store/sc6fv5hqxvk1nziq20wi427hh3cmr88n-git.scm.drv
> /gnu/store/w6jvr6r28z1gx1s5sxhl0f3d5q417g7y-compute-guix-derivation.drv
> 7,5 MB will be downloaded:
>    /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4
>    /gnu/store/0h9x3hqqh4fx52735a7mykqm7mdkqnf4-libgc-7.6.6
>    /gnu/store/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6
>    /gnu/store/b7pbksdw7f1x4faimd2xmgpcipsrp9ns-libffi-3.2.1
>    /gnu/store/g3az3q22hmlqwwzqjv4vqfrhcfl88a2s-libunistring-0.9.10
>    /gnu/store/w967m83560ik61vqv0v8aw3b0avb0hng-libltdl-2.4.6
>    /gnu/store/wsq5x6sizjq8ggyfydccv1hcsciy40wi-gmp-6.1.2
>    /gnu/store/y249ycgfvg0p83hwpwf5nbn1aghjcc9n-pkg-config-0.29.2
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6...
> Backtrace:
>    3 (apply-smob/1 #)
> In ice-9/boot-9.scm:
>     705:2  2 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
>     619:8  1 (_ #(#(#)))
> In guix/ui.scm:
>   1747:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:1747:12: In procedure run-guix-command:
> unsupported compression scheme lzip
> substitution of 
> /gnu/store/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6 failed

Oh my bad, it’s the same one as before.

You should be able to get around it by first building things locally:

  guix build --no-substitutes \
$(guix gc --derivers 
/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)

This is going to take a while though…

I’m sorry this upgrade turns out to be so painful.  We know what to work
on next.

Thanks,
Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi,

Matthieu Haefele  skribis:

>> I would suggest doing a two-step upgrade; first upgrade to 1.3.0:
>>
>>sudo -i guix pull --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff
>
> Are you sure this commit is old enough ? I still get the same error.
> By the way, a general question, where can you see the guix time line,
> such that one has a chance to pick up a relevant commit id at certain
> point in time ?
>
> (base) mhaefele@mdlspc113:~ $ sudo -i guix pull 
> --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff

[...]

> 7,5 MB will be downloaded:
>    /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4
>    /gnu/store/0h9x3hqqh4fx52735a7mykqm7mdkqnf4-libgc-7.6.6
>    /gnu/store/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6
>    /gnu/store/b7pbksdw7f1x4faimd2xmgpcipsrp9ns-libffi-3.2.1
>    /gnu/store/g3az3q22hmlqwwzqjv4vqfrhcfl88a2s-libunistring-0.9.10
>    /gnu/store/w967m83560ik61vqv0v8aw3b0avb0hng-libltdl-2.4.6
>    /gnu/store/wsq5x6sizjq8ggyfydccv1hcsciy40wi-gmp-6.1.2
>    /gnu/store/y249ycgfvg0p83hwpwf5nbn1aghjcc9n-pkg-config-0.29.2
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6...
> Backtrace:
>    3 (apply-smob/1 #)
> In ice-9/boot-9.scm:
>     705:2  2 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
>     619:8  1 (_ #(#(#)))
> In guix/ui.scm:
>   1747:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:1747:12: In procedure run-guix-command:
> unsupported compression scheme lzip
> substitution of 
> /gnu/store/4jh61hq9b4pv1bjqimafcv2w1c20cqrc-libatomic-ops-7.6.6 failed

It looks like the substitutes above are only available as lzip or zstd
even though they’re quite old:

--8<---cut here---start->8---
$ wget -qO- https://ci.guix.gnu.org/4jh61hq9b4pv1bjqimafcv2w1c20cqrc.narinfo 
|grep ^Compression
Compression: lzip
Compression: zstd
$ wget -qO- https://ci.guix.gnu.org/r658y3cgpnf99nxjxqgjiaizx20ac4k0.narinfo 
|grep ^Compression
Compression: lzip
Compression: zstd
--8<---cut here---end--->8---

So you’re right, we have to go a bit further back in time!  Apparently
v1.2.0 will do, so:

  guix pull --commit=a099685659b4bfa6b3218f84953cbb7ff9e88063

Let us know how it goes!

Thanks,
Ludo’.

bug#58149: Letting clients warn about old daemons

[Ludovic Courtès]

Hi,

(Cc: Mathieu O. + Maxim.)

Matthieu Haefele  skribis:

> I worked intensively with guix this summer, I did not get any
> deprecation warnings, I am quite sure. And I still do not get any. So
> might be a good idea to check the deprecation machinery.
>
> (base) mhaefele@mdlspc113:~ $ guix shell python-numpy python coreutils
> (base) mhaefele@mdlspc113:~ $ echo $GUIX_ENVIRONMENT
> /gnu/store/cy8y10jfnbq5y2r16i13q04h1lii428a-profile

Indeed.  I’ve just realized that commit
f9c62b23cc88541756656b3ec602ce987828d906, which added that deprecation
warning, will actually only fire with daemons dating back from before
2018 (the date at which ‘PROTOCOL_VERSION’ was last updated in
‘worker-protocol.hh’).  Going back to this issue at hand, it won’t
report a daemon that lacks lzip support.

Mathieu, Maxim: I think we need a finer-grain mechanism here, or maybe a
new builtin that would let a client ask the daemon for supported
features.

Thoughts?

Ludo’.

bug#58090: Missing bin/ffplay in ffmpeg@4

[Ludovic Courtès]

Hi,

Zhu Zihao  skribis:

> citreu@asus-laptop:~$ guix describe
> Generation 1149月 26 2022 13:24:04 (当前)
>   guix 754ce58
> repository URL: https://mirror.guix.org.cn/git/guix
> branch: master
> commit: 754ce586e013582b0f6d28337fdc46db35395997
> citreu@asus-laptop:~$ guix shell ffmpeg@4 --pure -- ffplay
> guix shell: error: ffplay: command not found

This is apparently caused by the switch from SDL2 2.0.14 to SDL2 2.24.0
in commit f24bf279d41fab25ceb3fcc88bcd5da6fb1404ae.

Fixed in 782c7455e1ea3785e8c7e9b300d55c9ebb441a35.

Thanks,
Ludo’.

bug#58040: "guix style" puts closing parentheses on the wrong line

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> and running "guix style -f a.scm" on it, it becomes
>
> (define (find-latest-release releases)
>   (fold (match-lambda* (((key . value) result)
> (cond
>   ((even-minor-version? key)
>(match result
>  (#f (cons key value))
>  ((newest . _) (if (version>? key newest)
>(cons key value) result
>   (else result)))
>   ) #f releases)).
>
> In particular, note the ") #f releases" -- IMO ) should be on the
> previous line, after (else result))), to avoid lonely parentheses and
> to align the arguments of 'fold'.

Fixed in 4bd75d79e5ad8bb0f6cdcc0d15b9afb25f54afbd: ‘match-lambda*’ had
an incorrect special form declaration.

Thanks,
Ludo’.

bug#58205: reconfiguration stuck unless using '--no-grafts'

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> While working on Berlin today from a chroot, and with --no-substitutes
> used for guix-daemon, I wasn't able to complete the 'guix system
> reconfigure' step; it'd hand on a read call (seen using strace):
>
> statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, 
> f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, 
> f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, 
> f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
> write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 
> 152) = 152
> read(14, "gmlo\0\0\0\0", 8) = 8
> read(14, "\276\0\0\0\0\0\0\0", 8)   = 8
> read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
> ) = 12
> write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for 
> guix-1.3.0-29.9e46320 ...
> ) = 48
> read(14, "gmlo\0\0\0\0", 8) = 8
> read(14, "\255\0\0\0\0\0\0\0", 8)   = 8
> read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
> \)= 5
> read(14,

The build process is probably actually grafting things, and while doing
that it doesn’t output anything.  Thus it’s not surprising that the
client is stuck on read(2) waiting for data on the daemon socket.  It
might be that the grafting process is just taking a long time?

The way to debug that would be to run ‘sudo guix processes’, to identify
the build process and hand (the one that builds /gnu/store/kv1hg….drv in
the example above), and to strace that process.

HTH!

Ludo’.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Hi!

Maxime Devos  skribis:

> On 05-09-2022 14:56, Ludovic Courtès wrote:
>> I’d like to test whether UPower invokes the intended critical action,
>> but I’m not sure how to simulate a low battery level.  Thoughts?
>
> I've found a 'Virtual Battery Driver': https://lwn.net/Articles/440097/
>
> The gmane links are dead, but the linux source tree as a
> drivers/power/supply/test_power.c that seems to be about the same
> thing.

I was able to give that a try.  Since the default ‘percentage-action’ in
 is 2, I did this (I configured syslogd to log to
/dev/console):

--8<---cut here---start->8---
root@antelope ~# modprobe test-power ac_online=off usb_online=off 
battery_capacity=2 battery_status=discharging
modprobe test-power ac_online=off usb_online=off battery_capacity=2 
battery_status=discharging
Oct  2 17:00:20 localhost vmunix: [   44.294530] __power_supply_register: 
Expected proper parent device for 'test_ac'
Oct  2 17:00:20 localhost vmunix: [   44.295049] __power_supply_register: 
Expected proper parent device for 'test_battery'
Oct  2 17:00:20 localhost vmunix: [   44.295147] __power_supply_register: 
Expected proper parent device for 'test_usb'
root@antelope ~# Oct  2 17:00:20 localhost shepherd[1]: [upowerd]  
Oct  2 17:00:20 localhost shepherd[1]: [upowerd] (upowerd:186): 
UPower-Linux-WARNING **: 17:00:20.457: no valid voltage value found for device 
/sys/devices/virtual/power_supply/test_battery, assuming 10V 
Oct  2 17:00:20 localhost shepherd[1]: [upowerd]  
Oct  2 17:00:20 localhost shepherd[1]: [upowerd] (upowerd:186): 
UPower-Linux-WARNING **: 17:00:20.473: USB power supply 
/sys/devices/virtual/power_supply/test_usb without usb_type property, please 
report 


root@antelope ~# Oct  2 17:00:41 localhost elogind[185]: System is powering 
down..
Oct  2 17:00:41 localhost elogind[185]: System is powering down..
Oct  2 17:00:41 localhost shepherd[1]: Exiting shepherd... 
Oct  2 17:00:41 localhost shepherd[1]: Service ntpd has been stopped. 
Oct  2 17:00:41 localhost ntpd[184]: ntpd exiting on signal 15 (Terminated)
Oct  2 17:00:41 localhost avahi-daemon[191]: Got SIGTERM, quitting.
Oct  2 17:00:41 localhost avahi-daemon[191]: Leaving mDNS multicast group on 
interface ens3.IPv6 with address fec0::e35c:509d:d937:2087.
Oct  2 17:00:41 localhost avahi-daemon[191]: Leaving mDNS multicast group on 
interface ens3.IPv4 with address 10.0.2.15.
Oct  2 17:00:41 localhost shepherd[1]: Service avahi-daemon has been stopped. 
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2220] caught 
SIGTERM, shutting down normally.
Oct  2 17:00:41 localhost shepherd[1]: Service networking has been stopped. 
Oct  2 17:00:41 localhost shepherd[1]: Service console-font-tty6 has been 
stopped. 
Oct  2 17:00:41 localhost shepherd[1]: Service term-tty6 has been stopped. 
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2318] dhcp4 
(ens3): canceled DHCP transaction
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2318] dhcp4 
(ens3): activation: beginning transaction (timeout in 45 seconds)
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2318] dhcp4 
(ens3): state changed no lease
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2326] 
manager: NetworkManager state is now CONNECTED_SITE
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2335] 
exiting (success)
Oct  2 17:00:41 localhost avahi-daemon[191]: Leaving mDNS multicast group on 
interface lo.IPv6 with address ::1.
Oct  2 17:00:41 localhost syslogd: exiting on signal 15
[   70.670560] reboot: Power down
--8<---cut here---end--->8---

So 20s after a battery at 2% got plugged in, UPower told elogind to
turn off the VM, which told shepherd to do that—exactly as expected.

It’s kinda disappointing to debug something just to find out it’s
working as advertised.  I think the conclusion is that 2% is too low a
threshold, at least for my laptop, or maybe the charge estimate is
slightly off on my laptop.  I’ll raise that threshold and see if it
works correctly next time I run out of battery…

If someone has better ideas, I’d love to hear them!

Ludo’.

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Thu, 29 Sep 2022 at 23:10, Maxim Cournoyer  
> wrote:
>
>> Wholly agreed, this thread is already too long and the original problem
>> was fixed.  Closing.
>
> I disagree, the original problem is not fixed; as I explained.

What would you think of opening specific issues as I proposed, including
(I forgot that one) an issue on substitute preservation?

I was thinking that this could make it clearer what actions remain to be
taken.  WDYT?

Thanks,
Ludo’.

bug#58203: Cuirass fails to respect (target-x86-32?) in some circumstances

[Ludovic Courtès]

Marius Bakke  skribis:

> Hello,
>
> I noticed Cuirass attempts to run imath tests on i686-linux:
>
>   https://ci.guix.gnu.org/build/739643/details

Following the links, this corresponds to
, itself corresponding to commit
f5fe0082abe4547f3fb9f29d8351473cfb3a387b, which dates back to May.

So this is a recent build for an old commit; maybe it had been queued
for some time and just got unlocked today?  Weirdness.

The good news is that with today’s ‘staging’, everything’s fine:

--8<---cut here---start->8---
$ guix time-machine --commit=e0546a11f0b65e301dc9d1d1cfec26e686070029 -- 
weather imath -s i686-linux
computing 1 package derivations for i686-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  100.0% substitutes available (1 out of 1)
  at least 0.2 MiB of nars (compressed)
  0.9 MiB on disk (uncompressed)
  0.230 seconds per request (0.2 seconds in total)
  4.3 requests per second

[...]

$ guix time-machine --commit=e0546a11f0b65e301dc9d1d1cfec26e686070029 -- build 
imath -s i686-linux -d --no-grafts
/gnu/store/g31xfskliryh10gij1hidydykqk7bb6z-imath-3.1.3.drv
--8<---cut here---end--->8---

Thanks,
Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi,

Matthieu Haefele  skribis:

> (base) mhaefele@mdlspc113:work $ 
> /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
>
> guix-daemon (GNU Guix) 1.0.1

It’s indeed a pre-lzip version¹.

Normally, ‘guix’ commands have been printing a message reading “Your
Guix daemon is severely outdated […]”  since February 2022 when talking
to an old daemon.  Can you confirm this was the case?  (If not, we have
a bug in the deprecation machinery.)

¹ https://guix.gnu.org/en/blog/2019/gnu-guix-1.0.1-released/

> Updating the daemon triggers the same error wit "unsupported compression 
> scheme lzip"
>
> 
>
> (base) mhaefele@mdlspc113:work $ sudo -i guix pull

I would suggest doing a two-step upgrade; first upgrade to 1.3.0:

  sudo -i guix pull --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff

and follow the instructions at
.

After that you can optionally make the same operation to update to the
last commit in ‘master’.

HTH!

Ludo’.

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Ludovic Courtès]

Hi,

zimoun  skribis:

> This “meta” bug raises 2 levels of issues for long-term:
>
>  1. save the source code,
>  2. save the current binary substitutes.

Maybe we can close this bug and open an issue for each of these, or
discuss them on guix-devel until there are actionable items that come
out of it?

Or better yet: we could file more specific bugs such as “Disarchive
lacks bzip2 support” or “SWH integration does not support Subversion”.

Thoughts?

Ludo’.

bug#58084: guix deploy fails, leaving the newly installed system generation active

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Maxim Cournoyer  writes:
>
> [...]
>
>>> … which is fine, except that there was already a pre-existing
>>> /etc/modprobe.d directory (coming from openSuSE, the distro that was
>>> initially installed on this machine), which caused this activation code
>>> to break:
>>
>> Oh wow! Should we be extra careful and always rm files before linking to
>> their location?  Or define our own 'symlink' procedure that'd take care
>> of it?  That's not very elegant but better than obscure crashes like
>> this.
>
> I just had a better idea: fail and report that an unexpected file was
> found there, leaving the user to inspect it and choose a proper action.

Yeah, that’d be nice.  It’s really a corner case that you’ll only hit
when installing on a non-empty file system, but gracefully handling it
would be nice for sure.

Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi,

Matthieu Haefele  skribis:

> Well, I installed guix on my laptop (with ubuntu) the very standard
> way described on guix website. It was back in January 2020.

OK.  Lzip support was added sometime in 2019:
.

Could you try updating your daemon as described at:

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

Also, could you report the output of:

  /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version

before and after the upgrade?

Thanks in advance,
Ludo’.

bug#58149: guix pull error

[Ludovic Courtès]

Hi Matthieu & Simon,

zimoun  skribis:

>> (base) mhaefele@mdlspc113:work $ guix pull

[...]

>> guix/ui.scm:1747:12: In procedure run-guix-command:
>> unsupported compression scheme lzip

Matthieu, how did you install guix-daemon?

The daemon provided in the binary installation tarball at
 has supported lzip for a few years
already.  Likewise if you’re on Guix System.

So I suspect that’s a custom installation where lzip support is somehow
missing, which can be a problem (ci.guix.gnu.org dropped gzip,
supporting only zstd + lzip, back in February.)

Thanks,
Ludo’.

¹ https://guix.gnu.org/en/blog/2022/sunsetting-gzip-substitutes-availability/

bug#57978: bug#58017: [PATCH 0/2] Retry nar downloads upon failure

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

>   substitute: Split nar download.
>   substitute: Retry downloading when a nar is unavailable.

Pushed as 8bd4126917f59f4af9a4323c3d5699201862dca2.  The ‘guix’ package
has yet to be updated.

Thanks,
Ludo’.

bug#58036: kernel module not found "pata_acpi" in linux-libre-5.19.10

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Maxim Cournoyer  skribis:

[...]

>> gnu/build/linux-modules.scm:257:5: kernel module not found "pata_acpi" 
>> "/gnu/store/nmdy7c4i34y12w8af7zl6sl9fmrp8wa0-linux-libre-5.19.10/lib/modules"
>> builder for `/gnu/store/x9qdj37d6l2yacc73bx284ggj6vkhcdv-linux-modules.drv' 
>> failed with exit code 1
>
> This is the derivation made by ‘flat-linux-module-directory’ in (gnu
> system linux-initrd).
>
> How did you work around it?
>
> Normally “pata_acpi” is excluded from ‘%base-initrd-modules’ on
> aarch64.  However, since this relies on (%current-system), there could
> be situations where the trick doesn’t work as expected when deploying
> say from x86_64:

Fixed in 1033645e9d3899edd6b052b19e24c0a718b95e88.

We need system tests for ‘guix deploy’!

Ludo’.

bug#58044: Localization: "info guix" always shows the manual in English regardless of the user locale

[Ludovic Courtès]

Hi,

Luis Felipe  skribis:

>> https://lists.gnu.org/archive/html/bug-texinfo/2019-05/msg00011.html
>> 
>
>> is relevant.
>
> Thanks for the info, Florian, I had no idea about that :)

Your expectations are legitimate though; I think it’d be worth bringing
it up again on bug-texi...@gnu.org if you feel so inclined.

There’s not much that can be done on the Guix side so I’ll close it
here.

Thanks,
Ludo’.

bug#58048: The boot process can't delete old /tmp when it contains non-UTF-8 file names

[Ludovic Courtès]

Maxime Devos  skribis:

> On 24-09-2022 23:12, Maxime Devos wrote:
>> Will try to catch the exact warning message and write a reproducer
>> at the next boot, for now I write it here before I forget about it.
>
> Two reproducers:
>
> (1) Compile ripgrep and somehow let it fail (but after it creates
> non-UTF-8 file names), reboot, "ls /tmp"
> (2) Run touch /tmp/OOPS-$(echo -e '\xff')-OOPS, reboot, "ls /tmp"

The culprit would be ‘cleanup-gexp’ in (gnu services).  It keeps going
upon ‘system-error’ (like ENOENT), but it could be that you’re getting
‘encoding-error’ in this case.

In that case, ‘fail-safe’ should also catch this.

We can extend ‘%test-cleanup’ in (gnu tests base) to exercise this.

Would you like to give it a spin?

Ludo’.

bug#58084: guix deploy fails, leaving the newly installed system generation active

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> While attempting to deploy to overdrive1, using the 9971141 commit in
> the maintenance repo, I encountered the following error:
>
> maxim@hurd ~/src/guix-maintenance/hydra$ guix time-machine 
> --commit=08d515233241ee0921b8b5ab706f98170c62437c -- deploy -L modules 
> deploy-overdrive1.scm
> The following 1 machine will be deployed:
>   overdrive1
>
> guix deploy: deploying to overdrive1...
> guix deploy: sending 0 store items (0 MiB) to 'overdrive1.guix.gnu.org'...
> guix deploy: sending 0 store items (0 MiB) to 'overdrive1.guix.gnu.org'...
> guix deploy: sending 0 store items (0 MiB) to 'overdrive1.guix.gnu.org'...
> guix deploy: error: failed to deploy overdrive1: failed to switch systems 
> while deploying 'overdrive1':
> system-error "symlink" "~A" ("File exists") (17)

I can reproduce it.

The failing code is in /gnu/store/…-switch-to-system.scm:

--8<---cut here---start->8---
(begin
  (use-modules
   (guix config)
   (guix profiles)
   (guix utils))
  (define profile
(or #f
(string-append %state-directory "/profiles/system")))
  (let*
  ((number
(#{1+}
 #
 (generation-number profile)))
   (generation
(generation-file-name profile number)))
(switch-symlinks generation 
"/gnu/store/kifxq4hmp4ihn6nb06ia8wms33qrndxn-system")
(switch-symlinks profile generation)
(setenv "GUIX_NEW_SYSTEM" 
"/gnu/store/kifxq4hmp4ihn6nb06ia8wms33qrndxn-system")
(primitive-load 
"/gnu/store/1wdwlaqkmixb1d7by7fj23lxppw8x44r-activate.scm")))
--8<---cut here---end--->8---

We can run it manually to get debugging data:

--8<---cut here---start->8---
ludo@overdrive1 ~$ sudo -E env -i COLUMNS=100  
"/gnu/store/xv7j4im9ap92mv0mbsm1wa4px93zxrms-switch-to-system.scm"
making '/gnu/store/kifxq4hmp4ihn6nb06ia8wms33qrndxn-system' the current 
system...
WARNING: (guile-user): imported module (guix build utils) overrides core 
binding `delete'
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/hf3qxlaiajvapwis0lq20avgl2whfa5w-etc...
Backtrace:
   6 (primitive-load 
"/gnu/store/xv7j4im9ap92mv0mbsm1wa4px93zxrms-switch-to-system.scm")
   5 (primitive-load 
"/gnu/store/1wdwlaqkmixb1d7by7fj23lxppw8x44r-activate.scm")
In ice-9/boot-9.scm:
   260:13  4 (for-each # _)
In unknown file:
   3 (primitive-load 
"/gnu/store/v03vaksmkpj7wv4dhm0yrd3y65lzbixz-activate-service.scm")
In srfi/srfi-1.scm:
634:9  2 (for-each # _)
In gnu/build/activation.scm:
   267:20  1 (_ "modprobe.d")
In unknown file:
   0 (symlink "/etc/static/modprobe.d" "/etc/modprobe.d")

ERROR: In procedure symlink:
In procedure symlink: File exists
--8<---cut here---end--->8---

This is because ‘zram-device-service-type’ contributes a file to
/etc/modprobe.d:

--8<---cut here---start->8---
(define %zram-device-config
  `("modprobe.d/zram.conf"
,(plain-file "zram.conf"
 "options zram num_devices=1")))

(define zram-device-service-type
  (service-type
(name 'zram)
(default-value (zram-device-configuration))
(extensions
  (list (service-extension kernel-module-loader-service-type
   (const (list "zram")))
(service-extension etc-service-type
   (const (list %zram-device-config)))
(service-extension udev-service-type
   (compose list zram-device-udev-rule
(description "Creates a zram swap device.")))
--8<---cut here---end--->8---

… which is fine, except that there was already a pre-existing
/etc/modprobe.d directory (coming from openSuSE, the distro that was
initially installed on this machine), which caused this activation code
to break:

--8<---cut here---start->8---
ludo@overdrive1 ~$ ls -l /etc/modprobe.d
total 36
-rw-r--r-- 1 root root 3221 Nov  6  2016 00-system.conf
-rw-r--r-- 1 root root  532 Nov 14  2012 10-unsupported-modules.conf
-rw-r--r-- 1 root root  181 May  5  2017 50-alsa.conf
-rw-r--r-- 1 root root 5009 Sep 15  2016 50-blacklist.conf
-rw-r--r-- 1 root root  128 Oct 12  2017 50-bluetooth.conf
-rw-r--r-- 1 root root   33 Oct 20  2016 50-ipw2200.conf
-rw-r--r-- 1 root root   34 Oct 20  2016 50-iwl3945.conf
-rw-r--r-- 1 root root   47 Nov 22  2011 99-local.conf
ludo@overdrive1 ~$ ls -ld /etc/modprobe.d
drwxr-xr-x 1 root root 260 Jan 29  2018 /etc/modprobe.d/
--8<---cut here---end--->8---

Once moved out of the way, reconfiguration proceeds just fine and
happiness ensues:

--8<---cut here---start->8---
ludo@overdrive1 ~$ ls -l /etc/modprobe.d
lrwxrwxrwx 1 root root 22 Sep 26 17:19 /etc/modprobe.d -> /etc/static/modprobe.d
ludo@overdrive1 

bug#58036: kernel module not found "pata_acpi" in linux-libre-5.19.10

[Ludovic Courtès]

Maxim Cournoyer  skribis:

>>> gnu/build/linux-modules.scm:257:5: kernel module not found "pata_acpi" 
>>> "/gnu/store/nmdy7c4i34y12w8af7zl6sl9fmrp8wa0-linux-libre-5.19.10/lib/modules"
>>> builder for `/gnu/store/x9qdj37d6l2yacc73bx284ggj6vkhcdv-linux-modules.drv' 
>>> failed with exit code 1
>>
>> This is the derivation made by ‘flat-linux-module-directory’ in (gnu
>> system linux-initrd).
>>
>> How did you work around it?
>
> I had to use the previous version of the latest linux-libre kernel, by
> using this commit:
>
> $ guix time-machine --commit=08d515233241ee0921b8b5ab706f98170c62437c -- \
> deploy -L modules deploy-overdrive1.scm

OK.  I wonder if it’s just luck, because on another run with the same
revision I’m now hitting it.  It might relate to
.

> There's currently no '--allow-downgrades' for 'guix deploy'.

There’s the ‘allow-downgrades?’ field of ‘machine-ssh-configuration’,
but sh!  (info "(guix) Invoking guix deploy")

Ludo’.

bug#58036: kernel module not found "pata_acpi" in linux-libre-5.19.10

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> While attempting to reconfigure the overdrive1 aarch64 machine, I got:
>
> substitute: ^Msubstitute: ESC[Kupdating substitutes from 
> 'https://ci.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes 
> from 'https://ci.guix.gnu.org'... 100.0%
> @ build-started /gnu/store/x9qdj37d6l2yacc73bx284ggj6vkhcdv-linux-modules.drv 
> - aarch64-linux 
> /var/log/guix/drvs/x9//qdj37d6l2yacc73bx284ggj6vkhcdv-linux-modules.drv.gz 
> 31574
> Backtrace:
> In ice-9/eval.scm:
> 619:8 19 (_ #f)
>626:19 18 (_ #)
>293:34 17 (_ #(# #))
> In srfi/srfi-1.scm:
>586:29 16 (map1 _)
>586:29 15 (map1 _)
>586:29 14 (map1 _)
>586:29 13 (map1 _)
>586:29 12 (map1 _)
>586:29 11 (map1 _)
>586:29 10 (map1 _)
>586:29  9 (map1 _)
>586:29  8 (map1 _)
>586:29  7 (map1 _)
>586:29  6 (map1 _)
>586:29  5 (map1 _)
>586:29  4 (map1 _)
>586:29  3 (map1 _)
>586:29  2 (map1 _)
>586:17  1 (map1 ("pata_acpi" "pata_atiixp" "isci" "virtio_pci" # ?))
> In gnu/build/linux-modules.scm:
> 257:5  0 (_)
>
> gnu/build/linux-modules.scm:257:5: kernel module not found "pata_acpi" 
> "/gnu/store/nmdy7c4i34y12w8af7zl6sl9fmrp8wa0-linux-libre-5.19.10/lib/modules"
> builder for `/gnu/store/x9qdj37d6l2yacc73bx284ggj6vkhcdv-linux-modules.drv' 
> failed with exit code 1

This is the derivation made by ‘flat-linux-module-directory’ in (gnu
system linux-initrd).

How did you work around it?

Normally “pata_acpi” is excluded from ‘%base-initrd-modules’ on
aarch64.  However, since this relies on (%current-system), there could
be situations where the trick doesn’t work as expected when deploying
say from x86_64:

--8<---cut here---start->8---
(define* (default-initrd-modules
   #:optional
   (system (or (%current-target-system)
   (%current-system
;; [...]

,@(if (string-match "^(x86_64|i[3-6]86)-" system)
  '("pata_acpi" "pata_atiixp";for ATA controllers
"isci")  ;for SAS controllers like Intel C602
  '())

,@virtio-modules))

(define-syntax %base-initrd-modules
  ;; This more closely matches our naming convention.
  (identifier-syntax (default-initrd-modules)))
--8<---cut here---end--->8---

I tried just now and did not reproduce it:

--8<---cut here---start->8---
$ guix describe
Generation 229  Sep 25 2022 23:42:53(current)
  guix ab69314
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: ab6931483be544b7debb9496f694b593af7e0c0f
$ guix deploy -L modules deploy-overdrive1.scm
The following 1 machine will be deployed:
  overdrive1

guix deploy: deploying to overdrive1...

[…]

guix deploy: sending 0 store items (0 MiB) to 'overdrive1.guix.gnu.org'...
guix deploy: error: failed to deploy overdrive1: failed to switch systems while 
deploying 'overdrive1.guix.gnu.org':
system-error "symlink" "~A" ("File exists") (17) 
--8<---cut here---end--->8---

(But as you can see, I did reproduce that other bug you reported.  :-))

Ludo’.

bug#57922: Shepherd doesn't seem to correctly handle waitpid itself

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> Maxim Cournoyer  writes:
>
>> This leads me to believe that Shepherd does not block until the process
>> is actually dead to mark the process as stopped (it just waitpid on the
>> group pid with WNOHANG), which means it won't block if the child process
>> hasn't exited yet, if I'm correct.

Correct: the service is marked as stopped as soon as ‘stop’ returns.

>> When we are in the stop slot, we know for sure that the process should
>> terminate completely, hence it'd make sense to call 'waitpid' *without*
>> WNOHANG there, to avoid 'herd restart' from starting the service while
>> its stopped process is not done terminating.
>>
>> jamid can take quite some time to terminate cleanly because of the
>> networking threads in the opendht library that needs to be finalized,
>> which is probably the reason this problem can be observed here.
>>
>> Thoughts?
>
> I agree with you, make-kill-destructor should waitpid the processes it's
> killing.  There shouldn't be any issues waitpid'ing before the
> shepherd's signal handler, since stop actions are run with asyncs
> disabled.  The signal handler will run once but won't get anything
> because all the processes were already waitpid'd and it uses WNOHANG.

I think we need an extra “stopping” state for services.  In general,
we’ll want to send SIGTERM, wait for some grace period or dead process
notification, then send SIGKILL, and finally change state to “stopped”.

This is not possible in 0.9 but is something I’d like to have in 0.10¹.

Ludo’.

¹ https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html

bug#57978: [bug#58017] [PATCH 2/2] substitute: Retry downloading when a nar is unavailable.

[Ludovic Courtès]

Hi Maxime,

Maxime Devos  skribis:

>> +(test-equal "substitute, first URL has narinfo but nar is 404, both URLs 
>> authorized"
>> +  "Substitutable data."
>> +  (with-narinfo*
>> +  (string-append %narinfo "Signature: "
>> + (signature-field %narinfo))
>> +  %main-substitute-directory
>> +
>> +(with-http-server `((200 ,(string-append %narinfo "Signature: "
>> + (signature-field %narinfo)))
>> +(404 "Sorry, nar is missing!"))
>> +  (dynamic-wind
>> +(const #t)
>> +(lambda ()
>> +  (parameterize ((substitute-urls
>> +  (list (%local-url)
>> +(string-append "file://"
>> +   
>> %main-substitute-directory
>> +(request-substitution (string-append (%store-prefix)
>> + 
>> "/-foo")
>> +  "substitute-retrieved"))
>> +  (call-with-input-file "substitute-retrieved" get-string-all))
>> +(lambda ()
>> +  (false-if-exception (delete-file "substitute-retrieved")))
>
> Shouldn't it only ignore 'file not found' (ENOENT?) exceptions?

By “it”, do you mean ‘dynamic-wind’ should be replaced by a ‘catch’
form?

We could discuss it, but note that this patch just keeps with the style
of existing tests.

> This test, and some others, can be improved by also checking the
> URI. While currently 'with-http-server' does not support that, there
> are (5 months, with the v1 having seen some reviewing and a v2
> available) patches for that at .
>
> That patch also _requires_ always mentioning the URI, if the cover
> letter is correct.  It also allows simplifying the use of '%local-url'
> a bit.

Ah, thanks for the reminder!  I’ve just spent most of the day reviewing
patches, but not that one…

Ludo’.

bug#57978: [PATCH 2/2] substitute: Retry downloading when a nar is unavailable.

[Ludovic Courtès]

Hi!

zimoun  skribis:

>> +  (with-narinfo*
>> +  (string-append %narinfo "Signature: "
>> + (signature-field
>> +  %narinfo
>> +  #:public-key %wrong-public-key))
>> +  %main-substitute-directory
>> +
>> +(with-http-server `((200 ,(string-append %narinfo "Signature: "
>> + (signature-field
>> +  %narinfo
>> +  #:public-key 
>> %wrong-public-key)))
>> +(404 "Sorry, nar is missing!"))
>> +  (let ((url1 (%local-url)))
>> +(parameterize ((%http-server-port 0))
>> +  (with-http-server `((200 ,(string-append %narinfo "Signature: "
>> +   (signature-field 
>> %narinfo)))
>> +  (404 "Sorry, nar is missing!"))
>> +(let ((url2 (%local-url)))
>> +  (dynamic-wind
>> +(const #t)
>> +(lambda ()
>> +  (parameterize ((substitute-urls
>> +  (list url1 url2
>> +(string-append "file://"
>> +   
>> %main-substitute-directory

[...]

> Although I do not understand this test.  Why is 404 appearing twice?

That’s because it’s testing with 3 substitute URLs.

Thanks for taking a look!

Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi!

All things considered, I prefer to drop this patch.  In the unlikely
event that we’ll get more requests to support these curves, we can
always revisit the issue.

What we should do, though, is improve error reporting in case an
unsupported curve or algorithm is encountered.

Thanks,
Ludo’.

bug#57217: home-openssh-service-type creates .ssh/config with wrong permissions

[Ludovic Courtès]

Ludovic Courtès  skribis:

> To address the issue at hand, we would need to map UID 0 of the host as
> UID 0 of the guest, but I’m not sure this can be done.

I believe it cannot be done: we can only map a single UID (at least
unless/until we use subordinate UIDs.)

Back to the original problem: it only affects ‘guix home container’; so
while this is annoying, it’s not a showstopper.  WDYT?

Ludo’.

bug#58031: LibreOffice 7.3.5.2 is not reproducible

[Ludovic Courtès]

There’s a single file that differs:

--8<---cut here---start->8---
$ guix describe
Generation 228  Sep 12 2022 08:17:50(current)
  guix e3ed1d0
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e3ed1d09f9d490eff6becd6e9cb85a4d36c48e85
$ guix challenge libreoffice
/gnu/store/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2 contents differ:
  no local build for 
'/gnu/store/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2'
  
https://ci.guix.gnu.org/nar/lzip/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2:
 1hp4dknx01s2lylf0bfagfvf04naaayrhyjbwa5l2iv0vqxdbcx8
  
https://bordeaux.guix.gnu.org/nar/lzip/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2:
 10vraihz73428z453wj7546ic98bkv3mkdr5222lg6grrfc49rp3
  differing file:
/lib/libreoffice/share/template/common/draw/bpmn.otg

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
--8<---cut here---end--->8---

It’s apparently a zip file and the difference lies in mtimes:

--8<---cut here---start->8---
$ guix challenge libreoffice --diff=diffoscope
/gnu/store/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2 contents differ:
  no local build for 
'/gnu/store/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2'
  
https://ci.guix.gnu.org/nar/lzip/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2:
 1hp4dknx01s2lylf0bfagfvf04naaayrhyjbwa5l2iv0vqxdbcx8
  
https://bordeaux.guix.gnu.org/nar/lzip/652zk4gzcnwpq90lbzvr1gk5q2p3flf7-libreoffice-7.3.5.2:
 10vraihz73428z453wj7546ic98bkv3mkdr5222lg6grrfc49rp3
 bordeaux.guix.gnu.org  125.3MiB   10.5MiB/s 00:12 
[##] 100.0%--- /tmp/guix-directory.7C81ON
+++ /tmp/guix-directory.n0WtkB
│   --- /tmp/guix-directory.7C81ON/lib
├── +++ /tmp/guix-directory.n0WtkB/lib
│ │   --- /tmp/guix-directory.7C81ON/lib/libreoffice
│ ├── +++ /tmp/guix-directory.n0WtkB/lib/libreoffice
│ │ │   --- /tmp/guix-directory.7C81ON/lib/libreoffice/share
│ │ ├── +++ /tmp/guix-directory.n0WtkB/lib/libreoffice/share
│ │ │ │   --- /tmp/guix-directory.7C81ON/lib/libreoffice/share/template
│ │ │ ├── +++ /tmp/guix-directory.n0WtkB/lib/libreoffice/share/template
│ │ │ │ │   --- /tmp/guix-directory.7C81ON/lib/libreoffice/share/template/common
│ │ │ │ ├── +++ /tmp/guix-directory.n0WtkB/lib/libreoffice/share/template/common
│ │ │ │ │ │   --- 
/tmp/guix-directory.7C81ON/lib/libreoffice/share/template/common/draw
│ │ │ │ │ ├── +++ 
/tmp/guix-directory.n0WtkB/lib/libreoffice/share/template/common/draw
│ │ │ │ │ │ │   --- 
/tmp/guix-directory.7C81ON/lib/libreoffice/share/template/common/draw/bpmn.otg
│ │ │ │ │ │ ├── +++ 
/tmp/guix-directory.n0WtkB/lib/libreoffice/share/template/common/draw/bpmn.otg
│ │ │ │ │ │ │ ├── zipinfo {}
│ │ │ │ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ │ │ │  Zip file size: 36563 bytes, number of entries: 6
│ │ │ │ │ │ │ │ --rw-r--r--  3.0 unx   52 b- stor 22-Aug-29 17:52 mimetype
│ │ │ │ │ │ │ │ --rw-r--r--  3.0 unx   281529 t- defN 22-Aug-29 17:52 
content.xml
│ │ │ │ │ │ │ │ --rw-r--r--  3.0 unx  711 t- defN 22-Aug-29 17:52 
META-INF/manifest.xml
│ │ │ │ │ │ │ │ --rw-r--r--  3.0 unx 1096 t- defN 22-Aug-29 17:52 meta.xml
│ │ │ │ │ │ │ │ --rw-r--r--  3.0 unx25395 t- defN 22-Aug-29 17:52 styles.xml
│ │ │ │ │ │ │ │ --rw-r--r--  3.0 unx 4680 b- defN 22-Aug-29 17:52 
Thumbnails/thumbnail.png
│ │ │ │ │ │ │ │ +-rw-r--r--  3.0 unx   52 b- stor 22-Aug-16 02:46 mimetype
│ │ │ │ │ │ │ │ +-rw-r--r--  3.0 unx   281529 t- defN 22-Aug-16 02:46 
content.xml
│ │ │ │ │ │ │ │ +-rw-r--r--  3.0 unx  711 t- defN 22-Aug-16 02:46 
META-INF/manifest.xml
│ │ │ │ │ │ │ │ +-rw-r--r--  3.0 unx 1096 t- defN 22-Aug-16 02:46 meta.xml
│ │ │ │ │ │ │ │ +-rw-r--r--  3.0 unx25395 t- defN 22-Aug-16 02:46 styles.xml
│ │ │ │ │ │ │ │ +-rw-r--r--  3.0 unx 4680 b- defN 22-Aug-16 02:46 
Thumbnails/thumbnail.png
│ │ │ │ │ │ │ │  6 files, 313463 bytes uncompressed, 35921 bytes compressed:  
88.5%

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
--8<---cut here---end--->8---

We could add a phase that resets timestamps in the zip file, or we could
tweak the build process that produces it.

Ludo’.

bug#57217: home-openssh-service-type creates .ssh/config with wrong permissions

[Ludovic Courtès]

Hi Elias,

Elias Kueny  skribis:

> The files are created with too open permissions, so ssh refuses to run:
>
>  $ ssh xxx
>  Bad owner or permissions on ~/.ssh/config
>
>  $ ls -l .ssh
>  lrwxrwxrwx 1 user users 59 Aug 14 18:17 authorized_keys -> 
> /gnu/store/y8g2d9kmlrhfna23r26cfgp5mr1sxl72-authorized_keys
>  lrwxrwxrwx 1 user users  52 Aug 14 18:17 config -> 
> /gnu/store/dnnzwrz4hp1z6wnr76a6j57v95vyrbf3-ssh.conf

Here’s what I see in a container:

--8<---cut here---start->8---
$ ls -ld .ssh
drwx-- 2 ludo users 80 Sep 23 06:39 .ssh/
$ ls -l .ssh/config
lrwxrwxrwx 1 ludo users 52 Sep 23 06:39 .ssh/config -> 
/gnu/store/5lksmnx3mlyinlja2lhd84p0jkp06bg5-ssh.conf
$ ls -l $(readlink .ssh/config)
-r--r--r-- 1 65534 overflow 6219 Jan  1  1970 
/gnu/store/5lksmnx3mlyinlja2lhd84p0jkp06bg5-ssh.conf
--8<---cut here---end--->8---

The relevant check in OpenSSH is this:

--8<---cut here---start->8---
  if (fstat(fileno(f), ) == -1)
  fatal("fstat %s: %s", filename, strerror(errno));
  if (((sb.st_uid != 0 && sb.st_uid != getuid()) ||
  (sb.st_mode & 022) != 0))
  fatal("Bad owner or permissions on %s", filename);
--8<---cut here---end--->8---

That is, if ~/.ssh/config is owned by root, it’s fine; and this is
exactly what happens outside the container:

--8<---cut here---start->8---
$ ls -l $(readlink ~/.ssh/config)
-r--r--r-- 1 root root 6219 Jan  1  1970 
/gnu/store/5lksmnx3mlyinlja2lhd84p0jkp06bg5-ssh.conf
--8<---cut here---end--->8---

So ‘ssh’ works fine outside the container, but not inside.

To address the issue at hand, we would need to map UID 0 of the host as
UID 0 of the guest, but I’m not sure this can be done.

To be continued…

Ludo’.

bug#57922: Shepherd doesn't seem to correctly handle waitpid itself

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> Maxim Cournoyer  writes:

[...]

>> 1. It requires to be installed in the signal handlers for each
>> processes, with something like:
>>
>> --8<---cut here---start->8---
>>   (unless %sigchld-handler-installed?
>> (sigaction SIGCHLD handle-SIGCHLD SA_NOCLDSTOP)
>> (set! %sigchld-handler-installed? #t))
>> --8<---cut here---end--->8---
>>
>> Done for fork+exec-command and make-inetd-forkexec-constructor, but not
>> for make-forkexec-constructor/container, AFAICT;
>
> The signal handler is only installed once in PID 1 (in fact, you haven't
> forked yet here), since it's the one that receives the SIGCHLD.

Right.

> What I don't understand that well is that this signal handler could be
> installed only once when shepherd starts, right?  That way, it wouldn't
> need to depend on specific start actions being chosen.

The SIGCHLD handler is installed lazily since
f776de04e6702e18d95152072e78c43441d3ccc3.  The rationale was discussed
here:

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

That said, on GNU/Linux, SIGCHLD is actually blocked and instead we rely
on signalfd(2).  It’s from the main even loop in shepherd.scm that the
signal handler is called.

>> Here's a small reproducer to apply on our code base:
>>
>> --8<---cut here---start->8---
>> modified   gnu/services/telephony.scm
>> @@ -685,13 +685,7 @@ (define (archive-name->username archive)
>>  
>>  ;; Finally, return the PID of the daemon process.
>>  daemon-pid))
>> -   (stop
>> -#~(lambda (pid . args)
>> -(kill pid SIGKILL)
>> -;; Wait for the process to exit; this prevents 
>> overlapping
>> -;; processes when issuing 'herd restart'.
>> -(waitpid pid)
>> -#f
>> +   (stop #~(make-kill-destructor

I think the main difference between these two is that the first one uses
SIGKILL while the second one uses SIGTERM.

You could try #~(make-kill-destructor SIGKILL) to get the same effect.

(Another difference is that ‘make-kill-destructor’ kills the process
group, not just the process itself.)

Anyway, the key point is that shepherd takes care of calling ‘waitpid’
for its child processes (services).  If you call it yourself as in the
snippet above, you’re racing with shepherd; in the case above it
probably doesn’t make any difference though because it will consider
that the service is stopped in any case.

HTH!

Ludo’.

bug#57978: [PATCH 2/2] substitute: Retry downloading when a nar is unavailable.

[Ludovic Courtès]

Fixes 
Reported by Attila Lendvai .

Previously, if a narinfo was available but its corresponding nar was
missing (for instance because the narinfo was cached and the server
became unreachable in the meantime), 'guix substitute --substitute'
would try to download the nar from its preferred location and abort when
that fails.  This change forces one retry with each of the URLs.

* guix/scripts/substitute.scm (download-nar): Do not catch
'http-get-error?' exceptions.
(system-error?, network-error?, process-substitution/fallback): New
procedures.
(process-substitution): Call 'process-substitution/fallback' upon
'network-error?'.
* tests/substitute.scm ("substitute, first URL has narinfo but lacks nar, 
second URL unauthorized")
("substitute, first URL has narinfo but nar is 404, both URLs authorized")
("substitute, first URL has narinfo but nar is 404, one URL authorized")
("substitute, narinfo is available but nar is missing"): New tests.
---
 guix/scripts/substitute.scm | 113 
 tests/substitute.scm| 113 
 2 files changed, 203 insertions(+), 23 deletions(-)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index e3b382d0d8..cf59db4315 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -460,25 +460,20 @@ (define (fetch uri)
(let ((port (open-file (uri-path uri) "r0b")))
  (values port (stat:size (stat port)
   ((http https)
-   (guard (c ((http-get-error? c)
-  (leave (G_ "download from '~a' failed: ~a, ~s~%")
- (uri->string (http-get-error-uri c))
- (http-get-error-code c)
- (http-get-error-reason c
- ;; Test this with:
- ;;   sudo tc qdisc add dev eth0 root netem delay 1500ms
- ;; and then cancel with:
- ;;   sudo tc qdisc del dev eth0 root
- (with-timeout %fetch-timeout
-   (begin
- (warning (G_ "while fetching ~a: server is somewhat slow~%")
-  (uri->string uri))
- (warning (G_ "try `--no-substitutes' if the problem persists~%")))
-   (with-cached-connection uri port
- (http-fetch uri #:text? #f
- #:port port
- #:keep-alive? #t
- #:buffered? #f)
+   ;; Test this with:
+   ;;   sudo tc qdisc add dev eth0 root netem delay 1500ms
+   ;; and then cancel with:
+   ;;   sudo tc qdisc del dev eth0 root
+   (with-timeout %fetch-timeout
+ (begin
+   (warning (G_ "while fetching ~a: server is somewhat slow~%")
+(uri->string uri))
+   (warning (G_ "try `--no-substitutes' if the problem persists~%")))
+ (with-cached-connection uri port
+   (http-fetch uri #:text? #f
+   #:port port
+   #:keep-alive? #t
+   #:buffered? #f
   (else
(leave (G_ "unsupported substitute URI scheme: ~a~%")
   (uri->string uri)
@@ -572,6 +567,68 @@ (define cpu-usage
 (bytevector->nix-base32-string expected)
 (bytevector->nix-base32-string actual)))
 
+(define system-error?
+  (let ((kind-and-args? (exception-predicate )))
+(lambda (exception)
+  "Return true if EXCEPTION is a Guile 'system-error exception."
+  (and (kind-and-args? exception)
+   (eq? 'system-error (exception-kind exception))
+
+(define network-error?
+  (let ((kind-and-args? (exception-predicate )))
+(lambda (exception)
+  "Return true if EXCEPTION denotes a networking error."
+  (or (and (system-error? exception)
+   (let ((errno (system-error-errno
+ (cons 'system-error (exception-args exception)
+ (memv errno (list ECONNRESET ECONNABORTED
+   ECONNREFUSED EHOSTUNREACH
+   ENOENT ;for "file://"
+  (and (kind-and-args? exception)
+   (memq (exception-kind exception)
+ '(gnutls-error getaddrinfo-error)))
+  (and (http-get-error? exception)
+   (begin
+ (warning (G_ "download from '~a' failed: ~a, ~s~%")
+  (uri->string (http-get-error-uri exception))
+  (http-get-error-code exception)
+  (http-get-error-reason exception))
+ #t))
+
+(define* (process-substitution/fallback port narinfo destination
+#:key cache-urls acl
+deduplicate? print-build-trace?)
+  "Attempt to substitute NARINFO, which is assumed to be authorized or
+equivalent, by trying to download its nar from each entry in 

bug#57978: [PATCH 1/2] substitute: Split nar download.

[Ludovic Courtès]

* guix/scripts/substitute.scm (download-nar): New procedure, with most
of the code moved from...
(process-substitution): ... here.  Call it.
---
 guix/scripts/substitute.scm | 52 +++--
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index cdf591ac4d..e3b382d0d8 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -437,20 +437,13 @@ (define-syntax-rule (with-cached-connection uri port exp 
...)
   "Bind PORT with EXP... to a socket connected to URI."
   (call-with-cached-connection uri (lambda (port) exp ...)))
 
-(define* (process-substitution port store-item destination
-   #:key cache-urls acl
-   deduplicate? print-build-trace?)
-  "Substitute STORE-ITEM (a store file name) from CACHE-URLS, and write it to
-DESTINATION as a nar file.  Verify the substitute against ACL, and verify its
-hash against what appears in the narinfo.  When DEDUPLICATE? is true, and if
-DESTINATION is in the store, deduplicate its files.  Print a status line to
-PORT."
-  (define narinfo
-(lookup-narinfo cache-urls store-item
-(if (%allow-unauthenticated-substitutes?)
-(const #t)
-(cut valid-narinfo? <> acl
-
+(define* (download-nar narinfo destination
+   #:key status-port
+   deduplicate? print-build-trace?)
+  "Download the nar prescribed in NARINFO, which is assumed to be authentic
+and authorized, and write it to DESTINATION.  When DEDUPLICATE? is true, and
+if DESTINATION is in the store, deduplicate its files.  Print a status line to
+STATUS-PORT."
   (define destination-in-store?
 (string-prefix? (string-append (%store-prefix) "/")
 destination))
@@ -490,10 +483,6 @@ (define (fetch uri)
(leave (G_ "unsupported substitute URI scheme: ~a~%")
   (uri->string uri)
 
-  (unless narinfo
-(leave (G_ "no valid substitute for '~a'~%")
-   store-item))
-
   (let ((uri compression file-size
  (narinfo-best-uri narinfo
#:fast-decompression?
@@ -575,14 +564,37 @@ (define cpu-usage
   (let ((actual (get-hash)))
 (if (bytevector=? actual expected)
 ;; Tell the daemon that we're done.
-(format port "success ~a ~a~%"
+(format status-port "success ~a ~a~%"
 (narinfo-hash narinfo) (narinfo-size narinfo))
 ;; The actual data has a different hash than that in NARINFO.
-(format port "hash-mismatch ~a ~a ~a~%"
+(format status-port "hash-mismatch ~a ~a ~a~%"
 (hash-algorithm-name algorithm)
 (bytevector->nix-base32-string expected)
 (bytevector->nix-base32-string actual)))
 
+(define* (process-substitution port store-item destination
+   #:key cache-urls acl
+   deduplicate? print-build-trace?)
+  "Substitute STORE-ITEM (a store file name) from CACHE-URLS, and write it to
+DESTINATION as a nar file.  Verify the substitute against ACL, and verify its
+hash against what appears in the narinfo.  When DEDUPLICATE? is true, and if
+DESTINATION is in the store, deduplicate its files.  Print a status line to
+PORT."
+  (define narinfo
+(lookup-narinfo cache-urls store-item
+(if (%allow-unauthenticated-substitutes?)
+(const #t)
+(cut valid-narinfo? <> acl
+
+  (unless narinfo
+(leave (G_ "no valid substitute for '~a'~%")
+   store-item))
+
+  (download-nar narinfo destination
+#:status-port port
+#:deduplicate? deduplicate?
+#:print-build-trace? print-build-trace?))
+
 
 ;;;
 ;;; Entry point.
-- 
2.37.3

bug#57978: [PATCH 0/2] Retry nar downloads upon failure

[Ludovic Courtès]

Hello!

This is a long overdue fix for <https://issues.guix.gnu.org/57978>:
when a nar cannot be downloaded from its “preferred” location,
‘guix substitute --substitute’ will now retry once for each substitute
URL instead of failing right away.

This should address the most common issues such as transient
networking failures.

Comments?

Thanks,
Ludo’.

Ludovic Courtès (2):
  substitute: Split nar download.
  substitute: Retry downloading when a nar is unavailable.

 guix/scripts/substitute.scm | 157 +++-
 tests/substitute.scm| 113 ++
 2 files changed, 231 insertions(+), 39 deletions(-)


base-commit: a09655b20850d065333ec333e6e184b604f606a8
-- 
2.37.3

bug#57978: the fallback machanism for substitute servers doesn't work?

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> guix substitute: warning: ci.guix.gnu.org: connection failed: No route to host
>  qemu-minimal-7.1.0-doc  3.4MiB   
>876.6MiB/s 00:00 
> [##] 100.0%
> guix substitute: error: connect*: No route to host
> substitution of 
> /gnu/store/7czrnkybr466v69wdj6i2sn6vpsg0ks3-cdrkit-libre-1.1.11 failed
> guix system: error: corrupt input while restoring archive from # 7f37458bd000>

I observed the same yesterday when ci.guix was down.

Note that the following command, where 203.* is unroutable, does not
reproduce it:

  guix build --substitute-urls="http://203.0.113.1 https://ci.guix.gnu.org; \
--no-grafts pandoc# pick a package not in store

So I believe what we experienced yesterday goes along these lines:

  1. We had cached narinfos for ci.guix available locally so the daemon
 assumed it could go ahead and download from ci.guix;

  2. When ‘guix substitute --substitute’ when to download stuff from
 ci.guix, which it assumed was possible because there was a valid
 narinfo for that, it didn’t handle the connection failure.  (The
 same happens if you get, say, 404 while substituting even though
 you have a valid substitute at hand.)

Trying to come up with a fix…

Ludo’.

bug#57827: Shepherd 0.9.2 possible regressions

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> Regarding those four, I was able to reproduce the issue this way:
>
> $ guix repl
> (stop-service 'guix-daemon)
> (start-service 'guix-daemon (list (number->string (getpid

Or from the shell:

  herd stop guix-daemon
  herd start guix-daemon $$

I was able to reproduce it using a bare-bones.tmpl VM.

> The latter command hangs and Shepherd becomes unresponsive.  I collected
> an (attached) strace dump of Shepherd showing that there is no response
> on the socket when the service is started.
>
> Note that, this works:
>
> $ guix repl
> (stop-service 'guix-daemon)
> (start-service 'guix-daemon) 
>
> So the problem could be caused by the "container-excursion*" in the
> "fork+exec-command/container" procedure.

PID 1 gets stuck on read(16, …) forever, after reading the string “2866”
(a PID):

--8<---cut here---start->8---
[pid  2865] clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process 2866 
attached
, child_tidptr=0x7fccfbe00a10) = 2866
[pid  2866] set_robust_list(0x7fccfbe00a20, 24) = 0
[pid  2866] close(3)= 0
[pid  2865] write(39, "2866", 4 
[pid  2866] close(4 
[pid  2865] <... write resumed>)= 4
[pid  2866] <... close resumed>)= 0
[pid  2866] pipe2( 
[pid  2865] close(39 
[pid  2866] <... pipe2 resumed>[3, 4], O_CLOEXEC) = 0
[pid  2865] <... close resumed>)= 0
[pid  2865] exit_group(0)   = ?
[pid  2866] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER|SA_NOCLDSTOP, sa_restorer=0x7fccfc304d80}, 8) 
= 0
[pid  2866] rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, 8) = 0
[pid  2866] rt_sigaction(SIGHUP, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, 8) = 0
[pid  2866] rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, 8) = 0
[pid  2866] rt_sigprocmask(SIG_UNBLOCK, [HUP INT TERM CHLD], [HUP INT TERM 
CHLD], 8) = 0
[pid  2866] mkdir("/var", 0777) = -1 EEXIST (File exists)
[pid  2866] mkdir("/var/run", 0777) = -1 EEXIST (File exists)
[pid  2865] +++ exited with 0 +++
[pid 1] <... wait4 resumed>[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, 
NULL) = 2865
[pid 1] close(39)   = 0
[pid  2866] setsid( 
[pid 1] read(16,  
[pid  2866] <... setsid resumed>)   = 2866
[pid 1] <... read resumed>"2866", 4096) = 4
[pid  2866] chdir("/")  = 0
[pid 1] read(16,  
[pid  2866] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) 
= 0
[pid  2866] close(0)= 0
[pid  2866] openat(AT_FDCWD, "/dev/null", O_RDONLY) = 0
[pid  2866] dup2(0, 0)  = 0
[pid  2866] close(1)= 0
[pid  2866] close(2)= 0
[pid  2866] openat(AT_FDCWD, "/var/log/guix-daemon.log", 
O_WRONLY|O_CREAT|O_APPEND, 0640) = 1
[pid  2866] dup2(1, 1)  = 1
[pid  2866] dup2(1, 2)  = 2
[pid  2866] 
execve("/gnu/store/bxnkqnpbf4q4z6245b61wgpm8gkr9nj1-guix-1.3.0-29.9e46320/bin/guix-daemon",
 ["/gnu/store/bxnkqnpbf4q4z6245b61w"..., "--build-users-group", "guixbuild", 
"--max-silent-time", "0", "--timeout", "0", "--log-compression", "gzip", 
"--discover=yes", "--substitute-urls", "https://substitutes.nonguix.org "...], 
0x7fccf71fa480 /* 3 vars */) = 0
--8<---cut here---end--->8---

This happens because the other end of the file descriptor happens to be
inherited by 2866, which will never close it because it just execs
guix-daemon.

This is fixed by 6abdcef4a68e98f538ab69fde096adc5f5ca4ff4; the log
contains extra details.

Thanks!

Ludo’.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I pushed these patches:
>
>   eedf71f948 * services: upower: Default to a percentage-based policy.
>   4765242540 * services: upower: Update default percentage values.
>
> I’m not sure whether they help, but they might: using a
> time-estimate-based policy is documented as less reliable, and I suppose
> even less so when a battery gets old, as is the case on this laptop.

As those at the Ten Years of Guix event noticed, this didn’t help at all.

Ludo’.

bug#57543: emacs-telega is broken

[Ludovic Courtès]

Hello,

Giovanni Biscuolo  skribis:

> IMHO yes, we should revert the tdlib upgrade /or/ keep a packaged
> tdlib@1.8.0 used by emacs-telega v. 0.8.3

[...]

> If I don't get it wrong, I still have commit access to the guis repo so
> I could revert the commit on tdlib, but I'd like to have an OK.
>
> Ludo' WDYT please?

I think we can reintroduce tdlib 1.8.0 (in addition to the latest
version currently available) for use by emacs-telega; we’ll remove it
eventually when it becomes unnecessary.

Could you send a patch?

Note that I don’t use tdlib and emacs-telega, so I’ll apply whatever
seems appropriate to you.  :-)

Thanks,
Ludo’.

bug#57581: Failing to build the website

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> zimoun  writes:
>> The culprit seems the package ’qtserialport’ in ’packages-builder’ from
>> (apps packages builder).  Maybe introduced by commit
>> 1ef04fb2288dade3ad2883026ae286a68ef13a1e.
>
> This was a first failing commit for me too, but the reason the website
> does not build appears to be the license field of qtshadertools in
> commit 1d65ff8fdeb20cc2db956093f0ecb1f3f72afc0e (Cc to Maxim).  I could
> make a patch but not today.  Maxim, would you fix it?

Fixed in e61c581805b2338ea8feaac86617c5d7bff41c41, thanks for the
investigation!

> I don’t know if there is a way to catch such mistakes early.  Field
> sanitizers?

Yes, we should do that.  We can arrange to have most checks done at
compile time, similar to how the ‘synopsis’ and ‘description’ sanitizers
work (well, with extra macro magic).

Ludo’.

bug#57077: guix-jupyter fails a test

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Andreas Enge  skribis:
>
>> guix-jupyter currently fails to build with the error message below. While I
>> noticed it when updating python-sympy, the problem was already present
>> before.
>
> It looks like the Jupyter protocol changed, probably in
> d54b8754fdba52d89aafaaf80b6c8e89bcea92bd, which was merged with the
> latest ‘staging’.

To my surprise, it looks like running tests sequentially as Marius did
in d09f3f82b84c850a9639ec80af19ba3918b63368 solves the problem.  That’s
good news.  :-)

Thanks,
Ludo’.

bug#57677: GIMP retains reference to GCC

[Ludovic Courtès]

>From ca. commit 2183db8d2ab773f41e4320367645880b06959bfc:

--8<---cut here---start->8---
$ guix size gimp | head -4
store item   totalself
/gnu/store/wdm2s2si8fqsrcd5xpc29ivmpkf20s8d-mesa-21.3.8411.6   
169.6  14.1%
/gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
149.5  12.4%
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0 217.7   
145.8  12.1%
$ guix graph --path -t references 
/gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32 
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0  
/gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0
$ grep -r 069aq2v993kpc41yabp5b6vm4wb9jkhg 
/gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32
grep: 
/gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32/libexec/gimp-debug-tool-2.0:
 binary file matches
grep: 
/gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32/bin/gimp-console-2.10: 
binary file matches
grep: /gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32/bin/gimp-2.10: 
binary file matches
$ strings 
/gnu/store/m4s1ghyqp05irx8acz2mqa68lyclcsrz-gimp-2.10.32/bin/gimp-console-2.10 
| grep -C3  069aq2v993kpc41yabp5b6vm4wb9jkhg
GNU Image Manipulation Program
Using built-in specs.
COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/libexec/gcc/x86_64-unknown-linux-gnu/10.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: 
Thread model: posix
--8<---cut here---end--->8---

So the root cause is that GIMP’s build process captures the output of
‘gcc -v’, which leads to this unintended retention.

Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi,

Thanks a lot for the explanations, Andreas!

As you write, the decision will be “political” as there’s no scientific
evidence to guide us.

I’d like to see what other free software OpenPGP implementors decided
(primarily Sequoia; GnuPG/Libgcrypt implement them).

Ludo’.

bug#57316: (core-updates) dejagnu@1.6.3 sometimes fails to build

[Ludovic Courtès]

Maxime Devos  skribis:

> I cannot reproduce the test failure locally myself.
>
> * gnu/packages/dejagnu.scm (dejagnu)[#:out-of-source?]:
> Do an out-of-source build, as recommended upstream, and
> add a link to the upstream bug report.

Pushed in ‘core-updates’ as 0e305798454c558ab6e722cf66ba351c326a1a8d.

Thanks!

Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi,

(Cc’ing Andreas for extra advice.)

Maxime Devos  skribis:

> We disallow signing with SHA-1, because it is known to be vulnerable
> and as there are alternatives that are considered good, even if this
> limits what users can do with their OpenPGP keys.

Right, we know it’s affordable to break SHA-1 these days.

> In case of those curves, I'm not aware of any 'crytopgraphic proof'
> (*) that the curves are vulnerable (unlike for SHA-1), but as noted in
> ¹ and elsewhere, there are other kinds of evidence that something is
> wrong.

It’s different from SHA-1 though: ECDSA is not known to be vulnerable,
and AIUI we can’t tell that there’s a possibility NIST/NSA has a
backdoor as is the case for DualEC.  However, the whole NIST design
process is tainted.  So my understanding is that it’s really a gray
area.

> Except for the different nature of the evidence of vulnerability, it
> seems about the same situation to me. As such, I don't think we should
> support them (some nice error messages like 'This algorithm [...] is
> not supported yet’ or ‘This algorithm [...] is (likely/known to be)
> vulnerable’ would be good though!).

Yes, that we can improve.  :-)

> An alternative option would be to allow the channel
> .guix-authorization (of the previous commits, not the commit that is
> about to be verified!) to decide what's considered a 'good algorithm'
> (with some defaults) (with a field). Maybe we'll have to deprecate,
> say, RSA or SHA-3 eventually, it would be nice to have a migration
> method in place as early as possible, to minimise the risk of some
> people doing a "guix pull" from a Guix that does not support that
> field to a Guix or other channel that _does_ use that field.

It’s tempting, but I’d rather avoid introducing such mechanisms to keep
things as simple as possible.

Thanks,
Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi,

ECDSA and the NIST curves (and in fact a large part of NIST’s crypto
standardization work¹) are actually considered with skepticism by some:

  
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Concerns

That makes me wonder whether supporting them is a good idea, after all.
Evidently they’re not widely used in OpenPGP and not supporting them
hasn’t been much of a problem, it seems.  On one hand, we don’t want
Guix’s OpenPGP implementation to limit what users do with their OpenPGP
keys; on the other hand, we don’t want to encourage algorithms that
bring little to the table at best and are suspicious at worst.

What do people think?

Ludo’.

¹ https://blog.cr.yp.to/20220805-nsa.html

bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Ludovic Courtès]

Maxime Devos  skribis:

> On 05-09-2022 15:06, Ludovic Courtès wrote:
>> The main difficulty here is that, should we eventually decide to change
>> behaviors, we’ll have to devise a migration timeline etc.  (As an
>> example, we chose to keep ‘guix environment’ until at least May 2023;
>> all this must take time if we want to avoid breaking user workflows.)
>>
>> Thoughts?
>
> "guix shell" is for making packages available in the
> environment. Currently, "guix shell -- foobar" does not make any
> packages available -- it's effectively a no-op except for setting
> GUIX_ENVIRONMENT.

True, though you could always have scripts that read:

  guix shell $packages -- whatever

and that will suddenly behave differently if $packages expands to an
empty string.  Tricky!

Ludo’.

bug#57576: Missing support for NIPT-P384 gpg algorithm in Guix channel authentication.

[Ludovic Courtès]

Hi,

Zhu Zihao  skribis:

> I'm working with my private channel, And I update my gpg key using
> NIPT-P384 algorithm. But `guix time-machine` complains that:

[...]

> 226:4  6 (authenticate-commit # # …)
>129:23  5 (commit-signing-key _ # …)
> In guix/openpgp.scm:
>562:26  4 (verify-openpgp-signature _ _ _)
> In gcrypt/pk-crypto.scm:
> 250:8  3 (key-type (unsupported-algorithm 19 #vu8(5 43 129 4 …)))
>202:27  2 (_ (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 …)) 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 struct-vtable: Wrong type argument in position 1 (expecting 
> struct): (unsupported-algorithm 19 #vu8(5 43 129 4 0 34 3 3 4 53 239 158 105 
> 250 133 46 247 192 56 245 48 43 60 70 47 46 85 221 226 213 94 248 254 218 85 
> 176 252 233 119 26 85 65 191 47 159 193 86 129 155 186 183 151 233 81 178 42 
> 30 81 234 192 184 140 230 226 26 72 186 82 18 213 187 6 28 34 39 197 75 37 
> 138 226 98 216 187 185 223 222 126 181 122 255 104 171 201 51 254 7 235 245 
> 151 247 168 215 165 73 181))
>
> Does Guix support NIPT-P384 key?

Nope!  (That’s NIST-P384.)

To add it, we need to adjust (guix openpgp) to support it (and ECDSA,
the “19” we see above).  I’ll follow up with a patch.

Ludo’.

bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Ludovic Courtès]

Hi David,

Thanks for your feedback on this.

"Thompson, David"  skribis:

> So there are some competing expectations here. The status quo is that
> non-interactive invocations of 'guix shell' will not load a guix.scm or
> manifest.scm file unless explicitly told to via --file/--manifest following
> the "explicit is better than implicit" philosophy.  People like myself who
> almost exclusively invoke 'guix shell' without any arguments would expect
> that 'guix shell -- make' would load their guix.scm file like they're used
> to.  It is the latter expectation that is typically the status quo in other
> language environments.  For example, in Ruby land, 'bundle exec foo' runs
> the command 'foo' non-interactively in the context of a project and you
> don't have to tell it where to find the conventional Gemfile because it's
> the default.  Treating interactive and non-interactive invocation
> differently in 'guix shell' was a surprise for me.  Of course, 'guix shell
> -D -f guix.scm -- make' works, but it doesn't "just work."

Right.  As you note, there were different expectations and constraints
when we discussed this.  We ended up with a tradeoff that has its pros
and cons.  The whole discussion took place here:

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

As a side note, I think as a project we may want to set up an RFC kind
of process to have a documented way to make decisions like these.  This
would ensure every person who wants to chime in has an opportunity to do
so, even people who would not follow implementation discussions or
follow the patch stream on guix-patches.  Food for thought!

> Both viewpoints have their merits and I'm wondering if there's a way
> to satisfy both expectations.  Perhaps 'guix shell -- make' would load
> guix.scm, but 'guix shell --pure -- make', or any invocation with any
> flags, would not?  Or, less ideal, a new short flag that can be passed
> that would be the equivalent of `-D -f guix.scm` (or the manifest.scm
> variant) to at least make for less typing.  Personally, I think that
> defaulting to loading from a conventional file when no packages are
> specified is much more user friendly than generating an empty profile,
> regardless of interactive vs.  non-interactive.

The main reason to me for distinguishing non-interactive behavior is
ensuring that scripts behave in a deterministic fashion, as opposed to
having their behavior dependent on the presence of a file in $PWD.

FWIW, I’m rather satisfied with the current behavior, though I’m open to
other opinions (and indeed, feedback from users of other tools in this
area is much welcome).

The main difficulty here is that, should we eventually decide to change
behaviors, we’ll have to devise a migration timeline etc.  (As an
example, we chose to keep ‘guix environment’ until at least May 2023;
all this must take time if we want to avoid breaking user workflows.)

Thoughts?

Thanks,
Ludo’.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> One issue remains: UPower should have called elogind’s “PowerOff” method
> for ordered shutdown before total power outage, but either that didn’t
> happen or elogind didn’t do it right (which is weird, because ‘loginctl
> poweroff’ DTRT.)

I pushed these patches:

  eedf71f948 * services: upower: Default to a percentage-based policy.
  4765242540 * services: upower: Update default percentage values.

I’m not sure whether they help, but they might: using a
time-estimate-based policy is documented as less reliable, and I suppose
even less so when a battery gets old, as is the case on this laptop.

I’d like to test whether UPower invokes the intended critical action,
but I’m not sure how to simulate a low battery level.  Thoughts?

Thanks,
Ludo’.

bug#57583: Guix cannot resume after hibernation

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> Yusuf Talha via Bug reports for GNU Guix  writes:
>
>> I haven't encountered this problem on any other distros.  You probably 
>> realized that I encrypted my disk.  Hibernation wasn't working while I was 
>> using Guix without encryption a few months ago either.  So I don't think 
>> LUKS is the problem here.
>
>>From what I can tell, resuming from an encrypted partition isn't
> currently supported.  This could potentially be done, though it's not my
> priority right now (and testing these kinds of features is dangerous,
> you could make a wrong move and incur heavy data loss).

I believe this is fixed by this:

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

Jack, do I get it right?

The patch in question fell through the cracks, but it actually LGTM.

Thanks,
Ludo’.

bug#57593: Racket 8.6 is not reproducible

[Ludovic Courtès]

Hey,

Just noticed that Racket does not build in a reproducible fashion:

--8<---cut here---start->8---
$ guix describe
Generation 227  Sep 04 2022 23:39:52(current)
  guix aae98c2
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: aae98c297214f87eb45302863adb021078c41a6f
$ guix challenge racket | head -40
/gnu/store/av255rh362283i1zaiq9rz4rpli69j59-racket-8.6 contents differ:
  local hash: 1w4dnkvpbbrgfasyq8x1cbqw58jzqsny17ms5l1fb1h6iid38bs1
  https://ci.guix.gnu.org/nar/lzip/av255rh362283i1zaiq9rz4rpli69j59-racket-8.6: 
1lnxklizpnc599w7n2svb1jaw595wranm9aagd2928fcbiaavbr6
  differing files:
/lib/racket/pkgs/2d-doc/scribblings/compiled/2d_scrbl.dep
/lib/racket/pkgs/2d-doc/scribblings/compiled/2d_scrbl.zo
/lib/racket/pkgs/algol60/compiled/algol60_rkt.dep
/lib/racket/pkgs/algol60/compiled/algol60_scrbl.dep
/lib/racket/pkgs/algol60/compiled/algol60_scrbl.zo
/lib/racket/pkgs/algol60/compiled/cfg-parser_rkt.dep
/lib/racket/pkgs/algol60/compiled/compile_rkt.dep
/lib/racket/pkgs/algol60/compiled/parse_rkt.dep
/lib/racket/pkgs/algol60/compiled/parse_rkt.zo
/lib/racket/pkgs/algol60/compiled/simplify_rkt.dep
/lib/racket/pkgs/algol60/compiled/tool_rkt.dep
/lib/racket/pkgs/algol60/lang/compiled/reader_rkt.dep
/lib/racket/pkgs/algol60/tests/compiled/export_rkt.dep
/lib/racket/pkgs/algol60/tests/compiled/export_rkt.zo
/lib/racket/pkgs/algol60/tests/compiled/syncheck-test_rkt.dep
/lib/racket/pkgs/algol60/tests/compiled/test_rkt.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/awk_scrbl.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/awk_scrbl.zo

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/cmdline_scrbl.dep

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/cmdline_scrbl.zo
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/cml_scrbl.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/cml_scrbl.zo
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/common_rkt.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/common_rkt.zo

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/compat_scrbl.dep

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/compat_scrbl.zo

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/compile_scrbl.dep

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/compile_scrbl.zo

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/contract-label_rkt.dep

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/contract_scrbl.dep

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/contract_scrbl.zo
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/etc_scrbl.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/etc_scrbl.zo
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/file_scrbl.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/file_scrbl.zo
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/for_scrbl.dep
/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/for_scrbl.zo

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/include_scrbl.dep

/lib/racket/pkgs/compatibility-doc/mzlib/scribblings/compiled/include_scrbl.zo
--8<---cut here---end--->8---

Ludo’.

bug#57095: 'terminal-window-size' throws ENOTTY ("Inappropriate ioctl for device")

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Maybe my answer on IRC is relevant here:
>
> https://logs.guix.gnu.org/guile/2022-09-01.log#231503

Interesting.

It’s a Guile bug, and a tricky one.  Here’s what Andy wrote on IRC:

 civodul, wingo says: i believe it is a bug.  in a pre-unwind handler,
you want to make it so that if it throws again, it is handled by the
handler that was current when the with-exception-handler was invoked
(the dynamically outer handler)
 civodul, wingo says: to implement this, when a throw first starts, we
capture the current handler stack, and arrange for subsequent throws
to resolve via that captured handler stack
 civodul, wingo says: but if there is an additional
with-exception-handler within the exception handler, that doesn't
augment the captured exception handler stack to which inner exceptions
will dispatch
 civodul, wingo says: the fix will be small but also gnarly :P  will
take some thinking.  there are funny interactions with delimited
continuations

I’ll defer to Andy to see what the best way to fix it is…

What’s frustrating is that I can’t think of a way to work around it,
except by changing ‘terminal-columns’ & co. to not use exceptions (or
introducing a variant that does that).

Thoughts?

Ludo’.

bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

>> Currently, new services don’t fail to run: we arrange so that new
>> services always “work”, whether they’re talking to an old shepherd or a
>> new one.  The user experience (bugs aside) should be good: services are
>> always reloaded.
>
> This depends on how the services are written, and how much care to this
> edge case their author put into writing it.  I know the Jami service
> type won't run without Shepherd >= 0.9.0, and the solution is not
> obvious (I'm suspecting sleep* from (guix build dbus-service) should use
> regular sleep when shepherd is < 0.9.0.).

Ah, that’s an exception then, and this should be avoided IMO.  :-)

Usually, the Shepherd’s API is backward compatible, so one can normally
leave services unchanged.  It’s only when you want to take advantage of
the new features that you have to resort to conditionals.

But then more complex services like Jami or childhurd were more likely
to hit edge cases with the switch to Fibers.

>> IIUC, in the model you propose, we’d sacrifice this, by admitting that
>> in some cases we just won’t load services live and instead tell users to
>> reboot; the benefit would be cleaner service code.
>>
>> It’s a tradeoff; the cost/benefit ratio is not obvious to me.
>
> Having a simple way to cleanly mark a service as "requiring Shepherd
> 0.9.X" would provide good value in my opinion, for when adding backward
> compatibility is too difficult or not desirable for any reason (such as
> causing long 'hangs' while busy-waiting for a process to start in older
> shepherds).

Right, I agree it’d be useful in those cases.  (Though having to
busy-wait is not a valid reason IMO: it’s a sign we should provide the
proper abstraction to avoid busy waiting.)

I don’t have a clear idea on how to implement it now, but we should keep
that in mind.

Thanks,
Ludo’.

bug#57095: 'terminal-window-size' throws ENOTTY ("Inappropriate ioctl for device")

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> We also use a big wrapping `with-error-handling` to display errors
> properly in the case when they are not caught.  The difference is that
> `with-error-handling` adds a non-unwinding handler, while catch is
> unwinding.  My first thought was that non-unwinding handlers, even outer
> ones would get priority over unwinding ones, since once the stack's
> unwound you can't really go back (I have no idea if that last part is
> actually true).  In practice this is actually false, I tested with a
> very simple example, but that lead me to test by setting `#:unwind? #t`
> for the `guard*` definition in guix/ui.scm and the issue went away, so I'm
> clueless as to why this happens.  What seems weird is that the error is
> not caught at all!

Here’s a reproducer:

--8<---cut here---start->8---
scheme@(guile-user)>  (with-exception-handler (lambda _ (catch 'x (lambda () 
(throw 'x)) (const 'good) ))
 (lambda ()
   (rmdir "/"))
 #:unwind? #f)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `x' with args `()'.
--8<---cut here---end--->8---

Or, simplified:

--8<---cut here---start->8---
scheme@(guile-user)>  (with-exception-handler
  (lambda _ (with-exception-handler (const 'good)
  (lambda () (throw 'x))
  #:unwind? #t))
 (lambda ()
   (rmdir "/"))
 #:unwind? #f)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `x' with args `()'.
--8<---cut here---end--->8---

We expect 'x to be caught, leading the handler to return 'good.
Instead, 'x is not caught at all.

In both cases, setting #:unwind? #t in the outer
‘with-exception-handler’ gives the expected result.

I spent some time staring at the relevant code in ‘boot-9.scm’ but
nothing came out of it.

Ludo’.

bug#57090: 'guix style' pretty-printer always renders integers as base10

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Now, we could tweak the pretty printer so that it recognizes patterns
> where numbers or strings should be printed in a certain way.

I did that in c3b1cfe76b7038f4030d7d207ffc417fed9a7ead.  Lemme know how
you like it!  :-)

Ludo’.

bug#57474: compute-guix-derivation fails due to insufficient memory

[Ludovic Courtès]

Hi,

"Michael F. Lamb"  skribis:

> I was following the instructions in the Guix Reference Manual for running 
> Guix in a VM using the pre-built qcow2 VM image:
>
> https://guix.gnu.org/manual/en/guix.html#Running-Guix-in-a-VM
>
> The documentation instructs me to create a qemu VM with the option '-m 1024' 
> which provides it 1GB of RAM.
>
> After doing so, each time I attempted to run 'guix pull', I received the 
> error message:
>
>> You found a bug: the program '/gnu/store/...-compute-guix-derivation' failed 
>> to compute the derivation for Guix (version: "..."; system: "x86_64-linux"; 
>> host version: "..."; pull-version: 1).
>
> Searching for this error message led me to many reports where "just run 'guix 
> pull' again" eventually worked for the reporter but such was not the case for 
> me.
>
> Watching "top" while running "guix pull" showed the memory usage increasing 
> to 100% whereupon "guix pull" fails. I set the -m option to '4096' and 
> thereafter 'guix pull' worked for me.
>
> A few approaches you might take:
>
> 1. Make 'compute-guix-derivation' or the process that executes it better at 
> reporting what variety of failure has occurred.
> 2. Change the docs to increase the default amount of memory granted to the 
> VM. (But this might not be helpful for users with older machines and limited 
> available memory.)
> 3. Change the docs to provide the VM with swap space.
> 4. Attempt to reduce the amount of memory compute-guix-derivation requires to 
> complete.

It looks like the memory requirements to build the latest revisions of
Guix have increased (and this is a bit ridiculous).

I checked with

and ‘-m 2048’ gives us enough headroom, so I modified the manual
accordingly in commit 98a8b48a69b8208475c9a1e40d09517f8643b8cb.

Thanks for your report!

Ludo’.

bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Howdy!

Maxim Cournoyer  skribis:

> I had something different on mind; I was thinking of some added field to
> our shepherd-service object where the minimal version of Shepherd
> required could be specified, e.g. "0.9.1".
>
> The check could be abstracted in the shepherd-service implementation,
> avoiding services writers to handle that by themselves in *each* service
> requiring so.

Hmm I see.

> The benefit would be an improved user experience, and cleaner service
> code.  Upon reconfiguring a machine not yet equipped with a new enough
> Shepherd, Shepherd could print:
>
> The x, y and z services won't be started until the next reboot, as they
> require a newer Shepherd version.
>
> Instead of seeing the new services fail to run without (for the end
> user) without any obvious reason.

Currently, new services don’t fail to run: we arrange so that new
services always “work”, whether they’re talking to an old shepherd or a
new one.  The user experience (bugs aside) should be good: services are
always reloaded.

IIUC, in the model you propose, we’d sacrifice this, by admitting that
in some cases we just won’t load services live and instead tell users to
reboot; the benefit would be cleaner service code.

It’s a tradeoff; the cost/benefit ratio is not obvious to me.

Thanks for explaining!

Ludo’.

bug#57356: libtool-2.4.7 removed as a "duplicate"?

[Ludovic Courtès]

Hi,

Michael Ford  skribis:

> In commit 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca, the libtool-2.4.7
> package was removed as a "duplicate". The commit message doesn't explain at
> all why libtool 2.4.7 was being removed, or what it was a duplicate of? As
> of latest master, libtool is still version 2.4.6.

Indeed, I think this commit was intended for ‘core-updates’, where
‘libtool’ *is* 2.4.7, and not for ‘master’.

I’m reverting it on ‘master’.  Marius, we’ll have to make sure not to
reintroduce it on the next merge into ‘core-updates’.

Thanks,
Ludo’.

bug#57315: guix upgrade --dry-run output is basically useless

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Just to mention this report is somehow a duplicate of bug#40612 [1].
> Maybe, they could be merged.  WDYT?

Yes, please.

>> (If you’re curious, see
>>  for details.)
>
> Nice read!  Quoting:
>
> [...] do a first pass lowering packages to derivations as if
> grafting was disabled, build all these derivations, and then do
> a second pass to determine which packages in the graph need to
> be grafted and to compute the relevant grafting
> derivation. [...] If we reify that second pass to the user
> interface code, it also addresses the user interface issue by
> allowing it to display, possibly, two build plans: the
> “ungrafted” one followed by the grafted one.
>
> Currently, these 2 plans are not well-exposed, IMHO.

When there are two or more passes, each one is printed as soon as
possible.  So you see “X MiB will be downloaded” or similar messages in
the middle of the process.

> $ guix package -i opensurge --dry-run
> guix package: warning: Your Guix installation is 12 days old.
> guix package: warning: Consider running 'guix pull' followed by
> 'guix package -u' to get up-to-date packages and security updates.
>
> The following package would be installed:
>opensurge 0.5.2.1
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> The following derivation would be built:
>   /gnu/store/r89hmhbxwm3gs1jl2dhns7gnwvi2k6s1-opensurge-0.5.2.1.drv
>
> 42.1 MB would be downloaded
>
> What does it mean?

That you’ll download 42M of dependencies and then build opensurge.

“The following derivation would be built” is about building derivations
that are not grafts.  For grafts, you would see “The following graft …”,
and only at verbosity level 2 or more (see ‘show-what-to-build’).

[...]

> When I run the option ’--dry-run’, I accept to pay a bit more and then
> compute as much as possible of derivations to have the most complete as
> possible graph to know beforehand and as accurately as possible:
>
>  1. what I need to download as substitutes
>  2. what I need to compile from source
>  3. what require grafts, e.g.,
>
> require 1 graft for openal-1.20.1 ...
> require 4 grafts for sfml-2.5.1 ...
> require 6 grafts for mars-0.7.5.1.c855d04 ...
>
> Sometime, the plan looks exactly like that.  Sometime, it is really
> confusing and you have unpleasant surprises when running it.

By definition, the whole plan cannot be known in advance in the presence
of dynamic dependencies such as grafts, so it’s hard to do better.

The way it’s implemented right now is not optimal strictly speaking in
that we might bail out before we have a complete picture of everything
that’s known statically beforehand.  In practice though I think it’s
doing an okay job from that perspective.

Cheers,
Ludo’.

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Wed, 31 Aug 2022 at 13:06, Ludovic Courtès  wrote:
>
>> I fixed it in 67a6828b2bb821274757f686f7c685b664339a96 using the same
>> trick as earlier.
>
> It means version 3 is used all the time, right?

Yes.

> Well, I miss when or where version 4 is used then.

Generations that were created with a slightly older Guix have a
version-4 manifest.

> From my understanding, set #:format-version to 3 should only be
> considered when  is a parent/ancestor of current commit in
> ’--commit=’.

Here #:format-version 3 is unconditional.  That avoids having to make
assumptions about whether or not the target commit understands newer
format versions.

But you’re right: a refinement would be to use version 3 only when
targeting an ancestor.  I don’t think it’s worth the trouble though.

> Well, I do not remember all the discussion about --allow-downgrades.
> For instance, why is
>
>  $ guix pull --commit=6f75565b -p /tmp/test
>
> not complaining about downgrade?  Because it is a downgrade. :-)

Whether it’s a downgrade depends on what’s in /tmp/test when you run it.

Thanks,
Ludo’.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Setting ‘hybrid-sleep-state’ to '("mem") doesn’t help though:
> “CanHybridSleep” still returns “na”.  I’m looking at ‘can_sleep_state’
> in elogind without seeing why it doesn’t return true.

Having changed elogind’s “LogLevel” to “debug” with a 1km-long
‘dbus-send’ command I’ll spare you, I got this in /var/log/debug for my
“CanHybridSleep” method call (in QEMU):

--8<---cut here---start->8---
Aug 31 16:01:07 localhost elogind[183]: Got message type=method_call 
sender=:1.78 destination=org.freedesktop.login1 path=/org/freedesktop/login1 
interface=org.freedesktop.login1.Manager member=CanHybridSleep cookie=2 
reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Aug 31 16:01:07 localhost elogind[183]: Sleep mode "mem" is supported by the 
kernel.
Aug 31 16:01:07 localhost elogind[183]: No possible swap partitions or files 
suitable for hibernation were found in /proc/swaps.
Aug 31 16:01:07 localhost elogind[183]: Sent message type=method_return 
sender=n/a destination=:1.78 path=n/a interface=n/a member=n/a cookie=190 
reply_cookie=2 signature=s error-name=n/a error-message=n/a
--8<---cut here---end--->8---

Closer inspection of the code confirms what we can guess from the above:
if swap space is missing, ‘can_sleep’ returns false, even if the chosen
sleep state is “mem”:

--8<---cut here---start->8---
static int can_sleep_internal(const char *verb, bool check_allowed, const 
SleepConfig *sleep_config) {
bool allow;
char **modes = NULL, **states = NULL;
int r;

assert(STR_IN_SET(verb, "suspend", "hibernate", "hybrid-sleep", 
"suspend-then-hibernate"));

[...]

#if 0 /// elogind supports setting a suspend mode
if (!can_sleep_state(states) || !can_sleep_disk(modes))
return false;
#else // 0
if (!can_sleep_state(states) ||
!((strcmp("suspend", verb) && can_sleep_disk(modes)) ||
  (streq("suspend", verb) && can_sleep_mem(modes
return false;
#endif // 0

if (streq(verb, "suspend"))
return true;

if (!enough_swap_for_hibernation())
return -ENOSPC;

return true;
}
--8<---cut here---end--->8---

(Specifically, ‘enough_swap_for_hibernation’ returns false when there’s
no space space.)

The caller:

--8<---cut here---start->8---
static int method_can_shutdown_or_sleep(
Manager *m,
sd_bus_message *message,
InhibitWhat w,
const char *action,
const char *action_multiple_sessions,
const char *action_ignore_inhibit,
const char *sleep_verb,
sd_bus_error *error) {

[...]

if (sleep_verb) {
#if 0 /// elogind needs to have the manager being passed
r = can_sleep(sleep_verb);
#else // 0
r = can_sleep(m, sleep_verb);
#endif // 0
if (IN_SET(r,  0, -ENOSPC))
return sd_bus_reply_method_return(message, "s", "na");
if (r < 0)
return r;
}
--8<---cut here---end--->8---

I find it a bit ridiculous: if we’re choosing “mem”, then we shouldn’t
need to check for swap space.

However, given how ‘hybrid-sleep’ is documented¹, it’s not meant to be
implemented by suspend-to-RAM:

  A low-power state where execution of the OS is paused, which might be
  slow to enter, and on complete power loss does not result in lost data
  but might be slower to exit in that case. This mode is called
  suspend-to-both by the kernel.

So, as a conclusion, it would seem that everything here is working as
advertised: no swap, no hybrid-sleep.  (We should probably document that
in the manual.)


One issue remains: UPower should have called elogind’s “PowerOff” method
for ordered shutdown before total power outage, but either that didn’t
happen or elogind didn’t do it right (which is weird, because ‘loginctl
poweroff’ DTRT.)

Thoughts?

Ludo’.

¹ https://man.voidlinux.org/logind.conf.5

bug#57480: Wrong Type To Apply on Reconfigure

[Ludovic Courtès]

Hi,

宋文武  skribis:

> Julien Lepiller  writes:
>
>> I don't know how to fix it, but here is what I think is the issue:
>>
>> in guix/scripts/system/reconfigure.scm:
>>
>> #:autoload   (guix describe) (current-channels)
>> ...
>> (define* (check-forward-update ...
>>(current-channels ...))
>>   (define new (current-channels)) ; this is supposed to be the
>>  ; autoloaded procedure, but it's the keyword argument
>>  ; which is a list
>>   ... ; uses of current-channels, the keyword argument
>>
>> Le Mon, 29 Aug 2022 23:01:46 -0400,
>> Christopher Rodriguez  a écrit :
>>
>>> Hello All,
>>> 
>>> A change made in b084398 is preventing both my system and home
>>> configurations from building with a Wrong Type to Apply error. Did the
>>> channel spec format change with the changes in that commit?
>
> Hello, I revert the commit b084398 for now.

Thanks for the quick reaction.

As Julien wrote, the code referred to the wrong ‘current-channels’.
Fixed in 270e1b9e1ea2b3e41067a38b094b0656ceb56838.

Ludo’.

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Ludovic Courtès]

Hi,

Arun Isaac  skribis:

>> I do not think it is related to guix-daemon and I think it is expected;
>> indeed it could be considered as a bug.  The command-line,
>>
>> guix pull --commit=xyz -p /tmp/test
>>
>> writes /tmp/test/manifest using the current Guix (say manifest 4) and
>> not using Guix at commit xyz (say manifest 3).  Contrary to “guix
>> time-machine --commit=xyz”.
>
> Ah, that makes sense! Any ideas as to how this issue might be fixed?

I fixed it in 67a6828b2bb821274757f686f7c685b664339a96 using the same
trick as earlier.

Thanks!

Ludo’.

bug#57315: guix upgrade --dry-run output is basically useless

[Ludovic Courtès]

Hi,

Csepp  skribis:

> I'd like to figure out what Guix will try to build before I run an
> upgrade on my netbook, so I always use --dry-run.  I'm pretty sure in
> the past it used to show more information, but today it just showed that
> it will download 20 megs, without saying what package that 20 megs are
> for, which ones will be built, which ones are downloaded, or anything
> useful at all.
>
> And now I see it's building Caja.  Why did it not warn me beforehand?
> No idea.

I understand this is a source of confusion.  It has to do with “grafts”
(which themselves are about applying security updates): if substitutes
for a package are missing, Guix has a partial view of the dependency
graph, which is why it can only tell you about extra builds/downloads
later on in the process (it does report them, only later).

(If you’re curious, see
 for details.)

Thanks,
Ludo’.

bug#57315: guix upgrade --dry-run output is basically useless

[Ludovic Courtès]

Hi,

"bdju"  skribis:

> On Sun Aug 21, 2022 at 1:39 AM CDT, Csepp wrote:
>> This should go without saying, but this is pretty bad UX.
>>
>> Is there something that can be done about this?  The upgrade process on
>> less powerful machines is pretty awful currently.
> Agreed. Upgrading on Guix can be pretty horrible. Especially when you
> find out you're seemingly the only user of certain packages so you hit a
> bunch of build failures that you would've expected to be found and fixed
> already, and you have to skip and/or report them and redo the upgrades
> repeatedly. On most distros I would upgrade daily without worry, but
> with Guix System I end up putting it off a week or two and trying to
> plan out a time when I don't mind my CPU being maxed out entirely with
> builds and such.

That’s a pretty bad experience that we should improve (my personal
experience is nicer: I upgrade my system and home roughly weekly and
usually without having to build anything locally).

Now, I think it’s a mistake to “expect” build failures “to be found and
fixed already”: you’re part of the process, you too can find, report,
and fix build failures.  Of course one has other obligations in life
too, but if each one of us does a small part, it’ll work better.

Thanks,
Ludo’.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Looking at the code, it could be because the ‘CanHybridSleep’ method
> returns false, but why that would happen is unknown to me.

Indeed, if we run ‘dbus-monitor --system’ and
‘herd restart upower-daemon’ (in QEMU), we see this:

--8<---cut here---start->8---
method call time=1661890192.586471 sender=:1.40 -> destination=:1.39 serial=16 
path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; 
member=GetCriticalAction
method call time=1661890192.586862 sender=:1.39 -> destination=:1.1 serial=17 
path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; 
member=CanHybridSleep
method return time=1661890192.588676 sender=:1.1 -> destination=:1.39 
serial=104 reply_serial=17
   string "na"
method call time=1661890192.589034 sender=:1.39 -> destination=:1.1 serial=18 
path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; 
member=CanHibernate
method return time=1661890192.591082 sender=:1.1 -> destination=:1.39 
serial=105 reply_serial=18
   string "na"
method return time=1661890192.591405 sender=:1.39 -> destination=:1.40 
serial=19 reply_serial=16
   string "PowerOff"
--8<---cut here---end--->8---

That is, elogind returns “na” to the Can* methods.

Same story on my actual laptop:

--8<---cut here---start->8---
$ dbus-send --print-reply --system --dest=org.freedesktop.login1 
/org/freedesktop/login1 org.freedesktop.login1.Manager.CanHybridSleep
method return time=1661890748.184775 sender=:1.1 -> destination=:1.130 
serial=253 reply_serial=2
   string "na"
$ dbus-send --print-reply --system --dest=org.freedesktop.login1 
/org/freedesktop/login1 org.freedesktop.login1.Manager.CanHibernate
method return time=1661890756.999248 sender=:1.1 -> destination=:1.131 
serial=254 reply_serial=2
   string "na"
$ dbus-send --print-reply --system --dest=org.freedesktop.login1 
/org/freedesktop/login1 org.freedesktop.login1.Manager.CanPowerOff
method return time=1661890761.375007 sender=:1.1 -> destination=:1.132 
serial=258 reply_serial=2
   string "yes"
--8<---cut here---end--->8---

This is not surprising since our ‘logind.conf’ reads:

--8<---cut here---start->8---
HybridSleepState=disk
--8<---cut here---end--->8---

… meaning that “hybrid sleep” attempts to suspend-to-disk¹, something
that’s not implemented yet in Guix System².

Setting ‘hybrid-sleep-state’ to '("mem") doesn’t help though:
“CanHybridSleep” still returns “na”.  I’m looking at ‘can_sleep_state’
in elogind without seeing why it doesn’t return true.

To be continued…

Ludo’.

¹ Per <https://man.voidlinux.org/logind.conf.5>.
² But it’s almost there! https://issues.guix.gnu.org/49475

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Ludovic Courtès  skribis:

> As discussed on IRC with Tobias, UPower appears to ignore our
> ‘critical-power-action’ setting.  On my machine, I left the default
> (‘HybridSleep’) but upowerd dismisses it and chooses ‘PowerOff’:

Furthermore, powering off is actually ungraceful: ‘halt’ wasn’t invoked;
the machine just stopped abruptly, fsck was needed on reboot, etc.

The “PowerOff” DBus method is implemented by elogind, so there could be
another bug there.

Ludo’.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

As discussed on IRC with Tobias, UPower appears to ignore our
‘critical-power-action’ setting.  On my machine, I left the default
(‘HybridSleep’) but upowerd dismisses it and chooses ‘PowerOff’:

--8<---cut here---start->8---
$ guix system describe
Generation 198  Aug 29 2022 00:47:53(current)
  file name: /var/guix/profiles/system-198-link
  canonical file name: /gnu/store/85441w3nzqv8lg04gm7601wi9np4qlw7-system
  label: GNU with Linux-Libre 5.18.19
  bootloader: grub-efi
  root device: label: "root"
  kernel: 
/gnu/store/a43ai5qi4vbgm2zywg4b60y71d7whccn-linux-libre-5.18.19/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 3294fa2ba451c7d5ef42a5d9fac780877f364bc7
  configuration file: 
/gnu/store/lmqb5d0il8zydd0p0vz4kviaq1qg4n9m-configuration.scm
$ upower -d | tail -6
Daemon:
  daemon-version:  0.99.15
  on-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: PowerOff
$ sudo herd status upower-daemon 
Status of upower-daemon:
  It is started.
  Running value is 338.
  It is enabled.
  Provides (upower-daemon).
  Requires (dbus-system udev).
  Conflicts with ().
  Will be respawned.
$ sudo cat /proc/338/environ |xargs -0
PWD=/ 
UPOWER_CONF_FILE_NAME=/gnu/store/yq6zf8q2l2axy03d99pami3sxrk4784y-UPower.conf 
SHLVL=0 
XDG_DATA_DIRS=/gnu/store/bnsf9il448hl5xjavbhq3rcx355svz2v-glib-2.70.2/share
$ cat /gnu/store/yq6zf8q2l2axy03d99pami3sxrk4784y-UPower.conf |grep Critical
PercentageCritical=3
TimeCritical=300
CriticalPowerAction=HybridSleep
--8<---cut here---end--->8---

Looking at the code, it could be because the ‘CanHybridSleep’ method
returns false, but why that would happen is unknown to me.

Thoughts?

Ludo’.

bug#56444: Gitolite home directory permissions

[Ludovic Courtès]

Hi there!

Please let’s avoid guessing each other’s willingness to do one thing or
another.

I agree with David that we should accept simple local fixes like this
one, while keeping the “better solution” in sight.  It’s a tradeoff, and
the goal is to make sure we can all move forward.

So I’m all for merging this Gitolite activation patch that David posted
right away; I think you can go ahead, David.

Adding ‘home-permission’ to  as Maxime suggested also
sounds like a welcome improvement to me, but I think it’s fine to do
that separately.

Thanks,
Ludo’.

bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Maxime Devos  skribis:

> On 30-08-2022 09:33, Ludovic Courtès wrote:
>
>> So are you suggesting replacing:
>>
>>(defined? 'make-inetd-constructor)
>>
>> by something like:
>>
>>(version>
>> or is it something different that you have in mind?
>>
>> I’m not sure how this could improve the user experience, unless by
>> “user” you mean the person writing the service?
>
> (defined? '...) does not work in all contexts -- it works on the
> top-level, but not always inside a procedure, as it tests if the thing
> is defined in (current-module), and not whether it is defined in the
> module that calls (defined? '...).

Right, but that’s a bit of a theoretical concern in my view.

Alternatively, one could write:

  (module-defined? (resolve-interface '(shepherd service))
   'make-inetd-constructor)

Thanks,
Ludo’.

bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Agreed, but the context differs wildly: while Autoconf or browsers for
> example really are facing a diversity of configuration, the version of
> Shepherd used in Guix System is known and controlled.  So the only
> problems bound to happen are in this context:
>
> 1. New Shepherd version introduced in Guix (package upgrade).
>
> 2. New Shepherd features used by services.
>
> 3. Machine reconfigured using a commit including 1 and 2.
>
> The problems are temporary: upon a reboot the running Shepherd version
> will be the latest, and have all the features needed.
>
> Hence my suggestion to use something simple to improve the user
> experience of a user faced with 3.

So are you suggesting replacing:

  (defined? 'make-inetd-constructor)

by something like:

  (version

bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Yes.  The issue is that we’re more free-style than systemd: we’re
>> basically loading code live in the running Shepherd.  So we have to
>> write that code such that it works with older Shepherd versions.
>>
>> This is why we have things like conditions on
>>
>>   (defined? 'make-inetd-constructor)
>>
>> and the likes, with a fallback.
>
> I saw that used somewhere, but I still think a minimally required
> Shepherd version field could be of use on services, for the following
> reasons:
>
> 1. Otherwise each services are left implementing ad-hoc solutions.
>
> 2. It's more complicated to be compatible with two Shepherd version than
> simply mentioning the minimum version required, and prevent the service
> from running until it is satisfied (especially on a system like Guix
> System where we *know* what is the current version of Shepherd
> available).

I think it’s a situation similar to “feature tests vs. identity tests”
in build system configuration (checking whether the libc function you
want to use is available rather than checking whether ‘uname’ returns
“Linux”), and for the same reason I tend to prefer feature tests as
shown above.

I won’t pretend it’s pretty :-), but I don’t see an improvement feasible
in the short term.

In the long term, maybe we’d want the service API in the Shepherd to be
more declarative, more like packages in Guix.  But that’s more for a 2.0
horizon IMO.

Perhaps we should close this issue unless it becomes actionable?

Thanks,
Ludo’.

bug#55848: AArch64 Honeycomb builders are inactive

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> I’m currently reconfiguring pankow and grunewald⁰ from berlin with ‘guix
> deploy’ to include the fix above¹, but it’s gonna take a while as it’s
> currently building GCC…

That eventually succeeded and pankow is now reconfigured with the right
daemon settings. \o/

In the meantime, grunewald went off-line so I can’t tell if it’s
properly reconfigured, and kreuzberg is still running the old config I
believe (I cannot log in).

Ricardo, do you have access to these two?

Cheers,
Ludo’.

bug#57071: Xscreensaver not working since latest patch

[Ludovic Courtès]

Heya,

Ludovic Courtès  skribis:

> Rick Huijzer  skribis:
>
>> It seems that xscreensaver-auth needs to be setuid instead of the main
>> xscreensaver binary. The screen-locker-service in xorg.scm sets the
>> provided package setuid and sets the required pam configuration for the
>> provided package. The problem is that the pam configuration needs to be set
>> for xscreensaver (/etc/pam.d/xscreensaver) and setuid needs to be set for
>> xscreensaver-auth.
>>
>> Interestingly when I setuid xscreensaver-auth manually I run into the
>> following when unlocking:
>> Aug 10 13:35:02 localhost unix_chkpwd[2197]: check pass; user unknown
>> Aug 10 13:35:02 localhost unix_chkpwd[2197]: password check failed for user
>> (rhuijzer)
>> Aug 10 13:35:02 localhost xscreensaver-auth: pam_unix(xscreensaver:auth):
>> authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost=
>>  user=rhuijzer
>>
>> But this might be fixed in time by [RFC PATCH] gnu: linux-pam: Change path
>> to unix_chkpwd helper <https://issues.guix.gnu.org/53468>.
>>
>> I don't know how to fix this elegantly, maybe create a dedicated service
>> for xscreensaver instead of the standard screen-locker-service?
>
> Yes, either that or a special case in ‘screen-locker-service’.

With the attached patch I can make ‘xscreensaver-auth’ setuid-root
(which is optional: it’s needed to tweak OOM behavior) while keeping the
‘xscreensaver’ PAM entry that’s needed.

However, authentication’s still failing due to ‘unix_chkpwd’ not working
on current ‘master’ where <https://issues.guix.gnu.org/53468> is
missing.

Ideas on how to work around that?  It’s not clear to me how
‘unix_chkpwd’ ends up being invoked in the first place…

Thanks,
Ludo’.

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 7be995a438..72698aa28a 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -1655,8 +1655,16 @@ (define-public xscreensaver
(lambda _
  (substitute* '("driver/Makefile.in" "po/Makefile.in.in")
(("@GTK_DATADIR@") "@datadir@")
-   (("@PO_DATADIR@") "@datadir@"))
- #t)))
+   (("@PO_DATADIR@") "@datadir@"
+ (add-before 'configure 'adjust-default-path
+   (lambda _
+ ;; On Guix System, give higher precedence to the setuid-root
+ ;; 'xscreensaver-auth' program compared to the one that lives in
+ ;; $libexecdir.  This modifies code in the 'hack_environment'
+ ;; function, which changes $PATH.
+ (substitute* "driver/xscreensaver.c"
+   (("= DEFAULT_PATH_PREFIX")
+"= \"/run/setuid-programs:\" DEFAULT_PATH_PREFIX")
#:configure-flags '("--with-pam"
 
;; Don't check /proc/interrupts in the build
@@ -1704,7 +1712,11 @@ (define-public xscreensaver
 (license (license:non-copyleft
   (string-append
"http://metadata.ftp-master.debian.org/changelogs/;
-   "/main/x/xscreensaver/xscreensaver_5.36-1_copyright")
+   "/main/x/xscreensaver/xscreensaver_5.36-1_copyright")))
+(properties
+ ;; Tell 'screen-locker-service' which program should be setuid-root.
+ '((screen-locker-setuid-program
+. "libexec/xscreensaver/xscreensaver-auth")
 
 (define-public xssproxy
   (package
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 0cbd9aa53b..8f99c0f023 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017 Andy Wingo 
-;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019, 2020 Ludovic Courtès 
+;;; Copyright © 2013-2017, 2019-2020, 2022 Ludovic Courtès 
 ;;; Copyright © 2015 Sou Bunnbu 
 ;;; Copyright © 2018, 2019 Timothy Sample 
 ;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen 
@@ -680,12 +680,26 @@ (define slim-service-type
 ;;;
 
 (define-record-type 
-  (screen-locker name program empty?)
+  (screen-locker name package empty?)
   screen-locker?
   (namescreen-locker-name) ;string
-  (program screen-locker-program)  ;gexp
+  (package screen-locker-package)  ;file-like
   (empty?  screen-locker-allows-empty-passwords?)) ;Boolean
 
+(define (screen-locker-setuid-program-name locker)
+  "Return the name of the setuid program of LOCKER.  It's usually LOCKER's
+name but it might differ in some cases--e.g., 'xscreensaver-auth' for
+XScreenSaver."
+  (let ((package (screen-locker-package locker)))
+(or (and (package? package)
+ (assoc-ref (package-properties pa

bug#55848: [cuirass] workers stalled

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Ludovic Courtès  skribis:
>>
>>> guix-daemon is configured to use the default substitute URLs,
>>> https://ci.guix.gnu.org and https://bordeaux.guix.gnu.org, which we know
>>> are unreachable.
>>>
>>> I’ve theoretically addressed this here:
>>>
>>>   
>>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=99bd9dc9001d6bea7480a7ce0e0e10ff78adb787
>>>   
>>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=b0661cc7d6dd74b0aeac3b052a80a8a2fef2af9c
>>>
>>> I tried to reconfigure those boxes with ‘guix deploy’, but this is
>>> currently on hold because ci.guix has run out of inodes…
>>
>> Time passed and I had kinda forgotten about it, but the problem remains.
>
> I wrote this earlier:
>
>> They should be using the local IP instead of routing through the
>> internet, so /etc/hosts should contain an entry for
>>
>> 141.80.167.131 ci.guix.gnu.org
>
> So running the daemon with “--substitute-urls=http://10.0.0.1” should
> not be necessary.

Oh my bad, sorry for overlooking your message.

Explicitly going through http://10.0.0.1 is still desirable I think
because we avoid HTTPS altogether.

‘guix deploy’ is still running on berlin.guix and building things;
unfortunately I’m going AFK for a bit.  I’ll pick it up later unless
someone takes care of it by then.

Thanks,
Ludo’.

bug#53210: installer: referring to N-1 guix is problematic.

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

>> Let me know if you have comments!
>
> Thanks for taking care of this!
>
> Looks like we have a small regression on 'system-tests and 'guix
> specifications:
>
> https://ci.guix.gnu.org/eval/528053/log/raw
> https://ci.guix.gnu.org/eval/528056/log/raw
>
> I think this is because channel-source->package is given a raw directory
> as source in (gnu ci) while this procedure expects either a channel or a
> lowerable object.

Indeed.  This should be fixed by
a81706494753ad84754cbb7583ccc783452decc0.

Thanks!

Ludo'.

bug#57071: Xscreensaver not working since latest patch

[Ludovic Courtès]

Hi Rick & Roman,

Rick Huijzer  skribis:

> It seems that xscreensaver-auth needs to be setuid instead of the main
> xscreensaver binary. The screen-locker-service in xorg.scm sets the
> provided package setuid and sets the required pam configuration for the
> provided package. The problem is that the pam configuration needs to be set
> for xscreensaver (/etc/pam.d/xscreensaver) and setuid needs to be set for
> xscreensaver-auth.
>
> Interestingly when I setuid xscreensaver-auth manually I run into the
> following when unlocking:
> Aug 10 13:35:02 localhost unix_chkpwd[2197]: check pass; user unknown
> Aug 10 13:35:02 localhost unix_chkpwd[2197]: password check failed for user
> (rhuijzer)
> Aug 10 13:35:02 localhost xscreensaver-auth: pam_unix(xscreensaver:auth):
> authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost=
>  user=rhuijzer
>
> But this might be fixed in time by [RFC PATCH] gnu: linux-pam: Change path
> to unix_chkpwd helper .
>
> I don't know how to fix this elegantly, maybe create a dedicated service
> for xscreensaver instead of the standard screen-locker-service?

Yes, either that or a special case in ‘screen-locker-service’.

Could you give it a try?

Unfortunately I’m going to be away from keyboard for a bit; please do
ping here and/or on IRC if you don’t get a timely reply.

Thanks,
Ludo’.

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> The vm-image.tmpl is the template we use for our graphical Guix demo
> QEMU image that can be downloaded from our site
> (https://guix.gnu.org/en/download/ ->
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2).
>
> This commit was made to allow SPICE dynamic resizing to work, as
> mentioned in a comment part of this commit.  XFCE lacks support for it,
> as also mentioned in the comment
> (https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142), which means
> a new user downloading the image and running it in a SPICE-capable
> viewer such as virt-manager or gnome-boxes will be dismayed that it
> doesn't resize as they may have come to expect from other modern
> distributions.

Understood.

(I wonder if the QEMU Guest Agent can serve a similar purpose.)

>> Should we remove this workaround, possibly finding another one?
>
> I think we should use a desktop environment that is better maintained,

I think this is unfair criticism: Xfce is actively maintained, with a
large user base.

> and which works well with SPICE, without hacks, given the improvements
> to the user experience it provides, and given it's important that a
> first user encounter with Guix be smooth and shiny.  GNOME could do it,
> at the cost of a bigger image size.

Right.  I wouldn’t mind GNOME, but one reason we went for Xfce is that
GNOME is just too big, at least as currently packaged in Guix.

> There are other, perhaps worst issues with XFCE, which is that the
> keyboard layout switcher doesn't work, and it didn't seem trivial to fix
> when I looked at it.

Oh, I wasn’t aware of that, that should certainly be fixed.  (I fixed a
similar issue in GNOME some years ago, and I’m confident it’ll be easier
to fix in Xfce because it doesn’t have all those layers and daemons and
JavaScript and DBus interfaces.  :-))

That’s a general issue with all Xfce installations, not just in the VM
image, right?

Thanks,
Ludo’.

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

>> There’s a third problem that I initially thought was unrelated:
>>
>>   3. The mcron job starts running before ‘xorg-server’ is up, and that
>>  can cause Xorg to fail to start.
>>
>> Namely, if you run the command above, you’ll see that Xorg starts and
>> fails typically a few times in a row, until it eventually succeeds.  In
>> /var/log/messages, you can see that the ‘xorg-server’ process exits with
>> code 1 (without any indication of what went wrong AFAICS) and the
>> service gets respawned.
>>
>> Now if you remove the mcron job and boot the VM, the ‘xorg-server’
>> service successfully starts.  It’s 100% reproducible for me.
>
> I tried to reproduce the problem without any luck on my machine (it
> always boots fine).  Odd.

Does ‘xorg-server’ successfully start from the first time, or does
succeed after a few tries?  For me it systemically tries a couple of
time before it succeeds.

Ludo’.

bug#57067: Missing Xfce icons

[Ludovic Courtès]

Hi,

宋文武  skribis:

> Ludovic Courtès  writes:
>
>> In current ‘master’ (ca. 6db3b34d7203639ef4286c237a6e536259f92352), in a
>> VM created with:
>>
>>   guix system vm gnu/system/examples/vm-image.tmpl
>>
>> Xfce is lacking a few icons in window decorations and in the bar at the top:
>>
>
> Fixed in commit 02b69362cb5922e3e2579b120a12afcc6167a46e now.

Excellent, thanks for the quick fix!

Ludo’.

bug#57091: Git authentication reports subkey fingerprints

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> On 09-08-2022 23:07, Ludovic Courtès wrote:
>> Hello,
>>
>> As Tobias explains at
>> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html>  and
>> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
>> git-authenticate) machinery reports the fingerprint of subkeys on
>> signatures (when subkeys are used) rather than the fingerprint of
>> primary keys.
>>
>> This should be changed to report primary keys, at least optionally.
>
> Why should it be changed? IIUC .guix-authorizations and (guix ...)
> care about the key that things were signed with, not necessarily the
> primary key, so it seems to me that it needs to report the subkey
> fingerprint, not the fingerprint of the primary key it belongs to, as
> the primary key is irrelevant to them IIUC.

Yes, I kinda agree, but…  the motivation here is that OpenPGP user
interfaces don’t normally refer to subkey fingerprints; instead they
refer to primary key fingerprints, even if you use a subkey, which is
the point of subkeys AIUI.  That Guix treats subkeys differently is
confusing to seasoned OpenPGP users.

Ludo’.

bug#57093: 'guix style --whole-file' hangs indefinitely if parenthesis is unmatched

[Ludovic Courtès]

Hi Mohammed,

Mohammed AMAR-BENSABER  skribis:

> guix style --whole-file package.scm hangs indefinitely if parenthesis is 
> unmatched. Relevant commit a15542d26df42dabdb5e2f76d150ae200230c3b0.

Oops, fixed in ebda12e1d2c64480bb7d5977e580d8b2eabeb503:

--8<---cut here---start->8---
$ ./pre-inst-env guix style -f /tmp/t.scm
/tmp/t.scm:25:0: error: unexpected end of file
hint: Did you forget a closing parenthesis?
--8<---cut here---end--->8---

Thanks for your report!

Ludo’.

bug#57095: another "inappropriate ioctl" bug :)

[Ludovic Courtès]

Hi!

Josselin Poiret  skribis:

> We also use a big wrapping `with-error-handling` to display errors
> properly in the case when they are not caught.  The difference is that
> `with-error-handling` adds a non-unwinding handler, while catch is
> unwinding.  My first thought was that non-unwinding handlers, even outer
> ones would get priority over unwinding ones, since once the stack's
> unwound you can't really go back (I have no idea if that last part is
> actually true).  In practice this is actually false, I tested with a
> very simple example, but that lead me to test by setting `#:unwind? #t`
> for the `guard*` definition in guix/ui.scm and the issue went away, so I'm
> clueless as to why this happens.  What seems weird is that the error is
> not caught at all!

The inner handler, even if it’s unwinding and the outer one is not,
appears to have higher precedence:

--8<---cut here---start->8---
scheme@(guix read-print)> (with-exception-handler (lambda args (pk 'outer args))
(lambda ()
  (with-exception-handler
  (lambda args (pk 'inner args))
(lambda()
  (rmdir "/"))
#:unwind? #t))
#:unwind? #f)

;;; (inner (#< components: (#<> #< 
origin: "rmdir"> #< message: "~A"> #< irritants: ("Device or 
resource busy")> #< kind: system-error args: 
("rmdir" "~A" ("Device or resource busy") (16))>)>))
$17 = (#< components: (#<> #< origin: 
"rmdir"> #< message: "~A"> #< irritants: ("Device or resource 
busy")> #< kind: system-error args: ("rmdir" "~A" 
("Device or resource busy") (16))>)>)
scheme@(guix read-print)> (with-exception-handler (lambda args (pk 'outer args))
(lambda ()
  (catch 'system-error
(lambda ()
  (rmdir "/"))
(lambda args
  (pk 'inner args
#:unwind? #f)

;;; (inner (system-error "rmdir" "~A" ("Device or resource busy") (16)))
$18 = (system-error "rmdir" "~A" ("Device or resource busy") (16))
--8<---cut here---end--->8---

This appears to work:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix build syscalls)
scheme@(guile-user)> (terminal-columns)
$19 = 119
scheme@(guile-user)> ,use(guix ui)
scheme@(guile-user)> (with-error-handling (terminal-columns))
$20 = 119
scheme@(guile-user)> (terminal-columns (open-input-string ""))
$21 = 143
scheme@(guile-user)> (with-error-handling (terminal-columns (open-input-string 
"")))
$22 = 143
--8<---cut here---end--->8---

Needs more investigation…

Ludo’.

bug#57117: ‘guix deploy’ doesn’t honor (build-locally? #f) in the presence of grafts

[Ludovic Courtès]

In current ‘master’ (ca. f0ae9da3210cc6d87ca519545203daf9751f3465), when
passed a set of ‘machine-ssh-configuration’ machines, ‘guix deploy’ ends
up trying to build locally even if those machines have:

  (build-locally? #f)

Passing ‘--no-grafts’ works around the problem.

Ludo’.