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

[Francesco Poli]

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?

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


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?


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


Perhaps I am completely off-track.
Please someone clarify!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20190709/26a4d358/attachment.sig>