Re: s6-log configure "current" dir separate from archive dir

From: John O'Meara <>
Date: Fri, 27 Oct 2017 20:56:49 +0000

see also

it has bit bake files for most of the skarnet packages.

It's a bit out of date (life has been busy lately) ; pull requests are

John O'Meara
On Fri, Oct 27, 2017, 2:11 PM Laurent Bercot <>
> >My RAM-disk is in /run and logging to two separate dirs is of no help
> >because "current" is duplicated in both:
>   Hi Brad,
>   What you want can be achieved by simply writing the output of the
> processor to your archived files directory, ignoring the processor's
> original stdout. This will create an empty archive in the logdir,
> which you can rotate away immediately by telling s6-log you don't
> want any archived files in the logdir (via n0).
>   So I would do something akin to this:
>   s6-log -b n0 s5242880 !./data/processor /run/yourlogdir
>   And ./data/processor, if you want to keep s6-log's naming scheme,
> could look like:
> #!/bin/execlineb -P
> # s6-clock is from s6-portable-utils
> backtick -n NOW { s6-clock }
> importas -u NOW NOW
> redirfd -w 1 /appdata/yourarchivedir/${NOW}.s
> xz
>   You can also fit the whole script into the !processor argument in
> the s6-log command line; I just separated it for better readability.
> >Also, as a side note, I've ported skalibs, execline, and s6 to the
> >embedded
> >build system Yocto (OpenEmbedded/BitBake) for use on embedded ARM
> >systems.
>   Nice! Thanks a lot for this.
> >  I could submit a
> >pull request, but I'm not sure where to submit them.  I suppose the
> >respective .bb files could be checked into each repository.  This would
> >be
> >Laurent's call.
>   My position is that the original repository and tarballs should only
> contain mechanism, not policy - so they shouldn't contain distribution-
> specific files: upstream should remain agnostic. If I started including
> files to accommodate one distribution, I would need to cater to *all*
> distributions, in the name of fairness; that is a burden that no
> upstream can reasonably shoulder, so no upstream does, and so they
> favor some distributions over others, and that increases fragmentation
> of the free software base - which is incredibly damaging. I do not
> want to add to that problem.
>   So, despite sincerely appreciating your work on bitbake files, I
> just cannot add them to the upstream repositories. The right place
> to store those files is in distributions using Yocto, just as the right
> place to store APKBUILD files is in Alpine's aports system, the
> right place to store debian/ information is in Debian packages, and
> so on.
>   If the idea of a repository hosting build recipes for
> packages for various distro-building systems appeals to some
> people, it's certainly be possible to create one. However, it would
> definitely have to be community-based - I can create it and give
> push rights, but people need to actually contribute and maintain
> the recipes. :)
> --
>   Laurent
Received on Fri Oct 27 2017 - 20:56:49 UTC

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