[00:03] thumper: wgrant: standup? [00:03] yeah, I have a few minutes [00:04] Project devel build #655: STILL FAILING in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/655/ [00:24] Anyone looking at the buildbot failure? [00:52] wgrant: looking now. been fighting with recordmydesktop this morning :-( [00:53] wallyworld: I've just pushed. [00:53] So don't worry about it. [00:53] wgrant: ok. what was the issue? [00:55] wallyworld: The check_permission changes in security.py. EditStructuralSubscription now relies on launchpad.Edit being defined for all IStructuralSubscriptionTargets. [00:55] It was not defined for DistributionSourcePackage. [00:55] ack. thanks [00:58] yay side effects [01:01] is anyone available to look at https://code.launchpad.net/~jcsackett/launchpad/bug-expiration-doesnt-oops/+merge/58412? [01:02] hi all [01:02] re bug 766149\ [01:02] <_mup_> Bug #766149: bzr from daily ppa blocks python 2.6 install on natty using site-packages < https://launchpad.net/bugs/766149 > [01:02] is this just deryck trying something, or is lp as a whole planning to move to natty before you move to py2.7? [01:04] poolie: LP doesn't quite run on 2.7 yet, so it's hardcoded to 2.6 for devs who are running natty. [01:04] poolie: company policy - we should all be running natty around now. [01:04] (eg. me) [01:05] poolie: but lp /cannot/ move to py2.7 until its backported to lucid and so on. [01:06] well, company policy would not (aiui) prevent you running lp in a chroot [01:06] poolie: No, but there's very little reason to. [01:06] poolie: Given that it works fine on natty. [01:06] (mostly) [01:06] :) [01:06] I do my dev in a lucid vm fwiw [01:07] shall we update https://dev.launchpad.net/Running then? [01:07] but thats different tradeoffs to in-place, and higher friction in some ways [01:07] poolie: It's not completely tested, but maybe. [01:09] anyhow, i don't mind, i just had not heard of anyone running natively on natty yet [01:09] if everyone was going to switch that bug would be a bit more urgent [01:10] I'd expect a rash of migrations in the next week or two [01:10] poolie: I've been running since November or so. [01:10] Without much trouble in recent months. [01:29] * wallyworld___ heads off to dentist with laptop and 3g modem. who knows how long i'll be stuck in the waiting room :-/ === wallyworld___ is now known as wallyworld [02:24] poolie: huwshimi: http://people.canonical.com/~ianb/filebug.ogv ps. browser back button also works [02:26] you legend [02:27] poolie: assignee picker also works on Chrome :-) [02:27] is this by having the fields statically present but hidden? [02:27] poolie: i think the fading of the details entry fields works ok. full rational in partially completed mp https://code.launchpad.net/~wallyworld/launchpad/filebug-loses-data/+merge/58410 [02:28] poolie: essentially yes [02:28] yes [02:28] choirs of angels sing thee to thy rest [02:28] * wallyworld_ now has to write js and windmill tests that won't be run anyway :-( [02:29] poolie: there's a lot of duplicate bugs filed about this one :-) [02:29] poolie: plus xss holes that will be plugged [02:39] * wallyworld_ goes to climb onto dentist chair. yeow :-( [02:52] 39 / 6 RootObject:+login [02:52] >< what now [02:52] Perhaps our friendly chæ doesn't have SSO access. [02:53] Hmm. [02:53] No, various prefixes. [02:53] Possibly traversal + locks. [02:53] DS, AU, CP [02:53] wut [02:54] prefixes [02:54] https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1935DS606 [02:54] Yes. [02:54] But look at the OOPS. [02:54] I blame SSO. [02:54] 10059ms gap. [02:54] we have missing instrumentation [02:54] do we make *http* calls to SSO ? [02:54] Yes. [02:54] okies [02:54] a) exception time [02:54] Right in that location, too. [02:54] and b) critical bug on sso time. [02:55] Well, no, it's probably an issue on our end. [02:55] But it's with the request to SSO. [02:55] and c) instrumentation [02:55] wgrant: nah, login is /slow/ [02:55] I've been suspecting it for weeks [02:55] but had nodata [03:04] :( dapper [03:07] oh [03:08] and we need to qa to unbreak bug assignment etc [03:08] lifeless: https://code.launchpad.net/~thumper/lazr.enum/release-1.1.3/+merge/58420 [03:08] lifeless: then I'll make a lazr.enum release [03:08] add it to our download cache [03:08] and fix the bug [03:09] lifeless: can you upload to pypi? [03:09] I don't think I can [03:09] thumper: its per-project [03:09] thumper: any of the existing uploaders can add you [03:09] hmm... [03:09] I wonder who it is [03:10] login to pypi, it will show you [03:11] * thumper should get a pypi login [03:11] thumper: you can use openid [03:11] You don't even need to log in. [03:11] * thumper is using openin [03:11] thumper: does lazr.enum already have the changes needed ? [03:11] openid even [03:11] lifeless: yes [03:11] in the last trunk revision [03:11] lifeless has privs. [03:11] thumper: this is most *definitely* a self review case [03:12] :) [03:12] oh I do, how about that. [03:12] hah, 1.1.1 [03:12] I'm so glad we keep it up to date [03:13] thumper: don't add it to the download cache, I'll get a tarball out as a result of doing sdist upload --signed [03:13] thumper: otherwise we'll have different tarballs and thats just a nuisance [03:14] Package Index Owner: barry, gary, flacoste, leonard, lifeless [03:14] lifeless: do you want to add me on [03:14] Having different tarballs is justification for homicide by distribution engineers. [03:14] and I can upload it? [03:14] sure [03:14] I'm thumper on pypi too [03:16] ok, you have owner on all the lazr.* things I have owner on [03:16] use it well [03:17] oh ffs [03:17] SMTPError: SMTP error: 552 5.2.3 Your message exceeded Google's message size limits. Please visit [03:17] 5.2.3 http://mail.google.com/support/bin/answer.py?answer=8770 to review [03:17] 5.2.3 our size guidelines. e37sm215844vbm.5 [03:17] lifeless: yeah, saw that, thanks [03:17] I really *must* finish the subunit post stuff for lp [03:17] lifeless: also... can sdist do the pypi upload too? [03:18] you change them togeter [03:18] sdist upload --signed [03:18] IIRC [03:18] s/change/chain/ [03:18] ack [03:18] * thumper tries [03:24] :( [03:24] lifeless: how do identify with pypi from the command line? [03:24] for sdist upload? [03:25] cat ~/.pypirc [03:25] [server-login] [03:25] username:lifeless [03:25] password: [03:25] um... I don't have a password though, I use openid [03:25] I could add one I suppose [03:26] I don't know how to do it for openid [03:27] there are good docs around that I read before openid was added, I suspec they have been upgraded [03:28] I just added a password to my account [03:28] all is good [03:28] 1.1.3 on pypi now [04:27] ok, opinions please [04:28] should the request timeline flatten recursive actions into a pair of start/stop actions automaticlaly [04:28] or only when the might-nest action has indicated this is expected [04:28] the latter seems more robust to me if a little more thought required to use. [05:09] can has review? https://code.launchpad.net/~lifeless/launchpad/bug-766786/+merge/58430 [05:12] lifeless: Broadly okay, I'm a little unsure why a bunch of your tests don't seem to test anything [05:16] StevenK: they run code which before the change will break [05:16] StevenK: thats a test [05:17] the idea that a test needs an assert in it is a cruel meme perpetuated on the unwary [05:18] lifeless: Okay, fine. r=me [05:18] thanks! [05:48] lifeless: "the idea that a test needs an assert in it is a cruel meme perpetuated on the unwary" <== brief expansion on the why? for personal curiosity/learning than anything profound. [05:49] so the argument is that a test case has to make an assert or its not making a statement about any particular thing being expected/not expected [05:49] related to this there is an argument that a test case should make one and only one assertion [05:49] right [05:50] now, the latter is more easily shown to be nuts, if you compare the LOC (and relatedly clarity) to curry a multi-attribute assertion vs 2 or 3 separate assertions [05:50] its a spectrum, *sometimes* good sometimes bad. [05:51] with the latter disposed of - we have merely to cover the what about 0 case? [05:51] perhaps one of those, here's the rule, so you think about it when you break it, cases? [05:51] and for that, we go back to basics: [05:51] StevenK: Bug #746376 needs QA. [05:51] <_mup_> Bug #746376: When DSD is created it needs to check for existing packagediff and set DSD diff properties

< https://launchpad.net/bugs/746376 > [05:51] - tests exist to help us deliver fit for purpose code [05:52] - if it helps with that, great. And we should aim for clear expression of whatever thing we want to ensure does/does not happen [05:52] wallyworld: That screencast looks good. [05:53] - one aspect of clarity is checking for a single -conceptual- issue in a test case (vs a single 'assertion') because that helps with correcting problems: you can see all the intentions that are violated and fix those. [05:54] spm: and thus, if being able to run code that you couldn't before is a useful thing to be able to do, it can be a test in and of itself. [05:54] spm: in C i would have written those tests with assertions [05:54] wgrant: Indeed, I've been mulling how to do that while working on another branch [05:54] because C doesn't have exceptions, I would have had to be returning error values. [05:54] spm: and I'd want to know that it hadn't errored; in python it will throw for me, so the test is simpler. [05:54] StevenK: It's fairly safe and the code doesn't run in prod yet, so qa-untestable is reasonable. [05:55] lifeless: right. and that's where I've typically come from with the very little unit testing I've done. if I plug in this value do I get back the desired answer. [05:55] spm: right; and thats exactly this case - plug in some code, desired answer is a lack of exceptions. [05:55] I think the point you make about conceptual issue testing, is a powerful one. [05:55] spm: its a rule of thumb again though :) [05:55] wgrant: Done. [05:56] tricky, but powerful. [05:59] huwshimi: cool. i'm fixing the tests which broke due to the different html and writing new ones [06:02] hmm [06:02] 'cve reports' should really be in the bug count portlet [06:02] Anyone getting "ImportError: No module named nestingtimedaction" on 'make schema'? [06:02] not inthe 'configure this product for bugs' portlet. [06:02] hahha I suck. [06:03] huwshimi: don't use my last landing. [06:04] I failed to add the new files. [06:05] lifeless: Are you going to land a fix soon or should I revert? [06:05] its landing now [06:05] lifeless: Ah sweet. I'll wait. Thanks [06:18] mwhudson: hey [06:18] lifeless: fyi bug 766757 was filed after a discussion with james [06:18] <_mup_> Bug #766757: creating mps for collisions isn't helpful < https://launchpad.net/bugs/766757 > [06:18] mwhudson: is canonical.launchpad.webapp.login.CookieLogoutPage your beastie ? [06:18] as what seemed like the most likely string to pull on [06:18] poolie: coolio [06:18] it is obviously not the full solution [06:19] poolie: I was (wrongly) concerned then :) [06:20] np, i probably should have said i'd spoken to him [06:21] you can see why i am concerned by some part-of-the-picture lp bugs :) [06:21] naturally [06:21] sorry if I caused any confusion or noise on the bug [06:23] no problem at all [06:23] i appreciate your interest [06:23] just letting you know [06:23] thanks [06:23] I do trust that you know the domain [06:24] not as well as i would like :/ [06:24] I guess I feel that there is stuff possibly missing given the previously distro heavy design [06:24] poolie: I'll keep commenting on such things then :) [06:24] "previously distro heavy design" meaning what? [06:24] \o/ 1-character bugfixes [06:25] poolie: well a lot of the design about how it should work was just done by doing + small conversations here and there amongst distro folk (which I count myself as for this purpose) [06:25] it was often written up into mail or wiki but not always [06:25] and it was spread over several years [06:26] so its hard to have a cohesive hold of all of the bits :) [06:27] ah yes [06:28] can has review? https://code.launchpad.net/~lifeless/launchpad/bug-112776/+merge/58434 [06:29] lifeless: I guess that's OK now, since we end up at the OpenID provider anyway? [06:29] Previously it was meant to return you to the current page, logged out. [06:29] makes sense to me too [06:29] wgrant: right [06:29] now we redirect to bazaar.launchpad.net [06:29] and from there to the openid sso [06:29] that's a pretty popular bug [06:29] Yup. [06:30] (ew) [06:30] StevenK: Could you mentor? [06:30] Terribly difficult. [06:30] Project windmill build #193: STILL FAILING in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/193/ [06:30] lifeless: Only if you promise you didn't miss any files this time [06:30] i wanted to have a beer-type conversation with you about testing sometime [06:30] StevenK: I make no such promises [06:30] i was noticing some of bzr's tests were making things hard to change rather than easier [06:30] no rush though [06:30] poolie: sure [06:30] wgrant: Done [06:31] i think some things we've been doing cause a skew towards tests that depend on internals [06:31] StevenK: Thanks. [06:31] wallyworld: Hi. [06:31] wgrant: 1 min. otp [06:31] sometimes just things that are not strictly internals, but external to a narrow layer [06:31] poolie: I meant, sure, I'd like that too + no rush :) [06:31] wallyworld: Sure. [06:31] anyhow, some other time [06:31] lifeless: Typical :-P [06:32] drop by some time :) [06:32] I have the miles :) [06:33] hmm, actually I wonder if I do on qantas; have to fly every year with them I think; I do on air nz [06:33] every 18m to keep them iirc [06:33] They changed it to 18 months a couple of years ago. [06:33] :( [06:34] Yes, this is a *bug*. [06:34] Probably an effective one, however [06:34] Along with their recent fuel increase. [06:34] I never really saw any validity in a fuel surchage. [06:35] pricing opacity [06:35] And jet fuel is quite expensive [06:35] That's business rationale, not validity :) [06:35] i am so happy with Amaysim because they have simple transparent linear pricing [06:35] wgrant: free now [06:35] none of this 1c/MB for the first 1000, then 100c [06:35] wallyworld: There are two remaining Windmill test failures. [06:36] Yippie, build fixed! [06:36] Project devel build #656: FIXED in 5 hr 24 min: https://lpci.wedontsleep.org/job/devel/656/ [06:36] amaysim ? [06:36] an australian optus mobile reseller [06:36] wgrant: the only ones i saw were due to the picker issue. [06:36] wallyworld: One of them is for inline non-contributor assigning, which works fine AFAICT. [06:36] poolie: ah, I saw the optus thread [06:36] didn't catch the reseller name [06:36] wgrant: i fixed that test a day or 2 ago [06:37] wallyworld: It just failed again a few minutes ago (in db-devel) [06:37] wtf [06:37] https://lpci.wedontsleep.org/job/windmill/193/testReport/junit/lp.bugs.windmill.tests.test_bug_inline_assignment/TestInlineAssignment/test_inline_assignment_non_contributor/ [06:37] https://lpci.wedontsleep.org/job/windmill/193/testReport/junit/lp.translations.windmill.tests.test_sourcepackage_sharing_details/TestSharingDetails/test_set_branch/ also, but that's a bitrotten test that I might try to fix now. [06:37] * StevenK kills gnome-do, hopefully to stop the wrong indicator popups [06:38] wgrant: well, the error message shows the code is as per my fix and it worked fine locally :-( [06:38] :( [06:39] wgrant: i'll get my current work done and then i'll take a look [06:39] wallyworld: Thanks. [06:39] wgrant: just check my email - the picker fix has gone through \o/ [06:39] wallyworld: Yup, and it works. [06:40] Thanks. [06:40] We'll deploy after the next buildout run finishes. [06:40] Since there's another regression fix in there right now. [06:40] wgrant: i'm pissed that i broke it but windmill tests would have caught it :-( it's becoming risky to make js/ui changes without the proper test coverage :-( [06:41] in-process windmill tests as part of ec2 land i mean [06:41] wallyworld: Right. [06:42] wallyworld: I can reproduce the assignment test failure locally, hmm. [06:42] It seems to be legit, but it works on qas. [06:42] wgrant: i'll look into it. it worked locally when i put it up for review etc [06:42] wgrant: maybe something has changed and is affecting it [06:43] wgrant: i've had that happen before. ie worked locally but broke after other stuff got merged in [06:43] wallyworld: I hope that with deryck on maintenance we will soon be able to make progress. [06:43] And get Windmill or its replacement back in soon. [06:43] +1 [06:44] And maybe even get it to work on natty. [06:49] I sure hope someone does bug 80902 soon :) [06:49] <_mup_> Bug #80902: Can't target bug report from project to distribution, or vice versa

< https://launchpad.net/bugs/80902 > [06:49] oldest critical [06:53] wgrant: yeah. still some remaining (weird) ff4 issues to fix for natty [06:55] lifeless: i can look at that one next [06:55] wallyworld: if curtis is cool with it that would rock [06:56] lifeless: i'll convince him :-) [06:56] \o/ [06:56] He was looking at that himself a few weeks ago. [06:57] lifeless: i've been hacking in bugs lately anyway. i'm still far from an expert but i know more than i used to [06:57] wgrant: maybe he has solved it already. well, one can hope :-) [07:00] * wallyworld runs bin/test --layer=BugsWindmillLayer. now to watch my laptop thrash the disk for 30 minutes and acquire lots of zombie processes that refuse to die :-( [07:00] * lifeless hammers staging to its knees [07:00] lifeless: Oh? [07:02] wallyworld: I've hopefully fixed the translations test. [07:02] wgrant: excellent :-) [07:02] wallyworld: I wonder if the bugs one is related to the odd proxying that Windmill does. [07:03] wgrant: not sure. i'm running the tests locally to check for breakages due the to filebug stuff i'm doing [07:03] wgrant: doing an analysis of the error rate for oe [07:03] m [07:03] for bugsummary [07:03] Ah. [07:03] lifeless: Well, staging is down, so you have the whole thing :) [07:19] thumper: Is any QA necessary for your stacking change? [07:19] thumper: Given that we won't be deploying codehosting tonight? [07:20] wallyworld: 'node.one(".no_button") is null' :/ [07:20] But it created the node just there :( [07:21] wgrant: that's the sort of stuff i've been fighting of late with windmill. takes me ages to do something which should be simple. :-( [07:21] wgrant: stacking change? [07:21] lifeless: [r=bac][bug=377519] Change the default stacking location to use the branch id alias. [07:22] wallyworld: Ah, it helps if I test in the right browser. [07:22] wgrant: you mean it's broken in ff4? [07:22] Reproducible outside Windmill in Firefox *3*. [07:22] wgrant: what rev? [07:22] wgrant: yes [07:23] wgrant: it is xmlrpc [07:23] thumper: I thought we were not going to land that till poolie acked it works ok with bzr ? [07:23] so it'll be live [07:23] wgrant: but works in ff4? [07:23] lifeless: r12874, in buildbot now. [07:23] lifeless: I've qa'ed it to my satisfaction [07:23] lifeless: Ahead of the bugmail fix. [07:23] thumper: I'd like poolies ack [07:23] thumper: he has expressed nervousness about this [07:23] wallyworld: Not sure. [07:23] sure [07:23] thumper: its the least we can do [07:23] wallyworld: I think so, though... [07:23] wgrant: this all just makes me sad :-( [07:24] poolie: has your team tested the id based stacking by hand yet ? [07:24] wallyworld: Ja. [07:24] wallyworld: We really need to get cross-browser Windmill working.. [07:24] wgrant: yep. i'd be happy if *one* browser worked reliably [07:24] Grumble. [07:27] Huh. [07:27] It creates yes_button, but not no_button. [07:27] I wonder if FF 3 disagrees with self-closing buttons. [07:28] Chromium disagrees with self-closing divs, I know. [07:28] Yup, that's it. [07:28] Web, I hate you. [07:28] * wallyworld cries [07:29] Anyway, both fixed now. [07:29] * wgrant lands. [07:29] wgrant: what was the fix? [07:29] - '', [07:29] + '', [07:29] Yes, seriously. [07:30] wgrant: wtf. i'm stunned [07:30] That works fine in Chromium and Firefox 4, but Firefox 3 chokes if you self-close the button. [07:30] Chromium goes crazy if you don't close a div. [07:30] Does type="button" /> work? [07:30] StevenK: I fucking hope not. [07:30] But possible. [07:30] * wgrant tries. [07:30] Haha [07:32] Fortunately not. [07:39] lifeless: it has not broken but i have not manually tested it by renaming branches etc [07:40] but i guess you have already done that [07:50] wallyworld: https://code.launchpad.net/~wgrant/launchpad/translations-windmill-testfix/+merge/58441 [07:50] Now that the spurious failures seem to have disappeared when running only WindmillLayer, I guess we should try to keep Jenkins' Windmill builder green. [07:51] * wallyworld looks [07:51] wgrant: too bad we can't hook jenkins into ec2 and [07:51] land [07:51] I'd like to [07:52] StevenK: jenkins seems more reliable at running wm tests? [07:52] wallyworld: Only when in a separate job. [07:52] When running in the main job it's just as unreliable. [07:52] (which is extremely interesting, yes) [07:53] wgrant: so why don't we run the wm tests isolated in ec2? [07:53] wallyworld: Because nobody has done that yet, and I didn't believe this could be the case until recently. [07:53] But it has held true for a month or so now. [07:53] So it may be a good thing to try. [07:53] Not sure quite how easy it will be, though. [07:53] yep [07:54] StevenK: wgrant: can we get jenkins to run the yui test layer too? [07:54] now that it is separate [07:54] wallyworld: Good point. [07:54] StevenK: Could you make it run YUITestLayer too? [07:54] --layer=(WindmillLayer|YUITestLayer) should do it, I think. [07:55] yep [07:55] Yeah, that works. [07:55] I was wondering about that [07:56] sudo -u hudson -H make TESTOPTS="--subunit --layer=(WindmillLayer|YUITestLayer)" check | subunit2junitxml -f -o test-results.xml [07:56] Should work. [07:56]