[00:33] <igc> morning
[00:40] <lifeless> hi igc
[00:40] <lifeless> losa ping
[00:40] <spm> morning igc
[00:40] <spm> hey lifeless, sup?
[00:40] <lifeless> pqm
[00:40] <lifeless> I rt'd a request to do an upgrade
[00:40] <lifeless> a weekortwo back
[00:40] <lifeless> its affecting developer troubleshooting
[00:41] <lifeless> doyouhavetimetodoittoday?
[00:41] <spm> if it's sufficiently high priority - and the world doesn't break again - sure?
[00:41] <spm> what's the rt #?
[00:42] <lifeless> I'm not sure :)
[00:42] <lifeless> its somewhere in the cauldron
[00:42] <spm> heh, see if I can find it. sec.
[00:42] <spm> deploy PQM trunk rev 236 please - in coordination with Robert ? tho who this robert dude is, dunno. never heard of him.
[00:42] <lifeless> see
[00:43] <lifeless> thats the problem with young folk these days
[00:43] <lifeless> no short term memory
[00:43] <spm> old folk man, *old* :-)
[00:43] <lifeless> spm: darn, I *forgot* that bit
[00:43] <spm> ahh. i see what's happened, looks like francis set the wrong priority button - tho it's new to me that RT has > 1 priority setting
[00:43] <spiv> lifeless: I just had that error too
[00:44] <poolie> hi there
[00:44] <spm> hey poolie
[00:44] <poolie> lifeless, i filed https://bugs.edge.launchpad.net/pqm/+bug/591507 for the pqm 'lost connection' problem
[00:44] <lifeless> thanks
[00:45] <poolie> since three people have hit this in recent days, at least, and since the subunit output is not actually valid, i'm inclined to disable it until it's more debugged
[00:45] <lifeless> poolie: well, we haven't deployed the candidate fix
[00:45] <lifeless> poolie: which spm and I are doing right now
[00:45] <spm> indeedily
[00:46] <lifeless> poolie: so perhaps we should try to fix it first :)
[00:46] <poolie> ok, let's at least try that
[00:46] <spm> novel :-)
[00:46] <poolie> ah
[00:46] <poolie> surely this is not going to make the streams actually valid though?
[00:47] <poolie> or does it change them into attachments?
[00:47] <lifeless> poolie: changes them to attachments
[00:47] <poolie> oh great
[00:47] <lifeless> poolie: it should be a step in the right direction. Will more steps be needed? Probably.
[00:47] <lifeless> poolie: its been not deployed because of a priority confusion, apparently. '11:43 < spm> ahh. i see what's happened, looks like francis set the wrong priority button - tho it's new to me that RT has > 1 priority setting
[00:47] <spm> lifeless: pqm disabled in crontab
[00:47] <lifeless> '
[00:48] <lifeless> spm: ok, so grab the revno
[00:48] <lifeless> spm: as we don't have staging yet, this will be 'test by doing'
[00:48] <lifeless> spm: bzr revision-info is the output to save
[00:48] <lifeless> spm: then pull in trunk
[00:49] <spm> simiar to you guys with bugs, we schedule our work based on priorities. by default stuff comes in and stays at zero; so tickets that are 'more important' need to be more apprioriately set. a LOT of our requests are wishlisty, so tend to be in the "I need a break, something easy" bucket.
[00:50] <lifeless> spm: yeah, I'm not critical; explaining to poolie, because figuring out why something important went stale helps us prevent it.
[00:50] <spm> lifeless: so current is revno 232
[00:50] <spm> nod
[00:50] <lifeless> spm: right, so the new commits are all simple:
[00:51] <lifeless>   Record unfixed typeerror note.
[00:51] <lifeless>   Make test suite run with bzr 2.2: set an explicit test usercode.
[00:51] <lifeless>   Merge and tweak Aaron's errors-as-attachments code.
[00:51] <spm> 232 robertc@robertcollins.net-20100422043204-70jn37kx2whdm8fr <-- rev info
[00:51] <lifeless>   More tweaks to email attachment support.
[00:51] <poolie> spm, i don't understand how you can schedule your work based on priorities but also "it's new to me that RT has > 1 priority setting"
[00:51] <lifeless> spm: please pull in trunk
[00:51] <poolie> or do you mean there's more than one priority-type variable?
[00:51] <lifeless> poolie: multiple fields, I think.
[00:51] <spm> poolie: more than 1 priority type variablee. 'priority' and 'final priority'
[00:51] <lifeless> rt is... not the simplest
[00:51] <spm> francis had set the latter; the former is what we use
[00:52] <spm> lifeless: that is a major understatement :-)
[00:52] <spm> Now on revision 236.
[00:52] <lifeless> great, spin it up, I have a broken branch to send to it
[00:52] <poolie> 'final justice' <http://bit.ly/acROW7>
[00:52] <spm> bzr only re-enabled in the crontab; I gather we don't need a UI restart?
[00:53] <lifeless> spm: UI is unaffected
[00:53] <poolie> you're going to tell francis about that right?
[00:53] <lifeless> poolie: #launchpad-code
[00:54] <lifeless> he's usually around again for a bit soon, if he disappears off IRC without acking, I'll email
[00:54] <spm> I think it was an accident tbh; normally he does set priority.
[00:54] <spm> just hit the wrong field by mistake
[00:54] <lifeless> can we hide that field ?
[00:55] <spm> I have no idea. see "[09:51:48] <lifeless> rt is... not the simplest" :-D
[00:55] <lifeless> lol
[00:56] <lifeless> ok so the current branch has a failing test
[00:56] <lifeless> everything going well it will a) fail to land, b) give me a useful email attachment in gmail.
[00:56] <lifeless> I shall report in about an hour, I suspect.
[00:57] <spm> np; should I be re-enabling pqm for U1 etc? ie they're safe here?
[00:57] <spiv> lifeless: you should have tweaked the Makefile to do -f that_test  :P
[00:58] <lifeless> spiv: no
[00:58] <lifeless> spiv: its deliberately in the middle, want to be sure that under normal circumstances we get sensible stuff out
[00:58] <lifeless> spiv: and that would raise the risk of getting it wrong
[00:58] <lifeless> spm: unknown.
[00:59] <spm> lifeless: fair enough; in that case, i'll stick with disabled for the time being.
[00:59] <lifeless> spm: if its faulty, the most likely failure mode is errors going to cronmail
[00:59] <lifeless> spm: its unlikely to let things through inappropriately
[00:59] <spm> coolio, given the U1 guys don't seem busy on pushing code in; going into holding shouldn't hurt.
[01:00] <lifeless> spm: can I ask a favour ?
[01:00] <lifeless> spm: file a bug/rt ticket as appropriate, for your team, to delete the unused button; its caused friction here, and IIRC rt is meant to be very customised
[01:10] <spm> lifeless: I can do that. I have no idea how easy that is tho; or the likyhood of it being done anytime soon.
[01:14] <poolie> lifeless, do you know what 'unknown content code' in roland mas's problem report is likely to mean?
[01:14] <poolie> to mean, the earlier gzip errors probably indicate a file-level problem
[01:15] <poolie> which may ultimately be attributable to us for example not defending enough against a sudden machine crash
[01:22] <lifeless> ok
[01:22] <lifeless> the gzip errors indicate a group couldn't be decompressed
[01:22] <lifeless> -> bit (or more) error in disk content
[01:23] <lifeless> and either out-of-order disk operations(man I wish we had user space barriers), or entropy/cosmic ray
[01:23] <lifeless> the invalid content code suggests a multibit error in gzip content not detected by the [weak] crc on the compressed block
[01:24] <lifeless> and thus garbage coming out of gzip
[01:25] <poolie> right
[01:26] <lifeless> so two symptoms, one problem
[01:26] <lifeless> we can verify the packs
[01:26] <lifeless> md5sum them
[01:26] <lifeless> and see if they match
[01:33] <lifeless> I've mailed a reply to that
[01:33] <poolie> that was what i suggested too
[01:33] <poolie> thanks
[01:33] <poolie> we could talk about the fixture stuff
[01:35] <lifeless> sure
[01:35] <lifeless> I was going to pop out and do lunchtimey shores
[01:35] <poolie> but perhaps when i get home
[01:36] <lifeless> s/shores/chores/
[01:36] <poolie> we're going to look at some ui stuff with ian for a few hours
[01:36] <lifeless> well, if you have speaks & a mic we could do a group call
[01:36] <lifeless> I'm happy any which way
[01:36] <poolie> the document is probably a bit rambly but the process was good
[01:43] <lifeless> ok, -> local stuff
[01:43] <lifeless> SMS if things blow up and I need to rush home
[03:00] <lifeless> spm: ok, bzr causing funnies I think; tweaking the patch to deal
[03:00] <spm> kk
[03:00] <lifeless>  File "/home/pqm/pqm/pqm/core.py", line 194, in send_mail_reply
[03:00] <lifeless>    message = Message()
[03:00] <lifeless> TypeError: 'LazyImporter' object is not callable
[03:00] <lifeless> went to cron
[03:01] <lifeless> spm: please pull rev 237
[03:01] <lifeless> spm: tell me when you have, I'll retest
[03:01] <spm> lifeless: done, go for it.
[04:24] <lifeless> spm: ok wow, rabbit hole goes deeper
[04:25] <lifeless> Message, in email, is not what it should be
[04:25] <lifeless> spm: I need some interactive testing please
[04:25] <spm> oh?
[04:25] <spm> sure. gimme 5? just sorting some space issues on lardibartfast
[04:25] <lifeless> sure sure
[04:26] <lifeless> utter bollocks
[04:26] <lifeless> excuse the vernacular
[04:28] <lifeless> spm: I've just done a push --overwrite; please pull --overwrite, and we'll try again.
[04:28] <spm> sure
[04:28] <lifeless> uhm, pushed ...
[04:29] <lifeless> now
[04:29] <spm> ow on revision 237. ?
[04:29] <lifeless> yeah
[04:29] <lifeless> log -r -1 should say 'import from the right place'
[04:29] <spm> hrm. maybenot. we were there before. try again?
[04:30] <spm> with a capital I and a Message in tehre as well, yarp
[04:31] <lifeless> ok
[04:31] <lifeless> can yuou aslo
[04:31] <lifeless> also
[04:31] <lifeless> do
[04:31] <lifeless> "python -c 'from email.message import Message'"
[04:32] <spm> pqm@balleny:~/pqm$ python -c 'from email.message import Message'
[04:32] <spm> pqm@balleny:~/pqm$ echo $?
[04:32] <spm> 0
[04:32] <spm> looks good to me
[04:32] <lifeless> thanks
[04:32] <lifeless> boombs away
[04:32] <spm> np
[05:57] <lifeless> spm: pull again please
[06:02] <spm> lifeless: rev 238
[06:03] <lifeless> thanks
[07:29] <spm> lifeless: how's it going? have a u1 item in the queue - are we safe to let it play?
[07:34] <lifeless> spm: yes, its giving attachments now
[07:34] <lifeless> we can iterate safely from here
[07:34] <lifeless> please enable it all
[07:34] <spm> oki, re-opening pqm
[07:35] <lifeless> or bugger
[07:35] <lifeless> its rather smaller than expected
[07:35] <spm> ?
[07:35] <spm> problem?
[07:35] <lifeless> if their merge fails they won't get much diagnostics right now
[07:35] <lifeless> but enable it
[07:36] <lifeless> it isn't going to crash now
[07:36] <spm> oki, it's enabled.
[07:38] <lifeless> right, the attachment isn't
[07:39] <lifeless> I need to dig deeper into the email api
[07:39] <lifeless> I shall do that around dinner
[07:39] <spm> kk
[07:40] <spm> updating the RT as to where we're at
[07:45] <lifeless> spm: when are you disappearing tonight? 15 minutes?
[07:46] <spm> 75.
[07:46] <lifeless> this looks wrong: Content-type: multipart/mixed
[07:46] <lifeless> Content_type: text/plain
[07:46] <spm> 6pm local.
[07:46] <lifeless> bloody broken API's
[07:46] <lifeless> spm: can you do python -c 'from email.mime.multipart import MIMEMultipart'
[07:46] <lifeless> please
[07:47] <spm> works fine
[07:48] <lifeless> oh man
[07:49] <lifeless> it wants headers spelt in lower case
[07:49] <lifeless> no, thats not it.
[07:49] <lifeless> gmm
[07:49] <lifeless> who writes a dict interface that doesn't replace keys
[07:49] <lifeless> So very not pythonic
[07:50]  * lifeless sobs
[07:50] <mgz> did you work out the email.Message vs. email.message thing from earlier?
[07:50] <lifeless> mgz: yes
[07:50] <mgz> you need both.
[07:50] <lifeless> mgz: email/__init__ contains a bad lazy_import implementation
[07:50] <lifeless> mgz: no, can just grab from email.message.Message
[07:51] <lifeless> Message appears ripe for user bugs in so many ways
[07:51] <lifeless> headers aren't normalised
[07:51] <mgz> this needs to run on python 2.4 right?
[07:51] <lifeless> mgz: no
[07:51] <mgz> ah, okay, ignore me then.
[07:51] <lifeless> mgz: it needs to run outside the chroot on balleny
[07:52] <Tibi> hi
[07:52] <mgz> mime isn't fun.
[07:52] <lifeless> mgz: email.* isn't fun; mime itself is pretty well established ;)
[07:52] <lifeless> mgz: check out message.Message.get_param for an eye watering docstring
[07:55] <mgz> see, I'd blame some of that on mime/rfc 2231 making things overly painful
[07:56] <lifeless> if the email module was close to rfc2231 compliant, I'd agree
[07:56] <lifeless> :)
[08:27] <lifeless> spiv: can you tell poolie, if he doesn't see me first, that I'm 'bloody fixing bloody pqm'.
[10:42] <lifeless> losa ping
[10:42] <mthaddon> lifeless: hi
[10:43] <lifeless> mthaddon: hi, need to rollback the PQM change from earlier today; take 1 minute
[10:44] <mthaddon> ok
[10:44] <lifeless> mthaddon: on balleny in the pqm dir, bzr pull -r 232 . --overwrite
[10:44] <lifeless> bzr revision-info should then report 232, and bzr st no changes
[10:45] <lifeless> turns out the email API is really tricky to get right and I'm doing more extended QA locally before we do the upgrade again
[10:45] <mthaddon> lifeless: https://pastebin.canonical.com/33182/ - I think we're good
[10:45] <lifeless> mthaddon: we should be, thanks. I'll send a test through to make sure its back to its ugly old self
[10:45] <mthaddon> k
[10:47] <parthm> there is a bzr grep bug #591233 ... does bzrlib.option provide a way of having an option that allows '-' as start of argument? e.g. '-e "-blah"'
[10:48] <lifeless> parthm: no
[10:48] <lifeless> parthm: or rather, I'm pretty sure it doesn't.
[10:48] <parthm> lifeless: ok. thanks. i will look into it to see if there is an easy way to do it.
[10:48] <lifeless> it will parse it as option 'b' with param 'lah' and no parameters given to 'e'
[10:49] <parthm> lifeless: yes. thats what i got when i tried it.
[10:49] <lifeless> Thats what I'd expect to happen; I don't think this is really a bug is it? just escape the - - -e "\\-blah"
[10:50] <parthm> lifeless: yes. thats the workaround i suggested in the bug. but posix grep supports -e ... so i suppose people used to posix grep would try that first.
[10:51] <lifeless> ok
[10:51] <parthm> so its not critical, but nice to have.
[10:51] <lifeless> so, if you find a way to add this to bzr core
[10:51] <lifeless> I'd like to suggest that it be made obvious in two places
[10:51] <lifeless> the docstrings for any objects that will sometimes-handle-leading-dash-and-sometimes-not
[10:52] <lifeless> and the help for commands that use such options - automatically in the this second case
[10:53] <parthm> argh. seems to be some problem with my network today. i keep dropping off.
[10:53] <parthm> lifeless: i will see if there is a good way to support this. maybe a new option type. will file a wishlist against bzr for now.
[10:54] <lifeless> 21:51 < parthm> so its not critical, but nice to have.
[10:54] <lifeless> 21:51 < lifeless> so, if you find a way to add this to bzr core
[10:54] <lifeless> 21:51 < lifeless> I'd like to suggest that it be made obvious in two places
[10:54] <lifeless> 21:51 -!- parthm [~chatzilla@122.167.117.28] has quit [Read error: Connection reset by peer]
[10:54] <lifeless> 21:51 < lifeless> the docstrings for any objects that will sometimes-handle-leading-dash-and-sometimes-not
[10:54] <lifeless> 21:52 < lifeless> and the help for commands that use such options - automatically in the this second case
[10:54] <lifeless> 21:52 -!- parthm [~chatzilla@122.167.117.28] has joined #bzr
[10:59] <parthm> lifeless: makes sense. bug #591657
[11:48] <lifeless> mthaddon: can you please tell me what python -V shows on balleny, outside the chroot ?
[11:49] <mthaddon> Python 2.5.2
[11:49] <lifeless> thanks
[12:37] <lifeless> gnight y'all
[13:22] <bilalakhtar> People, please help. bzr is stuck on Fetching revisions:Inserting missing keys: . Is this fine?
[13:23] <bilalakhtar> ok, its fine. got it
[13:54] <alf__> Hi all! When packaging using bzr builddeb is the versioned directory (upstream+debian) supposed to have debian/patches applied or not?
[13:54] <james_w> if it is dpkg-source v3 (quilt)
[13:57] <alf__> james_w: So, if I understand correctly, if it is v3 (quilt) it should have the changes applied *and* also have .pc/ versioned
[13:57] <alf__> james_w: and that is what I should push to launchpad?
[13:58] <james_w> yeah
[13:58] <james_w> it's not ideal, but it's the best we have for now
[13:58] <alf__> james_w: great, thanks
[17:13] <servilio> hi! I have a branch with a couple of commits I'd like to remove is there a way to do this without using uncommit? or is there a plugin that automates this?
[17:27] <maxb> servilio: Uh..... this is what uncommit is for.#
[17:31] <servilio> maxb: yes, but there are ~20 commits before the ones I need to take out
[17:32] <maxb> In that case you should just undo the effect of those commits on the tree (by doing a reverse-merge), and commit that
[17:32] <servilio> maxb: I changed the history of the parent after that branch was made
[17:32] <maxb> That sounds hideous
[17:32] <servilio> yes, it is
[17:32] <maxb> Well don't do that then :-)
[17:33] <servilio> but it was a merge gone wrong I needed to take out ASAP
[17:33] <servilio> I am looking into cherry-picking now
[17:33] <servilio> looks like that will be the solution
[17:33] <servilio> new branch, cherry-pick merge, push to the parent :D
[18:36] <taxilian> can anyone tell me if there is a good equivilent to webdav publishing like svn or mercurial can do with bzr?  I'm using bzr+ssh, but that requires creating a user account on the central repo machine for each user, which I'd prefer not to do
[18:38] <taxilian> or if there is a way I haven't found yet to run bzr over webdav...
[18:40] <servilio> taxilian: have taken a look at bzr-webdav?
[18:40] <taxilian> looked at a bit, but looks like it isn't stable
[18:40] <taxilian> maybe it's just been too long since I looked
[18:41] <servilio> haven't tried it myself, a co-worker did and it worked fine
[18:41] <taxilian> so it looks like it requires installing a plugin on each dev machine?
[18:42] <taxilian> what is the "recommended" way to publish a bzr repo?  sftp?
[18:42] <servilio> yes
[18:42] <servilio> yes was regarding the installation of the plugin in each dev system
[18:42] <servilio> regarding the "recommended" way, can't tell you sincerely, just a user here
[18:43] <servilio> I use bzr+ssh currently
[18:43] <taxilian> yeah; that's what I don't get about bzr.  I like bzr; I've been using it for awhile
[18:43] <taxilian> but bzr+ssh is not ideal for a real solid source control system
[18:43] <servilio> define "real solid" :D
[18:43] <servilio> meaning, state your requirements ;)
[18:43] <taxilian> we used to use that with cvs, and that's one of the main things that everyone I've worked about liked about svn over cvs; it worked over http instead of needing ssh
[18:44] <taxilian> flexible permissions on various projects
[18:44] <taxilian> easy to add and manage users
[18:44] <taxilian> with ssh, you have to deal with system users
[18:45] <taxilian> and unix groups aren't real ideal for managing access control
[18:46] <servilio> I have been looking at a solution for access control for ssh access that wouldn't need system account, but would use ssh keys
[18:46] <servilio> but haven't found any so far
[18:47] <taxilian> well, you can use ldap, but that's a pain
[18:47] <servilio> there is http://pypi.python.org/pypi/ClueBzrServer/
[18:48] <servilio> yes, a bit of a complicating solution LDAP is
[18:48] <servilio> and yesterday I found nappingcat http://pypi.python.org/pypi/nappingcat/
[18:48] <servilio> but haven't had time to take a look at it
[18:49] <taxilian> hmm.  does look like cluebzrserver supports pushing; very interesting
[18:50] <taxilian> not much information about nappiungcat
[20:11] <lifeless> moin
[20:27] <mtaylor> lifeless: moin
[20:27] <mtaylor> lifeless: hey - quick question for you
[22:08] <netshine> ;-(
[22:08] <netshine> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[22:08] <netshine> there any known problems right now?
[22:14] <lifeless> netshine: known problems with?
[22:15] <netshine> wish launchpad or bazaar ;-0
[22:16] <lifeless> that error usually indicates an ssh configuration issue
[22:16] <lifeless> do you have your ssh key setup correctly?
[22:18] <netshine> i think so...
[22:18] <netshine> i just updated my pgp key to be sure..
[22:18] <netshine> :-0
[22:19] <netshine> wait, ssh key?
[22:19] <netshine> not pgp? about what you talking about :-0
[22:19] <lifeless> ssh
[22:19] <lifeless> I have to pop out for a bit
[22:19] <netshine> :-?
[22:20] <lifeless> if this is your first time using bzr with launchpad, you might try asking on #launchpad
[22:20] <lifeless> bye for now.
[22:30] <netshine> :-0
[22:30] <netshine> lifeless, thanks: D