[00:30] <jml> thumper, mwhudson: you should upgrade :)
[00:31] <mwhudson> jml: week 4!
[00:31] <jml> mwhudson, oh yeah :(
[00:31] <jml> we're going to fix that some day soon
[00:33] <jml> actually, I should ask gary about that.
[00:33] <jml> he was going to do it as a part of an "only roll out QAd changes" mechanical solution
[00:33] <jml> they're orthogonal, but he wanted to use the former as a carrot for the latter
[00:33] <jml> turns out the latter is really really hard
[00:35] <mwhudson> jml: is this related to MergeWorkflowDraft ?
[00:35] <jml> mwhudson, that's Bjorn's one right?
[00:35] <mwhudson> jml: yeah
[00:35] <jml> mwhudson, I think it's different.
[00:40] <jml> anyway, really bed time
[00:40] <jml> (why do all you kiwis work such insane hours!)
[00:41] <mwhudson> launchpad is behaving very strangely during this rollout
[00:45] <wgrant> Timing out, OOPSing, saying it will be going down really really soon, then read-only, then timing out again...
[00:45] <mwhudson> wgrant: and despite saying "You cannot make any changes.", i can see all the editing options
[00:46] <wgrant> mwhudson: YOu're not logged in, are you?
[00:46] <wgrant> It's kicked me out again.
[00:46] <wgrant> So it shows all the actions.
[00:46] <wgrant> Even though launchpad.Edit and launchpad.Admin have been revoked from every object.
[00:49] <lifeless> jml: because we're committe?
[00:49] <lifeless> d
[00:49] <lifeless> d
[00:49] <lifeless> d
[00:49] <mwhudson> i'm logged in
[00:50] <wgrant> Hm.
[01:16]  * mwhudson off for a bit
[01:42] <wgrant> How is the internal community commit/review privileges discussion going?
[03:01] <thumper> mwhudson: https://code.edge.launchpad.net/~kiko/linux/2.6.31
[03:01] <thumper> mwhudson: first pass succeeded
[03:04] <mwhudson> thumper: woo
[03:04] <mwhudson> thumper: it's still going to take aaaaagees
[03:04] <thumper> mwhudson: yep, but at least it won't die part way through
[03:04] <thumper> just take ages
[03:05] <mwhudson> yeah
[06:11] <jtv> stub: I cheated
[06:11] <stub> I'm dobbing
[06:11] <jtv> stub: I *did* have a look at your branch
[06:12] <jtv> dobbing?
[06:12] <stub> strine
[06:12] <jtv> oh, sorry mate, I don't speak that
[06:12] <stub> 'informing the authorities', normally parents
[06:12] <jtv> apart from "beware drop bears near billabong"
[06:12] <jtv> ah
[06:13] <jtv> what in plain English we would call "ratting you out"
[06:13] <jtv> *drat
[06:13] <jtv> forgot to bring "dropbeertjes" from Holland
[06:13] <jtv> (beertjes == little bears)
[06:14] <jtv> stub: _anyway_...  the new feature looks cooler than I could have imagined.  I suspect we'll have to learn about or build a whole new set of tools to figure out where the savings are at this level of the stack.
[06:15] <jtv> (Although the hottest-bug listings come to mind :-)
[06:16] <stub> We have tools to measure page generation times by analizing the zserver trace logs. Run the report, land your tweak, run the report a day later. If things look better, its a win.
[06:17] <stub> I'm thinking off adding cache_stores, cache_hits & cache_misses to opstats today. If the hits are low we are choosing badly. But we will have to find out what 'low' is by trial an error.
[06:18] <jtv> But "land your tweak" also involves convincing a reviewer that you're doing something useful, which you'll only really find out in the next stage.
[06:18] <stub> No, convincing the reviewer it is a good experiement.
[06:18] <spm> losa cowboys on staging?
[06:19] <stub> It really needs edge - not enough genuine traffic on staging to generate genuine reports.
[06:19] <spm> point
[06:19] <jtv> spm: good point, but a bit unreliable in terms of performance and staging updates
[06:19] <spm> jtv: unreliable staging updates would work IN your favour here :-)
[06:19]  * jtv suspects spm of having his IRC client beep on the word "strine"
[06:20] <jtv> spm: unless they suddenly _do_ happen, is my point :)
[06:20] <spm> was the word 'beer' actually... in '"dropbeertjes"'
[06:20] <stub> What we have to avoid is using the cache to optimize particular pages. We add caching to a page template, it actually makes the initial rendering slower. So this is purely about increasing overall performance - reducing the average time of a particular class of pages or perhaps freeing up resources for other stuff.
[06:20] <jtv> spm: funny because it's quite probably true
[06:21] <jtv> stub: that was one question I had: how sensitive is the caching to exact path & query parameters?
[06:21] <stub> So make an educated guess, then measure the results over a day.
[06:21] <stub> It is very sensitive - the getKey() method encapsulates all this. query parameters or url changes, cache is not reused.
[06:22] <jtv> good to know
[06:22] <spm> the only danger i'd see in this process approach, is late in a cycle. we really wouldnt want experimental code accidently getting rolled to prod
[06:22] <wgrant> Sounds like MergeWorkflowDraft needs to be undraftified.
[06:23] <jtv> Would this also be a useful hook for profiling the fragments?
[06:23] <stub> I suspect it will be hard to make pages perform worse. It might be possible to put lots of pressure on the cache slowing things down, but we can fix that by increasing our cache size. But we shall see once I can land and do some real world tests.
[06:23] <jtv> wgrant: thou speakest in riddles, verily as Greek
[06:24] <spm> stub: please, for my sanity, do now throw down challenges like that. folks have a way of trying to achieve them. (....hard to make pages perform worse)
[06:24] <jtv> stub: is there a don't-cache-at-all mode to give us more flexibility there?  Especially handy with a hypothetical pofiling option
[06:24] <stub> jtv: Sure. You shutdown memcached.
[06:25] <lifeless> fragment caching++
[06:25] <lifeless> ESI yaaaay
[06:25] <jtv> stub: I was thinking of a slightly finer granularity—as an addition to the list of caching modes for a given fragment
[06:25] <stub> Its similar to ESI, except we don't have to work out htf to get page templates to generate non-wellformed XML fragments and have access control so 'fred' doesn't see 'bobs' cache when we want that.
[06:26] <jtv> End System Identifier?
[06:26] <jtv> ElectroStatic Interference?
[06:26] <stub> edge side includes
[06:26] <stub> Squid tech
[06:26] <jtv> ...and there goes a new GTF entry.
[06:26] <stub> (and devs don't need to run squid locally)
[06:26] <wgrant> Just memcached :P
[06:26] <jtv> lifeless, stub: gtf entry #23517, with thanks
[06:26] <mup> Bug #23517: adept is not translated in french <kde-i18n-fr (Ubuntu):Fix Released by carlos> <https://launchpad.net/bugs/23517>
[06:26] <stub> Chewing up a whole 1MB of ram for its cache!
[06:27] <jtv> no mup, stay out of it
[06:27] <stub> jtv: esi is at least 6-7 years old...
[06:27] <lifeless> stub: well, on the squid side, the main pt is ~= an ESI processor anyway
[06:27] <jtv> stub: well, I didn't have it yet
[06:27] <wgrant> Is the TALES extension going to land soon?
[06:28] <lifeless> Not sure about the xml angle; dunno why you would care about welformedness per se;
[06:28] <stub> As soon as pqm opens
[06:28] <lifeless> fred vs bob we should solve anyway
[06:28] <wgrant> Excellent.
[06:28] <lifeless> Vary is generally sufficient
[06:28] <jtv> stub: status on the mp is still Needs Review IIRC
[06:28] <stub> lifeless: PageTemplates is cool provided you want to generate well formed XML. If you want to generate anything else, your shit out of luck.
[06:29] <lifeless> stub: I get that; I don't get why that is an issue for ESI
[06:30] <wgrant> Why are there multiple Linux imports going?
[06:30] <wgrant> Wouldn't it make approximately several hundred times more sense to import the latest branch, stack the rest on it, and have all of them imported in only slightly longer than the last branch?
[06:30] <lifeless> wgrant: ask kiko :P
[06:31] <stub> lifeless: You are right. I had a different use case when I first looked at it, and for it to be useful to me then I would have needed to cache non-wellformed XML fragments due to page layout issues (cause we still had to use tables back then for any non-trivial page layout).
[06:31] <lifeless> stub: ahha! mystery explained :)
[06:32] <stub> You can't cache non-wellformed fragments with the TALES syntax either
[06:32] <stub> (cause they are generated with ZPT)
[06:39] <jtv> wgrant: that does sound like it makes several hundred times more sense, but maybe (and I really mean I don't actually know) the resulting number is considered less than the sense index for other things that could be done with the engineering time.
[06:39] <jtv> wgrant: we get similar questions about translations imports sometimes
[06:39] <wgrant> jtv: It doesn't take any engineering time, though.
[06:40] <wgrant> It's not an engineering issue.
[06:40] <wgrant> Somebody just clicked Retry on too many imports.
[06:40] <jtv> wgrant: you're saying somebody expended effort to produce needless work for the server?
[06:40] <wgrant> jtv: It looks that way. The imports should have been suspended for months/years.
[06:41] <jtv> wgrant: they're that old?  Did somebody revive an entire category of old imports to apply a bug fix or something?
[06:43] <wgrant> jtv: One has been suspended for four months. I don't know why they're active again.
[06:44] <jtv> wgrant: al-maisan landed a branch this cycle that IIRC suspends imports when disabling an... archive I believe.  Maybe that's related.
[06:44] <wgrant> jtv: There was a 10.01 branch that suspended binary builds when disabling archives.
[06:44] <wgrant> Is that what you're thinking of?
[06:44] <jtv> oh, last cycle, OK
[06:45] <jtv> Probably it.  I reviewed the branch, but can't say all the details stuck.
[06:46] <jtv> stub: I'm trying to simulate read-only mode in a view unit test.  Do you know how I do that?  I tried setting test_request.annotations['launchpad.read_only_mode'] to True but that doesn't do the trick.
[06:55] <jtv> And I don't know whether zope will give is_read_only the same request that the test set up for the view.
[06:59] <jtv> lifeless: can squid reuse a single connection to a server between requests from different clients?
[06:59] <lifeless> yes
[06:59] <lifeless> be a pretty freaking terrible proxy that can't do that
[07:00] <jtv> So if the connections live long enough, I guess a local proxy (with the necessary setup to deal with https) could save me some ssl connections on multi-browser LP testing.
[07:01] <jtv> Oh, but it'd all be one session to LP, wouldn't it
[07:01] <jtv> ...would it?
[07:02] <lifeless> one ssl session
[07:02] <lifeless> != one lp session
[07:02] <lifeless> lp doesn't see ssl
[07:02] <jtv> lifeless: I was wondering if LP sessions were designed on the assumption that nobody's proxying the SSL sessions.
[07:02] <lifeless> we proxy them
[07:02] <jtv> If they weren't, then great
[07:03] <lifeless> apache does SSL unwrapping
[07:03] <lifeless> backends speak http
[07:03] <jtv> So it all ends up in the same stomach after you swallow it anyway.  Gotcha.
[07:04] <jtv> (And the stomach can deal with that fact and fails to go antiperistaltic when it sees chocolate ice cream juxtaposed to haddock)
[07:04] <lifeless> only if the haddock is deep fried
[07:04]  * jtv checks
[07:04] <jtv> blast.  no haddock.
[07:05] <stub> jtv: I don't know sorry. When I left it, it was a config variable. Now we switch using a .txt file, but I'm not sure how it works in tests.
[07:06] <jtv> stub: I don't see a lot of code using is_read_only; we do in a few places to smooth over some bits that can oops out in read-only mode, and maybe that's just weird of us.
[07:08] <jtv> stub: I think I'll try reproducing the request-checking logic from is_read_only first... maybe it returns nothing at all and then I'll have to get into the function's head in a different way.
[07:08] <jtv> morning al-maisan!
[07:09] <al-maisan> Good morning jtv, how are things :)
[07:09] <stub> I would think the process would be construct your request, set the read only annotation on it, invoke the publication machinery with that request.
[07:09] <jtv> al-maisan: things are a lot warmer here than in Amsterdam, thank you :)
[07:09] <stub> (because the publication machinery is what needs to detect read only mode to install the read only database policy that triggers your bug)
[07:09] <al-maisan> jtv: we had the first lunch on our terrace yesterday :)
[07:10] <stub> Which might be a saner way of constructing your test - just install the read only database policy and see if the code works.
[07:10] <al-maisan> jtv: It was a bit chilly but nevertheless we ate outside :)
[07:10] <jtv> al-maisan: I had a hard disk temperature warning the other day where the temperature was lower than the one on my Gnome weather applet.  :)
[07:10] <al-maisan> jtv: oh :)
[07:10] <jtv> stub: it's based on a text file afaics... though there's also a global variable.
[07:11] <jtv> al-maisan: to be fair, it was a "temperature has been too high in the past" warning
[07:11] <stub> jtv: Yes, but what that text file does is tell the publication machinery to install the read only database policy
[07:11] <jtv> bon dia dpm
[07:11] <jtv> stub: ah ok
[07:11] <al-maisan> jtv: pheww ;)
[07:11] <dpm> hey jtv, bon dia :)
[07:12] <jtv> "based on periodic measurements taken from my server's on-board sensors, global warming is going to kill us all within the coming week"
[07:12] <stub> This is LaunchpadDatabasePolicyFactory in canonical.launchpad.webapp.dbpolicy, which is what is called when the publication machinery does IDatabasePolicy(request)
[07:12] <jtv> stub: thanks
[07:13] <al-maisan> jtv: Oh well, we have nothing to worry then ;)
[07:13] <jtv> al-maisan: not until about halfway through the week, and for different reasons, not after the coming week :)
[07:15] <al-maisan> jtv: maybe you should pursue career options in astrology? ;)
[07:15] <jtv> stub: the app code checks is_read_only() itself though, which wouldn't be fooled that way... is that wrong?
[07:16] <stub> jtv: You would need to do both then. Maybe that can be simplified.
[07:16] <jtv> al-maisan: "Pluto is in the house of...  Pluto is not in anybody's house, because nobody lives at the inner edge of the Kuyper belt.  Sorry."
[07:17] <al-maisan> :-)
[07:17] <jtv> stub: actually there's no reason to have the db policy at all, as long as I can convince is_read_only to return True for a moment.
[07:17] <stub> jtv: Quick hack would be to make is_read_only() return true if the currently installed database policy is LaunchpadReadOnlyDatabasePolicy
[07:18] <stub> jtv: Ok. I would have thought you would need the database policy installed to trigger the error, which you would then fix possibly using explicit checks to is_read_only() and choosing a different code path.
[07:18] <stub> Ideally, we would never need that sort of check but I suspect there are a few valid use cases buried in these 200k lines of code somewhere...
[07:20] <jtv> stub: in this case, checks to is_read_only deeper down in the call tree upset the logic that tries to describe to users what they can and cannot do with given translations.
[07:20] <jtv> stub: "can't do X, can't do Y, the usual explanation fails, BOOM."
[07:22] <jtv> I don't just want to replace the BOOM with "oh, we must be in read-only mode" and risk getting it wrong.  If worse comes to worst, I'll either create the read-only file (won't be cleaned up if you trip over your power lead during that split second though) or add a way to make is_read_only lie to you.
[07:23] <stub> Make it lie if tests need it, and LaunchpadFunctionalLayer can provide the API to twiddle it.
[07:24] <stub> The 'you can't do that because we are in read only mode' exception should already generate a 'you can't do that now' error page. Perhaps some code is swallowing exceptions it shouldn't be?
[07:25] <stub> Oh,... you are looking before you leap, so yeah.
[07:25] <stub> Nobody else worries about that - read only mode is rare.
[07:27] <jtv> stub: looks like is_read_only is merely getting a different request object than I'm creating, so I can work with that
[07:30] <jtv> BTW I am seeing some repeat requests in these oopses, so somebody is clearly coming away with the impression that Launchpad doesn't work for them.  So might as well fix them.
[07:33] <stub> I think the error page is 'you can't do that now, maybe later' so it is reasonable for users to hit reload a few times (more reasonable to have a cup of tea between reloads though).
[07:33] <jtv> stub: that's not the case here... it's an assertion failure on a non-form page
[07:34] <jtv> So somebody visits a page and just gets an oops.
[07:35] <stub> Sounds like the problem is they get an oops instead of a ReadOnlyModeViolation exception getting raised and rendered by the error handler.
[07:35] <stub> You might be papering over the real bug
[07:35] <jtv> stub: no, because it's a read-only, non-form page.
[07:35] <jtv> Just visiting the page should not be a mode violation.
[07:36] <jtv> Somebody visits a page and just gets an oops.
[07:36] <stub> I understand that, but it still shouldn't be generating an OOPS.
[07:37] <stub> In fact, I can't see how it would oops due to being in read only mode if the page is genuinely read only. But I haven't seen the OOPS report.
[07:37] <stub> Oh... because lower level code manually checks is_read_only() and returns values that other code can't handle?
[07:38] <jtv> 'zacly
[07:39] <stub> So you shot yourself in the foot ;)
[07:40] <jtv> stub: we work as a team.  So we shoot each other in the foot, which is a lot easier to do.
[07:40] <stub> synnergy
[07:40] <jtv> and occasionally, gangrene
[07:41] <jtv> al-maisan can praise himself lucky he missed that bit of TMI
[07:41]  * al-maisan resists the urge to ask what he missed .. :P
[07:42] <jtv> al-maisan: good.  Just be grateful your connection blinked.
[07:42] <al-maisan> :)
[08:27] <jtv> mwhudson: can tests access branches by their http URLs in any way?
[08:28] <adeuring> good morning
[08:28] <jtv> good morning adeuring
[08:28] <adeuring> hi jtv!
[08:45] <jtv> thumper: can you tell me of a way in which a test can access a branch by its http URL?
[08:45] <thumper> jtv: http://bazaar.launchpad.net/~user/project/name
[08:46] <jtv> thumper: in a test?
[08:47] <thumper> jtv: not at this time of the night
[08:47] <jtv> thumper: I'll take that as "too hard to test" then.  Thanks for responding though!
[08:48] <thumper> jtv: take it as "I'm tired"
[08:48] <jtv> thumper: ok, I'll go bother North-Americans when they get here.  Thanks.
[08:59] <wgrant> jtv: What're you trying to do?
[09:01] <jtv> wgrant: trying to test the bit where a buildfarm slave retrieves the contents of a branch through http
[09:02] <wgrant> jtv: I think you are violating the spirit of our poor slave code by adding tests to it.
[09:02] <jtv> wgrant: good point, thanks bye!
[09:03] <jtv> wgrant: then again, it wouldn't be a slave if its life was meant to be easy
[09:03] <wgrant> jtv: Heh.
[09:03] <jtv> Right now I'm testing it with a whatever-URL-LP-wants-to-give-for-it, but that little bit of extra realism would be nice
[09:04] <wgrant> HTTP branch access normally goes through Apache, doesn't it? I don't think it works for tests.
[09:09] <jtv> wgrant: that's what I think too, but I feel I would be remiss if I didn't at least look for a way.
[09:10] <wgrant> jtv: Indeed.
[09:24] <mrevell> Morning
[09:39] <mwhudson> jtv: no :/
[09:39] <mwhudson> jtv: in the testrunner config, branch.warehouse_url is a file:/// url that can be accessed
[09:39] <mwhudson> (with luck and a following wind, this area of the testing is pretty horrible)
[09:40] <jtv> mwhudson: I figured.  Accepted risk of this part of the code, I suppose.  But had to try.  Thanks!
[09:43] <mwhudson> jtv: at some point we'll maybe come up with a testing http server that we can use in tests
[09:43] <mwhudson> but it doesn't exist yet
[09:44] <jtv> mwhudson: given what the weather was like in NZ this "summer," I can see that you'd want the extra dissipation from your CPU
[09:44] <wgrant> I think I've almost dried out from that lovely Saturday.
[09:44] <mwhudson> jtv: summer waited until the day after lca
[09:45] <mwhudson> it was a gorgeous day today
[09:45] <mwhudson> but gosh yeah, the weekend between the sprint and the conference was pretty special
[09:45] <jtv> mwhudson: I didn't.  Which is a shame because someone I missed at both LCA _and_ FOSDEM (note opposite sides of globe) had business calling me recently
[09:45] <jtv> To be fair, FOSDEM was colder than LCA.
[09:45] <jtv> Barely.
[09:46] <jtv> Mostly because I wasn't wearing my coat when I went outside.
[09:46] <mwhudson> i took this yesterday: http://www.flickr.com/photos/mwhudson/4402652072/
[09:46] <wgrant> I thought it would be reasonable to walk between the hotels on Saturday. But no, no, it had to start ABSOLUTELY POURING when I was a few minutes out.
[09:46] <mwhudson> well, it doesn't actually ever get hot in wellington
[09:46] <mwhudson> (max temp ever recorded: 29 deg C)
[09:46] <wgrant> Nice.
[09:46] <jtv> mwhudson: remind me to drop by sometime...  Shame my next round-the-world flight goes the other way around
[09:47] <jtv> mwhudson: wgrant and I met in the street that day because we were blown along different roads towards the same intersection
[09:47] <wgrant> Ah, yes, that's right.
[09:47] <jtv> wgrant: good thing you managed to retract that elbow
[09:48] <jtv> If I'd flinched I wouldn't have been able to grab the lamppost.
[09:48] <wgrant> Heh.
[09:49] <jtv> mwhudson: I can't begin to explain how exotic that view is to someone from a country where a subliminal slope in the landscape is counted as the national Mountain.
[09:52] <mwhudson> jtv: wellington is VERY like that
[09:52] <mwhudson> jtv: thailand has lumpy bits though, doesn't it?
[09:53] <jtv> mwhudson: to me wellington looks a lot more like your picture than like where I come from
[09:53] <mwhudson> jtv: i mean, very not flat
[09:53] <mwhudson> sorry, bit unclear
[09:53] <jtv> quite :)
[09:53] <mwhudson> emma's workplace is 1000m across, 200m down
[09:53] <jtv> the most densely populated parts (such as "here") are pretty flat
[09:54] <jtv> What parts get flooded has more to do with the state of the sewage system than elevation.
[09:54] <wgrant> That seems to be the case in most places
[09:54] <wgrant> But Wellington's founders were clearly crazy.
[10:59] <deryck> Morning, everyone.
[11:01] <mrevell> Guten morgen deryck
[11:04] <bigjools> eyup deryck
[11:22] <adiroiban> BjornT: hi! do you know how can I run windminll test in „headless” mode ?
[11:45] <deryck> intellectronica, what happened to your branch for better queries when calculating max_bug_heat?  Did it make the rollout?
[11:46] <intellectronica> deryck: it landed, but didn't make the rollout
[11:46] <intellectronica> iiuc it's designated for a reroll or cp?
[11:47] <deryck> intellectronica, that's what I thought, too.  Just didn't see the card on the kanban board.
[11:48] <intellectronica> deryck: it seems cards disappear from the rightmost columns? i definitely moved the card there last night
[11:48] <intellectronica> are you or someone else moving the cards, or is there some automated process?
[11:49] <deryck> intellectronica, ah, you had it in done-done?  I moved all of them to archive late yesterday, with the release out of the way.  no worries.
[11:49] <deryck> intellectronica, or maybe someone came behind me as part of the release and moved your card, if it was the lone card there.
[12:21] <BjornT> adiroiban: the easiest is to use xvfb-run. e.g. "xvfb-run -s '-screen 0 1024x768x24' bin/test -t test-to-run"
[12:22] <adiroiban> BjornT: well, I'm trying to produce an testing environment similar to ec2 on one of my remote computers
[12:23] <adiroiban> on which I have ssh and root account
[12:24] <adiroiban> ok. so I have to manualy start the X framebuffer
[12:24] <wgrant> 'make check' will use xvfb-run, won't it?
[12:47] <bigjools> DISPLAY= make check
[12:47] <bigjools> much easier :)
[13:14] <didrocks> jml: ok :)
[13:14] <jml> hey folks
[13:14] <didrocks> hey guys :)
[13:14] <jml> didrocks & I are working on exposing some API stuff to make it much, much easier to opportunistically write Ubuntu apps
[13:14] <leonardr> salgado, jml, do you know if there is a reason why the launchpad web service does not publish public ssh keys? is it for security reasons?
[13:15] <leonardr> it came up twice yesterday
[13:15] <jml> leonardr, no, there isn't. I'm actively helping didrocks expose them :)
[13:15] <leonardr> ok, awesome
[13:15] <jml> leonardr, it's just https://launchpad.net/+people/me/+sshkeys after all
[13:15] <didrocks> there should be a branch hanging somewhere :)
[13:15] <jml> but!
[13:15] <jml> what is perhaps more interesting is exposing adding new SSH keys via the API
[13:16] <jml> and adding new GPG keys
[13:16] <BjornT> adiroiban: ec2 uses xvfb-run. you can look in test_on_merge.py, which is what ec2 runs.
[13:16] <leonardr> jml: yeah, i meant the functionality to add the keys as well as look at them
[13:16] <didrocks> (for the note, that's the hardest part for Quickly user)
[13:16] <didrocks> not uploading the right gpg key, and so on…
[13:18] <jml> leonardr, well, I guess the question is how much easier OAuth is to hack than whatever the browser normally does
[13:18] <jml> leonardr, a question I'm almost wholly ignorant of.
[13:19] <adiroiban>  thanks!
[13:22] <jml> so where were we
[13:22] <jml> ahh yes.
[13:22] <jml> we want to add SSH keys so that people can upload branches
[13:23] <jml> and we want to create the user's first PPA, and guide them through everything up to that point
[13:23] <jml> so we've exposed GPG keys and SSH keys...
[13:24] <persia> Users still just get/push public GPG keys and LP checks the keyserver, right?
[13:24] <jml> I don't know
[13:24] <james_w> no
[13:25] <jml> At least we need to link a GPG key to an account and to sign the CoC
[13:25] <persia> Please confirm.  Lots of folk set expiration dates in keys and then republish updates if they don't wish them to expire, which is supported now, and would break if that wasn't still true.
[13:25] <james_w> you decrypt a piece of text LP sends to you to get a string out of it which you give back to LP
[13:25] <persia> james_w: No?  Was that way in November (last time I updated my key)
[13:26] <jml> persia, if that's a genuine concern then send an email please, I've got too much on write now to get distracted on another thing
[13:26] <jml> so, my questions...
[13:26] <jml> what's the right internal api for adding GPG keys?
[13:26]  * persia will just test and file a bug if it breaks, expecting that it would only break from a structural change
[13:27] <james_w> https://help.launchpad.net/YourAccount/ImportingYourPGPKey
[13:27] <james_w> jml: you mean internal API, or exposed API?
[13:27] <didrocks> james_w: yeah, I remember about that. I think we can pause and tell user "check your email, past what's in it there" (and Quickly does the decrypt and send it)
[13:27] <jml> james_w, internal
[13:28] <james_w> jml: that I do not know
[13:28] <james_w> didrocks: yeah, that's probably about the best you can do absent events/callbacks in the API
[13:29] <jml> didrocks, I guess for this we should just expose an API that takes a fingerprint and does whatever https://launchpad.net/people/+me/+editpgpkeys does
[13:29] <didrocks> james_w: jml: agreed.
[13:30] <jml> james_w, statik has started some work on events/callbacks
[13:31] <didrocks> (so, quickly should upload the public key in the ubuntu keyserver first, not sure about the delay before refreshing, but I'll take that by experience :))
[13:31] <jml> didrocks, yeah, that sounds right.
[13:32] <jml> didrocks, so, I guess that means we should add a 'registerGPGKey' method to IPerson
[13:33] <didrocks> jml: oki
[13:34] <jml> didrocks, I don't know what to do with the codeofconduct stuff
[13:34] <jml> didrocks, nor with "creating a PPA"
[13:34] <jml> but we can figure those out, or maybe bigjools will hepl
[13:34] <didrocks> jml: right, I think first target is gpg and ssh key
[13:35] <bigjools> jml: are you talking about adding a PPA through the API?
[13:35] <didrocks> (in any case, for the CoC, Quickly should still present this with a "do you agree?" before upload the signature)
[13:35] <didrocks> bigjools: yeah
[13:37] <bigjools> I have always avoided doing that because it's at risk from rogue scripts creating loads of junk PPAs
[13:38] <didrocks> bigjools: the issue is that a lot of Quickly users don't get how to create one and also some others app are doing screen scrapping for that IIRC
[13:39] <didrocks> but I still understand your concern, and that's why I still think project creation should be manual and don't intend to automatize it in Quickly :)
[13:40] <bigjools> yeah - would we allow api creation of people etc?  same problem. and opens things up nicely for spammers.
[13:41] <jml> bigjools, aren't they already at risk from screenscrapers?
[13:42] <bigjools> yes but that involves more effort
[13:42] <jml> what's the cost of a PPA with nothing in it?
[13:42] <bigjools> risk of spam descriptions cluttering the search
[13:43] <bigjools> also
[13:43] <bigjools> once you create one you can't change your name
[13:43] <bigjools> so I want people to see the big fat warning on the web ui
[13:45]  * bigjools -> food
[13:45] <jml> bigjools, we could work around those problems first by deleting inactive empty PPAs and secondly by encouraging clients to warn their users.
[13:45] <bigjools> ppa deletion is a whole 'nother kettle of fish :)
[13:48] <jml> didrocks, ok let's keep going :)
[13:49] <didrocks> jml: oki
[13:50] <jml> didrocks, we need to find the code behind the editgpgkeys page
[13:50] <jml> didrocks, and then push it down into the model and then expose it.
[13:51] <didrocks> jml: make sense
[13:53] <jml> didrocks, ValidateGPGKeyView in canonical.launchpad.browser.logintoken
[13:53] <jml> the name "logintoken" scares me a little, I don't know how it fits in...
[13:55] <jml> _getGPGKey gets the key from the server
[13:55] <didrocks> jml: sorry, still grepping (my VM is very slow…)
[13:55] <jml> didrocks, fix your install :)
[13:56] <didrocks> jml: if only I would have been able to install on my lucid box at Portland :)
[13:56] <jml> didrocks, heh
[13:57] <didrocks> jml: ok, got it :)
[13:58]  * jml is getting his zope migraine again
[13:59] <jml> didrocks, afaict, 'validate' is called first
[13:59]  * james_w hands jml an IAsprin
[13:59] <jml> didrocks, and then 'continue_action_gpg' is called
[13:59] <jml> hahaha
[13:59] <didrocks> james_w: oh, you have a collection of IAsprin_set so? ;)
[14:00] <jml> didrocks, the interesting methods are _getGPGKey and _activateGPGKey
[14:00] <didrocks> jml: ok
[14:00] <jml> didrocks, they've got way too much logic for browser code imho.
[14:01] <jml> didrocks, so I guess when I get back from the half-hour meeting I'm about to go to, I'm going to move them mostly into model code... maybe as methods on IGPGKeySet or something
[14:01] <didrocks> a lot of intercall hidden functions in that file :)
[14:01] <jml> yeah
[14:01] <jml> and too much state stored on objects as a substitute for passing parameters :(
[14:02] <jml> be back soon
[14:02] <didrocks> jml: have a good meeting! Thanks again :)
[14:19] <adiroiban> using lazr.restful, can I export as a webservice operation, a method decored with @property ?
[14:32] <gmb> Argh. Is there something that I have to do to get store.flush() to actually work in a test? For some reason the objects that I create before doing store.flush() don't get stored unless I do a transaction.commit().
[14:49] <Ursinha> hey gmb, I see this oops happened during the rollout, do you know what could have caused that? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1523EC1637
[14:51] <gmb> Ursinha: Er... I think you're asking the wrong guy. That looks like a Soyuz oops.
[14:51]  * noodles775 looks
[14:51] <bigjools> ARGH
[14:51] <Ursinha> gmb: I don't actually know if that's Bug's, Soyuz' or foundations
[14:52] <bigjools> soyuz
[14:52] <gmb> \0/
[14:52] <gmb> I mean, too bad.
[14:52] <bigjools> :p
[14:52] <Ursinha> lol
[14:52] <bigjools> another release-critical for me
[14:53] <Ursinha> bigjools: there are 23 recorded oopses of that kind
[14:53] <bigjools> not surprised
[14:53] <bigjools> I can fix it
[14:53] <Ursinha> it seems all while the rollout was on
[14:53] <bigjools> easy fix - dunno how it slipped through
[14:53] <bigjools> hmmm
[14:53] <Ursinha> bigjools: let me check again
[14:54] <Ursinha> found 40 more
[14:55] <bigjools> Ursinha: the same url does not oops any more
[14:55] <Ursinha> bigjools: yes, I saw that too
[14:55] <bigjools> I think I know why it happened
[14:56] <bigjools> the database changed and edge was still running old code
[14:56] <bigjools> so it's a rollout issue
[14:56] <Ursinha> bigjools: that's why I thought that could be a foundations issue
[14:57] <bigjools> Ursinha: could be, I don't know the exact details of how rollouts are done
[15:11] <jml> didrocks, I'm a loser.
[15:11] <didrocks> jml: no, just very busy :)
[15:13] <jml> salgado, hi. I'm looking at the GPG key stuff in browser/logintoken
[15:13] <jml> salgado, what is a logintoken?
[15:15] <salgado> jml, a temporary place where we store things that need validation (e.g. email addresses and gpg keys) before they can be added to their tables
[15:15] <jml> salgado, ahh, I see.
[15:15] <jml> salgado, so "context.consume()" means "remove it from the table"
[15:15] <salgado> the logintoken is also what's used to handle the validation
[15:16] <salgado> almost. it means mark the token as consumed so that it can't be used again
[15:16] <jml> salgado, that makes sense
[15:16] <doctormo> jml: are you working with didrocks to add the ssh key management?
[15:16] <jml> salgado, there seems to be a fair chunk of gpg key validation code in browser/logintoken
[15:17] <jml> salgado, any objections to me moving some of the logic to the model class?
[15:17] <didrocks> doctormo: right, jml is making the gpg part and I try to adapt it to ssh :)
[15:17] <jml> doctormo, yep. working on GPG right now.
[15:17] <jml> doctormo, didrocks has a branch that does the beginning of the SSH key stuff.
[15:17] <jml> doctormo, lp:~jml/launchpad/expose-gpgkeys-bug-389872 for the GPG work
[15:18] <doctormo> didrocks: In my code I download existing ssh public keys to compare them with local keys.
[15:18] <jml> man, I still need to file an FFe for Twisted 10.0
[15:19] <salgado> jml, nope, that should be ok, but you might want to check with registry as I think that's their code, no?
[15:19] <jml> salgado, I'm checking with you because your name is all over the 'bzr blame' output
[15:20]  * didrocks was sure jml would choose the "blame" alias :)
[15:20] <salgado> jml, not for the gpg-specific bits, I'd expect.  I've always managed to stay away from that code
[15:20] <jml> heh heh
[15:20] <jml> didrocks, I don't have time to type out anno...
[15:22] <jml> didrocks, the equivalent SSH code is in...
[15:22] <jml> didrocks, lib/lp/registry/browser/person.py, class PersonEditSSHKeysView
[15:23] <jml> didrocks, I think the add_ssh and remove_ssh methods could be split and put into model code too.
[15:24] <didrocks> jml: so, I should pull first, right? You changed that?
[15:24] <jml> didrocks, I'm going to go head-down to do the GPG stuff, if you were here in person I'd talk it through ...
[15:24] <didrocks> oh no, ssh
[15:24] <jml> didrocks, no, unchanged.
[15:24] <didrocks> ok
[15:24] <jml> didrocks, ask me any questions, I'll ping here as I make progress.
[15:25] <didrocks> jml: ok, I've to push some packages into ubuntu right now, but I stick around (will do the ssh part later)
[15:28] <Ursinha> d/3
[15:28] <Ursinha> #fail
[15:29] <deryck> intellectronica, I can't find that card or any record of it -- the one you just landed to db-devel yesterday.
[15:29] <deryck> intellectronica, I'll just add a new card to "Landed."  You didn't QA this yet, right?
[15:30] <intellectronica> deryck: I QAd this by cowboying it onto staging
[15:30] <intellectronica> maybe i'm wrong about the card, but i was pretty sure i did something with the ban when it landed
[15:31] <intellectronica> deryck: should i create a card to put in the archive?
[15:32] <deryck> intellectronica, yeah, create a new card, but put it in Done-Done, please.
[15:58] <Ursinha> intellectronica: hi :) today I'm choosing random bugs' people to ask about oopses :) I'm not sure if this oops is a known issue: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1524C2016
[15:58] <asabil> hi all
[15:58] <intellectronica> Ursinha: i'm not sure either, and can't look immediately (in the middle of a review and i have a call in 2m). promise to get back to you later
[15:59] <Ursinha> intellectronica: ah, ok :) I can ask in the prod. meeting, don't worry
[15:59] <Ursinha> :)
[15:59] <Ursinha> intellectronica: thanks anyway
[16:18] <Ursinha> allenap: (or intellectronica :), could you help me with the oops I mentioned above, some time today?
[16:19] <allenap> Ursinha: Do you mean the one you asked about in the prod meeting?
[16:20] <Ursinha> allenap: yeah - I've asked intellectronica a bit earlier today too
[16:21] <jml> everything is far too complex.
[16:22] <intellectronica> Ursinha: otp, will have a look soon
[16:26] <jml> there's a comment here that implies that it's possible to active a GPG key without being logged in.
[16:26] <jml> that seems odd to me.
[16:27] <intellectronica> jml: it makes sense in theory, since gpg in itself can provide the necessary validation
[16:27] <intellectronica> maybe it can be done via email?
[16:27] <jml> intellectronica, it's in browser code
[16:27] <jml> intellectronica, which doesn't _necessarily_ mean it's not done by email
[16:28] <intellectronica> jml: well, cherche le pagetest
[16:28] <jml> intellectronica, my French is weak. Does that mean "sucks to be you"?
[16:29] <intellectronica> :D
[16:29] <intellectronica> jml: just in case this was a series question, the phonetic similarity should have been a giveaway. it means 'look for the ___'.
[16:30] <jml> intellectronica, it's not a serious question :)
[16:31] <jml> I might even bust out the word "cognate" to prove it, if called upon to do so.
[16:36] <intellectronica> Ursinha: i don't know what's the deal with that oops, and i don't want to push it back, but it looks like an authentication bug, rather than a bugs bug
[16:36] <intellectronica> Ursinha: is there a bug for it?
[16:37] <Ursinha> intellectronica: not yet, I wasn't sure if that was a known bugs problem or a new foundations one
[16:37] <intellectronica> Ursinha: my guess is foundations, but feel free to subscribe me to the bug just so that i can follow up on it later
[16:38] <Ursinha> sure, thanks intellectronica
[16:38] <intellectronica> sorry i couldn't help more
[16:49] <jml> phew
[16:52] <deryck> intellectronica, I moved your confirmation dialog bug into WIP but blocked, citing other work had to be done.
[16:52] <deryck> intellectronica, but I think we should consider it like this, to force us back to it sooner rather than later.
[16:52] <deryck> ok?
[16:52] <intellectronica> deryck: cool, makes sense
[16:52] <deryck> intellectronica, excellent.
[16:54] <jml> didrocks, I have pushed up some code
[16:54] <jml> still no exposed API
[16:54] <jml> but maybe the diff means something.
[16:56] <didrocks> jml: ok, I'll have a look, thanks  :) /me really busy until… I don't know :)
[16:57] <jml> didrocks, ok. cool. I'll keep plugging away at this.
[16:59] <didrocks> jml: thanks :)
[17:09] <intellectronica> flacoste: just a quick reminder that you've got an r-c request from me. another bug heat branch for the re-roll.
[17:14] <flacoste> intellectronica: ok, i'll look at it soon
[17:14] <intellectronica> cheers
[17:15] <leonardr> gary, bug #532025
[17:15] <mup> Bug #532025: Hard-coded version names in old scripts are duplicated in new versions of lazr.restfulclient <lazr.restfulclient:New> <https://launchpad.net/bugs/532025>
[17:15] <gary_poster> ah, I see leonardr
[17:16] <leonardr> gary: i don't think it's terribly urgent, but i could fix it in a couple hours
[17:17] <gary_poster> leonardr: I'm in favor of doing it now.  Please put it on the kanban board.  Force it in (we will be out of the limits)
[17:17] <leonardr> ok
[17:20] <leonardr> gary: ok, i've got another bug w/r/t the fake launchpadlib browser which i'm filing now
[17:21] <gary_poster> ok cool
[17:23] <allenap> Ursinha: Just read the scrollback. I'm at the same conclusion as intellectronica re. the OOPS from earlier. If you have filed a bug for it, or will, please can you subscribe me too?
[17:26] <Ursinha> allenap: sure
[17:57] <leonardr> gary, the unpleasant truth is in bug 532055
[17:57] <mup> Bug #532055: Trusted credential-management apps are broken and may be doomed <launchpadlib :New> <https://launchpad.net/bugs/532055>
[18:29] <Ursinha> allenap: have you seen this issue? bug 532078
[18:29] <mup> Bug #532078: Count of bugs with patches is wrong, +patches shows different information <Launchpad Bugs:New> <https://launchpad.net/bugs/532078>
[19:13] <mwhudson> good morning
[19:15] <Ursinha> morning mwhudson
[19:28] <gary_poster> thanks leonardr.  flacoste, when you have a moment, you might be interested in looking at https://bugs.edge.launchpad.net/launchpadlib/+bug/532055 also (if you haven't already ;-) )
[19:28] <mup> Bug #532055: Trusted credential-management apps are broken and may be doomed <launchpadlib :New> <https://launchpad.net/bugs/532055>
[19:33] <mars> deryck, ping
[19:33] <deryck> mars, on call
[19:33] <mars> ok, np
[19:46] <deryck> mars, off now, what's up?
[19:47] <mars> hi deryck, just wondering where the +patches view template is.  Trying to track down the revision popup positioning bug.
[19:48] <deryck> mars, I believe it's bugtarget-patches.pt in lip/lp/bugs/templates
[19:48] <mars> my copy of trunk may be messed up, files missing
[19:48] <deryck> kfogel could confirm this.  ^^
[19:49] <deryck> heh
[19:49] <deryck> kfogel wasn't here, I'd guess, mars. :-)
[19:49] <mars> kfogel / kfogel_, what was the name of the new +patches view template?
[19:50] <kfogel> deryck, mars: hi
[19:50]  * kfogel reads
[19:50] <kfogel> mars: uh, one sec
[19:50]  * deryck spins with all the kfogel*
[19:50] <kfogel> bugs-patches-view.pt I think
[19:50] <kfogel> mars: ^^
[19:50] <deryck> kfogel, bugtarget-patches.pt maybe?
[19:51] <kfogel> deryck: yeah, kfogel_ is from my under-surgery ubuntu box, whereas this one (talking now) is from my Debian lifeboat box.
[19:51] <kfogel> deryck: oh, that might be right
[19:51] <mars> lol
[19:51] <kfogel> mars: ^^
[19:51] <kfogel> mars: is it missing for you??
[19:51] <deryck> mars, it's only in db-devel for me, but I haven't updated all day.
[19:51] <mars> kfogel, yes, but I may have a serious branching issue at play instead
[19:52] <kfogel> mars: ok
[19:52] <mars> deryck, oh?  db-devel only would explain it :)
[19:52] <mars> I'm looking in devel
[19:54] <kfogel> mars: but it should have been merged over, no?
[19:55] <mars> kfogel, did you land your changes on devel, or on db-devel?
[19:55] <mars> but yes, with the rollout, devel and db-devel should be in sync
[19:57] <deryck> mars, kfogel -- perhaps we're waiting on a re-roll to merge db-stable back into devel?  Not sure how we normally do this honestly.
[19:57] <mars> bzr pull db-devel spat out 48 text conflicts.  Didn't know pull could do that...
[19:58] <mars> deryck, kfogel, I would like to rule out branch insanity on my end first, before delving too deep.  I'm using the +patches code as a lifeline - it's on edge, so it should be in devel
[19:59] <deryck> mars, I just updated and it's not in devel for me either.
[19:59] <kfogel> mars: landed on db-devel
[19:59] <kfogel> mars: all that work was on db-devel, because it involved db changes.
[20:01] <mars> kfogel, ok.  My understanding was that a db-devel landing shows up on staging, but not on edge.  *If* I'm remembering correctly, we did that for the YUI3 upgrade.
[20:02] <kfogel> mars: I believe that is correct.
[20:02] <mars> ok, so first I will rule out db-devel insanity on my end...
[20:02] <kfogel> mars: dev.launchpad.net/Trunk, but I think you're right -- db-devel changes show up on edge and main launchpad when we do a new release.
[20:02] <kfogel> which we either have done, or are in the middle of doing :-).
[20:02] <mars> right
[20:02] <kfogel> mars: devel always goes to edge; db-devel goes to staging.
[20:03] <kfogel> mars: just to be pedantically repetitive and prolixly verbose about it.
[20:03] <mars> so +patches is visible on edge, therefore...
[20:03] <kfogel> mars: therefore I think it must be in devel?
[20:03] <kfogel> mars: is it visible in non-edge?
[20:03] <mars> I am not insane, this exists: https://bugs.edge.launchpad.net/gwibber/+patches
[20:04] <mars> I am not insane, this also exists: https://bugs.launchpad.net/gwibber/+patches
[20:04] <thumper> guys, db-devel hasn't been merged back into devel yet
[20:05] <mars> thumper, so we're in limbo!
[20:05] <thumper> mars: go write some docs or something :)
[20:06] <mars> well, this means something was chewing up my local launchpad branches.
[20:07] <kfogel> thumper: I take it PQM is still gated then?
[20:07] <thumper> kfogel: yep
[20:07] <kfogel> CUZ I'M IN UR PQM WAITIN TO LANDZ
[20:07] <kfogel> ok
[20:07] <kfogel> I guess that branch will wait :-)
[20:11] <sinzui> adiroiban: I replied to bug 531261. There are some places in the code that may show you how to make ISeriesMixin complete
[20:11] <mup> Bug #531261: Move ISeriesMixin to lp.registry.interfaces.series <cleanup> <tech-debt> <Launchpad Registry:In Progress by adiroiban> <https://launchpad.net/bugs/531261>
[20:14] <adiroiban> sinzui: ok. I will try to move them.
[20:15] <adiroiban> I was also checking parent attribute, but distroseries already have the „parent” attribute and it returns the parent distribution
[20:16] <sinzui> adiroiban: so we need to add a parent to productseries?
[20:17] <adiroiban> sinzui: productseries already has a „parent” and it return self.product
[20:18] <sinzui> so we can move attrs like bug_supervisor to the mixin right?
[20:18] <adiroiban> sinzui: ah.. sorry. It looks like both „parent” implementations are ok
[20:20] <adiroiban> sinzui: yes. we can move them in the mixin
[20:22] <adiroiban> I will try to move as much as posible and will come back with questions/issues. Thanks for now :)
[20:35] <adiroiban> sinzui: do we still need „id” attribute in IProductSeriesPublic and IDistroSeriesPublic ?
[20:35] <sinzui> I think so.
[20:43] <adiroiban> where are they implemented?
[20:44] <adiroiban> I can not find them in model.productseries or model.distroseries
[20:49] <mwhudson> garara
[20:50] <mwhudson> why is the code in canonical.launchpad.webapp, some of the most delicate and central in the whole system, so poorly tested?
[20:50] <mwhudson> or tested in ways i can't find, anyway
[20:51] <mwhudson> flacoste: you there?
[20:52] <flacoste> mwhudson: i am
[20:52] <mwhudson> flacoste: do you know where the tests for adding the notification messages about read only mode are?
[20:52] <flacoste> hmmm
[20:52] <flacoste> i would bet in the pagetest
[20:53] <mwhudson> ah
[20:53] <flacoste> mwhudson: xx-read-only-=mode.txt
[20:53] <flacoste> without the =
[20:53] <flacoste> in lib/canonical/launchpad/pagestests
[20:53] <mwhudson> ah, you are right
[20:56] <mwhudson> flacoste: do you know why api requests don't explode from having notifications added in read-only mode?
[20:57] <mwhudson> flacoste: i was looking at fixing https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403281
[20:57] <mup> Bug #403281: public xmlrpc requests broken during read only period <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/403281>
[20:57] <mwhudson> but it seems like testing is going a bit awkward
[20:58] <flacoste> mwhudson: API requests don't use notifications
[20:58] <flacoste> mwhudson: and tbh, i don't understand how XML-RPC adds notification
[20:58] <mwhudson> flacoste: well, it blows up trying
[20:58] <mwhudson> INotificationResponse(request) raises CannotAdapt
[20:58] <flacoste> do you know where notifications are added?
[20:59] <mwhudson> flacoste: yeah, publication.py:212 ish
[21:00] <flacoste> mwhudson: api probably don't blow up because they can probably adapt
[21:00] <flacoste> they are a subclass of LaunchpadBrowserRequest
[21:00] <mwhudson> right
[21:00] <flacoste> that's probably not the case for the XMLRPC ones
[21:00] <mwhudson> but PublicXMLRPCRequest isn't
[21:00] <flacoste> you could override maybeReadOnlyRequest in the XMLRPC publiation
[21:01] <flacoste> to not add the notification
[21:01] <flacoste> or make PublicXMLR_PCRequest provide INotification...
[21:01] <mwhudson> what i was thinking of doing was INotificationResponse(request, None) and coping with the None returned
[21:02] <flacoste> that's also valid
[21:02] <mwhudson> flacoste: can you see what the try:/except ComponentLookupError: is for in maybeNotifyReadOnlyMode ?
[21:02] <flacoste> and probably the best option
[21:02] <flacoste> actually, i think it was meant to catch your use case
[21:02] <flacoste> but it's possible that a zope ugprade change the exception hierarchy
[21:02] <mwhudson> :/
[21:03] <mwhudson> ah
[21:03] <flacoste> or that code was bad in the first place
[21:03] <flacoste> never tested....
[21:03] <flacoste> i'd say just change the exception
[21:03]  * mwhudson deletes it
[21:03] <mwhudson> oh, not do the , None thing?
[21:06] <mwhudson> oh, i made up the CannotAdapt exception, it raises TypeError :(
[21:06] <flacoste> so handling None is probably better
[21:06] <flacoste> since TypeError can easily mask a programming error
[21:08] <mwhudson> right
[21:09] <mwhudson> flacoste: thanks for the hints
[21:11] <flacoste> my pleasure
[21:14] <wgrant> jml: Hmm, is it really a good idea to make authentication tokens writable by normal OAuth tokens?
[21:15] <flacoste> mwhudson: is lp-serve something Launchpad specific or is it part of bazaar itself?
[21:15] <mwhudson> flacoste: it's launchpad specific, but fairly small
[21:15] <mwhudson> flacoste: it's like bzr serve, but backed onto the launchpad vfs, not the file system
[21:16]  * mwhudson stabs TestReadOnlyModeSwitches
[21:16] <flacoste> mwhudson: ok, how impossible is it to have that command show the branch it's serving in the command line?
[21:16] <mwhudson> i guess i should just write a new class
[21:16] <mwhudson> flacoste: you mean using setprocargs or whatever that's called?
[21:17] <flacoste> mwhudson: you mean that the branch served is only known after the program is started, right?
[21:17] <mwhudson> flacoste: right
[21:17] <flacoste> mwhudson: is there a way now when a bzr lp-serve process starts eating all memory to know what was happening in it?
[21:17] <flacoste> what branch was being served
[21:17] <mwhudson> flacoste: not really :/
[21:17] <flacoste> is there a bug for that already?
[21:17] <mwhudson> flacoste: i guess lsof
[21:18] <flacoste> you mean, seeing which file it has open
[21:18] <mwhudson> yeah
[21:18] <flacoste> yeah, that's heavyweight
[21:18] <flacoste> i'll file a bug for the losa's sake
[21:18] <mwhudson> there's a bug about recording access statistics for branches
[21:18] <mwhudson> which is related
[21:18] <mwhudson> but nothing for this losa use case that i know about
[21:19] <mwhudson> flacoste: i hear crowberry was running out of memory even now it's got 32 gigs?
[21:19] <flacoste> yep
[21:19] <mwhudson> owwwwwwwwwww
[21:19] <flacoste> a bzr lp-serve process was chewing 21G of memory!
[21:19] <flacoste> that's a bug in bzr for sure
[21:19] <mwhudson> !!!
[21:19] <mwhudson> !!!
[21:19] <flacoste> for knowing the branch in cause would help
[21:20] <mwhudson> yeah, i can see that
[21:20] <sinzui> That is a bug a big a Mothera.
[21:20] <wgrant> That is impressive.
[21:21] <mwhudson> i think setting an rlimit of 4 gigs or so for lp-serve processes would be uncontroversial...
[21:21] <flacoste> mwhudson: can you file a RT about this? or is this something we should do in code?
[21:21] <mwhudson> that's something we can do in code
[21:22] <wgrant> mwhudson: Do you know why there are three Linux imports running concurrently? That seems insane, given how long even a single one will take.
[21:22] <mwhudson> wgrant: all but one got suspended
[21:23] <wgrant> mwhudson: Ah, so they are. Great.
[21:25] <mwhudson> flacoste: https://bugs.edge.launchpad.net/launchpad-code/+bug/532213
[21:25] <mup> Bug #532213: limit memory bzr-serve processes can use <trivial> <Launchpad Bazaar Integration:Triaged by mwhudson> <https://launchpad.net/bugs/532213>
[21:25] <flacoste> thanks
[21:25] <flacoste> mwhudson: i also filed https://bugs.edge.launchpad.net/launchpad-code/+bug/532210
[21:26] <mwhudson> flacoste: ok
[21:32] <donatas_s> Hello
[21:33] <donatas_s> There are problem with launchpad server:  Sorry, there was a problem connecting to the Launchpad server.
[21:39] <mwhudson> donatas_s: which url?
[21:42] <donatas_s> It just start to work, but there was problem with all launchpad url
[21:42] <gary_poster> one appserver has been acting up
[22:54] <mwhudson> flacoste: able to review this publication fix, seeing as we talked about it already?
[22:54] <mwhudson> it's pretty tiny
[22:54] <flacoste> mwhudson: sure
[22:58] <mwhudson> flacoste: https://code.edge.launchpad.net/~mwhudson/launchpad/read-only-xmlrpc-bug-403281/+merge/20707
[22:58] <mwhudson> oh, damnit i forgot to add comments to the tests
[23:57] <jml> flacoste, re lp-serve
[23:57] <jml> flacoste, I got *this* close to writing decent branch access logs for it
[23:58] <jml> wgrant, I don't know, honestly.
[23:59] <wgrant> jml: The point of OAuth is to allow users to revoke application privileges.
[23:59] <wgrant> If applications can add authentication tokens, that becomes difficult.