[00:00] and I get a Bad Request trying to edit the title of https://bugs.launchpad.net/launchpad/+bug/925791 [00:00] <_mup_> Bug #925791: OOPS-24bbc670994b55b2e26d848fce30c554 trying to update bug parameters < https://launchpad.net/bugs/925791 > [00:00] * lifeless twitches [00:01] StevenK: can you try editing a bug title ? [00:01] oh, nvm I had a CR in the field [00:01] odd but not major [00:18] I think there's a bug about something like that lifeless [00:19] * StevenK prods wallyworld to update the topic. [00:19] rick_h: probably ;) [00:19] of course now I can't find it [00:19] rick_h: The thought of rsync makes me sad :-( [00:19] StevenK: it does me as well [00:19] rsync ? [00:19] * wallyworld will as soon as he lands his branch [00:19] sorry, forgot that wasn't on the mailing list [00:20] lifeless: So, I changed the convoy root dir to be inside the tree, like icing === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugtasks: 4*10^2 [00:20] lifeless: give me a sec to get a summary between StevenK's email and my response [00:20] * StevenK goes back to his branch, leaving rick_h to explain [00:20] (Sorry, it *has* to be done today) [00:21] lifeless: https://pastebin.canonical.com/59345/ [00:21] lifeless: I wanted to get with deryck on it today, but he left early sick so we didn't get a chance to talk [00:22] StevenK: is /var/tmp a temp dir? I thought it was an lp spethial [00:22] /var/tmp is in the FHS [00:22] lifeless: And is 1777, so yes [00:22] It's more persistent than /tmp [00:22] lifeless: oh and this was the bug I was thinking of, not the right bug: https://bugs.launchpad.net/launchpad/+bug/703061 [00:22] <_mup_> Bug #703061: Tags edit with syntax error makes further tag editing impossible < https://launchpad.net/bugs/703061 > [00:22] ie. not a tmpfs [00:23] * StevenK tries to remember how to check if a feature flag is turned on [00:23] StevenK: /+feature-rules I think [00:23] In code :-P [00:23] oh, heh [00:24] StevenK: well check the app/templates/layout-macros since it's got checks there [00:24] StevenK: lp.services.features.getFeatureFlag(name) [00:24] Ah! [00:24] I thought it was get_ [00:24] huwshimi: hi; remember that cool ajax log you wrote ? [00:25] huwshimi: it seems to not be seeing ajax requests anymore for me (on FF in precise) [00:25] lifeless: that could be the broken JS due to localizing events that my branch landing today shold hopefully fix [00:25] if it's not fixed after that lands let me know [00:25] kk [00:26] lifeless: Yeah, killed by the non global attachement of the io event, I guess [00:27] ok cool [00:28] Would be fixed on prod by now if buildbot hadn't lost its mind. [00:28] * StevenK shakes his fist at buildbot more. [00:31] lifeless: wgrant appreciate any thoughts on the JS/build location fun there in the pastebin [00:32] You're going to regret that. [00:32] why won't the owner match? [00:32] *yawn* getting sleepy... /me runs to bed [00:33] lifeless: The symlink is created by me. [00:33] lifeless: because on your dev system make run is performed as you while apache is run as root [00:33] Apache does NOT run as root [00:33] we have the same split on prod etc [00:33] It runs as www-data [00:33] well www-data I guess [00:33] so why would it work on prod etc [00:33] sorry sorry [00:33] lifeless: Because the symlink won't be in a temp dir [00:33] righto [00:33] so, to me the obvious thing is 'wth are we putting this in a temp dir' [00:34] /srv/launchpad.dev/convoy [00:34] So we don't need root and the need to use sudo in our Makefile [00:34] make that owned by stevenk [00:34] lifeless: because we have to tell the apache .wsgi file for convoy where it's root directory it serves out of is. [00:34] rick_h: thats a constraint, but not a reason for that specific directory [00:34] lifeless: so we want that to be a constant spot, but still allow you to switch branches/etc in dev without breaking/relinking things [00:35] lifeless: true, just describing what led to where we are [00:35] rick_h: still with you, still don't see why that specific directory. [00:35] we need root to do the one-time setup [00:35] sites-enabled, bzr rewriter configuration, wsgi config addition to apache. [00:36] making and chowning /srv/launchpad.dev/convoy at the same time seems pretty straight forward, or am I missing something? [00:36] So that's 'sudo make copy-apache-config' [00:36] I'm a bit loath to have that do, well, more than that [00:39] lifeless: right, but after we make /srv/launchpad.dev/convoy, apache is serving the files in there as www-data while the symlink you create as the dev will be owned by your user [00:39] rick_h: but it won't be marked 1777 so who cares [00:39] lifeless: ah ic [00:39] * StevenK sees [00:41] wallyworld: ping, the second question in that MP was less about the . in the ids, but that the code you wrote uses Y.Dom.getById while the code in the tests uses Y.one('[name=]') [00:41] wallyworld: so one code is finding html elements by ids, while the tests are searching for elements with a name attribute, so they're testing different things [00:42] wallyworld: e.g. tests could pass with html that would fail the production code [00:42] rick_h: ah, right. what zope does is spit out elements with id = name [00:42] Success [00:42] wallyworld: right, I know it works and all, but just struck me as the tests html is manually generated/etc [00:43] wallyworld: anyway, just wanted to clear up the question wasn't about the periods, but the matching methods [00:43] rick_h: np. thanks. i'll look at it since there's still a couple more branches to go yet [00:44] wgrant: https://lp-oops.canonical.com/oops.py/?oopsid=9040bdec04b696e8fd0c80de3462cca5 may make you laugh maniacally [00:45] lifeless: It works with /srv/launchpad.dev [00:46] StevenK: yay! [00:46] StevenK: one step closer to domination [00:46] StevenK: wicked :) [00:48] Let me get this other branch put to bed, and I'll fix up combo-url [00:48] lifeless: Heh [00:48] lifeless: Handy [00:48] Speaking of loggerhead, it's very tempting to halve our exception count by fixing one of its bugs. [00:49] Just one? [00:49] Yes. [00:49] Hm [00:49] Why has the theme changed [00:49] wgrant: I'm going to do a release today. release today. release today. [00:49] Context menus etc. are light grey now :( [00:50] wgrant: in lh ? [00:50] wgrant: Yeah, some of the theme stuff got fixed, I think a few things broke too [00:50] wgrant: fixing that exception would be pretty awesome [00:50] actually, I'm going to upgrade our revision. Check its copacetic on qastaging and then release on tuesday. [00:51] WCPGW [00:51] E-WHUT? [00:51] What Could Possibly Go Wrong [00:52] with what I'm doing? We might have to rollback a rev if trunk is buggered somehow. Thats about all. [00:53] lifeless: I know. YHBT, HTH, HAND [00:53] * StevenK tries to figure out how to add a commercial subscription [00:54] <- was sick, now just sleep deprived [00:54] Welcome to fatherhood [00:55] StevenK: I think that's the only LP action I've never performed. [00:55] wgrant: I mean in a test, anyway [00:55] Tempted to just store.execute() and be evil [01:00] Hm [01:00] lifeless: How do I run loggerhead? [01:00] serve-branches just 404s [01:00] Do I have to symlink it into by bzr plugins path? [01:00] wgrant: you can use file://$(pwd) [01:01] wgrant: its getting a base url of readonly+path-you-gave-it [01:01] which doesn't trigger the readonly decorator for some odd reason, I think a bzr change [01:01] so you end up using $(pwd)/readonly+pathyougaveit [01:01] which fails humourously [01:01] lifeless: Ahh [01:01] Thanks. [01:02] I was just giving it a path, not a URL [01:02] you are meant to be able to [01:02] its a change :P [01:02] I certainly used to be able to. [01:02] Right [01:02] ah, mwhudson sucks [01:02] he fixed three bugs and didn't upgrade us [01:03] Haha [01:03] Mornin' [01:04] Good lord [01:04] Do not edit loggerhead with pocket-lint vim integration. [01:04] The red will make your eyes melt [01:04] heh [01:04] Haha [01:09] Now to extend Loggerhead's exemplary test suite to cover my fix. [01:09] *cough* [01:10] wgrant: do you want me to wait on https://code.launchpad.net/~lifeless/launchpad/loggerhead/+merge/91379 ? [01:10] lifeless: Might as well, it's a trivial try/except/raise NotFound [01:10] Just going to see if I can be bothered writing a test. [01:13] lifeless: This fixes exceptions #1 and #3 for the last 9 months, so might as well wait a few minutes :) [01:27] who wants to be the one to flip the switch on heat on monday? [01:28] me me me [01:28] Haha [01:29] wgrant: ok, please do [01:29] wgrant: I will be doing $notwork [01:29] ! [01:29] Oh, right, public holiday. [01:29] Skyrim! [01:29] X3! [01:29] All of the above! [01:29] x3:ap probably [01:29] another horse race? [01:29] that and house work [01:30] What's AP? [01:30] Is that the one after TC? [01:30] albion prelude [01:30] tc engine, terrans at war with argon [01:30] Ah [01:31] nigelb: No, the New Zealand people signed a treaty. Apparently, this is worth a day off [01:31] StevenK: wow. [01:31] Said treaty was signed in 18xx [01:31] To be fair, it sounds better than a holiday for a horse race :P [01:32] * nigelb ducks [01:32] lifeless: https://code.launchpad.net/~wgrant/loggerhead/bug-728209/+merge/91383 [01:34] lifeless: Hm [01:34] lifeless: I wonder if we want to drop heat from the default listings. [01:35] perhaps, but orthogonal [01:35] they won't change all that much even without aging because comments reset sging [01:35] True [01:36] lifeless: So, can has review, or should I throw it at wallyworld? [01:38] lifeless: Was that a +1 without a +1? [01:38] * wallyworld taps fingers waiting [01:39] Hah [01:39] Thanks. [01:40] handoffs cost :P so I've done it [01:43] nigelb: Only Melbourne gets the public holiday for Melbourne Cup Day [01:43] nigelb: The rest of the country have to work, but not much gets done [01:43] the rest of the country just fakes it [01:55] tis with ec2 [01:58] StevenK: Wait, I thought you lived in Melbourne. [01:59] Nah, only I'm in Melbourne. [01:59] Everyone else is Sydney or Hobart. [01:59] jamesh and wallyworld don't exist. [01:59] Bwahaha [02:00] * wallyworld goes to hospital to get wife [02:02] heh [02:02] AttributeError: type object 'Product' has no attribute 'owner_id' :-( [02:03] owneriD [02:03] ID [02:03] That doesn't work either [02:04] !doesn't work [02:04] AttributeError: type object 'Product' has no attribute 'ownerID' [02:06] StevenK: _ownerID [02:06] owner is a property [02:07] Bah [02:16] wgrant: is 1043 / 485 MaloneApplication:+bugs what you were expecting? [02:23] lifeless: That's more like it. [02:34] wgrant: whats up with 'unable to find source package foo in suite' [02:36] lifeless: It means the build's source is no longer active. [02:36] ie. it's superseded or deleted [02:46] why is it an oops? [02:50] Because nobody has fixed it. [02:51] Because it's not clear how best to fix it. [03:10] wgrant: what is there to fix? [03:10] bbiab [03:52] TypeError: Expected datetime, found (datetime.datetime(2012, 3, 4, 9, 15, 45, 96703),) [03:58] StevenK: tuple != datetime [04:00] Yes [04:00] I found the one-char bug :-( [04:12] wallyworld: But whereas I previously held for Java a cordial dislike borne of having only a cursory notion of how it worked, now my dislike for the language can no longer be called at all "cordial", for familiarity has bred contempt. -- Tom Christiansen [04:12] why? [04:13] Why what? [04:14] what made you have even more contempt? [04:14] It isn't my quote [04:15] oh, ok. i thought you were using the quote to communicate your own revelation [04:15] Nah, just teasing your like of Java [04:16] s/like/not blind hatred [04:18] s/like/respect/ ? [04:18] perhaps. it's done a fine job for 16 or so years [04:18] in the enterprise space [04:19] client not so much [04:35] $ ls -lh ~/.cache/checkbox/checkbox.log [04:35] -rw-rw-r-- 1 wgrant wgrant 50G Oct 15 17:02 /home/wgrant/.cache/checkbox/checkbox.log [04:36] The first and the final lines are 21 hours apart. [04:37] Impressive [04:48] wallyworld: O hai [05:03] * wgrant considers rejecting on the basis that the description matches /empower/. [05:12] Bah [05:29] wgrant: Would you mind reviewing it since wallyworld seems to be afk? [05:31] wgrant or StevenK - could you please land my loggerhead branch? I'm suffering the lp-land breakage abently is fixing [05:31] lifeless: Link me [05:31] I'm knee-deep in a few hundred lines of PL/pgSQL and bug search code and appserver logs, so I'd prefer not. [05:31] lifeless: If it's updating the revno, I can JFDI [05:32] wgrant: Okay [05:32] its a tiny bit more [05:32] lifeless: Then link me [05:32] StevenK: https://code.launchpad.net/~lifeless/launchpad/loggerhead/+merge/91379 [05:33] export tarballs false? Why? [05:33] new feature [05:33] unknown overheads [05:33] don't know if it would cripple us, or be totally fine [05:33] so being conservative [05:33] Oh, so it doesn't currently exist? [05:33] right [05:34] Objection withdrawn, landing [05:34] I think; let me triple check [05:34] nope, I'm wrong, we were on 461, which added that [05:34] lifeless: Is postgres smart enough to walk backwards from the end of a segment of a composite index? [05:34] but, I am moderately sure I intended for it to be turned off :P [05:34] lifeless: But it might be being used [05:35] StevenK: I'll delete that hunk, one sec [05:35] ie. if I have an index on (foo, bar, baz), filter on (foo, bar), and order by -baz, will it use the index sensibly? [05:36] wgrant: pretty sure it won't. If you order by -foo -bar -baz, then yes [05:37] StevenK: pushed [05:37] lifeless: Thanks [05:37] lifeless: ec2 is pointless? [05:40] FSVO [05:40] put it this way, if it breaks, tell me on tuesday :) [05:40] lifeless: For that branch. I can toss it through ec2 if you wish [05:40] its probably safer [05:40] I don't -expect- surprises, but then, who does? [05:42] * StevenK wonders where wallyworld has gotten to. [05:46] StevenK: (13:00:57) wallyworld: *goes to hospital to get wife* [05:46] But he spoke at 3pm [05:46] StevenK: Oh, that's true [05:49] StevenK: was picking up kid from school [05:49] wallyworld: He can walk home [05:49] :-P [05:49] still need a review? [05:49] wallyworld: Please [05:49] looking now [05:50] wallyworld: https://code.launchpad.net/~stevenk/launchpad/show-visibility-teamadd/+merge/91389 that one [05:50] wallyworld: combo-url can be done by rick_h [05:50] sounds good to me :-) [05:51] StevenK: btw - Total: 17029 tests, 5 failures, 0 errors in 210 minutes 43.985 seconds. [05:51] Nice, it's a smidge faster than ec2 [05:51] 3 of the failures were mailmain, 1 was due to oneiric, not sure about the other [05:52] We don't run Mailman tests [05:52] this one was the one that failed: lp.services.mailman.tests.test_mlist_sync.TestMListSync [05:52] so we don't run that one? [05:54] Let me check [05:54] StevenK: what's the difference between launchpad.Commercial permission and "current commercial subscription"? [05:54] We clearly run it, or it wouldn't have run :) [05:54] We don't run MailmanLayer [05:55] wallyworld: launchpad.Commercial == commercial admin [05:55] ok, so like curtis etc [05:55] wallyworld: "current commercial subscription" == have paid monies to us [05:56] StevenK: you'd have thought that folks who paid money would have had this feature already [05:56] steven@liquified:~% zcat Desktop/ttb-no-chroot-r14741.subunit.gz | subunit-ls | grep -c TestMListSync [05:56] 3 [05:56] wallyworld: They can ask for it, like Curtis said [05:56] StevenK: yep, those 3 tests all fail, probably same root cause [05:56] So, they can already have it, but it isn't self-service. [05:57] wallyworld: Right [05:57] right. pretty sucky though [05:57] That's why we're fixing it! [05:57] wallyworld: Yes, this is what I've been complaining about. [05:58] Someone implemented an overly-restricted checkbox in 2007, unrelatedly implemented commercial subscriptions, and then said "lol, we have a commercial offering" [05:58] i'm pretty embarrassed we charge people money, for not much it seems [05:58] Precisely. [05:58] I've long maintained that we should have discontinued the commercial offering years ago :) [05:59] yeah, can see why [06:00] StevenK: the logic in conditionallyOmitVisibility(self):... imho it needs a bit of love, and we should only type "self.form_fields = self.form_fields.omit('visibility')" once [06:00] in the method [06:04] StevenK: i'm not sure how the logic changes allow normal admins to see the field whereas before they didn't. perhaps extend the code comments to say how? [06:05] wallyworld: Like so http://pastebin.ubuntu.com/827310/ [06:05] wallyworld: Before they could, there are other tests for that [06:05] dammit postgres, it's not that hard to vacuum a 50000 row uncontended table :/ [06:05] admins have launchpad.Commercial too [06:07] StevenK: ok. the pastebin look better thanks. do we need "return None" or just "return"? just return would suffice? [06:07] wallyworld: Right, fixed too [06:09] StevenK: thanks. my only other comment is a personal preference - i would have used a helper method "hasCurrentCommercialSubscription(person)" to get the storm stuff out of the main method and make it a lot cleaner [06:09] perhaps there's already a helper method like that [06:09] I doubt it [06:10] hmmm. i would have thought there would be several places where we would need to know that [06:10] maybe even add the method to IPerson [06:10] There *should* be. [06:10] But this is the first. [06:10] so we should set things up "properly" perhaps - add the method to IPerson? [06:11] Yep [06:11] I can move it to IPerson [06:11] Then you'll want more tests [06:11] cool. that would be peachy. thanks [06:11] yeah, sorry. just one or two [06:11] * StevenK kicks wallyworld [06:11] ouch [06:11] be back in a sec, wife wants something [06:17] wtf postgres [06:21] what has it done now? [06:21] slow vacuum [06:21] maybe it needs to use a Dyson [06:32] wgrant: could you do me a favour and lp-land this? a single test failed ec2 which i fixed by editing the test. lp:~wallyworld/launchpad/confirm-reviewer-subscription-330290 [06:32] lpland still broken on precise for me [06:33] * StevenK grumbles at that [06:33] * StevenK kicks wallyworld again [06:33] ouch [06:33] I can land it if wgrant isn't on it [06:33] stub: How close it 9.1? [06:33] s/it/is/ [06:34] Hah, nice timing. [06:34] thanks stub [06:34] 28 failures, 25 errors [06:35] And a lot of that is probably due to using E style quoting if we want to push it through faster [06:37] AttributeError: 'Entry' object has no attribute 'source_branch' [06:37] yay [06:39] lp-land seems pretty broken without the branch existing locally [06:40] Yes [06:44] wallyworld: its with pqm now [06:45] https://pqm.launchpad.net/ is showing some odd errors - new? [06:45] bzr: ERROR: no such option: -0 [06:46] It's done that since I changed the regexps a year ago. [06:46] Not sufficiently harmful that I've found time to fix it. [06:47] wallyworld: Diff updated. [06:47] * wallyworld looks [06:48] Rather than fix it, I'm going to nuke the mockdb stuff which failed. [06:48] stub: That sounds like an excellent plan. [06:50] StevenK: me like. you could now use an "and" in your if condition in conditionallyOmitVisibility() [06:51] wallyworld: Where? [06:52] Oh, if getFF and if hasCurr [06:52] 50 + if getFeatureFlag( [06:52] 51 + 'disclosure.show_visibility_for_team_add.enabled'): [06:52] 52 + if self.user.hasCurrentCommercialSubscription(): [06:52] 53 + return [06:52] wallyworld: Not much point, it's +3/-3 [06:53] sure, but it reads much better. anyways, your choice [06:53] if getFeatureFlag( [06:53] 'disclosure.show_visibility_for_team_add.enabled') and [06:53] self.user.hasCurrentCommercialSubscription(): [06:53] return [06:53] But doesn't [06:54] i would write it as: f_flag = getFeatureFlag('xxxx') [06:54] if f_flag and self.user.hasCommercialSubsction(): [06:54] .... [06:56] wallyworld: Pushing [06:56] thanks, already approved :-) [06:56] wallyworld: But thanks for the +1, I'll toss it at ec2 [06:57] * StevenK cackles at the register [06:57] "iPhoners are the most likely to date a co-worker, with nearly a quarter saying they had an office fling in the past five years, perhaps because they all work in graphic design and don't have any real work to do." [07:18] http://ahbahb.com/TH/shop/typography-collection/ahbtypo03-m.html === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [08:54] good morning [08:56] wallyworld__: http://www.youtube.com/watch?v=2V9-g8JuBZc [08:56] Other YUI frontend people might love this ^ [08:59] rick_h: ^^ === almaisan-away is now known as al-maisan [09:30] nigelb: let me take a look [09:32] good sense of humour he has :-) [09:33] heh [11:04] nigelb: yea, saw that. Funny stuff === matsubara-afk is now known as matsubara [11:34] hi launchpadders [11:42] howdy jelmer [11:45] rick_h: heh [11:45] O hai jelmer [11:51] rick_h: So, you can review combo-url at some point? [12:01] adeuring: I found an OOPS for bug 925937 in yesterdays oops report [12:01] <_mup_> Bug #925937: Does this bug affect you: Timeout error popup < https://launchpad.net/bugs/925937 > [12:02] lifeless: cool, thanks! [12:02] adeuring: looks like classic death by many queries and/or sending mail - at a first glance [12:02] StevenK: is there a branch for that then? [12:02] adeuring: np [12:02] * rick_h must have missed it [12:02] lifeless: can you add the OOPS ID to the bug report? [12:02] adeuring: I have [12:03] lifeless: gah, i looked only at comments... [12:03] :P [12:04] StevenK: nvm, found it. Forgot that branch was around still [12:11] rick_h: It should be good to land, and shouldn't impact qastaging and so on [12:12] StevenK: cool, I'm pulling it to try it out and will update and try to get jcsackett to ok today then [12:13] rick_h: Okay -- if there isn't any problems, hoping to land on Monday morning [12:13] StevenK: would be awesome and I can move this test rewrite forward with the build files in place [12:14] StevenK: now this is using the older convoy version right? where it ignores the path? [12:14] StevenK: did you ever get a chance to verify what the $revno was in dev mode? [12:15] rick_h: It is the current revno of the branch [12:15] But it doesn't impact on devmode [12:15] StevenK: even in dev mode? I thought someone thought it was 'unkonwn' or something [12:15] Yes, even in devmode. [12:16] StevenK: so when I first run this I get an error that ln: creating symbolic link `/srv/launchpad.dev/convoy': No such file or directory [12:16] should it create the directory for me or is that my duty as dev? [12:16] rick_h: Right, so you need to do two things -- you need run 'sudo make copy-apache-config' which will create the dir for you, and you probably need to hack /usr/share/convoy/convoy.wsgi to point to it and reload apache. [12:17] It's a bit rough, I'll be updating convoy on Monday. [12:17] I may guard that ln to not bite people [12:17] StevenK: yea cool [12:19] Actually, guarding that ln would probably work [12:19] StevenK: so just for the review, want to make sure that the make file won't be a problem landing this out since that stops make? [12:20] rick_h: Right, so 'inplace' does not get run on qastaging and so on, and I just want the usual review for the rest of it since there are a large number of changes since the previous MP [12:20] StevenK: ok, yea sorry I just want to make sure. [12:21] rick_h: I think my plan of having devs needing to run 'sudo make copy-apache-config' once is a sane one, since the /+combo stuff will need to be there before they can enable the FF locally anyway [12:21] StevenK: yea, while it's a FF thing I think that's fine personally [12:21] And we can update the live sites that serve convoy to do that so that non-devs can use it on the live site then [12:23] rick_h: Right. One concern I have is I'm not sure how to inject CONVOY_ROOT into apache's environment. But that is only a deployment issue for qastaging/staging [12:23] And I was planning on RTFMing on Monday [12:23] StevenK: can we just do that at copy-apache-config? [12:24] sed the file as it's written? [12:24] qastaging doesn't use that make file target, and it should not [12:24] ok [12:24] Like I say, it's a deployment problem, it does not impact this branch [12:26] StevenK: ah ic, so we just use a different url in the dev mode combo_url property. [12:26] Eh? [12:27] Oh, right. Yes. [12:27] We don't care about revnos on dev [12:27] StevenK: just going over the MP and understanding why "it doesn't matter" what the revno is in dev mode [12:27] Sorry, early in the morning, slowly winding up :) [12:27] * StevenK sticks rick_h with a caffeine IV. [12:28] lol [12:28] I need one, out of Dr Pepper this morning. Might need a run to the coffee shop [12:28] Damn Fridays, kitchen gets empty [12:28] nigelb: BAH [12:28] nigelb: BAH [12:28] nigelb: BAH [12:28] StevenK, what? [12:28] Guess. [12:28] cricket not going well? [12:28] Cricket finished [12:28] OMG [12:28] EPICWIN [12:29] muhahahaha [12:29] Finally! [12:29] * StevenK stuffs nigelb out of an airlock [12:29] nigelb is a cricket fan as well? [12:30] man, who knew that was a real game people played? :P [12:30] As much as StevenK. [12:30] We both actually hate the game, but like it when our respective countries beat each other. [12:30] StevenK: so how does libapache2_modwsgi fit into this then? [12:30] rick_h: there's a load of Brits, Aussies and Indians around. There will be cricket fans :) [12:30] StevenK: that's another manual step right? Or can copy-apache-config check/install that? [12:31] bigjools has a valid point. [12:31] bigjools: yea, I'm getting an education. In the US it's just something we see in the occassional movie poking fun at the aristocracy kind of thing [12:31] rick_h: libapache2-mod-wsgi is still manual step [12:31] rick_h: I think I'm okay with that *for now* [12:31] StevenK: ok, cool. Just wanting to get the notes together so that as this moves forward we can have it documented or something [12:32] rick_h: I can't think why it's linked with aristocracy. I think you need to go to a game some time :) [12:32] rick_h: Documentation? What does that word mean? [12:32] bigjools: yea, I'll have to find out if it's legal in the US and see what's up. [12:33] StevenK: :) I'm going to have to tell deryck how to turn it on at some point [12:33] Three steps, which I was planning on announcing to -dev, once that branch lands [12:33] StevenK: ok, approved with the note on the ln command blowing up [12:34] StevenK: I'll poke jcsackett when he's around later this morning so you should be golden for Monday hopefully [12:34] Yeah, I think I will guard that ln just so I don't catch anyone out [12:34] Yea, if you're not using the combo loader it should be invisible I think [12:34] Right [12:34] Thanks for working on it! [12:35] if [ -d /srv/launchpad.dev ]; then ln ... ; fi [12:35] * rick_h is finally starting to see that this might actually work in the near future [12:35] rick_h: And then qas is waiting for the RT [12:35] But this branch must come first [12:36] StevenK: ok cool. Well, once we're actually ready maybe we can ping someone or something [12:36] StevenK: right, this opens up me getting tests fixed, and running locally to start fixing bugs/issues [12:36] Get going, then. :-) [12:37] heh, lifeless did we come to any conclusion on the browser front? [12:37] lifeless: should I bring up IE8 testing/fixing to deryck on our stand up today? [12:42] StevenK: heh, "Finally India" is trending on twitter in India :P [12:52] nigelb: I would have expected "About *bloody* time MS Dhoni!" [12:52] haha === bac__ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 4*10^2 === bac__ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac__ | Firefighting: - | Critical bugtasks: 4*10^2 [12:54] hello, adeuring -- reviewing today? [13:13] bac__: oops, yes... [13:13] * nigelb hands gmb a "Did not Die" badge :) === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac__ , adeuring | Firefighting: - | Critical bugtasks: 4*10^2 [13:14] nigelb: We should start a club :) [13:14] heh [13:14] I'll be riding 30km everyday from today though [13:16] rick_h: it has elliots +1, and it is pretty common out there, so I doubt francis will object to us fixing ie8 :) [13:17] nigelb: Might take me a couple of weeks to get back up to that; depends on the temperature outside. But before Christmas I was managing a 20k hilly ride every lunch, which wasn't so terrible. [13:17] Can't wait for the mornings to get lighter so that I can get out before work. [13:18] Ah. I drive to a co-working space sorta thing everyday. Through amazing traffic :) [13:18] Oh, lovely. [13:18] I'm fairly rural, so early morning rides in the dark are a bit hairy, especially on icy days. [13:18] Ah, that's scary. [13:19] My roads are filled with potholes to slow me down. [13:19] :) [13:19] * gmb -> emergency cup of tea before team call [13:42] jcsackett: if you get a sec can you look over this review we did for StevenK a while back? https://code.launchpad.net/~stevenk/launchpad/combo-url [13:42] rick_h: sure, i can look right now. [13:43] jcsackett: thanks, hoping to get it through to land on monday for him [13:47] StevenK: you actually up and around? [13:48] jcsackett: I chatted with him about it this morning if you've got a question I might know [13:49] rick_h: so, i see he's changed rocketfuel-setup to install mod-wsgi; what's the hurdle in getting make/rocketfuel to do all the setup we need for convoy? [13:49] since i would prefer that to a guard on the convoy path. [13:51] jcsackett: ah, not sure on that the setup side. I know I was worried about current users just running an updated make [13:51] jcsackett: but yea, it might make sense to have the setup support the whole thing then [13:53] rick_h: yeah. you have any idea of how long this stuff has been blocked? i don't want to be yet another holdup on something we need, but i want this question answered too. [13:54] jcsackett: well this is just to get things going in dev. There's still an issue getting it to run in QA and we're waiting on a RT for convoy I think [13:54] jcsackett: so this is mainly to land enough so that a dev can start working on it behind a FF [13:54] jcsackett: while the rest is still in progress on the ops side [13:55] jcsackett: so I guess I'm saying even if we hold off on ok'ing this until Monday, it's not like production will be getting combo loader monday anyway [13:55] * jcsackett nods [13:55] rick_h: that's what i needed to know. thanks. :-) === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac , adeuring | Firefighting: - | Critical bugtasks: 4*10^2 === al-maisan is now known as almaisan-away [16:04] jml: if I get a defer.succeed() in a test and add callbacks to it, can I expect them to fire? [16:04] bigjools: yes. they'll generally fire immediately, i.e. before the addCallback call returns. [16:05] jml: ok thanks, then something else is borked in my test, it spins forever :( [16:05] bigjools: http://paste.ubuntu.com/827747/ as a demo [16:06] jml: right, thanks. [16:06] bigjools: generally spinning forever means that the deferred being returned is never fired. [16:07] jml: if I return that deferred to the testtools ... [16:07] hmm that's not it [16:08] bigjools: if you want to paste the test I can have a quick look [16:10] jml: thanks, at the bottom of here: http://pastebin.ubuntu.com/827750/ [16:12] bigjools: test_get_nodes should probably return d. I doubt that would be the cause of the spinning though. [16:12] jml: yeah I just removed it to see if it made any difference [16:13] bigjools: Yeah, it looks like connection.deferred isn't being fired at all. [16:14] bigjools: not enough context in the diff to say much more. [16:14] jml: the whole branch: http://pastebin.ubuntu.com/827757/ [16:15] jml: line 285 is the deferred that is returned [16:16] oh wait [16:16] I'm a twit === salgado is now known as salgado-lunch [16:16] ah no, I'm not (well I am, but not here) [16:17] trippy [16:17] using the connection_factory method definition as a default... [16:19] bigjools: in FakeMaasHTTPConnection, I'd put an addBoth that prints out whatever it's passed and then returns it, just to see if it really is being fired. [16:20] (putting the 'return d' back in the test also) [16:20] ok [16:23] jml: yeah it gets fired [16:23] bigjools: with the JSON you expect? [16:23] yes [16:24] bigjools: and if you remove test_get_nodes you don't get the hanging? [16:25] jml: right [16:25] bigjools: what if you add a print-and-return callback to the thing returned from get_nodes in the test? [16:26] jml: I did that - it shows the value ok, then spins... [16:26] :\ [16:26] something is borked inside testtools perhaps? I am using the package in precise [16:26] bigjools: it's possible. [16:26] * jml tries [16:26] * bigjools tries with trial [16:27] jml: it works in trial [16:28] bigjools: that's a bad sign. :\ [16:28] jml: 'fraid so. [16:29] I'll do a basic test case and see if I can reproduce for a bug report [16:29] jml: hmmm, would it be a problem using the testtools TestCase with the trial runner? [16:30] bigjools: couldn't imagine why [16:30] bigjools: but a basic test case would be great, thanks. [16:40] bigjools: yeah, it looks like a trial / testtools interaction. [16:40] pissbum [16:41] jml: crapola. did you get a basic test case working? [16:42] bigjools: working with testtools.run but hanging with trial runner. [16:42] ok [16:42] bigjools: [16:42] I failed at that [16:42] bigjools: http://paste.ubuntu.com/827787/ [16:42] bigjools: that's it. [16:42] ! [16:42] $ trial istesttoolsbuggy [16:43] $ python -m testtools.run istesttoolsbuggy [16:43] shag [16:43] after saving to istesttoolsbuggy.py [16:45] well, I guess this trumps what I was doing [16:45] will try to fix. [16:45] ah I reproduced it now [16:45] jml: did you file a bug already? I'd like to reference it (or I can file it for you) [16:46] beware that it eats swap, so it's not just spinning [16:46] bigjools: yeah, it's calling addObserver over & over [16:46] (trial --spew ftw) [16:46] ah ok [16:47] bigjools: I haven't filed a bug, no. Would appreciate it if you could. [16:47] sure thing [16:47] bigjools: thanks [16:49] jml: https://bugs.launchpad.net/testtools/+bug/926189 [16:49] <_mup_> Bug #926189: Using the Trial test runner results in a spinning test < https://launchpad.net/bugs/926189 > [16:51] adeuring: abentley you guys know what this hwdb thing is that is being asked about in #lp? https://launchpad.net/+hwdb/+fingerprint/edda5d4f616ca792bf437989cb597002 [16:52] rick_h: Not me. I've heard of it, but couldn't describe it. [16:52] rick_h: I'm looking [17:17] bigjools: I've narrowed it down a bit. It's something to do with the interaction between trial's LoggedSuite and testtools run_with_log_observers [17:17] jml: cool, at least you are getting somewhere [17:17] bigjools: which kind of makes sense, since both are designed to do the same thing (catch logged errors and make sure they are turned into test errors) === salgado-lunch is now known as salgado === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 4*10^2 [17:51] bigjools: http://paste.ubuntu.com/827841/ <- the fix [17:51] bigjools: very embarrassing. [17:51] jml: :D [17:52] jml: if that can make it into precise I'd be very happy [17:52] bigjools: me too [17:52] grap [17:52] when's feature freeze? [17:52] does that matter for this? [17:52] 'tis a nasty bug [17:53] it's easier if I can just (ask jelmer to) upload the latest release [18:04] jelmer, lifeless: https://code.launchpad.net/~jml/testtools/trial-hang/+merge/91470 [18:04] otherwise I'll land sometime tomrrow. [18:04] Have to go now [18:04] Have a great weekend all. [18:11] cheers jml [19:27] gary_poster: I have gotten to the bottom of the test_mlist_sync failures. They happen because we end up running python 2.7 with a pythonpath suitable for python2.6. [19:28] gary_poster: Do you have any suggestions for how to ensure we run the script with the correct python interpreter? [19:28] abentley, I am guessing you are referring to the canonistack thread. I haven't followed those details closely enough to know the exact test of which you speak. Where do I find the script in the tree? I'll try looking... [19:29] gary_poster: scripts/mlist-sync.py [19:29] ack abentley looking [19:30] gary_poster: The tests are in ./lib/lp/services/mailman/tests/test_mlist_sync.py and specify python path, but not python interpreter. [19:30] abentley, this is on precise, I assume? [19:30] gary_poster: No, oneiric. I'm waiting for beta. [19:31] ah ok [19:33] gary_poster: I think Precise will have the same issue, though. Basically, ssl.py imports symbols defined in libpython.*.so, and at least one symbol defined in 2.6 is not defined in 2.7 [19:33] abentley, well, one thought is to simply specify pthon2.6 in the shebang. That's the kind of thing we've done before for this kind of transition period. Maybe we could instead use /usr/bin/env [path to bin/py] in the #! line, and move the script to the buildout template location. That would probably work just fine, and it would work whether you were on 2.6 or 2.7.. [19:34] but /usr/bin/python2.6 was our approach in the past. [19:35] The template location could even put the output back in utilities if so desired [19:35] gary_poster: I'm more of a mind to fix the invocation; I think it's broken to specify a python path and not specify the python interpreter. [19:35] You'd just want to clarify in the code that the actual location was in the template directory, so don't change it in situ [19:36] abentley, bin/py, either explictly or in the shebang, is the only way I know to do that. It also sets the path using that approach [19:37] gary_poster: I mean to fix the call site, i.e. ./lib/lp/services/mailman/tests/test_mlist_sync.py [19:39] gary_poster: But I guess if we moved it to the template, we could stop specifying the pythonpath in the call site. That would be even better. [19:41] abentley, template, right, that's one of the advantages. I think it also gives you a way to specify the python that LP is currently using, and substitute that in the shebang, rather than bin/py. We do that now IIRC. Alternatively, looking at the call site, I suppose you could change the script to use /usr/bin/env python as the shebang, and then manipulate the PATH so that the Python you want is first in your invo [19:41] cation. But I do think that the template is better. Lemme see if there is an example already... [19:43] abentley, buildout-templates/bin/bzr.in shows one way--the way we've done it so far [19:44] The first 10 lines (! :-( ) would be boilerplate that you would put at the top [19:44] gary_poster: cool. [19:44] you could make a utilities directory in buildout-templates and it would copy it over in utilities, or make the script go in bin like the other templates we have now. [19:45] bin is already bzr ignored [19:45] in its entirety [19:45] so if you put it in utilities you might want to explicitly bzr ignore the output [19:49] gary_poster: any reason not to keep it in "scripts"? [19:50] oh, abentley, no I was just not being detail oriented. s/utilities/scripts/ in what I said [19:51] gary_poster: cool. I think I've got the buildout side working. [19:51] great [19:53] gary_poster: tests passing, no PYTHONPATH needed anymore. [19:53] gary_poster: Thanks for the help. [19:53] awesome abentley [19:53] welcome [20:09] gary_poster: seems like buildout should have a "clean" command that deletes the artifacts it would otherwise create. [20:09] abentley, yeah, that's been said for years. It has the info to do it. No such command exists. [21:02] bac: Could you please review https://code.launchpad.net/~abentley/launchpad/stable-test-failures/+merge/91504 ? [21:03] abentley: :) [21:03] abentley: you're late [21:03] abentley: can it wait just a while? i'm in a call with gary atm. [21:04] bac: Sure. [21:04] abentley: no, i'll do it now. short and testfix. [21:10] bac: Thanks. [21:11] abentley: np === ]reed[ is now known as [reed] === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away