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 via email to