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

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>

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

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

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

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

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

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

bug#58778: Bug report

te-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 m

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

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#54783: ZRAM default priority wrong

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#54783: ZRAM default priority wrong

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

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

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#50592: Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader

ooting 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

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#47956: nfs-root-fs test is failing

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.

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

it another try. Bye Stefan

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

n 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! exi

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

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 t

bug#45196: guile-studio cannot open file

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#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

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#45716: Bug in ‘network-interface-names’ when building guix for aarch64 on x86_64.

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.

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: [PATCH 1/1] gnu: qemu: Fix ioclt(…, SIOCGIFCONF, …) for emulated 64 bit architectures.

* 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

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

* 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

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

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

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

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

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

mu 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#45654: [PATCH 1/1] gnu: qemu-binfmt-service-type: Change 'guix-support?' default to #t.

* 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

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

;= + 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 repr

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

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#45654: Building guile on x86_64 for aarch64 fails because of a missing guile

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 ev

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

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

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

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 '/

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

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.

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

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

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

uot;corrupt!" port))) +#t) + (not (verify-store s #:check-contents? #t)) + (delete-paths s (list file))) actual-value: #f actual-error: + (%exception + #< message: "path `dtmp/guix-tests/store/rn6xq5kaipp8aanhcnz2hvyfmr3y2laa-mirrors' is not in the store" status: 1>) result: FAIL Bye Stefan

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

nfs-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#45508: ‘guix system disk-image‘ installs GRUB debug files

ug output. Bye Stefan

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

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/invoca

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

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

bug#45196: guile-studio cannot open file

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

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

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#41654: [PATCH] tests: Ignoring incomplete clean-up on NFS share.

* 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

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

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 existenc

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

-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

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#44735: gilbc of the running system got wiped while building a package, system broken

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#44735: gilbc of the running system got wiped while building a package, system broken

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

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

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/

bug#44525:

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

-file. Thanks, I’ll close this issue. Bye Stefan

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

uilder"],[("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#43534: qemu-minimal-5.1.0 fails to build during test phase on aarch64

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

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

PASS 5 arm-cpu-features /aarch64/arm/max/query-cpu-model-expansion/sve-off Bye Stefan

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

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

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

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#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.

* 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

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

* 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

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

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

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

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

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

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 >

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

(#< 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#41484: guix gc fails catastrophically if the disk has no space left

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

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

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

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

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

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

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(-) > &g

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

e 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: Subject: [PATCH] gnu: system: Fix PATH export if the profile has no bin directory.

* 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 +++

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

rst 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 ~/develo

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

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 s

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

t;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 en