[00:03] <wallyworld> thumper: wgrant: standup?
[00:03] <thumper> yeah, I have a few minutes
[00:04] <LPCIBot> Project devel build #655: STILL FAILING in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/655/
[00:24] <wgrant> Anyone looking at the buildbot failure?
[00:52] <wallyworld> wgrant: looking now. been fighting with recordmydesktop this morning :-(
[00:53] <wgrant> wallyworld: I've just pushed.
[00:53] <wgrant> So don't worry about it.
[00:53] <wallyworld> wgrant: ok. what was the issue?
[00:55] <wgrant> wallyworld: The check_permission changes in security.py. EditStructuralSubscription now relies on launchpad.Edit being defined for all IStructuralSubscriptionTargets.
[00:55] <wgrant> It was not defined for DistributionSourcePackage.
[00:55] <wallyworld> ack. thanks
[00:58] <lifeless> yay side effects
[01:01] <jcsackett> is anyone available to look at https://code.launchpad.net/~jcsackett/launchpad/bug-expiration-doesnt-oops/+merge/58412?
[01:02] <poolie> hi all
[01:02] <poolie> re bug 766149\
[01:02] <_mup_> Bug #766149: bzr from daily ppa blocks python 2.6 install on natty using site-packages <packaging> <Bazaar:Confirmed> <bzr (Ubuntu):Invalid> < https://launchpad.net/bugs/766149 >
[01:02] <poolie> 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] <wgrant> 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] <lifeless> poolie: company policy - we should all be running natty around now.
[01:04] <wgrant> (eg. me)
[01:05] <lifeless> poolie: but lp /cannot/ move to py2.7 until its backported to lucid and so on.
[01:06] <poolie> well, company policy would not (aiui) prevent you running lp in a chroot
[01:06] <wgrant> poolie: No, but there's very little reason to.
[01:06] <wgrant> poolie: Given that it works fine on natty.
[01:06] <wgrant> (mostly)
[01:06] <poolie> :)
[01:06] <lifeless> I do my dev in a lucid vm fwiw
[01:07] <poolie> shall we update https://dev.launchpad.net/Running then?
[01:07] <lifeless> but thats different tradeoffs to in-place, and higher friction in some ways
[01:07] <wgrant> poolie: It's not completely tested, but maybe.
[01:09] <poolie> anyhow, i don't mind, i just had not heard of anyone running natively on natty yet
[01:09] <poolie> if everyone was going to switch that bug would be a bit more urgent
[01:10] <lifeless> I'd expect a rash of migrations in the next week or two
[01:10] <wgrant> poolie: I've been running since November or so.
[01:10] <wgrant> 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 :-/
[02:24] <wallyworld_> poolie: huwshimi: http://people.canonical.com/~ianb/filebug.ogv    ps. browser back button also works
[02:26] <poolie> you legend
[02:27] <wallyworld_> poolie: assignee picker also works on Chrome :-)
[02:27] <poolie> is this by having the fields statically present but hidden?
[02:27] <wallyworld_> 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] <wallyworld_> poolie: essentially yes
[02:28] <poolie> yes
[02:28] <poolie> 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] <wallyworld_> poolie: there's a lot of duplicate bugs filed about this one :-)
[02:29] <wallyworld_> poolie: plus xss holes that will be plugged
[02:39]  * wallyworld_ goes to climb onto dentist chair. yeow :-(
[02:52] <lifeless> 39 /    6  RootObject:+login
[02:52] <lifeless> >< what now
[02:52] <wgrant> Perhaps our friendly chæ doesn't have SSO access.
[02:53] <wgrant> Hmm.
[02:53] <wgrant> No, various prefixes.
[02:53] <wgrant> Possibly traversal + locks.
[02:53] <lifeless> DS, AU, CP
[02:53] <wgrant> wut
[02:54] <lifeless> prefixes
[02:54] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1935DS606
[02:54] <wgrant> Yes.
[02:54] <wgrant> But look at the OOPS.
[02:54] <wgrant> I blame SSO.
[02:54] <wgrant> 10059ms gap.
[02:54] <lifeless> we have missing instrumentation
[02:54] <lifeless> do we make *http* calls to SSO ?
[02:54] <wgrant> Yes.
[02:54] <lifeless> okies
[02:54] <lifeless> a) exception time
[02:54] <wgrant> Right in that location, too.
[02:54] <lifeless> and b) critical bug on sso time.
[02:55] <wgrant> Well, no, it's probably an issue on our end.
[02:55] <wgrant> But it's with the request to SSO.
[02:55] <lifeless> and c) instrumentation
[02:55] <lifeless> wgrant: nah, login is /slow/
[02:55] <lifeless> I've been suspecting it for weeks
[02:55] <lifeless> but had nodata
[03:04] <wgrant> :( dapper
[03:07] <lifeless> oh
[03:08] <lifeless> and we need to qa to unbreak bug assignment etc
[03:08] <thumper> lifeless: https://code.launchpad.net/~thumper/lazr.enum/release-1.1.3/+merge/58420
[03:08] <thumper> lifeless: then I'll make a lazr.enum release
[03:08] <thumper> add it to our download cache
[03:08] <thumper> and fix the bug
[03:09] <thumper> lifeless: can you upload to pypi?
[03:09] <thumper> I don't think I can
[03:09] <lifeless> thumper: its per-project
[03:09] <lifeless> thumper: any of the existing uploaders can add you
[03:09] <thumper> hmm...
[03:09] <thumper> I wonder who it is
[03:10] <lifeless> login to pypi, it will show you
[03:11]  * thumper should get a pypi login
[03:11] <lifeless> thumper: you can use openid
[03:11] <wgrant> You don't even need to log in.
[03:11]  * thumper is using openin
[03:11] <lifeless> thumper: does lazr.enum already have the changes needed ?
[03:11] <thumper> openid even
[03:11] <thumper> lifeless: yes
[03:11] <thumper> in the last trunk revision
[03:11] <wgrant> lifeless has privs.
[03:11] <lifeless> thumper: this is most *definitely* a self review case
[03:12] <thumper> :)
[03:12] <lifeless> oh I do, how about that.
[03:12] <lifeless> hah, 1.1.1
[03:12] <lifeless> I'm so glad we keep it up to date
[03:13] <lifeless> 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] <lifeless> thumper: otherwise we'll have different tarballs and thats just a nuisance
[03:14] <thumper> Package Index Owner: barry, gary, flacoste, leonard, lifeless
[03:14] <thumper> lifeless: do you want to add me on
[03:14] <wgrant> Having different tarballs is justification for homicide by distribution engineers.
[03:14] <thumper> and I can upload it?
[03:14] <lifeless> sure
[03:14] <thumper> I'm thumper on pypi too
[03:16] <lifeless> ok, you have owner on all the lazr.* things I have owner on
[03:16] <lifeless> use it well
[03:17] <lifeless> oh ffs
[03:17] <lifeless> SMTPError: SMTP error: 552 5.2.3 Your message exceeded Google's message size limits. Please visit
[03:17] <lifeless> 5.2.3 http://mail.google.com/support/bin/answer.py?answer=8770 to review
[03:17] <lifeless> 5.2.3 our size guidelines. e37sm215844vbm.5
[03:17] <thumper> lifeless: yeah, saw that, thanks
[03:17] <lifeless> I really *must* finish the subunit post stuff for lp
[03:17] <thumper> lifeless: also... can sdist do the pypi upload too?
[03:18] <lifeless> you change them togeter
[03:18] <lifeless> sdist upload --signed
[03:18] <lifeless> IIRC
[03:18] <lifeless> s/change/chain/
[03:18] <thumper> ack
[03:18]  * thumper tries
[03:24] <thumper> :(
[03:24] <thumper> lifeless: how do identify with pypi from the command line?
[03:24] <thumper> for sdist upload?
[03:25] <lifeless> cat ~/.pypirc
[03:25] <lifeless> [server-login]
[03:25] <lifeless> username:lifeless
[03:25] <lifeless> password:
[03:25] <thumper> um... I don't have a password though, I use openid
[03:25] <thumper> I could add one I suppose
[03:26] <lifeless> I don't know how to do it for openid
[03:27] <lifeless> there are good docs around that I read before openid was added, I suspec they have been upgraded
[03:28] <thumper> I just added a password to my account
[03:28] <thumper> all is good
[03:28] <thumper> 1.1.3 on pypi now
[04:27] <lifeless> ok, opinions please
[04:28] <lifeless> should the request timeline flatten recursive actions into a pair of start/stop actions automaticlaly
[04:28] <lifeless> or only when the might-nest action has indicated this is expected
[04:28] <lifeless> the latter seems more robust to me if a little more thought required to use.
[05:09] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-766786/+merge/58430
[05:12] <StevenK> lifeless: Broadly okay, I'm a little unsure why a bunch of your tests don't seem to test anything
[05:16] <lifeless> StevenK: they run code which before the change will break
[05:16] <lifeless> StevenK: thats a test
[05:17] <lifeless> the idea that a test needs an assert in it is a cruel meme perpetuated on the unwary
[05:18] <StevenK> lifeless: Okay, fine. r=me
[05:18] <lifeless> thanks!
[05:48] <spm> 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] <lifeless> 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] <lifeless> related to this there is an argument that a test case should make one and only one assertion
[05:49] <spm> right
[05:50] <lifeless> 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] <lifeless> its a spectrum, *sometimes* good sometimes bad.
[05:51] <lifeless> with the latter disposed of - we have merely to cover the what about 0 case?
[05:51] <spm> perhaps one of those, here's the rule, so you think about it when you break it, cases?
[05:51] <lifeless> and for that, we go back to basics:
[05:51] <wgrant> 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 <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/746376 >
[05:51] <lifeless>  - tests exist to help us deliver fit for purpose code
[05:52] <lifeless>  - 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] <huwshimi> wallyworld: That screencast looks good.
[05:53] <lifeless>  - 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] <lifeless> 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] <lifeless> spm: in C i would have written those tests with assertions
[05:54] <StevenK> wgrant: Indeed, I've been mulling how to do that while working on another branch
[05:54] <lifeless> because C doesn't have exceptions, I would have had to be returning error values.
[05:54] <lifeless> 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] <wgrant> StevenK: It's fairly safe and the code doesn't run in prod yet, so qa-untestable is reasonable.
[05:55] <spm> 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] <lifeless> spm: right; and thats exactly this case - plug in some code, desired answer is a lack of exceptions.
[05:55] <spm> I think the point you make about conceptual issue testing, is a powerful one.
[05:55] <lifeless> spm: its a rule of thumb again though :)
[05:55] <StevenK> wgrant: Done.
[05:56] <spm> tricky, but powerful.
[05:59] <wallyworld> huwshimi: cool. i'm fixing the tests which broke due to the different html and writing new ones
[06:02] <lifeless> hmm
[06:02] <lifeless> 'cve reports' should really be in the bug count portlet
[06:02] <huwshimi> Anyone getting "ImportError: No module named nestingtimedaction" on 'make schema'?
[06:02] <lifeless> not inthe 'configure this product for bugs' portlet.
[06:02] <lifeless> hahha I suck.
[06:03] <lifeless> huwshimi: don't use my last landing.
[06:04] <lifeless> I failed to add the new files.
[06:05] <huwshimi> lifeless: Are you going to land a fix soon or should I revert?
[06:05] <lifeless> its landing now
[06:05] <huwshimi> lifeless: Ah sweet. I'll wait. Thanks
[06:18] <lifeless> mwhudson: hey
[06:18] <poolie> lifeless: fyi bug 766757 was filed after a discussion with james
[06:18] <_mup_> Bug #766757: creating mps for collisions isn't helpful <canonical-bazaar> <Ubuntu Distributed Development:Confirmed for canonical-bazaar> < https://launchpad.net/bugs/766757 >
[06:18] <lifeless> mwhudson: is canonical.launchpad.webapp.login.CookieLogoutPage your beastie ?
[06:18] <poolie> as what seemed like the most likely string to pull on
[06:18] <lifeless> poolie: coolio
[06:18] <poolie> it is obviously not the full solution
[06:19] <lifeless> poolie: I was (wrongly) concerned then :)
[06:20] <poolie> np, i probably should have said i'd spoken to him
[06:21] <poolie> you can see why i am concerned by some part-of-the-picture lp bugs :)
[06:21] <lifeless> naturally
[06:21] <lifeless> sorry if I caused any confusion or noise on the bug
[06:23] <poolie> no problem at all
[06:23] <poolie> i appreciate your interest
[06:23] <poolie> just letting you know
[06:23] <lifeless> thanks
[06:23] <lifeless> I do trust that you know the domain
[06:24] <poolie> not as well as i would like :/
[06:24] <lifeless> I guess I feel that there is stuff possibly missing given the previously distro heavy design
[06:24] <lifeless> poolie: I'll keep commenting on such things then :)
[06:24] <poolie> "previously distro heavy design" meaning what?
[06:24] <lifeless> \o/ 1-character bugfixes
[06:25] <lifeless> 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] <lifeless> it was often written up into mail or wiki but not always
[06:25] <lifeless> and it was spread over several years
[06:26] <lifeless> so its hard to have a cohesive hold of all of the bits :)
[06:27] <poolie> ah yes
[06:28] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-112776/+merge/58434
[06:29] <wgrant> lifeless: I guess that's OK now, since we end up at the OpenID provider anyway?
[06:29] <wgrant> Previously it was meant to return you to the current page, logged out.
[06:29] <poolie> makes sense to me too
[06:29] <lifeless> wgrant: right
[06:29] <lifeless> now we redirect to bazaar.launchpad.net
[06:29] <lifeless> and from there to the openid sso
[06:29] <poolie> that's a pretty popular bug
[06:29] <wgrant> Yup.
[06:30] <wgrant> (ew)
[06:30] <wgrant> StevenK: Could you mentor?
[06:30] <wgrant> Terribly difficult.
[06:30] <LPCIBot> Project windmill build #193: STILL FAILING in 1 hr 2 min: https://lpci.wedontsleep.org/job/windmill/193/
[06:30] <StevenK> lifeless: Only if you promise you didn't miss any files this time
[06:30] <poolie> i wanted to have a beer-type conversation with you about testing sometime
[06:30] <lifeless> StevenK: I make no such promises
[06:30] <poolie> i was noticing some of bzr's tests were making things hard to change rather than easier
[06:30] <poolie> no rush though
[06:30] <lifeless> poolie: sure
[06:30] <StevenK> wgrant: Done
[06:31] <poolie> i think some things we've been doing cause a skew towards tests that depend on internals
[06:31] <wgrant> StevenK: Thanks.
[06:31] <wgrant> wallyworld: Hi.
[06:31] <wallyworld> wgrant: 1 min. otp
[06:31] <poolie> sometimes just things that are not strictly internals, but external to a narrow layer
[06:31] <lifeless> poolie: I meant, sure, I'd like that too + no rush :)
[06:31] <wgrant> wallyworld: Sure.
[06:31] <poolie> anyhow, some other time
[06:31] <StevenK> lifeless: Typical :-P
[06:32] <poolie> drop by some time :)
[06:32] <lifeless> I have the miles :)
[06:33] <lifeless> 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] <poolie> every 18m to keep them iirc
[06:33] <wgrant> They changed it to 18 months a couple of years ago.
[06:33] <wgrant> :(
[06:34] <StevenK> Yes, this is a *bug*.
[06:34] <wgrant> Probably an effective one, however
[06:34] <StevenK> Along with their recent fuel increase.
[06:34] <wgrant> I never really saw any validity in a fuel surchage.
[06:35] <poolie> pricing opacity
[06:35] <StevenK> And jet fuel is quite expensive
[06:35] <wgrant> That's business rationale, not validity :)
[06:35] <poolie> i am so happy with Amaysim because they have simple transparent linear pricing
[06:35] <wallyworld> wgrant: free now
[06:35] <poolie> none of this 1c/MB for the first 1000, then 100c
[06:35] <wgrant> wallyworld: There are two remaining Windmill test failures.
[06:36] <LPCIBot> Yippie, build fixed!
[06:36] <LPCIBot> Project devel build #656: FIXED in 5 hr 24 min: https://lpci.wedontsleep.org/job/devel/656/
[06:36] <lifeless> amaysim ?
[06:36] <poolie> an australian optus mobile reseller
[06:36] <wallyworld> wgrant: the only ones i saw were due to the picker issue.
[06:36] <wgrant> wallyworld: One of them is for inline non-contributor assigning, which works fine AFAICT.
[06:36] <lifeless> poolie: ah, I saw the optus thread
[06:36] <lifeless> didn't catch the reseller name
[06:36] <wallyworld> wgrant: i fixed that test a day or 2 ago
[06:37] <wgrant> wallyworld: It just failed again a few minutes ago (in db-devel)
[06:37] <wallyworld> wtf
[06:37] <wgrant> 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] <wgrant> 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] <wallyworld> wgrant: well, the error message shows the code is as per my fix and it worked fine locally :-(
[06:38] <wgrant> :(
[06:39] <wallyworld> wgrant: i'll get my current work done and then i'll take a look
[06:39] <wgrant> wallyworld: Thanks.
[06:39] <wallyworld> wgrant: just check my email - the picker fix has gone through \o/
[06:39] <wgrant> wallyworld: Yup, and it works.
[06:40] <wgrant> Thanks.
[06:40] <wgrant> We'll deploy after the next buildout run finishes.
[06:40] <wgrant> Since there's another regression fix in there right now.
[06:40] <wallyworld> 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] <wallyworld> in-process windmill tests as part of ec2 land i mean
[06:41] <wgrant> wallyworld: Right.
[06:42] <wgrant> wallyworld: I can reproduce the assignment test failure locally, hmm.
[06:42] <wgrant> It seems to be legit, but it works on qas.
[06:42] <wallyworld> wgrant: i'll look into it. it worked locally when i put it up for review etc
[06:42] <wallyworld> wgrant: maybe something has changed and is affecting it
[06:43] <wallyworld> wgrant: i've had that happen before. ie worked locally but broke after other stuff got merged in
[06:43] <wgrant> wallyworld: I hope that with deryck on maintenance we will soon be able to make progress.
[06:43] <wgrant> And get Windmill or its replacement back in soon.
[06:43] <wallyworld> +1
[06:44] <wgrant> And maybe even get it to work on natty.
[06:49] <lifeless> 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 <bugs> <escalated> <javascript> <linaro> <lp-bugs> <questions> <ubuntu-qa> <Launchpad itself:Triaged by launchpad-green-squad> < https://launchpad.net/bugs/80902 >
[06:49] <lifeless> oldest critical
[06:53] <wallyworld> wgrant: yeah. still some remaining (weird) ff4 issues to fix for natty
[06:55] <wallyworld> lifeless: i can look at that one next
[06:55] <lifeless> wallyworld: if curtis is cool with it that would rock
[06:56] <wallyworld> lifeless: i'll convince him :-)
[06:56] <lifeless> \o/
[06:56] <wgrant> He was looking at that himself a few weeks ago.
[06:57] <wallyworld> 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] <wallyworld> 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] <wgrant> lifeless: Oh?
[07:02] <wgrant> wallyworld: I've hopefully fixed the translations test.
[07:02] <wallyworld> wgrant: excellent :-)
[07:02] <wgrant> wallyworld: I wonder if the bugs one is related to the odd proxying that Windmill does.
[07:03] <wallyworld> wgrant: not sure. i'm running the tests locally to check for breakages due the to filebug stuff i'm doing
[07:03] <lifeless> wgrant: doing an analysis of the error rate for oe
[07:03] <lifeless> m
[07:03] <lifeless> for bugsummary
[07:03] <wgrant> Ah.
[07:03] <wgrant> lifeless: Well, staging is down, so you have the whole thing :)
[07:19] <wgrant> thumper: Is any QA necessary for your stacking change?
[07:19] <wgrant> thumper: Given that we won't be deploying codehosting tonight?
[07:20] <wgrant> wallyworld: 'node.one(".no_button") is null' :/
[07:20] <wgrant> But it created the node just there :(
[07:21] <wallyworld> 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] <lifeless> wgrant: stacking change?
[07:21] <wgrant> lifeless: [r=bac][bug=377519] Change the default stacking location to use the branch id alias.
[07:22] <wgrant> wallyworld: Ah, it helps if I test in the right browser.
[07:22] <wallyworld> wgrant: you mean it's broken in ff4?
[07:22] <wgrant> Reproducible outside Windmill in Firefox *3*.
[07:22] <lifeless> wgrant: what rev?
[07:22] <thumper> wgrant: yes
[07:23] <thumper> wgrant: it is xmlrpc
[07:23] <lifeless> thumper: I thought we were not going to land that till poolie acked it works ok with bzr ?
[07:23] <thumper> so it'll be live
[07:23] <wallyworld> wgrant: but works in ff4?
[07:23] <wgrant> lifeless: r12874, in buildbot now.
[07:23] <thumper> lifeless: I've qa'ed it to my satisfaction
[07:23] <wgrant> lifeless: Ahead of the bugmail fix.
[07:23] <lifeless> thumper: I'd like poolies ack
[07:23] <lifeless> thumper: he has expressed nervousness about this
[07:23] <wgrant> wallyworld: Not sure.
[07:23] <thumper> sure
[07:23] <lifeless> thumper: its the least we can do
[07:23] <wgrant> wallyworld: I think so, though...
[07:23] <wallyworld> wgrant: this all just makes me sad :-(
[07:24] <lifeless> poolie: has your team tested the id based stacking by hand yet ?
[07:24] <wgrant> wallyworld: Ja.
[07:24] <wgrant> wallyworld: We really need to get cross-browser Windmill working..
[07:24] <wallyworld> wgrant: yep. i'd be happy if *one* browser worked reliably
[07:24] <wgrant> Grumble.
[07:27] <wgrant> Huh.
[07:27] <wgrant> It creates yes_button, but not no_button.
[07:27] <wgrant> I wonder if FF 3 disagrees with self-closing buttons.
[07:28] <wgrant> Chromium disagrees with self-closing divs, I know.
[07:28] <wgrant> Yup, that's it.
[07:28] <wgrant> Web, I hate you.
[07:28]  * wallyworld cries
[07:29] <wgrant> Anyway, both fixed now.
[07:29]  * wgrant lands.
[07:29] <wallyworld> wgrant: what was the fix?
[07:29] <wgrant> -              '<button class="yes_button" type="button"/>',
[07:29] <wgrant> -              '<button class="no_button" type="button"/>',
[07:29] <wgrant> +              '<button class="yes_button" type="button"></button>',
[07:29] <wgrant> +              '<button class="no_button" type="button"></button>',
[07:29] <wgrant> Yes, seriously.
[07:30] <wallyworld> wgrant: wtf. i'm stunned
[07:30] <wgrant> That works fine in Chromium and Firefox 4, but Firefox 3 chokes if you self-close the button.
[07:30] <wgrant> Chromium goes crazy if you don't close a div.
[07:30] <StevenK> Does type="button" /> work?
[07:30] <wgrant> StevenK: I fucking hope not.
[07:30] <wgrant> But possible.
[07:30]  * wgrant tries.
[07:30] <StevenK> Haha
[07:32] <wgrant> Fortunately not.
[07:39] <poolie> lifeless: it has not broken but i have not manually tested it by renaming branches etc
[07:40] <poolie> but i guess you have already done that
[07:50] <wgrant> wallyworld: https://code.launchpad.net/~wgrant/launchpad/translations-windmill-testfix/+merge/58441
[07:50] <wgrant> 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] <wallyworld> wgrant: too bad we can't hook jenkins into ec2 and
[07:51] <wallyworld> land
[07:51] <StevenK> I'd like to
[07:52] <wallyworld> StevenK: jenkins seems more reliable at running wm tests?
[07:52] <wgrant> wallyworld: Only when in a separate job.
[07:52] <wgrant> When running in the main job it's just as unreliable.
[07:52] <wgrant> (which is extremely interesting, yes)
[07:53] <wallyworld> wgrant: so why don't we run the wm tests isolated in ec2?
[07:53] <wgrant> wallyworld: Because nobody has done that yet, and I didn't believe this could be the case until recently.
[07:53] <wgrant> But it has held true for a month or so now.
[07:53] <wgrant> So it may be a good thing to try.
[07:53] <wgrant> Not sure quite how easy it will be, though.
[07:53] <wallyworld> yep
[07:54] <wallyworld> StevenK: wgrant: can we get jenkins to run the yui test layer too?
[07:54] <wallyworld> now that it is separate
[07:54] <wgrant> wallyworld: Good point.
[07:54] <wgrant> StevenK: Could you make it run YUITestLayer too?
[07:54] <wgrant> --layer=(WindmillLayer|YUITestLayer) should do it, I think.
[07:55] <wallyworld> yep
[07:55] <wgrant> Yeah, that works.
[07:55] <StevenK> I was wondering about that
[07:56] <StevenK> sudo -u hudson -H make TESTOPTS="--subunit --layer=(WindmillLayer|YUITestLayer)" check | subunit2junitxml -f -o test-results.xml
[07:56] <wgrant> Should work.
[07:56] <StevenK> Done.
[07:56] <wgrant> Thanks.
[07:58] <wgrant> So, can has review?
[07:58] <wgrant> buildbot will finish soon.
[07:59] <StevenK> wgrant: r=em
[07:59] <StevenK> *me
[07:59] <wgrant> Thanks.
[08:00] <StevenK> wgrant: I'd say "Self-review for something that trivial.", but you can't. :-(
[08:00] <wgrant> Yeah.
[08:00] <wgrant> It's a little sad.
[08:00] <wgrant> wallyworld: Is test_TextFieldPickerPlugin_selected_item_is_saved new today?
[08:01] <wallyworld> wgrant: yes
[08:01] <wgrant> wallyworld: It fails locally.
[08:01] <lifeless> woo
[08:01] <wgrant> I wonder if it hasn't hit db-devel yet.
[08:01] <lifeless> the error rates ar elow
[08:01] <wallyworld> wgrant: i added it to test the regression. there's a similar test in lazr-js but we need our own also
[08:01] <lifeless> 243 -> 248
[08:01] <lifeless> 103 -> 108
[08:01] <lifeless> 12 -> 12 (with the occasional 13)
[08:02] <wallyworld> wgrant: fails how?
[08:02] <wgrant> wallyworld: Oh, is it YUITestLayer?
[08:02] <wallyworld> wgrant: yes
[08:02] <wgrant> Yes, yes it is.
[08:02] <wgrant> Broken in Firefox 3, yay.
[08:02] <wallyworld> hmpf
[08:02] <wgrant> And Windmill didn't catch it 'cause it wasn't running them until 5 minutes ago.
[08:02] <wgrant> AssertionError: Failure in lp/app/javascript/tests/test_picker.html.test_TextFieldPickerPlugin_selected_item_is_saved: test_TextFieldPickerPlugin_selected_item_is_saved: failed.
[08:02] <wgrant> focus didn't go to the search input.
[08:02] <wgrant> Expected: true (boolean)
[08:02] <wgrant> Actual: false (boolean)
[08:03] <wallyworld> wgrant: hmmmm. i lifted most of the code from lazr-js for that test
[08:03] <wallyworld> ported theirs across
[08:03] <wgrant> wallyworld: Let's see what happens if I run it outside Windmill.
[08:03] <StevenK> I've been pondering use of Jenkins -- use Tarmac, which fires off a Jenkins paramatised build, and if the tests pass, merges it to devel. A devel build to stable could work the same way.
[08:03] <wallyworld> wgrant: or perhaps in ff4
[08:04] <wgrant> wallyworld: How do I run it?
[08:04] <StevenK> wgrant: Does Windmill work with FF4?
[08:04] <wgrant> StevenK: That's how the new build infrastructure is meant to work, exception doing the build inside tarmac.
[08:04] <wallyworld> wgrant: one sec. phone just rang
[08:04] <wgrant> StevenK: Not for me, but for wallyworld it does.
[08:05] <StevenK> Because I've had a thought -- if we could get FF4 onto Lucid, I could convince the windmill tests to run twice -- once for 3 and once for 4
[08:05] <wgrant> StevenK: I was going to talk to deryck about that some time this week.
[08:05] <wgrant> And Chromium too.
[08:06] <wgrant> wallyworld: It turns out that having JS built in the relevant branch helps.
[08:06] <wgrant> I can see the failure outside Windmill now.
[08:06] <wgrant> Works in Chromium, not FF3.
[08:06] <StevenK> Hm, it would have to be a seperate builder inside Jenkins, which makes me sad.
[08:07] <lifeless> matrix build ftw
[08:07] <wgrant> Unexpected error: simulateMouseEvent(): Invalid target.
[08:07] <StevenK> lifeless: Yes, that was my plan
[08:08] <wgrant> StevenK: Why is that sad?
[08:08] <wgrant> It's how it should be, I think.
[08:08] <wallyworld> wgrant: to run outside wm you need to open the html file in a browser
[08:08] <StevenK> Because it would be almost-but-not-quite the same as the lucid builder
[08:08] <wgrant> Ah.
[08:08] <wgrant> wallyworld: nth-child(2)
[08:08] <wgrant> I bet that's it.
[08:08] <wallyworld> wgrant: the html files is in the same dir
[08:09] <wgrant> "Hmm... according to this page Firefox 3.0 does not support :nth-child"
[08:09] <wallyworld> wgrant: that expr will pick the no button
[08:09] <wallyworld> if it exists :-)
[08:09] <wallyworld> wgrant: that's fooked. does it say what to use instead?
[08:10] <wgrant> Hmm. It at least somewhat supports it.
[08:11] <wgrant> But not completely.
[08:11] <wallyworld> wgrant: there must be an alternative you'd think. btw, jquery and windmill don't play well together :-(
[08:11] <wgrant> wallyworld: Oh?
[08:11] <wallyworld> i've reverted to using xpath most times now :-(
[08:12] <wgrant> Ah, right.
[08:12] <wallyworld> wgrant: yeah, waitsForElement gives false positives
[08:13] <wgrant> Awesome.
[08:13] <wallyworld> ?
[08:14] <wgrant> Erm.
[08:14] <wgrant> nth-child(1)?
[08:14] <wgrant> Doesn't that mean every child?
[08:14] <wallyworld> that picks the yes button
[08:14] <wgrant> I forgot the 'n' syntax.
[08:14] <wgrant> So yes, you're right.
[08:15] <wallyworld> first time for everything
[08:23] <wgrant> wallyworld: Turns out those nth-child failures were from devel, not my fixed branch. But I can't reproduce the test_TextFieldPickerPlugin_selected_item_is_saved failure outside Windmill... I guess I'll run it again once this full WindmillLayer|YUITestLayer run finishes.
[08:24] <StevenK> The current Jenkins run is in the depths of make compile
[08:24] <wgrant> Yeah.
[08:24] <wgrant> It'll hopefully fail a few tests.
[08:25] <wgrant> Or at least four.
[08:29] <wallyworld> wgrant: i wish we knew why stuff that appears ok breaks inside windmill
[08:30] <lifeless> thumper: ah, I didn't realise you'd chatted with poolie already - we're gtg
[08:31] <lifeless> wgrant: stacking needs qa yes, and we should check its good after the deploy just-in-case.
[08:31] <lifeless> -> cooking
[08:34] <wgrant> lifeless: I hadn't looked hard enough to determine it was an XML-RPC change.
[08:35] <LPCIBot> Project windmill build #194: STILL FAILING in 25 min: https://lpci.wedontsleep.org/job/windmill/194/
[08:35] <wgrant> Erm.
[08:36] <wgrant> StevenK: I wonder if it needs more quotes.
[08:36] <StevenK> Haha
[08:37] <StevenK> wgrant: '' sprinkled in, build scheduled
[08:37] <wgrant> Thanks.
[08:40] <LPCIBot> Project windmill build #195: STILL FAILING in 3 min 44 sec: https://lpci.wedontsleep.org/job/windmill/195/
[08:40] <StevenK> Erm
[08:41] <wgrant> Even worse.
[08:41] <StevenK> Can we specify --layer more than once?
[08:41] <wgrant> Don't think so. I suggest escaping the quotes.
[08:41] <wgrant> Or the parens.
[08:41] <wgrant> And the pipe.
[08:42] <wgrant> I wonder how many levels of shell this is going through...
[08:42] <StevenK> At least one :-)
[08:43] <StevenK> wgrant: More escaping!
[08:43] <StevenK> \\\" ...
[08:51] <jtv> StevenK, wgrant: I'm trying to get a grip on what my next task means.. we need to run publish-distro -A, once, on a distroseries after we create it.  Could you help me grok?
[08:52] <StevenK> wgrant: It's working!
[08:52] <jtv> Specifically: is there a risk of it running more than once?  Are there known risks associated with interrupting and restarting it?  Does it take too long to incorporate in the normal scripting?
[08:52] <jtv> StevenK: if you got shell escaping fixed, my hat's off to you!
[08:53] <jtv> Well, helmet technically
[08:55] <thumper> lifeless: I haven't talked to poolie in several days
[08:56] <StevenK> jtv: 1. publish-distro -A can't run while any other publisher is running. 2. It will take a while to run.
[08:56] <wgrant> jtv: It takes a while.
[08:56] <wgrant> Yeah.
[08:56] <wgrant> StevenK: Any other publisher *for that archive*.
[08:56] <jtv> I guess this is the very step that also takes the bulk of the publish-ftpmaster time.
[08:56] <wgrant> Yes.
[08:56] <wgrant> Precisely.
[08:56] <StevenK> And if you're testing on mawson. It will take an eon to finish.
[08:56] <wgrant> Not any more.
[08:56] <wgrant> More like 25 minutes.
[08:57]  * jtv grins evilly
[08:57] <wgrant> jtv: How are you doing it? A dirty suite flag?
[08:57] <jtv> Well I'm still trying to figure that out.
[08:58] <jtv> The bit about concurrent runs is one of my bigger worries: do we need a global archive FS write lock perhaps, rather than script locks?
[08:58] <poolie> thumper: we talked last week though
[08:58] <poolie> i'm pretty sure
[08:58] <thumper> poolie: if you're happy with it, I'm happy
[08:59] <poolie> i'm happy with what you described
[08:59] <jtv> StevenK, wgrant: Come to think of it, the new publish-ftpmaster invokes run_publisher directly so we may have a concurrency hazard there already.
[08:59] <poolie> if you can think of anything you want me to test i can
[08:59] <wgrant> jtv: Why?
[09:00] <wgrant> jtv: I mean, yes, but why does that in paticular make it a hazard?
[09:00] <wgrant> Because it doesn't share the publish-distro.py lock?
[09:00] <jtv> Right, that's in the script presumably, not in run_publisher.
[09:00] <wgrant> This is indeed bordering on dire peril.
[09:00] <mrevell> Hi!
[09:01] <jtv> hi mrevell!
[09:01] <adeuring> good morning
[09:01] <jtv> wgrant: it might help for me to be aware of what global operations may mess with archives...  I take it there's database state and filesystem state that must stay in sync?
[09:01] <jtv> hi adeuring!
[09:01] <adeuring> hi jtv!
[09:01] <StevenK> jtv: Absolutely must, yes.
[09:02] <wgrant> jtv: Yes. process-accepted, publish-distro and process-death-row maintain the disk state.
[09:02] <StevenK> Otherwise we can get corrupted archives, and then wgrant will kill you.
[09:02] <wgrant> jtv: Those three can run in parallel, but more than one instance of each will cause grave damage.
[09:02] <jtv> wgrant: that smells very much like more than should be managed by a script lock.
[09:03] <wgrant> jtv: Most probably.
[09:03] <wgrant> But lots of things in Soyuz smell.
[09:03]  * jtv discreetly looks the otherway
[09:03] <wgrant> Some admittedly smell less bad, as they can't directly destroy an archive used by many millions of machines.
[09:04]  * jtv still looks the other way, but now starts blushing a bit as well
[09:04] <jtv> I hear Kazakhstan has some openings for software engineers who like to get away from it all.
[09:06] <jtv> wgrant: publish-ftpmaster also runs process-accepted I believe, so that's yet another locking hazard.  I'll file some bugs.
[09:07] <wgrant> That's correct.
[09:07] <stub> If you need more granular locks over the network, feel free to use PG advisory locks.
[09:07] <wgrant> Although parallel runs of p-a are less likely to have immediately devastating effects.
[09:08] <jtv> There's an idea.
[09:08]  * jtv rages at browser that's failing to connect to LP
[09:09] <jtv> wgrant: I'd rather maintain correctness overall than just avoid those.  Or are you trying to discourage me from trying it on the basis that immediately devastating effects are what I'm hoping for?
[09:09] <wgrant> jtv: No, both should be avoided.
[09:09] <jtv> Good, good.  Glad to know we're all on the same page.
[09:10] <jtv> Or would be, if LP would load over this connection.
[09:11] <jtv> wgrant: would you mind filing either one or two bugs about this?  The new, pythonized publish-ftpmaster script neglects to lock around run_publisher and ProcessAccepted.
[09:11] <jtv> stub's still bouncing
[09:11] <jtv> not a mental image I had hoped to evoke today
[09:14] <jtv> Do these Three Singletons of Death operate on different bits of filesystem?  Or do they just do things in some other way happen not to affect each other?
[09:14] <wgrant> jtv: They all work in archiveroot.
[09:14] <wgrant> But doing different tasks.
[09:20] <poolie> jelmer: https://bugs.launchpad.net/launchpad/+bug/761664
[09:20] <_mup_> Bug #761664: Import from git does not update <branch-scanner> <branches> <Launchpad itself:Triaged> < https://launchpad.net/bugs/761664 >
[09:24] <LPCIBot> Project windmill build #196: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/196/
[09:25] <wgrant> StevenK: Success, thanks.
[09:25] <wgrant> (well, failure, but the expected amount of failure)
[09:47] <henninge> wgrant: Hi!
[09:50] <wgrant> henninge: Hi.
[09:50] <henninge> wgrant: I am surprised that you find that check_permission allows unregistered permissions.
[09:50] <henninge> wgrant: because I copied that code in forwardCheckAuthenticated from check_permission ...
[09:51] <wgrant> henninge: Our check_permission?
[09:51] <henninge> hm, I thought so
[09:51]  * henninge checks
[09:51] <wgrant> Zope's checkPermission doesn't.
[09:52] <wgrant> Huh.
[09:52] <wgrant> our check_permission explicitly checks that.
[09:52] <henninge> exactly
[09:53] <wgrant> Perhaps it was not using our check_permission.
[09:53] <wgrant> It was...
[09:53] <wgrant> Huh.
[09:54] <wgrant> Well, the fix worked :/
[09:54] <wgrant> So I am very confused.
[09:54] <henninge> ...
[09:54] <henninge> I know the feeling
[09:54] <wgrant> Oh.
[09:54] <wgrant> I see.
[09:55] <wgrant> I think. Maybe.
[09:55] <wgrant> I see something that is wrong.
[09:55] <wgrant> But that wouldn't break this...
[09:57] <wgrant> henninge: forwardCheckAuthenticated fails to raise a ValueError when the permission is not specified.
[09:57] <wgrant> henninge: I wonder if ValueError is caught somewhere and taken as if checkAuthenticated had returned False?
[09:58] <henninge> wgrant: you mean not specified as a parameter and not specified as self.permission?
[09:59] <wgrant> henninge: If it is specified as self.permission then it doesn't do the registration check.
[09:59] <wgrant> henninge: This is wrong if the object is a different interface.
[09:59] <henninge> wgrant: oh, right
[09:59] <wgrant> I think that's the problem here.
[09:59] <wgrant> But something hideous is converting the ValueError into a False.
[10:00] <henninge> I had assumed that the permission has already been checked but missed the changed object dimension.
[10:00] <henninge> that sounds bad.
[10:01] <wgrant> Ah, not quite.
[10:01] <wgrant>             # The IAuthorization is a named adapter from objecttoauthorize,
[10:01] <wgrant>             # providing IAuthorization, named after the permission.
[10:01] <wgrant>             authorization = queryAdapter(
[10:01] <wgrant>                 objecttoauthorize, IAuthorization, permission)
[10:01] <wgrant>             if authorization is None:
[10:01] <wgrant>                 return False
[10:01] <wgrant> In LaunchpadSecurityPolicy
[10:01] <wgrant> So if the adapter isn't there it returns False, indeed.
[10:01] <wgrant> So, two bugs.
[10:02] <wgrant> The self.permission check is bad, as I outlined earlier. That's definitely a bug.
[10:02] <wgrant> But it's not clear if the ValueError behaviour is desired here.
[10:02] <wgrant> Hard to say.
[10:03] <henninge> wgrant: can you please file the first bug?
[10:03] <wgrant> Sure.
[10:05] <jtv> rvba: I'll go and relocate now, hopefully before rain and/or resumed heat.  After that, review!
[10:06] <rvba> jtv: great https://code.launchpad.net/~rvb/launchpad/fix-already-computed-pckdiff-request/+merge/58257
[10:06] <jtv> ta
[10:06] <henninge> wgrant: to be clear, we are talking about this change, right? http://paste.ubuntu.com/596466/
[10:07] <wgrant> henninge: Bug #766955
[10:07] <_mup_> Bug #766955: forwardCheckAuthenticated doesn't check existence if a permission is not specified <Launchpad itself:Triaged> < https://launchpad.net/bugs/766955 >
[10:07] <wgrant> Yes.
[10:07] <wgrant> That is probably the fix.
[10:07] <henninge> wgrant: cool, thanks
[10:12] <LPCIBot> Project windmill build #197: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/197/
[10:18] <lifeless> back
[10:20] <henninge> wgrant: I also think that it should use queryAdapter and return False if that fails, just like checkPermission in the Policy. Ist that what you identified as the second bug?
[10:21] <wgrant> henninge: Probably. I'm not sure I like that behaviour, but it would be more consistent.
[10:21] <henninge> yes, it is. I'll include that.
[10:21] <poolie> hi mrevell!
[10:22] <mrevell> Hey poolie
[10:22] <poolie> will get that for you in a sec
[10:22] <mrevell> Oh thanks. I'm just curious to see what people are using and how much.
[10:23] <poolie> me too
[10:24] <poolie> mrevell: what's your current gpg key id?
[10:41] <lifeless> night all
[10:45] <poolie> night lifeless
[10:50] <wgrant> Why are we making do_copy async?
[10:50] <wgrant> allenap: ^^?
[10:50] <allenap> bigjools: ^
[10:51] <bigjools> because the moon is made of cheese
[11:57] <stub> Hmm... lp-propose-merge just popped up chromium for my web browser instead of firefox. I think I need to twiddle something in this KDE thingy, but I know not what.
[12:46] <bigjools> stub: you're using KDE? :)
[12:47] <stub> Yeah - giving the new version a try. Looking good, although still haven't managed to fully purge those ayatana scrollbars yet.
[12:47] <bigjools> what are those?
[12:47] <bigjools> and did you figure out the default browser change?
[12:47] <stub> bigjools: no
[12:47] <bigjools> fire up System Settings
[12:48] <bigjools> then look in Workspace Appearance and Behavior -> Default Applications
[12:48] <stub> bigjools: The new scrollbars that appear when you hover over the right spot - I think GTK only? Anyway... pain to use with this trackball or maybe it is just me.
[12:48] <bigjools> oh you might be able to get rid of those, let me see
[12:49] <poolie> huh i just got something odd
[12:49] <bigjools> in the System Settings, have a looksee around Common Appearance...
[12:49] <bigjools> -> Application Appearance
[12:49] <poolie> the ajax dupe deally sasy "472201 is not a valid bug number or nickname."
[12:49] <poolie> really?
[12:49] <stub> bigjools: Hmm... so that will fire up firefox for all URLs, including the ones firefox can't handle like ssh: etc.
[12:50] <stub> bigjools: It isn't a KDE thing - can't see anywhere to configure it anyway. There is a package you can uninstall... oh... maybe it is still in effect because I haven't rebooted.
[12:51] <bigjools> stub: the GTK widgets under KDE are not really GTK widgets, they're gtkqt or something, so you can theme them
[12:51] <bigjools> try fiddling with the settings in Application Appearance.  I don't get the Ayantana stuff but I'm not sure what I set :)
[12:52] <stub> Its not there :) You have tomboy? Check out your scrollbar in a tomboy note.
[12:52] <bigjools> stub: the "web browser" setting is only for http/https
[12:53] <bigjools> stub: tomboy using normal scrollbar here
[12:53] <stub> I'll reboot.
[12:54] <poolie> nighta ll
[12:54] <bigjools> nn poolie
[13:04] <stub> aha... you have to remove both overlay-scrollbar and the liboverlay-scrollbar packages. The latter seems to be used by mono apps even when the overlay-scrollbar package has been removed.
[13:08] <bigjools> fun
[13:09] <jam> What is the correct protocol for getting someone to reconfigure a branch? We have a (very old) branch that has a bad stacked-on location, and I'd like to still get the new data.
[13:19] <jam> (I used my leet bzrlib skills to get at the data anyway, but it would be nice to fix it)
[14:07] <abentley> henninge-lunch: stand-up?
[14:19] <henninge> abentley: oh sorry, forgot ...
[14:19] <henninge> abentley: I guess you are done?
[14:19] <abentley> henninge: no, it was just me and abel, so we decided to wait for you.
[14:19] <abentley> henninge: ready now?
[14:19] <stub> bigjools, rvba: So for this derivatives stuff, we have a parent/child relationship between distroseries but the is_overlay flag is going on the distribution for all its series?
[14:19] <rvba> stub: correct
[14:19] <bigjools> yes
[14:20] <bigjools> potentially it should be on the archive actually
[14:20] <bigjools> mm,m
[14:20] <stub> So the owner of the parent distribution controls how people can derive from it?
[14:20] <henninge> abentley: getting there ;)#
[14:20] <stub> c/owner/driver/
[14:21] <bigjools> stub: no, the person making a new distro sets whether it's an overlay or not
[14:21] <bigjools> but I am wondering if this bool should be on IArchive instead
[14:21] <henninge> abentley: do you know which port mumble uses?
[14:21] <bigjools> then it can be used for PPAs
[14:21] <stub> oh yeah... the flag says 'these distroseries inherit from parents'
[14:21]  * henninge installed a new firewall
[14:22] <abentley> henninge: Not immediately.  Lemme see...
[14:23] <stub> bigjools: ok. I'll hold off reviewing that branch until tomorrow.
[14:24] <abentley> henninge: I think the client may not have a default port.
[14:24] <bigjools> rvba: it's probably a lot of work to move that flag to IArchive...  but I think it's better placed there.
[14:24] <bigjools> you may curse me
[14:24] <abentley> henninge: The server port is 64738, but that shouldn't be relevant.
[14:24] <rvba> bigjools: that's ok;)
[14:24] <henninge> abentley: I'll try that
[14:25] <rvba> bigjools: we will talk about it later this afternoon (I may curse you at this occasion)
[14:25] <abentley> henninge: try "force TCP mode" too.
[14:26] <henninge> I see my lips turn red ...
[14:30] <gary_poster> allenap, do you happen to know if bug heat calculations causing timeouts when trying to subscribe to a bug (https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1936QASTAGING50) is a known problem?  https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=bug+heat doesn't show anything particularly relevant
[14:31] <allenap> gary_poster: I've never heard of that problem before.
[14:31] <gary_poster> ok thanks allenap
[14:34] <wgrant> gary_poster: We often see that on qastaging due to cold cache issues.
[14:34] <wgrant> gary_poster: It's fine on prod.
[14:35] <gary_poster> wgrant, ah ok.  I have been trying various workarounds, and not succeeding.  I was about to create my own project to try and workaround.  Do you know any better approaches?
[14:35] <wgrant> gary_poster: Get a project with fewer bugs, I guess :/
[14:35] <wgrant> Or refresh a few hundred times.
[14:36] <gary_poster> heh, ok thank you wgrant :-)
[14:36] <wgrant> Oddly, staging seems to be mostly immune to this.
[14:36] <wgrant> Despite residing on the same DB server.
[14:37] <cr3> hi folks, would it be reasonable to create a team called ~launchpad-results to work on the launchpad-results project as defined in the ResultsTracker LEP?
[14:39] <wgrant> henninge: +text is nowadays strongly discouraged, fwiw. We want to drop it since it can show an unbounded an often immense volume of data.
[14:39] <henninge> wgrant: I see. Do we have a bug for that?
[14:40] <bigjools> wgrant: rvba has a branch adding is_overlay on IDistribution but I'm looking at moving that to IArchive as I think it's better placed there.  Do you have any comment?
[14:40] <wgrant> bigjools: Do we know what it does yet?
[14:40] <wgrant> I think IArchive is probably better.
[14:40] <wgrant> But it really depends on how it is going to work.
[14:40] <bigjools> wgrant: the thing we discussed the other week; it adds the extra sources.list entry to the builders
[14:41] <wgrant> bigjools: That's all it needs to do?
[14:41] <bigjools> if it's on IArchive it means we can remove hard-coded PPA check
[14:41] <wgrant> Not exactly.
[14:41] <bigjools> yup
[14:41] <wgrant> Since the default dependency is customisable.
[14:41] <wgrant> You can change the used components/pockets.
[14:41] <bigjools> I did say "one"
[14:41] <wgrant> I'm not sure a flag is the Right Way™
[14:42] <bigjools> doing something on IArchive is nearly always the right way instead of IDistribution
[14:42] <wgrant> Sure.
[14:42] <wgrant> It's definitely better than on IDistribution.
[14:42] <wgrant> But I'm not sure either is actually good.
[14:42] <wgrant> It doesn't directly help the PPA case.
[14:43] <wgrant> Since in the overlay distro case it has to use the parent series, for PPAs it has to not use the parent series.
[14:43] <wgrant> So it's still hard-coded.
[14:43] <wgrant> So it's not a benefit.
[14:44] <bigjools> things are very black and white to you huh
[14:44] <wgrant> Well, it's clear that there are possibly better options.
[14:44] <wgrant> That may clean this whole thing up quite spectacularly.
[14:44] <wgrant> Remove the default dependency hardcoding, that sort of thing.
[14:44] <wgrant> I'm trying to think how it would work with the parent relationship...
[14:44] <bigjools> yeah that was always a bit of a hack
[14:45] <bigjools> I wonder if, instead of a flag, we add an ArchiveDependency record at creation time
[14:45] <wgrant> bigjools: Does it always overlay on top of a single distroseries?
[14:45] <wgrant> Right.
[14:45] <wgrant> That was going to be my suggestion, once I'd worked out how the cross-distro stuff works.
[14:45] <wgrant> But I think we just have to have a flag :(
[14:45] <wgrant> On the archivedependency.
[14:45] <wgrant> To say that we're using the parent instead.
[14:46] <wgrant> But ew :/
[14:46] <wgrant> Still, it lets us unify the systems.
[14:46] <bigjools> not sure we need a flag
[14:46] <bigjools> hmm
[14:46] <wgrant> What, automatically use the parent if it's cross-distro?
[14:46] <wgrant> I guess that could work...
[14:47] <bigjools> the other way around
[14:47] <wgrant> Hm?
[14:47] <bigjools> use the parent if it's in ArchiveDependency
[14:47] <bigjools> no changes required anywhere in the code, I think
[14:48] <bigjools> other than adding the AD at distro setup/edit
[14:48] <wgrant> bigjools: ArchiveDependency specifies an archive. We would need to detect in the code that the dependency Archive is for an alternate Distribution, and use parent_series in that case.
[14:48] <wgrant> Otherwise it will try to use the child distroseries name.
[14:48] <wgrant> In the parent archive.
[14:49] <bigjools> ah right
[14:49] <wgrant> If you have multiple parents in one distribution you're screwed, but let's hope that never happens.
[14:49] <wgrant> Hmm.
[14:49] <bigjools> unless we add series to archivedependency!
[14:49] <wgrant> Ah, yes, this could work.
[14:49] <wgrant> No.
[14:49] <wgrant> So, here's an idea.
[14:49]  * bigjools waits
[14:50] <bigjools> rvba, you following this?
[14:50] <rvba> yes
[14:50]  * rvba waits too
[14:50] <wgrant> When expanding each ArchiveDependency, if it's for a foreign distribution we generate one entry for each matching DistroSeriesParent.
[14:50] <wgrant> So for each DistroSeriesParent where the child matches and the parent is in the dependency's distribution.
[14:51] <wgrant> This way things can change between series without a problem.
[14:51] <wgrant> No flag required.
[14:51] <wgrant> No elaborate parent_series hack required.
[14:51] <wgrant> If the archive is for the wrong distribution, it just won't be used.
[14:51] <wgrant> Because there are no DistroSeriesParents for that distribution.
[14:52] <wgrant> This seems reeeeasonably clean.
[14:52] <abentley> rvba: do you want me to review https://code.launchpad.net/~rvb/launchpad/distro-overlay-758908/+merge/58304 or is someone else doing that?
[14:52] <bigjools> FSVO clean
[14:52] <rvba> abentley: please don't review it now
[14:52] <rvba> abentley: I'll set it to WIP ...
[14:52] <bigjools> abentley: I'm looking at it, sorry I forgot to claim it yet
[14:52] <abentley> rvba: cool, thanks.
[14:53] <rvba> abentley: thanks for the offer though ;)
[14:53] <wgrant> bigjools: Otherwise we have to presume there's only one parent distribution, or something like that.
[14:54] <wgrant> bigjools: This also allows us to easily set some parents as fully inherited, and others as overlays.
[14:54] <wgrant> By adding a flag on DistroSeriesParent.
[14:54] <wgrant> It's no longer Distribution- or Archive-wide, so it can change over time if necessary.
[14:54] <bigjools> the overlay is the other way around really
[14:54] <wgrant> Hm?
[14:54] <bigjools> either my distro is an overlay or it isn't
[14:55] <wgrant> Is it?
[14:55] <bigjools> but ISWYM
[14:55] <wgrant> I might be an overlay over Ubuntu, but I want to fully customize the OEM base overlay.
[14:55] <wgrant> Without having to fully inherit Ubuntu.
[14:55] <wgrant> So I have a full inheritance DSP to OEM base, and an overlay DSP to Ubuntu.
[14:58] <wgrant> Hmm.
[14:59] <wgrant> This is difficult.
[14:59] <jtv1> bigjools: I'm thinking the publish-distro run for a new series wants to be a DistributionJob.  What needs to be done to the distroseries before we get to it?
[14:59] <bigjools> yes, it's difficult :)
[15:00] <bigjools> jtv1: it needs to be initialized
[15:00] <wgrant> bigjools: What issues do you see in my DSP-based pplan? I think we'd have to basically implement the same thing with your proposal, except it would be a lot more hardcoded and less flexible. It may even be slightly uglier, particularly if we have to extend it later.
[15:00] <bigjools> jtv1: but I need to think through the workflows again
[15:01] <wgrant> bigjools: Do we know how publishing is going to be triggered for derivation in general?
[15:01] <wgrant> Manual crontab editing is probably suboptimal.
[15:01] <wgrant> And the solution seems fairly relevant to jtv1's problem...
[15:01] <jtv1> Quite.
[15:02] <bigjools> wgrant: we need  a job runner to kick it off, based on a schedule configured in the DB
[15:02] <bigjools> I don't want to re-implement cron though
[15:03] <jtv1> So... a cron job that runs publish-distro for all "eligible" series?
[15:03] <wgrant> bigjools: It's difficult, because these jobs will take half an hour to run :(
[15:03] <bigjools> wgrant: so the presence of an AD will cause us to add one sources.list for each DSP for a foreign distro
[15:03] <wgrant> bigjools: For that distro, yes.
[15:03] <bigjools> wgrant: possibly
[15:04] <wgrant> bigjools: We'll go through all the ADs. For archives for the same distribution, we just spit out an entry for the build series.
[15:04] <wgrant> For archives for other distributions, we look up all parents in that distribution, and spit out entries for them all.
[15:04] <bigjools> right
[15:04] <bigjools> we don't need a flag, but we do need a way of changing these dependencies
[15:05] <wgrant> Yeah.
[15:05] <bigjools> rvba: call? :)
[15:05] <rvba> bigjools: sure
[15:05] <wgrant> bigjools: We basically have to do the DSP lookup anyway, regardless of how we do this (unless we include series in the AD, which seems a bit bad).
[15:05] <wgrant> bigjools: So we might as well do it this way, I think.
[15:07] <bigjools> wgrant: it seems reasonable
[15:07] <bigjools> we don't need any booleans now
[15:07] <wgrant> Right.
[15:07]  * bigjools OTP to rvba
[15:07]  * wgrant -> sleep.
[15:07] <bigjools> nn
[15:12] <jtv1> night wgrant!
[15:26] <jtv1> bigjools: I'm thinking of calling it a night as well.  I don't think I can get canonadmin to understand our latest plans; probably not worth the hassle.
[15:26] <bigjools> jtv1: ok :/
[15:31] <jtv1> bigjools: do let me know if you have any epiphanies or wishes about the distroseries workflow.  YWIMC.
[15:39] <abentley> henninge: I'm trying to read https://wiki.canonical.com/Launchpad/Translations/ImportQueueReview but I can't tell what I need to do to assess an import.
[15:40] <henninge> abentley: I have not read that document ... ;)
[15:40] <henninge> abentley: I cleared the qeueu yesterday. Let's see what we have today.
[15:40] <henninge> or on Monday?
[15:40] <abentley> henninge: I only see two, and one may yet be auto-approved.
[15:41] <henninge> abentley: I never wonder about that, I just do them all.
[15:41] <henninge> abentley: so, the first one is an old aquiantance. OpenERP has tons of templates and they keep adding more.
[15:42] <henninge> also, they have multiple project series.
[15:42] <henninge> abentley: click on the edit icon and you'll see.
[15:42] <henninge> https://translations.edge.launchpad.net/+imports/5463816
[15:43] <henninge> abentley: at the bottom is some general information about the project.
[15:43] <henninge> 323 templates ...
[15:44] <henninge> abentley: with a project that already has templates, I assume that they get the file format right, so I don't check the file itself.
[15:44] <henninge> abentley: you can have a look at existing template names (the drop-down box) but this one should not be in there.
[15:45] <henninge> abentley: so this is a new one. The preset name is good to use, you can just hit "Approve"
[15:45] <abentley> henninge: Okay.
[15:46] <henninge> oh, the queue just grew ;)
[15:46] <abentley> But those might be auto-approved.  In fact, looks likely.
[15:47] <henninge> abentley: yes, let's not worry about them.
[15:47] <henninge> abentley: but the next one won't, I guess.
[15:47] <henninge> https://translations.edge.launchpad.net/+imports/5464373
[15:48] <henninge> abentley: If you click on "1 template" in the footer, it will take you to the templates list.
[15:48] <henninge> abentley: so there is alread y template of that name. Click on  "Edit"
[15:48] <henninge> abentley: this is the only way to check the path of the template.
[15:49] <henninge> abentley: it is "po/xcsoar.pot" which is different from "xcsoar.pot" in the entry.
[15:49] <henninge> abentley: that's why it's not approved because the auto approver matches by path.
[15:49] <abentley> Spelling error on that page: "its status", not "it's status"
[15:49] <henninge> true
[15:50] <henninge> abentley: you have two options now: Change the path of the template here and wait for the auto approver to pick it up, or ...
[15:51] <henninge> approve the entry, leaving the path as it is.
[15:51] <abentley> I don't know what the implications of changing the path are.
[15:51] <henninge> The latter will *not* update the path of the template entry, so subsequent uploads will get stuck in the same way.
[15:52] <henninge> abentley: the implication is about how future uploads will behave and it's about guessing if the file name which is in the queue entry is a one-off or if the uploader actually changed it.
[15:53] <abentley> henninge: I see.
[15:53] <henninge> abentley: it's all a lot of guess work, I admit ... :(
[15:53] <abentley> It's not possible to have two templates with the same basename in a project, right?
[15:53] <henninge> abentley: paths with directories are either from a tarball uplaod or a branch upload.
[15:54] <flacoste> bigjools: that's a lot of diffs!
[15:54] <bigjools> flacoste: yup!
[15:54] <henninge> abentley: it is not possible to have two templates with the same name.
[15:54] <henninge> abentley: that is not even possible with gettext.
[15:54] <sinzui> jcsackett: do you have time to mumble. I am making no progress with bug 751995
[15:54] <_mup_> Bug #751995: person-transfer-job,  ProgrammingError: permission denied for relation account <oops> <teams> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/751995 >
[15:54] <jcsackett> sinzui: sure.
[15:54] <henninge> because with gettext name == translation domain and that needs to be unique
[15:55] <henninge> abentley: btw, that spelling mistake is most likely in the interface IPOTemplate.
[15:56] <bigjools> flacoste: ubuntu stops syncing a couple of months before release - that's all the packages that debian continues to change in the meantime
[15:56] <abentley> henninge: does it make sense for the auto-approver to check on path if basenames are unique?
[15:56] <bigjools> flacoste: see the new portlet on https://staging.launchpad.net/ubuntu/natty/
[15:57] <henninge> abentley: a lot of things don't make sense with the auto-approver.
[15:57] <henninge> abentley: it needs to be rewritten or more likely replaced badly.
[15:58] <henninge> abentley: ah! xcsoar imports from a branch!
[15:58] <abentley> henninge: curiouser and curiouser.
[15:59] <henninge> abentley: and there is po/xcsoar.pot dated 2011-04-20 ...
[15:59] <flacoste> bigjools:
[15:59] <flacoste> 2772 packages in Sid.
[15:59] <flacoste> 2289 packages in Natty.
[15:59] <flacoste> i find those label unclear
[15:59] <bigjools> yes
[15:59] <flacoste> only in Sidf
[15:59] <bigjools> there's a bug about that :)
[16:00] <flacoste> only in Natty
[16:00] <flacoste> cool
[16:00] <flacoste> !
[16:00] <flacoste> and that's great!
[16:00] <sinzui> jcsackett: http://pastebin.ubuntu.com/596578/
[16:00] <LPCIBot> Project windmill build #198: STILL FAILING in 1 hr 3 min: https://lpci.wedontsleep.org/job/windmill/198/
[16:00] <bigjools> flacoste: I just need my RT fixing up to add the crontabs I requested and it'll all start updating properly when requesting diffs and syncing packages
[16:01] <henninge> abentley: so it looks like the maintainer got impatient and uploaded the file manually.
[16:01] <henninge> abentley: although it was updated in the branch this morning AFAICT.
[16:04] <henninge> abentley: anyway, just approve it as it is, don't change the path. Usually it should get updated from the branch. I just wonder what is going wrong here.
[16:05] <abentley> henninge: done.
[16:06] <henninge> abentley: for the remaining three I agree that they should get approved automatically.
[16:06] <abentley> henninge: cool.
[16:07] <henninge> abentley: the real queue review happens when projects import their first template.
[16:07] <henninge> abentley: Here I check for:
[16:07] <henninge> - Is the template a proper gettext potemplate with header?
[16:07] <henninge> - Does it use English as the source language?
[16:07] <abentley> henninge: I can't do that.
[16:08] <henninge> abentley: it's just about if it looks correct, not an acutal parsing.
[16:08] <henninge> the importer will reject it if is wrong.
[16:09] <henninge> Anyway, since I check the source language, I look at the file.
[16:09] <henninge> - Is the project open source?
[16:09] <abentley> henninge: I really don't feel like I could recognize a proper potemplate with a header.
[16:09] <henninge> oh
[16:09] <henninge> look at one, then ;-)
[16:09] <abentley> henninge: :-P
[16:09]  * henninge clicks master_utf8.pot in the queue
[16:10] <henninge> argh, chromium recognizes POT as Powerpoint TEmplate ...
[16:11] <henninge> abentley: the header is the first record with an empty msgid.
[16:11] <henninge> abentley: after that follow msgid/msgstr pairs.
[16:11] <henninge> abentley: the msgid contain English.
[16:12] <henninge> that's all.
[16:12] <abentley> henninge: And since this is a template, the msgstr is usually empty?
[16:12] <henninge> s/usually//
[16:13] <henninge> although you are right, it would not hurt AFAIK. We'd just ignore that information.
[16:13] <henninge> abentley: yes, that is correct
[16:14]  * henninge has to remember to communicate clearly.
[16:14] <abentley> henninge: not empty for header, though.
[16:14] <henninge> ;)
[16:14] <henninge> abentley: exactly, the header is special because here the msgid is empty.
[16:15] <henninge> abentley: to continue on the check list:
[16:15] <abentley> henninge: firefox makes that mistake too.  Suggests maybe Launchpad's using the wrong MIME type.
[16:16] <henninge> - Is the project open source? Since we cannot really remove translations, we like to double check if they are allowed to use LP for free and if the strings are not likely to be coprighted.
[16:16] <henninge> although, it would not hurt *that* much.
[16:17] <henninge> - More interesting: Is the project maintainer really representing the project? Does the project really want to use Launchpad for translations?
[16:17] <henninge> We do not want to ask translators to translate stuff that will never be accepted by the upstream project. Waste of their time.
[16:18] <henninge> It also creates bad feelings with projects that host their translations elsewhere and we don't want that either.
[16:18] <abentley> henninge: Okay.
[16:19] <henninge> - Finally: can you figure out a template name? If it is just "messages.pot" you could use the project name, else use the file name.
[16:20] <henninge> And that's all I have to say about that. ;-)
[16:21] <abentley> Okay, good to know.
[16:36] <mrevell> Hey, anyone know why I might be getting a 404 on Packages.gz when I add a new PPA to my system?
[16:36] <bigjools> mrevell: the PPA is not published yet perhaps
[16:36] <bigjools> is it a new one?
[16:36] <bigjools> it also needs packages in it to get published
[16:37] <mrevell> bigjools, They're both fairly well established PPAs (libreoffice/ppa and gtg/ppa) with packages in them.
[16:37] <bigjools> mrevell: it's probably pebkac then :)
[16:37] <jcsackett> can anyone qa bug 377519? i'm not sure how to go about it.
[16:37] <mrevell> Maybe I've just been unlucky with both PPAs. I'll try another
[16:37] <_mup_> Bug #377519: Stacked on location breaks if the stacked upon branch is renamed <branch-stacking> <lp-code> <qa-needstesting> <Launchpad itself:Fix Committed by thumper> < https://launchpad.net/bugs/377519 >
[16:38] <bigjools> mrevell: paste me the error
[16:38] <mrevell> bigjools, heh, I don't see how I can get add-apt-repository wrong :) here's the error: http://pastebin.ubuntu.com/596596/
[16:39] <bigjools> mrevell: well, you did.  Look at the URL ...
[16:39] <bigjools> "pp"
[16:39] <mrevell> pp, yeah, I spotted that
[16:39] <mrevell> but ... maybe hrm
[16:39] <mrevell> erm
[16:41] <mrevell> bigjools, Does this prove my innocence? http://pastebin.ubuntu.com/596597/
[16:42] <bigjools> mrevell: weird.  What does sources.list.d/thing.list have in it?
[16:42] <mrevell> bigjools, deb http://ppa.launchpad.net/libreoffice/ppa/ubuntu maverick main
[16:42] <mrevell> deb-src http://ppa.launchpad.net/libreoffice/ppa/ubuntu maverick main
[16:43] <bigjools> !
[16:43] <bigjools> wth is going on then
[16:44] <mrevell> Odd, eh
[16:44] <bigjools> is it repeatable?
[16:44] <mrevell> bigjools, Yes, so far with the two PPAs and both through Software Centre and the terminal. I'll try a third if you like.
[16:46] <bigjools> mrevell: I mean, does the apt-get update do the same thing next time
[16:46] <mrevell> bigjools yeah
[16:46] <bigjools> mrevell: well if sources.list is correct then it's an apt bug
[16:47] <bigjools> but there must be something else, I can't see that being wrong
[16:47] <mrevell> bigjools, Interestingly all my other PPAs are fine.
[16:47] <bigjools> mrevell: there's no weird crontrol char in the sources.list file is there?
[16:48] <mrevell> Ah crap, I've just done a dist-upgrade and didn't spot that it was planning to remove all of OOo. Why would it do that? That's an aside, though. Let me check for weird control chars.
[16:50] <bigjools> mrevell: conflicts
[16:50] <benji> abentley: after screwing up the MP a couple of times, I have a very small branch for review: https://code.edge.launchpad.net/~benji/launchpad/fix-help-link-3/+merge/58524
[16:50] <abentley> benji: looking...
[16:51] <mrevell> bigjools, I don't see anything odd. I've cleared out all the entries relating to these buggered PPAs from sources.list.d and I'm gonna try again.
[16:51] <bigjools> k
[16:53] <mrevell> bigjools, Okay, I don't know what's going on but I just re-added the libreoffice PPA and pulled down the index fine. I'll keep a look out to see if anything similar happens in future.
[16:54] <bigjools> !
[16:58] <abentley> benji: why db-devel?
[16:59] <benji> abentley: the branch that introduced the link is db-devel and it hasn't been deployed yet
[17:01] <abentley> benji: did you consider making can_edit a function?  That way you can avoid repeating the code.
[17:02] <benji> abentley: +1 I'll do that.
[17:03] <abentley> benji: aside from that, r=me
[17:03] <benji> cool, thanks
[17:04] <adeuring> abentley: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136
[17:04] <adeuring> could have a look?
[17:05] <abentley> adeuring: happy to.
[17:08] <abentley> adeuring: you have two "canWrite(productseries..." calls.  Why not combine them?
[17:09] <adeuring> abentley: dou you mean in setPackagingReturnSharingDetailPermissions()? That's what we discussed: The calls check for different actions.
[17:09] <adeuring> The result is at present the same for both calls, I know
[17:09] <abentley> adeuring: Right.
[17:10] <abentley> adeuring: But why are you defining canWrite to be variadic and then calling it twice?
[17:11] <adeuring> abentley: that was a suggestion from Gary. It might make sense in other circumstances to check several attributes at once.
[17:11] <abentley> adeuring: why not canWrite(productseries, 'branch', 'translations_autoimport_mode') ?
[17:12] <gary_poster> yeah, I said that might be nice.
[17:12] <abentley> adeuring: You imply that it doesn't make sense in these circumstances to check several attributes at once.  Is that what you mean?
[17:12] <adeuring> abentley: well, if you prefer that, we can do it that way. They idea for the separation was "just in case that the attributes will in the future have different permission settings"
[17:12] <gary_poster> I didn't know if it made sense to implement it now
[17:12] <abentley> adeuring: I'm not suggesting that you should check only one of the attributes.
[17:12] <abentley> I'm suggesting you should check two at once.
[17:12] <adeuring> ok let's do it.
[17:13] <gary_poster> (well, lazily and them I assume)
[17:14] <abentley> adeuring: canWrite returns a list, right?  So you're returning 1-entry lists in the dict?  Is that what you intend?
[17:15] <adeuring> abentley: no, it return simply True or False
[17:15] <abentley> adeuring: Oh, with this all thing.
[17:15] <abentley> gary_poster: did you intend to OR the permissions?
[17:16] <abentley> gary_poster: actually, I guess that's AND?
[17:16] <gary_poster> abentley: yes, AND
[17:16] <gary_poster> abentley, though it's entirely driven by use case in my own mind
[17:16] <gary_poster> It was a brainstorm at the time
[17:17] <gary_poster> if it is more useful to do something else, then, maybe
[17:17] <gary_poster> but AND seems nice and simple
[17:17] <gary_poster> and works if you only have a single permission
[17:17] <gary_poster> I'd be tempted to say that canWrite should always return a single bool
[17:17] <gary_poster> if you want a list of bools, make another method
[17:17] <abentley> gary_poster: IMO, the list is more general.
[17:18] <adeuring> well, that would not buy us much compared to list comprehensions
[17:18] <gary_poster> abentley, IMO, the bool is easier to use in the common case :-)
[17:18] <gary_poster> but I'm saying that if I'm wrong, then there you go, go with a list
[17:18] <abentley> gary_poster: and there's a case to be made for doing multiple lookups at once to improve performance.
[17:18] <gary_poster> but otherwise I'd advocate separate methods
[17:20] <gary_poster> abentley, yes.  They seem like both useful approaches to me, both of which could be used for improving performance.  Admittedly, the list approach could be used more generally, but at the cost of, IMO, awkwardness in the kind of case I'm imagining.  Again, I'd be driven by use cases, and I only have ones that I'm imagining.
[17:21] <abentley> gary_poster: in which case, YAGNI.  Especially because if you ever encounter those cases, you can extend it without changing the existing callers.
[17:21] <gary_poster> YAGN what?
[17:22] <adeuring> [user.canWrite(obj, attr) for attr in 'a', 'b'] does the same as returning a list
[17:22] <abentley> gary_poster: You Ain't Gonna Need It.
[17:22] <adeuring> in that case I#d prefer a single argument
[17:22] <gary_poster> abentley, I mean, what does "it" refer to it in your statement
[17:22] <abentley> gary_poster: variadic behaviour for canWrite.
[17:24] <abentley> adeuring: I prefer a single argument, too.
[17:24] <adeuring> well, ok...
[17:25] <abentley> adeuring: sorry, about the earlier suggestion.  I misunderstood why canWrite accepted multple arguments.
[17:25] <gary_poster> abentley, yeah, that's what I was saying at the time to adeuring.  variadic was interesting, but nothing to explore unless we discover we need it.  If there's already a use case, yay.  If not, let's move on.
[17:25] <gary_poster> The only point to consider then, though, is that if we are going that way, then we are saying that canWrite returns a bool.  That contract can be continued in a hypothetical variadic future if results are ANDed together.
[17:25] <gary_poster> but I'm thrilled to defer that conversation to a later time.
[17:26] <abentley> gary_poster: right, that's what I meant by "if you ever encounter those cases, you can extend it without changing the existing callers."
[17:26] <gary_poster> cool, I think we're on the same page then abentley.
[17:30] <sinzui> Ursinha: ping
[17:30] <Ursinha> sinzui, pong
[17:30] <Ursinha> hi
[17:30] <Ursinha> what's broken
[17:30] <Ursinha> ?
[17:30] <sinzui> Ursinha: I am trying to reproduce an oops. This one indirectly involved you: https://lp-oops.canonical.com/oops/?oopsid=OOPS-1935REPORTIFSEEN298
[17:31]  * Ursinha looks
[17:31] <sinzui> Ursinha: I do not think you got an email about Rodrigo Catto  joining https://launchpad.net/~ubuntu-br-rj, which you are an admin for via https://launchpad.net/~conselhobrasil/+members
[17:32] <Ursinha> sinzui, let me see, I archive all those emails without reading them
[17:32] <sinzui> Ursinha: do you know if any of the admin members changed something about their email address or the team itself https://launchpad.net/~conselhobrasil
[17:33] <sinzui> I have created what I see, but do not get an oops :(
[17:33] <adeuring> abentley: new version pushed
[17:33] <Ursinha> sinzui, the team has no contact email
[17:33] <Ursinha> which is wrong
[17:33] <Ursinha> grrr
[17:34] <Ursinha> I should be admin of that team
[17:34] <sinzui> Ursinha: I testing a NEW email address for the team, but that did not cause an oops either
[17:35] <Ursinha> maybe the owner changed that, but he said anything
[17:35] <Ursinha> I can try to contact him
[17:36] <sinzui> thanks Ursinha
[17:36] <Ursinha> np, sorry not being more helpful
[17:39] <abentley> adeuring: documentation needs to be updated to refer to a single attribute, not "all given attributes of the object"
[17:39] <adeuring> gahh, sure
[17:40] <adeuring> done
[17:46] <abentley> adeuring: In "test_canAccess__anonymous", are you sure we're not already logged in as a user?  I thought that was part of the standard TestCase setup.
[17:46] <adeuring> abentley: I'm quite sure that we aren't
[17:47] <abentley> adeuring: okay.
[17:48] <Ursinha> sinzui, one of the members changed the contact address for the ubuntu-br-rj team
[17:51] <abentley> adeuring: This looks good.
[17:51] <abentley> adeuring: r=me.
[17:51] <adeuring> thanks
[17:51] <abentley> adeuring: one grammar nitpick
[17:52] <abentley> adeuring: "but return a dictionary which tells if the current user" => "but returns a dictionary which says whether the current user"
[17:53] <adeuring> whopps, I'll fix it
[17:53] <abentley> adeuring: intransitively, "tell" means something like "determine".  "I can tell it is raining when I look outside" vs "I will tell adeuring that it is raining."
[18:00] <mrevell> Night all
[19:17] <LPCIBot> Project windmill build #199: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/199/
[19:43] <sinzui> Ursinha: I solved the issue I with the oops. I had setup the admining team with members wrong. I reproduced the oops and now have a fix
[19:44] <Ursinha> ah, cool
[19:52] <jcsackett> lifeless: i made the changes you suggested on https://code.launchpad.net/~jcsackett/launchpad/bug-expiration-doesnt-oops/+merge/58412, if you would care to take another look at somepoint today.
[19:52] <jcsackett> thanks for the catch, by the way. i clearly didn't think that one through. :-P
[19:56] <lifeless> jcsackett: :)
[20:25] <sinzui> Oh Empathy, how you continue to disappoint
[20:25] <sinzui> abentley: I cannot see the topic be Empathy hates this one channel. Are you reviewing and if so, do you have time to review https://code.launchpad.net/~sinzui/launchpad/person-transfer-permission-0/+merge/58561
[20:26] <abentley> sinzui: Yes and yes.
[20:33] <abentley> sinzui: did you consider testing for DB permissions by just running the code using the correct database user?
[20:54] <sinzui> abentley: I did not
[21:04] <benji> abentley: are you ready for the most exciting MP you'll review all day? https://code.edge.launchpad.net/~benji/launchpad/update-sampledata/+merge/58563
[21:04] <abentley> benji: actually, I'm trying to ascertain the scope of an operational issue atm.
[21:05] <benji> abentley: well, if you can resist that incredible branch, then go ahead
[21:06] <jcsackett> benji, abentley: i'll take a look at it so abentley can focus on the ops issue.
[21:07] <benji> jcsackett: much obliged
[21:11] <abentley> flacoste: we seem to have some busted pickers on production.  http://pastebin.ubuntu.com/596682/
[21:12] <abentley> flacoste: So far, Questions and Sprints, but not bugs or translation sharing seem to be affected.
[21:13] <abentley> flacoste: Busted means when you select a choice from the picker, absolutely nothing happens.
[21:13] <abentley> flacoste: no javascript error, nada.
[21:14] <abentley> flacoste: joey reported it and says it's affecting Linaro track leads.
[21:16] <jcsackett> benji: r=me.
[21:17] <benji> jcsackett: thanks!
[21:18] <sinzui> jcsackett: do you have time to mumble about some oopses I am looking at
[21:19] <jcsackett> sinzui: sure.
[21:22] <abentley> lifeless: ^^ I think this is a critical isssue.  Do you agree?
[21:23] <flacoste> abentley: yes, it does
[21:23] <flacoste> it's a regression
[21:23] <flacoste> is there a bug filed yet?
[21:23] <abentley> flacoste: No.  I was going to start an incident report next.
[21:26] <flacoste> abentley: good
[21:27] <flacoste> abentley: it's sounds like a regression from wallyworld fix to the assignee widget on the bugs page
[21:27] <flacoste> sinzui: ^^^wdyt?
[21:32] <lifeless> abentley: busted how?
[21:32] <abentley> flacoste: I have no active line manager.  Will you nominate an owner for the incident report?
[21:32] <lifeless> abentley: if its that they aren't working, it should be ready for deploy
[21:33] <abentley> lifeless: when you select an entry using the picker, the picker disappears, but nothing further happens.
[21:33] <lifeless> the fix is in https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[21:33] <lifeless> Revision 12868 can be deployed: qa-ok
[21:33] <lifeless> Fixes: Bug:761494
[21:33] <abentley> lifeless: https://wiki.canonical.com/IncidentReports/2011-04-20-LP-Broken%20pickers#preview
[21:33] <flacoste> sinzui: since deryck is out sick, can you take care of this incident?
[21:34] <lifeless> and Revision 12880 can not be deployed: needstesting
[21:34] <lifeless> so the next thing to do is to complete qa and check its working on qastaging
[21:38] <lifeless> Ursinha: also - see rev 12879 in https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html - bug not linked
[21:42] <abentley> lifeless: could we deploy 12868?  That seems like it would solve the critical issues.
[21:42] <lifeless> we need 12880
[21:42] <lifeless> I'm just qaing it now
[21:43] <sinzui> jcsackett: Question:+huge-vocabulary
[21:43] <sinzui> oops
[21:43] <sinzui> jcsackett:  https://devpad.canonical.com/~lpqateam/oops-summaries/production-2011-04-18.html
[21:45] <abentley> lifeless: I think we should post this issue in identica.  Do you agree?
[21:47] <lifeless> bah
[21:47] <lifeless> it would be nice if the battery applet told me *before* running out of battery.
[21:49] <lifeless> ok, we should be completely qaed when the next run goes through
[21:49] <lifeless> queuing up a deploy request
[21:51] <abentley> sinzui: can you please act as communications liason for this incident?
[21:51] <sinzui> abentley: I will take it
[21:51] <abentley> sinzui: thank you.
[21:52] <abentley> sinzui: I've updated the #launchpad topic only, so far.
[21:54] <abentley> lifeless: I am approaching EOD.  Can you take it from here?
[21:55] <lifeless> abentley: sure
[21:56] <abentley> lifeless: thanks.
[22:02] <Ursinha> lifeless, I believe I found out the problem, working on a fix
[22:02] <lifeless> Ursinha: cool
[22:03] <lifeless> flacoste: ah that was it
[22:03] <lifeless> flacoste: the ppr is failing to write output again
[22:03] <flacoste> lifeless: yes, i saw that on the lpstats view
[22:04] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/daily_2011-04-17_2011-04-18/
[22:04] <flacoste> lifeless: i'll look into this, it's my next target
[22:04] <lifeless> I don't know why
[22:04] <lifeless> flacoste: that would be awesome; if you are too busy though I can ask stub to do so
[22:05] <lifeless> flacoste: I mentioned the error rates for private bugs right ?
[22:06] <lifeless> flacoste: you may find this interesting again - https://devpad.canonical.com/~lpqateam/dbr/last-15-mins.txt
[22:06] <lifeless> bloat reports
[22:13] <sinzui> lifeless: flacoste I was looking at an older ppr report today, and the oops reports. It is time to send question emails async. That will fix 8 of the top 10 durations
[22:15] <lifeless> sinzui: yes! yes! yes! omg yes!
[22:15] <lifeless> sinzui: also perhaps send less mail on 'convert to question'.
[22:15] <sinzui> yes
[22:15] <lifeless> sinzui: Relatedly, why do I get mail from questions that were turned into bugs when the bug changes status ?
[22:15] <lifeless> sinzui: I'm already subscribed to the bug...
[22:15] <sinzui> I just had my initial implement talk with jcsackett about that
[22:16] <sinzui> lifeless: answers and bugs are separate apps with separate email mechanisms
[22:17] <lifeless> sinzui: is it desired though?
[22:17] <lifeless> or a bug?
[22:18] <sinzui> No one wants duplicate emails, but we do not yet have a mechanism that can check that you do not
[22:19] <lifeless> sinzui: what changes on a bug are meant to trigger question notifications ?
[22:20] <lifeless> sinzui: [could we consider the question a 'team' subscribed to the bug, and have the main email code handle things]
[22:20] <sinzui> We would need an identifier for every event and store it with who got it. We can then  say Robert was sent email about x. All things that want to send email need to check the log to verify it is not a duplicate
[22:21] <sinzui> lifeless: I think the IBugLink creates a subscriber. The bug link could be to a question, branch, or spec
[22:22] <lifeless> sinzui: what I mean is, if we remove the question event listener and instead treat the question as a source of direct subscriptions *with a filter for the events important to questions*
[22:22] <lifeless> then the new bug notification stuff will:
[22:23] <lifeless>  - handle the mail async for us
[22:23] <lifeless>  - only send one notification to folk subscribed via both paths
[22:23] <lifeless>  - (or send none if they have muted the bug etc)
[22:23] <sinzui> That may work, so long as the bug code is also changed to dedupe you. It does not at this time
[22:24] <lifeless> sinzui: sure it does
[22:24] <lifeless> sinzui: I was reading the code yesterday
[22:24] <lifeless> lib/lp/services/mail/notificationrecipientset.py
[22:24] <lifeless> add()
[22:25] <lifeless> if you are subscribed directly, and via two different teams, bugs only mail you once
[22:25] <sinzui> That does not know you are getting email from a team with an email address
[22:25] <sinzui> and if the address is an lp mailing list
[22:25] <lifeless> thats true, but thats not the case thats bothering me with lp questions :)
[22:25] <lifeless> its also a problem for lp questions
[22:27] <lifeless> anyhow, this isn't critical
[22:28] <lifeless> it just struck me the other day when I closed a bug which had an attached question
[22:28] <lifeless> I have 'do not mail on own actions' turned on
[22:28] <sinzui> You reported a bug about it about 2 years ago
[22:28] <lifeless> heh, probably :)
[22:28] <sinzui> so did jml from another path
[22:28] <lifeless> I wonder if a breakdown of bug reporters in lp would be interesting.
[22:29] <sinzui> I do not think anyone will challenge mpt
[22:29] <sinzui> Wgrant tried
[22:32] <lifeless> hmm, missed gary
[22:32] <lifeless> sinzui: anything I can do for you guys today?
[22:33] <sinzui> lifeless: Getting ian's fix released is my immediate concern
[22:33] <lifeless> its in the automatons hands now
[22:34] <lifeless> sinzui: could I perhaps ask you|ian to do the incident report ?
[22:34] <sinzui> lifeless: we will
[22:36] <lifeless> coo
[22:36] <lifeless> l
[22:46] <LPCIBot> Project windmill build #200: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/200/
[23:08] <lifeless> sinzui: deployed
[23:09] <sinzui> thanks. I was just sending the annoucement
[23:09] <lifeless> cool!
[23:10] <lifeless> 10626231 renders by the lpnet zope appservers, excluding xmlrpc, including operational stats gathering.
[23:10] <lifeless> its a little sad that 3M requests are basically nagios and haproxy whinging
[23:10] <lifeless> but shrug
[23:10] <mwhudson> lifeless: is that daily?
[23:10] <lifeless> mwhudson: yes
[23:10] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-categories.html
[23:11] <mwhudson> cool
[23:11] <lifeless> 1.64 99th percentile today
[23:11] <lifeless> so even midweek we're still stable down low
[23:12] <lifeless> I don't believe this category - Bugs - Bug Page
[23:12] <lifeless> ^https?://bugs\.[^/]+/.+/\+bug/\d+$ 5738
[23:13] <lifeless> we can't possibly do only 5.7K bug renders a day
[23:17] <thumper> lifeless: so what are the popular pages?
[23:18] <james_w> lifeless, that doesn't count bug task renders, which is what you get redirected to from that url isn't it?
[23:28] <LPCIBot> Project windmill build #201: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/201/
[23:31] <lifeless> james_w: it should match tasks
[23:31] <lifeless> https://bugs.launchpad.net/udd/+bug/767711
[23:31] <_mup_> Bug #767711: some kde4libs bugfix branches not visible on the bug page <Launchpad itself:Incomplete> <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/767711 >
[23:31] <lifeless> is a typical final url
[23:32] <lifeless> thumper: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-top200.html
[23:32] <lifeless> 500K https://launchpad.net/codehosting/translatePath
[23:33] <lifeless> 200K https://launchpad.net/mailinglists/getMembershipInformation
[23:33] <thumper> haha
[23:33] <thumper> pushing branches :)
[23:33] <lifeless> 350K https://api.launchpad.net/beta/ubuntu
[23:33] <lifeless> 150K https://launchpad.net/+access-token
[23:34] <lifeless> 1.1K https://bugs.launchpad.net/bugs/766412/+bug-portlet-subscribers-content
[23:34] <lifeless> (yes, that specific portlet is top-200)
[23:34] <lifeless> 1.1K https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats
[23:34] <lifeless> 1.1K https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-tags-content
[23:35] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-pageids.html is the interesting one in terms of templates
[23:37] <lifeless> Bug:EntryResource 588039
[23:37] <lifeless> 550K DistroSeries:EntryResource
[23:37] <lifeless> 500K CodehostingApplication:CodehostingAPI
[23:37] <lifeless> 411K Unknown
[23:37] <lifeless> (yes, thats a wtf)
[23:38] <lifeless> 400K Person:EntryResource
[23:38] <lifeless> 370K RootObject:+login
[23:38] <lifeless> 300K Distribution:EntryResource
[23:38] <lifeless> 270K SourcePackage:EntryResource:getBranch
[23:38] <lifeless> 230K MailingListApplication:MailingListAPIView
[23:39] <lifeless> 200K Distribution:EntryResource:
[23:39] <lifeless> getSeries
[23:39] <lifeless> 200K BugTask:+index
[23:39] <lifeless> so logging in following by bugtasks are our two highest visibility end user pages
[23:39] <lifeless> highest frequency I mean
[23:40]  * thumper nods
[23:41] <lifeless> I suspect something off in the login case too
[23:41] <lifeless> e.g. the bug with edge losing credentials for users.