Package: runit Version: 2.1.2-33rescan1 Severity: wishlist [moving the privite discussion on BTS after D.Bogatov request]
[Lorenzo Puliti] Hi! As already anticipated, i'm working on a converter capable of generating runscripts from systemd units. In fact it's a set of script for automating the whole process, from the downloading of the unit up to the creation of a patch suitable for BTS. The idea is to improve the converter engine and then open a mass-bug thread on debian-devel with few hundred patch provided. Unfortunately the task revealed to be more complex than I expect, so the whole project is still in WIP status, usable but one has to carefully review and integrate the runscripts. https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/next-0.2 Each script takes as argument a space separated list of basenames as the one in /etc/init.d/ (but a unit with the basename must exists) the correct order is fetch --> converter --> finalize --> hackit I'm looking for ideas, suggestions or bug report to improve the code ( watch out, the converter code is messy, I haven't had the time to do the cleanup) ; in case you are interested, attached is the list of the services that i'm using for testing Among others, i have the following questions: * does it worth the effort of making a .deb package? ( for now it's just 'git clone' and it's ready for use ) * hackit: - are patches generated like that (with diff) ok for BTS? It looks I can't preserve the file mode for example.. any better way? - should I edit the changelog? * converter: - What to do with Oneshot units? runit-init doesn't need those, but i suspect runit-sysv does.. - there are hardening features in units files, like "capabilities".. not sure those are usable in runit, but in case, should i care? - Do I need to 'set -e' in run script, or it's inherited from invoke-run? Anyway, if you want to contribute directly I can move the project under /runit namespace in Salsa. Lorenzo [Dmitry reply] > Hi! > > As already anticipated, i'm working on a converter capable of generating > runscripts from systemd units. In fact it's a set of script for automating > the whole process, from the downloading of the unit up to the creation of a > patch suitable for BTS. > The idea is to improve the converter engine and then open a mass-bug thread > on debian-devel with few hundred patch provided. I doubt it will be possible. For as little runscripts I managed to push (tor, irqbalance, acpid), there are always some quirks. > Unfortunately the task revealed to be more complex than I expect, so the > whole project is still in WIP status, usable but one has to carefully > review and integrate the runscripts. > > https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/next-0.2 > > Each script takes as argument a space separated list of basenames as the > one in /etc/init.d/ (but a unit with the basename must exists) > the correct order is fetch --> converter --> finalize --> hackit > > I'm looking for ideas, suggestions or bug report to improve the code ( > watch out, the converter code is messy, I haven't had the time to do the > cleanup) ; in case you are interested, attached is the list of the services > that i'm using for testing Some experiments. Created runscript for mariadb. It got following line /bin/sh -c "systemctl unset-environment _WSREP_START_POSITION" || exit 160 But before patch can be submitted to maintainer, automatic testing is must. I suggest salsa.debian.org/kaction/daemons. Some suggestions on code: * you seem to invent yet-another templating engine with those #dep1# tokens. I suggest you to re-use something already established, like mustache or jinja2. bin:ionit may be interested. * please do not print "Starting $NAME". It goes to log, quite pointless and may confuse scripts/tools that want to analyze log. * please make scripts return != 0 in case of failure. `./fetch foo' exiting with 0 is very confusing. > Among others, i have the following questions: > * does it worth the effort of making a .deb package? ( for now it's just > 'git clone' and it's ready for use ) No, I do not think so. You will have to deal with Lintian and FTP team for little gain. > * hackit: > - are patches generated like that (with diff) ok for BTS? It > looks I can't preserve the file mode for > example.. any better way? Well, they are fine, but inconvenient. Ideal patch is one maintainer can just 'git am'. Patches generated with diff(1) or debdiff(1), require more work: * patch -p1 < your_patch.patch * git add . * git commit -m '<Invent commit message>' Personally, I find last part the most tiresome. May I suggest using git? `debcheckout`, if maintainer uses Salsa, or `gbp import-dsc apt:foo` otherwise. Extra points for making Salsa merge request in addition to BTS bug. > - should i edit the changelog? Definitely not. Otherwise your patch will stop applying clean after a release. Also, many (myself included) use `gbp dch` to regenerate changelog before release. > * converter: > - What to do with Oneshot units? runit-init doesn't need those, > but i suspect runit-sysv does.. I think, one-shot units can be translated to #/usr/bin/env /lib/runit/invoke-run ... do stuff ... exec sv down . > - there are hardening features in units files, like > "capabilities".. not sure those are usable in runit, but in > case, should i care? I ignore them. Actually, when I create runscripts, I read init.d script, not unit file. Simplier for human, impossible for machine, yeah. > Do I need to 'set -e' in run script, or it's inherited from invoke-run? No, it is not. Do you think invoke-run should? > Anyway, if you want to contribute directly I can move the project > under /runit namespace in Salsa. I am fine with patches. Code review is good thing. PS. You know that I already got runscript into src:tor and src:acpid? -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit depends on: ii libc6 2.28-10 ii runit-helper 2.8.13.2 ii sysuser-helper 1.3.3 Versions of packages runit recommends: ii runit-init 2.1.2-33rescan1 runit suggests no packages. -- Configuration Files: /etc/runit/2 changed [not included] /etc/runit/3 changed [not included] -- no debconf information -- debsums errors found: debsums: changed file /sbin/update-service (from runit package)
