[00:52] <acheronuk> ppa uploads seem to not be reaching the builders?
[00:57] <acheronuk> hmm. seems some are being processed now
[01:22] <wgrant> acheronuk: Some background jobs were delayed by DB maintenance.
[08:15] <ePierre_> rashed
[08:15] <ePierre_> oops :)
[13:37] <cjwatson> ahasenack: Could you try that GPG key import again?  I just landed some improved instrumentation.
[13:37] <ahasenack> ok
[13:37] <ahasenack> cjwatson: it was imported already, I guess it worked eventually
[13:38] <cjwatson> bah
[13:38] <cjwatson> was hoping to find out why it was slow
[13:39] <rbasak> In case it's related, I earlier did a --send-key to keyserver.ubuntu.com and got an error. Sorry, I didn't save the error. Retrying worked.
[13:39] <rbasak> Are you in a path that you need to talk to the keyserver? Any chance it's the keyserver behaving badly that LP doesn't handle?
[13:40] <cjwatson> Sure.  That's why I landed improved instrumentation, so that I could find out this sort of thing.
[13:40] <cjwatson> Aha, https://oops.canonical.com/oops/?oopsid=OOPS-c19ccefbed6bcb7b0d094cc14e180842
[13:40] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-c19ccefbed6bcb7b0d094cc14e180842
[13:42] <cjwatson> I don't think that's the keyserver
[13:43] <cjwatson> I mean, maybe a bit of it is, but mostly not
[13:48] <cjwatson> Is this really taking three seconds to build a gpgme context or am I hallucinating?
[13:50] <cjwatson> Hmm, it does seem about that slow locally too
[13:52] <cjwatson> Oh, I bet it's the stupid ulimit thing
[13:54] <cjwatson> In which case I should perhaps just backport the gpgme optimisation I did
[16:18] <bp0> Hello, I've been trying to report a bug via launchpad for a couple days, and I always get "Timeout error". Latest attempt:  (Error ID: OOPS-ad34bc67402921e640c37c5909ecd6a7)
[16:18] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-ad34bc67402921e640c37c5909ecd6a7
[16:20] <cjwatson> That one has historically always gone away in ten minutes or so, although it recurs every so often.
[16:21] <cjwatson> Hm, or is that the same one ...
[16:22] <cjwatson> OK, actually different from what I was thinking.  Let's see.
[16:23] <bp0> It's been happening every attempt, since yesterday evening
[16:28] <cjwatson> bp0: You could work around this by making the package name field be just "nvidia-graphics-drivers-390" rather than "nvidia-graphics-drivers-390 bionic".
[16:29] <cjwatson> bp0: I believe the superfluous " bionic" causes a form error which then means that the failure handling for that form does a search for similar bugs, which in this case times out due to overly-complicated search terms.
[16:29] <bp0> Hmm, alright, I'll try
[16:34] <bp0> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1757202
[16:34] <ubot5`> Ubuntu bug 1757202 in nvidia-graphics-drivers-390 (Ubuntu) "xubuntu / bionic / nvidia-driver-390 can only be used by one user at a time" [Undecided,New]
[16:34] <bp0> Thanks, cjwatson
[16:35] <cjwatson> Excellent
[19:50] <nacc> cjwatson: i believe all but one package in the 10% phasing set is now imported (oxide-qt, which is taking a while)
[19:51] <cjwatson> nacc: Nagios says 1010 GB free, which suggests 2% -> 10% took 4 GB
[19:51] <nacc> cjwatson: ok, that seems sensible to me (this was 240 or so packages, iirc)
[19:53] <nacc> cjwatson: so, in theory, presuming a similar repository size going forward; all of main (~5000 packages) will take < 100G
[19:53] <nacc> cjwatson: our plan was to go up to 20% next, and see if we're still following the same curve for space
[19:53] <nacc> cjwatson: then 50% and 100%
[19:54] <cjwatson> Right, no immediate concerns about that
[19:55] <nacc> cjwatson: thanks!
[19:55] <cjwatson> We'll want to take some care about universe, but let's see how it goes
[19:56] <nacc> yeah, universe is long-term at this point :)
[19:56] <nacc> the goal was to see if we can import main by 18.10 starting
[20:03] <rbasak> nacc: are you sure oxide-qt isn't stuck? 284 publications isn't _that_ many.
[20:05] <nacc> rbasak: it's making progress, just slowly
[20:05] <nacc> rbasak: afaict (i see as mch in top, at least)
[20:05] <rbasak> OK
[20:06] <nacc> rbasak: i'm not 100% on why it's so slow, but there are lots of repetitive publishes
[20:06] <nacc> i think it'd be much faster with one of my branches, i forget which one
[20:06] <nacc> taht doesn't do the branch changes until the end
[20:06] <nacc> right now the git branches are churning, i think
[20:17] <nacc> rbasak: lol, each orig tarball is roughly 400M
[20:17] <nacc> rbasak: that's why it's taking so long, it's hammering both the network and pristine-tar
[20:35] <rbasak> Nice
[20:41] <tsimonq2> That stuff isn't run in parallel?
[20:44] <rbasak> The importer can run stuff in parallel. But the import of multiple publications of a single source package is linear. It has to be for the commit graph to be able to be created correctly.
[21:01] <nacc> tsimonq2: e.g., right now we are doing 10 imports at the same time
[21:01] <nacc> tsimonq2: but each import itself is linearly reading the publishing hsistory, as we care about the order things happen in
[21:02] <tsimonq2> Ah ok.
[21:02] <tsimonq2> Right.
[21:03] <nacc> tsimonq2: we actually care less now than we did before, but we still need to ensure all prior stuff is in before the currently examined publish, so that we can parent as correctly as possible
[21:04] <tsimonq2> nacc: Right.