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