[00:49] <spiv> exalt: The problem is "Permission denied (publickey)"
[00:50] <spiv> exalt: /away
[00:50] <spiv> oops
[00:50] <exalt> spiv, yeah but bzr whoami returns my user
[00:50] <exalt> so i am logged in
[00:50] <spiv> exalt: try "ssh -l YOUR_LAUNCHPAD_USERNAME bazaar.launchpad.net"
[00:50] <spiv> And perhaps add -v for more debugging
[00:51] <spiv> I think you'll find that those commands also fail with that error
[00:54] <exalt> debug1: Server accepts key: pkalg ssh-rsa blen 279
[00:54] <exalt> Agent admitted failure to sign using the key.
[00:55] <exalt> spiv, ^
[00:57] <JackyAlcine> Hello, I'm having an issue with pushing code to a branch.
[00:58] <jelmer> hi JackyAlcine
[00:58] <JackyAlcine> Give me a moment to compile necessary info to a pastebin
[00:58] <JackyAlcine> http://pastebin.com/V7RJ74t1
[00:59] <JackyAlcine> That's my friend's bin.
[00:59] <JackyAlcine> And he can't pull code from branch lp:libopenmary-c++
[00:59] <exalt> JackyAlcine, hi :)
[01:00] <JackyAlcine> lol
[01:00] <JackyAlcine> jelmer: exalt's the person in need of assistance.
[01:02] <exalt> spiv, it seems the server accepts my key but then fails at it
[01:03] <exalt> jelmer, ^
[01:05] <jelmer> hi exalt
[01:05] <jelmer> sorry, was not watching IRC very closely
[01:06] <jelmer> exalt: it looks like you don't have the right SSH key up on launchpad
[01:06] <exalt> jelmer, ive searched for my error:
[01:07] <exalt> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/201786https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/201786
[01:07] <exalt> seems like min
[01:07] <exalt> mine
[01:08] <spiv> exalt: try running "ssh-add"
[01:09] <spiv> exalt: and/or try the workarounds in the later comments.
[01:09] <exalt> spiv, got it working
[01:09] <exalt> thanx all
[09:51] <twb> ssh-copy-id bazaar.launchpad.net ==> Not allowed to execute 'umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys'.
[09:51] <twb> Is there a way to upload additional keys WITHOUT using the web interface?
[09:52] <maxb> no, there isn't
[09:53] <twb> OK, I'll just use the git mirror for Emacs.  I just realized bzr clone gets OOM-killed anyway.
[10:26] <Miika--> Hello, does bazaar need to be installed on remote system to push / pull through ssh?
[10:27] <Peng> Miika--: bzr+ssh: Yes. That's what the "bzr+" means. sftp: No, but performance isn't as good as bzr+ssh.
[10:30] <Miika--> I mean, if I have bzr installed on my local, working computer, but I have only remote storage, with no bzr installed. Does push / pull work to that remote location?
[10:31] <Peng> Miika--: I know that's what you meant.
[10:34] <Miika--> Ok, thanks
[10:35] <Peng> Installing bzr on the remote server would be ideal since, as I said, sftp's performance is inferior.
[10:37] <Tak> besides - is a computer without bzr really a computer? :-P
[11:19] <catphish> are revision numbers in bzr always sequential?
[11:19] <catphish> by which i mean, if i find a revision called 100, are there definitely 99 ancestors?
[11:23] <Peng> There could be more ancestors, of course. The "100" refers only to mainline revisions.
[11:24] <catphish> what is a revision that's not mainline?
[11:25] <catphish> i was working on the (possibly incorrect) assumption that bzr branches were linear like svn
[11:27] <Peng> Bazaar's merging support isn't crap. Revisions can have more than one parent.
[11:28] <catphish> where are the parents located?
[11:28] <catphish> in another branch?
[11:28] <Peng> What do you mean?
[11:28] <catphish> i'm struggling to understand the structure
[11:29] <Peng> The docs should explain it well enough.
[11:29] <Miika--> Does bzr-git support git submodules?
[11:29] <catphish> you say a commit scan have more than one parent
[11:29] <catphish> *can
[11:29] <catphish> one parent i assume must be the previous tip? but where does the other one point?
[11:29] <Peng> catphish: Right. "bzr merge some_other branch; bzr commit". That revision's parents are the previous tip from this branch + the tip from the branch you merged in.
[11:29] <Peng> Err, "bzr merge some_other_branch" *
[11:30] <catphish> so a parent is either a revision number, or a url and a revision number?
[11:31] <Peng> No, revisions have GUIDs. Revision numbers are just a convenient per-branch representation.
[11:31] <catphish> ooo that's good
[11:32] <Peng> You know how git and hg use SHA-1 hashes? Bazaar does something similar, though the format is not restricted, and they're usually just randomly-generated.
[11:32] <Peng> catphish: You can pass --show-ids to "bzr log" and maybe some other commands, though it's not really very interesting.
[11:34] <catphish> so it's not possible to follow a parent and find the actual commit?
[11:34] <catphish> since it could be anywhere in a remote repo
[11:35] <catphish> or will those parent commits actually get pulled into the branch too?
[11:37] <Peng> "bzr merge" pulls the revisions into the local repo.
[11:37] <catphish> i ask because i'm making a log viewer
[11:38] <catphish> so i'm not totally sure what commits i can show, starting from a given revision
[11:38] <Peng> Obviously lightweight checkouts and stacked branches may not have all revisions locally, but they will be in the remote repo.
[11:39] <Peng> Unless they're ghosts, in which case the revision really isn't anywhere. But that's not a common situation.
[11:39] <catphish> the repo i'm testing with doesn't appear to have any revisions with multiple parents sadly
[11:39] <Peng> Nobody's merged? Ever? How boring.
[11:41] <catphish> ah found one :)
[11:43] <Peng> :D
[11:43] <catphish> the merged branches seem to be inside the commit message
[11:43] <catphish> *merged commits
[11:43] <catphish> in the log view
[11:45] <Miika--> How I can clone a project with submodules from github using bzr-git? It says about repository formats supporting nested trees
[11:45] <fax8> hi guys, I recall that there was a documentation page with suggestion on how to structure a bzr repository..
[11:46] <fax8> it seems that I'm not able to find it anymore.. can you guys point me to it?
[11:47] <catphish> fax8: structure one? do you mean using "bzr init-repo" to create a repo then create branches inside?
[11:47] <Miika--> Or, how I can change default repo format?
[11:48] <Peng> catphish: Yes, that's how "bzr log" displays it.
[11:48] <catphish> ok :)
[11:54] <fax8> catphish: how to structure it in a smart way.. I mean creating folder and subfolders using "trunk" or folders for various stable releases.. stuff like that
[12:15] <catphish> fax8: not sure, i'm a newbie here
[12:19] <fax8> catphish: thanks anyway
[12:19] <fax8> goodbye everybody!
[13:43] <janisozaur> hello. I have two separate branches (standalone trees, 2a) that share some code, but are not tied to each other via bzr. I've done some changes to branch A, that I'd like to introduce to branch B. how can I do that? preferably keeping commit logs, though it can be done manually, as there are not many revisions
[13:44] <LeoNerd> bzr replay   might be able to do it
[13:44] <LeoNerd> In fact I know it can because I've used that before in this very situation
[13:44] <janisozaur> LeoNerd, my bzr doesn't know such command
[13:44] <LeoNerd> Applying an identical bugfix to unrelated trees
[13:45] <LeoNerd> It's part of the rebase plugin
[13:46] <janisozaur> LeoNerd, thanks, will see to that.
[13:47] <janisozaur> also, I remember I've used 'bzr patch' once to merge in output of 'bzr diff', but I can no longer see the command. is it from a plugin or was it removed or just my memory doesn't serve me well?
[13:47] <LeoNerd> I expect that's what became  bzr replay
[13:47] <janisozaur> LeoNerd, ah, thanks a lot then
[13:47] <LeoNerd> replay  reapplies a given patch into the current branch
[13:48] <LeoNerd> bzr replay -r 123 /path/to/source/branch
[13:50] <fullermd> 'bzr patch' is part of bzrtools.  But it doesn't really do anything that regular patch(1) doesn't.
[14:18] <maxb> The rebase plugin is called the rewrite plugin these days
[15:55]  * catphish is sad because bzr diff returns non-zero exit codes on success :(
[15:56] <poolie> catphish, they have meanings
[15:56] <poolie> like 'there are uncommitted changes'
[15:56] <catphish> i know what they mean
[15:56] <spiv> james_w: do you have time to keep working on https://bugs.launchpad.net/udd/+bug/653307 today?
[15:56] <catphish> it just happens to be a problem for me that it exits non-zero on success
[15:56] <james_w> spiv, should do yeah, but I have something urgent to do this morning
[15:57] <spiv> james_w: ok, give me a poke or come say hello later if you want
[15:57] <james_w> spiv, I can probably come up after lunch again
[15:57] <spiv> Sounds good
[15:57] <catphish> i will need to write a wrapper that exits zero unless the exit code is 3
[15:59] <poolie> catphish, in a unix shell?
[15:59] <poolie> a quick way to write it is
[15:59] <poolie> bzr diff ||:
[15:59] <poolie> maxb, awake, perchance?
[16:00] <maxb> hello
[16:01] <catphish> poolie: does that just always return 0?
[16:02] <poolie> yes, it means "if this fails run :" and ":" is a builtin that returns 0
[16:02] <poolie> maxb, i just spoke to pitti about SRUs
[16:02] <catphish> poolie: unfortunately that's no use to me since i won't actually know if the diff failed
[16:02] <poolie> ah ok
[16:02] <catphish> i need some shell knowledge that returns (code != 3)
[16:03] <catphish> since diff returns 3 on a failure
[16:03] <poolie> so i guess you need bzr diff; [ $? -lt 2 ] || print "something's wrong"
[16:03] <catphish> yes :)
[16:27] <lifeless> poolie: bug 702914
[16:28] <poolie> really, interesting
[16:30] <poolie> lifeless, to avoid roundtrips, feel free to triage/assign etc
[16:31] <lifeless> poolie: I'm guessing another thread safety issue, seems fairly low frequency atm
[16:31] <poolie> k
[16:31] <lifeless> may be loggerhead, may be bzr itself
[16:31] <lifeless> I'm not sure if I should open a loggerhead task or not
[18:47] <lifeless> jelmer: are you updating loom packages too?
[18:50] <jelmer> lifeless: in the past Andrew has done the loom packages (I try to avoid packaging software I don't use for various reasons)
[18:51] <jelmer> lifeless: being on the bzr team and with their importance for UDD I should probably start using them now though
[18:51] <jelmer> lifeless: I'll have a look at updating the packages.
[18:51] <jelmer> lifeless: thanks for the reminder
[18:54] <jelmer> lifeless: did you see my reply (4 lines) ?
[19:05] <jelmer> argh
[19:07] <lifeless> jelmer: no
[20:37] <agruman> how much size does bzr take for each file (unmodified)? (does it save a copy of the file in .bzr?)
[20:40] <Peng> That's a bit complicated. Bazaar compresses everything.
[20:41] <Peng> Repositories store every revision of every file, but they're compressed six ways to Sunday.
[20:46] <agruman> Peng, ok, but if i have a single revision will it only take 1x the file size? (im not used to dvcs, been using clearcase and there the files are 1x and read only until checked out and modified)
[20:47] <lifeless> if you have a single revision the overhead will be <= gzip(file content)
[20:48] <lifeless> two revisions it will be gzip(file content + binary delta to second revision)
[20:50] <agruman> lifeless, ok, but the file would be present in its uncompressed form as well? resulting in 'file + gzip(file)'?
[20:51] <spiv> agruman: no
[20:52] <spiv> agruman: we don't store uncompressed file contents in the repository
[20:53] <Peng> Obviously the working copy is uncompressed, of course.
[20:53] <agruman> spiv, ok, then im not sure i understand. How would i read the file, would i need to decompress it?
[20:53] <agruman> Peng, k
[20:53] <lifeless> but the working copy isn't overheaad ;)
[20:54] <agruman> perhaps, depends on how you see it
[20:54] <agruman> i myself find it overhead
[20:55] <agruman> i would have wanted the size to be "repo + checked out files"
[20:57] <agruman> or is the working copy "optional"? i suppose not, but as i said this is new to me
[20:59] <lifeless> agruman: thats right
[20:59] <lifeless> its optional
[20:59] <Peng> agruman: Yes, you can remove the working copy.
[20:59] <lifeless> on a server you want just repo
[20:59] <Peng> Or not create one in the first place.
[20:59] <lifeless> on a laptop you want repo + working copy so that you can work offline, edit files, do log etc
[20:59] <Peng> agruman: The size is "repo + checked out files". You were asking about the specifics of "repo". And "checked out files" can be zero.
[21:00] <agruman> thanks alot for the explanation :)
[21:01] <agruman> would it be possible to only have a working copy and not the repo on a laptop (for file that dont change ex binary)
[21:02] <spiv> It is, "bzr checkout --lightweight".  There's a pretty large performance hit if the repo for that is on a network.
[21:04] <agruman> spiv, ok, thanks alot for the info
[21:15] <poolie> maxb, still here?
[21:15] <poolie> i spoke to pitti about our SRUs and MRE
[21:15] <poolie> he said we should just upload for -proposed, or ask for sponsorship into that
[22:26] <jml> jelmer: <exarkun> spiv: Can we be sure that those rev props don't get onto trunk?
[22:40] <jelmer> jml: I think I miss context.
[22:41] <spiv> jelmer: short version: svn users are allergic to revprops
[22:42] <spiv> jelmer: because they fear breakage in commit hooks, commit mail scripts, trac, etc
[22:42] <jml> and I never use bzr-svn to do Twisted stuff
[22:42] <jml> because I'm afraid of exarkun getting angry at me
[22:42] <jelmer> are you sure you mean revprpos, not file properties?
[22:42] <spiv> Anything that looks weird and unusual, basically :/
[22:43] <spiv> In this case there's a degree of discomfort about having props of any flavour in a branch
[22:43] <jelmer> Can you give a bit more context in that case - be sure that those revprops don't get onto trunk when doing what?
[22:43] <spiv> And deep fear about having them reach official branches like trunk
[22:44] <spiv> In this case landing my bugfix branch on trunk
[22:45] <jelmer> mwhudson: ooh, shiny linaro hostmask!
[22:45] <jelmer> spiv: so, "svn merge" will ignore revision properties
[22:45] <jelmer> spiv: is that what you're asking?
[22:46] <spiv> jelmer: I'm not asking anything, really (although thanks for confirming that for me)
[22:47] <spiv> jelmer: I think jml was just sharing some pain
[22:47] <jelmer> ah
[22:47] <spiv> jelmer: "svn merge" was my plan for landing this change
[22:47] <spiv> jelmer: as soon as I figure out the right invocation, because it doesn't just DTRT :)
[22:47] <jelmer> so I can feel the pain when it comes to file properties (and will require user confirmation before bzr-svn sets them in newer versions)
[22:49] <jelmer> revision properties shouldn't break anything other than bzr-svn if they're incorrect,
[22:49] <jelmer> and are only visible in a limited number of situations
[22:57] <mgedmin> so, I look in my process list and I see that bzr-notify has 7 zombie children (all ssh processes)
[22:57] <mgedmin> any clues?
[22:59] <jam> vila!
[22:59] <jam> vila!
[23:00] <jelmer> mgedmin: wow, that's interesting. As far as I know bzr-notify should never do remote access..
[23:04]  * awilkins would just turn off or filter revprop reporting on Trac or whatever
[23:04] <awilkins> I agree that it looks a mess from the POV of a "pretty" changeset browser
[23:06] <spiv> jelmer: AIUI the issue isn't that they break SVN, but that random tools people build on their SVN repo are fragile
[23:06] <spiv> jelmer: because they have never been tested with rev props
[23:07] <spiv> jelmer: in other news
[23:07] <spiv> jelmer: "the right invocation" turned out to be "bzr merge URL" in my SVN checkout, because apparently I've forgotten too much svn to know how to make it be sensible
[23:08] <awilkins> I could never get SVN to be sensible about merges
[23:09] <awilkins> I had a crack recently because I had to give training on SVN to my peers and was able to break it's merging ability with the first test I did (although it is *slightly* less rubbish than I remember it)
[23:10] <awilkins> 'tis a shame that CollabNet are so stuck on SVN having sunk so much into it ; 'tis still the only VCS they offer on their hosting services AFAIK (and guess which hosting service we signed up for ....)
[23:11] <awilkins> Happily I have a shell account and root on some of the build machines so I used it to make a Bazaar mirror of the sources and I don't have to use SVN anymore except on special occasions. Hooray.