"William D. Jones" <thor0505%comcast.net@localhost> writes: > ======= 8 extra files in DESTDIR ========= > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > ------------------------------------------ > ./usr/X11R7/lib/libxcb-randr.so.0 > ./usr/X11R7/lib/libxcb-randr.so.0.1 > ./usr/X11R7/lib/libxcb-sync.so.0 > ./usr/X11R7/lib/libxcb-sync.so.0.1 > ./usr/X11R7/lib/libxcb.so.1 > ./usr/X11R7/lib/libxcb.so.1.1 > ./usr/lib/libssh.so.22 > ./usr/lib/libssh.so.22.0 > ========= end of 8 extra files =========== That's not a kernel version change; that's a shlib major version bump. It's just that now there is libssh.so.23, so .22 is then cruft. > For space reasons, I do not capture the output from each invocation of > build.sh each night :P. I also cannot always check the build logs from > my cron scripts each night (sometimes once a week). I've been looking > into trying to autodetect kernel version upgrades so I can full > rebuild without needing to manually run the script. The best I've come > up with is the following grep command: You can rm -rf the destdir before starting. Probably that won't slow you down all that much (try it and report back, especially if I'm wrong :-). > ./gen_i386build.sh -u 2> /dev/null | grep -q "Files in DESTDIR but > missing from flist."; echo $? > > Ignoring the contrived example above, this requires saving output to > an intermediate file; I need both the output of build.sh and grep to > detect whether to rebuild, fail, or continue, so a pipe in non-bash > will not work in my cron scripts. While I can't guard against all > errors, is it possible to programmatically (and reliably) detect when > a kernel version upgrade occurred so I can tailor my cron scripts to > do a full rebuild during those cases? Even better would be to detect a > kernel version upgrade BEFORE beginning the builds :). Presumably you can save the output, grep and rm the files, and rerun, and then delete the output. or only save the most recent. I have logs for a dozen builds for 5 arches. It's only 3.2 GB, so I don't understand why you don't want to keep all that :-) Seriously, I never realized how big the output was. With gzip, it's only 200 MB. So perhaps you can first port updated zfs and then the logs will fit. But really piping through gzip might be a good strategy.
Attachment:
pgpEomxMCLSuU.pgp
Description: PGP signature