=== fta_ is now known as fta === jamesh_ is now known as jamesh [00:41] jelmer, duck branches :p [00:42] good work btw [00:43] hi pygi :-) [00:43] Thanks :-) [00:44] pygi: Duck branches ? What does the duck refer to? [00:45] jelmer, It can swim on water, and it can walk on ground. Users who don't use the plugin see only one branch, and others can see the whole thing :P [00:46] bzr duck create [00:46] bzr duck remove [00:47] bzr duck [branch] (switches to branch) [00:47] bzr duck (lists branches) [00:47] so obviously, argument to create and remove is [branch] too :) [00:50] o, and bzr duck [branch] asks you if you want to create branch if it doesn't exist [00:50] pygi: :-) I like the name [00:51] jelmer, good, so you'll take it? :p [00:51] we need to make this bzr thingy more fun, perhaps more people will use it then :D [00:51] I'm having a hard time convincing O'Reilly that it's worth to do a book on bzr :( [00:51] pygi: yeah, I think so [00:51] pygi: :-( [00:51] what bit is the problem? Are the other books on VCS not doing well? [00:52] jelmer, actually, they only want to do book on most popular DVCS :/ [00:52] and that is Git ... [00:53] Andy said that if I can show him that every version of bzr gets downloaded 80000 times per version, he might be able to convince his bosses... [00:53] but I can't do that, so :P [00:53] (some other publishers are interested tho ... but O'Reilly is O'Reilly) [00:53] Did you look at ubuntu popcon? [00:54] yup ... [00:54] 20745 downloads of bzr [00:54] 41440 downloads of git-core [00:54] that's 1:2 ratio [00:54] at debian, ratio is 1:6 ... [00:56] a 1:2 ratio isn't that bad, if the downloads are apparently high enough for O'Reilly [00:56] *downloads for git [00:56] I think they have the source tarball download number for git ... [00:56] not sure [00:57] but yes, they're doing git book [00:57] There's more publishers than O'Reilly out there though... [00:57] yup, I know [00:57] already got offer from one, waiting on others [00:57] we were pretty happy with PH when we published the Samba HOWTO [00:57] I don't have any contacts with PH ... [00:58] So far we've got offer from Packt Publishing, and I think we have good chances with Manning [00:58] Pragmatic said they'll contact us in two weeks [00:58] jelmer, if you know someone in PH ... :) [01:00] I can check, but I don't think I do anymore [01:00] my only contact (our editor) has switched jobs since the book was first published [01:01] aha, don't worry then ;) === RAOF__ is now known as RAOF [01:10] nice work jelmer [01:25] so bzr is claiming to be unable to load the paramiko module. Is this a known issue, or how could i diagnose it? (bzr from the repo, paramiko v1.7.4) [01:29] chandler1: does "python -c 'import paramiko'" work nicely? === verterok is now known as verterok_ [02:03] nope [02:04] chandler1, sudo apt-get install python-paramiko then? [02:04] james_w: ImportError: No module named Crypto.Util.randpool [02:04] not on a debian system [02:04] aha ... [02:04] but my package manager says the version is 1.7.4 [02:04] well,whatever the system .. [02:04] hm. [02:07] chadmiller, locate randpool [02:08] chadmiller, tell me what you get [02:08] pygi: was that for me? [02:08] ups, yes chandler1 :) [02:08] and if so, no locate, what area would it be in so i can do a relatively fast find? [02:09] /usr/lib/python2.4/site-packages/Crypto/Util/randpool.py [02:09] and [02:09] /usr/lib/python2.5/site-packages/Crypto/Util/randpool.py [02:10] ahh [02:10] its in 2.4, but not 2.5 [02:10] ok, you're missing symlinks then :) [02:11] sudo dpkg-reconfigure python-crypto would fix that if you were on debianish system :) [02:12] ;] [02:12] i'm on gentoo [02:12] uh xD [02:12] you know how to do symlink manually then I guess :p [02:13] * pygi hides [02:13] chandler1, does it work now? [02:14] pygi: i know about symlinks... =p [02:14] my lack of knowledge centers firmly on python at the moment. =D [02:16] * pygi notes this errors for "Lets troubleshoot" section of the book :p [02:18] hehe [02:19] apparently there is a nifty tool that may help here, python-updated [02:19] python-upder [02:19] :: sigh :: spelling ftl [02:19] can you use bzr to push data from a .bzr directory to an svn vise versa ? [02:20] c0mpub0mb, bzr-svn? [02:20] pygi: do you use bzr-svn ? [02:20] I used to, why? [02:20] pygi: how do i use it ? [02:20] chandler1, that tools seems to be used only in gentoo? [02:21] pygi: yes, its specifically to help moving modules between python versions [02:21] pygi: if it doesn't work, i'll do it manually, or beat on the package manager until its fixed [02:22] c0mpub0mb, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id72 [02:22] this might explain it better then me in a sentence or two :) [02:22] chandler1, oki, please do let me know if it works [02:23] it's being slow, surely its doing something productive. ;] [02:24] :P [02:26] lame, didn't work [02:26] is this part of pycrypto or paramiko? [02:26] pycrypto [02:28] brilliant, i lied, python-updater worked perfectly [02:28] =] [02:28] thanks btw, pointed me at the right spot right off the back [02:28] how rude, lying :P [02:29] most welcome [02:29] what do you think of recently introduce local branches plugin btw? [02:29] *cough* duck branches *cough* [02:29] s/introduce/introduced/g [02:31] pygi: does bzr support private repo's with user priviliges ? [02:32] you could do something with ssh keys, sure [02:33] pygi: so it doesn't have the kind of user control as svn ? [02:33] you mean authz file? [02:33] no, it doesn't [02:35] Adam Olsen is working on a nifty tool that would allow you to have something like that [02:36] but you'll still require ssh keys [02:36] pygi: was that aimed at me? and if so, what local branches plugin? [02:37] chandler1, yes, at you :) [02:37] jelmer released a plugin that adds the ability to have git-like branches [02:44] pygi: interesting [02:44] i'll have to read up on it to give a competent opinion [02:44] chandler1, oki, its on mailing list [02:45] ok [02:45] c0mpub0mb, any more questions? [02:49] hi hi fta [02:53] I remember someone in here mentioning to me some tool that allowed me to batch build/upload to different ubuntu releases on launchpad. Did I imagine that? [02:53] autoppa [02:56] Oh, hooray. [02:56] Thank you. === timchen1` is now known as nasloc__ [03:14] bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~gutsy1 is to be installed <----- frowny face. [03:40] awmcclain, yea, hasn't been updated yet === sdboyer|vurk is now known as sdboyer [04:13] bzr-svn should probably be removed from the ppa, at least while the package is not maintained [04:41] jelmer, probably, yes [05:11] is bzr-svn no longer being maintained? [05:11] chandler1: it's quite actively maintained, by jelmer [05:11] ok, was confused, prob just the packaging thats not [05:11] (a statement by jelmer a couple of hours ago) [05:12] The packaging is regular irritant, yeah :( [05:55] * jml hands spiv 0x88 [05:56] * jml takes that back and passes spiv 0x58 [05:56] spiv: use that, or 0x78 [05:57] ok, ok.01011000 [06:24] jml: :) [07:19] hi all [07:26] Ug. I'm sorry if this is OT, but I'm trying to get autoppa to work on the console and it's dying when it asks for my passphrase in order to sign the package (since I don't have Seahorse installed). Anyone know how to pre-cache my passphrase using gpg-agent or something? [09:26] jelmer: I've had some trouble getting the 0.5 branch of bzr-svn to work ; first, the minor change of having to replace the substitute header file includes. After it compiled though, I am getting errors [09:30] http://pastebin.ubuntu.com/76319/ [09:30] It does mystify me slightly why the plugin is doing anything at all when doing `bzr version` [09:33] If your bzr install exists in a branch, "bzr version" will open it up so it can display the basic details. bzr-svn is involved while it's probing to see which format the branch uses. [09:33] Peng_: It's not a branch [09:34] Neither is the plugin [09:34] But that would seem to be the source of the problem [09:38] Meh, it seems to be fetching data from a public SVN repo just fine. Trust me to pick the one command that makes it go "bang" [09:39] Aha, not the only command that makes it go "bang" then [09:39] Same error from a "branch" [09:40] It manages to grab the revision metadata [09:57] jelmer, poke [10:07] Hi ! How can I get information from bzr update which file exactly it gets "bzr: ERROR: [Errno 13] Permission denied" ? [10:09] Patching the source to report it in the traceback or you could use Sysinternals filemon (you seem to be on Windows) [10:10] matkor: Vista or XP? [10:10] linux :) [10:12] If it is a local file, strace can help you. [10:14] E.g. "strace -e trace=file -o strace.log bzr update" and have a look towards the end of strace.log when that finishes. [10:16] There might be a more-to-the-point solution within bzr, though; the strace log will be quite verbose. === fta_ is now known as fta === Bambi_BOFH is now known as Kamping_Kaiser === verterok_ is now known as verterok [11:22] Sod's law says which ever machine I have IRC open on, it will be the wrong one [11:22] Must install an IRC proxy sometime [11:23] Anyways, using bzr shelve in cygwin w/ 1.8 I get "bzr: ERROR: Failed removing shelved changes from theworking (sic) tree!" [11:23] Any ideas? Google did not help me much [11:30] http://pastebin.com/m234d816b [11:31] I wonder what bzr command it's trying to execute at that point? [11:32] VSpike, do you have diffutils installed? [11:34] pygi: I definitely have patch.exe .. let me check exactly [11:35] VSpike, and see if it accepts "--dry-run" [11:35] pygi: yep, I have diffutils, patch and patchutils [11:35] which, bzr shelve? [11:35] no,patch [11:36] pygi: yes it does [11:37] do you have binary files? [11:37] pygi: "bzr shelf list" shows the patches, and "bzr shelf show 00" shows the contents OK [11:37] pygi: these aren't binary files, no [11:41] VSpike, open shelf.py [11:41] lets try something ... [11:41] hm, or rather not [11:41] * pygi thinks [11:42] I'm going to have to do it the manual way I think [11:42] i.e. just copy the current files to a "saved" dir somewhere and revert :) [11:42] VSpike, nah, lets figure it out [11:43] could you paste complete output pls? [11:43] http://rafb.net/paste [11:43] Cos I also realised the changes I need to shelve span a couple of commmits - they are not just in this revision [11:44] But yeah could spend a couple of mins on it to investigate if you like :) [11:45] thanks VSpike :) [11:45] So you want me to bzr shelve the file and paste the complete output? [11:45] yup, obviously :) [11:47] http://rafb.net/p/VOwv1b50.html [11:50] I just created a simple test case and it works [11:50] So it's not universally broken [11:51] but its broken on certain use-cases... [11:52] Wondering what it could be. Doing two files at one? Files not in root? The fact that ~/projects is a symlink? [11:52] VSpike, well, did you try one file? [11:52] try it [11:52] (I know I'm bugging, please bear with me) [11:54] Ah, it appears to be the subdirectory [11:54] I tested a single file, still broken [11:54] I tried navigating to the location without using the symlink, still broken [11:55] Tried shelving a change in the root project folder, it works [11:55] right, so it only allows to shelve what's in the project root... [11:55] that's evil behaviour... [11:56] just testing with my simple test case [11:56] Oh [11:56] Hm [11:57] It works in the test case :) [11:57] vila, what works? [11:58] I created a sub dir, add a file, committed, edited the file, and tried shelving the change [11:58] worked fine [11:58] so hm, whats wrong here ... === jszakmeister is now known as jszakmeister|awa [12:02] VSpike, would you be willing to try a little hack? [12:02] Could it be because they are sometimes unicode files? [12:02] They usually don't contain anything other than a start record [12:02] The rest is normally ascii [12:03] pygi: I was thinking of editing ~/.bazaar/plugins/bzrtools/patch.py to log/dump command line [12:03] VSpike, we pretty much know what the command line is [12:03] pygi: what were you going to suggest? [12:03] editing ~/.bazaar/plugins/bzrtools/shelf.py [12:04] and change: [12:04] if reverse: [12:04] args.append('-R') [12:04] to: [12:04] if reverse: [12:04] args.append('-R -d=yoursubdir') [12:04] ergh [12:04] args.append('-R -d yoursubdir') [12:05] pygi: that code is not in mine [12:06] VSpike, in def _run_patch ? [12:06] It's in patch.py [12:06] ah, ok, patch.py then [12:06] sorry [12:07] yoursubdir is the full path or relative one? [12:07] relative should work [12:08] * pygi is mostly shooting in the dark, never had this problem :p [12:08] Relative from project root I take it? [12:08] I wonder if the code should apply --binary on cygwin? [12:10] VSpike, yup, project root [12:11] VSpike, I'm not sure if that'd had any effect, considering test case does work ... [12:11] but you could try patching sources to do it... [12:15] yeah, that fixes it :) [12:17] VSpike, what, the binary thing, or the "-d" ? [12:18] is there any way to get bzr shelve to show colored diffs? (bzr shelve is a complete revelation by the way - amazingly useful!) [12:19] why is it called shelve1 though? is there a new shelve2 coming? [12:19] thrope: strangely, it does show coloured diffs for me [12:19] pygi: the binary thing [12:19] oh - I saw the no-color option in the help but I don't get colored diffs [12:20] VSpike, could I now convince you to file a bug, and assign me to it? [12:20] Sure. Where do bugs for bzrtools go? [12:21] pygi: the reason my test case worked is possibly because I used cygwin tools to create it [12:21] VSpike, yup, mention all that in a bug :) [12:21] VSpike, https://bugs.edge.launchpad.net/bzrtools [12:21] mario-danic [12:24] thrope, does bzr cdiff works for you? [12:25] pygi: yep, works fine [12:26] thrope, what bzr/bzrtools version? [12:26] bzr 1.9, bzrtools 1.9.1 [12:27] shelve is an alias to shelve1 for me [12:30] yea, its the old shelve .. [12:31] how do I get the new one? [12:31] its in the mainline perhaps? [12:31] not sure [12:33] thrope, sudo apt-get install colordiff? [12:33] but I think you already have that.. [12:34] VSpike, thanks for submitting bug when you do btw ;) [12:34] and thanks for investigating it [12:34] shelve2 is in bzr.dev now I think [12:34] I've seen at least a couple of commits for it [12:35] pygi: done [12:35] Can you check the report contains all you need? [12:35] VSpike, yes, moment pls:) [12:35] #301639 in case your email is slow [12:36] no probs - going to go back to doing what I was doing before :) [12:36] VSpike, have fun ;) [12:37] VSpike, ah, you have bzr 1.8 ... perhaps that's why you still have colored shelve [12:37] VSpike, bug report is perfect, thank you :) [12:38] pygi: yeah, cygwin always seems to lag a version or two [12:38] pygi: yw [12:38] * pygi goes back to sleeping :p [12:38] Not sure why the patch command works without --binary in one direction and not the other [12:39] And also not sure why it passed on another windows generated file when I tested it [12:39] VSpike, this is a pretty safe-failover I'd say, so we don't have to break our heads on it :P [12:40] pygi: agreed, it's the right thing to do anyway, I think [12:40] * pygi nods [12:40] I hate thinking about line endings in cygwin anyway. I just close my eyes and hope it works, mostly [12:40] VSpike, its a pretty rare bug ... [12:40] only two known occurances so far [12:41] probably worth grepping the source for other cases where sys.platform is tested against win32 and not cygwin and checking they are correct [12:42] Oh, while your about it, can you fix the missing space in the error message? :) [12:42] s/your/you're/ [12:42] sure sure [12:42] hehe thx [12:42] * pygi writes that down somewhere [12:44] echo "TODO: fix space in error message" > /dev/null ;) [12:44] :p [12:44] it's the only task manager you need [12:45] my head still serves me, so I'm fine :p [12:48] ok, can I go to sleep now or is there anything else I can help you with? :) [12:50] Nope, sleep away :) Thanks for the help [12:52] no,thank YOU! [12:52] laters [12:55] awww [12:55] awilkins, poke [12:55] awilkins, no, no own implementations of pull/push/whatever [12:56] bzr can only access branches that are url-addressable [12:56] awilkins, we can probably do a workaround for it to work on Win once its more then proof of concept [12:57] awilkins, third, as jelmer said, plan is to move infrastructure for it in core [12:57] awilkins, and what do you have against ducks? :p [13:06] I find they keep acting like a goose! ;) [13:14] pygi: hi [13:14] awilkins: hi [13:18] py23 [13:18] oops :) [13:26] awilkins: still there? [13:35] hi markh :-) [13:36] hi jelmer :) You've been busy :) [13:40] I was a bit disappointed by how little work the local-branches stuff was [13:41] It's less then 200 lines of code, so I regret not writing it earlier [13:41] heh - everything seems so much simpler the more experienced you get at doing it :) [13:46] jelmer: can you create local-branches of remote branches, if you know what I mean? [13:48] pickscrape: not directly [13:50] That would be useful. You could then add a command to allow you to 'pull-all' or similar. [13:51] pickscrape: You'll get that for free once this is all a bit more integrated in the bzr core [13:51] (including pulling of multiple branches) [13:51] sweet :) [14:01] it'll require a new bzrdir format though, so that means upgrading existing bzrdirs [14:28] jelmer: Hi [14:31] awilkins: you were having trouble building 0.5 ? [14:33] jelmer: I had to put back stdbool.h [14:33] (the included one) [14:33] jelmer: After that it builds, but doesn't work for me [14:34] Did you get the trace off the pastebin [14:40] awilkins: We should probably fix the include path instead to use subvertpy [14:42] jelmer: Yes, that would work (pardon my complete C-noobness) [14:43] I tried to learn C when I was a teenager but the lack of cheap textbooks and no internet rather killed that before it started [14:55] awilkins: do you perhaps have subvertpy installed manually as well? [15:06] jelmer: I think I used the script but I had to copy the pyd files manually [15:06] I'll check and see if there is an egg-info [15:14] speaking of jelmer... how much do you know about the FTP spec? It seems our FTP "readv" support is basically just read the whole file and extract the bits we need. [15:15] It might be nice to actually use whatever partial-read support is available from FTP [15:16] jam: Yeah, that seems to be the main downside compared to sftp atm :-( [15:16] which is a rather large one :) [15:18] awilkins: the pyd files should end up in bzrlib.plugins.svn.subvertpy, not in subvertpy at the top-level [15:26] jelmer: Ah, so subvertpy shouldn't be a package on it's own then [15:27] I just tripped an assertion in 0.4 as well [15:27] * awilkins is a pita === jelmer is now known as Guest22036 === Guest22036 is now known as jelmer [16:29] Hi all. How can I find the revision where a file was removed? [16:31] CardinalFang: You have to run the whole log in verbose mode to do so [16:32] You must be the 4th person to ask in here at least [16:32] Someone put it in the FAQ! [16:32] :) I am asking as the proxy for someone else in my org. [16:33] Maybe there are others here. [16:33] * CardinalFang waves! [16:34] I don't suppose "-m FN" will work. [16:37] CardinalFang: I don't think so. It's fairly easy to modify the log command to list the revisions a file participates in if you know it's file-id, but alas, deletion is now one of the ways a file particicpates in a revision due to the way that invent [16:38] ories work [16:38] *not one of the ways [16:38] * CardinalFang writes some sed to print the log. === thekorn_ is now known as thekorn [17:13] hi [17:14] is there any problem in rich-root -- push --> non-rich-root? [17:26] verterok: yes, there is [17:27] LarstiQ: it can be done? or is a one way conversion? [17:27] verterok: can't be done [17:28] jelmer: LarstiQ: thanks a million! [17:30] LarstiQ: While you're here... I'm considering adding /etc/init.d/bzr file to start the readonly smart server [17:30] does that sound sensible? [17:30] jelmer: what will it read from? [17:30] jelmer: And I'd disable starting it by default. [17:31] jelmer: other than that, I'm missing context :) [17:31] LarstiQ: yeah, it would require some variables in /etc/default/bzr [17:32] (directory to share and enable/disable) [17:33] * LarstiQ nods [17:33] jelmer: how about when people want to share multiple directories? SOL? [17:33] They'd just have to add symlinks/bind mounts inside the directory they're sharing [17:33] does that work? :) [17:33] there's only a single namespace anyway [17:34] bind mounts definitely work, not sure about symlinks [17:34] * LarstiQ is thinking of branches symlinked into that namespace, and their repository being outside of it [17:34] I'm rather sure that would break [17:35] yeah, that would definitely break [17:35] hmm, maybe wait till that happens and then note it [17:35] jelmer: what protocols would it be reachable on? [17:35] LarstiQ: just bzr:// [17:35] it'd just run "bzr serve ..." [17:36] hmja [17:37] jelmer: if it's disabled by default, why not [17:39] jelmer: svn-push is the right command to use to push a new branch, right? [17:43] LarstiQ: yep [17:47] jelmer: morning [17:47] jfroy|work: hi [17:49] So my patch has allowed me to bypass the bad properties (which I cannot remove) by globally changing the bzr-svn prefix. That's a hack of course, but the next course of action would be to add a new property, bzr:prefix-override, which could be set on the root directory of an svn branch, which bzr-svn would read first and act accordingly. Or perhaps it would be better to have that as a repository option in subversion.conf for example. [17:56] jelmer: you might need more information for #301763 ? [18:09] * LarstiQ goes home [18:12] LarstiQ: can you perhaps print the variables in that assert? === mw is now known as mw|food [19:09] jelmer: sure [19:23] jelmer: except, I shut down that machien leaving work, and from another machine I don't get the assert (still diverged branches though) [19:23] LarstiQ: any particularly interesting messages in ~/.bzr.log ? [19:25] jelmer: hmm, Guessed repository layout: TrunkLayout(0), guess layout to use: CustomLayout(['branches/spitfire/spitfire5'],[]) maybe [19:25] Bundle Buggy's queue has gotten a bit long. [19:25] jelmer: after that, it's just the DivergedBranches error [19:31] 'pull -d' is awesome [19:31] more commands should support -d though [19:33] yes, they should [19:33] although I'm not sure what `bzr init -d a b` would do [19:34] i think that init and init-repo can probably get away without it [19:35] (i guess init -d a b should create a branch at b/a?) [19:35] um a/b [19:36] I suppose so [19:36] but i don't think it's a good idea :) [19:37] mwhudson: any other commands that should not have a -d? [19:38] LarstiQ: actually, further to init, it's not really clear how it would interact with commands that also take a relpath [19:38] like 'add' [19:38] or 'revert', which is actually what i wanted it for [19:39]