[00:00] <cjohnston> 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] <Ronnie> 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] <cjohnston> if mhall119 makes it, hes the most familiar i believe
[00:01] <mhall119> hola
[00:01] <cjohnston> hey
[00:02] <cjohnston> mhall119: < lifeless> whats the api call you make to find out about the members of the team?
[00:02] <cjohnston> < lifeless> cjohnston: do you verify their lp uids?
[00:03] <mhall119> no, we assume that the openid response 'nickname' matches the launchpad username
[00:03] <cjohnston> lifeless: see... i told you he would know the answers
[00:03] <wgrant> That's not ideal. Is there a reason you can't check the OpenID identifier?
[00:04] <cjohnston> howdy wgrant
[00:04] <mhall119> wgrant: what do you mean?
[00:04] <wgrant> mhall119: LP usernames are mutable.
[00:05] <mhall119> http://paste.ubuntu.com/563231/ is what we do
[00:06] <mhall119> 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] <mhall119> can we look it up based on the identity url?
[00:06] <wgrant> mhall119: Probably not at the moment. But that can be fixed easily enough.
[00:06] <mhall119> we're using the launchpadlib
[00:07] <mhall119> 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] <mhall119> lp.people[ld_user.username] is doing a lookup on the People collection exposed by the webservice API to launchpadlib
[00:08] <wgrant> Right.
[00:08] <wgrant> We can easily expose a method on lp.people to get a person by an OpenID identifier.
[00:09] <mhall119> 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] <wgrant> For particular users?
[00:10] <mhall119> I suppose once we can do lookups based on the identity url, we can change our code to get nickname for that
[00:10] <mhall119> wgrant: let me see if I can find the name
[00:10] <wgrant> SSO has a bug like that for some users at the moment. It's fixed, but not yet rolled out.
[00:11] <wgrant> I investigated it with one particular LD user a couple of weeks ago.
[00:11] <mhall119> wgrant: that might have been for us
[00:11] <Ronnie> i thought (but am not sure) that it was for users with unicode characters in the name
[00:11] <wgrant> So, known SSO issue, fixed in trunk a month or so ago, but awaiting deployment.
[00:11] <james_w> wgrant, lookup based on identity url would be spiffy
[00:12] <wgrant> Sadly it'll be a few days, because we are frozen for the release.
[00:13] <mhall119> well we've been dealing with this for months, another few days isn't going to kill us
[00:13] <Ronnie> mhall119: cant we check if the username has changed each login?
[00:13] <mhall119> Ronnie: we can, yes, infact I have a code change to that pending with django-openid-auth
[00:14] <mhall119> 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] <Ronnie> if so, we can do checkups with the username instead of identity, right/
[00:14] <mhall119> in theory, but again we'd have to wait for them to log in
[00:14] <lifeless> wgrant: I think there is a bug already requesting openid lookups
[00:14] <wgrant> lifeless: I tried to find it.
[00:14] <wgrant> But couldn't.
[00:14] <mhall119> if we can do lookups based on identity url, we can get updated during our nightly refresh
[00:15] <wgrant> Oh.
[00:15] <wgrant> Possibly bug #655565
[00:15] <_mup_> Bug #655565: Immutable reference to users in API <api> <lp-foundations> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/655565 >
[00:15] <lifeless> yes
[00:15] <lifeless> mhall119: so separately I'd like to get away from polling for updates
[00:15] <lifeless> mhall119: would pubsubhubbub work for you, if we implemented it ?
[00:16] <mhall119> is it strange that every time I see a number that starts with '655' I automatically think "oh no, integer overflow!"
[00:16] <lifeless> ah, a 16 bitter
[00:16] <mhall119> pubsubhubbub?
[00:16] <wgrant> 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] <lifeless> mhall119: http://code.google.com/p/pubsubhubbub/
[00:16] <lifeless> wgrant: collection - yes, person - no
[00:17] <lifeless> wgrant: but perhaps I'm being paranoid in objecting to such a collection
[00:17] <wgrant> 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] <lifeless> wgrant: it just seems a little too like iterating /etc/passwd
[00:17] <mhall119> lifeless: are they talking real multicast?
[00:18] <wgrant> lifeless: I mean something like lp.person['wgrant'].openid_identifiers
[00:18] <lifeless> wgrant: that would be fine with me; might want to check if stuartm has any reservations
[00:18] <wgrant> We already expose the primary one in the HTML.
[00:18] <lifeless> wgrant: I thought you meant lp.openid_identifiers
[00:18] <wgrant> Ah, no, that would be pointless.
[00:19] <mhall119> yeah, I can already get a person's identifier if I have their username
[00:19] <lifeless> mhall119: its point to point but with hubs that multiplex
[00:19] <mhall119> lifeless: I'm sure we could implement whatever needs implementing on our end to achieve that
[00:20] <lifeless> ok
[00:20] <lifeless> I suspect we can nuked 20 or 30 % load if we do this.
[00:20] <lifeless> But someone is going to need to do some hard core log analysis to confirm that
[00:21] <Ronnie> back to our mugshot. what is exactly the problem?
[00:23] <lifeless> ok
[00:23] <lifeless> 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] <lifeless> if the object isn't there, you end up with a redirect to the containing object AFAICT - the user page.
[00:25] <lifeless> there are several problems with just embedding the LP API url
[00:25] <lifeless> firstly, its slow for users: you make them do 2 new https lookups
[00:25] <wgrant> 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] <lifeless> 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] <lifeless> 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] <lifeless> wgrant: is it right?
[00:27] <lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/655565/comments/3 ?
[00:27] <_mup_> Bug #655565: Immutable reference to users in API <api> <lp-foundations> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/655565 >
[00:28] <lifeless> Ronnie: secondly, LP doesn't expose a magic object - one that transparently fills in the default mugshot if none is set
[00:28] <wgrant> 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] <wgrant> The LD case, that is.
[00:29] <lifeless> 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] <mhall119> lifeless: LD checks if the user's logo_link starts like a URL, and sets a default if it doesn't
[00:29] <lifeless> Ronnie: LP doesn't want such a magic attribute itself, because it would be heinously slow
[00:29] <lifeless> mhall119: http://loco.ubuntu.com/events/team/666/detail/ - broken images here
[00:30] <mhall119> yeah, I'm not sure sure why
[00:30] <mhall119> http://paste.ubuntu.com/563231/ shows the code we use set the mugshot url
[00:30] <lifeless> also, you guys know not to use edge, right ?
[00:30] <mhall119> yes, cjohnston already submitted a fix to that
[00:30] <lifeless> http://blog.launchpad.net/general/edge-is-deprecated
[00:30] <lifeless> cool
[00:30] <mhall119> nigelb pointed it out earlier today
[00:30] <lifeless> great
[00:31] <lifeless> just ensuring the message is out there :)
[00:31] <lifeless> edge has our oldest servers
[00:31] <lifeless> so moving off it will help you
[00:31] <mhall119> yeah, we've been migrating off
[00:31] <mhall119> just a few things we overlooked
[00:31] <Ronnie> cjohnston: your lp login still uses edge: def lp_login(lp_instance=EDGE_SERVICE_ROOT):
[00:32] <mhall119> Ronnie: I think it only uses that for local setups
[00:32] <lifeless> still should be changed
[00:32] <mhall119> or not
[00:32] <lifeless> launchpad has dropped the EDGE_SERVICE_ROOT constant
[00:33] <mhall119> lifeless: we had some issue with using openid from behind a firewall, I think is why we used different servers
[00:34] <wgrant> Also, you should probably be using the devel API.
[00:34] <wgrant> Rather than beta.
[00:34] <lifeless> or 1.0
[00:34] <wgrant> I like to consider 1.0 a deprecated mistake :)
[00:34] <lifeless> if the software is packaged, 1.0, if its just a live website you update a lot devel is fine.
[00:35] <mhall119> what's the url for the devel api?
[00:35] <wgrant> mhall119: Which version of launchpadlib are you using? Lucid's?
[00:35] <lifeless> version='devel' in the login call to launchpadliv
[00:36] <wallyworld_> henninge: ping
[00:36] <mhall119> wgrant: yeah, lucid
[00:36] <wgrant> mhall119: lifeless' suggestion will work, then.
[00:37] <mhall119> that'll work with login_anonymously too?
[00:38] <lifeless> yes
[00:38] <wgrant> Use something like Launchpad.login_anonymously('Loco Directory', 'production', version='devel')
[00:39] <mhall119> got it https://bugs.launchpad.net/loco-directory/+bug/713868
[00:39] <_mup_> Bug #713868: Use Launchpad devel API  <loco-directory:Confirmed> < https://launchpad.net/bugs/713868 >
[00:39] <mhall119> thanks
[00:39] <lifeless> ok
[00:39] <lifeless> our logo_link and mugshot_links are crack.
[00:39] <wgrant> Are they?
[00:40] <mhall119> good crack or bad crack?
[00:40] <lifeless> bad
[00:40] <mhall119> is there something better we can be using?
[00:40] <wgrant> lifeless: Because they always link to the same URL?
[00:40] <lifeless> we need to fix them
[00:40] <wgrant> Which then redirects to the librarian?
[00:40] <lifeless> wgrant: because they link to appserver code
[00:41] <lifeless> but for a public person (all people atm) we should just emit the librarian reference immediately.
[00:41] <lifeless> the whole LFA->LFC chain will complicate the performance of this slightly
[00:42] <lifeless> but we don't have a use case for 'can query the person and not their logo'
[00:45] <wgrant> Oh, Squeeze has happened.
[00:46] <lifeless> 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] <wgrant> lifeless: Sure.
[00:47] <lifeless> http://pastebin.com/CaTTajjy
[00:48] <wgrant> lifeless: Uh, lp.testing is probably not what you are looking for...
[00:48] <lifeless> wgrant: well, I thought that might be contentious ;)
[00:49] <lifeless> wgrant: OTOH, there is a certain logic to i.
[00:49] <lifeless> it.
[00:49] <wgrant> There is, but this does not work.
[00:49] <wgrant> We need to move one or the other.
[00:50] <wgrant> lifeless: Why are we storing subunit streams in LP, anyway?
[00:50] <lifeless> wgrant: so we can get them back out again
[00:50] <wgrant> lifeless: I don't really see why this is in scope for LP.
[00:50] <lifeless> mhall119: cjohnston: https://bugs.launchpad.net/launchpad/+bug/713873
[00:51] <_mup_> Bug #713873: Person.logo_link is hard to use and performs poorly <Launchpad itself:Triaged> < https://launchpad.net/bugs/713873 >
[00:54] <wgrant> Ugh.
[00:55] <wgrant> Do we have a branching-debian process that we need to run for squeeze->wheezy branches?
[00:56] <wgrant> I guess the Ubuntu script will work just as well.
[00:57] <lifeless> well
[00:57] <lifeless> this is why the 'lets make sid the dev focus'
[00:58] <wgrant> I'm not sure the script will work too well in that case.
[00:58] <wgrant> But yes.
[00:59] <henninge> wallyworld_: Hi! in a rush ...
[01:00] <henninge> wallyworld_: but thanks for the approval! I'll see to it first thing on Monday.
[01:00] <wgrant> :( They've created wheezy already.
[01:01] <lifeless> man, I don't understand why we get 170 updates to lucid :<
[01:01] <wgrant> I hope the package importer is using 'squeeze', not 'testing', like gina was last time.
[01:02] <lifeless> it was discussed on the caonical bazaar list, james_w seemed unconcerned about the basic correctness aspects
[01:03] <wgrant> Is ~canonical-bazaar going to handle the branches side of the new series?
[01:03] <wgrant> Including running branch-distro.py.
[01:04] <lifeless> wgrant: so you think using lp.testing as is will be too confusing ?
[01:04] <wgrant> lifeless: Yes. Using it for something other than internal testing utilities is crack.
[01:04] <wgrant> Well, more precisely, using it for both is crack.
[01:04] <lifeless> wgrant: its probably too late for the script; the new branches will be populating right now
[01:04] <lifeless> they'll all stack
[01:05] <wgrant> No they won't.
[01:05] <lifeless> has the development focus changed already?
[01:05] <wgrant> The new series doesn't exist yet.
[01:05] <lifeless> then they won't be created
[01:08] <wgrant> 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] <lifeless> It would be best to stop it, then create, run the branch script, then start it.
[01:08] <lifeless> *or*
[01:09] <lifeless> stop it, create, make sure sid is the development focus, run the branch script, then start it.,
[01:09] <james_w> I've stopped the importer
[01:09] <lifeless> (and that way we never have this again)
[01:10] <wgrant> OK, so. Tomorrow I will convince a LOSA to make lenny supported, squeeze current, sid development, and create a future wheezy.
[01:10] <lifeless> yes
[01:10] <wgrant> Then we can fix gina crontabs, run branch-distro, and the package importer can be restarted at our leisure.
[01:11] <wgrant> it would also be nice to restack the rest of the branches on sid, but that's a bit hard.
[01:11] <lifeless> the branch script moves the current ones to the new dev
[01:11] <lifeless> then branches *back*
[01:11] <wgrant> Right.
[01:11] <lifeless> oh you mean -2 etc
[01:11] <lifeless> meh
[01:11] <wgrant> Ah, and in this case we probably don't have lenny branches.
[01:11] <lifeless> yes, in principle.
[01:13] <lifeless> wgrant: were there any other things about the patch;
[01:13] <wgrant> lifeless: Your security is crack.
[01:13] <wgrant> It should inherit it from the branch.
[01:14] <lifeless> wgrant: how does one do that - I knew thats what I wanted, but not the mechanism to do so
[01:14] <wgrant> lifeless: See things like CodeReviewCommentView
[01:15] <wgrant> You do the delegation manually.
[01:15] <wgrant> Or you write a base class which automates it :)
[01:15] <lifeless> anything else?
[01:16] <wgrant> lifeless: Your security ZCML doesn't use your security adapter.
[01:17] <wgrant> You need to require launchpad.View
[01:17] <wgrant> Not allow.
[01:17] <lifeless> wgrant: sure, but thats tied to the other bit; thanks for being complete though.
[01:18] <wgrant> I also wonder how linkStream will function if the UUID doesn't exist.
[01:18] <wgrant> Apart from that it looks good.
[01:18] <wallyworld_> henninge: no problem. thanks
[01:18] <lifeless> wgrant: it will blow up, which is ok
[01:18] <wgrant> lifeless: It will probably OOPS, which is not OK.
[01:18] <lifeless> well
[01:19] <lifeless> indeed, I guess.
[01:19] <lifeless> however, I'm willing to land and iterate
[01:19] <wgrant> It's probably another three lines to fix this and avoid a Critical bug.
[01:20] <lifeless> if its that simple, cool.
[01:20] <lifeless> I can has patch?
[01:22] <lifeless> I'll be shelving this until next weekend I suspect
[01:23] <wgrant> lifeless: Check if TSM.fetch returns None, if so raise some webservice-annotated exception.
[01:23] <wgrant> If there is no appropriate webservice-annotated exception, three lines create a new one.
[01:26] <lifeless> whats the one for 404
[01:27] <wgrant> Is a 404 appropriate here? Possibly, I guess.
[01:27] <lifeless> if the uuid is absent
[01:27] <lifeless> the spec is ambivalent :)
[01:27] <wgrant> There's lp.app.errors.NotFoundError.
[01:27] <wgrant> I am not entirely sure if that's annotated.
[01:30] <wgrant> james_w: So can we go ahead and run branch-distro.py on Monday?
[01:30] <james_w> I don't see why not
[01:30] <wgrant> It worked fine for Natty, so it seems safe enough.
[01:34] <wgrant> D:
[01:56] <lifeless> wgrant: hey, you were looking at bug 32464
[01:56] <_mup_> Bug #32464: guess_bugtask() fails on distribution tasks without a source package <lp-bugs> <oops> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/32464 >
[01:56] <lifeless> wgrant: I thought you found the bug still existed?
[02:02] <lifeless> hmm
[02:02] <lifeless> we really need a profile for where the python time in oopses like OOPS-1862C1669
[02:03] <lifeless> 33.	8790	35ms	SQL-launchpad-main-slave	
[02:03] <lifeless> SELECT ValidPersonCache.id
[02:03] <lifeless> FROM ValidPersonCache
[02:03] <lifeless> FROM ValidPersonCache
[02:03] <lifeless> WHERE ValidPersonCache.id = %sLIMIT 1
[02:03] <lifeless> 3 seconds between those trivial queries
[02:08] <lifeless> 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] <lifeless> flacoste: same situation we had with the xmlrpc; same symtoms, and it was totally fixed when we gave it more resources.
[02:11] <wgrant> lifeless: It doesn't fail. It just does insane things, but the whole method is insane, so that's OK.
[02:11] <lifeless> ok
[02:11] <lifeless> cool, thanks.
[02:11] <wgrant> Yes, I was a bit surprised when he closed it too.
[02:12] <lifeless> wgrant: do you know where jon is at with bug 421901 ?
[02:12] <_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/421901 >
[02:14] <wgrant> lifeless: Still actively working on it.
[02:14] <wgrant> Was going to talk to deryck about a couple of things, IIRC.
[02:19] <lifeless> 15 second query
[02:25] <lifeless> wgrant: ok, I'm going to do some analysis, on the basis that he seems stalled, and that sucks,
[02:29] <wgrant> Uhoh, they are going to enable testing migrations again tomorrow.
[02:29] <wgrant> A few days earlier than I expected :(
[02:29] <lifeless> ?
[02:30] <wgrant> wheezy isn't going to be static for long.
[02:31] <lifeless> ahha
[02:31] <lifeless> its 'commented on'
[02:31] <lifeless> that is terribad
[02:32] <wgrant> Of course.
[02:32] <lifeless> well
[02:32] <lifeless> its poorly constructed
[02:32] <lifeless> no particular reason it should be bad
[02:33] <lifeless> -wow- minutes of runtime on qas
[02:33] <lifeless> hahahaha
[02:33] <lifeless> 8.4 fallout
[02:34] <lifeless> the inner correlated join is the problem I think
[02:34] <lifeless> 178 seconds cold
[02:35] <wgrant> Ouch.
[02:35] <lifeless> 20 hot
[02:58] <lifeless> heh
[02:58] <lifeless> apport has commented on more bugs than anyone else
[02:58] <lifeless> seb128 a close second
[02:59] <wgrant> Heh.
[03:03] <lifeless> ok, wrapped in a bow and ready to cod
[03:03] <lifeless> e
[03:06] <lifeless> wgrant: is there anything you were needing extra inspiration on?
[04:40] <StevenK> 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] <lifeless> cool
[04:47] <wgrant> Why is OpenIDRPSummary still in the LP tree? :/
[04:50] <wgrant> Ah, it's still used to warn about account renames.
[04:50] <wgrant> But it seems to no longer be used.
[04:50] <wgrant> mawson's latest record is from April.
[04:52] <wgrant> Perhaps we should make profile delegation optional, and warn on rename if it's delegated at all.
[04:53] <wgrant> I wonder what SF.net does.
[04:53] <wgrant> They have relatively unawful OpenID support.
[04:54] <wgrant> Ah, indeed. Delegation is optional, and you can select the identifier that you wish to delegate to.
[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] <maxb> When did that happen?
[17:54] <lifeless> morning
[17:54] <lifeless> maxb: 6 july last year
[18:53] <lifeless> allenap: around per chance ?
[18:55] <lifeless> ah
[18:55] <lifeless> actually brad
[18:55] <lifeless> bac: ping
[21:02] <wallyworld_> thumper: morning. did we need a call this morning?
[21:03] <thumper> wallyworld_: hi
[21:03] <thumper> wallyworld_: I'm trying to leave the office to get coffee and a warrent for the car
[21:03] <thumper> but got suck clearing through emails
[21:04] <wallyworld_> thumper: np. ping me later if required
[21:04] <wallyworld_> i've had my coffee :-)
[21:05] <thumper> phew
[21:05] <thumper> just done with the email
[21:05] <thumper> wallyworld_:  how's your recipe work going?
[21:07] <wallyworld_> 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] <thumper> ok
[21:58] <thumper> gah
[21:58] <thumper> found out that it was "self..." that was screwing up my js tests, should be "this.foo"
[22:01] <lifeless> heh
[22:15] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740
[22:39] <huwshimi> Has anyone hit this problem when using rocketfuel-branch today? Error: Couldn't find a distribution for 'windmill==1.5pre-deryck'
[22:40] <lifeless> update your download cache
[22:42] <huwshimi> lifeless: How do I do that. There were instructions on the wiki, but they got removed :(
[22:42] <lifeless> they did?
[22:43] <lifeless> I cd to the download cache and run bzr update
[22:43] <huwshimi> well they were on the canonical wiki
[22:44] <StevenK>   Set up canonical.testing.layers.DatabaseLayer in 10.542 seconds.
[22:44] <StevenK>   Set up canonical.testing.layers.LibrarianLayer in 16.152 seconds.
[22:44]  * StevenK peers at his machine
[22:45] <wallyworld_> StevenK: hot last night? meant to be the hottest on record
[22:46] <StevenK> wallyworld_: Last night? No, last night was fine, it was the night before that
[22:46] <wallyworld_> ah ok.
[22:47] <StevenK> 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] <huwshimi>  lifeless: Thanks that's fixed it. Just so I can understand, what does that download-cache do?
[22:51] <lifeless> its where we have buildout configured to 'download' from
[22:51] <lifeless> rather than grabing untrusted stuff off of the net
[22:52] <wallyworld_> wgrant: not sure but thanks for looking. btw i'm doing r12315 as soon as i get a feature flag enabled
[22:52] <wgrant> wallyworld_: I just did that. It's not behind FF, though -- it's just plain disabled.
[22:52] <wgrant> So there is no change, as long as existing subscriptions work.
[22:52] <huwshimi> lifeless: Right. Thanks.
[22:52] <wgrant> Which they do.
[22:53] <wallyworld_> wgrant: i the advanced fields alluded to in the bug report and qa notes are hidden behind a feature flag i thought?
[22:53] <wallyworld_> or maybe i missed something
[22:53] <wgrant> use_advanced_subscriptions is hardcoded to false for now.
[22:53] <wgrant> It *should* be behind FF. But it isn't.
[22:54] <wallyworld_> so how did you test then if advanced_sub is false?
[22:54] <wgrant> 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] <wgrant> And that is what matters.
[22:55] <wallyworld_> sure, but the bug also talks about updating the bug notification level field
[22:55] <wallyworld_> and that can be tested if the advanced subscriptions were enabled
[22:56] <wallyworld_> s/bug/mp
[22:59] <wgrant> Ahem, a couple of Unity crashes later...
[22:59] <StevenK> ne
[22:59]  * StevenK glares at Do
[22:59] <wgrant> 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 <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[22:59] <wgrant> wallyworld_: ^^
[23:02]  * wallyworld_ looks
[23:04] <wgrant> Um, it seems to not have come back up properly after I pulled the debversion stuff.
[23:05] <wgrant> Hrmm.
[23:05] <wallyworld_> wgrant: that page on dogfood errors for me.
[23:06] <thumper> :-(
[23:06] <thumper> car needs two new tires
[23:06] <thumper> I'm home to collect charger and usb cable so I can continue to work from town while care is getting fixed
[23:07] <thumper> at least #launchpad is quiet on Mondays
[23:07] <wallyworld_> thumper: i think you meant to say "tyres" :-P
[23:08] <thumper> wallyworld_:  what ever....
[23:08] <thumper> stupid english language
[23:08] <wallyworld_> no, the english language is fine. it's "american english" that is broken :-)
[23:08]  * thumper afk again
[23:14] <wgrant> 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 <exercises> <worksheets> <IVLE:Triaged> < https://launchpad.net/bugs/647286 >
[23:14] <wallyworld_> wgrant: thanks
[23:19] <wallyworld_> wgrant: the rev on dogfood is too old to qa 12315
[23:19] <wgrant> launchpad@mawson:/srv/launchpad.net/codelines/current$ bzr revno
[23:19] <wgrant> 10180
[23:20] <wgrant> Not sure what updates the footer.
[23:20] <wgrant> But it clearly hasn't happened in a while :/
[23:20] <wallyworld_> yup :-)
[23:20]  * wgrant goes Makefile diving.
[23:25] <poolie> hi all
[23:26] <wgrant> wallyworld_: The footer no longer lies.
[23:26] <wallyworld_> cool
[23:27] <wgrant> But we have a LOSA now anyway.
[23:27] <StevenK> wgrant: Did you fix it to actually update when the branch does?
[23:29] <wgrant> StevenK: No. make clean does, that but it seems to be all :/
[23:35] <poolie> guys, should i have another go at removing the oauth.py duplication, or just leave it?
[23:35] <lifeless> poolie: I thought it was fixed
[23:36] <lifeless> I saw a new python-openid in the download cache
[23:36] <wgrant> lifeless: != oauth
[23:36] <poolie> i think that's different
[23:36] <poolie> the last mail i have is just talking about reverting the attempted removal
[23:37] <lifeless> I'd roll a fixed egg
[23:37] <lifeless> better than having this thing hiding in contrib that noone knows to look for
[23:37] <poolie> you'd prefer an updated egg to using the ubuntu package?
[23:37] <wgrant> Yup.
[23:38] <poolie> launchpadlib currently uses the ubuntu package
[23:38] <poolie> wgrant: yup to what?
[23:38] <wgrant> poolie: To lifeless "I'd roll a fixed egg"
[23:38] <wgrant> poolie: We don't use the launchpadlib package.
[23:38] <wgrant> We use an egg.
[23:38] <poolie> for the sake of my education, why is this better than using the distro package?
[23:38] <wgrant> Because someone said so.
[23:38] <poolie> because it's easier to make our own changes later?
[23:38] <wgrant> I disagree.
[23:38] <lifeless> uhm
[23:39] <lifeless> my understanding is that the distro package in lucid is too old.
[23:39] <wgrant> It makes it easier to do upgrades.
[23:39] <lifeless> is that wrong ?
[23:39] <wgrant> lifeless: We have PPAs for that.
[23:39] <poolie> wgrant, no, i know the server doesn't use launchpadlib, but istm there is some benefit from having both the client and the server use the same thing
[23:39] <poolie> lifeless, no, it's been fixed in ubuntu since... karmic, at least
[23:39] <wgrant> You would think.
[23:39] <poolie> i think also since hardy
[23:40] <lifeless> so, if its fixed in lucid packages, we can use that
[23:40] <poolie> 'rmadison python-oauth' shows it's actually unchanged since karmic
[23:40] <lifeless> the more complex the package, the less likely we can use it in production deployments
[23:41] <lifeless> because of the 'only one can be installed' nature of python packaging; I've posted to debian-python a few times, and been talking to allison, barry etc about this
[23:41] <poolie> right
[23:42] <poolie> in this case it is just two py files, and also slowly moving (maybe dead) upstream
[23:42] <lifeless> the big thing here is that the api isn't changing
[23:42] <poolie> right, it's highly unlikely to get anything more than just bug fixes
[23:42] <wgrant> wallyworld_: FWIW the translations change seems to be good. But it's hard to be sure, since I don't really know translations.
[23:42] <poolie> so, the right way to proceed is:
[23:42] <poolie> update launchpad-dependencies to pull it in
[23:42] <poolie> somehow get that rolled out
[23:43] <poolie> delete the egg
[23:43] <poolie> and ditto get that updated by everyone
[23:43] <lifeless> which is why we can switch to using the package; add it to launchpad-*-dependencies, build that, remove from download cache, let the losas know the package is needed (they generally port the dependencies package to address this)
[23:43] <wgrant> Why do the translations DB tables hardcode 'ubuntu' in some column names? :/
[23:43] <poolie> then resubmit the deletion of the copy in contrib?
[23:44] <lifeless> poolie: was it rolled back ?
[23:44] <wallyworld_> wgrant: i don't know translations either.
[23:44] <poolie> yes, it caused a buildbot failure friday night my time
[23:44] <lifeless> poolie: anyhow yes; but after the release.
[23:44] <poolie> sorry
[23:44] <lifeless> this coming friday.
[23:44] <poolie> sure
[23:44] <lifeless> wallyworld_: wgrant: a pragmatic denormalisation
[23:45] <poolie> is there documentation somewhere of how to update the dependencies package etc?
[23:45] <lifeless> wallyworld_: wgrant: possibly unneeded, possibly needed.
[23:45] <lifeless> poolie: pretty sure its on the dev wiki
[23:45] <wgrant> lifeless: But definitely bad :)
[23:45] <poolie> ok, i'll shelve it until next week and maybe try then
[23:45] <lifeless> wgrant: I live in a world with greys
[23:45] <wgrant> wallyworld_: Note that staging will take a while to update with the debversion change.
[23:45] <wgrant> wallyworld_: The patch itself could take half an hour to run.
[23:45] <lifeless> poolie: sure; sorry you're having such trouble landing it successfully.
[23:45]  * thumper is connected again
[23:46] <thumper> more coffee on its way
[23:46] <poolie> it's ok
[23:46] <poolie> it's been interesting
[23:46] <poolie> i'm more just sorry to have caused a buildbot failure for something with no immediate concrete benefit
[23:46] <wgrant> buildbot failures happen.
[23:47] <poolie> however, i guess if you tolerate duplication because it's hard to remove, things get worse and worse
[23:47] <poolie> it's possible there are other fixes in the newer package too
[23:47] <lifeless> poolie: this is because we have too many ways to do dependencies.
[23:47] <poolie> right
[23:47] <poolie> righ
[23:47] <lifeless> I'd like to have one - the python upstream way (there isn't one), and have the packaging system back us up (but it can't yet)
[23:47] <poolie> :)
[23:48] <wallyworld_> wgrant: yeah, i know that patch will take some time to apply. just trying to communicate that rev 10178 doesn't have to be qa'ed right this second, but sometime soonish would be good :-)
[23:50] <poolie> when you say the rollout's this coming friday
[23:50] <poolie> i thought it was thursday a/nz time
[23:51] <lifeless> poolie: it is, I'm saying try landing on friday
[23:52] <poolie> oh i see, ok