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