[00:15] <lifeless> bac
[00:15] <lifeless> *back*
[00:15] <lifeless> (sorry bac)
[00:16] <StevenK> lifeless: Haha, I did wonder if you were at your keys or wanted Brad's attention
[00:32] <wgrant> Anyone around to review https://code.launchpad.net/~wgrant/launchpad/iseriesbugtarget/+merge/69951?
[01:08] <wgrant> lifeless: You don't have a good suggestion for a primary bug target?
[01:09] <wgrant> ie. product/distro/DSP?
[01:09] <lifeless> wgrant: 'thing', 'target', 'context', shrug.
[01:10] <lifeless> wgrant: I think we want to remove the series special casing eventually, so I don't really care about the name.
[01:10] <wgrant> True.
[01:45] <wallyworld> lifeless: following on from last week, could you please look at this mp (and +1 if you are happy). then i will land it for the contributor https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408
[01:58] <wgrant>  * 9967 Exceptions
[01:58] <wgrant> Hi codehosting.
[01:58] <lifeless> \o/
[02:08] <poolie> hi wallyworld
[02:09] <wallyworld> poolie: hi
[02:09] <poolie> thanks for pushing it
[02:09] <wallyworld> np
[02:10] <wallyworld> i got caught up yesterday
[02:47] <jtv> StevenK, wgrant: I uploaded a package to -partner (on dogfood) and ran publish-ftpmaster.  The pool now contains the .dsc and 2×tarball, and the package is in the Sources list, but it's not showing up in the Packages files and I don't see a .deb.  Is that bad?
[02:47] <StevenK> Has it built?
[02:48] <StevenK> And 2*tarball?
[02:48] <wgrant> Needs build + potential acceptance
[02:48] <jtv> StevenK: orig.tar.gz and debian.tar.gz
[02:48] <jtv> How do I find out about build and potential acceptance?
[02:49] <StevenK> What does dogfood.l.n/builders say?
[02:49] <jtv> 2 builders: ferraz & rubidium, both idle
[02:50] <jtv> Haven't found my package ("bye") in the logs yet, but the package I based it on ("hello") failed to build.
[02:51] <jtv> chroot problem.
[02:52] <jtv> Ah, "bye" built successfully on ferraz.
[02:52] <wgrant> It probably ended up in NEW.
[02:53] <wgrant> Yep, there it is.
[02:53] <wgrant> https://dogfood.launchpad.net/ubuntu/oneiric/+queue
[02:53] <jtv> The source package page also fails to show a deb.
[02:53] <wgrant> It doesn't really exist yet.
[02:53] <jtv> https://dogfood.launchpad.net/ubuntu/+source/bye/1.0
[02:54] <jtv> So… do I need to approve the binary upload like I did the source upload?
[02:54] <wgrant> Yes.
[02:54] <jtv> On the way.
[02:54] <jtv> There we go.
[02:55] <jtv> And now… process-accepted?
[02:55] <wgrant> publish-ftpmaster should do that, right?
[02:55] <jtv> You have me there.  Checking.
[02:55] <jtv> Yup, it does.
[02:56] <jtv> So then I can just re-run publish-ftpmaster?
[02:56] <wgrant> Correct.
[02:59] <jtv> It's mentioning the package now: "(Arch Specific)"
[02:59] <jtv> I don't know who Arch Specific is, but he seems to be doing something to my package.
[03:01] <wgrant> "arch specific" means "not architecture independent"
[03:05] <jtv> wgrant: to be really, really honest I did sort of gather it would be something like that.  :)
[03:06] <jtv> Anyway, it's done now.  Which seems suspiciously quick.
[03:06] <jtv> Then again, there won't have been any changes outside of -partner.
[03:06] <wgrant> And partner is both NMAF and small.
[03:08] <jtv> NMAF?
[03:08] <wgrant> No More Apt-Ftparchive
[03:09] <jtv> Ah, you mean it uses Launchpad's indexing code?
[03:09] <jtv> Well, all green lights so far.
[03:09] <wgrant> Right.
[03:09] <jtv> My package is in Packages for i386, and the +source page shows the i386 build.
[03:09] <wgrant> Excellent.
[03:09] <wgrant> And it didn't delete 600GB of archive?
[03:10] <jtv> Errr
[03:11] <mtaylor> lifeless: fix all of my problems!
[03:11] <mtaylor> :)
[03:11] <jtv> wgrant: the ubuntu-archive dir now contains about 15GB, I think.
[03:12] <mtaylor> hey all - the new launchpad haproxy stuff is killing me
[03:12] <jtv> I may lose power.
[03:12] <wgrant> mtaylor: Oh?
[03:12] <wgrant> jtv: Sounds good.
[03:12] <mtaylor> wgrant: it's causing tarmac to have its connections disconnected
[03:12] <wgrant> mtaylor: It maintains persistent connections?
[03:12] <mtaylor> wgrant: which is problematic
[03:12] <mtaylor> wgrant: it ddoes
[03:12] <wgrant> It probably shouldn't.
[03:13] <wgrant> It didn't have long-term connections open yesterday, interestingly...
[03:13] <mtaylor> wgrant: well, according to abently, bzrlib expects to stay connected for some reason
[03:13] <jtv> wgrant: the biggest chunks being in contents-generationold.  About 2GB in /srv/launchpad.net/ubuntu-archive/ubuntu/pool.
[03:13] <wgrant> mtaylor: I suspect you want to change your plugin to manage transports a little better.
[03:13] <wgrant> mtaylor: It can't expect to remain connected for weeks.
[03:13] <mtaylor> wgrant: it doesn't
[03:13] <jtv> wgrant: surprisingly, almost the same amount of data in ubuntu-partner.
[03:14] <mtaylor> wgrant: it just stays connected while it runs tests
[03:14] <wgrant> Ah.
[03:14] <wgrant> Someone else is keeping connections open for weeks, so I thought you might be too.
[03:14] <mtaylor> wgrant: which sometimes is longer than 50s
[03:14] <mtaylor> nope. that shouldn't be us
[03:14] <wgrant> So, sounds like your plugin needs to be fixed to not do that.
[03:15] <wgrant> We can possibly increase the haproxy timeouts for now, if it is causing big problems for you.
[03:15] <wgrant> But only very temporarily.
[03:15] <mtaylor> wgrant: rockstar told me to come bug you :) --- and it's actually the core tarmac code
[03:15] <mtaylor> tarmac holds the connection around the post-merge hook
[03:15] <wgrant> Hmm.
[03:16] <wgrant> rockstar: Any reason Tarmac can't handle transports a bit more sensibly?
[03:19] <mtaylor> wgrant: https://jenkins.openstack.org/view/Nova/job/nova-tarmac/109487/console
[03:20] <mtaylor> or more excitingly: https://jenkins.openstack.org/view/Nova/job/nova-tarmac/109467/console
[03:20] <wgrant> That's rather unpleasant.
[03:22] <lifeless> mtaylor: Use the source monty!
[03:22] <mtaylor> lifeless: these are not the droids you are looking for
[03:25] <lifeless> mtaylor: wgrant: so, this is a bzrlib bug.
[03:25] <wgrant> :( no criticals in that rollout
[03:25] <lifeless> not the holding open
[03:25] <lifeless> the handling of the disconnects.
[03:25] <lifeless> transports are defined stateless.
[03:25] <lifeless> so are RPC calls.
[03:26] <mtaylor> lifeless: yay! nothing better than a bzrlib bug!
[03:26] <lifeless> so the bug is 'when an idle ssh transport is disconnected, bzrlib should not error'
[03:26] <lifeless> or
[03:26] <lifeless> 'when an idle ssh transport is interrupted, bzrlib errors'
[03:27] <lifeless> the haproxy stuff is showing this up very visibly, but the bug pre-existed - bzr didn't seen keepalives, and if ssh wasn't configured to do so it could naturally happen anyhow
[03:27] <lifeless> however, lets up it for now to 10 minutes.
[03:28]  * mtaylor filing bzr bug
[03:30] <mtaylor> bug 819604
[03:30] <_mup_> Bug #819604: when an idle ssh transport is interrupted, bzrlib errors <Bazaar:New> < https://launchpad.net/bugs/819604 >
[03:32] <mtaylor> lifeless: you gonna be at the next uds?
[03:33] <lifeless> no
[03:33] <lifeless> new sprog (we hope)
[03:34] <mtaylor> what's a sprog?
[03:34] <lifeless> child
[03:34] <mtaylor> OH!
[03:35] <mtaylor> well, in that case, coming to UDS would be the wrong choice
[03:35] <mtaylor> (and hopefully congrats)
[03:35] <lifeless> yes, we think so
[03:35] <mtaylor> LCA then?
[03:35] <lifeless> doubtful
[03:35] <mtaylor> gah. I'm starting to think you're avoiding hanging out with me :)
[03:35] <lifeless> thats it, totally.
[03:36] <lifeless> if you wanted to swing by christchurch after UDS we could put you up for a few days
[03:36] <lifeless> bah
[03:36] <lifeless> LCA
[03:36] <mtaylor> ooh. now _that's_ not a bad idea
[03:36] <mtaylor> and yeah - I read LCA there
[03:36] <mtaylor> I still haven't been to the south island
[03:36] <mtaylor> thinking about hanging out with Stewart for a while pre-LCA
[03:36] <mtaylor> speaking of - I REALLY need to submit talk proposal...
[03:37] <lifeless> UDS +1 I expect I will be at
[03:41] <mtaylor> yay!
[03:41]  * mtaylor lists UDS's and LCA as the important things he should attend
[03:55] <nigelb> So, recently I used vagrant.
[03:55] <nigelb> I'm wondering how easy it would be to create a vagrant file to set up LP environement.
[03:56] <jtv> wgrant: I think partner publication works.  Next up is expedited -security publishing.  For that I need to copy a package into security, right?
[04:06] <rockstar> wgrant, the reason is because bzr doesn't handle transports more sensibly?
[04:08] <rockstar> I keep hearing launchpad people pushing back on this, and I understand why, but tarmac pushes as much as it can off to bzr.
[04:09] <rockstar> I'm unsure why we're timing out so quickly now.
[04:11]  * rockstar sees that lifeless has already covered this, and goes to bed
[04:17] <wgrant> jtv: Right.
[04:17] <wgrant> jtv: You can copy from a public PPA, if you want.
[04:17] <jtv> Thanks.
[04:20] <wgrant> Edit before sending? [y/n]: yConnection to bazaar.launchpad.net closed by remote host.
[04:20] <wgrant> Heh
[04:21] <StevenK> wgrant: Ouch
[04:48] <lifeless> StevenK: hi
[04:48] <lifeless> StevenK: https://code.launchpad.net/~stevenk/launchpad/pillarname-vocab/+merge/70091
[04:48] <lifeless> StevenK: vocabs depend on stable ordering to paginate
[04:50] <StevenK> It is stable?
[04:50] <lifeless> ho ?
[04:50] <lifeless> how?
[04:51] <StevenK> It appeared to be when I tested it on DF
[04:51] <lifeless> its not stable with an order by rank, when two rows can have the same rank
[04:52] <lifeless> you either need a more granular rank, or a disambiguator
[04:52] <StevenK> Right, then I want rank first and name second
[04:52] <StevenK> orderBy='rank- name' ?
[04:53] <lifeless> for storm? order_by=(SQL('rank'), PillarName.name)
[04:53] <wgrant> Desc(SQL('rank')), PillarName.name
[04:53] <lifeless> only if you want it to work
[05:03] <StevenK> lifeless: It will fail to land anyway, so I'll fix it once I'm sure no other tests have failed
[05:04] <lifeless> cool
[05:04] <lifeless> sorry for having to raise this
[05:05] <StevenK> I should have thought of it, by rights
[05:06] <lifeless> :)
[05:27] <LPCIBot> Project devel build #937: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/devel/937/
[06:07] <lifeless> wgrant: fun stuff for oneiric : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/819621
[06:07] <_mup_> Bug #819621: lucid container start failure after calling lxc-stop (fails across reboots) <lxc (Ubuntu):New> < https://launchpad.net/bugs/819621 >
[06:10] <wgrant> lifeless: I noticed that too, but decided it was probably the avahi or similar that I had installed.
[06:10] <wgrant> Upsetting to hear that it happens even when the container is not terribly mangled.
[06:10] <wgrant> (avahi sets odd rlimits for itself, which mean more than one instance can't run on a single kernel without a bit of work)
[06:11] <wgrant> nproc == 2, what could possibly go wrong.
[06:11] <lifeless> also having plymouth in the container is just bong
[06:12] <wgrant> Mmm.
[06:12] <wgrant> Not necessarily.
[06:12] <wgrant> It's not just a splash these days.
[06:12] <wgrant> It's the way upstart communicates with the outside world.
[06:30] <StevenK> jtv: Are you still playing in dogfood's wading pool?
[07:03] <StevenK> Bloody *hell* (Error ID: OOPS-2040DOGFOOD18397)
[07:03] <StevenK> How has DF generated 18,000 OOPSes?
[07:04] <wgrant> Probably the a-f warnings.
[07:06] <StevenK> And the publisher is running, so the webapp is being horridly slow.
[07:07] <wgrant> :D
[07:08] <StevenK> It can't even load bugs.dogfood.l.n
[07:17] <wgrant> wallyworld: Hmm, so the question subscription stuff is based on the *old* Bugs stuff?
[07:17] <wallyworld> no, how did you think that?
[07:17] <wgrant> "Direct subscribers" and "Also notified"
[07:18] <wgrant> Old, but more sensible, terms.
[07:18] <wallyworld> that's how questions subscriptions have always worked. i just made it use ajax
[07:18] <wallyworld> instead of html forms
[07:18] <wallyworld> so i extended the new subscribers_list portlet
[07:18] <wgrant> Right.
[07:19] <wallyworld> so, you ok with the change?
[07:19] <jtv> StevenK: still running
[07:19] <wgrant> wallyworld: Would be nice if we eventually integrated the same self-subscription stuff that Bugs introduced, but small steps.
[07:20] <wallyworld> wgrant: yes, one thing at a time. it's now much better than it was last week. it's now possible to unsubscribe without SQL :-)
[07:20] <wgrant> Yup.
[07:22]  * wallyworld off to soccer
[07:29] <adeuring> good morning
[07:59] <allenap> Good morning/evening wgrant :) Got time for a very short review? https://code.launchpad.net/~allenap/launchpad/dsd-base-view-dont-modify-globals-bug-809985/+merge/70076
[08:01] <wgrant> allenap: that's rather evil, but OK!
[08:01] <wgrant> Approved.
[08:02] <allenap> wgrant: Thanks :)
[08:09] <jelmer> g'morning
[08:19] <mrevell> Morning
[08:43] <allenap> Morning jelmer :)
[08:44] <allenap> jelmer: I saw that Dulwich made the front page of Hacker News.
[08:50] <jelmer> allenap: yeah :)
[08:55] <jelmer> allenap: I've met the Google code folks and have been in contact with them. They've contributed a bunch of patches which should help with performance.
[08:55] <allenap> jelmer: Also, bug 808035 is at the top of the deploy queue and needs testing :)
[08:55] <_mup_> Bug #808035: AttributeError: 'NoneType' object has no attribute 'write' during git import <oem-services> <qa-needstesting> <regression> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/808035 >
[08:55] <jelmer> That should also have a significant impact on git code import performance.
[08:55] <jelmer> allenap: Yep, it's on the top of my todo list too.
[08:55] <allenap> jelmer: That's really cool :)
[08:56] <lifeless> adeuring: hiya
[09:04] <danilos> mrevell, hi, do you have any time today to help move the docs forward and potentially announce the change to maintainers by email (import queue stuff)?
[09:05] <mrevell> danilos, Yes, certainly. In 30 minutes.
[09:05] <danilos> mrevell, excellent, let's talk then
[09:10] <adeuring> hi lifeless
[09:12] <lifeless> adeuring: https://code.launchpad.net/~adeuring/launchpad/bug-739052/+merge/69625 - you're not landing it yet ? [I can't see the column issue addressed]
[09:12] <adeuring> lifeless: now running through ec2
[09:13] <adeuring> forgot that yesterday...
[09:13] <lifeless> adeuring: and there were a bunch of suggestions that seem forgotten too :(
[09:13] <adeuring> I'm also working on the remaining suggestions you made
[09:14] <lifeless> adeuring: oh cool! - are you thinking of two separate landings ?
[09:14] <adeuring> lifeless: actually, three, to keep the diffs to review small
[09:14] <lifeless> sure thing; I'd be delighted to review those for you
[09:14] <lifeless> adeuring: have I mentioned how glad I am that you're doing this.
[09:15] <adeuring> lifeless: too late for this one : https://code.launchpad.net/~adeuring/launchpad/bug-739052-2/+merge/70044 ;)
[09:15] <adeuring> lifeless: and thanks :)
[09:16] <adeuring> (sorry, I have some reaally long lag between typing IRC messages and looking at incoimng...)
[09:16] <lifeless> heh no worries
[09:18] <lifeless> adeuring: so why won't (col1 >= M1 and col2 >= M2 and colN >MN) work ?
[09:19] <lifeless> oh, I see
[09:21] <lifeless> adeuring: however, using a tuple will work, I think ?
[09:21] <lifeless> hmmm, only if the direction on all the columns is consistent
[09:22] <adeuring> lifeless: no, I think we need, for three sort columns:
[09:22] <adeuring> col1 == memo1, col2 == memo2, col3 > memo3, then...
[09:22] <adeuring> col1 == memo1, col2 > memo2
[09:22] <adeuring> then col1 > memo1
[09:22] <lifeless> adeuring: what about
[09:23] <lifeless> (col1, col2, col3) >= (memo1, memo2, memo3)
[09:23] <adeuring> that wouldn't change much
[09:23] <adeuring> problem is:
[09:23] <adeuring> when the value in col1 increases, the values in col2, col3... starting from the minimum
[09:24] <adeuring> so we end up with N conditions for N sort columns
[09:26] <adeuring> lifeless: I think we have at least three options to "join" these N conditions: a more or less huge OR (implemented for mow), or a UNION ALL on sub-selects for each conditions
[09:26] <adeuring> or
[09:26] <adeuring> we can iterate in Python over the conditions
[09:26] <lifeless> adeuring: if the direction is consistent, a tuple works
[09:27] <adeuring> lifeless: ah, right!
[09:27] <lifeless> http://pastebin.com/mcShr1D2
[09:27] <adeuring> lifeless: but how do we express this in SQL?
[09:27] <lifeless> just so
[09:27] <adeuring> lifeless: cool!
[09:28] <adeuring> so, the content of my next branch is obvious ;)
[09:28] <lifeless> :)
[09:28] <lifeless> we may have a lot where we can't do this
[09:28] <lifeless> but we can probably group all the adjacent same-direction columns anyhow
[09:29] <adeuring> lifeless: right
[09:33] <henninge> jml: Hi! ;)
[09:34] <jml> henninge: hi
[09:34] <henninge> jml: I got a failed ec2 run for your branch.
[09:34] <jml> henninge: me too, but no actual failures
[09:34] <henninge> jml: right
[09:34] <henninge> it's the "smtp message exeeds size limit"
[09:35] <henninge> jml: same for you?
[09:35] <jml> henninge: I've corrected the default value as per StevenK's comments. I suspect that would have caused some tests to fail.
[09:35] <jml> henninge: yes.
[09:35] <lifeless> that smtp error means a catastrophic failure
[09:35] <henninge> lifeless: you mean "too many failures, the mail gets too big" ?
[09:35] <lifeless> yes
[09:38] <henninge> jml: I see you pushed, shall I start the landing again?
[09:38] <jml> henninge: yes. thank you.
[09:38] <henninge> ok
[11:03] <lifeless> allenap: there is a feature flag you can use for profiling too
[11:03] <lifeless> allenap: the default profile dir is $cwd, I think.
[11:05] <allenap> lifeless: Oh neat. I was just shuffling my wiki notes; I think that one is from back in the days when BjornT_ ran the bugs team :) Not sure if it'll even work any more.
[11:09] <jtv> Any reviewers in the house?  → https://code.launchpad.net/~jtv/launchpad/bug-819674/+merge/70135
[11:11] <jml> who actually uses checkUpload via the API?
[11:12] <LPCIBot> Project devel build #938: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/938/
[11:12] <jelmer> jml: I would imagine things like request-sync
[11:12] <jelmer> jml: to do things like determine if the current user requires sponsorship
[11:13] <jml> jelmer: ah, yeah, that would be a thing.
[11:13] <jml> for checking PPA uploads, it's not particularly useful
[11:14] <jml> since it errors when it doesn't recognize the source package, and insists that you supply component & pocket
[11:15] <jelmer> yeah, it's a bit odd
[11:38] <lifeless> night all
[11:38] <jelmer> g'night lifeless
[11:38] <jelmer> jtv-afk: trade you for https://code.launchpad.net/~jelmer/launchpad/logginguifactory-fixes/+merge/70144 ?
[12:14] <StevenK> The publisher takes 4+ hours on DF? Srsly?
[13:08] <bigjools> StevenK: it sometimes does
[13:59] <abentley> adeuring: Is it considered a feature that https://bugs.launchpad.net/mahara/+bug/630891%20/+index works?
[13:59] <_mup_> Bug #630891: Unable to delete Notification messages <Mahara:Fix Released by richard-mansfield> < https://launchpad.net/bugs/630891 >
[13:59] <abentley> adeuring: i.e. a URL with whitespace in it?
[13:59] <adeuring> abentley: I have no idea...
[14:00] <abentley> adeuring: It seems bizarre, and it means that https://bugs.launchpad.net/mahara/+bug/630891%C2%A0/+index fails due to encoding issues.
[14:00] <_mup_> Bug #630891: Unable to delete Notification messages <Mahara:Fix Released by richard-mansfield> < https://launchpad.net/bugs/630891 >
[14:01] <adeuring> abentley: I don't see how these two URL-oddities are related
[14:02] <abentley> adeuring: If URLs with spurious characters were not permitted, the second would give a LocationError instead of trying, and failing to render.
[14:02] <abentley> adeuring: i.e. a "Not found"/ "Lost something"?
[14:03] <adeuring> abentley: sure, a "not found" would be more reasonable, but the failure for your second URL is a separate issue: A unidoce decoding problem
[14:04] <adeuring> abentley: we would get that too for a project name like "mülltüte"
[14:04] <adeuring> but such names a not allowed
[14:04] <abentley> adeuring: Our URLs don't have non-ascii characters, so they can't have a unicode decoding problem.
[14:04] <abentley> adeuring: Except bug URLs, which can have spurious non-ascii characters.
[14:05] <adeuring> abentley: do we have a referer for the \xa0 / %C2%A0 URL?
[14:05] <adeuring> abentley: I mean: you can always type URLs manually
[14:06] <abentley> adeuring: No, but it was googlebot.
[14:08] <adeuring> abentley: so the URL has been somewhere/somehow generated. So we have two issues: the unicode error, and the fact that a spurious space at least in bug URLs does not result in a 404
[14:09] <abentley> adeuring: Yes, that's my view.  It hardly seems worth fixing the encoding bug if non-ascii URLs are supposed to be verboten.
[14:09] <abentley> adeuring: Who knows what other bugs non-ascii URLs might reveal?
[14:10] <adeuring> abentley: yeah,,,
[14:10] <adeuring> abentley: but regarding the working URL with the %20:
[14:10] <adeuring> Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
[14:10] <adeuring> [GCC 4.5.2] on linux2
[14:10] <adeuring> Type "help", "copyright", "credits" or "license" for more information.
[14:10] <adeuring> >>> int('1')
[14:10] <adeuring> 1
[14:10] <adeuring> >>> int('1 ')
[14:10] <adeuring> 1
[14:12] <adeuring> abentley: I guess that the travesal code does just such a simple int('630891 ')
[14:12] <abentley> adeuring: Interestingly: ValueError: invalid literal for int() with base 10: '2\xa0'
[14:13] <adeuring> abentley: try int(u'1\xa0')
[14:16] <abentley> adeuring: Fascinating.  So that is only permitted for unicode strings, because only in unicode strings does \xa0 refer to the same codepoint consistently.
[14:19] <adeuring> abentley: doesn't the "can't encode character u'\xa0'" in the traceback indicate that dict['PATH_INFO'] already _is_ a unicode object?
[14:21] <abentley> adeuring: yes, that's what I think.
[14:22] <adeuring> abentley: so again not a "clear border" where 8-bit sequences with some encoding are supposed to live on one side and unicode objects on the other...
[14:24] <abentley> adeuring: Right.  Requests appear to use a "sane_environment" where values are unicode, but converting the browser request to a web service request appears to re-convert the environment.
[14:25] <adeuring> abentley: so.... a trvial but bad workaround would be to convert to utf-8 in this case.
[14:26] <abentley> adeuring: Might be a necessary workaround, depending on how these calls are structured.
[14:27] <adeuring> abentley: if you want more fun, try this URL: https://bugs.launchpad.net/mahara/+bug/630891%C3%A4/+index
[14:27] <_mup_> Bug #630891: Unable to delete Notification messages <Mahara:Fix Released by richard-mansfield> < https://launchpad.net/bugs/630891 >
[14:28] <adeuring> quite different error...
[14:28] <adeuring> %C3%A4 is a 'ä'
[14:28] <abentley> adeuring: Yeah, that's kind of error I'd expect.
[14:30] <adeuring> abentley: I assume that this error is raised for a failed int('630891ä')
[14:30] <adeuring> (for the bug id)
[14:30] <abentley> adeuring: me too.
[14:31] <abentley> adeuring: a0 is non-breaking whitespace.
[14:31] <adeuring> right
[14:32] <adeuring> so it might be a replacement from the regular '\x20' space
[14:33] <abentley> adeuring: Maybe.  Since googlebot is the source, I imagine it's in some web page, though.
[14:34] <adeuring> abentley: right. And the s/\x20/\xa0/ might be deliberate: To avoid wrapping the URL...
[14:35] <adeuring> though as far as I know most webbrosers ignore the "don't wrap" for \xa0
[14:35] <abentley> adeuring: but of course URLs shouldn't have whitespace.
[14:35] <adeuring> abentley: sure, but we can't stop the world mangling our URLs ;)
[14:36] <abentley> adeuring: we can, it's just hard to get venture capital :-)
[14:36] <adeuring> abentley: it might help to add a check like "strip(path_element) == path_element" before the int(path_element)
[14:37] <adeuring> ...where path element is the bug ID
[14:37] <abentley> adeuring: Yeah, that would work, or re.match('[0-9]*', path_element)
[14:37] <adeuring> abentley: right
[14:38] <adeuring> a nitpick: re.match('^[0-9]+$')
[14:39] <adeuring> abentley: for even more fun: https://bugs.launchpad.net/mahara/+bug/630891%E4/+index
[14:39] <_mup_> Bug #630891: Unable to delete Notification messages <Mahara:Fix Released by richard-mansfield> < https://launchpad.net/bugs/630891 >
[14:39] <abentley> adeuring: what the??
[14:40] <adeuring> abentley:  %E4 is not vaild UTF8
[14:40] <adeuring> cool, right?
[14:40] <abentley> adeuring: That's wacky.
[14:58] <abentley> adeuring: merge proposals are also affected.
[14:58] <adeuring> abentley: interesting. Again via an integer ID?
[14:58] <abentley> adeuring: Right.
[15:00] <abentley> adeuring: I'm gonna guess that everything that has an integer ID is affected.
[15:00] <adeuring> abentley: seems this is worth a general helper function "check an int ID in a URL wfor all sorts of oddities"
[15:03] <abentley> adeuring: Yes, though I expect this kind of thing will rot.  Maybe we should just reject URLs with whitespace from the beginning.
[15:04] <abentley> adeuring: Or more precisely, URLs with whitespace in the PATH.
[15:05] <adeuring> abentley: the you can also add checks for the other issues: any byte value outside the ASCII set
[15:05] <adeuring> more precisely: all bytes in the URL should have integer values between 33 and 126
[15:05] <adeuring> ...127
[15:06] <adeuring> ...after replacing the %xx encoding
[15:07] <adeuring> ouch.. the latter check should _not_ be done for the part after '?'
[15:12] <abentley> adeuring: Right, only the PATH.
[15:12] <adeuring> yep
[16:56] <LPCIBot> Project db-devel build #775: STILL FAILING in 5 hr 59 min: https://lpci.wedontsleep.org/job/db-devel/775/
[16:57] <LPCIBot> Project devel build #939: STILL FAILING in 5 hr 45 min: https://lpci.wedontsleep.org/job/devel/939/
[17:52] <jcsackett> sinzui: are you free to mumble?
[17:53] <sinzui> jcsackett, I am otp. I will be available in 45 minutes
[17:59] <jcsackett> sinzui: dig.
[18:42] <sinzui> jcsackett, I can talk now
[18:42] <jcsackett> sinzui: cool.
[20:48] <benji> Anyone want a small (and possibly even slightly fun) JS review? https://code.launchpad.net/~benji/launchpad/bug-809511/+merge/70219
[20:53] <benji> sorry, gary claimed it so you all missed out
[21:39] <allenap> Hi, can anyone take care of reverting rev 13574 (from bug 810290). It's qa-bad, but I really have to go.
[21:39] <_mup_> Bug #810290: no way to set scopes for incoming mail <feature-flags> <mail> <qa-bad> <Launchpad itself:Fix Committed by mbp> < https://launchpad.net/bugs/810290 >
[21:47] <lifeless> 13574 ?
[21:49] <lifeless> allenap: does it work *without* the feature rule in place ?
[22:35] <LPCIBot> Project db-devel build #776: STILL FAILING in 5 hr 39 min: https://lpci.wedontsleep.org/job/db-devel/776/
[22:46] <LPCIBot> Yippie, build fixed!
[22:46] <LPCIBot> Project devel build #940: FIXED in 5 hr 48 min: https://lpci.wedontsleep.org/job/devel/940/
[23:02] <sinzui> StevenK, mumble?
[23:09] <wallyworld> sinzui: my sound is @!%@!%$!@^. rebooting
[23:13] <lifeless> matsubara-afk: wow, nice defect finding
[23:42] <poolie> hi all
[23:54] <wgrant> Hi poolie.
[23:54] <wgrant> poolie: Seen the latest on bug #810290?
[23:54] <_mup_> Bug #810290: no way to set scopes for incoming mail <feature-flags> <mail> <qa-bad> <Launchpad itself:Triaged by mbp> < https://launchpad.net/bugs/810290 >
[23:54] <poolie> not yet, was just wondering about it
[23:55] <poolie> ah
[23:55] <poolie> sorry
[23:55] <poolie> so is that ok just rolled back, or is anything else needed?
[23:56] <wgrant> Should be all OK.
[23:56] <wgrant> Just takes 8 hours.
[23:56] <poolie> to roll it back out?
[23:56] <poolie> :/
[23:56] <poolie> i did have some worries about whether this was sufficiently tested
[23:56] <wgrant> Yeah, because it missed buildbot by 3 minutes.
[23:56] <wgrant> So needs to wait for two runs.
[23:57] <poolie> i guess if it's trapping there the answer is that this code is not reached at all in the test suite
[23:57] <sinzui> wallyworld, is this what you were expecting? http://pastebin.ubuntu.com/657556/
[23:57]  * wallyworld looks
[23:58] <wallyworld> sinzui: yes, i think that's a bit nicer?
[23:58] <sinzui> The tests passed
[23:58] <sinzui> I will commit
[23:58] <wallyworld> \o/
[23:58] <wallyworld> thanks
[23:59] <sinzui> wallyworld, Changes are pushed
[23:59] <wallyworld> thanks, will approve and organise a mentor