Thanks for the execline processor Laurent.  It appears I lose my n20 and
S15728640 ability from my original line:

s6-log -b n20 s5242880 S15728640 !"xz" /appdata

Meaning now my /appdata directory could fill up.  In order to get my cake
and eat it too (not have /appdata fill up), I thought maybe a execline
processor that runs rsync or some such thing.  The idea being to mirror the
archive files from my RAM-disk in /run to my archive in /appdata.

By the way my C hack to s6-log would be to rename "current" (and
"previous", "lock", etc.) to say "link/current" and then make a symlink:

/appdata $  ln -s /run link

Thanks to John O'Meara for the bitbake repo reference.  And thanks to
Laurent for the execline example, I think I have what I need to achieve my

~~Brad Grissom

On Fri, Oct 27, 2017 at 12:11 PM, Laurent Bercot <> wrote:

> 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

Reply via email to