[00:05] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/db-destroy-potmsgset-potemplate/+merge/131294
[00:05] <StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/deal-with-unsynched-bugwatch-comments/+merge/131293
[00:11] <wallyworld> StevenK: shouldn't test_can_delete_watch() test that the bug watch has been deleted?
[00:12] <StevenK> How do you suggest I test that something is deleted? :-)
[00:13] <wallyworld> ask the db if it is there
[00:13] <wallyworld> the doc test did it
[00:13] <wallyworld> also, what about that bug which requires the Not()
[00:13] <wallyworld> it seems the Not() is removed now
[00:16] <StevenK> That bug is marked as Fix Released
[00:16] <wallyworld> ah ok
[00:17] <wallyworld> that's a problem in general - bugs get marked as fixed but the xxxs stay in the code
[00:17] <wallyworld> maybe the bugs should have the xxxs listed
[00:17] <StevenK> wallyworld: http://pastebin.ubuntu.com/1303889/
[00:18] <wallyworld> that works i think, thanks
[00:18]  * StevenK fixes it so it actually works
[00:19] <StevenK> wallyworld: I like http://pastebin.ubuntu.com/1303891/ much better
[00:19] <wallyworld> StevenK: my brain is dumb today - how does the branch fix the issue? it seems the same query is run as before the branch?
[00:19] <StevenK> wallyworld: Today? :-P
[00:19] <wallyworld> well, more than usual
[00:20] <wallyworld> the second attempt is better yes
[00:20] <mwhudson> huh
[00:20] <mwhudson> https://dev.launchpad.net/CleaningUpOurCode talks about make xxxreport
[00:20] <mwhudson> which is a Makefile rule that exists
[00:20] <mwhudson> but doesn't work
[00:20]  * wallyworld didn't know about that report
[00:21] <StevenK> wallyworld: Right, so before the view code was using IBugWatch.getImportedBugMessages() which wanted both BugMessage.bugwatch == self and BugMessage.remote_content_id != None. The new method is IBugWatch.getBugMessages() which only checks BugMessage.bugwatch == self.
[00:21] <mwhudson> wallyworld: you reviewed the branch that deleted it :-)
[00:21] <StevenK> wallyworld: As a bonus, I refactored IBugWatch.getImportedBugMessages() to call IBugWatch.getBugMessages() to save LoC.
[00:22] <wallyworld> mwhudson: oh, right. i didn't look at the contents. the file was just moved to lp-dev-utils
[00:23] <wallyworld> StevenK: ok, thanks. obvious now. r=me
[00:24] <StevenK> wallyworld, mwhudson: I've done a drive-by to drop that Makefile target in the branch
[00:24] <StevenK> wallyworld: In the one you just reviewed, if you don't mind much
[00:25] <wallyworld> sure, np. i didn't realise the makefile target was there. curtis just said to move the files across to lp-dev-utils which i did
[00:26] <wallyworld> i'll update the wiki
[00:29] <mwhudson> There are 5244 XXX comments in revno: 16183.
[00:31] <StevenK> You're a little out of date
[00:31] <mwhudson> only a couple of days i thought?
[00:31] <StevenK> Only 5 revs, so like yesterday
[00:32] <StevenK> Sorry, 6 revs
[00:41] <sinzui> mwhudson, I think the page is somewhat outdated. I was given instructions to make it obsolete by tying all the XXXs there were about bugs to real bugs in Lp, then stop using the script
[00:42] <sinzui> That was 3 years ago I think
[00:42] <mwhudson> sinzui: yes, it all looks a bit stale
[01:17] <StevenK> wgrant: Can haz db review?
[01:18] <wgrant> StevenK: Sure
[01:18] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/db-destroy-potmsgset-potemplate/+merge/131294
[01:27] <StevenK> wgrant: Should I hold off landing that until tonight?
[01:28] <wgrant> StevenK: Please do
[01:28] <wgrant> There's a bit of a queue
[01:28] <StevenK> Where a bit is 2 :-P
[01:28] <wgrant> And no rush on this
[01:31] <StevenK> https://oops.canonical.com/oops/?oopsid=OOPS-d79b482989c5e4175a55160a8e1aee5c
[01:31] <StevenK> 5 second translations SQL statement, and I can't work out which bit of the code is doing it
[01:32] <lifeless> StevenK: you've got the backtrace
[01:32] <lifeless> sure
[01:32] <lifeless> ly
[01:33] <wgrant> Not if it's from a resultset that's lazily evaluated later
[01:33] <StevenK> I've found the method that is directly respsonsible, anyway
[01:33] <StevenK> ITranslationsPerson.suggestReviewableTranslationFiles()
[01:33] <lifeless> wgrant: ugh true. Another reason to dislike such.
[01:34] <StevenK> Yay Storm
[01:35] <StevenK> ... This query is disgusting
[01:41] <StevenK> wgrant: http://pastebin.ubuntu.com/1303986/
[01:42] <StevenK> That's with it hot, cold is something like 116 seconds
[01:43] <mwhudson> is something in there a view?  that seems surprisingly horrible
[01:44]  * mwhudson is just waiting for a backup to finish before disappearing, don'
[01:44]  * mwhudson is just waiting for a backup to finish before disappearing, don't let me distract you
[01:44] <StevenK> mwhudson: Yeah, pulled in via TranslationsPerson:+index
[01:44] <wgrant> Not that sort of view :)
[01:44] <mwhudson> StevenK: i mean database view :)
[01:45] <StevenK> Oh, no.
[01:45] <StevenK> Thankfully
[01:45] <mwhudson> also what happened here?
[01:45] <mwhudson> ORDER BY POFile.date_changed; > 0uched >= '2012-03-16 06:00:00+00:00'tor.transla
[01:45] <StevenK> That would be readline
[01:47] <StevenK> http://pastebin.ubuntu.com/1303993/ better
[01:47] <mwhudson> ah
[01:47] <mwhudson> the query in the oops looks more horrible :)
[01:47] <mwhudson> or indeed, that one
[01:49] <StevenK> wgrant: So how do I start to work out what is causing the slowness instead of 'the whole thing' ?
[01:49] <wgrant> Well
[01:49] <wgrant> The whole thing
[01:49] <wgrant> Work out what the query is being used for
[01:49] <wgrant> Make sure Launchpad never thinks of doing it again
[01:50] <StevenK> It's a table of suggestions they could work on
[01:50] <StevenK> 'alsa-utils needs 1 string review in Spanish
[01:52] <wgrant> StevenK: First step is to get a version of that query that doesn't make one wish to be blind
[01:52] <wgrant> ie. indent it nicely
[01:53] <StevenK> wgrant: http://pastebin.ubuntu.com/1304003/
[01:53] <wgrant> It burns
[01:53] <wgrant> Oh god
[01:53] <wgrant> It burns
[01:54] <wgrant> That's not indented, that's deindented.
[01:54] <StevenK> You can blame sqlformat for that
[01:55] <mwhudson> http://www.dpriver.com/pp/sqlformat.htm appears to do a better job
[01:56] <wgrant> http://pastebin.ubuntu.com/1304010/
[01:57] <wgrant> Although mwhudson's link isn't bad
[01:57] <StevenK> http://pastebin.ubuntu.com/1304014/
[02:00] <wgrant> StevenK: So, what's the query trying to do?
[02:02] <StevenK> wgrant: It is trying to return a list of up to 9 projects/packages that the person could review strings on.
[02:02] <wgrant> Right
[02:43] <StevenK> wgrant: So, now that I've had lunch
[02:54] <wgrant> StevenK: Indeed
[02:58] <StevenK> wgrant: So I'm not comfortable just ripping out the functionality, but it only caused 21 OOPSes yesterday
[02:58] <wgrant> StevenK: I'd see if the query performs reasonably for any people at all
[02:59] <StevenK> wgrant: Based on the bug, it is only used if you load up your own +translations page
[03:00] <wgrant> Sure
[03:00] <wgrant> But more than that one person loads up their own +translations pages
[03:01] <StevenK> 3501ms for me, since I know my DB ID
[03:01] <StevenK> So, "No." ?
[03:01] <StevenK>               ->  Index Scan using pofiletranslator__person__pofile__key on pofiletranslator  (cost=0.00..0.97 rows=1 width=4) (never executed)
[03:02] <StevenK> Is that postgres' way of saying that I have no pofiles and so it doesn't need to index scan?
[03:02] <wgrant> Well, it never got to a point where it needed to do that scan
[03:03] <StevenK>                                        ->  Materialize  (cost=8940.46..12479.23 rows=24747 width=16) (actual time=4.288..25.864 rows=24756 loops=42)
[03:03] <wgrant> Possibly because all the pofiles were already filtered out by that point
[03:03] <StevenK> Hm, haven't seen that one before
[03:04] <wgrant> StevenK: It's used when a join can use a reasonable (ie. fits in memory) subset of a table more efficiently than the whole one
[03:05] <wgrant> So it'll fetch that subset into an automatic temporary table in RAM
[03:05] <wgrant> Once, usually
[03:05] <wgrant> Then the join can loop over that subset more efficiently
[03:06] <wgrant> So it's like a seqscan, except over a subset of the table
[03:06] <StevenK> Ah
[03:07] <StevenK> So, the whole thing is a mess, and looks like it performs horribly no matter who the person is
[03:07] <wgrant> Right
[03:07] <wgrant> I'm not sure how much better we can actually make it
[03:07] <wgrant> Given that what it's doing is fairly hideous
[03:07] <StevenK> Yeah, 3546 ms for lifeless, since his ID is so trivial
[03:08] <StevenK> wgrant: I should /+daily-builds it?
[03:08] <lifeless> it should be better than it was :)
[03:08] <wgrant> Only marginally
[03:10] <StevenK> lifeless: Yeah, I think this query is so terrible that it doesn't matter who we ask it about
[03:15] <wgrant> StevenK: Are you sure you got the right method?
[03:16] <wgrant> I don't think it's the one you mentioned
[03:16] <StevenK> Looks right to me, based on the call chain and the query
[03:17] <wgrant> StevenK: I think it's getReviewableTranslationFiles, not suggestReviewableTranslationFiles
[03:19] <wgrant> Indeed, the traceback confirms it's _review_targets
[03:22] <StevenK> Hmmmm
[03:22] <StevenK> I wonder if I've deleted too much
[03:26] <StevenK> wgrant: Is this where you say "Impossible!" ?
[03:29] <wgrant> No
[03:29] <wgrant> This is very possible
[03:29] <wgrant> There's one big simplification in getReviewableTranslationFiles
[03:29] <wgrant> Which makes things much easier
[03:30]  * StevenK calls revert a lot
[03:31] <StevenK> wgrant: Now, share?
[03:31] <wgrant> It's trying to find suggestions that the user can review, as you say
[03:32] <wgrant> But, more specifically, the relevance is based on whether they've translated in them recently
[03:32] <wgrant> The last join is a big win
[03:32] <wgrant> As it restricts the set to those pofiles for which there is a recent pofiletranslator for the person
[03:34] <StevenK> The method doesn't do that already?
[03:34] <wgrant> It does.
[03:42] <lifeless> but if you did it earlier, it might work better
[03:42] <StevenK> wgrant: Oh, you're saying we shouldn't do that join?
[03:42] <StevenK> This code isn't particularly clear to me, and my blocked sinuses are not helping matters.
[03:44] <wgrant> What lifeless said
[03:45] <wgrant> People generally translate fewer POFiles than there are POFiles in all of Launchpad
[03:45] <wgrant> s/People/A single person/
[03:45] <StevenK> IE, a CTE?
[03:45] <wgrant> So it's likely to be more efficient to work from the list of recently translated pofiles
[03:45] <wgrant> That would be a good start
[03:45] <wgrant> It'll probably require a bit more fiddling
[03:46] <wgrant> As there's a lot of joins, so it's not necessarily going to be able to optimise very well
[03:46] <wgrant> But I'd start by trying to coerce it into starting from POFileTranslator
[03:46] <StevenK> Given the function brings together the query via calling functions, this is going to be ... fun
[03:46] <wgrant> (this time I don't have a <20ms solution yet)
[03:46] <StevenK> Haha
[03:49] <StevenK> Oh ugh, trying to pull out TeamParticipation makes it all unravel, because that's JOINed via TranslationGroup which is pulled in via Project/Distribution and then POTemplate
[03:51] <wgrant> StevenK: Yeah
[03:51] <wgrant> It's a bit ugly
[03:53] <StevenK> I can see how starting from POFileTranslator.person and Translator.translator is a win, but I can't quite work out how to do that
[03:54] <wgrant> Pull it out bit by bit until it works
[03:54] <wgrant> Then try to compress it back into something that's not hideous
[03:54] <wgrant> But still works relatively quickly
[03:55] <wgrant> At this point we know the sort of plan we want
[03:55] <wgrant> We just need to convince postgres of it
[03:58] <StevenK> wgrant: http://pastebin.ubuntu.com/1304155/
[04:01] <wgrant> I have a 15ms query that mostly works
[04:01] <wgrant> By "mostly works" I mean "returns some similar results but isn't actually the same thing and I haven't worked out why yet"
[04:01] <wgrant> Also it's pretty fugly
[04:03] <StevenK> wgrant: http://pastebin.ubuntu.com/1304156/ is as far as I've gotten, but it's still 3150ms
[04:03] <StevenK> So better, but still terrible
[04:07] <wgrant> Oh
[04:07] <wgrant> It helps if I use productseries rather than distroseries twice
[04:08] <wgrant> But still, 30ms and it seems correct
[04:08] <wgrant> I have four CTEs: recent_pofiles, reviewable_groups, reviewable_distroseries, reviewable_productseries
[04:12] <StevenK> wgrant: Are you going to share, or do I need to rewrite my query until it matches? :-)
[04:13] <wgrant> Just checking some stuff
[04:13] <wgrant> eg. performance for other people
[04:14] <wgrant> StevenK: http://paste.ubuntu.com/1304165/
[04:15] <StevenK> (POTemplate.productseries, POFile.language) IN (SELECT * FROM translatable_productseries)
[04:15] <StevenK> That's pretty awesome
[04:15] <StevenK> And sneaky
[04:15] <wgrant> I try.
[04:16] <StevenK> Heh, it's as slow as the old hot query when it's cold.
[04:16] <StevenK> If that sentence makes sense.
[04:17] <StevenK> Hm, it seq scans both distroseries and distribution
[04:17] <StevenK> But they aren't large
[04:18] <wgrant> It can be indexed if needed, but those tables are so small it probably wouldn't use them
[04:18] <StevenK> The SubPlan 5 and 6 are the above awesomeness I pasted?
[04:19] <wgrant> Yeah
[04:19] <StevenK>  Total runtime: 0.543 ms
[04:19] <StevenK> For me
[04:20] <wgrant> Right, because pofiletranslator will have nothing for you
[04:20] <StevenK> Yeah, and it just skips large parts of the query
[04:20] <wgrant> Note that pofiletranslator isn't even properly indexed, but people rarely have more than 5000 rows so it's still fast
[04:21] <StevenK>                  ->  Bitmap Index Scan on pofiletranslator__person__pofile__key  (cost=0.00..5.43 rows=128 width=0) (actual time=0.056..0.056 rows=14 loops=1)
[04:21] <StevenK>                        Index Cond: (person = 6874)
[04:21] <StevenK> Looks indexed?
[04:21] <wgrant> It's indexed *enough*
[04:21] <wgrant> But it's not indexed properly
[04:22] <StevenK> Ah ha
[04:22] <wgrant>            ->  Bitmap Heap Scan on pofiletranslator  (cost=5.43..480.97 rows=6 width=4) (actual time=0.422..2.305 rows=215 loops=1)
[04:22] <wgrant>                  Recheck Cond: (person = 1780257)
[04:22] <wgrant>                  Filter: (date_last_touched >= '2012-03-16 06:00:00'::timestamp without time zone)
[04:22] <wgrant> It finds all the pofiletranslator rows for the person, then filters them by date_last_touched
[04:23] <wgrant> When it would save a couple of ms to have an index on (person, date_last_touched)
[04:23] <wgrant> And if we were on 9.2, it'd be even faster with (person, date_last_touched, pofile)
[04:23] <StevenK> Right
[04:23] <wgrant> The precise query formulation is going to become a *lot* more important when we upgrade to 9.2
[04:23] <wgrant> There's a lot of opportunity for big big wins
[04:24] <StevenK> Index only scans have you salivating?
[04:24] <wgrant> Only salivating? You underestimate me.
[04:24] <StevenK> Haha
[04:24] <StevenK> I'll leave the dirty jokes to wallyworld, he's better at them.
[04:25] <wallyworld> no i'm not
[04:26] <wallyworld> what does 9.2 offer?
[04:26] <StevenK> Mainly, index only scans
[04:26] <StevenK> IE, don't even hit the table, just pull the data straight from the index
[04:27] <wallyworld> oh very cool
[04:28] <wgrant> Right
[04:28] <wgrant> It'll make teamparticipation/APG/etc particularly fast
[04:29] <wgrant> But also lots of other things, with a bit of query tweaking
[04:29] <wallyworld> bring it on then
[05:18] <StevenK> wgrant: Holy crap, I'm down to 2 failures.
[05:21] <StevenK> AND POFileTranslator.date_last_touched >= None)
[05:21] <StevenK> Hahahaha
[05:23] <wgrant> StevenK: There were failures? :(
[05:23] <StevenK>   Ran 23 tests with 0 failures and 0 errors in 20.290 seconds.
[05:24] <StevenK> wgrant: Yeah, but they were all due to my Stormification of the query
[05:24] <wgrant> Ah
[05:28]  * StevenK tries to work out how to drag ITranslationsPerson.suggestReviewableTranslationFiles() into line
[05:29] <StevenK> The queries are virtually identical, the ORDER BY is different, and it uses a LEFT JOIN rather than a JOIN on POFileTranslator with the added condition of POFileTranslator.id == None
[05:32] <StevenK> Ah, no, it's a LEFT JOIN rather than a JOIN, and the TRUE that was in the guts of the old query is POFileTranslator.id == None
[05:32] <wgrant> Right, it's an antijoin
[05:33] <StevenK> Except that we've CTE'd the query within an inch of its life
[05:44] <StevenK> wgrant: I think my CTE antijoin doesn't quite work
[05:44] <wgrant> StevenK: Well, do you have a plan that should be fast?
[05:46] <StevenK> wgrant: I'm using the four CTEs of Doom with the LEFT JOIN change etc, but two tests fail, so it isn't quite right
[05:46] <wgrant> StevenK: Remember that my query is based around the assumption that there a user contributes to only a tiny subset of the full set of pofiles.
[05:52] <StevenK> wgrant: http://pastebin.ubuntu.com/1304235/
[05:53] <StevenK> My guess is the LEFT JOIN in recent_pofiles is what is wrong
[05:54] <wgrant> Right, it's wrong, but even if it was right it would probably be *extremely* slow
[05:54] <wgrant> Because you'd be asking it to build a list of all pofiles that you haven't contributed to
[05:54] <wgrant> Which is not a tiny subset of the full set of pofiles
[05:54] <StevenK> At the moment, it's incredibly fast :-)
[05:54] <wgrant> So the premise of my original restructured query is broken
[05:55] <StevenK> Right, so pulling ITranslationsPerson.suggestReviewableTranslationFiles() into line is harder than I thought
[05:56] <wgrant> What's it used for?
[05:56] <wgrant> Can you see an optimisation strategy similar to the one we used for getReviewableTranslationFiles?
[05:57] <StevenK> It is used in a view to find random translation targets for review
[05:58] <StevenK> That the user hasn't contributed to
[06:00] <wgrant> Right
[06:00] <wgrant> That last line is the key
[06:00] <wgrant> We were able to heavily optimise the previous query because we could restrict the search early to just a few thousand pofiles.
[06:00] <wgrant> With this query we don't have that luxury.
[06:01] <StevenK> Indeed
[06:01] <StevenK> Let me revert the suggest bit
[06:01] <wgrant> So attempting to reuse the optimisations that worked for the last query is perhaps slightly unwise
[06:01] <wgrant> Since the base assumption of the optimisation strategy does not hold here
[07:05] <rick_h_> benji___: ping
[07:17] <benji> rick_h_: hi (I didn't hear your ping, for some reason my laptop does not beep when on battery)
[07:19] <rick_h_> benji: np, nvm though. Was going to go through and run the tests for lpsetup but wanted to check how much of my systemit would take over and should I setup a virtualenv
[07:19] <rick_h_> but going through the readme see what's up
[07:19] <StevenK> dpm: O hai, can you look at staging? The stats should be fine
[07:19] <dpm> morning StevenK, cool. Give me a minute and I'll have a look
[07:32] <benji> rick_h_: yeah, the unit tests are safe; there is a functional test that is more intrusive, but it isn't run by default
[07:32] <rick_h_> yea, the unit tests all pass fine
[07:54] <czajkowski> morning
[08:03] <StevenK> dpm: No news is good news?
[08:20] <dpm> StevenK, sorry, I was on the phone, looking at it now
[08:24] <dpm> StevenK, the stats are not 100% identical, but that's fine, as I guess there has been some translation activity in quantal in the meantime. So all looks good to me except for one thing: it seems the Contributors column hasn't been updated along with the other statistics, and it's empty
[08:26] <wgrant> The near-daily ScrubPOFileTranslator job should take care of that after a few days, I believe
[08:27] <wgrant> But we can't sensibly run that in full on staging due to resource constraints
[08:29] <dpm> in that case, it all looks good to me
[08:42] <StevenK> dpm: Excellent, thank you. I'm not really fan of running the job on prod tomorrow, how does Monday sound to you?
[08:43] <dpm> StevenK, sounds perfect to me, I wouldn't consider this to be urgent
[08:43] <StevenK> dpm: Oh, sure, but I'd like to get it off my plate. :-)
[08:43] <dpm> absolutely :)
[09:05] <cjwatson> wgrant: I've fixed the problem you spotted in redirect-release-uploads now; do you need to re-review?
[09:09] <wgrant> cjwatson: Looks good, thanks
[09:09] <wgrant> adeuring: Hi, will you have time to QA bug #1069826 today?
[09:09] <_mup_> Bug #1069826: privacy aware security adapter for IProjectGroupMilestone <qa-needstesting> <Launchpad itself:Fix Committed by adeuring> < https://launchpad.net/bugs/1069826 >
[09:10] <adeuring> wgrant: doing it right now :)
[09:10] <wgrant> Lovely, thanks
[09:14] <cjwatson> wgrant: Thanks.
[09:26] <abentley> deryck: Could you please review lp:~abentley/launchpad/beta-banner ?
[09:27] <cjwatson> abentley: I think https://code.launchpad.net/~cjwatson/lazr.jobrunner/userErrorTypes/+merge/131248 probably needs either you or adeuring to review it, ideally, since you're the owners on PyPI?
[09:28] <abentley> cjwatson: be with you in a few minutes.
[09:28] <cjwatson> Thanks
[10:06] <abentley> cjwatson: Wow, took me a while to understand why we did that.  r=me.
[10:07] <cjwatson> Thanks.  I doubt I can land and release it. :-)
[10:08] <cjwatson> (It'll presumably want to go into lp-sourcedeps after release, too.)
[10:17] <abentley> cjwatson: You can certainly land it.  I or abel would have to release it, though.
[10:18] <abentley> cjwatson: I'll go ahead and do it all, this time.
[10:22] <cjwatson> Oh, do such things just go through PQM?
[10:22] <cjwatson> The trunk commit history all seems to be direct commits.
[10:23] <cjwatson> Ah, I'm in ~canonical-launchpad-branches.  Fair enough.
[10:23] <cjwatson> Thanks.
[10:41] <abentley> cjwatson: np
[10:42] <abentley> cjwatson: But I'm having trouble getting tests to pass, so the release may take a while.  You can generate your own tarball for now, if you want to keep hacking.
[10:43] <cjwatson> No rush, I have plenty of other stuff to do.  Just wanted to make sure it wasn't blocked on me.
[11:56] <cjwatson> Eek, I broke buildbot.  (I.  Hate.  Doctests.)  Could I have a review of https://code.launchpad.net/~cjwatson/launchpad/redirect-release-uploads-2/+merge/131383 so that I can land a testfix?
[11:57] <cjwatson> It's a one-liner.
[12:19]  * cjwatson trolls for a review of one-liner testfix https://code.launchpad.net/~cjwatson/launchpad/redirect-release-uploads-2/+merge/131383 in case the vagaries of the UDS network mean that more people can see it now
[12:25] <jml> cjwatson: approved.
[12:28] <cjwatson> jml: thanks
[12:43] <cjwatson> jcsackett: Are you likely to be able to manage your QA today?  I'm hoping that I might be able to get the branch currently working its way through buildbot deployed a bit later.
[14:07] <abentley> cjwatson: new release at http://pypi.python.org/pypi/lazr.jobrunner
[14:39] <jcsackett> sinzui: can you send me testemail.py?
[14:39] <sinzui> jcsackett, I will when qastaging is running. the schema needs patching
[14:39] <jcsackett> sinzui: aaah.
[14:52] <jcsackett> sinzui: nm, i found it in my mountains of email.
[14:52] <jcsackett> of course, still waiting on qa server.
[14:54] <sinzui> jcsackett, qastaging is back
[14:54] <jcsackett> oh sweet.
[14:56] <sinzui> jcsackett, my provider wont let me send. If you get that message, mark it qa-untestible
[15:00] <jcsackett> sinzui: yeah, i'm having the same issue.
[15:00] <jcsackett> ok, qa-untestable it is.
[15:26] <rick_h_> jcsackett: for your eyeballs if you get a sec. Kind of small https://code.launchpad.net/~rharding/launchpad/limit_product_types_1066904/+merge/131368
[15:33] <cjwatson> Could somebody add lazr.jobrunner 0.11 to download-cache?
[23:49] <wgrant> cjwatson: Did someone get around to that download-cache change?
[23:50] <cjwatson> wgrant: No
[23:53] <wgrant> cjwatson: I don't see 0.11 on LP
[23:53] <wgrant> I guess I'll grab it from PyPI
[23:54] <wallyworld_> wgrant: why weren't packaging components, ie universe, multiverse etc, done as a enumerated type? the code is littered with string literals 'multiverse' etc
[23:54] <wgrant> wallyworld_: Because they're not an enum, they're distro-specific config data
[23:54] <wgrant> Launchpad unfortunately retains lots of hardcoded rules for Ubuntu because it was never done properly
[23:54] <wgrant> Hence the hardcoded strings.
[23:54] <wallyworld_> ok, thanks
[23:55] <wallyworld_> i'm looking at soyuz code for the first time
[23:55] <cjwatson> one of these days ...
[23:55] <wgrant> I'm sorry for your loss.
[23:55] <wallyworld_> well, if i can understand enough to fix the bug, i'll be happy
[23:56] <cjwatson> (aka UE is not desperately keen on it being this way either, but not upset enough to demand it be fixed :-) )
[23:56] <wgrant> s/distro-specific/distroseries-specific/, even
[23:57] <cjwatson> if we ever get much further down the archive reorg then it might matter
[23:58] <wgrant> Indeed.
[23:58] <wgrant> cjwatson: lazr.jobrunner 0.11 is in download-cache
[23:59] <cjwatson> Thanks