GNU bug report logs - #63527
[PATCH 0/3] Initial attempt at rumpdisk support for the Hurd.

Previous Next

Full log

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

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 63527 <at> debbugs.gnu.org, dev <at> jpoiret.xyz
Subject: Re: bug#63527: [PATCH 0/3] Initial attempt at rumpdisk support for
 the Hurd.
Date: Fri, 19 May 2023 10:21:36 +0200

Ludovic Courtès writes:

Hi!

> Awesome patch series!!

Thanks!

> Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>> +++ b/gnu/packages/cross-base.scm
[..]
>> +                       ;; TODO: move to glibc in the next rebuild cycle
>> +                       (add-after 'unpack 'patch-libc/hurd
>> +                         (lambda* (#:key inputs #:allow-other-keys)
>> +                           (for-each
>> +                            (lambda (name)
>> +                              (let ((patch (assoc-ref inputs name)))
>> +                                (invoke "patch" "-p1" "--force" "-R" "-i" patch)))
>> +                            '("hurd-monotonic.patch"
>> +                              "hurd-centiseconds.patch"))
>
> Since this should also be applied when building glibc natively on
> i586-gnu, should this phase go to ‘glibc’ in (gnu packages base)
> instead?

Yes, but I don't know how to do that without triggering a world
rebuild, or (re)creating a glibc/hurd, and currently the native build is
broken on the hurd. It tried, in glibc

      #:phases (modify-phases %standard-phases
                 ,@(if (and (hurd-target?)
                            (equal? (package-version this-package) "2.35"))
                       ;; TODO: move to glibc in the next rebuild cycle
                       '((add-after 'unpack 'patch-libc/hurd
                           (lambda* (#:key inputs #:allow-other-keys)
                             (define* (apply-patch patch #:key reverse?)
                               (let ((patch (assoc-ref inputs name)))
                                 (invoke "patch" "-p1" "--force"
                                         (if reverse? "-R" "-N")
                                         "-i" patch)))
                             (for-each (cut apply-patch <> #:reverse #t)
                                       '("hurd-monotonic.patch"
                                         "hurd-centiseconds.patch"))
                             (for-each apply-patch
                                       '("2.35-hurd-centiseconds.patch"
                                         "2.35-hurd-monotonic.patch")))))
                        '())

but that isn't being picked-up for cross-libc.  I heard talk about
glibc/hurd, should we maybe keep this patch until we create glibc/hurd,
or make glibc/hurd sooner?

> Also, in general, we should move away from quasiquote/unquote to
> gexp/ungexp, which will allow us to not add inputs for patches (as is
> done with ‘gcc-11’ in (gnu packages gcc)).

Ah, right; nice!  Would that work for cross-libc without triggering a
world rebuild?

>> +                                 ;; TODO: move to glibc in the next rebuild cycle
>> +                                 ("hurd-monotonic.patch"
>> +                                  ,@(search-patches
>> +                                     "glibc-hurd-clock_gettime_monotonic.patch"))
[..]

> Let’s hope these patches will soon make it upstream!

Yeah!

Greetings
Janneke

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

Previous Next

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