| === Ursinha-afk is now known as Ursinha | ||
| poolie | hi spiv | 01:28 |
|---|---|---|
| spiv | Hi poolie | 01:30 |
| poolie | how are you? | 01:30 |
| spiv | Pretty good, codebrowse now appears to generate OOPSes :) | 01:33 |
| poolie | great :) | 01:33 |
| poolie | now we just need to stop it generating oopses :) | 01:33 |
| poolie | so we're half done? | 01:33 |
| spiv | And tell the OOPS reports infrastructure about them, apparently, but yes :) | 01:34 |
| spiv | At least it gives a slightly less ugly page now, even if the reports aren't visible to devs yet :) | 01:34 |
| lifeless | spiv: are you going to drive this through to conclusion? | 01:37 |
| lifeless | spiv: if not, please be sure to handover clearly so I or someone else can | 01:37 |
| spiv | lifeless: I just sent a mail to matsubara | 01:37 |
| lifeless | \o/ | 01:37 |
| spiv | lifeless: (who finally replied to my mail to him from weeks ago :/) | 01:37 |
| james_w | renames + bzr-builddeb are starting to get really hairy | 01:45 |
| james_w | well, they've always been hairy, I'm just starting to realise :-) | 01:45 |
| lifeless | james_w: lol, yes. | 01:45 |
| james_w | what we have currently is buggy, and worse, unstable | 01:45 |
| james_w | it might permute the file ids in your tree on every merge | 01:46 |
| james_w | which is...not ideal? | 01:46 |
| lifeless | james_w: it shouldn't do that, I don't think. | 01:47 |
| lifeless | james_w: at least, the patch I put in had some reasoning about that sort of thing around it. | 01:47 |
| james_w | lifeless: it looks through a number of trees (including itself) and if the path has a different id in any tree then it will switch it | 01:48 |
| james_w | so it won't reach a steady state if there are two trees that continue to differ on path2id for a particular path | 01:49 |
| lifeless | it switches? I thought it took the incoming id | 01:49 |
| lifeless | because the incoming is 'upstream' | 01:49 |
| james_w | incoming is a list, not a single tree | 01:49 |
| james_w | so I think we may have two things that are currently conflated to unpick | 01:50 |
| james_w | or some earlier assumptions may have to be changed, and it changed to be fewer trees to examine | 01:50 |
| james_w | there is a "goal tree" that we want to look at | 01:51 |
| james_w | and the old semantics which was "a list of trees that you should re-use ids from for added files" | 01:51 |
| james_w | which was added to mainly reduce the conflicts between debian + ubuntu IIRC | 01:52 |
| james_w | from something like the parallel import problem | 01:52 |
| lifeless | and upstream vs tarballs | 02:01 |
| lifeless | we want ids to flow from upstream -> tarball -> debian -> ubuntu | 02:01 |
| lifeless | I think :) | 02:01 |
| james_w | yeah, I think | 02:01 |
| james_w | we have 3 commands to consider: 1. dh-make 2. import-upstream/merge-upstream 3. import-dsc | 02:02 |
| james_w | dh-make is pretty boring for this, as it just introduces a tarball to a branch, so there is only one source of ids. I just need to check that it will only have a single tree, the upstream tree, and we can ignore it | 02:03 |
| lifeless | james_w: well | 02:05 |
| james_w | yes, that's a boring case as there is only a single tree | 02:06 |
| lifeless | james_w: one problem is that dh-make is what folk are pointed at to 'get going', but if their project is in bzr, they should really start from there. | 02:06 |
| james_w | lifeless: dh-make works with existing branches | 02:06 |
| lifeless | ok | 02:06 |
| lifeless | cool, my misunderstanding | 02:06 |
| james_w | "if the project is in bzr then start in a branch at the revision corresponding to the release you are packaging" | 02:07 |
| james_w | it just means we can talk about a single command as the starting point | 02:07 |
| james_w | import-upstream, this has more trees for sure | 02:08 |
| james_w | there's the existing "pristine tree" and an optional upstream tree | 02:08 |
| james_w | we don't really care about the packaging tree, except for an instance of the parallel imports problem | 02:09 |
| james_w | if we have an upstream tree then it should be authoritative, otherwise there is just the pristine tree, so there's no issue | 02:09 |
| james_w | the parallel imports problem is: 1) add a file in the packaging 2) new release contains (just in the tarball) that same path | 02:10 |
| james_w | if we do nothing we get a path conflict, but we can choose to turn that in to a contents conflict if we like | 02:11 |
| james_w | so far so good | 02:11 |
| james_w | import-dsc is more complicated I think | 02:11 |
| james_w | first there are two import_archives done, one for upstream and one for the packaging | 02:12 |
| james_w | in command line usage there are few trees | 02:12 |
| james_w | just the ones you are importing on top of | 02:12 |
| james_w | if we ignore parallel imports then upstream is easy, as there is just the single tree | 02:13 |
| james_w | for the packaging it may be more tricky, as you have the existing packaging tree, plus the pristine tree you just created | 02:13 |
| james_w | my guess is that in that case you want the pristine tree to be authoritative | 02:14 |
| james_w | it will have little impact generally | 02:14 |
| james_w | however, if we ignored parallel imports then if a file migrates from packaging to upstream (no bzr involved) then you can get packaging fileids changing | 02:15 |
| james_w | so far, I think we want 0 or 1 target trees, which are authoritative and we look for renames in etc. | 02:16 |
| james_w | and 0 or 1 opportunity trees which we will take fileids from if we are about to generate one and that tree has the path already | 02:16 |
| james_w | I'm suspicious that doing that will cause some problems, but I don't know what they are right now | 02:16 |
| james_w | when the importer use import-dsc, it has access to a lot more trees though, everything for Ubuntu and Debian, past and present | 02:17 |
| james_w | so, we could have 0 or more opportunity trees, and just pass them as that, but as I said, there may be pitfalls there | 02:18 |
| james_w | however, it may be that we want target trees as well | 02:18 |
| james_w | if not now, then maybe further down the road | 02:19 |
| james_w | I have a feeling that my experiment with rename detection in import-dsc fell down due to something related to that same question | 02:19 |
| james_w | so, what could go wrong with taking fileids from another tree, rather than generating them? | 02:20 |
| james_w | we would have to ensure that the ids weren't duplicates within our tree | 02:20 |
| james_w | obviously it can associate files with different "identities", but that's a risk that is outweighed by the benefits IMO | 02:21 |
| james_w | I can't really see any other issues | 02:22 |
| lifeless | right | 02:23 |
| james_w | if there is a target tree, now or later, then it will override, so that would get you out of some holes | 02:23 |
| lifeless | I put dup catching code in my patch, fwiw | 02:23 |
| james_w | lifeless: well, I spent the morning dealing with a crash due to duplicated ids :-) | 02:23 |
| lifeless | ahh | 02:24 |
| james_w | coming from a rather odd place though | 02:24 |
| james_w | if upstream renamed a file, then shipped another file at the old path in the tarball that wasn't in the branch, the code would use the same id for both | 02:24 |
| james_w | when may we want target trees in import-dsc? | 02:26 |
| james_w | maybe when we detect e.g. a merge from debian->ubuntu | 02:27 |
| lifeless | james_w: hang on, I fixed that exact same bug 3-4 months back | 02:27 |
| lifeless | james_w: with test. | 02:27 |
| james_w | I can see we may later when it knows about upstream trees and tries to guess how to graft them on | 02:28 |
| lifeless | james_w: this sounds like a regression | 02:28 |
| james_w | lifeless: I think it was the other way round, where it renamed on top of another file | 02:28 |
| lifeless | oh, perhaps its a variation on the theme. | 02:28 |
| james_w | bug 588060 | 02:29 |
| ubot5` | Launchpad bug 588060 in bzr-builddeb "unversioned executability issue, perhaps in builddeb (affected: 2, heat: 7)" [High,Fix committed] https://launchpad.net/bugs/588060 | 02:29 |
| james_w | ah, no, you fixed rename and replace with a versioned file | 02:30 |
| james_w | I just extended it to unversioned | 02:30 |
| * james_w gets to work implementing the above | 02:31 | |
| spiv | Hmm, yo yo internet for me today. | 03:17 |
| james_w | done | 03:54 |
| james_w | night all | 03:54 |
| poolie | night james | 03:55 |
| jam | hey poolie I have a question for you | 04:32 |
| jam | I had a question about async/sync feedback of the spawned process. I have all the connections working and "bzr log bzr+ssh://" is working, but it ends up hanging because Twisted needs to know when the process ends | 04:47 |
| jam | anyway, I'll try to write something up | 04:47 |
| * jam goes to play the new Metroid | 04:47 | |
| poolie | hi jam | 05:21 |
| poolie | jam, can you point me to your code? | 05:21 |
| vila | hi all ! | 07:55 |
| vila | poolie: see late comment on your ui mp | 08:01 |
| poolie | k | 08:01 |
| poolie | vila i'm just trying a side branch towards testing these things from scriptrunners | 08:01 |
| poolie | bit of a distraction but nice if we can do it, from the point of view of testable examples | 08:01 |
| vila | sure thing | 08:01 |
| vila | I'm feeling more and more inclined to write 'bzr config'... | 08:02 |
| poolie | arguably the 'all the configs we have open' should be semi-global state | 08:03 |
| poolie | perhaps in this context object robert wanted | 08:03 |
| poolie | vila, oh, what would it do? just be a command to set state? | 08:03 |
| vila | poolie: explore the active configs for wt/branch/repo/nothing (revealing the overrides) and set one config var | 08:04 |
| vila | or *unset* one ! | 08:04 |
| poolie | could be good | 08:06 |
| poolie | what are you going to do today? | 08:06 |
| vila | finish submitting proposal for bug #323111 and then... setup a proper TODO list | 08:07 |
| ubot5` | Launchpad bug 323111 in Bazaar "Cannot delete directory with ignored files (affected: 1, heat: 8)" [Medium,In progress] https://launchpad.net/bugs/323111 | 08:07 |
| poolie | i mention script runners because even when i intentionally change uncommit's confirmation string, it still passes its tests :/ | 08:07 |
| poolie | oh, yay | 08:07 |
| vila | urgh, how come ? | 08:08 |
| poolie | it seems that aspect is not tested | 08:09 |
| poolie | i would guess because it's a bit too hard to write good tests for user confirmation | 08:10 |
| poolie | spiv, where was that testdoc script? | 08:10 |
| vila | he he :) :-| :-/ | 08:10 |
| poolie | vila, so fwiw it fails because scripts run with a TestUIFactory whose stdin is connected to a (probably empty) stringio | 08:23 |
| * vila shudders... almost all transform tests force the format to be dirstate-with-subtree, I wonder what consequences it has on coverage :-/ | 08:23 | |
| poolie | would it be reasonable to arrange for them to pull lines from the script? maybe so | 08:23 |
| poolie | perhaps only for tests that specifically want this? | 08:24 |
| vila | err, did you try adding '< y' lines ? | 08:24 |
| vila | if the script provides no input, that should be an empty stringio, but if it does... it should be respected | 08:24 |
| poolie | hm | 08:25 |
| vila | hmm, ok, I overreacted, half of them only force the format :-/ | 08:25 |
| poolie | still, would be good to separate it out | 08:26 |
| poolie | at least to an abstract "a format with subtrees" | 08:26 |
| poolie | we could grep for more tests like that | 08:26 |
| vila | yup, or put them under.. per_workingtree | 08:26 |
| vila | oh wait, there may be some there already so probably they *are* tested indirectly | 08:27 |
| === zyga-gone is now known as zyga | ||
| poolie | actually it's better than i thought | 08:27 |
| poolie | it complains the string is missing a newline | 08:27 |
| poolie | which it is | 08:27 |
| poolie | but it seems easy to make it tolerate that | 08:27 |
| poolie | but now i really need to go | 08:27 |
| vila | script error reporting needs some love, iirc I needed a trick to produce correct line numbers for embedded strings | 08:28 |
| poolie | just getting a diff across the whole script might help | 08:30 |
| poolie | sometimes the one line it complains about is not very obvious | 08:30 |
| poolie | matcher might help | 08:30 |
| vila | matchers... yeah, I should *really* start using them :-/ | 08:30 |
| poolie | not so hard | 08:32 |
| poolie | just need to change your habit | 08:32 |
| poolie | oh, and we need to convert some existing utilities | 08:32 |
| vila | oh, I'm fully convinced :) | 08:33 |
| vila | It's just that I keep forgetting ;) | 08:33 |
| bialix | hey | 08:36 |
| bialix | vila, poolie: re https://code.launchpad.net/~mbp/bzr/ui-factory/+merge/34956 | 08:36 |
| bialix | what qbzr should be aware of? | 08:36 |
| vila | bialix: the new ui.confirm_action() method, that's the point of the mp | 08:37 |
| bialix | so? | 08:37 |
| bialix | my brain is slightly slow this morning | 08:37 |
| vila | bialix: may be you should read it, or at least the comments | 08:38 |
| vila | bialix: the question is: 'what impact would it have on qbzr if any' to add a new ui method | 08:38 |
| bialix | ok, IIUC qbzr should override this method, right? | 08:39 |
| vila | bialix: if you want to decorate it yes, otherwise it will fallback to get_boolean | 08:39 |
| bialix | as I remember we already using our own ui class, so we just need to override that method here | 08:39 |
| bialix | the good example is quncommit | 08:40 |
| vila | bialix: yeah, I think it's enough, I was worried about a case where you override confirm_action and not get_boolean, but that doesn't make sense I think | 08:41 |
| bialix | it has the custom asker | 08:41 |
| bialix | no, I really feel stupid today, wait a sec | 08:41 |
| vila | my concern was: are we introducing a new method that suddenly will prompt from the console ? | 08:42 |
| bialix | http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head%3A/lib/subprocess.py#L832 | 08:42 |
| bialix | my answer based on the link above: no, we have implementation for get_boolean | 08:43 |
| bialix | we == qbzr | 08:43 |
| vila | but since the implementation use get_boolean, I think it was silly. Now, if we make confirm_action depends on config variables... there may be other concerns like: always ask when using GUI, respect config var from command line | 08:43 |
| bialix | vila: how well bzt-gtk will behave I don't know | 08:43 |
| vila | & respect config var from command line *otherwise* | 08:44 |
| bialix | "I think it was silly" -- I don't understand | 08:44 |
| bialix | which one config var from command-line? | 08:44 |
| vila | I think *I* was silly, my concern was silly | 08:44 |
| vila | confirm_action use a confirmation_id the plan is to map it to a config var | 08:45 |
| bialix | so, your concern about our inability to handle get_boolean was wrong, right? ok | 08:45 |
| vila | so, for uncommit, the default will still be to ask the user, but *I* will be able to set it from a config file to say: 'hey, I just the command, stop asking will you ?' | 08:46 |
| vila | bialix: yes | 08:46 |
| vila | so, for uncommit, the default will still be to ask the user, but *I* will be able to set it from a config file to say: 'hey, I just typed the command, stop asking will you ?' | 08:46 |
| bialix | so, your concern about our inability to handle get_boolean was wrong, right? ok, when user can override any config parameter from command-line in the universal way? that would be great | 08:46 |
| bialix | sorry | 08:46 |
| bialix | the last message messed up | 08:47 |
| bialix | something wrong with chatzilla | 08:47 |
| bialix | will we have an universal way to override any config option from command line, like hg? | 08:48 |
| vila | bialix: you mean:<vila> I'm feeling more and more inclined to write 'bzr config'... ? | 08:49 |
| vila | <poolie> vila, oh, what would it do? just be a command to set state? | 08:49 |
| vila | <vila> poolie: explore the active configs for wt/branch/repo/nothing (revealing the overrides) and set one config var | 08:49 |
| vila | <vila> or *unset* one ! | 08:49 |
| bialix | vila: no, like this: `bzr uncommit --config "bazaar.conf:uncomiit_dont_ask_me = True" | 08:50 |
| vila | bialix: no like -obzrlib.lock.break=y | 08:50 |
| bialix | hg allows user to provide config settings for *current* coimmand | 08:50 |
| bialix | the latter is fine too | 08:51 |
| vila | bialix: see bug #<that one, thanks ubottu> | 08:51 |
| bialix | ubottu, don't sleep, read vila's mind, please | 08:51 |
| vila | bug #491196 | 08:52 |
| ubot5` | Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line (affected: 3, heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/491196 | 08:52 |
| vila | yeah, -O not -o | 08:52 |
| bialix | yeah, rocks | 08:53 |
| vila | bialix: just metoo it will you ? :D | 08:53 |
| bialix | :-) | 08:53 |
| bialix | bug 634240 | 09:04 |
| ubot5` | Launchpad bug 634240 in Bazaar Explorer "Initializing colocated branch fails. (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/634240 | 09:04 |
| bialix | signature of set_reference was changed in 2.2? but news has no mention of it | 09:04 |
| bialix | vila: you merged taht patch from jelmer | 09:11 |
| bialix | it has no news | 09:11 |
| vila | patches welcome :) | 09:11 |
| bialix | revno 5050.115.58 | 09:11 |
| bialix | in trunk | 09:12 |
| bialix | the train is already left the station | 09:12 |
| bialix | who want patches now? | 09:12 |
| vila | all the people ready to fall in the same trap | 09:12 |
| vila | bialix: I can't find this revno, revid ? | 09:13 |
| bialix | sorrrrrrrrrry, it's revno in 2.2 branch | 09:14 |
| bialix | revid:pqm@pqm.ubuntu.com-20100507115028-tuuxmnormm8oetw6 | 09:14 |
| bialix | it was possible to avoid compatibility break here, but anyway, the train is already left | 09:15 |
| bialix | sorry for the rant | 09:15 |
| vila | bialix: right, I reviewed it and rely on bzr-loom to catch compatibility issues so I missed this one :-/ | 09:18 |
| vila | bialix: is that a problem for bzr-explorer only or are there other colo related plugins that will suffer from it | 09:19 |
| bialix | I'm not sure yet, I need to check bzr-colo plugin itself | 09:19 |
| vila | bialix: did you find this by running a test suite or manually ? | 09:19 |
| vila | bialix: underlying question: can we automate something to detect such problems in the future ? | 09:20 |
| bialix | user filed bug report | 09:20 |
| vila | :-( | 09:20 |
| bialix | vila: perhaps | 09:20 |
| bialix | this specific bug -- yes, it's possible to create at least blackbox test for explorer | 09:21 |
| vila | On the positive side, it's more instance satisfying the rule: any bug is a missing test :) | 09:21 |
| bialix | will do while I will be fixing this particular bug | 09:21 |
| vila | bialix: thanks | 09:21 |
| bialix | vila: tests rock, yes, but gosh, it tends to steal too much time | 09:22 |
| vila | bialix: as do bugs | 09:22 |
| bialix | bzr-colo seems not affected, Neil has 2 code paths for 2.1 and 2.2 | 09:23 |
| spiv | Hmm, the per_tree/test_list_files.py tests could use some refactoring (and many more cases) | 09:26 |
| * vila grumbles: stupid emacs can't be spawned from xchat to open spiv links | 09:27 | |
| * vila get away from copy/pasted test code in disgust :( | 09:28 | |
| vila | spiv: from future import BB:approve :) | 09:28 |
| spiv | vila: hah | 09:29 |
| spiv | Something to try forget about over the weekend and tackle on Monday, perhaps :) | 09:30 |
| spiv | vila: have a good weekend :) | 09:30 |
| vila | spiv: you too ! | 09:30 |
| spiv | Also, I'm enjoying the new --format=shiny I added to lp:testdoc | 09:30 |
| vila | spiv: wow, yummy ! | 09:34 |
| vila | spiv: did you try that on the bzr test suite ? | 09:35 |
| bialix | vila: from past import brlib-2.1 :-P | 09:39 |
| * bialix hides | 09:39 | |
| vila | bialix: you're so last century :-p | 09:39 |
| bialix | I'm tired to fix bugs every time some lib updated it's version | 09:40 |
| bialix | and, yes, I'm | 09:40 |
| jdobrien | help! | 11:24 |
| jdobrien | I am having a problem in maverick with bzr | 11:24 |
| jdobrien | pqm-submit is broken now | 11:24 |
| jdobrien | which...I need :) | 11:24 |
| === mthaddon 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 | Release Manager: jam | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| jdobrien | hehe | 11:26 |
| GaryvdM | jdobrien: What error are you getting | 11:26 |
| jdobrien | Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://None@bazaar.ubunet/)> ignored | 11:26 |
| jdobrien | Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0x17088c0> ignored | 11:26 |
| jdobrien | sorry for the paste | 11:26 |
| GaryvdM | np | 11:27 |
| GaryvdM | jdobrien: Seeing If I can reproduce | 11:27 |
| lifeless | I'm just droppng by after cleaning teeth :P | 11:28 |
| lifeless | 2.2.1 fixes this | 11:28 |
| jdobrien | GaryvdM, this is with the latest from bzr | 11:28 |
| jdobrien | GaryvdM, sorry. i mean latest maverick | 11:28 |
| lifeless | it shouldn't be harmful for pqm-submit though, just noisy. | 11:28 |
| * lifeless waves bai | 11:28 | |
| jdobrien | hmm | 11:28 |
| jdobrien | GaryvdM, oh fiddle-dee dee, lifeless is right. it's still working | 11:29 |
| jdobrien | now i have queued my job many times :) | 11:29 |
| jml | I've got a bunch of checkouts in a directory, and I'd like to quickly get some information about their diff from trunk | 12:25 |
| jml | essentially, I want to do "bzr di -r submit: $checkout | wc -l" for each of them | 12:26 |
| jml | is there a plugin for this | 12:26 |
| spiv | jml: not that I know of | 12:51 |
| spiv | vila: yes, I added --format=shiny to testdoc because I wanted a quick and easy way to get a sense of the tests that were already in a module | 12:51 |
| jml | spiv, thanks. | 12:51 |
| jml | I hope vila's bzr-gardener is released someday soon. | 12:51 |
| spiv | Although I did try it out on bzrlib/tests/test_*.py, and it looked... shiny. Bit long, though ;) | 12:51 |
| vila | jml: shudder, me too | 12:51 |
| vila | jml: but it's in the front of my mind I swear | 12:52 |
| jml | :) | 12:52 |
| vila | jml: I even have an emacs opened with an unfinished line of code :-/ | 12:52 |
| vila | spiv: is it visible somehwere ? | 12:53 |
| spiv | vila: it's visible in your very own terminal! testdoc --format=shiny bzrlib/tests/test_*.py | 12:55 |
| vila | spiv: hehe, the next question would have been: 'or is there a one-liner ?' :-D | 12:55 |
| spiv | vila: it's pretty simple tool. | 12:56 |
| vila | spiv: hmpf, attributes... emacs.raise ENOTIMPLEMENTED | 13:10 |
| vila | ha, works better in terminal.... reminds me of gentoo :-P | 13:11 |
| vila | spiv: err, some text is barely readable, is that deliberate ? | 13:12 |
| vila | spiv: things like: From Unicode String Ascii Contents | 13:12 |
| vila | From Unicode Deprecated | 13:12 |
| vila | From Unicode String Unicode Contents | 13:12 |
| vila | From Utf8 String | 13:12 |
| vila | None | 13:12 |
| vila | are in so grey so light... it's white :) | 13:13 |
| vila | spiv: [37;1m | 13:13 |
| === CcxCZ_ is now known as CcxCZ | ||
| spiv | vila: my terminal has a dark background. | 13:37 |
| spiv | vila: patches welcome! | 13:37 |
| vila | hehe | 13:37 |
| === tchan1 is now known as tchan | ||
| allenap | MemoryTree has no revert() method, WorkingTree does. Does anyone know if this is this intentional or a defect? I tried, briefly, to use TestCaseWithMemoryTree in some Tarmac tests, but Tarmac relies quite heavily on revert. I wondered if I should file a bug. | 16:18 |
| mgz | this... rings a bell | 16:18 |
| * mgz seaches list archives | 16:19 | |
| mgz | https://lists.canonical.com/archives/bazaar/2009q3/061426.html | 16:20 |
| mgz | about merge rather than revert, but "MemoryTrees aren't a complete | 16:21 |
| mgz | emulation of a WorkingTree | 16:21 |
| mgz | seems relevent. | 16:22 |
| mgz | file a bug maybe? | 16:22 |
| jelmer | alennap: revert and merge both use treetransform underneath | 16:23 |
| allenap | mgz: If MemoryTree is not intended as a full emulation of WorkingTree then that's enough. I might file a bug to update the docstring though. | 16:24 |
| james_w | jelmer: revert doesn't does it? | 16:24 |
| jelmer | james_w: it does, WorkingTree.revert() calls out to bzrlib.transform.revert which uses TreeTransform | 16:26 |
| allenap | jelmer: I don't have any experience with treetransform. I am fairly inexperienced with bzrlib on the whole. Are you suggesting that I could perform a revert on a MemoryTree using treetransform? | 16:30 |
| bialix | GaryvdM: ping | 16:33 |
| jelmer | allenap: Aaron's saying in that email that merge doesn't work for memory tree because there are alternatives (PreviewTree, TransformPreview) for treetransform on memorytree. I merely wanted to clarify that that goes for revert, too. | 16:33 |
| bialix | GaryvdM: what is your mind on bug #614123? | 16:33 |
| ubot5` | Launchpad bug 614123 in QBzr 0.19 "Model tests not testing correctly (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/614123 | 16:33 |
| allenap | jelmer: Okay, cool :) Thank you. | 16:34 |
| jelmer | allenap: Unless you can use PreviewTree/TransformPreview in the code too, it's probably not possible to use TestCaseWithMemoryTree I guess. Perhaps Aaron has suggestions. | 16:34 |
| allenap | mgz: Thank you too. | 16:34 |
| allenap | jelmer: I'm okay doing without TestCaseWithMemoryTree. The test suite is fairly small for Tarmac and will remain so for a long while I would imagine, so using on-disk trees is fine for now. | 16:37 |
| jelmer | allenap: if you're used to the launchpad testsuite everything is fast and small ;-) | 16:38 |
| allenap | jelmer: Dead right :) | 16:38 |
| james_w | jelmer: huh, I thought it was implemented separately, thanks | 16:40 |
| jelmer | it's quite elegant the way it's done. | 16:41 |
| === deryck is now known as deryck[lunch] | ||
| === Ursinha is now known as Ursinha-lunch | ||
| mgz | gra, annoying bugs. | 17:07 |
| mgz | erm... jelmer, the email I just sent you probably comes off rather too snarky. what I meant was saying "Don't Do That Then" doesn't seem to be an effective stratgey to dealing with cross platform issues | 17:11 |
| jelmer | mgz: It didn't come across as particularly snarky but thanks anyway :-) | 17:25 |
| === beuno is now known as beuno-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === deryck[lunch] is now known as deryck | ||
| === sidnei is now known as sidnei-lunch | ||
| mgz | is launchpad ignoring email from jam? I see a couple of messages from him that launchpad still doesn't have. | 18:11 |
| mgz | eg, https://code.launchpad.net/~vila/bzr/323111-backup-names/+merge/35109 | 18:11 |
| vila | mgz: yeah, he voted but forgot to sign and I reply to the mp... | 18:13 |
| vila | replied | 18:14 |
| vila | mgz: so launchpad refused his email, but *I* only commented so no sig required | 18:14 |
| vila | urgh, hopefully the spammers don't read this channel :-} | 18:15 |
| cody-somerville | vila, if not, I'm sure they google for "hopefully the spammers don't read this" ;p | 18:25 |
| vila | cody-somerville: ouch: About 794,000 results (0.22 seconds) | 18:26 |
| vila | cody-somerville: dood luck to them :-D | 18:26 |
| vila | ghadd good luck, pff, bad luck yeah | 18:26 |
| mgz | vila, have we got a bug about the babune random failure on bzrlib.tests.per_transport.TransportTests.test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) ? | 18:28 |
| vila | mgz: spiv filed on upstream | 18:28 |
| mgz | cool. | 18:28 |
| vila | mgz: you're talking about the https specific one right ? | 18:28 |
| mgz | looks like it. | 18:28 |
| vila | where we get some attribute missing instead of EBADF ? | 18:30 |
| mgz | yup. | 18:32 |
| vila | mgz: there is also the infamous error: Socket is closed in lib/python/paramiko/channel.py", line 787, in sendall_stderr | 18:33 |
| vila | I don't know if we have a bug filed for that, but ISTR that we catch OSError when we should catch socket.error somewhere... | 18:34 |
| mgz | spiv got that one too though, right? (provided paramiko ever releases a new version) | 18:34 |
| vila | no, spiv patch is about IPV4 IPV6 | 18:35 |
| vila | the one I mentioned doesn't make any test fail, just a spurious traceback | 18:35 |
| vila | from a private paramiko thread or do you I mix several ones... haaa, I need to finish something else first :) | 18:36 |
| * mgz stops distracting vila | 18:36 | |
| * vila is sure mgz has better things to do :-P | 18:37 | |
| mgz | that is also true... :P | 18:37 |
| GaryvdM | mgz: How much do you know about building vsproj? | 18:41 |
| GaryvdM | I got an error building tortoisebzr, which I've know idea how to fix :-( | 18:41 |
| GaryvdM | But I restared my vm, as I'll only be able to pastebin error in about 5 min | 18:42 |
| mgz | not much unfortunately, I'm not up to date on the tooling changes | 18:42 |
| GaryvdM | He - I'm sure you know more than me :-) | 18:43 |
| mgz | paste it when you've got it and I'll see if I can help | 18:43 |
| GaryvdM | Ok thanks | 18:44 |
| === beuno-lunch is now known as beuno | ||
| mgz | 12448KB 31KB/s | Fetching revisions:Inserting stream <- what the hell bzr, this is a one rev change on top of the very latest bzr.dev | 18:57 |
| mgz | pushing that shouldn't require more than 10MB download | 18:58 |
| beuno | maybe it's packing | 18:58 |
| mgz | I'd really rather it didn't. | 18:59 |
| GaryvdM | beuno: Packing on a pull should not result in extra data being downloaded. | 19:00 |
| GaryvdM | It dose though on push to a dumb transport. | 19:00 |
| GaryvdM | mgz: bzr+ssh or http? | 19:00 |
| mgz | lp: so should be the former, right? | 19:01 |
| GaryvdM | Only if launchpad-login is set | 19:01 |
| mgz | it wouldn't let me push to lp:~gz without. | 19:01 |
| GaryvdM | Yhea | 19:01 |
| mgz | dammit! it's that same bug I hit before | 19:02 |
| mgz | what was the workaround... | 19:02 |
| mgz | (interrupted the first push because it was going sloooow/hung, and trying again does "fetch up to rev {None}") | 19:03 |
| mgz | ..delete branch via webinterface then push again | 19:04 |
| GaryvdM | mgz: Oh - this is a push, not a pull | 19:04 |
| GaryvdM | mgz: did it say it was stacking? | 19:05 |
| mgz | yeah, but this bug makes it re-download the entire repo. I'd just forgotten I'd done the exact same thing before. | 19:05 |
| mgz | ...in April. | 19:06 |
| mgz | https://lists.canonical.com/archives/bazaar/2010q2/068134.html | 19:06 |
| GaryvdM | vcbuild.exe : error VCBLD0004: Project 'c:\bzr_inst_build\bzr-windows-installers\build-win32\tortoisebzr\bzr-2.2\shellext\tbzrshellext.vcproj' does not contain a configuration called 'Release|x64'. | 19:09 |
| GaryvdM | http://pastebin.ubuntu.com/491715/ | 19:09 |
| GaryvdM | mgz: ^ and ideas? | 19:09 |
| mgz | okay, that sounds pretty straightforward | 19:10 |
| mgz | presumably the vsproj file really doesn't contain an x64 release config | 19:10 |
| * GaryvdM checks | 19:11 | |
| mgz | so, either the switch /p:Configuration="Release";Platform="x64" needs changing | 19:11 |
| mgz | or the project file needs to grow an x64 section | 19:11 |
| GaryvdM | It dose have the x64 platform in the .vcproj | 19:14 |
| GaryvdM | I think the problem my be that I only have 32bit windows :-( | 19:14 |
| GaryvdM | *may | 19:14 |
| mgz | hm... | 19:15 |
| GaryvdM | I think it tries to build 32bit and 64bit versions of the shellext | 19:15 |
| GaryvdM | Let me try figure out how to disable the 64 bit version build. | 19:16 |
| beuno | hrm | 19:52 |
| beuno | new bzr error for me: | 19:52 |
| beuno | beuno@beuno-laptop:~/canonical/ubunet/trunk/sourcecode/funambol_cared$ bzr up | 19:52 |
| beuno | bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-8005'), ('versioning no contents', 'new-8004'), ('versioning no contents', 'new-8008')] | 19:52 |
| === sidnei-lunch is now known as sidnei | ||
| === jelmer_ is now known as jelmer | ||
| vila | beuno: ouch, sry I was afk (dinner and cooking, yes in that order), did you manage to sort it out ? | 21:46 |
| beuno | vila, hi! | 21:47 |
| beuno | yes | 21:47 |
| vila | beuno: 1) malformed transform is only raised for *bugs* | 21:47 |
| beuno | I poked it at until it went away | 21:47 |
| beuno | reverted, updated, yelled | 21:47 |
| beuno | not sure how I can report this, if it was a bug | 21:47 |
| vila | it would be nice if you had a recipe to reproduce | 21:47 |
| vila | beuno: it probably involve setting the same branches/checkout at some revisions... Did you had uncommitted changes ? | 21:48 |
| vila | beuno: what kind of wt was it ? branch, checkout, light/heavy, bound branch ? | 21:49 |
| vila | beuno: may be just attaching a good chunk of your .bzr.log could be a good start and shouldn't require too much time | 21:50 |
| vila | beuno: poking at that we may have direct answers or more precise questions | 21:50 |
| vila | vila: I try to summarize my thoughts quickly because I won't be long ;) | 21:51 |
| fullermd | If you have to summarize your thoughts to yourself, I think you WON'T be long :p | 21:55 |
| beuno | vila, I can do that | 21:58 |
| beuno | the branch is ~1gb | 21:58 |
| beuno | from a private project | 21:58 |
| beuno | I'll file a bug with logs | 21:59 |
| beuno | and we can take it from there | 21:59 |
| vila | beuno: wfm | 22:08 |
| vila | fullermd: My thoughts are currently focused on my cooking (which I'm not sure you will be offered to taste now (which you will, I'm sure, deeply regret :-P) and let me assure you it smells already very good) and that, trust me, just can't be summarized, no matter how long you thought about it :-D Now go check the parenthesis, summary ! Ha ! | 22:12 |
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!