[13:01] <xnox> https://code.launchpad.net/~xnox/lazr.authentication/fix-wsgi-intercept-0.6/+merge/224287
[13:03] <xnox> https://code.launchpad.net/~xnox/lazr.restfulclient/py3/+merge/222172
[13:03] <xnox> are all of above managed by tumble thing? ( tarmac?)
[13:22] <wgrant> xnox: The trunks of both lazr.authentication and lazr.restfulclient are manually managed, not by Tarmac or PQM.
[13:23] <wgrant> xnox: What's with the weird spacing changes in your wsgi_intercept branch for lazr.restfulclient?
[13:27] <xnox> wgrant: hehe. wsgi_intercept 0.5.x -> 0.6.x series wraps tracebacks into it's own exception thus interractive raised expection textual representation is now different
[13:28] <xnox> wgrant: it does look odd, should i be fixing wsgi_intercept to print stuff as it used to?
[13:28] <xnox> the 0.6.0 came out in Novermber 2013.
[13:30] <wgrant> xnox: I'd quite like to know why those spacing changes happen; they look a lot like a bug.
[13:31] <xnox> wgrant: yeah, running without any ...., all headers are printed without space after colon
[13:32] <wgrant>                 self.output.write(k + b':' + v + b"\n")
[13:32] <wgrant> That sure looks buggy to me.
[13:32] <xnox> yeah, that's wrong.
[13:33] <wgrant> Trivial fix, too, fortunately :)
[13:33] <xnox> i'll upload that into debian & propose upstream....
[13:33] <xnox> can buildout use system-wide packages somehow ?
[13:33] <wgrant> xnox: It *can*, but we prefer not to at this point.
[13:34] <wgrant> We currently support running Launchpad on lucid, precise and trusty.
[13:34] <wgrant> We backport some packaged things like python-debian, but it's often more trouble than it's worth.
[13:35] <wgrant> (Particularly when it's a non-backward compatible change like this; we'd have to upgrade the package and Launchpad in lockstep)
[13:35] <wgrant> Hm
[13:35] <wgrant> So that header format isn't actually illegal. Whitespace isn't mandatory.
[13:35] <wgrant> But I've never seen any non-terrible app not prefix the value with a single space.
[13:36] <xnox> yeah, all dumps i've ever seen have a space.
[13:36]  * xnox ponders if it is in-fact in the HTTP RFC or some such.
[13:36] <wgrant> " The field value MAY be preceded by any amount of LWS, though a single SP is preferred."
[13:36] <cjwatson> beat me to it
[13:37] <cjwatson> was literally just selecting that text :)
[13:41] <wgrant> Heh
[13:42] <xnox> opened a merge proposal upstream, now making upload into debian.
[13:43] <wgrant> Excellent.
[13:43] <wgrant> That'll save a lot of trouble with fixing tests in lp:launchpad too.
[13:43] <wgrant> "fixing"
[13:44] <xnox> and all of openstack
[13:44] <xnox> although they might not be doing doctests as much as launchpad does.
[13:57] <xnox> wgrant: barry did review this one https://code.launchpad.net/~xnox/lazr.restfulclient/py3/+merge/222172 can you please merge it?
[13:58] <xnox> or should barry do the merging?
[13:58] <wgrant> xnox: Doing.
[14:00] <wgrant> If GitHub's JS stops hanging my Firefox...
[14:00] <xnox> wgrant: you merge lazr on github and then mirror to launchpad? *giggle*
[14:01] <wgrant> Heh, no, was looking at your PR
[14:01] <wgrant> xnox: I note a potential problem. The new wsgi_intercept doesn't seem to have the zope.testbrowser or mechanize support that the old one does, and Launchpad uses that.
[14:01] <wgrant> So it'll work for lazr.restfulclient, but not Launchpad itself.
[14:02] <xnox> wgrant: horum. I'm working on python3-launchpadlib at the moment, so that should be fine. ev kind of have vetoed for me to go into python3 launchpad project =)))))))
[14:03] <wgrant> Heh
[14:03] <wgrant> It's just a bit weird that we have to keep Launchpad using an old version, but I guess we'll live.
[14:03] <wgrant> xnox: Can you set a commit message on https://code.launchpad.net/~xnox/lazr.restfulclient/py3/+merge/222172?
[14:03] <xnox> meh, as long as there are no security issues....
[14:04] <xnox> wgrant: done.
[14:04] <wgrant> I don't trust that library enough to let it near production :P
[14:04] <wgrant> It's test-only.
[14:06] <ev> xnox: hey now, I said you can spend your time however you like – I'm not your manager – but there were seemingly better places to invest that time in Launchpadland.
[14:07] <xnox> ev: yeah, rumour has it you are after python3-launchpadlib though ;-)
[14:07] <wgrant> Definitely :)
[14:07] <wgrant> Porting launchpadlib is pretty tractable once the lazr.restful test dep is pushed out-of-process.
[14:07] <wgrant> lp:launchpad is just about impossible without splitting it up.
[14:08] <xnox> ev: for some sort of steam-punk engine
[14:08] <ev> :)
[14:09] <wgrant> xnox: Landed, thanks.
[14:09] <wgrant> Poke me if you need anything else.
[14:11] <xnox> wgrant: my wsgi-intrcept fix was pulled upstream already =)
[14:13] <wgrant> Nice.
[14:29] <wgrant> cjwatson: That launchpad-buildd ltsp change seems a bit weird. Is ltsp in the closure that ubuntu-rtm will have, for example?
[14:30] <cjwatson> We could make it i386-only in line with the old make-chroot.sh, I guess
[14:31] <cjwatson> Though I suppose we'll still have i386 in rtm
[14:31] <cjwatson> It is weird, I just couldn't think of anything better, suggestions welcome
[15:04] <cjwatson> wgrant: Is the CSV file that appears to be written by lp:~wgrant/lp-ftbfs-report/production available anywhere for http://qa.ubuntuwire.com/ftbfs/ ?  I can't make the obvious URLs work, and I assume the main page is a server-side redirect of some kind
[15:06] <wgrant> cjwatson: It's at the totally logical and obvious URL of http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/primary-utopic.csv
[15:08] <cjwatson> Aha, thanks.
[15:09] <cjwatson> I was wondering about exposing data over time somehow
[15:53] <xnox> wgrant: may i request review/merge of https://code.launchpad.net/~xnox/lazr.authentication/fix-wsgi-intercept-0.6/+merge/224287 ?! that one seems wsgi_intercept genuinely staying spec compliant and lazr.authentication was not.
[15:53] <xnox> please =)
[17:54] <cjwatson> wgrant: Do you have any idea what the occasional build upload failures we see where the upload log just says "Server said:" are about?  I understand it's some kind of librarian glitch but not a lot more.  I've seen two so far with livefs builds, which is a fairly annoying rate
[17:54] <cjwatson> (particularly without retry)
[23:06] <wgrant> cjwatson: Hm, I guess it might be more common with livefses because they're bigger.
[23:06] <wgrant> It's some librarian glitch which I've not been able to reproduce locally.
[23:06] <wgrant> We should probably just fix it by making the client retry.