Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

OpenSubmitted by Aiko Kyle.
Details
7 participants
  • Aiko Kyle
  • Akira Kyle
  • Chris Marusich
  • Leo Famulari
  • Ludovic Courtès
  • Pierre Langlois
  • Vagrant Cascadian
Owner
unassigned
Severity
important
Merged with
A
A
Aiko Kyle wrote on 2 Jan 00:54 +0100
(address . bug-guix@gnu.org)
CAPWcbYHjBoqd0vsLOknF7Yk86wUiC5P_ppTguv8G=fziJ=FJeQ@mail.gmail.com
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!
L
L
Leo Famulari wrote on 2 Jan 03:13 +0100
(name . Aiko Kyle)(address . aikokyle@gmail.com)(address . 52943@debbugs.gnu.org)
YdEKYg2eDo2b7b6h@jasmine.lan
On Sat, Jan 01, 2022 at 04:54:51PM -0700, Aiko Kyle wrote:
Toggle quote (18 lines)
> 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
L
L
Leo Famulari wrote on 2 Jan 03:14 +0100
(no subject)
(name . GNU bug tracker automated control server)(address . control@debbugs.gnu.org)
YdEKgAUl76AdwYB5@jasmine.lan
merge 52908 52943
A
A
Aiko Kyle wrote on 2 Jan 05:11 +0100
Re: bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
(name . Leo Famulari)(address . leo@famulari.name)(address . 52943@debbugs.gnu.org)
CAPWcbYEu4hcP6KQq8pumbk5+9uALiKdibR_kJ8KER-kCf9mDug@mail.gmail.com
Attached is the output of guix system shepherd-graph
gnu/system/examples/desktop.tmpl on commit 2a49ddb513
Attachment: graph.dot
L
L
Leo Famulari wrote on 2 Jan 05:51 +0100
(name . Aiko Kyle)(address . aikokyle@gmail.com)(address . 52943@debbugs.gnu.org)
YdEvVvT7k01JrYA2@jasmine.lan
On Sat, Jan 01, 2022 at 09:11:49PM -0700, Aiko Kyle wrote:
Toggle quote (3 lines)
> 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?
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: graph-x86_64.png
Attachment: graph-aarch64.png
A
A
Aiko Kyle wrote on 2 Jan 07:36 +0100
(name . Leo Famulari)(address . leo@famulari.name)(address . 52943@debbugs.gnu.org)
CAPWcbYEjhSWsXR41ivHUZfthUje_i0rc1P8p_8KYqw8ibtjJEg@mail.gmail.com
On Sat, Jan 1, 2022 at 9:51 PM Leo Famulari <leo@famulari.name> wrote:
Toggle quote (8 lines)
>
> 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.
A
A
Akira Kyle wrote on 3 Jan 22:38 +0100
(name . Leo Famulari)(address . leo@famulari.name)(address . 52943@debbugs.gnu.org)
CAPWcbYEUitbYDjfhfwwNJvysUkPmt-RLVjuNvQ=U0hRbBT=jLQ@mail.gmail.com
The attached patch fixes the failing guix-system.sh test on aarch64.
However there are now other tests that are failing.
A
A
Akira Kyle wrote on 4 Jan 02:13 +0100
(name . Leo Famulari)(address . leo@famulari.name)(address . 52943@debbugs.gnu.org)
CAPWcbYHDeB_ebMK6iRd4r3PDZ+v64MQjBvkF0GTbqrQMHiSHdw@mail.gmail.com
Attached is the current log file for the test suite on commit 92faad0
with the patch applied.
Attachment: test-suite.log
A
A
Akira Kyle wrote on 4 Jan 02:16 +0100
(name . Leo Famulari)(address . leo@famulari.name)(address . 52943@debbugs.gnu.org)
CAPWcbYEK0SrJxEa7f6zram8O5zGM_H5eGdHRi=Tf1OnTQMud8w@mail.gmail.com
Some of these failing tests have been reported on guix-devel already:

On Mon, Jan 3, 2022 at 6:13 PM Akira Kyle <akira@akirakyle.com> wrote:
Toggle quote (3 lines)
>
> Attached is the current log file for the test suite on commit 92faad0
> with the patch applied.
C
C
Chris Marusich wrote on 9 Jan 03:40 +0100
(address . control@debbugs.gnu.org)
87wnj9d435.fsf@gmail.com
# Although at first it did seem like 52908 was the sole cause of this
# bug, Aiko reported in 52908 that there are still more problems needing
# resolution. So, this should be regarded as a separate bug, after all.

unmerge 52943
reopen 52943

--
Chris

C
C
Chris Marusich wrote on 9 Jan 05:39 +0100
(name . Aiko Kyle)(address . aikokyle@gmail.com)(address . 52943@debbugs.gnu.org)
87o84lcyk1.fsf@gmail.com
Aiko Kyle <aikokyle@gmail.com> writes:

Toggle quote (4 lines)
> 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:

Toggle quote (3 lines)
> 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:


Pierre Langlois did some investigation and found this information,
posted in the email thread above:

Toggle quote (145 lines)
> 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:

Toggle snippet (85 lines)
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)>

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:

Toggle snippet (16 lines)
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]

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

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHaZw4VHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadp/8P/j8kro3YsstMpEFJu7Dv/Rbpumbq
aaxTxCcUFns9SrL+ixd+nSbJs1Rb1AGAX4VKrFxOOsSyL/tktOZyKBTc+QNGHIaA
wOH4UVY0Oeb9OEoqvO8lGUqEjwVdTZwwL8fuNPAk2MIBiFRTDtUl/cQDeH9241H5
UHR0NmvNETxAj2jCQUmt7KNSu3ZPeCHlXH3BwQKRKn5K1xQvjROI5OWlmhjlr5Wk
3F8cC5nR0Q6JN1/ZKjbu+HFEmrUT+865RtMK5vTXwnip6/g86Hpq7T0EBLXDN0CV
2irJplHKuR95f71w6B3K5rbvfz4ERJ5Hss7q0xIkXGnwOdL6NKJqI9y+na33uWN/
RqI4VCT7Y4XFFOVW8gp0bcpnsiLMyxy7soAbx2AY8+iuP992RWjHxuENDI6E+69h
cUYQD40/7jSmfWweCgTFWdTbo2pDg96vPtDmWdLYo5Qn+Bs+jx5hMDdS/myY/C5L
+4wWGiAVzmTbybbgiqlnpH1mi992kzqRiI02vTV/CXthOXL9X1KC9zz/LO0brS85
lYpSEavC6NV24ijJzU/xOQs++J/Ace+G9Z3Cuiut3pizvy77F+X9dbNhDZtawmQt
qQYl38hsj/rT0ru+s8PsA0grPmk0TlX1WmOvIU83gnqmj78E3fk2WCHU4BvKryMM
hpuzmb90D0ACj1ux
=AYD0
-----END PGP SIGNATURE-----

P
P
Pierre Langlois wrote on 15 Jan 14:27 +0100
(name . Chris Marusich)(address . cmmarusich@gmail.com)
874k65rukb.fsf@gmx.com
Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

(snip)

Toggle quote (16 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQFMBAEBCgA2FiEEctU9gYy29KFyWDdMqPyeRH9PfVQFAmHizYQYHHBpZXJyZS5s
YW5nbG9pc0BnbXguY29tAAoJEKj8nkR/T31URx4IAKl2cp3u2nYF30zh8XXKZkrh
j1rQA3UtxxD4bOIy/PKh3OAlxMDjw0GtRkfwYD1LKZsJenASIVuZFoVARS8eJ+ID
HVX2evHA7KR+uFBRY2cmGPgACHlcbP3H1a5Ol7f8ixqF6Vwxhnf1YSf7fPvXzQgF
/Z9g1wy1oqC3z3T0Kae5NsMmS0IBw1QFUeDTZQUFqvMhUz+Y+bb6P8iYRG7ncrdy
cIOF7dHlnk49sFOV34mwiMhm1vMCVApL2vi6jHK17N6vFEWPU3m919XZMxqfxasK
vqEKlgqYtDe84etrV3BCpu+/zstzRlDQ4T2JyFQErlXd/NHYnigWgd4bv/Bg48E=
=YxyK
-----END PGP SIGNATURE-----

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

Toggle diff (31 lines)
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
C
C
Chris Marusich wrote on 16 Jan 02:00 +0100
(name . Pierre Langlois)(address . pierre.langlois@gmx.com)
87czksa40e.fsf@gmail.com
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:

Toggle quote (14 lines)
> 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

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.


* 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(-)

Toggle diff (43 lines)
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
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHjbjEVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadIXEQALPumHR0mylMOAvw82hjPTxADns9
siUDaQ0rks+oJ9SvVbN92g0lgafmmz7X7dcAhLXvrKBswXxm4QlHcnNxjASj0xdM
RNIGaLKtUhRe8q5pfgVteeonEhlersZABQZPVcDEATicJkPhEyxzPiPd96WzHZ9O
zRbPp7+e1zqlB7o7+SZ1WmSVx/cnME5N2UGqrJhncLY58keGW6Z1R1c9Ps2ghjaf
IzQHdPYdndJI5CiNiv6OjNCrvCYBSh9R8o6rnXp3kel45SJ11DY7+Mn9qtbGa6Ty
Ps6ENU76IYtS6UvuHpDFdr3YrOFp5D35jVTUkez0zIh9LNrhN5D6dCwIJklxpEE5
O2HtFRxeURYjvcOYhHRjUL8EmhI7kr376Ef+8ZR96cphDNCcPCy6n9Z2eiEd+po4
Bjd+8YVwdOTHPmhbgoIA9CpNUeO/b2PBtSitq+WvHFJEbKYdF4oNd+b/cDUuKBp9
MEBdZNtnbzt3+5J8DTPn+US2+C2cp8jTbptB8It03oot3Ij/36nJkvKjD+5a5W7C
AVD32Wt5J1MdnWEhd4bNg/uiqmntrVNYnveACKPUC0qq7QaRmz2RS37ZLgXHkiOc
KeUE6jIblGxIfHx661pn2NWSYu+VzNz7e0G7YlM1a5kynfcTfvw7nEzSvSWbIi+K
rnXoKhihzR7BsgcN
=Gw+A
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 16 Jan 02:02 +0100
(no subject)
(address . control@debbugs.gnu.org)
878rvga3wt.fsf@gmail.com
# "guix" package fails to build on aarch64 on master, thus "guix pull"
# will also fail.
block 53214 by 52943

--
Chris

C
C
Chris Marusich wrote on 17 Jan 05:46 +0100
Re: bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
(name . Pierre Langlois)(address . pierre.langlois@gmx.com)
87y23f7yw1.fsf@gmail.com
Hi,

Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (3 lines)
> 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:


--
Chris

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHk9J4VHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadReAQAMen8SpTJW7xJyrdLazkYmyAGH1c
GtzNb9ZP5pdc1kdB4tb7JF10Bq7hPpzRyd9vvis2rdCZpSpModA9S1b7SGHLZnFb
VGOU7PHa7lLlFnomEnoLoVTyYELTrG8ghia3CZuWHePc1y0AfxVlZst3ycZqXVs3
PkQw+KVetZb0rp+Sz4yTny552wrTWo9XWwDerUx8IRx3/WuRuY222iu/Y02OGuXF
WEGmcN96/nufI24F/zxk6VNCrqzdHqWWbzgRcoZw3bpoh1+mQ5eeTFATze+VgNSm
liU7gfmBRLfKs3cGCMU6GqjoOIeIdfv1u8+Bbm/VgvxvB3ga5SgeLHIPUhjojf1b
IHwIEQIb6qCe2DUvSrMcCH+xVD7PZPfZ59KYpAnj2VeA2ITAaVbKKCoV7OXvwKs8
Ovub2acvCpMHyAZapJCGyaSNTBfGbfAegAsSfUmnkZB9mtZc42ArdTsSUcFg7PbY
aOiUyiO4CGcP73O42Of058FrNfPLh5ITR+v1r88uoo+YJMPnR+PjntIm7IDSSwR2
Eioi6KF85I+qYC6L6v+7F2e/A/BSNaQu0urALvO2qOyfyRxvMA50s6zx/dyaVbQ7
BLFqMeqJLRI3MoK7c7WeokKtoPWnjx1gTE+7VEKgj6o5OrTVusdZc/mi+xj/awaX
xOJlb9eof2xriw3b
=paAY
-----END PGP SIGNATURE-----

P
P
Pierre Langlois wrote on 17 Jan 19:51 +0100
(name . Chris Marusich)(address . cmmarusich@gmail.com)
878rvefb54.fsf@gmx.com
Hi,

Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (19 lines)
> [[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
-----BEGIN PGP SIGNATURE-----

iQFMBAEBCgA2FiEEctU9gYy29KFyWDdMqPyeRH9PfVQFAmHlutcYHHBpZXJyZS5s
YW5nbG9pc0BnbXguY29tAAoJEKj8nkR/T31Uc8oIALXgMAvtkKl4DRRQw7ta2rZE
SpiKlHYQKhugRJzxfUZnQQA93YLXx4eiBJScQMUiu3BzvTplMIzlD/0/RncfSt+E
9U+2FVqqkQnEjqQC4eeeyYn9YlBxV48U6Lfv17p1bRbP9W/ftovNvUGFLdg/kKvV
nWz75dw0zR1xjX2Jo+BnuAV8jtB/oti0FGsO/tyYczXH72bOE4ub0FLcZcvCaYot
0dKCbqXkAv/tna9dik7gQEhuIkgPrt6Hp/ByliZaBYCpCCtyvqcufzv///EZ1rSt
MAIoRH6cqmoEDNtqVE5XTkZKRL3VS7Z9GJS+BtVYdsxo1tyen5slE4Qv4CFDLjs=
=BWuk
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 18 Jan 06:33 +0100
87bl09d2wi.fsf@yucca
On 2022-01-17, Pierre Langlois wrote:
Toggle quote (19 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYeZRDgAKCRDcUY/If5cW
qkRZAQCUce0XWZ6VxG+eGmNA7h6bj5MGJ0VjfTmVdY9hgoWFQwEApzoFpZecnBaM
54+wP5hdHXUuOUhFQ7fwachLllWajAQ=
=iOg/
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 19 Jan 20:28 +0100
87k0eva5k3.fsf@yucca
On 2022-01-17, Vagrant Cascadian wrote:
Toggle quote (32 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYehmXAAKCRDcUY/If5cW
qjknAQC5mqWy3lTzwBCAJgtRXThKl2if9gwiSffnhdCW+V1AlQEAq8KG+P671uaq
t6ueyOG3j/cNVblfBMs+PnircgQPFQs=
=ybvY
-----END PGP SIGNATURE-----

Closed
L
L
Leo Famulari wrote on 29 Jan 19:33 +0100
YfWId5SVaChgck4O@jasmine.lan
On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote:
Toggle quote (3 lines)
> 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.
L
L
Leo Famulari wrote on 29 Jan 19:36 +0100
(no subject)
(address . control@debbugs.gnu.org)
YfWJQ+BQBuvTlSQg@jasmine.lan
merge 53616 52943
P
P
Pierre Langlois wrote on 29 Jan 21:54 +0100
Re: bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
(name . Leo Famulari)(address . leo@famulari.name)
87r18qb6l2.fsf@gmx.com
Hi Leo,

Leo Famulari <leo@famulari.name> writes:

Toggle quote (7 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQFMBAEBCgA2FiEEctU9gYy29KFyWDdMqPyeRH9PfVQFAmH1qukYHHBpZXJyZS5s
YW5nbG9pc0BnbXguY29tAAoJEKj8nkR/T31UUqMH/iWAJkU7JJ6SzxRbN2gzRWOm
AIYXfTqalS7Cgpqig3Uj58qc1rRGqonyL1OTnYviVe9/tyGP6LC+cugIDDt6tB2h
MhRyHYBxDB4ujadHsv0qXqEgcf8OdQI1o65cj8QDmF9NvvrbCG1coELIfzjL/1oY
t9UsZs+LopsjDZ6sUYgc29/u21oj//n9aWjTyF9IbFozKVMNTUR1IlUG1nsW0L8d
OY8SugWQXscyWVdLNKxVrbt9jETRa9srqHFWPf7bsVdtrCFTtQZnyFi73uo+9bXh
Iul4bLSCa+3dR3HPw/D+jNpulJQFmfbCnwFeqVsS6TSPPz3FHeWvX9biYRSxdJw=
=fEug
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 29 Jan 22:06 +0100
(name . Pierre Langlois)(address . pierre.langlois@gmx.com)
YfWsUoWtOhMDlLm9@jasmine.lan
On Sat, Jan 29, 2022 at 08:54:24PM +0000, Pierre Langlois wrote:
Toggle quote (5 lines)
> > 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.

Toggle quote (4 lines)
> 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:


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:

P
P
Pierre Langlois wrote on 29 Jan 22:35 +0100
(name . Leo Famulari)(address . leo@famulari.name)
87zgne9q2g.fsf@gmx.com
Leo Famulari <leo@famulari.name> writes:

Toggle quote (23 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQFMBAEBCgA2FiEEctU9gYy29KFyWDdMqPyeRH9PfVQFAmH1tMcYHHBpZXJyZS5s
YW5nbG9pc0BnbXguY29tAAoJEKj8nkR/T31U0mYH/3sAnQFh2E8C5SsMMVMznYY+
3DKsUlBeiX3bIOQ2j25x7c2e8x1eNjlB9c7fwhWma7TtFfNy+07ALkeD5jTYfrel
bxTnQJh0HXi3gY/IOgyyst+W1p946Jk97DB/Mfgan6gw6ENFuzl9SNMo9H3frOhn
4E2fFpOoGhvHEcutcaSw2hjGlZ0XnjOcoVhmyMj+FDPjjVDI2VDomNWd+8RYy5OJ
z+QsyY62cTkdT0fwhZtmC5iUbaJDc86vlEdlwagENw6jIV6eYN/KAjHR7t/OOLlV
6ZR0TTkqegKK5UQaQ+PkGsofa0OpTXOeEl3jkN5Pwgwz9iaMSbvACCFa8XDh8JE=
=mEIb
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 1 Feb 09:21 +0100
control message for bug #52943
(address . control@debbugs.gnu.org)
875ypz80b0.fsf@gnu.org
severity 52943 important
quit
?