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? | 02:24 |
---|---|---|
=== khmarbaise_ is now known as khmarbaise | ||
vila | parthm: ping | 10:31 |
vila | !paste | 10:32 |
ubot5 | 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:32 |
parthm | vila: hi | 10:33 |
vila | parthm: hey ! | 10:33 |
vila | parthm: do you remember bug #376388 | 10:34 |
ubot5 | 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:34 |
parthm | vila: yes. | 10:35 |
vila | I think I introduced a regression with my fix for bug #525571 | 10:36 |
ubot5 | 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 |
vila | i.e. when merging the fix from 2.0 -> 2.1 -> 2.2 the merge lost the copy_ownership call | 10:36 |
vila | I think the fix should b as simple as http://paste.ubuntu.com/463416/ | 10:37 |
vila | So I was wondering if you could look into reproducing it and confirm the regression | 10:38 |
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:39 |
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:40 |
parthm | vila: thats true. test suite should have caught it. | 10:41 |
* parthm looks at old merge proposal | 10:41 | |
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:42 |
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:43 |
vila | ha, yeah, I remember I wasn't so happy with that :-) | 10:44 |
parthm | vila: yup. we had a long discussion :) | 10:44 |
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:45 |
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:46 |
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 | 10:50 |
=== Meths_ is now known as Meths | ||
=== Meths_ is now known as Meths | ||
parthm | poolie: ping | 14:04 |
poolie | hi parthm | 14:07 |
parthm | poolie: regarding bug #605098 for bzr-grep ... did you happen to check your bzr-grep version? | 14:08 |
ubot5 | Launchpad bug 605098 in bzr-grep "ignore binary files (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/605098 | 14:08 |
poolie | i did, i was just out of date | 14:08 |
poolie | i closed it | 14:08 |
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:09 |
parthm | poolie: :) i recently added -p/--diff to grep changesets. if you are using trunk you could try that too. | 14:10 |
poolie | i will | 14:11 |
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:09 |
mwhudson | asac: bzr init the location, bzr reconfigure --unstacked the location, then push | 16:13 |
mwhudson | is one way | 16:13 |
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:16 |
asac | s/format/format upgrades/ | 16:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
fullermd | Not on lp:~mozillateam/firefox/firefox-3.7.head; pack-0.92 isn't stackable. | 16:28 |
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:29 |
fullermd | LP does a lot of magic, so you need a pretty big hammer like that to keep it from enstacking things. | 16:30 |
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:34 |
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:35 |
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:36 |
fullermd | Well, you're not having LP jump to 2a here ;) | 16:49 |
=== beuno is now known as beuno-lunch | ||
=== beuno-lunch is now known as beuno | ||
thrope | how can I delete some changes I've shelved? | 20:27 |
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:34 |
rubbs | right. | 20:35 |
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:44 |
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:47 |
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:48 |
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:51 |
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' | 21:58 |
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:00 |
lamont | rubbs: I could, and I won't | 22:01 |
lamont | I see no reason to give root on the remote machine access to my ssh key | 22:02 |
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:04 |
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:05 |
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:06 |
lamont | yeah - if it did, we'd have beaten them already, I suspect. | 22:07 |
rubbs | right. that's what I was thinking. | 22:07 |
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:08 |
rubbs | aversion may not have been the right word, but I think you know what I mean | 22:09 |
mgz | bug 605574 looks like a python 2.7 regression in xmlrpclib at first blush | 22:52 |
ubot5 | Launchpad bug 605574 in Bazaar "impossible to branch from web (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/605574 | 22:52 |
Stavros | hello | 23:41 |
Stavros | can i pull/push to hg branches? | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!