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

Jérémy Bobbio lunar at debian.org
Fri Nov 6 12:19:56 UTC 2015


Johannes Schauer:
> Lunar:
> > 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`.

Thanks for the explaination.

> 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.

I've changed the `if` to use $changelog->{'Binary-Only'}, but it was
already working as intended. The code read as follow:

    my $sourceversion = $changelog->{'Binary-Only'} ?
                        $prev_changelog->{'Version'} : $changelog->{'Version'};
    my $binaryversion = $changelog->{'Version'};
    […]
    if ($binaryversion ne $sourceversion) { # handle binNMU

> 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.

The naming is coming straight from dpkg-genchanges, so both should be
changed if you fill they are ill-named.

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20151106/f8dfe1b2/attachment.sig>


More information about the Reproducible-builds mailing list