Re: [GSoC] Guix + Hurd continuation
l...@gnu.org (Ludovic Courtès) skribis: 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. Another can of worms I forgot to mention is hurd/paths.h, which assumes that translators live in /hurd, whereas we’ll rather have them in /gnu/store/…/hurd. The recipe for the ‘hurd’ package could change those file names in hurd/paths.h. However, translator file names such as “/hurd/symlink” serve as shortcuts to avoid starting a translator for each symlink: http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libdiskfs/file-set-trans.c#n111. Thus, with /gnu/store file names for translators, a libc that uses /gnu/store/XYZ/hurd/symlink as _HURD_SYMLINK (e.g., in http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/symlink.c) would prevent the shortcut if it talks to a translator that expects /gnu/store/ABC/hurd/symlink. I think it would work anyway, but would end up starting one instance of /hurd/symlink for each symlink, which is suboptimal. Food for thought! Ludo’.
Re: [GSoC] Guix + Hurd continuation
Justus Winter 4win...@informatik.uni-hamburg.de skribis: Quoting Ludovic Courtès (2015-07-02 11:33:29) I think it would work anyway, but would end up starting one instance of /hurd/symlink for each symlink, which is suboptimal. No, /hurd/symlink doesn't quite work as expected. Currently, the shortcut semantics are important for us. Oh, good to know. How exactly does it not work as expected? Ludo’.
Re: [GSoC] Guix + Hurd continuation
Hello everyone, On 2 July 2015 at 12:12, Ludovic Courtès l...@gnu.org wrote: 0. Run Guix’s ‘./configure --with-courage make’ and see what happens. 1. ‘guix-daemon’ must work correctly on GNU/Hurd. Already started working on them. Will report back today on my first results. 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. I already have a pretty solid idea of what you mean. Will work around them as I progress. 3. In parallel to that, I should review wip-hurd again and apply the patches to a new ‘core-updates’ branch. Okay. 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. 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? Yes, I think now it's the right time to start this. Expect questions as I work on this. :-) Meanwhile if the hurd guys have something to point out, please do. :-) Another can of worms I forgot to mention is hurd/paths.h, which assumes that translators live in /hurd, whereas we’ll rather have them in /gnu/store/…/hurd. A question. Isn't it possible, that this will break the Hurd expected behavior? I think I should get a better understanding of how things work. Manolis
Re: [GSoC] Guix + Hurd continuation
Quoting Ludovic Courtès (2015-07-02 14:14:57) Justus Winter 4win...@informatik.uni-hamburg.de skribis: Quoting Ludovic Courtès (2015-07-02 11:33:29) I think it would work anyway, but would end up starting one instance of /hurd/symlink for each symlink, which is suboptimal. No, /hurd/symlink doesn't quite work as expected. Currently, the shortcut semantics are important for us. Oh, good to know. How exactly does it not work as expected? The wiki lists quite a few quirks: http://darnassus.sceen.net/cgi-bin/hurd-web?P=symlink Justus
Re: [GSoC] Guix + Hurd continuation
Quoting Ludovic Courtès (2015-07-02 11:33:29) I think it would work anyway, but would end up starting one instance of /hurd/symlink for each symlink, which is suboptimal. No, /hurd/symlink doesn't quite work as expected. Currently, the shortcut semantics are important for us. Justus
Re: [GSoC] Guix + Hurd continuation
Manolis Ragkousis, le Thu 02 Jul 2015 16:38:54 +0300, a écrit : 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. 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? Yes, I think now it's the right time to start this. Expect questions as I work on this. :-) Meanwhile if the hurd guys have something to point out, please do. :-) Note that this is listed on the contributing page of the wiki, with a link to the glibc open_issues page describing a bit more details. Another can of worms I forgot to mention is hurd/paths.h, which assumes that translators live in /hurd, whereas we’ll rather have them in /gnu/store/…/hurd. A question. Isn't it possible, that this will break the Hurd expected behavior? The Hurd is supposed to be flexible, so this is supposed to work. If not then that needs to be fixed, not the way you're doing things :) Samuel
