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

Vagrant Cascadian vagrant at debian.org
Tue Aug 14 19:21:57 BST 2018


On 2018-03-01, Guillem Jover wrote:
> On Thu, 2018-03-01 at 15:22:30 +0000, Holger Levsen wrote:
>> On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
>> We (reproducible builds) really dont want "our" tools (=.buildinfo files)
>> to cause grief to other teams in Debian, and especially not on a regular
>> basis... so as a first step to fix this, I'd like to collect opinions
>> how to best fix this issue here.
>
> The problem got introduced when I proposed changing the filename
> format, and dropping the annoying timestamp. I also though there was
> talk at some point initially about DAK renaming those files to cope
> with possible multiple uploads if the conflicting names?

It seems DAK is doing this, at least in some cases:

vagrant at coccia:/srv/ftp-master.debian.org/buildinfo/2018/08/01$ ls /srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai*amd64*

/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai_0.1.28-1_amd64.buildinfo
/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai_0.1.28-1_amd64.buildinfo.0

I'm fairly sure in this case the .0 one is from the buildd.

Could something similar be done with the security and other upload
queues? maybe even appending .quename.N or something. e.g. security.0.


> I guess, the ideal solution would be to qualify the buildinfo file
> with the builder user and hostname, because that in a way denotes the
> build environment. But that seems like too much leakage. As in:
>
>   pkgfoo_1.0.0-1_mips64el_username at hostname.buildinfo

What about having an option to enable this, and the buildd's would
enable it, and it otherwise defaults to false?


Do binNMUs produce a distinct .buildinfo filename? I seem to recall
local builds with sbuild producing an identical .buildinfo filename to
the regular build using --append-to-version and re-building the .dsc,
but I'm not sure about how the official buildds work with binNMUs.


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


More information about the Reproducible-builds mailing list