[02:05] <xiaohui> how to  change the parent branch of bzr?
[02:10] <jelmer> xiaohui: bzr pull --remember
[02:12] <xiaohui> jelmer, thank you
[02:15] <rockstar> abentley, around?
[02:15] <rockstar> jelmer, do you know much about bzr hooks?
[02:16] <jelmer> rockstar: hi
[02:16] <jelmer> rockstar: a bit
[02:17] <rockstar> jelmer, so, I've got a class that inherits from bzrlib.hooks.Hook, and it registers two hook points.  How do I fire those two hook points?
[02:18] <jelmer> rockstar: the hook points are iterables over the registered hooks
[02:18] <jelmer> so you can just do something like:
[02:19] <jelmer> for hook in myhooks_instance['hook_name']:
[02:19] <jelmer>    hook(42)
[02:19] <rockstar> bzrlib.hooks.HookPoint has a hook method, but not an fire method.
[02:19] <rockstar> jelmer, you would think that the HookPoint would know how to fire itself.  :/
[02:20] <jelmer> rockstar: no, you have to call the individually registered entries yourself
[02:20] <jelmer> although I guess it would indeed make sense for HookPoint to have such a method
[02:22] <rockstar> jelmer, yea.  Something like HookPoint.fire(*args)
[02:25] <rockstar> jelmer, I'll implement create a subclass of HookPoint in Tarmac, try it out, and if it works, I'll create a patch for Bazaar.
[07:39] <rockstar> Is there a simple way to add revisions to a branch created with BzrDir.create_branch_convenience ?
[07:44] <BasicOSX> Attempting 1.15rc1 release and I keep getting "bzr: ERROR: socket.error: (104, 'Connection reset by peer') " several network, all peered differently, even 1 network from a large hosting provider in the midwest (US). Something wrong with LP tonight?
[07:45] <rockstar> BasicOSX, on push?
[07:46] <BasicOSX> or branch or pull
[07:46] <rockstar> BasicOSX, hm, I haven't had any problems, and I've been using it steadily tonight.
[07:51] <lifeless> rockstar: what do you mean by add revisions
[07:51] <lifeless> rockstar: is this test code or real code
[07:51] <rockstar> lifeless, test code.
[07:51] <lifeless> BasicOSX: what aare you getting that from
[07:51] <BasicOSX> bzr  branch http://code.launchpad.net/~bzr/bzr/bzr.1.15
[07:51] <BasicOSX> gives that to me
[07:51] <lifeless> rockstar: and what do you mean by add revisions
[07:52] <rockstar> lifeless, basically, I want to test that two branches are merged.  I was planning on going to find the merge tests in bzrlib and see how they work.
[07:52] <rockstar> lifeless, if I create two branches with BzrDir.create_branch_convenience and try to merge them, it throws NoCommits (which makes sense)
[07:52] <lifeless> A and B are merged if len(heads(a.tip, b.tip)) == 1
[07:52] <BasicOSX> lifeless:  attempting  ~/projects/bzr/bzr.1.14/bzr  branch http://code.launchpad.net/~bzr/bzr/bzr.1.15 to see if it's a problem(?) in bzr.dev (revision: 4369)
[07:53] <lifeless> rockstar: tree1 = self.make_branch_and_tree('1'); tree1.commit(''); tree2 = tree1.branch.push('2')
[07:53] <lifeless> tree1.commit('next')
[07:53] <rockstar> lifeless, yes, so I want to add some revisions b so that I can actually make a merge (but not necessarily commit)
[07:53] <lifeless> tree2.commit('next in 2')
[07:53] <lifeless> tree2.merge_from_branch(tree1)
[07:53] <rockstar> lifeless, I'm not using the bzr test suite.
[07:54] <lifeless> rockstar: oh; any reason preventing you?
[07:54] <BasicOSX> bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' (-2, 'Name or service not known') things keep getting stranger
[07:54] <rockstar> lifeless, um, mostly because I'm too lazy to go try it out, and I probably don't need most of it.
[07:54] <BasicOSX> I did just recently upgrade to 2.6.24-24-server on my hardy system, but that's the only change
[07:54] <rockstar> lifeless, but mostly lazy.  :)
[07:55] <lifeless> rockstar: from bzrlib.tests import TestCaseWithTransport
[07:55] <lifeless> thats all thats needed :)
[07:55] <rockstar> lifeless, I am stealing the Hook/HookPoint stuff though.
[07:55] <rockstar> Well, not stealing, but using.
[07:58] <lifeless> rockstar: to add revisions you need to do commits or pull/push from another branch
[07:58] <lifeless> rockstar: by far the easiest way is using the bzr test harness
[07:58] <rockstar> lifeless, okay, that's simple enough.
[08:02] <lifeless> BasicOSX: anything I can do, let me know
[08:03] <lifeless> BasicOSX: but I think you have some local trouble ;P
[08:03] <BasicOSX> I'd like to think so, but 4 different computers on 4 different network on 4 different ISPs?
[08:04] <BasicOSX> Comcast, UUnet, Qwest, and Sprint all having problems? could be, heck google went down the other day :-)
[08:15] <BasicOSX> lifeless:  373455 when from Fix Released to Fix Committed, that normal?
[08:15] <BasicOSX> bug 373455 that is
[08:30] <lifeless> BasicOSX: no
[08:31] <lifeless> BasicOSX: fix committed means 'it has landed in bzr.dev'
[08:31] <Peng_> But bzr uses "Fix Released" for that.
[08:32] <lifeless> oh yes, I'm explaining badly
[08:32] <lifeless> what I mean is, if its not ix released, its not in trunk
[08:33] <lifeless> I don't think we've finished fixing stacking
[08:33] <lifeless> I could be wrong
[08:46] <Peng_> Congrats. :)
[08:47] <BasicOSX> Now the scary part.. merge back into trunk :-P
[10:42] <alsuren> is there a way to tell bzr to ignore changes in permissions? I just copied everything to a fat32 usb stick, and it's telling me that the entire repo has been changed
[10:43] <lifeless> alsuren: the only permission bzr tracks is the executable bit
[10:44] <lifeless> alsuren: are you using bzr under windows?
[10:46] <alsuren> no, I'm on ubuntu. Problem is that I made *some* changes
[10:50] <alsuren> oh, I just read the bit on status-flags. I reckon I could hack something together with grep to work out which files I *actually* modified
[10:58] <alsuren> yeah, so parsing the output of status -S is actually really easy. Why isn't this the default?
[10:58] <alsuren> actually, I'm quite glad that it's not
[10:58] <alsuren> ignore me
[11:09] <Peng_> :D
[11:09] <alsuren> okay, so actually I still need help
[11:09] <alsuren> $ bzr revert
[11:09] <alsuren> bzr: ERROR: [Errno 1] Operation not permitted
[11:10] <alsuren> there is a bug in launchpad about it
[11:10] <alsuren> https://bugs.launchpad.net/bzr/+bug/190725
[11:12] <alsuren> (for reference, I used cp -R proj/.bzr /media/disk to do the copy)
[11:14] <alsuren> does anyone know a way around this, or am I just screwed?
[11:25] <lifeless> alsuren: well the bzr metadata should be just fine
[11:25] <lifeless> alsuren: you could try branching fresh
[11:27] <alsuren> *bets he'll run out of space if he does that, but tries it anyway*
[11:27] <alsuren> no. still operation not permitted
[11:31] <alsuren> oh, ololol: it's symlink that's throwing
[11:36] <alsuren> okay, so removing the symlinks from the repo makes revert work, but I still need some way to stop bzr from trying to track the execute bit
[11:38] <Peng_> Hmm, content filters? :D
[11:40] <alsuren> Peng_: https://bugs.launchpad.net/bzr/+bug/190725/comments/8 suggests a plugin. how do I need to change it?
[11:42] <alsuren> (I'm thinking that the real solution would probably be retro-fitting permissions to FAT at the operating system layer, but we all know that's not going to happen
[11:46] <alsuren> hrrrm... I guess I could monkey-patch os.stat to clear the execute bit, but that's *really* horrible
[11:47] <lifeless> o
[11:47] <Odd_Bloke> jelmer: I just hit http://dpaste.com/44691/ when trying to push to Debian SVN.
[11:48] <lifeless> so the basic problem is, fat is returning garbage data, and we assume when the platform is unix that all fs's track X reasonably well
[11:48] <lifeless> we have code to work around no X tracking but only activate it on windows
[11:48] <lifeless> file a bug please
[11:48] <lifeless> I suggest we add a a config setting/environment variable to force that workaround code on in this sort of situation
[11:49] <Peng_> What about explicitly checking if the fs supports it?
[11:49] <Peng_> Same way you do the CIFS checks?
[11:49] <lifeless> Peng_: what CIFS checks
[11:50] <lifeless> Peng_: do you mean the case insensitive ones?
[11:50] <Peng_> Yeah.
[11:50] <lifeless> we need either reference data or to write
[11:50] <lifeless> its possible in principle
[11:50] <alsuren> lifeless: should I paste this conversation to the bottom of my bug report?
[11:54] <alsuren> lifeless: where is this no-X-tracking magic, and can I enable it with a plugin in the short-term?
[11:54] <awilkins> Offtopic : Is there an ability in the SFTP protocol to just get a hash or crc of a file, not the file?
[11:55] <awilkins> Thinking about it, is tracking x-bit a security risk, and should it be done at all?
[11:58] <alsuren> awilkins: where did you get that idea from?
[11:59] <alsuren> bzr is used for pushing source code around, which is compiled and executed on the user's system. There are far more dangerous things that you can do than twiddling an X bit
[11:59] <awilkins> alsuren: Yes, put that way it does seem less significant
[12:05] <lifeless> alsuren: its mainly in workingtree*.py
[12:05] <lifeless> awilkins: don't think so
[12:05] <lifeless> [to both SFTP and x-bit security]
[12:05] <lifeless> bzr doesn't run the users code
[12:05] <lifeless> its why we don't have in-tree plugins, for instance
[12:06] <awilkins> Fairy snuff.
[12:06] <lifeless> as long as bzr doesn't run code from a branch, there isn't a risk that is bzr's fault ;)
[12:06] <lifeless> now,if bzr tracked owners
[12:06] <lifeless> or setuid
[12:06] <luks> bzr actually can try to run some python code :)
[12:07] <lifeless> that would be different
[12:07] <lifeless> luks: from the users branch?
[12:07] <luks> yes
[12:07] <lifeless> how?!
[12:07] <luks> via imports
[12:07] <lifeless> thats the system python path
[12:07] <lifeless> outside bzr's control; file a bug on your OS/python install :)
[12:07] <luks> sure, but it can happen :)
[12:08] <lifeless> same as bash can run some code from there
[12:08] <luks> but bash is expected to do so
[12:08] <lifeless> no
[12:08] <lifeless> having '.' in your path is widely recognised as a security law
[12:08] <lifeless> *flaw*
[12:08] <lifeless> same goes for . in your python path
[12:09] <luks> except that's the default setting for python
[12:10] <alsuren> luks: well if you fancy porting bzr to python3 and using "from . import whatever" all over the place, then go for it
[12:12] <luks> I'm not saying anything except that it's possible for bzr to run user's code right now
[12:12] <luks> I know about it and I can live with it
[12:14] <alsuren> that's actually something I'd never thought about before.
[12:16] <luks> I can't even reproduce it right now, so maybe there was something done to fix it
[12:16] <luks> I've seen a few people to have that problem on the ML in the past
[12:18] <alsuren> luks: reading the tut, that's not how it works
[12:18] <alsuren> "Actually, modules are searched in the list of directories given by the variable sys.path which is initialized from the directory containing the input script (or the current directory)"
[12:20] <alsuren> so . isn't actually in your path, only $ dirname `which bzr`
[12:22] <luks> can't really find the posts
[12:23] <lifeless> alsuren: that doesn't protect against it :P
[12:37] <jelmer> Odd_Bloke: hi
[12:37] <jelmer> Odd_Bloke: that's the no 1 bug for bzr-svn, should be fixed before 1.15
[13:08] <Odd_Bloke> jelmer: Is there any way I can work around it?
[13:12] <jelmer> Odd_Bloke: you can comment out the assertion
[13:12] <jelmer> it should generally be harmless
[13:20] <Odd_Bloke> jelmer: Cool, thanks.
[13:29] <alsuren> lifeless: if . isn't in your path, then surely you're pretty safe (sorry, went to lunch)
[13:35] <alsuren> https://bugs.launchpad.net/bzr/+bug/377243
[13:41] <alsuren> lifeless: can't find the win32 hacks you speak of
[14:40] <knielsen> I have a --no-trees shared repo (bzr init --no-trees). Is there an option to `bzr branch` to override the --no-trees, eg. the opposite of `bzr branch --no-tree` ? `bzr brancj --tree` doesn't complain about the not documented --tree option, but it also doesn't create a tree?
[14:41] <knielsen> (I know I can just bzr co afterwards, so not big deal, just wondering if I missed the option)
[14:42] <jelmer> knielsen: I don't think there is anything like that atm, but I agree it makes sense
[14:42] <knielsen> ok
[14:42] <knielsen> Maybe an oversight, since the --tree option is there somehow but seems to do nothing
[14:43] <knielsen> might be a good starter project to get into the code ;-)
[14:48] <jelmer> knielsen: Yeah, this might be a trivial one to fix
[15:20] <pst555> i wonder how i could accomplish something like repo1/lib where lib being a link to repo2
[15:28] <pst555> is a bzr co lib inside repo1 and then a bzr link-tree the right thing to do?
[17:02] <rocky> jelmer: care to elaborate on "dpush" ? :)
[17:03] <jelmer> rocky: what about it?
[17:03] <rocky> just trying to understand it
[17:06] <jelmer> rocky: it just pushes into a foreign vcs (such as svn) losslessly (i.e. what can't be represented in that VCS is lost)
[17:07] <rocky> ah metadata can be loss
[17:07] <LarstiQ> hmmmm
[17:07]  * LarstiQ wonders about a /dev/null foreign vcs
[18:33] <Jesse> good evening london
[18:35] <Jesse> hi?
[18:48] <jesse_1> hi
[18:48] <luks> hi
[18:49] <jesse_1> is it possible to configure bazaar to use a username for ssh to certain hosts?
[18:49] <jesse_1> i tried authenticantion.conf
[18:49] <jesse_1> but bzr still uses the $USER value
[18:49] <luks> I don't know, but on unix with openssh you can use ~/.ssh/config
[18:50] <jesse_1> aha
[18:50] <jesse_1> dumb me, i thought everything's configured in bzr
[18:50] <jesse_1> i am still confused why authentication.conf didn't work
[18:51] <jesse_1> i am using private key for sftp, but am tired of typing my username in the url
[18:51] <jesse_1> so i put a section in my auth conf
[18:52] <jesse_1> with scheme, user & host
[21:37] <darkhole> Hi everybody...
[21:37] <darkhole> I need some help, about Eclipse+Bzr
[21:41] <darkhole> ??