GNU bug report logs - #40006
[core-updates] Merge wip-hurd

Previous Next

Package: guix;

Reported by: Jan Nieuwenhuizen <janneke <at> gnu.org>

Date: Tue, 10 Mar 2020 08:49:02 UTC

Severity: normal

Done: Jan Nieuwenhuizen <janneke <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40006 in the body.
You can then email your comments to 40006 AT debbugs.gnu.org in the normal way.

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

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


Report forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Tue, 10 Mar 2020 08:49:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jan Nieuwenhuizen <janneke <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 10 Mar 2020 08:49:02 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: [core-updates] Merge wip-hurd
Date: Tue, 10 Mar 2020 09:48:05 +0100
Hello Guix'y supporters of the Hurd,

This is a follow-up to a discussion on guix-devel
https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00081.html to
keep track of merging recent work for the Hurd by Efraim and others
that started on the Guix Days @fosdem20

    https://gitlab.com/Efraim/guix  @wip-hurd-bootstrap

The `wip-hurd' branch @savannah has now been reset* and now contains a
set of patches that allow for Hurd development, either by building
packages natively or by cross-building.

Most interesting here are the hurd bootstrap binaries and patches to get
through "commencement".  Efraim built a first set of bootstrap binaries
but I found we at least need some minimal set of glibc patches

    glibc-hurd-clock_t_centiseconds.patch
    glibc-hurd-clock_gettime_monotonic.patch
    glibc-hurd-signal-sa-siginfo.patch

which I added and so I built a new set.  While this mostly works, we may
want to look at/include more patches from the Debian glibc delta

    https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.31/debian/patches/hurd-i386

...but how to choose?

This patch series may be especially interesting as I have been also
using a number of hacks to get to build `hello' natively, avoiding
failing/hanging tests here and there

    HACK gnu: acl: Add patches for the Hurd, disable tests.
    HACK gnu: gettext-minimal: Expect test-raise test to fail on the Hurd.
    HACK gnu: check: Skip hanging tests on the Hurd.
    HACK gnu: guile: Disable tests on Hurd.
    HACK gnu: coreutils: Disable tests on Hurd.

I haven't re-evaluated the need for these yet after my last glibc
patches and I haven't included these on the wip-hurd branch; these live
on wip-hurd-system on my gitlab

    https://gitlab.com/janneke/guix  @wip-hurd-system

That's also where my scratchbook on the Hurd lives

   https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD

As discussed on guix-devel, we need to build gnumach-headers and
hurd-headers from a tarball release.  Initially I tried the latest
official releases but they are too old.  So I have created unofficial
source tarballs for Gnumach and Hurd tarball by running `make dist' on
the a git checkout on the Debian Hurd and uploaded them here

    http://lilypond.org/janneke/hurd

wip-hurd is branched off core-updates about two weeks ago; I will now
start with rebasing and re-evaluating on latest core-updates.

Greetings,
janneke

*) Everything from Manolis' old wip-hurd since been merged or ported to
   the new wip-hurd.

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Tue, 10 Mar 2020 08:55:02 GMT) Full text and rfc822 format available.

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

From: Manolis Ragkousis <manolis837 <at> gmail.com>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>, 40006 <at> debbugs.gnu.org
Subject: Re: bug#40006: [core-updates] Merge wip-hurd
Date: Tue, 10 Mar 2020 10:54:22 +0200
Awesome work Jan!




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Tue, 10 Mar 2020 09:00:02 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, 40006 <at> debbugs.gnu.org
Subject: Re: `guix build hello' now succeeds on the Hurd
Date: Tue, 10 Mar 2020 09:59:02 +0100
Ludovic Courtès writes:

>> The situation on the Hurd starts to look pretty good
>>
>>     janneke <at> debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload
>>     /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10
>>     janneke <at> debian:~/src/guix$ /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10/bin/hello
>>     Hello, world!
>>
>> \o/
>
> Woohoo!  Congrats!
>
> How do you run guix-daemon?  (In the future it’d be great to perhaps
> implement Linux namespaces on the Hurd in libc.)

I have slightly cleaned-up a patch by Manolis so that I can run

    sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &

This and other useful recipes I have noted in my scratchbook on the Hurd

   https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD

I briefly looked at more work-in-progress daemon patches by Manolis, but
stopped when I found that it needs [t]his "new" libhurdutils library...
@Manolis?

> Merging what you have—the earlier the better.  :-)
>> Shall I push this to savannah as `wip-hurd' (possibly save wip-hurd->
>> `wip-hurd-old?);
>
> Yup, sounds like a plan.

Great, thanks, done; follow-up here!

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40006
    https://issues.guix.info/issue/40006

>> I could also rewrite wip-hurd-bootstrap?
>
> Dunno!
>
> To me, the difficult bit with porting and bootstrapping work is making
> sure that bootstrap.scm/commencement.scm/base.scm/cross-base.scm remain
> maintainable.  All this complexity adds up so we must spend time trying
> to, for instance, minimize variation across platforms/OSes.  Every line
> of code and above all every conditional avoided in these files is a win
> in the not-so-long term.  That’d be my guideline as we merge it.  :-)
>
> Anyhow, thumbs up!  I’m looking forward to merging it and having it
> built on CI (we could offload to a Debian VM!)!

Yes, that would be awesome!

janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Tue, 10 Mar 2020 15:05:02 GMT) Full text and rfc822 format available.

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

From: Manolis Ragkousis <manolis837 <at> gmail.com>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>, Ludovic Courtès
 <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, 40006 <at> debbugs.gnu.org
Subject: Re: `guix build hello' now succeeds on the Hurd
Date: Tue, 10 Mar 2020 17:04:16 +0200
Hello Jan,

First of all awesome work!!

On 3/10/20 10:59 AM, Jan Nieuwenhuizen wrote:
> I briefly looked at more work-in-progress daemon patches by Manolis, but
> stopped when I found that it needs [t]his "new" libhurdutils library...
> @Manolis?
> 

This is that work
https://github.com/Phant0mas/Hurd/commit/3501ee22ad4150b3b2cf9a386d2350b9a68aecd8.patch

It was working, needed some cleanup but it never got merged. What is
does is implement mount and bind mounts using the hurd firmlinks.

>> Merging what you have—the earlier the better.  :-)
>>> Shall I push this to savannah as `wip-hurd' (possibly save wip-hurd->
>>> `wip-hurd-old?);

I don't think we need to keep the old wip-hurd. Just get rid of it.

Manolis




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Thu, 12 Mar 2020 07:00:02 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, 40006 <at> debbugs.gnu.org,
 Manolis Ragkousis <manolis837 <at> gmail.com>
Subject: Re: 33/33: daemon: Workaround issues for the Hurd.
Date: Thu, 12 Mar 2020 07:59:03 +0100
Ludovic Courtès writes:

Hello!

> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>>>> +#if !__GNU__
>>>>      int status = pid.wait(true);
>>>>      if (status != 0)
>>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>>> +#endif
>>>
>>> Do you know what the rationale was?  It looks like it could leave
>>> zombies behind us.
>>
>> No, maybe Manolis knows?  What I do know is why I used the patch: before
>> applying this patch I could only build up to binutils-boot0.
>> binutils-boot0 would always fail like so
>>
>>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>>     XXX fails: Workaround for nix daemon
>> phase `compress-documentation' succeeded after 0.4 seconds
>> error: cannot kill processes for uid `999': Operation not permitted
>> guix build: error: cannot kill processes for uid `999': failed with exit code 1
>
> But is the build process actually running as UID 999?  If you pass
> ‘--disable-chroot’, then I think build users are not used at all, right?

It seems that they are; I'm running

    sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &

and when starting two build processes, I get

    └─sudo(744,root)───guix-daemon(746)─ /

        ─┬─guix-daemon(1484)─┬─guile(1487,guixbuilder01)─ /
         │                   └─guile-2.2(1485)
         └─guix-daemon(1787)─┬─guile(2203,guixbuilder02)─ /

            ──bash(1497)───bash(3964)
            ──make(2512)───gcc(6043)───cc1(6048)

guixbuilder01 is 999, guixbuilder02 is 998 etc.  Does this mean that
root cannot pid.wait() for the builders?  Note that this error does not occur
when building gnu-make-boot0 or diffutils-boot0.

Hmm, after some more playing on the Hurd and our conversation on IRC, I
found that kill -1 simply does not work at the moment.

I copied sysdeps/mach/hurd/kill.c, renamed __kill to debug_kill and
added

--8<---------------cut here---------------start------------->8---
// libc_hidden_def (__kill)
// weak_alias (__kill, kill)

int
main ()
{
  return debug_kill (-1, SIGKILL);
}
--8<---------------cut here---------------end--------------->8---

Running this as a dummy user, it turns out we run

      err = __proc_getpgrppids (proc, - pid, &pids, &npids);

(effectively asking for PIDs in group of PID=1 ??) and returns only one
PID, in my case 5292

--8<---------------cut here---------------start------------->8---
demo <at> debian:~$ ps -ef -p 5292
    USER   PID  PPID TTY     TIME COMMAND
       -  5292     5   -  0:00.00 /hurd/storeio -Tzero
--8<---------------cut here---------------end--------------->8---

Hmm?  So it seems that kill -1 is currently not supported, or buggy.
I'll look/ask into this some more today.

>> -#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
>> +#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE)
>> +#define CLONE_ENABLED defined(CLONE_NEWNS)
>> +
>> +#if defined(SYS_pivot_root)
>> +#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,put_old))
>> +#endif
>>  
>>  #if CHROOT_ENABLED
>>  #include <sys/socket.h>
>> @@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
>>         - The UTS namespace ensures that builders see a hostname of
>>           localhost rather than the actual hostname.
>>      */
>> -#if CHROOT_ENABLED
>> +#if CLONE_ENABLED
>>      if (useChroot) {
>>  	char stack[32 * 1024];
>>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
>
> I’m not sure this is correct.  Perhaps we rather need an “#ifdef
> __linux__” around the use of clone(2)?

Okay, let's do that for now.

> Other options:
>
>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>
>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>      implementations of the abstraction (the Nix daemon did that at some
>      point, with the goal of supporting proprietary macOS etc.)
>
>      For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.
>
>      On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
>      its own proc server, root file system server, and without a pfinet
>      server running.
>
> Option #2 can be fun to implement and probably easier and less
> controversial than Option #1.  However, it does mean adding more code of
> the C++ code base, which is sad.

I'm assuming that 1.is what Manolis wanted to support with his
libhurdutil?  In fact, I forward ported (minimal effort) the patch

    https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56

but haven't tried linking against this yet.  That would be a nice first
step.  2. sounds fun, but it would need more getting familiar with the
Hurd for me :-)  You never know..

> Either way, it’s a bit of work, so this can definitely come later.

Great!

I have just reset wip-hurd again with new attempts for these too; all
somewhat and more experimental patches are at

    https://gitlab.com/janneke/guix/-/tree/wip-hurd-system

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Thu, 12 Mar 2020 13:01:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: guix-devel <at> gnu.org, 40006 <at> debbugs.gnu.org,
 Manolis Ragkousis <manolis837 <at> gmail.com>
Subject: Re: 33/33: daemon: Workaround issues for the Hurd.
Date: Thu, 12 Mar 2020 13:59:55 +0100
Hi!

Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:

> Ludovic Courtès writes:
>
> Hello!
>
>> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>>
>>>>> +#if !__GNU__
>>>>>      int status = pid.wait(true);
>>>>>      if (status != 0)
>>>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>>>> +#endif
>>>>
>>>> Do you know what the rationale was?  It looks like it could leave
>>>> zombies behind us.
>>>
>>> No, maybe Manolis knows?  What I do know is why I used the patch: before
>>> applying this patch I could only build up to binutils-boot0.
>>> binutils-boot0 would always fail like so
>>>
>>>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>>>     XXX fails: Workaround for nix daemon
>>> phase `compress-documentation' succeeded after 0.4 seconds
>>> error: cannot kill processes for uid `999': Operation not permitted
>>> guix build: error: cannot kill processes for uid `999': failed with exit code 1
>>
>> But is the build process actually running as UID 999?  If you pass
>> ‘--disable-chroot’, then I think build users are not used at all, right?
>
> It seems that they are; I'm running

Oh, OK.

[…]

>> Other options:
>>
>>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>>
>>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>>      implementations of the abstraction (the Nix daemon did that at some
>>      point, with the goal of supporting proprietary macOS etc.)
>>
>>      For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.
>>
>>      On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
>>      its own proc server, root file system server, and without a pfinet
>>      server running.
>>
>> Option #2 can be fun to implement and probably easier and less
>> controversial than Option #1.  However, it does mean adding more code of
>> the C++ code base, which is sad.
>
> I'm assuming that 1.is what Manolis wanted to support with his
> libhurdutil?  In fact, I forward ported (minimal effort) the patch
>
>     https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56
>
> but haven't tried linking against this yet.  That would be a nice first
> step.  2. sounds fun, but it would need more getting familiar with the
> Hurd for me :-)  You never know..

I suppose the commit you link to could have been used by libc to
implement #1?  Oh, actually, IIRC, Manolis was working on implementing
mount(2) and umount(2) in libc (which would also be needed), and
probably the settrans utilities were part of that effort.

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Sat, 14 Mar 2020 08:30:02 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, 40006 <at> debbugs.gnu.org
Subject: Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.
Date: Sat, 14 Mar 2020 09:28:56 +0100
Ludovic Courtès writes:

> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>> commit 7653827b8919ad85d025ba1a701ba38ab7d2e388
>> Author: Jan Nieuwenhuizen <janneke <at> gnu.org>
>> Date:   Sat Mar 7 03:53:38 2020 -0500
>>
>>     gnu: coreutils: Remove libcap dependency for the Hurd.
>>     
>>     * gnu/packages/linux.scm (libcap)[supported-systems]: Remove the Hurd.
>>     * gnu/packages/base.scm (coreutils)[inputs]: Include libcap only for supported
>>     systems.  Fixes building on the Hurd.
>
> LGTM!

Pushed to core-updates as 11a5ffba7327250ebe7b67c777204e49858310bb

Yay, my first work for the Hurd just got in \o/
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Sun, 15 Mar 2020 18:25:01 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, 40006 <at> debbugs.gnu.org
Subject: Re: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.
Date: Sun, 15 Mar 2020 19:23:52 +0100
Jan Nieuwenhuizen writes:

>> For the sake of reducing complexity and keeping supported systems as
>> close to one another as possible, would it be an option to keep using
>> 2.0 for GNU/Hurd, like on the other systems?
...
>> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
>> as a first step.  And yeah, it’d also entail another full rebuild, which
>> I’m sorry for, but I think this kind of simplification pays off quickly.
>>
>> WDYT?
>
> Yes, let's do that.  I'll also want to look at using gcc-5, that may
> solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
> build gcc-7 by default as bootstrap binary, while using that may not
> even work (and is certainly untested).

Yes; that worked and it simplifies things a lot.  So, wip-hurd is using
guile-2 and gcc-5 now.  Using gcc-5 allowed me to remove the puzzling
gcc-boot0 patch.

Just reset wip-hurd again; it was fully up to date with core-utils when
I started building the bootstrap-tarballs... Rebasing right now to
verify for a new round ;-)

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Mon, 16 Mar 2020 07:44:02 GMT) Full text and rfc822 format available.

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

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: guix-devel <at> gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 40006 <at> debbugs.gnu.org
Subject: Re: bug#40006: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.
Date: Mon, 16 Mar 2020 09:42:42 +0200
[Message part 1 (text/plain, inline)]
On Sun, Mar 15, 2020 at 07:23:52PM +0100, Jan Nieuwenhuizen wrote:
> Jan Nieuwenhuizen writes:
> 
> >> For the sake of reducing complexity and keeping supported systems as
> >> close to one another as possible, would it be an option to keep using
> >> 2.0 for GNU/Hurd, like on the other systems?
> ...
> >> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
> >> as a first step.  And yeah, it’d also entail another full rebuild, which
> >> I’m sorry for, but I think this kind of simplification pays off quickly.
> >>
> >> WDYT?
> >
> > Yes, let's do that.  I'll also want to look at using gcc-5, that may
> > solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
> > build gcc-7 by default as bootstrap binary, while using that may not
> > even work (and is certainly untested).
> 
> Yes; that worked and it simplifies things a lot.  So, wip-hurd is using
> guile-2 and gcc-5 now.  Using gcc-5 allowed me to remove the puzzling
> gcc-boot0 patch.
> 
> Just reset wip-hurd again; it was fully up to date with core-utils when
> I started building the bootstrap-tarballs... Rebasing right now to
> verify for a new round ;-)

I haven't been looking at the wip-hurd branch that much, but I tested my
libstdc++-boot0 patch on aarch64 using gcc-7 with bootstrap binary gcc-5
and it failed to build. I didn't investigate.

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Thu, 26 Mar 2020 12:26:02 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: 40006 <at> debbugs.gnu.org
Subject: Re: bug#40006: [core-updates] Merge wip-hurd
Date: Thu, 26 Mar 2020 13:25:32 +0100
Jan Nieuwenhuizen writes:

> Hello Guix'y supporters of the Hurd,

`wip-hurd' is now pushed to core-updates as

    3a1c3642d4d611c5516a8ba5b6bc7e39bdc1c9ae

As discussed on IRC yesterday, we did it in two stages: we first
merged all work necessary to build sensible bootstrap binaries
to core-updates:

    3342a1182b15ec031f0ec6f602fd96c1dca3d4b0

then we build bootstrap binaries and verified the result, producing
this commit message

--8<---------------cut here---------------start------------->8---
On 3342a1182b15ec031f0ec6f602fd96c1dca3d4b0
   gnu: make-bootstrap: Use _IOLBF on Guile 2.0 only.

Run
    ./pre-inst-env guix build --target=i586-pc-gnu bootstrap-tarballs --verbosity=1

Producing

    /gnu/store/lhca65c997pvic5cfrpm0dasniwqlg2a-bootstrap-tarballs-0

With guix hash -rx /gnu/store/lhca65c997pvic5cfrpm0dasniwqlg2a-bootstrap-tarballs-0

    07jnq2by98f2a45k8wd2gj62iazvwfa4z7p3w3id4m1g0fdsvc3b
--8<---------------cut here---------------end--------------->8---

Next up is to work towards getting a bootable guix image for the Hurd
and other porting work in the Debian VM.

See:

    https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD

but that's a whole other stage of effort, I'm tempted to close this bug
and open a new one (or two?) for that.  WYDT?

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Thu, 26 Mar 2020 12:52:01 GMT) Full text and rfc822 format available.

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

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 40006 <at> debbugs.gnu.org
Subject: Re: bug#40006: [core-updates] Merge wip-hurd
Date: Thu, 26 Mar 2020 14:51:10 +0200
[Message part 1 (text/plain, inline)]
On Thu, Mar 26, 2020 at 01:25:32PM +0100, Jan Nieuwenhuizen wrote:
> Jan Nieuwenhuizen writes:
> 
> > Hello Guix'y supporters of the Hurd,
> 
> `wip-hurd' is now pushed to core-updates as
> 
>     3a1c3642d4d611c5516a8ba5b6bc7e39bdc1c9ae
> 
> As discussed on IRC yesterday, we did it in two stages: we first
> merged all work necessary to build sensible bootstrap binaries
> to core-updates:
> 
>     3342a1182b15ec031f0ec6f602fd96c1dca3d4b0
> 
> then we build bootstrap binaries and verified the result, producing
> this commit message
> 
> --8<---------------cut here---------------start------------->8---
> On 3342a1182b15ec031f0ec6f602fd96c1dca3d4b0
>    gnu: make-bootstrap: Use _IOLBF on Guile 2.0 only.
> 
> Run
>     ./pre-inst-env guix build --target=i586-pc-gnu bootstrap-tarballs --verbosity=1
> 
> Producing
> 
>     /gnu/store/lhca65c997pvic5cfrpm0dasniwqlg2a-bootstrap-tarballs-0
> 
> With guix hash -rx /gnu/store/lhca65c997pvic5cfrpm0dasniwqlg2a-bootstrap-tarballs-0
> 
>     07jnq2by98f2a45k8wd2gj62iazvwfa4z7p3w3id4m1g0fdsvc3b
> --8<---------------cut here---------------end--------------->8---
> 
> Next up is to work towards getting a bootable guix image for the Hurd
> and other porting work in the Debian VM.
> 
> See:
> 
>     https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD
> 
> but that's a whole other stage of effort, I'm tempted to close this bug
> and open a new one (or two?) for that.  WYDT?
> 
> Greetings,
> janneke
> 

There's bootstrap binaries now existing, I'd say that counts as merging
in Hurd support.

Congrats!

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]

Reply sent to Jan Nieuwenhuizen <janneke <at> gnu.org>:
You have taken responsibility. (Thu, 26 Mar 2020 14:09:02 GMT) Full text and rfc822 format available.

Notification sent to Jan Nieuwenhuizen <janneke <at> gnu.org>:
bug acknowledged by developer. (Thu, 26 Mar 2020 14:09:02 GMT) Full text and rfc822 format available.

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

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 40006-done <at> debbugs.gnu.org
Subject: Re: bug#40006: [core-updates] Merge wip-hurd
Date: Thu, 26 Mar 2020 15:08:42 +0100
Efraim Flashner writes:

>> Next up is to work towards getting a bootable guix image for the Hurd
>> and other porting work in the Debian VM.
>> 
>> See:
>> 
>>     https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD
>> 
>> but that's a whole other stage of effort, I'm tempted to close this bug
>> and open a new one (or two?) for that.  WYDT?
>
> There's bootstrap binaries now existing, I'd say that counts as merging
> in Hurd support.
>
> Congrats!

Thank you => closing.
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




Information forwarded to bug-guix <at> gnu.org:
bug#40006; Package guix. (Thu, 26 Mar 2020 14:27:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 40006 <at> debbugs.gnu.org
Subject: Re: bug#40006: [core-updates] Merge wip-hurd
Date: Thu, 26 Mar 2020 15:26:38 +0100
Hi!

Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:

> Jan Nieuwenhuizen writes:
>
>> Hello Guix'y supporters of the Hurd,
>
> `wip-hurd' is now pushed to core-updates as
>
>     3a1c3642d4d611c5516a8ba5b6bc7e39bdc1c9ae

Congrats!  \o/

> Next up is to work towards getting a bootable guix image for the Hurd
> and other porting work in the Debian VM.
>
> See:
>
>     https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD
>
> but that's a whole other stage of effort, I'm tempted to close this bug
> and open a new one (or two?) for that.  WYDT?

Yeah, probably use one bug for each focused issue.  It’s easier to
follow & review, and also more rewarding because you get to close issues
more often.  :-)

Ludo’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 24 Apr 2020 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 339 days ago.

Previous Next


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