Message ID | 58b21d29-f0b0-af8a-8c9e-11f4dd7a317a@gmail.com |
---|---|
Headers | show |
Hello, as I recently worked on the same subject in [1], I reviewed and amended the documentation patch [2]. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40601 [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37624
Hello, Here is a RFC series of patches that add a few things: - small fixes & cleanups - removing some (not all) bashisms - non-interactive mode (useful for (semi-) automated testing) - openrc init system support - runit init system support - busybox compatibility (for alpine support) - handle local guix-binary.${ARCH}.tar.xz file (useful for (semi-) automated testing) - requirements fixes It currently has been tested on a range of distros/arches but the latest patches are still not polished (missing proper commit messages) The series is RFC as a few questions remain for me: - Do we want to support alien (aka foreign++) distros (different shells, different init systems, etc...) - To what extent - Are the patches too fine-grained (I personally like them smallish) Future, additionnal work items: - s6 (adelie / obarun) init support - handle GPG downloading in non-interactive mode - being able to cross-build & test them on other arches again (dunno why it broke) - documentation - add missing guix-publish services - add missing RO remounting the store on other distros - removing allremaining bashisms (being shellcheck clean maybe ?) This is to gather input before investing too much time. For example, do we want to commit part of this now, with the rest coming later ? Any feedback ? On individual patch(es) or on the whole series goal... Thanks for reading this far.
I have openrc working on parabola with guix-daemon. It successfully registers the following service. #! /sbin/openrc-run description="guix build daemon" command="/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon" command_args="--build-users-group=guixbuild" command_background=true pidfile="/run/guix-daemon.pid" The above is a modification of Vincent's code in order to make it run for me without using the @localstatedir@ variable. If anybody has suggestions, corrections, and incites about this it would be greatly appreciated. I would like to get this working with the packaged version of guix in parabola https://www.parabola.nu/packages/?q=guix since that PKGBUILD does not support openrc currently. It also needs to be updated.
On Fri, May 22, 2020 at 01:44:39PM +0000, jgart--- via Guix-patches via wrote: > I have openrc working on parabola with guix-daemon. It successfully registers the following service. > > #! /sbin/openrc-run > > description="guix build daemon" > command="/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon" > command_args="--build-users-group=guixbuild" > command_background=true > pidfile="/run/guix-daemon.pid" Great! > The above is a modification of Vincent's code in order to make it run for me without using the @localstatedir@ variable. Does it still use the "correct" local state directory? Normally that's '/var/guix' but I'm not sure what Parabola does. > I would like to get this working with the packaged version of guix in parabola https://www.parabola.nu/packages/?q=guix Is it not working now? What remains to be done, aside from updating the packages?
Hello, The patch series is becoming long. So here is a batch of fairly easy ones, to lighten it a bit.
Dear Vincent, I am working on Bug #43744 and Path #43769 and I hit these patches set. <http://issues.guix.gnu.org/43744> <http://issues.guix.gnu.org/43769> Well, I am a bit lost with the different series and I do not know which are still valid and which are now obsolete. Could you rebase and resent the patch set? And reroll with v5? Thank you in advance. All the best, simon
Vincent Legoll <vincent.legoll@gmail.com> writes: > Hello, > > The patch series is becoming long. So here is a batch of fairly easy > ones, to lighten it a bit. Hi, Sorry for the delays in reviewing this. Thanks for sending a smaller set of patches, that makes reviewing easier. I made some tweaks, and pushed 4 commits to master as d2532317d136ac063a24baeec6688ea0e0ebe37b. I'm not sure about the bashisms stuff, given the script seems to depend on bash (see the exec bash bit at the start), I think using bash functionality is reasonable. What was your motivation behind these changes? (sorry if I've missed this earlier in the thread). Maybe once we've talked about the bashisms stuff, would you be able to send another set of patches for review? Thanks, Chris
Hello, > Thanks for sending a smaller set of patches, that makes reviewing > easier. I made some tweaks, and pushed 4 commits to master as > d2532317d136ac063a24baeec6688ea0e0ebe37b. Thanks for taking care of this, I'll have a look. > I'm not sure about the bashisms stuff, given the script seems to depend > on bash (see the exec bash bit at the start), I think using bash > functionality is reasonable. What was your motivation behind these > changes? (sorry if I've missed this earlier in the thread). Some distributions that I intended to add support for don't default to bash (nor have it installed by default). I think this script should aim for the broadest possible support, but that is only my opinion. And the patch set was not finished, I wanted to tackle the low hanging fruits first (also to test the interest from the guix team before doing too much). > Maybe once we've talked about the bashisms stuff, would you be able to > send another set of patches for review? I'll try to revive the patch set, and submit other portions I should have lying somewhere. Tchuss
I rebased and sent the next batch On Fri, Dec 18, 2020 at 8:35 PM Vincent Legoll <vincent.legoll@gmail.com> wrote: > > Hello, > > > Thanks for sending a smaller set of patches, that makes reviewing > > easier. I made some tweaks, and pushed 4 commits to master as > > d2532317d136ac063a24baeec6688ea0e0ebe37b. > > Thanks for taking care of this, I'll have a look. > > > I'm not sure about the bashisms stuff, given the script seems to depend > > on bash (see the exec bash bit at the start), I think using bash > > functionality is reasonable. What was your motivation behind these > > changes? (sorry if I've missed this earlier in the thread). > > Some distributions that I intended to add support for don't default to bash > (nor have it installed by default). I think this script should aim for > the broadest > possible support, but that is only my opinion. > > And the patch set was not finished, I wanted to tackle the low hanging fruits > first (also to test the interest from the guix team before doing too much). > > > Maybe once we've talked about the bashisms stuff, would you be able to > > send another set of patches for review? > > I'll try to revive the patch set, and submit other portions I should have lying > somewhere. > > Tchuss > > -- > Vincent Legoll
Hi, I just wanted to give some information about me runnning guix on void linux. I get the following error when I try to install with guix-install.sh: [ FAIL ] Init system could not be detected. That's probably to be expected since runit has not been added yet to the guix-install.sh script. Here is the guix-daemon runit service that I currently run on void linux in case it is useful to anyone else: /etc/sv/guix-daemon/run: ``` #!/bin/sh exec /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild --substitute-urls=https://guix.bordeaux.inria.fr 2>&1 ``` Has anyone tried running guix on void linux? If so, are you running something different than above for your runit service? all best, jgart _________________________________________ / 3B1D 7F19 E36B B60C 0F5B 2CA9 A52A A2B4 \ \ 77B6 DD35 / ----------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||