[00:02] jam: the win32 binaries I'm putting together will have at least a couple of patches from 1.6 (setup.py/inno) - how do you feel about me also keeping those other test suite changes in? But if you think its important we only apply strictly necessary patches I'll back them out of my local tree. [00:03] hi markh [00:03] hi john [00:03] I'd rather have it be stock 1.6 if at all possible [00:04] For example, getting those patches in, would be something to get into 1.6 final [00:04] I guess you'd say that, which is why I thought I better ask ;) np [00:04] And would have been something I would have liked mentioned earlier.... [00:04] Supporting multiple versions is a real pain whenever there is skew [00:04] what would you have liked mentioned earluer? [00:04] markh: that you are going to need the setup.py/inno patches for the win32 release [00:05] So I would rather bring in something with a bit of cruft if it is going to be the *official* version anyway. [00:05] Though I'd really rather not bring in cruft :) [00:05] these are the same patches I've previously sent for the build process. [00:05] jam: here [00:06] So... standup meeting for 2008-08-13 [00:06] with yet more tweaks as I find issues in testing, such as uninstall problems, etc [00:06] spiv: what are you working on today and yesterday [00:06] markh: I understand the patches you are describing, I wish you had nominated them as 1.6 patches. [00:06] Since you are going to use them for a 1.6 release [00:07] hence.... they need to be in 1.6 [00:07] they aren't complete - I last made a change 3 days ago to it [00:07] Yesterday I got the improved testing docs merged, reviewed some of lifeless's stuff, and made a bit of progress on the HPSS effort tests. [00:07] Today I'm going to focus on the effort tests, plus mentally willing 1.6 to get released ;) [00:07] markh: I would rather you focused on getting something complete, that can be a 1.6 release, than having it perfect. [00:08] We can make it perfect for 1.7 [00:08] 1.7 isn't very far away, after all. [00:08] markh: I'll be the 1.7 manager, and if I have any say about it, we'll follow a strict timetable [00:08] so pushing 1.6 back [00:08] means that 1.7 will release the next day [00:09] spiv: ok, today was focused on getting 1.6rc2 out the door [00:09] which was successful [00:09] I don't see a huge issue in me releasing my "bzr + tortoise" binaries called "1.6" when they are infact 1.6 + 2 build/installer related patches [00:09] with zero changes to bzr itself [00:09] jam: hooray! [00:09] markh: Because I can't do "bzr co http://bazaar-vcs.org/bzr/bzr.1.6" and get what we released as bzr-1.6-win32 [00:10] markh: aka, I can't easily *reproduce* your work [00:10] It is all on *you*, and I'd rather have it in the system [00:11] markh: If you feel it isn't really worth merging, perhaps it could be a bzr-1.6-win32 branch or something [00:11] but I'd really rather avoid that. [00:11] if I publish those 2 patches, and those patches are only related to the binaries built that include tortoise, then I really don't share your concern. Release a stand-alone binary without tortoise using the existing setup.py if it bothers you that much [00:11] I *really* want a snapshot we could use. [00:12] markh: I don't want you to be the only person who can make a release of the official binaries. I think that is a valid concern. [00:12] I think for development processes [00:12] having the release be [00:12] tag the branch [00:12] 'make dist' [00:12] publish results [00:12] is a wonderful workflow [00:12] Having it be [00:12] make dist [00:12] then apply 3 patches [00:12] then make win32-installer [00:13] etc [00:13] is not a good *process* [00:13] which is what I'm trying to avoid. [00:13] spiv: Tomorrow is more triaging to make sure we are ready for 1.6-final, as well as getting my stuff together for 1.7 Metronome emails [00:13] (something we have also been missing) [00:13] TWiB should also be happening tomorrow [00:13] as I've missed it for 2 weeks now. [00:14] rockstar: ^^ [00:14] And I'd *like* to get to bringing the btree code into core bzr [00:14] I may not get that far. [00:15] lifeless: speaking of which, I'd like to hear your thoughts on a 1.6-final that had the log regression. [00:15] Martin seemed to feel it was a critical blocker [00:15] but he's not here to expand on that [00:15] TWiB? [00:15] Oh, right [00:15] This Week in Bazaar [00:15] yes, I agree its not a good workflow and I don't propose it as an ongoing process. Regardless, I consider myself appropriately scolded [00:15] markh: So make them public, I'll merge them for 1.6-final [00:15] and the problem is solved :) [00:16] As long as they are *usable* [00:16] You've convinced me about bundling TBZR [00:16] And you've almost convinced me about paramiko [00:16] that wasn't your approach when you reviewed them last time! [00:16] markh: I need a release [00:16] that causes friction :) [00:16] * awilkins can build the win32 stuff (up to the python installers so far) [00:16] I don't want to use an ad-hoc release unless we must. [00:17] awilkins: I can build the installers, but I would like to have our "official" build, which will be TBZR + qbzr, etc. [00:17] Either we get it for 1.6 [00:17] or it gets delayed to 1.7 IMO [00:17] Hmm. [00:17] I'll get it to you in an hour [00:17] I'd rather not have an ad-hoc build for 1.6 [00:17] Is qbzr better than Olive? [00:17] markh: If they are as unintrusive as you say, I'll be okay bringing them in for 1.7 [00:17] anyone about that can help me track down #254797, _read_bytes not defined when using smart protocol [00:17] awilkins: It is more Windows-like [00:18] as it is built on QT [00:18] there are tradeoffs between the two [00:18] qlog is better than bzr viz (IMO) [00:18] but gannotate is better than qannotate [00:18] bzr viz is what I use most [00:18] awilkins: qlog allows folding merges [00:18] Hows the conflict dialog? [00:18] which is *huge* for me. [00:18] johnf: I can [00:18] awilkins: I don't know that qbzr has conflict handling yet. [00:18] johnf: in a few minutes [00:19] spiv: cheers [00:19] spiv: I ran into that for _urllib when BB was not giving proper 404's by the way. [00:19] I have a patch to the bzr-gtk conflict window for starting my favourite win32 merge tools [00:19] spiv: anything else? [00:19] (for standup) [00:19] awilkins: wrt qbzr and tortoise, its probably fair to say we see better potential in qbzr, rather than thinking qbzr is already more "complete" [00:19] markh: Sounds good. I'll look forward to reading them tomorrow. If you are up late, I'd love to chat with you a bit [00:19] both about the locking issues you were seeing [00:19] and more potential specifically in the context of tortoise! [00:19] and about your development, etc. [00:20] Anyway, bed time [00:20] But now is family time [00:20] np - thanks [00:20] I might also be around in a couple hours depending on when everyone sleeps. [00:20] The good thing is that all these branches is actually giving me real experience doing non-trivial merges :) [00:20] * jam => away [00:20] jam: interesting [00:21] jml: no, not for the standup, thanks! [00:22] is there any way to copy/move a file WITH HISTORY between projects? [00:22] spiv: not for what standup? [00:22] I'm developing an app with components I'd like to eventually move into separate libraries [00:25] jam: reply, with worked example, which I think is what you wanted [00:25] bzr move cannot move between branches, which would be where I'd expect to see that, but was wondering if projects within a combined repo gave any benefits like that [00:25] jam: catch you later [00:26] jam: I know that martin would really like to avoid the log regression [00:26] I'm not sure how to do that :P [00:26] n[ate]vw: that's not possible as far as I know [00:26] * markh wonders what will happen if he sneaks in a transparent version of bzr.ico rather than the one that is in the branch... [00:28] james_w: so no plugins could either? basically, I'd be nice to take files like MyFloatStuff.c and MyMathStuff.c and put them into a separate "NumberLibrary" project without losing the histories [00:29] n[ate]vw: not possible. You could take a branch and delete everything else from the branch and just have the two files from that point on [00:31] that might work alright, especially if bzr ever gets horizons (?) or whatever they call branching just a recent history [00:32] stacked branches are in 1.6, history horizon is a way off [00:33] uhm [00:33] bzr split [00:33] kthxdone [00:34] lifeless: your rules patch still has "respectively" in the docs, now for a singular item [00:35] james_w: seems like I just skimmed something about stacked branches, but do you have a link? [00:35] lifeless: excellent, thanks [00:36] james_w: thanks [00:36] I gotta love "merge --reprocess" - it took a 74 line conflict region down to the 1 line it really is :) [00:37] jml: your nick is too close to jam's :( [00:37] jml: at least for these pre-coffee fingers. [00:37] spiv: you know the solution to that! [00:38] cut off the fingers! [00:38] james_w: n/m found http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html which was enough of a memory jog, I think I saw that in the checkouts help or something [00:39] oh, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-stacked-branches is where I saw it, FTR [00:39] abentley: are you around ? [00:40] abentley: my fix to iter_changes to be consistent has found a bug in diff that would show up on non-dirstate trees [00:40] abentley: but I'm not sure of the right behaviour [00:47] jam, TWiB is acknowledged, with high priority. [00:49] markh: what does bundling mean? [00:49] markh: I hoep it doesn't mean 'import into trunk' ? [00:49] one sec... [00:49] spiv: so it looks like medium.py is calling read_bytes on HTTPTransportBase but it's only implemented in SmartClientHTTPMediumRequest so maybe the read bytes should be on getsmartmedium?? [00:50] I'm totally poking in the dark here of course since I have no understanding of how this all fits together :) [00:50] lifeless: i don't think abentley is aroudn [00:51] johnf: what bzr version? [00:52] lifeless: 1.6rc2 and bzr.dev seems to exhibit the same bug [01:02] johnf: Ok, I'm looking into this one now. [01:02] spiv: let me know if I can help at all [01:02] spiv: I'm happy to look into it if pointed in the right direction [01:04] johnf: I think I have an idea about what's going on [01:04] johnf: I landed a change in 1.6 that tidied up a bunch of the logic around _read_bytes in bzrlib/smart/medium.py [01:05] johnf: part of that I think was moving methods from the mediumrequest into the medium [01:05] spiv: that makes sense [01:05] It wouldn't surprise me if the HTTP code didn't quite keep up. I thought I had fixed it (I definitely remember touching the HTTP code during that work), but I guess our test coverage is a bit lacking here. [01:11] Ah, I think SmartClientHTTPMediumRequest needs to implement read_line [01:11] lifeless: the bzr binary will bundle a few other binaries too (bzr-svn, qbzr, tortoise). The bzr.dev trunk's setup.py will get that capability, but no other code will be imported. Is that what you were asking? [01:11] Otherwise the default implementation falls back to calling that method on the medium, which is unimplemented in this case. [01:12] markh: cool; I was wondering if you intended to drop a copy of paramiko into the trunk etc [01:12] markh: that would have been concerning [01:13] lifeless: nope - just setup.py will kinda assume it is in-place when you make binaries [01:14] markh: windows binaries right ? [01:14] correct [01:14] kool [01:15] from a QA POV, we probably need to get the the point where setup.py nominates *exactly* what is bundled and fails if anything isn't there. It shouldn't be possible to "forget" to include something - but that can wait... [01:21] spiv: bug 257730 [01:21] Launchpad bug 257730 in bzr "bzr crashes during bzr pull" [Undecided,New] https://launchpad.net/bugs/257730 [01:22] johnf: ok, I have a probable fix in hand [01:23] johnf: http://rafb.net/p/XvhCPc82.html [01:23] lifeless: that looks like the same bug, thanks [01:24] yah [01:26] jam: I'm going to ask for the fix I'm doing for #254797 to go in 1.6 [01:32] lifeless: ping [01:33] hi [01:33] hey, first, thanks for the help on the article. The feedback from the head editor was great and it'll be out in pymag in sept [01:33] got bumped up a month [01:34] cool [01:34] I got asked to do a follow up article and I was thinking of covering a couple of workflows. Mainly a centralized (for the svn folks) and decentrailzed with share mainline [01:34] as I think those two are pretty common/useful for a large group out there [01:34] sounds good [01:34] is that your take or would another workflow better show off bzr or anything? [01:34] uhm [01:35] I think you should write about things you've experienced or played with [01:35] or helped people with [01:35] ok, definitely [01:37] It doesn't help that pycurl tests give (55, 'select/poll returned error') on my laptop. [01:41] spiv: that did the trick. Thanks === beuno is now known as beuno-dinner === beuno-dinner is now known as beuno [01:48] johnf: it has a bug, though :) [01:48] johnf: you may also be able to work around it by prefixing "nosmart+" to the http:// URL. [01:49] johnf: I'll send a polished patch to the list fairly shortly. === kiko-afk is now known as kiko-zzz [01:49] spiv: except I'm using a smart server bzr+https:// [01:49] Ah, in that case not so much :) [01:49] (The buglet is that there's a "return bytes" line in the _get_line function that needs to be "return bytes, ''" [01:50] ) [01:50] (Probably not significant in normal use) [02:01] Whoever just branched from my server (LP?) managed to download half of a 2 MB pack once, then the entire pack twice. Good going, bzr. [02:01] * Peng_ is away now. [02:01] Peng_: bleep [02:02] Peng_: same IP ? [02:05] Peng_: That would be me and my squid proxy I think. [02:05] Peng_: sorry! [02:06] spiv: upgrade it :) [02:06] lifeless: get it backported to hardy (or point me to a PPA I guess...) [02:06] spiv: feh [02:07] lifeless: that's my attitude too ;) [02:07] spiv: need a review for that patch" [02:07] ? [02:07] also, my rules one needs a review [02:08] and I'm wondering if we should file a bug on python for that 'cant write 80MB on smb reliably' bug [02:08] lifeless: I will need a review soon, not quite yet. [02:09] lifeless: hmm, probably. what happens exactly? Large writes get an EINVAL sometimes? [02:09] 22 whatever that is [02:10] bug 255656 [02:10] Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656 [02:12] lifeless: yeah, I'd bugger a file [02:12] lifeless: I wouldn't be very optimistic about it getting fixed, but you never know... [02:15] lifeless: hi, regarding your solution to bug 255656: I was told here that the solution is considered to be just a workaround for a bug in python.... [02:16] and that workarounds are not likely to be merged into bzr 1.6 [02:16] Ah, Squid. That would explain it. [02:17] * Peng_ goes back to being away. [02:17] what do you think? will there be a achance to get it merged into future revision (for the case python's bug doesn't get fixed) [02:17] spiv: You owe me $0.003 in wasted bandwidth! [02:18] Peng_: I'll have to buy you 1 mL of beer sometime... [02:28] jonnydee: its a bug [02:29] jonnydee: bzr supports python 2.4, so we have to fix it in bzr [02:39] rockstar: btw, did you end up doing much with that plugin you were writing in Dunedin? [02:40] jml, yes, but I haven't polished it. I didn't think there was much interest in it, so it got to my needs, and I quit. :) [02:40] Would you like me to make an official lp project for it? [02:41] hmm, is there a way for me to edit the checkin message after it was committed? [02:41] rockstar: do you have a published branch at least? [02:41] jml, no [02:41] * rockstar is ashamed [02:43] rockstar: +junk! [02:43] jml, yea yea... [02:43] warren: If you haven't pushed yet, and it's the most recent revision, you can uncommit and recommit. [02:44] someone else committed it, but I want to edit the commit message before pushing it to the real trunk [02:45] * Peng_ goes back to being away. [02:47] Peng_: you don't seem to be very good at being away [02:51] lifeless: so, we still hacking on Saturday? [02:51] if so, where, when and can RAOF come too? [02:53] I want to buy lingua latina [02:53] I think lynne would probably appreciate a little space, so not here [02:53] sure RAOF would be good company too [02:54] Howdie. [02:54] My place _could_ work. Possibly. There's a table and couch and stuff. [02:55] RAOF: where is your place? [02:55] Kensington. That makes it quite some way from both you and jml [02:55] indeedy [02:56] jml: whats your place like? [02:56] internetless. [02:56] jml: where are you now? [02:56] lifeless: spiv & Mary's place [02:56] ah [02:56] and next week ... ? [02:57] probably still up at Andrew & Mary's -- I've got a key. [02:59] well, there is a possibility. If spiv and mary would be happy with that. [02:59] I'll check in with Lynne when she gets home about doing it here [03:01] lifeless: ahh, ok -- thanks, taht's good news :) === mw is now known as mw|out [03:13] Question: Does bzr have any problem with many commits? Ie, are tiny commits about fixing little bugs, etc, acceptable in BZR? [03:14] Leefmc: absolutely [03:14] james_w: K [03:15] Anyone else used "Editra" before? I just learned of it today and it appears to have bzr support out of the box. [03:18] lifeless: Kensington isn't that far away. [03:20] where has spiv gone? [03:21] or going? :) [03:22] oh bugger - I see I should have put a 1.6 in the subject line for BB to see it targets 1.6... [03:23] lifeless: if it means the plants get watered, then we can probably cope with that... [03:24] markh: I'll be spending a couple of weeks in the South Island of NZ [03:24] ahh, nice :) [03:24] markh: and trying not to cut my head open with a snowboard ;) [03:24] oh that's right - you do that regularly? [03:25] Not very, which is probably the problem... [03:25] :) [03:27] lifeless: fix for #254797 sent to the list, btw [03:27] spiv: cool [03:29] jml: I know where spivs place is better [03:30] let's all party at spiv's while they are gone! [03:53] jam: welcome back :) [03:53] lifeless: well, for a bit at least [03:53] so I sent in a patch, its really quite tiny [03:56] Mmph. Has check gotten slower? [03:56] lifeless: so you basically just changed it so there are *no* per-branch config items? [03:56] Hmm, I thought there was some easy, obvious way to split a subdir with history into a new branch, but I don't see it. [03:56] I thought the point was to not version them [03:56] not to disable them completely [03:57] jam: Martin's request was to disable it rather than not-version [03:57] as he says: [03:58] If this is not baked yet then I think it would be cleaner to remove [03:58] the feature of reading from this file, rather than specially blocking [03:58] it out from being committed. We could still perhaps allow a branch or [03:58] plugin for trying filters to turn it back on. [03:58] ah, I do remember that. [03:58] Good enough I guess. [03:58] I still disagree with it, and I don't quite feel that Ian agrees, but I can accept the "lets postpone for now" [03:58] thank you [03:59] I'll merge that patch to trunk now then? [03:59] lifeless: please don't tie up the pqm yet :) [03:59] If I'm lucky, I'll get the 1.6 stuff merged that people want [03:59] and we can do a rc3 by tomorrow [03:59] so -final doesn't have to be delayed. [04:03] that would be good [04:03] I'll merge the rules after you go then [04:04] lifeless: It seems your patch is built on bzr.dev, not bzr 1.6 [04:04] do you want me to merge it to trunk and 1.6, or you'll do the cherrypick ? [04:04] So I'll cherry pick it [04:04] and you can merge it directly to trunk [04:04] ok [04:04] mwhudson, hi [04:04] I just addressed your review on my diff branch [04:04] jam: on inventories; does my worked example demonstrate the things you were concerned about ? [04:04] beuno: hi [04:05] lifeless: Did you ever get a chance to look back at bug 255155 (knit file permissions)? [04:05] Launchpad bug 255155 in bzr "bzr doesn't use the repository directory for permissions" [Medium,Confirmed] https://launchpad.net/bugs/255155 [04:05] beuno: oh right [04:05] fullermd: no, I haven't [04:05] beuno: i still think the diff should be against compare_revid if there is one [04:05] fullermd: can you upgrade to packs ? [04:05] mwhudson, and see 2 remaining bugs. The javascript one, I can squash tomorrow. bug #243415, not so sure about where to start [04:05] lifeless: Well you mention "minor variations" which doesn't seem to fit well with validators and "deterministic" values [04:05] Launchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/243415 [04:05] jam: I say that if we *don't do X* there would be [04:06] jam: the sentence before described X [04:06] mwhudson, aaaaaaaaaaaah, I see. I understand what you meant now. I tend to ignore the fact that we have compare_id, since the UI for it is so ugly [04:06] lifeless: Well... _can_. would rather not, for non-technical reasons. [04:06] beuno: yeah, but ... [04:06] fullermd: you have users using bzr < 0.92 ? [04:07] lifeless: No, but it means a soft-flag day of making everyone upgrade their branches (or swallow abysmal performance). And there'll be a hard flag coming up shortly when the next and rich-root-capable standard format comes along (in 1.2 or something soon like that) [04:07] fullermd: the problem with permissions is they don't really work well enough [04:08] fullermd: huh? why would there be a performance hit? [04:08] I'd rather only ram that through once. [04:08] Because pulling from packs into knits was life-threateningly slow, at least last time I tried. [04:08] Re-annotating and all. [04:08] fullermd: please try again, it should not be [04:08] fullermd: make sure you have the C extensions [04:09] mwhudson, I'll address the compare_id bit. Any ideas for #243415? [04:09] Hm. I'll try to fiddle with that tonite... [04:09] beuno: well, serve-branches still doesn't actually have a logging section, does it? [04:09] fullermd: slower-than-normal yes, life threatening slow - no, jam fixed that weeks ago [04:10] mwhudson, it looks like it does, yes [04:11] jam: thanks for the approval. Shall I upload my current rc2 binary directly to launchpad for the project and mail the bzr list, to try and get some feedback in time for a final? Or would you prefer more controlled testing by people first? [04:11] beuno: well, not one that sets up logging to a file ... ? [04:11] jam: this was the quote I think:"If we add a [04:11] constraint to the usual LPC rules that we must bubble compression [04:11] opportunities as high up the tree as possible, then yes. If we don't, I [04:11] think it is possible to have minor variations." [04:11] spiv: ugh... I just hit something nasty [04:11] jam: I was trying to be complete, possibly adding confusion. [04:11] I'm using bzr-email on a bound branch over bzr+ssh [04:11] and it seems to be doing the log on the bzr+ssh branch [04:11] and taking *forever* [04:12] markh: well, if beuno is up for it, we may have a 1.6rc3 tonight/tomorrow early [04:12] with your changes in it [04:12] mwhudson, doesn't line 48+ do that? http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/210?file_id=servebranches.py-20080618011543-s6ydx5c3bl38zap6-1 [04:12] my rc2 binary has only those changes you just approved. [04:12] (oh - and an icon with a transparent background ;) [04:13] jam, I can do rc3 tomorrow morning, sure (~10hs) [04:13] mwhudson, ignore me, it seems it doesn't [04:13] markh: ... what did I just mention about having the official build as part of core? :) [04:13] mwhudson, I'm tired :) [04:13] beuno: fair enough :) [04:13] mwhudson, so, not for 1.6? [04:14] beuno: so loggerhead _should_ have logging and the logging _should_ capture tracebacks... [04:14] beuno: but yeah [04:14] mwhudson, ok, different bug to address [04:15] mwhudson, how does releasing 1.6 this week sound? [04:15] beuno: awesome! [04:15] \o/ [04:15] jelmer even packaged it, so I can probably upload it to PPA [04:17] pickscrape, how's your branch coming along? can you make it this week? [04:22] lifeless, spiv: I would really like to include a NEWS entry with your changes. [04:22] Especially for "reasons why we went past an rc" I feel each commit should have a NEWS entry. [04:23] Could you write up a simple one for me? [04:23] sure, I guess [04:23] beuno: that's a point [04:23] beuno: how is loggerhead's NEWS doing? [04:23] mwhudson, well, it's... uhm... we try not to push it too hard [04:24] * beuno adds another task to his ToDo list [04:24] i guess we should write some stuff [04:24] beuno: oh, also, we have the issue that if i merge the current loggerhead trunk to launchpad's codebase [04:24] beuno: it will go blue [04:24] we should, um, do something about that [04:25] mwhudson, ah, yeah, I'd have to merge && revert && commit. If you point me at the branch tomorrow, I'll merge it in [04:25] beuno: ah yeah, that'll work [04:31] good day/evening. is there a logout equivalent to bzr launchpad-login? [04:31] Jucato: I don't think so [04:31] jml: ^ [04:31] lifeless, markh, beuno, spiv: Well, after just submitting all 3 patches to the wrong branch (and having them all merged), I'm re-submitting them to the correct branch, and going to bed. I'll work on 1.6rc3 tomorrow. [04:31] Jucato: What would it do? [04:31] jam: :P [04:32] jam: what branch did they land on ? [04:32] jam: ack - thanks! [04:32] lifeless: bzr.dev [04:32] jam: also, re - log [04:32] before I used bzr launchpad-login , this command worked: bzr checkout lp:~ubuntu-core-doc/ubuntu-doc/kubuntu-intrepid. after logging in, I get this error [04:32] bzr: ERROR: Repository KnitPackRepository ('file:///home/jucato/kubuntu-intrepid/.bzr/repository') is not compatible with repostiory RemoteRepository(bzr+ssh://jucato@bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/kubuntu-interpid/.bzr/) [04:32] jam: do you have a minute before you go, I can work on it over your night [04:32]