[03:28] <SoftwareExplorer> I'm trying to use bzr to keep track of changes I make to /etc on my Ubuntu system. The problem is that I got a glob of changes that I would like to split in to a few different commits. The nice thing is that the changes that should be in different commits are in different files. Is there a way to do this?
[03:30] <lifeless> bzr commit path [path...]
[03:31] <abentley> SoftwareExplorer: You should also look into using etckeeper for this-- it was designed for maintaining /etc in bzr.
[03:31] <SoftwareExplorer> lifeless: Thanks!
[03:32] <SoftwareExplorer> abentley: Cool, another toy to try :)
[07:33] <vila> hi all
[09:17] <quicksilver> mgz, jelmer: this is what I did in the end:
[09:17] <quicksilver> (cd ../tree-with-toxic-file/; bzr diff -r1384..1385) | patch -p0; bzr commit --author "Original author <author@name>"  -m"$(cd ../tree-with-toxic-file; bzr log -r1385 | grep '^ ')"
[09:17] <quicksilver> repeated multiple times in a shell loop.
[09:17] <quicksilver> fortunately there weren't any merges to worry about, that makes it much worse.
[09:39] <mgz> morning
[10:05] <quicksilver> mgz: aha, I just said something to you before you logged on :)
[10:11] <wgz> ah, but I have it in the buffer here
[10:12] <wgz> glad that worked, but we really do need a proper way of doing that
[10:13] <wgz> enough people run into it that they shouldn't all need to do their own hacks.
[10:25] <quicksilver> wgz: yeah. also, for the record, my hack is wrong because it doesn't account for added files.
[10:25] <quicksilver> wgz: I should have added "bzr add $(bzr unknowns)" to each step
[10:26] <vila> quicksilver: not to mention renames...
[10:26] <quicksilver> wgz: and most importantly, my method totally fails to record merges correctly. I've done that before and it was a lot more hard work. Our local wiki (where I work) has a long page on how you might fix this kind of stuff
[10:26] <quicksilver> with various approachs which don't work.
[10:26] <quicksilver> bzr fast-export and bzr rebase are listed as two of the ones which apparently don't work :)
[10:27] <quicksilver> vila: yes indeed. renames like merges.
[10:27] <quicksilver> fortunately this was a fairly short piece of history and it was mostly just changes. I was just pleased to preserve the commit messages and atomicity.
[10:27]  * vila nods and agrees with wgz about better supporting that kind of operations
[10:28] <quicksilver> ok, reading my notes from last time
[10:28] <quicksilver> last time I used 'bzr replay'
[10:28] <quicksilver> that's pretty much the same as the diff/patch thing but better.
[10:28] <quicksilver> and for merges I used shelve.
[10:28] <quicksilver> (taht is, uncommit, shelve, manually copy shelf to dest tree, unshelve)
[10:29] <vila> +1 on moving shelves from one tree to another (with some care for the needed revisions)
[10:29] <quicksilver> but shelve only worked for simple merges
[10:29] <quicksilver> it failed on a fiddly one with multiple conflicts and renames and stuff
[10:29] <quicksilver> and I never worked out *why* it failed
[10:30] <quicksilver> fortunately I was able to work around that by, essentially, manually redoing that merge from the revid involved, which wasn't a "toxic" revid so it was OK.
[10:30] <vila> worth a bug report if you can reproduce but shelving a merge... won't track the merged parent I think (which may be an acceptable limitation)
[10:31] <quicksilver> vila: I wrote a pretty detailed post about it to the list last time
[10:31] <quicksilver> it was mostly warnocked. Too much to digest, I fear.
[10:31] <vila> yeah, I was about to mention this rang a bell
[10:32] <quicksilver> you helped me last time, yes
[10:32] <vila> yeah, and bug reports are better to track middle/long terms issues, posting to the mailing list is still valuable  though, thanks for that
[10:32] <quicksilver> https://lists.ubuntu.com/archives/bazaar/2010q1/066738.html
[10:32] <quicksilver> the problem was I didn't understand bzr well enough to be clear what a useful bug report was
[10:32] <quicksilver> I tried to explain in enough detail for other people to understand
[10:35] <vila> yup, the issue is also that you were using 2.0.3 and some of the things you refer to sound like bugs that were fixed in later version so it was a bit hard to split that into proper bugs
[10:35] <quicksilver> understood
[10:36] <quicksilver> I appreciate the difficulties and I've love to be more helpful but I always hit these problems when I'm on tight release schedules myself :(
[10:36] <vila> some memory issues have been solved, there is now a add.maximum_file_size config option (defaulting to 20MB) which may have avoid the issue entirely
[10:36] <quicksilver> I'm now using 2.1.0
[10:36] <quicksilver> what should I be using?
[10:36] <wgz> 2.4.2 would be nice.
[10:37] <wgz> but the core issues you highlight in that post are still relevent.
[10:37] <vila> 2.4 at least, 2.5b6 has just been made available and is the last beta before 2.5 becomes the new stable
[10:38] <quicksilver> I have a conservative tendency not to upgrade core tools if they aren't broken.
[10:38] <quicksilver> and now I have a criss-cross merge and I don't know why :-(
[10:41] <quicksilver> how can I track down where the criss-cross is and break this merge down more sensibly?
[10:41] <wgz> qlog makes pretties
[10:43]  * quicksilver inverstiages installing qbzr
[10:50]  * quicksilver is in a maze of twisty branches all alike
[10:55] <vila> quicksilver: that's where 'bzr qlog trunk branch1 branch2 branch3' really helps
[10:58] <quicksilver> if I have a criss-cross trying to merge A and B then each of A and B must have independently merged C, right?
[10:58] <quicksilver> and the solution is to go via C
[10:58] <quicksilver> if I can locate C.
[10:59] <vila> criss-cross merges are generally just a warning, unless you encounter bad merge results, you can probably just ignore them
[11:00] <vila> and if you encounter bad merge results, fixing them once is also generally enough
[11:00] <vila> if you do encounter them frequently, you may want to investigate your workflow though
[11:01]  * quicksilver nods
[11:01] <quicksilver> quite bad conflicts
[11:02] <vila> legit or spurious ?
[11:02] <quicksilver> I thought I might be able to improve things by unpicking
[11:05] <quicksilver> looks like the same change applied independently in A and B in some cases
[11:18] <quicksilver> vila: I was mostly intellectually curious as to how we'd got into this situation and if I could simplify the conflicts by unpicking. It's probably a rabbit-hole I should avoid.
[12:05] <quicksilver> bzr: ERROR: Unable to determine your name
[12:06] <quicksilver> eh? how could bzr suddenly forget my name?
[12:06] <quicksilver> where is this normally stored?
[12:06] <quicksilver> ah, the bzr version upgrade must have lost it
[12:07] <mgz> ...it should really find the same config file
[12:08] <quicksilver> upgraded from 2.1.0 to 2.4.2
[12:08] <mgz> if you run `bzr version` and `bzr config` it should have the same location and contents before and after (probably a bit late to check now)
[12:08] <quicksilver> Bazaar configuration: /Users/jules/.bazaar
[12:09] <quicksilver> that directory is empty except for my ignore file
[12:09] <jml> hey
[12:09] <jml> I was talking with a git user the other day
[12:09] <jml> and the way they described interactive commit (incl. diff hunk splitting) sounded really nice
[12:10] <jml> Does bzr have a diff hunk splitting thingy?
[12:10] <jml> And does it have an interactive commit? (I use shelve a lot)
[12:10] <quicksilver> shelve splits by hunks
[12:10] <quicksilver> you know that if you use it :)
[12:10] <jml> quicksilver: really?
[12:10] <mgz> hm. and do you have an existing file in %APPDATA%/bazaar/2.0/ instead?
[12:10] <quicksilver> I thought it did
[12:11] <mgz> you can hit 'e' in shelve if you have an editor configured
[12:11] <jml> quicksilver: as in, can you take an existing hunk and split that up with shelve?
[12:11] <mgz> it's like, the least discoverable thing ever.
[12:11] <jml> mgz: interesting, will try that out.
[12:12] <quicksilver> mgz: there are a couple of places that %APPDATA% might resolve to on a Mac. I'm poking around.
[12:12] <mgz> I think it needs to actually be as in `bzr config editor=` rather than just EDITOR=
[12:12] <mgz> quicksilver: whoops, mistook that for win 7 for some reason
[12:12] <mgz> the osx logic shouldn't have changed
[12:13] <mgz> it's bascially BZR_HOME or ~/.bazaar
[12:13] <mgz> so, if you had config in your home dir before bazaar should still see it
[12:13] <quicksilver> this is peculiar
[12:13] <quicksilver> I set up bzr about 7 years ago, I don't remember how I told it who I was :)
[12:14] <quicksilver> probably just by typing bzr whoami without worrying about it
[12:14] <quicksilver> although I can't remember if I made som eeffort to distinguish work repos from non-work repos
[12:14] <mgz> yeah, or maybe it just worked?
[12:14] <mgz> I'd be suprised if you had no config at all though
[12:14] <mgz> newer bzrs are a little stricter about how they get your identity
[12:15] <quicksilver> ah you know what, I never did set it up I think
[12:15] <quicksilver> old commits show my user ID as jules@machine-name.localdomain
[12:15] <quicksilver> not with a real email
[12:16] <mgz> ah, yes, that's what the newer versions are trying to avoid
[12:16] <quicksilver> never bothered me personally since it was obviously me
[12:16] <quicksilver> but I can see people would prefer a real email address
[12:17] <quicksilver> would be nice to set whoami for a whole shared repo rather than one branch at a time
[12:18] <mgz> yup.
[12:18] <mgz> you can set a sensible global value though.
[12:19] <mgz> having a mix of different identities for different projects on the same machine is currently somewhat painful though
[12:23] <quicksilver> I've been compiling since vila convinced me to try qlog at 10:55
[12:23] <quicksilver> it's still working on Qt
[12:23] <quicksilver> I hate source distribution :P
[12:24] <mgz> eheh, surely there's an easier way to get qt there?
[12:24] <mgz> you're using a platform where you're not expected to do things for yourself.
[12:25] <quicksilver> mgz: dunno. I usually find macports is the best way to get open source software
[12:25] <quicksilver> apparently 'brew' is the new kid on the block.
[12:25] <quicksilver> but they both compile from source.
[12:25] <mgz> why not just run gentoo in a vm...
[12:26] <quicksilver> not sure that solves the source problem :)
[12:26] <mgz> seems like a masochistic approach
[12:26] <mgz> but I guess trying to do free software packaging on a mac means that's the kind of people they are
[12:27] <antonh> i am doing 'bzr commit' and my editor is launched. i am about to write a commit message and dont remember what i did so i open another terminal and type bzr status too see what i actually did
[12:27] <antonh> then bzr complains about bzr: ERROR: Could not acquire lock "/path/to/file"
[12:27] <quicksilver> yeah.
[12:28] <quicksilver> that's why the default commit messages reminds you what has changed at the bottom?
[12:28] <mgz> antonh: bug 98836
[12:28] <mgz> ...bot?
[12:29] <antonh> quicksilver, yes only what files has changed, it gives no info about the diff
[12:29] <mgz> at any rate, that's a known issue with one bit of bzr, but it's not an easy change
[12:29] <quicksilver> antonh: yes. I now have the habit to always run diff first, and then commit.
[12:29] <quicksilver> C-x V = and then C-x V c
[12:30] <quicksilver> then I can compose my commit message browsing the diff in the other window
[12:30] <quicksilver> mgz: I'll be your bot! https://bugs.launchpad.net/bzr/+bug/98836
[12:31] <mgz> thanks bot!
[12:33] <antonh> isn't it possible to perform a write lock on the file and let other processes have read access to the file?
[12:34] <antonh> isn't 'bzr status' a read-only operation?
[12:34] <quicksilver> not portably using the simplistic OS locks bzr is currently using
[12:34] <quicksilver> logically some way of differentiating read and write locks would go some way to solving the problem
[12:35] <antonh> okay, so there is only one kind of lock at the moment. and that lock covers up for both read and write
[12:36] <mgz> antonh: read the bug for the messy details, but basically the fancy stat cache can need updating whenever it looks at the tree
[12:36] <mgz> which is why it needs write access
[12:37] <mgz> so, entering the commit messsage shouldn't hold a lock, and st shouldn't really need to write lock, but that's how things work currently
[12:38] <antonh> yeah
[12:38] <antonh> if it was written in C i might have looked at it right away
[12:39] <mgz> it's really an issue with the design of dirstate, rather than something that's just a code problem, hence why it's stuck around as a problem
[12:40] <quicksilver> well I think you could scrap the lcok on starting commit couldn't you?
[12:40] <quicksilver> or collect the message first, at least
[12:41] <antonh> i guess your solution is the easiest quicksilver
[12:42] <antonh> actually it isn't 'bzr status' i want to do, it's 'bzr diff' but i think you realised that :)
[12:44] <mgz> antonh: the easy thing for you to do is just `bzr alias ci="commit -p"` or similar
[12:44] <mgz> so you always have the diff
[12:45] <antonh> oh cool
[12:47] <kise> Newbie question: In Bazaar, is there any difference between "bzr mv ..." and "bzr rm ...; bzr add ..."?
[12:49] <jelmer> kise: yes, that would add a completely new file
[12:49] <jelmer> kise: if you 'bzr rm', then 'bzr add' you can use 'bzr mv --auto' to make it detect renames
[12:50] <kise> jelmer: Thanks. Ok, then let me explain a problem I have.
[12:50] <kise> I had a folder named "extra" with many subfolders and did the following:
[12:50] <kise> 1) I rearranged rearranged them manually into "extra/cpp" and "extra/python".
[12:50] <kise> 2)"bzr add"
[12:50] <kise> Now Bazaar shows all the subfolders as "removed" and then "added".
[12:50] <kise> I thought it would be better if they appeared as "moved" but don't know how to do it.
[12:50] <kise> "bzr mv --auto" does not detect anything.
[12:50] <kise> Any suggestions?
[12:51] <jelmer> kise: hmm, are there more changes to the files than just their move?
[12:51] <kise> No
[12:51] <jelmer> I'm not sure why 'bzr mv --auto' doesn't work then
[12:51] <mgz> `bzr mv --after` will let you fix up stuff now
[12:52] <kise> jelmer: 'bzr mv --after' means I have to do it for every subfolder I moved manually?
[12:52] <jelmer> kise: yes
[12:52] <mgz> if there are hundreds that might be annoying, but if you didn't also rename the dirs it's amienable to scripting
[12:53] <mgz> bash one liner someone? :)
[12:53] <kise> I see. Thanks for the suggestion. Will try my hand at Python :)
[12:55] <kise> Sorry, a related question. While trying to use the "--after" switch I found this:
[12:55] <kise> bzr mv xtra/unused-cpp xtra/cpp/unused-cpp --after
[12:55] <kise> bzr: ERROR: Could not move to unused-cpp: xtra/cpp/unused-cpp is not versioned.
[12:55] <kise> Do I need to add first all directories with "add --no-recurse"?
[12:56] <mgz> what does switching --after to --auto do in that case?
[12:56] <jelmer> kise: yep
[12:58] <kise> Uhm, I see. Anyway tried switching --after to --auto and bzr complained:
[12:58] <kise> $ bzr mv xtra/unused-cpp xtra/cpp/unused-cpp --auto
[12:58] <kise> bzr: ERROR: Only one path may be specified to --auto.
[12:58] <kise> Seems like I will have to do it through scripting.
[12:59] <kise> Thank you very much, jelmer and mgz ;)
[12:59] <jelmer> it's a bit odd that 'bzr mv --auto' doesn't work thoughj
[13:00] <kise> It has happened to me several times. T_T I don't know why either. I use Bazaar 2.4.
[13:00] <kise> Never anyone had this experience?
[13:01] <jelmer> kise: 'bzr mv --auto' seems to work fine for me
[13:01] <jelmer> kise: I don't use it often though, usually I just use 'bzr mv' when I move files
[13:02] <kise> I see. Thanks anyway! ;)
[13:02] <jelmer> kise: if you hit this again, please file a bug
[13:02] <kise> Ok
[14:19] <quicksilver> vila: qbzr finally installed :)
[14:19] <vila> quicksilver: \o/
[14:22] <quicksilver> you know I hate GUI tools
[14:22] <quicksilver> but I can see some neat things here
[14:22] <quicksilver> what are the colours in qblame? "freshness" of the change?
[14:23] <mgz> hue is who, intensity is how recently
[14:24]  * quicksilver nods
[14:24] <quicksilver> what would be better, of course, is an emacs mode with the same functionality :) but this is cool.
[14:52] <quicksilver> hmm no bzr qmerge --preview
[14:55] <mgz> see bug 415232
[14:56] <mgz> or the bug linked from there for more.
[15:02] <vila> quicksilver: AIUI emacs provides something (but we had feature requests to make it faster)
[15:02] <vila> quicksilver: the default vc mode is where this is defined (IIRC)
[15:03] <quicksilver> vila: well I use dvc for quite a lot but it doesn't have sepcific support for merge --preview
[15:03] <quicksilver> vila: however it's simple enough to do M-! bzr merge --preview ../other-branch
[15:03] <vila> err, sorry, I thought you were talking about annotate
[15:03] <quicksilver> vila: and then M-x diff-mode in that buffer
[15:03] <vila> yup
[15:03] <vila> I use that Heavily
[15:04] <quicksilver> bonus points for C-x C-q to put it in read-only mode
[15:04] <quicksilver> which makes the keybindings more useful.
[15:04] <vila> hmm
[15:04] <vila> but that means C-c C-s (split-hunk) does not work anymore ?
[15:07] <quicksilver> didn't know that one
[16:01] <vila> quicksilver: very handy to revert part of a change
[16:09] <quicksilver> vila: yes I must admit I generally do that by hand
[16:09] <quicksilver> vila: and then re-check the diff to see I did it right.
[16:10] <vila> Yeah, I did that before I discover it, I never looked back ;) Of course it works for *applying* part of a change too (if you M-x cd to the right directory)
[17:11] <quicksilver> http://search.cpan.org/dist/VCI/ looks interesting
[17:11] <quicksilver> but I can't see that it's data model knows what a 'merge' is.
[17:11] <quicksilver> although it mostly supports VCSes which understand merging.
[17:36] <quicksilver> does anyone know offhand if there is a way to turn a revid into a loggerhead URL?
[17:37] <quicksilver> /branch-name/changes/34.1.2 is a valid URL for a dotted revision number
[17:38] <quicksilver> /branch-name/changes/revid:blah doesn't work though
[18:00] <quicksilver> ah well it turns out we're using a version of loggerhead which has a bug on that kind of URL anyway
[18:00] <quicksilver> c'est la vie
[18:24] <tronhammer> halo?
[18:25] <tronhammer> hey I had a general security question
[18:26] <tronhammer> I don't feel comfortable with out bzr stores my password in plaintext, so I modified the bzrlib/transport/http/_urllib2_wrappers.py :: get_user_password to grab the password from a file on the system
[18:27] <tronhammer> the file I made is a c program that when executed, checks the md5 of the bzrlib/transport/http/_urllib2_wrappers.pyc file, and if it matches the one that was given at the creation of the file, it prints out the password
[18:27] <tronhammer> does anyone see anything glaringly wrong with this approach?
[18:30] <tronhammer> oh, that's supposed to say "comfortable with how*"
[18:34] <mgz> tronhammer: I take it you're using https?
[18:34] <tronhammer> yeah
[18:35] <tronhammer> also, count out c decompilers of coarse, those aren't a concern
[18:36] <tronhammer> more issued with lunch time attacks
[18:36] <mgz> there are some neater password stores that integrate with some OS things
[18:36] <mgz> but that depends on you using an OS with one of them
[18:36] <tronhammer> hm, that's a good point, could use keyring for lion
[18:37] <tronhammer> keychain*
[18:42] <mgz> tronhammer: http://www.szakmeister.net/blog/2010/mar/9/bzr-keychain/
[18:43] <tronhammer> awesome, great find!
[18:43] <tronhammer> thanks
[19:15] <damd||> d:\repos\emacs-trunk>bzr pull
[19:15] <damd||> Using saved parent location: bzr+ssh://damd@bzr.savannah.gnu.org/emacs/trunk/
[19:15] <damd||> bzr: ERROR: Unable to connect to SSH host bzr.savannah.gnu.org; [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions
[19:15] <damd||> how do i fix this? :|
[19:19] <LarstiQ> damd||: can you pastebin the corresponding traceback from .bzr.log? `bzr --version` will tell you where to find the log file
[19:19] <LarstiQ> !pastebin
[19:20] <LarstiQ> hmm
[19:20] <LarstiQ> !paste
[19:20] <LarstiQ> meh
[19:21] <damd||> i'm attempting to upgrade bzr, but hold on if you have time, thanks!
[19:25] <damd||> here is the log: http://pastebin.com/raw.php?i=nYnKvQeM
[19:30] <damd||> brb
[19:31] <LarstiQ> damd: that error seems to come from somewhere underlying bzr (either the ssh provider or the os)
[19:32] <LarstiQ> damd: googling for the "An attempt ..." bit comes up with some hits
[19:32] <damd> yeah, i figured... i'm using pageant to serve the keys, i'm just guessing that bzr knows that i want plink to take care of SSH
[19:32] <LarstiQ> damd: yeah
[19:33] <LarstiQ> damd: do you have a firewall that could cause this maybe?
[19:34] <damd> no, i don't have a firewall, unless "microsoft security essentials" provides one
[19:34] <LarstiQ> damd: it does afaik (or builtin to windows itself)
[19:34] <damd> apparently i had the windows default firewall turned on, but turning it off didn't help
[19:35] <damd> turning off real-time protection in security essentials didn't help either
[19:36] <LarstiQ> damd: the other thing that comes up in google hits is that something else is already using the port the application tries to bind to
[19:36] <LarstiQ> but that doesn't make much sense in this case
[19:37] <damd> i'll try restarting the computer... :P
[19:42] <LarstiQ> damd: did that work?
[19:42] <damd> haven't tried just yet, hold on
[19:43] <damd> i'm afraid it didn't :/
[19:43] <LarstiQ> ok
[19:44] <damd> it's really weird, because it worked the last time i tried it, which was a few months ago
[19:44] <damd> i really haven't touched bzr since
[19:44] <LarstiQ> damd: right, might not be bzr itself that changed though
[19:45] <damd> you're right
[19:45] <LarstiQ> damd: you mentioned you tried to upgrade it now?
[19:45] <damd> yeah, i uninstalled bzr 2.3.1 (if i recall correctly) and installed the current 2.3.x stable
[19:45] <damd> 2.3.4 i think it was
[19:45] <damd> i used the standalone installer
[19:46] <LarstiQ> damd: not that I think it would solve it, but any reason not to use 2.4? (Or a 2.5 beta if you want to try that)
[19:47] <damd> when i tried to start the 2.4 stable installer, nothing happened, when i tried to start it from total commander, total commander just hanged
[19:47]  * LarstiQ blinks
[19:48] <damd> so did i :P
[19:49] <LarstiQ> damd: well, that's a reason :)
[19:49] <damd> :)
[19:49] <LarstiQ> damd: could you maybe try a different ssh provider?
[19:50] <damd> i'm not sure which one that would be, i've only ever used the putty suite
[19:51] <LarstiQ> paramiko is bundled with the standalone bzr installer I believe
[19:51]  * LarstiQ looks up how to tell bzr to use it
[19:51] <damd> my first guess would be BZR_SSH
[19:52] <LarstiQ> yeah
[19:53] <LarstiQ> maybe we should just try BZR_SSH=paramiko instead of me reading the code
[19:53] <LarstiQ> right, 'paramiko' or 'none'
[19:53] <damd> i can't find paramiko on my system
[19:53] <LarstiQ> brb
[19:54] <LarstiQ> damd: it's a python implementation, would be in with the bzr executable afaik
[19:54] <damd> oh
[19:54] <damd> well, same error
[19:54] <damd> d:\repos\emacs>set BZR_SSH
[19:54] <damd> BZR_SSH=paramiko
[19:56] <LarstiQ> bah
[19:57] <LarstiQ> damd: can you ssh in to rule out any problems with putty?
[19:57] <LarstiQ> or well
[19:58] <LarstiQ> problems indepedent of bzr
[19:58] <LarstiQ> 11
[19:58] <LarstiQ> woops
[19:59] <damd> in putty i get "network error: permission denied"
[20:00] <LarstiQ> damd: can we get more verbosity from putty?
[20:00] <damd> i have no idea to be honest
[20:04] <LarstiQ> damd: everything I can dig up keeps pointing at firewalls :/
[20:06] <damd> yeah, thanks a lot for the effort though
[20:07] <damd> you've done way more than i hoped for
[20:07] <LarstiQ> damd: np. I wish I could solve it
[20:08] <damd> luckily it's not that big of a deal
[20:08] <LarstiQ> damd: ok then :)
[20:46] <LarstiQ> damd: it occurs to me that perhaps it is a roundabout way of saying the equivalent of the openssh "Permission denied (publickey)."
[21:38] <Kamping_Kaiser> Hi all. can bzr import{dsc,tar} import only the debian/ directory from a package?
[22:22] <mathrick> hmm, is it normal that I see bzr 2.5b leaving locks all over the place when I Ctrl+C it?
[22:22] <mathrick> win32 here
[22:23] <lifeless> not expected no
[22:23] <mathrick> then I'm seeing it do that pretty much every time
[22:25] <lifeless> file a bug?