[00:37] wgrant: why did you remove the check for the bug created response at line 120? [00:38] wallyworld_: That was previously the only success verification [00:39] wallyworld_: Since it used /bugs to obtain the ID. [00:39] But now I check the body of the response, so the status code check isn't too important. [00:39] ok, thanks [00:44] wallyworld_: Thanks [00:44] np === jtv1 is now known as jtv [03:05] lifeless: the new celery jobs infrastructure - if i were to write a new celery job, would there be any need to provide a db table? i would think not, since the celery/rabbit stuff would provide the necessary guaranteed delivery/execution? [03:16] wallyworld_: that aspect is unchanged to date. [03:17] wallyworld_: we don't run rabbit in HA mode, its only good for things we're willing to drop on the floor in times of failure. [03:17] lifeless: ok, so i need to create the db table etc [03:17] yes [03:18] just wanted to check, thanks. i figure new stuff should be done using celery [03:18] it should [03:19] thanks [03:30] whats the bug # for 'apport bugs generate multiple notifications' [03:31] 424849? [03:32] bah. that one's fixed. [03:47] possible 667604 [03:51] hah 274537 should be dead easy [03:52] wgrant: I have a suspicion you fixed 626542 ? [04:03] * wallyworld_ off to see doctor. bbiab [04:10] lifeless: Not sure. All of that stuff sort of blurs together. [04:15] wgrant: any idea on the bug # I'm looking for ? [04:15] before I wont-fix all of LP ? [04:19] lifeless: That sounds a little drastic? [04:20] "BAH, I can't find the dinner plate I want, so I'm going to burn the house down." [04:20] lifeless: 667604 is the only one I know about [04:21] But that's about new bugs. [04:22] Bug 424849 [04:22] <_mup_> Bug #424849: Launchpad should batch attachment notification emails

< https://launchpad.net/bugs/424849 > [04:24] Ah [04:24] The end of that bug reveals all [04:24] Bug #768997 [04:24] <_mup_> Bug #768997: Batch multiple comments from the same person/same bug < https://launchpad.net/bugs/768997 > [04:24] lifeless: It's a dupe of that [04:27] wgrant: good call, I went past that and ignored it. [04:28] now, where is the damn one about mailing list subscriptions -> user terrible confusion [04:28] (that https://bugs.launchpad.net/launchpad/+bug/816373 is a dupe of) [04:28] <_mup_> Bug #816373: Launchpad sends duplicate bug change notifications < https://launchpad.net/bugs/816373 > [04:28] Bah, bug change [04:31] wgrant: fwiw I'm seeing nearly 3 second bug searches on LP [04:32] 423ms [04:32] SQL-main-slave: SELECT COUNT(*) [04:32] 681ms [04:32] SQL-main-slave: SELECT BugTaskFlat.bugtask [04:32] so, most of it elsewhere [04:35] Yeah, they're rarely below 2s now. [04:35] Partly because of slow COUNT(*)s, but it's mostly out of the DB Now [04:39] Yay, only major bugtaskflat timeouts were already a problem. Tag union searches, +subscribedbugs, +commentedbugs. But some obscure sort orders have regressed... I think most of them would be OK if we didn't have stupid COUNT(*). [04:39] But it seems I can sensibly denorm a few more cols onto BugTaskFlat to sort out sorts. [04:52] AssertionError: Name "+secrecy" is not registered as a view or navigation step for "Bug" on "bugs". [04:52] LIES! [04:54] Oh, it's on the bugtask [04:54] *stab* [05:16] Goddammit [05:16] I hate partner [05:18] Everyone does. [05:18] Not as much as me. [05:18] True. [05:19] You hate having a partner? [05:19] (j/k I know what he means) [05:20] nigelb: I love having a partner. I can't speak for wgrant. :-P [05:20] StevenK: Haha :) [05:20] Hah [05:20] Maybe nobody cares about searching for partner bugs :) [05:22] I'm very tempted to start launchpadmemes.tumblr.com in the footsteps of mozillamemes and webkitmemes [05:22] Though, I suspect all it will have are rage faces ;-) [05:23] I think it could be pretty well summed up by the original rageface :) [05:23] heh [05:24] For April fools, lp should at some point show rage face icon for ~launchpad-dev [05:24] you could have a yellow rubber duck, and a cowboy hat [05:24] webops have the monopoly on amusing icons [05:24] s/amusing/accurate/ [05:24] True [05:24] heh [05:24] canonical-sysadmin has a pigeon icon [05:24] so we bribe spm? Or is he LOSA and not webops [05:25] nigelb: s/losa/webops/ basically [05:25] just a rename a while ago [05:25] Back in my day, canonical-sysadmins had the default icon! [05:25] Ah [05:25] losa was getting a trifle overloaded. [05:25] But indeed, it is a pigeon now. Odd [05:25] Aw [05:25] Launchpad/Landscape/ISDU1/CA/EA OSA? :) [05:25] heh [05:25] launchpad, landscape, ubuntu one, consumer apps, isd etc operational systems admin [05:25] admin ALL THE THINGS [05:26] wgrant: right [05:26] pes, engineering [05:26] pretty much A-Z OSAs [05:26] oh god. I forgot about them [05:26] Oh right, PES now too [05:26] Must need to take on some more of CS soon [05:26] See, there's enough material in here to make a meme site. [05:27] Hah, the pigeon reminds of @feral_pigeon [05:27] webops is better than losa too. WeBops and use a Cyndi Lauper song as our theme; or Wh00psies! etc [05:28] "We didn't start the fire" is a better theme song for ops teams ;-) [05:28] nigelb: expect when we did [05:28] except* [05:28] A theme song doesn't have to be truthful :) [05:29] a good mate has a long running joke: he fixes everything with fire. as one of the UQ Datacentres had a fire in it - on his watch (he was networks dude at the time). [05:29] I'd prefer "Burning Down The House" myself, anyway. [05:32] heh [05:47] spm: We Are The Cham^WWebops? [05:48] bigjools: more like We're Too Sexy for LP Developers, too sexy by faaaarrr [05:49] spm: now you're doing Mission Impossible [05:49] heh [05:53] haha, well played bigjools. [05:53] * nigelb slow claps [06:01] wallyworld_: Are you back? [06:12] spm: we're too sexy for bops ? [06:14] I think my brain just abort retry ignored? [06:20] StevenK: yes [06:21] ah a review [06:29] StevenK: TestBugTaskInterestingActivity - that test looks a little out of place. where are the other similar tests for the bug activity stuff on _index? a doc test? [06:35] wallyworld_: Yes, a doctest. And I didn't really want to add to it. [06:36] StevenK: is it worth porting the doc test to a unit test? as it stands now, there's a bit here and a bit there if you know what i mean [06:37] the BugVisibilityChange class - that is only relevant if the show info type in ui feature flag is off right, and when turn on the ff for all, we delete that class? === jtv1 is now known as jtv [06:41] wallyworld_: BugVisibilityChange and BugSecurityChange and related gubbins will all die when we drop the UI feature flag and switch to information_type fully. [06:41] cool, just wanted to check - should we put in a XXX so we can keep track? [06:41] I can mark the two classes as such, if you wish. [06:41] with bug-change.txt - i'm all for ripping it out so long as there's coverage elsewhere [06:42] wallyworld_: I'd love your opinion on that -- compare bug-change.txt to test_bugchange.py [06:42] ok, let me look [06:42] StevenK: perhpas if we raise a bug for the work to rip out the legacy stuff when the ff is on that would be good and we could put the relavant XXXs in as we find them [06:43] StevenK: ffs, there's also test_bugchanges - note the extra 's' [06:44] Haha [06:44] wallyworld_: To be fair then, I'd be putting in XXXs all over the place. [06:45] ok, lets' leave it then. so long as we make sure we eventually deleting everything required [06:45] wallyworld_: I like the idea of XXXs for BugVisibilityChange and BugSecurityChange -- pretty much everything else will fall out due to tests failing. [06:45] right. my fear was that those classes would hang around, not be used, and we'd forget them [06:46] wallyworld_: test_buchange.py doesn't exist, it's only test_bugchanges, sorry [06:47] StevenK: lib/lp/bugs/adaptors/test/test_bugchange [06:50] StevenK: so, about the fact that this branch introduces a new unit test but everything else is in a doc test (bug activity stuff). my personal preference is to be consistent otherwise it's too hard to keep track of what's where. so add the new test as a doc test or port the doc test to unit tests. do you share that view? [07:03] StevenK: with bug-change.txt vs test_bugchanges.py: they are similar for sure but bug-change.txt mainly exercises the addChange() API which is a lower level one and is invoked indirectly in test_bugchanges when those tests are run. so if addChange() is broken, so too will be test_bugchanges bug there is an argument that all the current tests are required since strictly speaking they do test sifferent aspects [07:04] wallyworld_: Right. [07:04] wallyworld_: If you have time once you're done with StevenK, could you please look over https://code.launchpad.net/~wgrant/launchpad/bug-899776/+merge/103806? [07:04] sure [07:04] wallyworld_: I can move that one unit test into xx-bug-activity.txt if you wish [07:04] StevenK: it would be great if you could because then everything is together [07:05] StevenK: and the test_bugchange, test_bug_changes, bug-change.txt can stay as is for nowe [07:07] wallyworld_: Aye [07:13] StevenK: r=me but with an additional comment about the bug-change.txt deletions [07:13] wallyworld_: I just remember the other reason I didn't want to use xx-bug-activity.txt [07:13] Ran 1 tests with 1 failures and 0 errors in 24.564 seconds. [07:13] it failed as is ot with your additions? [07:14] wallyworld_: No, look at the time! [07:14] yeah, slow [07:14] so are manu unit tests due to setup of db [07:14] wallyworld_: I'll revert the drops in bug-change.txt with a little sadness. [07:14] StevenK: i share the sadness but we would be removing test coverage [07:15] you will need to wrap with a ff check as well [07:15] I will? It won't be set, they'll be fine unchanged. [07:17] StevenK: ah yes sorry. the classes are constructed directly [07:27] wallyworld_: Thanks. There are some other existing tests, but they're mostly at the browser layer because apparently people hate doing things properly. [07:27] wgrant: np. my main worry was that we have the test coverage to ensure any regression is caught [07:27] Yeah [07:27] seems like we do hopefully [07:27] And my new test covers most interesting caes. [07:33] good morning === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2 [08:04] One more benefit of moving to PG 9.1 is that the enum types no longer suck, and we can use meaningful terms instead of cryptic integers at the DB level with things like our partial indexes. [08:10] stub: Ah yeah, sorry, I just assume everyone knows those two [08:11] Oh, I'm used to that. Just seeing the index go past prompted me to confirm being able to add values to the enumerated type got into 9.1. [08:36] wgrant: I assume this new index needs to go live? [08:39] Hi guys, i'm writing some scripts for ubuntu accomplishments, until now i solved all my problems reading online api documentation, but I'm now in stuck [08:40] i have to find all packages uploaded by a person, can you suggest me the best way? === almaisan-away is now known as al-maisan [09:00] stub: yes it does :) [09:01] lifeless: the index? === al-maisan is now known as almaisan-away [09:02] yes [09:04] * StevenK stabs gpg for being obtuse and terrible. [09:14] stub: Yes please. Don't think backups are done yet, though. [09:15] lifeless, wgrant: My network is just far to bad. webops will need to do it if you don't want to wait for my SEA -> Los Angeles link to stop sucking. [09:16] Got as far as typing 'scree' and waiting for the 'n' to come though :-/ [09:17] stub: It's not urgent; the rev won't be deployed until Monday or so. [09:17] k. I'll stick it on my list and try later. [09:17] Thanks :) [09:17] Except my reminder list is 'in the cloud' and accessed via LA too... [09:18] * stub grabs a pen [09:20] Looks like all of level 3 from my POV... did we break level 3? [09:22] stub: Haha, it's possible. [09:22] Is it sucking from AU too? [09:23] I've not seen any problems, what are you having trouble reaching? [09:44] StevenK: Starts happening Level 3 in Los Angeles. Probably the Singapore -> LA link or Level 3 in LA. [10:26] bwuhahaha, https://launchpad.net/+combo/rev15149/?yui/yui/yui-min.js [10:26] rick_h_: Indeed! [10:27] rick_h_: I suggest you and deryck find some time to get the flag enabled on qas and then hit up every bit JS to see what breaks. [10:27] Actually, while I think of it. [10:28] We also probably need to get a reasonable subset loaded early. [10:29] Right. [10:35] stub: Thanks. [10:35] * wgrant lands. [10:49] * StevenK declares victory over gpg. [10:53] StevenK: every small victory counts! [11:02] czajkowski: I've been fighting with it for a few hours spread over the last few days. [11:03] You'd think moving a private key to a different keyring is hard or something. [11:17] hey guys [11:17] so, uhh, I left a couple of Launchpad ec2 instances running somehow === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugs: 3.47*10^2 [11:25] morning adeuring [11:25] morning bac [11:26] hi beuno [11:26] hiya bac! [11:38] adeuring: you're not reviewing ian's MP are you? if not, i'll grab it now. [11:58] adeuring: nm, done. [12:04] bac: , right, I did had a look at the mp. (sorry for the late answer: had lunch...) [12:05] erm i did _not_ have a look at the mp [12:06] adeuring: perfect === salgado_ is now known as salgado === wgrant_ is now known as wgrant [13:03] Morning, folks. [13:03] morning deryck [13:42] StevenK: here I am! [13:44] angeloc: Right, so as I said in #launchpad, the first step is to gather your requirements. What exactly do you want to search by, and what results do you want to get back. Once you have that, we can see. === fjlacoste is now known as flacoste [14:07] i have to verify that a person has uploaded at least one package to assign him a trophy [14:07] StevenK: sorry for delay [14:12] angeloc: To a PPA? To the main Ubuntu archive? As the uploader itself, or is it okay if his upload was sponsored? [14:14] StevenK: sorry for not being explicit... as a first package uploaded, I can think of a sponsored one, I think I can create another tropy for people that has packages on their ppas [14:17] angeloc: Right, so I can't recall any method exported over the API that will do that. If you're not afraid of diving in and writing some Python, some people here will probably answer any questions you have. As for me, it's time for bed. [14:18] StevenK: thank you so much! Wich package I have to download to dig inside launchpad api implementation? === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2 === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [16:35] gmb: photo walk plan ? [16:38] czajkowski, Will email to you by Monday - bug me if I don't! Trying to find out if some of the suggested routes that I've found are actually a) sane b) interesting c) not liable to get us mugged. [16:42] gmb: cool ask pleia2 if you like [16:42] ahh you sent the mail to uds cool [16:42] was working on that saves em time :) [16:43] czajkowski, Ah, sorry, didn't realise I was duplicating effort. Oh well, you can relax now. Have a beer, knock off early... :P [16:43] hehe [16:43] :) === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado [17:04] * deryck lunches afk for a bit, to enroll the youngest in kindergarten. [17:04] ooh, send the kids away! === matsubara is now known as matsubara-lunch === salgado is now known as salgado-brb === salgado-brb is now known as salgado === matsubara-lunch is now known as matsubara [19:11] bac: Are you OCR? [19:17] rick_h_: There's no OCR. Up for a review? [19:19] abentley: aure thing [19:19] rick_h_: Thanks. https://code.launchpad.net/~abentley/launchpad/remove-create-merge-proposal-job/+merge/103929 [19:19] np [19:19] rick_h_: It is long, but 90% deletion. [19:32] abentley: what's this --\x20 in line 619 of the diff? [19:32] some sort of unicode foobar there with the mp maybe? [19:32] rick_h_: that's a lint fix. It's the encoding for a space. Having an actual space caused a lint complaint. [19:32] rick_h_: Because we don't like having trailing whitespace. [19:33] abentley: ah, ok that's inside of some message body [19:33] abentley: thanks [19:34] rick_h_: np. Should have mentioned that in the description. [19:42] woot! no more code* my poor chrome auto complete is so confused === benji___ is now known as benji === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [22:45] Hrm, I need the opposite of source_package.setBranch .. I need to delete the official branch pointer [22:50] SpamapS: .setBranch(None) [22:50] That easy? [22:50] Why didn't I think of that. :) [22:50] well, branch=None obv. [22:50] according to the code, yes [22:50] else: [22:50] # Delete the official DSP if there is no publishing history. [22:50] self.distribution_sourcepackage.delete() [22:51] maybe try it on staging first [22:55] this is for the 'charms' distribution :) [22:58] ERROR:can't determine Launchpad branch from bzr branch [22:58] oh wait [22:58] thats my problem.. [23:03] cjwatson: first test did not result in its removal... Hrm [23:04] is there a way to get launchpadlib to spew out what it is doing? Some kind of logging decorator? [23:07] import httplib2; httplib2.debuglevel = 1 [23:08] man [23:08] but that may not help if I made a mistake in interpreting what's happening on the server side [23:08] I *just* fell far enough down the well to find that in pydoc :) [23:08] yeah I just want to see that it sends None :) [23:09] pocket=Release&ws.op=setBranch&branch=null [23:15] Yeah, so I get a 200 OK with that, but it doesn't seem to actually be deleting the source package record [23:19] OK, maybe I'm wrong then [23:21] cjwatson: I'm looking at the same code.. but I haven't gone deeper to see what .delete() does