[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] Porting GuixSD to GNU/Hurd Update 1

From: Ludovic Courtès
Subject: Re: [GSoC] Porting GuixSD to GNU/Hurd Update 1
Date: Tue, 31 May 2016 18:14:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hi Manolis!

Manolis Ragkousis <manolis837@gmail.com> skribis:

> We already knew that the guix-daemon was not working properly on the
> Hurd.  I looked more into it and I found that if you do a build with
> Guix and it fails, and then you retry again, the next one will create a
> new build directory in /tmp/ as it should, but it will still use the
> first one.

Are you sure about this?  There’s a nice feature from a reproducibility
viewpoint, when using chroot builds, which is that the build directory
inside the chroot is always the same (always
“/tmp/guix-build-foobar.drv-0”), even if its name outside the chroot
needs to be different (say, “/my/tmp/guix-build-foobar.drv-12”).  See
Guix commit cb9601029ea164b86bdf997f7160d494c15d344b.

> I also found out that guix publish may sometimes crash if a client asks
> for a big substitute.  I will investigate this one as soon as possible.

If you can find a way to reproduce it, please send it to

I saw on IRC that you publish GNU/Hurd binaries from your machine, and I
find it pretty cool!

> Now on the coding part, in Guix I updated the gnumach/mig/hurd packages
> to the latest version and worked on getting wip-hurd in a state which
> can eventually merge to master.  A part of wip-hurd is already on master
> and after this core-updates cycle is merged to master, we will be able
> to get the rest of wip-hurd merged as well. Package glibc/hurd will also
> be updated then as well.

Great, I’m willing to make progress on this front!

> On debian/hurd I am using Guix every day and in my github wip-hurd I
> have some patches which I need to clean up and apply to the Guix repo.
> These patches are for various packages of various importance.


> And on the Hurd side, I created a new library called libhurdutil and
> moved the settrans implementation there.  For implementation info please
> read this email[1]. I am currently improving that library after
> Guillem's and Justus' input. (Thank you :-))  On the Guix side I will
> just write a wrapper to use this call and we will be able to control
> translators really easily.  This way the non existing mount() is not a
> problem anymore :-).

Nice work!  Perhaps the library should be called “libhurdtrans” or
something like that to better reflect what it’s about?

It may be that the functionality that was extracted from the ‘settrans’
command needs be nicely “repackaged” to make for a nice library
interface (for instance, by removing global variables and by untangling
UI concerns from actual functionality), but I’ll leave it up to the Hurd
people to comment on it.  :-)

Thanks for the update!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]