When I dput a source package to landing, it gets rejected with explanation that it "is already known."
Concretely I tried several times today with firefox-esr_60.7.0esr-1pureos2really60.7.1esr1_source.changes and once with firefox-esr_60.7.0esr-1pureos3_source.changes
Severity set to highest due to zero-day bugfix needing urgent processing.
According to dak and the SHA256 hash of the package, the upload is indeed already known and would just be rejected again - can you rebuild the package again and do another upload?
TBH it is *really* weird that the package is rejected, as I would expect to find the originally rejected upload in the rejected queue, but that doesn't appear to be there.
So if your next upload doesn't succeed, let me know immediately! (I also made dak forget about the last upload attempt).
How do you mean the package was "indeed already known"? If you mean to say that you are certain that those releases had already been accepted preciously then what happened to them?
Also, how could the -1pureos2really60.7.1esr1 release possibly have happened before? I mean, what is the likelihood that any of us few uploaders came come up with that same name and superceded me?
Making another upload is what I already did with the -pureos3 release. Released yet again now as -4 as requested.
@mak: Failed again: "firefox-esr_60.7.0esr-1pureos4_source.changes is already known."
@jonas.smedegaard No, I mean the same file (without it being rebuilt) was apparently already uploaded and rejected before. Dak hashes the files to not process the same, already rejected upload multiple times (even if it has different names) - and to prevent people from just uploading the same thing over and over again.
That said, this case is really strange, as the upload actually wasn't known before, as far as I can see in the database.
I forced the package in now, it is available in the landing suite now (and will be built soon), but I'll keep an eye on this issue - could maybe be a bug in dak.
It should not be surprising that logfiles indicate that -1pureos2really60.7.1esr1 was rejected multiple times, because that is what I experienced and the reason I wrote "tried several times" in the description.
I am puzzled why you close this if only worked around, not yet solved, but whatever...
Well, the message was a false and the actual culprit was a SQL query failing. The cause of that is fixed now, so this shouldn't happen again (but if it does, I'll look into it again). Not sure why exactly the database was in a wrong state though, but that's really hard to figure out at this point.
That's why the issue is resolved.