Hello! Now that Manolis managed to produce the bootstrap binaries (yay!), we must plan for what’s next.
I think the first thing will be to try and start building things natively, as noted in <https://www.gnu.org/software/guix/manual/html_node/Porting.html>. That implies a few things: 0. Run Guix’s ‘./configure --with-courage && make’ and see what happens. 1. ‘guix-daemon’ must work correctly on GNU/Hurd. This should be mostly the case, but it’s degraded compared to GNU/Linux because it will not use name spaces and bind mounts, so no chroot either (see <http://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n54>.) That’s OK for a start. Maybe there are other issues I haven’t thought of. 2. When building natively, surely you’ll find out that some packages do not build (PATH_MAX!), and that there are assumptions in hurd.scm and base.scm, such as the fact that GNU/Hurd is a cross-compilation target and not a native system. 3. In parallel to that, I should review wip-hurd again and apply the patches to a new ‘core-updates’ branch. 4. Instead of sitting idle watching build logs ;-), it Would Be Nice™ to implement the ‘mount’ and ‘umount’ functions for GNU/Hurd in libc, with support for MS_BIND using /hurd/firmlink. See <http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/utils/mount.c#n213> (the Hurd’s ‘mount’ command) for a good starting point. Of course libc hacking can be quite involved. So ideally Samuel, Thomas, and others would give you detailed guidance and/or hack power. What do people think? The reason I’m suggesting this is that it will be useful for the build daemon (see #1), and it will also facilitate porting of GuixSD afterwards (see <http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/syscalls.scm#n144>.) Anything else? Comments? Ludo’.
