[00:01] <thomi> spiv: hmmm, I can't see how to get a rev_id for a give file_id in the branch.repository inventory
[00:03] <thomi> ahhh, this works (bug is kind of ugly): dict(inv.entries())[relpath].revision
[00:09] <thomi> spiv: got it! Are you able to tell me if I;m doing anything really wrong in this: http://pastebin.ubuntu.com/882561/ please?
[00:19] <lifeless> thomi: inv[inv.path2id(relpath)].revision
[00:19] <lifeless> I think there is a more direct one still
[00:21] <thomi> ahh, I didn't realise the inventory was usable like a dictionary :)
[01:05] <Pikkachu> hi, how can I keep an up-to-date reference in my code to submit or push branch?
[01:05] <Pikkachu> in the specific case, it's the branch url used as project home
[01:06] <Pikkachu> does bazaar allow to create a commit hook at least?
[01:07] <Pikkachu> or is it better to just write an enclosing shell script which performs the changes before committing (for example using sed)?
[01:15] <spiv> Pikkachu: you can create commit hooks, yes
[01:15] <spiv> Pikkachu: I don't entirely follow what you're asking for, though
[01:16] <spiv> Pikkachu: you want the text you commit to contain the location of the submit or push branch?
[01:38] <Pikkachu> no, I want every commit to trigger the references in code to be updated before the commit is performed
[01:48] <Pikkachu> I think I can enclose the commit with a previous look into .bzr and subsequent update of required files...
[01:48] <Pikkachu> with a shell script, I mean
[02:44] <Kamping_Kaiser> is it possible to diff one bzr branch against another branch at an arbitrary revision?
[02:44] <Kamping_Kaiser> i want to find out if foo/ (at rev 13) was merged into bar (at rev 191) at any point
[02:46] <spiv> Kamping_Kaiser: bzr help revisionspec, see revno:
[02:46] <spiv> Kamping_Kaiser: e.g. -r revno:13:foo/..revno:191:bar/ I think
[02:47] <Kamping_Kaiser> spiv: i'll have a try, thanks.
[03:02] <Pikkachu> thanks spiv anyway
[03:37] <spiv> Oh!  It sounds a bit like Pikkachu wanted keyword expansion.
[03:40] <mwhudson> noone really wants keyword expansion do they?
[03:40] <bob2> lots of people think they do though
[03:55]  * fullermd does.
[03:58]  * bob2 expands fullermd's keywords into merge conflicts
[03:59] <fullermd> I didn't say I want a crap implementation of keywords   :p
[04:00] <bob2> haha
[08:46] <poolie> hey all
[09:06] <vila> hmm, internet access issues here :-/ Rare but painful event, seems to to come from ADSL itself which is worrying
[09:10] <ggherdov> vila: totally OT, but you hit a point that bothers me when I have unstable connections: i am conversating over IRC, then I am cut off from the internet, the person I'm talking with continues writing, but I miss part of the chat. Is there any kind of "IRC buffering thing" I can install on a remote server I have (which has reliable internet), in order to proxy my IRC connection thru a "stabilyzer"?
[09:11] <mgz> morning all!
[09:12] <vila> ggherdov: probably what IRC proxies are about, I don't use one myself :-/ (On the other hand, since I'm connected via ADSL I think the availability have been like 99.999999% or something...)
[09:12] <vila> mgz: hey !
[09:13]  * ggherdov IRC proxies... interesting.
[09:13] <Peng> ggherdov: They're frequently known as bouncers.
[09:13] <ggherdov> Peng: good to know. thx.
[09:14] <Peng> ggherdov: Personally, I prefer to run a command-line IRC client, and I usually run it on something with a stable connection that I have SSH access to. (That's what I'm doing now.)
[09:16] <ggherdov> Peng: I see your point. But is the SSH part of the connection is faulty, you risk to miss stuff. You still need you remote-cmd-line-irc-client to buffer stuff for you, and send all the stuff you missed when it sees you again.
[09:16] <ggherdov> s/is/if
[09:17] <Peng> ggherdov: I use GNU screen, so the SSH connection doesn't have to be reliable.
[09:17] <Peng> Sorry, I should've said so, but I think of screen/tmux as a given when using SSH.
[09:17]  * ggherdov Peng got game
[09:17] <ggherdov> Peng now I see. wow a powerful combination
[09:18] <ggherdov> btw, using tmux since 2 months and it's a great util.
[09:18] <Peng> I've never tried tmux. screen's good enough for me.
[09:19] <ggherdov> Peng: I use tmux in order to split my terminal in several shell in a tiledfashion. didn't know of the fault tolerance thing untill now.
[09:19] <ggherdov> shells*
[09:19] <Peng> Ah. I don't tile stuff.
[09:20]  * ggherdov nobody's perfect :-)
[09:22] <Peng> :(
[09:41] <nigelb> Peng: tiling irssi leads to really really claustrophobic typing space :)
[09:43] <Peng> But but I need to IRC in six channels at once.
[09:44] <nigelb> haha
[11:02] <ggherdov> there was an option to 'bzr rm'  in order to bzr-remove a file that you had already bash-removed. what was that ?
[11:03] <jelmer> ggherdov: there is no special option necessary
[11:04] <jelmer> ggherdov: 'bzr rm' (without other arguments) should also pick that up
[11:04] <ggherdov> ah good.
[11:04] <ggherdov> thx jelmer
[11:04] <ggherdov> I was mixing up with 'bzr mv --after'
[11:29] <jelmer> vila: hah, the main user of .revision_history() is bzrlib.tests.per_branch.test_bound_sftp, but all tests there seem to be skipped for some reason
[11:31] <vila> jelmer: hmm, did I tyoped set_revisions_history ?
[11:31] <vila> in the line above ? yes :)
[11:31] <mgz> "Not a local URL"
[11:31] <mgz> fun.
[11:33] <vila> mgz: huh ?
[11:35] <vila> jelmer: so, having read your review (thanks !), I'm talking about *set_revision_history* not revision_history, probably related but still different beasts
[11:35] <mgz> we don't really have a way of detecting test success->skip regressions
[11:35] <mgz> without carefully watching babune test counts across runs
[11:35] <vila> jelmer, mgz: By the way, I didn't touch code deprecated in 2.5.0, I can't remember what our rule is ? n+1, n+2 ?
[11:36] <vila> meh, rule to delete code deprecated in series n that is
[11:36] <mgz> vila: what you did seems fine, 2.4 gone in 2.6 seems right
[11:36] <vila> anyway, there is still a bunch to remove before touching code deprecated in 2.5
[11:37] <vila> k, thought it was a bit conservative but since there is still a bunch to do before touching that...
[11:37] <vila> I think I saw code that was deprecated without any version attached which is... bad :)
[11:43] <vila> but again, let's get rid of what we can safely remove first
[11:44] <mgz> jelmer: those tests seem too be skipping all the way back to 2.2
[11:46] <mgz> it might make more sense to work out what they're trying to do, write new tests, and delete the module
[12:36] <mgz> there's already bug 728252 for those tests skipping, so just proposed deleting them to reduce the chance of us rediscovering that again in future
[12:55] <mgz> "Ran 1 test in 102.260s" heh...
[13:08] <ams_cs> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps
[13:08] <ams_cs> anybody know what I can do about that?
[13:12] <jelmer> hi ams_cs
[13:12] <jelmer> ams_cs: can you provide some more background?
[13:13] <ams_cs> I'm trying to merge lp:gcc/4.7 into (a clone of) lp:gcc-linaro/4.7
[13:13] <ams_cs> I've tried it on two machines and get the same result, so it doesn't appear to be some local corruption
[13:18] <jelmer> ah, hmm
[13:18] <jelmer> I didn't realize those two branches had related history
[13:19] <jelmer> that usually indicates branches having a slightly different view on shared history
[13:19] <jelmer> can you file a bug? I'll try to look into it.
[13:19] <ams_cs> hmm, lp:gcc-linaro/4.7 was originally branched from lp:gcc/trunk
[13:20] <ams_cs> upstream branched 4.7 from trunk (in SVN) a week or two ago
[13:21] <ams_cs> doko imported the new branch as lp:gcc/4.7, but they should share history right up to the svn branch point
[13:21] <ams_cs> and lp:gcc-linaro/4.7 has not diverge far from lp:gcc/trunk
[13:39] <ams_cs> jelmer: any luck?
[13:41] <jelmer> ams_cs: still fetching the branches
[13:43] <ams_cs> jelmer: yeah, that'll take a while. BTW, there's no need to have a local copy of lp:gcc/4.7 to reproduce the problem ... although maybe to debug it
[13:53] <jelmer> ok
[14:23] <mgz> vila: did you file a bug for the bzrlib/locale thing?
[14:23] <vila> mgz: nope, sry
[14:24] <vila> mgz: this test_bound_sftp stuff is... worrying :-/
[14:24] <mgz> I think it's less worrying than it looks.
[14:25] <vila> how d'you know we're not reducing coverage here ?
[14:25] <mgz> because the tests have never (at least since 2.0) actually been run.
[14:26] <mgz> we certainly lack functional style testing on various real world things with both the smart server and other remote branches
[14:26] <vila> revno 5030 (2.1 => 4857, 2.2 => 5120) says otherwise (but I can't run the tests there due to some testtools/subunit issue)
[14:27] <vila> well, not 5030 but rather 5017.3.33
[14:27] <vila> but what worries me is that we didn't notice it earlier
[14:27] <mgz> we did!
[14:27] <mgz> spiv filed a bug :)
[14:28] <vila> # ?
[14:28] <mgz> linked from the mp.
[14:28] <mgz> bug 728252
[14:28] <vila> gha, I parsed that as added by lp :-)
[14:29] <mgz> anyway, deleting these certainly doesn't reduce coverage, and I don't think there's much worth salvaging from their logic
[14:30] <vila> ... color me confused but how to you know these doesn't reduce coverage ?
[14:30] <vila> s/to you/do you/
[14:31] <mgz> we have pretty good unit testing for bound stuff, and we know we have holes for functional testing
[14:32] <vila> ha, ok
[14:34] <mgz> vila: eg. bt.per_branch.test_branch.TestBound
[14:35] <jelmer> it does seem kindof odd to have these kinds of tests in bt.per_branch
[14:35] <mgz> we're not testing against remote branches, but that's been true for... ages
[14:35] <vila> yeah, yeah, I mis-interpreted :)
[14:35] <vila> indeed, looks like very old bb tests
[14:36] <vila> approved by the way
[14:38] <jelmer> uhoh
[14:38] <jelmer> I guess that means https://code.launchpad.net/~jelmer/bzr/remove-branch-history/+merge/97411 will conflict
[14:38]  * vila reviewing, was about to mention
[14:40] <mgz> jelmer: you made them run again?
[14:41] <vila> nope, he made them keep skipping ;)
[14:41] <vila> instead of erroring :)
[14:41] <mgz> well, I better win the race then :)
[14:42] <jelmer> well, I kept them around but at least avoided the calls to the functions I was removing
[14:42] <vila> which is a bit unfortunate :-/
[14:44] <vila> err, I mean, it's unfortunate you spend time on them not knowing they were skipped anyway
[14:44] <jelmer> vila: in what way? It should be trivial to resolve the conflict..
[14:44] <jelmer> ah
[14:44] <jelmer> well, not the worst thing in the world :)
[15:06] <Pikkachu> what a straightforward way to make automated pre-commit (1) validations and/or (2) source code modifications? I'm just thinking of using shell script or the like
[15:11] <LarstiQ> Pikkachu: you could look at how the bzr-text-checker plugin works
[15:31] <ams_cs> jelmer: any news?
[15:38] <jelmer> ams_cs: I'm still looking, but I'm pretty sure it'll take a couple of days squash this bug. I'm not really familiar with this bit of the code.
[15:38] <jelmer> ams_cs: I'll file a bug about it and subcribe you - who are you on Launchpad?
[15:38] <ams_cs> ams-codesourcery
[15:39] <ams_cs> jelmer: thanks, I was hoping there'd be a work-around :(
[15:40] <alansaul> If I push over the top of a respository, can get get the previous one back?
[15:45] <jelmer> alansaul: yes, by using "bzr pull -rREV ."
[15:45] <jelmer> alansaul: yes, by using "bzr pull -rREV . --overwrite"
[15:47] <mgz> one jelmer always tells the truth, and the other jelmer always lies
[15:47] <mgz> how can you tell which command to run?
[15:47] <alansaul> Lol
[15:47] <alansaul> Uh oh
[15:48] <mgz> okay, so maybe I'm an idiot, and someone would have pointed the problem out by now if it was actually the case but...
[15:48] <mgz> don't the .mo files never actually get installed?
[15:49] <mgz> so... all that translation stuff we did for 2.5 isn't actually enabled?
[15:50] <vila> mgz: as in: on debian/ubuntu you mean ?
[15:50] <mgz> well, I'm looking at the code in setup.py
[15:51] <vila> I thought we had bug reports about that and that you even fixed some of them... may be we are 2 idiots :)
[15:51] <mgz> it may be that the way debian builds it the files are included, but they don't seem to be in the windows installer
[15:51] <LarstiQ> how does gettext on windows work btw?
[15:51] <mgz> badly.
[15:52] <mgz> ehem...
[15:52] <vila> it misses a leg or two may be...
[15:52] <mgz> python has it's own implementation, so you just point it at a directory of specially arranged .mo files
[15:54] <vila> . o O (post-install tests)
[15:55] <mgz> hm, there are .mo files in python-bzrlib
[15:55] <mgz> so, however we're building for debian works somehow at least
[15:55] <vila> WARNING: gnome-keyring:: couldn't send data: daemon closed connection
[15:56] <vila> while running the full test suite
[15:56] <vila> does that ring a bell ?
[15:56] <mgz> but the code seems to need the build artefact to exist at setup.py invocation to include it
[15:56] <mgz> which... implies you must run setup.py twice for it to function
[16:01] <jelmer> mgz: translations seem to work here..
[16:02] <mgz> jelmer: how do you build for debian exactly?
[16:02] <mgz> the intersection of makefile and setup.py is a little confusing
[16:03] <mgz> I'm trying to fix the inplace creation of .mo files but don't want to accidentally break you.
[16:04] <jelmer> mgz: don't worry about that
[16:08] <mgz> oh but I do :)
[16:24] <Pikkachu> sorry, pidgin crashed, who was talking to me?
[16:24] <Pikkachu> the text checker plugin seems overkill
[16:39] <LarstiQ> Pikkachu: sure, but the interest for you is the pre-commit machinery?
[16:41] <wgz> what was that thing from lifeless about not using "should" in bug titles?
[16:42] <wgz> I'm struggling to phrase things without it
[16:43] <jelmer> wgz: I think the point was mainly that bug reports should primarily describe problems
[16:44] <jelmer> as opposed to a ticket tracker I think
[16:45] <LarstiQ> wgz: I find that hard too
[16:45]  * LarstiQ looks it up
[16:47] <wgz> I think it was on google+ so good luck ever finding it again...
[16:51] <Pikkachu> LarstiQ: I don't want a machinery that's why it's overkill, I want some simple concept
[16:52] <Pikkachu> LarstiQ: I don't need to set up and configure any machinery for using an enclosing shell script with the custom rules for each branch, for example
[16:53] <Pikkachu> wgz: maybe because it's implied
[16:53] <wgz> Pikkachu: that's contradictory
[16:54] <Pikkachu> how so?
[16:54] <wgz> you want to do something pre-commit, but not have to worry about any machinery for doing things in response to actions?
[16:54] <LarstiQ> wgz: actually, it is the second hit on "bug should" in my circles
[16:55] <Pikkachu> wgz: I mean for example "Bazaar should grep revisions from diffs" => "Grep revisions from diffs in Bazaar"
[16:55] <LarstiQ> wgz: https://plus.google.com/u/0/105660309458564946897/posts/BLhnbgoouXV
[16:55] <Pikkachu> wgz: ah you mean my case, ok
[16:55] <wgz> LarstiQ: logging in and being in Robert's circle is cheating :)
[16:55] <Pikkachu> wgz: it's not contradictory, it's you who's not understanding
[16:56] <LarstiQ> wgz: isn't that how you find stuff on g+? ;P
[16:56] <LarstiQ> Pikkachu: could you explain some more what you're trying to do?
[16:57] <wgz> Pikkachu: I mean, sure you can write a shell script that does something and then calls bzr commit, and use that rather than commit itself
[16:57] <Pikkachu> wgz: doing complex things may require a machinery setup or not, making the former case unnecessarily complex, that's what I mean. In this specific case, I don't want to depend on some plugin installed and configured for anyone willing to commit to the branch. This can be completely avoided
[16:58] <Pikkachu> wgz: the shell script has the advantage of not requiring any installation, it's self-contained in the branch and ready for use for anyone who branches the repo
[16:59] <wgz> provided they remember to run it instead of using commit
[16:59] <Pikkachu> wgz: READE.BEFORE.COMMITING :)
[17:00] <Pikkachu> wgz: or seriously, for a single file branch, commit.sh will call user's attention unless he's dumb
[17:00] <wgz> doesn't seem that different from having an instruction in there to cp commit_hook.py to ~/.bazaar/plugins
[17:01] <wgz> but whichever you like.
[17:01] <wgz> it would be nice to have a better mechanism for branch-specific thingies, but there are reasons it hasn't happened
[17:02] <Pikkachu> wgz: that's why I was looking for a even better solution, but pre-steps like installing and configuring stuff *so that* I can achieve what I want is a non-go. This step can be completely replaced with a shell script already there and ready for using
[17:02] <wgz> mostly because the idea of branching something then meaning it automatically runs arbitrary code when you do some operation is scary
[17:02] <Pikkachu> wgz: I think a more straightforward solution was if I was able to register a commit hook natively within the branch without any external setup required
[17:02] <wgz> there are a few threads on the bazaar list on this topic
[17:03] <lamalex> jml, with testtools, what's the proper matcher to ensure something is not None?
[17:03] <jml> lamalex: assertThat(x, Not(Is(None)))
[17:04] <Pikkachu> wgz: I'd be really surprised that bzr does not support commit hooks though
[17:04] <wgz> it does, you just need to manually install them, for the above reason.
[17:04] <jml> lamalex: I guess if you wanted to you could define 'IsNotNone = Not(Is(None))' and then do assertThat(x, IsNotNone)
[17:05] <lamalex> ha right
[17:05] <lamalex> thanks
[17:05] <lamalex> i wasn't reading carefully and skipped over Not :P
[17:05] <lamalex> whoope
[17:10] <Pikkachu> wgz: manually install? how so?
[17:13] <wgz> as mentioned, `cp commit_hook.py ~/.bazaar/plugins/commit_hook.py` or similar.
[17:14] <wgz> probably want `mkdir -p ~/.bazaar/plugins` first.
[17:16] <wgz> if you desperately want to write your checking logic in shell you'd have to use subprocess from the commit hook callback
[17:22] <wgz> jelmer: you're the man today. or maybe the page?
[17:25] <Pikkachu> wgz: I have no idea what to put within that file
[17:25] <Pikkachu> wgz: besides a hook should be a hook not what the hook holds
[17:25] <Pikkachu> wgz: a hook is supposed to just trigger something, not be that very something
[17:26] <jelmer> wgz: eheh
[17:26] <jelmer> wgz: This coming from somebody with surname that's just begging for VCS-related puns?
[17:27] <jelmer> *a
[17:27] <Pikkachu> wgz: I mean something like $bzr add-hook --pre-commit --system "commit-validation.sh"
[17:27] <LarstiQ> Pikkachu: in my hazy memory something like that exists
[17:28] <jelmer> Pikkachu: that is what this is, except it is in Python, not shell.
[17:28] <wgz> Pikkachu: LarstiQ was trying to help you earlier linking an example
[17:28] <Pikkachu> wgz: or $bzr add-hook --post-commit afterCommitting => afterCommitting.py, run it directly from within python instead of catching output/return value from a system executable
[17:28] <jelmer> Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons.
[17:29] <Pikkachu> jelmer: if it's like wgz is saying, then it's not really a hook, it's a plugin which catches commit events
[17:29] <LarstiQ> Pikkachu: branch.Branch.hooks.install_named_hook('pre_commit', pre_commit_hook, 'text-check')
[17:29] <wgz> apart from a slightly different wrapper, I don't see the difference
[17:30] <Pikkachu> LarstiQ: 'text-check'?
[17:30] <LarstiQ> Pikkachu: that is from bzr-text-checker, it is the analog of your `bzr add-hook --pre-commit text-check.py`
[17:30] <Pikkachu> jelmer: what reasons
[17:30] <jelmer> Pikkachu: if I download a branch from somewhere, tweak it and then run "bzr commit" I don't want to run arbitrary code that came from that branch.
[17:30] <Pikkachu> LarstiQ: no it's not, mine is a command line, yours is python code
[17:31] <LarstiQ> Pikkachu: hence, analog
[17:31] <Pikkachu> LarstiQ: no
[17:31] <Pikkachu> LarstiQ: it may be analog but not in the sense I mean
[17:31] <LarstiQ> Pikkachu: and as I also said, I remember there being something to run arbitrary commands for hooks
[17:31] <Pikkachu> jelmer: that's easy to fix
[17:32] <Pikkachu> LarstiQ: ah thanks...that would be interesting....
[17:32] <jelmer> LarstiQ: there is bzr-shell-hooks, which allows you to define shell commands to run in .bzr/branch/branch.conf
[17:32] <jelmer> I haven't updated it in a long time though, so it may have bitrotted
[17:32] <LarstiQ> Pikkachu: apparently, it is called bzr-shell-hooks ;)
[17:33] <Pikkachu> jelmer: so you're the author? cool... by shell you mean any system command or the underlying shell like bash etc?
[17:33] <Pikkachu> is it my imagination or can plugins be installed within a branch?
[17:34] <LarstiQ> Pikkachu: you can have configuration for them in a branch
[17:34] <jelmer> Pikkachu: plugins can't be installed within a branch, they're installed in the users home directory
[17:34] <jelmer> Pikkachu: bzr-shell-hooks installs trivial hooks that can run commands configured in the branch
[17:35] <LarstiQ> jelmer: or well, you _could_ point BZR_PLUGIN_PATH at a branch
[17:36] <jelmer> LarstiQ: that's true
[17:37] <lamalex> hi im trying to write a push hook, and i want to get the author of the last commit
[17:37] <lamalex> really i want all the authors for each commit since the point where its parent was branched
[17:37] <lamalex> but just the one is fine for now :P
[17:37] <jelmer> lamalex: your hook should receive the relevant revision ids, which you can use to retrieve the revision metadata
[17:37] <lamalex> anyone have a tip? i see i can get the revision easily, but i dont see what i can actually do with that
[17:38] <jelmer> lamalex: The revision object has a .committer attribute which is just a string with the author name and email, and it has a .get_apparent_authors() method which returns a list of strings with authors
[17:38] <lamalex> ah nice
[17:39] <lamalex> so would i take that from my target branch
[17:41] <Pikkachu> LarstiQ: the BZR_PLUGIN_PATH seems a good idea if bzr-shell-hooks is lightweight, this way users would not be required to install it
[17:42] <jelmer> lamalex: yeah, usually. since you're sure the revision is present there
[17:42] <Pikkachu> lamalex: how are you writing a bzr hook?
[17:42] <LarstiQ> Pikkachu: on the other hand, you might not want to forcefully override their plugin path
[17:42] <lamalex> Pikkachu, http://doc.bazaar.canonical.com/beta/en/user-guide/hooks.html
[17:43] <Pikkachu> jelmer: well, wasn't you who said about security risks? and yet has such a plugin like bzr-shell-hooks? :P
[17:43] <lamalex> jelmer, so do i just take that id and make a new revision?
[17:43] <LarstiQ> Pikkachu: are you confusing me with jelmer?
[17:44] <lamalex> Revision(id).get_apparent_authors
[17:44] <jelmer> Pikkachu: that's exactly why bzr-shell-hooks is a plugin, and not part of the core
[17:44] <jelmer> Pikkachu: also, I don't actually use bzr-shell-hooks myself.. it was just a quick hack a couple of years ago
[17:46] <Pikkachu> lamalex: that looks like non-branch specific
[17:46] <Pikkachu> no LarstiQ: "jelmer: Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons."
[17:47] <lamalex> Pikkachu, i have no idea what you're talking about. i'm guessing you pinged me due to a misunderstanding
[17:47] <Pikkachu> lamalex: we're talking about commit hooks, coincidently
[17:47] <jelmer> lamalex: e.g. something like target_branch.repository.get_revision(id) will return the revision object
[17:47] <lamalex> ah, im talking about push hooks
[17:47] <lamalex> but totally unrealted
[17:48] <Pikkachu> lamalex: I want a commit hook on a specific branch, not wherever I typ bzr commit
[17:48] <LarstiQ> Pikkachu: that's easily controllable with configuration
[17:53]  * LarstiQ eats dinner
[18:16] <Pikkachu> actually I will explain the exact problem:
[18:19] <Pikkachu> I have a pidgin plugin written in C which needs to provide an URL, I didn't care to register a project in LP so the URL is basically [...]/+junk/branch-name. But it happens that this URL is already contained in .bzr as push/submit branch. I want to keep source code always up-to-date with what's in .bzr. Any ideas?
[18:19] <Pikkachu> well, actually I think it doesn't matter that much it being in source code, more in the resulting builds...
[18:20] <Pikkachu> therefore I could implement this as a build step not a commit hook... but I don't want to use make because I would duplicate code from pidgin build environment which is mostly required anyway in windows
[18:20] <Pikkachu> so any ideas? thanks
[18:23] <jelmer> re
[18:25] <jelmer> Pikkachu: I'm not sure I follow what you mean; are you talking about changing the default locations for 'bzr pull' and 'bzr push' ?
[18:32] <Pikkachu> no... nevermind I think I'll resolve the problem myself
[18:48] <LarstiQ> Pikkachu: at build time you want to say "this code came from <here>"?
[18:54] <Pikkachu> at build time it would be like:
[18:55] <Pikkachu> plugin.c => #define URL "@@PLUGIN_URL@@", then
[18:56] <Pikkachu> something like using sed for replacing @@@PLUGIN_URL@ from what's within .bzr before compiling it
[18:56] <LarstiQ> right
[18:56] <LarstiQ> sort of like the `bzr version-info` use case, but with different data
[18:57] <Pikkachu> seems like not
[18:57] <LarstiQ> Pikkachu: where would the url come from? Is `bzr config parent_location` sufficient?
[18:57] <Pikkachu> $ bzr help version-info => Show version information about this tree.
[18:57] <Pikkachu> shows, does not change anything
[18:57] <LarstiQ> Pikkachu: read on
[18:58] <Pikkachu> ah sorry...
[18:59] <Pikkachu> nice to know about $ bzr config, I'm not sure if it's submit or push branch, but yes it's either of it
[19:01] <Pikkachu> unfortunately the submit/push urls are not available there :(
[19:01] <LarstiQ> Pikkachu: if they're not set probably not
[19:01] <LarstiQ> Pikkachu: but it depends on your workflow what will be in there
[19:02] <Pikkachu> the ones listed are {date} {build_date} {revno} {revision_id} {branch_nick} {clean}
[19:02] <LarstiQ> Pikkachu: e.g., in my bzr.dev copy submit_branch is not set, but in my 2.5-fixes branch it is
[19:02] <LarstiQ> Pikkachu: ah, in version-info?
[19:03] <LarstiQ> right, that is what I meant with "different data"
[19:03] <LarstiQ> Pikkachu: I wonder if it makes sense for version-info to include this data
[19:03] <Pikkachu> it includes the branch nick already
[19:04] <LarstiQ> Pikkachu: yeah, but that is more portable
[19:04] <LarstiQ> Pikkachu: it's actually contained in the commit data
[19:04] <Pikkachu> I don't get this command though, the example says it will *generate* a C header file?
[19:05] <LarstiQ> Pikkachu: in the example the template will give valid C syntax
[19:05] <LarstiQ> Pikkachu: and then you'd direct the output to, say, build_info.h
[19:06] <Pikkachu> but I don't think it meant to " produce a C header **file**", just a valid header string
[19:07] <Pikkachu> anyway, I think I can simply seek into .bzr anyway
[19:07] <LarstiQ> Pikkachu: that is more fragile, but if you want, yes
[19:08] <LarstiQ> Pikkachu: sure, the example is a valid header *fragment*. The common use of it would be as a single header file though. And of course your template can be more complicated
[19:09] <Pikkachu> I think the help message needs a small fix
[19:09] <Pikkachu> fragile in which sense, just missing to be there?
[19:10] <LarstiQ> Pikkachu: that, and in theory subject to change
[19:11] <LarstiQ> Pikkachu: what fix to the help message do you propose?
[19:11] <Pikkachu> LarstiQ: change what, the config format/location?
[19:11] <LarstiQ> Pikkachu: yeah
[19:11] <LarstiQ> Pikkachu: you're poking around in internals
[19:11] <LarstiQ> Pikkachu: that's always at ones own risk
[19:12] <Pikkachu> LarstiQ: fix: not mentioning it will generate a file, it just generates text output which is supposed to be placed separately into a file (from what I've got of what the command does)
[19:13] <Pikkachu> LarstiQ: I just forgot, I can use cd branch; url=$(bzr config push_location)
[19:14] <LarstiQ> Pikkachu: or even `url=$(bzr config -d branch push_location)`
[19:17] <Pikkachu> oh I tried without -d, cool!
[19:18] <Pikkachu> now the problem is: I reuse the whole pidgin build infrastructure, because most of it is required anyway
[19:19] <Pikkachu> a pidgin windows build environment contains everything a regular plugin requires, plus the ability to build them if you place them in the correct place
[19:20] <Pikkachu> I could duplicate the makefiles and make them point to pidgin root, but I think it's overkill
[19:20] <Pikkachu> hmm I just had an idea
[20:02] <Pikkachu> something like build.sh:
[20:02] <Pikkachu> url=$(bzr config push_location | sed 's/\//\\\//g')
[20:02] <Pikkachu> cat plugin.c | sed s/@url@/$url/ > "$devroot/pidgin-$version/pidgin/plugins/plugin.c"
[20:03] <Pikkachu> cd "$devroot/pidgin-$version/pidgin/plugins" && make...
[20:03] <LarstiQ> Pikkachu: right.
[20:04] <LarstiQ> Pikkachu: stylistically I would go for including a header instead of rewriting plugin.c, but that's a small niggle
[20:08] <Pikkachu> LarstiQ: it's overkill to split the plugin into a separate files, and it doesn't rewrite the plugin itself, but the copy from which it will be built
[20:09] <Pikkachu> the above would be the same as copying the plugin to there then sed -i
[20:11] <Pikkachu> hmm actually I could use your suggestion to avoid build.sh not being used (if one copy the file to there and $ make it, then the url will remain as "@url@" in the binary)
[20:11]  * LarstiQ nods
[20:14] <Pikkachu> if I use #include "plugin.url.h" then 'URL' instead of @url@, compilation will fail if build.sh is not used and no header is manually created...sounds interesting, thanks for the tip LarstiQ
[21:19] <Pikkachu> thanks all for the constructive discussion!
[21:45] <poolie> hi all
[21:45] <poolie> hi lifeless
[22:42]  * jelmer waves to poolie