[02:24] 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? === khmarbaise_ is now known as khmarbaise [10:31] parthm: ping [10:32] !paste [10:32] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [10:33] vila: hi [10:33] parthm: hey ! [10:34] parthm: do you remember bug #376388 [10:34] Launchpad bug 376388 in bzr (Ubuntu) "~/.bazaar created owned by root (when run under sudo) (affected: 4, heat: 20)" [Low,Confirmed] https://launchpad.net/bugs/376388 [10:35] vila: yes. [10:36] I think I introduced a regression with my fix for bug #525571 [10:36] Launchpad bug 525571 in Bazaar Subversion Plugin "No locking when updating files in ~/.bazaar (affected: 6, heat: 52)" [High,In progress] https://launchpad.net/bugs/525571 [10:36] i.e. when merging the fix from 2.0 -> 2.1 -> 2.2 the merge lost the copy_ownership call [10:37] I think the fix should b as simple as http://paste.ubuntu.com/463416/ [10:38] So I was wondering if you could look into reproducing it and confirm the regression [10:39] vila: sure. i can look at that later today. i can propose a merge in case there is a regression. [10:39] 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] parthm: thanks a lot [10:39] parthm: My main concern here is that the test suite didn't catch the regression [10:40] 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] vila: thats true. test suite should have caught it. [10:41] * parthm looks at old merge proposal [10:42] 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] chown [10:43] 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] vila: yes. the test cases basically monkey patch and check that chown is being called. [10:43] parthm: anyway, thanks for looking into it ! [10:43] vila: np. [10:44] ha, yeah, I remember I wasn't so happy with that :-) [10:44] vila: yup. we had a long discussion :) [10:45] 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] *to( emulate [10:45] *to* emulate [10:46] 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] hi parthm, vila [10:50] poolie: hi [10:50] parthm: 2.2 should be the target [10:50] vila: will do. [10:50] poolie: hey :-P === Meths_ is now known as Meths === Meths_ is now known as Meths [14:04] poolie: ping [14:07] hi parthm [14:08] poolie: regarding bug #605098 for bzr-grep ... did you happen to check your bzr-grep version? [14:08] Launchpad bug 605098 in bzr-grep "ignore binary files (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/605098 [14:08] i did, i was just out of date [14:08] i closed it [14:09] just now [14:09] poolie: ok. cool. [14:09] on really big trees it's much faster than grepping the working tree [14:09] that's pretty cool [14:10] poolie: :) i recently added -p/--diff to grep changesets. if you are using trunk you could try that too. [14:11] i will [16:09] if i push to launchpad how can i prevent this to happen: [16:09] Created new stacked branch referring to /~mozillateam/firefox/firefox-4.0.head. [16:09] ? [16:13] asac: bzr init the location, bzr reconfigure --unstacked the location, then push [16:13] is one way [16:16] lets try [16:16] just to repeat how much i disagree with the not-being-able-to-easily-prevent branch format attitude [16:17] s/format/format upgrades/ [16:18] hell [16:18] i have a good branch with old format still [16:18] and whenever i push it it stacks and converts on the fly [16:18] even though locally its not even stackable [16:18] bzr reconfigure --unstacked [16:18] 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] 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] This may take some time. Upgrade the repositories to the same format for better performance. [16:19] bzr: interrupted bzr info [16:19] Repository tree (format: pack-0.92) [16:19] Well, FWIW, that conversion is essentially free... [16:19] it is not [16:19] its not pack-0.92 anymore [16:19] and hardy users cant branch it [16:19] without enabling ppas etc [16:19] It is in every way that counts, data-wise. [16:19] these kind of transitions of default have to wait until hardy is EOL [16:20] 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] 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] Oh, sure, that's a valid reason. But the cost of the conversion is almost immeasurable among that group. [16:20] then you shouldnt do this kind of default switch until the new branch format is out by at least 3 reasons [16:21] _I_'m not making any sort of switch. I don't have anything to do with LP. [16:21] its not launchpad [16:21] at least i think [16:21] Yes it is, it's LP forcing a stackable format. [16:21] afaik bzr switch to the new default [16:21] Well, not _forcing_, but making it fair bits of work to avoid. [16:21] 1.6 was NEVER a default format. The default format went straight from pack-0.92 to 2a. [16:21] i cant avoid it it seems [16:21] how can i do that? [16:22] i want to avoid it [16:22] I don't know offhand. I'm pretty sure it can be done, but it may require manual fiddling. [16:22] manual fiddling on launchpad side? [16:23] or on my side? [16:23] fullermd: thanks for clarifying though :/ [16:23] On your side. I think reconfigure SHOULD be able to do it. [16:24] no its not [16:24] my local branch is not stacked at all [16:24] Not on your local branch. On the lp branch. [16:24] bzr reconfigure --unstacked [16:24] 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] bzr reconfigure --unstacked lp:whatever [16:24] the online branch doesnt exist [16:25] i want to push to a new location [16:25] and it lways gets stacked [16:25] let me see [16:25] Yeah. As mwhudson said, use 'init' to create an empty branch at that new location first, reconfigure, then push. [16:25] cool [16:26] 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] 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] doesnt work: [16:27] bzr init --pack-0.92 lp:~mozillateam/firefox/firefox-3.7.head [16:27] Created a standalone branch (format: unnamed) [16:27] asac@tinya:/tmp/new$ bzr reconfigure --unstacked lp:~mozillateam/firefox/firefox-3.7.head [16:27] 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] IIRC branch6 is what you expect from pack-0.92, so that sounds right. [16:27] 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] fullermd: but when i push my pack 0.92 branch now it gets a) stacked and by converted on-the-fly [16:28] Not on lp:~mozillateam/firefox/firefox-3.7.head; pack-0.92 isn't stackable. [16:29] % bzr info nosmart+lp:~mozillateam/firefox/firefox-3.7.head [16:29] Standalone branch (format: pack-0.92) [16:29] hmm. that remove init seemed to have helped indeed [16:29] let me see what comes back when i do a fresh branch (once the push has finished) [16:30] LP does a lot of magic, so you need a pretty big hammer like that to keep it from enstacking things. [16:34] i will go and fight this ;) (if i have engery left ;)) [16:34] but i guess its too late now ... the harm is most likely done for many branches already [16:35] i am happy if i can safe just th e mozillateam branches for now ;) [16:35] Well, I DO get all twitchy at the thought of people running bzr's that can't read 1.6 ;p [16:36] yes. as i said. it doesnt give a professional and mature impression [16:36] i think bzr developers could have helped by not declaring 2.0a the default until its much older [16:36] that might have prevented launchpad to jump on it ;) [16:36] but thats just me [16:36] thanks a bunch fullermd and mwhudson [16:49] Well, you're not having LP jump to 2a here ;) === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [20:27] how can I delete some changes I've shelved? [20:34] thrope: try bzr help shelve [20:34] rubbs: i tried ... it didnt say anything [20:34] I believe there is a --destroy option [20:34] in the end I unshelved them and reverted [20:34] thats only when you are doing the shelving [20:34] nothing about deleting existing shalves [20:34] but it would have been a pain if there were other changes that I didnt want them to mix with [20:34] ah, sorry [20:35] right. [21:44] bzr: ERROR: gnomekeyring.IOError: [21:44] wth does that mean? [21:44] besides "no, you don't get to do a pull on that remote machine", of course [21:47] 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] 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] lamont: well bzr tries not to be interactive so it can be used as a library [21:51] the key needs to be unlocked before bzr can use it [21:58] 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] lamont: I think you can use ssh-agent [22:00] http://mah.everybody.org/docs/ssh [22:00] something like that [22:01] rubbs: I could, and I won't [22:02] I see no reason to give root on the remote machine access to my ssh key [22:04] 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] 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] but I could have misunderstood that [22:04] 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] ah, yeah - agent forwarding hands the keys over [22:05] 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] np. [22:06] I think just ssh-agent will unlock the key in local memory. bzr will not forward the key IIRC [22:06] but I can't tell you that for sure [22:07] yeah - if it did, we'd have beaten them already, I suspect. [22:07] right. that's what I was thinking. [22:08] but I can't definitively tell you yes or no on that question [22:08] I understand people's aversion to security issues. [22:09] aversion may not have been the right word, but I think you know what I mean [22:52] bug 605574 looks like a python 2.7 regression in xmlrpclib at first blush [22:52] Launchpad bug 605574 in Bazaar "impossible to branch from web (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/605574 [23:41] hello [23:41] can i pull/push to hg branches?