[00:40] <infinity> wgrant: Hrm, no can accept libreoffice.  Irksome.
[00:45] <slangasek> was there any specific reason to leave the language-pack-kde uploads in the queue, or should I flush them?
[00:51] <wgrant> infinity: A timeout?
[00:51] <infinity> wgrant: Sadly, yeah.
[00:52] <wgrant> I believe it's illegal in most jurisdictions to mention a timeout with its OOPS ID
[00:52] <wgrant> s/with/without/
[00:52] <wgrant> We may be able to bump the timeout enough
[00:52] <infinity> https://oops.canonical.com/oops/?oopsid=OOPS-bc3d500f772ea9e03cb98de14e919500
[00:52] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=bc3d500f772ea9e03cb98de14e919500
[00:53] <wgrant> Thanks
[00:53] <infinity> ubot2: That was pretty wildly unhelpful.
[00:53] <ubot2> infinity: Error: I am only a bot, please don't think I'm intelligent :)
[00:53] <wgrant> Does libreoffice still have hundreds of langpack packages?
[00:53] <infinity> wgrant: It does, yeah.  Does/should that matter for a source accept?
[00:53] <wgrant> Oh, source, no
[00:53] <wgrant> Hm
[00:53] <wgrant> Did you retry that?
[00:53] <wgrant> The timeout doesn't make very much sense
[00:54] <wgrant> There's this rather suspicious 8.5s gap in the SQL log
[00:54] <wgrant> Which looks like a one-off
[00:55] <infinity> I tried once from the web UI, twice from the CLI.
[00:55] <wgrant> Another OOPS ID would be helpful
[00:56] <infinity> Sure, I'll do it again!
[00:56] <wgrant> Heh
[00:56] <infinity> ...
[00:56] <infinity> And now it works.
[00:56] <infinity> Mechanic's syndrome.
[00:57] <wgrant> As long as you're unblocked :)
[00:57] <wgrant> We'll see the OOPSes in tomorrows reports
[00:57] <wgrant> I wonder if that 9s delay is consistent
[00:57] <infinity> To prove I'm not full of it, another OOPS for the same timeout was:
[00:57] <infinity> https://oops.canonical.com/oops/?oopsid=OOPS-bc3d500f772ea9e03cb98de14e919500
[00:57] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=bc3d500f772ea9e03cb98de14e919500
[00:57] <wgrant> It's really really odd
[00:57] <wgrant> Aha, thanks
[00:57] <infinity> Wait, that's the same one.
[00:57] <infinity> Wut?
[00:57] <wgrant> Yes, yes it is
[00:58] <infinity> On two different runs of the API tool, though.
[00:58] <infinity> My scrollback doesn't lie...
[00:58] <wgrant> Nope
[00:58] <wgrant> It does lie
[00:58] <wgrant> https://oops.canonical.com/oops/?oopsid=OOPS-eddb1503e8421232ad7713cdada76c44 is another one
[00:58] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=eddb1503e8421232ad7713cdada76c44
[00:59] <wgrant> Hmmm
[00:59] <infinity> Unless I'm blind...
[00:59] <infinity> http://paste.ubuntu.com/1263001/
[00:59] <wgrant> A 6s hole between those two queries this time
[00:59] <wgrant> wat
[00:59] <infinity> I swear that has the same OOPS twice.
[00:59] <infinity> Are async jobs re-entrant? :P
[00:59] <infinity> Okay, no, I'm blind.
[01:00] <wgrant> Search for x-lazr-oopsid
[01:00] <wgrant> There are two
[01:00] <infinity> THere's the other OOPS.
[01:00] <infinity> Evidently, scrolling through raw XML makes me go cross-eyed.
[01:00] <wgrant> Yeah
[01:00] <wgrant> So, all three OOPSes show the same thing, and none of them make much sense at all
[01:01] <wgrant> Oh
[01:01] <wgrant> Hmm
[01:01] <wgrant> That's about the time it would parse P-a-s
[01:01] <wgrant> But last I heard the appservers didn't have P-a-s.
[01:02] <wgrant> But I wonder if it's retrieving the source's binary history
[01:02] <wgrant> Which is quite a few binaries, IIRC
[01:02] <infinity> It's a lot of everything.
[01:02] <infinity> I think it's one of those source pages that times out, too.
[01:03] <wgrant> It's also the only source package that regularly ENOSPCs our builders
[01:03] <infinity> Only the PPAs, but yes.
[01:03] <wgrant> Hm
[01:03] <wgrant> The hole is right where it shells out to dpkg-architecture
[01:04] <infinity> That makes no sense.
[01:04] <infinity> Cause that call wouldn't be package-dependant.
[01:04] <wgrant> No, and it could be something that's just nearby
[01:04] <wgrant> Exactly
[01:06] <wgrant> But there's indeed no P-a-s specified
[01:14] <wgrant> And surely the scheduler doesn't hate us that much
[01:15] <wgrant> infinity: I think Launchpad just really really doesn't like you
[01:15] <infinity> wgrant: I'm not inclined to disagree with your analysis.
[01:15] <wgrant> It probably saw your blueprint change this morning
[01:25] <wgrant> infinity: Bug #1062638
[01:25] <ubot2> Launchpad bug 1062638 in launchpad "Queue accepts occasionally time out due to huge non-SQL time in createMissingBuilds" [Critical,Triaged] https://launchpad.net/bugs/1062638
[04:08] <tjaalton> anyone available to ack the precise-proposed upload for bug 966744?
[04:08] <ubot2> Launchpad bug 966744 in xserver-xorg-video-intel "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,In progress] https://launchpad.net/bugs/966744
[04:11] <infinity> tjaalton: I can look at it.
[04:11] <tjaalton> infinity: thanks
[04:11] <tjaalton> updating the sru header atm
[04:12] <infinity> tjaalton: You seem to be lacking bugs for the other patches?
[04:12] <tjaalton> infinity: that's the info I added there :)
[04:12] <infinity> Added... Where?
[04:13] <tjaalton> to the bug above
[04:13] <infinity> Oh, are you implying that all three patches address the same bug?
[04:13] <tjaalton> [regression potential]
[04:13] <tjaalton> yes
[04:13] <tjaalton> well, the first one was a by-product
[04:13] <tjaalton> when trying to reproduce it
[04:14] <tjaalton> hmm or maybe not
[04:18] <tjaalton> sigh, can't confirm it either way, since I added it to the branch late-august
[04:18] <infinity> tjaalton: Yeah.  I mean, they all sound like valid and useful bugfixes, but the compiz/resume thing doesn't seem to relate to the output-attach/resume issue?
[04:19] <infinity> tjaalton: There's no bug for the 106 patch?
[04:19] <tjaalton> upstream bugs yes
[04:19] <tjaalton> I'll check lp
[04:19] <tjaalton> pretty hard to match them..
[04:22] <infinity> tjaalton: Well, if there's no bug, there's no way to have a testcase to make sure it's fixing the bug, etc.  Sounds like the sort of thing we'd like to make sure is verified.
[04:25] <tjaalton> woohoo, bug 992391 should match fdo 50078
[04:25] <ubot2> Launchpad bug 992391 in xserver-xorg-video-intel "[i915] xserver freeze on switching VGA1/LVDS1" [Undecided,Confirmed] https://launchpad.net/bugs/992391
[04:26] <infinity> Ahh, so it doesn't need to be on suspend, it can be triggered manually with display switching?
[04:26] <infinity> Much easier to verify.
[04:26] <infinity> And also a much worse bug. :P
[04:26] <infinity> Can you give me a fresh upload with a bug closure in the changelog?
[04:28] <tjaalton> yes
[04:28] <tjaalton> seems like this was filed upstream too and then marked as closed, will check again if it really is the other bug..
[04:29] <infinity> Sure.  You may have a third bug on your hands.  Worth checking before uploading.
[04:29] <infinity> Cause these all sound like vaguely nasty behaviours.
[04:29] <tjaalton> heh
[04:30] <tjaalton> and actually, fdo 50100 references the commit in 50078 so I'll just add the bug closure there and ping the bug so they'll test it once it hits proposed
[04:33] <tjaalton> infinity: uploaded, but I wonder if it works with the same version number?
[04:33] <infinity> tjaalton: It does.
[04:34] <infinity> tjaalton: The queue doesn't care, only the archive.  I'll just reject one.
[04:34] <tjaalton> ah, cool
[04:36] <infinity> tjaalton: Okay, that changelog looks better.  I'll double-check the diff when it comes through and you should be good to go if you didn't just introduce weird cruft or replace an X driver with a copy of frozen-bubble.
[04:37] <tjaalton> heh, no the branch looks clean
[04:37] <infinity> Yes, but it's my job to not believe you. :)
[04:37] <tjaalton> of course :)
[04:39] <infinity> Oops, no precise task for that second bug.
[04:39]  * infinity fixes that.
[04:40] <tjaalton> i can do that
[04:40] <infinity> tjaalton: I don't care if there's all the SRU headers on that one, but do me a favour and make sure there's a clear test case somewhere.
[04:40] <infinity> tjaalton: I already set up the task. :P
[04:41] <tjaalton> heh, thanks
[04:41] <tjaalton> ok I'll see if the test case works here
[04:42] <infinity> Yeah.  The bug description itself IS a pretty good test-case, assuming it actually reproducibly crashes the server.
[04:42] <tjaalton> right, _should_ be easy to hit
[12:12] <Laney> ScottK: popey: anyone else: https://ubuntuone.com/1oBE6gcsZopYjcldngBqkr
[12:12] <Laney> I had to do one additional fix, but it looks good to me now.
[12:12] <Laney> I'm going to upload it to the queue.
[12:12] <popey> what was the fix?
[12:12] <Laney> same fix as Mirv did to Ubuntu-M but for Ubuntu-MI
[12:13] <Laney> otherwise Ubuntu Light Italic comes out as Ubuntu Medium Italic
[12:14] <popey> tested that fudged font on other platforms? (i.e. LO and other apps on Windows?
[12:14] <Laney> no
[12:14] <Laney> but I'm not going to upload it to windows :P
[12:14] <popey> sure, but we don't want different binary versions of the font for different platforms really do we?
[12:15] <Laney> if Windows is broken but Ubuntu is not then I wouldn't be too unhappy with a fork
[12:15] <Laney> it's this or rustle up DM to do the fix with their real tools
[12:16] <Laney> Qt is working as far as I can see too :-)
[12:17] <popey> forking our own font because our own apps don't work with it seems sub-optimal to me.
[12:19] <cjwatson> We're willing to patch our own non-font packages if need be
[12:24] <Riddell> Laney: got packages to test?
[12:24] <Laney> Riddell: queuebot will update you in 3...
[12:24] <Laney> 2...
[12:25] <Laney> 1 ...
[12:25] <Laney> :(
[12:25] <Laney> anyway, it is in the queue. Build that and try it out.
[12:27] <Laney> I'll leave it up to others to decide whether to accept now or reject/accept on Monday
[12:27] <Laney> out for a little while, bye
[12:28] <popey> thanks Laney
[12:56] <Riddell> Laney: fonts working good in Kubuntu for me
[12:56] <Riddell> ScottK: ^^
[13:48] <skaet> ^ Based on the fonts working ok for Riddell,  have accepted it.
[15:34] <ScottK> Riddell: Thanks.
[16:32] <cjwatson> so I know in outline what's wrong with aptdaemon, I think, but I have to get ready to go out for dinner
[16:32] <cjwatson> I'll finish fixing it when I get back
[16:32] <cjwatson> (just to save anyone else duplicating work on it)