[bug#40601,0/5] Handle runit-based foreign distributions

And assorted small fixes around the subject.

The first 3 patches are smallish things.

Maybe the REQUIRED array could get other
missing requirements: tar (or maybe the "tr"
item is a typoed tar, I've found no use of tr),
mkdir, ln, usermod, useradd, cp, cat...

The handling of local files for guix-install.sh is to
help testing modified / locally generated binary
tarballs.

One thing that is working as-is, but that I'm not sure
is right: The runit script in the guix-binary tarball is
patched for the shebang to point to /gnu/store/...

This looks wrong even if it is working, the interpreter
for that script should be the one of the foreign distro.

But this is not specific to the runit support, the sysv
scripts also are shebang-patched.

How would I tell guix not to patch these files's shebangs ?

WDYT ?

This series has been tested on void linux i686 in qemu
kvm with:

- upload locally build guix-binary tarball & guix-install.sh
to VM
- run guix-install.sh guix-binary.i686-linux.tar.xz

1) guix search hello
2) guix show hello
3) guix build hello
4) guix gc -D/gnu/store/*hello*
5) guix build --no-substitutes hello (stopped as it was rebuilding the world)
6) guix package -u
7) guix pull
8) guix package -u
9) guix gc


So the download part is not tested, but all ran well.

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 |
                ||     ||