[00:15] <KombuchaKip> Need help badly. Had a branch on lp. Unbound from it, commit to a different remote branch, unbound from it, rebound to the original one on lp, preparing to merge the branches by running a bzr update when I got an bzr: ERROR: An inconsistent delta was supplied involving 'Documentation/Users/AresEngine', 'documentationuserare-20101114225801-1g0nlj1eao16kgii-13' reason: Unable to find block for this record. Was the parent added?
[00:15] <bob2> bound branches :|
[00:16] <fullermd> Eh, it's only documentation.  Doesn't seem important.
[00:16] <KombuchaKip> That path, /Documentation/Users/AresEngine I had deleted between the unbinding of the lp branch and the rebinding of the new one.
[00:17] <KombuchaKip> bob2 and fullermd: Not sure what to do.
[00:17] <bob2> me either
[00:17] <bob2> bound branches scare me so i do not use them
[00:17] <fullermd> Do you have any important or difficult changes that aren't on one of the LP branches or the other?
[00:18] <KombuchaKip> fullermd: The original lp branch didn't have much in it and lots of stuff was moved around and refactored.
[00:18] <fullermd> But that's stuff you committed into the other remote branch, right?
[00:19] <KombuchaKip> fullermd: Yes, the non-lp one.
[00:19] <fullermd> Then I vote for "fugit".  Whatever you have locally is squirrely, but it doesn't contain anything you need to preserve, so just set it aside (JIC) and start over from your two remotes.
[00:20] <KombuchaKip> fullermd: But I need to apply the changes from the non-lp branch, which I am comfortable deleting, into the actual lp one now.
[00:21] <KombuchaKip> fullermd: Once I've done that, I can delete the non-lp one.
[00:21] <fullermd> Right, but just start your local setup from scratch.  Make a fresh branch of each, and work from them.
[00:21] <KombuchaKip> fullermd: What do you mean?
[00:22] <fullermd> mkdir /tmp/x ; cd /tmp/x ; bzr branch lp:whatever LP ; bzr branch bzr+ssh://wherever/else OTHER ; cd LP ; bzr merge ../OTHER
[00:22] <fullermd> (or the [im]moral equivalent)
[00:23]  * KombuchaKip thinks
[00:23] <fullermd> Just forget about your current local workspace; it'd be good to know what happened and how to fix it, but it's not essential.
[00:23] <fullermd> Don't delete it, just in case it turns out you need something there, but you probably don't.
[00:23] <KombuchaKip> fullermd: I'd like to use a centralized model, so should I replace the bzr branch with bzr checkout?
[00:24] <bob2> I'd really recommend not using bound branches
[00:24] <fullermd> I think that falls into "overthinking" in this case.
[00:24] <KombuchaKip> fullermd: Ok
[00:24] <fullermd> You're not trying to get a semi-permanent workspace going at the moment, just solve this particular problem and get code where it needs to be.
[00:25] <fullermd> Once that's done and you can know you haven't lost anything, you can sit back and figure moving forward.
[00:25] <KombuchaKip> bob2: For technical reasons or for philosophical cathedral vs bazaar reasons?
[00:25] <KombuchaKip> fullermd: Right
[00:25] <bob2> technical
[00:25] <bob2> it's 2012
[00:25] <bob2> no need to pretend you're using svn anymore
[00:25] <KombuchaKip> bob2: Ok, so philosophical then.
[00:25] <bob2> not using them makes everything simpler
[00:25] <bob2> no, technical
[00:25] <bob2> you're not using a centralised vc system
[00:26] <bob2> so using your dvcs as a centralised system leads to technical issues, like merges being more annoying
[00:26] <KombuchaKip> bob2: That's a matter of preference. Bzr can be used in a centralized model if one chooses to.
[00:27] <bob2> of course it's a matter of preference
[00:27] <bob2> but it makes things harder
[00:27] <fullermd> OTOH, I like checkouts, and use them constantly.  I do hate bound branches, though.
[00:27] <bob2> e.g. it lets you replicate the joy of svn making conflicts in uncommited changes
[00:27] <bob2> joy
[00:28] <fullermd> But at any rate, my offhand impression is that your issues probably stem from using a bound branch, but swapping around which other branches its bound to.  That sounds like a recipe for trouble; too many opportunities for confusion.
[00:28] <fullermd> (above and beyond whatever weird technical corners you might get painted into)
[00:28] <bob2> def feels like a bzr bug though
[00:29] <KombuchaKip> fullermd & bob2: https://bugs.launchpad.net/bzr/+bug/855155 Looks like Bob's right. It is a bug.
[00:29] <bob2> ouch
[00:29] <fullermd> Very probably; shouldn't be possible to get it twisted, all else being equal.
[00:29] <bob2> 'bzr up' :(
[00:30] <jono> hey folks
[00:30] <jono> I accidentally committed a a revision to a branch in LP
[00:30] <jono> how can I remove it?
[00:31] <bob2> like "accidentally commited a root password" or "the tests don't pass yet"?
[00:32] <fullermd> It would really be useful to nail down just what alteration triggers it; I see a lot of broad discussion there, but nothing that seems like a reproducible testcase.
[00:32] <jono> bob2, more like the latter
[00:33] <jono> I ran bzr uncommit and bzr push
[00:33] <jono> should that work?
[00:33] <KombuchaKip> fullermd: Ok, so I have run bzr merge successfully on the local lp branch. To "upload" those changes to the remote lp branch, do I just run bzr push? The reason I ask is I've been using bound branches all this time.
[00:34] <fullermd> You'll probably have to `bzr push :parent` or the like, since it won't have a saved pushloc.
[00:34] <KombuchaKip> fullermd: The :parent is an alias for the location of the pull? That being lp?
[00:34] <jono> thanks!
[00:35] <fullermd> :foo is an alias for the various saved locations.  The parent loc is where you branch'd from, and is the default for pull.
[00:35] <KombuchaKip> fullermd: Right. So the command should be bzr push lp:mybranch ?
[00:37] <fullermd> That would work too.
[00:37] <KombuchaKip> fullermd: ok
[00:37] <fullermd> But :parent was quicker to type   ;p
[00:38] <KombuchaKip> fullermd: "Working tree has uncommitted changes. Uncommitted changes will not be pushed". So I need to commit first?
[00:38] <bob2> yes
[00:38] <fullermd> Oh, yes.  Sorry, I assumed you had.
[00:38] <bob2> you always use 'commit' to commit changes
[00:39] <bob2> to push changes somewhere beyond your local repository, 'bzr push'
[00:39] <KombuchaKip> bob2 & fullermd: Thanks.
[00:42] <fullermd> jono: No, push would just have nothing to do.  You'd have to --overwrite.  But you shouldn't, unless you can know for sure nobody's grabbed it.
[00:43] <jono> I did
[00:43] <jono> that
[00:43] <jono> thanks!~
[00:43] <fullermd> The rev has already been exposed to the world; unless you can be sure you eradicated every copy of it, it's just going to come back and bite you hard.
[00:45] <qubodup> hello
[00:47] <youlysses> o/
[00:47] <qubodup> how would I go about deleting all files in a repo that are not tracked?
[00:48] <fullermd> There's a clean-tree command.  You could start there.
[00:51] <qubodup> thanks
[03:29] <jimis1> I want to commit interactively chunks from a file that I select
[03:30] <jimis1> like shelve but in the opposite direction
[03:30] <jimis1> I can't find a way, is it supported?
[03:48] <Peng> jimis: There was a bzr-interactive plugin, but I don't know if it's still maintained.
[03:51] <jimis> thanks Peng, I was hoping something had made it to mainline :-p
[03:52] <jimis> I remember I needed the same feature a year ago and was told it wouldn't be too hard, since most functionality is already in shelve
[03:57] <Peng> That plugin is more than a year old. >.>
[04:02] <jimis> yes I was talking about whether such functionalith had made it to /mainline/
[05:38] <KombuchaKip> fullermd: So before I merged, I was at revision one hundred and something. After the merge I am at only rev 29. I guess the revision numbers are not cumulative after a merge?
[05:41] <bob2> revnos are confusing at best
[05:41] <bob2> since yeah they do move around
[05:41] <mgrandi> they are relative to the branch
[05:42] <mgrandi> so you probably see they are something like 28.1 -> 28.100
[05:42] <mgrandi> or something
[05:42] <KombuchaKip> mgrandi: Yup. Pretty much, which is kind of demoralizing considering how many revisions I commit over the last year...
[05:43] <mgrandi> =P
[05:43] <mgrandi> you can still do uhh
[05:43] <mgrandi> bzr info -v
[05:43] <mgrandi> inside the branch to see the TOTAL number of revisions in the repo
[05:44] <mgrandi> like bzr has like 6000 something revisions, but the 'total' number of revisions (with all the sub revisions) is ... a lot more
[05:44] <KombuchaKip> mgrandi: Right.
[05:52] <KombuchaKip> mgrandi: What is the equivalent to 'bzr revno' for getting the full actual revision number?
[05:53] <mgrandi> do you mean the revision id?
[05:53] <mgrandi> like mark@example.comblahblhablha-time ?
[05:53] <KombuchaKip> mgrandi: I guess so.
[05:54] <KombuchaKip> mgrandi: No, like 6.123
[05:54] <KombuchaKip> e.g. the revno that includes those made before a merge.
[05:54] <mgrandi> as in you want the revno before a revision was merged?
[05:54] <mgrandi> like rev 100 before it got to like 2.100?
[05:54] <KombuchaKip> Yes
[05:55] <mgrandi> i don't think there is a way to get that information as its all relative to the branch
[05:55] <KombuchaKip> mgrandi: Ok, fair enough. I want to bind my local branch to a remote lp one that I pulled from, but getting a "Permission denied (public key)". I'm guessing some auth stuff needs to be setup.
[05:55] <mgrandi> im not an expert on the bzr internals but i think its computed based on the tree of revisions
[05:56] <mgrandi> and since you merged branch a into branch b, then the same revision object is in a different place in the tree
[05:56] <KombuchaKip> mgrandi: Any way to get the revision number like 2.100?
[05:56] <KombuchaKip> mgrandi: ok
[05:56] <mgrandi> you probably need to set your ssh key in launchpad
[05:56] <mgrandi> if you are getting that
[05:56] <mgrandi> and yeah there is a way to get the revision number
[05:57] <mgrandi> bzr log will show the entire history, or you can do bzr log -r <number>
[05:58] <KombuchaKip> mgrandi: I think I already did that, created a key pair, and put the public id on my launchpad page.
[05:58] <mgrandi> did you do bzr lp-login or whatever?
[05:59] <KombuchaKip> mgrandi: I did, but not for this branch. I thought it was system wide, but I realize now that wouldn't make sense.
[05:59] <mgrandi> it should be system wide
[05:59] <mgrandi> it writes it to your bzr.conf
[06:00] <KombuchaKip> mgrandi: Yes, indeed it is and it is correct.
[06:00] <KombuchaKip> mgrandi: I have my ssh key listed correctly too (https://launchpad.net/~kip)
[06:00] <mgrandi> what os are you on?
[06:00] <KombuchaKip> mgrandi: Xubuntu 12.04
[06:00] <mgrandi> you have to have your OS set up to use your key
[06:00] <mgrandi> like putting your private key in ~/.ssh/id.rsa or whatever
[06:01] <KombuchaKip> mgrandi: Hmm, it was working before when I had a bound branch. Yeah, that should be good already.
[06:02] <KombuchaKip> mgrandi: How does it know which public key to use when binding?
[06:02] <mgrandi> if there is only one then it just uses that
[06:02] <mgrandi> you can set up ssh apparently to use different keys for different hosts
[06:03] <KombuchaKip> mgrandi: Right. How can I test my auth without bzr, but just vanilla ssh?
[06:04] <mgrandi> try doing ssh <username>@bazaar.launchpad.net
[06:04] <mgrandi> it should connect and say no shells on this server then disconnect
[06:04] <KombuchaKip> mgrandi: Right
[06:04] <mgrandi> also, bzr testament will show you the revision id of a revision
[06:08] <KombuchaKip> mgrandi: Trying to figure out which file in .ssh contains the private key
[06:08] <KombuchaKip> mgrandi: Think it's id_rsa.1
[06:09] <mgrandi> you can open it in a text editor or cat it and see which one says PRIVATE KEY
[06:09] <mgrandi> its usually id_rsa
[06:09] <mgrandi> id_rsa.pub is usually the public one
[06:10] <KombuchaKip> mgrandi: I'm following this https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Using_a_custom_SSH_key_for_Launchpad
[06:10] <mgrandi> yeah
[06:10] <KombuchaKip> mgrandi: So should be id_rsa.1 ?
[06:10] <KombuchaKip> mgrandi: Not sure if IdentityFile should be the public or private key.
[06:11] <KombuchaKip> mgrandi: Wait, says private. So that should be right.
[06:11] <mgrandi> yeah
[06:11] <KombuchaKip>  mgrandi: debug1: Trying private key: /home/me/.ssh/id_rsa.1 debug1: No more authentication methods to try. Permission denied (publickey).
[06:12] <mgrandi> you are doing username@bazaar.blah right
[06:12] <mgrandi> your launchpad username
[06:13] <KombuchaKip> mgrandi: Yes.
[06:13] <KombuchaKip> mgrandi: Launchpad username should just be kip
[06:14] <KombuchaKip> mgrandi: And trying to login with just $ ssh -v kip@bazaar.launchpad.net
[06:15] <mgrandi> your permissions might be weird on the key
[06:15] <mgrandi> but i dunno, usually that works =(
[06:15] <mgrandi> try googling, dunno why its not working
[06:16] <KombuchaKip> mgrandi: Me neither.
[06:16] <mgrandi> i think #launchpad exists, can try there
[06:17] <vila> KombuchaKip: if 'ssh -vv' tells you the key is not valid, you don't have the right public key uploaded to lp
[06:17] <KombuchaKip> vila: debug2: key: /home/me/.ssh/id_rsa.1 ((nil)), debug1: Authentications that can continue: publickey, debug1: Next authentication method: publickey, debug1: Trying private key: /home/me/.ssh/id_rsa.1, debug2: we did not send a packet, disable method
[06:17] <KombuchaKip> vila: nil?
[06:18] <KombuchaKip> vila: $ ls -hs ~/.ssh/id_rsa.1, 16K /home/kip/.ssh/id_rsa.1
[06:19] <vila> KombuchaKip: 'nil'rgins no bell, the '.1' is a bit suspect but probably harmless
[06:19] <KombuchaKip> vila: Nevermind. I'm an idiot. IdentityFile contained /home/me/... instead of /home/kip/...
[06:19] <vila> here you are :)
[06:19] <vila> KombuchaKip: being an idiot is good and indicates you're walking on the One True Path :-D
[06:20] <vila> I try hard to be an idiot at least twice a day :)
[06:20] <KombuchaKip> vila: ;) It also reminds us that copying and pasting can be dangerous.
[06:20] <vila> yeah, that lesson needs to be re-learned every day
[06:20] <vila> :)
[06:21] <KombuchaKip> vila: I keep getting asked for my passphrase to unlock '/home/kip/.ssh/id_rsa.1'. There must be some way to cache that at login.
[06:21] <vila> yup, use an ssh agent
[06:21] <vila> 'ssh-add -l' will tell you which keys are known by your agent
[06:22] <vila> 'man ssh-add' for details
[06:22] <vila> There was a bug long ago where you needed the ',pub' key along the private one to make the GUI work on ubuntu (dunno if that has been fixed since then)
[06:22] <vila> '.pub'
[06:22] <vila> the public key
[06:23] <mgrandi> i know in gnome, you can make seahorse import your ssh key
[06:23] <mgrandi> and then it will automatically ask you when connecting via ssh for the pass
[06:23] <KombuchaKip> vila: Hmm, I'm not using gnome which I think used seahorse-daemon. I wonder what the standard way under xfce is?
[06:23] <vila> yup, that's what I use (and where the bug was)
[06:23] <mgrandi> good luck importing stuff into seahorse haha, its such a bad program
[06:24] <mgrandi> i think it SHOULD look in .ssh/ for your key and use that
[06:24] <mgrandi> i dunno on xubuntu
[06:24] <vila> KombuchaKip: if all else fails, 'ssh-add key'
[06:25] <KombuchaKip> vila: Yeah, the thing is I don't understand how ssh-add knows which daemon to communicate with?
[06:25] <KombuchaKip> ssh-add -l
[06:25] <KombuchaKip> The agent has no identities.
[06:25] <spiv> KombuchaKip: via environment variables
[06:26] <spiv> SSH_AUTH_SOCK or similar
[06:26] <KombuchaKip> spiv: I guess I probably need to setup seahorse-daemon manually under xfce.
[06:26] <vila> 'ssh-agent -s' displays the relevant env vars here
[06:26] <vila> SSH_AUTH_SOCK, SSH_AGENT_PID
[06:27] <KombuchaKip> vila: I see it is set, but I don't know which process is providing its socket file.
[06:27] <vila> spiv: heya !
[06:27] <KombuchaKip> vila: Got it
[06:27] <spiv> (The idea is to run the agent early enough in your login process that you can set those environment vars for all processes in your sessions)
[06:27] <spiv> vila: bonjour
[06:28] <vila> KombuchaKip: as spiv says. Part of my 'startup applications' in gnome
[06:28] <KombuchaKip> vila: So I have to some how get ssh-add to add my key some how.
[06:28] <KombuchaKip> vila: Well, it looks like ssh-agent is already running, but I don't know what it does that seahorse does or not does.
[06:28] <vila> if the agent has already started, yes. If it hasn't, you'll have to `ssh-agent -s` here and there
[06:29] <mgrandi> ssh-agent is what gets used
[06:29] <mgrandi> even with seahorse
[06:30] <KombuchaKip> mgrandi: Alright. So I need to tell ssh-add to use my key from now on.
[06:30] <mgrandi> just do ssh-add
[06:30] <mgrandi> or err
[06:30] <mgrandi> ssh-add ~/.ssh/id_rsa.1
[06:30] <mgrandi> and then it will work
[06:31] <mgrandi> you might have to put that in your .profile or whatever
[06:31] <KombuchaKip> mgrandi: Yeah, I tried $ ssh-add ~/.ssh/id_rsa.1. That seems to work.
[06:31] <mgrandi> there you go
[06:32] <vila> KombuchaKip: setting up an ssh agent is worth the trouble
[06:32] <KombuchaKip> vila: I think so too. Thanks mgrandi as well.
[06:32] <vila> KombuchaKip: next step is to define the right keys for the right places
[06:32] <KombuchaKip> vila: Right
[06:33] <vila> but that can wait until tomorrow ;)
[06:33] <KombuchaKip> vila: lol, for sure. ;)
[06:35] <vila> KombuchaKip: http://pastebin.ubuntu.com/1014282/ is how you set a specific key for some hosts
[06:36] <KombuchaKip> vila: Thanks.
[06:38] <KombuchaKip> I wish lp blueprints could host files.
[07:02] <vila> corrupted file in ~/.launchpadlib/cache leads to "interesting" udd import failures...
[07:03] <mgrandi> i just found the command bzr graph-ancestry, except it doesn't seem to graph all the revisions for some reason =(
[08:01] <mgz> morning all!
[10:23] <mgz> reconfigure --use-shared is pretty dangerous
[10:24] <jelmer> mgz: in what way?
[10:25] <mgz> ...and naturally my small attempt to reproduce failed
[10:25] <mgz> ah, I know what it was
[10:28] <mgz> simple mistake, painful result: <http://pastebin.ubuntu.com/1014520/>
[10:34] <jelmer> mgz: huh, that's an odd error - why doesn't it find the parent repository anymore?
[10:38] <mgz> presumably we don't look when the ancestor is a branch not just a repo, but reconfigure is happy with any repo it find
[14:04] <codeninjaSD> Does Bazaar have the ability to attach searchable tags, other than revision number, to code artifacts?
[14:10] <mgz> as in `bzr help tag` kind of tags?
[14:13] <Lo-lan-do> Hi all :-)
[14:14] <Lo-lan-do> Question about bzr-git: is there a way to keep "bzr dpush" from pushing if the branches have diverged (ie, if a rebase is needed beforehand)?
[14:25] <Lo-lan-do> Unrelated question: where can I read some user-oriented doc about colocated branches and how to use them?
[14:29] <CodeNinjaSDJ> sorry, got disconnected. Did you see that mgz?
[14:30] <CodeNinjaSDJ> tags as a way to search for artifacts/commits
[14:30] <mgz> Lo-lan-do: two questions you want to bug jelmer on :)
[14:31] <mgz> CodeNinjaSDJ: I'm still not sure exactly what you mean, perhaps you can give an example?
[14:37] <Lo-lan-do> mgz: Yeah, I guessed, but he told me he's not working on bzr-git anymore, so I hoped to get some support from #bzr at large :-)
[14:39] <CodeNinjaSDJ> we want to be able to search for artifacts in other ways besides using revision numbers
[14:39] <CodeNinjaSDJ> like a way of catagorizing
[14:41] <mgz> Lo-lan-do: indeed, but he'ss still the best repository of the current status of things. on colocated branch docs, we don't really have anything user-facing currently.
[14:41] <mgz> CodeNinjaSDJ: what do you mean by artefacts though? revisions? files?
[14:42] <Lo-lan-do> Could be bugs
[14:42] <mgz> okay.
[14:42] <mgz> so, you mean arbitrary revision properties.
[14:42] <Lo-lan-do> (We call tracker items "artefacts" in FusionForge)
[14:43] <mgz> bugs you can set up your own end point for
[14:43] <mgz> other stuff is also possible, but not directly supported.
[14:43] <CodeNinjaSDJ> files
[14:46] <CodeNinjaSDJ> Does Bazaar have the ability to trim down history to say, the last three months worth of changesets.
[14:46] <mgz> but a particular file in a particular revision? there doesn't seem much point just tagging files, that's what filenames are for.
[14:47] <mgz> you can edit history, but it's generally discouraged. not committing binaries tends to be the answer people actually need.
[14:47] <CodeNinjaSDJ> Well, we also want to use this as a reference tool. Say a developer is starting a project, he can go here to search to see if similar code has already been done
[14:49] <mgz> that beyond the scope of any version control tool.
[14:50] <mgz> you can grep across history with say, bzr-grep, but detecting similar code to something you want to write is AI-completish
[14:50] <sdjninja> Sorry, keep getting disconnected for some reason
[14:58] <mgz> sdjninja: so, it's still not clear if this is something you're envisioning devs adding for particular revisions, or a search that magically produces answers
[14:59] <jam> vila: it looks like someone actually checks gpg signatures :)
[15:00] <vila> jam: and ?
[15:00] <jam> vila: you accidentally uploaded the 2.5b1 signature with the 2.5.1 tarball
[15:00] <vila> ha, I never did *this* mistake before, my creativity has no limits...
[15:01] <vila> hmm, so, what I should do, delete and re-upload ?
[15:01] <mgz> it's a bdot.
[15:02] <vila> mgz: lol, took a while to get it ;)
[15:03] <vila> jam: who told you ?
[15:04] <vila> I've deleted the bogus one and I'm re-uploading with the right sig
[15:04] <jam> vila: it was on bazaar@
[15:04] <vila> AFAIK, only people referring to it via it's librarian lp id will be impacted, fullermd will probably want to kill me ;)
[15:04] <jam> I just downloaded and confirmed it
[15:55] <bsd> hello all.  I'm trying to do 'diff -r branch:colobranchname' but bzr isn't resolving colobranchname.  I vaguely recall that abentley or someone wrote a little directory-like plugin to simplify accessing native colocated branches?
[15:56] <jelmer> bsd: hi
[15:56] <bsd> hi jelmer
[15:56] <abentley> bsd: bzr+ssh://bazaar.launchpad.net/~abentley/+junk/nc/
[15:56] <bsd> ah, great — thanks jelmer
[15:56] <jelmer> bsd: no, thanks abentley :)
[15:56] <bsd> thx abentley too ;-)
[15:57] <abentley> bsd: np
[16:19] <fullermd> vila: I'm killing who for what now?
[16:22] <fullermd> vila: The source tarball is fine though, neh?  It's just the signature that's reuploaded?
[16:34] <mgz> fullermd: it was fine, just gets reuploaded as part of the lp process
[16:40] <vila> fullermd: 100% correct, but I seem to recall that you an alternate url to get it from the launchpad librarian, so the *content* is the same, but the librarian url has changed
[16:41] <vila> s/that you an/that you use/ (/me becomes anti-mgz and remove words instead of using them twice 8-)
[16:41] <vila> you use as !
[16:41] <vila> no, in retrospect, no as
[16:48]  * fullermd blinks.
[16:49] <fullermd> It changes the tarball URL, even though it's not changed?
[16:51]  * fullermd sighs.
[16:51] <fullermd> Grumph.  OK.  Let me oil up my good killing bat and check flight times...
[17:07] <vila> fullermd: ha ! At least I told you soon enough ;) Sorry about that, but I went with the fastest path (lp does not provide a way to dissociate a tarball from its sig while uploading (which isn't such a bad thing)). Just fix your redirection handler once and for all :-P
[17:07] <fullermd> The general opinion is that it _is_ fixed   ;p
[17:09] <vila> ha, cool, now we just have to fix the users then ;) . o O (Am I really fixable about mixing up sigs ?)
[17:10] <fullermd> Oh, I'm sure you're fixable.  I've got some scissors here somewhere...   >:-}
[17:14] <vila> To my defense, please note that this sig is valuable one, it still serves us well for 2.5b1 and.. it wanted to do a bit more... couldn't refuse
[17:15] <fullermd> There are only so many bits in the universe.  You were just saving some.
[22:05] <sarcasticCat> What does the command [bzr launchpad login] do when used w/o the argument?
[22:05] <sarcasticCat> Does it return the login name?
[22:18] <wgz> sarcasticCat: yes, if you use a dash rather than a space
[22:19] <sarcasticCat> yah, a dash is what I meant
[22:19] <sarcasticCat> what happens if no one ever logged in on that machine?
[22:19] <sarcasticCat> any error will be thrown?
[22:21] <wgz> prints "No Launchpad user ID configured." on stdout apparently
[22:21] <wgz> really that should be on stderr or something
[22:23] <sarcasticCat> I see. Thnks