[00:32] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/bugzilla-greater-than-36/+merge/134825
[00:37] <wgrant> StevenK: Have you tried it locally on old, new, and libav instances?
[00:47] <StevenK> wgrant: I have tried with libav and abisource, but I'm having trouble working out what bugzilla version it is
[00:48]  * StevenK uses the code to tell him
[00:50] <StevenK> Right, abisource is 2.22.7
[00:51] <wgrant> So both old
[00:51] <wgrant> Perhaps try GNOME
[00:51] <StevenK> libav is 3.6.2
[00:51] <StevenK> So not really
[00:52] <wgrant> Hm, wasn't the problem that libav didn't understand the new param?
[00:52] <StevenK> libav tossed an error page with bug_id_type=include, but worked without it or with bugidtype=include
[00:54] <StevenK> wgrant: I can try a gnome watch if you wish
[00:57] <wgrant> StevenK: So the param name changed in 3.6.2, but the compat code was only added later?
[00:58] <StevenK> wgrant: And then removed -- I can't find it in 4.2, but it may have moved
[00:59] <StevenK> https://bugs.launchpad.net/bugs/bugtrackers/auto-launchpad.net
[01:03] <wgrant> StevenK: Anyway, if the param was changed in 3.6.2, you'll want to spell the relation '< 3.6.2' or '>= 3.6.2', not anything about 3.6.1
[01:04] <StevenK> gnome blows up
[01:04] <StevenK> Which is odd
[01:04] <StevenK> Fault: <Fault Client: "Content-Type must be 'text/xml,' 'multipart/*,' 'application/soap+xml,' 'or 'application/dime' instead of 'application/x-www-form-urlencoded'">
[01:05] <wgrant> Are you sure you're using the right bugzilla client?
[01:05] <StevenK> I grabbed a URL from prod
[01:06] <wgrant> Right, but our bugzilla client behaves slightly differently depending on the plugins available on the remote instance
[01:06] <wgrant> It's possible you're creating the wrong one directly.
[01:06] <StevenK> http://bugzilla.gnome.org/show_bug.cgi?id=686321 is the URL I gave
[01:07] <wgrant> Sure
[01:07] <wgrant> But that's not really relevant
[01:07] <wgrant> What's relevant is the externalbugtracker class you're using
[01:07] <StevenK> Hm, indeed. That one is using XMLRPC, and didn't trigger my pdb
[01:08] <StevenK> So now I need a recent bugzilla
[01:11] <bigjools> it's very annoying that people can add new questions on a project after turning off Answers
[01:12] <wgrant> Indeed
[01:14] <StevenK> Which gives a 404 for some reason :-(
[01:18] <StevenK> Bleh, icedtea has the plugin
[01:23] <StevenK> As does libreoffice
[01:23] <StevenK> This is maddening
[01:29] <StevenK> wgrant: So I guess Bugzilla 4.2 and on include the LP plugin -- I seem to recall something like that, anyway. I guess I need to find a 3.8 running somewhere
[01:39] <StevenK> wgrant: Which I can't seem o find.
[01:44] <wgrant> StevenK: there's a genericised version of the LP plugin included as core XML-RPC functionality in 4.something
[01:49] <StevenK> Right
[02:05] <StevenK> wgrant: Which I seem to be hitting everytime I find a 4.2 bugzilla. I can't find a 4.0 or a 3.8 instance, so what do you think?
[02:06] <wgrant> Hmm
[02:42] <StevenK> wgrant: No real thoughts then?
[02:44] <wgrant> StevenK: Well, you could possibly just make it not use XML-RPC even if it's available
[02:44] <wgrant> See if that lets you test the old API on a new instance
[02:45] <StevenK> Hmmm
[02:45] <StevenK> Let me cowboy that in
[02:48] <StevenK> wgrant: Which gives a 404, oddly
[03:17]  * StevenK stabs bugzilla
[03:32] <StevenK> wgrant: So, that doesn't work, since we try and probe the version by using xml.cgi?id=1 which gives a 4040
[03:32] <StevenK> 404, even
[03:35]  * StevenK hacks around that too
[03:36] <StevenK> wgrant: Right, with some gruesome hacks and the change in the MP, updating a bug from libreoffice's 4.2.3 bugzilla works.
[04:41] <StevenK> wgrant: *prod*
[04:41] <wgrant> StevenK: So, it works on an old, a libav, and a new?
[04:43] <StevenK> wgrant: Yup
[04:45] <wgrant> StevenK: Do you have a link to the revision in the 3.6 branch?
[04:45] <StevenK> I do not
[04:45] <StevenK> I'm guessing, based on how libav behaves
[04:46] <wgrant> How'd you determine the change is in 3.6.2, then?
[04:46] <StevenK> I can't find any bugzilla 3.6.1 instance, so I'm still guessing
[04:46] <wgrant> Ah
[04:47] <wgrant> So you'll need to check that
[04:48] <StevenK> wgrant: http://bzr.mozilla.org/bugzilla/3.6/revision/6940
[04:51] <wgrant> StevenK: That's before 3.6.0.
[04:51] <wgrant> So >= 3.6.0, I suppose
[04:51] <StevenK> Just before 3.53.
[04:51] <StevenK> 3.5.3 even
[04:51] <wgrant> But it's in the 3.6 branch
[04:52] <wgrant> The change referencing 3.5.3 could just be a merge, perhaps
[04:52] <StevenK> 6950 	
[04:52] <StevenK> 	
[04:52] <StevenK> Convert .cvsignore files into a .bzrignore.
[04:52] <StevenK> 	Max Kanat-Alexander 	bugzilla-3.5.3 	2010-02-01 	Diff 	Files
[04:52] <StevenK> It's tagged as 3.5.3, at least
[04:52] <wgrant> Hm
[04:52] <wgrant> Anyway, just say 3.6.0 for now, I think
[04:53] <StevenK> wgrant: http://pastebin.ubuntu.com/1369400/
[04:53] <wgrant> StevenK: Right, that seems less arbitrary
[04:58] <StevenK> wgrant: The MP has updated
[05:05] <StevenK> wgrant: Can haz approval?
[05:06] <wgrant> StevenK: Done
[07:05] <StevenK> wgrant: You lose at Buildbot bingo -- xx-person-packages.txt
[07:07] <StevenK> Due to sampledata, I bet
[07:07] <StevenK> Since wallyworld___ didn't run the garbo job against it
[07:07] <wgrant> Except there was data there
[07:08] <StevenK> I
[07:08] <wgrant> And the code was already removed initially, as you might recall
[07:08] <StevenK> Bleh
[07:08] <StevenK> I'm guessing, based on the failure
[07:10] <wgrant>     >>> removeSecurityProxy(source1_mark).archive = (
[07:10] <wgrant>     ...     mark_private_ppa)
[07:10] <wgrant> That might do it
[07:11] <StevenK> Haha
[07:21] <StevenK> wgrant: Have you got a testfix yet?
[07:21] <wgrant> Not yet
[07:21] <wgrant> Considering rewriting the test
[07:21] <StevenK> Haha
[07:22] <StevenK> That good, is it?
[07:23] <wgrant> It moves publications multiple times :(
[07:24] <StevenK> Right, so it's a stupid test.
[07:25] <StevenK> I love how the Soyuz doctests have a flagrant disregard towards consistent archives
[07:26] <bigjools> StevenK: must.get.test.passing.at.all.costs
[07:27] <StevenK> Without using anything but sampledata, yeah.
[07:27] <StevenK> If I could, I'd delete cprov from the sampledata just to see what blows up.
[07:27] <wgrant> Oh
[07:27] <wgrant> wallyworld___ actually fixed this test to regen the table
[07:27] <wgrant> After it molests SPPH
[07:28] <StevenK> Did you remove that bit?
[07:28] <wgrant> No
[07:28] <wgrant> I think I just need to also clear out garbojobstate
[07:28]  * wgrant tries
[07:31] <wgrant> yeah
[07:33] <wgrant> wallyworld___: Do you have some unpushed changes to the dbpatches branch?
[07:33] <wgrant> I don't see your LPSPRC numbers there
[08:16] <stub> wgrant: There is more package cleanup happening this week?
[08:42] <adeuring> good morning
[09:07] <wgrant> stub: We did it a few hours ago
[09:25] <wgrant> stub: https://code.launchpad.net/~wgrant/launchpad/lpsprc-index-harder/+merge/134848
[09:28]  * stub wonders if postgresql enums are improved enough to be useful
[09:30] <stub> wgrant: That patch is fine. Should I be applying it anywhere?
[09:30] <wgrant> stub: Everywhere would be lovely
[09:30] <wgrant> An enum wouldn't exactly help here
[09:30] <wgrant> Since we still need it ordered
[09:30] <wgrant> Even if it could use the index for !=
[09:31] <stub> wgrant: To replace hard coded constants like '2'
[09:32] <stub> Not just indexes, but all the raw SQL.
[09:32] <wgrant> Ah, I thought you meant in terms of being able to answer != from indices
[09:33] <wallyworld___> wgrant: i have no unpushed changes
[09:33] <wallyworld___> what is missing?
[09:35] <wgrant> wallyworld___: The description for 38-0 (the creation of LPSPRC) is wrong, and 38-1 (LPSPRC person FKs) and 38-2 (LPSPRC indices) aren't there at all
[09:35] <wallyworld___> hmmm. 38-1 and 38-2 were pushed to devel
[09:35] <wallyworld___> from memory
[09:36] <wgrant> Yeah, but they're not in allocated.txt
[09:36] <wgrant> The patches exist, but the numbers aren't registered as being in use
[09:36] <wallyworld___> ah, yes. i only reserved the first 38-0
[09:36] <wallyworld___> i can fix if you like
[09:37] <wgrant> That would be great, if you haven't thrown away all your LP-related branches yet :)
[09:37] <wgrant> Otherwise I can
[09:37] <wallyworld___> no, tomorrow :-P
[09:37] <wallyworld___> i'll do it in a bit after my standup
[09:37] <wallyworld___> which is now at 8pm
[09:37] <wallyworld___> stupid timezones
[09:38] <wgrant> Ew :/
[09:38] <wgrant> Reminds me of the good old Soyuz days
[09:39] <czajkowski> there were ever good Soyuz days ?
[09:39] <bigjools> yes
[09:40] <stub> wgrant: we can do prod after the backups
[09:41] <wgrant> stub: Indeed, thanks
[09:41] <wgrant> Still
[09:41] <wgrant> They should be done in 5-10 mins
[09:41] <wgrant> unless something's gone wrong
[09:50] <wallyworld___> wgrant: dbpatches changes pushed
[09:55] <wgrant> wallyworld___: Thanks!
[09:55] <wallyworld___> np. sorry about the omission. i totally forgot
[10:00] <smartboyhw> Hi guys. When I go to the new CoC page in qastaging to see the new CoC 2.0, I saw that the release date is not changed. Is it because it is still not released officially?
[10:27] <smartboyhw> Or is that a bug actually?
[10:32] <czajkowski> still not officaly released
[10:33] <smartboyhw> czajkowski, ah OK. When is it going to be officially released then?
[10:34] <czajkowski> smartboyhw: soon no eta on it
[10:35] <czajkowski> we're waiting on a few things to align
[10:35] <czajkowski> you;ll know as there will be an annoucement on the planet ubuntu about it
[10:36] <StevenK> czajkowski: Does that mean that only 1.1 is still on prod?
[10:36] <czajkowski> StevenK:  Not  sure rick_h is looking after this bug atm
[10:36] <czajkowski> we've a bug tracking it
[10:37] <StevenK> Should it get handed over, since they're not on maint?
[10:38] <czajkowski> StevenK: he as handling the merge to ticks
[10:38] <czajkowski> let me find the bug
[10:39] <czajkowski> StevenK: https://bugs.launchpad.net/launchpad/+bug/1079654
[10:39] <_mup_> Bug #1079654: CoC isn't version 2.0  <codeofconduct> <qa-ok> <Launchpad itself:Fix Committed by rharding> < https://launchpad.net/bugs/1079654 >
[10:41] <StevenK> Ah, it hasn't been deployed yet
[10:43] <czajkowski> narp
[10:43] <czajkowski> and we've a few other bits to do also elsewhere
[10:43] <czajkowski> must go poke website editors also
[10:44] <StevenK> So we can't deploy it until those bits are done?
[10:49] <czajkowski> StevenK: sent to pm
[11:53] <rick_h> czajkowski: so the bug is qa'd and not looked yet if a NDT has been run. catching up this morning still
[11:53] <czajkowski> nods
[11:53] <czajkowski> well we're good to go on our end re other bits falling into place
[11:54] <rick_h> czajkowski: we've got a bunch of QA to do this morning. I'll try to get a deploy after our stand up in 3hrs
[11:54] <rick_h> czajkowski: so will try to get it deployed today on this side of the pond
[11:54] <czajkowski> lovely thanks
[14:08] <jtv> My attempt at merge proposal is oopsing... but it works for another branch!
[14:08] <jtv> Unfortunately the oops listing seems to be oopsing as well.
[14:13] <sinzui> jtv, ask a webops to unscan your branch. He will need the lp:... name
[14:14] <jtv> Unscan?  Didn't know you could do that.  Thanks.
[16:16] <rick_h> abentley: is there a trick to make the test runner not use a subprocess? I want to pdb and can't in a subprocess test
[16:17] <abentley> rick_h: If you run a single layer, it shouldn't run a subprocess.
[16:17] <abentley> rick_h: It uses subprocesses if the layer can't be torn down and there are other layers to do.
[16:32] <rick_h> abentley: ah thanks.
[16:32] <rick_h> yea, using --layer helps me get my pdb back yay
[16:32] <abentley> rick_h: Good.
[17:34] <czajkowski> sinzui: you about?
[17:34] <sinzui> yes
[17:34] <czajkowski> sinzui: ello, is this something you cna help with, https://answers.launchpad.net/launchpad/+question/214619
[17:35] <czajkowski> we can askk web ops to change the owner, but the bit allenap has saida needs run is that something you can do?
[17:35] <sinzui> only if we own then and nothing ever merged them
[17:35] <sinzui> the user who merged the branches need to delete their branched
[17:36] <czajkowski> :s
[17:36] <sinzui> We can mark the branches as obsolete to hide them from most searched
[17:36] <czajkowski> ah
[17:41] <sinzui> czajkowski, we could also also change the owner so that they can restore the branch is they need to
[17:42] <czajkowski> sinzui: that nmight be the easiest in the long run
[19:07] <abentley> rick_h: There's no OCR.  Could you please review https://code.launchpad.net/~abentley/launchpad/transitive-confidential/+merge/134995 ?
[19:09] <rick_h> abentley: sure
[19:10] <abentley> rick_h: Thanks.
[19:15] <rick_h> abentley: r=me
[19:15] <abentley> rick_h: Thanks.
[19:16] <rick_h> abentley: side question though on that. I'm trying to think of other things that might need to be checked
[19:16] <rick_h> would milestones/series go into that as well?
[19:17] <rick_h> e.g. "You've got a milestone out there, can't change the project"?
[19:17] <abentley> rick_h: No, because the milestone and series information types are controlled by the product information type.
[19:17] <rick_h> ok
[19:17] <abentley> I'm certainly open to adding more checks as needed.
[19:42] <czajkowski> rick_h: did you approv of this weeks desktop :)
[19:51] <abentley> sinzui: Are you familiar with the query used by _getProjectsWithTheMostKarma and if so, would it be simpler to phrase it as http://pastebin.ubuntu.com/1370868/ ?
[19:53] <sinzui> abentley, I think your query is sane, but I need to see the old query to remember it
[19:53]  * sinzui looks
[19:56] <sinzui> abentley, I like your change. I think the test for it in test_person will pass
[19:56] <abentley> sinzui: Thanks.
[20:16] <rick_h> czajkowski: I did notice it