[00:00] hi *! [00:00] OMG, jelmer is back [00:01] hey beuno :-) [00:01] hi. is there a way to run, say, the update command and have it only indicate what it *would* do rather than take action? [00:01] beuno, Do I have you to blame for the bzr-search upload? If so, thanks ! [00:02] jelmer, yeah, I took advantage of debcamp :) welcome' [00:02] now, I'm about to release loggerhead 1.6.1, which would be nice to have in debian/ubuntu too :) [00:02] even PPA meanwhile [00:03] BrianRice, I don't think there's a --dry-run option. Feel free to file a bug requesting it [00:03] ok [00:03] 08:46 < mwhudson> "Port Loggerhead should listen on (default 8080 is the default." [00:03] beuno, ah, cool [00:03] "bzr log" comparison seems to do well enough in the mean-time [00:04] beuno, will see what I can do to get into debian once I'm rested [00:04] mwhudson: perhaps [00:04] "Port Loggerhead should listen on (8080 is the default)." [00:04] jelmer, where were you, btw? vacation? [00:04] lifeless: that was a typo, yes [00:04] beuno, yep, went cycling in the alpes for ~10 days [00:05] jelmer: wow back already [00:05] Bet you're knackered now :) [00:06] jelmer, cool. Welcome back then. [00:06] pickscrape, I still owe you your review. I'm sucking at getting to stuff quickly lately [00:06] lifeless, yeah, bad weather so came back one day early [00:06] lifeless, thanks for the bzr-gtk pqm update === RAOF_ is now known as RAOF [00:09] beuno: no rush at all [00:13] lifeless: Some interesting results when tweaking the knobs on ChunkWriter for the btree index [00:13] http://rafb.net/p/owGbxj90.html [00:13] This is with the artificial nodes from the test suite. [00:13] But still interesting. [00:13] I'm planning on putting something together with real data tomorrow. [00:14] The only problem with using copy() is that it will change the page sizes if it is/isn't available [00:14] which means the test suite will become very brittle. [00:15] The "current" algorithm creates 490 pages, the "best" creates 390 [00:15] So there may be some room to either be a bit faster, or compress a bit better in the same time [00:16] Anyway, I'm done for the evening. === mw|brb is now known as mw [00:19] jam: gnight [00:19] jam: perhaps we should do the zlib interface ourselves === `6og is now known as kgoetz [01:03] hmm, rc5!? [01:04] jelmer, don't ask [01:07] It's ok. It's called "quality". That's a good thing. [01:15] AfC: what is this "quality" thing you speak of? [01:23] It's what happens when you take the time to polish a release after you've decided to make one in the first place. There is a point of diminishing returns, but I've long felt that being shackled to particular dates and thereby shipping arbitrary bugs does not result in a better user experience. [01:24] thumper, working on the gnome theme, progress so far: lp:~beuno/loggerhead/gnome_theme (still have to fix quite a few things) [01:24] beuno: cool [01:25] AfC: a hard shackling to a specific date, no. But I feel it's better to not ship it if it needs too much polish. [01:25] lifeless, you have access to gnome to push this once it's finished, don't you? [01:26] beuno: maybe:) [01:26] :) [01:26] * beuno -> dinner [01:46] LarstiQ: so if something needs too much polish, what - you give up on the project? [01:47] lifeless: include it in the next release [01:48] LarstiQ: well, thats what we're doing :) [01:50] lifeless: I was disagreeing with AfC's general statement, I think :) [02:05] oh suck [02:05] some plugin is making TestOutsideWT.test_url_log fail hard [02:06] lifeless, have you updated bzr-svn recently? [02:06] jelmer: FSVO recent [02:06] jelmer: remember it segfaults for me [02:07] lifeless, ahh [02:07] lifeless, it should no longer segfault [02:07] lifeless, if it does, please let me know [02:07] 0.4 still ? [02:07] it also contained a bug that made test_url_log hang [02:07] yep [02:08] I worked on a fix for this with Mark Hammond, which made it into the 0.4.11 rc [02:08] pullink [02:11] eek [02:11] I'm in install-revisions, in fetch :( [02:12] EFREAKINGSLOW [02:15] jelmer: editor.c: In function 'py_dir_editor_change_prop': [02:15] editor.c:358: warning: unused variable 'p_c_value' [02:16] lifeless, thanks, fixed [02:16] also, [02:16] ra.c:1141: warning: 'py_revstart_cb' defined but not used [02:16] ra.c:1161: warning: 'py_revfinish_cb' defined but not used === mw is now known as mw|out [02:18] meh, === kiko is now known as kiko-zzz [02:18] * lifeless disables Werror [02:19] ah, looks like that happens when you build against svn 1.4 [02:19] fixed as well [02:20] hmm, build_ext -i is broken [02:20] actually, no, its fine [02:20] ok, that test isn't hanging now, thanks [02:20] * lifeless returns to log hacking === toytoy_ is now known as toytoy [03:55] 'No handlers cound be found for logger "bzr"' [03:55] ^^ wassat? [03:55] 1.6~rc3-1~ bzr and 1.6.0-1~ bzrtools [04:30] lamont: a race? [04:30] lamont: from pqm or something? [04:30] lamont: also, bzr-playground? [04:31] that'll teach him to unidle. [05:38] lifeless: testresources? [05:38] jml: yes, high on my queue [05:39] jml: or are you wanting to chat about it right now? [05:39] lifeless: no, just thought I'd take the opportunity to pester :) [05:46] can I review-by-mail? [05:48] jml: I see why you wanted the review; you went rather critical. [05:48] unfortunately, some of what you did isn't suitable [05:48] lifeless: that's ok. I figured that would be the case. [05:49] in particular the licence changes are incorrect [05:50] lifeless: review by mail is fine by me. [05:55] we'll see if lp forwards it to you [06:27] beuno: I'm loving bzr upload, it works like a charm. :) [08:05] later all [08:38] hi, i've a question regarding launchpad-cscvs, is this the right place to ask? [08:42] beuno: jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14) [08:42] beuno: jelmer: is this something to worry about or shall I continue uploading it? [08:42] sadleder: probably #launchpad is better [08:44] thumper: thanks === BasicPRO is now known as BasicOSX [10:27] is it intentional that http://bazaar-vcs.org/releases/src/ doesn't have the latest 1.6 RCs? [10:27] oh [10:27] * luks is blind [11:28] Since MarkH is producing .exe installers, would you like my builds of the Python-flavoured ones? [11:32] * awilkins finds the python ones to be easier to hack/dogfood on [11:33] jam: (when you are here, and if you are interested) http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1 [12:09] * luks wonder why https://launchpad.net/~bzr/+archive has 1.6rc5 for hardy [12:11] +s [12:11] Is everyone dead at their desk? [12:13] yes! [12:13] Arrgh, 'tis zombie bob2 [12:25] hi. is it possible to change commit metadata (message, commiter etc)? [12:31] no [12:31] unless you count "bzr uncommit" [12:31] or merging them and giving better information in the merge revision [12:42] siretart, hi [12:43] hey jelmer [12:44] jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14). is this something to worry about or shall I continue uploading it? [12:45] what are the errors exactly? [12:45] jam: did you cut bzr-1.6-rc5 yet? [12:46] AfC, yep, according to the website :-) [12:48] jelmer: I can mail you the full log if you want to know [12:48] jelmer: where should I mail it to? [12:49] siretart: jelmer@samba.org === prateeksaxena is now known as prTk [12:49] siretart, It's probably nothing, but let's check just in case [12:50] jelmer: should be in your inbox now [12:50] jelmer: ah. Nice. Someone should change channel topic then. === siretart changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc5! / http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ [12:51] AfC: this channel is -t [12:56] bazaar: please choose a different nickname; you will confuse people with the nickname you have :) [13:05] lifeless: in my case, it was a root owned ~/.bzr.log [13:05] the other person seeing it doesn't have such a simple explanation [13:06] siretart, thanks [13:11] jelmer: is that expected breakage, local breakage or is there something really wrong? [13:14] siretart, I haven't received your email yet [13:15] ah, got it [13:17] the file has been created with this command: env -i bzr --no-plugins selftest -v | tee selftest.log [13:25] ah, it's all poll errors from pycurl [13:25] lifeless/jam: ping [13:30] Oh dear. I got the error at https://bugs.launchpad.net/bzr-svn/+bug/229419 / https://bugs.launchpad.net/bzr-svn/+bug/234010 and, upon upgrading to bzr-1.6-rc5 and bzr-svn trunk, trying to bzr pull in a (from Subversion) checkout seg faults [13:30] Launchpad bug 229419 in bzr-svn "WorkingSubversionBranch.test_create_checkout fails" [High,Fix released] [13:32] * AfC is not even sure where to turn next [13:32] Is bzr-svn trunk something runnable? [13:32] I thought jelmer was doing all his stuff in the 0.4 branch or something... [13:33] Oh? [13:33] * AfC tries that... [13:34] * fullermd doesn't really know, just vaguely remembers conversations here. [13:34] fullermd: sure. Thanks [13:34] He must be dead, though. It's been two minutes since I said 'jelmer' out loud, and he hasn't shown up. [13:34] I'm not entirely sure he is required to come running just because someone says his name. [13:37] AfC, did you rebuild bzr-svn after updating it? [13:37] fullermd, coffee brake :-) [13:37] *break [13:37] Is it safe to have another web server serve Loggerhead's static files, instead of passing them back to Paste? [13:38] Oh, good. I was getting worried about you ;) [13:39] (-: [13:40] jelmer: so I just did a fresh branch of 0.4 (ok, branch + pull --overwrite --remember, whatever) [13:40] jelmer: and then ran `make` there. [13:40] jelmer: and it too segfaults [13:41] jelmer: .bzr.log shows it getting as far as "opening SVN RA connection to 'svn+ssh://afcowie@svn.gnome.org/svn/gtk+/trunk/" [13:41] jelmer: and then that's it [13:41] AfC, any chance you can run it inside gdb and paste the backtrace? [13:41] Sure, I can try [13:42] gdb bzr pull ? [13:42] * AfC doubts [13:42] `gdb python` and inside gdb `run /path/to/bzr pull` [13:42] k [13:45] jelmer: http://rafb.net/p/2Gm5ck59.html I hope [13:45] * AfC has never tried Python inside gdb before, but has plenty of scars from trying to debug segfaults in Java code reaching to a native library. Pain. [13:46] AfC, thanks [13:46] AfC, It's not too bad with Python [13:46] AfC, there's even gdb macros that allow you to inspect the python stack [13:46] jelmer: single threaded :) [13:46] jelmer: oh yeah? Nice. [13:46] jelmer: [now that Java is finally free, we're starting to see some progress along those lines] [13:46] AfC, Ah, of course. Multiple threads would make things more complex in java [13:54] hrm, if i bzr merge something but don't commit it, what's the standard way to revert the merge? [13:54] revert? [13:55] i bzr revert'ed each of the individual file changes but when i run bzr stat it still says i have a pending merge [13:55] rocky, just revert without any arguments [13:55] revert doesn't touch the merges, just the full version. [13:55] rocky, (which will revert all changes in the working tree) [13:55] ah thanks ;) [13:55] rocky, or revert --forget-merges [13:55] (there's an arg to touch ONLY the pending merges too, but if you're blowing away the merge, you don't care about that) [13:56] jelmer: btw... i've troubleshooted the speed issue with bzr-svn 0.4.10 a bit again... and i'm seeing that everytime i commit, it basically checks properties on every folder in the remote svn repo (100's of svn requests) [13:56] siretart, seems fine to me to upload [13:56] siretart, there's an issue with pycurl, but I think that's known [13:56] rocky, even with 0.4.11~rc1? [13:57] jelmer: 0.4.11-rc1 only works with bzr 1.6rcX right? [13:57] rocky, yep [13:57] jelmer: i tried playing with that in a sandbox the other day and got tracebacks all the time [13:58] jelmer: does that mean you won't be trying to fix this in the 0.4.10 branch? [13:58] rocky, what backtraces exactly? [13:58] rocky, yes, 0.4.10 won't see any further development [13:58] jelmer: i'll have to try again (i didn't at the time because you weren't around) to see the tracebacks [13:59] jelmer: (am I in error to be working from your 0.4 branch? Should I grab the 0.4.11-rc1 tarball instead?) [14:00] (or trying to bludgeon Subversion, or...?) [14:00] Wouldn't you be doing that anyway, just on GP? :p [14:01] fullermd: I was thinking more a rapier missile battery on fully-automatic, but yes [14:01] AfC, no, the 0.4 branch should work just fine (atm it's the same code as 0.4.11~rc1) [14:01] AfC, I'm not sure what's causing your backtrace, still looking into it [14:01] jelmer: (that's what I figured) [14:02] jelmer: what version of svn does bzr-svn 0.4.11 require? [14:02] jelmer: Most kind. I hope it's not something stupid I'm doing (or with my environment). [14:02] rocky, 1.4 [14:02] jelmer: will it work with svn 1.5.x ? [14:03] AfC, even then it shouldn't be segfaulting [14:03] rocky, yes [14:03] jelmer: atm i'm testing with http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/ ... should i keep testing with that or switch to your tarball or? [14:04] rocky, that seems fine, though you may want to use the original location (http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead since the lp mirror may be out of date) [14:04] (I would automatically blame Subversion, except that I was able to do an `svn checkout` of a different project whereas that URL segfaulted for bzr-svn trying to do a checkout) [14:04] jelmer: gotcha [14:22] jelmer: here's a traceback just trying to check out a svn branch... http://cluebin.appspot.com/pasted/601 [14:23] rocky, was this in a clean sandbox? [14:24] jelmer: that toplevel "repo" dir was a fresh repo i just created with "bzr init --rich-root-pack repo" if that's what you mean [14:25] jelmer: but... the remote svn repo it's connecting to has lots of bzr props set from other versions of bzr-svn [14:29] jelmer: and, the remote svn repo i'm connecting to is publically available so you can play with it if you'd like [14:36] rocky, thanks, will give it a try [14:53] for a while my prompt (Ubuntu) included the version of the current tree, now it doesn't [14:53] where is that set? [14:56] ktenney: I think there may be something in /usr/share/doc/bzr/examples , but I'm not sure [14:59] beuno, ping [15:00] jelmer, pong [15:00] beuno, any chance you can set a tag for the loggerhead release? [15:01] jelmer, I've never used tags. Do I have to change the repo format? [15:01] beuno, if the branch is in a packs format, you should already be able to use tags [15:02] beuno, e.g. "bzr tag -r213 loggerhead-1.6" [15:02] jelmer, sure then. Tag && push? IIRC, they don't propagate automatically? [15:02] although I have a checkout, that may do it [15:03] beuno, yep, a checkout should do it [15:03] beuno, they should propagate automatically [15:03] beuno@beuno-laptop:~/bzr_devel/loggerhead/trunk$ bzr tag -r213 loggerhead-1.6 [15:03] Created tag loggerhead-1.6. [15:04] AKA, done :) [15:04] we should have 1.6.1 out tomorrow, the code is up for review [15:04] don't you need to commit it though? [15:05] beuno, I see it here, thanks! [15:05] james_w .. no examples, I'll poke around. Odd how it appeared and disappeared ... [15:05] LarstiQ, it seems not. I never quite got my head around how tags propagate [15:06] rocky, thanks, I can reproduce that [15:07] jelmer: excellent :) [15:07] jelmer: if you can get this issue fixed i'll try again and if everything's ok i'll start using bzr-svn 0.4.11 for all my stuff ;) [15:08] since i'm using a bzr branch of your bzr-svn 0.4 i should be able to test quickly [15:12] rocky, cool [15:12] jelmer: if it wasn't for the fact that i love bzr so much i would have given up by now due to the speed issues with 0.4.10 :( [15:14] siretart, while you're at it, any chance you can sponsor an upload of loggerhead to debian and ubuntu? [15:14] rocky, 0.4.11 should really be a lot better in that regard [15:14] excellent :) === mw|out is now known as mw [15:20] Does anyone want my rc5 Python/Win32 installer builds? === kiko-zzz is now known as kiko === toytoy_ is now known as toytoy [15:27] awilkins, somebody asked me about them [15:27] awilkins, perhaps just add them to the releases wiki page? [15:28] jelmer: As attachments? [15:28] awilkins, Just pointing at the URLs if you have uploaded them somewhere [15:29] awilkins, alternatively, maybe you can upload them to the bzr launchpad project? [15:29] awilkins, It may be useful to talk with John or Mark about that [15:30] jelmer: The "exe" version is convenient but I prefer the Python version which is more hackable [15:31] jelmer: I have no inkling of how to upload a file to the launchpad project (I feel certain that I have no rights to do so) [15:31] awilkins, I think it makes sense to have both available for users to download [15:31] awilkins, John, Mark or Martin should be able to help there [15:32] markh: Ping? jam: ping? [15:32] jam: Ping? [15:33] jelmer: pong [15:33] awilkins: pong [15:34] jam, siretart is seeing select/poll errors in the testsuite from pycurl [15:34] jam, is that a known issue? [15:34] jam: Hello, I have a build of the python-installer packages for windows if you want them [15:34] jelmer: there is a known issue with newer versions of pycurl giving select/poll errors, yes [15:34] I don't know that anyone has really dug into it [15:34] jam, ah, ok [15:34] jam, So this occurs with older versions of bzr as well? [15:34] I thought vila poked at it a bit, but has been gone the last 3 weeks, and doesn't really start up again for about 24hrs [15:35] jelmer: it has to do with the new pycurl, not so much bzr [15:35] As I understand [15:35] so jam: Ah, cool - thanks [15:35] siretart, ^^ [15:36] jam, well, not *cool* but good it's not a new issue introduced by bzr :-) [15:37] jelmer: sec [15:38] jelmer: okay, I'll upload then rc5 in a minute then [15:38] jelmer: where to find the loggerhead packaging branch? [15:39] siretart, http://bzr.debian.org/pkg-bazaar/loggerhead/unstable [15:39] awilkins: thanks, I would guess it is easier to just have me reboot and build them, or have markh do it when he does the full installer. Mostly because someone needs to upload them, and sending 5MB email attachments isn't great :) [15:39] when doing a "bzr pull" is it possible to tell bzr to not overwrite a particular file? (ever?) [15:40] i.e. one of the files under version control [15:41] I'm guessing it's not, but if I'm wrong would be cool :-) [15:44] beuno: ping [15:44] Peng_, pong [15:45] beuno: Just to make sure, is it safe to have Loggerhead's /static/ directory served by another web server instead of LH itself? [15:45] timnik: generally not [15:46] Peng_, sure, I don't see why that would blow up at all [15:46] jam: Fair enough [15:46] Yeah, it seems to be working fine. [15:46] it accesses everything through the URL, so you should be fine [15:46] Thanks. :) [15:47] timnik: A pull will never overwrite a file. It may move it, but not destroy it [15:47] Peng_, anything for our star tester :) [15:47] jam, thanks [15:47] :) [15:47] awilkins, would it not attempt to update it, if it's contents had changed? [15:47] timnik: Unless that's part of the revisions pulled of course.... [15:48] awilkins, well, yes [15:48] awilkins, not to worry. It's more a matter of me being lazy than any real problem. [15:48] thanks! [15:52] timnik: You could write a post-pull hook that restored your file I suppose [15:53] awilkins, Thanks for the hints. What I should really do is fix my program to use a custom settings file not under version control. :-D [15:54] awilkins, admittedly I was looking for the lazy way out [15:54] timnik: I like a versioned template that you copy, but it's on the ignore list in it's "active" position [15:55] awilkins, hmm, that's an idea [15:55] the problem with this is that you have to manually copy any change to the real config [15:55] * timnik runs to try it [15:55] I'd really like to see a proper solution to that problem [15:55] but I can't think of anything [15:55] Primary file is versioned but secondary ignored file overrides it? [15:55] luks, it should really ever be a problem. If it's needed, the developer is doing something wrong, imho. [15:56] In this case it's me, and I'm too lazy to fix it. [15:56] timnik: well, software evolves and you need to add some configuration options [15:56] *never [15:56] luks, well, have a default file, and use it, unless a custom file exists. The settings in the custom file override that of the default. [15:57] default is under version control, custom is not, and is only ever used if it exists. [15:57] hmm, yeah, that works for some cases [15:57] but it's still not as flexible as I'd like [15:57] heh, now you sound like me :-P [15:58] is in possible to undo a "bzr ignore" other than edit the ignore file? [15:58] I don't think so [15:58] oh, ok. Almost had it. :-D [16:07] Is it just me or are the google IMAP servers being a right pain in the bum today... [16:09] They go through spells. Unfortunately Thunderbird doesn't deal with it particularly well :( [16:12] The only issue I ever have is having to log in frequently. [16:12] Is that what you meant? [16:16] Peng_: Yes, that's what I mean [16:16] That is a pain, but I've gotten used to it. :\ [16:17] That shows how much it happens. [16:17] awilkins, FWIW, I'm having problems with gmail through the web interface [16:17] it's doing odd things [16:18] What does hgext.convert.common.getchanges mean by "where id is the source revision id of the file." [16:19] jelmer: oh, loggerhead is a completely NEW package, isn't it? [16:19] I thought it was the revision id where the file was last modified. [16:19] siretart, yes [16:19] oops, sorry, wrong channel ;) [16:19] (although the question is bzr-related, too) [16:19] Leonidas Filthy mercurial user! Begone! [16:20] jelmer: oh, that meas I have to do a more thourough license check and such, I won't get to it today, will try tomorrow. If I fail to manage it until saturday, please ping me again [16:20] siretart, [16:20] jelmer: btw, did you run 'licensecheck -r .' on the source? [16:20] awilkins: hey, when i implement the bzr_sink, you'll be able to convert hg repositories to bzr ;) [16:20] siretart, thanks! [16:20] siretart, no, wasn't aware of that tool yet [16:20] siretart, I will, now :-) [16:21] jelmer: it is a rather simple tool using regex to determine the license of each file. of course not bulletproof, but a great asset for ftpmasters ;) [16:21] it is in the 'devscripts' package [16:22] siretart, yep, found it [16:22] siretart, I did a recursive grep for Copyright, that seemed to've covered everything [16:23] siretart, I'll keep this in mind for next time though, very useful [16:24] Leonidas: my understanding was that with hg fast-export | bzr fast-import you already *can* [16:24] Or with the bzr-hg plugin, though I don't know if it has received any polish in a while. [16:24] Leonidas: I don't really understand that sentence, in the context of hg or bzr [16:25] "source revision id of the file" sounds like the revision id that initially added the file? [16:25] Is this bug known and/or fixed? http://paste.ubuntu.com/39425/ [16:26] jam: Yeah, but as far as I have seen it should be the "current" revision. [16:27] jam: I haven't tried fast-(im/ex)port, need to give it a try. I am currently hacking up hg convert so there is support for continous integration of new changesets into repositories. [16:27] Laney: sounds like you have the bzr-dbus plugin installed [16:27] I don't know why it would need X11 [16:27] you could do "bzr pull --no-plugins" and have it work [16:27] siretart, any chance you can commit your changes for rc5 in the bzr branch on alioth? [16:27] I have no idea what that is jam [16:28] I'll file the bug [16:28] Laney, that's a known issue in bzr-dbus [16:28] Oh! [16:28] Laney: I don't know who did your setup then :) But you seem to have the bzr-dbus package installed. If you don't use it, you could "apt-get remove" it [16:28] jam: Maybe it was pulled in as a dep of something? [16:29] "Automatically installed: yes" [16:29] Well if it's known then I will wait [16:29] Laney, https://bugs.edge.launchpad.net/bzr-dbus/+bug/107169 [16:29] Launchpad bug 107169 in bzr-dbus "Failed to execute dbus-launch to autolaunch D-Bus session" [Low,Confirmed] [16:30] bzr-gtk suggests or recommends bzr-dbus these days, I think apt may automatically install it when you install bzr-gtk by default [16:31] Probably. But I don't know why bzr-gtk would be involved at all - I'm invoking this over SSH [16:32] To read a file from a repo I just need to lock_write it, right? Because lock_read 8which is unfortunately undocumented) would lock it also for reading, as far as I can guess. Am I right? [16:32] Laney, If you install bzr-gtk, apt may also install bzr-dbus for you [16:33] Laney, bzr-gtk isn't involved here, but bzr-dbus probably came along with it if you installed it [16:33] jelmer: err, I already did? [16:33] jelmer: Right, I get that. But shouldn't bzr-dbus be disabled if calling over SSH too, or? [16:33] >> bzr missing sftp://bzr.debian.org/bzr/pkg-bazaar/bzr/unstable/ :0.0 [16:33] Branches are up to date. [16:34] jelmer: Anyway, removing bzr-dbus has fixed it. Many thanks [16:34] siretart, sorry, my bad [16:34] siretart, my mail is just very slow today [16:34] pulling manually does indeed work [16:36] jelmer: I work with checkouts, my local branch is bound to alioth [16:38] siretart, I was checking for a commit email from alioth, but for some reason are not seeing any [16:39] ok, heading home now, cu later! [16:40] see you! === mvo_ is now known as mvo [17:32] beuno: did you see luks: http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1 [17:33] vila: I submitted my patch (with test) for bug #259855 so I closed that bug, but opened a new one about FTP transport and assigned it to you. It is priority low, so you are welcome to ignore it, unassign it [17:33] Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Medium,Fix committed] https://launchpad.net/bugs/259855 [17:34] jam, oh, open source rocks! :) [17:34] beuno: I haven't tried it [17:34] * beuno branches [17:34] but it looks like he set up a few packaging branches [17:34] and has the whole thing fairly scripted [17:34] I noticed he left out "intrepid" [17:35] and he hosted the packaging branches as "bzr" project branches, which isn't quite correct. [17:35] but in general, it could make things a lot easier. [17:35] jam: they already were under bzr [17:35]