[00:58] <bob2> 'clone' was deprecated?
[01:29] <lifeless> yes, it isn't what git means by clone, nor hg, so it was confusing (it was deprecated -ages- ago)
[01:30] <bob2> hm, in the sense that it "clones" a branch not a repo like hg/git?
[01:30] <lifeless> right
[01:30] <bob2> fairynuff
[01:31] <lifeless> possibly it ca come back with colocated setups
[05:38] <infinet> how to resume an interrupted "bzr branch lp:xxxxx " command?
[05:39] <bob2> afaik you're boned unless you run it in a shared-repo
[05:39] <AuroraBorealis> why are you boned? try just running the command again
[05:40] <AuroraBorealis> they say that bzr is failure resiliant
[05:40] <bob2> pretty sure it won't use the already downloaded data
[05:40] <AuroraBorealis> well a branch operation is pretty easy to just start over anyway so if it doesn't then it doesn't matter :>
[05:40] <infinet> it says "bzr: ERROR: Target directory "calibre" already exists.", so seems like have to delete data already download and start over
[05:40] <bob2> as above
[05:41] <bob2> AuroraBorealis, not if it is a large branch
[05:41] <AuroraBorealis> bzr's dev branch takes less then 5 minutes =
[05:41] <AuroraBorealis> you might have to delete the .bzr directory
[05:42] <infinet> the calibre appears quite large, I end up over 100M of unfinished data when last interrupted
[05:42] <infinet> what a waste
[05:42] <bob2> pretty sure as above
[05:42] <AuroraBorealis> try
[05:42] <AuroraBorealis> bzr branch --use-existing-dir
[05:43] <infinet>  --use-existing-dir make no difference, it is what bzr explorer did by the way
[05:44] <AuroraBorealis> i would just try again, then.
[05:45] <infinet> thanks
[05:45] <AuroraBorealis> 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] <infinet> true, it is the first time to fetch the branch, so nothing lost
[05:47] <bob2> still immensely tedious though
[05:47] <AuroraBorealis> i agree. i dont know why it wouldn't resume if its just downloading revisions
[05:48] <infinet> more carbon emission, perhaps
[05:48] <AuroraBorealis> perhaps its just on the ever growing todo list.
[07:19] <poolie> hi vila?
[07:36] <vila> hi all !
[07:36] <vila> hey poolie
[07:36] <poolie> hi there
[07:48] <poolie> vila, tangentially, what did we end up with as preferred config option naming
[07:49] <poolie> jelmer is adding 'bzr.transform.orphan_policy' but i thought we were going to drop the 'bzr.'
[07:49] <vila> he didn't add it, just migrated it
[07:49] <vila> yes, we settled on dropping the leading 'bzr.' but this option predates that decision
[07:49] <poolie> k
[07:50] <poolie> true
[09:02] <mgz> morning all!
[09:05] <poolie> hi mgz, and good night
[09:08] <mgz> night poolie :)
[10:08] <apw> 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] <mgz> try profiling it and seeing what the call that blocks is.
[10:18] <apw> mgz, any hints as to how to profile it, is there something pythony in my toolbox
[10:23] <mgz> you can run it via a bzr command line thing right?
[10:24] <mgz> so `bzr --lsprof-file bzr_viz_prof.txt viz ...`
[10:24] <mgz> and close the window as soon as it's done loading.
[10:24] <mgz> I've used that for bzr explorer/qbzr issues
[11:29] <AfC> apw: yeah, I've seen that delay lately. It's pretty awful.
[11:30] <jelmer> I think it was introduced with our migration to gtk3, haven't had time to investigate either though :-/
[11:33] <mgz> it's worth a bug at any rate.
[11:33] <mgz> jelmer: how was the weekend's snow?
[11:35] <jelmer> mgz: terrible :)
[11:35] <mgz> did the trains go in the end?
[11:35] <jelmer> had long delays on Friday and Sunday, but got back home safely
[12:20] <LarstiQ_> can I turn 'pypy' into an official tag?
[12:23] <mgz> LarstiQ: if you can, do so.
[12:24] <LarstiQ> mgz: done
[12:27] <mgz> 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:28] <mgz> there's no sensible way of implementing detection of test cases living too long without depending on gc implementation details
[12:29] <mgz> 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] <mgz> 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] <LarstiQ> mgz: now that an entire testsuite run completes, I'm not too worried about the memory consumption
[12:31] <LarstiQ> so for my part skipping would be fine
[12:31] <mgz> for bug 927581 win32 has a similar but worse problem, pypy only uses the bytestring version
[12:32] <mgz> 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] <mgz> I couldn't find an upstream pypy bug, it may be worth filing one and linking it.
[12:33] <LarstiQ> mgz: I can do that
[12:33] <LarstiQ> mgz: do you have a link for the win32 version?
[12:33] <mgz> 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] <wgz> note we create a file that we then can't remove with a standard library function in cleanup
[12:39] <tsdgeos> hi guys
[12:39] <tsdgeos> i obviously messed up something in a merge
[12:40] <tsdgeos> and ended up with https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/+merge/90455
[12:40] <tsdgeos> where i have "added file 'tests/launcher/autohide_show_tests_common.rb'" and "removed file 'tests/launcher/autohide_show_tests_common.rb'"
[12:40] <tsdgeos> instead of just the differences in that file
[12:40] <tsdgeos> is there a way i can fix that?
[12:42] <LarstiQ> tsdgeos: try `bzr status --show-ids` on that change
[12:42] <LarstiQ> tsdgeos: it sounds like two files with different file-ids
[12:42] <tsdgeos> i mean probably
[12:42] <tsdgeos> the file was already there
[12:42] <tsdgeos> and then the merge brought a file named the same
[12:43] <tsdgeos> so that's basically where i messed up i guess
[12:43] <tsdgeos> just wondering if it can be repaired
[12:43] <LarstiQ> tsdgeos: well, you could backtrack to where the extra copy got introduced
[12:44] <tsdgeos> 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] <LarstiQ> tsdgeos: but if that has already been merged into the project history, might not be worth it to disrupt that
[12:44] <tsdgeos> it looks acceptable
[12:44] <tsdgeos> when you unfold "tests/launcher/autohide_show_tests_common.rb "
[12:45] <tsdgeos> it looks like only the changes there, not a whole replace/rewrite of the file
[12:45] <LarstiQ> tsdgeos: right, so that's the wrong place
[12:46] <tsdgeos> well, that's the place i merged the two branches that had the same file, before that all was fine
[12:48] <tsdgeos> anyway, not important
[12:48] <tsdgeos> thanks!
[12:48] <LarstiQ> tsdgeos: you're merging into lp:~unity-2d-team/unity-2d/unity-2d-shell
[12:48] <LarstiQ> tsdgeos: so could be that there the change happened
[12:48] <LarstiQ> tsdgeos: (or maybe there is a bug in the merge proposal preview)
[12:48] <tsdgeos> maybe
[12:48]  * LarstiQ branches and checks
[12:49] <tsdgeos> this is my first merge with files coming from everywhere
[12:49] <tsdgeos> so probably did something wrong somewhere
[12:55] <LarstiQ> tsdgeos: so ` bzr log -p tests/launcher/autohide_show_tests_common.rb` in your branch shows it getting added in r957
[12:57] <LarstiQ> tsdgeos: and ` bzr st --show-ids -r ancestor:../unity-2d-shell` tells you the fileid of the removed versions
[13:00] <LarstiQ> tsdgeos: hmm, I don't quite get it
[13:01] <LarstiQ> 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] <mgz> 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] <LarstiQ> mgz: that sounds plausible
[13:03] <mgz> so then, merging that into trunk replaces the existing file
[13:03]  * LarstiQ nods
[13:03] <mgz> 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] <LarstiQ> tsdgeos: what mgz said.  Trunk added autohide_show_tests_-20120131103636-9609yigoypwit8fi-1 in r953, you added autohide_show_tests_-20120130172001-gjk3mfvvx7hksg75-1
[13:41] <pippijn> hi all
[13:41] <pippijn> I'm having some issues committing
[13:41] <pippijn> http://xinutec.org/~pippijn/files/txt/ca85c58612e67f7eb1b5581a6478aa2c.txt
[13:48] <jelmer> hi pippijn
[13:48]  * mgz wants to make a joke about this being the wrong place for relationship advice
[13:48] <jelmer> vila: ^
[13:50] <mgz> pippijn: did that not also print out the version and plugin version info?
[13:50] <pippijn> hmm
[13:50] <pippijn> I did bzr merge, got an error, did bzr commit again, got a different error
[13:50] <pippijn> one that does not read Traceback
[13:51] <pippijn> there we go, it's suddenly fixed
[13:51] <jelmer> pippijn: this seems odd, the error suggests you have files from different versions of bzr installed
[13:51] <tsdgeos> LarstiQ: mgz: how would i do that? bzr uncommit + push again? will that overwrite the old history?
[13:51] <pippijn> it's working now
[13:51] <pippijn> magically
[13:54] <jelmer> pippijn: do you have a dist-upgrade / yum upgrade job going on in the background, or something like that?
[13:54] <pippijn> jelmer: no
[13:54] <mgz> tsdgeos: either uncommit, or to be safer branch the rev just before to a new directory and try again
[13:55] <jelmer> pippijn: it sounds like there's something really funky going on with the files in /usr/lib/python2.7/dist-packages/bzrlib
[13:55] <mgz> 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] <tsdgeos> mgz: nice that worked :-)
[14:04] <tsdgeos> tx
[14:05] <mgz> cool.
[15:09] <vila> jelmer: what ? mgz's joke ?
[15:10] <jelmer> vila: sorry, unping
[15:10] <jelmer> vila: it was about the config hooks issue pippijn was running into
[15:12] <vila> 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] <mgz> eheh, the ping was amusingly timed.
[20:35] <cabbey> anyone familar with oddball errors out of bzr rebase around?
[20:35] <cabbey> 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] <cabbey> can't seem to convince bzr resolve to clear the bogus conflict messages
[20:41] <jelmer> hi cabbey
[20:41] <cabbey> howdy jelmer
[20:41] <jelmer> cabbey: you should be able to run 'bzr resolved' and then 'bzr rebase-continue'
[20:42] <cabbey> heh, if anyone is familiar with this code, I suspect you would be. :)
[20:42] <cabbey> so right after I posted that, a co-worker suggested explictly resolve'ing by name... that worked when bzr resolved wouldn't
[20:43] <jelmer> cabbey: bzr resolved can only automatically resolve text conflicts, not shape conflicts
[20:43] <jelmer> there is also 'bzr resolved --all' which makes it consider all conflicts as resolved
[20:43] <cabbey> mmm... --all woulda saved me some copy/paste
[21:09] <cabbey> 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] <cabbey> we've got 3 branches: trunk -> feature A -> feature B
[21:10] <cabbey> 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] <cabbey> 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] <cabbey> (A and B were in parrallel development since last september... I've probably done 1000 hand merges during that time)
[21:19] <cabbey> oh god. I just looked at some of the supposed merge results it handled without flagging as conflicts. :(
[21:23] <jelmer> RE
[21:24] <jelmer> cabbey: I would do a reverse merge of the changes from A in B
[21:24] <jelmer> 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] <cabbey> sadly it seems to be doing a very bad job of re-creating them :(
[21:27] <jelmer> cabbey: it's just applying the changes again
[21:27] <jelmer> cabbey: you might have more luck trying to rebase on the revision from trunk before feature A was started
[21:28] <cabbey> that's not what I'm seeing in these .BASE, .THIS and .OTHER files
[21:28] <jelmer> 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] <poolie> hi jelmer, wgz
[21:29] <jelmer> hi poolie
[21:30] <jelmer> are you feeling better?
[21:32] <poolie> yes thanks
[21:32] <poolie> how are things with you?
[21:32] <cabbey> jelmer: it should be replaying the commits from my branch, right?
[21:32] <poolie> i'm going to try to get through the queue today
[21:33] <poolie> and maybe then look in to debugging some precise bugs
[21:33] <jelmer> poolie: I had fun at FOSDEM :)
[21:34] <Riddell> jelmer: you never came by my stall!
[21:34] <poolie> hi riddell, how are you?
[21:34] <Riddell> poolie: recovering
[21:35] <Riddell> enjoyed fosdem, had to limit my intake of belgian beer of course
[21:35] <jelmer> Riddell: well, you missed the Ubuntu dinner >-)
[21:36] <jelmer> Riddell: I did spot you at some point during the weekend, but you were in conversation with somebody
[21:36] <Riddell> that's because I had about 25 KDE cats to herd to the dinner I organised
[21:36] <jelmer> ah, heh :)
[21:36] <Riddell> I might be concussed but I still can organise better than most free software types
[21:38] <jelmer> cabbey: did you merge trunk during the feature development at all?
[21:38] <jelmer> Riddell: :)
[21:38] <cabbey> yes. via A
[21:38] <cabbey> A pulled trunk in, B pulled A in
[21:39] <jelmer> 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] <cabbey> well, pulled or merged... mostly merged there in the latter days as things diverged :)
[21:40] <jelmer> 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] <cabbey> right, so rebase-abort here I come. :(
[21:47] <lifeless> poolie: hiya
[21:48] <lifeless> 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] <poolie> hm
[21:49] <poolie> as in, it doesn't automatically find them?
[21:49] <poolie> or, you can't even load them by hand?
[21:50] <poolie> this seems to get into namespace package ickiness
[21:50] <poolie> but
[21:50] <poolie> i don't recall a bug for it and i don't object
[21:50] <poolie> the only bzr tasks i have been objecting to are the ones where the bug is not yet actionable in bzr
[21:51] <lifeless> sure; I wasn't referencing or impeded by that :)
[21:53] <lifeless> 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] <jelmer> cabbey: I would recommend doing a reverse merge of the changes between A and trunk
[21:54] <poolie> +1
[21:54] <jelmer> cabbey: rebase is just conceptually problematic in this regard
[21:54] <lifeless> 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] <cabbey> jelmer: yeah, I'm starting down that route in copy of my branch right now
[21:59] <lifeless> poolie: I've filed https://bugs.launchpad.net/bzr/+bug/927920 about this
[22:23] <poolie> thanks lifeless
[22:36] <lifeless> poolie: de nada :)
[22:50] <milki> hm
[22:50] <milki> bug 0
[22:50] <milki> :o
[22:50] <milki> bug 1
[22:50] <milki> lol
[23:35] <wgz> a little bazaar before bed