GNU bug report logs - #78471
[PATCH core-packages-team 0/5] Restoring the Hurd

Previous Next

Package: guix-patches;

Reported by: yelninei <at> tutamail.com

Date: Sat, 17 May 2025 14:55:01 UTC

Severity: normal

Tags: patch

Done: yelninei <at> tutamail.com

To reply to this bug, email your comments to 78471 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to guix-patches <at> gnu.org:
bug#78471; Package guix-patches. (Sat, 17 May 2025 14:55:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to yelninei <at> tutamail.com:
New bug report received and forwarded. Copy sent to guix-patches <at> gnu.org. (Sat, 17 May 2025 14:55:01 GMT) Full text and rfc822 format available.

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

From: yelninei <at> tutamail.com
To: guix-patches <at> gnu.org
Cc: Janneke Nieuwenhuizen <janneke <at> gnu.org>
Subject: [PATCH core-packages-team 0/5] Restoring the Hurd
Date: Sat, 17 May 2025 16:53:39 +0200 (CEST)
[Message part 1 (text/plain, inline)]
Hello,

Here are (hopefully) the last remaining patches to fix #77709.
I have built things up to bison and automake succesfully.
Some notes:
I am bad at naming things and labelled the glibc patches according to the gnulib-test they fix.

I tried to add comments explaining why things are changed, I hope they are clear enough.

In the pthread-once patch I removed the note from the debian patch regarding the symbol version of pthread-once because as soon as glibc 2.42 is available in guix everything will be built against the 2.42 symbol automatically.

For the --disable-year2038 changes, several packages in commencement.scm already have it unconditionally and this is now repeated twice on i586-gnu by inheriting the args.
Is there a better way to get only the 32bit hurd target than the

(and (target-hurd?)
     (not (target64bit?)))

i am using currently?

I dont know what the convention is when the #:configure-flag keyword is added only for a specific target if the keyword is also spliced in or not, but this is only a cosmetic change.

The automake test suite seems to be extremely flaky. It fails when the host glibc is 2.39 because of locale errors on stderr  (the test checks for empty stderr)  and some other tests that required multiple tries (~8) to get lucky. 
However the t/output-order.sh failure due to libgc warnings from the guile driver on stderr currently on master no longer occurs.

Ludovic also mentioned to merge glibc and glibc/hurd again.


Yelninei (5):
  gnu: glibc/hurd: Fix gnulib tests.
  gnu: findutils: Disable 64bit time_t on the 32bit Hurd.
  gnu: util-linux: Disable 64bit time_t on the 32bit Hurd.
  gnu: tar: Disable 64bit time_t on the 32bit Hurd.
  gnu: bison: Link with pthread on the Hurd.

gnu/local.mk                                  |   3 +
gnu/packages/base.scm                         |  13 ++
gnu/packages/bison.scm                        |  10 +-
gnu/packages/commencement.scm                 |   3 +-
gnu/packages/linux.scm                        |   7 +-
.../glibc-hurd-2.41-pthread-once.patch        | 185 ++++++++++++++++++
.../glibc-hurd-2.41-pthread-sigmask.patch     |  22 +++
.../patches/glibc-hurd-2.41-symlink.patch     |  32 +++
8 files changed, 271 insertions(+), 4 deletions(-)
create mode 100644 gnu/packages/patches/glibc-hurd-2.41-pthread-once.patch
create mode 100644 gnu/packages/patches/glibc-hurd-2.41-pthread-sigmask.patch
create mode 100644 gnu/packages/patches/glibc-hurd-2.41-symlink.patch


base-commit: 4935a8066168c3efc0520d132b6c6a3116eb5d54

[0001-gnu-glibc-hurd-Fix-gnulib-tests.patch (text/x-patch, attachment)]
[0002-gnu-findutils-Disable-64bit-time_t-on-the-32bit-Hurd.patch (text/x-patch, attachment)]
[0003-gnu-util-linux-Disable-64bit-time_t-on-the-32bit-Hur.patch (text/x-patch, attachment)]
[0004-gnu-tar-Disable-64bit-time_t-on-the-32bit-Hurd.patch (text/x-patch, attachment)]
[0005-gnu-bison-Link-with-pthread-on-the-Hurd.patch (text/x-patch, attachment)]

Information forwarded to guix-patches <at> gnu.org:
bug#78471; Package guix-patches. (Sat, 24 May 2025 07:14:01 GMT) Full text and rfc822 format available.

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

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: yelninei <at> tutamail.com
Cc: guix-patches <at> gnu.org
Subject: Re: [PATCH core-packages-team 0/5] Restoring the Hurd
Date: Sat, 24 May 2025 09:13:15 +0200
Hi!

> Here are (hopefully) the last remaining patches to fix #77709.
> I have built things up to bison and automake succesfully.
> Some notes:

> I am bad at naming things and labelled the glibc patches according to
> the gnulib-test they fix.

Yes, that makes sense to me.

> I tried to add comments explaining why things are changed, I hope they
> are clear enough.

Thanks, I like what you've done!

> For the --disable-year2038 changes, several packages in
> commencement.scm already have it unconditionally and this is now
> repeated twice on i586-gnu by inheriting the args.
> Is there a better way to get only the 32bit hurd target than the
>
> (and (target-hurd?)
>      (not (target64bit?)))
>
> i am using currently?

This is how it's done, indeed.

> I dont know what the convention is when the #:configure-flag keyword
> is added only for a specific target if the keyword is also spliced in
> or not, but this is only a cosmetic change.

> The automake test suite seems to be extremely flaky. It fails when the
> host glibc is 2.39 because of locale errors on stderr  (the test
> checks for empty stderr)  and some other tests that required multiple
> tries (~8) to get lucky. 
> However the t/output-order.sh failure due to libgc warnings from the
> guile driver on stderr currently on master no longer occurs.

Yes.  IIRC, Debian has simply disabled many test suites on the Hurd.
It can be quite a lot of work to disable specific tests but usually
I much prefer that.

> Ludovic also mentioned to merge glibc and glibc/hurd again.

Yes, whenever that's possible I think it's preferrable.  I'm always
hoping "this time" is the last time we have to use a separate glibc/hurd
:)

> Yelninei (5):
>   gnu: glibc/hurd: Fix gnulib tests.
>   gnu: findutils: Disable 64bit time_t on the 32bit Hurd.
>   gnu: util-linux: Disable 64bit time_t on the 32bit Hurd.
>   gnu: tar: Disable 64bit time_t on the 32bit Hurd.
>   gnu: bison: Link with pthread on the Hurd.

LGTM, pushed to core-packages-team; thanks!

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com




Reply sent to yelninei <at> tutamail.com:
You have taken responsibility. (Sat, 24 May 2025 15:10:04 GMT) Full text and rfc822 format available.

Notification sent to yelninei <at> tutamail.com:
bug acknowledged by developer. (Sat, 24 May 2025 15:10:04 GMT) Full text and rfc822 format available.

Message #13 received at 78471-done <at> debbugs.gnu.org (full text, mbox):

From: yelninei <at> tutamail.com
To: 78349-done <at> debbugs.gnu.org, 78513-done <at> debbugs.gnu.org,
 78351-done <at> debbugs.gnu.org, 78471-done <at> debbugs.gnu.org
Subject: Closing Issues
Date: Sat, 24 May 2025 17:08:57 +0200 (GMT+02:00)
All patches are applied, cleaning up the issues.




This bug report was last modified 19 days ago.

Previous Next


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