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: > > Any news regarding this proposal from Ansgar? We were biten now > > several times already by this (e.g. php update, curl via > > security.d.o). > > Guilem, what's your stance on this bug?
I think it should be fixed. I've just not come up with something that would seem a generic/clean way to do that. :( > 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? Renaming the arch buildinfo to _source.buildinfo seems wrong, and even then I'm not sure how to cleanly transfer that knowledge from dpkg-buildpackage to dpkg-genbuildinfo. 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] Perhaps just using the maintainer email address might be enough though, the one from the -m option or from the changelog, which AFAIR buildds do set? But this seems like it can produce quite ugly filenames: pkgfoo_1.0.0-1_mips64el_buildd_mipsel-mipsel-sil...@buildd.debian.org.buildinfo not to mention that both of these "break" the conventional pattern, which is still used by things like the debian/files parser and injector. Perhaps the simplest and more correct might be to name it using something like source+amd64 as the arch name, which seems like a dubious arch, but at least is accurate and might be trivial to implement, taking care of not ending up with such fake arch in unexpected places… Thanks, Guillem
