Re: Add a new exec_exec_file_name RPC
Hello! Samuel Thibault skribis: > For non-Debian distributions, you may want > to pick up the hurd exec_filename_ patches from > https://anonscm.debian.org/git/pkg-hurd/hurd.git/tree/debian/patches > and the local-exec_filename.diff patch from > https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/tree/debian/patches/hurd-i386 > at least for some time to get backward compatibility with the previous > experimental RPCs. Are you planning to commit them upstream? That’d be nice. Also, now that you’re a glibc maintainer for the Hurd part, what would you think of doing a “mass commit” (with a lightweight re-review process) of all the patches that are in hurd/glibc.git? Ludo’.
Re: Add a new exec_exec_file_name RPC
Ludovic Courtès, on mar. 09 janv. 2018 12:57:40 +0100, wrote: > Samuel Thibault skribis: > > > For non-Debian distributions, you may want > > to pick up the hurd exec_filename_ patches from > > https://anonscm.debian.org/git/pkg-hurd/hurd.git/tree/debian/patches > > and the local-exec_filename.diff patch from > > https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/tree/debian/patches/hurd-i386 > > at least for some time to get backward compatibility with the previous > > experimental RPCs. > > Are you planning to commit them upstream? That’d be nice. The support is already commited upstream. The backward compatibility is not. > Also, now that you’re a glibc maintainer for the Hurd part, what would > you think of doing a “mass commit” (with a lightweight re-review > process) of all the patches that are in hurd/glibc.git? Sure, but even lightweight review needs time. Samuel
Re: Add a new exec_exec_file_name RPC
Samuel Thibault, on mar. 09 janv. 2018 13:00:44 +0100, wrote: > Ludovic Courtès, on mar. 09 janv. 2018 12:57:40 +0100, wrote: > > Also, now that you’re a glibc maintainer for the Hurd part, what would > > you think of doing a “mass commit” (with a lightweight re-review > > process) of all the patches that are in hurd/glibc.git? > > Sure, but even lightweight review needs time. What takes time is: - making sure the patches respect the GNU coding standard - writing the changelog both are really mandatory before commit. If people help me with it, the commit rate will be higher :) Samuel
Re: Add a new exec_exec_file_name RPC
I read that part a bit too fast Samuel Thibault, on mar. 09 janv. 2018 13:00:44 +0100, wrote: > Ludovic Courtès, on mar. 09 janv. 2018 12:57:40 +0100, wrote: > > Samuel Thibault skribis: > > > > > For non-Debian distributions, you may want > > > to pick up the hurd exec_filename_ patches from > > > https://anonscm.debian.org/git/pkg-hurd/hurd.git/tree/debian/patches > > > and the local-exec_filename.diff patch from > > > https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/tree/debian/patches/hurd-i386 > > > at least for some time to get backward compatibility with the previous > > > experimental RPCs. > > > > Are you planning to commit them upstream? That’d be nice. > > The backward compatibility is not. So you were indeed asking for the backward compatibility changes. It doesn't make much sense to commit them there since they have never been there. Note that they are only required for the upgrade path between hurd and libc of an existing system, then they are useless since the RPCs in question are only used between hurd and libc. For e.g. Guix you will never have the issue so you don't even need them. Samuel
Re: GSoC 2018: Microkernel devroom
Hello, Jakub Jermář, on ven. 05 janv. 2018 08:57:02 +0100, wrote: > another year of GSoC started and the mentor organization application > period is on until January 23 [0]. The question on the table is: would > Hurd like to participate under the Microkernel devroom [1] as it did > (very successfully) last year? Will anybody be able to mentor students? (I don't think I will have the time to) Samuel
Re: boot the Hurd with Guix
Hello Ludovic,
> Uncaught exception:
> Throw to key misc-error with args ("primitive-load-path" "Unable to
> find file ~S in load path" ("ice-9/boot-9") #f)Can\
> not exit gracefully when init is in progress; aborting.
> Aborted
This must come from the lack of /proc/self/exe.
In Debian GNU/Hurd we've '/proc/self/exe -> /bin/ls'
Specifically, “guile-static-stripped” has this patch to make it
relocatable:
This is necessary for the bootstrap Guile (see make-bootstrap.scm),
and
was necessary in the initrd on GNU/Linux (I think we no longer need it
for the initrd).
At any rate, you may be able to boot the Hurd with the “real”,
dynamically-linked Guile, no? That would solve the problem entirely.
I will try not to use initrd. Thanks
Re: boot the Hurd with Guix
Hello Svante, > /proc/self/exe is supported in glibc for Hurd since 2.24-18. Are you using an > earlier version? Currently we use glibc/hurd 2.23, see http://alpha.gnu.org/gnu/hurd/glibc-2.23-hurd+libpthread-20161218. And of course Hurd must be newer than Debian version 0.9.git20170507-1 The version level is: GNU Hurd 0.9 GNU-Mach 1.8+git20170609-486/Hurd-0.9 i686-AT386 GNU I think the solution is to eliminate the dependency of initrd for the moment in Guix, as Ludovic commented. Thanks
