Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
carnil at debian.org
Sat Jul 28 14:56:40 BST 2018
On Fri, Mar 02, 2018 at 01:25:51AM +0100, 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:
> > > 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:
> pkgfoo_1.0.0-1_mips64el_username at hostname.buildinfo
> 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-01 at 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…
Do you know, was there any (non-logged) progress for this issue? I'm
asking back since we had for security uploads now since then several
times problems were we had to workaround it by reuploading the buildd
Thanks all for your work!
More information about the Reproducible-builds