[12:06] <lapthrick> jelmer: it seems that that svn branch of mine got completely botched
[12:07] <lapthrick> bzr missing svn://parent reports entire history to be missing on both sides
[12:10] <lapthrick> that's rather unfortunate, as I will have to re-do the changes I already committed in it
[12:17] <lapthrick> does shelf provide any way to export shelved patches?
[12:17] <LeoNerd> They're just plain .diff files
[12:17] <LeoNerd> Go take a look at e.g.  .shelf/shelves/default/00
[12:17] <lapthrick> LeoNerd: I guess, but I dunno where they live :)
[12:18] <LeoNerd> (I specifically know they're plain patches because they blow up if you rename a file while it wasn't looking)
[12:18] <LeoNerd> (whereas tla/baz "undo" facility works fine)
[12:18] <abentley> lapthrick: but also, depending on why you want that, you may find merge --uncommitted useful.
[12:18] <lapthrick> I want that because an svn branch of mine broke :\
[12:19] <lapthrick> and I'm carrying over the changes to a fresh one
[12:21] <abentley> so if you unshelve and run diff, does it show all your changes?
[12:22] <lapthrick> actually it seems I have no changes shelved in that branch, I got confused
[12:24] <bicchi> Would anyone know if version 0.91 will make it into gutsy?
[12:31] <lapthrick> bah
[12:31] <lapthrick> another error
[12:32] <lapthrick> :(
[12:50] <Peng> Does anyone in the world have bzr+http working?
[12:51] <LeoNerd> I presume for that to work, some sort of (Fast)CGI app is needed
[12:51] <Peng> Yes.
[12:51] <Peng> It's very simple.
[12:51] <Peng> And it doesn't work.
[12:51] <Peng> I want to know if anyone has it working so I can see what I'm doing wrong.
[12:52] <lifeless> Peng: when you say it doesn't work, what happens
[12:53] <Peng> Hold on.
[12:57] <Peng> http://privatepaste.com/44AFaH6wN7
[12:57] <Peng> Eh, oops.
[12:57] <Peng> Anyway
[12:57] <Peng> I meant to obfuscate my email address in that.
[01:03] <lifeless> oh hmm, no browser here at the moment
[01:03] <lifeless> is it long?
[01:03] <lifeless> could you /msg it to me ?
[01:03] <Peng> Eh. Not that long.
[01:03] <Peng> hold on.
[01:04] <Peng> '$ echo hello | POST http://bzr.mattnordhoff.com/bzr/.test/.bzr/smart' returns ok2
[01:04] <Peng> '$ time bzr log bzr+http://bzr.mattnordhoff.com/bzr/.test$ time bzr log bzr+http://bzr.mattnordhoff.com/bzr/.test' says 'bzr: ERROR: Not a branch: "bzr+http://bzr.mattnordhoff.com/bzr/".'
[01:04] <Peng> But with regular http, it works.
[01:04] <Peng> Oops. How did I paste that twice?
[01:04] <Peng> I blame my keyboard!
[01:05] <poolie__> hello
[01:06] <lifeless> Peng: what version of the smart server?
[01:06] <lifeless> Peng: I bet that you are being bitten by the bug where the relpath must match inside and outside apache
[01:06] <lifeless> I don't know if that is fixed or not
[01:07] <Peng> lifeless: 0.91. And that could be it. My homedir is a symlink.
[01:11] <Peng> What, what's the bug, exactly? And what's the workaround?
[01:38] <lifeless> Peng: hi
[01:39] <lifeless> the problemi s that bzr sends in its protocol a path like
[01:39] <lifeless> /foo/bar
[01:39] <lifeless> to a url like
[01:39] <lifeless> http://host/bzr/foo/bar/.bzr/smart
[01:40] <lifeless> and on the server process that is mapped
[01:40] <lifeless> so /bzr/foo/bar might be /home/bzr/~public_html/foo/bar
[01:40] <lifeless> and finally chrooted
[01:40] <lifeless> so '' inside bzr means /home/bzr/~public_html/foo/bar
[01:40] <lifeless> but we sent '/foo/bar'
[01:41] <lifeless> so you actually end up accessing /home/bzr/~public_html/foo/bar/foo/bar
[01:41] <lifeless> which of course, does not exist
[01:41] <igc> morning
[01:41] <lifeless> and we don't know on the client where the chroot point is, s o we cannot do path calculations to send less, sanely.
[01:43] <lifeless> hi igcv
[01:44] <Peng> lifeless: Well, I'm not chrooted.
[01:44] <lifeless> Peng: its a bzr software chroot
[01:44] <Peng> Oh.
[01:44] <lifeless> so that people cannot ask for /etc/passwd
[01:44] <Peng> Yeah.
[01:44] <Peng> Well, what's the workaround?
[01:45] <lifeless> one is to make the duplicated path segments exist
[01:45] <lifeless> in your case, I'm guessing, movig bzr/.test on bzr/.test/bzr/.test
[01:45] <lifeless> just on the server
[01:45] <lifeless> may well work
[01:45] <lifeless> or
[01:46] <lifeless> possibly symlink bzr/.test/bzr/.test to ../..
[01:49] <Peng> Err.
[01:50] <lifeless> how often are workarounds pretty ?
[01:50] <Peng> :(
[01:51] <Peng> So until then, what, bzr+http is completely nonfunctional?
[01:51] <lifeless> it works if your paths line up
[01:51] <lifeless> there is a high severity bug on this
[01:52] <Peng> Oh.
[01:53] <Peng> Does anybody have their paths lined up?
[01:54] <lifeless> yeah, we did when we tested it lol
[02:13] <lifeless> abentley: ping; is there a method to get an inventory delta from two trees/two inventories ?
[02:16] <Peng> Well, I guess the bug 107161 guy got bzr+http to run. So it's not impossible.
[02:16] <ubotu> Launchpad bug 107161 in bzr "http smart server performance is far worse than http alone" [Medium,Incomplete]  https://launchpad.net/bugs/107161
[02:17] <AfC> Actually I never got it to work. Debugging it was too hard.
[02:18] <Peng> Okay, https://bugs.launchpad.net/bzr/+bug/119330/comments/8 has a good explanation of the path issues.
[02:19] <ubotu> Launchpad bug 119330 in bzr "bzr+http mod_python wsgi issues" [Undecided,New] 
[02:21] <Peng> Hey, awesome!
[02:21] <Peng> In /bzr, I added a symlink to . so /bzr/bzr/bzr/bzr ... works.
[02:21] <Peng> Now I get a different error! :)
[02:22] <Peng> AttributeError: 'DisabledTags' object has no attribute 'get_reverse_tag_dict'
[02:22] <lifeless> ok, I think that is fixed in bzr.dev
[02:22] <Peng> Newer than 0.91?
[02:22] <lifeless> yes
[02:22] <Peng> Hey, cool.
[02:23] <Peng> Oh, yes, 2867.
[02:25] <Peng> It sucks that hg can only use a smart server, but at least its smart server works!
[02:41] <abadger1999> hg can use plain http as well... just not very well.
[02:43] <Peng> That's true.
[02:43] <Peng> So, then, I could say in #mercurial, "It sucks that bzr can't use a smart server, but at least its dumb server works!".
[02:44] <abadger1999> heh.  As long as you have your asbestos suit +2 equiped :-)
[02:45] <Peng> Haha.
[02:46] <jelmer> Peng: the smart server is also available over plain tcp/ip or ssh
[02:47] <jelmer> the latter two are better supported than http
[02:49] <Peng> jelmer: I know that. In fact, I use bzr+ssh. I just thought "can't" sounded better. :)
[04:17] <AfC> bzr 0.91 is in Gentoo now, btw
[04:20] <Peng> Hey, no version of bzr is marked as stable. :(
[04:21] <poolie> in where?
[04:21] <Peng> Gentoo.
[04:29] <lifeless> Peng: seems appropriate, it is Gentoo
[04:30] <lifeless> AfC: thanks!
[05:05] <lifeless> igc: hi
[05:05] <lifeless> igc: I think you did two reviews, one I've submitted the other replied to; any chance of some more today ?
[05:06] <igc> Probably ...
[05:06] <igc> I'm flat out putting together a 3 hr tutorial for ODSC today ...
[05:07] <igc> but I'm keen to keep you moving :-) :-)
[05:39] <lifeless> igc: rotfl, sorry, but I've had to just mini rant at you; I couldn't contain myself.
[05:41] <igc> lifeless: hasn't arrived yet. Looking forward to it :-)
[05:42] <lifeless> should be there now ;)
[05:51] <igc> yep :-)
[06:01] <lifeless> igc: :)
[07:40] <abentley> lifeless: I don't think there is a method for that.
[07:48] <lifeless> abentley: I've whipped up a test helper
[07:56] <Gacha> I'm trying to ignore a single file, but it doesnt work - bzr ignore ./top/settings.py
[07:57] <Gacha> when I run bzr ignored the wile isn't there
[07:57] <Gacha> not wile but file
[07:58] <Peng> Gacha: Well, that should work, as long as 'top' is in the root directory of the branch.
[07:59] <Gacha> I know, but it doesn't
[07:59] <Peng> Heh.
[07:59] <Peng> Yeah, "it's supposed to work!" isn't a very useful answer, is it?
[07:59] <lifeless> Gacha: can you cat .bzrignore please
[07:59] <lifeless> I don't have a browser right now; so either paste it here or /msg it to me
[08:00] <Gacha> ./top/settings.py
[08:00] <lifeless> ok
[08:00] <lifeless> next thing is that adds overwrite ignores
[08:00] <lifeless> so try bzr rm --keep top/settings.py
[08:02] <Gacha> but if I want that the settings.py is a part of the project after doing checkout
[08:02] <Gacha> but when doing changes it should ignore them
[08:03] <lifeless> oh
[08:03] <lifeless> this is not what ignores do :)
[08:03] <Gacha> because settings.py can be different
[08:03] <lifeless> ignores are for files you don't want to be part of the project.
[08:04] <lifeless> I can offer a work around; we are discussing on the list at the moment a 'readonly' flag that would probably do what you want; you might want to peek at that discussion thread
[08:04] <lifeless> the workaround is -
[08:04] <lifeless> have a file, 'settings.py.default' or something like that
[08:04] <Gacha> nice idea
[08:05] <lifeless> have your build process - setup.py, or Makefile, can copy that to settings.py IFF settings.py does not exist
[08:06] <Gacha> ok, I will try
[08:06] <lifeless> anyhow, I realise this is not as ideal as having the VCS manage this for you
[08:06] <Gacha> when the readonly feature will be?
[08:07] <lifeless> but, we may be able to manage it directly in the future
[08:07] <lifeless> well, its early days of discussion now
[08:07] <Gacha> ok
[08:07] <lifeless> if you would use this, I encourage you to get involved in the discussion
[08:07] <lifeless> simply because that will give the folk considering how to implement it more input on how you, the user, expect it to work
[08:08] <Gacha> in launchpad?
[08:08] <lifeless> the bazaar mailing list
[08:08] <Gacha> ok
[08:08] <lifeless> there is a link to that from http://bazaar-vcs.org/
[08:15] <poolie> lifeless, still around?
[08:16] <lifeless> yeth
[08:18] <poolie> can i call?
[08:18] <lifeless> bit later would be better
[08:19] <lifeless> say 5 sharp ?
[08:19] <lifeless> sorry, phone is in other room
[08:20] <poolie> np, call whenever you're ready
[08:58] <poolie> lifeless, on phone atm
[08:58] <lifeless> lol
[08:58] <lifeless> well ring me back
[09:04] <siretart> dato: yay. it seems neuro has fixed ball's (the mips buildd) chroot! :)
[09:05] <lifeless> lol, neuro has fixed balls. Quote of the day.
[09:05] <AfC> I was just thinking that that was one of the less comprehensible sentences I had ever seen.
[09:06] <lifeless> poolie: will you be long?
[09:06] <siretart> lifeless: LOL
[09:06] <siretart> I didn't write that! :)
[09:07] <siretart> dato: but this time the sparc buildlog looks fishy :/
[09:07] <lifeless> siretart: you building 0.91 binaries?
[09:08] <siretart> lifeless: http://buildd.debian.org/pkg.cgi?pkg=bzr
[09:08] <lifeless> browser is awol
[09:08] <lifeless> so is that a 'yes' ?
[09:08] <siretart> lifeless: dato has uploaded 0.91-1 to debian yesterday
[09:08] <siretart> so, 'no, not be, but the debian buildd network yes'
[09:09] <siretart> not me, even
[09:09] <lifeless> cool
[09:09] <lifeless> cause I need to do the official builds
[09:09] <lifeless> so his packaging is helpful
[09:09] <lifeless> :)
[09:09] <siretart> lifeless: but the alternative build depends is causing lots of trouble
[09:10] <siretart> After installing, the following source dependencies are still unsatisfied:
[09:10] <siretart> python-celementtree(missing)|python(inst 2.4.4-6 ! >> wanted 2.5)
[09:10] <siretart> Source-dependencies not satisfied; skipping bzr
[09:10] <siretart> that's because some chroots already have the package 'python' installed, which is at version 2.4.4-6 in debian
[09:10] <siretart> so sbuild fails the build here
[09:10] <lifeless> thats an sbuild bug right ?
[09:11] <siretart> in some ways, yes
[09:11] <siretart> but fixing bugs in the official buildds seems nearly impossible, since neuro is unreachable
[09:11] <siretart> at least for me
[09:12] <siretart> well, actually it is a pure sbuild bug. I've mailed neuro and CC'ed our mailing list with an detailed analysis of the problem
[09:12] <siretart> atm, I think the easiest would be to have more strict build dependencies on debian, and carry a small patch for ubuntu's bzr
[09:14] <lifeless> so theres a couple of issues here hmm
[09:14] <lifeless> we should probably build extension modules for multiple pythons
[09:14] <siretart> 'extension modules'?
[09:16] <lifeless> we have C extension modules
[09:16] <siretart> yes
[09:16] <lifeless> they are specific to the python version
[09:16] <lifeless> if you use bzrlib via python2.4, you need a 2.4 version of the module
[09:16] <lifeless> ditto 2.5, 2.6, 3.0
[09:18] <siretart> and what does this mean wrt packaging
[09:27] <lifeless> multiple binary packages, one per python version, I presume, or whatever python-magic we have today
[09:27] <lifeless> but I would expect that to change the source dependencies
[09:27] <james_w> if you use pycentral and have correct build rule then you get one per python available.
[09:27] <james_w> build: $(PYVERS:%=build-python%)
[09:27] <james_w> build-python%:
[09:27] <james_w>         python$* setup.py build
[09:27] <lifeless> so how does tis reconcile with sbuild borking on this dep ?
[09:28] <james_w> then build depend on python-all-dev
[09:28] <lifeless> surely it's going to be pulling in all the different pythond *anywy*
[09:28] <james_w> that's due to cleverness trying to avoid trying to pull in celementree which doesn't exist in Ubuntu, but is required on Debian.
[09:29] <james_w> the method chosen fails if python is already installed as sbuild wont try and remove/upgrade packages to satisfy it.
[09:34] <indraveni> hi all
[09:34] <indraveni> I use subversion, and I am working for a linux distibution
[09:34] <indraveni> and we invite community to work with us on the source,
[09:34] <indraveni> thus we need to maintain the source in a good version control system.
[09:35] <indraveni> and I thought of using subversion
[09:35] <indraveni> BUT
[09:35] <indraveni> I have seen ubuntu is using Bazaar , and our distro is something like ubuntu distro
[09:35] <indraveni> so i want to know what are the advantages of Bazaar
[09:36] <indraveni> and why I should go for Bazaar for maintinaning source for a linus distribution project, which is a huge project
[09:42] <matkor> indraveni: Check if developement model fits bzr style
[09:43] <indraveni> what is bzr style ?
[09:44] <indraveni> matkor, what is bzr style ?
[09:44] <matkor> multibranch, commits for whole tree
[09:45] <matkor> subversion IIRC it is server client (checkout) style
[09:45] <matkor> also check if performance of bzr is enough ...
[09:46] <indraveni> matkor, bzr also, can act as server / client right ?
[09:46] <matkor> indraveni: yes
[09:47] <indraveni> matkor, wnat about security aspects?
[09:47] <indraveni> matkor, how can I authorize some people to rw, and some to onlt read
[09:47] <indraveni> in svn, we can control this though apache athz module
[09:48] <matkor> indraveni: I think it depends on transport used to access remote repository
[09:49] <matkor> I basically use sftp / local (file) transports so I set proper file ACLs
[09:49] <matkor> and use ssh key-based auth
[09:49] <Gacha> how can I export the code from a bazaar banch? When I use export os push command it doesn't copy the full tree
[09:49] <Gacha> I want to export my code to a production enviroment
[09:49] <Gacha> without the .zr specific folders and files
[09:50] <Gacha> I mean, without .bzr files
[09:50] <matkor> Gacha: export code ? What would be wrong with bzr checkout <repo> ?
[09:51] <matkor> Gacha: bzr export    also exists but I never used it
[09:51] <indraveni> matkor, so it cannot be remotely accessed through http protocol ?
[09:51] <Gacha> bzr checkout I can do on the other enviroment, but not from my current
[09:52] <Gacha> to do checkout I need to ssh to the production enviroment and then execute the command
[09:52] <Gacha> but I want to export the data from my local machine to another
[09:53] <spiv> Gacha: "bzr export" can export the current version of the tree to a directory or a zip file.
[09:53] <Gacha> but the dir is empty
[09:53] <Gacha> I found there only .bzr
[09:54] <vila> indraveni: bzr branches can be accessed via http
[09:54] <spiv> Gacha: what command did you run?
[09:54] <spiv> Oh, I misread.
[09:55] <spiv> Gacha: Most people I think just use rsync for that.
[09:56] <spiv> Gacha: you can easily tell rsync to exclude the .bzr directory.
[09:56] <Gacha> I know, but I was thinking maybe there are some special feature for bazaar
[09:56] <Gacha> ok, I will use rsync
[09:56] <spiv> You could use "bzr export" to e.g. a zip file, copy that, and then unzip on the remote machine instead, but I don't think that's any easier.
[09:56] <indraveni> vila, what is the server that it uses ?
[09:56] <Gacha> thats hard
[09:57] <Gacha> I want to execute one command then type password and  done
[09:57] <vila> for read access any http server, for write access you will need a webdav enabled server and the bzr-webdav plugin
[09:58] <Gacha> spiv: thanks for helping
[09:58] <vila> but don't expect good performances with webdav
[09:58] <indraveni> where can i get good document to configure all these ?
[09:58] <indraveni> i am findnig only 10 pages quick tutorial in bzr website
[09:58] <vila> if  you control the server you'd better use bzr serve directly
[09:59] <vila> to publish your branches via http, you just need to have them accessible with whatever access you configure in your web server
[10:00] <vila> for 'bzr serve' more precise answers I think spiv is the right guy :)
[10:01] <indraveni> vila, which web server, can i use for http access ?
[10:01] <vila> indraveni: any http server
[10:03] <indraveni> vila, i need a document for confugirig all these . please suggest a good one
[10:03] <spiv> indraveni: any http server that can serve plain files from the filesystem.
[10:03] <indraveni> spiv, apache is it ok?
[10:04] <spiv> Yep.
[10:04] <indraveni> spiv, , i need a document for confugirig all these . please suggest a good one
[10:04] <spiv> indraveni: a document for configuring apache to serve bzr branches?
[10:05] <indraveni> spiv, yes
[10:06] <spiv> indraveni: there isn't much to configure.  You just use the usual <Directory> or whatever sections; it's just the same as serving static HTML as far as apache is concerned.
[10:07] <indraveni> spiv, if it is html , we place them in /var/www
[10:07] <indraveni> spiv, for bzr where does we place , the repo could be anywhere
[10:08] <spiv> indraveni: right, so say you want to publish at http://host/code/, you could simply place the bzr branches in /var/www/code on the filesystem.
[10:08] <indraveni> spiv, and specicy DocumentRoot /var/www/code ?
[10:08] <indraveni> will this work out ?
[10:08] <spiv> Or if you want to keep the branches elsewhere on the filesystem, you could use symlinks or Alias directives or whatever instead.
[10:09] <indraveni> ok
[10:09] <spiv> I'm not very familiar with apache directives, but there's nothing bzr specific to doing this.
[10:09] <indraveni> spiv, and specicy DocumentRoot /var/www/code ?will work ?
[10:09] <indraveni> ok i will check and let you know
[10:09] <spiv> Probably.  (Like I say, I'm not very good with apache)
[10:10] <indraveni> but i think there should something else, s
[10:10] <spiv> How do you mean?
[10:11] <indraveni> spiv, i willl check and let you know
[10:11] <indraveni> implementation gives more ideas
[10:11] <indraveni> and solutions
[10:12] <spiv> Ok.
[10:19] <lifeless> spiv: you know of jam's 'trigger update' plugin?
[10:20] <poolie> spiv, hi?
[10:22] <spiv> lifeless: the push-and-update one?  yeah.  It doesn't seem like it would help the "I don't want the .bzr directory" case.
[10:23] <spiv> poolie: hello
[10:28] <lifeless> spiv: oh right; but it does help the 'I want the other files' case :)
[10:51] <mrevell> igc: ping
[10:51] <igc> hi mrevell
[10:52] <mrevell> hi igc, could we organise a time for a quick chat some time?
[10:52] <igc> mrevell: sure - how does around 24 hours from now sound?
[10:53] <igc> I'm pretty tired tonight :-(
[10:53] <mrevell> igc: Yeah, no problem. Either that or when you start your Friday?
[10:54] <igc> ok - that's usually around 9am my time
[10:54] <igc> how about I see in you're around ...
[10:54] <igc> and ping you then?
[10:54] <igc> s/see in/see if/
[10:54] <mrevell> igc: Which city are you in? (Just trying to work out what time that'll be for me)
[10:55] <igc> Brisbane GMT+10
[10:55] <poolie> i'm going to call it a night
[10:55] <igc> night poolie
[10:56] <poolie> igc, if you're tired maybe you should go home too
[10:56] <poolie> mentally i mean
[10:56] <mrevell> igc: Oh right, yeah, silly me - that's midnight for me. Okay, could we say 18.00 your time Friday?
[10:56] <igc> dinner is real soon now
[10:57] <igc> mrevell: yes, that's no problem
[10:57] <mrevell> igc: Thanks, I look forward to it :)
[10:57] <igc> cool
[10:58] <lifeless> night poolie
[11:10] <ubotu> New bug: #145511 in bzr "compiled dirstate extension breaks hashcache" [High,In progress]  https://launchpad.net/bugs/145511
[11:13] <lifeless> night all
[11:15] <dato> siretart: cool (re ball's chroot)
[11:16] <dato> siretart: but now we have the same story with sparc
[11:16] <siretart> dato: right
[11:17] <siretart> dato: lifeless was thinking about introducing extension module packages to work around that
[11:18] <dato> a package doing what exactly? and how would it help?
[11:18] <dato> the real question would be if the ubuntu autobuilders can cope with 'B-D: python-celementtree | python (>> 2.5)'. I can't remember if we got that answered or not.
[11:19] <lifeless> build arch-any for the non-C code
[11:19] <lifeless> sorry
[11:19] <lifeless> bleh, I forget which is -all and which -any
[11:20] <lifeless> but we only need to build the extensions per arch
[11:20] <lifeless> and building the extensions does not need celementree etc etc
[11:20] <lifeless> *also*, we don't need celementree for the package build, FWIW
[11:20] <dato> ah, that last statement is way more interesting
[11:21] <dato> it was in build-depends when I first touched the package, so I never questioned whether it was
[11:21] <lifeless> celementree is purely performance optimisation
[11:21] <siretart> that would make things lots easier here...
[11:21] <dato> oh yes.
[11:23] <siretart> lifeless: is python-paramiko necessary at build-time?
[11:28] <fullermd> No.
[11:29] <fullermd> I don't think _anything_ is needed at build time, except python (and cc if you're building the C .so's).
[11:32] <lifeless> pyrex to do .pyx -> .c
[11:32] <lifeless> (if building from bazaar, rather than tarball)
[11:33] <lifeless> if you run the test suite
[11:33] <lifeless> then paramiko, medusa, python-crypto (for old pythons only) are needed
[11:36] <vila> lifeless: they should not even be required, better to test with them though, but I think the patch handling their availability have been merge (or is it in 0.92 ?)
[11:45] <vila> nope, bug #59150 not merged for 0.91, so paramiko is required to run the test suite
[11:45] <ubotu> Launchpad bug 59150 in bzr "bzr selftest fails on a machine without paramiko" [Low,Fix released]  https://launchpad.net/bugs/59150
[12:03] <lapthrick> bzr treats branch as equal when their history's the same and doesn't have a concept of any unique "branch ID", right?
[12:03] <lapthrick> *branches
[12:14] <matkor> lapthrick: to my tiny knowledge - right
[12:14] <matkor> I think about branches as sequences of unique revisions
[12:20] <lifeless> vila: well, not required, but strongly preferred
[12:20] <lifeless> lapthrick: URL is branch id
[12:20] <vila> lifeless: agreed
[12:21] <siretart> oh, since we don't run the testsuite on the buildds, I'll remove paramiko for now
[12:26] <lapthrick> lifeless: well, yeah, but it's not encoded anywhere inside the branch itself, no?
[12:27] <lapthrick> so if I switched the parent branch of anything to an equivalent branch under another URL, it wouldn't change anything, right?
[12:28] <pbor> bzr: ERROR: Repository KnitRepository('file:///home/paolo/dev/gedit/.bzr/') is not compatible with repository KnitRepository3('file:///home/paolo/bzr/gedit/.bzr/')
[12:28] <pbor> what should I do?
[12:29] <lapthrick> pbor: bzr upgrade --something
[12:29] <pbor> (I did bzr init-repo in dev/gedit because I want to create a repo with multiple branches under it and then I tried to branch from bzr/gedit which is the branch I created with bzr-svn...)
[12:29] <lapthrick> for appropriate value of something :)
[12:29] <pbor> lapthrick: in the newly created repo or in the bzr-svn one?
[12:30] <lapthrick> pbor: I think the newly created, as KnitRepository is the default (still) and older format unless you override it
[12:32] <pbor> mmm the bzr-svn one is "dirstate-with-subtree" while the newly created is "dirstate or dirstate-tags or knit"
[12:33] <lapthrick> pbor: you need dirstate-with-subtree for svn interop
[12:33] <pbor> bzr  help formats doesnt mention dirstate-with-subtree
[12:33] <lapthrick> it's in the FAQ now
[12:33] <pbor> okay
[12:34] <lapthrick> though usually it complains about not being able to interop with SvnRepository, not KnitRepository3
[12:36] <pbor> work now, thanks lapthrick
[01:13] <matkor> Hi ! I have problems:
[01:13] <matkor> >>> import bzrlib.plugins
[01:13] <matkor> >>> bzrlib.plugins.__file__        -> '/usr/lib/python2.4/site-packages/bzrlib/plugins/__init__.pyc'
[01:13] <matkor> >>> import bzrlib.plugins.gtk       -> ImportError: No module named gtk
[01:14] <Odd_Bloke> matkor: That presumably means that you don't have the bzr-gtk plugin installed.
[01:14] <matkor> Odd_Bloke: I have but in /usr/share:
[01:14] <matkor> [matkor@laptop-hp /usr/share/python2.4/site-packages/bzrlib/plugins] $ python
[01:14] <matkor> >>> import gtk       ->  No handlers could be found for logger "bzr"
[01:15] <matkor> but it imports
[01:15] <Odd_Bloke> In that case I don't know.  Sorry. :(
[01:16] <matkor> >>> "/usr/share/python2.4/site-packages" in sys.path         -> True
[01:16] <dato> matkor: the gtk plugin *has* to be under the plugins path
[01:17] <dato> so either /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk or ~/.bazaar/plugins/gtk
[01:17] <dato> (or other location if you play with BZR_PLUGIN_PATH)
[01:18] <matkor> dato: But I have /usr/share/python2.4/site-packages in sys.path
[01:19] <dato> yes, but plugins can't be there directly
[01:19] <matkor> dato: so "plugins path" is sth different than sys.path ?
[01:19] <dato> if I'm not mistaken, yes
[01:20] <matkor> can I add another plugins path during configure install ?
[01:20] <dato> I don't think so, but there is the runtime BZR_PLUGIN_PATH (or a similar name)
[01:21] <matkor> dato: I am preparing bzr bzr-gtk bzrtools for distro release and we use both "/usr/lib/python2.4" and "/usr/share/python2.4" (FHS) so it would be much much better to do it during install
[01:22] <dato> if it's for distro release, why dont you put them under /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk ?
[01:22] <dato> *or*
[01:22] <dato> make /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk a symlink to /usr/share/python2.4/...
[01:22] <dato> *but*
[01:23] <dato> I think it's a very very very bad idea to put the gtk plugin *directly* in /usr/share/python2.4/site-packages/gtk
[01:24] <matkor> dato: Why is that ?
[01:24] <matkor> dato default bzr-gtk install (setup.py install) puts plugins under /usr/share/ ...
[01:24] <dato> because 'import gtk' should import the pygtk bindings, not the bzr plugin
[01:27] <matkor> dato: That's true. But I understood that bzr plugin path contains only /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk and ~/.bazaar/plugins/gtk so putting them under  /usr/lib/python2.4/site-packages will not help with import bzrlib.plugins.gtk
[01:27] <dato> I said put them under /usr/lib/python2.4/site-packages/bzrlib/plugins/gtk, not /usr/lib/python2.4/site-packages/gtk
[01:28] <matkor> Sensible fix would be to add new default /usr/share/python2.4/site-packages/bzrlib/plugins/ ...
[01:29] <dato> that won't work
[01:29] <dato> because when bzr imports plugins, it's not looking at sys.path
[01:29] <dato> directly
[01:30] <dato> but under `dirname bzrlib.__file__`/plugins
[01:30] <matkor> Ah ... so symlinks are only way ...
[01:31] <dato> mostly, if you insist on not shipping the plugin under /usr/lib
[01:32] <matkor> but you said that it is not only looking in  `dirname bzrlib.__file__`/plugins but also in ~/.bazaar/plugins/gtk , correct ?
[01:32] <dato> yes
[01:57] <matkor> dato: You think that wishlist to add /usr/share... to bzr plugin paths during setup.py has a chance to be included in next bzr releases ? That would be step towards FHS ...
[01:58] <dato> matkor: I personally don't know, because I'm not a bzr developer, but if it depended on me, I would not.
[01:59] <matkor> dato: I will try anyway ...  , but what is yours rationale against ?
[02:18] <lifeless> matkor: why do you want usr/share/something in the bzrlib plugins path?
[02:19] <lifeless> matkor: (also, you can just set an environment variable to control that)
[02:21] <matkor> lifeless: default setup puts plugins there (and it is correct according to FHS)
[02:21] <lifeless> matkor: the default is in the plugins path
[02:22] <matkor> lifeless: I would like to have install time and system-wide way of adding that path
[02:22] <matkor> lifeless:  python  setup.py install --optimize=2 --root=$RPM_BUILD_ROOT  puts them uder /usr/share
[02:23] <lifeless> matkor: our default path is [dirname(bzrlib.plugins.__file__), '~/.bazaar/plugins'] 
[02:23] <lifeless> matkor: where under /usr/share ?
[02:24] <matkor> lifeless: /usr/share/python2.4/site-packages/bzrlib/plugins
[02:24] <matkor> default for pure-python packages
[02:24] <lifeless> what does 'python -c import bzrlib.plugins; print bzrlib.plugins.__file__' report ?
[02:25] <matkor> lifeless: /usr/lib/python2.4/site-packages/bzrlib/plugins/__init__.pyc
[02:25] <lifeless> ok, there is the problem
[02:25] <matkor> which also correct (but for binary modules)
[02:25] <lifeless> what is
[02:25] <lifeless> what does 'python -c import bzrlib.plugins; print bzrlib.plugins.__path__' report ?
[02:26] <ubotu> New bug: #145612 in bzr "Unable to use pure-python plugins from /usr/share/ ... (FHS) location" [Undecided,New]  https://launchpad.net/bugs/145612
[02:26] <matkor> lifeless: ['/home/users/matkor/.bazaar/plugins', '/usr/lib/python2.4/site-packages/bzrlib/plugins'] 
[02:26] <lifeless> matkor: this is a bug in your python environment, not bzr
[02:27] <schierbeck> jelmer: ping
[02:27] <lifeless> matkor: I am pretty sure
[02:27] <lifeless> $ python -c 'import bzrlib; print bzrlib.__path__'
[02:27] <lifeless> ['/usr/lib/python2.5/site-packages/bzrlib'] 
[02:27] <lifeless> if I put any additional package FOO in /usr/share/python2.5/site-packages/bzrlib/FOO
[02:27] <lifeless> then it will not load into python
[02:28] <matkor> lifeless: I think it should in default python setup
[02:28] <lifeless> matkor: try it
[02:28] <matkor> I mean package foo should be looked both in /usr/bin/.. and  /usr/share
[02:28] <lifeless> matkor: importing bzrlib does not alter the module __path__
[02:29] <lifeless> matkor: but they are not; its not how python works
[02:30] <lifeless> it can be made to work that way, but its a problem in your environment not bzrlib, as long as bzrlib handles the __path__ that you assign to the bzrlib.plugins module correctly (and there looks to be a small bug there today, which I'll fix tomorrow)
[02:31] <matkor> lifeless: I think import foo/bar should check module in both /usr/share and /usr/bin in FHS installed python
[02:31] <lifeless> (we look at __file__, rather than __path__ to grab the default place to load plugins from)
[02:31] <lifeless> matkor: I'm not arguing that you are wrong, I'm arguing that you should file a bug on python in redhat, because it *doesn't*, not for non-root modules.
[02:32] <lifeless> and bzr inherits this behaviour
[02:33] <lifeless> what you want is: $ python -c 'import bzrlib; print bzrlib.__path__'
[02:33] <lifeless> to print out
[02:33] <lifeless> ['/usr/lib/python2.5/site-packages/bzrlib', '/usr/share/python2.5/site-packages/bzrlib'] 
[02:33] <lifeless> (for bzrlib, or any other module)
[02:34] <lifeless> I don't know enough about the design implications of the module system in python to comment on whether this is a good idea or not.
[02:34] <lifeless> I do know enough to say that bzrlib should not prevent that, and should, if that is being done, honour it for plugins.
[02:35] <lifeless> I'm reasonably sure that doing it manually is a potentially bad idea
[02:39] <lifeless> well, I hope this has helped clarify things; and I'll look at the bug, and also fix the bug I spotted during the discussion, tomorrow.
[02:39] <lifeless> gnight
[02:40] <matkor> gnight :)
[02:42] <siretart> lifeless: dato: bzr_0.91-2 uploaded, without paramiko and celementree in build-depends
[02:42] <siretart> hopefully it builds this time on all archs
[02:47] <dato> siretart: I saw, thanks
[03:00] <karmazilla> was there a way to use bzr for diffing two files without adding them or using some repo/branch ?
[03:06] <karmazilla> patiencediff.py, it seems
[03:10] <schierbeck> any bzr-gtk hackers here?
[03:13] <matkor> schierbeck: one tiny ;) why ;) ?
[03:14] <matkor> and olive-gtk only
[03:14] <schierbeck> i've cleaned up the viz code quite a bit, removing some redundancy
[03:14] <schierbeck> could i get you to check it out a bit?
[03:15] <schierbeck> it's not really advanced at all, i just want to be sure you can run it
[03:24] <matkor> schierbeck: I think you should talk with jelmer
[03:25] <matkor> schierbeck: Have you published branch with those changes somwhere ?
[03:25] <schierbeck> yup, at http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-cleanup
[03:25] <schierbeck> i don't think jelmer's online
[03:28] <matkor> send him or Szilwester e-mail and be patient - I worked little bit only with olive-gtk
[03:31] <schierbeck> ok
[04:16] <Lllama> Afternoon all. Anyone using bzr-svn under Windows?
[04:16] <Lllama> I'm having trouble pushing up to Google Code
[04:25] <zyga> is there any description of API changes from around 0.16 to 0.91?
[04:26] <zyga> I'm trying to use latest tailor to convert something but 0.91 has different API
[05:12] <steko> hi
[05:13] <steko> what is the current status of the webdav plugin ?
[05:25] <mgedmin> to whoever implemented 'bzr ignore': thank you thank you thank you!
[05:28] <LarstiQ> mgedmin: multiple people, what makes it so joyful for you? :)
[05:38] <mgedmin> it's what I always wanted
[05:45] <disorder> hi, can I use username containing @ somehow with bzr over FTP? Hosting uses user@domain.tld usernames
[05:46] <disorder> tried to google something and set username inf config but no luck yet
[05:46] <dato> disorder: try `bzr push ftp://user%40domain.tld@server.com`
[05:46] <mwh> url-encode the @?
[05:47] <disorder> thaks dato and mwh. haven't thought of it
[05:52] <jelmer> re
[05:52] <jelmer> hey schierbeck, matkor
[05:53] <vila> steko: webadv plugin status is: requires bzr-0.92.0 (i.e. bzr.dev), pass the bzr test suite, awaiting testers :)
[05:54] <jelmer> looks like Samba will end up using git :-(
[05:54] <steko> vila: thanks. then I'll wait for 0.92 to enter lenny
[05:55] <vila> steko: what is your use case ?
[05:57] <steko> vila: I think nothing very interesting, I have a web space with webdav access and I'd like to keep also there some of the code I write. But I just write very small Python programs for myself
[05:58] <vila> steko: there is no such thing as not interesting user needs :) I'd lie the webdav plugin to work on as many setups as possible, so feel free to ping me here when you're ready
[05:58] <vila> s/lie/like/
[05:59] <steko> vila: thanks. The server is running Apache 2.0 so there should be no problem
[05:59] <schierbeck> jelmer: hi
[05:59] <dato> jelmer: aw
[06:00] <vila> steko: ok. That's my testing env so yes, that should work ok, do you administer the server yourself ?
[06:01] <steko> vila: no, I don't. otherwise I would have used something like SFTP.. ;-)
[06:01] <vila> :)
[06:02] <schierbeck> jelmer: have you seen my merge request on the bzr-gtk list? i'm not sure it's getting through...
[06:03] <pbor> jelmer: do you have a link on samba discussion/decision?
[06:04] <zerok> hi :)
[06:04] <schierbeck> zerok: hi!
[06:07] <zerok> if you use a centralized approach with checkout and also have some local commits, can you somehow push them to the central branch without creating another changeset? (or is this done with push?)
[06:08] <dato> zerok: yes, with push
[06:09] <zerok> dato, thanks :) i was just not sure because the default push path wasn't automatically set when creating that branch :)
[06:10] <jelmer> pbor: all happening in person
[06:12] <fullermd> Heck, that should make it easy to sway toward bzr.  In person, it's SO much easier to apply blunt instruments...
[06:14] <jelmer> schierbeck, will check in a moment
[06:14] <jelmer> fullermd, :-)
[06:20] <TeTeT> is there currently a problem with registering new branches on LP?
[06:20] <TeTeT> e.g. failed to create path prefix?
[06:24] <mwh> not that i know of
[06:25] <schierbeck> jelmer: thanks
[06:26] <LarstiQ> TeTeT: what are you trying to do? bzr push? Tried --create-prefix?
[06:26] <schierbeck> phanatic: hi
[06:26] <phanatic> hey schierbeck
[06:27] <schierbeck> phanatic: i've tried posting a merge request to the list, but it doesn't seem to have gotten through
[06:27] <TeTeT> LarstiQ: yes, found the prob: when not using a projects name as directory path, it won't work
[06:27] <TeTeT> bzr+ssh does not tell you, but sftp does
[06:28] <LarstiQ> TeTeT: oh?
[06:29] <mwh> uh
[06:29] <mwh> TeTeT: what does bzr+ssh say?
[06:30] <phanatic> schierbeck: i didn't get any mails about moderation either (theoretically all the mails which don't make it to the list, should be in the moderation queue, and we should get notified about that)
[06:30] <schierbeck> i'll try to re-send
[06:30] <phanatic> okay
[06:31] <dato> LarstiQ, mwt, TeTeT: there's a thread in the list by jam precisely on that.
[06:32] <LarstiQ> dato: thanks
[06:32] <schierbeck> phanatic: i've cleaned up the viz code a bit, removing some redundancy -- wanna have a peek?
[06:33] <phanatic> schierbeck: first i'd say you should have a look at Gary's brokenlines branch, because that pretty much refactors some bits of viz, and probably we'll merge it into trunk (at least i'd like to)
[06:33] <schierbeck> phanatic: okay, i'll have a look
[06:36] <schierbeck> phanatic: it seems there's room for both
[06:37] <schierbeck> should i try to merge it into trunk or brokenlines?
[06:38] <phanatic> schierbeck: good question :) first i'd like someone with the sufficient knowledge to review the brokenlines branch (tbh, i don't know that part of the code well, since it was written way before olive existed), after that we can talk about any changes to viz. that's my opinion, but feel free to convince me :)
[06:39] <schierbeck> sounds reasonable -- this was just a maintenance cleanup, removing code duplication and simplifying the construction of the widget
[06:40] <TeTeT> mwh:failed to create path prefix
[06:40] <schierbeck> but the brokenlines branch seems to be pretty sophisticated, i'm not sure it's that easy to review...
[06:40] <mwh> sounds like a bug
[06:40] <phanatic> schierbeck: sure, don't forget about it please :)
[06:41] <phanatic> schierbeck: yeah, maybe i'll just go on and merge it, so we can find possible bugs
[06:41] <schierbeck> sounds like a good idea
[06:42] <schierbeck> i'd also like to see a major cleanup of some parts, including moving the scrollwin outside of brancwin.py
[06:43] <phanatic> what's scrollwin?
[06:43] <schierbeck> the part of the viz with the treeview and stuff
[06:44] <schierbeck> i think it would be cool if we offered it as a widget of itself
[06:45] <Peng> How does bzr do binary diffing and whatnot?
[06:45] <Peng> Bah, I dunno what that question is supposed to mean.
[06:48] <phanatic> schierbeck: yep, maybe you're right. logview was also moved to a separate module/widget by jelmer
[06:48] <Peng> pmezard: You ask. I don't know what to ask. :P
[06:50] <schierbeck> phanatic: perhaps it could be generalized, and included in anjuta or something :)
[06:51] <phanatic> probably other applications could make a use of it as well, that's true
[06:54] <schierbeck> hmm, my mail still hasn't come true (that is, if it is resent to the author)
[06:54] <schierbeck> *through
[06:59] <phanatic> schierbeck: are you sending it from your gmail account?
[06:59] <schierbeck> yup
[07:03] <schierbeck> phanatic: is that causing problems?
[07:04] <phanatic> no idea
[07:47] <Peng> Um, is 'bzr commit' supposed to say 'Committing revision N to "<PATH>"'?
[07:47] <jelmer> peng: yup
[07:48] <Peng> Why?
[07:48] <Peng> Is that new with 0.91?
[07:51] <TeTeT> which bazaar GUI would you recommend for technical writers? I'm looking for something that provides ease of use for simple things, rather than completeness
[07:56] <Odd_Bloke> Peng: Yeah, assuming '<PATH>' is replaced with an actual URL/path. :p
[07:56] <Odd_Bloke> (Yeah to both questions)
[07:56] <Peng> Odd_Bloke: Right.
[08:24] <mw> when i do "bzr add *" in a large directory (a svn checkout of evolution-data-server, fwiw) it says "ignored 583 file(s)."  how can i see what those files are?
[08:25] <mw> nothing about those files goes to stdout or stderr
[08:25] <fullermd> 'bzr ignored'
[08:27] <mw> aha, those were just object files anyway
[08:29] <mw> --verbose lists them too.  duh.
[08:29] <mw> passing --verbose to add, that is
[08:30] <Peng> Really? I didn't know that. Cool.
[08:37] <TeTeT> does bzr init-repo also work for already existing branches in a directory?
[08:37] <TeTeT> or is it recommend to make a new directory, bzr init-repo there, and then bzr move the branches to the repo directory?
[08:37] <Odd_Bloke> TeTeT: You would want to 'bzr branch' them to the repo directory.
[08:39] <TeTeT> Odd_Bloke: thx
[09:57] <lifeless> moin
[10:17] <lifeless> abentley: morning; you identified a merge base problem a few weeks back; are you working on correcting that?
[10:23] <jelmer> hey lifeless
[10:24] <lifeless> hey jelmer
[10:24] <lifeless> pqm will happen soonm I have your mail
[10:27] <jelmer> lifeless: cool, thanks
[10:28] <lifeless> jelmer: how long till you have rebase fixed do you think?
[10:28] <lifeless> jelmer: is it worth shipping a bzrlib.plugins.svn.rebase in the interim ?
[11:11] <ubotu> New bug: #145812 in bzr "Upgrade can leave a broken repository (with backup)" [Undecided,New]  https://launchpad.net/bugs/145812
[11:16] <ubotu> New bug: #145813 in bzr "Can't upgrade RepositoryFormatKnit1 and no clue given as to what to do about it." [Undecided,New]  https://launchpad.net/bugs/145813
[11:18] <jelmer> lifeless: Yeah, that may be a good idea. I'll do that if it's still broken when I do the next rleease
[11:18] <lazy1> Can someone explain why even though I have '.subversion/auth/*' in my .bzrignore I still get .subversion/auth/svn.simple/0e79c1d269bc64edc62fd3ca3683a2cc as unknown?
[11:19] <lifeless> jelmer: I'm seeing lots of people be unable to upgrade, its breaking users; so if your next release is more than a few days away; I'd encourage you to do this now :)
[11:19] <lifeless> lazy1: if svn.simple was added, then that will override the ignore.
[11:20] <lifeless> lazy1: for a full path match, use ./.subversion/auth/*
[11:20] <lazy1> lifeless: Just .subversion as a whole
[11:20] <ubotu> New bug: #145814 in bzr "Please provide a way to do 'missing' between a bound branch and it's master." [Wishlist,New]  https://launchpad.net/bugs/145814
[11:21] <lazy1> lifeless: ./.subversion/auth/* does not work as well
[11:22] <lifeless> lazy1: so is .subversion versioned ?
[11:23] <lazy1> lifeless: yes
[11:23] <lifeless> is auth ?
[11:23] <lazy1> (as most of my home directory)
[11:23] <lazy1> auth as well
[11:24] <lifeless> oh, hmm
[11:24] <lifeless> perhaps you need /**/*
[11:24] <lazy1> ?
[11:24] <lifeless> ./.subversion/auth/**/*
[11:25] <lazy1> excellent, that works. Thanks!
[11:25] <lifeless> bzr help ignore has the language
[11:25] <lazy1> missed that, sorry
[11:25] <lifeless> hey no problem
[11:25] <lazy1> thougth it's just shell regexp
[11:26] <mgedmin> well, in shell patterns * doesn't match subdirs
[11:26] <mgedmin> so I'd expect .subversion/auth/*/* to work, but not .subversion/auth/*
[11:27] <lazy1> you are right
[11:28] <lazy1> however Python glob does show subdirectories with *
[11:28] <lifeless> yes
[11:28] <lifeless> glob is broken
[11:28] <lifeless> it doesn't match shell
[11:29] <lazy1> for f in `/bin/ls .subversion/*`; do echo $f; done shows subdirectories as well
[11:29] <lazy1> (bash)
[11:29] <mgedmin> that's ls
[11:29] <lifeless> that shows the dir, not the contents
[11:29] <lazy1> yup
[11:29] <mgedmin> try echo rather than ls
[11:29] <lifeless> 'ls dir' shows whats in dir
[11:30] <lazy1> for f in .subversion/*; do echo $f; done shows sub directories as well
[11:30] <lifeless> not for me
[11:30] <lifeless> ~$ for f in .subversion/*; do echo $f; done
[11:30] <lifeless> .subversion/auth
[11:30] <lifeless> .subversion/config
[11:30] <lifeless> .subversion/README.txt
[11:30] <lifeless> .subversion/servers
[11:30] <lazy1> But you see "auth" which is a directory
[11:31] <lifeless> its not a sub directory of the point the * is at
[11:31] <lazy1> ?
[11:31] <mgedmin> when I said "in shell patterns * doesn't match subdirs" I meant that it doesn't match the / character
[11:31] <lazy1> oh, now I get it
[11:31] <mgedmin> not that it checks the types of the filenames
[11:53] <lifeless> james_w: hi
[11:53] <lifeless> james_w: there is another bug, about format ui - your bug is really a dup of that, because you need 'dirstate-with-subtree-tags'
[11:54] <fullermd> Ooooh, do I get to renew my crusade against rollup format names?   ;>
[11:55] <lifeless> fullermd: only if you write the patch for that bug :)