Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
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 this case, you'll either need to dcut the remaining files from the
> previous upload, or wait for the queue daemon to delete them on its
> own.
>
> I've flagged the buster upload for rejection, once dak notices, so feel
> free to re-upload that once you receive the rejection confirmation (and
> bullseye once it times out, or you dcut it).
>
Great! Thanks for the info, as the single REJECT seemed strange when I
was expecting two of them.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: