=== wallyworld_ is now known as wallyworld === mwhudson is now known as mwhudson- === mwhudson is now known as mwhudson-bip === mwhudson-bip is now known as mwhudson === mwhudson is now known as mwhudson-bip [13:01] https://code.launchpad.net/~xnox/lazr.authentication/fix-wsgi-intercept-0.6/+merge/224287 === jtv_ is now known as jtv [13:03] https://code.launchpad.net/~xnox/lazr.restfulclient/py3/+merge/222172 [13:03] are all of above managed by tumble thing? ( tarmac?) [13:22] xnox: The trunks of both lazr.authentication and lazr.restfulclient are manually managed, not by Tarmac or PQM. [13:23] xnox: What's with the weird spacing changes in your wsgi_intercept branch for lazr.restfulclient? [13:27] 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] wgrant: it does look odd, should i be fixing wsgi_intercept to print stuff as it used to? [13:28] the 0.6.0 came out in Novermber 2013. [13:30] xnox: I'd quite like to know why those spacing changes happen; they look a lot like a bug. [13:31] wgrant: yeah, running without any ...., all headers are printed without space after colon [13:32] self.output.write(k + b':' + v + b"\n") [13:32] That sure looks buggy to me. [13:32] yeah, that's wrong. [13:33] Trivial fix, too, fortunately :) [13:33] i'll upload that into debian & propose upstream.... [13:33] can buildout use system-wide packages somehow ? [13:33] xnox: It *can*, but we prefer not to at this point. [13:34] We currently support running Launchpad on lucid, precise and trusty. [13:34] We backport some packaged things like python-debian, but it's often more trouble than it's worth. [13:35] (Particularly when it's a non-backward compatible change like this; we'd have to upgrade the package and Launchpad in lockstep) [13:35] Hm [13:35] So that header format isn't actually illegal. Whitespace isn't mandatory. [13:35] But I've never seen any non-terrible app not prefix the value with a single space. [13:36] 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] " The field value MAY be preceded by any amount of LWS, though a single SP is preferred." [13:36] beat me to it [13:37] was literally just selecting that text :) [13:41] Heh [13:42] opened a merge proposal upstream, now making upload into debian. [13:43] Excellent. [13:43] That'll save a lot of trouble with fixing tests in lp:launchpad too. [13:43] "fixing" [13:44] and all of openstack [13:44] although they might not be doing doctests as much as launchpad does. [13:57] wgrant: barry did review this one https://code.launchpad.net/~xnox/lazr.restfulclient/py3/+merge/222172 can you please merge it? [13:58] or should barry do the merging? [13:58] xnox: Doing. [14:00] If GitHub's JS stops hanging my Firefox... [14:00] wgrant: you merge lazr on github and then mirror to launchpad? *giggle* [14:01] Heh, no, was looking at your PR [14:01] 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] So it'll work for lazr.restfulclient, but not Launchpad itself. [14:02] 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] Heh [14:03] It's just a bit weird that we have to keep Launchpad using an old version, but I guess we'll live. [14:03] xnox: Can you set a commit message on https://code.launchpad.net/~xnox/lazr.restfulclient/py3/+merge/222172? [14:03] meh, as long as there are no security issues.... [14:04] wgrant: done. [14:04] I don't trust that library enough to let it near production :P [14:04] It's test-only. [14:06] 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] ev: yeah, rumour has it you are after python3-launchpadlib though ;-) [14:07] Definitely :) [14:07] Porting launchpadlib is pretty tractable once the lazr.restful test dep is pushed out-of-process. [14:07] lp:launchpad is just about impossible without splitting it up. [14:08] ev: for some sort of steam-punk engine [14:08] :) [14:09] xnox: Landed, thanks. [14:09] Poke me if you need anything else. [14:11] wgrant: my wsgi-intrcept fix was pulled upstream already =) [14:13] Nice. [14:29] cjwatson: That launchpad-buildd ltsp change seems a bit weird. Is ltsp in the closure that ubuntu-rtm will have, for example? [14:30] We could make it i386-only in line with the old make-chroot.sh, I guess [14:31] Though I suppose we'll still have i386 in rtm [14:31] It is weird, I just couldn't think of anything better, suggestions welcome [15:04] 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] cjwatson: It's at the totally logical and obvious URL of http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/primary-utopic.csv [15:08] Aha, thanks. [15:09] I was wondering about exposing data over time somehow [15:53] 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] please =) [17:54] 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] (particularly without retry) === mwhudson-bip is now known as mwhudson [23:06] cjwatson: Hm, I guess it might be more common with livefses because they're bigger. [23:06] It's some librarian glitch which I've not been able to reproduce locally. [23:06] We should probably just fix it by making the client retry.