[00:17] <wallyworld_> wgrant: StevenK: it seems IBugSet.createBugWithoutTarget() is only used internally by createBug(), it doesn't seem to be exported, there is a doctest for it. i'd like to remove the method from IBugSet. thoughts?
[00:18] <cjwatson> wgrant: Right.  Now if only I can get the last couple of tests passing ...
[00:18] <wgrant> cjwatson: What's broken?
[00:19] <wgrant> wallyworld_: I believe that used to be used by the email interface, but it's not any more. Destroy.
[00:20] <wgrant> wallyworld_: I deliberated avoided removing it last month because the email interface uses it.
[00:20] <wallyworld_> wgrant: yay, will allow me to simplify the AAG branch and fix failing tests
[00:20] <cjwatson> doctest hatred of some kind in xx-archive and xx-ppa-files.  (Not in front of the laptop right now - I'll have another crack at it tomorrow)
[00:20] <wgrant> But now you've made me check and it doesn't actually use it any more.
[00:20] <wgrant> cjwatson: Ah, right.
[00:20] <cjwatson> Maybe it was too ambitious to change the default for allow_delayed_copies.
[00:20] <wgrant> cjwatson: I imagine the diff should be fairly small?
[00:20] <cjwatson> Not horrible for what it does.  Several layers of tentacles.
[00:21] <cjwatson> Since the new unembargo option needs to go all the way up to the webservice layer.
[00:22] <wgrant> Yeah
[01:39] <cjwatson> wgrant_: https://code.launchpad.net/~cjwatson/launchpad/change-override-forbid-release-stable/+merge/110942 is that changeOverride bug-fix you asked for
[01:40] <lifeless> cjwatson: thanks for the 10GB reply
[01:40] <lifeless> cjwatson: the alternative to debdelta is !debsatall, which isn't something we've had much discussion on.
[01:41] <cjwatson> I confess I've never heard of it.
[01:41] <cjwatson> No relevant Google hits.
[01:42] <cjwatson> I think the short answer on debdelta is that it would be done by now if only mvo had any spare time.
[01:43] <lifeless> cjwatson: I meant, not using debs, not a specific thing :) Unless of course you got that and ran with it :>
[01:43] <cjwatson> So sticking somebody reasonably clued on it for a couple of months ought to be enough to get it thrashed out.
[01:43] <cjwatson> Oh I see.
[01:43] <cjwatson> debdelta will probably be quicker, and will have widespread benefits if we get it done.
[01:44] <wgrant_> cjwatson: canUploadToPocket and checkLegalPocket seem pretty similar to cannotModifySuite
[01:45] <wgrant_> More specifically, they all duplicate the Release-is-immutable-in-stable-series logic.
[01:45] <lifeless> cjwatson: sure. I'm a little worried about failure modes like 'user edited a file'
[01:46] <lifeless> cjwatson: which something a little more dynamic in nature could deal with rather more gracefully than we can today.
[01:47] <cjwatson> wgrant_: Yes, I wasn't sure how far I should go in refactoring that swamp
[01:47] <wgrant_> cjwatson: That's putting it nicely.
[01:48] <cjwatson> wgrant_: But I take it you want to go a bit further?
[01:48] <wgrant_> cjwatson: I'd extend canUploadToPocket to do this. But you don't have to if you don't want.
[01:49] <cjwatson> In particular I wasn't sure whether it would be a good idea to change the behaviour of the publisher to avoid touching anything that canUploadToPocket refuses.
[01:49] <wgrant_> It's less obvious that it's correct for the publisher to do that.
[01:49] <wgrant_> I think it probably is correct for changeOverride to use canUploadToPocket, however.
[01:49] <cjwatson> checkLegalPocket is semantically closer, but has a less near to being helpful interface.
[01:50] <wgrant_> canUploadToPocket's name is just crap
[01:51] <wgrant_> checkLegalPocket is a publisher-specific method which should be somewhere else and implemented in terms of canUploadToPocket
[01:54] <cjwatson> OK.  I'm happy to rearrange it in terms of canUploadToPocket.
[01:55] <wgrant_> But it looks fine apart from that, so if you don't care enough to fix it I will +1
[02:00] <cjwatson> Nah, I'd rather get it as right as possible first time
[02:17] <lifeless> worth a read - http://shirky.com/writings/group_enemy.html
[02:29] <mwhudson> lifeless: the middle section makes me think of time
[02:29] <mwhudson> * daker has quit (Ping timeout: 246 seconds)
[02:29] <mwhudson> oh ffs, twice today!
[02:29] <mwhudson> lifeless: http://xkcd.com/1043/
[02:30] <lifeless> mwhudson: LOL
[02:31] <mwhudson> there is something that's changed in precise (i think inside ff) that really screws up my clipboard experience
[02:31] <lifeless> mwhudson: do you have a three button trackpad ?
[02:31] <lifeless> or hmm, three button nipple ?
[02:32] <lifeless> bigjools: wallyworld_: HUSH.
[02:32] <mwhudson> lifeless: i do, but i use an external keyboard & mouse almost all of the time
[02:32] <lifeless> ok, cause I find the middle button of the three connected to the nipple extremely frustrating to use
[02:32] <wallyworld_> huh? me has said nothing
[02:32] <mwhudson> (i certainly can't blame either of today's stuffups on the thinkpad)
[02:32] <lifeless> wallyworld_: no, but you usually do :P
[02:33] <bigjools> nipple is the correct term
[02:33] <wallyworld_> ah, guilty by assumption :-)
[02:33] <bigjools> just don't flick your tongue over it
[02:33] <wallyworld_> lol, knew i could proxy to bigjools :-)
[02:36] <lifeless> see
[02:37] <lifeless> exactly my point
[02:38] <wgrant> wallyworld_: Are you sure that new query is good?
[02:38] <wgrant> It looks broken to me.
[02:38] <wallyworld_> in what way? the tests pass
[02:38] <wgrant> It seem like it'll find people with *any* team participation that doesn't have permission.
[02:39] <wgrant> Rather than finding people where *all* team participations don't have permission.
[02:39] <mwhudson> lifeless: it's an interesting article, i've read it at least once before but that was before "facebook" and "twitter" were words that appeared on the 6pm news...
[02:39] <wallyworld_> wgrant: let me look
[02:40] <cjwatson> wgrant: Happier with this try?  It's rather more verbose, but gets rid of duplicate logic in several places now.
[02:41] <cjwatson> (E.g. it rephrases checkLegalPocket mostly in terms of canUploadToPocket.)
[02:42] <wallyworld_> wgrant: at first read it looks ok - not(a or b) = not(a) and not(b)
[02:42] <wgrant> wallyworld_: Sure, that bit of the logic is fine.
[02:42] <wgrant> wallyworld_: But you're joining against TP
[02:43] <wgrant> You want to find people where all the teamparticipations match the OTs.
[02:43] <wgrant> s/OTs/NOTs/
[02:43] <wgrant> But that query will find people where any of them do.
[02:44] <wallyworld_> yes, that seem true
[02:44] <wgrant> eg. if foo is a member of bar and baz, and bar has access but baz does not, the query will say foo doesn't have access.
[02:44] <wallyworld_> so i need a extra constraint
[02:47] <wgrant> a GROUP BY with HAVING(COUNT(teamparticipation) = 0) is probably clearest
[02:47] <wgrant> But it's horrid
[02:47] <wgrant> Which is why I suggested inverting the method and doing the difference in Python
[02:47] <wgrant> It's more useful and far simpler.
[02:49] <wallyworld_> but it's python and the results could be large, they may not be, but we can't guarantee that
[02:49] <wgrant> wallyworld_: Not really.
[02:49] <wgrant> We're passing in a set of people
[02:49] <wgrant> The set we get back out will be at most that large.
[02:49] <wgrant> And it's probably only a set of ints.
[02:49] <wallyworld_> ok, i can rework it
[02:50] <wgrant> cjwatson: Looking, sorry
[02:50] <wgrant> wallyworld_: Unless you want to do a set of horrid left joins with group by and having, that's probably best.
[02:50] <wgrant> But you can do it all in SQL if you really wanr.
[02:54] <wgrant> cjwatson: Should cannotModifySuite be replaced too?
[02:54] <wgrant> If you're feeling adventurous, canUploadToPocket would be even better as Archive.canModifySuite
[02:56] <wgrant> cjwatson: But that's an excellent improvement, thanks.
[03:06] <cjwatson> wgrant: cannotModifySuite> Doesn't that go back to the conversation above?
[03:06] <cjwatson> 02:49 <cjwatson> In particular I wasn't sure whether it would be a good idea to change the behaviour of the publisher to avoid touching anything that canUploadToPocket refuses.
[03:06] <cjwatson> 02:49 <wgrant_> It's less obvious that it's correct for the publisher to do that.
[03:07] <cjwatson> I'll look at refactoring it into Archive.canModifySuite tomorrow
[03:09] <wgrant> cjwatson: That's a good point, ignore me.
[03:09]  * wallyworld_ sighs. i may triggered the branch scanning bug again :-(
[03:09] <wgrant> cjwatson: But moving the archive-related stuff onto Archive is a good thing; should have been done during ArchiveRework in 2006 :)
[03:09] <wgrant> So please move that if you have a moment.
[03:10] <wgrant> wallyworld_: Was an MP involved again?
[03:10] <wallyworld_> yep
[03:10] <wgrant> :(
[03:10] <wgrant> Missed the first run
[03:11] <wgrant> Was hoping we could actually see what was going on there.
[03:11] <wgrant> spm: Not at lunch, are you?
[03:11] <spm> am back now, but about to be exclusively doing stuff
[03:11] <wgrant> Ah, k
[03:11] <wgrant> Nevermind, then.
[03:15]  * wallyworld_ taps fingers. branch scanning seems to be taking forever
[03:16] <wgrant> wallyworld_: It just retimed out a few seconds ago
[03:16] <wgrant> Your new push should process in a sec
[03:16] <wallyworld_> hope so
[03:16] <wgrant> It's scanning
[03:18] <wgrant> Done
[03:18] <wallyworld_> branch pages doesn't seem to think so
[03:19] <wallyworld_> ah now it does
[03:20] <wgrant> Hm
[03:20] <wgrant> It's rescanning the original one now, for the third time.
[03:20] <wgrant> Did you repush it?
[03:21] <wallyworld_> nope
[03:21] <wallyworld_> wgrant: if you could peek at this, much appreciated https://code.launchpad.net/~wallyworld/launchpad/create-aag-privacy-transitions-followup2/+merge/110945
[03:25] <wgrant> wallyworld_: Looking
[03:25] <wallyworld_> thanks
[03:26] <wgrant> wallyworld_: r=me, thanks.
[03:26] <wgrant> Although neither the MP nor commit message nor any of the other commit messages actually say what the issue is :)
[03:26] <wallyworld_> wgrant: thanks for spotting the issue
[03:28] <cjwatson> wgrant: All right, since sleep continues to elude, I've done that move now - and landing, since I see you approved it already (thanks)
[03:30] <wgrant> cjwatson: Marvellous.
[03:30] <wgrant> Apart from the not sleeping thing.
[04:56]  * StevenK headdesks.
[04:59] <wgrant> ?
[05:01] <StevenK> wgrant: I ran make schema and was then going to run the garbo tests again and managed to fat finger make clean && make schema somehow.
[05:01] <wgrant> Heh
[05:04] <wgrant> TDD on LP really sucks
[05:04] <wgrant> Just saying
[05:33] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-branch-ap/+merge/110950
[06:22] <lifeless> EWTF 7878.23s  OOPS-ebfdc5eaa4642ee738b09283e0964a82  BranchSet:CollectionResource:#branches
[06:24] <lifeless> wgrant: have you looked into https://oops.canonical.com/?oopsid=OOPS-f08635d8a0548f5b1bafb1bb0209c980#repeatedstatements ?
[06:30] <wgrant> lifeless: Heh
[06:30] <wgrant> I didn't think it would ever get that bad.
[07:26] <czajkowski> morning
[07:50] <adeuring> good morning
[07:57] <lifeless> wgrant: and yet...
[09:09] <stub> Add one query per request, and 5 tests fail. We have some sensitive query counts in there...
[09:16] <stub> Bump 'em by one, and they will be less sensitive when 1 request ends up being removed from every request in a future landing.
[09:26] <cjwatson> Make them equality tests rather than maxima?
[09:26] <jam> dpm, jtv: I'm looking over the Q translations, I'm running into a couple things. The #contributors doesn't match between Q and P, but maybe that is the Garbo job, or maybe just newer stuff?
[09:27] <jam> I'm getting timeouts trying to load the actual page, but it does eventually load.
[09:27] <jam> for example this: https://translations.launchpad.net/ubuntu/precise/+source/gfxboot-theme-ubuntu/+pots/bootloader/es/+translate vs https://translations.launchpad.net/ubuntu/quantal/+source/gfxboot-theme-ubuntu/+pots/bootloader/es/+translate
[09:27] <jam> The checkboxes are also a bit different.
[09:27] <jam> On P it defaults to 'New translation', but on Q it is marked on "Current Spanish".
[09:28] <jam> Though aside from the first, the pages seem identical.
[09:28] <jtv> jam: otp
[09:28] <jam> jtv: np
[09:32] <jam> so aside from the Contributors stuff, all the pages I've looked at for specific translations have been identical between P and Q
[09:33] <jtv> jam: back.  The contributors are updated by the garbo job, right.
[09:34] <jam> jtv: so on this page: https://translations.launchpad.net/ubuntu/quantal it seems to say there are 237045 untranslated strings for Bosnian, but when I go: https://translations.launchpad.net/ubuntu/quantal/+lang/bs it only lists 37371. Maybe I'm not looking at the right page?
[09:35] <jtv> jam: the checkboxes sound strange… it may be an unanticipated side effect of Quantal translations still being closed.  The important thing is that you get identical items between P and Q, both labelled Current Spanish, with the same text.
[09:35] <jtv> The statistics are also updated asynchronously, so don't rely on those.\
[09:35] <jam> jtv: yeah, the checkbox seems to be if Firefox puts the cursor inside the text entry box
[09:35]  * jtv looks at pages
[09:35] <jam> jtv: how asyncrhonously? Given the copy happened last night
[09:35] <jtv> !
[09:36] <jam> jtv: we were able to get the copy to succeed yesterday around 14:00 utc
[09:36] <jtv> Actually I guessed from what you said earlier, but it's nice to have that part be such a non-event.
[09:36] <jtv> How long did it take?
[09:36] <jam> jtv: well, we had some old 'temp_' tables that required st-ub to fix
[09:36] <jtv> Ah yes.
[09:36] <jam> but then the copy happenid in about 5 min
[09:37] <jam> vs the 1.5hrs to get the delete script to run
[09:37] <jtv> There'll be less of that holding-table business.
[09:37] <jam> (about 3 retries)
[09:37] <jtv> Five minutes!  It's hard to express how happy that makes me.
[09:37] <jam> jtv: I don't have the background to fully appreciate it, but yes, very quick vs what it looks like in the past.
[09:37] <jtv> Do note that please on the wiki page.
[09:37] <jam> Already been noted
[09:38] <jam> but it will be highlighted later.
[09:38] <gmb> Arse
[09:38] <jam> I'm personally satisfied enough that the copy completed correctly. As you expected, the statistics are all wrong, but the strings all look correct.
[09:38] <jtv> Well… 2007: take Launchpad offline for the copy.  2008: strain the app to its limits for I don't remember how many days as we copy dozens of millions of rows.
[09:39] <czajkowski> gmb: LOL!
[09:39]  * gmb needs to remember that he sucks at IRC.
[09:39] <czajkowski> meh could in fact be worse
[09:39] <czajkowski> you in the Fin?
[09:39] <gmb> Also, I need to write a bot for taking ReviewerSchedule and updating the topic (because I do this crap on a regular basis)
[09:40] <gmb> czajkowski, Yep. It's massive!
[09:40] <gmb> I feel tiny
[09:40] <jtv> gmb: And a bot that says “good morning, volunteer!” as you log in on your review day.
[09:40] <gmb> Quite
[09:40] <jam> jtv: definitely well done
[09:41] <jtv> jam: those Spanish translations look fine to me.  I won't say there's no problem anywhere, but it passes the basic sanity test that really matters right now.
[09:41] <czajkowski> gmb: aye it is nice alright
[09:41] <jam> jtv: I haven't found a page with translations strings that aren't identical.
[09:41] <jam> Just "Contributors" for a given entry, etc.
[09:41] <jam> and the summary of "Untranslated" doesn't quite match.
[09:42] <jam> but all those are summary statistics stuff.
[09:42] <jtv> The credits should start to fill in, but one of the breakthroughs of this year is that that is now a separate problem.
[09:42] <jam> jtv: so its says the next step is activating the translation imports. Does it seem reasonable to do so?
[09:42] <jtv> The only numbers you can trust, really, are on the batch navigator for a page — e.g. 1234 items in the “translated items” view.
[09:43] <jtv> jam: I would say so, and I'm sure dpm would be much relieved.  Ask him to tell you some stories as well.  :)
[09:44]  * dpm reads scrollback...
[09:44] <jtv> jam: it's useful to note when the imports are started, because that way we can more or less track in the UI whether a full generation of translations has been imported yet.
[09:44] <jtv> Bon dia dpm :)
[09:45] <jtv> jam: and now for a short intermission between self-congratulation sessions… I see Approved items on the import queue for Quantal, but they're not attached to any files to import to.  That looks like an omission in the cleanup script.
[09:45] <jtv> If we enable imports, that will break.
[09:46] <jam> jtv: I don't quite follow your thread, links?
[09:46] <jtv> https://translations.launchpad.net/ubuntu/quantal/+imports
[09:46] <jtv> These are the files awaiting import into Quantal.
[09:46] <jtv> Approval, in translations-import-queue terminology, is a bit of a misnomer.
[09:47] <jtv> It also involves attaching an upload on the queue to a POTemplate or POFile in the database that it's supposed to go into.
[09:47] <jtv> (There must be one; these objects are created as part of the approval process).
[09:47] <jtv> For most files, it's the import queue gardener (rosetta-approve-imports.py) that does this.
[09:48] <jtv> And the importer assumes that any file it's going to import will already have been approved, and so is attached to a POTemplate or POFile.
[09:49] <jtv> So we need something like:
[09:49] <jtv> UPDATE TranslationImportQueueEntry SET status=5 WHERE status=1 AND distroseries = (SELECT id FROM DistroSeries WHERE distribution=1 AND name='quantal');
[09:49] <jtv> Let me just ask about that on -ops.
[09:50] <wgrant> jtv: That's not doable through the API nowadays?
[09:50] <jtv> Hmm… it might be, but I imagine not on a batch basis.
[09:51] <wgrant> Certainly not on a batch basis, no
[09:52] <dpm> jtv, jam, having a quick look at P and Q, the translations look ok, but I'm also concerned about the mismatch in the number of contributors. Apparently we got +100 contributors on Q according to LP, which is certainly not the case
[09:52] <cjwatson> gmb: Oh hello Mr. OCR.  There's a question for you in https://code.launchpad.net/~cjwatson/launchpad/export-change-override/+merge/109549
[09:52] <dpm> sorry, I mean for Catalan
[09:52] <dpm> it might be different for other languages
[09:53] <jam> dpm: most of the ones I've seen have almost 2x the contributors in P than Q
[09:54] <gmb> cjwatson, Looking now.
[09:54] <jam> dpm: I'm seeing P having 145 more contributors, how are you getting 100 more in Q?
[09:54] <jtv> dpm, jam: it'll take garbo some time to derive all that contributor information.  Try looking at templates whose names start with numbers, or 'a'.
[09:55] <jam> jtv: the first one is "Abkhazian" which matches (with 0 contributors), but Acehnese is 55 in P vs 18 in Q
[09:55] <jtv> Template names, not languages.
[09:55] <jam> ah
[09:56] <daker> mwhudson, do you need me ?
[09:56] <jtv> jam: also, if the daily garbo job was interrupted for this…
[09:56] <dpm> jam, sorry, you're right, I was looking it the other way round -> https://translations.launchpad.net/ubuntu/quantal - Catalan: 216 contributors, https://translations.launchpad.net/ubuntu/precise - Catalan: 318 contributors
[09:57] <dpm> so Q is 102 less contributors
[09:57] <jam> dpm: well that number just jumped from 20 min ago
[09:57] <dpm> than P
[09:57] <jam> for Q
[09:57] <jam> It was 155 just a bit ago
[09:57] <jam> jtv: it was interupted before the copy, but should be running today.
[09:57] <jam> dpm: so the number seems to be going in the right direction
[09:57] <dpm> gotcha
[09:58] <jtv> Well, there we go then.  :)
[09:58] <gmb> cjwatson, Okay, it looks like copy_field isn't doing what it should. Revert to your earlier solution and add a comment explaining why you're not using copy_field. r=me on everything else.
[09:58] <jam> jtv: currently OTP, but I want to sort out the import queue things with you in a bit if that's ok. Or are you at EOD
[09:58] <jtv> jam: I'll be here.
[09:59] <cjwatson> gmb: Fair enough, thanks.  (It's blocked on another landing at the moment, but hopefully after that.)
[09:59] <gmb> cjwatson, Okay.
[10:05] <wgrant> jtv, jam Are you aware of the poimport errors?
[10:05] <wgrant> 2012-06-19 09:46:16 ERROR   Entry is approved but has no place to import to. -- 'po/skanlite.pot' (id 6579415) in ubuntu Quantal package skanlite
[10:05] <wgrant> Lots of that
[10:06] <jam> wgrant: I just unchecked the import queue, and we're chatting about it. Still OTP, though.
[10:06] <jtv> That'd be the thing I said would happen.  :)
[11:10] <jam> jtv: back.
[11:10] <jtv> OK
[11:46] <jml> benji: I've annotated the SSL exception in those two branches you reviewed yesterday. I'd welcome a re-review.
[11:48] <benji> jml: sure, I'd be glad to
[11:48] <jml> benji: thanks.
[11:50] <benji> jml: looks great
[11:50] <jml> benji: thanks. Do you know what the landing process is for those two projects?
[11:50] <benji> since the value of "e" is known to be an exception the "% (e,)" bit is superfluous, but it won't hurt anything
[11:51] <jml> benji: a little paranoia is healthy.
[11:51] <benji> Just merge to trunk, update NEWS, and make a release... I think there is a document for that, hold on a sec and I'll find it
[11:51] <jml> benji: you never know when SSLHandshakeError will decide to subclass tuple!
[11:52] <benji> heh
[11:52] <benji> that'll be the day Python jumps the shark
[11:52] <benji> jml: https://dev.launchpad.net/HackingLazrLibraries#landing-your-branches and https://dev.launchpad.net/HackingLazrLibraries#releases look like what you need
[11:54] <jml> versions :(
[11:54] <jml> benji: thanks.
[11:54] <benji> versions.cfg loves you
[11:54] <jml> benji: SSLHandshakeError isn't in the buildout-depended version. Should I try to match httplib2 behaviour in currently depended version or should I bump the version dependency?
[11:55] <benji> you can bump it; versions is for development and if development doesn't match reality it can be changed
[12:00] <jml> benji: I don't have commit access.
[12:00] <benji> jml: I'll land it for you if you want
[12:00] <jml> benji: thanks.
[12:01] <jml>   [r=benji] Add environment variable, LP_DISABLE_SSL_CERTIFICATE_VALIDATION, to
[12:01] <jml>   disable SSL certificate checks.  Most useful when testing against development
[12:01] <jml>   servers.
[12:01] <jml> that's my commit message.
[12:01] <benji> k
[12:01] <jml> benji: no need for the bump, I just hadn't run buildout in a while.
[12:01] <benji> cool
[12:18] <rick_h_> bah, sorry jcsackett wrong channel, reset irssi and my channel numbers get moved on me
[12:44] <maxb> rick_h_: /layout save is your friend :-)
[12:45] <jam> dpm: according to https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings the next steps are up to you. (steps 8+)
[12:45] <maxb> (Remember to also /save afterward)
[12:45] <cjwatson> rick_h_: Thanks for r= on https://code.launchpad.net/~cjwatson/lazr.restfulclient/cgi-parse-qs-deprecated/+merge/111001.  I don't have commit access; could you land it for me
[12:45] <cjwatson> ?
[12:46] <dpm> jam, excellent, thanks for your work in getting the copy done. I can now open the translations and set up language packs before the end of the week.
[12:50] <rick_h_> cjwatson: sorry, my LP env isn't setup yet on the new machine. Can we rope someone else in atm? adeuring can you help land please? ^
[12:51] <adeuring> cjwatson, rick_h_: sure.
[12:51] <rick_h_> ty adeuring
[13:02] <jam> jelmer: did you get a chance to re-submit my MP?
[13:03] <jelmer> jam: ah, sorry, I misunderstood.. thought you were going to get somebody to run the fancy parallel test script for it
[13:03] <jelmer> resubmitting now
[13:03] <jam> jelmer: I was meaning for the sprint week on that.
[13:03] <bac> mrevell: "crave the metal"  -- ha!
[13:04] <mrevell> bac, :)
[13:05] <bac> mrevell: i think the narrator for The Big Lebowski would add a certain western flair that might be appealing.
[13:12] <jml> benji: hi. I don't mean to hassle but I haven't seen my MPs get merged. Anything I can do?
[13:12] <deryck> Morning, all.
[13:12] <benji> jml: I've been on calls.  Working on it now.
[13:13] <jml> benji: np, thanks.
[13:14] <czajkowski> sinzui: morning
[13:14] <sinzui> hello
[13:16] <mrevell> bac, I like that idea :) I wonder what he charges
[13:43] <benji> jml: launchpadlib 1.10.0 released; releasing lazr.restfulclient now
[13:45] <jml> benji: woot, thanks.
[13:51] <benji> jml: ok, lazr.restfulclient 0.13.0 is released
[13:51] <jml> benji: wonderful :)
[13:51] <jml> this will make local testing of API scripts much easier.
[13:52] <benji> yep, it's a good addition
[14:04] <deryck> adeuring, ivory -- https://plus.google.com/hangouts/_/4da3cee079179cf73f401a0a94ca9813bedf7ca8?authuser=0&hl=en
[14:12] <jam> Is someone around that can help me understand: http://people.canonical.com/~wgrant/librarian-pruning.html
[14:12] <jam> It mentions a few SQL statements to run, but then seems to run them under different circumstances.
[14:13] <jam> (the very first query says "All SPRs" vs "Expired SPRs", but I don't see how the query is restricted to only Expired SPRs
[14:30] <jcsackett> rick_h_: ack on the comments, looking through making those changes now.
[14:30] <rick_h_> jcsackett: cool, hopefully removes some more LoC though the attr docs might bring it back, but at least it's not more code
[14:33] <jcsackett> rick_h_: yeah. i usually think SLoC rather than just LoC. whitespace and comments really aren't the problem we're trying to curb.
[14:34] <jcsackett> ...well, the suckless version of SLoC. Significant, not Source.
[14:34] <rick_h_> :)
[14:35] <rick_h_> jcsackett: let me know if I'm wrong on the event stuff. I kind of saw maybe that method of calling was required due to current scope in event passing
[15:50] <cjwatson> jtv: I gather from https://code.launchpad.net/~jtv/launchpad/katie-and-gina-are-bad-bad-girls/+merge/75472 that you have some experience running gina into a scratch table on dogfood.  Do you know if this is documented anywhere?  I have a branch I'd like to land, but I'm not sure how to QA it.
[15:50] <jtv> That's a long time ago.  Let me refresh my memory.
[15:51] <jtv> cjwatson: ah, I see what you mean now.  I just ran it normally, but also selected some data into a scratch table for before/after comparison.
[15:52] <jtv> But I don't really remember any of it.
[15:53] <cjwatson> Ah, OK.  Hmm.
[15:54] <czajkowski> jtv: what time is it over there ?
[15:54] <jtv> Late:54
[15:54] <timrc> has the LP team developed a generic YUI3 Model/ModelList sync layer akin to Backbone.Sync?
[15:54] <cjwatson> $ ls -ld /srv/launchpad.net/gina-mirror/dists/sid/
[15:54] <cjwatson> drwxr-xr-x 5 launchpad launchpad 4096 2010-11-25 01:45 /srv/launchpad.net/gina-mirror/dists/sid/
[15:54] <cjwatson> Eep, that's old.  Probably doesn't have any of the packages I care about in it.
[15:55] <cjwatson> Maybe I could download one of them into the mirror by hand?
[15:56] <cjwatson> Oh, main/source/Sources.gz is 2011-09-12.  Still.
[15:56] <jtv> ISTR this stuff depends heavily on what happens to be in the local archive on dogfood.  Maybe there's ways of injecting individual packages directly… I don't know.
[15:57] <cjwatson> I bet it'll get confused by the database (hence /debian/+source/*) being substantially newer than the mirror.
[15:58] <cjwatson> I do need to do some approximation of a full run.  I have unit tests for my changes to lib/lp/soyuz/scripts/gina/*, but scripts/gina.py doesn't seem to be meaningfully tested.
[16:02]  * deryck goes offline for lunch, back in an hour
[16:03] <jtv> cjwatson: I can only recommend waiting for Australia to wake up…
[16:03] <cjwatson> :-)
[16:04] <czajkowski> it's an odd timezone to wait for, but given the folks there don't sleep it's not too long a wait either
[16:05] <flacoste> gary_poster: you should get your blog on the LP planet, the retrospectives would show up on it
[16:06]  * cjwatson upgrades mawson while he waits, given that when StevenK last tried that it took three hours
[16:07] <czajkowski> flacoste: +1
[16:12] <gary_poster> flacoste, cool will do.  I don't see how to do that on planet.launchpad.net, but looking around more.  If you know (or czajkowski?) hints welcome
[16:12] <flacoste> gary_poster: you might have to ask mrevell, i don't know the specifics tbh
[16:13] <gary_poster> ok cool
[16:13] <mrevell> gary_poster, I can add you to the planet. It's not especially intuitive.
[16:13]  * cjwatson notices there's a doctest for gina.  Phew, that's slightly less bad than it might have been.
[16:14] <mrevell> gary_poster, It's so long since we added one that I can't remember if anyone in the LP team can do it or just a few people.
[16:16] <gary_poster> mrevell, oh cool thanks.  Lemme get you a tagged link...
[16:19] <gary_poster> mrevell, http://codesinger.blogspot.com/feeds/posts/default/-/launchpad or http://codesinger.blogspot.com/feeds/posts/default/-/canonical .  they are the same atm :-)
[16:19] <mrevell> thanks gary_poster.
[16:19] <gary_poster> thank you
[16:20] <czajkowski> gary_poster: see your blogging of team meetings is going to catch on :)
[16:21] <gary_poster> czajkowski, heh, we'll see :-)
[16:21] <jcsackett> rick_h_: took a bit to cycle back, but replies on my MP and code updates.
[16:22] <rick_h_> jcsackett: loading up now
[16:25] <james_w> gmb, rick_h_: does one of you have time for https://code.launchpad.net/~james-w/python-oops/refactor-publishing/+merge/109428 ?
[16:25] <rick_h_> james_w: will look in just a sec
[16:25] <rick_h_> sorry, two snuck into the queue on me while I wasn't looking
[16:25] <james_w> thanks rick_h_
[16:28] <rick_h_> jcsackett: r=me, thanks again for taking the time
[16:33] <jcsackett> rick_h_: thanks for the review and the suggestions. :-)
[16:34] <rick_h_> jcsackett: fav, when you assign me a review make sure to ping me. I didn't notice it until I loaded the list for OCR today. I totally would have missed it otherwise
[16:34] <jcsackett> rick_h_: i didn't ping you b/c i knew you were OCR today, and i put it up last night. :-)
[16:34] <rick_h_> ah, well nvm then. Glad I didn't hold you up too much then
[16:34] <jcsackett> didn't hold me up in the least. thanks again. :-)
[16:49] <rick_h_> james_w: so is there a back story here I assume?
[16:49] <james_w> rick_h_, there is, yes
[16:49] <james_w> I guess I should have updated the description, sorry
[16:50] <james_w> rick_h_, the oops stack has a hack where it decides if a report has already been published by seeing if it has an 'id' key
[16:50] <james_w> but it's valid for an app to allocate an id when it generates an oops, e.g. for django to show the id to the user
[16:50] <rick_h_> ok
[16:50] <james_w> there is a wrapper function in python-oops that publishes to a publisher only if the id isn't set
[16:51] <rick_h_> ok, so this is trying to build that in with the flag
[16:51] <rick_h_> ?
[16:51] <james_w> which you want to use for reliable oops delivery (try and publish to amqp, if that fails drop it in a directory and have something else try again when amqp is back)
[16:51] <james_w> so if the app allocates the id then you never get that fallback, and oopses are lost
[16:52] <james_w> so you remove the wrapper and instead duplicate the work as you will always publish to the dir on disk, even if amqp succeeeded
[16:52] <james_w> talking to Rob about it we decided that whether an oops has been published should be remembered by the config, rather than stored in the oops
[16:52] <rick_h_> ok
[16:52] <james_w> and then publishers would be added to the config declaring if they should only get oopses that are unpublished
[16:53] <james_w> that would be an API break from the current API of appending publishers to a list
[16:53] <rick_h_> james_w: ok, r=me with a couple of nitpicks, one is just something that maybe is me coming unaware to the conversation
[16:53] <james_w> Rob suggested that instead the "publish to a list of publishers" thing be extracted out and taught all of that stuff
[16:53] <james_w> so I did that, and left the old code in for compatibility
[16:54] <rick_h_> ok, kind of see it. Now an oops pro, but nothing here looks like it'll go boom! :)
[16:54] <rick_h_> /now/not
[16:55] <james_w> thanks rick_h_
[16:55] <james_w> rick_h_, good comments, thanks
[16:56] <james_w> I'll fix all of that up
[16:56] <james_w> I'm not sure about deprecation warnings
[16:56] <james_w> I don't know if there is a policy we can follow without thinking
[16:56] <rick_h_> yea, not sure either. I've not really seen us do that, but if we're clearly deprecating things in an API seems like we really want to get the word out
[16:57] <rick_h_> since I know python-oops stuff is used in a few places I believe
[16:57] <rick_h_> sinzui: any feedback on officially deprecating something like this in a library? python-oops
[17:01] <sinzui> rick_h_, I think we want to raise the warning to tell developers we are going to remove the API. We do not know this much since we have do not have a lot of code that is reused. We do rely on the deprecated warning from our libs to tell us to fix code before it breaks
[17:02] <james_w> rick_h_, yeah, a few
[17:02] <james_w> I'm not too keen on warnings immediately when the change is made as that tends to annoy developers
[17:02] <james_w> I'll be trying to shepherd internal users along
[17:02] <james_w> I don't know how many external users we have
[17:02] <rick_h_> sinzui: ok, thanks. So james_w I'd think we'd just use http://docs.python.org/library/warnings.html
[17:02] <rick_h_> james_w: well, it'll take time for them to get the new version I'm sure, so don't think it'll annoy current items right off the bat
[17:04] <james_w> no, but IME, "YOU'RE USING SOMETHING YOU SHOULDN'T BE AND I'VE ONLY JUST TOLD YOU BUT I'M GOING TO ANNOY YOU ABOUT IT UNTIL YOU FIX IT EVEN THOUGH YOU CAN'T WRITE CODE THAT WILL WORK ON BOTH VERSIONS" tends to be what developers see :-)
[17:06] <sinzui> james_w, that other developer can choose to suppress warnings, as we do. We are informed, and we chose to delay the fix.
[17:06] <rick_h_> james_w: yea, but not seeing how we make sure we get back to this and eventually remove deprecated code
[17:06] <james_w> that's true
[17:06] <james_w> rick_h_, I absolutely agree on the XXX
[17:06] <james_w> then someone will clean it up as part of the LoC policy before too long :-)
[17:07] <rick_h_> hah
[17:08]  * sinzui recalls that Lp needs to switch to hashlib to get to python 2.7
[17:08] <rick_h_> james_w: well, personally I'd prefer to see the warning. I ok'd it, and as long as the XXX and bug are there, it's a trail, but not an obvious one for users of the module
[17:09] <james_w> rick_h_, yeah, I'll make the change to emit a deprecation warning too
[17:09] <rick_h_> james_w: thanks, appreciate it
[17:09] <james_w> thanks for the review
[17:11] <gary_poster> To Whom It May Concern: the most recent devel commit from stub might have caused some test failures.  http://ec2-174-129-111-89.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/3/steps/shell_9/logs/summary  I'll investigate more later
[17:12] <cjwatson> sinzui: AFAICS it already has
[17:12] <cjwatson> sinzui: Unless there's stuff in sourcedeps I'm missing
[17:12] <stub> gary_poster: I landed something?
[17:12]  * sinzui looks
[17:13] <gary_poster> stub, http://ec2-174-129-111-89.compute-1.amazonaws.com:8010/changes/7 ?
[17:13] <stub> oh, damn. I lp-landed instead of ec2 land
[17:13] <stub> sorry
[17:13] <sinzui> cjwatson, if so we can delete code from lp_sitecustomize
[17:14] <sinzui> cjwatson, and script_isolation.py
[17:15] <gary_poster> stub, cool, are you reverting or otherwise fixing or should I do it or try to corral someone to do it?
[17:16] <stub> I can revert it unless someone has something ready. Just syncing trunk down.
[17:18] <sinzui> jcsackett, I would like your review of this SQL that clean up historical data. This relates to the branch you reviewed to teach the commercial project job to delete commercial subscriptions for non-proprietary projects: http://pastebin.ubuntu.com/1049490/
[17:19] <cjwatson> sinzui: From a quick glance through, I think ZODB3, windmill, pycrypto, and ipython still have unguarded md5/sha imports
[17:19] <jcsackett> sinzui: ok.
[17:21] <cjwatson> sinzui: I'm not sure why 2.7 is relevant, though; md5 and sha were deprecated in 2.6, and seem to be no less available / no more deprecated in 2.7 than in 2.6
[17:24] <jcsackett> sinzui: r=me, looks good.
[17:38] <stub> What is the magic rollback syntax?
[17:38] <stub> for the commit line?
[17:39]  * stub finds the guide
[17:39] <stub> hmm... doesn't say
[17:51] <sinzui> cjwatson, windmill...We don't use it. I thought all the code was removed. Someone gets to delete it
[17:51] <sinzui> I thought the sha module was removed in 2.7
[17:53] <cjwatson> Nope, still there
[17:53] <rick_h_> yea, have it here
[17:54] <rick_h_> just deprecated still
[17:54] <cjwatson> Gone in 3.0 of course
[18:42] <abentley> stub: [rollback=revno]
[18:55] <abentley> rick_h_: Could you please review https://bugs.launchpad.net/launchpad/+bug/891715 ?
[18:55] <_mup_> Bug #891715: API doesn't recognize standard parent branch URLs <api> <Launchpad itself:Triaged> < https://launchpad.net/bugs/891715 >
[18:57] <abentley> rick_h_: I mean https://code.launchpad.net/~abentley/launchpad/real-branch-name/+merge/111082
[18:59] <rick_h_> abentley: looking
[19:03] <rick_h_> abentley: r=me
[19:03] <abentley> rick_h_: ty
[19:48] <lifeless> gary_poster: what was the lxc workaround?
[20:00] <jcsackett> sinzui: got a few minutes to talk?
[20:00] <sinzui> yes
[20:00] <jcsackett> cool. i'll send a hangout invite momentarily then.
[20:00] <gary_poster> lifeless, change /var/lib/lxc/lptests/rootfs/etc/init/networking.conf to not wait for udev (that is, use "start on (local-filesystems)"); and remove the container's /etc/init/udevtrigger.conf (rm /var/lib/lxc/lptests/rootfs/etc/init/udevtrigger.conf)
[20:01] <lifeless> hah!
[20:01] <lifeless> so some udev concurrency limit ?
[20:02] <jcsackett> sinzui: laptop with webcam won't start google+, so i'm in messenger via the phone app.
[20:03] <gary_poster> lifeless, yeah something like that.  hallyn didn't get deep into it because he didn't want to focus on it if what he gave us was good enough.  I said it seemed good enough to me.  When we switch to Precise, we can remove the hack.
[20:43] <lifeless> bac: hi
[20:44] <lifeless> bac: p:~bac/zope.testing/1012171 - I notice that you've had some trouble with the Content stuff there; what was in the file already appears crufty to me - there are solid helpers in testtools that would make life a lot easier.
[20:44] <lifeless> bac: I've made a couple of notes in the MP, but looking in testtools.content and testtools.content_type may give you even more ideas.
[20:44] <lifeless> bac: there is one specific defect you should fix though, which is that iterating 'asd' vs ['asd'] will be considerably slower, if the length of the string is nontrivial.
[20:49] <benji> lifeless: thanks for pointing out the helper on the MP; bac is away right now but I'm sure he'll implement the suggestion in the comment
[20:50] <lifeless> benji: anytime
[20:50] <benji> the bit about the API really being an iterable of strings reminds me of why I hate strings being iterable in Python
[20:50] <lifeless> indeed
[20:50] <lifeless> I hate that too
[20:50] <lifeless> but breaking that to make the API clearer sucks more :(
[20:51] <lifeless> actually, what I hate is type(char) and type(str) being equivalent, same same though
[20:51] <benji> absolutely; the fault here clearly lies with Guido, circa 1990 :)
[20:52] <benji> I don't mind that so much; it would be possible to make strings not iterable, but instead have, say, a .chars attribute that is, for when you really do want to iterate over the chars
[20:52] <lifeless> cat, skin, # of ways ;)
[20:52] <benji> :)
[20:52] <lifeless> by which I mean that that would work too
[20:54] <czajkowski> poor cat
[20:54] <czajkowski> :)
[21:40] <timrc> has the LP team developed a generic YUI3 Model/ModelList sync layer akin to Backbone.Sync?
[21:41] <timrc> Hm, it would help if I mentioned that I'm specifically referring to a sync layer for Yui.App
[21:45] <bac> lifeless: thanks for the note
[21:45] <lifeless> bac: np
[22:42] <StevenK> Conflict adding file logs.  Moved existing file to logs.moved.
[22:42] <StevenK> Conflict adding file logs.moved.  Moved existing file to logs.moved.moved.
[22:42]  * StevenK facepalms
[22:46] <StevenK> Oh. Sigh. PPAVocabulary has no tests.
[22:47] <StevenK> Looks like none of the Soyuz vocabs do.
[22:54] <sinzui> https://qastaging.launchpad.net/launchpad/trunk/+addrelease
[22:59] <rick_h_> timrc: no, we're not up to 3.5 yet, but the combo loader integration is in beta so I'd love to hopefully get it some point this year
[22:59] <rick_h_> timrc: rockstar over on the U1 team has been doing some work on the YUI3 Y.App stuff so you might ping him, but don't think they're to that point
[23:00] <rick_h_> timrc: if you're interested I can chat about it, I've used the model layer on some outside stuff, but nothing LP specific.
[23:09] <timrc> rick_h_, we are re-implementing some stuff in hexr and are going to use Y.App on the front-end and django-tastypie on the backend... I believe bigkevmcd wants to implement a generic sync layer akin to Backbone.Sync... so I was wondering if anyone in the company has done it yet
[23:09] <timrc> seems like people are building model-specific sync layers
[23:13] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/gina-deb-vendor-debian/+merge/111120 - dogfood gina QA advice wanted
[23:14] <wgrant> cjwatson: "meh"
[23:14] <cjwatson> That good?
[23:14] <wgrant> I'd suggest a combination of not caring and constructing a fake archive that contains the relevant package.
[23:15] <cjwatson> Yeah, I just wasn't sure how that would interact with the existing dogfood.lp.net/debian.
[23:15] <rick_h_> timrc: it seems it'd have to be tied to the api end
[23:15] <cjwatson> Unless you mean import it into an entirely fresh distribution or something.  (Sounds hard.)
[23:15] <rick_h_> since tastie-pie would have requests formulated a certain way, I'm not sure anyone would have anything yet
[23:16] <cjwatson> Kind of a shame gina doesn't seem to have a dry-run mode.  If it did, it'd be sufficient to run it with that and make sure it didn't explode.
[23:16] <cjwatson> Maybe I should add one?
[23:16] <rick_h_> timrc: but yea, I could easily see a Y.Model.sync -> tastiepie module
[23:16] <wgrant> cjwatson: Could just comment out the transaction.commit()s...
[23:16] <wgrant> cjwatson: It's easy enough to import into a new distro, but then you can't use the actual problematic package.
[23:16] <cjwatson> Oh yeah, it's dogfood, I guess that's an option
[23:16] <wgrant> Because DEB_VENDOR will be different
[23:16] <cjwatson> Right
[23:17] <cjwatson> I could go with comment-out-commits as a plan
[23:17] <cjwatson> And just inject the broken qjackctl or something with a spoon
[23:17] <timrc> rick_h_, yeah with specific regards to tastypie, I believe there is a project called backbone-tastypie which overrides the default sync() call to  build models and collections using its JSON format
[23:18] <timrc> the same goes for saving models and collections back to the server
[23:18] <timrc> so something similar for Y.Model.sync as you suggest
[23:18] <rick_h_> timrc: right, so basically in the YUI.model you'd monkey patch the sync method and generate the generic request with the model's ATTRS
[23:19] <rick_h_> timrc: so makes total sense, especially with the current state of the tooling standards, but nothing existing I know of for it as the Y.Model stuff is really knew to us as well as the tastiepie default
[23:20] <rick_h_> timrc: I'd be happy to help/look over anything that comes up, but since LP is so far from tastiepie and 3.5 I don't see us directly using/getting to anything
[23:21] <timrc> rick_h_, awesome, thanks
[23:23] <timrc> wgrant, do the api servers throttle "heavy" users?  I've written a script to generate a graph of teams and their relationships using a sample of users across our organization (in the hopes I can discover as many business-relevant teams as possible and how they're related).  I
[23:23] <timrc> argh
[23:24] <timrc> I've tried to design the script so that it doesn't hit the API if it's already seen a team
[23:29] <lifeless> timrc: we firewall bad users.
[23:29] <lifeless> timrc: we don't current have dynamic throttling.
[23:29] <lifeless> Don't be a bad user :P
[23:30] <timrc> :)
[23:30] <lifeless> timrc: also, you can't see most of the business relevant teams, because they will be private.
[23:30] <timrc> lifeless, I'm super special
[23:30] <timrc> or something
[23:30] <timrc> I have fairly good insight into most of the important PES teams
[23:30] <lifeless> sure, but the organisation is rather larger than PES :P. Just saying ;)
[23:31] <timrc> lifeless, oh well allow me to qualify the organization as "PES" in this case
[23:31] <lifeless> ah, sure ;)
[23:35] <StevenK> wgrant, wallyworld_
[23:35] <StevenK> Bah
[23:35] <StevenK> https://code.launchpad.net/~stevenk/launchpad/archive-empty-description-vocab/+merge/111118
[23:44] <StevenK> wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/archive-empty-description-vocab/+merge/111118
[23:45] <wallyworld_> StevenK: sorry, i will need a bit of time to finish my qa