void-linux
s6/66 integration (previously boot-66serv )
This PR contains packaging templates, scripts and frontend service files that enable a voidlinux system to boot and work using s6 and s6-rc via the 66 suite of utilities. Packaging templates are provided for:
-
boot66-serv, the portable set of service to boot a machine in conjunction with 66 API. The package also contains extra scripts, under the files/ subdir and two services frontend files. Under the patches/ subdirectory there are void-specific patches.
-
void-66-services, a collection of frontend service files for voidlinux, maintained in https://github.com/mobinmob/void-66-services.
-
scandir-66serv, a module type service for 66 that enables running services in a user session.
-
66-void, a replacement for the runit-void package, that reuses the void-runit repo contents to create a 66 "base" package for the distribution.
-
base-system-66, a replacement for the base-system meta package, only difference the dependence on 66-void instead of runit-void.
History
The effort to make this possible started in https://github.com/void-linux/void-packages/pull/21142 from @zenfailure that packaged the portable stage 1 scripts for 66, created by Eric Vidal. @teldra packaged the current, module-based iteration ( https://github.com/void-linux/void-packages/pull/23122 ) and I took over the effort and maintained a stable version in a ( https://github.com/void-linux/void-packages/pull/25743 ).
Packages based on the templates are created and uploaded to a repository and there is some documentation on using them to setup the system.
Testing the changes
- I tested the changes in this PR: YES
New package
- This new package conforms to the package requirements: YES
Documentantion:
- Basic setup information
- Runit services in 66
- Logging in 66
- base-system-66 and 66-void packages
- 66boot-* utilities
Relevent git repositories:
- https://github.com/mobinmob/void-66-services/ : Services and documentation
- https://codeberg.org/mobinmob/66-voidlinux/ : Templates and scripts are maintained here, with full commit history.
The next release will be out this month (hopefully :P ). For everyone interested, please chech the MR: https://codeberg.org/mobinmob/66-voidlinux/pulls/21
There will be a deprecation: The helper script that runs as init will be renamed from 66 to init-66. This is in preparation for the next 66 release which will have an executable named... 66. To assist in the transision I will provide a symlink for some time. The other goals of the release are in the MR comments.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
A new version of 66 is in the rc stage, after 3 beta releases. I am testing that, it will need documentation and user intervention since it has breaking changes.
Hey,
just wanted to let you know that I've setup a draft PR for the whole s6* + utility packages.
The PR #48582.
Hey,
just wanted to let you know that I've setup a draft PR for the whole s6* + utility packages.
The PR #48582.
preprod for 66 in not a final release, it is an rc (I know, I am the one who proposed beta etc releases to @obarun ).I am waiting for the final release and (more) testing. Going from 0.6.0.x to 0.7.0.x is a major change and I didn't have the time yet to test as much as I like. You are ofc free to create another PR ( https://github.com/void-linux/void-packages/pull/47177) and the devs to merge whatever they want.
preprod for 66 in not a final release, it is an rc (I know, I am the one who proposed beta etc releases to @Obarun ).I am waiting for the final release and (more) testing. Going from 0.6.0.x to 0.7.0.x is a major change and I didn't have the time yet to test as much as I like.
That is why I created a draft PR for testing. Building looks fine now and of course we would need to wait for 66 to have a stable 0.7.0.0 available. But seeing check marks already is a good sign for testing the packages.
You are ofc free to create another PR and the devs to merge whatever they want.
I would like to go further together with you if you don't mind. If you've other plans I don't want to get into your way.
I'm not yet using s6 and with the PR on the way and all green. I would now test the PR versions and try out s6 and the other packages as well.
preprod for 66 in not a final release, it is an rc (I know, I am the one who proposed beta etc releases to @Obarun ).I am waiting for the final release and (more) testing. Going from 0.6.0.x to 0.7.0.x is a major change and I didn't have the time yet to test as much as I like.
That is why I created a draft PR for testing. Building looks fine now and of course we would need to wait for
66to have a stable0.7.0.0available. But seeing check marks already is a good sign for testing the packages.
I already have a PR (https://github.com/void-linux/void-packages/pull/47177), since the 66 has to be upgraded (breaking changes from the skarnet stack), but have not yet pushed all needed programs. Maybe your approach is better :)
You are ofc free to create another PR and the devs to merge whatever they want.
I would like to go further together with you if you don't mind. If you've other plans I don't want to get into your way.
I will gladly work with you to advance 66 in voidlinux, please sent an email - github comments is not the ideal place for collaboration beyond reviews :)
I'm not yet using s6 and with the PR on the way and all green. I would now test the PR versions and try out s6 and the other packages as well.
The current 66 release is stable and well-tested. See the links in the first post on how to setup a system with this. 0.7.0.0 is quite different - my current working branch for boot-66serv voidlinux is voidlinux-dev: https://git.obarun.org/mobinmob/boot-66serv/-/tree/voidlinux-dev?ref_type=heads What needs to be done for this is:
- revamp the 66boot-* utils to use the new 66 subcommands (not really diffcult) - developed in codeberg
- revise the services in voidlinux-66-services for the new format (easy)
- revice the documentation (straightforward)
- test and then test some more :P
I plan to do most of the above if not all (well testing will continue...) in the following days and the weekend...
Here is a first quick refactoring of the boot-66serv template.
I looked at the configure_args and was wondering if the ! are mandatory. The configure file of the package doesn't give much information.
--- a/srcpkgs/boot-66serv/template
+++ b/srcpkgs/boot-66serv/template
@@ -1,11 +1,10 @@
# Template file for 'boot-66serv'
pkgname=boot-66serv
-version=2.4.1
+version=3.0.0
revision=1
build_style=gnu-configure
-configure_args="--HOSTNAME=!voidlinux --TTY=!4
- --KEYMAP=!us --TZ=!Europe/Madrid"
-make_install_target="install install-man install-html"
+configure_args="--HOSTNAME=!voidlinux --TTY=!4 --KEYMAP=!us
+ --TZ=!Europe/Madrid"
hostmakedepends="lowdown"
makedepends="file"
depends="s6-linux-utils s6-portable-utils 66 66-tools virtual?awk"
@@ -15,13 +14,13 @@ maintainer="mobinmob <[email protected]>"
# The 66boot-* utilities are under BSD-2-Clause.
license="0BSD, BSD-2-Clause"
homepage="https://git.obarun.org/obmods/boot-66serv"
-conf_files="/etc/66/rc.local"
-distfiles="https://git.obarun.org/obmods/boot-66serv/-/archive/v${version}/boot-66serv-v${version}.tar.bz2"
+changelog="https://git.obarun.org/obmods/boot-66serv/-/blob/master/NEWS.md"
+distfiles="https://git.obarun.org/obmods/boot-66serv/-/archive/${version}/boot-66serv-${version}.tar.gz"
checksum=3f6b7437451a1ca20820fa75d42e0165d88e2ec722fcfad1276f276a97c46a7c
+conf_files="/etc/66/rc.local"
make_dirs="/etc/runit/runsvdir/66 0750 root root"
post_install() {
-
# Install the switch-initutils core service for runit.
vinstall "${FILESDIR}"/switch-initutils 644 etc/runit/core-services 99-switch-initutils.sh
# Install the 66 wrapper for 66-boot
I'm unsure if we should ship a base-system version for the 66 init. Because then we've two packages which only differ in one dependency, but should be all the time parallel updated. Maybe we should talk to the Void maintainers for there opinion about that and if they have an idea.
I do not think 66 will ever be offically integrated in voidlinux. I am maintaining the integration bits for me and anyone that wants to have a modern and capable initsystem/service manager in voidlinux. Having said that, having these packages is the most clean way I know of changing init systems. See the effort for alternatives (that went nowhere): https://github.com/void-linux/void-packages/pull/29115
The ! is to ensure that the values do not stay in the environment. It is not absolutely necessary, but nice to have.
I do not think 66 will ever be offically integrated in voidlinux. I am maintaining the integration bits for me and anyone that wants to have a modern and capable initsystem/service manager in voidlinux.
I see where you want to go with that. These new packages ensure that you are the maintainer and no Void maintainer need to worry about tinkering. With that new knowledge I endorse that approach.
Having said that, having these packages is the most clean way I know of changing init systems. See the effort for alternatives (that went nowhere): #29115
Thank you for the link to the PR. I can understand both sides and as stated above understand the approach you've chosen here.
The ! is to ensure that the values do not stay in the environment. It is not absolutely necessary, but nice to have.
Oh good to know. Am I assuming correct that the values in the [] of each line in the configuration file are showing the default value for the argument? If so, could we remove the KEYMAP argument in the template? Are the TTY and TZ arguments necessary for the building process?
Oh good to know. Am I assuming correct that the values in the
[]of each line in the configuration file are showing the default value for the argument? If so, could we remove theKEYMAPargument in the template? Are theTTYandTZarguments necessary for the building process?
The configuration file for the boot@ service contains by default all possible keys.
That may change in the future but the upstream logic is to be explicit in configuration. In order to prevent anything missing that may result in weird behaviour, I have created a way to test the configuration (see here) and missing keys is an error.
The configure arguments in the template are just the default values that the void configuration has, nothing more. They are there only to ensure that the default configuration matches the voidlinux default one.
66boot-rcdotconf can populate the configuration with the values from the void /etc/rc.conf file and 66boot-storage-autoconf finds the correct values for ZFS,BTRFS etc.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.
...
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.