bug#43534: qemu-minimal-5.1.0 fails to build during test phase on aarch64

[Stefan]

Hi Maxim!

> Do you think this is a regression?  I doubt so, because even before
> pushing the update to 5.1.0, the test suite of qemu (not qemu-minimal)
> was failing on master.

I don’t know. Until today I always got a substitute. There was at least a 
successful build in late August.

http://ci.guix.gnu.org/search?query=system%3Aaarch64-linux+spec%3Aguix-master+qemu-minimal-5

> The error in the log you posted appear to be:
> 
> ERROR:tests/qtest/arm-cpu-features.c:508:test_query_cpu_model_expansion_kvm: 
> assertion failed: (resp_has_props(_resp))
> ERROR arm-cpu-features - Bail out! 
> ERROR:tests/qtest/arm-cpu-features.c:508:test_query_cpu_model_expansion_kvm: 
> assertion failed: (resp_has_props(_resp))

I only searched for “FAIL”. :-)

The same test was passing in August.

http://ci.guix.gnu.org/log/391wav2qcfd1wkss2ssv408zhbgcxhq7-qemu-minimal-5.0.0

MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=arm-softmmu/qemu-system-arm QTEST_QEMU_IMG=qemu-img 
tests/qtest/arm-cpu-features -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="arm-cpu-features" 
PASS 1 arm-cpu-features /arm/arm/query-cpu-model-expansion
…
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 QTEST_QEMU_IMG=qemu-img 
tests/qtest/arm-cpu-features -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="arm-cpu-features" 
PASS 1 arm-cpu-features /aarch64/arm/query-cpu-model-expansion
PASS 2 arm-cpu-features /aarch64/arm/kvm/query-cpu-model-expansion
PASS 3 arm-cpu-features /aarch64/arm/kvm/query-cpu-model-expansion/sve-off
PASS 4 arm-cpu-features /aarch64/arm/max/query-cpu-model-expansion/sve-max-vq-8
PASS 5 arm-cpu-features /aarch64/arm/max/query-cpu-model-expansion/sve-off


Bye

Stefan

bug#43534: qemu-minimal-5.1.0 fails to build during test phase on aarch64

[Stefan]

Hi Maxim!

> Is this reproducible on your side?

Retrying my previous command it found a substitute this time.

stefan@guix ~/development/guix$ sudo -E -b ./pre-inst-env guix system 
reconfigure -L /home/stefan/guix/ /home/stefan/guix-system.scm &> nohup.out && 
tail -f nohup.out
Passwort: 
guix system: warning: cannot determine provenance for current system
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
The following derivations will be built:
   
/gnu/store/rgpllviv84cfhhd3bnnkmjpa1ndph8wh-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04.drv
   /gnu/store/12balhwfp2lzqyvy246j9zgh0zif16pn-grub-efi-2.04.drv

18,7 MB will be downloaded
downloading from 
https://ci.guix.gnu.org/nar/lzip/6da0v0yb0ikw348y8rm431nnd947mla7-qemu-minimal-5.1.0
 ...
 qemu-minimal-5.1.0  17.8MiB  533KiB/s 00:34 [##] 100.0%

building /gnu/store/12balhwfp2lzqyvy246j9zgh0zif16pn-grub-efi-2.04.drv…


Is it possible, that the test is somehow picky about the exact type of 
processor in use?


By the way, I also tried this command:

guix build --rounds=2 qemu-minimal --no-substitutes

But (probably because I got a substitute) it did not compile anything – I’m a 
bit clueless how to compile it again.


Bye

Stefan

bug#44525: Derivation of computed-file has no outputs

[Stefan]

Hi!

I try to use a computed-file as an input to a bootloader profile hook function. 
Using guix system I get this error message:

guix system: error: reference to invalid output 'out' of derivation 
'/gnu/store/946szbrwn3ja74yjnibbhjisjflvsk73-test.txt.drv'

This is the simple definition of the computed-file:

(computed-file "test.txt" (with-imported-modules '((guix utils)) 
#~(%current-system)))

And this is the content of the generated derivation of it:

Derive([],[("/gnu/store/0hcx4wgpgf1nn4gl3lhnd055vj2y28cj-guile-3.0.2.drv",["out"]),("/gnu/store/2ss1lzy0x0wwayy5n5mvzmsv77dnni39-module-import-compiled.drv",["out"])],["/gnu/store/9lw2pp0hjcjgmq5hx7w6aq92699r6pim-module-import","/gnu/store/plgbvrkkq1ghvph24kf0bdgb4w8glgqb-test.txt-builder"],"aarch64-linux","/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile",["--no-auto-compile","-L","/gnu/store/9lw2pp0hjcjgmq5hx7w6aq92699r6pim-module-import","-C","/gnu/store/3v6bh2hn62i4qp674d1hqg4ca7hpys3a-module-import-compiled","/gnu/store/plgbvrkkq1ghvph24kf0bdgb4w8glgqb-test.txt-builder"],[("preferLocalBuild","1")])

I think the problem is visible already with this call:

scheme@(guile-user)> (derivation-path->output-paths 
"/gnu/store/946szbrwn3ja74yjnibbhjisjflvsk73-test.txt.drv")
$5 = ()


Bye

Stefan

bug#44525: Derivation of computed-file has no outputs

[Stefan]

Hi Marius!

> Assuming you intended to write (%current-system) to test.txt, you can do
> something along these lines:
> 
>  (computed-file "test.txt"
> #~(call-with-output-file #$output
> (lambda (port)
>   (format port #$(%current-system)

Thanks for this solution.

> That's expected: this derivation does not produce any outputs.
> So I think this is not-a-bug.  WDYT?


I think I got a bit distracted by the functionality of plain-file and the 
similar wording of the documentation of computed-file.

Thanks, I’ll close this issue.


Bye

Stefan

bug#44525:

[Stefan]

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Stefan]

Hi!

After trying to just build a package (with a modified guix, but this is 
certainly unrelated), the system broke catastrophically:

stefan@guix ~/development/guix$ sudo -E ./pre-inst-env guix-daemon 
--build-users-group=guixbuild &
stefan@guix ~/development/guix$ /home/stefan/development/guix/pre-inst-env guix 
build -L /home/stefan/guix u-boot-rpi-3
accepted connection from pid 23848, user stefan
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
12,5 MB will be downloaded:
   /gnu/store/ldg4jqfan2vp01lm255zz7zrb4vllixp-libxau-1.0.9
   /gnu/store/m1r4jwmc56q44x31xcnvg1hcijf0lq88-libxcb-1.14
   /gnu/store/8b75zmsyxc5qghfrxhyqi6g23bq993b1-libbsd-0.10.0
   /gnu/store/z18hwxwgk551y4a0f6j1dxhmp208i4ha-bash-static-5.0.16
   /gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31
   /gnu/store/z7hanmdmdalqh1v0y7z8ilinfhyfh91d-glibc-2.31-static
   /gnu/store/pcsl88vd66k62sk1g4wcc9i985xn369m-libxdmcp-1.1.3
   /gnu/store/785ldh00ix897pamyg5p6fpjls6ddwzz-libx11-1.6.A-doc
   /gnu/store/x10mk7ri4ny013km57d3h5093270r7pg-libx11-1.6.A
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substituting /gnu/store/785ldh00ix897pamyg5p6fpjls6ddwzz-libx11-1.6.A-doc...
downloading from 
https://ci.guix.gnu.org/nar/lzip/785ldh00ix897pamyg5p6fpjls6ddwzz-libx11-1.6.A-doc
 ...
 libx11-1.6.A-doc  1.2MiB  309KiB/s 
00:04 [##] 100.0%

substituting /gnu/store/z18hwxwgk551y4a0f6j1dxhmp208i4ha-bash-static-5.0.16...
downloading from 
https://ci.guix.gnu.org/nar/lzip/z18hwxwgk551y4a0f6j1dxhmp208i4ha-bash-static-5.0.16
 ...
 bash-static-5.0.16  502KiB976KiB/s 
00:01 [##] 100.0%

guix build: error: cannot unlink 
`/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale/de/LC_MESSAGES':
 Directory not empty
stefan@guix ~/development/guix$ /home/stefan/development/guix/pre-inst-env guix 
build -L /home/stefan/guix u-boot-rpi-3
accepted connection from pid 23911, user stefan
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
12,0 MB will be downloaded:
   /gnu/store/ldg4jqfan2vp01lm255zz7zrb4vllixp-libxau-1.0.9
   /gnu/store/m1r4jwmc56q44x31xcnvg1hcijf0lq88-libxcb-1.14
   /gnu/store/8b75zmsyxc5qghfrxhyqi6g23bq993b1-libbsd-0.10.0
   /gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31
   /gnu/store/z7hanmdmdalqh1v0y7z8ilinfhyfh91d-glibc-2.31-static
   /gnu/store/pcsl88vd66k62sk1g4wcc9i985xn369m-libxdmcp-1.1.3
   /gnu/store/785ldh00ix897pamyg5p6fpjls6ddwzz-libx11-1.6.A-doc
   /gnu/store/x10mk7ri4ny013km57d3h5093270r7pg-libx11-1.6.A
guix build: error: cannot unlink 
`/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib/gconv': Directory 
not empty
stefan@guix ~/development/guix$ /home/stefan/development/guix/pre-inst-env guix 
build -L /home/stefan/guix u-boot-rpi-3
-bash: /home/stefan/development/guix/pre-inst-env: /bin/sh: Defekter 
Interpreter: No such file or directory
stefan@guix ~/development/guix$ ls
-bash: /run/current-system/profile/bin/ls: No such file or directory
stefan@guix ~/development/guix$ echo $PATH
/run/setuid-programs:/home/stefan/.config/guix/current/bin:/home/stefan/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin
stefan@guix ~/development/guix$ ls
-bash: /run/current-system/profile/bin/ls: No such file or directory


The problem that the unlink was not successful was certainly due to a deleted 
but still opened file on the NFS share. There may be an intermediate hidden 
.nfs… file, which get created in such a case (“delete on last close”, “silly 
rename”), However, the RFC-5661 for NFS demands even if 
OPEN4_RESULT_PRESERVE_UNLINKED is supported, that the directory entry of an 
open file must not be removed in this case, thus preventing a directory removal.

Taking a look on the nfs-server, this is now the content of the glibc:

# ls gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib -l
total 12
drwxr-xr-x 2 root root 12288 Nov 18 19:41 gconv
lrwxrwxrwx 7 root root11 Jan  1  1970 libanl.so -> libanl.so.1

Everything is missing.

Of course I tried to reboot the system, but because of the missing 
ld-linux-aarch64.so.1 the system is not booting properly.


This leaves some questions:

If the whole system (maybe not the booted/running one, but a reconfigured one) 
was already using /gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31, why 
has it been downloaded again when building a package? Was this due to grafting?

How can it be that the store is kind of “state“ being modified on the fly?

How does it come that removing files for 
/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31 happens before the 
download even started? Could this render a system unusable if a network loss 
happens at the right point in time?

Booting the previous system generation luckily worked – it must be using a 
different glibc version. But now what abo

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Stefan]

Hi!

I resolved the problem by copying 
gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31 from 
https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc2.aarch64-linux.tar.xz into 
gnu/store on the NFS server. The system is running again.

Now I retried my commands and I am able to reproduce the problem:

stefan@guix ~/development/guix$ /home/stefan/development/guix/pre-inst-env guix 
build -L /home/stefan/guix u-boot-rpi-3
accepted connection from pid 241, user stefan
12,0 MB will be downloaded:
/gnu/store/ldg4jqfan2vp01lm255zz7zrb4vllixp-libxau-1.0.9
/gnu/store/m1r4jwmc56q44x31xcnvg1hcijf0lq88-libxcb-1.14
/gnu/store/8b75zmsyxc5qghfrxhyqi6g23bq993b1-libbsd-0.10.0
/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31
/gnu/store/z7hanmdmdalqh1v0y7z8ilinfhyfh91d-glibc-2.31-static
/gnu/store/pcsl88vd66k62sk1g4wcc9i985xn369m-libxdmcp-1.1.3
/gnu/store/785ldh00ix897pamyg5p6fpjls6ddwzz-libx11-1.6.A-doc
/gnu/store/x10mk7ri4ny013km57d3h5093270r7pg-libx11-1.6.A
guix build: error: cannot unlink 
`/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale/de/LC_MESSAGES':
 Directory not empty


This is now the diff of a correct cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31 
and the now broken one:

# diff -r cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/ 
guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/: etc
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/: include
Only in 
guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib/gconv: 
.nfs03a20e49231b
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20e882314
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20e932316
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20e972311
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20e9a2317
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20e9d2315
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20eac2319
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20eb32318
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20eb82313
Only in guix-system/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/lib: 
.nfs03a20ec12312
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/: libexec
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share: doc
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share: i18n
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share: info
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: be
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: ca
Only in 
cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale/de/LC_MESSAGES: @eaDir
Only in 
cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale/de/LC_MESSAGES: libc.mo
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: en_GB
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: eo
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: es
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: fi
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: fr
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: hu
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: ja
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: ko
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: lt
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: nb
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: pl
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: pt
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: pt_BR
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: rw
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: sk
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: sv
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: uk
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: vi
Only in cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31/share/locale: zh_TW

Indeed there are the hidden .nfs files leading to the unlink error.
If I would try the same commands a second time, as before, then more files will 
be removed and my system will brake again.

Why is guix trying to reinstall 
/gnu/store/cb88z63hyg1icd2kkahiink2p291mhr2-glibc-2.31? It is part of the 
running system already.


Bye

Stefan

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Stefan]

Hi!

I found the root cause of this issue: I made a typo and inadvertently did a 
“./configure --localstatedir=/vaar”.

The manual should warn that using a wrong (or omitted) --localstatedir may 
destroy the guix installation and possibly the whole guix system.

What can be done to prevent that a simple mistake like this destroys a system?


Having the configure command boxed inside the manual would at least reduce the 
risk of overlooking this, see also https://issues.guix.gnu.org/40848. But this 
still does not prevent anything.


Bye

Stefan

bug#44758: doc: build system arguments #:modules and #:imported-modules are not documented

[Stefan]

Hi!

The build system arguments #:modules and #:imported-modules are not documented.

They are at least evaluated by the gnu-build-system, probably by even more 
build systems. I think the trivial-build-system only accepts a #:modules 
argument.

Further it seems important to also document %gnu-build-system-modules (and 
maybe others?) and its use inside #:important-modules.

The cookbook neither mentions one of these arguments.


Bye

Stefan

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Stefan]

Hi Ludo’!

> Your store database may no longer be in sync with your actual store so
> you may have to reinstall.  You can try ‘guix gc --verify’ to get an
> idea of how bad the situation is.

stefan@guix ~/development/guix$ guix gc --verify
reading the store...
checking path existence...
path `/gnu/store/1kh1p8ypgn1yn826cc0mizw7gjjn5yfb-usbutils-012-guile-builder' 
disappeared, removing from database...
path `/gnu/store/da76qwnqrfravn2qd92b6vk5inp7273v-vala-0.44.5.drv' disappeared, 
removing from database...
path `/gnu/store/iq987sfc1bwyaijckagv59b0z2z3c4nb-vala-0.44.5.drv' disappeared, 
removing from database...
path 
`/gnu/store/m7l8381hqz4dgp12v9fbnf0k9n1ij5ja-module-import-compiled-guile-builder'
 disappeared, removing from database...
path 
`/gnu/store/mnhh9m6v88zk9k7lc6hj15db40qv5cnh-guix-packages-base-modules-builder'
 disappeared, removing from database...
path `/gnu/store/nal2ssav0z0qk523w5v6xp2vfqqfpc13-guix-module-union-builder' 
disappeared, removing from database...
path `/gnu/store/x5gczh79g5aarws1xgkcp2gc1av4fzas-vala-0.44.5.tar.xz.drv' 
disappeared, removing from database…

stefan@guix ~/development/guix$ guix gc --verify
reading the store...
checking path existence…

stefan@guix ~/development/guix$

That doesn’t seem to be so bad. :-)

> ./configure warns or errors out and the manual warns in a couple of
> places too, but evidently it remains too easy to shoot oneself in the
> foot.

It warns in the chapter “2 Requirements”. It doesn’t warn in chapter ”14.1 
Building from Git”.

Anyway, it was just a typo. Even if I would have known about that warning, this 
would have happened. 

> Could you check ‘config.log’ to see what ‘configure’ said?  You can see
> the source of this check at the bottom of ‘m4/guix.m4’.

I retried:

stefan@guix ~/development/guix [env]$ ./configure --localstatedir=/vaar
checking for a BSD-compatible install... 
/gnu/store/5hj9mdr79nqfcqg9hb45dpfrrs5qqrnr-profile/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... 
/gnu/store/5hj9mdr79nqfcqg9hb45dpfrrs5qqrnr-profile/bin/mkdir -p
checking for gawk… gawk

[pages of checking]

checking the current installation's localstatedir... /var
configure: WARNING: chosen localstatedir '/vaar' does not match that of the 
existing installation '/var'
configure: WARNING: installing may corrupt /gnu/store!
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/guix/Makefile.in
config.status: creating po/packages/Makefile.in
config.status: creating etc/guix-daemon.cil
config.status: creating guix/config.scm
config.status: creating etc/committer.scm
config.status: creating test-env
config.status: creating pre-inst-env
config.status: creating nix/config.h
config.status: nix/config.h is unchanged
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/guix/POTFILES
config.status: creating po/guix/Makefile
config.status: creating po/packages/POTFILES
config.status: creating po/packages/Makefile
stefan@guix ~/development/guix [env]$ 

Indeed, there in all that pages of output, luckily on the last page, there is a 
warning. I could have noticed it. But I did’t. Red colour could have helped. :-)

The same warning is hidden inside the very middle of the config.log. At least 
the mistake with localstatedir is visible right at its beginning. 

Would it be possible to do that check right at the beginning of configure and 
ask the user for confirmation?

> Also, why did you run guix-daemon from your checkout?  This is only
> necessary if you’re actually hacking on the daemon, but perhaps the
> manual is misleading.  (Hadn’t you run guix-daemon from the checkout,
> the problem would not have occurred, even with a wrong
> ‘--localstatedir’.)

I was trying to add a build side module into guix/build. This failed all the 
time with an error “no code for module”. As neither #:modules nor 
#:imported-modules are documented (see also 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44758), I was a bit clueless. Then 
I found out, that I have to add the module into Makefile.am and have to run 
configure. And there the typo happened. But still this was’t working and I 
thought that I may need to start the daemon with pre-inst-env to have the 
GUILE_LOAD_PATH properly point to guix/build. Well, and so the disaster 
happened.


Bye

Stefan

bug#41654: [PATCH] tests: Ignoring incomplete clean-up on NFS share.

[Stefan]

* tests/guix-package.sh: The 'rm -rf' for clean-up inside the trap may not
succeed on an NFS share, but this should not fail the test.
---
 tests/guix-package.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/guix-package.sh b/tests/guix-package.sh
index 3e5fa71d20..b1c6eeffb8 100644
--- a/tests/guix-package.sh
+++ b/tests/guix-package.sh
@@ -33,7 +33,7 @@ profile="t-profile-$$"
 tmpfile="t-guix-package-file-$$"
 rm -f "$profile" "$tmpfile"
 
-trap 'rm -f "$profile" "$profile.lock" "$profile-"[0-9]* "$tmpfile"; rm -rf 
"$module_dir" t-home-'"$$" EXIT
+trap 'rm -f "$profile" "$profile.lock" "$profile-"[0-9]* "$tmpfile"; rm -rf 
"$module_dir" t-home-'"$$"' || echo  "incomplete clean-up ignored"' EXIT
 
 # Use `-e' with a non-package expression.
 ! guix package --bootstrap -e +
-- 
2.29.2

bug#41654: test-name: verify-store + check-contents failing on guix-1.2.0rc2-1.0d4b1af

[Stefan]

Hi!

The “dtmp/” issue is not new. It appeared already in these bugs: 

https://issues.guix.gnu.org/27032
https://issues.guix.gnu.org/27034
https://issues.guix.gnu.org/29676

In all cases it happens in tests/store.scm:

test-name: verify-store + check-contents

This bug happened on x86_64 and aarch64.
 
The issues 27032 and 27034 where reported when the installer used a unionfs. 
Probably it was hidden when switching to an overlayfs.

This issue 41654 and 29676 show the “dtmp/” error when running this test on an 
NFS share.


Bye

Stefan

bug#45196: guile-studio cannot open file

[Stefan]

Hi!

These two commands reproduce an error in guile-studio/emacs, which prevents it 
from opening the file argument:

stefan@guix ~/development/guix$ guix environment --pure --ad-hoc guile-studio
stefan@guix ~/development/guix [env]$ guile-studio README

This is the error in emacs’ Messages buffer:

Loading 
/gnu/store/2z03mc1hyq8ii0w7n5ggwf4j5qb8kfyq-emacs-27.1/share/emacs/site-lisp/guix-emacs.el
 (source)...done
eval-buffer: Cannot open load file: No such file or directory, company

The passed file README will not be opened.


Bye

Stefan

bug#36380: service urandom-seed takes too long on boot

[Stefan]

Hi!

I’m running Guix in qemu on a NAS. The boot takes sometimes more than 30 
minutes, probably waiting to start the urandom-seed service.

Guix is using virtio_rng:

stefan@guix ~$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0 
stefan@guix ~$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio_rng.0
stefan@guix ~$ guix describe
Generation 126. Dezember 2020 15:06:11  (aktuell)
  guix 4969b51
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: 4969b51d175497bfcc354c91803e9d70542b7113


This may be relevant information from dmesg:

[0.194324] random: get_random_u64 called from 
__kmem_cache_create+0x30/0x460 with crng_init=0
…
[3.271767] random: fast init done
…
[3.497369] random: crng init done
…
[   21.228829] shepherd[1]: Service file-systems has been started.
[   21.243838] shepherd[1]: Service user-homes has been started.
[ 2182.735965] shepherd[1]: Service urandom-seed has been started.
[ 2182.737229] shepherd[1]: Service user-processes has been started.
…

Sometimes the urandom-seed service takes “just” 200 seconds – still a lot.

Interestingly during this time-out the system can’t be pinged, the networking 
with dhclient doesn't seem to be done.

The Guix installer iso is not using the urandom-seed service and does not 
suffer from this delay.


The host kernel and qemu are rather old:

~$ uname -a
Linux  4.4.59+ #25426 SMP PREEMPT Mon Dec 14 18:48:50 CST 2020 x86_64 
GNU/Linux synology_apollolake
~$ /usr/local/bin/qemu-system-x86_64 --version
QEMU emulator version 2.12.1 (-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers


Qemu is invoked with these arguments concerning random:

-cpu 
host,+smap,+rdseed,+erms,+smep,+fsgsbase,+3dnowprefetch,+rdtscp,+pdpe1gb,+rdrand,+osxsave,+xsave,+tsc-deadline,+movbe,+x2apic,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
 -object rng-random,id=objrng0,filename=/dev/random -device 
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x1c

The full qemu command is huge. I can provide it on request.


Bye

Stefan

bug#36380: service urandom-seed takes too long on boot

[Stefan]

Hi Leo!

> What does the argument "filename=/dev/random" do? Does it use the host's
> /dev/random to provide entropy to the QEMU guest?

Yes, see [1]:

“-object rng-random,id=id,filename=/dev/random
Creates a random number generator backend which obtains entropy from a device 
on the host. The id parameter is a unique ID that will be used to reference 
this entropy backend from the virtio-rng device. The filename parameter 
specifies which file to obtain entropy from and if omitted defaults to 
/dev/urandom.”


Bye

Stefan


[1] https://www.qemu.org/docs/master/system/invocation.html#hxtool-10

bug#45508: ‘guix system disk-image‘ installs GRUB debug files

[Stefan]

Hi!

I noticed that ‘guix system disk-image’ installs GRUB with its debug files, 
which doubles the size for GRUB inside the image.

There is gnu/bootloader/grub.scm (install-grub), which does a simple

  (copy-recursively (string-append bootloader "/lib/") install-dir)

This also copies gdb_grub, gmodule.pl and all *.module files, in total about 
200 files. These *.module file are basically unstriped versions of the *.mod 
files.

The (install-grub) function should prevent to install these files, or – 
possibly better – the grub package could move these files into a separate debug 
output.


Bye

Stefan

bug#41654: test-name: verify-store + check-contents failing on guix-1.2.0rc2-1.0d4b1af

[Stefan]

Hi Ludo’!

Could you please take a look at the bug report 
<https://issues.guix.gnu.org/41654>?

There are two reproducible problems when building the guix-1.2.0 package. 

There is a patch already for the first of the two problems (an incomplete 
cleanup) at <https://issues.guix.gnu.org/41654#2>.

For the other issue with a wrong path "dtmp/guix-tests/store/", there is a 
summary at <https://issues.guix.gnu.org/41654#3>. This problem is existing 
since years and seems to be depending on the underlying file-system. It seems 
to appear with a tmp-store on a unionfs-fuse or NFS. In the past it got hidden 
by switching to overlayfs or changes on the NFS server side. 

As the CI for aarch64 is always lagging behind these issues are kind of 
blockers to me. Today they block the build of guix-1.2.0-8.7624ebb.


Bye

Stefan

bug#41654: test-name: verify-store + check-contents failing on guix-1.2.0rc2-1.0d4b1af

[Stefan]

Hi!

Today I thought that it should be possible to work around this bug on my 
aarch64 system by mounting /tmp as a tmpfs, backed by swap on a small SD card, 
to prevent any issues due to my NFS root. This worked for the 
trap-cleanup-issue. But to my surprise this didn’t work out for the “dtmp/” 
error.

I was wondering, if using /tmp as a tmpfs on my virtual x86_64 system would 
make the test fail there as well. So I did 

sudo mount -t tmpfs -o size=768M tmpfs /tmp
guix build --check --no-grafts guix@1.2.0-8.7624ebb

But there it was passing.

This is the interesting part from the log of the aarch64 system:

test-name: verify-store + check-contents
location: /tmp/guix-build-guix-1.2.0-8.7624ebb.drv-0/source/tests/store.scm:1156
source:
+ (test-assert
+   "verify-store + check-contents"
+   (with-store
+ s
+ (let* ((text (random-text))
+(drv (build-expression->derivation
+   s
+   "corrupt"
+   `(let ((out (assoc-ref %outputs "out")))
+  (call-with-output-file
+out
+(lambda (port) (display ,text port)))
+  #t)
+   #:guile-for-build
+   (package-derivation
+ s
+ %bootstrap-guile
+ (%current-system
+(file (derivation->output-path drv)))
+   (with-derivation-substitute
+ drv
+ text
+ (and (build-derivations s (list drv))
+  (verify-store s #:check-contents? #t)
+  (begin
+(chmod file 420)
+(call-with-output-file
+  file
+  (lambda (port) (display "corrupt!" port)))
+#t)
+  (not (verify-store s #:check-contents? #t))
+  (delete-paths s (list file)))
actual-value: #f
actual-error:
+ (%exception
+   #<&store-protocol-error message: "path 
`dtmp/guix-tests/store/rn6xq5kaipp8aanhcnz2hvyfmr3y2laa-mirrors' is not in the 
store" status: 1>)
result: FAIL


Bye

Stefan

bug#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

[Stefan]

Hi!

I setup my virtual x86_64 system with an qemu-binfmt-service-type for aarch64 
and tried to build guix for aarch64. But this failed because of a missing guile:

stefan@guix ~$ guix build -s aarch64-linux guix@1.2.0-8.7624ebb
Folgende Ableitung wird erstellt:
   /gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv
/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv wird 
erstellt …
while setting up the build environment: executing 
`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
file or directory
builder for 
`/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv' failed 
with exit code 1
Erstellung von 
/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv 
fehlgeschlagen
Das Erstellungsprotokoll kann unter 
„/var/log/guix/drvs/4w/dh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv.bz2“
 eingesehen werden.
guix build: error: build of 
`/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv' failed

I did a guix gc and then tried to build guile itself. But again it failed to 
build because it is missing guile itself.

stefan@guix ~$ guix build --check --no-grafts --system=aarch64-linux guile@3.0.2
24,0 MB werden heruntergeladen:
   /gnu/store/6yw1j6n9rklnfgxs2fsi81fis23lvkjw-bash-minimal-5.0.16
   …
Substituiere /gnu/store/z18hwxwgk551y4a0f6j1dxhmp208i4ha-bash-static-5.0.16 …
Lade von 
https://ci.guix.gnu.org/nar/lzip/z18hwxwgk551y4a0f6j1dxhmp208i4ha-bash-static-5.0.16
 herunter …
 bash-static-5.0.16  502KiB 
3.3MiB/s 00:00 [##] 100.0%
…
/gnu/store/qa15xk65hfx8vhwbnff62iy6g8q9d764-guile-3.0.2.drv wird erstellt …
while setting up the build environment: executing 
`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
file or directory
builder for `/gnu/store/qa15xk65hfx8vhwbnff62iy6g8q9d764-guile-3.0.2.drv' 
failed with exit code 1
Erstellung von /gnu/store/qa15xk65hfx8vhwbnff62iy6g8q9d764-guile-3.0.2.drv 
fehlgeschlagen
Das Erstellungsprotokoll kann unter 
„/var/log/guix/drvs/qa/15xk65hfx8vhwbnff62iy6g8q9d764-guile-3.0.2.drv.bz2“ 
eingesehen werden.
guix build: error: build of 
`/gnu/store/qa15xk65hfx8vhwbnff62iy6g8q9d764-guile-3.0.2.drv' failed

Then I thought to try to download the referred but missing guile:

stefan@guix ~$ guix download 
https://ci.guix.gnu.org/nar/lzip/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2
Starting download of /tmp/guix-file.q3Qwo3
From 
https://ci.guix.gnu.org/nar/lzip/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2...
 …62s2i8y7rl-guile-3.0.2  6.8MiB
5.6MiB/s 00:01 [##] 100.0%
/gnu/store/5aq0m64wlh6mhi6g61z13asdnv8dmq3k-x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2
159d8i1yp0ksh7c9fib2ki7pljjhszk6l3bs9xibnx0kjh78rvli

Afterwards building guix for aarch64 was possible.


Bye

Stefan

bug#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

[Stefan]

Hi!

> Then I thought to try to download the referred but missing guile:
> 
> stefan@guix ~$ guix download 
> https://ci.guix.gnu.org/nar/lzip/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2
> Starting download of /tmp/guix-file.q3Qwo3
> From 
> https://ci.guix.gnu.org/nar/lzip/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2...
> …62s2i8y7rl-guile-3.0.2  6.8MiB   
>  5.6MiB/s 00:01 [##] 100.0%
> /gnu/store/5aq0m64wlh6mhi6g61z13asdnv8dmq3k-x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2
> 159d8i1yp0ksh7c9fib2ki7pljjhszk6l3bs9xibnx0kjh78rvli
> 
> Afterwards building guix for aarch64 was possible.

I was too optimistic with this, I didn't wait for the result before sending the 
e-mail.

Well, the rebuild failed again, as the freshly downloaded guile is not part of 
the build environment. So the same error happened again:

while setting up the build environment: executing 
`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
file or directory
builder for `/gnu/store/qa15xk65hfx8vhwbnff62iy6g8q9d764-guile-3.0.2.drv' 
failed with exit code 1

This becomes a blocker now:

 • There is no substitute of guix@1.2.0-8.7624ebb for aarch64.
 • Due to <https://issues.guix.gnu.org/41654> building locally an aarch64 is 
not possible for me.
 • Due to ‘guix system’ not supporting ‘--without-test’ I can’t avoid that 
error when reconfiguring.
 • Due to this error with a missing guile even building on x86_64 is impossible.
 • Cross-building on x86_64 is possible but creates a derivation with a 
different hash. So it will not satisfy the need for a ‘guix system reconfigure’ 
on aarch64.


Bye

Stefan

bug#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

[Stefan]

Hi Efraim!

> I just came across this today myself. try 'sudo herd restart
> guix-daemon'. It's what made it suddenly start working for me (I
> reconfigured to add qemu-binfmt service without restarting).

Indeed I didn’t restart guix-daemon after the reconfigure. I looked through my 
console log again and I see that I did a reboot after facing this problem. So 
the guix-daemon should not have been the problem in the end.

I retried everything now: reconfigure, restart guix-daemon, build guix for 
aarch64, but unfortunately the problem remains. 

Thanks for your response Efraim, it gives me some hope that I can escape my 
deadlock somehow.


stefan@guix ~$ sudo -E guix system reconfigure guix-system.scm 
Passwort: 
/gnu/store/bhz37cjjhqsfd26vrnlka6qxirqnw6q8-system
/gnu/store/7f385ijy7r9j3vxsisizhk7r9xpf2q5n-grub.cfg

System wird aktiviert …
making '/gnu/store/bhz37cjjhqsfd26vrnlka6qxirqnw6q8-system' the current 
system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/xkd47jda21whyc70gfy4ackvlkmjaslp-etc...
`/gnu/store/4blizgsx21j1hfn4v25gs4235cq8ani7-openssh-authorized-keys/stefan' -> 
`/etc/ssh/authorized_keys.d/stefan'
Folgende Ableitungen werden erstellt:
   /gnu/store/ipsj88x3bxm0i1ygs6sh03c87g3qq8lx-install-bootloader.scm.drv
   /gnu/store/y201j3lz7cc5sxv4fx8094aan4dyaxps-module-import.drv

0,7 MB werden heruntergeladen
Lade von 
https://ci.guix.gnu.org/nar/lzip/wjpkjxbgmirxdy5r3jhy83pb50m9i48s-module-import-compiled
 herunter …
 module-import-compiled  671KiB 
2.0MiB/s 00:00 [##] 100.0%

/gnu/store/y201j3lz7cc5sxv4fx8094aan4dyaxps-module-import.drv wird erstellt …
/gnu/store/ipsj88x3bxm0i1ygs6sh03c87g3qq8lx-install-bootloader.scm.drv wird 
erstellt …
guix system: Bootloader erfolgreich auf „/boot/efi“ installiert
0,0 MB werden heruntergeladen
Lade von 
https://ci.guix.gnu.org/nar/lzip/q9wrh0rrhq3sy3n2i6m73ijql7a1m2nm-module-import-compiled
 herunter …
 module-import-compiled  24KiB  
 65KiB/s 00:00 [##] 100.0%

Folgende Ableitung wird erstellt:
   /gnu/store/jympl6hv53c7df6mm0jkjjzq0zzxi2yw-upgrade-shepherd-services.scm.drv

/gnu/store/jympl6hv53c7df6mm0jkjjzq0zzxi2yw-upgrade-shepherd-services.scm.drv 
wird erstellt …
shepherd: Service host-name has been started.
shepherd: Service user-homes has been started.
shepherd: Service host-name has been started.
shepherd: Service term-auto could not be started.
Um die Aktualisierung abzuschließen, können Sie für jeden Dienst, der
nicht automatisch neu gestartet werden konnte, „herd restart DIENST“
ausführen, um ihn anzuhalten, zu aktualisieren und neu zu starten.
Führen Sie „herd status“ aus, um die Dienste auf Ihrem System zu sehen.
stefan@guix ~$ sudo herd restart guix-daemon
Service guix-daemon has been stopped.
Service guix-daemon has been started.
stefan@guix ~$ guix build --system=aarch64-linux guix 
Folgende Ableitung wird erstellt:
   /gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv
/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv wird 
erstellt …
while setting up the build environment: executing 
`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
file or directory
builder for 
`/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv' failed 
with exit code 1
Erstellung von 
/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv 
fehlgeschlagen
Das Erstellungsprotokoll kann unter 
„/var/log/guix/drvs/4w/dh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv.bz2“
 eingesehen werden.
guix build: error: build of 
`/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv' failed


Bye

Stefan

bug#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

[Stefan]

Hi!

I found a workaround, starting the guix-daemon manually with PATH and 
--disable-chroot:

stefan@guix ~$ sudo herd stop guix-daemon
Service guix-daemon has been stopped.
stefan@guix ~$ sudo 
PATH=/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin 
/gnu/store/ca91bk34z3hmzv5d8j5xi0z8f4riyx7m-guix-1.2.0-8.7624ebb/bin/guix-daemon
 --build-users-group guixbuild --max-silent-time 0 --timeout 0 
--log-compression bzip2 --discover=no --substitute-urls https://ci.guix.gnu.org 
--disable-chroot &

Now ‘guix build --system=aarch64-linux guix’ is running, however, it is not 
finished yet.


Bye

Stefan

bug#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

[Stefan]

Hi Ludo’!

> Stefan: I recommend against ‘--disable-chroot’ as anything could leak
> into build processes.

Thanks for your reply. I understand that ‘--disable-chroot’ is not a good idea. 
In the end my try building guix over night fails with test errors. As I wrote 
in the bug ticket, I even did a reboot after the reconfigure. But just 
restarting qemu-binfmt and guix-daemon is no solution in my case:

stefan@guix ~$ sudo herd restart qemu-binfmt
Service qemu-binfmt has been stopped.
Service qemu-binfmt has been started.
stefan@guix ~$ sudo herd restart guix-daemon
Service guix-daemon has been stopped.
Service guix-daemon has been started.
stefan@guix ~$ guix build --system=aarch64-linux guix
Folgende Ableitung wird erstellt:
   /gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv
/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv wird 
erstellt …
while setting up the build environment: executing 
`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
file or directory
builder for 
`/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv' failed 
with exit code 1
Erstellung von 
/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv 
fehlgeschlagen
Das Erstellungsprotokoll kann unter 
„/var/log/guix/drvs/4w/dh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv.bz2“
 eingesehen werden.
guix build: error: build of 
`/gnu/store/4wdh7yy6g7imycaz9c21vcmk9l97qnpv-guix-1.2.0-8.7624ebb.drv' failed

I’ll now retry with

sudo -b env -i PATH=/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin 
/gnu/store/ca91bk34z3hmzv5d8j5xi0z8f4riyx7m-guix-1.2.0-8.7624ebb/bin/guix-daemon
 --build-users-group guixbuild --max-silent-time 0 --timeout 0 
--log-compression bzip2 --discover=no --substitute-urls https://ci.guix.gnu.org 
--disable-chroot

What else could I try otherwise?


Bye

Stefan

bug#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

[Stefan]

Hi Ludo’!

Thanks for caring!

> I don’t see why restarting the two services has no effect.  Could you
> compare the output of:
> 
>  guix gc -R $(cat /proc/sys/fs/binfmt_misc/qemu-aarch64 |grep interpreter|cut 
> -d ' ' -f 2-)

> 
> with the ‘--chroot-directory’ flags shown by:
> 
>  cat /proc/$(LC_ALL=C sudo -E herd status guix-daemon | grep Running| sed 
> -'es/.* \([0-9]\+\).*/\1/g')/cmdline | xargs -0 echo

There were no ‘--chroot-directory’ flags in my case. So I wondered what is 
wrong and re-read the manual. I figured that I managed to copy-paste the 
‘wrong’ example code from the “Transparent Emulation with QEMU” section into my 
operating-system definition, the first one. I was missing (guix-support? #t).

I know that I read the ‘guix-support’ documentation before changing my 
operating-system. I think in the end   I copied the first example, I freshly 
navigated to the “Transparent Emulation with QEMU” chapter after looking-up 
something else, maybe also because it is mentioning the aarch64, which I needed.

So now it is working. Thanks again for you support. :-)

Would you accept a patch for the manual to contain (guix-support? #t) in the 
first example as well?

Actually I would even prefer a default change of ‘guix-support’ to #t.

Would it also possible to print some proper error message, if guix build is 
used with an unsupported ‘--system’ argument.


Bye

Stefan

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi!

When building for aarch64 on a x86…64 system, then the 
‘network-interface-names’ function produces an error.

Because of this building guix for aarch64 fails during the test with this:

test-name: network-interface-names
location: 
/tmp/guix-build-guix-1.2.0-8.7624ebb.drv-0/source/tests/syscalls.scm:387
source:
+ (test-assert
+   "network-interface-names"
+   (match (remove
+(lambda (interface)
+  (string-contains interface ":"))
+(network-interface-names))
+  (((? string? names) ..1)
+   (lset<=
+ string=?
+ names
+ (all-network-interface-names)
actual-value: #f
actual-error:
+ (wrong-type-arg
+   "list-tail"
+   "Wrong type argument in position ~A (expecting ~A): ~S"
+   (1 "pair" ())
+   (()))
result: FAIL


I created a little reproducer for this problem:

stefan@guix ~$ cat test.scm 
(use-modules (guix gexp)
 (gnu packages admin))
(with-imported-modules '((guix build syscalls)
 (guix build utils))
  (computed-file "insterface-names"
#~(begin
(use-modules (guix build syscalls)
 (guix build utils)
 (ice-9 popen)
 (ice-9 rdelim))
(mkdir-p #$output)
(chdir #$output)
(with-output-to-file "interface-names"
  (lambda ()
(display (string-join (all-network-interface-names) ", "))
(newline)
(let* ((port (open-input-pipe #$(file-append inetutils 
"/bin/ifconfig"
  (display (string-join 
(let loop ((output '()))
  (let ((line (read-line port)))
(if (eof-object? line)
  (reverse output)
  (loop (cons line output)
"\n"))
  (close-pipe port))
(display (string-join (network-interface-names) ", "))
(newline))

stefan@guix ~$ guix build --system=aarch64-linux -f test.scm 
Folgende Ableitung wird erstellt:
   /gnu/store/l7sypckaywl3djrhagywwzsb2c3984wf-insterface-names.drv
/gnu/store/l7sypckaywl3djrhagywwzsb2c3984wf-insterface-names.drv wird erstellt …
Backtrace:
   7 (primitive-load "/gnu/store/a37szh4h151v66xyl874qfcbm6x?")
In ice-9/ports.scm:
   463:17  6 (call-with-output-file _ _ #:binary _ #:encoding _)
474:4  5 (_ _)
In ice-9/eval.scm:
619:8  4 (_ #(#(#)))
155:9  3 (_ #(#(#)))
159:9  2 (_ #(#(#)))
In guix/build/syscalls.scm:
  1476:13  1 (bytevector->string-list _ 40 _)
In unknown file:
   0 (list-tail (108 111 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 ?) ?)

ERROR: In procedure list-tail:
In procedure list-tail: Wrong type argument in position 1 (expecting pair): ()
builder for `/gnu/store/l7sypckaywl3djrhagywwzsb2c3984wf-insterface-names.drv' 
failed with exit code 1
Erstellung von /gnu/store/l7sypckaywl3djrhagywwzsb2c3984wf-insterface-names.drv 
fehlgeschlagen
Das Erstellungsprotokoll kann unter 
„/var/log/guix/drvs/l7/sypckaywl3djrhagywwzsb2c3984wf-insterface-names.drv.bz2“ 
eingesehen werden.
guix build: error: build of 
`/gnu/store/l7sypckaywl3djrhagywwzsb2c3984wf-insterface-names.drv' failed


When the line containing "(display (string-join (network-interface-names) ", 
"))" is removed, the output looks as follows:

stefan@guix ~$ cat 
/gnu/store/q7m7dxp4pn7jrw4f6hkwfsiga5zj43x1-insterface-names/interface-names 
lo
loLink encap:Local Loopback
  inet addr:127.0.0.1  Bcast:0.0.0.0  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0  TX bytes:0

I think the problem happens in guix/build/syscalls.scm in 
‘bytevector->string-list’, which is used by ‘network-interface-name’, certainly 
in (drop bytes stride) more bytes than available should be dropped, probably 
because stride is bigger than len:

(define (bytevector->string-list bv stride len)
  "Return the null-terminated strings found in BV every STRIDE bytes.  Read at
most LEN bytes from BV."
  (let loop ((bytes  (take (bytevector->u8-list bv)
   (min len (bytevector-length bv))))
     (result '()))
(match bytes
  (()
   (reverse result))
  (_
=> (loop (drop bytes stride)
 (cons (bytes->string bytes) result))


Bye

Stefan

bug#45654: [PATCH 1/1] gnu: qemu-binfmt-service-type: Change 'guix-support?' default to #t.

[Stefan]

* gnu/services/virtualization.scm (qemu-binfmt-service-type)[guix-support?]:
Change the default from #f to #t.
* doc/guix.texi (Transparent Emulation with QEMU): Change the default of
‘guix-support?’ from #f to #t.  Describe the implication of setting it to #f.
---
  doc/guix.texi   | 8 +++-
  gnu/services/virtualization.scm | 2 +-
  2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 884224fce6..3a22709821 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -27221,7 +27221,7 @@ This is the configuration for the @code{qemu-binfmt} 
service.
  The list of emulated QEMU platforms.  Each item must be a @dfn{platform
  object} as returned by @code{lookup-qemu-platforms} (see below).
  
-@item @code{guix-support?} (default: @code{#f})
+@item @code{guix-support?} (default: @code{#t})
  When it is true, QEMU and all its dependencies are added to the build
  environment of @command{guix-daemon} (@pxref{Invoking guix-daemon,
  @option{--chroot-directory} option}).  This allows the @code{binfmt_misc}
@@ -27250,6 +27250,12 @@ build}, transparently using QEMU to emulate the ARMv7 
CPU.  Pretty handy
  if you'd like to test a package build for an architecture you don't have
  access to!
  
+When @code{guix-support?} is set to @code{#f}, then of course programs for
+other architectures can still be executed transparently, but invoking commands
+like @command{guix build -s armhf-linux inksake} will fail with an unobvious
+error that @command{guile} cannot be executed.  However, the build environment
+of @command{guix-daemon} then needs less store items.
+
  @item @code{qemu} (default: @code{qemu})
  The QEMU package to use.
  @end table
diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index f435630faf..2f5a258bfe 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -717,7 +717,7 @@ potential infinite waits blocking libvirt."))
(platforms   qemu-binfmt-configuration-platforms
 (default '())) ;safest default
(guix-support? qemu-binfmt-configuration-guix-support?
- (default #f)))
+ (default #t)))
  
  (define (qemu-platform->binfmt qemu platform)
"Return a gexp that evaluates to a binfmt string for PLATFORM, using the
-- 
2.29.2

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi!

This change makes the reproducer working and prints some more values:

diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 85c1c45f81..250c577d33 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -1473,7 +1473,19 @@ most LEN bytes from BV."
(()
 (reverse result))
(_
-   (loop (drop bytes stride)
+   (display "bytes: ")
+   (display (length bytes))
+   (newline)
+   (display "stride: ")
+   (display stride)
+   (newline)
+   (display "ifreq-struct-size: ")
+   (display ifreq-struct-size)
+   (newline)
+   (display "sizeof '*: ")
+   (display (sizeof '*))
+   (newline)
+   (loop (drop bytes (min stride (length bytes)))
  (cons (bytes->string bytes) result))
 
  (define* (network-interface-names #:optional sock)


So indeed, the number of bytes is only 32, if build with ‘./pre-inst-env guix 
build --system=aarch64-linux -f ~/test.scm’:

bytes: 32
stride: 40
sizeof '*: 8

If this is instead build with just ‘./pre-inst-env guix build -f ~/test.scm’, 
the output is as expected:

bytes: 40
stride: 40
sizeof '*: 8
 
I have however no clue, why the number of bytes is only 32 in case of aarch64. 
This value is taken from the struct ifconf read via ioctl(SIOCGIFCONF).

Danny, does that maybe ring a bell?

To be precise this is all running in a virtual machine with virtio-net-pci. 
Both kernel and qemu on the host are rather old. However, building for x86_64 
works just fine, so I think the host setup is unrelated.


Bye

Stefan

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi Danny and Ludo’!

> Can you try printing (@@ (guix build syscalls) ifreq-struct-size) directly?

I did that, it's printing 40 in both cases. That’s the value which is ending up 
in stride.

> Is it qemu-user or qemu-system?

~$ /usr/local/bin/qemu-system-x86_64 --version
QEMU emulator version 2.12.1 (-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

> (Note: Empirically, on armhf, that struct is 32 Bytes big in C.
> And indeed the Linux kernel contains a compat struct ifreq32 in 
> fs/compat_ioctl.c)



Bye

Stefan

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi!

> I think that should rather be (sizeof* '*) instead of (sizeof '*).  Ludo?

For aarch64 I tried using ‘sizeof*’ instead of ‘sizeof’ in ‘ifreq-struct-size’, 
but this makes no different at all. Well, pointers have to be 8 bytes long on 
x86_64 and aarch64, so this was expected. However, it should make a difference 
for armhf, but I didn't try that.


Bye

Stefan

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi!

I think I found the root cause of this issue in qemu. I'm about to prepare a 
patch.


Bye

Stefan

bug#45716: gnu: qemu: Fix ioclt(…, SIOCGIFCONF, …) for emulated 64 bit architectures.

[Stefan]

* gnu/packages/virtualization.scm (qemu): Add a snippet to fix a bug in the
do_ioctl_ifconf() function of qemu to make ioclt(…, SIOCGIFCONF, …) work for
emulated 64 bit architectures.

The sizeof(struct ifreq) is 40 for 64 bit and 32 for 32 bit architectures.
This structure contains a union of other structures, of which struct ifmap
is the biggest for 64 bit architectures. Calling ioclt(…, SIOCGIFCONF, …)
fills a struct sockaddr of that union, and do_ioctl_ifconf() only considered
that struct sockaddr for the size of the union, which has the same size as
struct ifmap on 32 bit architectures. So do_ioctl_ifconf() assumed a wrong
size of 32 for struct ifreq instead of the correct size of 40 on 64 bit
architectures.

The fix makes do_ioctl_ifconf() handle struct ifmap as the biggest part of
the union, treating struct ifreq with the correct size.

This fixes (@ (guix build syscalls) network-interface-names) when used in
emulated 64 bit architectures.
---
 gnu/packages/virtualization.scm | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 10eae8ea7d..f82a19ecf3 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -140,7 +140,17 @@
(sha256
 (base32
  "1rd41wwlvp0vpialjp2czs6i3lsc338xc72l3zkbb7ixjfslw5y9"))
-  (patches (search-patches "qemu-build-info-manual.patch"
+  (patches (search-patches "qemu-build-info-manual.patch"))
+  (modules '((guix build utils)))
+  (snippet
+   '(begin
+  (substitute* '("linux-user/syscall.c")
+(("^([[:blank:]]*)const argtype ifreq_arg_type.*$" line 
indent)
+ (string-append line indent
+"const argtype ifreq_max_type[] = { 
MK_STRUCT(STRUCT_ifmap_ifreq) };\n"))
+(("^([[:blank:]]*)target_ifreq_size[[:blank:]]=.*$" _ 
indent)
+ (string-append indent "target_ifreq_size = 
thunk_type_size(ifreq_max_type, 0);")))
+  #t
  (outputs '("out" "doc"));4.7 MiB of HTML docs
  (build-system gnu-build-system)
  (arguments
-- 
2.29.2

bug#45716: [PATCH 1/1] gnu: qemu: Fix ioclt(…, SIOCGIFCONF, …) for emulated 64 bit architectures.

[Stefan]

* gnu/packages/virtualization.scm (qemu): Add a snippet to fix a bug in the
do_ioctl_ifconf() function of qemu to make ioclt(…, SIOCGIFCONF, …) work for
emulated 64 bit architectures.

The sizeof(struct ifreq) is 40 for 64 bit and 32 for 32 bit architectures.
This structure contains a union of other structures, of which struct ifmap
is the biggest for 64 bit architectures. Calling ioclt(…, SIOCGIFCONF, …)
fills a struct sockaddr of that union, and do_ioctl_ifconf() only considered
that struct sockaddr for the size of the union, which has the same size as
struct ifmap on 32 bit architectures. So do_ioctl_ifconf() assumed a wrong
size of 32 for struct ifreq instead of the correct size of 40 on 64 bit
architectures.

The fix makes do_ioctl_ifconf() handle struct ifmap as the biggest part of
the union, treating struct ifreq with the correct size.

This fixes (@ (guix build syscalls) network-interface-names) when used in
emulated 64 bit architectures.
---
  gnu/packages/virtualization.scm | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 10eae8ea7d..e773fe357d 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -140,7 +140,22 @@
(sha256
 (base32
  "1rd41wwlvp0vpialjp2czs6i3lsc338xc72l3zkbb7ixjfslw5y9"))
-  (patches (search-patches "qemu-build-info-manual.patch"
+  (patches (search-patches "qemu-build-info-manual.patch"))
+  (modules '((guix build utils)))
+  (snippet
+   '(begin
+  ;; Fix a bug in the do_ioctl_ifconf() function of qemu to
+  ;; make ioclt(…, SIOCGIFCONF, …) work for emulated 64 bit
+  ;; architectures.  The size of struct ifreq is handled
+  ;; incorrectly.
+  ;; 
https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01545.html
+  (substitute* '("linux-user/syscall.c")
+(("^([[:blank:]]*)const argtype ifreq_arg_type.*$" line 
indent)
+ (string-append line indent
+"const argtype ifreq_max_type[] = { 
MK_STRUCT(STRUCT_ifmap_ifreq) };\n"))
+(("^([[:blank:]]*)target_ifreq_size[[:blank:]]=.*$" _ 
indent)
+ (string-append indent "target_ifreq_size = 
thunk_type_size(ifreq_max_type, 0);")))
+  #t
  (outputs '("out" "doc"));4.7 MiB of HTML docs
  (build-system gnu-build-system)
  (arguments
-- 
2.29.2

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi Ludo’!

> Applied, thanks!

Thanks.

Unfortunately the bug still appears on ci.guix.gnu.org, for example see 
<https://ci.guix.gnu.org/build/204877/details>.

I think that the build machines need to be reconfigured to get the fixed qemu 
version.


Bye

Stefan

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi Mathieu!

This is still failing, see <https://ci.guix.gnu.org/build/233248/details>.

> Yes, I reconfigured them yesterday


Could it be that the services qemu-binfmt and guix-daemon still need to be 
restarted?


Bye

Stefan

bug#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

[Stefan]

Hi Mathieu!

> Just restarted those services, let's see what happens!


Thanks! Now it is working: <https://ci.guix.gnu.org/build/283711/details>

I just can’t tell if it got build on a x86_64 or an aarch64 machine. But the 
result matters. :-)


Bye

Stefan

bug#45196: guile-studio cannot open file

[Stefan]

Hi!

It is possible to work around this error 
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45196> by installing emacs as 
well.

Another workaround is to start guile-studio with EMACSLOADPATH preset to:

EMACSLOADPATH=/gnu/store/…-emacs-27.1/share/emacs/27.1/site-lisp guile-studio

It seems to me that this /gnu/store/…-emacs-27.1/share/emacs/27.1/site-lisp 
path is missing in the guile-studio shell script, which only uses tis path from 
the emacs package: /gnu/store/…-emacs-27.1/share/emacs/site-lisp.


Bye

Stefan

bug#47744: nfs-root-fs test is failing

[Stefan]

Hi Mathieu!

> I'm working on fixing all the system tests before the release. The
> "nfs-root-fs" test is failing this way:

> Danny, Stefan, do you think you could have a look?

I remember that I did the sketch for this test, mainly copying from the other 
nfs tests. But in the end my Raspberry was too weak for testing or even 
compiling everything necessary. A bit later Danny improved the test and I got 
the impression that it was running.

I’ll try to take a look tomorrow, let’s see.


Bye

Stefan

bug#47744: nfs-root-fs test is failing

[Stefan]

Hi Mathieu and Danny!

I’m now sure that this test has never been working.

To get it working, first of all we need a change in (gnu system vm) to not 
discard a root file-system of type “nfs”. I did this change. I also cleaned up 
the test itself. See the attached patch.

The test needs two virtual machines communicating over TCP. The NFS client 
machine needs the linux command line argument “ip=dhcp“ (or a static IP 
setting) or some other code inside the initrd to bring the network interface up 
and running before mounting its root file-system over NFS. And finally some 
QEMU networking needs to be setup to have the NFS server and client talk to 
each other with proper IP addresses.

Unfortunately I have no clue how to achieve these two prerequisites. The kernel 
argument “ip=dhcp” does not help, as the driver for the network interface is 
not part of the linux-libre kernel. And also adding the initrd-module e1000 
comes too late. On my Raspberry Pi I’m using a modified kernel with a build-in 
network driver and the “ip=dhcp” argument.

It seems to me that the base-initrd is missing an argument to add some 
arbitrary expression, or an option to configure the network interface, or the 
shepherd service which is provisioning 'networking. For network booting the 
initrd in Guix currently seems to be useless – however, getting rid of it is 
not trivial either.

With the attached changes, the NFS server side tests are passing, but the NFS 
client is missing an own IP address when trying to mount its root file-system, 
which results in this error when executing “make check-system TESTS=nfs-root”:

Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.

loading kernel modules...
[   27.250034] e1000: Intel(R) PRO/1000 Network Driver
[   27.250975] e1000: Copyright (c) 1999-2006 Intel Corporation.
[   28.026651] PCI Interrupt Link [LNKC] enabled at IRQ 11
[   28.31] e1000 :00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56
[   28.388012] e1000 :00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[   28.706203] usbcore: registered new interface driver usb-storage
[   28.839354] usbcore: registered new interface driver uas
[   28.922481] hid: raw HID events driver (C) Jiri Kosina
[   28.942031] usbcore: registered new interface driver usbhid
[   28.943247] usbhid: USB HID core driver
[   29.425330] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[   30.100062] PCI Interrupt Link [LNKD] enabled at IRQ 10
[   30.724003] PCI Interrupt Link [LNKA] enabled at IRQ 10
[   31.335165] PCI Interrupt Link [LNKB] enabled at IRQ 11
[   32.129714] virtio_blk virtio3: [vda] 143360 512-byte logical blocks (73.4 
MB/70.0 MiB)
[   32.167257]  vda: vda1 vda2
[   32.526742] random: crng init done
[   32.624351] FS-Cache: Loaded
[   32.675399] 9pnet: Installing 9P2000 support
[   32.692551] 9p: Installing v9fs 9p2000 file system support
[   32.695268] FS-Cache: Netfs '9p' registered for caching
configuring QEMU networking...
[   32.842717] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 
RX
[   32.859236] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
In gnu/build/linux-boot.scm:
   599:12  3 (_)
423:8  2 (mount-root-file-system ":/export" "nfs" # _ #:flags _ # ?)
In unknown file:
   1 (mount ":/export" "/real-root" "nfs" 1 "addr=127.0.0.1")
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)
In procedure mount: No such device
[   33.616971] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x


Bye

Stefan




0001-NFS-root-for-virtual-machines.patch
Description: Binary data

bug#47956: nfs-root-fs test is failing

[Stefan]

Hi Mathieu!

> I think I'll remove the "nfs-root-fs" test for now.

> Any objections?

I’d like to ask you to apply my patch. It paves the way for using nfs-shares 
inside virtual machines, which is not possible today. This is certainly a good 
impovement. 

The patch also fixes the nfs-root test. It would certainly work, if networking 
in qemu during the bootup works and if the two virtual machines are able to 
communicate via IP to each other.

It woud be sufficient to comment out the nfs-root test or even only the client 
part of it. But please don’t throw it away!

If either the kernel or the initrd will be changed to support networking in 
qemu, then this test needs possibly only small adjustments to start working. 
For the networking part at bootup it is enough to add CONFIG_E1000 when 
building linux-libre. Is that an acceptable change? If so then I could give it 
another try.


Bye

Stefan

bug#47956: nfs-root-fs test is failing

[Stefan]

Hi Mathieu and Danny!

I got the nfs-root test working now with the attached patch.

It makes use of the (modify-linux) function from my other patch series¹, as the 
current kernel for x86 is not capable to use an NFS root file system.



Bye

Stefan


¹ <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48314>



nfs-root-for-virtual-machines.patch
Description: Binary data

bug#47744: nfs-root-fs test is failing

[Stefan]

Hi!

A solution for the failing nfs-root test is part of 
<http://issues.guix.gnu.org/48314>.

I think this ticket can be closed.


Bye

Stefan

bug#50592: Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader

[Stefan]

Hi!

The solution for this is already available in the patch series in 
<http://issues.guix.gnu.org/48314>. The new 
grub-efi-netboot-removable-bootloader can be used for this.

Technically there is no big difference between an installation to boot from 
network or from local storage. For booting from network two symlinks are 
needed, which can’t be created on an EFI System Partition with its FAT file 
system. In the later case a small intermediate grub.cfg is created, which 
allows booting from local storage.


Bye

Stefan

bug#47744: nfs-root-fs test is failing

[Stefan]

Hi!

Sorry, that was not quite correct. I sent a patch months back, which did not 
make it into this ticket, which solved this ticket but depends on 
<http://issues.guix.gnu.org/48314>.

Here it is again.


Bye

Stefan


nfs-root-for-virtual-machines.patch
Description: Binary data

bug#40848: doc: chapter "Building from Git" in "Contributing" misses to list required packages

[Stefan]

Hi!

The chapter "Building form Git" starts with two git commands to clone and 
verify the code. Unfortunately it misses to mention before that two packages 
are required for this to be working: git and gnupg.

While the former is obvious, the gnupg package is not that obvious. If you 
missed to install it, then the "git verify-commit" prints some error messages 
with "error: cannot run gpg". And unfortunately gpg is not the package name to 
install to solve this error.

It would be beneficial, if the two required packages git (or git-minimal?) and 
gnupg would be mentioned before starting with commands which would fail 
otherwise.

It would further help to repeat the wget command from the installation section 
to fetch the keys necessary for this verification, as there are other numbers 
printed beside the mentioned 3CE4645…

However that wget command requires yet another package to be installed: wget.

Finally trying to verify commit f84b0363053e5479464f6ce6ded45f80360d90fc it 
leaves this unresolved key: 

gpg: Signatur vom Sa 28 Mär 2020 21:30:07 CET
gpg:mittels RSA-Schlüssel 
39B33C8D94480D2DDCC2A4988B44A0CDC7B956F2
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

The next command mentioned then is "make authenticate". It fails because the 
make package first needs to be installed. But even if this is done, it fails 
with "make: *** Keine Regel, um „authenticate“ zu erstellen.  Schluss." There 
has yet no Makefile been created.

Further down the commands "./bootstrap" and ".configure" are mentioned, which 
are both required to create the needed Makefile. But to be able to run this, 
all the listed dependencies need to be installed. 

Only after struggling down to the failing "make authenticate" there is the 
finally helpful command "guix environment guix —pure".

So to sum it all up: the packages to install and missed to mention are

 • git (or git-minimal?)
 • gnupg
 • wget 

The wget command to download the key should ideally be repeated. The "make 
authenticate" command is not helpful at all to be mentioned that early.

It would instead be very helpful, if first "guix environment guix —pure" would 
be mentioned, and if this (or a similar command) would also provide git, gnupg 
and wget to be able to fetch and verify the source code of guix as described by 
the first two commands "git clone …" and "git verify-commit …".

The "make authenticate" command must not be mentioned before but only after the 
"./bootstrap" and "./configure" commands.  Both "./bootstrap" and "./configure" 
should ideally be boxed like the other commands. This boxing would also help 
the important argument "--localstatedir=/var" to not be overseen.

In my case after all this and running ".configure" successfully, "make 
authenticate" still failed, because I relied on "guix environment guix —pure" 
to have a dependency to gnupg to have the gpg command accessible, which is 
unfortunately not the case.

I then exited the environment and started a new one with "guix environment guix 
--pure --ad-hoc gnupg" and ran "make authenticate" now with this result:

stefan@guix ~/development/guix [env]$ make authenticate
Authenticating Git checkout...
Authenticating d68de95 to f84b036 (14629 commits)...
[###   
]Backtrace:
  12 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 11 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 10 (_ #(#(#)))
   293:34  9 (_ #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
142:2  8 (dynamic-wind _ _ #)
152:2  7 (with-fluid* _ _ _)
In srfi/srfi-1.scm:
   466:18  6 (fold # ?)
In ice-9/eval.scm:
   293:34  5 (_ #(#(# # ?) ?))
619:8  4 (_ #(#(#(#) # ?) ?))
   626:19  3 (_ #(#(#(#) # ?) ?))
In ice-9/boot-9.scm:
152:2  2 (with-fluid* _ _ _)
142:2  1 (dynamic-wind # ?)
142:2  0 (dynamic-wind # ?)

ice-9/boot-9.scm:142:2: In procedure dynamic-wind:
Throw to key `srfi-34' with args `(#)'.
make: *** [Makefile:5895: authenticate] Error 1

The documentation then finally suggest to run "make check". Isn't the actual 
build step with "make" missing?


I'm currently using 

guix describe
Generation 528. März 2020 18:44:49  (aktuell)
  guix e425713
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: e4257138fe1d924c56c9979b75319585b9251fb7

My profile is empty, no installed packages – I removed all packages again after 
obtaining the source code and before running "guix environment guix --pure 
--ad-hoc gnupg".


Bye

Stefan

bug#40872: First installed package on guix system is not instantly usable

[Stefan]

Hi!

I have a guix system and my user account has no package installed yet. After 
installing the first package – git-minimal in my case – this message is printed 
and I get this error when trying to use the new command:

building profile with 1 package...
Hinweis: Vielleicht möchten Sie die nötigen Umgebungsvariablen festlegen, indem 
Sie dies ausführen:

 GUIX_PROFILE="/home/stefan/.guix-profile"
 . "$GUIX_PROFILE/etc/profile"

Sie können sie auch mit `guix package --search-paths -p 
"/home/stefan/.guix-profile"' nachlesen.

stefan@guix ~$ git show
-bash: git: Kommando nicht gefunden.


The problem is that without a single package installed there is no user 
profile-link present:


stefan@guix ~$ echo $PATH
/run/setuid-programs:/home/stefan/.config/guix/current/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin


This is of course easily solved by either following the hint or a logout and 
login:


stefan@guix ~$ exit
Abgemeldet
Connection to raspberry closed.
Computer:~ stefan$ ssh stefan@raspberry
Last login: Sun Apr 26 13:59:31 2020 
stefan@guix ~$ echo $PATH
/run/setuid-programs:/home/stefan/.config/guix/current/bin:/home/stefan/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin


However, this gives a bad first impression to users. Moreover users may think 
that a logout/login cycle or manually following the hint could be necessary 
after each package installation. They may get annoyed by this.


Bye

Stefan

bug#40872: First installed package on guix system is not instantly usable

[Stefan]

Hi Marius!

> This is odd, as /etc/profile contains a workaround for this exact
> problem (notice the else clause):
> 
> # Arrange so that ~/.config/guix/current comes first.
> for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
> do
>  if [ -f "$profile/etc/profile" ]
>  then
># Load the user profile's settings.
>GUIX_PROFILE="$profile" ; \
>. "$profile/etc/profile"
>  else
># At least define this one so that basic things just work
># when the user installs their first package.
>export PATH="$profile/bin:$PATH"
>  fi
> done
> 
> Can you investigate why this is ineffective on your system?

Previously I had some packages installed, but I rolled-back to generation 0. I 
found this in my scroll-back buffer:

stefan@guix ~/development/guix$ guix package --roll-back
Folgende Ableitung wird erstellt:
   /gnu/store/l0n6l104ldj7nz6kdyi7l8v5yjnc9p9g-profile.drv
building profile with 0 packages...
Von Generation „1“ zu „0“ gewechselt

By rolling back it created a new generation 0 profile which is now lying around 
with this kind of empty file: 

stefan@guix ~$ cat .guix-profile/etc/profile 
# Source this file to define all the relevant environment variables in Bash
# for this profile.  You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
#  GUIX_PROFILE=/path/to/profile ; \
#  source /path/to/profile/etc/profile
#
# When GUIX_PROFILE is undefined, the various environment variables refer
# to this specific profile generation.

So the test for the existence of this file does not fail, but it doesn't change 
PATH either. This is the profile content, it has no bin/ folder to add to PATH:

stefan@guix ~$ ls -lA /gnu/store/yyxqc1rhz2i062xq8lbfrhhmiyf6pzvp-profile
insgesamt 12
dr-xr-xr-x 2 root root 4096  1. Jan 1970  etc/
-r--r--r-- 4 root root   37  1. Jan 1970  manifest


Bye

Stefan

bug#40872: Subject: [PATCH] gnu: system: Fix PATH export if the profile has no bin directory.

[Stefan]

* gnu/system.scm (operating-system-etc-service): Testing for $profile/bin.

Fixes .
---
 gnu/system.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 540f0e4a9e..0eb5731c82 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -725,7 +725,8 @@ do
 # Load the user profile's settings.
 GUIX_PROFILE=\"$profile\" ; \\
 . \"$profile/etc/profile\"
-  else
+  fi
+  if [ ! -d \"$profile/bin\" ]
 # At least define this one so that basic things just work
 # when the user installs their first package.
 export PATH=\"$profile/bin:$PATH\"
-- 
2.26.0

bug#40872: First installed package on guix system is not instantly usable

[Stefan]

Hi Marius!

> Am 02.05.2020 um 16:20 schrieb Marius Bakke :
> 
> We could extend the test in /etc/profile to look for a /bin
> directory of the profile

I think this is the right solution, as that’s the actual aim of the else-part: 
Provide a path to a bin directory if the profile doesn’t do this by itself – 
there is just the implicit (but wrong) assumption that it would, if the profile 
is existing. I sent a patch, probably you saw it already.


Bye

Stefan

bug#40872: [PATCH] gnu: system: Fix PATH export if the profile has no bin directory.

[Stefan]

Hi!

> Am 02.05.2020 um 18:59 schrieb Stefan :
> 
> * gnu/system.scm (operating-system-etc-service): Testing for $profile/bin.
> 
> Fixes <https://debbugs.gnu.org/40872>.
> ---
> gnu/system.scm | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/system.scm b/gnu/system.scm
> index 540f0e4a9e..0eb5731c82 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -725,7 +725,8 @@ do
> # Load the user profile's settings.
> GUIX_PROFILE=\"$profile\" ; \\
> . \"$profile/etc/profile\"
> -  else
> +  fi
> +  if [ ! -d \"$profile/bin\" ]

I just realised that I missed the necessary 

then

between these lines. 

> # At least define this one so that basic things just work
> # when the user installs their first package.
> export PATH=\"$profile/bin:$PATH\"
> -- 
> 2.26.0
> 


Bye

Stefan

bug#41484: guix gc fails catastrophically if the disk has no space left

[Stefan]

Hi!

While trying to build guix, my disk ran out of space.

building /gnu/store/w5l7acwbfvn0n8zj2v9by4j3jwbiimj9-guix-1.1.0-4.bdc801e.drv...
100% 
[#]note:
 build failure may have been caused by lack of free disk space
builder for 
`/gnu/store/w5l7acwbfvn0n8zj2v9by4j3jwbiimj9-guix-1.1.0-4.bdc801e.drv' failed 
with exit code 1
build of /gnu/store/w5l7acwbfvn0n8zj2v9by4j3jwbiimj9-guix-1.1.0-4.bdc801e.drv 
failed
View build log at 
'/var/log/guix/drvs/w5/l7acwbfvn0n8zj2v9by4j3jwbiimj9-guix-1.1.0-4.bdc801e.drv.bz2'.
guix system: error: build of 
`/gnu/store/w5l7acwbfvn0n8zj2v9by4j3jwbiimj9-guix-1.1.0-4.bdc801e.drv' failed

stefan@guix ~$ df -h /
Dateisystem   Größe Benutzt Verf. Verw% 
Eingehängt auf
:/volume5/RaspberryPi/Betriebssysteme/guix-system  1,4T1,4T 0  100% /

OK, well, there’s certainly a lot of garbage to collect. Due to bad experiences 
in the past with the same situation, I first try to collect only a little 
garbage.

stefan@guix ~$ guix gc -F 100M
guix gc: 100 MiB werden freigegeben
finding garbage collector roots...
note: can't create trash directory: creating directory `/gnu/store/trash': No 
space left on device
deleting garbage...
[0%] deleting '/gnu/store/g30aknl5yxk9jbpx2w7r5d0ak6xa5dl2-grub.cfg.lock'
[0%] deleting 
'/gnu/store/gidc7jrgbnvfm38qx4sc012kn9llgsvz-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04-collection.lock'
[0%] deleting '/gnu/store/9cpj3ir8fnsg5fiqs3x8alai713xzfz0-grub-keymap.de.lock'
[0%] deleting 
'/gnu/store/z08s3kwlnpqq6aa1v6ydni5qp2k7gkkb-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04'
[0%] deleting 
'/gnu/store/wv7iwd66q6n5775qa4hgaq9j9f2vyvl4-guix-1.1.0-4.bdc801e.lock'
[0%] deleting 
'/gnu/store/pab2ylsvas12824qw6j8q2h1qm3gh4x6-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04-union.lock'
[0%] deleting 
'/gnu/store/3ldyga22s6ym9g2pc9ycjwdwqb4i41v2-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04.lock'
[0%] deleting 
'/gnu/store/nfxgqhjyzwngiadn0l180hsbfnw3h4zy-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04-collection.lock'
[0%] deleting 
'/gnu/store/pab2ylsvas12824qw6j8q2h1qm3gh4x6-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04-union'
[0%] deleting '/gnu/store/dahbiixsbi1xhjiim9phl1vginm83bbm-grub.cfg.lock'
[0%] deleting 
'/gnu/store/61mwka1h77kkhylcs9jj4ij167qgfj39-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04.lock'
[0%] deleting '/gnu/store/q829h36vnwhbdlnzkgdrx2b51kp2mvdv-grub.cfg.lock'
[0%] deleting '/gnu/store/ragpi42x39sf5qwcmcmdn751fp4jfhmv-grub.cfg.lock'
[0%] deleting '/gnu/store/ncdsjfl245k6r7zym6w4sr9fyxrwhb38-grub.cfg.lock'
[0%] deleting 
'/gnu/store/z08s3kwlnpqq6aa1v6ydni5qp2k7gkkb-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04.lock'
[0%] deleting 
'/gnu/store/gidc7jrgbnvfm38qx4sc012kn9llgsvz-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04-collection'
[0%] deleting 
'/gnu/store/61mwka1h77kkhylcs9jj4ij167qgfj39-package-collection-grub-efi-raspberrypi-firmware-u-boot-rpi-3-2.04'
[0%] deleting '/gnu/store/hmy4ni005digrilzjf93wr9gaj5cq536-computed-files.lock'
[0%] deleting '/gnu/store/hmy4ni005digrilzjf93wr9gaj5cq536-computed-files'
error (ignored): aborting transaction: cannot rollback - no transaction is 
active
guix gc: error: committing transaction: disk I/O error
stefan@guix ~$ 

And that’s it. Repeating the guix gc command now results in this immediate 
error:

stefan@guix ~$ guix gc -F 100M
warning: SQLite database is busy (SQLITE_PROTOCOL)
guix gc: error: setting synchronous mode: locking protocol
stefan@guix ~$ guix gc -F 100M
warning: SQLite database is busy (SQLITE_PROTOCOL)
guix gc: error: setting synchronous mode: locking protocol

A reboot is needed to solve this SQLite error. But retrying all this leads to 
the same situation again and again. It is kind of a deadlock.

Well, as my guix system boots from an NFS share, in the past I solved this by 
removing other stuff – not related to guix – from the same disk. But right now 
there isn't unrelated stuff left to be deleted. 

I intend to remove the listed /gnu/store/… files by hand from the NFS server 
side (which is much easier than removing the read-only bind-mount.) Is this 
save at least?

This is all on a Raspberry Pi 3b aarch64 machine, if it matters.


Bye

Stefan

bug#41484: guix gc fails catastrophically if the disk has no space left

[Stefan]

Hi!

After this trouble with guix gc I did a sudo reboot, and it got worse. At 
startup I now see these errors:

GC Warning: pthread_getattr_up or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use --repl for an initrd REPL.

loading kernel modules…
loading '/gnu/store/…-system/boot'...
making '/gnu/store/…-system' the current system...
setting up setuid programs in '/run/setuid-programs'...
warning: failed to make '/gnu/store/…-shadow-4.8.1/bin/newuidmap' setuid-root: 
No space left on device
warning: failed to make '/gnu/store/…' setuid-root: No space left on device
…
populating /etc from /gnu/store/…-etc...
ERROR: In procedure fsync:
In procedure fsync: No space left on device

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
GNU Guile 2.2.6
Copyright …
…

Enter `help' for help.
scheme@(guile-user)> ,bt
In gnu/build/linux-boot.scm:
   561:14 10 (_)
In unknown file:
   9 (primitive-load "/gnu/store/…")
In ice-9/eval.scm:
   619:8 (_ #f)
In unknown file:
   7 (primitive-load "/gnu/store/…")
In ice-9/boot-9.scm:
   260:13  6 (for-each # _)
In unknown file:
   5 (primitive-load "/gnu/store/_")
In gnu/build/activation.scm:
136:2  4 (activate-users+groups _ _)
In guix/build/syscalls.scm:
   1089:4  3 (call-with-file-lock _ _)
In gnu/build/activation.scm:
139:6  2 (_)
In gnu/build/accounts.scm:
   253:14  1 (_ (#< name: "root" password: #f gid: …> …) …)
In unknown file:
   0 (fsync #)
scheme@(guile-user)>


Now this is the very end. Even selecting an older system generation is 
obviously not an option any more. 

I’m happy that all this is on my NFS share to which I have access via my server.


Bye

Stefan

bug#41654: Test of guix-1.1.0-4.bdc801e is failing on aarch64

[Stefan]

Hi!

Building guix-1.1.0-4.bdc801e is failing on aarch64 since about two weeks on 
ci.guix.gnu.org. 

http://ci.guix.gnu.org/search?query=guix-1.1.0-4.bdc801e+system%3Aaarch64-linux

There is always the same failure during the test. See for example the raw log 
from http://ci.guix.gnu.org/build/2794788/details:

test-name: network-interface-names
…
actual-error:
+ (wrong-type-arg
+   "list-tail"
+   "Wrong type argument in position ~A (expecting ~A): ~S"
+   (1 "pair" ())
+   (()))
result: FAIL


When building locally this particular test is passing (after about three days 
on an SBC with 1 GB RAM). 

But unfortunately building locally I get two different failures instead:

FAIL: tests/store.scm
FAIL: tests/guix-package.sh

Here are some more details:


test-name: verify-store + check-contents
location: /tmp/guix-build-guix-1.1.0-4.bdc801e.drv-0/source/tests/store.scm:972
…
actual-error:
+ (%exception
+   #<&store-protocol-error message: "path 
`dtmp/guix-tests/store/bpl866rgsjyzdczlngfw8ss2lkld6bim-mirrors' is not in the 
store" status: 1>)
result: FAIL

Note the “dtmp/” instead of “/tmp/”. I saw the same error some weeks ago 
already, but shortly after that was happening, there was a substitute 
available. But it seems this error is reproducible in my case.


guix install: error: profile t-guix-package-541/profile is locked by another 
process
+ true
+ kill 1387
+ rm -f t-profile-541 t-profile-541.lock t-profile-541-1-link 
t-guix-package-file-541
+ rm -rf t-guix-package-541 t-home-541
rm: cannot remove 't-guix-package-541': Directory not empty
FAIL tests/guix-package.sh (exit status: 1)


This may be due to a deleted but still opened file on an NFS share. There may 
be an intermediate hidden .nfs… file, which may get created in such a case 
(“delete on last close”, “silly rename”), However, the RFC-5661 for NFS demands 
even if OPEN4_RESULT_PRESERVE_UNLINKED is supported, that the directory entry 
of an open file must not be removed in this case, thus preventing a directory 
removal.



54pswxwm35kq47zk2dswvsq3nm55kb-guix-1.1.0-4.bdc801e.drv.bz2
Description: application/applefile

bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.

[Stefan]

* gnu/bootloaders/grub.scm (eye-candy): Use gfxterm depending only on
(bootloader-configuration (terminal-outputs …)), which defaults to '(gfxterm).
This makes the system argument obsolete.
---
 gnu/bootloader/grub.scm | 46 -
 1 file changed, 13 insertions(+), 33 deletions(-)

diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 2d9a39afc3..544847b9cd 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -135,41 +135,25 @@ file with the resolution provided in CONFIG."
(_ #f)
 
 (define* (eye-candy config store-device store-mount-point
-#:key store-directory-prefix system port)
+#:key store-directory-prefix port)
   "Return a gexp that writes to PORT (a port-valued gexp) the 'grub.cfg' part
 concerned with graphics mode, background images, colors, and all that.
 STORE-DEVICE designates the device holding the store, and STORE-MOUNT-POINT is
 its mount point; these are used to determine where the background image and
-fonts must be searched for.  SYSTEM must be the target system string---e.g.,
-\"x86_64-linux\".  STORE-DIRECTORY-PREFIX is a directory prefix to prepend to
-any store file name."
-  (define setup-gfxterm-body
-(let ((gfxmode
-   (or (and-let* ((theme (bootloader-configuration-theme config))
-  (gfxmode (grub-theme-gfxmode theme)))
- (string-join gfxmode ";"))
-   "auto")))
-
-  ;; Intel and EFI systems need to be switched into graphics mode, whereas
-  ;; most other modern architectures have no other mode and therefore
-  ;; don't need to be switched.
-
-  ;; XXX: Do we really need to restrict to x86 systems?  We could imitate
-  ;; what the GRUB default configuration does and decide based on whether
-  ;; a user provided 'gfxterm' in the terminal-outputs field of their
-  ;; bootloader-configuration record.
-  (if (string-match "^(x86_64|i[3-6]86)-" system)
-  (format #f "
-  set gfxmode=~a
-  insmod all_video
-  insmod gfxterm~%" gfxmode)
-  "")))
-
+fonts must be searched for.  STORE-DIRECTORY-PREFIX is a directory prefix to
+prepend to any store file name."
   (define (setup-gfxterm config font-file)
 (if (memq 'gfxterm (bootloader-configuration-terminal-outputs config))
-#~(format #f "if loadfont ~a; then
-  setup_gfxterm
-fi~%" #+font-file)
+#~(format #f "
+if loadfont ~a; then
+  set gfxmode=~a
+  insmod all_video
+  insmod gfxterm
+fi~%"
+  #$font-file
+  #$(string-join
+  (grub-theme-gfxmode (bootloader-theme config))
+  ";"))
 ""))
 
   (define (theme-colors type)
@@ -190,8 +174,6 @@ fi~%" #+font-file)
 
   (and image
#~(format #$port "
-function setup_gfxterm {~a}
-
 # Set 'root' to the partition that contains /gnu/store.
 ~a
 
@@ -206,7 +188,6 @@ else
   set menu_color_normal=cyan/blue
   set menu_color_highlight=white/blue
 fi~%"
- #$setup-gfxterm-body
  #$(grub-root-search store-device font-file)
  #$(setup-gfxterm config font-file)
  #$(grub-setup-io config)
@@ -358,7 +339,6 @@ when booting a root file system on a Btrfs subvolume."
(menu-entry-device (first all-entries))
(menu-entry-device-mount-point (first all-entries))
#:store-directory-prefix store-directory-prefix
-   #:system system
#:port #~port))
 
   (define keyboard-layout-config
-- 
2.26.0

bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.

[Stefan]

* gnu/bootloaders/grub.scm (eye-candy): Use gfxterm depending only on
(bootloader-configuration (terminal-outputs …)), which defaults to '(gfxterm).
This makes the system argument obsolete.
---
 gnu/bootloader/grub.scm | 46 -
 1 file changed, 13 insertions(+), 33 deletions(-)

diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index d4dbb57131..e3b8416d6d 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -135,41 +135,25 @@ file with the resolution provided in CONFIG."
(_ #f)
 
 (define* (eye-candy config store-device store-mount-point
-#:key store-directory-prefix system port)
+#:key store-directory-prefix port)
   "Return a gexp that writes to PORT (a port-valued gexp) the 'grub.cfg' part
 concerned with graphics mode, background images, colors, and all that.
 STORE-DEVICE designates the device holding the store, and STORE-MOUNT-POINT is
 its mount point; these are used to determine where the background image and
-fonts must be searched for.  SYSTEM must be the target system string---e.g.,
-\"x86_64-linux\".  STORE-DIRECTORY-PREFIX is a directory prefix to prepend to
-any store file name."
-  (define setup-gfxterm-body
-(let ((gfxmode
-   (or (and-let* ((theme (bootloader-configuration-theme config))
-  (gfxmode (grub-theme-gfxmode theme)))
- (string-join gfxmode ";"))
-   "auto")))
-
-  ;; Intel and EFI systems need to be switched into graphics mode, whereas
-  ;; most other modern architectures have no other mode and therefore
-  ;; don't need to be switched.
-
-  ;; XXX: Do we really need to restrict to x86 systems?  We could imitate
-  ;; what the GRUB default configuration does and decide based on whether
-  ;; a user provided 'gfxterm' in the terminal-outputs field of their
-  ;; bootloader-configuration record.
-  (if (string-match "^(x86_64|i[3-6]86)-" system)
-  (format #f "
-  set gfxmode=~a
-  insmod all_video
-  insmod gfxterm~%" gfxmode)
-  "")))
-
+fonts must be searched for.  STORE-DIRECTORY-PREFIX is a directory prefix to
+prepend to any store file name."
   (define (setup-gfxterm config font-file)
 (if (memq 'gfxterm (bootloader-configuration-terminal-outputs config))
-#~(format #f "if loadfont ~a; then
-  setup_gfxterm
-fi~%" #+font-file)
+#~(format #f "
+if loadfont ~a; then
+  set gfxmode=~a
+  insmod all_video
+  insmod gfxterm
+fi~%"
+  #$font-file
+  #$(string-join
+  (grub-theme-gfxmode (bootloader-theme config))
+  ";"))
 ""))
 
   (define (theme-colors type)
@@ -190,8 +174,6 @@ fi~%" #+font-file)
 
   (and image
#~(format #$port "
-function setup_gfxterm {~a}
-
 # Set 'root' to the partition that contains /gnu/store.
 ~a
 
@@ -206,7 +188,6 @@ else
   set menu_color_normal=cyan/blue
   set menu_color_highlight=white/blue
 fi~%"
- #$setup-gfxterm-body
  #$(grub-root-search store-device font-file)
  #$(setup-gfxterm config font-file)
  #$(grub-setup-io config)
@@ -380,7 +361,6 @@ menuentry ~s {
  device
  mount-point
  #:store-directory-prefix store-directory-prefix
- #:system system
  #:port #~port)))
 
   (define keyboard-layout-config
-- 
2.26.0

bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.

[Stefan]

Welcome. Yes, that’s fine.

> Am 09.06.2020 um 14:24 schrieb Mathieu Othacehe :
> 
> 
> Thanks for rebasing :)
> 
> Your copyright is missing, is this ok for you if I use:
> 
> "Stefan "
> 
> or would you prefer something else?
> 
> Mathieu

bug#43390: eudev should have ability to add a hwdb file

[Stefan Huchler]

There is a configuration field for udev rules:

https://guix.gnu.org/manual/en/html_node/Base-Services.html
udev-service [#:udev eudev #:rules '()]

But there is no configuration option to add a hwdb file.

I don't know if that matters but nixos has such option:
services.udev.extraHwdb

That's the hwdb file I want to add:
https://github.com/spiderbit/emacs-ergo-thinkpad-kb-layout/archive/master.zip

bug#44735: gilbc of the running system got wiped while building a package, system broken

[Stefan Kuhr]

Hi!

I didn’t look close enough before or didn’t wait long enough, but booting the 
previous system failed, actually.

I now tried to boot some more system generations and even the oldest one: None 
of my previous system generations is booting any longer. The system is bricked.


Bye

Stefan

bug#54783: ZRAM default priority wrong

[Stefan Baums]

I have a swap file and zram configured without specifying
priority. The swap file was assigned -2, and zram -3, with the
effect that zram was never used. I had to manually change the zram
priority to something higher that that of the swap file.

The manual wrongly claims that the default priority for zram is
-1. The same paragraph of the manual also says:

   ‘swapon’ accepts values between -1 and 32767, with higher
   values indicating higher priority.

which makes the -2 priority of the swap file look suspect (though
it seems to work).

bug#54783: ZRAM default priority wrong

[Stefan Baums]

Dear Josselin,

thank you very much! That should clarify things. I have been
happily using ZRAM on Guix since I figured it out.

All best,
Stefan

bug#58778: Bug report

[Diederich, Stefan]

ot-2.16.0.drv wird 
erstellt ...
/gnu/store/63rg0z7740w54nw1i13c298hp2nr485i-gcc-mesboot1-wrapper-4.6.4.drv wird 
erstellt ...
/gnu/store/1n6ikrdlf7z9bzqwjzb1rry92rkvnj83-gcc-mesboot-4.9.4.drv wird erstellt 
...
/gnu/store/q0ighqq1m74rpc95kw19nvirc52m8pzd-gcc-mesboot-wrapper-4.9.4.drv wird 
erstellt ...
/gnu/store/61zq7piv2smqvjay42hh0fwidlcpb1sj-coreutils-mesboot-8.32.drv wird 
erstellt ...
/gnu/store/rczzljpxym9hwj7rlgnvvmv83y8c7w5w-make-boot0-4.3.drv wird erstellt ...
/gnu/store/4i201488yp7lb8dpgjpg3d8xnfyfr8g7-coreutils-boot0-8.32.drv wird 
erstellt ...
/gnu/store/fxl2h3i6dzbil06vj7ps8irg6gpxhd15-diffutils-boot0-3.8.drv wird 
erstellt ...
/gnu/store/hlwciz0ax69w7397ki7qcbhmw4hkjk32-file-boot0-5.39.drv wird erstellt 
...
/gnu/store/np6mqc621p7cpqiph6zwn6qcpw7bgrlp-bzip2-boot0-1.0.8.drv wird erstellt 
...
/gnu/store/s4m2f22fzxyrrivimmg6k3mv03cv25cn-findutils-boot0-4.8.0.drv wird 
erstellt ...
/gnu/store/ia5zj1dmry65k3k5k9hkwdkxrniivrnb-gawk-boot0-5.1.0.drv wird erstellt 
...
/gnu/store/gm40mphaw3rlvkac2fqva6ps4g8pdrdb-patch-boot0-2.7.6.drv wird erstellt 
...
/gnu/store/i0gd1kwkvz2rfs9lj1cbvz36kivmzgw8-sed-boot0-4.8.drv wird erstellt ...
/gnu/store/p8sggng5kh5m1qypqvzf28ac7irdp4n5-tar-boot0-1.34.drv wird erstellt ...
/gnu/store/z4vfpjkm1hkfhci7i7w9m18klyr2azf6-binutils-cross-boot0-2.37.drv wird 
erstellt ...
/gnu/store/6j320ycam19b1vdw2s8hmqx9l8p1h8ly-expat-2.4.1.drv wird erstellt ...
/gnu/store/hshwaz730xvc458zjlr5zyp3prdqj3p8-ld-wrapper-boot0-0.drv wird 
erstellt ...
/gnu/store/94nc1pzihyai477jrsxx8zn4rcisxhq4-libstdc++-boot0-4.9.4.drv wird 
erstellt ...
/gnu/store/5s3v42q63whp7gjfivqsx1h3li61icg4-m4-boot0-1.4.18.drv wird erstellt 
...
/gnu/store/jx8dmd38rbv6gfvr7imhpnc36dfmaql2-gcc-cross-boot0-10.3.0.drv wird 
erstellt ...
/gnu/store/3g5zcpvrlx0inx4i4w8sipsyzl4nvysm-perl-boot0-5.34.0.drv wird erstellt 
...
/gnu/store/n2cy8lg74cxmmg00n4lx7qpy8k7bqh4i-gettext-boot0-0.19.8.1.drv wird 
erstellt ...
/gnu/store/91pqb5k7jpsjsxahcqnm19m5rxsd1055-bison-boot0-3.7.6.drv wird erstellt 
...
/gnu/store/359l4zdib187n1if68qv0myb3qk1mjbj-python-minimal-3.5.9.drv wird 
erstellt ...
/gnu/store/8vsn4sjdmbq306k8lpj3wgvw022f5x8k-flex-2.6.4.drv wird erstellt ...
/gnu/store/6nxkvh3ab6yzfcbb9x6z6yxqwd6xb4yi-texinfo-6.7.drv wird erstellt ...
/gnu/store/mrylnsq1m3731snyb9qjvxg64vlcz10j-linux-libre-headers-5.10.35.drv 
wird erstellt ...
/gnu/store/djsq5xw592l93v8wv66hyb6qmhhs4lk9-glibc-intermediate-2.33.drv wird 
erstellt ...
/gnu/store/ckzgp8fzc15frpd8jvfzsif28yqvvkvp-gcc-cross-boot0-wrapped-10.3.0.drv 
wird erstellt ...
/gnu/store/qnqdn0jyhb00rlhdhdkiv9ijhz3rlabs-bash-static-5.1.8.drv wird erstellt 
...
/gnu/store/v553l6m5k1799mxnx2anbaxpbl180c97-glibc-2.33.drv wird erstellt ...
/gnu/store/jhjgg22q1bjgkqhlwwp2bzd8f5r5jmmr-gcc-cross-boot0-wrapped-10.3.0.drv 
wird erstellt ...
/gnu/store/7p8m2v35lrjmgffv7map1cmn45vi0pkm-binutils-2.37.drv wird erstellt ...
/gnu/store/hwkk5yybmz7y7i71lwdg8gyzp75982km-libstdc++-10.3.0.drv wird erstellt 
...
/gnu/store/cpk9ywapa9ql6zz43w1cks81j6ar2qx0-ld-wrapper-boot3-0.drv wird 
erstellt ...
/gnu/store/3yki0pxx01xb72x1hy563jdcgm3czs8j-zlib-1.2.11.drv wird erstellt ...
/gnu/store/q1pxsx599ypzhamcm2rx2yvj6pchap87-gcc-10.3.0.drv wird erstellt ...
Backtrace:
  13 (primitive-load 
"/gnu/store/7rn1f6bi17pbir3amrdnhhakq4zbl7r5-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2170:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1998:8  7 (_ _)
In ./guix/gexp.scm:
   299:22  6 (_ _)
   1180:2  5 (_ _)
   1046:2  4 (_ _)
892:4  3 (_ _)
In ./guix/store.scm:
  2055:12  2 (_ #)
   1403:5  1 (map/accumulate-builds # 
# ?)
  1419:15  0 (_ # _ _)

./guix/store.scm:1419:15: ERROR:
  1. &store-protocol-error:
  message: "build of 
`/gnu/store/i6ckkxx8211x9yz3f34wcnbg7mblk7kg-curl-7.84.0.drv' failed"
  status: 100
guix pull: error: You found a bug: the program 
'/gnu/store/7rn1f6bi17pbir3amrdnhhakq4zbl7r5-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"a2e4e3489b4fdec6e270c93fcd9724abe983217e"; system: "x86_64-linux";
host version: "1.3.0"; pull-version: 1).
Please report the COMPLETE output above by email to .


Can you please help me?

Bests Stefan


Dr. Stefan Diederich
M. Sc. Bioinformatik

Universitätsmedizin
der Johannes Gutenberg-Universität Mainz
Langenbeckstraße 1, 55131 Mainz
Tel.: 06131 17-5797

bug#54528: [PATCH] fix store-prefix for menu-entries

[Stefan Karrmann]

Dear Maxim Cournoyer,

here is a patch, that fixes the global store-prefix for grub menu-entries

on commit 58a95d599ee5d0dc6419d038b7317e1b77b11519

git apply fix-store-prefix-for-menu-entry.patch

Kind regards,
--
Dr. Stefan Karrmann
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index ecd44e7f3c..048b9ff8fd 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -378,22 +378,25 @@ (define (menu-entry->gexp entry)
   (device-mount-point (menu-entry-device-mount-point entry))
   (multiboot-kernel (menu-entry-multiboot-kernel entry))
   (chain-loader (menu-entry-chain-loader entry)))
+  ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
+  ;; Use the right file names for LINUX and INITRD in case
+  ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
+  ;; separate partition. Then we don't use STORE-DIRECTORY-PREFIX.
+  ;; When STORE-DIRECTORY-PREFIX is defined, prepend it the linux and
+  ;; initrd paths, to allow booting from a Btrfs subvolume.
+  (define (normalize-or-grub path)
+"Normalize PATH if and only if DEVICE-MOUNT-POINT is \"/\"."
+(if (and (string? device-mount-point)
+ (string= "/" device-mount-point))
+(normalize-file path
+device-mount-point
+store-directory-prefix)
+path))
   (cond
(linux
 (let ((arguments (menu-entry-linux-arguments entry))
-  (linux (normalize-file linux
- device-mount-point
- store-directory-prefix))
-  (initrd (normalize-file (menu-entry-initrd entry)
-  device-mount-point
-  store-directory-prefix)))
-  ;; Here DEVICE is the store and DEVICE-MOUNT-POINT is its mount point.
-  ;; Use the right file names for LINUX and INITRD in case
-  ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
-  ;; separate partition.
-
-  ;; When STORE-DIRECTORY-PREFIX is defined, prepend it the linux and
-  ;; initrd paths, to allow booting from a Btrfs subvolume.
+  (linux (normalize-or-grub linux))
+  (initrd (normalize-or-grub (menu-entry-initrd entry
   #~(format port "menuentry ~s {
   ~a
   linux ~a ~a

bug#41178: can't log into X anymore ( polkit )

[Stefan Huchler]

shortly after installing X and making the first few changes setting the
root password and boom I can't login into X anymore.


My configuration:
/--
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop ssh)
(use-package-modules bootloaders certs ratpoison emacs-xyz
 suckless wm xorg emacs web-browsers)

(operating-system
 (host-name "XXX")
 (timezone "Europe/Berlin")
 (locale "en_US.utf8")

 (keyboard-layout (keyboard-layout "us" "dvorak"))
 
 (bootloader (bootloader-configuration
  (bootloader grub-bootloader)
  (target "/dev/sda")))

 (file-systems (append
(list (file-system
   (device (file-system-label "guix-root"))
   (mount-point "/")
   (type "ext4"))
  (file-system
   (device (file-system-label "home"))
   (mount-point "/home")
   (type "ext4")))
%base-file-systems))

 (users (cons (user-account
   (name "XXX")
   (comment "Me")
   (group "users")
   (supplementary-groups '("wheel" "netdev"
   "audio" "video")))
  %base-user-accounts))

 (packages (append (list
;; window managers
ratpoison i3-wm i3status dmenu
;; emacs-exwm
xterm
nss-certs
vimb
emacs)
   %base-packages))

 (services (cons* (service openssh-service-type
   (openssh-configuration
(permit-root-login #t)))
  ;;(service xfce-desktop-service-type)
  %desktop-services))

 (name-service-switch %mdns-host-lookup-nss))

/--

Authentication needed [...] intel-backlight-helper and a password prompt
that I can't hit on, and somethnig with polkit.

I think it propable had to do with me setting a root password. I unset
it with password -dl root and only passwd -d root, but both didn't fix
it.

bug#41178: can't log into X anymore ( polkit )

[Stefan Huchler]

So, after nobody answered to my problem and a guix pull / reconfigure
did change nothing I replaced gdm with slim with following changes:

(use-modules (gnu)
 (srfi srfi-1)
 (gnu system nss))
(use-service-modules desktop ssh xorg)
(use-package-modules bootloaders certs ratpoison emacs-xyz
 suckless wm xorg emacs web-browsers)

...

 (services (cons* (service openssh-service-type
   (openssh-configuration
(permit-root-login #t)))
  (service slim-service-type)
  (remove (lambda (service)
(eq? (service-kind service) gdm-service-type))
  %desktop-services)))

and slim just works, it fixes the problem for me because I don't want to
run gdm on this low power machine anyway, but maybe somebody can
understand why slim runs and gdm not, I did not do much special I just
wanted to make my first guix install and got X running with the
light-desktop config with some minor unrelated changes like adding a few
packages and activate ssh. The only thing as I said was that I set a
password for root, but that seems also not to be such a untypical
step. So I wonder if that is a 32bit only problem else I would assume
many people would run into that. More or less the default installation
broke, sure not the graphical installation, with that I had problems
with grub, because if I remember correctly it assumed efi support.

It's strange to me that switching the display-manager fixes the problem
because that would imply that the gdm package is buggy, which again it's
in the default desktop-services variable.

But for me it's ok and maybe somebody else runs into that problem, then
maybe my bug report information helps.


Stefan Huchler  writes:

> shortly after installing X and making the first few changes setting the
> root password and boom I can't login into X anymore.
>
>
> My configuration:
> /--
> (use-modules (gnu) (gnu system nss))
> (use-service-modules desktop ssh)
> (use-package-modules bootloaders certs ratpoison emacs-xyz
>suckless wm xorg emacs web-browsers)
>
> (operating-system
>  (host-name "XXX")
>  (timezone "Europe/Berlin")
>  (locale "en_US.utf8")
>
>  (keyboard-layout (keyboard-layout "us" "dvorak"))
>  
>  (bootloader (bootloader-configuration
> (bootloader grub-bootloader)
> (target "/dev/sda")))
>
>  (file-systems (append
>   (list (file-system
>  (device (file-system-label "guix-root"))
>  (mount-point "/")
>  (type "ext4"))
> (file-system
>  (device (file-system-label "home"))
>  (mount-point "/home")
>  (type "ext4")))
>   %base-file-systems))
>
>  (users (cons (user-account
>  (name "XXX")
>  (comment "Me")
>  (group "users")
>  (supplementary-groups '("wheel" "netdev"
>  "audio" "video")))
> %base-user-accounts))
>
>  (packages (append (list
>   ;; window managers
>   ratpoison i3-wm i3status dmenu
>   ;; emacs-exwm
>   xterm
>   nss-certs
>   vimb
>   emacs)
>  %base-packages))
>
>  (services (cons* (service openssh-service-type
>  (openssh-configuration
>   (permit-root-login #t)))
> ;;(service xfce-desktop-service-type)
> %desktop-services))
>
>  (name-service-switch %mdns-host-lookup-nss))
>
> /--
>
> Authentication needed [...] intel-backlight-helper and a password prompt
> that I can't hit on, and somethnig with polkit.
>
> I think it propable had to do with me setting a root password. I unset
> it with password -dl root and only passwd -d root, but both didn't fix
> it.

bug#41121: (Keyboard-layout) form does not work "across the board"

[Stefan Huchler]

o.ro...@posteo.net writes:

> In the process of changing my login manager to slim (over gdm), I
> noticed that the (keyboard-layout ...) form does not work the same way
> in the (bootloader)/(set-xorg-configuration) and the
> (slim-configuration) form. While in the former cases, (keyboard-layout
> keyboard-layout) uses the string I inputted in the beginning of the
> config file, an error is thrown when I try to do the same in the
> (slim-configuration) form (error 1). When I simply use (service
> slim-service-type) and try to supplement via (set-xorg-configuration),
> an error is thrown as well (error 2).

Hello "o",

sadly can't see your name, I run into the same Problem and first found
only your bug report so did not care to look for other bug reports
further back in the past, but this "bug" missunderstanding seems to be
related to bug#37422.

I found the solution by carefully reading the docu und try/error a few
iterations first with simpler level of config till I got the solution
( would be easier if I found the bug mentioned earlier but I learned more
this way so it's good :D )

This is the solution to get it working:
(service slim-service-type
(slim-configuration
   (xorg-configuration (xorg-configuration
(keyboard-layout keyboard-layout)

The tricky part is that you have to use 2 times xorg-configuration one
time for the variable name and one time you have some sort of generator
function for xorg-configuration, that didn't clip for me as newcomer to
guix instantly.

If we consider that a bug it would be a documentian bug, and maybe that
the set-xorg-configuration method does not work (at least it seems that
way) that is not what the documentation implies. This function looks
like a general function where it says "e.g. gdm" that implies that it
should work for both gdm and all other login-managers the same way.

Ok just testet it that works to:

(set-xorg-configuration
   (xorg-configuration
  (keyboard-layout keyboard-layout)) slim-service-type)

Where the documentition there is missleading is that you see the:

Scheme Procedure: set-xorg-configuration config
[login-manager-service-type]

optional login-manager-service-type parameter but it's not described
that it defaults to gdm-service-type and can be therefor ommited in the
case of gdm.

So I would A maybe add more sample code and B adding (default:
gdm-service-type) behind the "set-xorg-configuration" description.

bug#41516: Slim package unnessesarily conflates default-user/default-session with autologin

[Stefan Huchler]

The 3 options of default-user / default-login-session and autologin are
not as tight coupled and should in fact it's the wrong way coupled:

> When @var{auto-login?} is true, log in automatically as
> @var{default-user} with @var{auto-login-session}.

So you can set auto-login? #t and don't set the other 2 values and it
then succesfully reconfigures but just presents the normal login screen
and not autologins.

But if you only use default-user or auto-login-session but keep
auto-login? #f this values get not written in the config and therefor
the settings get just ignored:

(if (slim-configuration-auto-login? config)
(string-append "auto_login yes\ndefault_user "
   (slim-configuration-default-user config) "\n")
"")

At least that is true for user, I find no code for the
auto-login-session but when I set it without autologin it seems to get
ignored, too.

But the default user setting works independent from autologin:
https://wiki.archlinux.org/index.php/SLiM#Set_default_username

In fact the default-session seems to be also only useful for autologin
as far as I can tell:

  (let* ((xinitrc (xinitrc #:fallback-session
   (slim-configuration-auto-login-session
   config)))
...
login_cmd  exec " xinitrc " %session
...
)

There seems to be different ways to have per user default sessions or
global so I am not 100% sure about that, but you can set default user
without conflating that with autologin, while you maybe need a
default-user for autologin you don't need autologin for a default-user.

bug#63045: Can't suspend and wakeup outside of gnome

[Stefan Huchler]

When I try to suspend as example with loginctl suspend, but also other
methods like dbus command sending or the echo mem > ... it sometimes
works but around 60% mostly the 2nd time never reaches fully the suspend
state but monitor is out, no suspend typical power blinking, the only
way to recover is then to shut down the pc long power button press.

Now I switched from nixos where it worked I also tried to install the
5.15 kernel so in case it's a kernel bug, but the same issue.

I run into another person on #guix irc which claimed to have the same
issue, with a totally different system, I use a amd Ryzen 5 2400G with
the vanilla kernel not linux-libre he said he used the libre kernel with
a intel system.

Did report this already to the nonguix repo.
https://gitlab.com/nonguix/nonguix/-/issues/257

My workaround is to have a gnome instance runnig on tty8 and switch
there to suspend it over gnome then it works always.

bug#63045: Can't suspend and wakeup outside of gnome

[Stefan Huchler]

here is the part of the log that should show a crash from suspend.

Apr 15 19:38:32 localhost elogind[352]: Suspending system...
Apr 15 19:38:32 localhost vmunix: [   96.960350] PM: suspend entry (deep)
Apr 15 19:38:34 localhost vmunix: [   96.971363] Filesystems sync: 0.011 seconds
Apr 15 19:38:34 localhost vmunix: [   96.971643] Freezing user space processes
Apr 15 19:38:34 localhost vmunix: [   96.972920] Freezing user space processes 
completed (elapsed 0.001 seconds)
Apr 15 19:38:34 localhost vmunix: [   96.972926] OOM killer disabled.
Apr 15 19:38:34 localhost vmunix: [   96.972927] Freezing remaining freezable 
tasks
Apr 15 19:38:34 localhost vmunix: [   96.974038] Freezing remaining freezable 
tasks completed (elapsed 0.001 seconds)
Apr 15 19:38:34 localhost vmunix: [   96.974062] printk: Suspending console(s) 
(use no_console_suspend to debug)
Apr 15 19:38:34 localhost vmunix: [   96.975397] serial 00:04: disabled
Apr 15 19:38:34 localhost vmunix: [   96.975545] r8169 :02:00.0 enp2s0: 
Link is Down
Apr 15 19:38:34 localhost vmunix: [   97.002210] sd 0:0:0:0: [sda] 
Synchronizing SCSI cache
Apr 15 19:38:34 localhost vmunix: [   97.002481] sd 0:0:0:0: [sda] Stopping disk
Apr 15 19:38:34 localhost vmunix: [   97.290213] ACPI: PM: Preparing to enter 
system sleep state S3
Apr 15 19:38:34 localhost vmunix: [   97.830759] ACPI: PM: Saving platform NVS 
memory
Apr 15 19:38:34 localhost vmunix: [   97.830872] Disabling non-boot CPUs ...
Apr 15 19:38:34 localhost vmunix: [   97.830875] Wakeup pending. Abort CPU 
freeze
Apr 15 19:38:34 localhost vmunix: [   97.830876] Non-boot CPUs are not disabled
Apr 15 19:38:34 localhost vmunix: [   97.830886] ACPI: PM: Waking up from 
system sleep state S3
Apr 15 19:38:34 localhost vmunix: [   98.162855] xhci_hcd :03:00.3: 
Controller not ready at resume -19
Apr 15 19:38:34 localhost vmunix: [   98.162881] xhci_hcd :03:00.3: PCI 
post-resume error -19!
Apr 15 19:38:34 localhost vmunix: [   98.162884] xhci_hcd :03:00.3: HC 
died; cleaning up
Apr 15 19:38:34 localhost vmunix: [   98.162892] xhci_hcd :03:00.3: PM: 
dpm_run_callback(): pci_pm_resume+0x0/0x110
 returns -19
Apr 15 19:38:34 localhost vmunix: [   98.162908] xhci_hcd :03:00.3: PM: 
failed to resume async: error -19

bug#58008: [PATCH] gnu: linux: Fix the extra-version parameter in make-linux-libre*.

[Stefan via Bug reports for GNU Guix]

Hi Leo!

I’m addressing you directly because of the entry in etc/teams.scm.

I found and fixed a bug in make-linux-libre*. The split of the phase 'configure 
into a separate 'set-environment will be used by another patch. 

Actually this is part of a patch series in 48314. But it is an independent fix, 
which can reduce the size of that other ticket.

If this patch is accepted, I may send another part of that patch series 
separately.


Bye

Stefan



01-gnu-linux-fix-extra-version.patch
Description: Binary data

bug#71326: ld-wrapper does not handle all possibilities to specify libraries and their search paths

[Stefan via Bug reports for GNU Guix]

Hi!

Beside using an absolute path, the ld of Binutils has eight ways¹ to pass a 
library like libfoo.so via options:

-lfoo
-l foo
-library=foo
--library=foo
-l:libfoo.so
-l :libfoo.so
-library=:libfoo.so
--library=:libfoo.so

The ld-wrapper however only supports one of these possibilities, which is the 
most common: -lfoo. GCC itself does not support the -[-]library= variants.


Similarly there are four ways to specify a library search path /bar for ld:

-L/bar
-L /bar
-library-path=/bar
--library-path=/bar

The ld-wrapper only supports the first two. GCC itself does not support the 
-[-]library-path= variant.


The lld form the LLVM project supports all these different options as well.


Bye

Stefan


¹ <https://sourceware.org/binutils/docs-2.42/ld/Options.html>