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