>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 skarnet.org
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 - 18:11:40 UTC