[00:58] 'clone' was deprecated? [01:29] yes, it isn't what git means by clone, nor hg, so it was confusing (it was deprecated -ages- ago) [01:30] hm, in the sense that it "clones" a branch not a repo like hg/git? [01:30] right [01:30] fairynuff [01:31] possibly it ca come back with colocated setups [05:38] how to resume an interrupted "bzr branch lp:xxxxx " command? [05:39] afaik you're boned unless you run it in a shared-repo [05:39] why are you boned? try just running the command again [05:40] they say that bzr is failure resiliant [05:40] pretty sure it won't use the already downloaded data [05:40] well a branch operation is pretty easy to just start over anyway so if it doesn't then it doesn't matter :> [05:40] it says "bzr: ERROR: Target directory "calibre" already exists.", so seems like have to delete data already download and start over [05:40] as above [05:41] AuroraBorealis, not if it is a large branch [05:41] bzr's dev branch takes less then 5 minutes = [05:41] you might have to delete the .bzr directory [05:42] the calibre appears quite large, I end up over 100M of unfinished data when last interrupted [05:42] what a waste [05:42] pretty sure as above [05:42] try [05:42] bzr branch --use-existing-dir [05:43] --use-existing-dir make no difference, it is what bzr explorer did by the way [05:44] i would just try again, then. [05:45] thanks [05:45] i think operations that change stuff (like history) are safe, but i guess branch isn't since you don't really lose any data if it gets interrupted. [05:46] true, it is the first time to fetch the branch, so nothing lost [05:47] still immensely tedious though [05:47] i agree. i dont know why it wouldn't resume if its just downloading revisions [05:48] more carbon emission, perhaps [05:48] perhaps its just on the ever growing todo list. === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie === yofel_ is now known as yofel [07:19] hi vila? === Merwin_ is now known as Merwin [07:36] hi all ! [07:36] hey poolie [07:36] hi there === echo-are` is now known as echo-area [07:48] vila, tangentially, what did we end up with as preferred config option naming [07:49] jelmer is adding 'bzr.transform.orphan_policy' but i thought we were going to drop the 'bzr.' [07:49] he didn't add it, just migrated it [07:49] yes, we settled on dropping the leading 'bzr.' but this option predates that decision [07:49] k [07:50] true [09:02] morning all! [09:05] hi mgz, and good night [09:08] night poolie :) [10:08] anyone else seeing a large delay (leading to compiz greying out) in bzr vis after the progress bars are done filling and before showing the first commit [10:17] try profiling it and seeing what the call that blocks is. [10:18] mgz, any hints as to how to profile it, is there something pythony in my toolbox [10:23] you can run it via a bzr command line thing right? [10:24] so `bzr --lsprof-file bzr_viz_prof.txt viz ...` [10:24] and close the window as soon as it's done loading. [10:24] I've used that for bzr explorer/qbzr issues [11:29] apw: yeah, I've seen that delay lately. It's pretty awful. [11:30] I think it was introduced with our migration to gtk3, haven't had time to investigate either though :-/ [11:33] it's worth a bug at any rate. [11:33] jelmer: how was the weekend's snow? [11:35] mgz: terrible :) [11:35] did the trains go in the end? [11:35] had long delays on Friday and Sunday, but got back home safely === Quintasan_ is now known as Quintasan [12:20] can I turn 'pypy' into an official tag? === LarstiQ_ is now known as LarstiQ [12:23] LarstiQ: if you can, do so. [12:24] mgz: done [12:27] LarstiQ: for bug 926869 it's as poolie says, I'd have added features.RefCountingGC or something to the tests were there an obvious way of detecting that [12:27] Launchpad bug 926869 in Bazaar "TestUncollectedWarnings failures under pypy" [Medium,Confirmed] https://launchpad.net/bugs/926869 [12:28] there's no sensible way of implementing detection of test cases living too long without depending on gc implementation details [12:29] and though some of the pypy gc options will benefit from testcases that die promptly, there's no way short of running a collection after each case to actually do that, and that will have other downsides [12:30] it should perhaps have been more clearly documented as such, but I wasn't particularly thinking that any other python implementations were close to working [12:31] * LarstiQ nods [12:31] mgz: now that an entire testsuite run completes, I'm not too worried about the memory consumption [12:31] so for my part skipping would be fine [12:31] for bug 927581 win32 has a similar but worse problem, pypy only uses the bytestring version [12:31] Launchpad bug 927581 in Bazaar "pypy raises UnicodeDecoderError on os.listdir(unicode) in a C locale" [Low,Confirmed] https://launchpad.net/bugs/927581 [12:32] so really I think they need to make listdir less broken with non-ascii data, but the way we use it doesn't help. [12:32] * LarstiQ nods [12:32] I couldn't find an upstream pypy bug, it may be worth filing one and linking it. [12:33] mgz: I can do that [12:33] mgz: do you have a link for the win32 version? [12:33] I thought I'd posted a bug, but now can't find it, so maybe I just noticed the issue but didn't file [12:35] [12:35] note we create a file that we then can't remove with a standard library function in cleanup [12:39] hi guys [12:39] i obviously messed up something in a merge [12:40] and ended up with https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/+merge/90455 [12:40] where i have "added file 'tests/launcher/autohide_show_tests_common.rb'" and "removed file 'tests/launcher/autohide_show_tests_common.rb'" [12:40] instead of just the differences in that file [12:40] is there a way i can fix that? [12:42] tsdgeos: try `bzr status --show-ids` on that change [12:42] tsdgeos: it sounds like two files with different file-ids [12:42] i mean probably [12:42] the file was already there [12:42] and then the merge brought a file named the same [12:43] so that's basically where i messed up i guess [12:43] just wondering if it can be repaired [12:43] tsdgeos: well, you could backtrack to where the extra copy got introduced [12:44] LarstiQ: otoh it's weird, because if you go to http://bazaar.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/revision/969 that is the merge commit [12:44] tsdgeos: but if that has already been merged into the project history, might not be worth it to disrupt that [12:44] it looks acceptable [12:44] when you unfold "tests/launcher/autohide_show_tests_common.rb " [12:45] it looks like only the changes there, not a whole replace/rewrite of the file [12:45] tsdgeos: right, so that's the wrong place [12:46] well, that's the place i merged the two branches that had the same file, before that all was fine [12:48] anyway, not important [12:48] thanks! [12:48] tsdgeos: you're merging into lp:~unity-2d-team/unity-2d/unity-2d-shell [12:48] tsdgeos: so could be that there the change happened [12:48] tsdgeos: (or maybe there is a bug in the merge proposal preview) [12:48] maybe [12:48] * LarstiQ branches and checks [12:49] this is my first merge with files coming from everywhere [12:49] so probably did something wrong somewhere [12:55] tsdgeos: so ` bzr log -p tests/launcher/autohide_show_tests_common.rb` in your branch shows it getting added in r957 [12:57] tsdgeos: and ` bzr st --show-ids -r ancestor:../unity-2d-shell` tells you the fileid of the removed versions [13:00] tsdgeos: hmm, I don't quite get it [13:01] tsdgeos: `bzr missing --line ../unity-2d-shell` and then `bzr log -v -r 935..-1` show you didn't remove or rename them [13:02] I think both sides of the merge added the file, so there was a path conflict rather than a content conflict, and he took his copy? [13:03] mgz: that sounds plausible [13:03] so then, merging that into trunk replaces the existing file [13:03] * LarstiQ nods [13:03] the right thing to do is redo that merge, keep trunk's file, add in any changes needed, which should then merge back to trunk cleanly [13:05] tsdgeos: what mgz said. Trunk added autohide_show_tests_-20120131103636-9609yigoypwit8fi-1 in r953, you added autohide_show_tests_-20120130172001-gjk3mfvvx7hksg75-1 [13:41] hi all [13:41] I'm having some issues committing [13:41] http://xinutec.org/~pippijn/files/txt/ca85c58612e67f7eb1b5581a6478aa2c.txt [13:48] hi pippijn [13:48] * mgz wants to make a joke about this being the wrong place for relationship advice [13:48] vila: ^ [13:50] pippijn: did that not also print out the version and plugin version info? [13:50] hmm [13:50] I did bzr merge, got an error, did bzr commit again, got a different error [13:50] one that does not read Traceback [13:51] there we go, it's suddenly fixed [13:51] pippijn: this seems odd, the error suggests you have files from different versions of bzr installed [13:51] LarstiQ: mgz: how would i do that? bzr uncommit + push again? will that overwrite the old history? [13:51] it's working now [13:51] magically [13:54] pippijn: do you have a dist-upgrade / yum upgrade job going on in the background, or something like that? [13:54] jelmer: no [13:54] tsdgeos: either uncommit, or to be safer branch the rev just before to a new directory and try again [13:55] pippijn: it sounds like there's something really funky going on with the files in /usr/lib/python2.7/dist-packages/bzrlib [13:55] tsdgeos: then, after doing the merge, committing, and maybe testing against a local copy of trunk to see the merge back works as expected, you can push --overwrite to fix your branch and mp [14:04] mgz: nice that worked :-) [14:04] tx [14:05] cool. [15:09] jelmer: what ? mgz's joke ? [15:10] vila: sorry, unping [15:10] vila: it was about the config hooks issue pippijn was running into [15:12] jelmer: oh, ok, just seen the traceback, quite weird indeed, I don't remember changing hook signatures there... I agree with your feeling about some weird update [15:13] eheh, the ping was amusingly timed. === Odd_Blok1 is now known as Odd_Bloke === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [20:35] anyone familar with oddball errors out of bzr rebase around? [20:35] trying to rebase my branch and it's given me a "conflict" on a directory and file that are new in my branch [20:36] can't seem to convince bzr resolve to clear the bogus conflict messages [20:41] hi cabbey [20:41] howdy jelmer [20:41] cabbey: you should be able to run 'bzr resolved' and then 'bzr rebase-continue' [20:42] heh, if anyone is familiar with this code, I suspect you would be. :) [20:42] so right after I posted that, a co-worker suggested explictly resolve'ing by name... that worked when bzr resolved wouldn't [20:43] cabbey: bzr resolved can only automatically resolve text conflicts, not shape conflicts [20:43] there is also 'bzr resolved --all' which makes it consider all conflicts as resolved [20:43] mmm... --all woulda saved me some copy/paste [21:09] hey jelmer, I'm starting to think what I'm doing is not a good use of rebase. Got a moment to confirm/reject that? [21:10] we've got 3 branches: trunk -> feature A -> feature B [21:10] feature A landed to trunk last week, now I'm trying to rebase my branch for B to trunk, since A is deadended [21:12] rebase is dragging me through lots of nasty manual conflict merges that make no sense to go through again... I had already dealt with all of them as I pulled A into B [21:13] (A and B were in parrallel development since last september... I've probably done 1000 hand merges during that time) [21:19] oh god. I just looked at some of the supposed merge results it handled without flagging as conflicts. :( [21:23] RE [21:24] cabbey: I would do a reverse merge of the changes from A in B [21:24] cabbey: rebase will try to create all commits again on top of trunk, one by one - so it's probably not what you want, indeed [21:25] sadly it seems to be doing a very bad job of re-creating them :( [21:27] cabbey: it's just applying the changes again [21:27] cabbey: you might have more luck trying to rebase on the revision from trunk before feature A was started [21:28] that's not what I'm seeing in these .BASE, .THIS and .OTHER files [21:28] cabbey: it's basically just doing "bzr diff -c" for each revision and then calling "patch -p0" for that revision on top of trunk [21:29] hi jelmer, wgz [21:29] hi poolie [21:30] are you feeling better? [21:32] yes thanks [21:32] how are things with you? [21:32] jelmer: it should be replaying the commits from my branch, right? [21:32] i'm going to try to get through the queue today [21:33] and maybe then look in to debugging some precise bugs [21:33] poolie: I had fun at FOSDEM :) [21:34] jelmer: you never came by my stall! [21:34] hi riddell, how are you? [21:34] poolie: recovering [21:35] enjoyed fosdem, had to limit my intake of belgian beer of course [21:35] Riddell: well, you missed the Ubuntu dinner >-) [21:36] Riddell: I did spot you at some point during the weekend, but you were in conversation with somebody [21:36] that's because I had about 25 KDE cats to herd to the dinner I organised [21:36] ah, heh :) [21:36] I might be concussed but I still can organise better than most free software types [21:38] cabbey: did you merge trunk during the feature development at all? [21:38] Riddell: :) [21:38] yes. via A [21:38] A pulled trunk in, B pulled A in [21:39] cabbey: replaying the changes from B on top of trunk means that older B revisions won't have all the changes from trunk merged in yet [21:39] well, pulled or merged... mostly merged there in the latter days as things diverged :) [21:40] basically, rebasing anything that has merges of the branch onto which you're rebasing in it somewhere is going to cause massive conflicts [21:41] right, so rebase-abort here I come. :( [21:47] poolie: hiya [21:48] poolie: LP would like to be able to import bzr plugins from eggs (in our buildout environment) - are you aware of an existing bug for having bzr find plugins via setuptools voodoo ? I don't want to file a dupe, I vaguely recall such a bug, but flacoste couldn't find it when he looked [21:49] hm [21:49] as in, it doesn't automatically find them? [21:49] or, you can't even load them by hand? [21:50] this seems to get into namespace package ickiness [21:50] but [21:50] i don't recall a bug for it and i don't object [21:50] the only bzr tasks i have been objecting to are the ones where the bug is not yet actionable in bzr [21:51] sure; I wasn't referencing or impeded by that :) [21:53] poolie: as in the load_plugins call needs to call some setuptools api to ask it to iterate the available bzrlib.plugins.* eggs; that would get the package path setup fo r'import bzrlib.plugins.foo' at the same time; I think its fairly shallow (but possible expensive to call so may need an option to turn it on) [21:53] cabbey: I would recommend doing a reverse merge of the changes between A and trunk [21:54] +1 [21:54] cabbey: rebase is just conceptually problematic in this regard [21:54] bug 78520 is tangentially related (in that you can't install plugins into an egg distribution, so if plugins are desired, this is a pre-cursor to fixing that existing bug report) [21:54] Launchpad bug 78520 in Bazaar "build a Python Egg installer package?" [Medium,Confirmed] https://launchpad.net/bugs/78520 [21:54] jelmer: yeah, I'm starting down that route in copy of my branch right now [21:59] poolie: I've filed https://bugs.launchpad.net/bzr/+bug/927920 about this [21:59] Launchpad bug 927920 in Bazaar "plugins installed as eggs are not found by bzrlib" [Medium,Confirmed] [22:23] thanks lifeless [22:36] poolie: de nada :) [22:50] hm [22:50] bug 0 [22:50] Error: Launchpad bug 0 could not be found [22:50] :o [22:50] bug 1 [22:50] Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [22:50] lol [23:35] a little bazaar before bed