[00:08] <GungaDin> is it possible to merge into a branch if there already is an ongoing merge?
[00:09] <mgz> I believe it is these days, it's certainly possible for there to be more than two parents.
[00:09] <mgz> not actually tried it recently though.
[00:09] <GaryvdM> GungaDin: bzr merge --force
[00:11] <GaryvdM> If I recall correctly - Bzr has been able to do that from pre 0.17 days - if not the beginning
[00:11] <GungaDin> they're not really done from the same machine.
[00:11] <mgz> ha, clearly I didn't try hard enough last time then.
[00:12] <mgz> thanks Gary.
[00:12] <GaryvdM> GungaDin: then I think I we miss understand you - Could you try describe in more detail what you are wanting to do?
[00:13] <GungaDin> there's a branch stored in a shared on machine S. there are 2 checkouts of it on machine A & B. both users on A & B want to merge something into this branch.
[00:14] <GaryvdM> GungaDin: Yes - person A commits - cause it's a check out it gets pushed to the master branch.
[00:15] <maxb> One should merge and commit. The other should then update, merge and commit
[00:15] <GaryvdM> then person b ties to commit - It wont let him/her because of person a's commit
[00:16] <GaryvdM> so b must update before he commits
[00:16] <GaryvdM> and the update will merge a's changes with b's changes
[00:16] <GungaDin> I'm talking about the situation before anyone commits.
[00:17] <GungaDin> one has started a merge... can the other one start his now?
[00:17] <dash> GungaDin: merges don't happen in branches, they happen in working copies.
[00:17] <GungaDin> or is that branch locked until the commit of the first one?
[00:18] <maxb> There is no locking, but if they both start simultaneously, one will have to update before committing, and may have to resolve conflicts as a result
[00:19] <poolie> hi guys
[00:19] <poolie> i'm going to be at uds next week so i'll be offline a bit
[00:19] <poolie> and i have been busy a bit this week getting ready
[00:21] <spiv> GungaDin: a merge is basically just another kind of uncommitted edit you can make to a checkout, like modifying or adding files.
[00:21] <spiv> GungaDin: and the branch isn't affected by uncommitted changes until they are committed.
[00:24] <GaryvdM> mgz: see revno 4825.1.1 in bzr.dev
[00:25] <mgz> ...appears to be doc fixes from nmb?
[00:25] <GaryvdM>  mgz: hint - count the parents :-)
[00:27] <mgz> ah, I see what you mean.
[00:29] <GaryvdM> I had a script to find octopus merges, but I've lost it. There are others...
[00:32]  * KombuchaKip is very much enjoying the soundtrack to The Fountain by Kronos Quartet. Every time he sees their name on a soundtrack, he's confident it will be stellar.
[01:55] <poolie> hi there spiv
[02:13] <spiv> Hey
[02:21] <poolie> sorry i haven't piloted much
[02:21] <poolie> having one of those about-to-go-away weeks
[02:21] <poolie> the lp-dev review thread is interesting, isn't it
[02:21] <poolie> it reminds me how much easier things seem to flow for us compared to a few years ago
[02:22] <spiv> Yeah, definitely
[02:23] <spiv> It's partly also that they have such a large team, so naturally there's a little more divergence in understanding of the norms and rationales for reviewing.
[02:23] <spiv> Such a large review team, that is.
[02:24] <spiv> We actually have a pretty large set of people generating merge proposals, really :)
[02:29] <poolie> mm
[02:40] <mwhudson> i think launchpad and bazaar are really quite different projects
[02:40] <mwhudson> in ways that i can't quite put my finger on
[02:56] <poolie> probably
[02:57] <poolie> hm, gmail seems to be down?
[02:57] <mwhudson> not for me
[02:57] <mwhudson> but then the way that sort of thing works, partial outage is hardly surprising
[02:59] <spiv> On another channel I'm on someone else had gmail be down just for them for a while this morning.
[02:59] <spiv> Or more facetiously, http://downforeveryoneorjustme.com/gmail.com
[02:59] <poolie> hm, maybe this is a good chance to get something done :)
[03:00] <spiv> Hah
[03:08] <poolie> hm the docs are indeed broken by danilo
[03:09] <poolie> by his name occurring in a tex document
[03:09] <poolie> spiv what did you change there?
[03:10] <spiv> Nothing much I would have thought...
[03:10] <spiv> Where does his name occur?  In release-notes?
[03:12] <poolie> in bzr-en-release-notes
[03:14] <spiv> I didn't look at the tex generation at all
[03:14] <spiv> I believe that's done by sphinx?  So in theory nothing significant has changed there...
[03:16] <spiv> Yeah, nothing obvious... will look again after lunch if you're still having trouble.
[03:22] <poolie> i can reproduce it locally
[03:22] <poolie> and yes, it does seem to be produced by sphinx
[03:27] <gilaniali> whats the bzr of eqivalent of gitosis and gitolite
[03:27] <jbowtie> I think that's Sphinx issue 432, fixed 5 months ago in http://bitbucket.org/birkenfield/sphinx/changeset/28e9f10c1f34
[03:27] <dash> gilaniali: what do those do?
[03:28] <gilaniali> dash: they help in managing a gitserver by providing an easy way to add user users, manage group permissions and such
[03:29] <poolie> gilaniali: i believe there is a fork of gitosis that runs bzr, bzrosis or something
[03:29] <poolie> jbowtie: i don't think it is that issue ,but thanks
[03:31] <jbowtie> poolie: sorry, correct URL is http://bitbucket.org/birkenfeld/sphinx/changeset/28e9f10c1f34
[03:32] <poolie> mm, i found it, but that's not the error i'm getting
[03:32] <poolie> i'll file a bug
[03:37] <jbowtie> Hm, Maverick still has 0.6.6, bug was fixed in 0.6.7 but it could be down to latex version being used I suppose.
[03:51] <poolie> https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/39115 skirts around it
[03:51] <poolie> jbowtie: but the one i get is an error during pdflatex, not while producing the tex
[03:52] <poolie> i suspect the bug if anywhere is in their tex templates but i really don't want to dig into that now
[04:01] <jbowtie> Oh, that might be the moving arguments bug in pdflatex. I'll have a closer look over the weekend when I push my documentation bug fixes.
[04:01] <poolie> great
[04:02] <poolie> do you want to rubberstamp <https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/39115> in the interim?
[04:02] <poolie> i'd be happy to leave the bug open
[04:46] <jbowtie> poolie: Yes, just did so.
[04:46] <poolie> thanks
[04:47] <jbowtie> Hmm...apparently I'm 'community'.  Is that a new launchpad feature?
[04:48] <poolie> i think it means you're not in the team of reviewers for the target branch?
[04:49] <jbowtie> Maybe. I just requested bzr-core membership.  Already in bzr-qa and bzr-doc
[04:51] <jbowtie> I would have thought that would have been within the purview of bzr-doc anyhow.
[04:51] <poolie> mm
[04:51] <poolie> bzr-core is just the default reviewer and i didn't change it
[04:51] <poolie> it's totally fine as it is
[05:00] <jbowtie> Is bug 388249 still an issue?
[05:01] <abentley> poolie: bzr-core is not merely the default reviewer, it is the designated review team for that branch.  Anyone doing a review for that branch who's not a member of that team is "(community)".
[05:33] <lifeless> poolie: http://bzr.bz/
[05:39] <poolie> wow
[05:39] <poolie> nice domain
[05:40] <spiv> Ooh, some excellent lightning and thunder where I am atm.
[05:42] <glyph> "It's not launchpad.net"?
[05:43] <poolie> mm me too
[05:43] <poolie> apparently not
[06:38] <mtaylor> lifeless: what an interesting thing that is
[06:39] <lifeless> indeed
[06:48] <peitschie> i can understand the sentiment slightly
[06:49] <peitschie> it'd be very nice to get something simpler to play with than launchpad for hosting bzr projects
[06:49] <peitschie> having said that... i wouldn't trust that place from teh looks of it with my code ;)
[07:11] <poolie> i think it's nice to have an alternative that is seems to be taking a very kind of dry approach
[07:11] <poolie> in fact it's good to have alternatives full stop
[07:21] <poolie> has anyone else tested bzr from maverick-proposed?
[07:28] <spiv> Hmm, I have the bzr from bzr-beta-ppa, haven't tried maverick-proposed.
[07:29] <lifeless> do you have maverick ?
[07:29] <lifeless> 'you' should talk to marjo about getting testers
[08:09] <vila> hi all
[08:10] <poolie> that would be good
[08:10] <poolie> lifeless: what do you mean?
[08:10] <lifeless> the ubuntu qa folk are discussing how to attract testers at themoment
[08:10] <lifeless> mainly for iso testing I think
[08:10] <poolie> ok, maybe i'll see him next week
[08:10] <lifeless> but SRU is pretty important, I would be surprised if they aren't thinking about it
[08:12] <poolie> spiv, can you downgrade and test that, and then comment on the bug? or vila?
[08:13] <vila> hmm... I've got so many different configurations flying around that the main problem will be to find the right one where I can be sure to test the right bzr 8-)
[08:14] <vila> poolie: on the other hand, I've *already* tested it one way or the other...
[08:14] <poolie> vila actually if we have room to spare, an infrequent babune job that checks bzr selftest from maverick-proposed, and other things where it should be green, would be good
[08:15] <poolie> i should add babune to my 'poll' bookmarks
[08:15] <poolie> i wonder too if we can separate them into 'should be green' and 'not yet'?
[08:15] <poolie> or maybe you already did?
[08:15] <vila> poolie: you know there are news feeds there
[08:15] <poolie> mm, i don't really believe in rss though
[08:16] <vila> poolie: toying around with ppas or other things requiring root access is outside babune capacities so far (and will remain for the foreseeable future)
[08:16] <poolie> even in a vm?
[08:16] <vila> poolie: the focus is on running from branches, not toying with system setups
[08:17] <vila> another maverick vm then or may be I should instead look into *not* running from source
[08:17] <vila> I haven't looked from this angle yet
[08:18] <poolie> on the whole i would say source is a higher prioirity
[08:18] <peitschie> (hi vila :) )
[08:18] <vila> babune slaves requires an available bzr, whatever it is, just a running one
[08:18] <poolie> since we can change it much faster
[08:18] <vila> peitschie: hey :)
[08:18] <vila> poolie: +1
[08:19] <poolie> vila i see for instance http://babune.ladeuil.net:24842/job/selftest-jaunty/321/ failed
[08:19] <poolie> with a subunit 'connection broken' message
[08:19] <poolie> which is not much of a message at all
[08:19] <poolie> what does that mean?
[08:19] <vila> poolie: now, it's conceivable to run an hudson job without tying it to a bzr branch and look into configuring the vms with -proposed
[08:19] <vila> poolie: shudder
[08:19] <spiv> poolie: replied to your bug 653307 comment: I think we are closer to a diagnosis now
[08:19] <poolie> right, just do it every day or every few days
[08:20] <poolie> oh good
[08:20] <lifeless> poolie: you don't like rss?
[08:20] <spiv> poolie: unfortunately, it involves the word "stacking" :(
[08:20] <poolie> lifeless: i just tend to find i don't want to read a whole bunch of news mashed together
[08:20] <vila> that's the remaining pain point with subunit/testtools/hudson: random failures, not reproducible at will, unknown cause
[08:20] <poolie> i check different things at different intervals
[08:20] <lifeless> poolie: I do quite like google reader
[08:21] <poolie> i know
[08:21] <vila> poolie: best guesses includes: hangs or.... whatever can make a selftest subprocess die... no traces, go figure
[08:21] <poolie> lifeless: this is one of my grumbles about subunit; it tends to fail opaquely in practice
[08:21] <lifeless> poolie: :(
[08:21] <poolie> vila i wonder if it crashed in C, or ran out of memory, or something like that
[08:21] <poolie> very good in other ways mind you, and i'm sure this is tractable
[08:22] <poolie> vila is it possible to see the raw streams?
[08:22] <vila> poolie: for a while I just hit delete and re-run, now I keep them but still re-run
[08:23] <vila> poolie: could be, but it hasn't reach the top of my TODO list yet (and I suspect it won't for quite some time ;)
[08:23] <poolie> just wondering
[08:23] <vila> poolie: my gut feeling is more around timing issues than OOM or crashes
[08:24] <vila> poolie: could also be virtualbox related
[08:24] <poolie> in some cases if unexpected output gets into the noise subunit will disconnect
[08:24] <poolie> that too
[08:25] <vila> there are a couple or network bugs randomly occurring here and there even at boot time for karmic/lucid/maverick where the eth0 interface is not properly configured/initialized including avahi failing or dhcp or goat or chicken
[08:26] <vila> and sometimes the network connection is lost or the autofs fail or...
[08:26] <vila> you know, the kind of bug that disappear as soon as you try to look at them ?
[08:26] <vila> just like them
[08:27] <vila> anyway, to come back to the initial question: I don't feel qualify to test '-proposed', there are too many reasons that my tests won't be representative
[08:28] <vila> imbw
[08:28] <vila> by the way, natty is not yet installable right ?
[08:29] <vila> I mean, with a reasonable effort
[08:29] <vila> like: download a bootable iso or tweak an apt sources files on a maverick vm :)
[08:31] <vila> hmm, so looking a bit at my vm configs: the idea is to test whatever is packaged by the distro, except for ubuntus where I add the stable ppa
[08:32] <vila> and this rule is not fully enforced for windows and osx (but well, I'm just adding osx to the mix)
[08:32] <vila> this is partly due to hudson requiring a system-wide available bzr to bootstrap the jobs
[08:33] <vila> so I'm not super keen on introducing possible failures there... and setting up alternative install of bzr kind of defeat the purpose of testing -proposed, so this will require different vms...
[08:35] <vila> said otherwise: there are ways to inject -proposed in babune but any failure there will induce significant fallouts
[08:35] <vila> which may be a good thing... or not at all
[08:37] <poolie> ok
[08:37] <poolie> well, maybe we should wait for the existing ones to stabilize more
[08:38] <vila> what do you mean ?
[08:38] <spiv> Ok, I should finish work for the day.  Happy weekend (and happy travelling if appropriate)!
[08:38] <poolie> to get all the existing jobs continuously green
[08:38] <jbowtie> Hey, hey, I'm in bzr-core!  I feel happy!
[08:39] <poolie> thanks spiv, have a good weekend, thanks for the updates on the bugs
[08:39] <poolie> keep status-ing :)
[08:39] <poolie> congrats!
[08:39] <vila> poolie: ha right, yes, that why I just added osx now that windows is close to green
[08:40] <poolie> vila, so i think the thing to do is: boot a vm that's configured to use maverick-proposed; aptitude upgrade; run bzr selftest; see what happens
[08:40] <vila> poolie: I had a hudson plugin that was re-running some failures automatically but it stopped working, I didn't find the time to disagnose that one
[08:40] <poolie> i don't know how hard this is to put into hudson but it's only a few shell commands so it seems it shouldn't be all that hard
[08:41] <vila> oh, *that* shouldn't be hard, right, but that's indeed adding other vm
[08:42] <vila> poolie: But I did this test manually... can't remember when
[08:42] <poolie> they're pretty cheap though
[08:42] <poolie> at least if they can be shut down when they're not actually running
[08:42] <poolie> which test?
[08:43] <vila> running selftest from a ppa installed bzr
[08:43] <vila> you make me doubt now...
[08:44] <vila> ha no, -proposed not a ppa, meh
[08:47] <poolie> ah, you've tested 2.2.1 that way?
[08:47] <poolie> then you should say so on the bug...
[08:51] <vila> poolie: no, I did test from the stable ppa not from the -proposed pocket
[08:52] <vila> poolie: sry for the confusion
[08:53] <vila> poolie: meh, bug you already did the test yourself if I read bug 636930 correctly right ?
[08:54] <vila> oh, you want one more verification
[08:58] <poolie> right
[08:59] <vila> why didn't you start with that ? :-p
[09:00] <poolie> sorry :)
[09:00] <vila> hehe, kidding
[09:06] <Ng> hrm
[09:06] <Ng> today's maverick package update just failed because of bzr whoami
[09:06] <Ng> which would presumably be because I have etckeeper installed
[09:06] <Ng> have we managed to yet convince people that requiring identity to commit is bad, harmful and wrong?
[09:07] <GaryvdM> Ng: To fix I did :
[09:07] <GaryvdM> sudo -i
[09:07] <vila> poolie: grumble, subunit/testtools bugs, can't run -proposed on hudson
[09:07] <spiv> Ng: have we managed to yet get etckeepr to take care of setting one for you? ;)
[09:07] <GaryvdM> bzr whoami "Root <root@hostname>"
[09:08] <Ng> spiv: my laptop having a failed apt transaction suggests not
[09:08] <GaryvdM> Which is a work around...
[09:08] <Ng> and you question answers mine that we continue to fail :(
[09:09] <Ng> please change bzr's behaviour, this is madness
[09:10] <jpds> Ng: Is that not bug #616878 ?
[09:10] <Ng> jpds: it very likely is
[09:10] <GaryvdM> You can't keep everybody happy :-/
[09:11] <vila> Ng: what do you think will be faster: issuing 'bzr whoami "junk <me@exmaple.com>"' or getting an updated bzr in maverick ?
[09:11] <Ng> even a change in behaviour to s/error/warn/ for id 0 would be something
[09:11] <spiv> Or more precisely perhaps bug 647475
[09:11] <spiv> I suggest grabbing poolie at UDS
[09:12] <vila> Ng: not that we shouldn't *refuse* to change bzr behaviour, just proposing you a workaround to address your problem *now*
[09:13] <Ng> vila: sure, a workaround is no problem for me at all, but tools that build on bzr, like etckeeper, are very likely to be used by people who don't understand (or indeed care) the ins and outs of this, which is why I asserted that changing the behaviour in this way is bad, harmful and wrong
[09:14] <Ng> it probably seems very correct from a perspective of develoeprs working on code where every bzr interaction is human driven, but that's not the full reality of bzr's usage
[09:15] <Ng> I will gladly talk to pooli e about it at UDS :)
[09:15] <vila> Ng: I indeed use bzr unattended and find it good to know where a commit is coming from
[09:16] <Ng> vila: I use bzr more with robots than people and username@hostname was fine for me
[09:19] <poolie> ng, i may even fix it on the plain
[09:19] <poolie> especially if you tell me what you think a good tradeoff would be
[09:19] <poolie> s//plane
[09:19] <vila> Ng: then I suggest you contribute to bug #647475 or bug #616878 both of which give a good summary of the issues
[09:19] <poolie> i guess you want to go back to just no check, no warning?
[09:19] <poolie> would it be reasonable to rely on /etc/mailname being set?
[09:22] <Ng> poolie: so ultimately the limit of my real caring is breaking automated root committing, so I'd be happy if it would notice it was running as uid 0 and just warn, then go with root@hostname
[09:22] <Ng> erroring for users is, I think, a bit annoying, but it's way less likely to break critical things like package transactions
[09:24] <vila> Why isn' etckeeper setting the proper default ? Istm we're bikeshedding about what bzr default should be with a conflict between protecting unaware users of the consequences and third-party tools on top of bzr using it in an unusual way (running as root)
[09:25] <Ng> vila: it's not bikeshedding dude, bikeshedding is arguing about trivial details, this is me advocating for people whose critical systems are being broken by a significant change of behaviour
[09:26] <vila> Ng: the fix was about addressing a problem seen as critical by other users, so I still call it bikeshedding as far as different users want different defaults
[09:32] <Ng> vila: I think your characterisation of bug #549310 is misleading, it's not described as critical, it was not assigned a critical bug status and the requested just asked for a warning to be printed
[09:35] <GaryvdM> Ok - this is really bike sheading: For a new qlog option: --show-wt or --show-trees?
[09:35] <lifeless> --show-iterables
[09:35] <vila> GaryvdM: --show-trees
[09:41] <peitschie> garyvdm: +1 for show trees
[09:42] <vila> Ng: well, this has been discussed in other places than here, and I was the one setting it to Wishlist at first. Nobody changed its status but it's hardly relevant now. Can we focus on what the problem is and the various ways it could be addressed ?
[09:44] <vila> Ng: critical for bzr is only used for bugs that should block a release (including data loss for example), *not* for that kind of problems which could be addressed by explicitly setting a default with a single bzr command
[09:44] <Ng> vila: I think my suggestion for handling uid=0 cases takes care of the most obviously dangerous scenarios
[09:45] <Ng> I'd be happy to repeat that suggestion as bug commentary
[09:45] <vila> Ng: thanks
[09:46] <Ng> :)
[09:49] <poolie> ng hang on, you're saying we shouldn't have fixed 5493
[09:49] <poolie> 549310
[09:49] <poolie> because it's not critical?
[09:49] <poolie> thanks for talking about this btw
[09:49] <poolie> oh, nm, i see you're disputing vila calling it critical
[09:50] <Ng> poolie: indeed, I'm all for encouraging users to set good metadata, I just think the fix went too far
[09:52] <Ng> perhaps bzr could notice that it's not attached to a terminal and not error, but that sounds like a potential rats nest of fragility
[09:56] <poolie> Ng would a warning rather than an error be ok?
[09:57] <Ng> poolie: I think at one point james expressed a preferences for it to warn once only. Wearing an ubuntu user hat, if a warning stops things like etckeeper commits from failing, then yes
[10:05] <jbowtie> Two more bug fixes and bzr-tfs should be good enough to use with codeplex, should make jelmer happy.
[10:09] <poolie> nice one
[10:09] <poolie> good night all
[10:10] <GaryvdM> Night poolie. Travel well, and enjoy uds!
[10:10] <vila> poolie: night !
[10:15] <jbowtie> poolie: Good night.
[13:20] <Tak> when using the command api, is there any point to calling cleanup_now() ?
[13:50] <gthorslund> when moving around between versions is there any advantage of doing "bzr revert -r <revno>" instead of "bzr update -r <revno>"? with revert "bzr version-info" doesn't get updated, while it does with update.
[14:14] <maxb> gthorslund: revert is primarily useful if you wanted to commit the old tree state as a new revision, e.g. to back out changes
[14:15] <maxb> update is normally more useful for inspecting previous tree states, plus it will retain local modifications in your tree whilst you traverse through history
[14:18] <gthorslund> maxb: so for a plugin like bzr-bisect it would make more sense to use update then? appears it's using revert now and then version-info fails.
[14:18] <maxb> Indeed.
[14:19] <maxb> AFAIK, bisect uses revert purely because 'bzr update -r' was not implemented until recently
[14:19] <gthorslund> maxb: thx. I'm looking at that plugin anyway. I'll look at writing a bug report + patch later.
[14:19] <gthorslund> have to go now
[14:24] <GaryvdM> How do you fix a Conflicting tags error?
[14:25] <GaryvdM> I have established that the tag is wrong in my branch, correct in the parent
[14:26] <GaryvdM> So I want to pull the tag from the parent.
[14:28] <maxb> GaryvdM: pull --overwrite will do it, if you're happy for all that entails
[14:28] <maxb> otherwise, locally delete the selected tags you don't want, then pull
[14:28] <maxb> erm
[14:28] <maxb> s/don't want/know to be wrong/
[14:29] <GaryvdM> maxb: thanks - --overwrite did the trick.
[15:42] <abentley> jam, does history_db use PQM or should I just push to trunk?
[15:42] <jam> abentley: just push trunk
[15:43] <abentley> jam, what happens if I specify a history_db, but that db doesn't have any information about my branch?
[15:43] <jam> it gets populated
[15:45] <abentley> jam, is history-db-create optional?
[15:45] <abentley> jam, or is it needed to create the database if it doesn't exist?
[15:45] <jam> abentley: yes, but faster for the initial import
[15:45] <jam> I'm not sure what happens if the file itself doesn't exist
[16:36] <RenatoSilva> what is bzr+ssh exactly? how does it work exactly?
[16:36] <LeoNerd> It ssh's to the server, and runs 'bzr serve' as a remote command over SSH
[16:37] <RenatoSilva> bzr serve, not bzr <the-desired-command>?
[16:42] <LeoNerd> Correct..
[16:42] <LeoNerd> E.g. if you   bzr branch bzr+ssh://....     there's no point running  bzr branch  on the server, because the new workspace needs to be written on the client.
[16:43] <LeoNerd> So, it ssh's to the server, and runs  bzr serve  which acts as a remote agent for the (local) bzr to talk to; taking commands on stdin, issuing responses on stdout.
[16:51] <RenatoSilva> complicated...
[16:52] <LeoNerd> It's a fairly simple way to do it, really. A lot of tools do things this way. svn's ssh support did that. My own IPC::PerlSSH does that; it ssh's to the server and runs "perl" to accept a program on STDIN
[16:52] <LeoNerd> It means you only have to open the ssh port, and most servers already have that, and the ssh server itself doesn't have to understand anything special. It already has all the user auth, for example.
[16:58] <RenatoSilva> I definitely don't understand, it may be easier but I don't get it :(
[16:59] <RenatoSilva> Maybe someday I'll see step by step or so, but now...I just can't grok it
[17:00] <RenatoSilva> I use putty on windows and my private key is protected by password, ssh on Linux doesn't have password protection, besides it'd be necessary to export the ppk to ssh format, creating two files for the same thing
[17:01] <RenatoSilva> I'd like to use putty on linux exactly the same way I do on windows, or at least use the ppk on linux (some other program to load it after asking passowrd)
[17:07] <jbunting> i'm not very familiar with putty's private key handling, but does adding a passphrase to your private key on linux not do what you want?
[17:08] <RenatoSilva> does ssh on linux support protecting the key with a password? In putty, I just click over the file and it shows a dialog asking the password, and in linux, how is that?
[17:09] <maxb> ssh-keygen -p -f I think
[17:11] <LeoNerd> It's called a passphrase.
[17:11] <LeoNerd> But yes, either supply one when you generate the key, or you can alter an existing one as maxb suggests
[17:15] <maxb> And frankly, I blame Putty for not supporting openssh's key format
[17:15] <LeoNerd> Yeah. It's very annoying. I had to jump thruogh many hoops to put a PuTTY SSH key on my phone
[17:16] <RenatoSilva> maxb: so when I do bzr push lp:project it will ask me the password in the terminal?
[17:17] <LeoNerd> passphrase.  Perhaps. Depends if you're using an agent, and if it's loaded into it
[17:17] <LeoNerd> But this is now just a general "how to use SSH" question, and not directly the fault or control of bzr itself
[17:18] <maxb> I assume so. Personally I've never tried it that way. I always load my key into ssh-agent so I don't have to enter the passphrase once per connection
[17:18] <LeoNerd> Yeah.. it gets very tedious very quickly :)
[17:18] <RenatoSilva> how to tell bzr to use "the ssh agent"? In windows it's BZR_SSH=plink for putty's agent
[17:18] <LeoNerd> (though, less so in bzr because e.g. the branch is still local..)
[17:18] <LeoNerd> It should just happen automatically
[17:19] <RenatoSilva> automatically? bzr guesses it's meant to use ssh?
[17:19] <vila> RenatoSilva: bzr on linux (but tell us which one you use if you want more precise answers) relies on openssh. Configuring the ssh agent there is... generally taken into account by your distro
[17:20] <RenatoSilva> sorry for the offtopic but just one more question? does "ssh-agent" / ubuntu  have a GUI interface for loading keys?
[17:21] <RenatoSilva> ok will reboot to linux, brb...
[17:21] <LeoNerd> ssh-add  without a tty ought to do that, but easier just to run   ssh-add
[17:21] <maxb> Recent Ubuntu will run a GNOME reimplementation of the ssh agent which does have all manner of GUI nonsense
[17:22] <maxb> However, I like the CLI much better, so can't tell you much about that :-)
[17:22] <LeoNerd> Also, the CLI has much less cope for a security attack
[17:22] <LeoNerd> If "some GUI box" pops up and asks for your passphrase, and you neter it... how did you know it wasn't a Javascript box on some webpage, or whatever?
[17:22] <vila> LeoNerd, maxb: You mean you use 'ssh-add <key>' only ?
[17:22] <LeoNerd> If you see it in the very xterm you ran 'ssh-add' from, there's a much greater chance of it being legit
[17:23] <LeoNerd> vila: Yes. See my reason above
[17:23] <maxb> vila: Well, no, I mean my .bash_profile does stuff for me :-)
[17:23] <vila> maxb: your.... where do you get the passphrase from ? smart card ?
[17:24]  * vila keep for himself that he just add some 'ssh-add' for passwordless keys in a cron job :D
[17:25] <maxb> My .bash_profile inspects .ssh/* and builds a list of keys, and invokes eval `keychain --eval $keys`
[17:25] <maxb> keychain then ensures an agent is available and invokes ssh-add
[17:25] <maxb> I then get prompted either on the console or via pinentry-gtk for the passphrase
[17:26] <vila> what is keychain ?
[17:26] <vila> not installed here apparently
[17:26] <maxb> keychain is a manager for ssh-agent
[17:27] <vila> an equivalent to seahorse then ?
[17:27] <maxb> It will inherit a running ssh-agent from the environment, or start a new one if not found, and then write the necessary envvars to a file, so that future invocations of keychain can then reload the environment in another session
[17:27] <maxb> So basically "find me my running ssh agent or make a new one if necessary"
[17:28] <maxb> plus, inspect the ssh-agent for what keys are loaded, and load any that are missing
[17:29] <vila> oh, right, synaptic is telling me about it, thanks for the pointer
[17:30] <vila> hmmm, so that allows you to run cron jobs under password protected keys
[17:31] <vila> maxb: I have a corner case that isn't covered here: I need to start a daemon on reboot, so there is noone to type the passphrase... any idea ? (I've gove with passwordless keys but...)
[17:33] <maxb> right, no other solution there
[17:33] <maxb> ideally the passwordless keys will have forced command restrictions on the other end
[17:34] <vila> hmm
[17:36] <mgz> hey all.
[17:38] <vila> mgz: hey !
[17:39] <vila> maxb: anyway, I will re-think about it now that I see what keychain offer
[17:41] <mgz> vila, does <https://code.launchpad.net/~gagern/bzr/bug663773-help-requires-testtools/+merge/38926> look okay to you?
[17:42] <vila> argh, totally forgot about this one
[17:42] <mgz> also, a second review on <https://code.launchpad.net/~jared-bunting/bzr/644990-win32-path-length-check/+merge/39104> and I'll land that as well.
[17:43] <vila> hmm, I think I'm vaguely uncomfortable splitting the command in its own file instead of digging a bit more for lazy loading but... so little time
[17:45] <mgz> importing bzrlib.tests.script will import bzrlib.tests because that's how packages work
[17:45] <mgz> and bzrlib.tests *can't* lazy import testtools
[17:45] <mgz> it needs it for class definitions and such like.
[17:46] <vila> mgz: thanks, that's the bit I wanted to check
[17:47] <vila> mgz: pff, tell what you want, a good regexp for the jared patch will be *far* clearer :-p
[17:49] <mgz> :D
[17:52] <vila> mgz: we need a commit message for the jared patch, I can't summarize the fix there... my english fails :-/
[17:52] <mgz> I'm doing it.
[17:53] <vila> well, let's be honest, the patch is too small for me to understand where this is used ;-)
[17:58] <mgz> done done done, thanks vila.
[17:59] <jbunting> and thanks to you both
[18:00] <vila> jbunting: hey ! Thanks for the fix :)
[18:49] <dooferlad> Hi, I have a bzr-svn checkout that I am having trouble with - the file contents doesn't match an svn checkout of the same trunk.
[18:50] <dooferlad> I assume I am having trouble pulling the latest changes from the server. I have been using bzr pull
[19:44] <peitschie_> mornin all :)
[20:34] <vila> mgz: sorry, I was on other subjects this week and couldn't find the time to discuss about the transport hook. I just saw you put in mp into wip, does this mean you get new ideas ?
[20:34] <vila> s/in mp/your mp/
[20:35] <mgz> vila: decided to think about the testcase collection branch first, then come back to it
[20:36] <mgz> I still need to absorb jam's post on the mailing list
[20:36] <vila> :-/
[20:36] <vila> mgz: which thread ?
[20:36] <jam> mgz: basic idea, just add a per-transport test that the connect hook gets called
[20:37] <vila> jam: I think bzrlib.tests.commands is full of tests ensuring that the connect hook is called
[20:38] <vila> not proper unit tests though
[20:38] <jam> vila: mgz was saying explicitly that he was having problems getting smart transport to fire the hook
[20:38] <jam> so add a per transport hook
[20:38] <jam> s/hook/test/
[20:39] <vila> ha, but smart transport doesn't respect the specific part we're interested in there, but let me read your mail first as I lack the context
[20:39] <jam> vila: I haven't followed in detail either, but as I understand it:
[20:39] <vila> which means I may be misunderstanding you
[20:39] <jam> 1) we want to make sure the test suite cleans up after it connects
[20:39] <vila> right
[20:39] <jam> 2) we want to use a hook so we know what was connected so we know what to disconnect
[20:39] <vila> right
[20:39] <jam> 3) add a test that ConnectTransport classes call the hook
[20:39] <jam> 4)?
[20:39] <jam> 5) profit
[20:40] <vila> yeah, but the evil is in the details
[20:40] <vila> The proposal as it is can fit the definition you gave above
[20:41] <vila> mgz, jam: In which thread could I find this mail, I have some backlog :-/
[20:41] <mgz> vila: the original one about sorting out get_transport
[20:41] <vila> mp or ml discussion ?
[20:41] <mgz> list, sec, I'll find it in the online archive
[20:42] <mgz> https://lists.ubuntu.com/archives/bazaar/2010q4/070670.html
[20:42] <vila> thxs
[20:43] <vila> ha, right
[20:43] <vila> the problem here is that we'd like to put it on the transport object, but the smart transport one define the connection point in code that doesn't get access to the transport object itself: the medium
[20:44] <vila> hence the nudge to spiv to shed some light here, but AIUI he has been pretty busy with quite a nasty bug
[20:45] <vila> This means we can't just put a hook here since we require a transport object to call the disconnect() method
[20:46] <vila> jam: and you know mgz, if we embed a transport reference in the medium and/or the connection object, he willl run all over the place yelling: 'ref cycles ! ref cycles !!!!'
[20:46] <mgz> :)
[20:48] <mgz> spiv did give some useful pushback on that front, I might scale the branch back to a big list of weakrefs and a gc.collect call.
[20:52] <vila> mgz: I still haven't understood where the cycle occur which a bit frustrating (as in: If I don't grok this one, how could I know if I'm introducing cycles without realizing it)
[20:53] <vila> and how on earth do you say 'without realizing it' in a shorter form in English ?
[20:53] <mgz> unwittingly?
[20:53] <fullermd> Cycles just mean the bits of code are friendly with each other.  Who can be opposed to friendly code?
[20:54] <dash> it's like how you aren't supposed to date people in your office
[20:54] <fullermd> That's a pretty unpleasant prohibition if you work at home...
[20:55] <mgz> I agree it can be pretty obscure, but there are really not many places that do it, and most would be clearer written another way (eg, rather than putting testcase instance methods on an object instance to override, use a subclass
[20:55] <mgz> )
[20:55] <fullermd> (Though actually, back when I worked in an office and dated somebody in it, it worked out OK)
[20:56] <vila> Indeed, who said you can't date in your office ?
[21:00] <vila> mgz: can't you just add cleanup for these instances methods (yeah, yeah, I know, I know, not the same, but still) or are they needed *after* the cleanups are called (define another cleanup list in this case ;-p)
[21:00] <mgz> I have been!
[21:02] <vila> Can't you also replace the ugly except/finally by a simpler call so that the ugly construct is defined only once with a loooong docstring ?
[21:02] <vila> mgz: You have been... what ?
[21:02] <vila> :)
[21:04] <mgz> adding cleanups for the tests that do slightly odd things with bound methods
[21:04] <vila> ha, right, sorry, not sure I read the last diff :-(
[21:05] <mgz> I've only done try/finally in a few cases where the code just wants to get ripped out later anyway, and for lock decorators where I can't think of a better idea.
[21:06] <vila> mgz: I'm not against the construct itself (I trust you about breaking the cycle this way, it's just that I'd like to *see* it), it's about its repetition in several places
[21:07] <vila> It spread FUD, literally :)
[21:07] <mgz> yeah, but, blame the existing lock decorator code for that, has the same thing four times.
[21:07] <vila> mgz: one more reason to address it in a cleaner way :-D
[21:10] <mgz> patches welcome! :p
[21:10] <vila> mgz: The underlying fear in my case is that closure create cycles in an unexpected (to me) way
[21:10] <vila> mgz: you're right, I should do that
[21:11] <vila> mgz: except you're taking my offer to collaborate on one mp and divert it to *another* mp which is... border line ? :-D
[21:11] <mgz> right, I think that's a small but potentially valid fear, hence the testing for that and printing if a test isn't freed
[21:12] <mgz> not caring about it unless a big gc at the end doesn't shift the test is the other option
[21:12] <vila> mgz: Well, all I can say at this point is that this sounds a lot like: mp author: "We need this because X", reviewer: "Why not Y instead", author . o O (You have no idea about what X means, don't you ?)
[21:14] <aaronfay> Hello all, just started looking at bazaar.  I'm interested in the push ftp feature, and I'm trying to stage an existing Wordpress setup with bzr.  I guess my question is: can I have bzr ftp files into an existing scenario?
[21:16] <mgz> aaronfay: yes. it's not nessersarily the best way of doing deployment, but it can work.
[21:18] <aaronfay> mgz: Thanks, I'm green with bazaar, longtime svn user.  This is probably not the best way to deploy sites, I know.  My problem is: I'm a django developer but more and more I'm working on client wordpress sites.  I generally don't have shell access, so I need a sane way to manage versioning themes/plugins/etc.  I've known I needed to switch to a dvcs anyway...
[21:21] <mars> abentley, ping, if you have a moment, I have a question about bzr send with pipelines
[21:21] <vila> aaronfay: lp:bzr-upload
[21:21] <abentley> mars: sure.
[21:22] <mars> abentley, so I've done this before: 'bzr send -r ancestor::prev..'.  Is it supposed to set the prerequisite branch on the merge proposal for me?
[21:22] <aaronfay> vila: fantastic, thank you.
[21:23] <rocky> is there an easy way to see what the date/time was that a revision was pulled into a branch (not the original date/time of the actual revision)
[21:23] <vila> aaronfay: feedback welcome
[21:23] <abentley> mars: no.  Prerequisite branches are a Launchpad thing, not a Bazaar thing.  The Bazaar merge directive format does not support them.  I recommend using lp-propose.
[21:25] <mars> abentley, great, thanks
[21:26] <mars> abentley, so lp-propose understands pipelines?  Or is there some other mechanism linking the two branches?
[21:28] <abentley> mars: lp-propose provides hooks that bzr-pipeline uses to set the prerequisite branch to the previous pipe.
[21:28] <mars> ah, cool
[21:30] <abentley> mars: It's all a bit cute, because it's my own code cooperating with my own code.
[21:31] <mars> abentley, its well worth it.  bzr-pipeline is awesome
[21:31] <abentley> mars: I'm glad you like it.
[21:32] <peitschie_> rocky: no clue here sorry
[22:07] <konr> why do you personally use bzr?
[22:09] <dash> konr: 'cause it's the best
[22:09] <dash> obviously.
[22:10] <konr> haha
[22:10] <konr> But Git has github, in which you can post your photo and have friends and followers!
[22:11] <dash> launchpad's better.
[22:11] <peitschie_> +1 for launchpad
[22:11] <peitschie_> issue tracking & integration with bzr is very handy
[22:12] <peitschie_> other big plus is the low barrier to mods through the rather nice bzr plugin system
[22:13] <peitschie_> took me about an hr to figure out how to write a few basic plugins
[22:13] <peitschie_> which have since easily been worth the time spent writing them :)
[22:18] <Kobaz> i find launchpad to be a bit slow
[22:21] <dash> i don't mind, i am too.
[22:44] <RenatoSilva> why does bzr branch lp:project work if I have no key loaded in ssh-agent?
[22:48] <RenatoSilva> it's http not ssh? it defaults to http transport if no ssh key is loaded, that's it?
[22:49] <Kamping_Kaiser> i'd have expected it to use bzr:// if bzr+ssh isn't available
[22:49] <Kamping_Kaiser> but i'm not ina position to answer your question
[22:50] <RenatoSilva> it's worse actually, even after ssh-add, I can't push to Launchpad
[22:53] <RenatoSilva> I was missing bzr launchpad-login (I thought my private key would act as identifier but ok)
[22:53] <fullermd> Launchpad doens't serve bzr://
[22:54] <konr> oh god, 300mb and Emacs's repo is still at 68/113 :(
[22:55] <RenatoSilva> anyhow I'd like to understand this, in windows bzr doesn't default to http, but here in linux it does
[22:55] <Kamping_Kaiser> fullermd: really? i'm supprised but ok :)
[22:57] <RenatoSilva> hmmm it was because of launchpad-login, if it's empty then bzr uses http it seems
[22:57] <fullermd> Yes, that's how the lp: lookup chooses.
[23:02]  * RenatoSilva pushed succesfully his tool for using ppk keys in linux: https://code.launchpad.net/~renatosilva/+junk/loadppk
[23:09] <aaronfay> vila: what is the advantage of bzr_upload vs bzr push sftp://...
[23:12] <aaronfay> I'm seeing now that push sftp isn't doing what I want.  I see it's created a directory remotely, but there are no files in it
[23:12] <RenatoSilva> how to delete a lp branch from bzr?
[23:18] <aaronfay> Hmm, ok, using both push sftp and push ftp (--create-prefix) I see the folder is created, but no files are added, any recommendations?
[23:23] <fullermd> Push pushes the VCS info, not the working tree files.
[23:24] <aaronfay> fullermd: Thanks for clarifying that.  What is the advantage/purpose of that?
[23:25] <fullermd> I...   um...   I don't know how to answer that.   :)
[23:25] <aaronfay> vila: Fantastic plugin, I like the 'using saved location' feature.  That's what you call a time saver :)
[23:25] <fullermd> That's just what it's for...
[23:25] <aaronfay> fullermd: Hmm, no worries, I'm sure it will become apparent to me down the road
[23:26] <fullermd> It's the dual to pull.  Pull is for syncing the local branch to a branch $THERE, push is for syncing a branch $THERE to the local branch.
[23:26] <aaronfay> But not the files?
[23:27] <vila> aaronfay: pushing the VCS info (the .bzr directory) is publishing the whole history of your project, if it's behind an http server, everybody able to reach your site can download it
[23:27] <vila> aaronfay: bzr-upload, by contrast, only upload the working tree and *none* of the history
[23:28] <aaronfay> Okay, I see
[23:28] <aaronfay> bzr-upload isn't a branch then
[23:28] <aaronfay> So it would be safe to say I could create a branch remotely with both push and bzr-upload
[23:28] <vila> aaronfay: if you want *both* then bzr-upload is not the solution, you want bzr-push-and-update (but this requires ssh access AFAIR)
[23:28] <aaronfay> Okay, makes sense
[23:29] <aaronfay> Thanks for the clarification
[23:29] <vila> aaronfay: 'using saved location' was 100% borrowed from bzr itself :)
[23:30] <vila> push/pull/update/missing/merge/send and I forget some certainly, all use the same principle
[23:30] <aaronfay> vila: as a cheat, could you "bzr push <location>" and then "bzr upload <location>" ?  That would effectively upload the .bzr folder and the files, correct?
[23:31] <aaronfay> I'm having trouble finding paramiko, is my problem
[23:31] <vila> aaronfay: yes
[23:31] <aaronfay> vila: Okay, sounds like a good scenario for fab
[23:31] <vila> aaronfay: OS/bzr versions ?
[23:31] <vila> fab ?
[23:31] <aaronfay> vila: XP sp3 (fab -> fabric)
[23:32] <aaronfay> vila: bzr 2.2.1
[23:33] <vila> aaronfay: if you use the bzr installer, paramiko should be included... jam, GaryvdM or bialix or any windows user will answer that better than me
[23:34] <aaronfay> vila: fabric is a python library for deploying stuff/automating stuff.  It will SSh and do all kinds of funky stuff, basically you set up a fab.py file, write a couple functions (that can do thinks locally or remotely) and then you run (for example) fab update
[23:34] <vila> aaronfay: but it's rather unusual to upload the wroking tree *AND* push the branch
[23:34] <aaronfay> vila: the 'update' function might commit local changes, log into a server, and then svn up the changes remotely, delete a few things, etc, all in one command
[23:34] <vila> aaronfay: as soon as you have access via ssh on the server, 1) use a smart server, 2) update the working tree locally
[23:35] <aaronfay> vila: my issue is: I need to be able to push files to a server I don't have ssh access to, and it would be equally nice to leave a copy of the branch there for future usage if possible
[23:35] <vila> aaronfay: just use hooks either in the bzr client or the bzr server, if you're already writing python code, you'll feel at home and get access to all the needed objects
[23:36] <aaronfay> vila: in most cases I can't run bzr server :(
[23:36] <vila> aaronfay: you'd better push the branch in another place
[23:36] <aaronfay> vila: Thanks for your input, I have a much clearer idea where to start now.  Cheers
[23:36] <vila> aaronfay: if you have an ssh shell access and can run bzr there, you already have a bzr server
[23:37] <aaronfay> vila: sorry, can you elaborate on the last part?
[23:37] <vila> aaronfay: there is *nothing* to configure
[23:37] <aaronfay> vila: how do you "start" it?  Or do you serve it over apache?
[23:37] <vila> aaronfay: all the client has to know is where bzr is on the remote side if it's not in default path
[23:38] <vila> aaronfay: roughly: 'ssh <server> bzr serve' is launched on the client and we send commands and receive answers
[23:39] <vila> aaronfay: so if you have a branch in your home directory at example.com you do: bzr branch bzr+ssh://example.com/~/my/branch
[23:40] <aaronfay> vila: Okay, very good to know
[23:40] <vila> aaronfay: if bzr is not in the default path you do: BZR_REMOTE_PATH=/path/on/remote/bzr bzr branch bzr+ssh://example.com/~/my/branch
[23:40] <vila> aaronfay: or the equivalent on windows
[23:41] <aaronfay> Heh, this is very fantastic, I'm quite excited about Bazaar.
[23:42] <aaronfay> Thanks again for all your input.
[23:42] <vila> Always happy to help (tm jam)
[23:43]  * vila off to bed 8-/