[00:04] I'm having strange locking problems on MacOS X where bzr is complaining about a lock being held — but it's the same process [00:04] This is with 2.3.0 [00:04] I have a branch bound to another branch, that is itself bound to another branch [00:04] It's complaining trying to acquire a lock to the third branch [00:05] That sounds like a familiar issue [00:05] I'll see if I can find a bug report about that [00:07] If there's something horribly wrong in my last post to the list, someone please correct me. [00:09] briandealwis: it might be related to https://bugs.launchpad.net/bzr/+bug/412223, but I think there's something specific to 2.3.0 because I think there's been a small spike in reports of it happening [00:09] Ubuntu bug 412223 in Bazaar "bzr up locks master branch" [High,Confirmed] [00:10] briandealwis: I can't find an obvious bug about it though, so I guess file a new report. Maybe we've regressed in how we handle a bound branch of a bound branch? [00:10] spiv: I don't think that's right. At least all my branches are local and fully-qualified [00:10] And I just unbound the second level, and it's still occurring. [00:10] Weirdness. [00:10] Indeed! [00:14] spiv: hmm, I'll have to dig into this tomorrow. It doesn't seems to only happen with a particular branch pair [00:15] briandealwis: ok. I think the contents of the .bzr/branch/branch.conf files would be particularly interesting [00:15] spiv: the only thing that's different is that I have some post-commit hooks to trigger a hudson build [00:16] Oh, and the traceback, of course :) [00:21] How do I force a branch back to a previous version? "bzr pull . -r −1" doesn't seem to do it… [00:22] jelmer: when you are around [00:22] https://bugs.launchpad.net/loggerhead/+bug/728691 [00:22] Ubuntu bug 728691 in loggerhead "loggerhead NoSuchRevision: KnitPackRepository exception" [Undecided,Incomplete] [00:25] ah, —overwrite it the key: "bzr pull . —overwrite -r −4" [00:27] mgz: replied :) [00:27] briandealwis: yep, --overwrite [00:28] lifeless: hi [00:28] lifeless: hmm [00:29] spiv: aha, there was a generic method, thanks. what's still not clear to me is what initialisation steps need/should really be done first. [00:29] lifeless: Is there actually any reason for that method to use revision_trees() rather than get_revision_delta() ? [00:29] jelmer: good question [00:29] jelmer: that may be addressed by jams historydb work [00:30] mgz: just bzrlib.initialize(), IIRC [00:31] with bzrlib.initialze(): do stuff [00:33] spiv: I put the branch.conf and .bzr.log at http://pastebin.com/cmv6ZWqv [00:33] spiv: I thought it might be related to a plugin, but doesn't seem to be [00:34] is that true even with hooks? you can't use run_bzr like that because it doesn't know about the commands, do any of the command objects themselves depend on hooks that aren't installed by default? [00:35] mgz: there is an entry point for running commands that adds the bzr-internal command hooks [00:35] mgz: its what the bzr script calls [00:36] but it's not part of initialize. [00:36] right [00:37] commands.install_bzr_command_hooks [00:37] which is called by run_bzr_catch_errors [00:37] and run_bzr-catch_user_errors [00:38] which is called by main() [00:38] mgz: start with bzrlib.commands.main() [00:39] one of the important bits there seems to be _register_builtin_commands which doesn't have a public alternative as far as I can see. [00:39] nope [00:39] briandealwis: hmm, could you add -Dlock to the command line and paste the .bzr.log from that? That should tell us where the locking is happening. [00:39] mgz: thats more plumbing :) [00:40] mgz: if you want to use the inbuilt command dispatch, calling main() is the key [00:42] spiv: log at http://pastebin.com/68x4VM1n [00:42] spiv: oops, that didn't work [00:43] spiv: sorry, try this: http://pastebin.com/JptmhQUT [02:36] hello, i found this plans http://doc.bazaar.canonical.com/developers/colocated-branches.html for 2.4 what is the state of this ? [02:47] ovnicraft: jelmer has the most up to date info I think [02:48] ovnicraft: IIRC, most if not all of the core infrastructure in the code now exists [02:48] ovnicraft: so what's left is mainly the UI [02:54] we have problems with all modules in our repo each module/directory has dependencies each other i was thinking in a module to manage this and canc clone just the dep [02:54] i need colocated for this ? [02:54] can* [02:57] lifeless, ping [02:58] beuno: hi [02:58] lifeless, hey! [02:58] so, I got into loggerhead hacking again [02:58] trying to get this tarball thing proposable [02:58] I've got it working [02:58] have you looked at launchpad_loggerhead? thats the glue we use to run lh in lp [02:59] now, I'm trying to figure out what the best way to make it easy for LP to turn it off [02:59] I haven't in 2 years I think [02:59] ovnicraft: there are some existing plugins that may help you [02:59] beuno: you should [02:59] lifeless, where can I grab that from? [03:00] spiv, maybe a clue [03:00] beuno: because we'd turn it off from there, whatever the mechanism - we'd be adding the hook or $whatever [03:00] beuno: lib/launchpad_loggerhead [03:00] ovnicraft: bzr-colo, bzr-colocated, bzr-scmproj [03:00] lifeless, that assumes I have the LP tree :) [03:00] beuno: yes, yes it does [03:00] lifeless, lets pretend I don't [03:01] beuno: we have loggerhead running on lp [03:01] bazaar.launchpad.net/~launchpad-pqm/launchpad/devel [03:01] beuno: I hear you can browse via it [03:01] spiv, yes i am checkin' bzr-colo so i need your opinion here to manage this if i am clear [03:01] sounds like en evil technology [03:01] managing dependencies using colocated and write a plugin [03:02] ovnicraft: easiest way to make it fast is to setup one, or perhaps several, shared repositories [03:03] ovnicraft: then use bzr-scmproj - the repository will cache data locally for you [03:04] ovnicraft: I agree with lifeless; my guess is bzr-scmproj will either do what you want or be a good starting point for building what you want. [03:05] sound ok i want to do something like bzr branch lp:project --myproj-modulename [03:06] and maybe gets another modules [03:06] like bzr pull --myproj-anothermodule [03:06] ovnicraft: I wouldn't think colocated branches would be a natural fit for managing a collection of different modules and their dependency relationships. It seems to me that colocated branches are better suited to tracking multiple versions of a single project (e.g. to have all of bzr 2.0, bzr 2.1, bzr 2.2, bzr 2.3 and bzr trunk branches). [03:08] in that ways looks better so the problem is when cloning (if plugin exists) need just a copy from module and their deps [03:09] and can pull more modules [03:49] lifeless, up for a loggerhead review? [03:52] anyway, sleep now [03:52] jam, if you happen to be around, https://code.launchpad.net/~beuno/loggerhead/export-tarball/+merge/52797 [03:52] oooops [03:52] this branch has things committed it shouldn't [03:53] gar... in the first revision [04:07] ok, really sleep now [04:08] * beuno waves [04:30] vila: hmm, 16 package imports failing due to LockContention? That seems odd. === Ursinha is now known as Ursinha-afk [06:43] spiv: not fully there yet, but didn't bzr get upgraded on jubany ? [06:49] spiv: there have been a few bugs around LockContention lately (one in particular has to do with connection reuse in builddeb ?) [07:22] ok, I'm in, spiv ? [07:39] vila: there's an rt for upgrading bzr on jubany, but it hasn't been done yet IIRC [07:39] rt 44398 [07:40] bzr version says 2.3b5 (which in itself is pretty weird, why b5 ???) [07:43] ha right, so this points to bug #726854 which indeed mentions reusing transports (I didn't dig that though) [07:43] Launchpad bug 726854 in SABnzbd "Upgrading queue from 0.5.x to 0.6.0 can fail" [Critical,Fix released] https://launchpad.net/bugs/726854 [07:44] vila: specifically I saw LockContention on a local branch, though [07:44] vila: http://package-import.ubuntu.com/status/udev.html#2011-02-24%2020:39:43.444410 [07:44] grr bug #726584 [07:44] Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/726584 [07:45] *local* branch ? Urgh [07:50] vila: Hi. I think I'll rename bzr.webdav now, since there have been no objections [07:50] maxb: please do ! Sorry I didn't find the time to do it myself :-/ [07:51] not a problem [07:51] * vila is still fighting to unbrick a natty vm... [07:51] nothing too vital trapped inside it, I hope? [07:51] no, it's ok [07:51] what is a 'held package' ? [07:51] A virtual brick? [07:53] update-manager is telling me: E:Error,pkgProblemResolver::Resolve generated breaks, this may be caused by help packages... [07:53] spiv: :) [07:57] vila: A held package is one which has been placed on hold in aptitude or dpkg by the local sysadmin, to prevent automatic upgrades [07:57] urgh, I can't remember doing that, how can I find it or them ? [07:58] dpkg -l | egrep ^h [07:59] empty :-/ [07:59] I guess held packages aren't the problem then! [07:59] My general advice on encountering any sort of dependency chaos is that the interactive curses mode of aptitude is a wonderful tool :-) [08:00] ha, let me try that [08:01] * vila restores last backup [08:02] the nice thing with vms is that they are easy to restore, just use the whole disk backup :) [08:02] ok, that's 6GB, but still :D [08:27] morning vila, evening spiv [08:27] hi jam [08:30] out of curiosity, what tools to bzr developers use for development? vi, eclipse or something else? [08:37] mr-russ: depends on the dev [08:37] mr-russ: most are vim, at least one is emacs [08:43] mr-russ: If I was using an idea, it would probably be Wing. Lots of good stuff there, but their VI-mode was lacking [08:43] It might have gotten better since [08:43] it was a year or two ago [08:43] IDEs can be great, but VIM just rocks as a text editor [08:44] I've just never found a comfortable tools on linux that feels like I'm doing things fast. vi is pretty good, but my skills ain't brilliant, especially with shortcuts for going into functions and back, like ctags [08:45] ^] [08:45] or you're saying you know that but don't feel great with using it? [08:45] Once you have vim muscle memory, it is pretty hard to use another editor, IME [08:45] jam: I'd love to see you write code: wing - Galaga-like arcade game [08:46] WingIDE [08:46] http://wingide.com/ [08:46] Aw, that's no fun at all. [08:46] soren: but yes, that would be pretty awesome [08:46] squashing bugs in real time, baby [08:57] maxb: unbricked ! I had to reinstall the vbox additions which confused me for a bit though [08:57] maxb: thanks for the aptitude trick ! [09:15] "Branch to merge into, rather than the one containing the working directory." Does anyone understand that? I don't [09:15] (from bzr merge --help) [09:15] mok0: yes, almost everybody :) [09:15] mok0: by default you merge in the directory you're working [09:16] vila: ah, yes I see :-) [09:16] vila: that help text could be better though :-) [09:16] mok0: if, for whatever reason, you want to merge into *another* directory than the current one, you use -d [09:16] mok0: certainly [09:16] vila, I'd prefer (cd ../otherdir ; bzr merge ) [09:17] mok0: so you don't need -d [09:17] vila: right [09:17] mok0: but if you have a good idea for a better phrasing, patch welcome ! [09:18] vila: patch? That would take me an hour [09:18] vila: I can submit a bug [09:19] bzr branch lp:bzr ; hack hack, bzr commit ; bzr push lp:~/bzr/better-merge-help ; bzr lp-propose ; done [09:19] mok0: sure, a bug is a good starting point [09:19] vila: I could try. Never hacked on bzr before [09:27] vila: heh lp is down [09:27] mok0: ooohhhhhh, paaaaaaaaiiiiinnnn [09:28] vila: actually, what I was looking for is a "dry-run" switch for merge [09:28] mok0: db upgrade in progress, should be back in ~90 minutes at max :-/ [09:28] mok0: --preview [09:29] mok0: http://identi.ca/launchpadstatus for tracking lp status [09:30] vila, oh, thanks. I got so puzzled at the -d switch I didn't discover that... [09:30] mok0: :) [09:30] mok0: almost all bzr commands accept a -d switch [09:30] vila: I am slowly trying to become a more sophisticated bzr user. Not doing too well ;-.) [09:31] mok0: take your time ;) [09:31] vila: I guess the -h texts are not the best avenue for that endeavour [09:32] vila, will --preview give me an indication of potential conflicts? [09:32] mok0: well, they should. They are supposed to help... May be not the newcomers that may be better served by http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html but still [09:32] Because sometimes I'd like to put off a merge if there are conflicts [09:33] yes, --preview will tell you about conflicts [09:33] vila, I've read those docs many times [09:33] vila: but my brain is old and fragile [09:34] yeah, brains tend to become fragile when you get old, but they are also supposed to be more effective ;) [09:34] vila: perhaps what I need is a reference-manual type document, with examples [09:34] vila: effective? I guess... I am still going pretty ok at 10% capacity :-) [09:35] wow, indeed, if you're able to discuss with *me* at 10% capacity, that's surely a good sign :D [09:35] vila: the tutorials are fine for getting started, but they never give you the full story [09:35] http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/index.html then ? [09:36] vila, perfect! Bookmarked! [09:36] http://doc.bazaar.canonical.com/bzr.dev/en/ is the starting point [09:37] vila, one problem I meet in my daily workflow is this: [09:37] or even http://doc.bazaar.canonical.com/en/ (except there is currently a bug there, 2.3 being the stable version, the links are valid, only the numbers are wrong) [09:38] I have upstreams subversion branch mirrored on LP. I have a packaging branch off that [09:38] upstreams branch contains a whole bunch of stuff that doesn't get into the distribution tarball ("make dist" tarball") [09:39] to avoid getting a huge .diff.gz file, I have deleted everything from the packaging branch that does not go into the dist tarball [09:40] that normally works fine, but when upstream has edited one of the "un-needed" files, I get conflicts [09:40] :-/ [09:40] I just need to resolve them, but it is a drag [09:41] Most of the time, the merge goes smoothly, but I'd like to check if a merge would generate conflicts ahead of time. So perhaps --preview can help me there [09:41] There are several works in progress to address that, including the ability to specify either globally or on a file-by-file basis that you don't care about modifications to deleted files [09:41] --preview should help [09:42] vila: ultimately, we shouldn't have to rely on tarballs for source packages, but... [09:42] you should also be able to say 'bzr resolve --take-this ' to resolve the conflict where is involved [09:43] mok0: that's call UDD, see https://wiki.ubuntu.com/DistributedDevelopment [09:43] * mok0 goes off to bzr reference manual to see :-) [09:43] vila: yeah, I've been tracking that now and then, but much of it goes over my head. [09:44] mok0: then this needs to be fixed [09:44] not your head... [09:44] vila: It is my religious belief that the packaging branch should be a child of upstream [09:44] vila: and some of the current practices are not like that AFAIU [09:45] vila: as like having debian/ in its own branch [09:45] mok0: I'm (still) not a seasoned packager myself, but I'd like to get there and yes, the idea is that upstream should be a parent branch [09:45] mok0: yup, we hope to get away from this practice as soon as it becomes *easier* to *not* use it [09:46] vila: I also haven't grasped looms yet, which seems to be central in the whole patch thing [09:46] mok0: looms are discussed indeed but needs some polish to be fully usable [09:46] vila: ... unfortunately 3.0 (quilt) seems to have consolidated the way patches are treated [09:47] mok0: think of looms as a stack of branches with upstream at the bottom [09:47] vila: sort of like git? [09:47] git branches? [09:48] no, git branches are more like colocated branches where you switch from one branch to the other without any enforced relationship between them [09:49] vila: I guess I should just try looms. I've put it off, because I've read (like you said) that looms "need some polish" [09:49] colocated branches help using a single working tree when ... it matters. It can be because it's expensive to maintain (lots of compilations), it can be a convenience [09:49] mok0: they need polish for the udd case, I use them daily myself [09:49] I see [09:50] Perhaps I should just try them. Doesn't it add another layer of complexity? [09:50] mok0: you can think of them as an alternative to quilt (IIUC) where each patch is turned into a branch (and as such get an history) [09:50] mok0: it depends on your workflow [09:50] vila: hm, that sounds useful. I use quilt a lot [09:51] vila: I am patching upstreams code quite a lot, and I keep all my changes in quilt patches [09:51] I use looms when I want to work on a bug feature for a long time and create threads for pieces I can submit for inclusion in trunk [09:51] s/bug/big/ === Ursinha-afk is now known as Ursinha [09:51] vila: threads? Uh-oh, another concept.. :-) [09:52] vila: so, can I use looms in one branch and not another? [09:52] mok0: a loom is composed by threads, a thread is just a funny name for a branch but with a name and a position in the loom [09:52] mok0: yes, you can go from branches to looms [09:53] vila: so looms replace branches? [09:53] mok0: one part that need polish in looms is when you want to collaborate on looms, merging looms is... not implemented yet for example [09:53] vila: ah, so they're for personal use [09:54] well, technically they are a branch format [09:54] mok0: in their actual state, they are safe to use for personal use, there are some rough edges when you try to share them [09:54] vila, so I can make a child branch and turn that into a loom? [09:55] mok0: pipelines are an alternative that some people prefer [09:55] yes [09:55] bzr loomify [09:55] err [09:55] vila: and what will LP say to that? [09:55] For example, when I start a loom, I do: [09:56] bzr branch lp:bzr new-stuff [09:56] cd new-stuff; bzr nick bzr.dev # to track trunk [09:56] bzr create-thread stuff [09:57] from there I have two threads in the loom, I'll use the 'stuff' one to develop my new feature and commit there [09:57] when I want to resync with trunk I do: bzr switch bzr.dev ; bzr up-thread [09:57] err [09:57] when I want to resync with trunk I do: bzr switch bzr.dev ; bzr pull -v ; bzr up-thread [09:58] vila: "up-thread" ? [09:58] the pull will update by base thread to the current version of trunk and 'up-thread' will merge my changes onto this new trunk [09:58] it's a command provided by the loom plugin [09:58] and lp knows about looms so you can push there like any other branch [09:59] vila: it does sound a bit like a git-like workflow [09:59] vila: beneath a bzr branch [09:59] mok0: you mean rebase ? [10:00] vila: no, I mean like having a stack of branches in a single directroy [10:00] AFAIK with git you get a *set* of branches, not a stack [10:01] vila: ah yes, that's true [10:01] vila: so with threads, you can only merge "down" ? [10:01] well, up :) [10:01] :-D [10:02] vila: and when you do that, the stack becomes lower? [10:02] well, the pointer goes up [10:03] each thread is fully included in the upper ones [10:03] vila: but the bottom two threads will then be identical? [10:03] if they are you use combine-threads to delete the upper one, it means you don't carry changes anymore in this thread [10:03] it happens when the changes have landed on trunk [10:04] vila: It's starting to dawn... [10:04] it's a bit like maintaining a series of patches except you keep track of the history (roughly) [10:05] vila: that sounds very useful [10:05] vila: I should "just try it" [10:07] vila: so I am maintaining my patches in quilt in the packaging branch. Where should I have the looms though? In "trunk" or in "ubuntu"? [10:08] mok0: vast question :) [10:08] vila: I was afraid so :-) [10:09] mok0: the current theory is that you work in a loom with the following threads (starting from bottom): upstream, debian packaging, ubuntu packaging [10:09] now, for the quilt patches, you can also add one thread by patch [10:09] and that's where the discussion is roughly as there are various ways to handle the quilt patches with or without threads [10:10] vila: but when you do "bzr builddeb" you need the debian/patches directory to be populated [10:10] mok0: and I can't say much more on the topic as I don't know quilt :-/ [10:10] vila: quilt just manages a stack of patches [10:10] mok0: you'll need a better packager than me to answer this one ;D [10:11] perhaps bzr builddeb know how to deal with looms [10:11] mok0: the idea is that it's better to work with the patches applied than working with diffs of diffs [10:11] mok0: not yet (AFAIK) [10:12] * maxb eeps at the size of scrollback.... what's the unanswered question, and can I help? :-) [10:12] mok0: but the plan is to teach builddeb to (hand waving) make it easier :D [10:12] vila: I think just needs to try it [10:12] mok0: maxb is a *far* better packager than me for one ;) [10:13] vila: that would be cool. But of course packaging policies are decided in Debians dungeons [10:13] maxb: we are discussing packaging using looms [10:14] maxb: and I am asking more questions than 20 geniuses can answer :-) [10:14] Yes it's all a bit of an unresolved question [10:15] I think some people see a utopia where quilt series get mapped into looms, such that you keep history of the patch series too [10:16] maxb: I described my branchs 25 minutes ago (10:38 my time) [10:16] *gah*, I am being summoned afk, sorry [10:16] maxb: ah [10:16] maxb, let me copy-paste a bit [10:18] maxb, http://paste.ubuntu.com/578269/ [10:20] maxb: I also asked vila on advice for maintaining my patches and we discussed looms [10:29] On the subject of the pastebin, that's a tricky one. [10:29] I think bzr core could use some way of being told that files are being deleted and you really don't care what upstream does with them from then on [10:30] However, you might be interested in using bzr-builddeb [10:31] If, instead of merging normally from the upstream import, you use its merge-upstream command, it will not only help you track what is in the tarballs, but will embed pristine-tar metadata in the packaging branch such that original tarballs can be rebuild from it [10:31] It goes like this: [10:32] bzr merge-upstream --version upstream-version path-or-url-to-upstream-tarball path-or-url-to-upstream-import-branch -r tag:the-tag [10:33] When you do this, bzr-builddeb will commit the contents of the tarball, associating it as a merge commit with the revision in the upstream import branch specified by the -r switch [10:34] maxb: but I really think as a matter of philosophy that the packaging branch should be a child off upstreams branch [10:34] morning [10:35] As for the looms, I'd be tempted to loomify the packaging, and simply not bother with a quilt series at all [10:35] maxb: ah, didn't read your last comment properly [10:35] I would use debian/source/options to put dpkg into single-debian-patch mode [10:35] maxb: but I need a quilt series once the package is created? [10:36] mok0: ish. your series can contain a single monolithic patch [10:36] maxb: single-patch mode? [10:36] ah [10:36] maxb: like the old diff.gz file [10:36] googling for reference, one moment [10:37] Point number 4 in http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/ [10:37] * mok0 looks [10:38] maxb: I've been avoiding 3.0 (quilt) ... I think it sux [10:39] i'm struggling to understand what initiates the execution of post_change_branch_tip hooks [10:39] This mostly makes it unsuck by making it behave like 1.0 :-) [10:40] i have configured one, and if i commit or push locally, it is executed, but if i push to the server remotely it is not [10:40] maxb: I like the idea of debian/ in a tarball, but it is really unmanageable that unintentional changes to your source tree finds their way into debian/patches. That really sucks [10:40] maxb: I usually do a quick lsdiff -z ...diff.gz to check that nothing but debian/ is added [10:41] catphish: Your hook is installed for the user that the server is executing as? [10:41] maxb: with 3.0, I need to unpack the debian tarball and go look [10:41] yes [10:47] i am executing with -Dhooks [10:47] but that doesn't tell me that they're trying to be executed [10:48] http://paste.codebasehq.com/pastes/0177vm21a108 [10:50] it works if i push to the same repository locally, but not remotely over bzr serve --inet [10:57] jelmer: before I forget: it would be nice if you could add an entry in the what's-new for 2.4 about the bunch of changes related to both the weave-as-plugin and the foreign plugins being better tested [10:58] jelmer: may be more than one entry in fact;D [11:18] vila: any idea who i should talk to regarding hooks? [11:19] i'd read the code if i were just a little smarter [11:20] catphish: lunch time right now, bbl (I'm freezing 2.3.1 though) [11:20] catphish: but first things first, make sure you get the right code on the server when testing for hooks and remember that paths may be different (if you use them to parametrize your hooks) [11:21] ooo 2.3 1 :) [11:21] right code? [11:21] anyway enjoy lunch [11:22] i'd enjoy lunch more if i were in france i think [11:25] vila: Sure [11:26] vila: weave as a plugin hasn't really landed (yet) though [11:33] jelmer: last I looked at the mp I understood you wanted to push some more changes or split it, should I look again ? [11:34] catphish: hehe, back, very quick lunch, light, but prepared by my daughter which gave it this invaluable love touch ;) [11:34] :) [11:34] vila: Yeah, that's still the case (unless you feel like reviewing a 4k-line branch :)) [11:35] jelmer: not *that* much ;) [11:43] catphish: ok, so given your pastebin it looks like the code is in the right place, to be extra sure, you can try 'bzr plugins -v' on the server to check which plugins are seen there [11:44] yeah it shows up in bzr plugins [11:44] catphish: there may still be some env variations between your shell and your server but if the log comes from the server, you should be good [11:44] that log i pasted it generated when pushing through the web server [11:44] ok, so I don't know the shellhooks plugin, how do you associate actions with branches there ? [11:45] http://paste.codebasehq.com/pastes/5ngeu2bx9wxb [11:45] hmm, the author's name rings a bell :D [11:45] lol [11:45] i rearranged it to be a little simpler for my needs [11:47] and if i push locally between 2 directories, the hook runs [11:47] right, so the idea there is that the hook is always called and pass the basedir to the shell script ? [11:47] locally == on the server [11:47] correct [11:48] the plugin isn't installed on the client machine [11:48] hey ! if you push locally you don't involved the server code no ? [11:48] that's also correct [11:48] pushing locally between dirs on the server is 100% bzr code [11:49] ie. "bzr push /path/to/repo" [11:49] hmm, so you probably don't use the right hook or the hook is not implemented correctly server-side [11:50] ok, so the doc explicitly mention the server for post_change_branch_tip [11:50] Possible gotchas: 1) environment you're running 'bzr serve --inet' in might see different plugins? 2) paths the server sees might not be what you expect (chroot transports and such) [11:51] spiv: the plugin doesn't filter the paths, it just pass them to the called shell command (AFAICS) [11:51] I'm about to go to bed, but hopefully that's enough clues for vila to work with :) [11:51] hehe [11:51] vila: what happens if the transport.base is 'chroot+1234://...'? [11:51] spiv: that the ones I started with but thanks for confirming :D [11:52] ooh... [11:52] wow: return ! [11:52] that'll probably be it! [11:52] i assumed it would get file: [11:53] catphish: here you are, the plugin doesn't suit your needs, the hidden assumption is that it's used only for the client for local paths [11:53] In the API it's not too hard to go from a chroot-decorated transport to the underlying file path [11:53] The shellhooks plugin probably ought to do that on behalf of the shell commands though. [11:53] i can easily rework the plugin now i know what the problem is [11:54] (assuming that's what the problem is :)) [11:54] catphish: no, add a print, but as spiv said, you probably get {chroot|filtered}-12321:// [11:54]