[Reproducible-builds] binNMU detection for generating Changes field in buildinfo (was: Re: binNMU or reproducible builds (choose only one))

[Johannes Schauer]

Hi Lunar,

Quoting Jérémy Bobbio (2015-09-19 16:46:36)
> Simon McVittie:
> > BinNMUs don't upload any source at all. They instruct the autobuilders
> > to run sbuild with some non-default options ("sbuild --binNMU=2
> > --make-binNMU "Rebuild with foo 3" foo_1.2-3" will result in
> > foo_1.2-3+b2_i386.changes, I think), and sbuild on each autobuilder
> > downloads the foo_1.2-3.dsc that already exists in the archive.
> > 
> > The only inherent conflict that I can see between binNMUs and
> > reproducible builds is that all attempts to reproduce the original build
> > need to prepend the same changelog entry as the original build, for
> > example by copying them from the build info that will already be
> > necessary to be able to use the same build-dependency versions.
> 
> This is already taken in account in the current `.buildinfo`
> specification [1]:
> 
>     Changes
> 
>     Close to the one in `*.changes`. When source and binary versions
>     differ, the field is added with the content of the extra changelog
>     entries.
> 
> The field is already created by the experimental `dpkg-genbuildinfo` [2].
> It is not yet implement in the `srebuild` script but it shouldn't be too
> hard.
> 
>  [1]: https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification#buildinfo_field_descriptions
>  [2]: https://anonscm.debian.org/cgit/reproducible/dpkg.git/tree/scripts/dpkg-genbuildinfo.pl?h=pu/reproducible_builds&id=c4665b80d7a042216145652ea3d1259b78ac6237#n246

I don't think this is the right way to do it. Looking at the dpkg-genbuildinfo
script, it seems that this behaviour is triggered whenever the source version
differs from the binary version. But binNMUs are not the only case for which
the source and binary versions differ. To convince yourself you can run the
following (get all packages that are not binNMUs (detected by them having a bX
at the end of their version) and which have a versioned Source field):

grep-dctrl --not --field Version --eregex '\+b[0-9]+$' --and \
	-F Source --eregex '\(' \
	/var/lib/apt/lists/http.debian.net_debian_dists_sid_main_binary-amd64_Packages \
	-n -s Package,Source,Version

It shows that there are several binary packages that have a different source
package version even though they are not binNMUs. The version of any binary
package can be done during the build with dh_gencontrol or directly via
`dpkg-gencontrol -v$version`.

The right way to find out whether a binNMU is done is to check
$changelog->{'Binary-Only'} as it is done in dpkg-genchanges. During a binNMU,
sbuild sets binary-only=yes in the top changelog entry.

In fact, what you call $binaryversion in that script is really the source
version because your $binaryversion comes from d/changelog. So maybe you want
to rename that variable. That also then remove the ambiguity from a later part
in the code when you set the Version field in the buildinfo to $binaryversion.
This is ambiguous because a source package can build binary packages of several
different versions.

Sorry, I currently don't have time to write a patch :(

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150920/785b9c31/attachment.sig>