If we know the ppa the upload was target at we could put a notification
on the web page there; a single field (not one per failure), and no
email sent would:
- allow users to discover it. (In fact we could document that they
should look there for other things too)
- not be badly spammable - multiple annoying uploads would just
coalesce into a single notification whenever the ppa owners happened
to pop by
affects launchpad
IRC snippet from discussion:
18:53 < tohms> strange ... tried yesterday evening to upload ... upload
self was fine but no mail and no package ... in both of my ppa ... tried
today again ... same matter
18:55 < cprov> tohms: it looks like a gpg key problem (no mail back).
What's the source name ?
18:56 < tohms> absolutely ... source is splashy_0.3.13-3ubuntu2
18:58 < cprov> tohms: FatalUploadError: GPG verification of
splashy_0.3.13-3ubuntu2_source.changes failed: Verification failed 3
times: ["(7, 9, 'No public key')", "(7, 9, 'No public key')", "(7, 9,
'No public
key')"]
18:59 < tohms> damn ... why didn't I get this as an email notification?
19:00 < tohms> i've forgotten that I renewd my key ... thx for help!
19:03 < cprov> tohms: for the meantime, remember that 'no-email within
10 minutes' == 'your gpg key setup in LP has issues'
19:03 < cprov> tohms: no worries, sorry for the inconvenience, we are
working on a fix.
19:04 < tohms> at least you could help me now :)
19:04 < cprov> sure.
19:18 < lifeless> cprov: we could show something on the ppa page
19:18 < lifeless> 'uploads recently rejected without notification'
19:19 < cprov> lifeless: if we avoid to notify people when we can't
authenticate the changesfiles, I doubt we would like to store that
information in the DB
19:20 < cprov> lifeless: anyone could easily inject an annoying number
of rejected uploads in someone else PPA.
19:20 < lifeless> cprov: just thinking it would let them answer the
problem without you haveing to read a log
19:20 < lifeless> cprov: so limit it to one notification
Related: OOPS-1866PPA1221
There is a quick set of checks that we could perform before finishing the upload session that would allow us to spot problems like that earlier and be able to warn the user immediately:
1. There is a .changes;
2. Its signature is good and known by LP;
3. The .changes is parseable;
If those 2 checks pass, there will be always a notification after the upload is processed (later) if any of them fail the upload session should be terminated with an error, which is handled by dput (and can be improved later).
This approach fits the current FTP media and will also work when and if we migrate to SSH media.