[00:33] <cjwatson> OK, MP raised for the publishinghistory improvement above
[00:41] <cjwatson> And I've installed a workaround in copy-report to try to avoid those null copies
[00:53] <wgrant> cjwatson: I'm pretty sure there's an existing bug for that
[00:54] <wgrant> cjwatson: Also, that's buggy
[00:54] <wgrant> cjwatson: Look at the markup in the test you added :)
[00:55] <cjwatson> I looked for an existing bug and couldn't find one
[00:55] <wgrant> Maybe I'm thinking of sponsor
[00:55] <wgrant> So
[00:56] <cjwatson> Maybe it's too late at night, but what's wrong with the markup?
[00:56] <wgrant> I'd do <tal:message condition="context/creator">by <span tal:replace="structure context/creator/fmt:link" /></tal:message> or so
[00:56] <wgrant> It's escaped
[00:56] <cjwatson> ... oh, that escaping isn't introduced by extract_text is it?
[00:56] <cjwatson> I assumed it was doctest insanity
[00:56] <wgrant> No
[00:56] <wgrant> TAL is stupid
[00:56] <wgrant> You declare in the template whether a string is safe
[00:57] <wgrant> Rather than declaring in the string that the string is safe
[00:57] <cjwatson> Something like yours is what I started with and then I tried to imitate the surroundings
[00:57] <cjwatson> I'll put it back
[00:58] <wgrant> Don't imitate surroundings in LP
[00:58] <wgrant> They're usually wrong.
[00:58] <wgrant> Ah, yeah, I see your original diff
[00:58] <wgrant> The other places do it because there's no sensible fmt:link
[00:58] <wgrant> Or they ignore that there is one
[00:59] <wgrant> I'm not quite sure what that template has against IArchive's fmt:link.
[01:01] <cjwatson> Ah, bug 851047
[01:01] <ubot2> Launchpad bug 851047 in launchpad "The PPA page and distro publishing details pages don't correctly show where a package was copied from" [High,Triaged] https://launchpad.net/bugs/851047
[01:01] <cjwatson> Should I just try to fix this all at once?
[01:02] <cjwatson> Micah's single case was easyish ...
[01:02] <wgrant> cjwatson: Might as well. Even better if you show sponsor too, although I can't see a bug.
[01:02] <wgrant> Both should be pretty trivial
[01:02] <wgrant> The hardest bit is identifying the tests
[01:02] <wgrant> and ec2 will do that easily :)
[01:02] <wgrant> If slowly...
[01:03] <cjwatson> I managed to blow the monthly limit on the cloud computing policy last month
[01:03] <cjwatson> Roll on LP tests in Canonistack
[01:04] <wgrant> Hm, you should talk to someone about that. We're advised to file it under misc, since it's essential and anyone who's doing anything violates it.
[01:04] <wgrant> Now
[01:04] <wgrant> I'm just thinking
[01:04] <wgrant> +publishinghistory doesn't show any people at the moment, does it?
[01:04] <wgrant> So adding even one is probably going to make it time out.
[01:05] <wgrant> Fortunately, preloading this is roughly two lines if you can identify the views that render lots of these.
[01:06] <cjwatson> BinaryPublishingRecordView (though at least this part of the change is a no-op there) and SourcePublishingRecordView
[01:06] <wgrant> Yeah, those are the only two I can think of
[01:06] <cjwatson> That's from grep for that template
[01:06] <wgrant> The foreign keys you care about are all in the easy directly, fortunately.
[01:06] <wgrant> s/directly/direction/
[01:06] <wgrant> You don't have to deal with cachedproperties. Just load the objects into the global storm cache.
[01:07] <cjwatson> Just in initialize?
[01:08] <wgrant> Right. You'll probably want to use lp.services.bulk.load_related to grab the ancestor, and then getPrecachedPersonsFromIds or whatever it is to grab the creator and sponsor.
[01:10] <cjwatson> OK.  Tomorrow I think.
[01:10] <cjwatson> Thanks.
[01:12] <wgrant> Yeah.
[01:12] <wgrant> If you need any help, I'm happy to as always.
[01:36] <slangasek> wgrant: is this why +publishinghistory is now timing out for me? :)
[01:36] <wgrant> slangasek: No. Do you have an OOPS ID?
[01:36] <wgrant> It's unbatched, so packages with insane numbers of uploads will always time out.
[01:36] <wgrant> And have always timed out.
[01:36] <slangasek>  OOPS-9f81eb12c92b5d31bf2cdff106cade84)
[01:36] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=9f81eb12c92b5d31bf2cdff106cade84
[01:37] <slangasek> oh, really?
[01:37] <slangasek> I've never seen timeouts before
[01:37] <wgrant> It's better than it used to be, since it's not pulling down tens of megabytes of changelogs from the DB any more
[01:37] <wgrant> Wow
[01:38] <wgrant> 700ms of DB time, 5s of Python
[01:38] <wgrant> I suspect you were just fairly unlucky, but let's see...
[01:38] <wgrant> (since it loads for me)
[01:38] <cjwatson> slangasek: the above discussion between wgrant and me is of a patch that hasn't landed
[01:39] <slangasek> ok :-)
[01:39] <slangasek> I wouldn't have expected it to land so fast, but figured I should check
[01:39] <wgrant> Maybe by the end of the year we'll be deploying stuff an hour after we think of it, but not yet :)
[01:40] <slangasek> bdmurray: so I found your dist-upgrader-all directories; ubuntu/dists/precise-updates/main/dist-upgrader-all/ instead of ubuntu/dists/precise/main/dist-upgrader-all/
[01:40] <slangasek> bdmurray: are you saying that the precise-updates ones aren't being used?
[01:40] <slangasek> if so we probably have to manually copy... and put that on the pile of things to fix before we lose cocoplum shells ;)
[01:41] <cjwatson> slangasek: Uh, I fixed that recently
[01:41] <infinity> slangasek: The updates ones absolutely should be used, if that's not happening, we should fix the broken bits, not copy stuff into release...
[01:41] <slangasek> cjwatson: which part?
[01:41] <wgrant> Yeah, you're not going to convince LP to poke the release pocket
[01:41] <cjwatson> automatic copying from precise-proposed to precise-updates
[01:41] <wgrant> You'll have to fix u-m
[01:42] <slangasek> right
[01:42] <infinity> cjwatson: It's in updates.
[01:42] <cjwatson> Yeah, I didn't fix u-m, but that's what should be done.
[01:42] <cjwatson> Taking away our lp_publish access might be a good way to stop us being tempted to do that kind of thing. :)
[01:42] <wgrant> Yes :)
[01:43] <wgrant> slangasek: Does the page work for you now? I suspect you just had bad luck that time
[01:43] <wgrant> It's sitting at about 90% of the timeout for me, mostly because there's so many uploads
=== rsalveti` is now known as rsalveti
[01:43] <wgrant> We really should batch it, but there was resistance from you guys last time we tried ('09)
[01:43] <cjwatson> So the upgrade tool URL is in the meta-release file
[01:44] <infinity> Does mvo still hold all the keys to that?
[01:44] <cjwatson> http://changelogs.ubuntu.com/meta-release and friends
[01:44] <slangasek> there was resistance from cjwatson in particular to batching, yes
[01:44] <slangasek> I defer to him :)
[01:44] <cjwatson> Probably
[01:44] <slangasek> wgrant: page is timing out for me consistently
[01:44] <cjwatson> It would take mvo about a minute to fix it
[01:44]  * infinity nods.
[01:44] <cjwatson> batching> Well, the thing I objected to at the time was difficulty of searching
[01:44] <cjwatson> But, at the time, there wasn't an API worth mentioning
[01:45] <infinity> We might want to de-SPOF mvo on the meta-release stuff sometime.
[01:45] <infinity> It's not hard to fix, but it often seems to need fixing in a hurry (not this time, obviously).
[01:45] <cjwatson> I think nowadays it'd be fine to batch that and punt to the API for searchability
[01:46] <cjwatson> So consider my historical resistance withdrawn
[01:46] <slangasek> it's possible bdmurray has access to metarelease
[01:46] <wgrant> It's a very batchable page, because the core query to determine the contents is indexed, ordered and fairly quick.
[01:46] <slangasek> but he's EOD too :)
[01:46] <slangasek> anyway, I've taken that to email
[01:47] <cjwatson> I'd certainly rather it be batched than time out.
[01:47] <cjwatson> And the more we upload stuff, the more it times out for important packages.
[01:47] <wgrant> Yup
[01:47] <cjwatson> Fairly inevitably.
[01:47] <wgrant> You ignored that argument last time :P
[01:47] <cjwatson> I didn't ignore it, I just didn't consider it dominating
[01:47] <infinity> He clearly didn't maintaing anything important before.
[01:48] <infinity> Nor maintain.
[01:48] <cjwatson> We don't need to grep through +publishinghistory for stuff nearly so often now
[01:53] <slangasek> stgraber: the edubuntu-artwork SRU references a bug not marked as fixed in quantal?
[02:03] <stgraber> slangasek: let me check, I'm 90% sure that was fixed earlier in quantal
[02:04] <stgraber> slangasek: right, was fixed in 12.06.3
=== ScottL is now known as scott-work
[04:30] <slangasek> stgraber: ok.  I'm assuming you're ok with having this for .1, for edubuntu?
[04:30] <slangasek> (was uploaded before the deadline, anyway)
[04:34] <ScottK> slangasek: Looks to me like the compiz SRU should be failed/removed already since it FTBFS on arm*.
[04:36] <stgraber> slangasek: yep, I discussed it with jocarter before he uploaded.
[04:38] <infinity> ScottK: I'd concur with that.
[04:47] <stgraber> yeah, it should at least be marked as failed and probably removed. I can do some poking next week to figure out whether they had any critical bugs that need to be fixed for 12.04.1 or if they can wait till after the point release.
[04:57] <infinity> stgraber: Fixing the FTBFS shouldn't be rocket science for them, I'm sure.
[04:58] <infinity> stgraber: But releasing a skewed compiz is a non-starter, IMO.
[04:58] <infinity> stgraber: So, there shouldn't even be a "well, if it fixes some critical bugs..." consideration.
[05:05] <stgraber> infinity: well, I haven't looked at the diff but I remember ogra_ complaining quite a bit about the work needed to update the arm patches that sit on top of the compiz code.
[05:06] <stgraber> infinity: so yeah, skewed compiz is definitely a non-starter, I'm just wondering if we can have something fixed early enough (Monday/Tuesday) or if we can just postpone the compiz change until after we released 12.04.1
[05:08] <slangasek> there's at least one targeted compiz bug
[05:09] <slangasek> so, it shouldn't be promoted as-is, but I think we should try to get a fixed version
[05:26] <slangasek> bug #1032902 opened
[05:26] <ubot2> Launchpad bug 1032902 in compiz "compiz 1:0.9.7.8-0ubuntu1.3 FTBFS in precise-proposed on armel, armhf" [Critical,Triaged] https://launchpad.net/bugs/1032902
[06:16] <slangasek> infinity: ^^ if you happen to have some time this weekend, this mdadm SRU would be nice to have reviewed and (hopefully) accepted; it fixes the regression found in the previous one
[06:50] <infinity> slangasek: Diff looks like it should do (or, rather, not do) what it advertises...
=== yofel_ is now known as yofel
[15:17] <asomething> Hi all. I've got a regression in precise-proposed. The package is indicator-weather. There is a fix in the queue. I'd appreciate it if someone could accept the new package or at least nuke the old one until someone can accept the new one.
[15:17] <asomething> The regression is tracked in lp: #1032887
[15:17] <asomething> and the original bug that the SRU intended to fix is lp: #964365
[15:18] <asomething> version with regression: 11.11.28-0ubuntu1.1; fixed version: 11.11.28-0ubuntu1.2