State of projects

From: Laurent Bercot <>
Date: Sun, 02 Feb 2020 09:34:30 +0000


  A small update on my current projects.

  - Most important packages are due a new release. If only
to fix a bug that prevents them from properly installing shared
in some cases.

  - The release hasn't been cut yet because things are still evolving and
I don't want to tag a release right before I need to add some
functionality. (Which, by Murphy's law, always happens anyway.)

  - Everything is available, and builds, on the projects' git head. If
you build from git, please be aware that you always need the latest
version of all the software in the dependency chain.

  - Some things are *only* available from git because the project they're
a part of is much bigger and far from complete, but pieces of the
functionality are already in.

  And for some specifics:

  - The next execline release has been ready for some time and just needs
some external testing. (Hint, hint.) The new thing is a posix-umask
program. When it's released, execline will be fully POSIX-compliant
(when built with the --enable-pedantic-posix option).
  As an aside, posix-umask was a lot of fun to write. Unlike posix-cd.

  - The next s6 version, among other things, has an option to disable
its dependency on execline, which hopefully will alleviate a lot of
the FUD surrounding it. Of course, disabling the execline dep will make
some minor functionality unavailable. And since s6-log is vital, there
is a new '?' s6-log directive to launch a processor under /bin/sh.

  - The next s6-linux-init has options that make it usable in containers.
The plan is to use it to work on a new version of s6-overlay that would
be lighter, faster, and less clunky.

  - Following a discussion that happened here last December, there is a
new s6-frontend git repository, which currently only holds a series of
binaries designed to provide daemontools- and runit-like interfaces to
s6 programs. The emulation is not perfect, in particular lots of runit
interfaces cannot be exactly mapped to s6 interfaces because the
architecture is too different, but the main ones are there. So if you
are used to controlling your services with sv, you can switch to s6
and keep using sv while porting your scripts (and getting used) to the
native s6 interfaces.

  Nothing's decided yet, but I may embark on a programming project for
one year or so for a professional contract within the next month, which
won't leave me many programming brain cells for So, if you
have feature requests, or bug-reports, things I forgot to integrate, or
anything to send me, now would be the time: I'd like to cram as much
minor stuff as possible into the next releases before a potentially
dormant period.

Received on Sun Feb 02 2020 - 09:34:30 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC