[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