Runit 2.1.2 was released 10th August; the announcement can be found in the URL field. This release contains only minor bugfixes/additions, renaming the ebuild works.
All, Our runit ebuild does some things I would like to change with the version bump, which will allow me to fix bug #354053 and bug #409469 by making the runlevel setup user configurable and moving us to be more in line with upstream's recommendations for how runit services should be installed. The first change is to move /etc/runit/runsvdir/all to /etc/sv, which is the upstream recommended location for runit service directories [1]. Along this same line, /var/service should be /etc/service since we do our best to comply with fhs where possible, and /etc is where the default service directory should be in that case [2]. I have found ways to make these changes transparently. That leaves me with one question about this version bump. Upstream does document runlevels. However, they seem to recommend a single flat service directory with all of the services to monitor. Since The older runit ebuilds only set up one runlevel with getty's, it seems sensible to use only a flat service directory on new installs and to possibly recommend that everyone move to this setup. Thoughts? [1] http://www.smarden.org/runit/faq.html [2] http://www.smarden.org/runit/upgrade.html
Another good reason for moving to a single directory of services instead of runlevels is that if people want to use runit as a supervisor for an OpenRC system, it is best to have all of the sevices we are monitoring in one directory.
the userbase for this pkg is small, so feel free to make changes to better align with upstream when it makes sense wrt service levels, isn't it possible to support both ? or at least, while the default might be to search one dir, can't you tweak knobs in the conf.d so that you can use whichever mode you want ?
Hi, I imagine some people will be compiling runit with dietlibc and USE="static", since upstream recommends this on its website, and other distributions ship with a statically linked /sbin/runit. It might be a good idea to add the following to src_prepare(): # see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726008 [[ ${COMPILER} == "diet" ]] && use ppc && filter-flags "-mpowerpc-gpopt"
Just to clarify the above, I downloaded runit-2.1.2.tar.gz and grepped for power, eg: find ./admin/runit-2.1.2/ -type f -print0 | xargs -0 grep 'power' and didn't see anything about this ppc bug. I also looked at the changelog. I believe it's fixed in the Debian package, not in the source.
(In reply to Andrew M. from comment #4) i don't think dietlibc is common at all -- there are plenty of better alternatives. we also don't want to grow this kind of super specific cruft in ebuilds.
(In reply to SpanKY from comment #6) Perhaps you should contact upstream and ask them to stop recommending dietlibc. William, can you give some thought as to whether IUSE should be +static. As I mentioned above, other distributions I've used (Finnix and Void Linux) ship with a statically linked /sbin/runit; it seems sensible for PID1.
Version 2.1.2 is now in portage, thanks for the report.
(In reply to SpanKY from comment #3) > wrt service levels, isn't it possible to support both ? or at least, while > the default might be to search one dir, can't you tweak knobs in the conf.d > so that you can use whichever mode you want ? I don't know what you mean by conf.d; there isn't one for runit. The runlevels are controlled by how the services are linked. /etc/sv is like /etc/init.d in OpenRC; that is where the service directories go. Whether you use runlevels or not is controlled by what /etc/service is. If it is a flat directory with symbolic links, runit starts and supervises all services linked into that directory. If it is a link to another directory, that is how you set up runlevels [1]. [1] http://smarden.org/runit/runlevels.html (In reply to Andrew M. from comment #4) > I imagine some people will be compiling runit with dietlibc and > USE="static", since upstream recommends this on its website, and other > distributions ship with a statically linked /sbin/runit. > > It might be a good idea to add the following to src_prepare(): > > # see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726008 > [[ ${COMPILER} == "diet" ]] && use ppc && filter-flags "-mpowerpc-gpopt" I added the test, now I will add the comment after I finish with this bug. (In reply to Andrew M. from comment #7) > (In reply to SpanKY from comment #6) > > Perhaps you should contact upstream and ask them to stop recommending > dietlibc. > > William, can you give some thought as to whether IUSE should be +static. As > I mentioned above, other distributions I've used (Finnix and Void Linux) > ship with a statically linked /sbin/runit; it seems sensible for PID1. I can give it some thought, sure. We don't do that for any of our other inits, but it may make some sense.
With 2.1.2, the default method of setting up runlevels is the way upstream seems to set things up initially, one service level with all services. However, if folks want to, feel free to open another bug and give me an idea of what you would like if it is something different and we can go from there. :-)
(In reply to Andrew M. from comment #7) runit is not special and does not qualify for an exception to IUSE=+static
I had to create a symlink from /bin/chpst to /usr/bin/chpst to make the gettys work, also /etc/sv/initctl/run didn't have the x bit set. Did this occur to anyone else or am I the only one?!?