/srv/irclogs.ubuntu.com/2018/03/20/#launchpad.txt

acheronukppa uploads seem to not be reaching the builders?00:52
acheronukhmm. seems some are being processed now00:57
wgrantacheronuk: Some background jobs were delayed by DB maintenance.01:22
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
ePierre_rashed08:15
ePierre_oops :)08:15
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== JanC_ is now known as JanC
cjwatsonahasenack: Could you try that GPG key import again?  I just landed some improved instrumentation.13:37
ahasenackok13:37
ahasenackcjwatson: it was imported already, I guess it worked eventually13:37
cjwatsonbah13:38
cjwatsonwas hoping to find out why it was slow13:38
rbasakIn 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
rbasakAre 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:39
cjwatsonSure.  That's why I landed improved instrumentation, so that I could find out this sort of thing.13:40
cjwatsonAha, https://oops.canonical.com/oops/?oopsid=OOPS-c19ccefbed6bcb7b0d094cc14e18084213:40
ubot5`https://oops.canonical.com/?oopsid=OOPS-c19ccefbed6bcb7b0d094cc14e18084213:40
cjwatsonI don't think that's the keyserver13:42
cjwatsonI mean, maybe a bit of it is, but mostly not13:43
cjwatsonIs this really taking three seconds to build a gpgme context or am I hallucinating?13:48
cjwatsonHmm, it does seem about that slow locally too13:50
cjwatsonOh, I bet it's the stupid ulimit thing13:52
cjwatsonIn which case I should perhaps just backport the gpgme optimisation I did13:54
=== dgadomski_ is now known as dgadomski
=== askhl_ is now known as askhl
=== shadeslayer_ is now known as shadeslayer
=== chihchun is now known as chihchun_afk
bp0Hello, 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-ad34bc67402921e640c37c5909ecd6a716:18
cjwatsonThat one has historically always gone away in ten minutes or so, although it recurs every so often.16:20
cjwatsonHm, or is that the same one ...16:21
cjwatsonOK, actually different from what I was thinking.  Let's see.16:22
bp0It's been happening every attempt, since yesterday evening16:23
cjwatsonbp0: 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:28
cjwatsonbp0: 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
bp0Hmm, alright, I'll try16:29
bp0https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/175720216: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
bp0Thanks, cjwatson16:34
cjwatsonExcellent16:35
nacccjwatson: i believe all but one package in the 10% phasing set is now imported (oxide-qt, which is taking a while)19:50
cjwatsonnacc: Nagios says 1010 GB free, which suggests 2% -> 10% took 4 GB19:51
nacccjwatson: ok, that seems sensible to me (this was 240 or so packages, iirc)19:51
nacccjwatson: so, in theory, presuming a similar repository size going forward; all of main (~5000 packages) will take < 100G19:53
nacccjwatson: our plan was to go up to 20% next, and see if we're still following the same curve for space19:53
nacccjwatson: then 50% and 100%19:53
cjwatsonRight, no immediate concerns about that19:54
nacccjwatson: thanks!19:55
cjwatsonWe'll want to take some care about universe, but let's see how it goes19:55
naccyeah, universe is long-term at this point :)19:56
naccthe goal was to see if we can import main by 18.10 starting19:56
rbasaknacc: are you sure oxide-qt isn't stuck? 284 publications isn't _that_ many.20:03
naccrbasak: it's making progress, just slowly20:05
naccrbasak: afaict (i see as mch in top, at least)20:05
rbasakOK20:05
naccrbasak: i'm not 100% on why it's so slow, but there are lots of repetitive publishes20:06
nacci think it'd be much faster with one of my branches, i forget which one20:06
nacctaht doesn't do the branch changes until the end20:06
naccright now the git branches are churning, i think20:06
naccrbasak: lol, each orig tarball is roughly 400M20:17
naccrbasak: that's why it's taking so long, it's hammering both the network and pristine-tar20:17
rbasakNice20:35
tsimonq2That stuff isn't run in parallel?20:41
rbasakThe 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.20:44
nacctsimonq2: e.g., right now we are doing 10 imports at the same time21:01
nacctsimonq2: but each import itself is linearly reading the publishing hsistory, as we care about the order things happen in21:01
tsimonq2Ah ok.21:02
tsimonq2Right.21:02
nacctsimonq2: 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 possible21:03
tsimonq2nacc: Right.21:04

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!