-- John O'Meara On Fri, Oct 27, 2017, 2:11 PM Laurent Bercot <ska-supervision_at_skarnet.org> 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 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 - 20:56:49 UTC
This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC