[00:00] hm [00:00] if i change buildrecipe into an importable module so that i can test it... [00:00] that seems to have a fair risk of breaking something during deployment [00:18] yes [00:18] its also an entirely separate project [00:18] well [00:19] i would like to add automatic tests for my changes [00:19] just something to be aware of [00:19] i guess i could add a separate landing to just make it testable [00:19] it seems like a high risk change so perhaps i'll just do without === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugtasks: 266 [00:25] lifeless: Thanks. [00:25] Still extremely slow, but it works. [00:25] lifeless: What's the production rabbit status? [00:25] lifeless: And are we going to persist with rsync-based fallback, or have a disk2amqp daemon? [00:26] s/daemon/cronjob/, if you like. [00:33] wgrant: cron job [00:33] wgrant: plumbing written, just need a glue project to pull it all together (datedir repo on one hand, amqp on the other) [00:33] wgrant: see oops-datedir-repo 0.0.10 [00:33] We should also ensure that the config name and tree base and script name are in the OOPSes, and then nuke all our OOPS configs :) [00:34] Ah, excellent! [00:34] prod rabbit is pending firewalls and tuolumne and nagios etc [00:34] I've an rt up for migration to this including moving to a shared local-oops dir for all servers [00:34] Great. [00:35] beuno is champing at the bit to get this for u1 ;) [00:35] i think the firewall's been done. was some chatter around that recently. [00:36] YES [00:36] looks like it [00:36] We also need a better way to handle rabbit passwords. [00:36] Currently they're in the LP configs, which won't really do. [00:36] so yes, we're ready to receive prod oopses over rabbit when the rest of the bits come together [00:36] We probably need to read them from some other file. [00:36] whats the issue ? [00:37] Configs are widely accessible, and the rabbitmq instance is accessible from more than just production LP servers. [00:37] you mean 'someone could connect and either consume or inject inappropriate messages' ? [00:37] yes. [00:38] so, moving oops-tools to its own box will help there [00:38] Indeed. [00:38] also we need to make sure the lp rabbit user has narrow perms [00:38] But we should be treating our message queue like we treat our DB, I think. [00:38] I haven't checked on that [00:38] Good luck with that... [00:38] How do you propose to do that? [00:39] It basically needs to be able to write to everything. [00:39] not at all [00:39] And eventually read lots of things too, probably. [00:39] write to oopses, create and write to longpoll.*, read from nothing, admin nothing. [00:39] (today) [00:39] thats pretty narrow [00:39] Today. [00:39] and as it changes, we can change it. [00:39] bbs [00:42] lifeless, i commented on https://code.launchpad.net/~mbp/launchpad/bug-width/+merge/80161 [00:45] wgrant: do you have any idea how buildrecipe gets installed, or where it gets renamed to buildrecipe.py? [00:45] It's probably contained in lp-buildd [00:45] So the build machinery of lp-buildd likely renames it [00:46] and that's not in the lp tree? [00:46] apparently not public ? [00:46] It is, lib/canonical/buildd [00:46] poolie: I don't think it actually does get renamed. [00:47] [sourcepackagerecipemanager] [00:47] buildrecipepath = /usr/share/launchpad-buildd/slavebin/buildrecipe [00:47] StevenK: i don't see anything in there that renames it [00:47] argv[0] might be buildrecipe.py, but I think it's a lie. [00:48] yes! [00:48] just realized the same thing [00:48] :/ [01:11] StevenK: hi [01:12] you don't need to write a lep for my sake [01:12] just a 'i'm planning to do X' on the bug would be ince in general though [01:27] short review on https://code.launchpad.net/~mbp/launchpad/884997-rusage/+merge/80971please anyone? [01:57] lifeless: Did you change the uppercasing rule part-way through yesterday? [01:57] Some of the hashes are allcaps, some are not. [01:58] in the db ? [01:58] or as reported to users? the latter is hashlib variations [01:58] DB, I assume. [01:58] It's in the reports. [01:58] hmm, odd. Possibly dboopsloader needs a fix too. [01:58] I shall check. [01:59] Ah [01:59] Could be. [02:01] yeah, from_pathname needs a fix [02:02] cowboyed [02:02] === modified file 'src/oopstools/oops/models.py' [02:02] --- src/oopstools/oops/models.py 2011-10-31 02:07:24 +0000 [02:02] +++ src/oopstools/oops/models.py 2011-11-02 02:02:03 +0000 [02:02] @@ -476,6 +476,7 @@ [02:02] oopsid = parsed_oops.get('id') [02:02] if oopsid is None: [02:02] raise OopsReadError('Not a valid OOPS report') [02:02] + parsed_oops['id'] = parsed_oops['id'].upper() [02:05] Thanks. [02:08] lifeless: 1 https%3A//launchpad.net/ubuntu/%2Bsource/oops/1.5.23.cvs-5.1/%2Bbuild/390896/%2Bindex (BinaryPackageBuild:+index) [02:08] OOPS-48d0191b7ac2d3136e4bd47d385fceb7 [02:08] 1 https://launchpad.net/ubuntu/+source/oops/1.5.23.cvs-5.1/+build/390896/+index (BinaryPackageBuild:+index) [02:08] OOPS-2131AU23 [02:08] New URLs are excessively URL-encoded. [02:17] I was afrait of that [02:17] I think I mentioned it [02:18] probably need an LP change - I suspect its emitting them as unicode [02:52] is this pqm rejection lp's way of telling me you're only taking rc fixes? [02:52] no [03:01] poolie: It's because we're in testfix. [03:01] and is that advertised anywhere? [03:01] No, because PQM sucks. [03:02] i thought people used to put it in the topic here or something [03:02] anyhow, np, just glad it's not my branch [03:27] lifeless: Around? [03:29] yas [03:30] lifeless: File "/srv/lp-oops.canonical.com/cgi-bin/lpoops/src/oopstools/oops/models.py", line 309, in _get_oops_tuple [03:30] for key, value in req_vars: [03:30] ValueError: need more than 1 value to unpack [03:30] Broken by a ['field.blob'] [03:30] Without a value. [03:30] Assume ''? [03:31] ugh [03:31] also win [03:31] so that needs two bugs [03:32] a) yes we should handle that [03:32] I thought that was already done [03:32] and b) we shouldn't be generating that [03:32] also c) req_vars should be a dict [03:32] I remember reviewing something that did that [03:32] but there is a bug on that lready [03:32] StevenK: urls [03:32] StevenK: / encodings [03:32] Not everything has a URL [03:33] What do you do for script OOPS [03:36] lifeless: Are you fixing the immediate issue, or should I? [03:45] StevenK: I know [03:46] wgrant: please do [03:47] It even works. [04:14] OOPS summaries twice in one day? [04:14] Yes, the old ones were wrong. [04:14] And today's are of particular interest. === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugtasks: 266 [04:17] lifeless: Is there a branch for your cowboy? [04:17] not yet [04:18] if you're doing one, roll this in [04:18] Was about to ask you to do the same :) [04:18] I can later [04:19] Also tempting to upper() the oopsids that were imported badly. [04:19] it would make them accessible [04:19] the oops table is a bit big to do it without date constraints [04:19] I planned to restrict to the last few days. [04:26] All seems happy now. [04:43] is lp out of testfix? [04:43] * StevenK becks [04:43] * StevenK grumbles at his keyboard [04:44] spm: Can you check if pigeonpea and pilinut need cleaning? [04:44] yup [04:45] lifeless: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1517/steps/shell_6/logs/summary looks possibly relevant to you [04:46] there's a bunch of oldish rabbits still running [04:46] only on pilinut tho [04:46] pigeonpea looks clean [04:46] Does pigeonpea have any old pid files in /var/tmp? [04:47] no old appserver processes ? [04:47] buildbot@pigeonpea:~$ ls /var/tmp/*.pid | wc -l [04:47] 111 [04:47] maybe.... [04:48] nothing running as BB, just the slave itself. no old processes running. [04:48] ^^ pigeonpea; all that applies to. [04:50] should I assume those pids should be rm'd? [04:50] pleas [04:50] e [04:50] Yup. [04:50] ugh. pilinut is just as dirty [04:51] any objections if I shutdown BB on pilinut and clear out the running rabbits [04:51] Do eet [04:51] No need to shut it down, but sure. [04:51] No build, so shutting it down is fine. [04:52] just to make it easy to clear out everything [04:52] What, kill all processes owned by the user? [04:52] yup [04:52] well. more making sure I don't clobber the BB process itself hard. [04:53] It deserves it, kill it anyway [04:53] huh. there's 3 pgbouncers in there as well [04:53] was [04:53] pilinut cleaned; pigeonpea cleaned [04:54] * StevenK forces a devel builkd [04:54] s/k// [04:55] Thanks spm. [04:55] np [05:02] poolie: Your branch should be fine to land now [05:02] thanks [05:07] * StevenK sets lp-oops on fire. [05:07] Perhaps SSO is to blame. [05:07] StevenK: What's up? [05:09] Forgetting the query string when logging in. [05:09] That's apache-openid [05:09] We should work around it by not using the query string. [05:09] This isn't 1990 :) [05:15] wgrant: kindly refrain from ridiculing as ancient history a year that I used to look forward to as the wondrous future. [05:16] Bah [05:16] It predates me by a year, therefore it is ancient history :) [05:16] Bwaha [05:16] Insolent whippersnapper. [05:16] This does illustrate why my quiz team lost that crucial point a few weeks back. [05:16] The question: name the four horsemen of the Apocalypse. [05:17] I shouted “Ronnie, Paul” etc. but whispered the real names to the teammate who was doing the writing. [05:17] He dutifully, but not altogether correctly, noted down: [05:17] Hunger [05:17] War [05:17] Dath [05:17] *Death [05:18] Insolence [05:18] I took him to task about it afterwards, after we'd lost by 1 point. His defense: “I'm British. To us, Insolence *is* a horseman of the apocalypse!” [05:19] * StevenK is trying to remember the four horsemen as according to Good Omens [05:19] Hunger, War, Pestilence, Death, and Ronnie who left before they became famous. [05:21] (Let's not give away the rest; there may be people here who haven't read it yet :) [05:22] No, it's Pollution, since Pestilence retired in 1963 following the discovery of pencillin. [05:24] Damn you, Sir Alexander Fleming! [05:25] (Why do I remember the name? Because the anniversary of his death was a few weeks ago, on quiz night. It pays to look these things up.) [05:28] This just in: IPCC announces the floods in Thailand were caused by Global Warming, _not_ as a naïve reader would deduct from looking at the actual numbers, from the reservoirs failing to run off excess water throughout the rain season. [05:29] To understand these announcements better, replace “Science” with “God” and variants of “Climate Change” with “Satan.” [05:30] I'm apparently expiring from 3 teams almost at the same time :/ [05:30] Yay launchpad spam [05:30] Shouldn't have joined them all in the same week. :) [05:31] Yeah, regrets. [05:32] Funny really: apparently team memberships expire, but when we wonder if untended membership _requests_ should expire, everyone's up in arms! [05:33] heh. [05:36] I want to change the lies in the expiry warning email. [05:36] Or a way to say "Hey, I dont care, let me expire [05:36] " [05:37] If anyone else does it, I'll buy them a drink :) [05:40] nigelb: I must warn you about one subtlety in Launchpad, and one in the real world. [05:40] jtv: Well, team memberships expire when the team admins want them too. [05:41] s/too/to/ [05:41] In Launchpad, where we say “person,” that person can also be a team. [05:41] And in the real world, champagne qualifies as a drink. [05:41] wgrant: that explains, thanks. [05:42] We don't just expire them by default, so you can't use that as an argument for expiring requests :) [05:42] by default [05:45] jtv, you're feisty today [05:45] hi poolie! === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 266 [05:52] night StevenK [05:56] jtv: hah. [05:59] nigelb: soooo… you just committed yourself to something that can be stretched to buying the entire team champagne. On the bright side, that might make the search for a volunteer a little easier. :) [05:59] * nigelb whistles [06:30] Our tests are crap :( [06:36] wgrant: so. write a test to test the crapness of our tests. problem solved. /me cross arms. nods. [06:38] Also, bugtasks are the bane of my existence. === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub === stub1 is now known as stub [06:54] wgrant: I'd argue its not bugtasks, but launchpad itself :P [06:55] Nah, most Launchpad stuff is fixable without incredible migration costs. [06:56] The existence of bugtasks is not. [07:09] ok, good night all [07:09] Night poolie. [08:17] Reviewer needed for small & simple change! https://code.launchpad.net/~jtv/launchpad/orderingcheck-unicode/+merge/80987 [08:18] jtv: I can do it ;) [08:18] So you can! Thanks. :) [08:19] * rvba likes Unicode stuff; yummy. [08:20] Spoken like a man with an umlaut [08:30] Evening stub. [08:31] Yo [08:32] Hi there stub — did you go back home? [08:34] Also, AFAIK Raphaël does not have an Umlaut; it's a different diacritical mark that happens to look the same (unless you're Hungarian I believe, in which case you use both for their respective purposes). [08:34] Ah: diaeresis, that's the word. [08:34] I think. [08:35] True, Umlaut != Diaeresis. [08:36] All you pedantics :P [08:36] An Umlaut transforms one vowel into another (a bit like the vowel changes in English, actually); this one separates two consecutive vowels, to show that they are in separate syllables. [08:37] Nobody bothers with them now, but a few decades ago you'd still find the same mark in English: “coöperate” [08:37] (To show that it's co-op-er-ate, not coop-er-ate) [08:38] stub: We ran into some slightly disturbing query speed issues yesterday. On qastaging, https://pastebin.canonical.com/55125/ takes <10ms to EXPLAIN ANALYZE, but 300-700ms to actually execute. On DF, it executes in <10ms too. It evaluates to [(1,)], so it's presumably not just terrible output formatting speed... [08:38] wgrant: too late. I chased him off. [08:38] Curses. [08:38] (This suggests he probably didn't go back home. Smart choice.) [08:38] Are you home? [08:38] No. [08:39] I'm making a trip there in a few hours, but don't want to sit around consuming scarce resources I'm not helping deliver. [08:39] Oh, done already eh? Thanks rvba [08:40] np [08:44] jtv: scarce resources? [08:44] Clean water, food, etc. [08:45] Even in areas that aren't affected, shops have found it difficult to keep stocks up. [08:45] oh. [08:50] morning [08:51] Morning bigjools! [08:52] good morning [08:54] g'morning [08:56] 'lo [09:11] 4 / 1081 RootObject:+login === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 266 [10:28] hmm, this is odd. one of my pending builds has an estimated start and finish time in the past. is that possible? [10:33] Any reviewers out there? I need to leave soon but I have a largish branch up for review: https://code.launchpad.net/~jtv/launchpad/bug-884649-branch-1/+merge/80988 [10:36] jtv: I'll take it [10:36] Thanks! [10:40] jtv: why all the new tests? [10:41] bigjools: so we won't need to iterate through all the possibilities in the integration tests. [10:41] This is stuff that couldn't be tested in isolation before. [10:41] ok [10:43] jtv: approved [10:45] Thanks. That was fast! [11:34] can I bug someone for a review please? https://code.launchpad.net/~julian-edwards/launchpad/cancel-build-bug-173018-ui-part4/+merge/80997 [11:47] bigjools: least I can do. [11:49] bigjools: I guess the “Cancel build” link takes you to a confirmation form (at +cancel)? [11:52] jtv: correct [11:53] I swear I don't remember a thing about menu links. I thought a link wouldn't show up in menu.links if its "enabled" condition said it was disabled. [11:57] jtv: menu.links is just the list defined at the top of the class [11:57] Ah [12:00] bigjools: done [12:00] thanks [12:01] I don't suppose python has a built-in equivalent to “lambda x: not x”? [12:01] Actually, no, that's not what I need. What I need is partial application of operator.not_ [12:02] Or something. [12:02] __builtins__.not_ = lambda x: not x [12:03] I was hoping to combine it with an attrgetter: filter(negate(attrgetter('my_bool_attr')), my_list) [12:03] For some value of negater. [12:04] jtv: operator.not_ [12:05] The problem is combining it with the attrgetter. :) [12:05] ah; lambda is your friend [12:05] Or reduce maybe [12:06] No [12:06] So back to partial [12:47] hey stub. We are getting a lot of activity on pgkillactive.py. This may be old news; I was out last week and am consumed by interviewing. But the logs are telling us stuff like this: [12:47] Killing lpnet127 (15802), 2011-11-01 11:20:17.341629+00:00, 2011-11-02 06:57:42.661591+00:00 [12:47] Locks found: [12:47] relname, transactionid, mode, granted, current_query, query_start, age, procpid [12:47] It's on lpnet 127, 129 and 130. [12:47] Does that suggest an action item? If so, has it already been taken? [12:49] gary_poster: I spent last week in a small village 100km from the Laos border and am now encircled by flood waters. I know less than you :-) [12:49] stub, heh, ok [12:49] are things getting better or worse, stub? [12:49] for your physical environment I mean :-P [12:50] gary_poster: I'm still dry, and if it floods in my area I'll be fine upstairs. Official news is crap though so hard to follow. [12:50] gotcha stub. good luck. [12:51] gary_poster: That was several hours ago? [12:51] Yes. [12:51] wgrant, yes [12:51] That was soybean wandering off into lala land. [12:51] It was powerstabbed and recovered. [12:51] We still don't really know what happened, but it wasn't an LP thing. [12:52] ok thanks wgrant [13:01] Guten morgen alles. [13:02] Bonjour mrevell [13:02] is the Launchpad web service going to get a 2.0 release for Precise? [13:05] Morning, all. [13:05] deryck: morning. [13:11] timrc: I'm not aware of any plans to do another stable API. However, the devel API is improving over time. [13:18] abentley, okay... I wasn't sure what LTS would mean (if anything) to the web service [13:20] timrc: you might want to ask lifeless for his thoughts. He's usually around in 6-7 hours. I have the impression that the devel service is much more popular than the 1.0 service, so stable versions may not be worth the extra effort they require. [13:27] bug 879589 [13:27] where's the bot [13:28] * nigelb pokes _mup_ [13:33] One of the blueprints for a session during UDS was deleted.. do any of the devs have the ability to figure out when it was deleted [13:42] cjohnston: I'm not too familiar with blueprints (that'd be sinzui) but I'm not sure we normally delete blueprints at all. [13:43] We have various statuses along the line of "obsolete" and "declined," and if that's what happened we may be able to learn more. [13:43] its 404'ed [13:43] we figured out the issue.. so its all good [13:43] cjohnston: it's probably been renamed [13:43] Ah. [13:44] that could be too [13:44] or retargeted [13:44] would it be possible to create some sort of forward for a while when they are retargeted? [13:45] if you don't mind changing launchpad, sure! [13:45] lol [13:45] He already has patches [13:45] ;) [13:45] ive already made changes [13:45] 6 landings I think? [13:45] something like that [13:46] And yet none of them fixed your problem? Patch harder! [13:46] Meanwhile, any reviewers for tiny tiny leetle branch? https://code.launchpad.net/~jtv/launchpad/getBinariesForDomination-bulk/+merge/81020 [13:47] yup.. its a branch [13:53] jtv / mwhudson.. for sprints (ie the current UDS) when a track lead is set as an approver.. do they get a notification and or a reminder about a blueprint that needs to be approved [13:54] cjohnston: don't know, sorry [13:54] Same here. [13:55] anyone else know by chance? [13:56] cjohnston: *cough* "Use the source, Like" *cough* [13:56] too much work [13:57] Blueprints is probably the easiest to understand. === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 266 [14:01] Does anyone know why I'd get a NotABranch error from merge-proposal-jobs.py in qastaging? https://lp-oops.canonical.com/?oopsid=OOPS-d39c8d786a4c80ed1f17e9943d2f51ae [14:01] s/NotABranch/NotBranchError/ [14:01] jtv: I've reviewed your tiny tiny branch ;) [14:01] Thanks! [14:02] allenap: not scanned yet? [14:04] jtv: I pushed it yesterday, and revisions are appearing in the UI [14:04] Oh, wait. This is qastaging. [14:04] Does it have its own codehosting server? [14:04] jtv: It's running on gandwana as bzrsyncd. [14:05] Which is the same host as used for staging. [14:05] So much for that then. [14:06] jtv: The error mentioned lp-internal:///~allenap/scriptify/test1... there's no mention of qastaging there, or is it, as it implied, a purely internal identifier. [14:07] danhg: Do you know if the launchpad session will have audio? [14:08] $ bzr push lp://qastaging/~allenap/scriptify/test1 --use-existing-dir [14:08] bzr: ERROR: Server sent an unexpected error: ('error', 'NotBranchError', 'Not a branch: "lp-83227408:///+branch-id/360039".') [14:11] $ bzr push lp://qastaging/~allenap/scriptify/test1 [14:11] This transport does not update the working tree of: bzr+ssh://bazaar.qastaging.launchpad.net/~allenap/scriptify/test1/. See 'bzr help working-trees' for more information. [14:11] Created new branch. [14:11] $ bzr push lp://qastaging/~allenap/scriptify/test1 [14:11] No new revisions to push. [14:11] Now I can see a .bzr directory in the right place (with hitchhiker). [14:13] abentley, hey, shall we mumble a bit now? [14:13] deryck: sure [14:13] hi coffeedude [14:13] jtv: I was thinking about BPPH.binarypackagename but I'm not sure that's helpful for you. [14:14] rvba: not really — it's still one-by-one. [14:14] But I'm not too worried about it; I think it'll be a secondary issue at worst. [14:14] Okay. [14:14] Oh wait, _now_ I get what you mean! [14:15] hey deryck [14:15] The column that's been recently added to the table. Has that been fully initialized yet? [14:15] jtv: exactly [14:15] Has initialization completed yet? [14:15] jtv: I think it has. [14:15] If so then yes, it would be useful! [14:15] Thanks for pointing that out. [14:15] Glad to help ;) [14:16] It means we can avoid loading the BPN anywhere. [14:16] Maybe even the BPR… worth thinking about. [14:24]