[17:32] <Odd_Bloke> I'm getting reports from someone in #cloud-init that they uploaded to a PPA (https://launchpad.net/~trstringer/+archive/ubuntu/ppa) a couple of hours ago and they haven't seen anything appear there as yet.
[17:32] <Odd_Bloke> That feels like a long time to be waiting for that; any known issues that haven't made it to the topic?
[18:22] <cjwatson> Odd_Bloke: Their upload was rejected due to a keyserver failure (still something we suffer from occasionally, although hopefully hockeypuck will save us soon).  They should reupload
[18:32] <Odd_Bloke> cjwatson: Thanks!  They attempted that and were told by dput that there was nothing to do (even with force); will they need to bump the version number to do so?
[18:39] <cjwatson> Odd_Bloke: I don't believe that they used force.
[18:39] <cjwatson> Odd_Bloke: That check is entirely client-side.
[18:39] <cjwatson> And --force overrides it.
[18:40] <cjwatson> Odd_Bloke: But they could also try just removing the corresponding .upload file.
[18:45] <Odd_Bloke> Ack, will let them know, thanks!
[18:46] <chillysurfer> big thanks to Odd_Bloke :) i'm the one he is helping
[18:46] <chillysurfer> about 30 min ago i created a new ppa called "ppa2". i noticed that the ppa title is "ppa2". my original ppa title was "trstring_ppa" but the dput command in launchpad indicated i should use ppa:trstringer/ppa
[18:47] <chillysurfer> either way, i just tried pushing to my new ppa, and yep deleting that .upload file allowed me to do it
[18:47] <chillysurfer> hopefully this one hits the new ppa! wondering if i had a weird timing issue with the other ppa
[18:47] <chillysurfer> ahhh i see
[18:47] <chillysurfer> just reread some messages
[18:48] <chillysurfer> ok cool i'll give that a try
[22:11] <pjdc> cjwatson: do you happen to have the timestamp and key ID for that keyserver failure?  we pointed DNS at hockeypuck in the early hours of 2019-07-30 (~01:12 for ubuntu.com, ~02:09 for internal)
[22:11] <pjdc> although i suppose something could have still have had the old IPs cached
[22:18] <cjwatson> pjdc: today's failures are in https://pastebin.canonical.com/p/bTRRjwV4Dy/
[22:18] <cjwatson> (internal)
[22:18] <cjwatson> pjdc: some succeeded on retry, but not all.  The ones that have three failures in quick succession are the ones where retrying didn't help
[22:18] <pjdc> ta
[22:29] <pjdc> taking 0x1FE932B6EA48369D first, hockeypuck/0 received it at 2019-07-31T15:26:56Z, and hockeypuck/1 at 2019-07-31T16:24:23Z - i'd assume the first was --send-keys and the second was via reconciliation. an hour seems like a long time, but if apache send all 3 requests to hockeypuck/1, then that's explainable (although not ideal, and something we should look into)
[22:29] <pjdc> 0xB6DCBA663EA1B150 is more concering, because it's ancient... unless it wasn't --send-keys until recently
[22:30] <pjdc> it did get a new subkey recently: https://hockeypuck.ubuntu.com/pks/lookup?search=0xB6DCBA663EA1B150&fingerprint=on&op=index so maybe it was private until then-ish
[22:33] <pjdc> that doesn't seem to be the case, so that one's even iffier
[22:39] <pjdc> pretty strange pattern of 200s and 404s on the FEs https://pastebin.canonical.com/p/hRFcjHBmnS/
[22:39] <pjdc> anyway, i'll keep looking, will let you know if i find/fix anything
[22:46] <cjwatson> thanks