* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 @ 2022-01-01 23:54 Aiko Kyle 2022-01-02 2:13 ` Leo Famulari 2022-01-09 4:39 ` Chris Marusich 0 siblings, 2 replies; 21+ messages in thread From: Aiko Kyle @ 2022-01-01 23:54 UTC (permalink / raw) To: 52943 [-- Attachment #1: Type: text/plain, Size: 1185 bytes --] Hi, I'm new to guix so I'm really struggling to debug this strange issue. On the latest master I can run 'guix pull', and the latest guix seems to build just fine, however when I go to do 'guix system reconfigure', building guix fails the check phase. I've attached the log file. After some help on IRC, I understand that during 'guix system reconfigure' ends up building a previous version of itself via the "boot-stripping" process in gnu/packages/package-management.scm. I followed this linked list of commits backwards and found that commits prior to commit 224d437fb4 which updates this guix package definition to version 14 which is commit 2a621f1 build just fine, however all the versions of that package afterwards fail at the same place during 'guix system reconfigure', in the check phase, with the same tests failing. At this point, I think I lack sufficient knowledge of guix to debug this issue further and it looks like cuirass is so backlogged on aarch64 that is still hasn't gotten to building these guix versions so I can't compare with it's build attempts. Any help would be greatly appreciated as I'd really like to be running the latest guix from master. Thanks! [-- Attachment #2: 7w4qq23xj1jhk0972x7q8s5q918pl3-guix-1.3.0-14.2a621f1.drv --] [-- Type: application/octet-stream, Size: 2488362 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-01 23:54 bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 Aiko Kyle @ 2022-01-02 2:13 ` Leo Famulari 2022-01-02 4:11 ` Aiko Kyle 2022-01-09 4:39 ` Chris Marusich 1 sibling, 1 reply; 21+ messages in thread From: Leo Famulari @ 2022-01-02 2:13 UTC (permalink / raw) To: Aiko Kyle; +Cc: 52943 On Sat, Jan 01, 2022 at 04:54:51PM -0700, Aiko Kyle wrote: > I'm new to guix so I'm really struggling to debug this strange issue. > On the latest master I can run 'guix pull', and the latest guix seems > to build just fine, however when I go to do 'guix system reconfigure', > building guix fails the check phase. I've attached the log file. After > some help on IRC, I understand that during 'guix system reconfigure' > ends up building a previous version of itself via the "boot-stripping" > process in gnu/packages/package-management.scm. I followed this linked > list of commits backwards and found that commits prior to commit > 224d437fb4 which updates this guix package definition to version 14 > which is commit 2a621f1 build just fine, however all the versions of > that package afterwards fail at the same place during 'guix system > reconfigure', in the check phase, with the same tests failing. At this > point, I think I lack sufficient knowledge of guix to debug this issue > further and it looks like cuirass is so backlogged on aarch64 that is > still hasn't gotten to building these guix versions so I can't compare > with it's build attempts. Any help would be greatly appreciated as I'd > really like to be running the latest guix from master. Thanks, this has already been reported as <https://issues.guix.gnu.org/52908> ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-02 2:13 ` Leo Famulari @ 2022-01-02 4:11 ` Aiko Kyle 2022-01-02 4:51 ` Leo Famulari 0 siblings, 1 reply; 21+ messages in thread From: Aiko Kyle @ 2022-01-02 4:11 UTC (permalink / raw) To: Leo Famulari; +Cc: 52943 [-- Attachment #1: Type: text/plain, Size: 107 bytes --] Attached is the output of guix system shepherd-graph gnu/system/examples/desktop.tmpl on commit 2a49ddb513 [-- Attachment #2: graph.dot --] [-- Type: application/msword, Size: 13867 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-02 4:11 ` Aiko Kyle @ 2022-01-02 4:51 ` Leo Famulari 2022-01-02 6:36 ` Aiko Kyle 0 siblings, 1 reply; 21+ messages in thread From: Leo Famulari @ 2022-01-02 4:51 UTC (permalink / raw) To: Aiko Kyle; +Cc: 52943 [-- Attachment #1: Type: text/plain, Size: 437 bytes --] On Sat, Jan 01, 2022 at 09:11:49PM -0700, Aiko Kyle wrote: > Attached is the output of guix system shepherd-graph > gnu/system/examples/desktop.tmpl on commit 2a49ddb513 Thanks, and I've attached a graph of the same operating system declaration from the same revision of Guix but for x86_64, along with rendered images of both graphs. The graphs clearly show that xorg-server is provided in two places on aarch64. The question is why? [-- Attachment #2: graph-x86_64 --] [-- Type: text/plain, Size: 13617 bytes --] digraph "Guix shepherd-service" { "user-file-systems" [label = "user-file-systems", shape = box, fontname = sans]; "file-systems" -> "user-file-systems" [color = darkviolet]; "file-systems" [label = "file-systems", shape = box, fontname = sans]; "user-processes" -> "file-systems" [color = dimgrey]; "user-homes" -> "file-systems" [color = darkgoldenrod]; "urandom-seed" -> "file-systems" [color = magenta]; "user-processes" [label = "user-processes", shape = box, fontname = sans]; "nscd" -> "user-processes" [color = darkseagreen]; "guix-daemon" -> "user-processes" [color = dimgrey]; "syslogd" -> "user-processes" [color = darkseagreen]; "term-tty6" -> "user-processes" [color = peachpuff4]; "term-tty5" -> "user-processes" [color = red]; "term-tty4" -> "user-processes" [color = darkseagreen]; "term-tty3" -> "user-processes" [color = darkgoldenrod]; "term-tty2" -> "user-processes" [color = dimgrey]; "term-tty1" -> "user-processes" [color = magenta]; "term-auto" -> "user-processes" [color = red]; "ntpd" -> "user-processes" [color = red]; "dbus-system" -> "user-processes" [color = peachpuff4]; "avahi-daemon" -> "user-processes" [color = cyan3]; "wpa-supplicant" -> "user-processes" [color = dimgrey]; "networking" -> "user-processes" [color = darkviolet]; "xorg-server" -> "user-processes" [color = red]; "mcron" -> "user-processes" [color = darkgoldenrod]; "nscd" [label = "nscd", shape = box, fontname = sans]; "guix-daemon" [label = "guix-daemon", shape = box, fontname = sans]; "syslogd" [label = "syslogd", shape = box, fontname = sans]; "dbus-system" -> "syslogd" [color = peachpuff4]; "wpa-supplicant" -> "syslogd" [color = dimgrey]; "dbus-system" [label = "dbus-system", shape = box, fontname = sans]; "elogind" -> "dbus-system" [color = darkviolet]; "upower-daemon" -> "dbus-system" [color = dimgrey]; "avahi-daemon" -> "dbus-system" [color = cyan3]; "wpa-supplicant" -> "dbus-system" [color = dimgrey]; "networking" -> "dbus-system" [color = darkviolet]; "xorg-server" -> "dbus-system" [color = red]; "elogind" [label = "elogind", shape = box, fontname = sans]; "upower-daemon" [label = "upower-daemon", shape = box, fontname = sans]; "avahi-daemon" [label = "avahi-daemon", shape = box, fontname = sans]; "wpa-supplicant" [label = "wpa-supplicant", shape = box, fontname = sans]; "networking" -> "wpa-supplicant" [color = darkviolet]; "networking" [label = "networking", shape = box, fontname = sans]; "ntpd" -> "networking" [color = red]; "avahi-daemon" -> "networking" [color = cyan3]; "ntpd" [label = "ntpd", shape = box, fontname = sans]; "xorg-server" [label = "xorg-server", shape = box, fontname = sans]; "term-tty6" [label = "term-tty6", shape = box, fontname = sans]; "console-font-tty6" -> "term-tty6" [color = darkviolet]; "console-font-tty6" [label = "console-font-tty6", shape = box, fontname = sans]; "term-tty5" [label = "term-tty5", shape = box, fontname = sans]; "console-font-tty5" -> "term-tty5" [color = peachpuff4]; "console-font-tty5" [label = "console-font-tty5", shape = box, fontname = sans]; "term-tty4" [label = "term-tty4", shape = box, fontname = sans]; "console-font-tty4" -> "term-tty4" [color = red]; "console-font-tty4" [label = "console-font-tty4", shape = box, fontname = sans]; "term-tty3" [label = "term-tty3", shape = box, fontname = sans]; "console-font-tty3" -> "term-tty3" [color = cyan3]; "console-font-tty3" [label = "console-font-tty3", shape = box, fontname = sans]; "term-tty2" [label = "term-tty2", shape = box, fontname = sans]; "console-font-tty2" -> "term-tty2" [color = blue]; "console-font-tty2" [label = "console-font-tty2", shape = box, fontname = sans]; "term-tty1" [label = "term-tty1", shape = box, fontname = sans]; "console-font-tty1" -> "term-tty1" [color = darkseagreen]; "console-font-tty1" [label = "console-font-tty1", shape = box, fontname = sans]; "term-auto" [label = "term-auto", shape = box, fontname = sans]; "mcron" [label = "mcron", shape = box, fontname = sans]; "user-homes" [label = "user-homes", shape = box, fontname = sans]; "user-processes" -> "user-homes" [color = dimgrey]; "urandom-seed" [label = "urandom-seed", shape = box, fontname = sans]; "user-processes" -> "urandom-seed" [color = dimgrey]; "root-file-system" [label = "root-file-system", shape = box, fontname = sans]; "file-systems" -> "root-file-system" [color = darkviolet]; "file-system-/boot/efi" -> "root-file-system" [color = cyan3]; "file-system-/dev/pts" -> "root-file-system" [color = red]; "file-system-/sys/kernel/debug" -> "root-file-system" [color = cyan3]; "file-system-/dev/shm" -> "root-file-system" [color = peachpuff4]; "file-system-/sys/firmware/efi/efivars" -> "root-file-system" [color = red]; "file-system-/gnu/store" -> "root-file-system" [color = magenta]; "file-system-/run/systemd" -> "root-file-system" [color = darkseagreen]; "file-system-/run/user" -> "root-file-system" [color = magenta]; "file-system-/sys/fs/cgroup/elogind" -> "root-file-system" [color = dimgrey]; "file-system-/sys/fs/cgroup" -> "root-file-system" [color = dimgrey]; "file-system-/sys/fs/cgroup/cpuset" -> "root-file-system" [color = blue]; "file-system-/sys/fs/cgroup/cpu" -> "root-file-system" [color = cyan3]; "file-system-/sys/fs/cgroup/cpuacct" -> "root-file-system" [color = magenta]; "file-system-/sys/fs/cgroup/memory" -> "root-file-system" [color = darkgoldenrod]; "file-system-/sys/fs/cgroup/devices" -> "root-file-system" [color = magenta]; "file-system-/sys/fs/cgroup/freezer" -> "root-file-system" [color = red]; "file-system-/sys/fs/cgroup/blkio" -> "root-file-system" [color = peachpuff4]; "file-system-/sys/fs/cgroup/perf_event" -> "root-file-system" [color = red]; "file-system-/sys/fs/cgroup/pids" -> "root-file-system" [color = darkviolet]; "file-system-/var/cache/fontconfig" -> "root-file-system" [color = magenta]; "udev" -> "root-file-system" [color = cyan3]; "virtual-terminal" -> "root-file-system" [color = peachpuff4]; "file-system-/boot/efi" [label = "file-system-/boot/efi", shape = box, fontname = sans]; "file-systems" -> "file-system-/boot/efi" [color = darkviolet]; "file-system-/dev/pts" [label = "file-system-/dev/pts", shape = box, fontname = sans]; "file-systems" -> "file-system-/dev/pts" [color = darkviolet]; "file-system-/sys/kernel/debug" [label = "file-system-/sys/kernel/debug", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/kernel/debug" [color = darkviolet]; "file-system-/dev/shm" [label = "file-system-/dev/shm", shape = box, fontname = sans]; "file-systems" -> "file-system-/dev/shm" [color = darkviolet]; "file-system-/sys/firmware/efi/efivars" [label = "file-system-/sys/firmware/efi/efivars", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/firmware/efi/efivars" [color = darkviolet]; "file-system-/gnu/store" [label = "file-system-/gnu/store", shape = box, fontname = sans]; "file-systems" -> "file-system-/gnu/store" [color = darkviolet]; "file-system-/run/systemd" [label = "file-system-/run/systemd", shape = box, fontname = sans]; "file-systems" -> "file-system-/run/systemd" [color = darkviolet]; "file-system-/run/user" [label = "file-system-/run/user", shape = box, fontname = sans]; "file-systems" -> "file-system-/run/user" [color = darkviolet]; "file-system-/sys/fs/cgroup/elogind" [label = "file-system-/sys/fs/cgroup/elogind", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/elogind" [color = darkviolet]; "file-system-/sys/fs/cgroup" [label = "file-system-/sys/fs/cgroup", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup" [color = darkviolet]; "file-system-/sys/fs/cgroup/elogind" -> "file-system-/sys/fs/cgroup" [color = dimgrey]; "file-system-/sys/fs/cgroup/cpuset" -> "file-system-/sys/fs/cgroup" [color = blue]; "file-system-/sys/fs/cgroup/cpu" -> "file-system-/sys/fs/cgroup" [color = cyan3]; "file-system-/sys/fs/cgroup/cpuacct" -> "file-system-/sys/fs/cgroup" [color = magenta]; "file-system-/sys/fs/cgroup/memory" -> "file-system-/sys/fs/cgroup" [color = darkgoldenrod]; "file-system-/sys/fs/cgroup/devices" -> "file-system-/sys/fs/cgroup" [color = magenta]; "file-system-/sys/fs/cgroup/freezer" -> "file-system-/sys/fs/cgroup" [color = red]; "file-system-/sys/fs/cgroup/blkio" -> "file-system-/sys/fs/cgroup" [color = peachpuff4]; "file-system-/sys/fs/cgroup/perf_event" -> "file-system-/sys/fs/cgroup" [color = red]; "file-system-/sys/fs/cgroup/pids" -> "file-system-/sys/fs/cgroup" [color = darkviolet]; "file-system-/sys/fs/cgroup/cpuset" [label = "file-system-/sys/fs/cgroup/cpuset", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/cpuset" [color = darkviolet]; "file-system-/sys/fs/cgroup/cpu" [label = "file-system-/sys/fs/cgroup/cpu", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/cpu" [color = darkviolet]; "file-system-/sys/fs/cgroup/cpuacct" [label = "file-system-/sys/fs/cgroup/cpuacct", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/cpuacct" [color = darkviolet]; "file-system-/sys/fs/cgroup/memory" [label = "file-system-/sys/fs/cgroup/memory", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/memory" [color = darkviolet]; "file-system-/sys/fs/cgroup/devices" [label = "file-system-/sys/fs/cgroup/devices", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/devices" [color = darkviolet]; "file-system-/sys/fs/cgroup/freezer" [label = "file-system-/sys/fs/cgroup/freezer", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/freezer" [color = darkviolet]; "file-system-/sys/fs/cgroup/blkio" [label = "file-system-/sys/fs/cgroup/blkio", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/blkio" [color = darkviolet]; "file-system-/sys/fs/cgroup/perf_event" [label = "file-system-/sys/fs/cgroup/perf_event", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/perf_event" [color = darkviolet]; "file-system-/sys/fs/cgroup/pids" [label = "file-system-/sys/fs/cgroup/pids", shape = box, fontname = sans]; "file-systems" -> "file-system-/sys/fs/cgroup/pids" [color = darkviolet]; "file-system-/var/cache/fontconfig" [label = "file-system-/var/cache/fontconfig", shape = box, fontname = sans]; "file-systems" -> "file-system-/var/cache/fontconfig" [color = darkviolet]; "udev" [label = "udev", shape = box, fontname = sans]; "swap-/swapfile" -> "udev" [color = darkseagreen]; "file-system-/boot/efi" -> "udev" [color = cyan3]; "file-system-/dev/pts" -> "udev" [color = red]; "file-system-/sys/kernel/debug" -> "udev" [color = cyan3]; "file-system-/dev/shm" -> "udev" [color = peachpuff4]; "file-system-/sys/firmware/efi/efivars" -> "udev" [color = red]; "file-system-/gnu/store" -> "udev" [color = magenta]; "file-system-/run/systemd" -> "udev" [color = darkseagreen]; "file-system-/run/user" -> "udev" [color = magenta]; "file-system-/sys/fs/cgroup/elogind" -> "udev" [color = dimgrey]; "file-system-/sys/fs/cgroup" -> "udev" [color = dimgrey]; "file-system-/sys/fs/cgroup/cpuset" -> "udev" [color = blue]; "file-system-/sys/fs/cgroup/cpu" -> "udev" [color = cyan3]; "file-system-/sys/fs/cgroup/cpuacct" -> "udev" [color = magenta]; "file-system-/sys/fs/cgroup/memory" -> "udev" [color = darkgoldenrod]; "file-system-/sys/fs/cgroup/devices" -> "udev" [color = magenta]; "file-system-/sys/fs/cgroup/freezer" -> "udev" [color = red]; "file-system-/sys/fs/cgroup/blkio" -> "udev" [color = peachpuff4]; "file-system-/sys/fs/cgroup/perf_event" -> "udev" [color = red]; "file-system-/sys/fs/cgroup/pids" -> "udev" [color = darkviolet]; "file-system-/var/cache/fontconfig" -> "udev" [color = magenta]; "urandom-seed" -> "udev" [color = magenta]; "term-tty6" -> "udev" [color = peachpuff4]; "term-tty5" -> "udev" [color = red]; "term-tty4" -> "udev" [color = darkseagreen]; "term-tty3" -> "udev" [color = darkgoldenrod]; "term-tty2" -> "udev" [color = dimgrey]; "term-tty1" -> "udev" [color = magenta]; "term-auto" -> "udev" [color = red]; "upower-daemon" -> "udev" [color = dimgrey]; "xorg-server" -> "udev" [color = red]; "swap-/swapfile" [label = "swap-/swapfile", shape = box, fontname = sans]; "virtual-terminal" [label = "virtual-terminal", shape = box, fontname = sans]; "term-tty6" -> "virtual-terminal" [color = peachpuff4]; "term-tty5" -> "virtual-terminal" [color = red]; "term-tty4" -> "virtual-terminal" [color = darkseagreen]; "term-tty3" -> "virtual-terminal" [color = darkgoldenrod]; "term-tty2" -> "virtual-terminal" [color = dimgrey]; "term-tty1" -> "virtual-terminal" [color = magenta]; "host-name" [label = "host-name", shape = box, fontname = sans]; "term-tty6" -> "host-name" [color = peachpuff4]; "term-tty5" -> "host-name" [color = red]; "term-tty4" -> "host-name" [color = darkseagreen]; "term-tty3" -> "host-name" [color = darkgoldenrod]; "term-tty2" -> "host-name" [color = dimgrey]; "term-tty1" -> "host-name" [color = magenta]; "term-auto" -> "host-name" [color = red]; "xorg-server" -> "host-name" [color = red]; "sysctl" [label = "sysctl", shape = box, fontname = sans]; "loopback" [label = "loopback", shape = box, fontname = sans]; "wpa-supplicant" -> "loopback" [color = dimgrey]; "networking" -> "loopback" [color = darkviolet]; } [-- Attachment #3: graph-x86_64.png --] [-- Type: image/png, Size: 674730 bytes --] [-- Attachment #4: graph-aarch64.png --] [-- Type: image/png, Size: 668336 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-02 4:51 ` Leo Famulari @ 2022-01-02 6:36 ` Aiko Kyle 2022-01-03 21:38 ` Akira Kyle 0 siblings, 1 reply; 21+ messages in thread From: Aiko Kyle @ 2022-01-02 6:36 UTC (permalink / raw) To: Leo Famulari; +Cc: 52943 On Sat, Jan 1, 2022 at 9:51 PM Leo Famulari <leo@famulari.name> wrote: > > Thanks, and I've attached a graph of the same operating system > declaration from the same revision of Guix but for x86_64, along with > rendered images of both graphs. > > The graphs clearly show that xorg-server is provided in two places on > aarch64. The question is why? Thanks Leo for the help on IRC! What we seem to have figured out is that commit 49599fab56 is almost certainly the culprit. So the issue is that somehow using sddm-service-type in %desktop-services on aarch64 instead of gdm-service-type which is used an x86_64 after that commit results in xorg-server-service-type being included twice, likely though gdm-service-type still being included somewhere. set-xorg-configuration is a potential culprit, although so far I haven't' been able to make the test pass by modifying the call to set-xorg-configuration in desktop.tmpl to explicitly pass sddm-service-type. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-02 6:36 ` Aiko Kyle @ 2022-01-03 21:38 ` Akira Kyle 2022-01-04 1:13 ` Akira Kyle 0 siblings, 1 reply; 21+ messages in thread From: Akira Kyle @ 2022-01-03 21:38 UTC (permalink / raw) To: Leo Famulari; +Cc: 52943 [-- Attachment #1: Type: text/plain, Size: 121 bytes --] The attached patch fixes the failing guix-system.sh test on aarch64. However there are now other tests that are failing. [-- Attachment #2: 0001-tests-guix-system-Fix-on-non-x86_64-systems.patch --] [-- Type: application/octet-stream, Size: 2913 bytes --] From e2a6d4c4043a1e149a5eb99343fc6049ba2778bb Mon Sep 17 00:00:00 2001 From: Akira Kyle <akira@akirakyle.com> Date: Mon, 3 Jan 2022 14:23:46 -0700 Subject: [PATCH] tests: guix-system: Fix on non-x86_64 systems Addresses issue 52943 caused by commit 49599fab56 * gnu/system/examples/desktop.tmpl: explicitly set optional login-manager-service-type argument * gnu/system/examples/vm-image.tmpl: also remove sddm-service-type from %desktop-services --- gnu/system/examples/desktop.tmpl | 12 +++++++++--- gnu/system/examples/vm-image.tmpl | 3 ++- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/gnu/system/examples/desktop.tmpl b/gnu/system/examples/desktop.tmpl index a209fbcb05..aec0466cb6 100644 --- a/gnu/system/examples/desktop.tmpl +++ b/gnu/system/examples/desktop.tmpl @@ -2,8 +2,8 @@ ;; for a "desktop" setup with GNOME and Xfce where the ;; root partition is encrypted with LUKS, and a swap file. -(use-modules (gnu) (gnu system nss)) -(use-service-modules desktop xorg) +(use-modules (gnu) (gnu system nss) (guix utils)) +(use-service-modules desktop xorg sddm) (use-package-modules certs gnome) (operating-system @@ -78,7 +78,13 @@ (service xfce-desktop-service-type) (set-xorg-configuration (xorg-configuration - (keyboard-layout keyboard-layout)))) + (keyboard-layout keyboard-layout)) + ;; See comment in desktop-services-for-system + (if (string-prefix? "x86_64" + (or (%current-target-system) + (%current-system))) + gdm-service-type + sddm-service-type))) %desktop-services)) ;; Allow resolution of '.local' host names with mDNS. diff --git a/gnu/system/examples/vm-image.tmpl b/gnu/system/examples/vm-image.tmpl index a59d91587b..bd9b6b8402 100644 --- a/gnu/system/examples/vm-image.tmpl +++ b/gnu/system/examples/vm-image.tmpl @@ -5,7 +5,7 @@ ;; (use-modules (gnu) (guix) (srfi srfi-1)) -(use-service-modules desktop mcron networking spice ssh xorg) +(use-service-modules desktop mcron networking spice ssh xorg sddm) (use-package-modules bootloaders certs fonts nvi package-management wget xorg) @@ -113,6 +113,7 @@ root ALL=(ALL) ALL (let ((type (service-kind service))) (or (memq type (list gdm-service-type + sddm-service-type wpa-supplicant-service-type cups-pk-helper-service-type network-manager-service-type -- 2.34.0 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-03 21:38 ` Akira Kyle @ 2022-01-04 1:13 ` Akira Kyle 2022-01-04 1:16 ` Akira Kyle 0 siblings, 1 reply; 21+ messages in thread From: Akira Kyle @ 2022-01-04 1:13 UTC (permalink / raw) To: Leo Famulari; +Cc: 52943 [-- Attachment #1: Type: text/plain, Size: 94 bytes --] Attached is the current log file for the test suite on commit 92faad0 with the patch applied. [-- Attachment #2: test-suite.log --] [-- Type: application/octet-stream, Size: 2676666 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-04 1:13 ` Akira Kyle @ 2022-01-04 1:16 ` Akira Kyle 0 siblings, 0 replies; 21+ messages in thread From: Akira Kyle @ 2022-01-04 1:16 UTC (permalink / raw) To: Leo Famulari; +Cc: 52943 Some of these failing tests have been reported on guix-devel already: https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00158.html On Mon, Jan 3, 2022 at 6:13 PM Akira Kyle <akira@akirakyle.com> wrote: > > Attached is the current log file for the test suite on commit 92faad0 > with the patch applied. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-01 23:54 bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 Aiko Kyle 2022-01-02 2:13 ` Leo Famulari @ 2022-01-09 4:39 ` Chris Marusich 2022-01-15 13:27 ` Pierre Langlois 1 sibling, 1 reply; 21+ messages in thread From: Chris Marusich @ 2022-01-09 4:39 UTC (permalink / raw) To: Aiko Kyle; +Cc: 52943 [-- Attachment #1: Type: text/plain, Size: 19397 bytes --] Aiko Kyle <aikokyle@gmail.com> writes: > On the latest master I can run 'guix pull', and the latest guix seems > to build just fine, however when I go to do 'guix system reconfigure', > building guix fails the check phase. Aiko has reported that the fix for 52908 did indeed fix the "tests/guix-system.sh" problem on aarch64-linux. This means the "service 'xorg-server' provided more than once" error has been fixed. However, fixing that issue has revealed another. Aiko said: > guix system reconfigure is still failing for me on aarch64 due to the > test 'file-needed/recursive' in tests/gremlin.scm failing. So the current status is that Aiko still can't do "guix reconfigure" on master after running "guix pull". For this reason, I have re-opened this bug and unmerged it from 52908, since it's not exactly the same issue any more. At the moment, the file-needed/recursive bug that is preventing Aiko from running "guix reconfigure" appears to be specific to aarch64-linux. The problem was reported on guix-devel here: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00019.html Pierre Langlois did some investigation and found this information, posted in the email thread above: > I've also been trying to fix this test but without much luck. It > does look similar to this issue for ppc64 [0], where the `ldd/ld.so' > beaviour isn't the same as what the gremlin guile module does. However > the patch proposed there isn't fixing the issue for me either on > aarch64. > > [0]: https://issues.guix.gnu.org/52940, > > Maybe we can compare notes and a solution will come up :-). So the test > fails because 'truth', the result from `ldd', has ld-linux-aarch64.so > listed while 'needed', from the gremlin guile module doesn't: > > --8<---------------cut here---------------start------------->8--- > (truth ;; result from `ldd libguile.so' > ("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1" > "/gnu/store/...-glibc-2.33/lib/ld-linux-aarch64.so.1" ;; This isn't > ;; in gremlins > "/gnu/store/...-glibc-2.33/lib/libc.so.6" > "/gnu/store/...-glibc-2.33/lib/libcrypt.so.1" > "/gnu/store/...-glibc-2.33/lib/libdl.so.2" > "/gnu/store/...-glibc-2.33/lib/libm.so.6" > "/gnu/store/...-glibc-2.33/lib/libpthread.so.0" > "/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1" > "/gnu/store/...-libffi-3.3/lib/libffi.so.7" > "/gnu/store/...-libgc-8.0.4/lib/libgc.so.1" > "/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2")) > > (needed ;; result from gremlin > ("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1" > "/gnu/store/...-glibc-2.33/lib/libc.so.6" > "/gnu/store/...-glibc-2.33/lib/libcrypt.so.1" > "/gnu/store/...-glibc-2.33/lib/libdl.so.2" > "/gnu/store/...-glibc-2.33/lib/libm.so.6" > "/gnu/store/...-glibc-2.33/lib/libpthread.so.0" > "/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1" > "/gnu/store/...-libffi-3.3/lib/libffi.so.7" > "/gnu/store/...-libgc-8.0.4/lib/libgc.so.1" > "/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2")) > --8<---------------cut here---------------end--------------->8--- > > Digging a bit more I started comparing x86_64 and aarch64 binaries and > noticed that libguile.so didn't have the same dynamic section: > > --8<---------------cut here---------------start------------->8--- > # On aarch64: > $ objdump -x > /gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0 > > > > /gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0: > file format elf64-littleaarch64 > ... > Dynamic Section: > > NEEDED libgc.so.1 > > NEEDED libpthread.so.0 > > NEEDED libffi.so.7 > > NEEDED libunistring.so.2 > > NEEDED libcrypt.so.1 > > NEEDED libdl.so.2 > > NEEDED libm.so.6 > > NEEDED libgcc_s.so.1 > > NEEDED libc.so.6 > > SONAME libguile-3.0.so.1 > ... > > # On x86_64: > $ objdump -x > /gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-3.0.7/lib/libguile-3.0.so.1.4.0 > > /gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-3.0.7/lib/libguile-3.0.so.1.4.0: > file format elf64-x86-64 > ... > Dynamic Section: > NEEDED libgc.so.1 > NEEDED libpthread.so.0 > NEEDED libffi.so.7 > NEEDED libunistring.so.2 > NEEDED libcrypt.so.1 > NEEDED libdl.so.2 > NEEDED libm.so.6 > NEEDED libgcc_s.so.1 > NEEDED libc.so.6 > NEEDED ld-linux-x86-64.so.2 # ld-linux-<arch>.so is here > SONAME libguile-3.0.so.1 > ... > --8<---------------cut here---------------end--------------->8--- > > On aarch64, ld-linux-<arch> is missing. I'm not sure if this is an > issue with our aarch64 port or if that's OK. It's interesting though > that if you run `ldd' on libguile on aarch64, the dynamic linker is > added to the list, even though it's not in the dynamic section: > > --8<---------------cut here---------------start------------->8--- > # On aarch64 > $ ldd > /gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0 > linux-vdso.so.1 (0x0000ffff96fab000) > libgc.so.1 => > /gnu/store/1gkpbfxjx2sbchjhf19yjm4a8vkir0nm-libgc-8.0.4/lib/libgc.so.1 > (0x0000ffff96d88000) > libpthread.so.0 => > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libpthread.so.0 > (0x0000ffff96d59000) > libffi.so.7 => > /gnu/store/hjirgm7pwmc2biqz6d0fc1ajr3ha4v14-libffi-3.3/lib/libffi.so.7 > (0x0000ffff96d40000) > libunistring.so.2 => > /gnu/store/4k552fq1p6q73mr9ww7g5y3m77p7cfbm-libunistring-0.9.10/lib/libunistring.so.2 > (0x0000ffff96bb4000) > libcrypt.so.1 => > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libcrypt.so.1 > (0x0000ffff96b6d000) > libdl.so.2 => > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libdl.so.2 > (0x0000ffff96b59000) > libm.so.6 => > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libm.so.6 > (0x0000ffff96ab0000) > libgcc_s.so.1 => > /gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/libgcc_s.so.1 > (0x0000ffff96a8b000) > libc.so.6 => > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libc.so.6 > (0x0000ffff96917000) > > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/ld-linux-aarch64.so.1 > (0x0000ffff96f79000) > # ^ > --8<---------------cut here---------------end--------------->8--- > > We could adapt the test to add the dynamic linker, emulating `ldd', but > I'm curious if anybody deeply familiar with ELF and dynamic linking > might have an idea what's going on. To summarize, this seems to be the problem: On aarch64-linux, when an ELF file's dynamic section does not contain a NEEDED entry for ld-linux-aarch64.so.1, file-needed/recursive dutifully omits that entry, but ldd prints it (even though it is actually missing from the file's dynamic section). This causes the file-needed/recursive test in tests/gremlin.scm to fail because the set of entries returned by file-needed/recursive differs from the set of entries returned by ldd. Although this may sound similar to 52940, it is different. Bug 52940 was an issue where, when an ELF file's dynamic section contains two entries in RUNPATH that are different strings but refer to the same directory (which does happen on powerpc64le-linux), it causes file-needed/recursive to include in its result two entries that are different strings but refer to the same file. We decided that such redundant entries are probably benign, so we resolved 52940 by changing the test to compare entries by file equality, rather than string equality. However, this is not the same issue as described by Aiko and Pierre above, so it makes sense that the fix for 52940 did not fix the test for aarch64-linux. So, the separate aarch64-linux problem with file-needed/recursive persists. For comparison, on powerpc64le-linux, when an ELF file's dynamic section does not contain a NEEDED entry for "ld64.so.2" (I believe this is the powerpc64le-linux equivalent of ld-linux-aarch64.so.1), both ldd and file-needed/recursive include ld64.so.2, despite the fact that there is no actual NEEDED entry for it in the ELF file. Here is what I see on a powerpc64le-linux system: --8<---------------cut here---------------start------------->8--- marusich@suzaku ~/guix-master [env]$ type -P guile /gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/guile marusich@suzaku ~/guix-master [env]$ type -P ldd /gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/ldd marusich@suzaku ~/guix-master [env]$ ldd /gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/guile linux-vdso64.so.1 (0x00007fff89220000) libguile-3.0.so.1 => /gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1 (0x00007fff89050000) libgc.so.1 => /gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib/libgc.so.1 (0x00007fff88fb0000) libpthread.so.0 => /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libpthread.so.0 (0x00007fff88f60000) libffi.so.7 => /gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib/libffi.so.7 (0x00007fff88f30000) libunistring.so.2 => /gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistring-0.9.10/lib/libunistring.so.2 (0x00007fff88d80000) libcrypt.so.1 => /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libcrypt.so.1 (0x00007fff88d30000) libdl.so.2 => /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libdl.so.2 (0x00007fff88d00000) libm.so.6 => /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libm.so.6 (0x00007fff88bb0000) libgcc_s.so.1 => /gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x00007fff88b70000) libc.so.6 => /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libc.so.6 (0x00007fff88950000) /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/ld64.so.2 (0x00007fff89240000) marusich@suzaku ~/guix-master [env]$ readelf -d /gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/guile Dynamic section at offset 0xfc60 contains 37 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libguile-3.0.so.1] 0x0000000000000001 (NEEDED) Shared library: [libgc.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libffi.so.7] 0x0000000000000001 (NEEDED) Shared library: [libunistring.so.2] 0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000001d (RUNPATH) Library runpath: [/gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib:/gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib:/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib:/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistring-0.9.10/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib:/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib:/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib/gcc/powerpc64le-unknown-linux-gnu/10.3.0/../../../../lib] 0x000000000000000c (INIT) 0x100009e0 0x000000000000000d (FINI) 0x10000f30 0x0000000000000019 (INIT_ARRAY) 0x1001fc50 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x1001fc58 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x0000000000000004 (HASH) 0x100002a0 0x000000006ffffef5 (GNU_HASH) 0x100002f8 0x0000000000000005 (STRTAB) 0x100004a8 0x0000000000000006 (SYMTAB) 0x10000328 0x000000000000000a (STRSZ) 894 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x10020000 0x0000000000000002 (PLTRELSZ) 216 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x100008e8 0x0000000070000000 (PPC64_GLINK) 0x10000eec 0x0000000070000003 (PPC64_OPT) 0x0 0x0000000000000007 (RELA) 0x10000888 0x0000000000000008 (RELASZ) 96 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x10000848 0x000000006fffffff (VERNEEDNUM) 2 0x000000006ffffff0 (VERSYM) 0x10000826 0x0000000000000000 (NULL) 0x0 marusich@suzaku ~/guix-master [env]$ ./pre-inst-env guix repl GNU Guile 3.0.7 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guix-user)> ,use (guix build gremlin) scheme@(guix-user)> ,pp (file-needed/recursive "/gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/guile") $1 = ("/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libc.so.6" "/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib/libgcc_s.so.1" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libm.so.6" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libdl.so.2" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libcrypt.so.1" "/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistring-0.9.10/lib/libunistring.so.2" "/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib/libffi.so.7" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libpthread.so.0" "/gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib/libgc.so.1" "/gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/ld64.so.2" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib/libc.so.6") $2 = ("ld64.so.2") scheme@(guix-user)> --8<---------------cut here---------------end--------------->8--- I don't know if it's related, but I just noticed this: it's a little strange that in the above output (for powerpc64le-linux), ld64.so.2 is included in the second value ($2). This is supposedly the list of .so file names that could not be found. It's strange that ld64.so.2 shows up in $2 because it seems to contradict the fact that it is included in $1, which is the list of files that were found successfully. Since Pierre shared information about the libguile shared object specifically, I'll do the same here. On powerpc64le-linux, the "ld64.so.2" entry is present in the dynamic section of the /gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1 ELF file: --8<---------------cut here---------------start------------->8--- marusich@suzaku ~/guix-master [env]$ readelf -d /gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1| grep -e NEEDED -e RUNPATH 0x0000000000000001 (NEEDED) Shared library: [libgc.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libffi.so.7] 0x0000000000000001 (NEEDED) Shared library: [libunistring.so.2] 0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld64.so.2] 0x000000000000001d (RUNPATH) Library runpath: [/gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib:/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib:/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistr ing-0.9.10/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib:/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib:/gnu/store/l0hnwrv8ma03shjg84a03s05 wmj7a0sk-gcc-10.3.0-lib/lib/gcc/powerpc64le-unknown-linux-gnu/10.3.0/../../../../lib] --8<---------------cut here---------------end--------------->8--- Maybe this information can help somehow. It seems fishy that on aarch64-linux, there is no NEEDED entry for ld-linux-aarch64.so.1 in the ELF files under consideration. As shown above, a similar entry DOES exist on both x86_64-linux and powerpc64le-linux. For this reason, it seems plausible that maybe the missing NEEDED entry is bad. However, I don't really know enough to say whether it's indicative of a problem with our aarch64-linux port. Is there an aarch64-linux or ELF expert in the room who can help? :-) It also seems fishy that, on powerpc64le-linux, file-needed/recursive apparently resolves ld64.so.2 successfully, even though it simultaneously includes it in the "failed to resolve" list. Confusing as that is to me, I don't know if that's really related to the aarch64-linux issue. More investigation is needed... -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-09 4:39 ` Chris Marusich @ 2022-01-15 13:27 ` Pierre Langlois 2022-01-16 1:00 ` Chris Marusich 0 siblings, 1 reply; 21+ messages in thread From: Pierre Langlois @ 2022-01-15 13:27 UTC (permalink / raw) To: Chris Marusich; +Cc: aikokyle, 52943 [-- Attachment #1.1: Type: text/plain, Size: 1548 bytes --] Hi Chris, Chris Marusich <cmmarusich@gmail.com> writes: (snip) > It seems fishy that on aarch64-linux, there is no NEEDED entry for > ld-linux-aarch64.so.1 in the ELF files under consideration. As shown > above, a similar entry DOES exist on both x86_64-linux and > powerpc64le-linux. For this reason, it seems plausible that maybe the > missing NEEDED entry is bad. However, I don't really know enough to say > whether it's indicative of a problem with our aarch64-linux port. Is > there an aarch64-linux or ELF expert in the room who can help? :-) > > It also seems fishy that, on powerpc64le-linux, file-needed/recursive > apparently resolves ld64.so.2 successfully, even though it > simultaneously includes it in the "failed to resolve" list. Confusing > as that is to me, I don't know if that's really related to the > aarch64-linux issue. > > More investigation is needed... I'm afraid I don't have any new insight if this is an issue or just working as intended. Given we have a limited bandwidth to address this thoroughly, would it make sense to apply a temporary work-around in the mean time? I'd be good for at least guix to build on aarch64 in the 1.4 release. I have the attached patch in my tree for instance (along with an update of the guix package), and I've not noticed any issues on a rockpro64, running cgit, DHCP and dnsmasq. That's just anecdotal :-), but I'm also thinking if we unblock the guix package then the farm might catch other issues that could help getting to the bottom of this. WDYT? Thanks, Pierre [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 519 bytes --] [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-gremlin-Adjust-test-for-aarch64.patch --] [-- Type: text/x-patch, Size: 1812 bytes --] From cdd2c995b7c03400a9702a6b354655b0584b727c Mon Sep 17 00:00:00 2001 From: Pierre Langlois <pierre.langlois@gmx.com> Date: Wed, 22 Dec 2021 22:02:08 +0000 Subject: [PATCH] gremlin: Adjust test for aarch64. --- tests/gremlin.scm | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/tests/gremlin.scm b/tests/gremlin.scm index 9e0017337a..c9b05ae21a 100644 --- a/tests/gremlin.scm +++ b/tests/gremlin.scm @@ -20,9 +20,11 @@ (define-module (test-gremlin) #:use-module (guix elf) #:use-module (guix tests) - #:use-module ((guix utils) #:select (call-with-temporary-directory)) + #:use-module ((guix utils) #:select (call-with-temporary-directory + target-aarch64?)) #:use-module (guix build utils) #:use-module (guix build gremlin) + #:use-module (gnu packages bootstrap) #:use-module (srfi srfi-1) #:use-module (srfi srfi-26) #:use-module (srfi srfi-34) @@ -99,7 +101,12 @@ (define ground-truth (or (string-prefix? "linux-vdso.so" entry) (string-prefix? "linux-vdso32.so" entry) ;32-bit powerpc (string-prefix? "linux-vdso64.so" entry) ;64-bit powerpc - (string-prefix? "linux-gate.so" entry))) ;i386 + (string-prefix? "linux-gate.so" entry) ;i386 + ;; FIXME: Binaries on aarch64 do not always include the + ;; dynamic linker in their NEEDED section, it's unclear if that's OK, see + ;; ttps://bugs.gnu.org/52943. + (and (target-aarch64?) + (string-contains entry (glibc-dynamic-linker))))) (read-ldd-output pipe))) (and (zero? (close-pipe pipe)) -- 2.34.0 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-15 13:27 ` Pierre Langlois @ 2022-01-16 1:00 ` Chris Marusich 2022-01-17 4:46 ` Chris Marusich 0 siblings, 1 reply; 21+ messages in thread From: Chris Marusich @ 2022-01-16 1:00 UTC (permalink / raw) To: Pierre Langlois; +Cc: Aiko Kyle, 52943 [-- Attachment #1.1: Type: text/plain, Size: 1851 bytes --] Hi Pierre, FYI, it looks like you included bug-guix@gnu.org in the CC list of your last email. If you do that, I believe it will create a new bug report, which may not be what you intended to do. Pierre Langlois <pierre.langlois@gmx.com> writes: > I'm afraid I don't have any new insight if this is an issue or just > working as intended. Given we have a limited bandwidth to address this > thoroughly, would it make sense to apply a temporary work-around in the > mean time? I'd be good for at least guix to build on aarch64 in the 1.4 > release. > > I have the attached patch in my tree for instance (along with an update > of the guix package), and I've not noticed any issues on a rockpro64, > running cgit, DHCP and dnsmasq. That's just anecdotal :-), but I'm also > thinking if we unblock the guix package then the farm might catch other > issues that could help getting to the bottom of this. > > WDYT? I agree with you. That said, I don't personally run any aarch64-linux machines, and I don't plan to investigate the aarch64-linux issue further right now. Although I will defer to anyone who actually runs aarch64-linux and knows better, at the moment to me it seems reasonable to commit a patch like the one you've proposed in order to ensure that the "guix" package builds successfully on that platform for the 1.4.0 release. The fact that you have successfully built and used various pieces of software on aarch64-linux with this patch suggests that maybe the current behavior is OK, after all. I've made some rather trivial modifications to your patch, mainly to make it conform to our required ChangeLog format. If nobody has further comments, I will commit the attached version to master in about 24 hours. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 [-- Attachment #1.2: 0001-tests-Fix-file-needed-recursive-on-aarch64-linux.patch --] [-- Type: text/x-patch, Size: 2394 bytes --] From f502bab1e09276982acfd3ac0c151b241f7aa07d Mon Sep 17 00:00:00 2001 From: Pierre Langlois <pierre.langlois@gmx.com> Date: Wed, 22 Dec 2021 22:02:08 +0000 Subject: [PATCH] tests: Fix file-needed/recursive on aarch64-linux. Fixes: <https://issues.guix.gnu.org/52943>. * tests/gremlin.scm (file-needed/recursive)[ground-truth]: On aarch64-linux, remove the dynamic linker from this list. --- tests/gremlin.scm | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/tests/gremlin.scm b/tests/gremlin.scm index 9e0017337a..3dbb8d3643 100644 --- a/tests/gremlin.scm +++ b/tests/gremlin.scm @@ -1,6 +1,7 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2015, 2018, 2020, 2022 Ludovic Courtès <ludo@gnu.org> ;;; Copyright © 2022 Chris Marusich <cmmarusich@gmail.com> +;;; Copyright © 2022 Pierre Langlois <pierre.langlois@gmx.com> ;;; ;;; This file is part of GNU Guix. ;;; @@ -20,9 +21,11 @@ (define-module (test-gremlin) #:use-module (guix elf) #:use-module (guix tests) - #:use-module ((guix utils) #:select (call-with-temporary-directory)) + #:use-module ((guix utils) #:select (call-with-temporary-directory + target-aarch64?)) #:use-module (guix build utils) #:use-module (guix build gremlin) + #:use-module (gnu packages bootstrap) #:use-module (srfi srfi-1) #:use-module (srfi srfi-26) #:use-module (srfi srfi-34) @@ -99,7 +102,12 @@ (define ground-truth (or (string-prefix? "linux-vdso.so" entry) (string-prefix? "linux-vdso32.so" entry) ;32-bit powerpc (string-prefix? "linux-vdso64.so" entry) ;64-bit powerpc - (string-prefix? "linux-gate.so" entry))) ;i386 + (string-prefix? "linux-gate.so" entry) ;i386 + ;; FIXME: ELF files on aarch64 do not always include a + ;; NEEDED entry for the dynamic linker, and it is unclear + ;; if that is OK. See: https://issues.guix.gnu.org/52943 + (and (target-aarch64?) + (string-contains entry (glibc-dynamic-linker))))) (read-ldd-output pipe))) (and (zero? (close-pipe pipe)) base-commit: 172bd0b5cde2609389fd16d18862b5b612c4b000 -- 2.33.1 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] ^ permalink raw reply related [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-16 1:00 ` Chris Marusich @ 2022-01-17 4:46 ` Chris Marusich 2022-01-17 18:51 ` Pierre Langlois 0 siblings, 1 reply; 21+ messages in thread From: Chris Marusich @ 2022-01-17 4:46 UTC (permalink / raw) To: Pierre Langlois; +Cc: Aiko Kyle, 52943 [-- Attachment #1: Type: text/plain, Size: 743 bytes --] Hi, Chris Marusich <cmmarusich@gmail.com> writes: > If nobody has further comments, I will commit the attached version to > master in about 24 hours. I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We still need to update the "guix" package, so even if you run "guix pull" right now, you won't be able to successfully build "guix" after pulling on aarch64-linux yet. I will coordinate with the other people who are helping to make the 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. See this guix-devel email thread for details: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-17 4:46 ` Chris Marusich @ 2022-01-17 18:51 ` Pierre Langlois 2022-01-18 5:33 ` Vagrant Cascadian 0 siblings, 1 reply; 21+ messages in thread From: Pierre Langlois @ 2022-01-17 18:51 UTC (permalink / raw) To: Chris Marusich; +Cc: Aiko Kyle, 52943 [-- Attachment #1: Type: text/plain, Size: 793 bytes --] Hi, Chris Marusich <cmmarusich@gmail.com> writes: > [[PGP Signed Part:Undecided]] > Hi, > > Chris Marusich <cmmarusich@gmail.com> writes: > >> If nobody has further comments, I will commit the attached version to >> master in about 24 hours. > > I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We > still need to update the "guix" package, so even if you run "guix pull" > right now, you won't be able to successfully build "guix" after pulling > on aarch64-linux yet. > > I will coordinate with the other people who are helping to make the > 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. > See this guix-devel email thread for details: > > https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html That's awesome, thank you! Pierre [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 519 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-17 18:51 ` Pierre Langlois @ 2022-01-18 5:33 ` Vagrant Cascadian 2022-01-19 19:28 ` Vagrant Cascadian 0 siblings, 1 reply; 21+ messages in thread From: Vagrant Cascadian @ 2022-01-18 5:33 UTC (permalink / raw) To: Pierre Langlois, Chris Marusich; +Cc: Aiko Kyle, 52943 [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] On 2022-01-17, Pierre Langlois wrote: > Chris Marusich <cmmarusich@gmail.com> writes: >> Chris Marusich <cmmarusich@gmail.com> writes: >>> If nobody has further comments, I will commit the attached version to >>> master in about 24 hours. >> >> I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We >> still need to update the "guix" package, so even if you run "guix pull" >> right now, you won't be able to successfully build "guix" after pulling >> on aarch64-linux yet. >> >> I will coordinate with the other people who are helping to make the >> 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. >> See this guix-devel email thread for details: >> >> https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html > > That's awesome, thank you! FWIW, I can also confirm that updating the "guix" package to a version that contains 24c3485bb3ffc05e687ef6513ac287b8d3048bab allows the "guix" package (which contains the fairly important "guix-daemon"), to build again. Thanks for getting it that far! Haven't been able to upgrade my aarch64 systems without local patches for over a month now... glad to see a fix is *almost* ready! Is there anything in particular holding back upating the guix package (other than the huge amount of big merges in progress, release preparation, etc. and etc.)? Thanks everyone! live well, vagrant [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-18 5:33 ` Vagrant Cascadian @ 2022-01-19 19:28 ` Vagrant Cascadian 2022-01-29 18:33 ` Leo Famulari 0 siblings, 1 reply; 21+ messages in thread From: Vagrant Cascadian @ 2022-01-19 19:28 UTC (permalink / raw) To: Pierre Langlois, Chris Marusich; +Cc: Aiko Kyle, 52943-done [-- Attachment #1: Type: text/plain, Size: 1688 bytes --] On 2022-01-17, Vagrant Cascadian wrote: > On 2022-01-17, Pierre Langlois wrote: >> Chris Marusich <cmmarusich@gmail.com> writes: >>> Chris Marusich <cmmarusich@gmail.com> writes: > >>>> If nobody has further comments, I will commit the attached version to >>>> master in about 24 hours. >>> >>> I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We >>> still need to update the "guix" package, so even if you run "guix pull" >>> right now, you won't be able to successfully build "guix" after pulling >>> on aarch64-linux yet. >>> >>> I will coordinate with the other people who are helping to make the >>> 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. >>> See this guix-devel email thread for details: >>> >>> https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html >> >> That's awesome, thank you! > > FWIW, I can also confirm that updating the "guix" package to a version > that contains 24c3485bb3ffc05e687ef6513ac287b8d3048bab allows the "guix" > package (which contains the fairly important "guix-daemon"), to build > again. Thanks for getting it that far! > > Haven't been able to upgrade my aarch64 systems without local patches > for over a month now... glad to see a fix is *almost* ready! > > Is there anything in particular holding back upating the guix package > (other than the huge amount of big merges in progress, release > preparation, etc. and etc.)? I went ahead and pushed to master: f758ede583ef9662963873750206540f58ff3c45 gnu: guix: update to 1.3.0-22.24c3485. I tried building a newer version, but there were new test suite failures on both aarch64 and x86_64 :/ Happy aarch64ing! live well, vagrant [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-19 19:28 ` Vagrant Cascadian @ 2022-01-29 18:33 ` Leo Famulari 2022-01-29 20:54 ` Pierre Langlois 2022-10-07 8:48 ` Christopher Baines 0 siblings, 2 replies; 21+ messages in thread From: Leo Famulari @ 2022-01-29 18:33 UTC (permalink / raw) To: 52943, vagrant, aikokyle On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote: > I tried building a newer version, but there were new test suite failures > on both aarch64 and x86_64 :/ Since the 'guix' package still does not build on aarch64, I'm reopening this bug. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-29 18:33 ` Leo Famulari @ 2022-01-29 20:54 ` Pierre Langlois 2022-01-29 21:06 ` Leo Famulari 2022-10-07 8:48 ` Christopher Baines 1 sibling, 1 reply; 21+ messages in thread From: Pierre Langlois @ 2022-01-29 20:54 UTC (permalink / raw) To: Leo Famulari; +Cc: vagrant, aikokyle, 52943 [-- Attachment #1: Type: text/plain, Size: 588 bytes --] Hi Leo, Leo Famulari <leo@famulari.name> writes: > On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote: >> I tried building a newer version, but there were new test suite failures >> on both aarch64 and x86_64 :/ > > Since the 'guix' package still does not build on aarch64, I'm reopening > this bug. Oh it doesn't? What hash are you on? I'm currently on b14a1cdef571c0901f716f4e752a97e8028ccbbd on a RockPro64 and it's working OK, maybe something changed since then although this hash isn't very old. I see the farm does not have any substitutes yet. Thanks, Pierre [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 519 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-29 20:54 ` Pierre Langlois @ 2022-01-29 21:06 ` Leo Famulari 2022-01-29 21:35 ` Pierre Langlois 0 siblings, 1 reply; 21+ messages in thread From: Leo Famulari @ 2022-01-29 21:06 UTC (permalink / raw) To: Pierre Langlois; +Cc: vagrant, aikokyle, 52943 On Sat, Jan 29, 2022 at 08:54:24PM +0000, Pierre Langlois wrote: > > Since the 'guix' package still does not build on aarch64, I'm reopening > > this bug. > > Oh it doesn't? What hash are you on? I'm not using aarch64, so I can't give a commit hash. I am observing the build farm's support for aarch64. > I'm currently on b14a1cdef571c0901f716f4e752a97e8028ccbbd on a RockPro64 > and it's working OK, maybe something changed since then although this > hash isn't very old. I see the farm does not have any substitutes yet. As you point out, the build farm cannot build it: https://ci.guix.gnu.org/search?query=spec%3Amaster+system%3Aaarch64-linux+guix-1.3.0 Maybe it's a problem with in the 'guix' package, maybe in the some other package. But the effect for users is the same, and they report things like this: https://issues.guix.gnu.org/53616 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-29 21:06 ` Leo Famulari @ 2022-01-29 21:35 ` Pierre Langlois 0 siblings, 0 replies; 21+ messages in thread From: Pierre Langlois @ 2022-01-29 21:35 UTC (permalink / raw) To: Leo Famulari; +Cc: vagrant, aikokyle, 52943 [-- Attachment #1: Type: text/plain, Size: 1412 bytes --] Leo Famulari <leo@famulari.name> writes: > On Sat, Jan 29, 2022 at 08:54:24PM +0000, Pierre Langlois wrote: >> > Since the 'guix' package still does not build on aarch64, I'm reopening >> > this bug. >> >> Oh it doesn't? What hash are you on? > > I'm not using aarch64, so I can't give a commit hash. I am observing the > build farm's support for aarch64. > >> I'm currently on b14a1cdef571c0901f716f4e752a97e8028ccbbd on a RockPro64 >> and it's working OK, maybe something changed since then although this >> hash isn't very old. I see the farm does not have any substitutes yet. > > As you point out, the build farm cannot build it: > > https://ci.guix.gnu.org/search?query=spec%3Amaster+system%3Aaarch64-linux+guix-1.3.0 > > Maybe it's a problem with in the 'guix' package, maybe in the some other > package. But the effect for users is the same, and they report things > like this: > > https://issues.guix.gnu.org/53616 Oh I see, I'm not familiar with how the infra works, but it looks like aarch64 jobs aren't currently scheduled at all: https://ci.guix.gnu.org/build/337714/details Maybe we could restart it and see if we can reproduce the problem? I wonder if there's a good reason for jobs not being scheduled, I saw recent commits regarding new aarch64 HW being set up. I'll be happy to help debug build issues when we know more of course! Thanks, Pierre [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 519 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-01-29 18:33 ` Leo Famulari 2022-01-29 20:54 ` Pierre Langlois @ 2022-10-07 8:48 ` Christopher Baines 2022-10-20 14:57 ` Mathieu Othacehe 1 sibling, 1 reply; 21+ messages in thread From: Christopher Baines @ 2022-10-07 8:48 UTC (permalink / raw) To: Leo Famulari; +Cc: vagrant, aikokyle, 52943 [-- Attachment #1: Type: text/plain, Size: 676 bytes --] Leo Famulari <leo@famulari.name> writes: > On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote: >> I tried building a newer version, but there were new test suite failures >> on both aarch64 and x86_64 :/ > > Since the 'guix' package still does not build on aarch64, I'm reopening > this bug. It looks to me that there were problems with the guix package on aarch64-linux, but it's working currently. 1: https://data.guix.gnu.org/repository/1/branch/master/package/guix/output-history?output=out&system=aarch64-linux&target=none Also, substitute availability for aarch64-linux and armhf-linux is OK. Does that mean this issue can be closed? Thanks, Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 2022-10-07 8:48 ` Christopher Baines @ 2022-10-20 14:57 ` Mathieu Othacehe 0 siblings, 0 replies; 21+ messages in thread From: Mathieu Othacehe @ 2022-10-20 14:57 UTC (permalink / raw) To: Christopher Baines; +Cc: vagrant, aikokyle, 52943-done, Leo Famulari Hello, > Also, substitute availability for aarch64-linux and armhf-linux is > OK. Does that mean this issue can be closed? The guix package for armhf-linux is not built anymore by ci.guix.gnu.org, but guix for aarch64-linux seems to be working. Closing, Thanks, Mathieu ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2022-10-20 15:05 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-01-01 23:54 bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 Aiko Kyle 2022-01-02 2:13 ` Leo Famulari 2022-01-02 4:11 ` Aiko Kyle 2022-01-02 4:51 ` Leo Famulari 2022-01-02 6:36 ` Aiko Kyle 2022-01-03 21:38 ` Akira Kyle 2022-01-04 1:13 ` Akira Kyle 2022-01-04 1:16 ` Akira Kyle 2022-01-09 4:39 ` Chris Marusich 2022-01-15 13:27 ` Pierre Langlois 2022-01-16 1:00 ` Chris Marusich 2022-01-17 4:46 ` Chris Marusich 2022-01-17 18:51 ` Pierre Langlois 2022-01-18 5:33 ` Vagrant Cascadian 2022-01-19 19:28 ` Vagrant Cascadian 2022-01-29 18:33 ` Leo Famulari 2022-01-29 20:54 ` Pierre Langlois 2022-01-29 21:06 ` Leo Famulari 2022-01-29 21:35 ` Pierre Langlois 2022-10-07 8:48 ` Christopher Baines 2022-10-20 14:57 ` Mathieu Othacehe
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
![[-- Attachment #3: graph-x86_64.png --] [-- Type: image/png, Size: 674730 bytes --]](../../YdEvVvT7k01JrYA2@jasmine.lan/3-graph-x86_64.png){kind=link}
![[-- Attachment #4: graph-aarch64.png --] [-- Type: image/png, Size: 668336 bytes --]](../../YdEvVvT7k01JrYA2@jasmine.lan/4-graph-aarch64.png){kind=link}