[00:04] ChristopheT, You need to run ./setup.py build_ext --inplace [00:04] (Which is exactly what make runs.) [00:04] jelmer: Why doesn't setup.py do it automatically? [00:04] peng: it does [00:04] peng: Well, if you have some way to make that the default [00:05] that's deep inside distutils though [00:05] Ah. [00:05] patches are welcome :-) [00:05] you can replace the default build command object with one that does that? [00:05] I've heard rumours about distutils. I'm afraid to go anywhere near it. :) [00:06] LarstiQ: It's the build_ext command unfortunately [00:07] jelmer: yes, but I mean making './setup.py build' do an inplace extension build (too) [00:53] wait a moment, imagine you restrict the log in via ssh or http, whichever you want, to a server, both are the same fake for the repo, right, your server is secure, but as bzr not having an auth method, anybody can personify another developer just setting his email variable in his bazaar.conf, and commit mistakes to blame someone else, that's a security error [00:53] That is true. [00:53] You could have developers always PGP-sign their commits. [00:54] LarstiQ: Rather just recommend everybody to use make :-) [00:55] jelmer: what a copout! ;) [00:55] baco: supposedly you merge from people you trust, not random strangers [00:57] Peng: I think I misted that doc, but wouldn't be easier to have an auth method in the server? that would require to run a server each time, the smart-server for example, mmm... nasty [00:58] LarstiQ: then I wouldn't merge anybody, neither myself [00:59] baco: I'm not sure what you mean with it being easier to have an auth method in the server. [01:00] LarstiQ: I was imaging the svn model, which forces you to give a correct user and password [01:00] but this requieres to have a server running somewhere [01:01] bac: The thing is, with a DVCS, people will often be pushing each others' commits around. [01:04] Peng: they do need at least an ssh server running, there is no difference in having another server that forces them to auth correctly, using that for setting the commit-er field [01:07] bac: Say you're working on a feature in a branch, committing frequently. I notice a bug and fix it. You merge my fix. Now when you finally merge your feature branch into the trunk and push it, you'll be pushing both your revisions and one from me. [01:10] baco: not really, there are many ways you can exchange revisions [01:10] the signing of the revisions could be an useful feature [01:11] Peng: I don't get your point [01:12] baco: your method works in a centralized setup, not in a decentralized one. [01:12] Augh, dammit. I'm sorry again, bac. [01:12] Dammit. I keep doing that. [01:13] * LarstiQ hands Peng the second part of cola [01:13] LarstiQo: :) [01:14] haha :) [01:15] baco: perhaps it helps to get clear what exactly it is you are after. As santagada said, bzr supports signing commits with gpg, that (and verifying them) can take care of trusting who authored a commit. [01:16] LarstiQ: I understand, that could be also done by faking persons in local commits an then merging you lose the control, but again, you fix at least the centralized model [01:17] pardon me? [01:17] baco: it is already fixed with signing [01:17] baco: I didn't follow you [01:18] LarstiQ: I was referring to (21:12:51) LarstiQ: baco: your method works in a centralized setup, not in a decentralized one. [01:18] baco: read about signing, then tell us why this doesn't fix your problem [01:19] baco: mja, I don't see a lot of merit in doing it for a centralized workflow when the tool supports decentralization. [01:20] baco: and in my experience, it's a non-issue. [01:20] santagada: no anybody I work with knows about the private-public key scheme, but they know that when they see 'Password:' they have to enter one [01:20] *not anybody... [01:21] baco: this is mostly a tool issue... it has to be fixed, but it is not a problem with bzr [01:21] baco: why not use svn then? [01:22] baco: I worked with a team of people that couldn't understand keys or distributed scm at all... the easiest thing was just using subversion then. [01:23] baco: aha, I think I understand your situation now. [01:23] santagada: I like the best of both worlds, decentralization, works for me working at home [01:23] baco: do you think things will go wrong if you just trust your peers to set their committer id correctly? [01:24] baco: bzr-svn [01:24] should solve your problem of working at home [01:26] LarstiQ: I am really paranoid, I don't allow any ssh connection to my station, I just don't trust [01:29] santagada: yeah, that's a solution, I just wanted to promote bazaar because I like it, but I can not without solving those problems. I think is a good solution for working in many situations, but is strongly based on trust, or experienced users (like the ones who know about public-private keys) :-( [01:31] baco: to me shell access to your machine is a bit different than trusting people's claim that it's their work [01:31] baco: I'm not from the bazaar project so I can't express what they want, but maybe they can be everything to everyone. fixing your problem is just going to bring one completely unuseful and dangerous feature to the project [01:32] s/can/can't [01:32] santagada: we do try to be :) [01:32] well, to some extent [01:32] LarstiQ: I can't access bzr with my svn client... try to fix this :D [01:32] in the context of a versioning control system mainly for source code, the idea is to support different workflow styles [01:33] santagada: there is a project for that, though I think long dormant [01:33] baco: so, if someone would mail you a bundle, would you be willing to merge that? [01:35] LarstiQ: did you see the linuxhater blog post about bzr? [01:35] http://linuxhaters.blogspot.com/2008/06/do-you-guys-remember-that-whole-betamax.html [01:35] baco: or, if each coworker pushes their work to their own home directory on a central server where only they have access, would you be willing to merge from one of those? [01:36] santagada: looking at it now [01:37] LarstiQ: is almost the same situation, but in a workgroup in which someone wants to harm a coworker an scheme like svn solves my problem [01:37] santagada: that seems to be a general lament about the amount of different dvcsen, that's an old concern [01:38] LarstiQ: I know it's a really wried situation, but could happen [01:38] baco: if they really want to hurt you they'll crack the password, or worse, break your fingers. [01:39] baco: you can use bzr just like svn in this regard if you so desire: [01:39] LarstiQ: I still wish that mercurial and bzr would just merge... both projects that have almost the same goals using almost the same tools [01:39] baco: setup a server, have everyone push and pull against a central branch there [01:39] baco: via webdav, or bzr+http, or bzr+ssh [01:40] baco: trust will have to enter the picture somehow [01:40] baco: why not have each user have its own accound on the main server [01:40] if someone tamper with commits you can discover who did it [01:41] LarstiQ: I preferred the conspiring plot instead of physical aggression :-P [01:41] well, they can't tamper with history without bzr alerting everyone else anyway [01:41] back later folk [01:43] lifeless: with bzr+http or bzr+ssh they auth against the server, but the commit in the repo could be made by sancho or don for the same log in account at separate times [01:44] baco: but you can track wich user did what [01:44] santagada: no if you branch the trunk to another server losing the log-ins history [01:44] ? [01:45] baco: you could conceivably set the committer id server side [01:45] baco: but if you want to go to all these lengths, I'd really try to invest my effort in educating my coworkers about signing and verifying commits. [01:46] baco: but frankly, I trust my coworkers. [01:46] LarstiQ: I do insist when I say I am a paranoid bastard [01:48] LarstiQ: how could you set the id server side? not only with bzr, I guess [01:49] baco: I've not verified this all works, but something along the lines of using the smartserver and generating new revisions to actually commit with the commiter id changed to server side approved ids. [01:50] baco: note that that is very nasty to do, because then you will have to throw away your local revisions and pull from central again. [01:50] baco: and I don't think it actually buys you anything [01:50] baco: as soon as you outside that central server, people have control over their committer id again. [01:51] baco: really, the committer id is not meant to give a secure way of identifying who is responsible for said commit. [01:52] then blame is not a secure command to say who introduced a bug [01:52] baco: before going back to my girlfriend I'll suggeset two avenues of attack for you: 1) educate on gpg signing (bzr supports this in the tool) 2) trust people [01:53] baco: no, 'secure' doesn't enter the equation [01:53] neither is svn blame [01:54] imagine you dismiss the wrong person for that [01:54] baco: if your assumption is that people are out to harm you and hide their tracks, I wouldn't stop at assuming they can't do with the server whatever they want. Including doing and svn dump and restore. [01:54] baco: using the wrong tool for the job. [01:55] baco: the only thing that can ever work is signed statements. Digitally, that would mean gpg. [01:55] (for that sceneario) === rockstar` is now known as rockstar [03:51] is there a Bazaar equivalent to svn:keywords? [03:52] ie can I replace a keyword with the current revision? [03:55] no, I think people generally use "bzr version-info" in a build script [05:39] LarstiQ: I would have suggested 'peer review' actually. [05:40] LarstiQ: as in - noone commits to trunk unless there is someone else with them, etc. [05:40] LarstiQ: because of his concept of firing people that introduce bugs :) [06:25] is there a way to link files from other branches / repositories when pushing to another branch? [06:26] or even directories? [06:43] ala svn-externals? [07:38] yes! [07:38] been so long since svn that i'd forgotten the name [07:39] (bob2) [11:07] D'oh. bzr.dev and bzr-svn trunk started out better, but its memory use exploded after it finished grabbing revisions. [11:09] i hear the worst leak is in sqlite now :) [11:11] * ToyKeeper wonders how to get swap usage data per process [11:13] The versions in hardy used about 600MiB RAM to branch this repo, but the dev versions are up to about 2 GiB if I count swap. [12:10] anyhoo, the current head revisions are both better and worse. :) http://launchpadlibrarian.net/15674458/bzr-svn-memuse.png [12:13] does someone have an idea on: https://bugs.launchpad.net/svn2bzr/+bug/230341 ? [12:13] Launchpad bug 230341 in svn2bzr "ValueError: need more than 1 value to unpack" [Undecided,New] [12:13] I run into the same problem [12:36] ToyKeeper, Wow, I wonder what that sudden memory increase comes from [12:37] at least part of the memory usage is caused by memory leaks in the python sqlite3 bindings [12:38] jelmer: Yeah, I was pretty surprised. === Kamping_Kaiser is now known as Birthday_Kaiser [13:30] jelmer: could be versionedfiles copying [13:30] jelmer: did you implement streams memory-efficiently ? [13:32] is gustavo niemeyer here from time to time ? [13:32] yes [13:33] what's his nick ? [13:33] niemeyer [13:34] lifeless: he's not using stacked stuff at all [13:34] jelmer: oh [13:34] lifeless, there's no versionedfiles involved in that case [13:34] ToyKeeper: was it building a tree ? or just a branch fetch ? [13:35] lifeless: https://bugs.launchpad.net/bzr-svn/+bug/243939 [13:35] Launchpad bug 243939 in bzr-svn "'bzr branch' over svn uses a lot of RAM" [Undecided,New] [13:35] lifeless, it's memory leaks in the python bindings and sqlite3 bindings [13:35] lifeless: I can reproduce them here, but debugging them is pretty hard [13:36] jelmer: after its grabbed the revisions though, it builds a tree; that could be local KnitVFs issue [13:54] lifeless: hmm, that would be convenient :-P [13:55] lifeless: I'm sure there's bzr-svn- or svn-specific memory leaks as well still though [13:59] jelmer: right, I'm just noting that it needs more analysis :) [14:00] jelmer: and my question to ToyKeeper will help [14:00] ToyKeeper: if you could answer it that would be great [14:00] apropos #75700, how ghetto is extracting the version from the deprecation symbol's string [14:01] lifeless: The spike happened just after it finished fetching all the revisions, and started on the next step. [14:01] 22:34 < lifeless> ToyKeeper: was it building a tree ? or just a branch fetch ? [14:01] I only know what it printed onscreen, which didn't include that much detail. [14:02] ToyKeeper: well, did you end up with a working tree? [14:03] Yes, the result seems to work fine. [14:04] ToyKeeper: You'd want http://svn.gnome.org/svn/sawfish/trunk rather than http://svn.gnome.org/svn/sawfish [14:04] ToyKeeper: Or perhaps bzr svn-import http://svn.gnome.org/svn/sawfish [14:04] ToyKeeper: so 'yes it was building a working tree' [14:05] next thing would be to try fethcing into a treless branch [14:05] lifeless: Oh, sorry, I parsed that as "functional result". Yes, it included a working tree. :) [14:06] jelmer: Yes, I plan to fetch only the trunk for a real conversion. 90% of the files are in tags/, and that's wasteful. I used the repo root just as a test case. [14:06] ToyKeeper: That's an unfair comparison with git-svn then though [14:07] I fetched the repo root with git, too. [14:07] Ah, ok. Sorry [14:07] I wasn't aware it could do that [14:12] The behavior of git is mostly irrelevant. I just wanted a vague idea what people might expect after using other tools. [14:17] * jelmer tries to reproduce [14:24] I hope the gnome server admins don't mind me sending hundreds of thousands of http requests as I poke at this. [14:25] poke what :o [14:25] hmm [14:25] ToyKeeper: why are you poking sawfish via svn [14:26] bzr branch http://bzr-mirror.gnome.org/bzr/sawfish/trunk ?? [14:26] Jc2k: The sawfish project is considering moving to git or bzr, so I'm looking into the migration details. [14:27] well its already kinda migrated to both :) [14:27] gnight [14:27] you can get an rsync of the sawfish module svn stuff if you want to keep running conversions though [14:28] either ask bkor or i can throw up a .tar.gz on my webspace for you [14:28] conversion of sawfish trunk here took 20 minutes [14:29] unfortunately I was away for a bit while it was building the working tree :-/ [14:32] * LarstiQ chains jelmer to his chair [14:34] Jc2k: Any chance of getting tag data in those mirrors? :) [14:35] ToyKeeper: git-mirror has tags, bzr-mirror.. i don't know how to, but the tags exist as branches [14:35] http://bzr-mirror.gnome.org/bzr/sawfish/tags/ [14:39] In any case, whether or not grabbing from root makes sense, it does help expose a memory issue. [14:45] hmm, this appears to be related to the number of write groups I use in bzr-svn [15:21] Is there a faster way to push/pull to central repository than using the prefix sftp:// ? I've got a shared key solution today but I've heard something you could still use SSH without having to use sftp? [15:22] nandersson: bzr+ssh://, the drawback is that that requires having bzr on the remote side. If that is no problem, it will be faster than sftp:// [15:23] nandersson: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#id60 [15:24] LarstiQ, Thanks for that! [15:25] nandersson: np :) [15:25] * LarstiQ heads off to Parkpop [15:27] LarstiQ, enjoy! [15:49] I'm a first time Launchpad user and I've created a new empty branch, factoryx-java, that I try to push to with: bzr push lp:~niklas-andersson/+junk/factoryx-java [15:49] but I get this error: bzr: ERROR: Transport operation not possible: http does not support mkdir() [15:50] nandersson: try running `bzr lp-login` first [15:51] aha, thanks! [15:54] dato, Thanks a lot! Now I'm up'n running [15:54] nandersson, great [16:22] How do I get Eclipse 3.4 into Ubuntu 8.04 without breaking the repository? [16:23] ...or Eclipse 3.3 even.. [17:39] is there something like svn:keywords in Bazaar? [18:02] bpeterson: I believe someone has written a plugin to do them [18:02] nasty things though they are [18:02] === visik7 is now known as Guest51209 === visi_ is now known as visik7 [19:04] beuno, ping [19:20] ToyKeeper, still there? [19:21] whatever happened to your diff panel patch ? === abentle1 is now known as abentley [19:47] emgent, pong [19:47] er [19:48] jelmer, pong [19:48] emgent, ignore me :) [19:48] beuno: was just wondering if you had time to do some patch reviewing for bzr-gtk [19:48] jelmer, sure, I can spare an hour or so after I eat something :) [19:48] es BB up? [19:49] it is, cool [19:49] I'll get to it in a while [19:50] is there a release date for 0.95? [19:52] not yet [19:52] I would like to get daniels signature checking fixed [19:53] sounds like a good idea [19:53] I've been toying with the idea of getting bzr-search integrated on there [19:53] it should't be too much work [19:54] I've just been crazy busy [19:55] Yeah, that would be a really neat thing [19:56] most of the backend stuff can be re-used from Loggerhead, so it's more about the interface [19:57] anyway, off to get food. I'll try and go through the whole batch when I get back [19:57] and, btw, I just re-poked the DD about bzr-upload [19:57] ah, thanks [19:57] but I suppose it may be time to find someone else... :( [19:57] oh, ok [19:57] I can keep on poking, just don't want to keep on delaying it [19:58] k [19:58] thanks for packaging that, btw :) [20:15] I keep getting this error when updating. But I don't get on wich file bzr: ERROR: [Errno 13] Permission denied [20:15] Can I force or see some log to know where the error is? [20:20] ~/.bzr.log may be able to tell you [20:25] beuno: Is there a loggerhead example up somewhere that does search? [20:29] jelmer: http://bzr-mirror.gnome.org:8080/$MODULE/trunk [20:29] :) [20:31] Jc2k, ah, thanks :-) [20:37] beuno, J2ck: coming up with the right UI would be the hardest bit I guess [20:37] aye [20:38] I just sent a patch that allows indexing branches from "bzr viz" [20:41] nice [21:02] If I rename a repo, and one of it's branches, manually, the only thing affected would be the Working trees generated as checkouts of this branch? [21:11] beuno: Just saw a bzr-upload upload, thanks! [21:17] jelmer, there is no .bzr/log [21:18] or .bzr.log [21:18] enquest: .bzr.log in your home directory [21:19] jelmer no there is not much more info in there [21:19] it crashes when always when updating a file [21:20] jelmer, here the traceback http://dpaste.com/59818/ [21:21] enquest, no idea what's going wrong, sorry [21:21] wb LarstiQ [21:25] jelmer: thanks, firewall problems ftl [21:25] Is there a good tool for browsing bzr repositories on the Web? [21:26] davidstrauss: do you mean something like loggerhead? [21:27] davidstrauss: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3513 [21:28] LarstiQ: yes, but i couldn't find good info on it [21:30] davidstrauss: what kind of info are you looking for? [21:30] LarstiQ: Documentation for it [21:32] LarstiQ: many of the related sites seem to be down or devoid of information [21:33] LarstiQ: for example, http://www.lag.net/bzr.dev/changes [21:40] moin [21:40] moin [21:41] http://icanhascheezburger.files.wordpress.com/2008/06/funny-pictures-never-trust-a-feline-technician.jpg [21:41] davidstrauss: hi, what sort of info do you want? https://launchpad.net/loggerhead/ is the home for loggerhead these days [21:41] lifeless: thanks [21:50] lifeless: morning [21:50] hi thumper [21:51] lifeless: do you have a date for the move across the ditch? [21:51] enquest: for some reason the rename is failing [21:51] enquest: renames on window et permission denied when a file is open - is it possible that you have a file in your tree open in an editor ? [21:52] lifeless, I found it ther was a directory not in the right permission but bzr didn't tel me wich one [21:52] thumper: not yet, currently getting budget size from bank [21:52] enquest: cool; could you file a bug please? [21:52] lifeless: fun, fun [21:53] how much is the house you want? I don't know, how much can I ask for? well it depends on the house ... === edcrypt is now known as edcrypt_ [22:02] jelmer, seems the poking finally payed off! [22:02] lifeless, hey! [22:02] hi beuno [22:03] how did the search talk go? [22:03] good [22:03] http://www.robertcollins.net/talks/bzr/200806-slug [22:04] * beuno branches [22:04] it was taped as well [22:04] anything interesting come out of it? [22:05] nothing major [22:10] lifeless, Search seems to depend on weave_store existing, is that right? [22:11] lifeless, I've got a pending merge request that adds an Index button to bzr viz [22:11] not pending anymore :) [22:11] jelmer: I was going to update it for bzr.dev in the weekend [22:12] jelmer: but I had some stomach updaset and spent most of it in bed taking drugs :( [22:12] lifeless: ah, ouch :-/ [22:13] yah not fun [22:14] still hurts a bit now, but fingers cross I'll get some code written [22:14] curious, anyone seen issues w/ create_signatures (gpg) for bzr 1.5 on gentoo? [22:17] ...specifics being the signing generally just hanging [22:18] I wouls strace -ff and see whats happening [22:19] * ferringb mutters, was expecting that suggestion [22:19] was hoping someone had a solution that didn't involve me debugging it myself ;) [22:19] ferringb: (no I haven't heard anyone else complain) [22:19] ferringb: I expect its the gpg command doing something you don't expect [22:19] yep [22:19] gpg-agent specifically seems to be implicated [22:22] hello [22:22] why should i choose bzr over git? [22:23] lifeless: reminds me, noticed your nick a couple of times in trac-bzr discussions- any comments on that pkg? [22:23] lifeless: specifically, areas of improvement, if it's still actively maintained, etc [22:23] jelmer: uhm - [22:23] File "/home/robertc/.bazaar/plugins/svn/fileids.py", line 20, in [22:23] from bzrlib.knit import make_file_knit [22:24] jelmer: which url should I pull from to fix that ? [22:24] bjwebb_: because its better overall ? [22:24] bjwebb_: (sorry if that sounds flippant) [22:24] lol [22:24] for example? [22:26] less tightly coupled to ext3 internals, less portability issues, more hackable (written in python), more approachable UI [22:26] tracks renames [22:26] uhm [22:27] what I hear from git refugees who start using bzr is that bzr is 'nicer' and 'more pleasant' and 'not in their way' [22:27] oooh, tracks renames [22:27] nice [22:27] lifeless: 0.4 branch [22:28] any good bzr hosts than propreitarypad? [22:28] bjwebb_: any web host will do [22:28] bjwebb_: http://kubasik.net/blog/tag/bzr/ [22:28] bjwebb_: point 9 [22:28] bjwebb_: really sums up what we are trying to achieve - and I think we _are_ achieving it [22:29] bjwebb_: alioth, savannah (though their support is in beta and not yet polished) [22:29] bjwebb_: oh, if it matters - bzr is a GNU project [22:29] it is now, nah, doesn't really matter to me [22:30] all that matters on the ethical side is that it is free software [22:30] so bzr does branches as directories in the way that cvs and svn do [22:31] I read that as 'can you checkout arbitrary subdirectories of a branch'? (Is that a fair translation?) [22:31] jelmer: whats the url [22:32] lifeless, http://people.samba.org/bzr/jelmer/bzr-svn/0.4 [22:32] It's also registered in launchpad, I believe as lp:~jelmer/bzr-svn/0.4 [22:33] jelmer: its rich-root, or subtrees [22:34] lifeless: rrp [22:34] are those repo formats documented somewhere? [22:34] I often have no clue what to use [22:34] (and why I should choose) [22:35] i'm having trouble using bzr-svn. when I try to branch an svn repo I get the message "Unable to load bzr-svn extensions - did you build it?" After downloading the svn plugin I ran "make" in the svn dir. anything else I need to do? [22:35] http://bazaar-vcs.org/BazaarFormats, although it doesn't appear to be up to date [22:35] Are reports about the svn-1.5 branch of bzr-svn wanted? [22:35] RAOF: the 0.4 branch should work fine with subversion 1.5 [22:36] berto-: Right. That's something I'm meaning to report; the modules seem to be installed a directory or two too low. [22:36] uws: yes [22:36] jelmer: I take that to be a "no", then. :) [22:36] uws: in the doc/developers/repository-formats.txt i think [22:36] RAOF: Well, reports are always welcome :-) [22:37] bzr help init has some info as well it seems [22:37] RAOF: what can i do to make it work? [22:37] RAOF: I just wouldn't recommend using that branch if you're just looking to try out bzr-svn as opposed to working with it [22:37] berto-: You installed bzr-svn in ~/.bazaar/plugins/svn ? [22:37] jelmer: yes, sir. [22:37] jelmer: I was just kinda interested. Depending on how the mood takes me, I may actually hack on it, too. [22:38] Well, the reports are: the modules are installed in the wrong place, and they generate a bus error in ra.c on x86-64 :). [22:38] berto-: Any errors in ~/.bzr.log ? [22:38] bjwebb_: I read your lasst question as 'can you checkout arbitrary subdirectories of a branch'? (Is that a fair translation?) [22:38] not quite [22:38] RAOF: The bus error was fixed about a week ago - are you using a recent revision? [22:38] jelmer: 1 sec, i'm going to clean out my log and repro the error [22:38] i get the impression that in svn adn cvs branches are just directories [22:39] wheras in git they are kindof abstracted [22:39] jelmer: Yes. Pulled as of yesterday. [22:39] RAOF, and rebuilt? [22:39] Yes, but I'll check again. [22:40] bjwebb_: ah; so in cvs a branch is orthogonal to directories, they are identified by tags [22:40] bjwebb_: in svn a branch is just a directory [22:40] right [22:40] whats it like in bzr? [22:40] in git and bzr and hg etc branches are first class objects [22:40] jelmer: the last interesting bit looks to be: UnboundLocalError: local variable 'version' referenced before assignment [22:40] jelmer: i can send you the entire traceback if you wish. [22:41] bjwebb_: that said, I strongly believe that we have gone too far [22:41] berto-: Any chance you can pastebin it? [22:41] and need to restore some of the flexibility that cvs/svn displayed in this area [22:42] in any DVCS branches are first class [22:42] :) [22:42] jelmer: http://paste.pocoo.org/show/78162/ [22:42] * pygi hides [22:42] pygi: :) [22:43] berto-: That's odd - what revno of bzr-svn are you using? [22:44] * pygi is practicing for the book xD [22:44] jelmer: revno: 1368, just downloaded it last night. [22:44] jelmer: Gah. Apparently I _hadn't_ rebuilt. Sorry for the noise. [22:45] jelmer: i'm working on cleaning out some other stuff. [22:45] berto-: Did "make" create a ra.so file in your plugin directory? [22:45] jelmer: yes it did. [22:46] jelmer: ra.so client.so wc.so and repos.so === bjwebb_ is now known as bjwebb [22:49] jelmer: i see pycurl errors in my .bzr.log; is that from bzr-svn? i should install pycurl, working on that ... [22:49] berto-: you don't need pycurl [22:50] lifeless: ok, thanks. wonder what the pycurl error is all about then ... [22:50] berto-: its probing for it is all [22:50] berto-: What is the error exactly? [22:50] berto-: it possibly needs to be toned down :) [22:52] lifeless: jelmer: here's the entire log: http://paste.pocoo.org/show/78163/ [22:56] RAOF: I've add some code to make bzr-svn warn when the extensions are out of date [22:57] * LarstiQ thought that was some sort of acronym at first [22:57] *warning [22:58] berto-: please update your version of bzr-svn and try again [22:59] jelmer: http://rafb.net/p/uWYMxK12.html [22:59] lifeless, you need to have libsvn-dev installed [23:00] jelmer: then the exception could note that :) [23:01] jelmer: i'd go about doing that by running "bzr pull" ? [23:01]