Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
On Sun, 2021-08-29 at 12:25 -0400, Roberto C. Sánchez wrote:
> On Sun, Aug 29, 2021 at 05:17:02PM +0100, Adam D. Barratt wrote:
> > As it turns out, the bullseye upload is still sat on upload.d.o,
> > because:
> >
> > Aug 29 15:31:17 processing /shiro_1.3.2-4+deb11u1_source.changes
> > Aug 29 15:31:17 shiro_1.3.2.orig.tar.xz doesn't exist (ignored for
> > now)
> >
> > My assumption is that both of your .changes reference the same
> > .orig.tar.xz. If they were uploaded close together, then the queue
> > daemon will have removed the .orig from the queue together with the
> > files from the buster upload, thus stranding the bullseye upload.
>
> Yes, they reference the same .orig.tar.gz and I uploaded
> simultaneously.
>
> > To
> > avoid this, either space the uploads further apart, or don't
> > include
> > the .orig in more than one of them - in fact, if the upstream
> > tarball
> > is the same as is already in the archive, you don't need to include
> > it
> > in either.
> >
> Is this because the upload is going to the main FTP archive, rather
> than the security archive first? It seems that the "always use -sa
> to build a u1 update" needs to only be for uploads targeted at
> security.d.o.
In general, that's correct, yeah - the security archive won't tend to
already have the orig, whereas the main archive will.
It's not an issue to include / reference it for the main archive
anyway, but as a consequence you will get this issue if you do so for
two uploads that occur close together. (I'd assume that you'll also hit
it if you upload for buster-security and bullseye-security under
similar circumstances.)
Regards,
Adam
Reply to: