[00:32] wgrant: https://code.launchpad.net/~stevenk/launchpad/bugzilla-greater-than-36/+merge/134825 [00:37] StevenK: Have you tried it locally on old, new, and libav instances? [00:47] 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] Right, abisource is 2.22.7 [00:51] So both old [00:51] Perhaps try GNOME [00:51] libav is 3.6.2 [00:51] So not really [00:52] Hm, wasn't the problem that libav didn't understand the new param? [00:52] libav tossed an error page with bug_id_type=include, but worked without it or with bugidtype=include [00:54] wgrant: I can try a gnome watch if you wish [00:57] StevenK: So the param name changed in 3.6.2, but the compat code was only added later? [00:58] wgrant: And then removed -- I can't find it in 4.2, but it may have moved [00:59] https://bugs.launchpad.net/bugs/bugtrackers/auto-launchpad.net [01:03] 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] gnome blows up [01:04] Which is odd [01:04] Fault: [01:05] Are you sure you're using the right bugzilla client? [01:05] I grabbed a URL from prod [01:06] Right, but our bugzilla client behaves slightly differently depending on the plugins available on the remote instance [01:06] It's possible you're creating the wrong one directly. [01:06] http://bugzilla.gnome.org/show_bug.cgi?id=686321 is the URL I gave [01:07] Sure [01:07] But that's not really relevant [01:07] What's relevant is the externalbugtracker class you're using [01:07] Hm, indeed. That one is using XMLRPC, and didn't trigger my pdb [01:08] So now I need a recent bugzilla [01:11] it's very annoying that people can add new questions on a project after turning off Answers [01:12] Indeed [01:14] Which gives a 404 for some reason :-( [01:18] Bleh, icedtea has the plugin [01:23] As does libreoffice [01:23] This is maddening [01:29] 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] wgrant: Which I can't seem o find. [01:44] StevenK: there's a genericised version of the LP plugin included as core XML-RPC functionality in 4.something [01:49] Right [02:05] 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] Hmm [02:42] wgrant: No real thoughts then? === jamesh_ is now known as jamesh [02:44] StevenK: Well, you could possibly just make it not use XML-RPC even if it's available [02:44] See if that lets you test the old API on a new instance [02:45] Hmmm [02:45] Let me cowboy that in [02:48] wgrant: Which gives a 404, oddly [03:17] * StevenK stabs bugzilla [03:32] 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] 404, even [03:35] * StevenK hacks around that too [03:36] 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] wgrant: *prod* [04:41] StevenK: So, it works on an old, a libav, and a new? [04:43] wgrant: Yup [04:45] StevenK: Do you have a link to the revision in the 3.6 branch? [04:45] I do not [04:45] I'm guessing, based on how libav behaves [04:46] How'd you determine the change is in 3.6.2, then? [04:46] I can't find any bugzilla 3.6.1 instance, so I'm still guessing [04:46] Ah [04:47] So you'll need to check that [04:48] wgrant: http://bzr.mozilla.org/bugzilla/3.6/revision/6940 [04:51] StevenK: That's before 3.6.0. [04:51] So >= 3.6.0, I suppose [04:51] Just before 3.53. [04:51] 3.5.3 even [04:51] But it's in the 3.6 branch [04:52] The change referencing 3.5.3 could just be a merge, perhaps [04:52] 6950 [04:52] [04:52] Convert .cvsignore files into a .bzrignore. [04:52] Max Kanat-Alexander bugzilla-3.5.3 2010-02-01 Diff Files [04:52] It's tagged as 3.5.3, at least [04:52] Hm [04:52] Anyway, just say 3.6.0 for now, I think [04:53] wgrant: http://pastebin.ubuntu.com/1369400/ [04:53] StevenK: Right, that seems less arbitrary [04:58] wgrant: The MP has updated [05:05] wgrant: Can haz approval? [05:06] StevenK: Done [07:05] wgrant: You lose at Buildbot bingo -- xx-person-packages.txt [07:07] Due to sampledata, I bet [07:07] Since wallyworld___ didn't run the garbo job against it [07:07] Except there was data there [07:08] I [07:08] And the code was already removed initially, as you might recall [07:08] Bleh [07:08] I'm guessing, based on the failure [07:10] >>> removeSecurityProxy(source1_mark).archive = ( [07:10] ... mark_private_ppa) [07:10] That might do it [07:11] Haha [07:21] wgrant: Have you got a testfix yet? [07:21] Not yet [07:21] Considering rewriting the test [07:21] Haha [07:22] That good, is it? [07:23] It moves publications multiple times :( [07:24] Right, so it's a stupid test. [07:25] I love how the Soyuz doctests have a flagrant disregard towards consistent archives [07:26] StevenK: must.get.test.passing.at.all.costs [07:27] Without using anything but sampledata, yeah. [07:27] If I could, I'd delete cprov from the sampledata just to see what blows up. [07:27] Oh [07:27] wallyworld___ actually fixed this test to regen the table [07:27] After it molests SPPH [07:28] Did you remove that bit? [07:28] No [07:28] I think I just need to also clear out garbojobstate [07:28] * wgrant tries [07:31] yeah [07:33] wallyworld___: Do you have some unpushed changes to the dbpatches branch? [07:33] I don't see your LPSPRC numbers there [08:16] wgrant: There is more package cleanup happening this week? [08:42] good morning === jam1 is now known as jam [09:07] stub: We did it a few hours ago [09:25] 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] wgrant: That patch is fine. Should I be applying it anywhere? [09:30] stub: Everywhere would be lovely [09:30] An enum wouldn't exactly help here [09:30] Since we still need it ordered [09:30] Even if it could use the index for != [09:31] wgrant: To replace hard coded constants like '2' [09:32] Not just indexes, but all the raw SQL. [09:32] Ah, I thought you meant in terms of being able to answer != from indices [09:33] wgrant: i have no unpushed changes [09:33] what is missing? [09:35] 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] hmmm. 38-1 and 38-2 were pushed to devel [09:35] from memory [09:36] Yeah, but they're not in allocated.txt [09:36] The patches exist, but the numbers aren't registered as being in use [09:36] ah, yes. i only reserved the first 38-0 [09:36] i can fix if you like [09:37] That would be great, if you haven't thrown away all your LP-related branches yet :) [09:37] Otherwise I can [09:37] no, tomorrow :-P [09:37] i'll do it in a bit after my standup [09:37] which is now at 8pm [09:37] stupid timezones [09:38] Ew :/ [09:38] Reminds me of the good old Soyuz days [09:39] there were ever good Soyuz days ? [09:39] yes [09:40] wgrant: we can do prod after the backups [09:41] stub: Indeed, thanks [09:41] Still [09:41] They should be done in 5-10 mins [09:41] unless something's gone wrong [09:50] wgrant: dbpatches changes pushed [09:55] wallyworld___: Thanks! [09:55] np. sorry about the omission. i totally forgot [10:00] 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] Or is that a bug actually? [10:32] still not officaly released [10:33] czajkowski, ah OK. When is it going to be officially released then? [10:34] smartboyhw: soon no eta on it [10:35] we're waiting on a few things to align [10:35] you;ll know as there will be an annoucement on the planet ubuntu about it [10:36] czajkowski: Does that mean that only 1.1 is still on prod? [10:36] StevenK: Not sure rick_h is looking after this bug atm [10:36] we've a bug tracking it [10:37] Should it get handed over, since they're not on maint? [10:38] StevenK: he as handling the merge to ticks [10:38] let me find the bug [10:39] StevenK: https://bugs.launchpad.net/launchpad/+bug/1079654 [10:39] <_mup_> Bug #1079654: CoC isn't version 2.0

< https://launchpad.net/bugs/1079654 > [10:41] Ah, it hasn't been deployed yet [10:43] narp [10:43] and we've a few other bits to do also elsewhere [10:43] must go poke website editors also [10:44] So we can't deploy it until those bits are done? [10:49] StevenK: sent to pm [11:53] czajkowski: so the bug is qa'd and not looked yet if a NDT has been run. catching up this morning still [11:53] nods [11:53] well we're good to go on our end re other bits falling into place [11:54] 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] czajkowski: so will try to get it deployed today on this side of the pond [11:54] lovely thanks === gary_poster|away is now known as gary_poster [14:08] My attempt at merge proposal is oopsing... but it works for another branch! [14:08] Unfortunately the oops listing seems to be oopsing as well. [14:13] jtv, ask a webops to unscan your branch. He will need the lp:... name [14:14] Unscan? Didn't know you could do that. Thanks. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara is now known as matsubara-lunch [16:16] 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] rick_h: If you run a single layer, it shouldn't run a subprocess. [16:17] rick_h: It uses subprocesses if the layer can't be torn down and there are other layers to do. [16:32] abentley: ah thanks. [16:32] yea, using --layer helps me get my pdb back yay [16:32] rick_h: Good. === matsubara-lunch is now known as matsubara [17:34] sinzui: you about? [17:34] yes [17:34] sinzui: ello, is this something you cna help with, https://answers.launchpad.net/launchpad/+question/214619 [17:35] 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] only if we own then and nothing ever merged them [17:35] the user who merged the branches need to delete their branched [17:36] :s [17:36] We can mark the branches as obsolete to hide them from most searched [17:36] ah [17:41] czajkowski, we could also also change the owner so that they can restore the branch is they need to [17:42] sinzui: that nmight be the easiest in the long run === yofel_ is now known as yofel === matsubara is now known as matsubara-brb [19:07] rick_h: There's no OCR. Could you please review https://code.launchpad.net/~abentley/launchpad/transitive-confidential/+merge/134995 ? === almaisan-away is now known as al-maisan [19:09] abentley: sure [19:10] rick_h: Thanks. === al-maisan is now known as almaisan-away [19:15] abentley: r=me [19:15] rick_h: Thanks. [19:16] abentley: side question though on that. I'm trying to think of other things that might need to be checked [19:16] would milestones/series go into that as well? [19:17] e.g. "You've got a milestone out there, can't change the project"? [19:17] rick_h: No, because the milestone and series information types are controlled by the product information type. [19:17] ok [19:17] I'm certainly open to adding more checks as needed. === matsubara-brb is now known as matsubara [19:42] rick_h: did you approv of this weeks desktop :) [19:51] 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] abentley, I think your query is sane, but I need to see the old query to remember it [19:53] * sinzui looks [19:56] abentley, I like your change. I think the test for it in test_person will pass [19:56] sinzui: Thanks. [20:16] czajkowski: I did notice it === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away