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
