[00:00] bob2: I actually does push the tags, though. [00:00] If I do a branch, they show up. [00:00] Pull doesn't pull them, it seems. [00:00] oh [00:01] Yes, it's odd. [00:01] * lifeless repeats it [00:01] you know what sucks [00:01] If I do a tag, and the push, I get the "No revisions to push." [00:01] I can't find a good clean reusable B/B+ index for python [00:01] But it still pushes the tags. [00:01] all the 'pure python' databases are either csv, the moral equivalent of csv, or dbm [00:01] NIH time [00:01] * beuno goes clean up the revision mess [00:02] tdb + ctypes! [00:03] beuno: tdb wants more file system semantics than we offer [00:03] s/beuno/bob2 [00:03] ah, remote, right [00:04] bob2: which is the problem with dbm too [00:04] what does one need to provide to have a fully functional TestCaseWithTransport subclass? [00:04] I went on a code search trying to find a python index module that was, well, modular. [00:04] no such freaking luck [00:04] jml: class foo(TestCaseWithTransport): def test_me(self): pass [00:05] mwhudson, do you have a copy of loggerhead before I pushed 173? I'm not sure how to get them back as left-hand history [00:05] lifeless: in particular, I would like to be able to use make_branch. [00:05] anybody know the size of the mysql repository? [00:05] re [00:05] When I do, I am told: AttributeError: 'TestFoo' object has no attribute '_TestCaseWithMemoryTransport__server' [00:06] beuno: bzr pull -r some.dotted.revno . --overwrite probably? [00:06] jml: you have replaced setUp() and not called it [00:06] well spotted. [00:07] tethridge: 300MB I think. or maybe its 500MB. [00:07] jam: ^ [00:07] awilkins, still there? [00:07] jelmer: Yes [00:07] back in 45 or so. [00:07] awilkins, any luck? [00:07] jelmer: I've reduced the size of that error log a lot, but still plenty of problems [00:07] Jc2k: did you file bugs? please say yes :P - and feel free to subscribe me to them [00:08] lifeless, nice [00:08] jelmer: Library discovery is really crippled on this build platform [00:08] http://pastebin.ca/1054527 [00:08] lifeless: I'm not quite sure what you are pointing me to [00:08] jam: 'how big is a mysql branch' [00:09] 500+ MB for 6.0, 300 ish for 5.0 [00:09] ok, time to put this pc in for repair. [00:10] tethridge: my copy is 591MB, with most of their branches [00:10] Is there a discussion of permissions anywhere? Like when different processes and/or users are pushing to a central locations? Oy. I'm not sure wide open umasks are the solution. [00:10] awilkins: ouch [00:10] bug #240262 [00:10] Launchpad bug 240262 in bzr "No repository present error when using bzr+http protocol talking from bzr 1.5 client to a 1.3.1 repository" [High,Confirmed] https://launchpad.net/bugs/240262 [00:14] jelmer: I remember having more success with those Pyrex bindings using MSVC ; how hard is it to ditch the dots? [00:14] jelmer: Previously managed to get as far as having built .pyd files (even if they didn't actually work) [00:15] awilkins: basically, it's changing all structs that use the dotted notation to explicitly set all member variables, and in the right order [00:16] I'd guess that's quite a few [00:17] yeah, indeed [00:17] tolstoy: you may want to look at contrib/bzr_access, which would be a good place to work out multiple user keys for a shared repo, and proper umask, etc. [00:18] jam: Okay, thanks. [00:21] hrm, LP hates me today: [00:21] beuno@beuno-laptop:~/bzr_devel/loggerhead.fix_dirs$ bzr pull lp:~beuno/loggerhead/bug-240512 [00:21] Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) [00:21] bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 502 Bad Gateway [00:22] :( [00:22] try again again [00:22] i think [00:22] yeah, already did, but it's *extremely* slow [00:23] it's stuck at: 0.198 opening working tree '/home/beuno/bzr_devel/loggerhead.fix_dirs' [00:23] * beuno tries again with Dhpss [00:26] jelmer: Those traces are full of MSVC symbols..... [00:26] Or rather, the lack of them [00:27] awilkins: probably a different ABI or something [00:28] some sort of compiler mismatch at least [00:28] PLus things like _chkstk which is apparently shoved in when big stack frames are in there etc. [00:28] Darn [00:29] ok, so fixing the dotted structure notation is the only solution? [00:29] I hate to say it, but probably [00:30] THe other solution would be building Neon, SVN and all the other stuff on MinGW and I can't find much help for that [00:30] There's a reason I'm using the pre-archive developers pack of SVN libraries and headers [00:30] LP is autopacking LH again [00:30] * beuno crosses his fingers === mario_ is now known as pygi [00:34] jelmer: Right, it's 0033 here, I'm going to bed.... if there is any simple drudge work I can do to help, let me know. [00:34] awilkins, will do [00:34] jelmer: But bear in mind my C is rather rusty. [00:34] awilkins, g'night [00:34] Goodnight [00:40] Is this error serious? or can i ignore it? This transport does not update the working tree of: sftp://...../trunk/. See 'bzr help working-trees' for more information. [00:42] RichW, that means the the actual files aren't been updated, so it depends on what you're using it for [00:43] is that in launchpad? [00:48] beuno: so loggerhead/trunk looks better again thanks [00:49] mwhudson, yeah, sorry about that. I was used to the bzr workflow, where PQM is always left-hand. I'll be more careful from now on [00:49] no worries [00:50] autopack worked fine now (took almost 20 minutes though( [00:50] autopack still mostly happens client side i think [00:51] there's a patch floating around to fix that [00:51] yeah, but it doesn't take 20 minutes to push the full branch, so I suppose it should take at most that long, right? [00:51] anyway, it's done now, so no use in complaining :) [00:51] i can imagine there being a silly amount of roundtrips [00:52] beuno: for bug 242466, how does this look? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png [00:53] Launchpad bug 242466 in loggerhead "Log view should show sub-revisions" [Medium,Confirmed] https://launchpad.net/bugs/242466 [00:53] (this is something i did ages ago in a branch which has gone to the big hard disk crash in the sky, but i think i know how to do it again) [00:55] mwhudson, that looks pretty good. I remember now you emailed that a while back to the list. I had in mind maybe trying to show them like collapsed revisions, and being able to expand them too [01:04] ok, trunk should be back to before the left-hand-side-plus-collapsing-packs mess [01:04] beuno: you mean, making less distinction between the mainline and off-mainline revisions? [01:05] that probably makes sense [01:06] mwhudson, yes. I feel it makes merged revisions seem like something different, when they're not. Users already get confused with DVCS in that sense, and that may not help [01:06] I'll try to get a mockup for that once we're through with the new theme, if you'd like [01:06] beuno: swings and roundabouts, i think having _some_ emphasis on the mainline revs is ok [01:07] (this is one of the things i find incomprehensible about bzr-webserve) [01:07] mwhudson, alright, two mockups :p [01:07] beuno: heh [01:08] let's get the new theme done [01:08] first [01:09] mwhudson, I had something in mind similar to "This revision is composed of N revisions. Show revisions" [01:09] and expand on-screen [01:10] if that's possible without making the UI a mess [01:10] Well, the big problem is that having high emphasis on the mainline revs is perfect in some workflows, but with others having ANY emphasis is bunk. [01:11] lifeless, FWIW, second time Loggerhead auto-packed, after going back a few revisions, it worked out fine [01:12] Peng: true (re server generated index html). I hadn't even tried it. (smacks forehead) [01:12] fullermd: but it makes sense in a workflow that involves pqm, which is the right workflow, so qed [01:13] * mwhudson runs away and has lunch [01:13] pqwhat? :p [01:13] and ... IT WORKS!@ [01:14] now to get around the ~ since my work blocks access to 'personal pages' ie those with a tilde :-( [01:14] beuno: btw, are you running the tests before committing to trunk? [01:14] beuno: the tests suck, but they do occasionally catch problems [01:14] don't s'pose bzr does ntlm proxy auth? :-) [01:15] mwhudson, uhm, 50% of the time, tbh. I'll bump that up to always :) [01:15] Well, if the tests cover 50% of the code, and you run them 50% of the time, the two add up to 100% coverage! [01:15] if it used curl, it could [01:15] I do go through all pages in UI, before pushing, which may catch more than tests. But I will do both until we have better tests [01:16] mwhudson, just checked though, haven't broken any tests (which just goes to show how little we're testing :P) [01:18] * beuno goes back to gnome-theming while mwhudson eats his well-deserved lunch [01:19] Hm. On solaris, the xmloutput plugin says that encoding is "646". I've never heard of 646 as an encoding. [01:20] Unicode is ISO-10646 [01:21] Well, UCS technically. But who can keep track of all the acronyms and subacronem? [01:21] It's odd. I'm trying to integrate this with bamboo (oy) and its jdom parser rejects the xml output because encoding="646". [01:24] Interesting. On this version of python (that I compiled myself), on Solaris (hail mary), sys.getfilesystemencoding() returns '646'. [01:24] weird === mw is now known as mw|out [01:25] Just as a user, rather than an ops staff, or whatever, Solaris leavs much to be desired. [01:26] yep, checked [01:26] I've got two pythons installed on solaris, site compiled, and one installed from blastwave [01:26] both have '646' [01:26] It's good to know I didn't mess up the compile. [01:27] I would guess that means UTF-8. But it could be UCS-2 or some such insanity. [01:27] solaris has got a lot to be desired frmo an ops view too [01:27] first thing I do is install a swag of freeware [01:28] I guess I'll have to "fix" the xmloutput plugin. [01:28] s/ frmo.*// [01:28] well, 2nd thing, after jass. (here's ends the OT) [01:28] mlh: I'd just erase the whole OS and install something else, but then I don't have root, and people get tired of such suggestions. ;) [01:28] :-) [01:28] Luckily, these days, there's vmware and such ;> [01:29] We compile java apps, and people are afraid that if we compile on linux and deploy on solaris, Bad Things Will Happen. [01:30] we have smiilar superstitions here [01:31] even though, people have compiled on windows and deployed on solaris and it's just worked dandily [01:34] Jc2k, ping [01:36] Jc2k, lifeless, I've got some integration for the gnome theme: http://intranet.pentacorp.net:8080/changes [01:37] it could probably be nicer for the LH menu navigation/search bar, but not sure how to cram everything together [01:37] is there a proggy to generate index.html that DOES include .bzr? [01:38] it'd be pretty simple to make one I guess; just checking if there's an option or plugin [01:39] bzr ls --html mebbe [01:44] tiny bug in bzr help status: [01:44] s/bzr -SV/bze status -SV/ [01:45] mlh, I see: [01:45] to Subversion's status command. To get output similar to svn -q, [01:45] use bzr -SV. [01:46] yeah [01:46] which seems correct. What version of bzr are you using? [01:46] beuno: right, there's a command name missing [01:46] 1.5 on fedora9 [01:46] aah :) [01:46] mlh, you can either file a bug and/or send a patch [01:46] thanks spiv [01:46] er too small for a bug [01:47] one of you can just sneak it in with other fixes :-) [01:49] Jc2k, lifeless, I'm off in a few minutes to have dinner, but, screenshot up in: http://beuno.com.ar/random/gnome_themed.png and pushed it to: lp:~beuno/loggerhead/gnome_theme [02:17] beuno: cool [02:18] beuno: does it have bzr-search ? :P [02:31] hello beuno etc === poolie_ is now known as poolie === kiko is now known as kiko-zzz [02:39] are there any java or csharp lang bindings to bzr? [02:44] gambler: look at the bzr-eclipse plugin; the work done there is relevant. [02:45] AfC, is it stable? [02:48] * igc lunch [03:05] gambler: do you mean 'is it done' or 'does it work well' [03:07] does it work well [03:07] gambler: I don't use eclipse; but various folk that do tell me it works nicely [03:11] not completely tangentally, jython 2.5 alpha is out [03:12] meh another time sink. ill investigate it then [03:14] gambler: 'Verterok' who hangs out here is one of the primary developers [03:14] he's in argentina though, his nighttime now [03:14] i installed eclipse yesterday! [03:14] then it confused me [03:14] gambler: also, SoC last yerar, someone wrote some c# bindings [03:14] dunno how good they are [03:15] linky? [04:03] Jc2k: ironic that you are having to hack on git :) [04:08] poolie: At some point this week, I'd like to talk about the PQM work I'm going to be doing this summer, so I can start next Monday with clear targets and rewards. === Odd_Blok1 is now known as Odd_Bloke [04:10] Odd_Bloke: that'd be good, could you start by putting down your thoughts on the list about what to do, so others can get involved [04:10] also the dates you'll be working on it [04:17] poolie: I'll do that tomorrow. [04:44] would someone like to help me figure out how to organize a project? I'm having trouble with the bazaar concepts [04:51] xz, sure [04:51] gambler: sorry, was away from keyboard [04:51] Verterok: btw - gambler is asking about accessing bzr from java [04:51] lifeless: thanks for pointing it :) [04:52] gambler: I'm not sure about where the c-sharp bindings are [04:52] * Verterok looking the backlog [04:52] I don't even remember the students name sorry :( [04:52] poolie: my project is a single directory with a number of subdirectories. I want people to be able to work on the subdirectories independently, and then the parent can use various versions of them [04:53] gambler: to access bazaar from java, there is a library I'm working on (and using it bzr-eclipse), https://launchpad.net/bzr-java-lib [04:53] poolie but it should also be possible to move a file from one subdirectory to another, and that is a change to the parent [04:54] s/it/in/ [04:54] xz, this is the subtrees feature [04:55] well, hm [04:55] there is a feature called subtrees which lets you commit independently in all the subdirectories and link them into the parent [04:55] gambler: the current trunk of bzr-java-lib, is based on a CLI wrapper, so it's performance isn't quite good [04:55] it is a bit rough atm [04:56] poolie I guess a single versioned branch (the parent) is a possibility, and to work on a subdirectory, you branch the whole thing, work on the inside, then merge back - is that the way to do it? [04:57] gambler: I'm working in a branch that uses a xmlrpc backend, provides far better perfomance and mantain API compatibility with the CLI based one. [05:04] xz, yes, and that's probably simpler for many uses [05:11] igc, still around? [05:12] poolie: yep [05:13] igc, i guess we should just consider it settled that there will be a file in the tree for preferences [05:14] i still think that's the best option but your quoted message from john makes me want to get more certainty that it is so [05:14] poolie: I did :-) [05:15] did consider it settled? [05:15] the issue now IMO is format marker syntax and optional vs required [05:15] right [05:15] i'm replying on that [05:15] thanks [05:23] I should reply still :( but don't block on me [05:30] hey poolie [05:31] lifeless, search isn't my choice, but if Jc2k wants it, I'd b happy to help him out with that too [05:32] beuno: I believe he is running search already :P [05:32] beuno: also, what time is it for you ?! [05:33] lifeless, ~1:30amish [05:33] early :p [05:33] I've been going to when mwhudson_ stops working, which is usually ~3am here [05:34] so, if he's running search I should probably make it auto-index... :/ [05:35] beuno: maniac [05:36] mwhudson_, hehehe, well, it's the only way to do *both* things (my current work and bzr/LH) [05:36] beuno: but it already auto indexes [05:36] beuno: so I really don't understand why you want to do that at all :P [05:36] lifeless, well, it autoindexes once it has indexed :) [05:37] beuno: right [05:37] so, I'd like to provide an egg for the chicken [05:37] shouldn't be too hard [05:37] just juggling quite a few things at a time [05:37] beuno: which means lh doesn't need a config item saying to index or not - it can just detect if there is an index, and only show Search when there is [05:37] beuno: I'm not sure I agree, because it will add the need for a knob for people that don't want a search index [05:38] lifeless, right, I suppose that can be the default behaviour (which is what it currently does), but it would be nice to be able to tell it to index everything [05:38] it'll probably be 50/50 of people wanting and not wanting [05:38] it's a very cool feature :) [05:39] beuno: wouldn't it be better to have bzr-search have an option which when set causes 'bzr branch' to create an index too ? [05:39] (and init etc) [05:39] lifeless, that would be nice, yes. And it has the bonus that it falls on your court, and not mine! [05:40] beuno: you've got patches in bzr-search too :P [05:41] heh, true. [05:47] bug filed [05:52] igc, ok, reply sent [05:52] that increased my conviction that adding one will not really help anything [05:53] to me it seems like an overgeneralization from what we had before [05:53] s/what we had before/from bzrignore and internal database versioning [06:05] thanks for the detailed reply poolie. I hadn't considered the idea of introducing a new file as the way to bump the format. Interesting. [06:19] loom question. [06:20] two commits went to the wrong thread. between now and then I've made 5 other commits. [06:20] what can I do about this? [06:21] cherrypick out those two wrong commits? [06:25] jml: so thread A should have got commits 1 and 2 [06:25] and thread B got them instead [06:25] jml: where did commits 34567 go ? [06:26] thread A [06:26] whats thread B's position relative to thread A? [06:26] immediately above. [06:26] ok [06:27] because B has content A doesn't, you can't just merge them in, you'd get B as well [06:27] so yes - cherry pick merge them down to A [06:27] sorry. I misread something you said. [06:27] let me answer your questions again. [06:28] jml: where did commits 34567 go ? [06:28] thread B [06:28] whats thread B's position relative to thread A? [06:28] thread A [06:28] err, thread B is immediately below thread A [06:28] so [06:28] switch to B [06:28] bzr up-thread [06:29] that will merge them to A, commit. [06:29] then, switch to B [06:29] and bzr cherrypick 1 and 2 out of B [06:29] (e.g. by bzr merge -r -5..-7 .) [06:29] commit [06:29] bzr up-thread [06:29] (which will back the commits out) [06:29] and bzr revert . [06:29] which will put them back and keep the merge record [06:30] then bzr st (should show a pending merge) [06:30] bzr commit [06:34] thanks [07:16] hellow all [07:23] mornin' Jc2k [07:25] Jc2k, http://200.127.6.219:8080/changes [07:26] now that is quite pretty :D [07:27] beuno: can you make the plain pages that serve-branches serves equally shiny? [07:27] Jc2k, ah, yes. That would involve templating those bits, which will close a bug. I'll bump that up on my priorities [07:28] Jc2k, you can get the branch from: lp:~beuno/loggerhead/gnome_theme [07:29] we can play around with the tabs to make LH's navigation seem more integrated, but I didn't want to change anything substantial [07:32] have you read http://adam.gomaa.us/blog/thoughts-on-dvcss/ (reddit) ? [07:45] good afternoon [07:47] is there a nice tool to display branches as a graph? [07:47] eMBee: bzr vis [07:47] gour, it's an interesting read, although he seems to know nothing about bzr, and a lot about git/hg [07:48] eMBee, that would be part of bzr-gtk plugin [07:48] beuno: heh, i really like such kind of posts :-/ [07:48] ah, thanks [07:48] alright, that's it for me today [07:49] g'night everyone [07:50] Jc2k, I've got theming the remaining bits of LH on my list, make sure to poke me if you need something else :) [07:50] bzr vis does not seem to exist, and bzr-gis only in lenny, not in etch or backports :-( [07:51] eMBee, bzr-gtk is the package, not sure if it's in etch ot backports, but you can install it with: bzr co lp:bzr-gtk ~/.bazaar/plugins/gtk [07:51] of course, you have to have gtk installed :) [07:52] so it just uses pygtk or something? [07:52] yes [07:53] ok, then that's good enough for testing [07:53] normally i prefer to have the packages installed [07:53] eeeks, need a launchpad login for that [07:54] eMBee, actually, check out the manual installation: http://bazaar-vcs.org/bzr-gtk [07:54] eMBee, you shouldn't need a LP login, no [07:55] anyway, I'm really off to be now :) [07:55] jelmer: there will be new bzr-svn release soon? [08:00] bzr branch http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk ~/.bazaar/plugins/gtk; seems to work [08:00] good [08:01] i guess lp references my local setup and assumes launchpad access [08:02] where does bzr vis come from? is that part of the gtk plugin? [08:03] eMBee: part of gtk plugin, it's alias for visualize [08:03] thanks [08:04] does it work? [08:05] * gour likes bzr vis although comfortable with cli [08:06] * ToyKeeper ponders working on some vis improvements [08:07] * eMBee is still loading the source [08:07] i like the cli. but i do like to visualize the branch graph [08:08] it really helps me to see where i am and if the operation i do has the desired outcome [08:08] I like browsing changes and diffs in the GUI, and sometimes committing changes in the GUI, but everything else seems easier on the command line. [08:08] right. it's very helpful [08:08] (sometimes) [08:09] * gour comes from non-gui world of darcs [08:09] heh, with darcs i was always confused about the state of my branch [08:10] I liked the patch-based concept of darcs, but never really did much with it. [08:10] Jc2k: are you running bzr-search version of loggerhead? [08:10] Jc2k: beuno needs to know, to know to memrge it in or not :) [08:11] i used it almost exclusively for several years, but had issues with it as well [08:11] hmm: bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack [08:11] eMBee: from bzr viz? [08:12] eMBee: I blieve that was a specific version issue [08:12] yes [08:12] eMBee: it must be something wrong with your repo :-) [08:12] i just checked out trunk [08:13] eMBee: and what bzr are you runnin? [08:13] i mean, the repo you want to 'vis' [08:13] bzr is 1.5 from debian etch backports [08:14] I suspect trunk of bzr-gtk needs trunk of bzr [08:17] hmm, can i check out a version of gtk that works with the released 1.5? [08:17] eMBee: you mean the bzr-gtk plugin? [08:17] yes [08:17] eMBee: you could try -rtag:bzr-gtk-0.94.0, it might work with 1.5 [08:17] eMBee: or the GTK+ library? [08:17] eMBee: You could just update your branch to a released revision. [08:17] eMBee: you need trunk of bzr, if i understand [08:18] (that's just a guess though, I'm not sure if that release works with 1.5) [08:18] but i don't want to get the trunk of bzr, i prefer to stick to the debian package [08:19] Huh. I have bzr-gtk 0.93.0 here plugged into my bzr 1.5; I guess it's time for me to poke at that. [08:19] eMBee: why would you want to do that? [08:19] why would i want what? [08:19] stick with out of date Debian packages of a project which is iterating quickly? [08:20] eMBee: if you are using the debian packaged bzr, you should also use the debian packaged bzr-gtk :) [08:20] because i can not recommend others to use bzr if they are expected to get the latest revision. it just means that bzr is not yet stable for use [08:21] lifeless: that is true, unfortunately, there is no bzr-gtk backport for etch available yet [08:21] eMBee: have you requested one? [08:21] only lenny, which is equally not something i can recommend [08:24] bzr pull -rtag:bzr-gtk-0.94.0 lp:bzr-gtk ~/.bazaar/plugins/gtk ? [08:25] You do have python-gtk2 installed, yes? [08:25] bzr-gtk requires python-central, python-glade2, python-gtk2 [08:30] eMBee: have you requested a backport? [08:31] i run bzr-gtk-0.94 with bzr-1.6b3 - no problems [08:32] lifeless: i just discovered that it wasn't backported, and i am not aware of any place where i could request a backport [08:32] but used it with pre1.5 as well [08:32] eMBee: do you have seahorse installed? [08:33] what's seahorse? (i guess no) [08:33] there was (is) issue that bzr-gtk requires it [08:33] try to install it [08:34] for managing gpg keys [08:36] installing seahorse does not make the error go away [08:36] eMBee: I believe you file a bug on debian.org to ask for a backport [08:37] lifeless: i'll look into that, thanks [08:38] eMBee: http://lists.backports.org/lurker-bpo/list/backports-users.html is the users list [08:38] eMBee: I would start there [08:38] heh, thanks [08:38] the backport is not a priority, since i need to get this working now. in the worst case i can make my own backport later, but that's to much effort now [08:39] eMBee: can you paste error? [08:40] Is it expected that bzr trunk branching from LP complains about the server not supporting network protocol 3? [08:41] ToyKeeper: yes; protocol 3 is new and lp hasn't been upgraded to support it yet [08:41] yes, hold on [08:42] lifeless: Okay, that's what I figured. Just wanted to check. [08:43] bbiab [08:44] poolie: ok, you've convinced me I think. I've replied with another idea for your consideration [08:45] http://pastebin.ca/1054962 [08:48] eMBee: have you seen https://bugs.launchpad.net/bzr-gtk/+bug/237205 [08:48] Launchpad bug 237205 in bzr-gtk "error starting webbrowser.GenericBrowser in python2.4" [Medium,In progress] [08:48] not yet, looking now [08:49] so i run into this problem because of python 2.4 in etch, ok [08:50] right, python-2.5.2 here [08:50] bzr vis uses a webbrowser? [08:51] Ah, I had that exact problem on edgy. [08:52]