[02:24] <michaelh> Hi there.  I recently did a commit/push but forgot to tag the commit as fixing a Launchpad hosted bug.  What's the best way of doing a --fixes after the commit?
[10:31] <vila> parthm: ping
[10:32] <vila> !paste
[10:33] <parthm> vila: hi
[10:33] <vila> parthm: hey !
[10:34] <vila> parthm: do you remember bug #376388
[10:35] <parthm> vila: yes.
[10:36] <vila> I think I introduced a regression with my fix for bug #525571
[10:36] <vila> i.e. when merging the fix from 2.0 -> 2.1 -> 2.2 the merge lost the copy_ownership call
[10:37] <vila> I think the fix should b as simple as http://paste.ubuntu.com/463416/
[10:38] <vila> So I was wondering if you could look into reproducing it  and confirm the regression
[10:39] <parthm> vila: sure. i can look at that later today. i can propose a merge in case there is a regression.
[10:39] <vila> Second, I don't clearly remember the constraints around calling copy_ownership, I think the file should exist but otherwise how did you minimize the races ?
[10:39] <vila> parthm: thanks a lot
[10:39] <vila> parthm: My main concern here is that the test suite didn't catch the regression
[10:40] <vila> I know we need to run as root to be able to setup a test context and I think we may want to file a bug asking for a specialized test suite that requires running as root (handwaving a bit)
[10:41] <parthm> vila: thats true. test suite should have caught it.
[10:41]  * parthm looks at old merge proposal
[10:42] <vila> parthm: I think the issue is that normal users can't run chwon to give ownership to someone else, so you can't test such things
[10:42] <vila> chown
[10:43] <vila> hence we need to run such tests as root, but I know some other tests should *not* be run as root or they will fail :)
[10:43] <parthm> vila: yes. the test cases basically monkey patch and check that chown is being called.
[10:43] <vila> parthm: anyway, thanks for looking into it !
[10:43] <parthm> vila: np.
[10:44] <vila> ha, yeah, I remember I wasn't so happy with that :-)
[10:44] <parthm> vila: yup. we had a long discussion :)
[10:45] <vila> parthm: in retrospect, tracking the chown calls looks like a good way to run the tests without being root, maybe there is a way to enrich the injected version so emulate the behavior we want
[10:45] <vila> *to( emulate
[10:45] <vila> *to* emulate
[10:46] <parthm> vila: yes. considering that the regression was not caught the tests could probably use some improvement. i will see if i can think of something.
[10:50] <poolie> hi parthm, vila
[10:50] <parthm> poolie: hi
[10:50] <vila> parthm: 2.2 should be the target
[10:50] <parthm> vila: will do.
[10:50] <vila> poolie: hey :-P
[14:04] <parthm> poolie: ping
[14:07] <poolie> hi parthm
[14:08] <parthm> poolie: regarding bug #605098 for bzr-grep ... did you happen to check your bzr-grep version?
[14:08] <poolie> i did, i was just out of date
[14:08] <poolie> i closed it
[14:09] <poolie> just now
[14:09] <parthm> poolie: ok. cool.
[14:09] <poolie> on really big trees it's much faster than grepping the working tree
[14:09] <poolie> that's pretty cool
[14:10] <parthm> poolie: :) i recently added -p/--diff to grep changesets. if you are using trunk you could try that too.
[14:11] <poolie> i will
[16:09] <asac> if i push to launchpad how can i prevent this to happen:
[16:09] <asac> Created new stacked branch referring to /~mozillateam/firefox/firefox-4.0.head.
[16:09] <asac> ?
[16:13] <mwhudson> asac: bzr init the location, bzr reconfigure --unstacked the location, then push
[16:13] <mwhudson> is one way
[16:16] <asac> lets try
[16:16] <asac> just to repeat how much i disagree with the not-being-able-to-easily-prevent branch format attitude
[16:17] <asac> s/format/format upgrades/
[16:18] <asac> hell
[16:18] <asac> i have a good branch with old format still
[16:18] <asac> and whenever i push it it stacks and converts on the fly
[16:18] <asac> even though locally its not even stackable
[16:18] <asac> bzr reconfigure --unstacked
[16:18] <asac> bzr: ERROR: The branch 'file:///home/asac/Development/ubuntu/mozillateam/firefox-3.7.head/'(Branch format 6) is not a stackable format. You will need to upgrade the branch to permit branch stacking.
[16:18] <asac> bzr push lp:~mozillateam/firefox/firefox-3.7.head/Doing on-the-fly conversion from RepositoryFormatKnitPack1() to RemoteRepositoryFormat(_network_name='Bazaar RepositoryFormatKnitPack5 (bzr 1.6)\n').
[16:19] <asac> This may take some time. Upgrade the repositories to the same format for better performance.
[16:19] <asac> bzr: interrupted                                                           bzr info
[16:19] <asac> Repository tree (format: pack-0.92)
[16:19] <fullermd> Well, FWIW, that conversion is essentially free...
[16:19] <asac> it is not
[16:19] <asac> its not pack-0.92 anymore
[16:19] <asac> and hardy users cant branch it
[16:19] <asac> without enabling ppas etc
[16:19] <fullermd> It is in every way that counts, data-wise.
[16:19] <asac> these kind of transitions of default have to wait until hardy is EOL
[16:20] <asac> you are too focussed on bzr and the data. i am focussed on the user and the reputation bzr gets by this kind of experience
[16:20] <fullermd> pack-0.92, 1.6, and 1.9 are all practically the same in terms of the data for the revisions/texts/etc.
[16:20] <fullermd> Oh, sure, that's a valid reason.  But the cost of the conversion is almost immeasurable among that group.
[16:20] <asac> then you shouldnt do this kind of default switch until the new branch format is out by at least 3 reasons
[16:21] <fullermd> _I_'m not making any sort of switch.  I don't have anything to do with LP.
[16:21] <asac> its not launchpad
[16:21] <asac> at least i think
[16:21] <fullermd> Yes it is, it's LP forcing a stackable format.
[16:21] <asac> afaik bzr switch to the new default
[16:21] <fullermd> Well, not _forcing_, but making it fair bits of work to avoid.
[16:21] <fullermd> 1.6 was NEVER a default format.  The default format went straight from pack-0.92 to 2a.
[16:21] <asac> i cant avoid it it seems
[16:21] <asac> how can i do that?
[16:22] <asac> i want to avoid it
[16:22] <fullermd> I don't know offhand.  I'm pretty sure it can be done, but it may require manual fiddling.
[16:22] <asac> manual fiddling on launchpad side?
[16:23] <asac> or on my side?
[16:23] <asac> fullermd: thanks for clarifying though :/
[16:23] <fullermd> On your side.  I think reconfigure SHOULD be able to do it.
[16:24] <asac> no its not
[16:24] <asac> my local branch is not stacked at all
[16:24] <fullermd> Not on your local branch.  On the lp branch.
[16:24] <asac> bzr reconfigure --unstacked
[16:24] <asac> 17:18 < asac> bzr: ERROR: The branch 'file:///home/asac/Development/ubuntu/mozillateam/firefox-3.7.head/'(Branch format 6) is not a stackable format. You will need to  upgrade the branch to permit branch stacking.
[16:24] <fullermd> bzr reconfigure --unstacked lp:whatever
[16:24] <asac> the online branch doesnt exist
[16:25] <asac> i want to push to a new location
[16:25] <asac> and it lways gets stacked
[16:25] <asac> let me see
[16:25] <fullermd> Yeah.  As mwhudson said, use 'init' to create an empty branch at that new location first, reconfigure, then push.
[16:25] <asac> cool
[16:26] <fullermd> Actually, maybe if you init --pack-0.92, it won't bother trying to setup a stack in the first place since that format isn't stackable.
[16:26] <mwhudson> asac: the messages from bzr can be a bit deceptive, it might not actually be stacked even if it looks like its saying it is
[16:27] <asac> doesnt work:
[16:27] <asac> bzr init --pack-0.92 lp:~mozillateam/firefox/firefox-3.7.head
[16:27] <asac> Created a standalone branch (format: unnamed)
[16:27] <asac> asac@tinya:/tmp/new$ bzr reconfigure --unstacked lp:~mozillateam/firefox/firefox-3.7.head
[16:27] <asac> bzr: ERROR: The branch 'bzr+ssh://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.7.head/'(Remote: Branch format 6) is not a stackable format. You will need to upgrade the branch to permit branch stacking.
[16:27] <fullermd> IIRC branch6 is what you expect from pack-0.92, so that sounds right.
[16:27] <asac> mwhudson: well. all i know is that when i push to the new place it upgrades on the fly because it thinks it is stacked
[16:27] <asac> fullermd: but when i push my pack 0.92 branch now it gets a) stacked and by converted on-the-fly
[16:28] <fullermd> Not on lp:~mozillateam/firefox/firefox-3.7.head; pack-0.92 isn't stackable.
[16:29] <fullermd> % bzr info nosmart+lp:~mozillateam/firefox/firefox-3.7.head
[16:29] <fullermd> Standalone branch (format: pack-0.92)
[16:29] <asac> hmm. that remove init seemed to have helped indeed
[16:29] <asac> let me see what comes back when i do a fresh branch (once the push has finished)
[16:30] <fullermd> LP does a lot of magic, so you need a pretty big hammer like that to keep it from enstacking things.
[16:34] <asac> i will go and fight this ;) (if i have engery left ;))
[16:34] <asac> but i guess its too late now ... the harm is most likely done for many branches already
[16:35] <asac> i am happy if i can safe just th e mozillateam branches for now ;)
[16:35] <fullermd> Well, I DO get all twitchy at the thought of people running bzr's that can't read 1.6  ;p
[16:36] <asac> yes. as i said. it doesnt give a professional and mature impression
[16:36] <asac> i think bzr developers could have helped by not declaring 2.0a the default until its much older
[16:36] <asac> that might have prevented launchpad to jump on it ;)
[16:36] <asac> but thats just me
[16:36] <asac> thanks a bunch fullermd and mwhudson
[16:49] <fullermd> Well, you're not having LP jump to 2a here  ;)
[20:27] <thrope> how can I delete some changes I've shelved?
[20:34] <rubbs> thrope: try bzr help shelve
[20:34] <thrope> rubbs: i tried ... it didnt say anything
[20:34] <rubbs> I believe there is a --destroy option
[20:34] <thrope> in the end I unshelved them and reverted
[20:34] <thrope> thats only when you are doing the shelving
[20:34] <thrope> nothing about deleting existing shalves
[20:34] <thrope> but it would have been a pain if there were other changes that I didnt want them to mix with
[20:34] <rubbs> ah, sorry
[20:35] <rubbs> right.
[21:44] <lamont> bzr: ERROR: gnomekeyring.IOError:
[21:44] <lamont> wth does that mean?
[21:44] <lamont> besides "no, you don't get to do a pull on that remote machine", of course
[21:47] <rubbs> lamont: I'm not an expert but that looks like gnomekeyring isn't able to unlock the ssh key that bzr is looking for.
[21:48] <lamont> not terribly surprising, since it's a remote session.  then again, one would hope for a prompt or some such before it threw its hands in the air
[21:51] <rubbs> lamont: well bzr tries not to be interactive so it can be used as a library
[21:51] <rubbs> the key needs to be unlocked before bzr can use it
[21:58] <lamont> rubbs: and lacking a gui to talk to gnome, and a lacking a clue how to do it outside of gnome, I'm left with 'oh well'
[22:00] <rubbs> lamont: I think you can use ssh-agent
[22:00] <rubbs> http://mah.everybody.org/docs/ssh
[22:00] <rubbs> something like that
[22:01] <lamont> rubbs: I could, and I won't
[22:02] <lamont> I see no reason to give root on the remote machine access to my ssh key
[22:04] <rubbs> I was unaware that ssh-agent did that. I'm not an ssh expert, or really a bzr one for that matter. just trying to point out what I think was the problem
[22:04] <rubbs> i was under the impression that ssh-agent only held keys in local memory, and only with agent-forwarding turned on did it forward those keys to the remote
[22:04] <rubbs> but I could have misunderstood that
[22:04] <lamont> rubbs: if you pass your agent to a remote machine, root on that machine can access the agent.  this might not be quite what you want.
[22:05] <lamont> ah, yeah - agent forwarding hands the keys over
[22:05] <lamont> that's usually what I've seen people be referring to when they start talking about ssh-agent... my bad for jumping to the conclusion
[22:05] <rubbs> np.
[22:06] <rubbs> I think just ssh-agent will unlock the key in local memory. bzr will not forward the key IIRC
[22:06] <rubbs> but I can't tell you that for sure
[22:07] <lamont> yeah - if it did, we'd have beaten them already, I suspect.
[22:07] <rubbs> right. that's what I was thinking.
[22:08] <rubbs> but I can't definitively tell you yes or no on that question
[22:08] <rubbs> I understand people's aversion to security issues.
[22:09] <rubbs> aversion may not have been the right word, but I think you know what I mean
[22:52] <mgz> bug 605574 looks like a python 2.7 regression in xmlrpclib at first blush
[23:41] <Stavros> hello
[23:41] <Stavros> can i pull/push to hg branches?