[00:51] <pltonik> hello. i was wondering if it is possible to do 'daggy fixes' using bzr?
[00:58] <Pilky> poolie: you around?
[01:17] <jskulski> hey all
[01:18] <jskulski> i am wroking with a SVN repository that I branched with bzr-svn. I have been working succesfully, but when I bzr merge, commit, push it seems to overwrite any log of the real commit (everyone else is using svn as per normal)
[01:18] <jelmer> jskulski, see the bzr-svn FAQ
[01:20] <jskulski> jelmer:: thanks
[01:38] <mzz> is there some way to share *uncommitted* changes with someone that's better than "bzr diff" and doesn't involve me committing them? They're incomplete/broken, so I want to avoid committing.
[02:45] <Peng_> mzz: "bzr merge --uncommitted" *might* work remotely.
[02:45] <Peng_> mzz: You might also be able to rig something using shelves. E.g. "bzr shelve" the changes and then rsync/scp the files over. Or something.
[02:45] <mzz> Peng_: mmm, but only if the branch I'm trying to merge from is accessible remotely by the other user, so that wouldn't really work here.
[02:45] <Peng_> mzz: There are probably better ideas, but I don't know them. :D
[02:46] <mzz> Peng_: (perhaps other people would just commit for this case)
[02:46] <mzz> if this was my own code I'd just use commit and uncommit, because I'd be pretty sure the bogus revision wouldn't "escape" after I uncommit it.
[02:46] <mzz> err, if both branches were on systems I control, I mean. Or something like that.
[02:47] <mzz> the goal here was to share a very incomplete change with someone else, and they found a pastebinned diff a little hard to read and apply.
[02:48] <mzz> he wanted me to push the change to launchpad, but pushing a known broken branch to launchpad seemed like a bad idea.
[02:48] <Peng_> mzz: Personally, I'd commit it, with a message explaining that it's half-complete and currently broken.
[02:48] <Peng_> mzz: Hmm, didn't think of Launchpad. I push things to my server and kind of mirror them on LP as an afterthought. Huh.
[02:48] <Peng_> mzz: Still, you could push it up in a separate branch, maybe even in +junk, with a name and/or description that explains it.
[02:49] <mzz> Peng_: I actually have my own http server to push to too, just trying to work like I don't, since it may become a less convenient option in the future.
[02:49] <Peng_> I hope it doesn't become less convenient. :D
[02:49] <mzz> yeah, I guess a +junk branch is just the best option available and I should be less anal about only pushing commits I think work (it's actually not like I never commit broken code, I just try not to do it *intentionally* :)
[02:50] <Peng_> Heh
[02:50] <Peng_> Pretend you didn't notice? :D
[02:50] <Peng_> (that it doesn't work)
[03:42] <sohail> OK PEOPLE EMERGENCY
[03:42] <sohail> just kidding
[03:42] <sohail> I'm going to be away from coding headquarters and would like to code, however I need to be able to work on multiple branches
[03:43] <sohail> I can clone the master branch, but then do I have to clone all the branches manually?
[03:43] <sohail> I did bzr clone bzr+ssh://.../path/to/master master
[03:50] <Peng_> sohail: What do you mean? You want to get copies of a bunch of branches at once, without having to run "bzr branch" 17 times?
[03:51] <sohail> Peng_, I don't even know what I should be doing, branching or cloning
[03:51] <sohail> and yes, I'd like to basically have exactly the same setup as I have on my desktop
[03:51] <sohail> (all the branches)
[03:52] <Peng_> sohail: Welll...I'd probably just use rsync.
[03:53] <Peng_> sohail: There are plugins that help with this, but I can't remember their names. multi-pull is one.
[03:53] <sohail> Peng_, then how would I push back, just rsync back?
[03:53] <sohail> is that safe?
[03:59] <Peng_> sohail: At that point, I'd use bzr pull.
[03:59] <Peng_> sohail: Err, push.
[03:59] <sohail> Peng_, how does it know where to push back?
[04:00] <sohail> oh I'd tell it
[04:00] <sohail> man this is confusing..
[04:00] <Peng_> sohail: ...Didn't think of that. Yeah, you'd have to set up locations.conf or pass the location to push.
[04:03] <sohail> I think my brain is not advanced enough for bzr
[04:24] <sohail> oh Peng_ one more thing, I recall I was told NEVER to do bzr push on the branches because bad things happen
[04:24] <sohail> so I guess I can't bzr push can I?
[07:29] <Peng_> sohail: What what? when does bzr push do Bad Things?
[08:24] <RenatoSilva> where can I find the source code for bzr start-xmlrpc?
[08:24] <RenatoSilva> and for rpc processings in general
[08:24] <RenatoSilva> one is returning <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 255
[09:11] <domas> hi! Is there a way to get $Id:$ kind of things inside bzr files, apart from using 'bzr version-info' ?
[09:12] <Peng_> domas: I'm not sure if it's fully supported yet, but that's one of the purposes of the content filtering stuff added starting in version 1.14.
[09:13]  * domas eyes http://bazaar-vcs.org/KeywordExpansion
[09:14] <domas> right
[09:23] <jml> wuuu hooo
[09:26] <Peng_> I don't think I can sprint all the way to Birmingham. Even if I was in good shape, there's the ocean...
[09:26] <Peng_> Sorry, bad joke.
[09:26] <Peng_> Carry on.
[09:27] <jml> :)
[09:39] <jml> gnublade, http://pqm.bazaar-vcs.org/
[10:15] <jml> 'mutter' is for general debug log, right?
[10:16] <ferrouswheel> Just recently upgraded to latest bzr - now my lp repository gives "bzr: ERROR: short readline in the readvfile hunk." if I try to create a local branch - people with 1.13 (in jaunty) don't seem to be having any issues.
[10:17] <ferrouswheel> Does anybody have any clue about what I should try next? Existing local repositories do the same thing, so I though a fresh branch might fix it, but doesn't seem to help :(
[10:21] <jml> ferrouswheel, I'm going to search launchpad for that error message
[10:22] <Peng_> I think that's been fixed now.
[10:22] <Peng_> It's definitely in progress, at the very least.
[10:22] <jml> https://bugs.edge.launchpad.net/bzr/+bug/360476
[10:23] <ferrouswheel> Yeah, unfortunately it's not on a smb mount... although I guess it could be a broader bug that's been named wrong.
[10:23] <ferrouswheel> (unless LP use it... which I guess would be highly doubtful!)
[10:31] <ferrouswheel> what's weird is that "bzr pull" works on the local repo, but "bzr update" gives the same error as branch.
[10:57] <ferrouswheel> FYI, the problem I was having was due to a corruption from a not cleanly unmounted drive. :(
[11:17] <Peng_> Eh. I guess I'm glad there wasn't a bug in bzr, but I hope ferrouswheel was able to recover his/her/its data.
[11:55] <LarstiQ> gnublade1: bug  249919
[11:58] <mgedmin> bzr-svn incompatible with google code?
[11:58] <mgedmin> bzr: ERROR: subvertpy.SubversionException: ("REPORT of '/svn/!svn/bc/272': 200 OK (http://jrfonseca.googlecode.com)", 175002)
[11:58] <LarstiQ> mgedmin: sometimes. google code is a funny svn server implementation
[11:59] <Peng_> That's a new one for me, though.
[12:01] <Peng_> 175002 is the ever helpful ERR_RA_DAV_REQUEST_FAILED.
[12:01] <Peng_> fwiw
[12:10] <gnublade1> LarstiQ: bug 213185
[12:14] <mgedmin> git-svn accepts that repository, but then kills me with merge conflicts when trying to rebase later
[12:24] <jelmer> mgedmin, Not sure about that one
[12:25] <jelmer> mgedmin, 157002 is a generic "Request failed" return code in Subversion
[12:25] <mgedmin> you can try yourself with bzr branch http://jrfonseca.googlecode.com/svn/trunk/xdot xdot-bzr
[12:25] <mgedmin> or I could go to launchpad and look for bug reports...
[12:27] <mgedmin> full traceback: https://bugs.launchpad.net/bzr-svn/+bug/395482
[12:28] <jelmer> mgedmin, this looks like a problem in the google svn server
[12:28] <jelmer> mgedmin, try running "svn log -r272:1 -v http://jrfonseca.googlecode.com/svn"
[12:29] <jelmer> you'll see the same error
[12:29] <mgedmin> fun
[12:29] <mgedmin> svn log -r2 -v http://jrfonseca.googlecode.com/svn fails
[12:29] <mgedmin> all other revs appear to be normal
[12:31] <jelmer> the web view gives a 404 for that revision: http://code.google.com/p/jrfonseca/source/detail?r=2
[12:32]  * mgedmin looks for a way to report bugs in googlecode.com, in vain
[12:38] <jelmer> mgedmin, Actually, it might be a bug in the way a particular reply is handled in libsvn
[12:38] <jelmer> mgedmin, so it might be worth reporting and attaching a packet trace
[12:55] <jelmer> moin
[13:04] <jml> jelmer, hello :)
[13:04] <jelmer> jml, Hey
[13:04] <jelmer> jml, How's the sprint going?
[13:04] <jml> jelmer, pretty good.
[13:05] <jml> jelmer, at least I'm getting stuff done that I've wanted to do for ages :)
[13:06] <jml> jelmer, wish you could have made it.
[13:06] <jelmer> jml: Cool, what are you working on?
[13:07] <jml> jelmer, using launchpadlib in the launchpad plugin
[13:07] <jelmer> jml: ah, neat
[13:07] <jml> jelmer, first command implement: bzr lp-mirror
[13:07] <jml> implemented, rather
[13:08] <jml> now I want to do interactive commit
[13:16] <jml> of course, I'm going to fix launchpad first :(
[13:27] <Peng_> jml: You know there's a bzr-interactive plugin?
[13:28] <jml> Peng_, yes.
[13:28] <Peng_> OK :)
[13:28] <LarstiQ> Peng_: it seems to consist of shelf1 files copied from bzrtools
[13:28] <LarstiQ> Peng_: with a couple of bugs filed against it that would be solved if it was shelve2 based
[13:29] <Peng_> I used to use hg's interactive commit plugin, as a substitute for shelves, but I've never actually done it in bzr. :D
[13:29] <Peng_> Well, maybe once, but not recently.
[13:43] <mgedmin> bzr push --remember refuses to change the push branch
[13:43] <mgedmin> it says Value "bzr+ssh://bazaar.launchpad.net/%7Emgedmin/gtkeggdeps/trunk/" is masked by "bzr+ssh://fridge/home/mg/www/gtkeggdeps/bzr/" from locations.conf
[13:43] <mgedmin> what on Earth does that mean?
[13:44] <mgedmin> hm, I have a ~/.bazaar/locations.conf with interesting contents
[13:44] <mgedmin> it says ##push_location:policy = norecurse
[13:44] <mgedmin> without the ##, I mean
[13:44] <jml> I haven't seen that one before
[13:46] <mgedmin> I assume I had an unfortunate interaction with bzr-svn (since the parent dir of my bzr branch is in svn), and probably applied some workaround to make it work a long time ago
[13:46] <mgedmin> and now the long-forgotten workaround is biting me
[14:00] <mgedmin> is there a way to ask bzr to try to opportunistically push my changes to the parent branch after every commit?
[14:00] <mgedmin> bzr bind kinda does that, but it insists too strongly
[14:00] <mgedmin> I don't want the commit to fail if I'm offline
[14:00] <mgedmin> and I'd like to be able to ^C if the push is too slow
[14:01] <mgedmin> but have the commit committed locally without any further interaction
[14:01] <LarstiQ> iirc amanica wrote something for that
[14:03] <LarstiQ> can't find it right now
[14:03] <jml> mgedmin, 'bzr ci && bzr push' would one way to do that.
[14:04] <jml> mgedmin, but I don't think bzr has something built in.
[14:05] <jelmer> jml: What does lp-mirror do?
[14:05] <jml> jelmer, requests that launchpad mirror the branch now
[14:05] <jelmer> ooh
[14:05] <jml> jelmer, Launchpad needs a new method on its API for it to be fully useful though
[14:06] <jml> jelmer, I'm writing that new method right now :) bug 395076
[14:17] <jml> kfogel, hello
[14:18] <kfogel> jml: hey!
[14:28] <Peng_> ...I totally didn't know there was a "bzr mkdir" command.
[14:30] <spiv> Peng_: me either!
[14:31] <mgedmin> ouch
[14:31] <mgedmin> why do you hate me so, bzr!
[14:31] <mgedmin> I do bzr push lp:myproject; I do bzr bind; I edit some files; I try to commit, it tells me of a divergence and tells me to bzr up; I run bzr up and I get a conflict of some kind
[14:31] <mgedmin> now I've no clue what's happening in my working dir or what to do
[14:43] <mgedmin> ah, what I did was bad: bzr push remote; bzr add newfile; bzr commit; bzr bind remote; edit file; bzr commit -> divergence detected!
[14:43] <mgedmin> shouldn't that bzr bind have pushed my local changes to remote?
[14:44] <mgedmin> if that's a bug, I've got a typescript file demoing my problem
[14:47] <LarstiQ> afaik, it shouldn't
[14:49] <mgedmin> jml: do you remember what my $PWD was when you walked over to me?
[14:49] <mgedmin> nm
[14:54] <mgedmin> https://bugs.launchpad.net/bzr/+bug/395514 has the exact sequence of commands
[14:58] <mgedmin> aaargh data loss
[14:58] <jml> :(
[14:59] <mgedmin> bzr revert --forget-merges or something else I did trying to untangle the mess resulted in that file disappearing
[14:59] <mgedmin> ah, bzr revert file3.txt
[14:59] <mgedmin> deleted it
[14:59] <mgedmin> wtf
[14:59] <mgedmin> revert means "give me what was there before"
[14:59] <mgedmin> it was there before
[14:59] <mgedmin> it was committed, ffs
[15:00] <LarstiQ> mgedmin: you're bound now, right?
[15:00] <LarstiQ> mgedmin: the revision is still in your repository
[15:00] <mgedmin> at least I have the full contents (both versions) in the terminal scrollback
[15:00] <mgedmin> I unbound as soon as it bit me
[15:00] <LarstiQ> mgedmin: try `bzr heads --dead-only`
[15:01]  * jml wonders why bzr hates mgedmin so much
[15:01] <LarstiQ> then you can pull -r revid:relevantrevid
[15:01] <mgedmin> because I'm impatient and don't read docs
[15:01] <mgedmin> it's supposed to be intuitive and easy to use and forgiving, right? right?
[15:01] <jml> mgedmin, it is.
[15:01] <jml> mgedmin, ... supposed to be.
[15:01] <mgedmin> and if I believed that, you'd sell me a bridge, right?
[15:02] <mgedmin> nah, bazaar is fine, it just needs a few more years to mature
[15:02] <mgedmin> to make a fool-proof system you need years of stress-testing by fools like yours truly
[15:03] <jml> mgedmin, I think that bound branches in particular need to have more love
[15:03]  * mzz is confused about what happened there
[15:04] <mgedmin> mzz:  https://bugs.launchpad.net/bzr/+bug/395514 has the exact sequence of commands
[15:04] <mzz> yeah, I was just reading that
[15:04] <mzz> I would've expected it to complain when you ran that bind
[15:05] <mgedmin> so would I
[15:05] <mgedmin> either push or tell me that the branches aren't identical
[15:05] <mgedmin> I expected it to push
[15:06] <jml> mgedmin, well, I can reproduce that error locally
[15:06] <mgedmin> there was https://bugs.launchpad.net/bzr/+bug/43744
[15:06] <mgedmin> which says that bzr bind no longer pushes, but it also talks about warning the user, which never happened
[15:08] <jml> so bind should warn
[15:08] <jml> and that conflict error should be a *lot* more helpful
[15:08] <jml> since following the instructions can lead to data loss.
[15:10] <mzz> so afaict its suggestion to run "update" is backwards
[15:10] <mgedmin> I should mention that
[15:10] <mzz> afaict running "bzr push ../bazaar-hates-me-again" after the "bind" makes it work
[15:11] <mzz> running "bzr up" at that point is confusing at best, and "bzr push" complains about no push location being set
[15:13] <mgedmin> bzr heads: unknown command "heads"
[15:13] <jml> mgedmin, you need bzrtools for that
[15:13] <mzz> in fact running "bzr push ../bazaar-hates-me-again" after "commit" fails (and tells you to run "update") works
[15:16] <mzz> I expected doing the (failing) commit with --local and then running "bzr up" to work too, but that also gives a weird conflict.
[15:37] <LarstiQ> gnublade1: https://lists.ubuntu.com/archives/bazaar/2009q3/060216.html
[16:09] <Glenjamin> hi guys, i'm trying to build the latest bzr on windows - it was working before but now i'm getting errors about missing zdll
[16:09] <Glenjamin> presumably there's some new dependancy i'm missing?
[16:11] <Glenjamin> oh wait, i can just use the binary dist can't I >.<
[16:12] <LarstiQ> Glenjamin: libz has recently become a dependancy. But yes, you can use the binary installer :)
[16:12] <woeye> real men build their own binary ;)
[16:12] <Glenjamin> heh, i tried!
[16:12] <woeye> :D
[16:13] <Glenjamin> also, what is the recommended method for installing on OS X?
[16:13] <woeye> i'd go with the binary
[16:13] <Glenjamin> i was hoping to play with bzr-svn and qbzr on my work computer
[16:14] <woeye> Szilveszter announced some minutes ago that he released a binary for leopard
[16:14] <woeye> https://launchpad.net/bzr/1.16/1.16.1
[16:14] <Glenjamin> excellent
[16:15] <Glenjamin> also, is there any way to get the windows installer to make a bzr.py file in the Scripts dir?
[16:15] <woeye> I am currently installing bzr by using MacPorts which his horribly outdated - so I had to patch the portfiles manually
[16:15] <Glenjamin> it only makes bzr and bzr.bat - but i have .py on my pathext
[16:15] <Glenjamin> i tried installing bzrtools using ports, it managed to install graphviz from source including all dependencies
[16:16] <woeye> yeah, but bzrtools ist out-of-date as well (1.13)
[16:16] <woeye> If only those MacPort maintainers would apply my patches o.O
[16:17] <Glenjamin> yeah, so after it downloaded compiled and staged about 15 dependencies, it didnt run >.<
[16:17] <Glenjamin> easy_install wasnt having any of it either
[16:17] <woeye> hehehe :)
[16:18] <Glenjamin> also on linux i've found easy_install installs bzr and bzrtools as separate eggs, so the plugin doesnt get placed inside bzr
[16:21] <LarstiQ> yes
[16:21]  * LarstiQ stabs easy_install in the face
[16:22] <Glenjamin> amusingly the windows install is the least painless
[16:22] <Glenjamin> except on ubuntu with root i suppose
[16:22] <mzz> hrm?
[16:23] <mzz> setup.py build_ext -fi doesn't suffice on linux?
[16:23] <Peng_> "make" is shorter. :D
[16:23] <mzz> oh, sure
[16:23] <Glenjamin> "setup.py install" is fine
[16:23] <Glenjamin> but you have to download and unpack
[16:23] <mzz> or that
[16:23] <Glenjamin> because easy_install fails
[16:23] <mzz> and on windows I have to download and click through the installer
[16:23] <mzz> I fail to see the problem
[16:24] <mzz> also, on linux you should have it packaged for $yourfavoritedistro
[16:24] <Glenjamin> assuming i have root, yeah
[16:24] <mzz> ah, there's that.
[16:25] <Glenjamin> it'd be much easier if you didnt keep updating so often :p
[16:25] <LarstiQ> Glenjamin: not that you need to install bzr to use it
[16:25] <Glenjamin> time to have another go on the mac
[16:25] <mzz> it runs quite acceptably as pure python straight from the tarball, just a bit slower with the extensions not built
[16:25] <Peng_> 2a repos will also use more disk space without the C extensions.
[16:26] <mzz> and it runs with no dependencies other than a recentish python if you don't need sftp
[16:26] <mzz> ah, I didn't know about that one
[16:26] <Peng_> Probably not much or anything, but some.
[16:26] <Peng_> The Python version of groupcompress is limited to line-based deltas, while the C version is not.
[16:27] <mzz> I hope the recent glitches with the release tarballs missing c files have been worked out then
[16:27] <Glenjamin> has much work been done with the smart server since 1.10?
[16:27] <Peng_> mzz: Heh.
[16:27] <Peng_> Glenjamin: ...Yes.
[16:27] <Peng_> Glenjamin: Define "much".
[16:27] <mzz> Glenjamin: skim the release notes
[16:27] <Glenjamin> will do
[16:28] <Peng_> Glenjamin: ISTM a lot of the hpss changes have to do with stacking and the 2a disk format. If you're not using those, the changes are less relevant.
[16:28] <Glenjamin> i had a bit of a go at getting a web interface + authentication + smart server going a while back
[16:28] <Glenjamin> didnt really get anywhere
[16:28]  * mzz is tempted to go with "meh, just use launchpad" for that one
[16:29]  * Peng_ is happy with Loggerhead + bzr+ssh + bzr+http.
[16:29] <LarstiQ> Peng_: streaming push though
[16:29] <mzz> I occasionally use bzr+ssh, haven't bothered with bzr+http
[16:29] <mzz> bzr+ssh is pretty neat in that it even works pretty well on windows using plink + pageant last time I tried
[16:30] <Peng_> LarstiQ: Ah, good point. There are some nice new features, huh? :)
[16:30] <Peng_> mzz: For a client, bzr+http needs nothing.
[16:30] <mzz> yep
[16:30] <Peng_> I run it on my server for fun. Mostly dogfooding, I guess.
[16:30] <mzz> Peng_: I'm usually not a client, and for small branches plain http suffices
[16:31] <Peng_> mzz: Especially since I use plain CGI, so the startup time diminishes the efficiency benefits.
[16:31] <Peng_> Someday somebody's going to do something weird and a bzr-smart process will take out my poor little VPS. :D
[16:33] <Glenjamin> gah
[16:34] <Glenjamin> the whitespace decoding bug in bzrtools still hasnt been fixed :(
[16:34] <Peng_> Whitespace decoding bug?
[16:35] <Glenjamin> on vista the tab completion throws a unicode decode exception because string.whitespace contains a non ascii character
[16:35] <Peng_> Ah, fun.
[16:36] <Glenjamin> i reported it months ago, its been repreoduced by multiple people, and has a fix
[16:40] <Glenjamin> oh wow, the mac installer worked perfectly
[16:55] <LoRe> why is bzr transfering so much data? i've just done a pull, 4 MB were transfered, but only 3 files were updated.
[16:56] <LarstiQ> LoRe: one answer could be (depending on the transport and the format), is that it needs to first read the indices to find out what to get
[16:59] <LoRe> LarstiQ: ic, thanks
[17:02] <LarstiQ> LoRe: you can try -Dtransport and -Dhpss for some more detail
[17:04] <Glenjamin> anyone know which version of the svn development libraries i need for subvertpy? (for bzr-svn)
[17:04] <jml> LarstiQ, https://bugs.edge.launchpad.net/bzr/+bug/238776
[17:04] <LarstiQ> Glenjamin: the ones matching your subversion library.
[17:04] <LarstiQ> Glenjamin: ideally 1.6, but 1.5 should work too
[17:05] <Glenjamin> ty
[17:14] <Peng_> Hell, 1.4 works...
[17:16] <LarstiQ> Peng_: it does, but it is rather suboptimal
[17:17] <Glenjamin> as i'm doing this
[17:17] <Glenjamin> i'm stuggling to remember why i didnt just use the windows installer for the whole lot
[17:18] <Peng_> LarstiQ: Well yeah.
[17:31] <Glenjamin> has anyone had problems opening a transport that uses http basic auth?
[17:32] <LarstiQ> Glenjamin: nafaik, can you be more specific?
[17:32] <Glenjamin> auth['user'] is None gives a key error on line 1921 in the http transport lib
[17:33] <Glenjamin> 1291 even
[17:34] <Glenjamin> i've only reproduced it with svn so far, on mac and windows
[17:34] <Glenjamin> i dont know of a bzr branch behind http auth
[17:36] <LarstiQ> Glenjamin: is that a svn url I can try against?
[17:36] <gnublade> jml: when you're done, got a change that could possibly benefit with a test, or should I just bang it into another email?
[17:36] <Glenjamin> this particular one is VPNed i'm afaid
[17:41] <jml> gnublade, another email, I think...
[19:30] <LarstiQ> hmmm
[19:36] <LarstiQ> sorry for (temporarily) removing subvertpy from the bzr ppa
[20:15] <james_w> anyone know what's going on in http://launchpadlibrarian.net/28691173/buildlog_ubuntu-karmic-i386.subvertpy_0.6.7-1~ppa1~karmic1_FAILEDTOBUILD.txt.gz ?
[23:27] <LarstiQ> james_w: looking at it now
[23:31] <LarstiQ> james_w: http://groups.google.com/group/nose-users/browse_thread/thread/ab603fb160cc2d9c seems relevant ("ython-nose is fully broken in ubuntu karmic alpha 2 and I'm not able
[23:31] <LarstiQ> to understand why. "
[23:33] <LarstiQ> james_w: or more specifically, https://bugs.edge.launchpad.net/ubuntu/+source/nose/+bug/389942
[23:34] <LarstiQ> sigh, reporting as I go
[23:35] <LarstiQ> james_w: upstream nose bug: http://code.google.com/p/python-nose/issues/detail?id=276
[23:36] <LarstiQ> james_w: I'm willing to live with subvertpy not working on karmic till someone fixes nose or python itself