[00:10] <ronny> sup
[00:10] <ronny> is there any simple way to get a git diff between 2 bzr revision trees
[00:17]  * ronny pokes lifeless 
[00:18] <lifeless> sorry, no
[00:18] <lifeless> not that I know of anyway; bzr-git might have something
[00:19] <ronny> i dont think bzr-git will need it
[00:20] <jelmer> ronny: what is a git diff?
[00:21] <jelmer> ronny: there's some initial work there in "bzr send --format=git" to behave like git format-patch
[00:21] <jelmer> is that what you mean?
[00:22] <ronny> jelmer: i want to get git style diffs betwen 2 revisions (ie the extra lines with rename/add/remove metadata), i never used gits format-patch
[00:26] <wgrant> 'bzr diff' gives me that information.
[00:26] <ronny> wgrant: not in the same format as git
[00:26] <ronny> directory renames are more concise tho
[00:38] <cellofellow> where might I find the bzrlib.plugins.stats module? I'm assuming it's a plugin? Trying to install bzr-gtk from trunk and it says it needs that module.
[00:40] <james_w> cellofellow: the bzr-stats plugin
[00:40] <cellofellow> oh, duh
[00:40] <cellofellow> :)
[00:43] <verterok> lifeless: fwiw, looks like there is a eclipse package >= 3.4 in karmic :O
[00:44] <lifeless> I'm running karmic...
[00:44] <verterok> lifeless: https://edge.launchpad.net/ubuntu/karmic/+source/eclipse
[00:44] <lifeless> oh, this is interesting..
[00:45] <lifeless> Version: 3.4.1-0ubuntu2 yeah
[00:45] <verterok> lifeless: it's still old, but not "years" old
[00:46] <lifeless> I was seeing..
[00:46] <lifeless> Version: 3.2.2-5ubuntu3
[00:46] <lifeless> must been new in the archive ;)
[00:47] <lifeless> I haven't updated for a week I think
[00:49]  * verterok --> dinner
[01:58] <cellofellow> bzr-gtk nautilus plugin is very slow. :(
[01:58] <cellofellow> s/plugin/extension/
[02:09] <JoaoJoao> howdy
[07:02] <poolie> igc1: hi?
[07:03] <fullermd> poolie: Aaron's away until after 1.18 is intended to be released, right?
[07:03] <poolie> i think so
[07:06] <fullermd> 'k.
[07:13] <fullermd> Oh, rolled over another ten million on launchpadlibrarian.  Neat.
[10:03] <alexharrington> Hi everyone. Does someone have a few minutes to help me with upgrading repository formats? I'm working on the Xibo project, which is developed cross-platform, and we keep having issues with line endings getting mixed up. I've upgraded to 1.17 and written a rules file, but I'm not sure how I go about upgrading the whole project (in Launchpad) and associated branches to use the new format.
[10:03] <alexharrington> I converted one over, and it shows Branch Working Format 5, but when I then branch from that it comes up as format 4?
[10:10] <alexharrington> I guess what I'm asking is do I have to upgrade the stable/development trunks first, then my branches? Or can I do stuff in any order? And what is it that causes future branches to use the newer format?
[11:19] <AfC> alexharrington: asking here never hurts, but if you don't get an answer I'd recommend mailing their list.
[11:19] <alexharrington> yeah - I'm posting on Launchpad Answers now - see if I get any joy there
[11:19] <alexharrington> thanks
[12:04] <AfC> alexharrington: actually, I said Bazaar's mailing list.
[12:04] <james_w> answers is fine
[13:26] <Noldorin> hello. could anyone please tell me the file in the source in which unlocking is done?
[13:26] <Noldorin> (including the rename to unlock)
[13:44] <LarstiQ> Noldorin: bzrlib/lockdir.py ?
[13:44] <LarstiQ> Noldorin: combined with .unlock() on branch/repository/tre
[16:08] <Proteuskor> I have a quick question about permissions after an initial branch. If I do the branch locally. bzr branch <dir1> <dir2> the umask is honored
[16:09] <Proteuskor> however if I do it using the bzr+ssh method bzr branch <dir1> bzr+ssh://user@host/path it doesnt honos the umask
[16:09] <Proteuskor> s/honos/honor
[16:09] <Proteuskor> so I have to manually chmod -R g+r /path on the server for every created branch :(
[16:12] <Proteuskor> chmod -R g+w rather...
[16:15] <Proteuskor> has no one here ever tried to have a multi-user bazaar server using the bzr+ssh method?
[16:27] <Proteuskor> well, adding os.umask(002) right after the if __name__ == '__main__': might be a nasty hack but it works for now... bzr should really fix the bzr_ssh method to honor the umask as set in /etc/profile... perhaps its not running the shell in login mode so /etc/profile isn't being executed. This won't work for multi-user environments...
[16:28] <vila> Proteuskor: please report a bug and your work around, no everybody will read the IRC logs...
[16:29] <Proteuskor> I wonder if its a misconfig of my system still :) thats why I was asking here first
[16:29] <Proteuskor> could be my strange ssh server (I use dropbear because of its reduced memory footprint)
[16:29] <vila> oooh, is that you that plays with tiny servers ? :-D
[16:30] <vila> s/that/who/ oops
[16:30] <Proteuskor> indeed
[16:30] <vila> hmm, well, at least, instead of your "nasty hack" (your words :) you can just define a wrapper and set BZR_REMOTE_SSH
[16:31] <vila> err, BZR_REMOTE_PATH (see bzr help env-variables)
[16:31] <Proteuskor> ok, let me look into that real quick :)
[16:32] <vila> that way you eon't have to patch bzr every time (if it's due to your config)
[16:32] <Proteuskor> ya, I like that idea better, thank you
[16:32] <Proteuskor> although I'm not yet sure how to get my windows users to tickle that setting via the tortoise GUI
[16:33] <vila> and remember that BZR_REMOTE_PATH can also be set in config files (don't remember the config variable name though)
[16:33] <vila> lol, messages crossed on the wire
[16:33] <Proteuskor> ok, I can prolly just distribute a config file to all of the users then :D
[16:34] <Proteuskor> I am actually new to bzr, I used to use perforce, just because thats what the company was using when I joined
[16:34] <Proteuskor> comming up the learning curve now
[16:34] <vila> hehe, the pleasure is in learning a little bit every day :-D
[16:39] <Proteuskor> i think the real fix is to get the ssh transport to use login mode so /etc/profile is processed before calling the specified server. That way the systems configured umask is honored... but there may be a reason they didnt want to use login mode. If the comment at the top of transport/ssh.py is right I could email robey pointer and just ask. I dun want to file a bug if there is a good reason for the current behaviour
[16:40] <vila> Proteuskor: robey doesn't work on bzr these days, you'd better file a bug, you'll get a far better tracking of the issue, really
[16:40] <Proteuskor> ok
[16:43] <AirBender> Hello guys
[16:44] <AirBender> is there a way to override make AC_PACKAGE_VERSION in autoconf reflect the current revno in a bzr branch?
[16:44] <AirBender> to make*
[16:47] <vila> AirBender: hacking around: bzr version-info --custom --template "{revno}"
[16:49] <AirBender> vila: yeap, but do you know the procedure to make AC_PACKAGE_VERSION read a file with the revno, or execute this bzr command to get the number?
[16:49] <vila> I know nothing about autoconf except using it :)
[16:50] <AirBender> because in AC_INIT I can't put a macro I think...
[16:50] <AirBender> me too lol
[16:51] <AirBender> but I'm pretty sure there's a simple way to do this... I don't like to change manually the revno every time in configure.ac
[16:53] <vila> Did you ask Google? :-)
[16:53] <weigon> http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#in-development has two bzr 1.18 releases
[16:54] <vila> weigon: the more the merrier !!
[16:55] <weigon> please add at least a 3rd :)
[16:56] <AirBender> vila: yes I have, but may be I'm searching in the wrong way...
[16:59] <vila> well, most of the time yo found in the last place you search so... keep digging :)
[19:36] <johnjosephbachir> is there any way to have access control with `bzr serve` ?
[20:05] <jfroy> is there a known bug with 2a and patch files?
[20:05] <jfroy> I just tried to apply a merge bundle someone sent me, and bzr died with AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'
[20:07] <jfroy> mmm actually no
[20:07] <jfroy> the branch has the problem
[20:07] <jfroy> it dies with the same error when doing bzr check
[20:18] <jfroy> so I branched the bad branch with 1.18rc
[20:18] <jfroy> and the new branch looks ok (according to check)
[20:19] <jfroy> however now the merge command is failing with "bzr: ERROR: Bad bzr revision-bundle: "Can't convert to target format"  "
[20:19] <jfroy> whatever the hell that means
[20:25] <denys> johnjosephbachir: not at present, but I just started working on it
[20:26] <johnjosephbachir> denys: cool. so it seems like the only read/write hosting solution with access control that doesn't require making OS users is webdav, yeah?
[20:28] <denys> johnjosephbachir: and ssh to some extent
[20:47] <fullermd> No, you could use the smart server over HTTP.
[20:47] <fullermd> (and of course over ssh doesn't necessarily require system users, since you can putz with how sshd authenticates)
[21:01] <teolicy> Hi. I'm a git user. A few months ago I wanted to contribute to a project using bzr, and installed some old version of bzr (maybe 1.6?). Today I updated my bzr to 1.18rc1, because I want to contribute to a different project.
[21:02] <bialix> that's ok
[21:02] <teolicy> After the upgrade, upon running bzr status in the repository I branched, I get an uncaught TypeError. I read a bit and found this bug to match what happened to me: https://bugs.launchpad.net/bzr/+bug/334202
[21:03] <teolicy> The workaround works and indeed I have bzr-loom 1.4dev in the output of bzr plugins.
[21:03] <teolicy> The question is: I'm not sure how to remove the plugin altogether, and, more importantly, since I'm not well versed in bzr I don't know if bzr-loom is a very important and often used plugin or not.
[21:03] <teolicy> Recommendations?
[21:03] <bialix> run `bzr plugins -v`
[21:04] <bialix> it will tell you where plugin located
[21:04] <teolicy> And I just rm -fr it?
[21:04] <bialix> go there and delete loom directory
[21:04] <bialix> yep
[21:04] <teolicy> Excellent, very nice.
[21:04] <bialix> bzr-loom provided special workflow, so in most cases you don't need it
[21:05] <teolicy> And indeed bzr works now.
[21:05] <teolicy> OKie, thanks a bunch.
[21:05] <bialix> :-)
[21:05] <teolicy> You know what, while I'm here, another question.
[21:05] <bialix> shoot
[21:06] <teolicy> I might have my terminology a bit git-ish, I hope you'll understand me. The feature I probably like best in git is 'git rebase -i'.
[21:06] <bialix> -i means interactive?
[21:06] <teolicy> After doing a series of local commits on my repo, and before I 'pushed' the changes to the upstream repo, I can see my local changes, edit them, edit their commit messages, reorder them, squash them into one commit, etc, etc.
[21:06] <teolicy> Yep.
[21:06] <teolicy> Is there something similar to play with in bzr?
[21:07] <bialix> no, there is rebase but it has no -i
[21:07] <teolicy> OK, never mind. I'll do without for now.
[21:07] <teolicy> Thanks again, see you around bialix.
[21:07] <bialix> np
[21:20] <denys> fullermd: is usage of the bzr server over http mentioned/described/explained somewhere?
[21:34] <awilkins> denys: Windows or Linux?
[21:37] <denys> awilkins: access control, you mean?
[21:38] <awilkins> HTTP server
[21:38] <denys> awilkins: linux
[23:22] <sinelaw> help! on windows, bzr add on a specific subdir fails with ERROR: "blabla..."  is not a working copy
[23:24] <Noldorin> lifeless: ping?
[23:24] <Noldorin> sorry to bother you again :)
[23:30] <sinelaw> crap. bzr does that because the subdir is versioned by .svn
[23:30] <sinelaw> but who cares!
[23:31] <sinelaw> did I ask bzr to give a damn about svn?
[23:31] <sinelaw> the error is very confusing.
[23:32] <wgrant> sinelaw: Do you maybe have bzr-svn installed?