| bob2 | 'clone' was deprecated? | 00:58 |
|---|---|---|
| lifeless | yes, it isn't what git means by clone, nor hg, so it was confusing (it was deprecated -ages- ago) | 01:29 |
| 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:30 |
| lifeless | possibly it ca come back with colocated setups | 01:31 |
| infinet | how to resume an interrupted "bzr branch lp:xxxxx " command? | 05:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| infinet | --use-existing-dir make no difference, it is what bzr explorer did by the way | 05:43 |
| AuroraBorealis | i would just try again, then. | 05:44 |
| 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:45 |
| infinet | true, it is the first time to fetch the branch, so nothing lost | 05:46 |
| bob2 | still immensely tedious though | 05:47 |
| AuroraBorealis | i agree. i dont know why it wouldn't resume if its just downloading revisions | 05:47 |
| infinet | more carbon emission, perhaps | 05:48 |
| AuroraBorealis | perhaps its just on the ever growing todo list. | 05:48 |
| === poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | ||
| === yofel_ is now known as yofel | ||
| poolie | hi vila? | 07:19 |
| === Merwin_ is now known as Merwin | ||
| vila | hi all ! | 07:36 |
| vila | hey poolie | 07:36 |
| poolie | hi there | 07:36 |
| === echo-are` is now known as echo-area | ||
| poolie | vila, tangentially, what did we end up with as preferred config option naming | 07:48 |
| 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:49 |
| poolie | true | 07:50 |
| mgz | morning all! | 09:02 |
| poolie | hi mgz, and good night | 09:05 |
| mgz | night poolie :) | 09: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:08 |
| mgz | try profiling it and seeing what the call that blocks is. | 10:17 |
| apw | mgz, any hints as to how to profile it, is there something pythony in my toolbox | 10:18 |
| mgz | you can run it via a bzr command line thing right? | 10:23 |
| 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 | 10:24 |
| AfC | apw: yeah, I've seen that delay lately. It's pretty awful. | 11:29 |
| jelmer | I think it was introduced with our migration to gtk3, haven't had time to investigate either though :-/ | 11:30 |
| mgz | it's worth a bug at any rate. | 11:33 |
| mgz | jelmer: how was the weekend's snow? | 11:33 |
| 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 | 11:35 |
| === Quintasan_ is now known as Quintasan | ||
| LarstiQ_ | can I turn 'pypy' into an official tag? | 12:20 |
| === LarstiQ_ is now known as LarstiQ | ||
| mgz | LarstiQ: if you can, do so. | 12:23 |
| LarstiQ | mgz: done | 12:24 |
| 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:27 |
| ubot5 | Launchpad bug 926869 in Bazaar "TestUncollectedWarnings failures under pypy" [Medium,Confirmed] https://launchpad.net/bugs/926869 | 12:27 |
| mgz | there's no sensible way of implementing detection of test cases living too long without depending on gc implementation details | 12:28 |
| 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:29 |
| 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:30 |
| * 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:31 |
| ubot5 | Launchpad bug 927581 in Bazaar "pypy raises UnicodeDecoderError on os.listdir(unicode) in a C locale" [Low,Confirmed] https://launchpad.net/bugs/927581 | 12:31 |
| 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:32 |
| 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:33 |
| wgz | <http://float.endofinternet.org/xmlbin/pypy_non_per_FAIL#bb.test_alias.TestAlias.test_unicode_alias> | 12:35 |
| wgz | note we create a file that we then can't remove with a standard library function in cleanup | 12:35 |
| tsdgeos | hi guys | 12:39 |
| tsdgeos | i obviously messed up something in a merge | 12:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| tsdgeos | well, that's the place i merged the two branches that had the same file, before that all was fine | 12:46 |
| 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:48 | |
| tsdgeos | this is my first merge with files coming from everywhere | 12:49 |
| tsdgeos | so probably did something wrong somewhere | 12:49 |
| LarstiQ | tsdgeos: so ` bzr log -p tests/launcher/autohide_show_tests_common.rb` in your branch shows it getting added in r957 | 12:55 |
| LarstiQ | tsdgeos: and ` bzr st --show-ids -r ancestor:../unity-2d-shell` tells you the fileid of the removed versions | 12:57 |
| LarstiQ | tsdgeos: hmm, I don't quite get it | 13:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| LarstiQ | tsdgeos: what mgz said. Trunk added autohide_show_tests_-20120131103636-9609yigoypwit8fi-1 in r953, you added autohide_show_tests_-20120130172001-gjk3mfvvx7hksg75-1 | 13:05 |
| pippijn | hi all | 13:41 |
| pippijn | I'm having some issues committing | 13:41 |
| pippijn | http://xinutec.org/~pippijn/files/txt/ca85c58612e67f7eb1b5581a6478aa2c.txt | 13:41 |
| 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:48 |
| 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:50 |
| 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:51 |
| 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:54 |
| 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 | 13:55 |
| tsdgeos | mgz: nice that worked :-) | 14:04 |
| tsdgeos | tx | 14:04 |
| mgz | cool. | 14:05 |
| vila | jelmer: what ? mgz's joke ? | 15:09 |
| jelmer | vila: sorry, unping | 15:10 |
| jelmer | vila: it was about the config hooks issue pippijn was running into | 15:10 |
| 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:12 |
| mgz | eheh, the ping was amusingly timed. | 15:13 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| 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:35 |
| cabbey | can't seem to convince bzr resolve to clear the bogus conflict messages | 20:36 |
| 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:41 |
| 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:42 |
| 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 | 20:43 |
| 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:09 |
| 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:10 |
| 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:12 |
| cabbey | (A and B were in parrallel development since last september... I've probably done 1000 hand merges during that time) | 21:13 |
| cabbey | oh god. I just looked at some of the supposed merge results it handled without flagging as conflicts. :( | 21:19 |
| jelmer | RE | 21:23 |
| 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:24 |
| cabbey | sadly it seems to be doing a very bad job of re-creating them :( | 21:25 |
| 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:27 |
| 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:28 |
| poolie | hi jelmer, wgz | 21:29 |
| jelmer | hi poolie | 21:29 |
| jelmer | are you feeling better? | 21:30 |
| 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:32 |
| poolie | and maybe then look in to debugging some precise bugs | 21:33 |
| jelmer | poolie: I had fun at FOSDEM :) | 21:33 |
| Riddell | jelmer: you never came by my stall! | 21:34 |
| poolie | hi riddell, how are you? | 21:34 |
| Riddell | poolie: recovering | 21:34 |
| Riddell | enjoyed fosdem, had to limit my intake of belgian beer of course | 21:35 |
| jelmer | Riddell: well, you missed the Ubuntu dinner >-) | 21:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| cabbey | right, so rebase-abort here I come. :( | 21:41 |
| lifeless | poolie: hiya | 21:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| lifeless | sure; I wasn't referencing or impeded by that :) | 21:51 |
| 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:53 |
| 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 |
| ubot5 | Launchpad bug 78520 in Bazaar "build a Python Egg installer package?" [Medium,Confirmed] https://launchpad.net/bugs/78520 | 21:54 |
| cabbey | jelmer: yeah, I'm starting down that route in copy of my branch right now | 21:54 |
| lifeless | poolie: I've filed https://bugs.launchpad.net/bzr/+bug/927920 about this | 21:59 |
| ubot5 | Launchpad bug 927920 in Bazaar "plugins installed as eggs are not found by bzrlib" [Medium,Confirmed] | 21:59 |
| poolie | thanks lifeless | 22:23 |
| lifeless | poolie: de nada :) | 22:36 |
| milki | hm | 22:50 |
| milki | bug 0 | 22:50 |
| ubot5 | Error: Launchpad bug 0 could not be found | 22:50 |
| milki | :o | 22:50 |
| milki | bug 1 | 22:50 |
| ubot5 | Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 | 22:50 |
| milki | lol | 22:50 |
| wgz | a little bazaar before bed | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!