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 goals. ~~Brad Grissom On Fri, Oct 27, 2017 at 12:11 PM, Laurent Bercot < [email protected]> 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 > >
