Hi Guillem, On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote: > > during discussing #844431 it became clear, that some information about the > > running kernel should be included in .buildinfo files, as this can affect > > the > > build. > > It is actually not very clear to me. The examples provided there seem > bogus: > > * Any build that relies on the currently running kernel for the > resulting object is broken, and needs to be fixed. The host kernel > might/should/will have nothing to do with the build one. > * Builds that embed build kernel information should be fixed to not > do that, as that information should be irrelevant for the generated > object. > * Builds breaking on kernel changing the version schema should only > affect things such as kernel modules or similar, anything else is > also broken. Any kernel version checks, if at all, should always > be done at run-time. > * Builds breaking due to disabled functionality in the current running > kernel should be considered broken. In case of the test suite > failing, that should be fixed to skip those tests gracefully. In > case of the build system breaking, that should be reworked to not > use that functionality (which I'd assume is unportable?).
good points. (just having information on the kernel *can* be helpful, even
though it *should* not matter, but when it (wrongly) does, it is helpful…)
> > For a start, including the output of "uname -s -r -v -m -i -o" (so basically
> > uname -a without the hostname) would be better than the current status quo,
> > though it would probably be even nicer to also include a hash of
> > /proc/config.gz or maybe even the whole thing.
>
> In addition to the above, I'm actually somewhat uncomfortable with this
> request, as it looks like a massive privacy leak. Compared to package
> lists and versions, which are actually requested by the package being
> built and might not have anything to do with the main system this
> build was being run on (say a chroot for example), or might get deleted
> immediately after the build. The kernel tends to be a system-wide
> resource, that even if upgraded does not mean it will be running (until
> a reboot).
on reflection I agree that the privacy implications are too bad.
[more insightful stuff I cannot disagree with removed.]
> Given all the above, I'm inclined to just close the report? :)
Probably, maybe, just please keep it open for another week or two for now, so
others can chime in…
Thanks!
--
cheers,
Holger
signature.asc
Description: Digital signature
