Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

[Holger Levsen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20170902/f49cbfe6/attachment.sig>