Heya, Carlo Zancanaro skribis: > On Thu, Mar 29 2018, Ludovic Courtès wrote: >> I would rather install the handler as a phase in gnu-build-system: >> this leaves ‘build-expression->derivation’ generic, and also gives >> us more flexibility (e.g., we can disable that phase without doing a >> full rebuild if needed.) See the patch below. >> >> WDYT? > > What do you mean by "generic"? I want as little magic as possible around the expression that’s passed to ‘build-expression->derivation’. > From what I can understand it's one of pid 1's responsiblities to reap > child processes, so I would expect this to be set up for every > builder, before the builder is run. True, but for derivations it’s also “optional” because eventually guix-daemon terminates all its child processes. > Given it's not specific to the gnu-build-system, I don't think it > really fits there. Yes, but note that it would be inherited by all the build systems. >> On my first attempt with: >> >> ./pre-inst-env guix build -e '(@@ (gnu packages commencement) >> findutils-boot0)' >> >> quickly failed: >> >> ... >> >> This is why ‘install-SIGCHLD-handler’ in the patch does nothing on >> Guile <= 2.0.9. > > From what I understand, Guix depends on Guile 2.0.13 or later, so I > didn't think it needed to work with 2.0.9. From my quick check, > though, our bootstrap binaries are Guile 2.0.9? Exactly. > I can see how that might cause a problem. In what sense does Guix > require 2.0.13 (as the manual claims) rather than 2.0.9? There’s the “host side” (the ‘guix’ commands and related modules), and there’s the “build side” (code used in the build environment when building derivations.) The “build side” is fully specified: ‘guix graph’ shows exactly what Guile is used where, and you can see with, say: guix graph -t derivation \ -e '(@@ (gnu packages commencement) findutils-boot0)' that the early derivations run on Guile 2.0.9. For “host side” code, users can use any Guile >= 2.0.13. See also . I hope this clarifies a bit! Ludo’.