[00:00] just wanted to say thanks to bzr. [00:00] it enabled me to pull from qt.gitorious when git itself cannot. [00:00] lol, nice [00:01] lifeless: :) [00:01] lifeless: ah, but how do I use the git plugin? in svn it works ootb [00:02] odd, I've done that already and forgot... [00:04] ahh stupid git [00:04] why can't everybody just use bzr...life would be so much simpler. [00:13] dunno, I kinda like git [00:13] but I use both [00:16] luke-jr: so it was me who was stupid [00:16] luke-jr: s/http/git/ [00:17] luke-jr: can't expect every DRCS to do hg/bzr guggling of urls. [00:17] anyway, back to hacking [00:19] lifeless: do you know if there are any presentation on the bzr wiki that are up to date(ish) that I can base my talk on? [00:25] Hello [00:26] hi duckx_ [00:26] I was wondering what was the current state of nested trees in bazaar [00:26] i'd recommend you use the bzr-externals or scmproj plugins [00:26] see the plugin guide [00:27] Ok I will have a look, thx [00:27] I played with bzr-loom this WE [00:27] Nice plugin, very easy to use [00:28] Well I tried to find out what could be the best Workflow to get debian python-modules in sync in ubuntu [00:28] Using the debian repository ;) [00:30] That is using svn with merge mode ... [00:30] That fun, make me play a lot with bzr [00:33] Thx poolie [00:33] I will see what I can do with bzr externals [00:38] hi poolie [00:38] hi there [00:51] poolie, igc: I'm looking for a big bzr image for my presentation [00:51] know where to find one? [00:51] meaning a big screenshot? [00:51] igc: how are you feeling today? [00:52] poolie: just the bzr image for the slide master background [00:52] hi thumper - I'm ok today thanks [00:52] the logo? [00:52] igc: up for a skype call? [00:52] poolie: yes [00:52] thumper: sure [00:53] thumper: let me fire up my laptop first [00:53] poolie: we should have links to the images somewhere of the front web page I reckon [00:53] s/of/off/ [00:53] thumper: http://wiki.bazaar.canonical.com/LogoOptions [01:02] thumper: I have Skype up but it doesn't think you're online [01:36] poolie, thx again [01:37] the externals plugin was exactly was I was looking for ! [01:37] * duckx_ : my english is really crappy today [01:47] So, someone just asked me if there was a continuous integration server that integrates nicely with a DVCS (bzr, obviously) [01:47] I know lifeless was playing with Hudson recently, but I don't know whether that was Canonical internal, or a customer of theirs, or... [01:55] we're using hudson at canonical [01:55] for bzr (vila's test environment - I think he posted a url to it), for some dx stuff (internal builds - not public) [01:55] drizzle use hudson, its where I was introduced to it [02:02] igc is bug 537387 something that was fixed in a later installer? [02:02] Launchpad bug 537387 in bzr "Bazaar crash on update of (bzr-svn) checkout" [Undecided,New] https://launchpad.net/bugs/537387 [02:02] it looks familiar [02:03] poolie: he's using the latest installer already [02:03] poolie: it certainly includes the latest explorer [02:04] poolie: maybe the problem is fixed in 2.1.1 or a more recent bzr-svn? [02:05] Is it possible to mirror repositories? [02:25] yes [02:28] Is bzr git-serve part of the bazaar package these days? [02:29] I just noticed the 'server' module in the git plugin and was trying to see how it worked. [02:40] dcoles: I'd expect it to hook into 'bzr serve --protocol=' [02:41] Ah! I misread the wiki page [02:42] Yes, `bzr serve --git` will do it [05:23] lifeless: your thoughts wanted on bug 185211 [05:23] Launchpad bug 185211 in bzr "renaming out of directory with unicode name fails with InconsistentDelta" [High,Confirmed] https://launchpad.net/bugs/185211 [05:31] poolie: well, looks like I created a shell demo for it [05:32] yes, it's fine as an open bug [05:32] if that's all it is that's fine [05:32] i just wondered if you knew more about it than is described there [05:33] ENOENT :P [05:38] also, does https://bugs.edge.launchpad.net/bzr/+bug/337455 look like something that might have been fixed with bug 397705? [05:38] Launchpad bug 337455 in bzr "Unexpected error message about inconsistent delta ." [Undecided,New] [05:38] Launchpad bug 397705 in bzr "inventory delta consistency checks are missing known problems and not universally applied." [Critical,Fix released] https://launchpad.net/bugs/397705 [05:40] no [05:40] I suspect dirstate corruption there, but we should have fixed that too. [05:40] I'd be fine with closing it as 'we think it works now'. [05:51] igc: and others. bzr-explorer? <3 that is all. :-) [05:53] How do you spell “bzr missing” in git? :/ [05:53] apt-get install bzr-git ? :) [05:54] You'd make me a happy man if you could tell me that (a) that now has some way to specify non-master branches, and (b) I can use it on the kernel tree :) [05:54] 'git log origin/master...' or so [05:55] for (a) ah, um, for (b) i think revgraph stuff /might/ be ok on the kernel? [05:55] bob2: Imagine, if you will, that there are some 6400 commits in the last couple of weeks of git history :) [05:56] Hm. I think I want “git branch --contains”. That's not totally insane. [05:57] hi! how dho i recover from BranchInTheWay when using pipes? basically, i want to overwrite whatever is on launchpad (because it is wrong) [05:57] stewart: I don't know. delete the one on lp perhaps? [05:59] lifeless, trying... had fail because of that in the past... [06:00] lifeless, now get a "Not a branch" error. [06:01] RAOF: pretty sure it will find all unmerge commits [06:01] (note /3/ dots) [06:02] bob2: Oh! I thought that was an elipsis, rather than a part of the command. [06:02] ah [06:03] That's impressively arcane. Makes up for git branch --contains! [06:10] spm: ? [06:11] spm what does <3 mean? [06:11] igc: <3 == is love :-) [06:11] its a heart [06:11] turn your heard to the right [06:11] or your screen to the left [06:11] aha [06:11] spm: thanks! [06:12] igc: for someone (me) who spends all day staring at grey text on a black screen in consoles; a gui that makes life easier on less used tasks is a truly *wonderful* thing. magic stuff! [06:13] spm: I'd love it more myself if it stopped crashing all the time. One day soon I really need to fix that [06:13] ha. obvioulsy I haven't hit a crash yet. I'll revise my love for the tool and send a hate message when that happens [06:13] lifeless, but then, if i go to launchpad and create the branch... i get the "Not a branch" error still. if i push into that branhc, i get the BranchInTheWay error. so it seems that i'm a bit screwed... [06:26] * stewart notes this wouldn't happen with quilt. [06:26] lifeless, so tried to avoid syncing that pipe.... by adding a new pipe (with a new name) and removing the old one. I still get the "not a branch" error. so there's something on LP.... any idea what? or how? [06:29] hrm.. ~/.bazaar/pipeline-cachedir can go away.... let's hope that does something. [06:30] wtf... [06:33] stewart: i think you'll find the config inside .bzr/branch/branch.conf [06:33] you can break the pipeline there probably [06:34] poolie, i'm getting "bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~stewart-flamingspork/drizzle/embedded-innodb-configuration-table-function/"." yet grepping for "configuration" in .bzr reveals no results [06:35] i could go and try deleting the 29 branches on launchpad... [06:35] potentially screwing up everything i have linked to them... [06:36] stewart: try grepping in . [06:38] lifeless, still nothing... [06:38] try ~/.bazaar [06:38] and try .bzr of the branches you have on lp [06:39] lifeless, nope. not on my system at all. [06:39] * stewart is not gonig to grep / as that'll probably take 3 hours [06:39] reminder: bzr your mai [06:39] l [06:41] lifeless, i'll wait until some point after i can upload my work and propose merge reqs of it... [06:42] * stewart sees what damage deleting all 29 damn branches on lp may cause. [06:42] not especially nice UI that... 29 times several page loads... urgh. [06:43] oh wait... there's merge requests with comments on them. [06:45] now trying deleting the single empty branch... eep. [06:46] fuck. [06:48] hello. i was writing some tests for bzr-grep and noticed that some tests were not seen. changing the name from test_something to test_somethingelse made it ok. [06:48] are there any rules to test naming? [06:49] parthm: the function name? [06:50] lifeless: yes the function name. e.g. "def test_version_something" was not seen. If I changed it to "def test_ver_someting" the test count went up by 1. [06:50] parthm: did you perhaps have another function with the same name? [06:51] lifeless: hmm. could be. i will check again. [06:55] parthm: so yes there are restrictions, but both test_version_something and test_ver_something pass the them [06:57] lifeless: you are right. i think it was duplicate names. does bzr use pyunit or its own test framework. maybe such a thing can be an error? [06:58] as the number of tests go up (51 in this case) we can end up with duplicates. [07:05] parthm: python itself does the compilation [07:05] moin lifeless [07:05] parthm: and its at that stage that you'd want to catch it. [07:05] hi jelmer [07:06] parthm: we use a derivative of pyunit [07:08] lifeless: ok. thanks. i will need to be more careful with the names :-) [07:19] hi all ! [07:20] hai [07:20] hey Vincent [07:20] so, lost+found :) [07:41] EODing [07:42] lifeless: have a nice evening [08:14] where are the API docs? [08:15] p.c.c/~mwhudson [08:23] * vila @dentist [08:44] * igc dinner [09:41] * vila back [10:01] vila: so, lost + found? [10:02] lifeless: hehe, not yet on the top of my TODO graph but I'm targeting the related tests in test_conflicts already [10:03] lifeless: I will also start implementing the basic feature so I can *then* plug it in the right places [10:04] basic feature: moving an unversioned file in some trash with a bare-bones handling and how it was called and when it was trashed (to address the likely collisions) [10:08] lifeless: does a '_trash' method on the wt sounds fine ? (AIUI we need it only for unversioned files right ?) [10:09] vila: lost_and_found please, trash is explicitly discarded [10:11] trash (or recycle bin) are more mainstream than lost_and_found IMHO, besides, what is 'lost' in our case ? (found as 'found' in bzr way can fly but requires a bit of explanation [10:12] they are diferent concepts [10:12] I don't see how one can be a mainstream version of the other [10:13] well, to me, lost+found in the unix way to store... 'garbage' found when errors occurred at the fs level, I don't clearly the connection here, [10:13] I'm fine with not using trash, so maybe 'quarantined' or something ? [10:14] err [10:14] well, to me, lost+found *is* the unix way to store... 'garbage' found when errors occurred at the fs level, I don't clearly *see* the connection here, [10:16] i dont like to think of my files as garbage >.> [10:17] Kamping_Kaiser: well, we are talking about files like .pyc, .o etc, as far as versioning is concerned, how would you like them to be called ? [10:18] vila: i was refering more to your comment 'lost+found *is* the unix way to store... 'garbage'' [10:19] * Kamping_Kaiser heads off [10:19] Kamping_Kaiser: ha, right, well, the ellipsis was intended to carry my lack of precise wording here :) My experience is that the files or directories found in lost_found are not always in good shape :0 [10:20] vila: so, lost+found in ext* fs's caries files that the filesystem has recovered because they no longer had a directory to belong in. [10:20] vila: the connection is that lost+found in a bzr tree would carry files that bzr no longer has a directory to put them in. [10:20] lifeless: wow, yeah in that case there is a 1-1 match, but who knoes that ? [10:20] orphans ? [10:21] no value judgement is made about the files - they might be databases or temp files - we don't know [10:21] 'trash' is a value judgement [10:21] I got that [10:21] orphans would be fine [10:21] recovered [10:21] lost + found would be bad because folk that do know what it is might think their file system is insane if bzr makes such a dir ;) [10:22] recovered is slightly misleading as there aren't lost today :) [10:23] recoverable ? [10:23] uhm [10:23] I don't get what you mean [10:23] anyway, I'll outlight all this naming issues in my proposal so we can find a consensus [10:23] *foo*-able would imply some way that the user can *foo* files. [10:23] yes, that's the idea [10:24] foo-ed or foo-s implies that bzr has done foo for the user, and they can now decide what do to. [10:24] I don;t intend to propose commands for that but at least a naming scheme that allows once to find back these files [10:24] s/once/one/ [10:25] there will be cases where an unknwon file was really a not-yet-added but precious file [10:26] but the general case should be that the user can cleanup all of them on a regular basis [10:27] indeed [10:27] I don't really like recoverable [10:27] can't articulate why [10:27] recovered I could cope with [10:27] or orphans [10:27] oh, I suggest a bzr- prefix [10:28] bzr-recovered [10:28] bzr-orphans [10:28] then I'll start with orphans [10:28] you mean in as a first-level directory in the wt ? [10:28] I thought it will be in .bzr/checkout... but no strong feeling, [10:29] I'm still unclear about how the user should restore from there... [10:30] ...and how to avoid the content growing out of control if it's not noticed... [10:33] vila: I don't think we should hide it [10:33] it should be in-your-face if this happens, but not in-your-way [10:33] and yes, I mean a sibling of .bzr [10:34] hmm [10:35] That makes sense. At least for me, I can imagine I will promptly delete it as soon as I discover it... [10:35] after a quick content check of course [10:36] exactly [10:37] So that raises the question of the content naming, reproducing the full relpaths (with some anti-collision scheme added) doesn't look very good, using fully random names requires some way to translate back to a (date, relpath) [10:37] the later requires an additional command (or two) [10:38] namely: list, recover [10:39] vila: huh, using the full relpath is great. [10:39] lifeless: not if you have tenths or hundreds of them [10:39] uhm [10:39] I think you're over designing [10:39] we expect folk to clean this up regularly and promptly. [10:39] and I'm a bit concerned about max-length paths [10:40] we can merge the directories [10:40] and we only add len(bzr-orphans) to the max length [10:41] I was thinking about adding yyyymmdd-hhmmss stamps [10:41] but if folks clean it regularly, that may be useless [10:41] so don't do that [10:41] thats ugly [10:42] it would stop people trivially moving them back into place [10:42] and the files will have a mtime of their own already if we don't break it [10:42] well, they can't move them back normally since that's why the files end up here in the first place [10:42] sure they can [10:42] Might be good to add an incrementing number to the end of the first directory in the relpath, like with backup.bzr. [10:42] yeah, mtime, good point [10:42] (Or similar to it, anyway; I don't remember exactly how backup.bzr works.) [10:43] we delete the directory - but now we'll preserve the directory in this tree [10:43] lastly [10:43] lifeless: right, but AIUI that's why the merge can't complete successfully [10:44] I think it might be fine to just overwrite existing files in this dir: if the user has the same precise file generated + not versioned twice, then they very likely are autogenerating it [10:45] or re-create it in which case the last one is as good as the previous one [10:45] yeah, that's certainly sounds like a good first implementation anyway, I'll go that route === gerard_1 is now known as gerard_ === mrevell is now known as mrevell-lunch [13:55] Is there an export function that could upload version controlled files up to another location but didn't write any .bzr (et al) files? [13:56] Oli``: "bzr export" or the bzr-upload plugin if it's remote. [13:57] Peng: doh - thank you === mrevell-lunch is now known as mrevell === Kilroo1 is now known as Kilroo [15:25] hi [15:26] I got these errors when trying to use --lsprof-file: http://paste.ubuntu.com/395662/ [15:33] jml: Try 'bzr --lsprof-file grep.callgrind' instead of using an =. Maybe it will like that. [15:33] Peng: ahh yes, it does. thanks [15:34] Global options use really basic parsing. It's like 5 'if' statements. [15:34] No optparse or anything./ [15:38] Peng: good to know, thanks. === salgado is now known as salgado-lunch === IslandUsurper is now known as IslandUsurperAFK === deryck is now known as deryck[lunch] [16:17] hello everybody :) [16:18] I'm a bzr newbie... and I have some silly questions to ask... anyone interested in humouring me? [16:18] fire away [16:18] that's what the channel is for ;) [16:19] awesome. [16:19] so, I use svn, and am trying out bzr for the first time [16:19] whenever I delete a folder in svn, svn treats it as being accidentally deleted, and recreated it on the next update [16:20] in bazaar, it treats it as being removed from versioning [16:20] is that correct? [16:20] if you mean bzr rm filename then yes. [16:20] nope... [16:20] it will remove it from versioning [16:20] just "rm filename" [16:20] when I run bzr status, it reports it as "removed" [16:20] gotcha. [16:20] is this just a byproduct of using bzr-svn? [16:21] I could be wrong, but IIRC anything "removed" from the repo is automatically detected by bzr as removed from versioning. [16:21] this can be reversed [16:22] if you are using bzr with as SVN repo, I'm not entirely sure, but others here are bigger experts with bzr-svn than I am [16:22] right.. I thought so [16:22] I'm in the process of uploading my code to launchpad anyway, so I probably won't have to use bzr-svn for too long... === bac` is now known as bac [16:24] btw that wasn't a stupid newbie question ;) [16:24] sorry i couldn't answer it with more authority :( [16:26] haha... sorry [16:26] I guess you were expecting something more along the lines of "what's a checkout?!" [16:27] okay, then, answer me this [16:27] trunks are branches, yes? [16:27] then... branches are not trunks? [16:27] the trunk* [16:28] haha [16:28] best way to look at it is a trunk is just the central focus on where the development will take place [16:29] every branch is a copy of that trunk [16:29] so you have a branch on your computer, the "branch" you make as your focus/target for others to develop to is the "trunk" [16:30] and the trunk is the one hosted on a central server (arbitrarily determined) for others to checkout/branch from? [16:30] i.e. Launchpad? [16:30] most of the time yes. For our purposes in this example that is exactly correct === beuno is now known as beuno-lunch [16:31] any branch can be a trunk. in distrubited version control like bzr "trunk" is more of a social thing than a technical difference [16:31] okay... [16:32] so when I "pushed" my code onto launchpad... and it called it a branch (both on my computer and on LP)... that's fine? [16:32] yes [16:32] even if the branch is named "trunk"? [16:32] correct [16:32] this is all very confusing. :P [16:32] I see. [16:32] it gets better once you use it a little more [16:32] I sure hope so, heh. [16:33] bzr makes not technical distinctions between branches and trunks. Most people make the distinction themselves by naming a branch "trunk" like you did. [16:33] I see, that makes sense. [16:34] LP also helps because you can make the specific branch as the "focus of development" [16:34] this tells other LP users that "trunk" is the one to branch from [16:34] right [16:35] okay, next... [16:35] ready [16:36] in my app, I have a check in index.php to see if ../install is present. If so, it halts the script and tells the user to go to the install script. Makes sense, I hope. [16:36] once the install script finishes, the user is instructed to delete the /install folder. [16:36] got the idea from mediawiki, I think... [16:36] ok, I'm following so far [16:37] anyways, if the user maintained their program using bzr, then wouldn't bzr automatically recreate ../install every time? [16:37] basically, I'm asking, the way I designed my program, is it "anti-bzr"? :P [16:37] I don't mind having to rely on .tar.gz releases, I'm just wondering. [16:38] well, two things to think about with that issue. 1) bzr isn't really designed for distribution of the final product, but most people work around that. [16:38] okay, that's what I thought... [16:39] 2) there are ways around it but it could require some work from either you or your "customers" [16:39] one way I would think about doing it is having a "trunk" for development [16:39] and having a "distrubtion" branch [16:40] in the distribution branch you pull from the trunk and delete the install directory [16:40] that way when people update from the dist branch they dont' get a new install dir every time [16:40] kareeser: to workaround that, suppossing that newer versions never need reinstalling, use a .installed file or similar, instead of removing your dir, bzr will ignore that file [16:40] and if development continues in trunk, then distribution is updated periodically? [16:41] (just an idea) [16:41] abeaumont, elegant, I like it. [16:41] kareeser: yes, but you'd have to do that manually [16:42] but I think abeaumont's idea is better than mine [16:43] hm.. [16:43] okay, thanks rubbs, abeaumont, for your help :) [16:43] A+. [16:43] np. [16:43] you're welcome :) [16:44] come back and ask more questions if you have any. most of the time someone knows where to look if they don't know the answer outright. [16:49] I only ask, because I do development on three computers, one of which is the actual implementation (with real data) [16:49] and with bzr being unfamiliar, I'm afraid I'll accidentally delete the repository with a stray rm command ;) === salgado-lunch is now known as salgado === IslandUsurperAFK is now known as IslandUsurper === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck [17:19] I have some files I need version controlled with filenames that match bzr's default ignore rules. How can I get bzr to not use its default ignore rules? [17:20] dolphinling_: I might not remember this right, but there should be a global config file you can edit. What system are you using? [17:21] er Operating system I meant [17:21] gentoo linux [17:22] k... just as sec. I'm going to check before I tell you the wrong thing ;) [17:23] All right, I'm searching through system dirs to see if I can find this file [17:25] rubbs: heh, I found it, it's ~/.bazaar/ignore [17:25] ah, ok, sorry [17:25] I thought there was a global one too [17:25] but I could be wrong [17:26] This is fine for me. [17:26] I wish there were some way to just override it rather than editing it, but oh well. [17:27] dolphinling_: I'm sure there probably is, I'm just not remembering it right now [17:38] dolphinling_, you should be able to just bzr add specific_filename [17:39] of course, that's only useful if you have only a few of those files to unignore [17:39] 2.1 and later have support for negative ignore patterns. [17:40] It's definitely better to not edit the builtin ignore if at all possible. That tends to have unpleasant knockon effects down the line. [17:42] I have a website that I've been updating with bzr-upload, but I've recently gotten shell access. Is there a clean way to convert that folder into a branch without having to reconstruct all of those files again? [17:47] maybe I should say, without having lots of conflicts that would disrupt the working of the site [17:47] I don't know, but I doubt it. [17:47] I can think of some unclean ways that might work. [17:48] I've thought about making a new branch, doing one commit, and then pull --overwrite [17:48] if the file content is the same, no one outside should notice... [17:49] If what you've uploaded is exactly what's in the branch, you could try making a throwaway branch somewhere, transplanting its .bzr/ over to the location, and seeing what 'stat' etc have to say. [17:51] yeah. but I've read that Bzr compares file IDs first, and those will probably be different, especially for the directories [17:51] How? The existing files from upload don't really ahve id's. [17:51] ID's are an internal bzr thing, they don't exist in the filesystem. [17:51] hmm. ok [17:52] I'll give that a shot then [17:52] hi folks. i have a question about bzr-pipeline. is it known/expected that renaming the top-level directory breaks the pipelines? [17:52] barry: Absolute paths used in cross-references? [17:58] fullermd: dunno. it was weird though. when i moved the dir back to its original name, the pipes below it showed up again (phew! :) === radoe_ is now known as radoe === mwhudson_ is now known as mwhudson === salgado is now known as salgado-afk [19:16] jelmer: ping? [19:30] another inconsistent sha bug :( https://code.edge.launchpad.net/~vcs-imports/fetchmail/master [19:34] I am having problems with bzr unshelve - i just get a dump of bzr metadata with the following error at the top [19:34] bzr: ERROR: The file id "workflow.html.erb-20100305150443-x3ac2am7beykb5dz-1" is not present in the tree [19:36] https://bugs.launchpad.net/bzr/+bug/253806 is the problem I am having [19:36] Launchpad bug 253806 in bzr "bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree" [Medium,Fix released] [19:36] ubottu: any idea what release? [19:36] Error: I am only a bot, please don't think I'm intelligent :) [19:36] 1.13 it looks like [19:37] sigh - way to fail the reverse turing test [19:37] * rbriggsatuiowa heads off to try a newer version of bzr === airfoil is now known as coldswitch === coldswitch is now known as airfoil === airfoil is now known as coldswitch [20:31] mwhudson, looking [20:31] jelmer: i filed a bug btw [20:36] mwhudson, ah, merci [20:42] hello. for bzr-grep, i am seeing UnicodeDecodeError while printing the output. whats the recommended way to handle this? http://pastebin.com/x7TLnMAV [20:46] jelmer: the question of the uber-slow kernel import came up again in the stand up [20:46] jelmer: do you know why it's as slow as it is? [20:47] mwhudson, one part of it is the indexes [20:48] oh, the using bzr indexes thing? [20:49] mwhudson, s/indexes/cache/ [20:49] mwhudson, yeah [20:49] mwhudson, that's about 25% I suspect; not sure how the other part could be optimized, we'd have to do performance analysis first [20:50] jelmer: do you have any idea why the kernel is so much slower than everything else? [20:50] just because it's a really big tree? [20:51] mwhudson, yeah, the size of the tree [21:16] jelmer_: https://code.edge.launchpad.net/~vcs-imports/iso-codes/master failed in the same way :( [21:28] how do i slve this? bzr commit bzr: ERROR: Could not acquire lock "/home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailab [21:28] *solve [21:39] lifeless: ayt? [21:44] hai [21:44] ubuntujenkins: is that a fuse mount or something? [21:44] kfogel: hai [21:45] I did a bzr commit and exited badly which caused it. [21:46] lifeless: hey, so I'm trying to test out some of your recommendations for bzr+ssh in the proposed savannah.gnu.org setup. If you have some time, I'd love your help -- I think I'm stumbling on perhaps basic ssh configuration issues. [21:46] ok [21:46] shoot [21:47] ubuntujenkins: what does fuser /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate show? [21:47] lifeless: so I'm testing out your first recommendation: (one sec, I'll paste) [21:47]