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
