[00:00] as I said, im not very familiar with this part.. thats why I invited Ronnie and I've invited mhall119 here as well [00:01] im not familiar with the lp code too, it was created before i started hacking, but i think i know where too look [00:01] if mhall119 makes it, hes the most familiar i believe [00:01] hola [00:01] hey [00:02] mhall119: < lifeless> whats the api call you make to find out about the members of the team? [00:02] < lifeless> cjohnston: do you verify their lp uids? [00:03] no, we assume that the openid response 'nickname' matches the launchpad username [00:03] lifeless: see... i told you he would know the answers [00:03] That's not ideal. Is there a reason you can't check the OpenID identifier? [00:04] howdy wgrant [00:04] wgrant: what do you mean? [00:04] mhall119: LP usernames are mutable. [00:05] http://paste.ubuntu.com/563231/ is what we do [00:06] wgrant: I know, I have a merge proposal in to django-openid-auth that'll update the username on our end when the user logs in [00:06] can we look it up based on the identity url? [00:06] mhall119: Probably not at the moment. But that can be fixed easily enough. [00:06] we're using the launchpadlib [00:07] wgrant: we have the openid identity url, we can change our lookups to use that instead of username if/when that interface is available [00:08] lp.people[ld_user.username] is doing a lookup on the People collection exposed by the webservice API to launchpadlib [00:08] Right. [00:08] We can easily expose a method on lp.people to get a person by an OpenID identifier. [00:09] our other problem, and I'm not sure if you can help us with that, is that SSO sometimes returns a response without a 'nickname' field, even when the user has a launchpad profile [00:10] For particular users? [00:10] I suppose once we can do lookups based on the identity url, we can change our code to get nickname for that [00:10] wgrant: let me see if I can find the name [00:10] SSO has a bug like that for some users at the moment. It's fixed, but not yet rolled out. [00:11] I investigated it with one particular LD user a couple of weeks ago. [00:11] wgrant: that might have been for us [00:11] i thought (but am not sure) that it was for users with unicode characters in the name [00:11] So, known SSO issue, fixed in trunk a month or so ago, but awaiting deployment. [00:11] wgrant, lookup based on identity url would be spiffy [00:12] Sadly it'll be a few days, because we are frozen for the release. [00:13] well we've been dealing with this for months, another few days isn't going to kill us [00:13] mhall119: cant we check if the username has changed each login? [00:13] Ronnie: we can, yes, infact I have a code change to that pending with django-openid-auth [00:14] but we don't want to wait on them to log in to LD, after changing their username in LP, for us to get their profile information again [00:14] if so, we can do checkups with the username instead of identity, right/ [00:14] in theory, but again we'd have to wait for them to log in [00:14] wgrant: I think there is a bug already requesting openid lookups [00:14] lifeless: I tried to find it. [00:14] But couldn't. [00:14] if we can do lookups based on identity url, we can get updated during our nightly refresh [00:15] Oh. [00:15] Possibly bug #655565 [00:15] <_mup_> Bug #655565: Immutable reference to users in API

< https://launchpad.net/bugs/655565 > [00:15] yes [00:15] mhall119: so separately I'd like to get away from polling for updates [00:15] mhall119: would pubsubhubbub work for you, if we implemented it ? [00:16] is it strange that every time I see a number that starts with '655' I automatically think "oh no, integer overflow!" [00:16] ah, a 16 bitter [00:16] pubsubhubbub? [00:16] lifeless: Thinking of future plans, is there any reason not to expose a collection of OpenID identifiers, and a method to get a person by one? [00:16] * mhall119 has actually barely ever written C code [00:16] mhall119: http://code.google.com/p/pubsubhubbub/ [00:16] wgrant: collection - yes, person - no [00:17] wgrant: but perhaps I'm being paranoid in objecting to such a collection [00:17] Once we support non-SSO authentication we may want to grant people the ability to make identifiers private, but I don't see much reason to not expose all the releated SSO ones now. [00:17] wgrant: it just seems a little too like iterating /etc/passwd [00:17] lifeless: are they talking real multicast? [00:18] lifeless: I mean something like lp.person['wgrant'].openid_identifiers [00:18] wgrant: that would be fine with me; might want to check if stuartm has any reservations [00:18] We already expose the primary one in the HTML. [00:18] wgrant: I thought you meant lp.openid_identifiers [00:18] Ah, no, that would be pointless. [00:19] yeah, I can already get a person's identifier if I have their username [00:19] mhall119: its point to point but with hubs that multiplex [00:19] lifeless: I'm sure we could implement whatever needs implementing on our end to achieve that [00:20] ok [00:20] I suspect we can nuked 20 or 30 % load if we do this. [00:20] But someone is going to need to do some hard core log analysis to confirm that [00:21] back to our mugshot. what is exactly the problem? [00:23] ok [00:23] so the LD page includes a reference to an api attribute which is the mugshot object; this acts like a symlink - it gets resolved and then does a 302 [00:24] if the object isn't there, you end up with a redirect to the containing object AFAICT - the user page. [00:25] there are several problems with just embedding the LP API url [00:25] firstly, its slow for users: you make them do 2 new https lookups [00:25] lifeless: The bug seems to say that OpenID identifiers are not sufficient to fix it. But I think they are reasonable for this use case, so I'll open a separate bug. [00:26] one to LP, which does a webapp request, then issues a 302, then a new https connection to th e librarian, which finally shows the content [00:26] if you're on http you don't even actually want https but you have no choice as lp won't answer on http [00:26] wgrant: is it right? [00:27] wgrant: https://bugs.launchpad.net/launchpad/+bug/655565/comments/3 ? [00:27] <_mup_> Bug #655565: Immutable reference to users in API

< https://launchpad.net/bugs/655565 > [00:28] Ronnie: secondly, LP doesn't expose a magic object - one that transparently fills in the default mugshot if none is set [00:28] lifeless: In this case I don't think they're really tracking LP users. They're tracking SSO users, getting extra info on them from LP. [00:28] The LD case, that is. [00:29] Ronnie: and arguably it shouldn't, because that would make it harder for actual API clients (rather than img dereferences) to use; it would be very special case. [00:29] lifeless: LD checks if the user's logo_link starts like a URL, and sets a default if it doesn't [00:29] Ronnie: LP doesn't want such a magic attribute itself, because it would be heinously slow [00:29] mhall119: http://loco.ubuntu.com/events/team/666/detail/ - broken images here [00:30] yeah, I'm not sure sure why [00:30] http://paste.ubuntu.com/563231/ shows the code we use set the mugshot url [00:30] also, you guys know not to use edge, right ? [00:30] yes, cjohnston already submitted a fix to that [00:30] http://blog.launchpad.net/general/edge-is-deprecated [00:30] cool [00:30] nigelb pointed it out earlier today [00:30] great [00:31] just ensuring the message is out there :) [00:31] edge has our oldest servers [00:31] so moving off it will help you [00:31] yeah, we've been migrating off [00:31] just a few things we overlooked [00:31] cjohnston: your lp login still uses edge: def lp_login(lp_instance=EDGE_SERVICE_ROOT): [00:32] Ronnie: I think it only uses that for local setups [00:32] still should be changed [00:32] or not [00:32] launchpad has dropped the EDGE_SERVICE_ROOT constant [00:33] lifeless: we had some issue with using openid from behind a firewall, I think is why we used different servers [00:34] Also, you should probably be using the devel API. [00:34] Rather than beta. [00:34] or 1.0 [00:34] I like to consider 1.0 a deprecated mistake :) [00:34] if the software is packaged, 1.0, if its just a live website you update a lot devel is fine. [00:35] what's the url for the devel api? [00:35] mhall119: Which version of launchpadlib are you using? Lucid's? [00:35] version='devel' in the login call to launchpadliv [00:36] henninge: ping [00:36] wgrant: yeah, lucid [00:36] mhall119: lifeless' suggestion will work, then. [00:37] that'll work with login_anonymously too? [00:38] yes [00:38] Use something like Launchpad.login_anonymously('Loco Directory', 'production', version='devel') [00:39] got it https://bugs.launchpad.net/loco-directory/+bug/713868 [00:39] <_mup_> Bug #713868: Use Launchpad devel API < https://launchpad.net/bugs/713868 > [00:39] thanks [00:39] ok [00:39] our logo_link and mugshot_links are crack. [00:39] Are they? [00:40] good crack or bad crack? [00:40] bad [00:40] is there something better we can be using? [00:40] lifeless: Because they always link to the same URL? [00:40] we need to fix them [00:40] Which then redirects to the librarian? [00:40] wgrant: because they link to appserver code [00:41] but for a public person (all people atm) we should just emit the librarian reference immediately. [00:41] the whole LFA->LFC chain will complicate the performance of this slightly [00:42] but we don't have a use case for 'can query the person and not their logo' [00:45] Oh, Squeeze has happened. [00:46] wgrant: feel like eyeballing apartial patch adding a new package - lp.testing as a webservice entity - and see if I've massively missed anything? [00:46] lifeless: Sure. [00:47] http://pastebin.com/CaTTajjy [00:48] lifeless: Uh, lp.testing is probably not what you are looking for... [00:48] wgrant: well, I thought that might be contentious ;) [00:49] wgrant: OTOH, there is a certain logic to i. [00:49] it. [00:49] There is, but this does not work. [00:49] We need to move one or the other. [00:50] lifeless: Why are we storing subunit streams in LP, anyway? [00:50] wgrant: so we can get them back out again [00:50] lifeless: I don't really see why this is in scope for LP. [00:50] mhall119: cjohnston: https://bugs.launchpad.net/launchpad/+bug/713873 [00:51] <_mup_> Bug #713873: Person.logo_link is hard to use and performs poorly < https://launchpad.net/bugs/713873 > [00:54] Ugh. [00:55] Do we have a branching-debian process that we need to run for squeeze->wheezy branches? [00:56] I guess the Ubuntu script will work just as well. [00:57] well [00:57] this is why the 'lets make sid the dev focus' [00:58] I'm not sure the script will work too well in that case. [00:58] But yes. [00:59] wallyworld_: Hi! in a rush ... [01:00] wallyworld_: but thanks for the approval! I'll see to it first thing on Monday. [01:00] :( They've created wheezy already. [01:01] man, I don't understand why we get 170 updates to lucid :< [01:01] I hope the package importer is using 'squeeze', not 'testing', like gina was last time. [01:02] it was discussed on the caonical bazaar list, james_w seemed unconcerned about the basic correctness aspects [01:03] Is ~canonical-bazaar going to handle the branches side of the new series? [01:03] Including running branch-distro.py. [01:04] wgrant: so you think using lp.testing as is will be too confusing ? [01:04] lifeless: Yes. Using it for something other than internal testing utilities is crack. [01:04] Well, more precisely, using it for both is crack. [01:04] wgrant: its probably too late for the script; the new branches will be populating right now [01:04] they'll all stack [01:05] No they won't. [01:05] has the development focus changed already? [01:05] The new series doesn't exist yet. [01:05] then they won't be created [01:08] However, the new series will be created and imported package-wise on Monday, unless the branch importer means I can't ask for that. [01:08] It would be best to stop it, then create, run the branch script, then start it. [01:08] *or* [01:09] stop it, create, make sure sid is the development focus, run the branch script, then start it., [01:09] I've stopped the importer [01:09] (and that way we never have this again) [01:10] OK, so. Tomorrow I will convince a LOSA to make lenny supported, squeeze current, sid development, and create a future wheezy. [01:10] yes [01:10] Then we can fix gina crontabs, run branch-distro, and the package importer can be restarted at our leisure. [01:11] it would also be nice to restack the rest of the branches on sid, but that's a bit hard. [01:11] the branch script moves the current ones to the new dev [01:11] then branches *back* [01:11] Right. [01:11] oh you mean -2 etc [01:11] meh [01:11] Ah, and in this case we probably don't have lenny branches. [01:11] yes, in principle. [01:13] wgrant: were there any other things about the patch; [01:13] lifeless: Your security is crack. [01:13] It should inherit it from the branch. [01:14] wgrant: how does one do that - I knew thats what I wanted, but not the mechanism to do so [01:14] lifeless: See things like CodeReviewCommentView [01:15] You do the delegation manually. [01:15] Or you write a base class which automates it :) [01:15] anything else? [01:16] lifeless: Your security ZCML doesn't use your security adapter. [01:17] You need to require launchpad.View [01:17] Not allow. [01:17] wgrant: sure, but thats tied to the other bit; thanks for being complete though. [01:18] I also wonder how linkStream will function if the UUID doesn't exist. [01:18] Apart from that it looks good. [01:18] henninge: no problem. thanks [01:18] wgrant: it will blow up, which is ok [01:18] lifeless: It will probably OOPS, which is not OK. [01:18] well [01:19] indeed, I guess. [01:19] however, I'm willing to land and iterate [01:19] It's probably another three lines to fix this and avoid a Critical bug. [01:20] if its that simple, cool. [01:20] I can has patch? [01:22] I'll be shelving this until next weekend I suspect [01:23] lifeless: Check if TSM.fetch returns None, if so raise some webservice-annotated exception. [01:23] If there is no appropriate webservice-annotated exception, three lines create a new one. [01:26] whats the one for 404 [01:27] Is a 404 appropriate here? Possibly, I guess. [01:27] if the uuid is absent [01:27] the spec is ambivalent :) [01:27] There's lp.app.errors.NotFoundError. [01:27] I am not entirely sure if that's annotated. [01:30] james_w: So can we go ahead and run branch-distro.py on Monday? [01:30] I don't see why not [01:30] It worked fine for Natty, so it seems safe enough. [01:34] D: [01:56] wgrant: hey, you were looking at bug 32464 [01:56] <_mup_> Bug #32464: guess_bugtask() fails on distribution tasks without a source package < https://launchpad.net/bugs/32464 > [01:56] wgrant: I thought you found the bug still existed? [02:02] hmm [02:02] we really need a profile for where the python time in oopses like OOPS-1862C1669 [02:03] 33. 8790 35ms SQL-launchpad-main-slave [02:03] SELECT ValidPersonCache.id [02:03] FROM ValidPersonCache [02:03] FROM ValidPersonCache [02:03] WHERE ValidPersonCache.id = %sLIMIT 1 [02:03] 3 seconds between those trivial queries [02:08] flacoste: OOPS-1862C1669 - these are the things making me think we're running into GIL overload quite a bit atm. I think we're going to need to escalate single threaded to the top rather than waiting for RFWTAD [02:08] flacoste: same situation we had with the xmlrpc; same symtoms, and it was totally fixed when we gave it more resources. [02:11] lifeless: It doesn't fail. It just does insane things, but the whole method is insane, so that's OK. [02:11] ok [02:11] cool, thanks. [02:11] Yes, I was a bit surprised when he closed it too. [02:12] wgrant: do you know where jon is at with bug 421901 ? [02:12] <_mup_> Bug #421901: Person:+bugs timeouts < https://launchpad.net/bugs/421901 > [02:14] lifeless: Still actively working on it. [02:14] Was going to talk to deryck about a couple of things, IIRC. [02:19] 15 second query [02:25] wgrant: ok, I'm going to do some analysis, on the basis that he seems stalled, and that sucks, [02:29] Uhoh, they are going to enable testing migrations again tomorrow. [02:29] A few days earlier than I expected :( [02:29] ? [02:30] wheezy isn't going to be static for long. [02:31] ahha [02:31] its 'commented on' [02:31] that is terribad [02:32] Of course. [02:32] well [02:32] its poorly constructed [02:32] no particular reason it should be bad [02:33] -wow- minutes of runtime on qas [02:33] hahahaha [02:33] 8.4 fallout [02:34] the inner correlated join is the problem I think [02:34] 178 seconds cold [02:35] Ouch. [02:35] 20 hot [02:58] heh [02:58] apport has commented on more bugs than anyone else [02:58] seb128 a close second [02:59] Heh. [03:03] ok, wrapped in a bow and ready to cod [03:03] e [03:06] wgrant: is there anything you were needing extra inspiration on? === Ursinha is now known as Ursinha-zzz [04:40] lifeless: Re your bugs about mugshot and logo -- there is precendent for that -- build records have a build_log_url property that is None if there none or a librarian URL if there is one [04:41] cool [04:47] Why is OpenIDRPSummary still in the LP tree? :/ [04:50] Ah, it's still used to warn about account renames. [04:50] But it seems to no longer be used. [04:50] mawson's latest record is from April. [04:52] Perhaps we should make profile delegation optional, and warn on rename if it's delegated at all. [04:53] I wonder what SF.net does. [04:53] They have relatively unawful OpenID support. [04:54] Ah, indeed. Delegation is optional, and you can select the identifier that you wish to delegate to. === Ursinha-zzz is now known as Ursinha-afk [17:00] * maxb is surprised to be able to wget https://api.launchpad.net/1.0/branches?ws.op=getByUrl&url=lp:bzr without any oauth fiddling [17:00] When did that happen? [17:54] morning [17:54] maxb: 6 july last year [18:53] allenap: around per chance ? [18:55] ah [18:55] actually brad [18:55] bac: ping [21:02] thumper: morning. did we need a call this morning? [21:03] wallyworld_: hi [21:03] wallyworld_: I'm trying to leave the office to get coffee and a warrent for the car [21:03] but got suck clearing through emails [21:04] thumper: np. ping me later if required [21:04] i've had my coffee :-) [21:05] phew [21:05] just done with the email [21:05] wallyworld_: how's your recipe work going? [21:07] thumper: ok. didn't get much else done with those forms. been doing rm stuff - just landing r-c db-devel branch for julian now. gotta get that done asap [21:07] ok [21:58] gah [21:58] found out that it was "self..." that was screwing up my js tests, should be "this.foo" [22:01] heh [22:15] https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740 [22:39] Has anyone hit this problem when using rocketfuel-branch today? Error: Couldn't find a distribution for 'windmill==1.5pre-deryck' [22:40] update your download cache [22:42] lifeless: How do I do that. There were instructions on the wiki, but they got removed :( [22:42] they did? [22:43] I cd to the download cache and run bzr update [22:43] well they were on the canonical wiki [22:44] Set up canonical.testing.layers.DatabaseLayer in 10.542 seconds. [22:44] Set up canonical.testing.layers.LibrarianLayer in 16.152 seconds. [22:44] * StevenK peers at his machine [22:45] StevenK: hot last night? meant to be the hottest on record [22:46] wallyworld_: Last night? No, last night was fine, it was the night before that [22:46] ah ok. [22:47] 41degC during the day, and it only dropped to 36 inside or so when Sarah and I went to bed. [22:48] * wgrant wonders how to QA r12321. [22:50] lifeless: Thanks that's fixed it. Just so I can understand, what does that download-cache do? [22:51] its where we have buildout configured to 'download' from [22:51] rather than grabing untrusted stuff off of the net [22:52] wgrant: not sure but thanks for looking. btw i'm doing r12315 as soon as i get a feature flag enabled [22:52] wallyworld_: I just did that. It's not behind FF, though -- it's just plain disabled. [22:52] So there is no change, as long as existing subscriptions work. [22:52] lifeless: Right. Thanks. [22:52] Which they do. [22:53] wgrant: i the advanced fields alluded to in the bug report and qa notes are hidden behind a feature flag i thought? [22:53] or maybe i missed something [22:53] use_advanced_subscriptions is hardcoded to false for now. [22:53] It *should* be behind FF. But it isn't. [22:54] so how did you test then if advanced_sub is false? [22:54] I tested that the JS around it still works. It's impossible to QA the stuff inside the change, but I know it didn't break anything that is not disabled. [22:54] And that is what matters. [22:55] sure, but the bug also talks about updating the bug notification level field [22:55] and that can be tested if the advanced subscriptions were enabled [22:56] s/bug/mp [22:59] Ahem, a couple of Unity crashes later... [22:59] ne [22:59] * StevenK glares at Do [22:59] I didn't realise you were looking at that bit, sorry. https://bugs.dogfood.launchpad.net/ubuntu/+bug/1234/+subscribe is where I QA'd that, since I can add FFs there. [22:59] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [22:59] wallyworld_: ^^ [23:02] * wallyworld_ looks [23:04] Um, it seems to not have come back up properly after I pulled the debversion stuff. [23:05] Hrmm. [23:05] wgrant: that page on dogfood errors for me. [23:06] :-( [23:06] car needs two new tires [23:06] I'm home to collect charger and usb cable so I can continue to work from town while care is getting fixed [23:07] at least #launchpad is quiet on Mondays [23:07] thumper: i think you meant to say "tyres" :-P [23:08] wallyworld_: what ever.... [23:08] stupid english language [23:08] no, the english language is fine. it's "american english" that is broken :-) [23:08] * thumper afk again [23:14] wallyworld_: It's back now, but that restart destroyed the cache, so Launchpad bug heat updates time out like on qas... however it still works fine on smaller projects like https://bugs.dogfood.launchpad.net/ivle/+bug/647286/+subscribe [23:14] <_mup_> Bug #647286: Ability to import/export exercises and worksheets < https://launchpad.net/bugs/647286 > [23:14] wgrant: thanks [23:19] wgrant: the rev on dogfood is too old to qa 12315 [23:19] launchpad@mawson:/srv/launchpad.net/codelines/current$ bzr revno [23:19] 10180 [23:20] Not sure what updates the footer. [23:20] But it clearly hasn't happened in a while :/ [23:20] yup :-) [23:20] * wgrant goes Makefile diving. [23:25] hi all [23:26] wallyworld_: The footer no longer lies. [23:26] cool [23:27] But we have a LOSA now anyway. [23:27] wgrant: Did you fix it to actually update when the branch does? [23:29] StevenK: No. make clean does, that but it seems to be all :/ [23:35] guys, should i have another go at removing the oauth.py duplication, or just leave it? [23:35] poolie: I thought it was fixed [23:36] I saw a new python-openid in the download cache [23:36] lifeless: != oauth [23:36] i think that's different [23:36] the last mail i have is just talking about reverting the attempted removal [23:37] I'd roll a fixed egg [23:37] better than having this thing hiding in contrib that noone knows to look for [23:37] you'd prefer an updated egg to using the ubuntu package? [23:37] Yup. [23:38] launchpadlib currently uses the ubuntu package [23:38] wgrant: yup to what? [23:38] poolie: To lifeless "I'd roll a fixed egg" [23:38] poolie: We don't use the launchpadlib package. [23:38] We use an egg. [23:38] for the sake of my education, why is this better than using the distro package? [23:38]