[00:02] <jelmer> lifeless: into core please
[00:56] <james_w> lifeless: it makes the tree the same as the content of the tarball, so if you run it in your packaging branch it would lose your packaging changes
[00:57] <lifeless> james_w: thats not what it should do though, it should do an import + pending merge
[00:57] <lifeless> james_w: *or* it should just import to the tag
[00:58] <lifeless> james_w: by should, I mean to be most useful.
[00:58] <lifeless> james_w: this would also make it safe to run in a packaging branch :)
[00:58] <james_w> import + pending merge == merge-upstream
[00:59] <james_w> import to the tag and print the revision-id it created?
[00:59] <lifeless> james_w: no, import + pending merge + debian changelog mangling == merge-upstream
[00:59] <lifeless> james_w: yes. For instance: import-tarball --to-tag 1.4.2
[00:59] <james_w> well request a --no-changelog flag to merge-upstream if you don't want the last part
[00:59] <lifeless> doesn't need to print the rev id, it would have made a tag.
[01:00] <james_w> that's true
[01:00] <lifeless> anyhow my main point is, that this has nothing to do with debianisation
[01:00] <lifeless> it has everything to do with importing tarballs, so calling it dh_make is extremely confusion
[01:00] <james_w> debianisation is import tarball + create packaging
[01:00] <james_w> I wanted to solve that use case
[01:01] <lifeless> and frankly, if you run 'import-tarball' or whatever the bzrtools existing command is and it makes everything look like the tarball, thats fine: bzr uncommit; bzr revert.
[01:01] <lifeless> no harm, no foul.
[01:01] <james_w> I added --bzr-only to just do the first step for those that don't want autogenerated packaging
[01:01] <james_w> so that leaves a way to "import tarball"
[01:01] <lifeless> james_w: I'm glad you've solved that use case.
[01:01] <james_w> so I just mentioned that you can achieve what you want at the UI level as well now
[01:01] <lifeless> I'd like to see a precise command that acts as a building block, for several reasons
[01:01] <lifeless>  - debugging
[01:01] <lifeless>  - reuse
[01:02] <lifeless>  - showing people the mechanics
[01:02] <james_w> I've never argued against having such a command
[01:02] <lifeless> cool
[01:02] <james_w> It's just not high on my priority list
[01:02] <james_w> I would have happily merged a patch that did something sensible for an import-upstream command
[01:02] <lifeless> etime :)
[01:03] <james_w> and I would happily merge one now that built in the work I have just done, which should make it even easier
[01:03] <james_w> that's fine, but I'm not blessed with bags of time either
[01:05] <lifeless> I know
[01:05] <lifeless> I recall a mail along the lines of 'done the command you asked for, its called dh_make'
[01:06] <lifeless> which prompted this conversation, as it wasn't what I asked for (for all that it is a good thing to have).
[01:07] <james_w> that's not how I intended it to come across
[01:07] <lifeless> miscommunication happens, we deal :)
[01:07] <lifeless> I'm glad you have done what you've done
[01:08] <lifeless> when someone gets time other things can get done
[01:08] <james_w> "if you have a need to you (lifeless) can now access this functionality at the UI level, rather than just the API by doing bzr dh_make --bzr-only. You'll still have to make a temporary branch for the upstream."
[01:08] <lifeless> james_w: separate discussion: when someone does merge-upstream --version=4 foo-4.tar.gz ../trunk
[01:09] <lifeless> does bzr-builddeb look to see if other commands have been done in trunk ?
[01:09] <james_w> other commands?
[01:09] <lifeless> or perhaps take a tag in trunk (of '4') in preference to tip ?
[01:09] <lifeless> s/commands/commits/
[01:10] <james_w> I've been pondering this
[01:10] <lifeless> I'm thinking of the scenario where someone doesn't have a dedicated 'releases' branch
[01:10] <james_w> currently it expects -r to specify it it's not tip
[01:10] <lifeless> this would apply to import-upstream too, I should think (as its the tarball revision's parents we're talking about)
[01:11] <james_w> it has functionality to remember the upstream branch, in which case I will make it look up the tag and require the -r if not there
[01:11] <james_w> it should perhaps always have that behaviour
[01:11] <lifeless> of wanting -r ?
[01:11] <lifeless> I hate optional-options :)
[01:13] <james_w> required options?
[01:14] <james_w> I know, but I also hate inconsistent ways of specifying things like revision specs
[01:15] <james_w> and we could add some sort of tag pattern configuration for those that use foo-4 or FOO_4 or whatever as their tags
[01:15] <lifeless> yeah
[01:15] <lifeless> I'd like to offer a reliable way for upstreams using bzr to say 'I made a tarball of this revision'
[01:15] <lifeless> we can advertise that
[01:16] <lifeless> tell people to hook 'make dist' into it, etc.
[01:20] <james_w> that would be cool
[01:20] <james_w> there was a patch for autotools around
[01:20] <james_w> for git, but still
[01:57] <lifeless> jml: http://pypi.python.org/pypi/unittest2/0.1.4 ><
[04:18] <jjardon> Hello, Is there any command similar to "git grep" in bzr?
[04:31] <mgolisch> bzr grep? but i dont think its builtin
[04:31] <AfC> jjardon: well, if you'll tell us what `git grep` does, perhaps we can speculate whether there is a way to achieve that effect with the bzr ecosystem.
[04:32] <jjardon> oh, yeah, sorry. Is similat to 'rgrep "something" *', but only search in the tracked git files
[04:33] <mgolisch> quite sure i saw a plugin like that somewhere, no idea bout its state though
[04:34] <mgolisch> https://code.launchpad.net/~vila/bzr/grep
[04:35] <mgolisch> seems quite old though
[04:45] <jjardon> mgolisch, thank you
[04:48] <AfC> jjardon: there's Robert's "bzr search" plugin. I'm not sure what state that's in, but I just heard him request someone to update the packaging, so it can't be that bad
[04:49] <AfC> jjardon: or, you can just do
[04:49] <AfC> $ bzr ls -R | xargs grep something
[04:51] <jjardon> AfC, thank you for the tip
[05:20] <RyNy_> How do I found out the location of the bazaar executable on my computer? Need to tell Eclipse that to use the Eclipse Bazaar Plugin.
[05:20] <RyNy_> Running Mac OS X 10.5.
[05:21] <Kilroo> Does OS X have the which command?
[05:21] <RyNy_> not sure?
[05:21] <Kilroo> Try which bzr in a terminal and see if it says something useful.
[05:22] <RyNy_> result is /usr/local/bin/bzr
[05:22] <Kilroo> That's probably it then.
[05:22] <Kilroo> Unless you somehow have it installed twice.
[05:24] <RyNy_> makes sense, but I have to use eclipse's file browser to choose the executable and I don't see it.
[05:31] <Kilroo> Odd. I could have sworn I remembered being able to type it in.
[05:33] <mgolisch> still wonder why they hide those dirs
[05:34] <mgolisch> :)
[05:35] <mgolisch> but i would have thought that only finder cares for those strange file atributes they set to hide files
[05:35] <mgolisch> or directories
[05:38] <RyNy_> ok I found in the Finder. usr is a hidden directory at root
[05:44] <RyNy_> Not sure if Eclipse will let me browse to a hidden directory. Don't think I can type in path either.
[11:57] <dutchie> I think I'm being an idiot, but I don't understand merge conflict markers
[11:58] <dutchie> in http://pastebin.com/m3a15020e say, which is the one from the branch I'm merging in?
[12:02] <Peng> dutchie: ISTM it's the second one.
[12:02] <Peng> dutchie: "TREE" refers to what you had in the working tree before the merge, so "MERGE-SOURCE" would have to be the branch you're merging in.
[12:02] <Peng> dutchie: Probably.
[12:02] <Peng> dutchie: Usually it's easy to tell from the code. :P
[12:03] <dutchie> yeah, it's a bit harder when it's po files for a language I can't read
[12:03] <Peng> Fun.
[12:04] <jml> lifeless, yeah, I've been following on twitter but haven't had a chance to analyze it.
[12:04] <Peng> Maybe you should tell the translator to fix it.
[12:04] <Peng> jml: Eh, what's on Twitter?
[12:04] <jml> Peng: unittest2 -- Michael Foord has been talking about it
[12:04] <dutchie> http://pastebin.com/m22be8358
[12:04] <dutchie> lots of arabic
[12:05] <dutchie> but it seems to have disappeared in MERGE_SOUCE
[12:05] <dutchie> bah, MERGE-SOURCE
[12:05] <Peng> dutchie: And it's escaped, too... Awesome.
[12:05] <dutchie> that's pastebin's fault
[12:05] <dutchie> I can see it fine in my editor
[12:05] <Peng> Oh. Even more awesome.
[15:54] <maxb> jelmer: Hi, what is the difference in purpose between your trunk and trunk-mirrored branches of bzr-rebase on people.samba.org ?
[15:54] <maxb> jelmer: Also, perhaps the time has come to finish the bzr-rebase -> bzr-rewrite rename and end the confusion?
[16:00] <fullermd> So, you want to rewrite the rebase rename?
[16:01] <maxb> huh?
[16:02] <maxb> And I think I've answered my first question, by discovering that Launchpad won't let you register a remote URL as both a remote branch and a mirrored branch
[16:02] <fullermd> Oh, don't mine me, I'm just playing with prefixes.
[16:03]  * maxb cheats, and composes an URL which is unequal yet functionally identical
[17:04] <jelmer> maxb: The package needs to be renamed in Debian first..
[17:04] <jelmer> maxb: I haven't had time to take care of that yet
[17:36] <maxb> jelmer: Why is renaming the Debian package a prerequisite to finishing the rename in the upstream project?
[19:44] <ed-209> I seem to be getting this error, ERROR: The user name ed-209 is not registered on Launchpad
[19:44] <ed-209> when I do a: bzr launchpad-login ed-209
[19:45] <ed-209> but I am registered at launchpad with that username
[19:46] <ed-209> this is 2.0.4
[20:09] <maxb> ed-209: In fact, no, you are not registered at Launchpad with that name
[20:16] <ed-209> oh thats the dumb screen name
[20:38] <lifeless> moin