=== jamespag` is now known as jamespage
[08:39] <wgrant> cjwatson: sync-source should be unbroken now. Your germinate change is deployed too.
[08:43] <cjwatson> wgrant: excellent, thanks.  And thanks for the testfix too, teach me to be in a hurry
[08:43] <wgrant> I was going to blame Julian for that one, unless you've gained PQM privs? :)
[08:44] <wgrant> Hopefully there's no other armhf breakage, anyway.
[08:44] <cjwatson> well, it was Julian's fault that he didn't send it through EC2, but my fault for not having run the tests locally ...
[08:44] <cjwatson> (I was surprised when he lp-landed it directly)
[08:44] <wgrant> Bah
[08:44] <wgrant> Well, all that stuff is notoriously untestd.
[08:44] <wgrant> So not terribly surprising.
[08:47] <wgrant> (see my sync-source regression, for example :))
[08:49] <cjwatson> Heh.  It's looking good so far now.
[08:50] <wgrant> Great.
[08:58] <wgrant> cjwatson: How long do you tend to have the publisher not running for when it's on manual? It's one of our last few unmonitored scripts, because you could potentially prevent it from running for several hours.
[08:59] <wgrant> We normally alert on ~2 missed runs of all other scripts, but they're all constantly cronned.
[09:01] <cjwatson> It varies.  It's often only a single run though
[09:01] <cjwatson> But it certainly is more than that occasionally; I don't think I have a simple answer for you there
[09:02] <wgrant> Yeah, that's what I suspected.
=== doko__ is now known as doko
[09:33] <wgrant> cjwatson: It worked?
[09:33] <wgrant> I see tonnes of uploads, so I assume it went fine.
[09:36] <cjwatson> it got up to fonts-vlgothic, which required -F, so I stopped there and flushed
[09:36] <wgrant> Aha
[09:37] <cjwatson> usual annoying quadratic behaviour means that sometimes it's quicker to do it in chunks
=== med_out is now known as medberry
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[17:14] <slangasek> heh, that didn't take long for component-mismatches to explode :)
[17:21] <doko> jamespage, ^^^
[17:22] <doko> just java
[17:25] <jamespage> doko: aware - trying to figure out whats pulled most of the known java universe into main
[17:29] <slangasek> cjwatson: so the new syncpackage is completely unusable to me (along with a number of other things) thanks to bug #745801; before it was mostly unusable, now seahorse won't even launch on my desktop so I can't even clear out broken keys.  My question is, how does this work for anyone else?
[17:29] <ubot4> Launchpad bug 745801 in python-launchpadlib (Ubuntu Natty) (and 2 other projects) "system-based authorization broken in gnome-keyring: NoOptionError: No option 'consumer_key' in section: '1' (affects: 9) (dups: 6) (heat: 41)" [High,Triaged] https://launchpad.net/bugs/745801
[17:29] <slangasek> is there some way to configure this stuff to use a different authentication method than the per-app-openid one that seems to be the default?
[17:30] <slangasek> per-app-oauth, I guess that would be
[17:39] <tumbleweed> slangasek: at some point I considered having all the ubuntu-dev-tools fall back to a specific credential cache file if we got an IO error frome gnome keyring. That is an option, I just haven't bothered to do it
[17:52] <slangasek> tumbleweed: this doesn't appear to be an IO error; and I have no idea why it happens to me but not to others.  Any clue?
[17:52] <tumbleweed> yeah, it isn't, but it could be handled the same way
[17:52] <tumbleweed> nafc. The bug talks about deleting a keyring as a workaround
[17:53]  * tumbleweed certainly hasn't seen it before (or has long forgotten about it)
[17:55] <tumbleweed> slangasek: if you remove the bad key from the keyring, does it create another bad one?
[17:55] <slangasek> yes
[17:55] <slangasek> that's the whole problem
[17:55]  * tumbleweed has vague memories of having to do that once...
[17:56] <slangasek> I see no mention there of deleting keyrings, only deleting the broken password - which always gets readded after the next reauthorization
[18:06] <tumbleweed> slangasek: can you run something like http://paste.ubuntu.com/711146/ for me? (feel free to alter the secrets :P)
[18:07] <slangasek> 25
[18:07] <slangasek> 'network password'
[18:07] <slangasek> '[1]'
[18:07] <slangasek> there's your secret
[18:08] <tumbleweed> hrrrm, /me wishes he could reproduce this
[18:08]  * slangasek wishes he couldn't ;P
[18:09] <slangasek> I would be happy to just have the old authentication method back
[18:09] <tumbleweed> still on natty?
[18:09] <slangasek> oneiric now, of course
[18:11] <tumbleweed> well the hacky solution is to not use newlines, but I wish I knew what was eating them
[19:11] <slangasek> tumbleweed: so where are the newlines from that it's eating?
[19:11] <slangasek> there certainly aren't any newlines in my launchpad password
[19:32] <tumbleweed> slangasek: it's storing an openid credential, not the password. lazr.restfulclient.authorize.oauth is writing it through configobj (resulting in multiple lines), which launchpadlib.credentials catches with a StringIO and writes to the keyring
[19:33] <slangasek> ok
[19:33] <tumbleweed> we could mangle the string in launchpadlib.credentials, replacing the newlines with something else
[19:37] <tumbleweed> something like http://paste.ubuntu.com/711240/ ? (hackity hack hack)
[19:39] <slangasek> but then what if | appears in the string :)
[19:39] <slangasek> I guess you need full escape handling
[19:40] <tumbleweed> I'm pretty sure it won't
[19:40] <tumbleweed> the secrets are all base64 encoded
[19:49] <slangasek> base64> ah, good
[19:49] <slangasek> why are the \n not base64-encoded as well?  Could they simply be smashed, in that case?
[19:52] <tumbleweed> here's what it looks like on a happy machine (key obfuscated with similar chracter sequences
[19:52] <tumbleweed> 3
[19:52] <tumbleweed> 'network password'
[19:52] <tumbleweed> '[1]\nconsumer_secret = \naccess_token = 9WXLTrcXkqJf24WpdQLK\nconsumer_key = System-wide: debian (dvorak)\naccess_secret = yfhbDJZ9rY7jwfEtVkicsMy3FpuCsyuIcCOa4qPkTBxVHg1DKquQBnwjFylOfgAkdKP2m12L1fcVJW5x\n\n'
[19:53] <slangasek> well, why does that \n work on yours but not mine?
[19:53] <tumbleweed> that's what I wish I knew :/
[19:55]  * slangasek nods
[20:06] <slangasek> tumbleweed: so it seems that .replace('\n', '\\n') on the encoding side is enough to get around the error
[20:10] <tumbleweed> so something's unescaping it on decoding
[21:35] <slangasek> is anyone planning a devscripts upload to switch the default target back to precise again? :)
[21:41] <tumbleweed> well, that's just easy: http://paste.ubuntu.com/711402/
[21:46] <slangasek> tumbleweed: easy yes, but the question is if someone's doing it :)
[21:46]  * tumbleweed can't upload it myself
[21:48]  * slangasek shakes the branches for a sponsor
[21:50] <slangasek> cjwatson: MoM seems to be looking at unstable currently; do we want it to be looking at testing?
[21:50] <cjwatson> I thought I fixed that
[21:50] <cjwatson> have you reloaded today?
[21:51] <cjwatson> if so, an example would be good
[21:51] <slangasek> well, let's see
[21:51] <slangasek> ok, apparently I had to shift-reload
[21:51] <cjwatson> phew, glad it's no more obscure than that
[21:52] <cjwatson> (I actually fixed it a few days back, I'd thought, but the deployment was stuck behind 'bzr upgrade')