=== morphis5 is now known as morphis [17:32] 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] That feels like a long time to be waiting for that; any known issues that haven't made it to the topic? [18:22] 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] 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] Odd_Bloke: I don't believe that they used force. [18:39] Odd_Bloke: That check is entirely client-side. [18:39] And --force overrides it. [18:40] Odd_Bloke: But they could also try just removing the corresponding .upload file. [18:45] Ack, will let them know, thanks! [18:46] big thanks to Odd_Bloke :) i'm the one he is helping [18:46] 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] either way, i just tried pushing to my new ppa, and yep deleting that .upload file allowed me to do it [18:47] hopefully this one hits the new ppa! wondering if i had a weird timing issue with the other ppa [18:47] ahhh i see [18:47] just reread some messages [18:48] ok cool i'll give that a try [22:11] 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] although i suppose something could have still have had the old IPs cached [22:18] pjdc: today's failures are in https://pastebin.canonical.com/p/bTRRjwV4Dy/ [22:18] (internal) [22:18] 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] ta [22:29] 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] 0xB6DCBA663EA1B150 is more concering, because it's ancient... unless it wasn't --send-keys until recently [22:30] 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] that doesn't seem to be the case, so that one's even iffier [22:39] pretty strange pattern of 200s and 404s on the FEs https://pastebin.canonical.com/p/hRFcjHBmnS/ [22:39] anyway, i'll keep looking, will let you know if i find/fix anything [22:46] thanks === viv`d is now known as vivid