[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Raising the severity of reproduciblity issues to "important"



On Fri, Sep 01, 2017 at 06:34:38PM +0100, Ian Campbell wrote:
> On Fri, 2017-09-01 at 12:43 +0200, Helmut Grohne wrote:
> > Whatever point you were trying to make around NEW, your argument is not
> > very convincing. I think Holger is right here: Where the package is
> > built should not matter. Presence of .buildinfo and reproducibility
> > does.
> 
> Appollogies if this is covering well worn ground but does this mean we
> therefore need to check that everything referenced in .buildinfo was
> present in the archive at some point as a step during accepting a
> package (new or not new) into the archive?

well, yes, but we should check this today too, just for proper builds, 
independently of reproducible builds.

> Where "was present in the archive at some point" is a proxy for "is
> present on snapshots.d.o". If that can also be checked directly that
> might be cool, although it might be considered a bit rude to a
> maintainer to reject a package for what was a snapshot.do.o issue.

well, yes, the check should be done using a local (copy of the) snapshot.d.o
database. It's also rude to upload a package built with packages not in the
archive, and we should prevent that.

> https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles suggests that
> the build environment contains the versions of packages but not their
> hashes -- so there is a possibility that a developer might be building
> with a non-canonical version of the package. Perhaps they installed a
> local dev version of the build-dep, perhaps because they maintain both
> and we doing a quasi-simultaneous upload. That's perhaps not indicative
> of best practice, but mistakes do happen.
 
yup, and we should try to catch as many automatically as we can.


-- 
cheers,
	Holger

Attachment: signature.asc
Description: Digital signature


Reply to: