[00:09] <sandsmark> 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] <sandsmark> backtrace and some info: http://pastebin.com/m2d85582c
[00:15] <johnjosephbachir> anyone have a favorite rhel/centos rpm that's newer than the one provided by EPEL?
[00:16] <sandsmark> hah, I love bzr:   Conflict adding file .bzrignore.THIS.moved.  Moved existing file to .bzrignore.THIS.moved.moved.
[00:19] <sandsmark> (how on earth I get conflicts when I only have one local branch is beyond me :-P)
[00:19] <lifeless> sandsmark: you can conflict with someone else without needing two local branches
[00:20] <sandsmark> lifeless: there is noone else, there is only one branch, my local one
[00:20] <lifeless> sandsmark: can you do 'bzr inventory | grep .bzrgnore.THIS'
[00:21] <RenatoSilva> Is there a way to change commit comments?
[00:21] <sandsmark> lifeless: yeah, bzr inventory returns such a file
[00:21] <lifeless> RenatoSilva: uncommit the commit, and recommit it with new comments.
[00:21] <lifeless> sandsmark: ok, you need to 'bzr remove' that file. bzr uses '$filename.THIS' for storing its conflicts
[00:22] <sandsmark> ah
[00:22] <sandsmark> ok
[00:22] <lifeless> so by versioning it you've got it in a loop
[00:22] <RenatoSilva> lifeless: I'm better off not doing this, it's an old revision
[00:22] <lifeless> RenatoSilva: then no.
[00:22] <RenatoSilva> ok thanks anyway
[00:22]  * sandsmark blames etckeeper
[00:22] <lifeless> sandsmark: could you file a bug? we should be more graceful/informative about that particular case.
[00:23] <sandsmark> lifeless: well, 1.5 is pretty old
[00:23] <lifeless> even so
[00:23] <sandsmark> ok
[00:23] <lifeless> if its fixed already it will be easy to close ;)
[00:23] <sandsmark> heh, ok :-)
[00:23] <lifeless> but while I suspect we have a bug thats similar to this already, I'm fairly sure we haven't actioned it.
[00:23] <lifeless> so at worst this will be a dup and add data to the frequency people hit it.
[00:24] <sandsmark> lifeless: uhm, is this really a bug, though? I would rather say the problem is with etckeeper, adding all files indiscriminately
[00:25] <sandsmark> (the real question is where the conflict comes from, though)
[00:25] <lifeless> 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] <sandsmark> yeah, true
[00:27] <sandsmark> well, it might give some false positives, but a simple warning might be nice
[00:30] <sandsmark> https://bugs.launchpad.net/bzr/+bug/414589
[00:30] <sandsmark> lifeless: something like that ok?
[00:30] <lifeless> sandsmark: great
[00:30] <sandsmark> k
[00:30] <lifeless> I'll add a little editorial when it gets to my inbox
[00:30] <sandsmark> ok, thanks :-)
[00:31] <sandsmark> hmm, I'll try to backport a more recent bazaar to see if it helps with the utf8-failings
[00:32] <sandsmark> ah, it is in lenny-backports
[00:38] <sandsmark> ah, awesome, that worked like a charm
[00:46] <sandsmark> hmm, another odd error
[00:47] <sandsmark> http://pastebin.com/m32268cf3
[01:07] <james_w> igc: some people find documentation more exciting than writing code ;-)
[01:09] <igc> james_w: really?? Name one. :-)
[01:09] <james_w> crazy people I know :-)
[01:09] <james_w> but exactly the ones you want to be writing your documentation
[01:10] <igc> james_w: true. Too much knowledge of the code can be a disadvantage when it comes to writing clear docs :-)
[01:11] <igc> james_w: well docs for beginners at least
[01:11] <mzz> see the git documentation!
[01:11]  * mzz ducks
[01:11] <james_w> not wanting to spend your time writing code means that you can instead focus on writing great documentation
[01:11] <igc> mzz: it makes my head spin
[01:12] <mzz> (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] <igc> mzz: 'git log' is 30 pages! (and I wish I understood half of it)
[01:12] <james_w> 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] <mzz> "I don't *want* to hunt deep sea creatures right now! stop talking to me about an octopus!"
[01:13] <james_w> same goes for documentation
[01:56] <Colonel-Rosa> Is there a good guide to using the bzr smart server?
[01:57] <Colonel-Rosa> Would I have to setup a chroot jail for users?
[02:31] <spm> am getting these errors: bzrlib.errors.LockContention: Could not acquire lock "<directory>/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable <== which I infer is a roundabout way of saying directory doesn't exist? or?
[02:32] <spm> This is seen via a cron task; but only 1 in 4 runs.
[02:50] <lifeless> spm: is it on nfs?
[02:52] <spm> 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] <spm> 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] <lifeless> spm: this shouldn't have suddenly gone odd
[03:43] <lifeless> however, the latter error means that you've broken it by whatever gives the boom:)
[03:43] <spm> truly :-)
[03:44] <spm> 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] <lifeless> something changed ;)
[03:57] <spm> 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] <spm> lifeless: nope. same error. something else is happening here....
[04:20] <lifeless> spm: yes, I rather thought so :P
[04:21] <spm> aye. ah well. At least that cleans up one possible area of problem. <== searching for any silver lining
[04:23] <johnjosephbachir> 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] <lifeless> bzr add --ids-from /path/to/main files_copied_from_main
[04:23] <lifeless> or something like that
[04:24] <lifeless> then if you do a cherry pick merge bzr will know the files are the same
[04:24] <johnjosephbachir> intriguing-- i'll check that out
[04:24] <lifeless> 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] <bialix> hi igc
[04:27] <johnjosephbachir> 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] <lifeless> its not a panacea
[04:28] <lifeless> but it should help
[04:29] <johnjosephbachir> 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] <jseabold> 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] <jseabold> I moved the file and then used "bzr add" and then commited instead of bzr move
[04:30] <lifeless> 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] <lifeless> jseabold: bzr uncommit
[04:30] <lifeless> jseabold: bzr remove --keep <file>
[04:30] <bialix> jseabold: uncommit, revert add, then use bzr mv --after
[04:30] <lifeless> jseabold: bzr mv --auto
[04:30] <lifeless> jseabold: bzr commit
[04:31] <jseabold> Ok, I actually commited more than once before I realized it, can I uncommit to a certain revision?
[04:31] <lifeless> you can commit several times
[04:31] <lifeless> you may want to shelve each step
[04:31] <lifeless> unless you're happy to combine them
[04:33] <jseabold> 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] <jseabold> lifeless: I think I need to read up some more on shelving.
[04:34] <lifeless> uncommit; shelve --all; uncommit; shelve --all; uncommit; do stuff
[04:35] <lifeless> commit; unshelve; commit; unshelve; commit
[04:35] <igc> hi bialix
[04:35] <bialix> igc: I've read http://doc.bazaar-vcs.org/plugins/en/qbzr-plugin.html
[04:36] <bialix> I see there is holes in or doc
[04:36] <bialix> and based on your mail today I think I need to release 0.13.2 with some patches cherrypicked from trunk
[04:37] <jseabold> lifeless: ha, awesome.  I think I see what shelving is about.  I am mighty relieved to learn this.  Thanks.
[04:37] <igc> bialix: why not a qbzr 0.14 at the end of thw week instead?
[04:37] <lifeless> the docs say more
[04:37] <lifeless> you don't want to uncommit past a merge, or stuff other folk will have merged, unless you really need to do.
[04:38] <lifeless> but uncommit + shelve - very powerful
[04:38] <bialix> igc: can you explain this deadline?
[04:38] <bialix> 1 week
[04:39] <bialix> 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] <igc> 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] <bialix> aha
[04:40] <bialix> understand
[04:40] <jseabold> lifeless: ok, I don't need to uncommit past a merge so I should be good.  Thanks again.
[04:40] <bialix> igc: so yes, it's better to release 0.14 then
[04:40] <igc> 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] <bialix> igc: I'm not either
[04:42] <bialix> igc: but 0.14 cycle is kinda too short (2 weeks) I guess
[04:42] <wgrant> New upstream versions do need paperwork in a week, but it's not impossible paperwork.
[04:43] <wgrant> It gets progressively harder as time goes on, so you should endeavour to get it in ASAP.
[04:43] <wgrant> (August 27 is the date, I believe)
[04:43] <igc> bialix, wgrant: sounds right: https://wiki.ubuntu.com/KarmicReleaseSchedule
[04:45] <igc> bialix: so if it's aug 27, I think next Monday is ok for 0.14
[04:45] <igc> 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] <igc> bialix: and, no pressure, but qrun would be nice :-) :-)
[04:46] <lifeless> igc: it might be prettier for people to have qbzr uncommit
[04:47] <bialix> igc: we have also new commit_data patch I'm about to merge
[04:47] <bialix> 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] <bialix> so we can do 0.14.1
[04:48] <bialix> if necessary
[04:48] <bialix> wgrant: what is the process to ensure our release from PPA will go into karmic?
[04:48] <igc> 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] <igc> bialix: I need some lunch - bbl
[04:49]  * igc food
[04:49] <bialix> ok
[04:49] <jseabold> 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] <lifeless> jseabold: uncommit doesn't change the tree
[04:50] <lifeless> jseabold: which is why you need to shelve between uncommits:)
[04:50] <wgrant> 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] <lifeless> jseabold: hwen you're back tot he point you want to be recommitting on, just do
[04:50] <lifeless> bzr remove --keep FILE
[04:50] <lifeless> bzr mv --auto
[04:50] <lifeless> and bzr will detect it
[04:51] <jseabold> 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] <lifeless> the new location
[04:52] <jseabold> ah ok
[04:54] <jseabold> lifeless: "bzr mv --after" rather than "bzr mv --auto"?
[04:54] <lifeless> the latter is easier
[04:54] <lifeless> :)
[04:55] <jseabold> It gave me a no auto option error.  Do I need to upgrade bzr?
[04:55] <lifeless> oh
[04:55] <lifeless> if you have an old bzr then mv --after OLD NEW
[04:55] <lifeless> --auto is reasonably old itself though. strange.
[04:56] <jseabold> ugh, said OLD is not versioned
[04:57] <lifeless> hmm
[04:57] <lifeless> do 'bzr st'
[04:57] <lifeless> does OLD show as 'missing'?
[04:58] <jseabold> nope they show as 'removed'
[04:58] <lifeless> ok
[04:58] <lifeless> run 'bzr revert OLD'
[04:59] <lifeless> then, 'rm OLD' (!not bzr rm OLD)
[04:59] <lifeless> and then the mv --after should work
[04:59] <jseabold> you are a lifesaver!  I think that did the trick.  Thanks
[05:00] <lifeless> my pleasure
[06: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:05] <vila> hi all
[07:11] <lifeless> vila: hi vila
[07:11] <lifeless> 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] <vila> lifeless: I saw that, but *I* am not windows savvey 8-)
[07:13] <vila> 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] <vila> lifeless: and hi :)
[07:16] <lifeless> :)
[07:16] <lifeless> have a good weekend?
[07:16] <vila> could have been better, but life can't always be pink :)
[07:20] <spm> 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] <lifeless> no
[07:20] <lifeless> but - a) bugs
[07:20] <lifeless> and b) bugs
[07:20] <spm> heh
[07:20] <lifeless> so
[07:21] <lifeless> we guard the dirstate _write_ lock with a lockdir lock on the tree
[07:21] <lifeless> and we take write locks out to write stuff (duh)
[07:21] <lifeless> 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] <spm> makes sense
[07:23] <spm> 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] <lifeless> spm: kk
[07:24] <lifeless> if it 'fixes it', file a bug
[07:24] <lifeless> it may be a misconfigured sys/proc thing, or a code bug
[07:24] <lifeless> there may be a legitimate error we don't catch.
[07:24] <lifeless> \o/ 12 errors
[07:24] <lifeless> _closing in_
[07:24] <spm> right
[07:24] <spm> heh
[07:29] <lifeless> 11.
[07:35] <spm> just as well the number counts down. I'd be worried else...
[07:49] <lifeless> 5
[07:50] <spiv> lifeless: hurrah!
[07:52] <lifeless> I love this:
[07:52] <lifeless> :!bzr commmit -m "Merge fix for test_knit in 2a."
[07:52] <lifeless> Command 'commmit' not found, perhaps you meant 'commit'? [y/n]: y
[07:52] <bialix> thumper: your question still open?
[08:04] <bialix> thumper: answered
[08:12] <bialix> vila: bonjour
[08:37] <vila> bialix: hi, argh, already gone
[08:55] <lifeless> Done!
[08:55] <lifeless> spiv: ^
[08:56] <vila> lifeless: tests passing with 2a as default ?
[08:56] <lifeless> yes
[08:56] <vila> YES !
[08:57] <vila> :)
[08:57] <lifeless> ;)
[08:57] <lifeless> just in time too
[08:57] <lifeless> spamming the review queue++
[08:59] <vila> lifeless: since you seem to be in the right mood, care to fix the loom failures too ? :-}
[08:59] <lifeless> heh
[08:59] <lifeless> 6pm
[08:59] <lifeless> I started at 6:30 this morning.
[08:59] <lifeless> But you could put up a patch for loom !
[08:59] <vila> hehe, I tried :)
[09:00] <lifeless> [please do]
[09:00]  * lifeless halts
[09:04] <spiv> lifeless: sweet!
[09:04] <spiv> lifeless: I churned through a bunch of your review proposals, btw :)
[09:04] <lifeless> 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] <lifeless> vila: and secondly, loom is something we support, feel free to put time into keeping it working :)
[09:05] <lifeless> spiv: i saw - thanks
[09:05] <lifeless> spiv: I'm not going to shepard them today.
[09:05] <lifeless> I'll probably make pqm-submit a bit friendlier tomorrow and batch-submit them from lp directly.
[09:07] <vila> 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] <lifeless> vila: bzr branch lp:bzr-loom; fix the failing tests; push and submit ;)
[09:10] <lifeless> 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] <vila> lifeless: hehe, I know, that was bug #309730 I was referring to, marked for expiration tomorrow :-/
[09:12] <lifeless> oh
[09:12] <lifeless> well, push in a loom to a new location is meant to make a loom
[09:12] <lifeless> otherwise it pushes to whatevers there - loom or branch
[09:13] <vila> yup, I thought it should always push to a branch (misconception)
[09:14]  * igc dinner
[10:28] <thumper> bialix: thanks
[10:33] <bialix> thumper: I think there is bug report in bzr about using paramiko as default SSH client
[10:33] <bialix> plink (PuTTY SSH tool) has too much caveats
[10:33] <bialix> and that guy using plink
[10:34] <thumper> ah
[10:34] <thumper> what is the default setup with bzr on windows?
[10:34] <thumper> I have some people locally that want me to give them a tutorial on bzr
[10:34] <thumper> but they all use windows
[10:34] <thumper> they are interested in using LP though
[10:34] <thumper> so they need SSH keys
[10:35] <thumper> are there docs on the wiki about the easiest way to set this up?
[10:35] <thumper> I don't have a windows machine myself any more
[10:38] <bialix> thumper: I guess you need to ask for this in Bzr-Windows mailing list
[10:39] <bialix> I don't think there is good wiki about setup ssh for windows
[10:41] <bialix> 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] <bialix> thumper: btw, launchpad wiki resource about setting up ssh keys is very good
[10:42] <bialix> the problem not in lp itself or ssh keys
[10:42] <thumper> ok...
[10:42] <bialix> problem in initial connection when user should say: yes, I'm trust this ssh server
[10:43] <bialix> paramiko do it implicitly
[10:43] <bialix> plink just fails
[10:43] <thumper> hah
[10:43] <thumper> how does one add a trusted server for plink then?
[10:43] <bialix> manually
[10:43] <bialix> bzr can;t help here
[10:43] <thumper> ick
[10:44] <bialix> one need run plink to connect the server
[10:44] <bialix> first time
[10:46] <bialix> thumper: http://pastebin.com/m2d48ac6e
[10:47] <bialix> maybe launchpad plugin for bzr can help here? with some sort of special command. I dunno
[10:47] <thumper> hmm, not right now for sure :)
[10:48] <bialix> yep, I mean somebody need to write this special command
[10:48] <bialix> but I'm just suggest people to avoid using plink
[10:48] <bialix> paramiko using the same ssh keys from pageant
[10:49] <bialix> and I don't find any significant difference in speed between both
[10:49] <bialix> and paramiko bundled into bzr.exe by default
[10:49] <bialix> so paramiko -- it's almost the right way
[10:51] <bialix> and perhaps one can file a bug against lp:paramiko and asking for y/n when unknown ssh server signature encountered
[11:06] <fax8> 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] <fax8> now I'm not sure how the workflow for creating different versions of my software will be..
[11:07] <fax8> should I have to tag the trunk? or creating subdirectories? .. I'm confused
[11:17] <spiv> 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] <thumper> spiv: I'm not sure I could sell that
[11:17] <spiv> 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] <thumper> spiv: keep thinking though :)
[11:18] <spiv> But it would probably ease the pain for SSH newbies.
[11:18] <thumper> I'm sure there's something for our windows users
[11:18] <thumper> perhaps we should do something with the launchpad plugin like bialix suggests
[11:19] <spiv> Make the bzr installer automatically add launchpad's fingerprint to plink's registry of known hosts?
[11:21] <spiv> 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] <spiv> So insulating ourselves from that via bundling paramiko is perhaps the best we can do?  Dunno.
[11:27] <bialix> spiv: just for note: in the past (~2006-2007) plink was disabled for long time, at all
[11:27] <bialix> because the same problem with initial y/n
[11:31] <bialix> thumper, spiv: Bug #296110
[12:13] <bialix> luks: hi
[12:22] <luks> hi bialix
[12:32] <ZuLuuuuuu> hello is there a list of project hosting sites with bazaar support?
[12:34] <bialix> luks: today I've stumbled with problem in qconflicts
[12:35] <bialix> luks: mark_item_as_resolved try to convert file_id to filename. do you remember why in needed?
[12:36] <luks> bialix: not really, sorry
[12:36] <bialix> heh
[12:37] <bialix> currently I'm just using filename we shows in the widget
[12:37] <bialix> I'll dogfood it more, maybe can found use case for this
[12:53] <vila> bialix: Are you sure you didn't mean bug #237297 instead of #296110 ?
[12:54]  * vila trying to better understand for the next time the question is raised
[13:15] <bialix> vila: no
[13:15] <bialix> they are different ways to solve th eproblem
[13:16] <bialix> 296100 is about lp
[13:16] <bialix> spiv and thumper talking about ssh server fingerprint, and this bug about certificates
[13:20] <vila> bialix: ???
[13:20] <bialix> [14:53]	<vila>	bialix: Are you sure you didn't mean bug #237297 instead of #296110 ?
[13:20] <vila> both #237297 and #296110 are about host keys
[13:20] <bialix> yep
[13:21] <bialix> vila, I teach you right answer for this problem on WIndows: set BZR_SSH=paramiko
[13:21] <vila> bialix: ok, good :)
[13:22] <bialix> https://bugs.launchpad.net/bzr/+bug/414743
[13:22] <bialix> hmmm
[13:22] <vila> and which ssh agent ?
[13:22] <bialix> why ubottu said it's a "Ubuntu bug"?
[13:22] <bialix> if paramiko then pageant
[13:23] <vila> ok
[13:23] <denys> bzrlib.tests.blackbox.test_serve.TestBzrServeSSH.test_bzr_connect_to_bzr_ssh is leaking threads among 1 leaking tests.
[13:23] <denys> should I worry?
[13:23] <bialix> vila: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[13:23] <vila> denys: no
[13:23] <bialix> vila: this guide is OK, but it miss the problem with plink/paramiko
[13:24] <vila> bialix: may be mention that in bug #414743 ?
[13:25] <bialix> it's really hard
[13:25] <bialix> bbiab
[13:30] <bialix> vila: it seems either nobody care too much about plink or don't want to prohibit it.
[13:30] <bialix> vila: and there is only jam who can do something about windows
[13:30] <bialix> cila: and jam too busy with other things
[13:31] <bialix> it's a stalemate I'd say
[13:31] <vila> These are good reasons to collect the information in the bug reports
[13:32] <bialix> which sort of information
 vila: this guide is OK, but it miss the problem with plink/paramiko
[13:33] <vila> the sooner people get good directions... the less problems they will encounter down the road...
[13:35] <bialix> 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] <bialix> I'm afraid there is no "right" answer
[13:36] <bialix> perhaps just prohibit plink from auto-detection will be enough
[13:36] <bialix> somebody should say: "yes, this is the right way"
[13:36] <bialix> as of today nobody dare enough
[13:36] <Colonel-Rosa> Does anyone have experience with bzr server?
[13:37] <vila> bialix: JFDI :)
[13:37] <bialix> JFDI?
[13:37]  * bialix never was good in acronyms
[13:37] <Colonel-Rosa> Jeff Fondles Dweebs, Init?
[13:38] <Colonel-Rosa> I don't know, google it
[13:38] <bialix> jump for dumb iphone?
[13:39] <Colonel-Rosa> oh, just focus and do it
[13:39] <vila> Just Do it :)
[13:39] <vila> Colonel-Rosa: very polite way 'focus', thanks ;)
[13:40] <bialix> oooh, quoting fullermd: where I can download extra 8 hours to do everythong I want?
[13:45] <bialix> Colonel-Rosa: you can ask about bzr server
[13:46] <bialix> the answer will depends on question
[13:46] <Colonel-Rosa> I was going to ask, if I set one up, do I need to specfiy users if I allow writing?
[13:47] <bialix> plain bzr serve has no support for ACL
[13:47] <bialix> so you need to use bzr+ssh
[13:48] <Colonel-Rosa> Why does it allow writes then?
[13:48] <bialix> and specify users via ssh stuff
[13:48] <bialix> good question
[13:48] <igc> night all
[13:48] <bialix> igc: night
[13:49] <bialix> Colonel-Rosa: maybe because when you run bzr+ssh it invokes bzr serve via ssh in write-enabled mode?
[13:50] <spiv> 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] <bialix> I'm using it in such conditions at work
[13:50] <bialix> small network
[13:51] <igc> 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] <Colonel-Rosa> Ok, I might go with that route. I'll restrict the port to my port
[13:51] <Colonel-Rosa> to my ip* rather
[13:52] <spiv> 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] <Colonel-Rosa> I had a look at setting up a chroot jail for users, but didn't really get it
[13:52] <lfaraone> 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] <bialix> igc: Id like to remove merge --qpreview
[13:53] <bialix> igc: but garyvdm has another opinion. but I can remove it just for 0.14 and later fix it in trunk
[13:54] <bialix> igc: good point though. if you can write some comment tomorrow in that bug report
[14:00] <vila> 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] <vila> bialix: good mail on bzr-windows :)
[14:15] <bialix> why?
[14:16] <bialix> I hope it will start discussion
[14:24] <vila> bialix: exactly !
[14:25] <spiv> vila: I did, yes.
[14:25] <vila> spiv: great
[14:25] <vila> spiv: I should check that to stay in touch then :)
[15:34] <fjalvingh> 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] <fjalvingh> I don't know why Kopete always replaces jam with James_W: I mean jam...
[16:03] <jam> fjalvingh: I can probably look at it some today, I need to check for any other pressing matters, though
[16:03] <jam> morning vila
[16:04] <bialix> jam: hello
[16:04] <jam> hi bialix
[16:04] <bialix> jam: did you saw my message about installing Pyreadline on kerguelen?
[16:05] <Enisseo> hi everyone!
[16:05] <Enisseo> i'm in big trouble! :(
[16:05] <Enisseo> i think maybe i lost 2 weeks of work
[16:05] <bialix> bzr heads --dead
[16:06] <Enisseo> bialix > yes!
[16:06] <Enisseo> bialix > i see my last (true) revision in the list
[16:06] <bialix> bzr pull -r revid:your-revisioin-id --overwrite .
[16:07] <Enisseo> trying...
[16:07] <bialix> or branch with this revid
[16:07] <fjalvingh> james_w: thanks, I will wait.
[16:07] <fjalvingh> james_w: thankx
[16:07] <fjalvingh> Thanks, jam... Very irritating.
[16:08] <fjalvingh> I will check why Kopete always replaces jam.
[16:08] <Enisseo> omfg bialix! :)
[16:08] <jam> fjalvingh: you might be typing jam<tab> which wouldn't autocomplete the exact name, I guess
[16:08] <fjalvingh> I'm just typing jam:
[16:08] <bialix> Enisseo: what? I'm in telepatic mode?
[16:08] <fjalvingh> I'll check the settings.
[16:08] <jam> bialix, Enisseo: or 'bzr merge . -r revid:'
[16:09]  * bialix : telepatic mode off
[16:09] <Enisseo> bialix: kind of ;)
[16:09] <Enisseo> i did not know this command but i was pretty sure bzr could not lose my files
[16:09] <Enisseo> but "bzr log" made me nervous :P
[16:10] <Enisseo> maybe i'll explain how i did to lose my files
[16:10] <Enisseo> 1. commit changes locally
[16:10] <Enisseo> 2. commit to the repo
[16:10] <Enisseo> 3. uncommit the repo
[16:10] <Enisseo> 4. do a lot of changes to the --locla
[16:11] <Enisseo> 5. update from the repo
[16:12] <Enisseo> 6. panicking while reading the list of actions done by the update command
[16:12] <Enisseo> 7. revert to the last:1 rev
[16:12] <Enisseo> 8. panicking even more
[16:13] <jam> Enisseo: so update changes your local work into the upstream work and 'merges' the local stuff in
[16:13] <jam> when you reverted you through away your local work
[16:13] <jam> 'bzr heads --dead' shows you the local work again
[16:13] <jam> and you can merge that back into your upstream
[16:13] <Enisseo> jam > okay
[16:15] <Enisseo> bialix > thanks, really :) and to the bzr team for anticipating my mistakes (and for building a *real* VCS, unlike that sh** of VSS i have to use at my office :P)
[16:15] <bialix> Enisseo: np
[16:16] <Enisseo> bye!
[16:17] <bialix> jam: I've got very strange error: ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex(GraphIndex('bzr://host/repo/.bzr/repository/indices/1be11e45e6965720333219afc18eac5b.rix'))) is not locked
[16:17] <jam> bialix: happens when you use "-r XXX" + log + bzr+ssh
[16:17] <jam> I assume we aren't locking the branch before evaluating -r
[16:17] <bialix> jam: no, I'm using merge
[16:17] <bialix> and plain bzr://
[16:18] <jam> bialix: you are using a remote access, and -r, right?
[16:18] <bialix> jam: I did not found such bug, and pehaps just filed duplicate
[16:18] <jam> bzr+ssh == bzr for pretty much all purposes
[16:18] <bialix> yes
[16:18] <bialix> Bug #414869
[16:18] <jam> there is one for log
[16:18] <jam> presumably log and merge both aren't locking the branch
[16:18] <jam> which works ok locally for some reason
[16:19] <bialix> error message misleading then
[16:19] <bialix> it tells about locking index file. not the repo itself
[16:21] <jam> it is a bug, people shouldn't get that sort of error
[16:21] <vila> morning jam !
[16:21] <jam> The error could probably be clearer, not sure if it is worth tracking it all down
[16:21] <jam> hi vila
[16:22] <goneri> Hi, who should I contact to get a review of the patch done to fix 'Bug #347729: git-bzr doesn't work'
[16:22] <jam> goneri: jelmer is the maintainer of bzr-git, last I checked
[16:23] <james_w> git-bzr, not bzr-git :-)
[16:23] <bialix> if this bug about fastimport you need Ian Clatworthy, igc
[16:23] <bialix> he's sleeping right now
[16:23] <goneri> james_w: I know but It's broken by bzr-fastimport
[16:23] <bialix> AU timezone
[16:24] <goneri> bialix: ok good to know. thanks
[16:30] <vila> jam: you haven't submitted 1.19-kg-merge-sort yet right ?
[16:32] <jam> vila: afaik it is 1.19-known-graph-sorted and no, it hasn't been submitted yet
[16:32] <vila> jam: yeah, typed it from memory, I knew you recognize it :-)
[16:33] <vila> It seems to come along nicely...
[16:36] <jam> vila: I'm at ~3x faster for merge_sort
[16:36] <jam> it doesn't change the algorithm at all, though
[16:37] <jam> I at least feel that I have a better understanding of the algorithm now
[16:38] <vila> Well, I wanted to work on it too, but you fired first :-D I'm ready to review though
[16:38] <jam> vila: well, review this one first, then :)
[16:38] <jam> https://code.edge.launchpad.net/~jameinel/bzr/2.0b1-merge-sort/+merge/10253
[16:40] <jam> vila: so the current open questions for me are
[16:40] <jam> 1) Am I exposing it in a reasonable manner (VF.get_known_graph_ancestry())
[16:40] <jam> 2) Should merge_sort handle ghosts internally or not
[16:41] <jam> (i think it should, since it removes a lot of the _strip_NULL_parents calls)
[16:41] <vila> 2) yes
[16:41] <jam> 3) Should bzrlib.tsort.merge_sort be a thunk over to KnownGraph(parent_map).merge_sort()
[16:41] <vila> 1) sounds ok to me (that was your last commit right ?)
[16:41] <jam> 4) Should KnownGraph.__init__() check for graph cycles
[16:41] <jam> vila: 1) last-ish
[16:41] <jam> (rather than merge_sort and topo_sort doing it now)
[16:42] <vila> 3) for backward compatibility, but my feeling is that we should deprecate bzrlib.tsort
[16:42] <jam> for (3) it would basically mean moving the current tsort implementations into KnownGraph.py and then changing the tsort.py functions to import graph, etc.
[16:43] <jam> 5) KnownGraph.topo_sort() == 10ms, KnownGraph.merge_sort() == 50-60ms, can I get that down any further?
[16:43] <glyph> exarkun: hi
[16:43] <exarkun> glyph: Hi
[16:43] <exarkun> I am having trouble getting revisions that glyph is committing.
[16:43] <jam> (like not allocating extra info per record, but instead hanging it off of the original KnownGraphNode object.)
[16:44] <vila> 4) hmm, if they can appear, there should be a cheap way to check, so yes
[16:44] <glyph> exarkun: so, the revisions are there.  the file in question does exist in my homedir on charm.
[16:44] <jam> vila: right now, if gdfo = None after processing, we know we have a cycle
[16:44] <jam> it just means another pass across the data
[16:44] <jam> or something along those lines
[16:44] <glyph> (why did this have to happen only with the *one* highly proprietary and sensitive bzr repository I've worked with this year rather than one of the dozens of totally harmless open source ones)
[16:44] <exarkun> glyph: How did the revisions get there?  Did you 'bzr push ...' to charm?
[16:45] <glyph> exarkun: yes.
[16:45] <glyph> from illidan, as it happens
[16:45] <glyph> are you pulling from alastor?
[16:45] <vila> jam: hmm, I'm surprised there is not a simpler way... but that can come later if really needed (i.e. start with the check in one pass, and we found a better place, we'll get rid of the pass)
[16:45] <glyph> wait no
[16:45] <glyph> crap, this is my fault
[16:45] <exarkun> Oh too many hosts
[16:45] <glyph> for some reason 'charm' is an ssh alias for alastor on this machine
[16:45] <jam> vila: well, we can check as we pass over the data already
[16:45] <exarkun> glyph: Wow awesome
[16:45] <jam> the current code pops things out of a dictionary
[16:46] <jam> and notices when what it wants to pop isn't there
[16:46] <jam> but
[16:46] <jam> 1) doesn't handle ghosts
[16:46] <jam> 2) takes time to build that dict, and pop everything out of it
[16:46] <exarkun> okay got it
[16:46] <jam> I'm down to around 4microseconds per node
[16:46] <jam> which sounds great
[16:46] <glyph> sorry everybody, bzr's great, no bugs
[16:46] <jam> but still means it is 1.0s to merge_sort the OOo graph
[16:47] <jam> though at 10s to load it, I'm probably in the right ballpark
[16:47] <vila> jam: my feeling is that a two passes algo should be possible,
[16:47] <vila> if loading still dominate, don't bother optimize the algo :-D
[16:48] <vila> jam: two passes, not counting building the graph !
[16:48] <jam> vila: 2 passes for merge_sort?
[16:48] <jam> it is 1 two depth-first traverse
[16:49] <jam> 1 to pop that back out and number
[16:49] <jam> 1 to reverse it for display
[16:49] <jam> (as it stands now)
[16:49] <jam> (1 *to* depth-first trav)
[16:49] <jam> oh, and convert _MergeSortNodes into merge_sort tuples
[16:51] <vila> jam: ok, I haven't look at how it works in detail right now, if it's already 2 passes, then good. I'm not sure the reversing counts as a pass though, if it is, it may be worth avoiding it
[16:53] <jam> vila: it costs 10-15 ms out of 55 ms of processing
[16:53] <jam> though there is some more actual processing going on there
[16:53] <jam> which I'm trying to factor out
[16:53] <jam> well, move to a different place at least
[16:55] <vila> jam: by the way, about revno 4627, don't worry too much about the layering yet, my feeling is that at one point we'll have a node_index and from there we'll be able to have dedicated arrays for specific processing
[17:44] <OllieR> Hey I am having a problem adding a directory. It doesn't look to be ignored so I don't see why it won't add... http://stikked.com/view/88043329 - my bash session
[17:48] <OllieR> ah so interesting the files/ dir was ignored in .bzrignore in a previous revision http://stikked.com/view/60255181
[17:48] <OllieR> since then I have removed that rule but it is as if that has cached somewhere
[17:49] <OllieR> abyone seen something like this before?
[17:51] <luks> well, if you want to know more information use bzr add -v
[17:51] <luks> but if you just want to add the directory, add it manually
[17:54] <OllieR> luks - http://stikked.com/view/20119491 so I added it and it doesn't give me any errors but still shows as unknown with a status
[17:56] <luks> what does "bzr add -v" say?
[17:56] <luks> but I don't know what could be the issue
[17:57] <OllieR> ignored config/site.php matching "config/site.php"
[17:57] <OllieR> which is fine as that corresponds with my .bzrignore rule
[17:58] <OllieR> this is truly weird. Not seen anything like this before
[18:03] <luks> my guess would be that there is something wrong with the checkout, so I'd make a new checkout to see if it works there
[18:12] <OllieR> doh the files/ dir was a different checkout!
[20:26] <lifeless> moinmoin
[20:29] <vila> Good morning lifeless:)
[20:53] <lifeless> 4 new failures since I last ran full test run
[20:55] <beuno> wooo
[20:55] <beuno> go 2.0, go!
[20:56] <vila> lifeless: merge trunk and use --parallel=fork again :-)
[21:05] <gsuveg> re
[21:08] <awmcclain> What's the command I should run to update my repository (which I created around 1.08 or somesuch)?
[21:09] <jderose> awmcclain: bzr upgrade --<format>
[21:09] <jderose> awmcclain: e.g., bzr upgrade --1.9
[21:09] <lifeless> awmcclain: is bzr telling you to ?
[21:10] <awmcclain> lifeless: No, it's not, but it's been quite slow branching and doing everything.
[21:11] <lifeless> awmcclain: we have a bug open at the moment about an apparent performance regression
[21:11] <lifeless> I suggest you file one yourself
[21:11] <awmcclain> lifeless: Oh... this isn't a regression. This is more like I haven't seen any speed increases since I've started using bzr.
[21:12] <lifeless> ah
[21:12] <awmcclain> What's the newest repository format?
[21:12] <awmcclain> --19?
[21:12] <lifeless> what does bzr info -v report for the repository you have?
[21:12] <awmcclain> 1.9
[21:12] <awmcclain> Format:
[21:12] <awmcclain>        control: Meta directory format 1
[21:12] <awmcclain>     repository: Packs containing knits with rich root support
[21:16] <awmcclain> so....should I upgrade?
[21:17] <beuno> awmcclain, upgrade --2a should give you give significant performance improvments
[21:17] <lifeless> what bzr version do you have?
[21:17] <lifeless> awmcclain: ^
[21:17] <awmcclain> 1.18a
[21:17] <awmcclain> 1.18rc1, sorry
[21:17] <lifeless> awmcclain: yes, switching to --2a would be sensible. There are docs on doing this on the web
[21:17] <lifeless> awmcclain: please do follow the upgrade guide ;)
[21:17] <awmcclain> lifeless: Great! Will do.
[21:43] <awmcclain> Hrm... my bzr status is borked. (Haven't run the upgrade yet). here's the traceback: http://dpaste.com/81857/
[21:44] <lifeless> try --no-plugins
[21:44] <awmcclain> a ha...
[21:45] <LarstiQ> weird traceback though
[21:46] <lifeless> awmcclain: if that works, try upgrading your plugins, or something
[21:47] <awmcclain> lifeless: It was the xmloutput plugin, which was nearly 18 months old
[21:47] <awmcclain> I don't even need it anymore
[21:47] <awmcclain> Thank you!
[22:01] <Noldorin> hi lifeless
[22:01] <lifeless> hi Noldorin
[22:01] <Noldorin> thought i might try to prgoress a bit more with my FTP issue now
[22:01] <Noldorin> while i have some time
[22:01] <lifeless> cool
[22:02] <Noldorin> i got your last message...but wasn't quite clear on a few things
[22:02] <lifeless> spiv: :( you broke my testsuite
	there is a function in that file that the lock object uses to check that its in the right place on disk and has the right nonce
[22:03] <Noldorin> i'll be glad to test that now, if you could just clarify things slightly
[22:03] <awmcclain> One thing I'm not sure of after reading http://people.canonical.com/~ianc/doc/en/upgrade-guide/#data-migration, I have a local shared repository containing a bound "trunk" branch to a remote server (which also has a shared repo) as well as my local branches. Do I need to update the repo on the remote server before I update my local repo?
[22:04] <lifeless> Noldorin: self.confirm()
[22:04] <lifeless> put that after the self.transport.rename()
[22:04] <Noldorin> right
[22:04] <lifeless> in normal operation that will raise
[22:04] <lifeless> with your symptoms it may not raised
[22:04] <Noldorin> i see
[22:05] <lifeless> awmcclain: no, you can upgrade them independently
[22:05] <lifeless> the server will need bzr 1.16 (1.18 preferred) though
[22:05] <lifeless> Noldorin: so you probably need a try:except:else: around the confirm
[22:05] <lifeless> with the else clause being the 'ftp breakage is occuring code path'
[22:06] <Noldorin> hrmm...we're not still talking about __init__.py here?
[22:06] <lifeless> never were
[22:06] <lifeless> lockdir.py
[22:06] <Noldorin> oh sorry
[22:06] <Noldorin> i missed that bit
[22:07] <Noldorin> we were messing with __init__.py at first
[22:07] <Noldorin> a while ago
[22:08] <Noldorin> lifeless: in the _attempt_lock function i presume?
[22:09] <lifeless> Noldorin: unlock()
[22:09] <lifeless> Noldorin: locking works fine, its unlocking that is failing
[22:09] <lifeless> lock appears to fail because the unlock isn't working
[22:09] <Noldorin> ok, got it
[22:14] <Noldorin> lifeless: http://pastebin.ca/1533028
[22:14] <Noldorin> does that look right to you?
[22:15] <lesshaste> hi glyph, are you about?
[22:15] <glyph> lesshaste: what's up?
[22:15] <lesshaste> glyph, something boring I am afraid..it's about python
[22:15] <lesshaste> I understand you are the founder.. can I pm you?
[22:15] <lesshaste> I mean #python
[22:17] <lifeless> Noldorin: you have some tabs
[22:17] <lifeless> just use spaces (python limitation)
[22:17] <lifeless> the except needs to be
[22:17] <lifeless> except LockBroken:
[22:17] <lifeless>     pass
[22:17] <lifeless> else:
[22:17] <lifeless>    print "ftp breakage"
[22:17] <Noldorin> ok
[22:17] <Noldorin> got it
[22:18] <Noldorin> thanks. i can read python, but no more really :)
[22:22] <Noldorin> lifeless: http://pastebin.ca/1533033
[22:22] <Noldorin> ftp breakage indeed
[22:23] <lifeless> right, we're detecting it
[22:23] <lifeless> I'd add that patch to the bug
[22:23] <Noldorin> :)
[22:23] <lifeless> its also now at the point you might be able to show your FTP server admins
[22:23] <lifeless> we can continue hunting for a work around
[22:23] <lifeless> perhaps a while loop
[22:23] <Noldorin> ok sure
[22:24] <Noldorin> hmm, so what exactly is the FTP server doing wrong?
[22:24] <lifeless> its not renaming the directory.
[22:24] <lifeless> but its not erroring either
[22:25] <Noldorin> (this is IIS6 btw, so i'm not sure how much they could do, short of changing the server software)
[22:25] <Noldorin> hmm
[22:25] <Noldorin> due to the fact the OS is locking it, you think?
[22:25] <lifeless> something :P
[22:26] <Noldorin> heh
[22:26] <Noldorin> shall we test this manually perhaps?
[22:26] <Noldorin> (is there any way to do so?)
[22:26] <lifeless> with an ftp client perhaps
[22:26] <Noldorin> yep, i have filezilla or windows explorer at hand
[22:26] <lifeless> doing the same operations by hand
[22:29] <Noldorin> lifeless: so just renaming the /branch/lock/held dir to something arbitrary?
[22:30] <lifeless> yes, with a file in that dir called info, and with the sort of text we put in our info files
[22:31] <Noldorin> ok
[22:32] <Noldorin> Status:	Renaming '/httpdocs/repos/texdotnet/.bzr/repository/lock/held' to '/httpdocs/repos/texdotnet/.bzr/repository/lock/held-temp'
[22:32] <Noldorin> Command:	RNFR held
[22:32] <Noldorin> Response:	350 File exists, ready for destination name
[22:32] <Noldorin> Command:	RNTO held-temp
[22:32] <Noldorin> Response:	250 RNTO command successful
[22:32] <Noldorin> lifeless: no problems there :S
[22:33] <lifeless> Noldorin: you don't know that
[22:33] <lifeless> does held still exit
[22:33] <lifeless> *exist*
[22:33] <lifeless> I suspect you need the whole set of operations to trigger it
[22:33] <Noldorin> hrmm i see
[22:34] <lifeless> if simply renaming was broken all the time, it would never be able to work
[22:34] <Noldorin> but if i'll really need to tell my ftp server admin the entier set of steps...
[22:34] <Noldorin> if they're to reproduce it
[22:34] <lifeless> 'bzr init' :)
[22:34] <lifeless> with your build
[22:34] <Noldorin> lifeless: i tested this on the repo i just pushed btw
[22:34] <Noldorin> lol
[22:34] <lifeless> if you run with -Dtransport
[22:34] <lifeless> then you can see the FTP commands
[22:34] <Noldorin> i'm not sure i'm paying them enough for that :)
[22:34] <Noldorin> ok
[22:34] <lifeless> and make a script to match
[22:34] <lifeless> we could also automate that using bzrlib
[22:35] <Noldorin> ok, sounds like a plan
[22:37] <Noldorin> lifeless: http://pastebin.ca/1533056
[22:39] <Noldorin> lifeless: anything interesting in there?
[22:40] <lifeless> Noldorin: if thats the commands bzr is doing, not for me
[22:40] <lifeless> we know whats going on - bzr is doing a rename, server is saying it has but not doing it
[22:40] <Noldorin> yeah
[22:40] <lifeless> there are two main things to do:
[22:40] <lifeless>  - get the server environment fixed, now that we have bzr able to report on it being broken
[22:41] <lifeless>  - get an optional flag to make bzr retry the rename some number of times, which you can use to workaround the problem
[22:42] <Noldorin> right, so if i wrap the rename command in a loop with a 1 second delay, then test that...?
[22:42] <lifeless> for instance, yes
[22:45] <Noldorin> lifeless: say i loop 10 times, and exit the loop when self.confirm succeeds, will that be the right thing to try?
[22:45] <lifeless> sure
[22:46] <lifeless> for pos in range(10):
[22:46] <lifeless>     rename
[22:46] <lifeless>     try:
[22:46] <lifeless>         self.confirm
[22:46] <lifeless>     except LockBroken:
[22:46] <lifeless>         break
[22:46] <lifeless>     else:
[22:46] <lifeless>     print "ftp breakage"
[22:46] <Noldorin> heh, cheers :)
[22:46] <lifeless> hmm, indent the print more
[22:46] <Noldorin> yep, noticed
[22:48] <Noldorin> ho hum
[22:48]  * Noldorin crosses fingers..
[22:51] <Noldorin> hrmm
[22:51] <Noldorin> ftp breakage
[22:51] <Noldorin> bzr: ERROR: Parent directory of ftp://alexreg-repos@213.175.198.12/texdotnet doe
[22:51] <Noldorin> s not exist.
[22:51] <Noldorin> lifeless: strangeness..
[22:51] <lifeless> heh
[22:52] <jam> lifeless: do you know if poolie is back around?
[22:52] <Noldorin> now i'm baffled...
[22:54] <lifeless> jam: I don't, sorry.
[22:54] <lifeless> jam: hugh got in last night, so if poolie left on the same day he should be around today
[22:55] <Noldorin> lifeless: http://pastebin.ca/1533085 - sorry for more code review, but can you spot any issue there?
[22:56] <Noldorin> or perhaps explain the error otherwise?
[22:56] <lifeless> that looks accurate
[22:57] <lifeless> I have to assueme that other error is either a) unrelated or b) part of the same server environment issue ;)
[22:57] <Noldorin> yeah, that was my conclusion
[22:57] <Noldorin> (well, there really isn't any other)
[22:57] <jam> lifeless: k. poolie and I usually have a weekly call ~ now, and I was just wondering if he was going to show up this week
[22:58] <Noldorin> lifeless: brb 20 mins. let me know if the reason strikes you :)
[22:59] <lifeless> jam: You can ring me if you need to talk to someone ;)
[22:59] <jam> lifeless: thanks.
[22:59] <jam> No specific need
[22:59] <jam> just trying to keep in a weekly habit
[23:00] <lifeless> I have 2a default w/no test failures
[23:00] <jam>  \o/
[23:00] <Noldorin> lifeless: otherwise, i'm just going to have to send my build over to my web host admin and hope they bother checking into it :P
[23:00] <lifeless> Noldorin: try pushing again
[23:00] <lifeless> does this new error repeat?
[23:00] <Noldorin> yes
[23:01] <lifeless> if so, pastebin a -Dtranspot trace of it
[23:03] <Noldorin> lifeless: http://pastebin.ca/1533089
[23:04] <Noldorin> interesting. it seems like the unlock is succeeding now (?)
[23:05] <Noldorin> brb
[23:07] <lifeless> looks like
[23:07] <lifeless> rename
[23:07] <lifeless> check
[23:07] <lifeless> rename again
[23:08] <lifeless> then a traceback
[23:09] <lifeless> can you run with BZR_PDB=1
[23:11] <jam> lifeless: I'm probably going offline now. If you see poolie he can call my house or cell
[23:15] <lifeless> jam: ok. gnight
[23:19] <thumper> ImportError: cannot import name weave
[23:19] <thumper> ?!?
[23:20] <thumper> nm
[23:21] <thumper> it was probably my update updating bzr while I was pulling :)
[23:22] <lifeless> thumper: yes
[23:22] <thumper> is there a bzrtools that works with bzr.dev?
[23:31] <Noldorin> back
[23:32] <Noldorin> lifeless: no luck still
[23:34] <Noldorin> :S
[23:36] <lifeless> try http://pastebin.ca/1533125
[23:38] <Noldorin> will do
[23:43] <igc> morning
[23:49] <Noldorin> bzr: ERROR: At ftp://alexreg-repos@213.175.198.12/texdotnet you have a valid .bz
[23:49] <Noldorin> r control directory, but not a branch or repository. This is an unsupported conf
[23:49] <Noldorin> iguration. Please move the target directory out of the way and try again.
[23:49] <Noldorin> lifeless: isn't that lovely?
[23:49] <lifeless> Noldorin: did you delete the texdotnet dir first?
[23:49] <lifeless> and check it was actually gone ?
[23:49] <Noldorin> yeah
[23:50] <lifeless> !
[23:50] <Noldorin> hrmm
[23:50] <Noldorin> works now
[23:50] <Noldorin> well i say works but...
[23:50] <Noldorin> back to thsi again:
[23:50] <Noldorin> ftp breakage
[23:51] <Noldorin> bzr: ERROR: Parent directory of ftp://alexreg-repos@213.175.198.12/texdotnet doe
[23:51] <Noldorin> s not exist.
[23:51] <Noldorin> no "past unlock step"
[23:52] <lifeless> ok, some exception is being raised
[23:53] <Noldorin> mm
[23:54] <lifeless> http://pastebin.ca/1533138
[23:55] <Noldorin> heh, i like this way of resolving bugs :)
[23:57] <Noldorin> it's tedious, though methodical at least
[23:57] <lifeless> james_w: hi
[23:57] <Noldorin> ftp breakage
[23:57] <Noldorin> fail:  No such file: '/texdotnet/.bzr/branch-lock/held': : unable to rename to '
[23:57] <Noldorin> /texdotnet/.bzr/branch-lock/releasing.1db1o9w8i4g6wxax077u.tmp': 550 /texdotnet/
[23:57] <Noldorin> .bzr/branch-lock/held: The system cannot find the file specified.
[23:57] <Noldorin> bzr: ERROR: Parent directory of ftp://alexreg-repos@213.175.198.12/texdotnet doe
[23:57] <Noldorin> s not exist.
[23:57] <lifeless> Noldorin: fun!
[23:57] <lifeless> so we rename
[23:57] <Noldorin> yep
[23:57] <lifeless> but the rename hasn't taken effect (because we read back)
[23:57] <lifeless> then, when we try to rename again, its been moved
[23:57] <james_w> hey lifeless
[23:57] <Noldorin> yep
[23:57] <lifeless> james_w: the .so
[23:57] <Noldorin> makes sense
[23:58] <lifeless> james_w: the .so's in the wrong place, what corrects that for the debs - or did you manually work around?
[23:58] <james_w> sorry, I think I'm lacking context
[23:58] <james_w> the bzr pyrex speedups?
[23:59] <Noldorin> lifeless: anything further to test?
[23:59] <lifeless> james_w: yeah, on karmic setup.py puts them in bzrlib/bzrlib/*.so
[23:59] <lifeless> there was a bug filed on the nightly debs
[23:59] <james_w> I missed the bug
[23:59] <lifeless> And I thought you closed that; we still have a bug in the core about it too (the deb bug being that the dailies should fail to build if the .so's are not there)