Debian Bug report logs - #869184
dpkg-buildpackage: Source uploads including _amd64.buildinfo cause problems

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg (PTS, buildd, popcon).

Reported by: Ansgar Burchardt <ansgar@debian.org>

Date: Fri, 21 Jul 2017 10:36:02 UTC

Severity: important

Found in version dpkg/1.18.24

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Fri, 21 Jul 2017 10:36:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 21 Jul 2017 10:36:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: dpkg
Version: 1.18.24
Severity: important

source-only uploads sometimes include a _amd64.buildinfo (or other
architecture).  This sometimes causes problems as the amd64 buildd
upload will include a file using the same name.

In particular, it breaks any uploads going to policy queues
(e.g. security's embargoed, proposed-updates) and the sync of uploads
from security-master to ftp-master.

The same is true for maintainer source+all uploads: if the source also
builds arch-indep binaries, the .buildinfo files from maintainer and
buildd might end using the same name.

Please don't include _amd64.buildinfo in source-only or source+all
uploads.  Just changing the name is enough to make me happy
(e.g. _source.buildinfo).

It might also be worth having an option to change the suffix of all
such names (.changes, .buildinfo) easily so that buildds could use
_${arch}-buildd.changes or something.

Ansgar

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Thu, 05 Oct 2017 19:09:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 05 Oct 2017 19:09:03 GMT) (full text, mbox, link).

Message #10 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi,

> source-only uploads sometimes include a _amd64.buildinfo (or other
> architecture).  This sometimes causes problems as the amd64 buildd
> upload will include a file using the same name.

This broke two uploads to the security archive again.  That's not great,
so this bug really should be fixed in stable too (or we could disallow
source-only uploads, or source-only uploads including a .buildinfo for
stable).

Ansgar

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Thu, 19 Oct 2017 13:15:02 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 19 Oct 2017 13:15:02 GMT) (full text, mbox, link).

Message #15 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi Ansgar,

On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> Hi,
> 
> > source-only uploads sometimes include a _amd64.buildinfo (or other
> > architecture).  This sometimes causes problems as the amd64 buildd
> > upload will include a file using the same name.
> 
> This broke two uploads to the security archive again.  That's not great,
> so this bug really should be fixed in stable too (or we could disallow
> source-only uploads, or source-only uploads including a .buildinfo for
> stable).

and unfortunately another one (libvirt). Should we maybe disalow
source-only uploads including a buildinfo file for now? Completely
disalowing source-only uploads would be a major drawback IMHO.

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Wed, 24 Jan 2018 15:09:04 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 24 Jan 2018 15:09:04 GMT) (full text, mbox, link).

Message #20 received at 869184@bugs.debian.org (full text, mbox, reply):

Hello,

On Thu, Oct 19, 2017 at 03:13:15PM +0200, Salvatore Bonaccorso wrote:
> Hi Ansgar,
> 
> On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> > Hi,
> > 
> > > source-only uploads sometimes include a _amd64.buildinfo (or other
> > > architecture).  This sometimes causes problems as the amd64 buildd
> > > upload will include a file using the same name.
> > 
> > This broke two uploads to the security archive again.  That's not great,
> > so this bug really should be fixed in stable too (or we could disallow
> > source-only uploads, or source-only uploads including a .buildinfo for
> > stable).
> 
> and unfortunately another one (libvirt). Should we maybe disalow
> source-only uploads including a buildinfo file for now? Completely
> disalowing source-only uploads would be a major drawback IMHO.

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).

Regards,
Salvatore

Acknowledgement sent to Guido Günther <agx@sigxcpu.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 24 Jan 2018 15:12:03 GMT) (full text, mbox, link).

Message #25 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi,
On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> Hello,
> 
> On Thu, Oct 19, 2017 at 03:13:15PM +0200, Salvatore Bonaccorso wrote:
> > Hi Ansgar,
> > 
> > On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> > > Hi,
> > > 
> > > > source-only uploads sometimes include a _amd64.buildinfo (or other
> > > > architecture).  This sometimes causes problems as the amd64 buildd
> > > > upload will include a file using the same name.
> > > 
> > > This broke two uploads to the security archive again.  That's not great,
> > > so this bug really should be fixed in stable too (or we could disallow
> > > source-only uploads, or source-only uploads including a .buildinfo for
> > > stable).
> > 
> > and unfortunately another one (libvirt). Should we maybe disalow
> > source-only uploads including a buildinfo file for now? Completely
> > disalowing source-only uploads would be a major drawback IMHO.
> 
> 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).

Is this just a configuration thing? If so I'd say it would be good to
activate. I'm adding Thorsten to cc: since he might know.
Cheers,
 -- Guido

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Thu, 01 Mar 2018 13:12:03 GMT) (full text, mbox, link).

Message #30 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi

On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> Hello,
> 
> On Thu, Oct 19, 2017 at 03:13:15PM +0200, Salvatore Bonaccorso wrote:
> > Hi Ansgar,
> > 
> > On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> > > Hi,
> > > 
> > > > source-only uploads sometimes include a _amd64.buildinfo (or other
> > > > architecture).  This sometimes causes problems as the amd64 buildd
> > > > upload will include a file using the same name.
> > > 
> > > This broke two uploads to the security archive again.  That's not great,
> > > so this bug really should be fixed in stable too (or we could disallow
> > > source-only uploads, or source-only uploads including a .buildinfo for
> > > stable).
> > 
> > and unfortunately another one (libvirt). Should we maybe disalow
> > source-only uploads including a buildinfo file for now? Completely
> > disalowing source-only uploads would be a major drawback IMHO.
> 
> 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).

The recent xmltooling update caused the same problem :(

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Thu, 01 Mar 2018 15:27:02 GMT) (full text, mbox, link).

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 01 Mar 2018 15:27:02 GMT) (full text, mbox, link).

Message #35 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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?

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.

-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Fri, 02 Mar 2018 00:27:02 GMT) (full text, mbox, link).

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 02 Mar 2018 00:27:02 GMT) (full text, mbox, link).

Message #40 received at 869184@bugs.debian.org (full text, mbox, reply):

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@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@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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sat, 28 Jul 2018 14:00:03 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 28 Jul 2018 14:00:03 GMT) (full text, mbox, link).

Message #45 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi Guillem,

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@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@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
uploads renamed.

Thanks all for your work!

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 13 Aug 2018 18:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 Aug 2018 18:33:03 GMT) (full text, mbox, link).

Message #50 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Guillem,

people are still affected by this bug...

On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover wrote:
> 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…

could we have this simple migation for now, please? 


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
                    holger@(debian|reproducible-builds).org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Tue, 14 Aug 2018 18:27:03 GMT) (full text, mbox, link).

Acknowledgement sent to Vagrant Cascadian <vagrant@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Aug 2018 18:27:03 GMT) (full text, mbox, link).

Message #55 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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:
>
>   pkgfoo_1.0.0-1_mips64el_username@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

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Thu, 08 Nov 2018 20:27:06 GMT) (full text, mbox, link).

Message #60 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi

We were again biten by this issue for some security-updates (most
recent one nginx). Do any involved parties know, was there any
progress in adressing this problem? 

Sorry I know, probably patches and ideas welcome, but I cannot
contribute here, take my question please just from my "users"
point of view.

Regards,
Salvatore

Message #65 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> We were again biten by this issue for some security-updates (most
> recent one nginx). Do any involved parties know, was there any
> progress in adressing this problem? 

in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
wrote:

   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…

and I cannot find anything wrong with this simple solution and have
already asked Guillem in August to implement this ;)


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Fri, 09 Nov 2018 10:51:07 GMT) (full text, mbox, link).

Message #70 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi!

On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > We were again biten by this issue for some security-updates (most
> > recent one nginx). Do any involved parties know, was there any
> > progress in adressing this problem? 

Sorry, had your earlier mail from July marked for reply, but it seems
I missed that. :/

> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> wrote:
> 
>    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…
> 
> and I cannot find anything wrong with this simple solution and have
> already asked Guillem in August to implement this ;)

So, as I mentioned at the time this would require modifing the internal
filtering of the debian/files entries to cover this case in several of
the tools. It also modifies the documented filename pattern in
deb-buildinfo(5). This is all solvable and I should probably just do it.
But this breaks previous public filename "interfaces", seems rather
intrusive, and entirely inappropriate for a stable update, which means
it would not fix your immediate problems anyway, only starting with
Buster. :/

Thanks,
Guillem

Message #75 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi!

On Fri, 2018-11-09 at 11:48:27 +0100, Guillem Jover wrote:
> On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > We were again biten by this issue for some security-updates (most
> > > recent one nginx). Do any involved parties know, was there any
> > > progress in adressing this problem? 
> 
> Sorry, had your earlier mail from July marked for reply, but it seems
> I missed that. :/
> 
> > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > wrote:
> > 
> >    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…
> > 
> > and I cannot find anything wrong with this simple solution and have
> > already asked Guillem in August to implement this ;)
> 
> So, as I mentioned at the time this would require modifing the internal
> filtering of the debian/files entries to cover this case in several of
> the tools. It also modifies the documented filename pattern in
> deb-buildinfo(5). This is all solvable and I should probably just do it.
> But this breaks previous public filename "interfaces", seems rather
> intrusive, and entirely inappropriate for a stable update, which means
> it would not fix your immediate problems anyway, only starting with
> Buster. :/

Actually, I guess the other option that might be an option for stable is
to make dpkg-buildpackage generate the buildinfo file itself, and on
source-only uploads force the name to be _source.buildinfo regardless
of the options passed down to dpkg-genbuildinfo (even if the contents
will end up not matching the name).

This would seem rather less intrusive, as that only changes the
behavior in a "corner-case" (even though documented and recommended
one), when using «dpkg-buildpackage --changes-option=-S». And while it
could be considered to produce confusing filenames, it sticks to the
current pattern. It would also fix the other bug where running
dpkg-genbuildinfo leaves debian/files around, even on source only
builds.

So, I might go with that instead.

Thanks,
Guillem

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Fri, 09 Nov 2018 11:06:05 GMT) (full text, mbox, link).

Message #80 received at 869184@bugs.debian.org (full text, mbox, reply):

On Fri, 2018-11-09 at 11:55:38 +0100, Guillem Jover wrote:
> Actually, I guess the other option that might be an option for stable is
> to make dpkg-buildpackage generate the buildinfo file itself, and on
> source-only uploads force the name to be _source.buildinfo regardless
> of the options passed down to dpkg-genbuildinfo (even if the contents
> will end up not matching the name).
> 
> This would seem rather less intrusive, as that only changes the
> behavior in a "corner-case" (even though documented and recommended
> one), when using «dpkg-buildpackage --changes-option=-S». And while it
> could be considered to produce confusing filenames, it sticks to the
> current pattern. It would also fix the other bug where running
> dpkg-genbuildinfo leaves debian/files around, even on source only
> builds.

Err, ugh, disregard all the above. This would still generate the
_<arch>.buildinfo pattern, because we are under a full build, and
the only option passed is for .changes, an option which we do not
parse from dpkg-buildpackage anyway. If the .changes file was generated
by dpkg-genchanges itself then it could end up generating
_source.changes, but that would not help here at all anyway…

Thanks,
Guillem

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sun, 11 Nov 2018 07:42:02 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 11 Nov 2018 07:42:02 GMT) (full text, mbox, link).

Message #85 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi Guillem!

On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > We were again biten by this issue for some security-updates (most
> > > recent one nginx). Do any involved parties know, was there any
> > > progress in adressing this problem? 
> 
> Sorry, had your earlier mail from July marked for reply, but it seems
> I missed that. :/
> 
> > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > wrote:
> > 
> >    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…
> > 
> > and I cannot find anything wrong with this simple solution and have
> > already asked Guillem in August to implement this ;)
> 
> So, as I mentioned at the time this would require modifing the internal
> filtering of the debian/files entries to cover this case in several of
> the tools. It also modifies the documented filename pattern in
> deb-buildinfo(5). This is all solvable and I should probably just do it.
> But this breaks previous public filename "interfaces", seems rather
> intrusive, and entirely inappropriate for a stable update, which means
> it would not fix your immediate problems anyway, only starting with
> Buster. :/

Although this would not help us for stretch-security uploads, such a
move starting from buster would be very appreciated!

Thanks a lot for your time investing in it, very much appreicated.

Regards,
Salvatore

Changed Bug title to 'dpkg-buildpackage: Source uploads including _amd64.buildinfo cause problems' from 'dpkg: source uploads including _amd64.buildinfo cause problems'. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 03 Mar 2019 00:45:07 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sat, 09 Mar 2019 14:03:03 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 09 Mar 2019 14:03:03 GMT) (full text, mbox, link).

Message #92 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi

The following question goes maybe specifically to Ansgar, from
dak/ftp-master perspective:

On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> Hi Guillem!
> 
> On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > Hi!
> > 
> > On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > We were again biten by this issue for some security-updates (most
> > > > recent one nginx). Do any involved parties know, was there any
> > > > progress in adressing this problem? 
> > 
> > Sorry, had your earlier mail from July marked for reply, but it seems
> > I missed that. :/
> > 
> > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > wrote:
> > > 
> > >    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…
> > > 
> > > and I cannot find anything wrong with this simple solution and have
> > > already asked Guillem in August to implement this ;)
> > 
> > So, as I mentioned at the time this would require modifing the internal
> > filtering of the debian/files entries to cover this case in several of
> > the tools. It also modifies the documented filename pattern in
> > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > But this breaks previous public filename "interfaces", seems rather
> > intrusive, and entirely inappropriate for a stable update, which means
> > it would not fix your immediate problems anyway, only starting with
> > Buster. :/
> 
> Although this would not help us for stretch-security uploads, such a
> move starting from buster would be very appreciated!
> 
> Thanks a lot for your time investing in it, very much appreicated.

We regularly get issue still with that given one easily forgets about
the issue (the last occurence whas the php7.0 upload for
stretch-security as of yesterday). I wonder thus: would it be easily
workaroundable on ftp-master/dak's side to perform some additional
checks in that direction and reject such uploads wich would contain a
_${arch}.buildinfo file?

Any help in this regard would be very welcome from security team's
perspective, as we -- although an easy step -- need to fetch rejected
packages, rename files, resign and upload.

Sorry for always returning with this issue to both you and dpkg
maintainers.

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Thu, 09 May 2019 17:27:03 GMT) (full text, mbox, link).

Message #97 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi,

On Sat, Mar 09, 2019 at 03:00:10PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> The following question goes maybe specifically to Ansgar, from
> dak/ftp-master perspective:
> 
> On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > Hi Guillem!
> > 
> > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > Hi!
> > > 
> > > On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > We were again biten by this issue for some security-updates (most
> > > > > recent one nginx). Do any involved parties know, was there any
> > > > > progress in adressing this problem? 
> > > 
> > > Sorry, had your earlier mail from July marked for reply, but it seems
> > > I missed that. :/
> > > 
> > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > wrote:
> > > > 
> > > >    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…
> > > > 
> > > > and I cannot find anything wrong with this simple solution and have
> > > > already asked Guillem in August to implement this ;)
> > > 
> > > So, as I mentioned at the time this would require modifing the internal
> > > filtering of the debian/files entries to cover this case in several of
> > > the tools. It also modifies the documented filename pattern in
> > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > But this breaks previous public filename "interfaces", seems rather
> > > intrusive, and entirely inappropriate for a stable update, which means
> > > it would not fix your immediate problems anyway, only starting with
> > > Buster. :/
> > 
> > Although this would not help us for stretch-security uploads, such a
> > move starting from buster would be very appreciated!
> > 
> > Thanks a lot for your time investing in it, very much appreicated.
> 
> We regularly get issue still with that given one easily forgets about
> the issue (the last occurence whas the php7.0 upload for
> stretch-security as of yesterday). I wonder thus: would it be easily
> workaroundable on ftp-master/dak's side to perform some additional
> checks in that direction and reject such uploads wich would contain a
> _${arch}.buildinfo file?
> 
> Any help in this regard would be very welcome from security team's
> perspective, as we -- although an easy step -- need to fetch rejected
> packages, rename files, resign and upload.
> 
> Sorry for always returning with this issue to both you and dpkg
> maintainers.

We regularly get biten by this issue when contributors to security
uploads, most recently with the bind9 upload but as well others.

Would it be possible to at least workaround this on dak's side?
Disabling source-only uploads completely would seem to be a step back
on that regards.

Though if that's the only way  out of having to regularly fetch the
rejected builds, do manual renamings and resigning and reuploading of
files, then we should then just disable source-only uploads for the
security suites again.

So I think we pretty much would prefer to be able to continue so.

Just to be clear, thanks a lot for your work, this is not meant as
critique, just hilighting that we have recurring issues due to this
bug when people perform uploads for security.

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 13 May 2019 17:54:05 GMT) (full text, mbox, link).

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 May 2019 17:54:05 GMT) (full text, mbox, link).

Message #102 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote:
> > On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > > On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> > > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > > wrote:
> > > > > 
> > > > >    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…
> > > > > 
> > > > > and I cannot find anything wrong with this simple solution and have
> > > > > already asked Guillem in August to implement this ;)
> > > > 
> > > > So, as I mentioned at the time this would require modifing the internal
> > > > filtering of the debian/files entries to cover this case in several of
> > > > the tools. It also modifies the documented filename pattern in
> > > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > > But this breaks previous public filename "interfaces", seems rather
> > > > intrusive, and entirely inappropriate for a stable update, which means
> > > > it would not fix your immediate problems anyway, only starting with
> > > > Buster. :/
> > > Although this would not help us for stretch-security uploads, such a
> > > move starting from buster would be very appreciated!

Guillem, back in November Salvatore said they would appreciate this
"source+amd64 as the arch name" solution for this bug (see above), while
now (because nothing happened I believe) he suggests disabling source
all uploads for security builds, which IMO would be a *very* bad and sad
outcome, as I believe source only security uploads are even more desired
than regular source only uploads...

> We regularly get biten by this issue when contributors to security
> uploads, most recently with the bind9 upload but as well others.
> 
> Would it be possible to at least workaround this on dak's side?
> Disabling source-only uploads completely would seem to be a step back
> on that regards.
> 
> Though if that's the only way  out of having to regularly fetch the
> rejected builds, do manual renamings and resigning and reuploading of
> files, then we should then just disable source-only uploads for the
> security suites again.
> 
> So I think we pretty much would prefer to be able to continue so.
> 
> Just to be clear, thanks a lot for your work, this is not meant as
> critique, just hilighting that we have recurring issues due to this
> bug when people perform uploads for security.

sigh, understandable...


-- 
tschau,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sun, 16 Jun 2019 13:54:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ivo De Decker <ivodd@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 16 Jun 2019 13:54:04 GMT) (full text, mbox, link).

Message #107 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi,

Last week, Salvatore pointed me at this bug and Holger mentioned it in his
talk.

On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote:

[...]

> We regularly get biten by this issue when contributors to security
> uploads, most recently with the bind9 upload but as well others.

Is it clear in what cases this issue happens? Guillem mentioned
"dpkg-buildpackage --changes-option=-S" in https://bugs.debian.org/869184#75
Are there any other use cases that trigger it?

As "--changes-option=-S" creates an upload that is broken from the point of
view of the archive, it might make sense not to recommend (or even allow) this
for now. Just building with "-S" instead should create a buildinfo file with
_source, which won't trigger this issue.

> Would it be possible to at least workaround this on dak's side?
> Disabling source-only uploads completely would seem to be a step back
> on that regards.

There was this commit almost 2 years ago, which cleanly rejects these uploads,
allowing the uploader to do a new upload:
https://salsa.debian.org/ftp-team/dak/commit/7d234eaa5

However it was disabled shortly after (because it was rejecting a lot of
uploads):
https://salsa.debian.org/ftp-team/dak/commit/f9eb90374

Maybe this check should be enabled again. The beginning of the bullseye cycle
might be a good time to do that.

Even if that is considered too disruptive, this check could be enabled for the
security archive only, which would probably be better than to disable
source-only uploads there.

Thanks,

Ivo

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sun, 16 Jun 2019 15:09:12 GMT) (full text, mbox, link).

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 16 Jun 2019 15:09:13 GMT) (full text, mbox, link).

Message #112 received at 869184@bugs.debian.org (full text, mbox, reply):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, 2019-06-16 at 15:50 +0200, Ivo De Decker wrote:
> > We regularly get biten by this issue when contributors to security
> > uploads, most recently with the bind9 upload but as well others.
> 
> Is it clear in what cases this issue happens? Guillem mentioned
> "dpkg-buildpackage --changes-option=-S" in https://bugs.debian.org/869184#75
> Are there any other use cases that trigger it?
> 
> As "--changes-option=-S" creates an upload that is broken from the point of
> view of the archive, it might make sense not to recommend (or even allow) this
> for now. Just building with "-S" instead should create a buildinfo file with
> _source, which won't trigger this issue.

I'm my case I'm just using pbuilder with SOURCE_ONLY_CHANGES=yes, so it builds
a complete (arch:all + arch:any) package, then generate a .changes for source-
only upload (but there's the amd64.buildinfo included).

Regards,
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0GWt8ACgkQ3rYcyPpX
RFtQ8ggAnZSlfTWlEx4sLTfq59wI7ooeFwqRn84tuF5o9wGkmu6TiqvL5iKiw2l5
4j8x/bmwvTw4VE4QW7tMCnZ3VEfiZA4NXBkFVoCvwhiDFKWhzZL058yfoRqMMIhf
O/GAnZ0FIjwn3s0k5K6TEFPHNA9CdIhHWtLBnzVfwIZt3QeuVYE0CTE9ZehTrGZe
ygr2mlyNjO+izUwqlacwyDV7vH6p0789I6ulYKn/2AfxRxf/S7C+GmKbIrXy8e+9
xTWDcuudK9BmZU2WjtzY43ER7gyzFx8AHv89AXmWZ9jcaBiFcbd0K7pKnAPsY/+x
+FwaxjrWWoIquJezCQ0RGmtPdxpE3Q==
=L3gm
-----END PGP SIGNATURE-----

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 17 Jun 2019 04:00:03 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 17 Jun 2019 04:00:03 GMT) (full text, mbox, link).

Message #117 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote:
> As "--changes-option=-S" creates an upload that is broken from the point of
> view of the archive, it might make sense not to recommend (or even allow) this
> for now. Just building with "-S" instead should create a buildinfo file with
> _source, which won't trigger this issue.

For the rest of the regular archive, --changes-option=-S is definitely
*not* broken.  I use that regularly, and strongly prefer it.  It allows
me to document what i managed to build, while still ensuring that the
distributed binaries are created by debian's buildd network, and not my
own machinery.

I would be pretty sad if --changes-option=-S was explicitly deprecated
in any part of the debian archive.

  --dkg

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 17 Jun 2019 19:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 17 Jun 2019 19:57:03 GMT) (full text, mbox, link).

Message #122 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi Daniel,

On Sun, Jun 16, 2019 at 01:49:24PM -0400, Daniel Kahn Gillmor wrote:
> On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote:
> > As "--changes-option=-S" creates an upload that is broken from the point of
> > view of the archive, it might make sense not to recommend (or even allow) this
> > for now. Just building with "-S" instead should create a buildinfo file with
> > _source, which won't trigger this issue.
> 
> For the rest of the regular archive, --changes-option=-S is definitely
> *not* broken.  I use that regularly, and strongly prefer it.  It allows
> me to document what i managed to build, while still ensuring that the
> distributed binaries are created by debian's buildd network, and not my
> own machinery.
> 
> I would be pretty sad if --changes-option=-S was explicitly deprecated
> in any part of the debian archive.

This behaviour is really causing issues for the security-archive so in
one way or the other there needs to be a solution. Regularly we need
to fetch the buildd changes and build binary packages, resign them and
reupload them due to this bug.

Prefered for us would defintively to find a solution though which does
not mean the need to disable source only uploads for security-master,
that IMHO would be a read drawback.

That said, sorry it looks I'm repeating myself, but I wanted to
express again that this causes real issues for the work on releasing
security-updates via the security archive.

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 17 Jun 2019 20:15:03 GMT) (full text, mbox, link).

Acknowledgement sent to Vagrant Cascadian <vagrant@aikidev.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 17 Jun 2019 20:15:03 GMT) (full text, mbox, link).

Message #127 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 2019-06-17, Salvatore Bonaccorso wrote:
> On Sun, Jun 16, 2019 at 01:49:24PM -0400, Daniel Kahn Gillmor wrote:
>> On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote:
>> > As "--changes-option=-S" creates an upload that is broken from the point of
>> > view of the archive, it might make sense not to recommend (or even allow) this
>> > for now. Just building with "-S" instead should create a buildinfo file with
>> > _source, which won't trigger this issue.
>> 
>> For the rest of the regular archive, --changes-option=-S is definitely
>> *not* broken.  I use that regularly, and strongly prefer it.  It allows
>> me to document what i managed to build, while still ensuring that the
>> distributed binaries are created by debian's buildd network, and not my
>> own machinery.
>> 
>> I would be pretty sad if --changes-option=-S was explicitly deprecated
>> in any part of the debian archive.
>
> This behaviour is really causing issues for the security-archive so in
> one way or the other there needs to be a solution. Regularly we need
> to fetch the buildd changes and build binary packages, resign them and
> reupload them due to this bug.

What's unclear to me is why the workaround in DAK for the main archive,
which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or
hasn't been applied for the security archive. Is there something
fundamentally different with the security archive?

It seems quite late in the freeze cycle to get this fixed in dpkg even
for buster, so it seems worth considering fixing in the archive, unless
I'm missing something?


> Prefered for us would defintively to find a solution though which does
> not mean the need to disable source only uploads for security-master,
> that IMHO would be a read drawback.
>
> That said, sorry it looks I'm repeating myself, but I wanted to
> express again that this causes real issues for the work on releasing
> security-updates via the security archive.

Really hard to see that this has dragged on for almost two years now
without resolution!


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Tue, 18 Jun 2019 16:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@43-1.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 18 Jun 2019 16:33:03 GMT) (full text, mbox, link).

Message #132 received at 869184@bugs.debian.org (full text, mbox, reply):

On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote:
> > This behaviour is really causing issues for the security-archive so in
> > one way or the other there needs to be a solution. Regularly we need
> > to fetch the buildd changes and build binary packages, resign them and
> > reupload them due to this bug.
> 
> What's unclear to me is why the workaround in DAK for the main archive,
> which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or
> hasn't been applied for the security archive. Is there something
> fundamentally different with the security archive?

The .buildinfo files are referred to in the .changes files; renaming
them would require updating the .changes file.  The .changes files are
used to upload the security updates to ftp-master.

ftp-master also has the same problem when uploads end up in policy
queues (the renaming to .buildinfo.N is only done when dak is "done"
with the file and will never touch it again).

As most uploads go to unstable and experimental, one mostly doesn't
notice the issue.

Ansgar

Message #135 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
> The .buildinfo files are referred to in the .changes files; renaming
> them would require updating the .changes file.  The .changes files are
> used to upload the security updates to ftp-master.

With .changes being ephemeral, it feels to me that using them to cross
the archive is not really a good solution, and whatever is used to copy
packages from one archive to another (is it dak itself?) should instead
re-create the upload and re-sign it.  Also because that way it would be
perfectly able to "upload" all of the sources+binaries from sec-master
to ftp-master in a single go, which can't be bad.

> ftp-master also has the same problem when uploads end up in policy
> queues (the renaming to .buildinfo.N is only done when dak is "done"
> with the file and will never touch it again).

Also here, it feels to me that once something is accepted into a policy
queue, dak should already consider it something controlled by itself,
store checksums in the database and be done, not keep the .changes
around as a "source of truth" for additional processing, imho.

Sure, I understand that things works like that, I'm just showing a few
design points that could potentially be done differently.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Tue, 18 Jun 2019 19:06:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 18 Jun 2019 19:06:03 GMT) (full text, mbox, link).

Message #140 received at 869184@bugs.debian.org (full text, mbox, reply):

Mattia Rizzolo writes:
> On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
>> The .buildinfo files are referred to in the .changes files; renaming
>> them would require updating the .changes file.  The .changes files are
>> used to upload the security updates to ftp-master.
>
> With .changes being ephemeral, it feels to me that using them to cross
> the archive is not really a good solution, and whatever is used to copy
> packages from one archive to another (is it dak itself?) should instead
> re-create the upload and re-sign it.  Also because that way it would be
> perfectly able to "upload" all of the sources+binaries from sec-master
> to ftp-master in a single go, which can't be bad.

We also currently require .dsc to be signed by the same key as the
.changes; that wouldn't work either.

There are some advantages to changing the way the sync works, but it's
not a priority to look at.  There are enough other things...

>> ftp-master also has the same problem when uploads end up in policy
>> queues (the renaming to .buildinfo.N is only done when dak is "done"
>> with the file and will never touch it again).
>
> Also here, it feels to me that once something is accepted into a policy
> queue, dak should already consider it something controlled by itself,
> store checksums in the database and be done, not keep the .changes
> around as a "source of truth" for additional processing, imho.

Throwing away .changes doesn't help with .buildinfo name conflicts.

> Sure, I understand that things works like that, I'm just showing a few
> design points that could potentially be done differently.

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.

Ansgar

Message #143 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> > Also here, it feels to me that once something is accepted into a policy
> > queue, dak should already consider it something controlled by itself,
> > store checksums in the database and be done, not keep the .changes
> > around as a "source of truth" for additional processing, imho.
> 
> Throwing away .changes doesn't help with .buildinfo name conflicts.

It helps in the sense that once the .changes is thrown away, dak would
be free to rename the .buildinfo however it likes.

> 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.

That would indeed be a fine workaround for me, and reduce the load the
security team is experience, since it's the team which is the most
affect by this.
(Incidentally, it also is the same way launchpad works, there you can't
upload a .buildinfo for an arch that you aren't uploading, and humans
can't upload binaries, so you can't upload .buildinfo for binaries at
all).

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Wed, 19 Jun 2019 06:36:03 GMT) (full text, mbox, link).

Acknowledgement sent to Yves-Alexis Perez <corsac@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 19 Jun 2019 06:36:03 GMT) (full text, mbox, link).

Message #148 received at 869184@bugs.debian.org (full text, mbox, reply):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 2019-06-18 at 21:20 +0200, Mattia Rizzolo wrote:
> That would indeed be a fine workaround for me, and reduce the load the
> security team is experience, since it's the team which is the most
> affect by this.
> (Incidentally, it also is the same way launchpad works, there you can't
> upload a .buildinfo for an arch that you aren't uploading, and humans
> can't upload binaries, so you can't upload .buildinfo for binaries at
> all).

But some tools (at least pbuilder) generate such (meaningful, since there was
a binary build) files. It's already been said earlier but if the uploads are
considered invalid it should be consistent accross the archive (not just on
security-master) and tools should not generate them.

Regards,
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0J1xkACgkQ3rYcyPpX
RFsxowgA7bIn+1RfeJ6J7xv7Gxjh+WE5xZGbhOv+sDWgVwkJDiPAiW4tIMKU6qrw
17ghR+m7jo1PNZqr+boDZ851UVQOD5ii4SsyWBbesbMLPn2hNaBZN93El3pe4ni0
EgIeePe2d6wez+zZjiubdKEAZMuf7ezq3+9EuXuQDjSKmWV6PSu90i5/ncl6AByW
/3SWQmt4sgUlr6HoR60B586d3eVVg82Hd/0GQBPinkgyp57G+R4z7HpRTPrYFmM3
QRIkcBhBcvG4FI7AdV/b1ki0iXPvwXrucOTxzBKWoehqFwA3kvJUZf+vBi9I93VW
THIx8duOD0M7VoLNS6ohJHWZ8MyWrg==
=xZJB
-----END PGP SIGNATURE-----

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 19 Jun 2019 06:42:04 GMT) (full text, mbox, link).

Message #153 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi Ansgar,

On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
[...]
> > Sure, I understand that things works like that, I'm just showing a few
> > design points that could potentially be done differently.
> 
> 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 ftp-masters and security
team members do not need to roundtrip reuploading binary builds
(download, rename, resign ... reupload) 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.

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 08 Jul 2019 22:45:03 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 08 Jul 2019 22:45:03 GMT) (full text, mbox, link).

Message #158 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Mon, 08 Jul 2019 23:42:03 GMT) (full text, mbox, link).

Acknowledgement sent to Vagrant Cascadian <vagrant@reproducible-builds.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 08 Jul 2019 23:42:03 GMT) (full text, mbox, link).

Message #163 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 2019-07-09, Francesco Poli wrote:
> 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?

It's an attestation from the uploader that they built the package, what
the hashes of their build are, and the build environment used to produce
those binary packages. If there are differences between the buildd build
of the package and the uploader's build of the package, it may be
possible to compare the results.

I usually use sbuild's --source-only-changes feature to produce a
.changes that also includes the .buildinfo that produced my local debs
without uploading the actual .deb files to the archive.

This is certainly desireable from a reproducible builds perspective.

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

.buildinfo files without any hashes of .deb files do seem less useful,
unless you consider the building of the .dsc as a build process
itself.

> 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?

Or calling the .buildinfo by a different name, e.g. source.buildinfo or
source-arch.buildinfo, etc.

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

I hope this doesn't end up being the solution.

Though a workable solution would be really welcome at this point...

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Tue, 09 Jul 2019 07:42:07 GMT) (full text, mbox, link).

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 09 Jul 2019 07:42:07 GMT) (full text, mbox, link).

Message #168 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Mon, 08 Jul 2019 16:39:30 -0700 Vagrant Cascadian wrote:

> On 2019-07-09, Francesco Poli wrote:
[...]
> > Maybe it's a naive question: what's the use of including a .buildinfo
> > file into a source-only upload? Is it superfluous?
> 
> It's an attestation from the uploader that they built the package, what
> the hashes of their build are, and the build environment used to produce
> those binary packages. If there are differences between the buildd build
> of the package and the uploader's build of the package, it may be
> possible to compare the results.
[...]
> 
> This is certainly desireable from a reproducible builds perspective.

I see: this makes perfect sense, sure.
Thanks a lot for the clear explanation!

[...]
> > Would it be better, if dpkg-genchanges completely refrained from
> > including .buildinfo files into source-only .changes files?
> 
> Or calling the .buildinfo by a different name, e.g. source.buildinfo or
> source-arch.buildinfo, etc.

Maybe an alternative strategy could work as follows:

 • dpkg-genchanges should continue to do exactly what it currently does

 • the autobuilders should rename their own .buildinfo files on the fly,
   to something like package_version_arch-buildd.buildinfo

This way, we could avoid name clashes, without the need to fix the
tools used by all the people who upload packages...

Could this strategy be the way to go?
Does it have any important drawback?


-- 
 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

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sat, 17 Aug 2019 08:39:03 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 17 Aug 2019 08:39:03 GMT) (full text, mbox, link).

Message #173 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi Ansgar,

On Wed, Jun 19, 2019 at 08:39:50AM +0200, Salvatore Bonaccorso wrote:
> Hi Ansgar,
> 
> On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> [...]
> > > Sure, I understand that things works like that, I'm just showing a few
> > > design points that could potentially be done differently.
> > 
> > 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 ftp-masters and security
> team members do not need to roundtrip reuploading binary builds
> (download, rename, resign ... reupload) 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.

We had a couple of occasions still where we needed to do fetch the
builds, rename, resign and reupload the packages.

Any chance to enable the above check again? That would solve most of
or issues and people which did upload a source only upload but
containing a ${arch}.buildinfo would get their uploads rejected.

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Tue, 27 Aug 2019 12:27:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ivo De Decker <ivodd@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 27 Aug 2019 12:27:03 GMT) (full text, mbox, link).

Message #178 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi,

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@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@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.

I submitted a merge request to sbuild to add a suffix like this to the
buildinfo and changes files:

https://salsa.debian.org/debian/sbuild/merge_requests/6

This would work around this issue, without needing any changes in maintainer
workflows.

The suffix could just be 'buildd', no need to have the buildd name in there.
The filename just needs to be different from the filename uploaded by the
maintainer. Obviously it could contain the buildd name if people think that
would be useful.

This change in sbuild only needs to happen on the buildd system. No change is
needed in the build chroots. So it should work for stretch and newer without
the need for changes to dpkg (or any other package) in those releases (jessie
doesn't have buildinfo files).

The patch also adds the suffix to the .changes file, to avoid a similar issue
there. This happens when the maintainer manually removes binaries from a
changes file to do a source-only upload. It would also potentially happen if
dak supported throw-away binaries.

Cheers,

Ivo

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Tue, 15 Oct 2019 04:42:03 GMT) (full text, mbox, link).

Acknowledgement sent to Salvatore Bonaccorso <carnil@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 15 Oct 2019 04:42:03 GMT) (full text, mbox, link).

Message #183 received at 869184@bugs.debian.org (full text, mbox, reply):

Hi,

On Sat, Aug 17, 2019 at 10:37:43AM +0200, Salvatore Bonaccorso wrote:
> Hi Ansgar,
> 
> On Wed, Jun 19, 2019 at 08:39:50AM +0200, Salvatore Bonaccorso wrote:
> > Hi Ansgar,
> > 
> > On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> > [...]
> > > > Sure, I understand that things works like that, I'm just showing a few
> > > > design points that could potentially be done differently.
> > > 
> > > 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 ftp-masters and security
> > team members do not need to roundtrip reuploading binary builds
> > (download, rename, resign ... reupload) 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.
> 
> We had a couple of occasions still where we needed to do fetch the
> builds, rename, resign and reupload the packages.
> 
> Any chance to enable the above check again? That would solve most of
> or issues and people which did upload a source only upload but
> containing a ${arch}.buildinfo would get their uploads rejected.

We still have recurring this issue, where people continue to upload
_sources.changes (even more frequently now I would say, given the
workflow for unstable/testing) but which include a _amd64.buildinfo.
The last one was the (not yet released) unbound update.

So if we can have this check enabled again for the security archive
this would help us a lot not having to workaround those rejected
uploads :)

Thanks for all your work!

Regards,
Salvatore

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#869184; Package dpkg. (Sat, 22 Feb 2020 17:18:02 GMT) (full text, mbox, link).

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 22 Feb 2020 17:18:02 GMT) (full text, mbox, link).

Message #188 received at 869184@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

hi Guillem,

On Fri, Nov 09, 2018 at 11:55:38AM +0100, Guillem Jover wrote:
> Actually, I guess the other option that might be an option for stable is
> to make dpkg-buildpackage generate the buildinfo file itself, and on
> source-only uploads force the name to be _source.buildinfo regardless
> of the options passed down to dpkg-genbuildinfo (even if the contents
> will end up not matching the name).
> 
> This would seem rather less intrusive, as that only changes the
> behavior in a "corner-case" (even though documented and recommended
> one), when using «dpkg-buildpackage --changes-option=-S». And while it
> could be considered to produce confusing filenames, it sticks to the
> current pattern. It would also fix the other bug where running
> dpkg-genbuildinfo leaves debian/files around, even on source only
> builds.
> 
> So, I might go with that instead.
 
any update on this?

the security team people still have to workaround this manually regularily, eg
today, and would really like to see this fixed...


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed May 17 10:12:10 2023; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #869184 dpkg-buildpackage: Source uploads including _amd64.buildinfo cause problems

Debian Bug report logs - #869184
dpkg-buildpackage: Source uploads including _amd64.buildinfo cause problems