Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Vagrant Cascadian]

On 2019-07-09, Francesco Poli wrote:
> On Wed, 19 Jun 2019 08:39:50 +0200 Salvatore Bonaccorso wrote:
>
> [...] 
>> On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> [...]
>> > We could also just not accept .buildinfo uploads when they don't contain
>> > useful information about published binaries, that is for source-only
>> > uploads.
>> > 
>> > Maybe I should reenable the check for this at least on security-master?
>> > It was rejecting uploads that are okay for unstable/experimental so I
>> > disabled it again the last time.
>> 
>> Thank you I think that would be a good compromise. Source-only uploads
>> remain possible for security uploads,
> [...]
>> and instead uploads which
>> contain a buildinfo file rejected giving the uploader a explanation
>> why, and the possiblity to just reupload a "proper" source only one.
> [...]
>
>
> Hello all,
> sorry for adding noise to this long discussion.
>
> Maybe it's a naive question: what's the use of including a .buildinfo
> file into a source-only upload? Is it superfluous?

It's an attestation from the uploader that they built the package, what
the hashes of their build are, and the build environment used to produce
those binary packages. If there are differences between the buildd build
of the package and the uploader's build of the package, it may be
possible to compare the results.

I usually use sbuild's --source-only-changes feature to produce a
.changes that also includes the .buildinfo that produced my local debs
without uploading the actual .deb files to the archive.

This is certainly desireable from a reproducible builds perspective.


> If it's indeed superfluous and it also causes issues on some queues,
> maybe source-only .changes files should _never_ include .buildinfo
> files...

.buildinfo files without any hashes of .deb files do seem less useful,
unless you consider the building of the .dsc as a build process
itself.


> But dpkg-genchanges shipped in dpkg-dev/1.19.7 seems to
> include .buildinfo files into every .changes file (even for source-only
> uploads):
>
> [snip from /usr/bin/dpkg-genchanges]
> 317     if (defined $file->{package} && $file->{package_type} eq 'buildinfo') {
> 318         # We always distribute the .buildinfo file.
> 319         $checksums->add_from_file("$uploadfilesdir/$f", key => $f);
> 320         next;
> 321     }
> 322 
> 323     # If this is a source-only upload, ignore any other artifacts.
> 324     next if build_has_none(BUILD_BINARY);
>
> This puzzles me.
>
> Would it be better, if dpkg-genchanges completely refrained from
> including .buildinfo files into source-only .changes files?

Or calling the .buildinfo by a different name, e.g. source.buildinfo or
source-arch.buildinfo, etc.


> At the same time, dak could reject any source-only upload which also
> include a .buildinfo file.

I hope this doesn't end up being the solution.


Though a workable solution would be really welcome at this point...


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20190708/4b043507/attachment.sig>