| === ubot5` is now known as ubot5 | ||
| 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:28 |
|---|---|---|
| lifeless | bzr commit path [path...] | 03:30 |
| 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:31 |
| SoftwareExplorer | abentley: Cool, another toy to try :) | 03:32 |
| vila | hi all | 07:33 |
| 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:17 |
| mgz | morning | 09:39 |
| === RickCogley_ is now known as RickCogley | ||
| quicksilver | mgz: aha, I just said something to you before you logged on :) | 10:05 |
| wgz | ah, but I have it in the buffer here | 10:11 |
| wgz | glad that worked, but we really do need a proper way of doing that | 10:12 |
| wgz | enough people run into it that they shouldn't all need to do their own hacks. | 10:13 |
| 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:25 |
| 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:26 |
| 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:27 | |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:41 |
| * quicksilver inverstiages installing qbzr | 10:43 | |
| === RickCogley_ is now known as RickCogley | ||
| * quicksilver is in a maze of twisty branches all alike | 10:50 | |
| vila | quicksilver: that's where 'bzr qlog trunk branch1 branch2 branch3' really helps | 10:55 |
| 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:58 |
| vila | criss-cross merges are generally just a warning, unless you encounter bad merge results, you can probably just ignore them | 10:59 |
| 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:00 |
| * quicksilver nods | 11:01 | |
| quicksilver | quite bad conflicts | 11:01 |
| vila | legit or spurious ? | 11:02 |
| quicksilver | I thought I might be able to improve things by unpicking | 11:02 |
| quicksilver | looks like the same change applied independently in A and B in some cases | 11:05 |
| 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. | 11:18 |
| quicksilver | bzr: ERROR: Unable to determine your name | 12:05 |
| 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:06 |
| mgz | ...it should really find the same config file | 12:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| quicksilver | would be nice to set whoami for a whole shared repo rather than one branch at a time | 12:17 |
| mgz | yup. | 12:18 |
| mgz | you can set a sensible global value though. | 12:18 |
| mgz | having a mix of different identities for different projects on the same machine is currently somewhat painful though | 12:19 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| mgz | thanks bot! | 12:31 |
| antonh | isn't it possible to perform a write lock on the file and let other processes have read access to the file? | 12:33 |
| 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:34 |
| antonh | okay, so there is only one kind of lock at the moment. and that lock covers up for both read and write | 12:35 |
| 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:36 |
| 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:37 |
| antonh | yeah | 12:38 |
| antonh | if it was written in C i might have looked at it right away | 12:38 |
| 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:39 |
| 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:40 |
| antonh | i guess your solution is the easiest quicksilver | 12:41 |
| antonh | actually it isn't 'bzr status' i want to do, it's 'bzr diff' but i think you realised that :) | 12:42 |
| 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:44 |
| antonh | oh cool | 12:45 |
| kise | Newbie question: In Bazaar, is there any difference between "bzr mv ..." and "bzr rm ...; bzr add ..."? | 12:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| mgz | bash one liner someone? :) | 12:53 |
| kise | I see. Thanks for the suggestion. Will try my hand at Python :) | 12:53 |
| 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:55 |
| mgz | what does switching --after to --auto do in that case? | 12:56 |
| jelmer | kise: yep | 12:56 |
| 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:58 |
| kise | Thank you very much, jelmer and mgz ;) | 12:59 |
| jelmer | it's a bit odd that 'bzr mv --auto' doesn't work thoughj | 12:59 |
| 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:00 |
| 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:01 |
| kise | I see. Thanks anyway! ;) | 13:02 |
| jelmer | kise: if you hit this again, please file a bug | 13:02 |
| kise | Ok | 13:02 |
| quicksilver | vila: qbzr finally installed :) | 14:19 |
| vila | quicksilver: \o/ | 14:19 |
| 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:22 |
| mgz | hue is who, intensity is how recently | 14:23 |
| * quicksilver nods | 14:24 | |
| quicksilver | what would be better, of course, is an emacs mode with the same functionality :) but this is cool. | 14:24 |
| quicksilver | hmm no bzr qmerge --preview | 14:52 |
| mgz | see bug 415232 | 14:55 |
| mgz | or the bug linked from there for more. | 14:56 |
| 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:02 |
| 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:03 |
| 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:04 |
| quicksilver | didn't know that one | 15:07 |
| vila | quicksilver: very handy to revert part of a change | 16:01 |
| 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:09 |
| 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) | 16:10 |
| 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:11 |
| quicksilver | does anyone know offhand if there is a way to turn a revid into a loggerhead URL? | 17:36 |
| quicksilver | /branch-name/changes/34.1.2 is a valid URL for a dotted revision number | 17:37 |
| quicksilver | /branch-name/changes/revid:blah doesn't work though | 17:38 |
| === maxb is now known as Guest79372 | ||
| 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:00 |
| tronhammer | halo? | 18:24 |
| tronhammer | hey I had a general security question | 18:25 |
| 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:26 |
| 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:27 |
| tronhammer | oh, that's supposed to say "comfortable with how*" | 18:30 |
| mgz | tronhammer: I take it you're using https? | 18:34 |
| tronhammer | yeah | 18:34 |
| tronhammer | also, count out c decompilers of coarse, those aren't a concern | 18:35 |
| tronhammer | more issued with lunch time attacks | 18:36 |
| mgz | there are some neater password stores that integrate with some OS things | 18:36 |
| === verterok` is now known as verterok | ||
| mgz | but that depends on you using an OS with one of them | 18:36 |
| === deryck is now known as deryck[lunch] | ||
| tronhammer | hm, that's a good point, could use keyring for lion | 18:36 |
| tronhammer | keychain* | 18:37 |
| mgz | tronhammer: http://www.szakmeister.net/blog/2010/mar/9/bzr-keychain/ | 18:42 |
| tronhammer | awesome, great find! | 18:43 |
| tronhammer | thanks | 18:43 |
| 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:15 |
| 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:19 |
| LarstiQ | hmm | 19:20 |
| LarstiQ | !paste | 19:20 |
| LarstiQ | meh | 19:20 |
| damd|| | i'm attempting to upgrade bzr, but hold on if you have time, thanks! | 19:21 |
| damd|| | here is the log: http://pastebin.com/raw.php?i=nYnKvQeM | 19:25 |
| damd|| | brb | 19:30 |
| === deryck[lunch] is now known as deryck | ||
| LarstiQ | damd: that error seems to come from somewhere underlying bzr (either the ssh provider or the os) | 19:31 |
| 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:32 |
| LarstiQ | damd: do you have a firewall that could cause this maybe? | 19:33 |
| 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:34 |
| damd | turning off real-time protection in security essentials didn't help either | 19:35 |
| 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:36 |
| damd | i'll try restarting the computer... :P | 19:37 |
| LarstiQ | damd: did that work? | 19:42 |
| damd | haven't tried just yet, hold on | 19:42 |
| damd | i'm afraid it didn't :/ | 19:43 |
| LarstiQ | ok | 19:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 | |
| damd | so did i :P | 19:48 |
| LarstiQ | damd: well, that's a reason :) | 19:49 |
| damd | :) | 19:49 |
| LarstiQ | damd: could you maybe try a different ssh provider? | 19:49 |
| damd | i'm not sure which one that would be, i've only ever used the putty suite | 19:50 |
| 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:51 |
| LarstiQ | yeah | 19:52 |
| 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:53 |
| 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:54 |
| LarstiQ | bah | 19:56 |
| LarstiQ | damd: can you ssh in to rule out any problems with putty? | 19:57 |
| LarstiQ | or well | 19:57 |
| LarstiQ | problems indepedent of bzr | 19:58 |
| LarstiQ | 11 | 19:58 |
| LarstiQ | woops | 19:58 |
| damd | in putty i get "network error: permission denied" | 19:59 |
| LarstiQ | damd: can we get more verbosity from putty? | 20:00 |
| damd | i have no idea to be honest | 20:00 |
| LarstiQ | damd: everything I can dig up keeps pointing at firewalls :/ | 20:04 |
| damd | yeah, thanks a lot for the effort though | 20:06 |
| damd | you've done way more than i hoped for | 20:07 |
| LarstiQ | damd: np. I wish I could solve it | 20:07 |
| damd | luckily it's not that big of a deal | 20:08 |
| LarstiQ | damd: ok then :) | 20:08 |
| === mbarnett` is now known as mbarnett | ||
| LarstiQ | damd: it occurs to me that perhaps it is a roundabout way of saying the equivalent of the openssh "Permission denied (publickey)." | 20:46 |
| Kamping_Kaiser | Hi all. can bzr import{dsc,tar} import only the debian/ directory from a package? | 21:38 |
| 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:22 |
| lifeless | not expected no | 22:23 |
| mathrick | then I'm seeing it do that pretty much every time | 22:23 |
| lifeless | file a bug? | 22:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!