[00:04] lifeless: it's consistent with the announcement of Launchpad APIs. === rocky1 is now known as rocky [00:15] jml: I don't understand [00:17] jam: so I'm looking at disabling auto-detection of plink as (I think :) everyone agreed. This would means that source-code users who do not have paramiko, but do have pageant/plink setup will not work at all without setting BZR_SSH. ie, we will "fix" plink users that don't use pageant at the cost of "breaking" users that use plink + pageant to manage their keys who work today. Is that the intent? [00:20] markh: why disable plink? [00:21] (short answer is fine, I just missed the conversation) [00:21] plink is unable to correctly interactively prompt for a passphrase [00:21] it was disable plink *detection* [00:21] so setting BZR_SSH=plink would still allow it to work [00:21] have we filed a bug about that ? [00:22] but - the point I was making is that plink works fine is pageant is used (meaning plink doesn't *need* to prompt for the passphrase) [00:22] so can we detect plink+pagent vs plink w/o pagent ? [00:22] https://bugs.launchpad.net/bzr/+bug/107593 is the closest IIUC [00:22] Launchpad bug 107593 in bzr "bzr unable to ask password for access over bzr+ssh:// or sftp:// when plink.exe used as SSH client" [Low,Fix released] [00:22] markh: well I was meaning in the plink bugtracker :P [00:23] but the resolution to that was simply to pass a param to plink that stops it even *trying* to prompt :) [00:23] there is something funky going on with windows consoles [00:23] plink executed directly works fine [00:23] so we'd need more research to file a plink bug [00:25] * markh idly wonders how a windows GUI app could hope for either ssh or plink to prompt for a passphrase... [00:27] so - I actually think the status quo is fine. There is almost an expectation that BZR_SSH needs to be set, and I think the current plink default behaviour helps more people than changing it would. [00:28] and later we can see if we can convince plink to prompt like ssh, and everyone remains happy (except me with ssh.exe on my path, but I digress ;) ) [00:30] markh: sounds fine to me [00:30] FWIW [00:30] cool - thx! [00:31] that was my last task for the binaries too (well, apart from releasing them and submitting changes upstream and working out what we do with them once I've uploaded them :) [00:32] the bzrsvn plugin isn't working that well, but I think there is still value to including it given we aren't trying to call it anything like stable/final [00:32] cool === mark1 is now known as markh [01:08] heh - bzr just logged "... readv() read unknown bytes rather than unknown bytes at unknown for "http:..." - obviously it doesn't know much about that error :) [01:08] jelmer: lol @ gloom [01:10] hello markh, lifeless === poolie_ is now known as poolie [01:10] hi poolie [01:23] lifeless, (-: [01:23] lifeless, I hadn't realized the meaning of gloom in English [01:23] Now all we need is a command to Dump the Original Outside Metrics... [01:37] so I come from a history of using monotone which I want to move away from, I've just discovered some behaviours with Hg that I don't like and wanted to check see what bzr does [01:37] hi [01:37] but firstly, does bzr allow you to name branches? [01:37] yes, our model is that every branch is a directory on disk (we do support sharing the repository and having a single working tree that switches between branches) [01:37] jelmer: :) [01:38] lifeless: yeah, I get the model, I just wanted to see if you can give a name to a branch and then for example, switch to that branch just by going bzr update branchname [01:39] matthew-_: yes, 'bzr switch NAME' will look in $branch/../NAME [01:39] ahh ok. so the name of a branch isn't meta data that's attached to a revision? [01:40] we store a nickname in revisions [01:40] but its used for bzr viz and other such reporting, not for switching [01:40] the nickname that will be stored defaults to basename(branchdir); but can be forced via 'bzr nick' [01:41] ok, so if two people share the same set of revisions, they would have the same branch names for the same revisions? [01:41] uhm yes but I feel like we're not connecting somehow [01:42] we're not at all like hg in our treatment of branches [01:42] no I think we are. It's just that mtn assigns quite a lot of semantics to branch names and I just want to see how much that's carried across [01:42] yeah, you seem quite different to hg and mtn [01:42] we don't assign any semantic to branch names [01:42] ok, so let me give you a scenario [01:43] let's say I'm working on the mainline of my project and then I branch to start work on a new feature. My friend then wants to help me with this new feature. So how do I identify to him which branch he should switch to? [01:44] just tell him the url [01:44] right, of course, the branch is reflected in the url [01:44] I understand. thank you for your patience :) [01:44] happy to help, I'm here all day :) [01:45] so my next question is the following. Say I've made some changes, but not committed [01:45] I then do a switch to a different branch, or even just an update to a different revision [01:45] what would the output of bzr diff be? [01:46] your uncommitted changes [01:47] so it takes the diff from the current revision and then reapplies that diff to the new current revision? [01:48] well [01:48] the switch and update operations do a merge [01:49] a merge preserves edits (though they may conflict and if so you get conflicts as a result) [01:50] ok, so I probably didn't mean either switch or update ;) How would I change my current directory to be of a different revision? [01:51] switch moves you to a different branch; so that your commits will go to it [01:51] Depends on how deeply you mean that... [01:51] (its the same as switch on svn/git) [01:51] 'revert' will change the contents (and layout, presence, etc) of the files to be like that revision. [01:51] update is used when you have a tree that is out of date with its branch [01:52] But your WT still considers itself to be at whatever revision you were previously at, so e.g. 'diff' will show a lot. [01:52] ok, sorry, so many terms get reused between DVCSs and all with different semantics! [01:53] matthew-_: we've tried quite hard to be consistent with cvs/svn on these common commands, because they have market dominance - less relearning for bzr users [01:53] ok, so from revision X I add one line to a file. Then I do bzr revert Y where Y came before X. Then bzr diff will show all of the changes necessary to go from Y to X and to add the extra line? [01:53] lifeless: sure, I appreciate that. It's just I use neither :) [01:54] No, revert will blow away the uncommitted changes. [01:54] matthew-_: so you add one line [01:54] matthew-_: why do you want to change the revision the tree is at ? [01:54] Its main purpose is its name; 'revert this {file,dir,tree}'. That you can specify 'to a given revision' is fruit on top of that. [01:54] matthew-_: (as in, whats the follow up operation you want to do) [01:55] lifeless: say I've done an hour's work, without committing. I then realise that I'm on the wrong branch and I should commit to another branch, and thank goodness, I realise that the file I've altered is the same in both branches, so I should just be able to switch to the head of the branch I want, and commit there, without having to redo my work [01:56] matthew-_: 'bzr switch BRANCH; bzr diff' will show you just the work you've done [01:56] matthew-_: and it is switch you want, because you want to commit to a different branch [01:56] ok [01:56] morning [01:57] and what happens if the branch I switch to has altered the file I've worked on but in such a way that the diff still applies cleanly? [01:57] same [01:57] right, so it doesn't just apply my changes, it leaves the whole file unaltered [01:58] It's a little smarter than just 'diff'. It's more like if you committed the change, then merged it in the other branch. [01:59] matthew-_: no, it does a merge [01:59] matthew-_: so you only see your uncommitted work, transformed as needed by the merge [02:01] ok cool [02:05] ok, sorry, I have another question [02:05] say I want to start a branch, but I want to start it from a particular revision [02:06] branch -r /url /tosomewhere [02:06] how do I get back to that revision in order to create the branch? [02:06] er, -r nnn /url /tosomewhere [02:06] matthew-_: you don't need to go bac to the revision, you just need to give -r to the branch command, as bob2 says [02:07] ugh, this is my problem. I'm used to mtn where you normally have a single working directory that you move all over the place, rather than lots of directories [02:07] just a mental shift I guess [02:07] sure, that is what 'bzr switch' is for [02:07] create a repository somewhere, check out a branch from it. want a new branch, 'bzr branch . ~/repository/somename', 'bzr switch somename' [02:08] it is a trivial plugin to simplify that to 'bzr tbranch somename' [02:14] Or it could be a useful addition to 'switch'. [02:16] yeah, I wasn't sure how to integrate it into the existing ui [02:17] '-c' to create the branch (based on the current by default) and -r to specify a revision to start it from (which could include branch: revspecs or the like to specify a different one) [02:17] (I don't say that's the best; just the most obvious) [02:21] sorry, is there an ENV Var to set to force merge to use a nice tool? [02:22] I think there's a bzr plugin for meld... [02:23] dunno, but unclean merges leave the 2/3 sources files on disk so you can use any merge tool you like [02:23] err, I want to force it to use xxdiff [02:23] it won't automatically fire it up for me somehow? [02:23] Well, the existence of meld is the extent of my knowledge of "nice tool"s for merge ;) [02:25] jelmer: for some reason, bzrsvn is causing blackbox.test_check.ChrootedCheckTests.test_check_missing_branch to hang for me. It stops hanging with --no-plugins, or if I manually remove just svn. It seems to be reading from a socket, but I haven't dug any deeper. Any clues? [02:25] markh: No, sorry. I would guess it's related to the custom log function bzr-svn registers [02:25] ahh, extmerge is clearly what I want http://erik.bagfors.nu/bzr-plugins/extmerge/ [02:26] markh, seems strange it would hang in a socket operation though [02:26] matthew-_: you can also do "bzr diff --using xxdiff" I think === BasicTheProgram is now known as Basic [02:27] markh, if you comment out the custom log code in __init__.py:160, does that fix it? [02:27] that was just a very quick break into the debugger with no symbolic info... I'll try and repro it from a source version [02:29] apparently not :( [02:30] markh, where is it hanging then? [02:31] sorry - commenting 160-163 had no effect [02:33] bugger - source version is failing that test with an earlier pycurl error. I'll dig a little and see what i find. [02:34] this is probably related to the bug spiv filed [02:38] markh: I think the chance of someone using bzr +plink without paramiko is vanishingly small, and shouldn't be optimized for [02:39] paramiko is about 90% away from a "requires" [02:39] Especially if you are writing an installer [02:39] we would bundle it [02:39] So I think moving the plink autodetect to *after* paramiko is fine [02:40] jam: I'd say the chance of someone using passphrase protected keys with plink on their path but without pageant is approaching zero too. [02:41] ahh, so visualise doesn't show all heads of all branchs in the current repo. It just shows the head of the current branch [02:41] markh: well, if pageant would find the keys for me, I might actually use it :) [02:41] sure - but as you dont it will not be on your path, so no problem :) [02:41] matthew-_: ATM, I think there has been work to allow it to show more heads [02:42] markh: agreed, no problem [02:42] the problem with plink isn't with keys [02:42] (otoh, I think its reasonable it *may* be on your path, likes its reasonable ssh may be on mine, which is why I think paramiko is a better default, but I think we've done that already ;) [02:42] it is that you can't prompt for *any* password [02:42] markh: so with plink you can't access a password-protected page [02:42] but you *can* with paramiko [02:43] right - paramike seems to have everything going for it ;) [02:43] over plink, yes [02:43] over ssh, no [02:43] at least IMO [02:43] you can't really configure plink to use a config [02:43] without passing in a command line option [02:43] you *can* for ssh [02:44] matthew-_: vis can show multiple branches at a time, but normally it just shows your current branch. [02:47] I think we should wait for the "bug" reports before making things more convoluted. At least the status-quo of "we try and find known ssh vendors on your path, or fall back to paramiko" is easy to explain, and as you point out, setting BZR_SSH isn't hard either - especially when "fixing" plink and/or paramiko to overcome the limitations we are discussing would also change the "best" defaults IMO. [02:50] jelmer: just to mention, you probably shouldn't do "getattr()" on the plugins, but try a "try import except ImportError" [02:50] Because you don't know that loom will be imported *before* gtk [02:50] jam: hi [02:50] hi lifeless [02:50] jam: did you change mail client a month or so back? [02:50] you seem to be quoting much more than you used to [02:50] lifeless: still using T-bird, why? [02:50] * igc lunch [02:51] probably just depends on my mood [02:51] its a little weird to quote 40-50 lines to reply with 7 [02:51] IMNSHO [02:52] jelmer: it appears to be in SvnRemoteFormat._open [02:53] then calling into ra.pyd, which presumably is remote.SvnRemoteAccess [02:53] lifeless: It would be weirder if I edited *some* of the message but left the rest [02:53] in this case I just hit reply [02:53] and replied [02:54] better than top-posting, IMO [02:54] lol.. ok [02:54] I just thought I'd mention it, because I've had a feeling of wading through quotes to try and find your comments recently === Verterok_ is now known as Verterok [02:55] I'll try to be a bit more terse [02:55] jam, thanks, fixed now [02:55] its not a big deal [02:57] ok, I'm confused, again! [02:57] matthew-_: shoot [02:58] if I do init-repo --no-trees repo; init repo/trunk; co --lightweight repo/trunk trunk; cd trunk [02:58] then commits get sent to repo/trunk [02:58] yes [02:58] so it would appear that it's bound to the repo [02:58] but unbind says it's not bound to anything [02:58] hmm, bit of plumbing exposed here [02:59] so the --lightweight option means that 'trunk' has no branch object [02:59] markh: So it's probably attempting to open the path specified as a subversion repo [02:59] 'bound branches' are what you get if you omit the --lightweight parameter [02:59] markh: I wouldn't know why that would cause a hang though [02:59] ok [02:59] so why is there no --lightweight option to branch? [02:59] 'bound branches' are a way to emulate cvs/svn's tree facility while still having full local history [02:59] yes, I understand that [02:59] jam: your last mail said you yourself stick cygwin\bin on your path, and given ssh-agent is almost impossible to use for mere-mortals on Windows, I'm surprised you think it is the "extreme minority" case that people will have an ssh.exe on their path even though they use pageant to manage their keys and use ssh.exe rarely, if at all. But I guess we just have to agree to disagree :) [03:00] markh, what specifically is it hanging on? [03:00] file handle? [03:00] because, in trunk, say I do a branch . ../mybranch; cd ../mybranch; nick mybranch [03:00] markh: well, *I* want to use ssh.exe [03:00] matthew-_: well, because branch makes a new branch object. We could possibly do --lightweight; however there is a command in bzrtools that you may like [03:00] I then want commits to go to repo/mybranch [03:00] markh: that is why I put it in my path [03:00] matthew-_: alled 'cbranch' [03:01] matthew-_: well, you probably want to do 'bzr branch repo/trunk repo/mybranch' bzr switch mybranch [03:01] jam: I fully understand that, but its just I'd think *you* are in the extreme minority for a windows developer in this regard ;) [03:01] I want to use various cygwin tools - that's why its on my path [03:01] markh: I think the effort to put things in your path means you want them there [03:01] lifeless: ahh! brilliant, thank you [03:01] and I'm not so careful to remove every tool I don't currently use [03:01] I think for *real* windows developers, they don't use cygwin [03:02] matthew-_: broad description - you want all your branches as repo/BRANCHNAME [03:02] and you want one lightweight checkout somewhere else [03:02] I don't use *everything* in my cygwin dir directly - but lots of build processes do. [03:02] switch in that checkout will accept just BRANCHNAME [03:02] most other commands want a longer relative or absolute path [03:02] lifeless: right. this is closer to the mtn model I'm used to than I thought [03:02] this is a bug - the logic for switch just needs to be hooked into these other commands [03:03] jam: is that because they don't understand them, or have alternatives for everything cygwin provides? [03:03] matthew-_: is that good or bad ? :) [03:03] all windows developers I know use them! [03:03] good, for me ;) [03:03] cool [03:04] I'd go so far to say "any windows developer who regularly uses the command prompt would use them". My concern is that includes our "target" developer, particularly in the early days until the GUIs get better. [03:04] s/any/many/ ;) [03:05] lifeless: ahh, but it doesn't seem to like switching when you have divergence [03:06] jelmer: sorry - it seems to be reading a socket, but I've not got symbolic info for the svn binaries [03:06] I don't want to merge. I just want to change my lightweight checkout to a different branch [03:06] spiv: http://rafb.net/p/0xKkTQ77.html [03:06] matthew-_: thats what switch does [03:06] matthew-_: what is happening [03:06] but it tried to do a merge. I was ci'd and everything [03:07] top of the stack is ntdll.dll, then below that is mswsock.dll, and below that ws2_32.dll, so that sure smells like a socket :) [03:07] matthew-_: the machinery of merge is whats used [03:07] matthew-_: so thats not surprising. Tell me what happened though [03:07] markh: I can agree with that, and if pageant +plink wasn't so crummy I would be fine putting paramiko first [03:07] but as it stands [03:07] pageant can't find a ssh-key [03:07] unless you add it every time you boot [03:08] whereas ssh.exe can find it in its "standard" location [03:08] ok. so I added a file with some lines and ci'd. Then I branched. Then, still in trunk, I added some more lines, ci'd. Then I switched to the new branch, added further lines (creating devergence) and ci'd. So far so good [03:08] then I switched back to trunk and it tried to merge [03:08] which I didn't want [03:09] matthew-_: what do you mean by tried to merge ? [03:09] matthew-_: you might be confused by the progress bar [03:09] it shouldn't merge the changes [03:09] (I use switch with diverged branches *all the time*) [03:09] just uses the "merge" logic to safely reset your tree [03:09] no, I got file.THIS, file.OTHER, file.BASE [03:09] matthew-_: did it leave the wrong content in your tree? [03:09] yes [03:09] matthew-_: hm... I haven't seen that [03:09] ok, run bzr st [03:09] do you have pending merges? [03:10] jam: and you use ssh-agent, correct? [03:10] err, I hit bzr revert in order to tidy up the mess ;) [03:10] markh: occasionally, but not all the time [03:10] let me try again [03:10] the problem is you can't get it to start at the beginning [03:10] so I just type my password a lot [03:11] but if it couldn't find the key, then I couldn't connect to LP [03:11] at one point I had a hacked up startup script [03:11] that would check if ssh-agent was started [03:11] if not, start it, and save the env vars [03:11] so the next bash shell would re-use it [03:11] jam: right - and as paramiko can prompt for passphrases, your only practical issue with paramiko being the default is that HOME is set differently in a cygwin environment than a "normal" one, so the same keys aren't found by paramiko? [03:11] but then the prompt would hang when you exit, etc [03:11] lifeless: I didn't nick the new branch. is that important? [03:12] it's just the path that's important right? not the nick? [03:12] matthew-_: not important [03:12] markh: well, and when I *do* use the agent I can't with paramiko [03:12] and pageant being worse... [03:13] ok, I must have done something wrong. It is behaving as you describe. sorry, my fault. [03:13] I certainly understand where you are coming from - I guess the question is - who is in the smallest minority, as they should probably take the "pain" of setting BZR_SSH. So we are back to agreeing to disagree about who that is ;) [03:14] matthew-_: I would wager you had uncommitted changes that conflicted [03:14] I'd say ssh-agent is such a world of hurt that its use is absolutely tiny - you are the first person I've ever met who uses it on windows. I understand why you do though. [03:15] jelmer: here-p? [03:16] mwhudson: Hello [03:16] jelmer: thumper would like to talk to you :) [03:16] well, even if you explicitly install cygwin, you have to install openssh as well [03:16] jelmer: hi [03:16] jelmer: we're talking about bzr-svn [03:16] mwhudson, He's too shy to say that himself ? :-) [03:16] thumper, hi! [03:16] jelmer: I can probably extract more of the stack trace if you are interested? [03:16] jelmer: and when the version 4 mapping will be available [03:16] python stack trace [03:16] we're doing the 'bzr-svn for code imports' conversation again [03:16] well, plink is far worse than ssh.exe [03:16] jelmer: I was trying to get mwhudson to be the typer [03:16] ok, thanks very much for all your help. I think I shall be using bzr from now on :) [03:16] regardless the agent [03:17] but this time we are all in a room! [03:17] jelmer: except you [03:17] jml: irc has rooms, right? [03:17] markh: yeah, that would probably be useful [03:17] we agree about how poor pageant is in those cases - just seem to disagree how many people use it over ssh-agent anyway :) [03:17] Heh [03:18] So it may be a good idea to list what mapping version 4 is going to be exactly [03:18] matthew-_: cool [03:18] yeah, something like that [03:18] It's mainly about supporting the storage of bzr metadata in revision properties [03:18] and removal of branching schemes [03:18] ok [03:18] and whatever happens to be around by the time it's put out [03:18] jelmer: and this would be when? [03:19] jml: I am still confused about this xmlrpc thing [03:19] spiv: can you tell me if that test looks plausible to you [03:19] lifeless: it is a way to call methods on a remote machine :) [03:20] Hopefully 0.4.11 + 1 or 2 months [03:20] lifeless: So, we've published the requestMirror method over Launchpad APIs. The client library (and documentation) isn't released yet.p [03:20] (0.4.11 is intended to be released together with bzr 1.6) [03:21] jml: so the bug isn't fixed - I as a user can't use it yet [03:21] jml: if I could, I could patch bzr's launchpad plugin to let 'bzr push' trigger a mirror [03:22] lifeless: the bug is fixed in Launchpad Bazaar. [03:22] so where is it not fixed, can we add a task on that [03:23] most of the other possible candidates for inclusion in mappingv4 rely on changes in bzr core [03:23] lifeless: Launchpad. If you add a task, I'll have to mark it as a duplicate of whatever bug is releasing the client API. [03:23] for the list, see https://bugs.edge.launchpad.net/bzr-svn/+bugs?field.tag=requires-mapping-upgrade [03:24] I think you are saying 'jml has no more code to write to make this work', which is fine; I'm saying 'I want the bug to be marked closed when I can use it' [03:24] jelmer: see /msg [03:25] How can I convince bzr to not attempt bzr+http? It seems to be disagreeing with SourceForge's Subversion server. [03:25] wgrant, svn+http:// [03:25] jelmer: Aha, thanks. [03:25] wgrant: although it should work even if there's no bzr server remotely - what error are you getting? [03:25] jelmer: It's SF's fault: [03:26] Connection error: while sending POST /svnroot/ivle/trunk/.bzr/smart: (104, 'Connection reset by peer') [03:26] is there some way to get bzr to show you all the branches in a given repo? [03:27] or do you just tend to do an ls and assume the same layout model? [03:27] matthew-_: bzr branches [03:27] bzr branches PREFIX [03:27] matthew-_: but yeah, I use shell tab completion :P [03:27] ahh, it needs the path to the repo. ok, thanks [03:28] matthew-_: repositories are purely storage otimisation [03:28] indeed [03:28] matthew-_: they aren't part of the semantic of commands [03:28] lifeless: that does look plausible, yeah. [03:28] jelmer: It seems that SF is just very broken at the moment. Sorry for the noise. [03:28] ok. so with mtn I wrote the tab completion for branches and there you have an attached repo, which is a sqlite db [03:29] wgrant, they sent out an email announcing downtime for ~12 hours [03:29] wgrant, apparently work on performance improvements [03:29] It has been ridiculously slow for a couple of weeks. [03:29] Minutes to commit a trivial change. [03:29] *.nz: Still there? [03:29] jelmer: yes. [03:30] oh, branches can't be nested? [03:30] jelmer: we're talking again [03:31] jelmer: sorry [03:31] jelmer: I think I'm pretty much done, I was just wondering about timings [03:31] matthew-_: as in /repo/a and /repo/a/b are branches? they can. [03:32] matthew-_: yah. One reason we use regular directories is to allow standard toolchains like bash, nautilus etc to all be useful directly [03:33] sorry, I'm an idiot. I created the branch and forgot to switch to it [03:34] :P [03:35] thumper: Within one or two months after bzr 1.6 is released I think [03:35] The main thing left to be done is tests for the upgrade from v3 to v4 mappings [03:35] jelmer: ok, thanks [03:38] * jelmer gets some sleep [03:47] another question, with mtn, you commit locally, then sync with your shared repo across the network. syncing is both push and pull but does that for all branches at the same time. How would you do this for bzr? Do you have to do a push and pull for every branch? [03:53] ahh ignore that, I've found repo-push [03:55] matthew-_: indeed; this is one of the things in mtn that is clever but doesn't work that well IMO [03:56] matthew-_: because you can't keep a private branch due to it always doing a full sync; the network sync logic depends on a full convergence for performance [04:07] The result is that I've ended up doing horrible hacks like having 2 mtn repos and very carefully crafted setups to have the private branches :| [04:08] fullermd: or use bzr :P [04:08] Well, I do that where possible :p [04:08] I'm waiting for Samba to move to mtn, so jelmer writes bzr-mtn... [04:12] cjwatson: ping [04:12] fullermd: doesn't mtn allow you to slightly modify history, by attaching a new certificate? [04:13] jam: annotate history I would say [04:13] not so much modify, as annotate/extend [04:13] Well, that's how you merge [propogate], but... [04:14] matthew-_: there is a 'repo-push' plugin [04:15] bob2: yeah, he mentioned it already :) [04:15] bah, oops [04:41] any idea why a selftest run with -q would have different results than -v [04:42] my blackbox tests has 3 tests...with -v (failures=2) with -q (failures=3) [04:45] jdobrien: That suggests that there's something wrong with the blackbox tests. How are you invoking bzr? [04:45] jdobrien: interesting [04:48] Odd_Bloke: ./bzr selftest RelativePathStatus [04:48] this is a new set of blackbox tests [04:49] there are 3 tests in all [04:49] 2 are expected to fail [04:49] (failures-2) when ./bzr selftest RelativePathStatus [04:50] (failures=3) when ./bzr selftest -q RelativePathStatus [04:51] why i am using -q with only 3 tests is related to my laziness :-) [04:52] jdobrien: I've never used -q with selftest [04:52] jdobrien: you'll need to debug the failure that is caused [04:52] indeed [04:52] lifeless: indeed [04:52] * meteoroid just started a new project using svn and populated it with bzr-svn [04:56] beuno: still awake? [04:56] mwhudson, yeap [04:57] so i'm looking at fix_setup [04:57] and seeing some things that don't appear to make heaps of sense [04:58] like [04:58] class InstallData(install_data): [04:58] def run(self): [04:58] install_data.run(self) [04:58] mwhudson: ping; what do you know about buffer objects ? [04:58] lifeless: as in 'things returned by the buffer() builtin' ? [04:58] http://python.active-venture.com/api/bufferObjects.html [04:58] PyBufferProcs [04:59] oh that [04:59] mwhudson, ah, right. THat used to do more things, but then I moved it around. I left if as-is because I wasn't sure how complex the installer will get [04:59] (doesn't jsutify it, just explains it) [04:59] beuno: i think i'd call yagni for now [04:59] beuno: also, there are both unecessary and missing imports [05:00] distuils leftovers? [05:00] lifeless: i know some stuff, what do you want to know? [05:00] beuno: yeah [05:00] beuno: and missing the import of bzrlib.errors [05:00]