[00:02] poolie: may I join the call? [00:02] yes [00:02] just fiddling with linux audio :/ [00:02] ahh :) [00:03] That's an endless source of joy. [00:04] * jml finds a bzr bug [00:04] http://paste.ubuntu.com/47016/ [00:24] jml: is it normal that it takes almost a minute to authenticate to bazaar.staging.launchpad.net? [00:24] sadly, yes :/ [00:25] spiv: there's a graph of auth times available internally [00:27] so what's the deal with KeyError? [00:28] so hey guys, someone said a while back, and i know i ask once in a while about this because i don't have latest bzr and haven't started using, but there is a semi-equivalent to svn:externals in bzr being worked on, or maybe in 1.6, but i can't find it in docs or anywhere.. [00:28] jml: https://bugs.edge.launchpad.net/bzr/+bug/208869 [00:28] Launchpad bug 208869 in bzr "info -v fails over bzr+ssh" [High,Confirmed] [00:28] oh. fun. [00:28] i have access to an ubuntu intrepid box with 1.6 now so want to plan to use that feature if possible.. [00:29] jml, i wish it was faster to put tags on bugs [00:29] justizin: its not baked yet unfortunately; the feature is called nested trees, and LarstiQ has a bzr branch on launchpad with it [00:30] poolie: me too. [00:30] poolie: we might actually make it so over the next couple of months. [00:30] i'd love to help test, i make heavy use of svn externals and have replaced it for now with a bash script in my bzr repo that just fetches the contents of EXTERNALS.txt, but i'm looking to mirror all our svn dependencies in bzr so that i can hand-merge upstream changes, be aware, etc.. and get off svn. [00:30] poolie: is there a "this shows users a stack trace zomg fix it now" tag? [00:31] for bzr? [00:31] it's a handy feature but bzr's list tips the scales pretty heavily away from it either way [00:31] not really [00:31] just set importance=zomg [00:31] it is a one-liner to fetch the externals, and i'm soon going to just use bzr to fetch either bzr or svn externals, and make our file contain svn+http urls [00:33] lifeless: I'll try to find the branch in lp :) [00:33] jml: lots of things show stack traces; its not a great metric for how many users it affects [00:33] lifeless: do you know anything about the feature's current design? [00:33] jml: we try to set importance by normalising frequency and impact [00:33] is it like a shared repo? [00:34] justizin: not really, shared repos just optimise storage [00:34] brb [00:34] well, i mean, i guess a better formed question would be, does it use a shared repo, or similar func, to optimize storage.. [00:34] lifeless: sure. It's something dear to me because I've had reports from friends who show off bzr to *their* friends and then get all embarrassed because of stack traces. [00:38] jml: is it the branch-history one? wtf is branch-history anyhow :P [00:38] lifeless: it's https://bugs.edge.launchpad.net/bzr/+bug/208869 — info -v fails over bzr+ssh [00:38] Launchpad bug 208869 in bzr "info -v fails over bzr+ssh" [High,Confirmed] [00:39] oh look, ubottu doesn't suck :) [00:42] poolie: I get this with your branch: http://paste.ubuntu.com/47029/ [00:43] * jml tries a couple of things to ensure not pebkac [00:49] yeah, looks like a bug. [01:11] jml, interesting [01:11] thanks [01:14] poolie: np [01:20] spiv: ping [01:25] poolie: ping [01:26] lifeless: pong [01:27] lifeless, hi [01:29] spiv: is the hash for a char-converted-to-int the same as a 1-length string containing the same char (for dict lookups from C python) [01:29] lifeless: I don't know, I'd guess not. It's certainly not guaranteed. [01:30] pyrex FTL then :P [01:30] Yep, definitely different. [01:30] it translated _minikind_to_kind[minikind] to _minikind_to_kind[PyLongInt_FromInt(minikind)] [01:31] when I made minikind into a cdef char, rather than a python string [01:31] lifeless, was that all you wanted? [01:31] poolie: yeah, echannel :P [01:31] intrepid wants to reboot now, biab [01:31] lifeless: Hmm, maybe pyrex things _minikind_to_kind is a C array rather than a dict, or something? [01:32] Oh, except obviously not if it's doing PyLongInt_FromInt. [01:32] Anyway, that does seem badly broken :) [01:33] lifeless: python -c "for i in range(256): print i, hash(i), hash(chr(i))", btw :) [01:37] spiv: yeah, I wasn't going to list all the C Python API calls to do the dict lookup [01:37] I was just showing the key 'oops' moment [01:44] 2.4 seconds now [01:44] oh, thats by cheating. doh. [01:46] :) [01:48] ok, thats annoying [01:48] we put every dir into a dict during st [01:48] if there are no renames, epic fail. === kiko is now known as kiko-zzz [02:56] spiv: is there a constant value for True and False in CPYthon ? [02:56] Py_True [03:00] I would like to make a branch using make_branch that has a stackable branch format and a non-stackable repo format. [03:00] what's the easiest way of doing this? [03:00] jml: heh [03:01] jml: take a look at the mail I *just* sent to the bazaar@ list [03:01] I saw :) [03:01] slightly different though. [03:01] jml: TestCaseWithMemoryTransport.make_branch unfortunately ignores shared repos. [03:01] spiv: I don't need shared repos, just a non-standard branch/repo format pair [03:02] And doesn't give you any way to specify non-standard format groupings. [03:02] :) [03:02] I suppose you could register a new format in the bzrlib.bzrdir.format_registry [03:03] I'll just steal code I have elsewhere that does what I want (but doesn't use make_branch) [03:03] But simplest is probably to instantiate a custom BzrMetaFormat1 and set the *_format attributes appropriately [03:05] *nod* === mlh_ is now known as mlh [03:35] lifeless, ping? [03:36] i want to run something past you re bug 261315 [03:36] Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 [03:36] either before or after lunch [03:36] that is basically, is it reasonable for the RemoteBranch to get the branch.conf file and interpret it itself to extract the fallback url, rather than relying on the server to do this? [03:36] i think it is [03:47] poolie: you mean via VFS calls? [03:47] poolie: or delegated to _real_branch? [03:48] poolie: accessing branch.conf from RemoteBranch, directly, would be unreasonable - abstraction violation IMO [04:25] re branch.conf [04:25] it kind of is [04:26] otoh i'm not sure why it's exposed by an rpc if the client is not supposed to read it directly [04:26] maybe this is a spurious historical reason [04:26] err [04:26] you've lost me [04:26] simple thought experiment, imagine the branch at the other end is a bzr svn branch [04:26] or a BzrBranch5 [04:27] neither of which have branch.conf [04:27] sure, that's just the case i'm thinking of [04:27] an rpc can abstract that [04:27] without the client having the format's code locally [04:30] my point is it's odd that RemoteBranch supplies a get_config() method [04:30] well [04:30] why is that odd? [04:31] arguably that can represent the configuration file as any object [04:31] SvnBranch supplies such a method, and so does Branch5 [04:32] i meant to say Branch.get_config_file, [04:33] and it's no longer called, i removed it a while ago iirc [04:33] so that's ok [04:43] spiv, ping? [04:44] my current plan for this is then [04:44] first off, read it through the real branch at RemoteBranch construction time [04:44] this is unfortunately going to cause all branches to do vfs operations [04:44] but we need to do this to work with older servers [04:45] poolie: pong [04:45] then, add an rpc that gets all the information we need when opening a branch: repository location, last revision, stacking, etc [04:45] probably called Branch.open_v3 or something [04:46] then change the client to call this, and only if the server fails go back to using the vfs [04:46] That sounds good to me. [04:46] so the fact that we have to be able to do it over vfs suggests i should get that going first [04:47] if we do that second stage we will save some roundtrips when opening a branch [04:47] but we need to think a bit about where to cache it [04:47] the straightforward thing would be to just naively cache it in the RemoteBranch object indefinitely [04:47] however, the general approach aaiu is that caching should be scoped by locks [04:48] How do non-remote branches handle caching of stacking info/ [04:48] ? [04:48] so then there seem to be a few options [04:48] apparently they don't cache it [04:49] heh, nice question :) [04:49] so, the stacking info does not particularly need to be cache because it's normally only used from the constructor to open the repository [04:49] caching it would not be particularly important for performance [04:50] and if we can arrange to make this open_v3 call from the constructor or nearby we would not need to call it either [04:50] i guess i was thinking more about putting other things like the last_revision into the same call [04:51] where it both would be important to call it and also it's quite likely to change [04:51] Hmm, last revision info is currently cached, and that cache's lifetime is managed by locks. [04:52] Possibly what's missing is an open-and-immediately-read-lock operation? [04:52] um, also, if the only higher-level rpc that reads the stacking location is the open_v3 one, then presumably it needs to be cached for commands like info that might ask for it later [04:53] this does seem related to creating objects locked [04:53] both on disk when we start writing to them and also in the api [04:53] Right. [04:54] spiv, how is the lifetime managed by a lock? [04:55] afaics it isn't [04:55] See BzrBranch.unlock [04:55] It calls _clear_cached_state [04:56] RemoteBranch also calls _clear_cached_state on unlock. [04:57] ah [04:57] right [04:57] i was mislead a bit by the lack of a call to the super constructor, but there is a comment saying why [04:57] though it's still a bit tasteless [05:01] so it would be a bit dodgy but we could cache it there from the constructor and it would last until the object is first unlocked [05:01] uhm [05:02] thats lots dodgy [05:02] if you want an idiom for open-locked, do that as a separate branch IMO, possibly lots of things that can break [05:03] sure [05:04] so if we don't do that, it seems necessary to add a specific fine-grained api to get the stacked location [05:04] this could be done in addition to putting it in the constructor [05:05] i guess we need one to set it so it's not unreasonably increasing the number of available apis. [05:06] didn't jml put up a branch to allow getting stacked location from the branch format object? [05:07] lifeless: it was rejected. [05:07] we do have api's for settings and getting the location already [05:07] the problem for me was that I needed a Branch object to use BranchConfig [05:12] * poolie reads [05:18] ok, i read that thread [05:20] in the end, I used something close to the original patch. [05:22] used meaning it was merged to bzr.dev? [05:22] or used in an external patch? [05:23] lifeless, sure, i'm just wondering how those apis should be implemented on RemoteBranch [05:23] or rather, how to most cleanly get my implementation of it to pass the existing test_remote tests [05:23] spiv, re those tests we were looking at on friday [05:24] poolie: used as in "wrote a standalone function that did the same thing" [05:25] poolie: https://pastebin.canonical.com/9155/ if you are interested. [05:25] I think it's useful for tests if merely constructing a RemoteBranch doesn't trigger an RPC. [05:28] spiv, that's the heart of the problem here [05:32] A possibility would be to add an optional fallback_urls= param to RemoteBranch.__init__. [05:32] and do it from the RemoteBranchFormat [05:32] that's true [05:32] but, if we find we need to do it through the real_branch, then what... [05:32] The existing test_remote tests would just pass fallback_urls=[], and for now the real code can not pass it. [05:33] And when not passed RemoteBranch could then fallback to using real_branch. [05:45] hm [05:45] so i can see how that's handy if you just want to test some other aspect [05:45] of the class [05:45] on the other hand it seems a bit like cheating [05:58] poolie: it's a bit weird to me that opening a branch mutates the repository object, which potentially belongs to other branches too. [05:59] poolie: (i.e. by adding the fallbacks) [06:02] that's true [06:02] but, that's the api [06:02] Yeah. [06:03] it's kind of related to being able to get the repository either from the bzrdir or the branch [06:03] and now you get different behaviour [06:03] um [06:03] there are some other possible paths as far as asking the Repository class method or format object too [06:03] it should be more clear which one is primary [06:10] could someone with linux try this - valgrind --tool=callgrind python2.5 bzr st bzr.dev [06:10] spiv: it was a tradeoff [06:11] spiv: having a arbitrarily large list of fallbacks is intrinsic to a shared repo with stacking [06:11] spiv: having the branch maintain the state allows restricting that scope to just the repository instances that need to know about it [06:12] lifeless: you say "the branch maintain the state", but they state is kept on the repo afaict? [06:13] lifeless: I guess my naive expectation would be that stacked_branch.repository would be a FallbackRepository(real_repo, *fallback_urls) rather than having the branch mutate the repo. [06:13] I haven't spent much time thinking about this, though :) [06:14] spiv: the disk state is in the branch [06:15] spiv: reconcile needs to be able to work with all branch's fallback repos at once [06:15] lifeless: I've run that valgrind command, what output do you want? [06:16] jml: did it fail with 'cannot allocate memory' ? [06:16] lifeless: nope. [06:16] ok [06:16] that's using bzr.dev built for py2.5 [06:17] spiv, the thing is that the repo implementation might want to know about how they're stacked [06:17] rather than it just being a composite object [06:17] um [06:17] jml: thanks [06:17] it might be cleaner though to unambiguously give the branch responsibility for opening the repo [06:17] if it has the knowledge how to do so [06:18] by comparison, git has a single repo instance with a list of 'alternates', and hg just writes nulls for parents at the edge of the stacking boundary [06:21] could it be a security problem for the server to give arbitrary urls back to the client? [06:22] yes, if they are trusted [06:22] but that applies to normal content and hooks too [06:22] so I don't think they are any more special than reading a file from a http server [06:23] mm [06:49] it seems like it'd be good for test_smart to start its test with the tuple-like request it wants to test [06:50] so it can also check the right thing gets called [06:50] rather than starting with the Request class that's going to ultimately run... [06:55] hm [06:55] it's not really easily accessible though [07:07] Good morning Bazaar [07:07] morning [07:08] hi vila [07:13] hello vila [07:20] i got an odd error when upgrading a shared repository with a bzr-svn branch in it: [07:20] bzr: ERROR: No such file: ('3@fc50161f-d74b-0410-97f1-43881e8fa688:parser%2Ftrunk:templates', 'svn-v3-trunk1:fc50161f-d74b-0410-97f1-43881e8fa688:parser%2Ftrunk:18') [07:24] jelmer: ^ see chandlerc's upgrade problem [07:26] poolie: have you seen David Ingamells' stacking problem on the mailing list? [07:26] no [07:27] poolie: https://lists.ubuntu.com/archives/bazaar/2008q3/047516.html is the most recent post in the thread [07:27] ok, yes [07:28] spiv, what about it? [07:29] Just that you are somewhat likely to know if it's a already known issue or not. [07:30] it's not totally surprising to me, but i don't specifically know what it is [07:30] i.e. you're probably best placed to reply and say "yes, that's bug #NNN" or "that's a problem, please file a new bug report". [07:30] not off hand [07:30] i'd have to try to reproduce it [07:30] so, (B) [07:31] it would be nice if we could just say "expose this as an rpc" rather than declaring each one as a custom class [07:31] i guess there's no strong reason why we can't? [07:31] like it would probably fit into the registry format [07:32] poolie: for RPCs with simple arguments and return values? [07:32] yeah [07:32] at least to start with [07:34] i'm going to put the fallback repositories into the real_repository fallback, as well as the remote one [07:34] Or rather than changing the registry, you could perhaps have a helper to construct a SmartServerRequest* subclass for you, and then register that. [07:34] exactly [07:34] or even just an instance [07:34] well, archetype or something [07:35] spiv, i wouldn't be totally surprised if this current branch fixes it but i'm not sure it will [07:35] I needs to be a class, or object factory of some sort, I think. [07:35] poolie: yeah. That's what I thought about my last fix, though ;) [07:35] ^^ which "that"? [07:36] "i wouldn't be totally surprised if this current branch fixes it but i'm not sure it will" [07:36] heh [07:50] spiv: regarding but #269535, could you make a quick review of lp:~vila/bzr/py26bzr revno 2940 ? It fixes a lot of python-2.6 failures and errors but makes bzrlib.tests.test_fetch.TestHttpFetch.test_weaves_are_retrieved_once fails. [07:51] Which is a bit puzzling... [07:52] spiv: I'm not asking for a true review, just a look and feedback, it may need more polish (I'm just trying to make it work for now) [07:52] vila: ok [07:53] spiv: thanks [07:57] * AfC would just like to say that he is finding bzr fast today. [07:57] Take THAT all you whingers. [07:59] AfC: :) [08:00] AfC: 1.7x? [08:02] gour: don't be ridiculous; 1.6.1. [08:02] Running released software == sanity. [08:02] ok, ok...nice to hear [08:02] [Unless of course it's a project you're hacking on. Then of course you run upstream from source. [08:03] Which reminds me of something I was chatting about with Rusty one day... I was observing that I had just done a release of my project, and didn't feel terribly enlightened or uplifted as a result. [08:03] After all, *I* don't need to do a release to use my code. We just need everyone _else_ in the software universe to release _their_ code so we can use it :) :)] [08:04] lol [08:05] (I first thought of this when I'd get "congratulations on your release" type emails from colleagues, when all doing a release was good for was a lot of time consumed away from time spent on hacking ... and bug reports for OSes I don't use and for situations that were all WORKSFORME) [08:06] vila: wow that's a lot of changes! [08:07] "everybody is thinking about himself/herself, only I think..." [08:07] don't look at the whole ! Just diff -c 2940 ! [08:07] (made me realize just how big a burden doing releases really is. Its not only work. It's also psychological pain and distraction ... just so other people can use your work and not pay your anything. Reminds you just how much we owe people who offer their work as Open Source and promote Software Freedom). [08:07] vila: sure :) [08:07] I'm not sure all changes in that branch are still needed, but since that was an early attempt to be compatible with python-2.6 I didn't re-start from scratch [08:08] but if your remark was about: "what is needed to be compatible with 2.6" then, yes, it's not as trivial as one may hope ;-/ [08:09] AfC: just consider eternal glory people are using your software [08:09] vila: bzr will soon jump to 2.6 bandwagon? [08:09] vila: yeah, that's what my remark was [08:09] gour: no, we'll still support 2.4 for quite a while I think [08:10] gour: no, I'm looking at what is needed, I don't think we want to rush [08:10] thanks [08:10] gour: (and 2.5). But we want to work with 2.6 as well. [08:10] * gour wonders who will use 3.0 then [08:10] vila: so at a glance the changes in 2940 look nice. Interesting that it causes that test to fail. [08:11] vila == puzzled, spiv == interested :D [08:12] spiv: I don't really like passing transport at medium construction time, it may be enough to provide it at request time [08:12] but that's the make it right part ;) [08:13] spiv, did we ever settle something about systematically marshalling all/most errors across hpss? [08:13] vila: so for some reason it's reprobing for a smart server [08:13] afc, that's good to hear [08:13] poolie: somewhat [08:14] poolie: bzrlib/remote.py now has a _translate_error helper. [08:14] i saw [08:14] i guess i meant, on the server side, it's be nice to let the do() method just pass the error up and have it automatically sent [08:15] * vila thinks that the smart probes are itching more and more.... redirection bugs, now that :-/ [08:16] spiv: That's why I asked for feedback, I'm wondering if my patch is in the right direction or is foobaring some "ok, I have already probed, no need for more" [08:16] poolie: so there's a single place to handle the unmarshalling now, and it deals with the "this exception needs an other_branch param" problem. On the server side I think it's enough to make _call_converting_errors smarter. [08:23] vila: I think it's the right direction [08:23] ok [08:24] vila: so the reason it fails is that SmartClientMedium is the thing that remembers if there's been a protocol error or not [08:25] vila: and now we are making new SmartClientMedia rather than re-using them. [08:25] vila: bug 246880 [08:25] Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 [08:25] vila: probably the thing to do is keep the medium in the _shared_connection object, so there's one instance per connection. [08:25] spiv: Haaaaa ! Thks [08:25] vila: rather than making a new one for each get_smart_medium call [08:25] vila: please poke now at my fixed branch and script so you can see what I've done [08:26] vila: as the EU guys come online, I won't be around to answer questions shortly [08:26] spiv: so it should not keep a transport instance [08:26] vila: we still have code changes to make vis-a-vis the bug, but the casper branch should be done [08:26] vila: (search for _protocol_version_error inside SmartClientMedium to see where/how this state is tracked) [08:26] lifeless: ok, switching to it right now so that *I* can ask questions :) [08:27] spiv: sure, now that you mention that, it should be easy [08:54] lifeless: http://paste.ubuntu.com/47101/ [08:55] when trying your script on cp -R casper.backup casper [08:56] Your script is intended to produce a 'cleaned' branch from a 'casper' branch, the later being broken, right ? [09:00] vila: you shouldn't need to run it though, I uploaded a fixed branch [09:00] I downloaded it, your script runs ok on it :D [09:01] I thought your script was intended to be used by people having broken branches [09:01] lifeless: what should be done with your clean branch ? push --overwrite it to lp:~ubuntu-core-dev/casper/trunk ? [09:02] and from there everybody should re-clone ? [09:02] should we go private from here to avoid spamming this channel ? [09:02] here is fine [09:02] but i think he's signed off [09:03] vila: something like that [09:04] vila: that error is a local repo error in whatever branch you tried it on [09:05] my script assumes a 'working but cannot clone' branch [09:05] lifeless: ok, I may have played too much, I'll retry with a less broken one [09:14] so, starting again with the casper.backup from http://people.ubuntu.com/~cjwatson/tmp/casper-wreckage.tar.gz, your script works [09:15] lifeless: I won't pretend I understand everything that is going on nor that I can go further, but I think I can help them get back a clean branch [09:16] lifeless: that's what you're expecting from me right ? [09:55] vila: well, ideally they grab my cleaned branch [09:55] vila: and you help them become users of that branch, and its all good [09:55] lifeless: ok [10:31] morning folks... just looking for advice on an easier way to do something [10:31] I keep coming across a similar problem.. I organised a directory of files under source control by creating subdirectories and moving the file in there [10:33] Previously I've resolved this with bzr after the fact by doing a series of bzr move --after file1 /newdir/file1 [10:34] Trouble is, if the directory is new, it complains there about it not being controlled, so I have to do bzr add newdir, but this then adds all the files in that new directory.. so I have to then remove each one before issuing the move --after command [10:34] Is there an easier way to do this? [10:34] It's bad enough that on windows the files are listed in bzr st with "/" when windows won't accept that so you can't even copy and paste to speed things up :) [10:35] VSpike: "bzr add --no-recurse newdir" would help you I think [10:35] That will add newdir without adding the files underneath it [10:36] spiv: ah was hoping there was something like that :) [10:36] vila: may need LOSA help to zap the existing branches [10:36] jml: could you draft a _real quick_ mail to vila about what it would take to zap the existing corrupt branches of casper, for LOSA's to execute ? [10:37] jml: (you know the details I'd have to say 'look up' on) [10:38] casper's a project on Launchpad? [10:38] jml: yes [10:38] jml: its a package whose source is managed in bzr [10:38] jml: I'm not sure what product the branches are attached to [10:39] * vila would really like to know the expansion of LOSA... [10:39] some are not on LP but are mirrored - the 'remirror now' button discussed previously would suite those branches, others are hosted on LP [10:39] vila: Launchpad/Landscape Operation System Administrator [10:40] ok, I was close with my Launchpad Overlord System Admins, but no cigar :) [11:14] my bzr login id would be just gnomefreak? [11:15] nope guess not [11:16] vila: hey, so I'm looking through lifeless' work on bug 246880, and I understand he briefed you on what it'll take to deal with existing LP branches [11:16] Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 [11:16] gnomefreak: It's unclear to me what you mean [11:16] gnomefreak: If your username is gnomefreak then bzr will default to using that to record commits [11:16] Kinnison: trying to push to my bzr branch it asks for "bzr launchpad-login YOUR_ID" [11:17] gnomefreak: aah, you need to tell it your launchpad login id [11:17] gnomefreak: that's not a "bzr login", that's your Launchpad login :) [11:17] gnomefreak: e.g. mine is 'dsilvers' [11:17] cjwatson: yes, basically the bug has a clean branch associated with it [11:17] i used gnomefreak as ID and it still failed permissions on ssh key [11:17] vila: right, I actually had to reconvert it using lifeless' script as he was missing some new revisions [11:17] gnomefreak: You are John Vivirito? [11:17] vila: I'm doing a diff-at-every-revision test now [11:17] Kinnison: yes [11:17] cjwatson: great [11:18] vila: I'm going to want to push to lp:casper, and I have a funny feeling that I'll need to move the old branch out of the way first [11:18] gnomefreak: and you're using one of gnomefreak@Development or gnomefreak@Hardy in terms of ssh keys? [11:18] vila: do you know whether simply changing the branch name with "edit details" in LP will do the trick there? [11:18] Deveklopemt [11:18] Development Kinnison [11:18] gnomefreak: so, having done bzr launchpad-login gnomefreak, did it give you errors? [11:19] it seems the permissions are due to shh key :( [11:19] cjwatson: ah, I don't remember if lp supports branch renames, it wasn't a long time ago, but that may have changed [11:19] vila, i think it does [11:19] I suppose I can just try it [11:20] poolie: thks :) [11:20] cjwatson: To change the branch that "lp:casper" resolves to you'd need to use https://code.edge.launchpad.net/casper/trunk/+edit [11:20] and i know it worksoh yuck looks like no key in my ~/.ssh dir :( is there a way to add the exsisting key to it? [11:20] cjwatson: (and simply renaming the underlying branch wouldn't affect lp:casper AIUI) [11:20] gnomefreak: either copy your .id_{dsa,rsa}{,.pub} files in, or make a new key for that machine and register it on launchpad [11:20] spiv: right, the bazaar.launchpad.net mirror won't care about what lp:casper is though. I just want to make sure the physical branch data is out of the way so that a fresh push will copy it all from scratch [11:20] see what I mean? [11:21] gnomefreak: s/\.id/.ssh/id/ [11:21] cjwatson: so probably for clarity for everyone you'd want to rename the existing branch, make a new one, and then point lp:casper at the new one === mvo__ is now known as mvo [11:21] I've renamed the existing one to trunk.old [11:21] Kinnison: that is gonna be hard since the dir is empty but i think i saved it to USB stick [11:21]