[00:09] I get a fun error when trying to run “bzr update”: UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 358465: ordinal not in range(128) [00:10] backtrace and some info: http://pastebin.com/m2d85582c [00:15] anyone have a favorite rhel/centos rpm that's newer than the one provided by EPEL? [00:16] hah, I love bzr: Conflict adding file .bzrignore.THIS.moved. Moved existing file to .bzrignore.THIS.moved.moved. [00:19] (how on earth I get conflicts when I only have one local branch is beyond me :-P) [00:19] sandsmark: you can conflict with someone else without needing two local branches [00:20] lifeless: there is noone else, there is only one branch, my local one [00:20] sandsmark: can you do 'bzr inventory | grep .bzrgnore.THIS' [00:21] Is there a way to change commit comments? [00:21] lifeless: yeah, bzr inventory returns such a file [00:21] RenatoSilva: uncommit the commit, and recommit it with new comments. [00:21] sandsmark: ok, you need to 'bzr remove' that file. bzr uses '$filename.THIS' for storing its conflicts [00:22] ah [00:22] ok [00:22] so by versioning it you've got it in a loop [00:22] lifeless: I'm better off not doing this, it's an old revision [00:22] RenatoSilva: then no. [00:22] ok thanks anyway [00:22] * sandsmark blames etckeeper [00:22] sandsmark: could you file a bug? we should be more graceful/informative about that particular case. [00:23] lifeless: well, 1.5 is pretty old [00:23] even so [00:23] ok [00:23] if its fixed already it will be easy to close ;) [00:23] heh, ok :-) [00:23] but while I suspect we have a bug thats similar to this already, I'm fairly sure we haven't actioned it. [00:23] so at worst this will be a dup and add data to the frequency people hit it. [00:24] lifeless: uhm, is this really a bug, though? I would rather say the problem is with etckeeper, adding all files indiscriminately [00:25] (the real question is where the conflict comes from, though) [00:25] bzr could help - it could say 'this is a dangerous file to add', it could, on conflicts, not conflict on that file but instead know it can overwrite it;it could adjust the conflict path it uses [00:25] yeah, true [00:27] well, it might give some false positives, but a simple warning might be nice [00:30] https://bugs.launchpad.net/bzr/+bug/414589 [00:30] Ubuntu bug 414589 in bzr "Bazaar doesn't notice/care if you try to version-control *.THIS, *.BASE, *.OTHER or *.moved" [Undecided,New] [00:30] lifeless: something like that ok? [00:30] sandsmark: great [00:30] k [00:30] I'll add a little editorial when it gets to my inbox [00:30] ok, thanks :-) [00:31] hmm, I'll try to backport a more recent bazaar to see if it helps with the utf8-failings [00:32] ah, it is in lenny-backports [00:38] ah, awesome, that worked like a charm [00:46] hmm, another odd error [00:47] http://pastebin.com/m32268cf3 [01:07] igc: some people find documentation more exciting than writing code ;-) [01:09] james_w: really?? Name one. :-) [01:09] crazy people I know :-) [01:09] but exactly the ones you want to be writing your documentation [01:10] james_w: true. Too much knowledge of the code can be a disadvantage when it comes to writing clear docs :-) [01:11] james_w: well docs for beginners at least [01:11] see the git documentation! [01:11] * mzz ducks [01:11] not wanting to spend your time writing code means that you can instead focus on writing great documentation [01:11] mzz: it makes my head spin [01:12] (it's not entirely fair towards the git folks, but the thing I remember most clearly about git is that it documentation suddenly went on and on about some kind of squid when I was trying to do some basic version control thing) [01:12] mzz: 'git log' is 30 pages! (and I wish I understood half of it) [01:12] I'd prefer code written by people passionate about it than code written by those who were just writing it because they felt they had to [01:12] "I don't *want* to hunt deep sea creatures right now! stop talking to me about an octopus!" [01:13] same goes for documentation [01:56] Is there a good guide to using the bzr smart server? [01:57] Would I have to setup a chroot jail for users? === thumper is now known as thumper-afk [02:31] am getting these errors: bzrlib.errors.LockContention: Could not acquire lock "/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable <== which I infer is a roundabout way of saying directory doesn't exist? or? [02:32] This is seen via a cron task; but only 1 in 4 runs. [02:50] spm: is it on nfs? [02:52] lifeless: no, local. based on the full traceback tho - i suspect it may be a bzrlib issue of sorts. it's pulling in a local 1.16 copy to run with - which was a hack to get around 2a format updates back in July. Take that out and I get a full on boom. progress of sorts... [02:55] lifeless: old vs new https://pastebin.canonical.com/21210/ - i suspect the cm bzrlib needs updating; and/or rejig the path to use the system one. [03:42] spm: this shouldn't have suddenly gone odd [03:43] however, the latter error means that you've broken it by whatever gives the boom:) [03:43] truly :-) [03:44] I've just put in a fix which works in manual testing; but in the leadup to, was seeing some really weird errors. My first suspicion was pebkac and inclined to hold that; but I wonder if something else is going on [03:48] something changed ;) [03:57] which is where it gets very weird; because a similar script isn't erroring at all. Anyway. see if the fix in place works. [04:10] lifeless: nope. same error. something else is happening here.... [04:20] spm: yes, I rather thought so :P [04:21] aye. ah well. At least that cleans up one possible area of problem. <== searching for any silver lining [04:23] let's say i have an existing bzr branch, and i want to bring in some code from another completely unrelated tree (think: main project, and plugin) -- is there any slick way to somehow preserve history, or even to keep that part of the tree "pointing" at the other branch to bring in updates later? Is this exactly what is going to be supported in the future with "subtrees"? [04:23] bzr add --ids-from /path/to/main files_copied_from_main [04:23] or something like that [04:24] then if you do a cherry pick merge bzr will know the files are the same [04:24] intriguing-- i'll check that out [04:24] keeping the history the same is rather harder, unless you're happy to have all of the other tree copied around forever more. [04:27] hi igc [04:27] lifeless: this is a really cool feature, i'm amazed that i never encountered it in my hours of googling on the topic [04:28] its not a panacea [04:28] but it should help [04:29] lifeless: so i put file-ids-from to the top of the branch, even if i'm only integrating a part of it? [04:29] Hello, I accidentally moved a file under version control manually and then commited. Is there a way to tell bzr I have moved the file to update its version history? [04:29] I moved the file and then used "bzr add" and then commited instead of bzr move [04:30] johnjosephbachir: yes, and you'll want the files being added at the same paths; then you can bzr mv then into their final place in the new tree [04:30] jseabold: bzr uncommit [04:30] jseabold: bzr remove --keep [04:30] jseabold: uncommit, revert add, then use bzr mv --after [04:30] jseabold: bzr mv --auto [04:30] jseabold: bzr commit [04:31] Ok, I actually commited more than once before I realized it, can I uncommit to a certain revision? [04:31] you can commit several times [04:31] you may want to shelve each step [04:31] unless you're happy to combine them [04:33] lifeless: Hmm, ok thanks. I will try to follow your instructions. So I'd just uncommit a few times until I'm at the right revision before the move? [04:34] lifeless: I think I need to read up some more on shelving. [04:34] uncommit; shelve --all; uncommit; shelve --all; uncommit; do stuff [04:35] commit; unshelve; commit; unshelve; commit [04:35] hi bialix [04:35] igc: I've read http://doc.bazaar-vcs.org/plugins/en/qbzr-plugin.html [04:36] I see there is holes in or doc [04:36] and based on your mail today I think I need to release 0.13.2 with some patches cherrypicked from trunk [04:37] lifeless: ha, awesome. I think I see what shelving is about. I am mighty relieved to learn this. Thanks. [04:37] bialix: why not a qbzr 0.14 at the end of thw week instead? [04:37] the docs say more [04:37] you don't want to uncommit past a merge, or stuff other folk will have merged, unless you really need to do. [04:38] but uncommit + shelve - very powerful [04:38] igc: can you explain this deadline? [04:38] 1 week [04:39] igc: btw, if you will be able to regenerate the doc with fresh qbzr trunk so I can see my latest doc improvements, it will be great. [04:39] bialix: iiuic, around aug 24? is the close off day for packages to make it into karmic. Beyond that, things can go in but the paperwork and approval process becomes larger [04:40] aha [04:40] understand [04:40] lifeless: ok, I don't need to uncommit past a merge so I should be good. Thanks again. [04:40] igc: so yes, it's better to release 0.14 then [04:40] bialix: I'm not a deb/Ubuntu packaging guy though so take my comments with a grain of salt until someone closer to the process confirms that [04:41] igc: I'm not either [04:42] igc: but 0.14 cycle is kinda too short (2 weeks) I guess [04:42] New upstream versions do need paperwork in a week, but it's not impossible paperwork. [04:43] It gets progressively harder as time goes on, so you should endeavour to get it in ASAP. [04:43] (August 27 is the date, I believe) [04:43] bialix, wgrant: sounds right: https://wiki.ubuntu.com/KarmicReleaseSchedule [04:45] bialix: so if it's aug 27, I think next Monday is ok for 0.14 [04:45] bialix: there's a lot there in a sense: qexport, qbind, qunbind and hopefully more if I pull my finger out this weekend and write quncommit say [04:46] bialix: and, no pressure, but qrun would be nice :-) :-) [04:46] igc: it might be prettier for people to have qbzr uncommit [04:47] igc: we have also new commit_data patch I'm about to merge [04:47] igc: so I think I'd better release 0.14 in the middle of this week and have 1 week for user testing. [04:47] so we can do 0.14.1 [04:48] if necessary [04:48] wgrant: what is the process to ensure our release from PPA will go into karmic? [04:48] bialix: to regen the plugin docs yourself, just download the branch I mentioned in the email and run the built-topics.py script. I think you can give qbzr as an argument iirc [04:49] bialix: I need some lunch - bbl [04:49] * igc food [04:49] ok [04:49] lifeless: do I need to move the file back by hand? I uncommitted to a revision that should have the file unmoved but when I "bzr status" it shows the file as removed. Am I missing something? [04:49] jseabold: uncommit doesn't change the tree [04:50] jseabold: which is why you need to shelve between uncommits:) [04:50] bialix: You have to ask for it to happen, or it will not happen at all. https://wiki.ubuntu.com/SponsorshipProcess is what you want. [04:50] jseabold: hwen you're back tot he point you want to be recommitting on, just do [04:50] bzr remove --keep FILE [04:50] bzr mv --auto [04:50] and bzr will detect it [04:51] sorry to be slow, but is FILE the path to the file that I have moved or the original location? Trying the original location gave an unversioned error. [04:51] the new location [04:52] ah ok [04:54] lifeless: "bzr mv --after" rather than "bzr mv --auto"? [04:54] the latter is easier [04:54] :) [04:55] It gave me a no auto option error. Do I need to upgrade bzr? [04:55] oh [04:55] if you have an old bzr then mv --after OLD NEW [04:55] --auto is reasonably old itself though. strange. [04:56] ugh, said OLD is not versioned [04:57] hmm [04:57] do 'bzr st' [04:57] does OLD show as 'missing'? [04:58] nope they show as 'removed' [04:58] ok [04:58] run 'bzr revert OLD' [04:59] then, 'rm OLD' (!not bzr rm OLD) [04:59] and then the mv --after should work [04:59] you are a lifesaver! I think that did the trick. Thanks [05:00] my pleasure === thumper-afk is now known as thumper [06:11] are there any windows savvey bzr people that use Launchpad that could comment on https://answers.edge.launchpad.net/launchpad/+question/79261 ? [07:05] hi all [07:11] vila: hi vila [07:11] vila: 15:11 < thumper> are there any windows savvey bzr people that use Launchpad that could comment on https://answers.edge.launchpad.net/launchpad/+question/79261 ? [07:12] lifeless: I saw that, but *I* am not windows savvey 8-) [07:13] The best I can guess is that ssh or its agent is not configured as it should... but indeed someone can explain the steps needed to check that better than me... [07:15] lifeless: and hi :) [07:16] :) [07:16] have a good weekend? [07:16] could have been better, but life can't always be pink :) [07:20] lifeless: that locking error we were chasing earlier. hypothetically :-) if we had two almost identical tasks (bzr update/config-manager) running simultaneously, would you expect that to generate that style of error? [07:20] no [07:20] but - a) bugs [07:20] and b) bugs [07:20] heh [07:20] so [07:21] we guard the dirstate _write_ lock with a lockdir lock on the tree [07:21] and we take write locks out to write stuff (duh) [07:21] we don't guard dirstate read locks like that, we expect the os to tell us it can/can't read lock it. [07:21] makes sense [07:23] as a "can't hurt" trial, I've offset the problematic of the two jobs to run 5 mins after the 1st. If we get a repeat, then life gets interesting again; if we don't... [07:23] spm: kk [07:24] if it 'fixes it', file a bug [07:24] it may be a misconfigured sys/proc thing, or a code bug [07:24] there may be a legitimate error we don't catch. [07:24] \o/ 12 errors [07:24] _closing in_ [07:24] right [07:24] heh [07:29] 11. [07:35] just as well the number counts down. I'd be worried else... [07:49] 5 [07:50] lifeless: hurrah! [07:52] I love this: [07:52] :!bzr commmit -m "Merge fix for test_knit in 2a." [07:52] Command 'commmit' not found, perhaps you meant 'commit'? [y/n]: y [07:52] thumper: your question still open? [08:04] thumper: answered [08:12] vila: bonjour [08:37] bialix: hi, argh, already gone [08:55] Done! [08:55] spiv: ^ [08:56] lifeless: tests passing with 2a as default ? [08:56] yes [08:56] YES ! [08:57] :) [08:57] ;) [08:57] just in time too [08:57] spamming the review queue++ [08:59] lifeless: since you seem to be in the right mood, care to fix the loom failures too ? :-} [08:59] heh [08:59] 6pm [08:59] I started at 6:30 this morning. [08:59] But you could put up a patch for loom ! [08:59] hehe, I tried :) [09:00] [please do] [09:00] * lifeless halts [09:04] lifeless: sweet! [09:04] lifeless: I churned through a bunch of your review proposals, btw :) [09:04] vila: seriously - if you wanted to identify any remaining tests (i've been running a reduced set from what failed the first time I tried) that would be great [09:04] vila: and secondly, loom is something we support, feel free to put time into keeping it working :) [09:05] spiv: i saw - thanks [09:05] spiv: I'm not going to shepard them today. [09:05] I'll probably make pqm-submit a bit friendlier tomorrow and batch-submit them from lp directly. [09:07] lifeless: (regarding loom), my last submission stalled, mostly because I had misconceptions about looms (when pushed mainly), I should look at it again... [09:10] vila: bzr branch lp:bzr-loom; fix the failing tests; push and submit ;) [09:10] the big question for me is 'should -b make a new branch or thread, in a loom' and I think the answer is 'thread'. [09:12] lifeless: hehe, I know, that was bug #309730 I was referring to, marked for expiration tomorrow :-/ [09:12] Launchpad bug 309730 in bzr-loom "loom semantics around about push/stacking/clone unclear or buggy ?" [Undecided,Incomplete] https://launchpad.net/bugs/309730 [09:12] oh [09:12] well, push in a loom to a new location is meant to make a loom [09:12] otherwise it pushes to whatevers there - loom or branch [09:13] yup, I thought it should always push to a branch (misconception) [09:14] * igc dinner [10:28] bialix: thanks [10:33] thumper: I think there is bug report in bzr about using paramiko as default SSH client [10:33] plink (PuTTY SSH tool) has too much caveats [10:33] and that guy using plink [10:34] ah [10:34] what is the default setup with bzr on windows? [10:34] I have some people locally that want me to give them a tutorial on bzr [10:34] but they all use windows [10:34] they are interested in using LP though [10:34] so they need SSH keys [10:35] are there docs on the wiki about the easiest way to set this up? [10:35] I don't have a windows machine myself any more [10:38] thumper: I guess you need to ask for this in Bzr-Windows mailing list [10:39] I don't think there is good wiki about setup ssh for windows [10:41] I'm working with lp and sftp and ssh since 2006 and during this years I've minted the gold rule: always use paramiko [10:41] thumper: btw, launchpad wiki resource about setting up ssh keys is very good [10:42] the problem not in lp itself or ssh keys [10:42] ok... [10:42] problem in initial connection when user should say: yes, I'm trust this ssh server [10:43] paramiko do it implicitly [10:43] plink just fails [10:43] hah [10:43] how does one add a trusted server for plink then? [10:43] manually [10:43] bzr can;t help here [10:43] ick [10:44] one need run plink to connect the server [10:44] first time [10:46] thumper: http://pastebin.com/m2d48ac6e [10:47] maybe launchpad plugin for bzr can help here? with some sort of special command. I dunno [10:47] hmm, not right now for sure :) [10:48] yep, I mean somebody need to write this special command [10:48] but I'm just suggest people to avoid using plink [10:48] paramiko using the same ssh keys from pageant [10:49] and I don't find any significant difference in speed between both [10:49] and paramiko bundled into bzr.exe by default [10:49] so paramiko -- it's almost the right way [10:51] and perhaps one can file a bug against lp:paramiko and asking for y/n when unknown ssh server signature encountered [11:06] hi there, I'm moving my first steps with bzr.. seems pretty cool so far.. I've been able to create a centralized development infrastructure .. [11:07] now I'm not sure how the workflow for creating different versions of my software will be.. [11:07] should I have to tag the trunk? or creating subdirectories? .. I'm confused [11:17] thumper: btw, for casual launchpad code users password auth would probably be more convenient... I wonder if we should enable that in code hosting's ssh server? [11:17] spiv: I'm not sure I could sell that [11:17] Yeah. And I kinda like that we're currently only asking users to type their password directly into the website, so maybe it's not worth it. [11:18] spiv: keep thinking though :) [11:18] But it would probably ease the pain for SSH newbies. [11:18] I'm sure there's something for our windows users [11:18] perhaps we should do something with the launchpad plugin like bialix suggests [11:19] Make the bzr installer automatically add launchpad's fingerprint to plink's registry of known hosts? [11:21] The difficulty is partly that windows doesn't have a de facto standard SSH install like /usr/bin/ssh that we can rely on, and partly that the one of the common options (plink) is pretty crummy. [11:22] So insulating ourselves from that via bundling paramiko is perhaps the best we can do? Dunno. [11:27] spiv: just for note: in the past (~2006-2007) plink was disabled for long time, at all [11:27] because the same problem with initial y/n [11:31] thumper, spiv: Bug #296110 [11:31] Launchpad bug 296110 in bzr "bzr should install launchpad ssh host keys" [Low,Confirmed] https://launchpad.net/bugs/296110 === Noldorin_ is now known as Noldorin [12:13] luks: hi [12:22] hi bialix [12:32] hello is there a list of project hosting sites with bazaar support? [12:34] luks: today I've stumbled with problem in qconflicts [12:35] luks: mark_item_as_resolved try to convert file_id to filename. do you remember why in needed? [12:36] bialix: not really, sorry [12:36] heh [12:37] currently I'm just using filename we shows in the widget [12:37] I'll dogfood it more, maybe can found use case for this [12:53] bialix: Are you sure you didn't mean bug #237297 instead of #296110 ? [12:53] Launchpad bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix] https://launchpad.net/bugs/237297 [12:54] * vila trying to better understand for the next time the question is raised [13:15] vila: no === mrevell is now known as mrevell-lunch [13:15] they are different ways to solve th eproblem [13:16] 296100 is about lp [13:16] spiv and thumper talking about ssh server fingerprint, and this bug about certificates [13:20] bialix: ??? [13:20] [14:53] bialix: Are you sure you didn't mean bug #237297 instead of #296110 ? [13:20] Launchpad bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix] https://launchpad.net/bugs/237297 [13:20] both #237297 and #296110 are about host keys [13:20] yep [13:21] vila, I teach you right answer for this problem on WIndows: set BZR_SSH=paramiko [13:21] bialix: ok, good :) [13:22] https://bugs.launchpad.net/bzr/+bug/414743 [13:22] Ubuntu bug 414743 in bzr "paramiko should be default client for Windows" [Undecided,New] [13:22] hmmm [13:22] and which ssh agent ? [13:22] why ubottu said it's a "Ubuntu bug"? [13:22] if paramiko then pageant [13:23] ok [13:23] bzrlib.tests.blackbox.test_serve.TestBzrServeSSH.test_bzr_connect_to_bzr_ssh is leaking threads among 1 leaking tests. [13:23] should I worry? [13:23] vila: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair [13:23] denys: no [13:23] vila: this guide is OK, but it miss the problem with plink/paramiko [13:24] bialix: may be mention that in bug #414743 ? [13:24] Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [Undecided,New] https://launchpad.net/bugs/414743 [13:25] it's really hard [13:25] bbiab [13:30] vila: it seems either nobody care too much about plink or don't want to prohibit it. [13:30] vila: and there is only jam who can do something about windows [13:30] cila: and jam too busy with other things [13:31] it's a stalemate I'd say [13:31] These are good reasons to collect the information in the bug reports [13:32] which sort of information [13:33] vila: this guide is OK, but it miss the problem with plink/paramiko [13:33] the sooner people get good directions... the less problems they will encounter down the road... [13:35] vila: IIUC there is possible that people could use not plink but openssh port for win32 that may not affected by plink problem [13:35] I'm afraid there is no "right" answer === mrevell-lunch is now known as mrevell [13:36] perhaps just prohibit plink from auto-detection will be enough [13:36] somebody should say: "yes, this is the right way" [13:36] as of today nobody dare enough [13:36] Does anyone have experience with bzr server? [13:37] bialix: JFDI :) [13:37] JFDI? [13:37] * bialix never was good in acronyms [13:37] Jeff Fondles Dweebs, Init? [13:38] I don't know, google it [13:38] jump for dumb iphone? [13:39] oh, just focus and do it [13:39] Just Do it :) [13:39] Colonel-Rosa: very polite way 'focus', thanks ;) [13:40] oooh, quoting fullermd: where I can download extra 8 hours to do everythong I want? [13:45] Colonel-Rosa: you can ask about bzr server [13:46] the answer will depends on question [13:46] I was going to ask, if I set one up, do I need to specfiy users if I allow writing? [13:47] plain bzr serve has no support for ACL [13:47] so you need to use bzr+ssh [13:48] Why does it allow writes then? [13:48] and specify users via ssh stuff [13:48] good question [13:48] night all [13:48] igc: night [13:49] Colonel-Rosa: maybe because when you run bzr+ssh it invokes bzr serve via ssh in write-enabled mode? [13:50] Colonel-Rosa: in some situations (e.g. a small, isolated network with only trusted users) a simple unauthenticated write-enabled server is all you need. [13:50] I'm using it in such conditions at work [13:50] small network [13:51] bialix: before I forget, that bug where qbzr and bzr-pipeline are incompatible needs fixing in qbzr 0.14.*. Can you chat to garyvdm about it? If we have to, I'd like to drop support for us override the merge command - I don't think the feature we're offering is important enough to break compatibility with other plugins overriding merge. You guys may feel otherwise though [13:51] Ok, I might go with that route. I'll restrict the port to my port [13:51] to my ip* rather [13:52] Or you could run "bzr serve" on a localhost only port, and then and use another tool to provide simple authentication based on SSL client certs on a public port. [13:52] I had a look at setting up a chroot jail for users, but didn't really get it [13:52] Hi, is there any way to make bzr remember the password I use for my googlecode SVN? (HTTPS checkout). Currently it asks me every time. [13:52] igc: Id like to remove merge --qpreview [13:53] igc: but garyvdm has another opinion. but I can remove it just for 0.14 and later fix it in trunk [13:54] igc: good point though. if you can write some comment tomorrow in that bug report [14:00] spiv: regarding ssl client certs, did you review denys merge proposal about bzrs:, you nay have to chase the right one a bit as he made several resubmit [14:15] bialix: good mail on bzr-windows :) [14:15] why? [14:16] I hope it will start discussion [14:24] bialix: exactly ! [14:25] vila: I did, yes. [14:25] spiv: great [14:25] spiv: I should check that to stay in touch then :) === ja1 is now known as jam === kiko-afk is now known as kiko [15:34] james_w: good morning, do you have some time to look at bug 405251 again? Our new repo's are killing themselves in the same way... [15:34] Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251 [15:34] I don't know why Kopete always replaces jam with James_W: I mean jam... === deryck_ is now known as deryck [16:03] fjalvingh: I can probably look at it some today, I need to check for any other pressing matters, though [16:03] morning vila [16:04] jam: hello [16:04] hi bialix [16:04] jam: did you saw my message about installing Pyreadline on kerguelen? [16:05] hi everyone! [16:05] i'm in big trouble! :( [16:05] i think maybe i lost 2 weeks of work [16:05] bzr heads --dead [16:06]