GNU bug report logs - #77709
Restoring the Hurd on core-packages-team branch

Previous Next

To reply to this bug, email your comments to 77709 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: bug-guix <at> gnu.org
Subject: Restoring the Hurd on core-packages-team branch
Date: Thu, 10 Apr 2025 16:55:15 +0200 (CEST)

Hello,


Here are all of the things I had to do to restore the (32bit) Hurd on core-packages-team branch


- gnumach incompatible with automake <at> 1.17

Our current gnumach does not build with automake <at> 1.17. This got fixed for gnumach and gnumach-headers in hurd.scm by using automake <at> 1.16.5 but not in commencement.scm.


Probably the better solution is to instead refresh hurd/mach and friends to their latest snapshots which includes the fix for automake <at> 1.17

- The same 4 gnulib tests would fail in a lot of packages: coreutils grep libunistring diffutils findutils sed m4 gettext

  As these were fine with glibc <at> 2.40 this seems to be a regression in glibc.
  
* test-once1 and bison segfaulting
Fixed with
https://salsa.debian.org/glibc-team/glibc/-/commit/22f0a9381fe844a5de92a57012833bec225a9686
https://sourceware.org/git/?p=glibc.git;a=commit;h=ccdb68e829a31e4cda8339ea0d2dc3e51fb81ba5

* test-pthread_sigmask1

https://salsa.debian.org/glibc-team/glibc/-/commit/6c823b5862bd91ca757eeb9c6f5326875bc8af01

* test-symlink and test-symlinkat

https://sourceware.org/bugzilla/show_bug.cgi?id=32569
https://sourceware.org/git/?p=glibc.git;a=commit;h=8ef17919509e909746b0ad6465e9c6c952a3fe34 causes

mkdir("dir")
symlink("nowhere", "dir/")

to fail with ENOTDIR (previously it was EINVAL). On Linux it is EEXIST


- The disable-year-2038 configure flag

Some packages (findutils, tar, util-linux [latest coreutils, currently not yet updated]) have a configure time fatal check for 64bit time_t whcih needs to explicitly be disabled if not supported.

This is also relevant for other 32 bit platforms.


- rumpkernel : Implicit function declaration

It fails to build because of gcc14 and -Wimplicitit-function-declaration

there is a newer tag on the debian repo but I struggled to understand the build system.

- Some test failures:

openssl, automake <at> 1.17 and bison

I have not looked into these yet,

- Flaky tests:
tar, curl


It should also be possible to build hurd with a more recent texinfo.


With all of these dealt with I could build all of a slightly modified hurd-manifest (all of these are not new problems and also fail on the master branch).
- Removed  gdk-pixbuf (dbus is failing https://gitlab.freedesktop.org/dbus/dbus/-/commit/5d7b87496f3bb094b926692036ae656c31efdd8e and I havent looked further)
- Removed guix
- Removed patch (it #+ includes gnulib , which fails because of clisp)
- Skipped tests in grep: Triple-backref test fails
- Skipped tests in libgit2: The last one fails
- Skipped tests in guile-fibers: One test hangs
- Skipped tests in shepherd #77634

I hope this helps.

Message #8 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Restoring the Hurd on core-packages-team branch
Date: Fri, 11 Apr 2025 12:00:45 +0200 (CEST)

The symlink test failure is even more complex than I thought.

In 2009 there was a patch to gnulib to accept the incorrect EINVAL errno https://git.savannah.gnu.org/cgit/gnulib.git/commit/tests/test-symlink.h?id=48b0feac54dce2caf46cc53dd160e699737ff52a.
which should never have been passing in the first place. 

And now that this value has changed with glibc-2.41 everything breaks.

Maybe all of these cases in the glibc patch should be EEXIST instead which I think is the behavior on linux (assumption and untested).

I am unsure how to proceed because I don't know who is wrong, gnulib or glibc.

Message #11 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: Restoring the Hurd on core-packages-team branch
Date: Fri, 25 Apr 2025 12:07:21 +0200 (CEST)

This is now fixed in glibc for symlink see 39183b953c68a489cc0b9aefb8974711c834fb38 but should probably be added to glibc/hurd.

Apr 11, 2025, 10:00 by yelninei <at> tutamail.com:

> The symlink test failure is even more complex than I thought.
>
> In 2009 there was a patch to gnulib to accept the incorrect EINVAL errno > https://git.savannah.gnu.org/cgit/gnulib.git/commit/tests/test-symlink.h?id=48b0feac54dce2caf46cc53dd160e699737ff52a> .
> which should never have been passing in the first place.
>
> And now that this value has changed with glibc-2.41 everything breaks.
>
> Maybe all of these cases in the glibc patch should be EEXIST instead which I think is the behavior on linux (assumption and untested).
>
> I am unsure how to proceed because I don't know who is wrong, gnulib or glibc.
>

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: yelninei--- via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: yelninei <at> tutamail.com, 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: bug#77709: Restoring the Hurd on core-packages-team branch
Date: Fri, 25 Apr 2025 19:43:49 +0200

Hi,

> This is now fixed in glibc for symlink see 39183b953c68a489cc0b9aefb8974711c834fb38 but should probably be added to glibc/hurd.

Would you like to prepare a patch for Guix adding this patch to glibc?

Actually, on ‘core-packages-team’, we should merge ‘glibc’ and
‘glibc/hurd’ since they only differ by Hurd-specific patches.

Thanks,
Ludo’.

Message #20 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: bug#77709: Restoring the Hurd on core-packages-team branch
Date: Mon, 28 Apr 2025 16:28:31 +0200 (CEST)

Hello,

Apr 25, 2025, 17:46 by ludo <at> gnu.org:

> Hi,
>
>> This is now fixed in glibc for symlink see 39183b953c68a489cc0b9aefb8974711c834fb38 but should probably be added to glibc/hurd.
>>
>
> Would you like to prepare a patch for Guix adding this patch to glibc?
>
Sure, I can do that. 

I mentioned in the first message that at least 2 other glibc patches are needed as well as currently bison is segfaulting immediately  . With these it is only crashing in 3 tests and I have not yet looked if there are another (glibc) patches that would fix those aswell.



> Actually, on ‘core-packages-team’, we should merge ‘glibc’ and
> ‘glibc/hurd’ since they only differ by Hurd-specific patches.
>

That would be great but I would love to have the bison issue fully solved before to not cause inconveniences for the linux builds. I have not yet looked into this though.
> Thanks,
> Ludo’.
>

Message #23 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: Restoring the Hurd on core-packages-team branch
Date: Mon, 5 May 2025 18:16:11 +0200 (GMT+02:00)

The openssl test issue went away after I updated openssl to 3.4.1

Considering that 3.4.0 is vulnerable to CVE-2024-12797 and CVE-2024-13176
it should probably be upgraded, but I dont know whether to use 3.4.1 or 3.5.0 ?

I reconfigured a minimal server os (basically just openssh and dhcp and and a hurd vm, removing guix-icons and no grub image to prevent a dependency on librsvg and thus rust) ontop of my WIP core-packages-team successfully and encountered some issueson the linux side:

- dtc: Test failures
- fakeroot: Fixed by an update to 1.37.1.1
- python-pyelfutils: Test failures
- nvi: Add a missing #~ in the #:make-flags
- clisp: Test failures (this is needed because of gnulib -> patch -> linux-libre-source)
- openbios: Had issues building libstdc++ for not version 14. The package is using gcc-10. Changing to the normal gcc (-14) and it fails compiling.  I worked around this by updating to a later commit which includes a change to disable a compiler warning.


I ignored them for now because my main goal was a childhurd with glibc-2.41, latest hurd and mach natively.

Message #26 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: Restoring the Hurd on core-packages-team branch
Date: Mon, 5 May 2025 22:10:30 +0200 (GMT+02:00)

For automake <at> 1.17 when I tried to rerun the tests only the t/backcompat2.sh test was failing.
However this seems to be a transient failure that went away when I retried. Should flaky tests be disabled? 

I dont have the previous logs anymore but iirc there were more failed tests previously. As this test suite takes forever with a single core (phase `check' succeeded after 3722.8 seconds) I did not bother to check again previously.

In particular the issue with the t/output-order.sh test and the libgc warnings from the guile driver seem to be gone/less of a problem.

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Z572 <z572 <at> z572.online>
To: yelninei--- via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: yelninei <at> tutamail.com, 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: bug#77709: Restoring the Hurd on core-packages-team branch
Date: Wed, 07 May 2025 22:35:15 +0800

[Message part 1 (text/plain, inline)]

yelninei--- via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

> The openssl test issue went away after I updated openssl to 3.4.1
>
> Considering that 3.4.0 is vulnerable to CVE-2024-12797 and CVE-2024-13176
> it should probably be upgraded, but I dont know whether to use 3.4.1 or 3.5.0 ?

As far as I know, openssl 3.5 is the lts version and I would tend to
upgrade to 3.5. Are you interested in sending patches to update it?


>
> I reconfigured a minimal server os (basically just openssh and dhcp
> and and a hurd vm, removing guix-icons and no grub image to prevent a
> dependency on librsvg and thus rust) ontop of my WIP
> core-packages-team successfully and encountered some issueson the
> linux side:
>
> - dtc: Test failures
> - fakeroot: Fixed by an update to 1.37.1.1
> - python-pyelfutils: Test failures
> - nvi: Add a missing #~ in the #:make-flags
> - clisp: Test failures (this is needed because of gnulib -> patch -> linux-libre-source)
> - openbios: Had issues building libstdc++ for not version 14. The
> package is using gcc-10. Changing to the normal gcc (-14) and it fails
> compiling.  I worked around this by updating to a later commit which
> includes a change to disable a compiler warning.
>
>
> I ignored them for now because my main goal was a childhurd with
> glibc-2.41, latest hurd and mach natively.

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: Restoring the Hurd on core-packages-team branch
Date: Wed, 7 May 2025 19:18:28 +0200 (CEST)

I asked about the bison failures on #hurd and ZhaoM tried to rebuild bison on debian with glibc 2.41 and encountered similar segfaults in the same tests.

I only had one additional failure than them that also was not failing when I initially checked this. After retrying on a childhurd from master the test was skipped because of a lack of english utf8 locale. On the childhurd running on core-packages-team the locale seems to be available, the test runs and bison segfaults.
I guess it is great that guix forces one to deal with such things immediately and not when one decides to rebuild a program but it massively increases the scope of updating a core package.

May 5, 2025, 20:10 by yelninei <at> tutamail.com:

> I dont have the previous logs anymore but iirc there were more failed tests previously. As this test suite takes forever with a single core (phase `check' succeeded after 3722.8 seconds) I did not bother to check again previously.
>
>
This is probably because of the same locale issue as I have problems with a childhurd built from master but no such things (apart from flaky tests) on a childhurd from core-packages-team.
The stderr is full of "sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)" and the automake test suite seems really picky about having no messages on stderr

Message #38 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: Z572 <z572 <at> z572.online>
Cc: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: bug#77709: Restoring the Hurd on core-packages-team branch
Date: Wed, 7 May 2025 19:39:24 +0200 (CEST)

Hello,

May 7, 2025, 14:35 by z572 <at> z572.online:

> As far as I know, openssl 3.5 is the lts version and I would tend to
> upgrade to 3.5. Are you interested in sending patches to update it?
>
>

Great, also I had no issues on i586-gnu with 3.5.0 . It will be a while until I will have an x86-64-linux toolchain to build-test it there.  I would prefer to stick to hurd specific patches for now and would greatly appreciate some help with the more generic patches.

One thing that after rebasing my wip-patches ontop of the new core-packages team branch the test_ssl test in python 3.11 is failing with all openssl 3.4.0, 3.4.1 and 3.5.0 on i586-gnu, but I dont know yet if this is also a problem on linux.

I feel like the list of problems is not getting smaller.

Message #41 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: Restoring the Hurd on core-packages-team branch
Date: Sun, 11 May 2025 12:02:14 +0200 (CEST)

Some more info for bison:

May 7, 2025, 17:18 by yelninei <at> tutamail.com:

> I asked about the bison failures on #hurd and ZhaoM tried to rebuild bison on debian with glibc 2.41 and encountered similar segfaults in the same tests.
>
>
One that is easy to reproduce is
22 Undefined Symbols (input.at:1013)

It tries to parse this file:
input.y

%printer {} foo baz
%destructor {} bar
%type <foo> qux
%%
exp: bar;

Starting program: /gnu/store/myb2g81i62fclqf0w9rm6kwrfcg8rv56-bison-3.8.2/bin/bison input.y
[bogus thread id 1 exited]
[bogus thread id 2 exited]
[bogus thread id 3 exited]
[New Thread 10710.5]

Thread 4 received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080917db in keys_init () at lib/fstrcmp.c:69
#2  0x0113dea8 in pthread_once <at> GLIBC_2.12 ()
   from /gnu/store/z945hln6sgh4nl5fy1p67hzb4i6rnc73-glibc-2.41/lib/libc.so.0.3
#3  0x08091a12 in fstrcmp_bounded (string1=0x20036120 "foo", 
    string2=0x200308a0 "$end", lower_bound=0.59999999999999998) at lib/fstrcmp.c:212
#4  0x08083781 in symbol_from_uniqstr_fuzzy (key=0x20036120 "foo") at src/symtab.c:368
#5  complain_symbol_undeclared (sym=0x20036130) at src/symtab.c:383
#6  symbol_check_defined (sym=0x20036130) at src/symtab.c:623
#7  symbols_check_defined () at src/symtab.c:1037
#8  0x08072a0d in check_and_convert_grammar () at src/reader.c:972
#9  reader (gram=0x20000bc0 "input.y") at src/reader.c:772
#10 0x0804b630 in main (argc=2, argv=0x103cdf4) at src/main.c:118

Configuring with --disable-threads works around this but i think this is another problem with libpthread. 

My current hope that this is the only one.
To be continued.

Message #44 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: Restoring the Hurd on core-packages-team branch
Date: Mon, 12 May 2025 17:57:50 +0200 (GMT+02:00)

May 11, 2025, 10:02 by yelninei <at> tutamail.com:

> One that is easy to reproduce is
> 22 Undefined Symbols (input.at:1013)
>
> It tries to parse this file:
> input.y
>
> %printer {} foo baz
> %destructor {} bar
> %type <foo> qux
> %%
> exp: bar;
>
> Starting program: /gnu/store/myb2g81i62fclqf0w9rm6kwrfcg8rv56-bison-3.8.2/bin/bison input.y
> [bogus thread id 1 exited]
> [bogus thread id 2 exited]
> [bogus thread id 3 exited]
> [New Thread 10710.5]
>
> Thread 4 received signal SIGSEGV, Segmentation fault.
> 0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0x080917db in keys_init () at lib/fstrcmp.c:69
> #2  0x0113dea8 in pthread_once <at> GLIBC_2.12 ()
>    from /gnu/store/z945hln6sgh4nl5fy1p67hzb4i6rnc73-glibc-2.41/lib/libc.so.0.3
> #3  0x08091a12 in fstrcmp_bounded (string1=0x20036120 "foo", 
>     string2=0x200308a0 "$end", lower_bound=0.59999999999999998) at lib/fstrcmp.c:212
> #4  0x08083781 in symbol_from_uniqstr_fuzzy (key=0x20036120 "foo") at src/symtab.c:368
> #5  complain_symbol_undeclared (sym=0x20036130) at src/symtab.c:383
> #6  symbol_check_defined (sym=0x20036130) at src/symtab.c:623
> #7  symbols_check_defined () at src/symtab.c:1037
> #8  0x08072a0d in check_and_convert_grammar () at src/reader.c:972
> #9  reader (gram=0x20000bc0 "input.y") at src/reader.c:772
> #10 0x0804b630 in main (argc=2, argv=0x103cdf4) at src/main.c:118
>
>

When building bison with disabled weak symbols (gl_cv_have_weak=no) it fails to link with undefined references to pthread_key_create, pthread_getspecific and pthread_setspecific.

Forcing it to link with libpthread with LDFLAGS=-lpthread  fixes this. This is only needed for the hurd as on linux these symbols are in libc and not in libpthread. Thoughts?.

Message #47 received at 77709 <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 77709 <77709 <at> debbugs.gnu.org>
Subject: Re: bug#77709: Restoring the Hurd on core-packages-team branch
Date: Sat, 17 May 2025 20:23:47 +0200 (CEST)

Hi Ludo,

Apr 28, 2025, 14:28 by yelninei <at> tutamail.com:

>
>
>> Actually, on ‘core-packages-team’, we should merge ‘glibc’ and
>> ‘glibc/hurd’ since they only differ by Hurd-specific patches.
>>
>
> That would be great but I would love to have the bison issue fully solved before to not cause inconveniences for the linux builds. I have not yet looked into this though.
>
>> Thanks,
>> Ludo’.
>>

I sent the series which fixes all the major regressions for the 32bit hurd earlier today (#78471). All the things that are broken now are also currently broken on master. (i'll need to recheck with the final patches, currently waiting on expensive/flaky tests but with earlier versions I had no other problems)

So once these (or rather the glibc/hurd patch) are reviewed the glibcs can be merged again.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.