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@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: > > [email protected] 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
signature.asc
Description: PGP signature
