Re: runit patches to fix compiler warnings on RHEL 7
Laurent Bercot: It looks like several distributions have their own version of runit; they are maintained by the distros themselves. Further to all that: I believe, although things may have changed, that the Debian maintainer for runit is open to patches. * https://tracker.debian.org/pkg/runit
Re: runit patches to fix compiler warnings on RHEL 7
Some of those are common. I looked at similar stuff in daemontools, where runit got some of this code from, when I packaged it up with some of the other Bernstein softwares some years ago. However, you have missed the point of HASSHORTSETGROUPS. There's no point in having conditionally compiled code selected by it that uses gid_t in both codepaths. If you are going to use gid_t, you do not need the HASSHORTSETGROUPS mechanism in its entirety. Think about what it does. * http://jdebp.uk./Softwares/djbwares/ In the nosh toolset, I have no such mechanisms. The code uses the types, with a std::vector for the call to setgroups() in setuidgid-fromenv for example. The only similar mechanism picks between the very old waitpid() function and the newer (but still old, because it was SVR4) waitid() function. And only OpenBSD ever needs the code to use the former, in practice.
Re: runit patches to fix compiler warnings on RHEL 7
Jan Braun: 2) runit has manpages. s6 has HTML. :( Daniel J. Bernstein had something to say on that subject, two decades ago. See the "Notes" section of http://cr.yp.to/slashdoc.html . I generate both manual pages and HTML from a common DocBook XML master in the nosh toolset. And the DocBook XML is itself readable directly with a WWW browser. http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml is a copy of one such DocBook XML master, for example. It's on the WWW, and the packages also install it locally, for off-line reading. M. Pape did some of the manual pages for some operating system's versions of daemontools, converting M. Bernstein's HTML pages into roff. For djbwares I converted everything into DocBook XML, and the same holds for djbwares as for the nosh toolset. There is a DocBook XML master that one can view in a WWW browser directly (both on-line and off-line), generated HTML pages, and generated manual pages readable with man. http://jdebp.uk./Softwares/djbwares/guide/commands/setuidgid.xml is a copy of one such DocBook XML master, for example. This is the source for the "man setuidgid" manual and the source for http://jdebp.uk./Softwares/djbwares/guide/setuidgid.html . I even filled in the manual pages that M. Pape hadn't done and that M. Bernstein hadn't originally written in HTML, and updated some of the doco. See http://jdebp.uk./Softwares/djbwares/guide/commands/caldate_easter.xml and http://jdebp.uk./Softwares/djbwares/guide/commands/dnscache.xml for examples of that.
Re: s6 usability
Samuel Holland: Then, with the symlinks, s6 could "provide" virtual/daemontools. I do this with the nosh toolset already, for Debian. Several of the "shim" and "-run" packages, which are separate from the main tools packages, "provide" stuff. I even have a things such as a dummy "nosh-logrotate-shims" package that provides "logrotate", which is required by things like the "rabbitmq-server" package but isn't actually needed at all in order to run rabbitmq-server under nosh service management. And a "nosh-run-bcron" that "provides" "bcron-run". * http://jdebp.uk./Softwares/nosh/debian-binary-packages.html#Toolsets * http://jdebp.uk./Softwares/nosh/debian-binary-packages.html#run
Re: runit patches to fix compiler warnings on RHEL 7
On 12/04, Jonathan de Boyne Pollard wrote: > Jan Braun: > > > 2) runit has manpages. s6 has HTML. :( > > > Daniel J. Bernstein had something to say on that subject, two decades ago. > See the "Notes" section of http://cr.yp.to/slashdoc.html . > > I generate both manual pages and HTML from a common DocBook XML master in > the nosh toolset. And the DocBook XML is itself readable directly with a > WWW browser. > http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml is a > copy of one such DocBook XML master, for example. It's on the WWW, and the > packages also install it locally, for off-line reading. I still like having man pages. It's often just easier to type "man " than to find the local (or remote) HTML document and open it in a web browser. However, I agree that it's very nice to have HTML as well. So, I like to have both! It seems good to generate them from a single source format. I would like DocBook except that the toolchain seems *so* heavy. And if you want to generate PDFs, it's even heavier. What about mandoc? http://mandoc.bsd.lv/ It seems pretty lightweight, and from an mdoc source, it can generate ASCII, HTML, man, PDF, and PostScript. Lewis
Re: runit patches to fix compiler warnings on RHEL 7
What about mandoc? The colour of this bikeshed is not up for debate. If you want man pages for skaware, provide me with: 1. a reasonable source format (e.g. not roff, so mandoc is right out) 2. a tool that can be built using *only* a C compiler (so as to keep bootstrapping skaware easy), that converts the source format into man pages *and* into HTML 3. the actual contents of the man pages you want, in that source format. (https://git.sr.ht/~sircmpwn/scdoc fits 1. and 2., but its author wasn't motivated enough to do 3.) Until then, any further discussion of documentation formats is pure noise, I've heard it all before - several times - and it has the potential to piss me off VERY quickly. -- Laurent
Re: s6 usability
From a Linux distribution perspective, there's also the question of if s6 can be made a drop-in replacement for daemontools, since it does follow djb's naming scheme. In gentoo, there are various packages that depend on virtual/daemontools; for example, the nullmailer test suite uses ipcserver. From a quick comparison of the documentation, it looks like s6 only adds options, and remains compatible with the daemontools options. Yes, and that was on purpose, but it's only true with the "official" API and not with the internals. For instance, the supervise/status file isn't compatible. So would it be valid/acceptable for a distribution to create unprefixed symlinks to the s6-* binaries? It looks like this would mostly only work for the subset of the binaries that implement daemontools functionality; some others (s6-setsid, s6-sudo) would have naming conflicts if they were not prefixed. s6-setsid can be symlinked as pgrphack: same functionality, different name. The same way that s6-log can be symlinked as multilog. Then, with the symlinks, s6 could "provide" virtual/daemontools. Maybe this would also help discoverability (the issue at hand). Maybe the inconsistency would cause more harm than good, and the symlinks should be "for compatibility only". s6 can provide at least surface compatibility with daemontools, yes. With the symlinks, it can still be a drop-in replacement (unless there are interface changes I haven't thought about). daemontools replacement is easy. The real subject is compatibility with runit, which is possible but not quite drop-in. -- Laurent
Re: runit patches to fix compiler warnings on RHEL 7
On Wed, 4 Dec 2019 10:40:14 -0600 "J. Lewis Muir" wrote: > On 12/04, Jonathan de Boyne Pollard wrote: > > Jan Braun: > > > > > 2) runit has manpages. s6 has HTML. :( > > > > > Daniel J. Bernstein had something to say on that subject, two > > decades ago. See the "Notes" section of > > http://cr.yp.to/slashdoc.html . > > > > I generate both manual pages and HTML from a common DocBook XML > > master in the nosh toolset. And the DocBook XML is itself readable > > directly with a WWW browser. > > http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml > > is a copy of one such DocBook XML master, for example. It's on the > > WWW, and the packages also install it locally, for off-line > > reading. > > I still like having man pages. It's often just easier to type "man > " than to find the local (or remote) HTML document and open it > in a web browser. I never thought about man pages until a few days ago I did some experiments with execline and had a quick question about syntax. I did man execlineb and of course got "no entry". So I fired up a browser, did a locate command, and put a path in my browser. The browser is vastly superior for learning all about unfamiliar or moderately familiar software, but for the quick lookup of something you primarily know about, there's no substitute for a quick "man execlineb". SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: runit patches to fix compiler warnings on RHEL 7
On 12/04, Laurent Bercot wrote: > > What about mandoc? > > The colour of this bikeshed is not up for debate. > > If you want man pages for skaware, provide me with: > 1. a reasonable source format (e.g. not roff, so mandoc is right out) > 2. a tool that can be built using *only* a C compiler (so as to keep > bootstrapping skaware easy), that converts the source format into man > pages *and* into HTML > 3. the actual contents of the man pages you want, in that source format. > > (https://git.sr.ht/~sircmpwn/scdoc fits 1. and 2., but its author wasn't > motivated enough to do 3.) Interesting, I hadn't heard of scdoc before. I don't see where it says it can convert the source format into HTML, though. Did I miss that? > Until then, any further discussion of documentation formats is pure > noise, I've heard it all before - several times - and it has the potential > to piss me off VERY quickly. Certainly don't want to cause trouble, and not intending to bikeshed, but I searched for "halibut" in the archive for this list as well as the skaware list and did not find that it had been mentioned, so I'll just mention that another system I've used in the past is Halibut which is lightweight and written in ANSI C: https://www.chiark.greenend.org.uk/~sgtatham/halibut/ It can generate ASCII, HTML, PDF, PostScript, man, and info. So, I think it would satisfy #1 and #2, but certainly not #3. Still, if someone wanted to do the work to provide #3 at some point, then Halibut may be a reasonable tool to consider. Lewis
Re: runit patches to fix compiler warnings on RHEL 7
The browser is vastly superior for learning all about unfamiliar or moderately familiar software, but for the quick lookup of something you primarily know about, there's no substitute for a quick "man execlineb". https://lmgtfy.com/?q=execlineb&iie=1 -- Laurent
