[Reproducible-builds] Raising the severity of reproduciblity issues to "important"

[Matthias Klose]

On 08/23/2015 12:48 PM, Chris Lamb wrote:
> Hi -devel,
> 
> The reproducible-builds team are currently contributing patches with
> "wishlist" severity.
> 
> This is because it is not currently possible to build reproducible
> packages within sid itself - we maintain a separate repository whilst
> our changes to the toolchain are pending review and consultation.
> 
> Filing these bugs with a higher severity -- which would require
> developers to use this repository to fully test any modifications --
> would be unacceptable.
> 
> However, based on an informal survey at DebConf (and to reflect the
> feeling towards software reproducibility in the free software community
> in general) unless there are strong objections I intend to raise the
> severity of these wishlist issues to "important" once the toolchain
> changes to dpkg and debhelper land in sid.

I don't like this kind of "ad hoc" decision.  Sure, there are reasons to raise
the severity for this particular category, however we have a lot of issues that
affect a lot of packages, and which are not fixed or don't get any review for a
long time.  So what about identifying categories which should be fixed in any
case, and maybe which should have special rules for accelerated NMUs and such?
Categories would include:

 - running dh-autoreconf during the build to accommodate new archs.

 - respecting dpkg-buildflags for current "security" settings, and
   obsoleting the old manually coded -O0/-O2 for debug builds.

 - respecting DEB_BUILD_OPTIONS=parallel=<n>. While this doesn't
   improve package quality, it will help to better use buildd resources.
   almost every architecture now uses multi cores. It will help Debian
   to faster process binNMUs / transitions at least for release archs.

 - verbose build logs on the buildds. Doesn't add to quality immediately,
   but from my point of view helps a lot for analyzing build failures
   and other issues.

 - cross build-ability. surely this wouldn't be important, however
   would raise awareness for this requirement.

The good thing for the reproducibility issues is that you have an easy way to
find these.  It's maybe more difficult for the issues mentioned above, but maybe
not impossible.

So what about generalizing these categories into something which doesn't need
asking again for every single package to be applied?

Matthias