| nilg` | hi, how to set append-revisions-only otherwise than at init? | 05:59 |
|---|---|---|
| spiv | With bzr config | 06:00 |
| spiv | Something like 'bzr config append_revisions_only=true' | 06:00 |
| nilg` | thanks a lot! | 06:01 |
| nilg` | spiv: I've done that on my local branch but how do I do the change on the global one? | 06:10 |
| nilg` | when I try to commit it tells that there is no change to commit | 06:10 |
| nilg` | same thing when I try to push | 06:11 |
| LarstiQ | nilg`: you can do `bzr config -d bzr+ssh://server/path/to/remote append_revisions_only=true` | 06:13 |
| nilg` | awesome, thx | 06:14 |
| LarstiQ | nilg`: and then when you try to push a change that would reorder commits, you'd get: bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/tmp/foo/". | 06:16 |
| LarstiQ | nilg`: do you know the `bzr missing` command btw? | 06:17 |
| nilg` | nsoi010 | 06:30 |
| nilg` | wrong window... | 06:30 |
| nilg` | useful thanks | 06:32 |
| nilg` | hmmm, it didn't work, I can still "violate causality" | 06:43 |
| LarstiQ | nilg`: ok, how did you do that? | 06:52 |
| LarstiQ | nilg`: does `bzr config -d remote/branch` show append_revisions_only is correctly set? | 06:54 |
| nilg` | it seems so | 06:56 |
| nilg` | locations: | 06:56 |
| nilg` | [lp:opencoglp:opencog] | 06:56 |
| nilg` | append_revisions_only = True | 06:56 |
| nilg` | 06:56 | |
| nilg` | then I branch a revision before | 06:58 |
| nilg` | bzr branch -r6777 opencog opencog_r6777 | 06:58 |
| nilg` | (opencog contained lp:opencog actually) | 06:58 |
| nilg` | then committed something so it reaches revision 6778 | 06:58 |
| nilg` | then bzr merge | 06:59 |
| nilg` | then bzr commit -m "merge" | 06:59 |
| nilg` | and finally bzr push lp:opencog | 06:59 |
| LarstiQ | nilg`: what did you merge where? | 07:00 |
| nilg` | now the last commit of the trunk (that was at 6778) has been replaced by my fraudulent commit at r6778 as well + the merge | 07:00 |
| LarstiQ | I see | 07:01 |
| spiv | Huh | 07:01 |
| spiv | append_revisions_only in locations.conf? I'm not sure that works | 07:01 |
| spiv | It's a branch.conf thing | 07:01 |
| LarstiQ | spiv: aah | 07:01 |
| LarstiQ | vila: do you recall config issue with setting branch.conf on lp: ? | 07:01 |
| spiv | (You may also need to double-check I got the config option name correct, I'm not sure how careful 'bzr config' is to warn) | 07:02 |
| LarstiQ | spiv: I tested that part locally, it works | 07:02 |
| nilg` | bzr there's something weird with the tag | 07:02 |
| nilg` | [lp:opencoglp:opencog] | 07:02 |
| nilg` | see the snippet of bzr config -d lp:opencog that I pasted above | 07:03 |
| spiv | nilg`: yes, that's funny too | 07:03 |
| nilg` | ho, lol, I wanted to say BTW, not bzr | 07:03 |
| spiv | nilg`: anyhow, try, 'bzr config --scope=branch ...' | 07:03 |
| spiv | nilg`: (after all, you presumably want this set for everyone using the branch on LP, not just for yourself) | 07:04 |
| * spiv -> afk | 07:04 | |
| vila | LarstiQ: well, yeah, but 2.5.0 should have all the fixes | 07:04 |
| nilg` | spiv: in for everybody | 07:04 |
| vila | the section name is indeed weird but that means it shouldn't apply to *any* branch | 07:05 |
| vila | what does 'bzr config -d lp:opencog' display ? | 07:06 |
| vila | (I don't think lp:opencog is even a valid section name....) | 07:06 |
| nilg` | "section name"? | 07:06 |
| vila | [<section name>] | 07:07 |
| nilg` | here's the output of bzr config -d lp:opencog | 07:11 |
| nilg` | http://pastebin.com/iRpKwqhB | 07:11 |
| vila | right | 07:12 |
| vila | so, this means 'bzr config' doesn't interpret lp:opencog *at all*, | 07:12 |
| nilg` | so I guess a fix of that would be to take the bzr+ssh... address, right? | 07:13 |
| vila | there is no 'branch:' part and locations.conf is matched just because the substring appears in the section name | 07:13 |
| vila | yup | 07:13 |
| vila | but as spiv mentioned, you'd better set append_revisions_only in the relevant branch.conf | 07:13 |
| LarstiQ | right | 07:14 |
| LarstiQ | nilg`: so for now a workaround is to do that with hitchhiker | 07:15 |
| LarstiQ | vila: unless you have a better idea on how to get it set on launchpad? | 07:15 |
| vila | huh ? If nilg` has write access to the branch, 'bzr config -d bzr+ssh://...' should work just fine | 07:15 |
| nilg` | vila: you mean no need of --scope=branch? | 07:16 |
| nilg` | I do have write access | 07:16 |
| LarstiQ | ok, so just not use the lp: shorthand | 07:16 |
| vila | yup, by default branch.conf is where the modifications go | 07:17 |
| vila | LarstiQ: yup | 07:17 |
| LarstiQ | and I see bug 957049 is already filed | 07:18 |
| ubot5 | Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049 | 07:18 |
| vila | LarstiQ: ha damn, my memory is flaky coming back from vacations ;( | 07:19 |
| nilg` | bzr config -d lp:opencog is still given me the same output | 07:19 |
| LarstiQ | vila: I know the feeling | 07:19 |
| nilg` | even if I set it to false | 07:19 |
| vila | nilg`: don't use the lp: shortcut | 07:19 |
| LarstiQ | vila: any idea how to tackle the bug? | 07:20 |
| nilg` | http://pastebin.com/ApAA7EEg | 07:20 |
| nilg` | oh, sure... | 07:21 |
| LarstiQ | nilg`: right, so `bzr config -d bzr+ssh://bazaar.launchpad.net/+branch/opencog/` | 07:21 |
| LarstiQ | should now show it | 07:21 |
| nilg` | it does ;-) | 07:21 |
| LarstiQ | good, good :) | 07:22 |
| LarstiQ | nilg`: ok, so toggle to true, try the merge test again? | 07:22 |
| nilg` | so before (with lp:opencog) I was writing somewhere else? | 07:22 |
| LarstiQ | I'm confident that will work, but better safe than sorry | 07:22 |
| LarstiQ | nilg`: yeah, to ~/.bazaar/locations.conf | 07:22 |
| LarstiQ | ehm | 07:22 |
| LarstiQ | if I'm not mistaken | 07:23 |
| vila | LarstiQ: from the top of my head, it probably means url aliases should all be tried to match but there are probably nasty fallouts | 07:23 |
| LarstiQ | vila: ok | 07:24 |
| nilg` | just to be sure (before I try) http://pastebin.com/BxrAS8vY | 07:24 |
| LarstiQ | nilg`: that looks good | 07:26 |
| nilg` | woohoo | 07:26 |
| nilg` | bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "chroot-66248080:///%2Bbranch/opencog/".') | 07:26 |
| nilg` | 07:26 | |
| nilg` | it works, thanks a lot guys | 07:26 |
| LarstiQ | nilg`: sorry it took so long | 07:26 |
| LarstiQ | nilg`: for the record, which bzr version are you using? | 07:27 |
| nilg` | Bazaar (bzr) 2.5.0 | 07:27 |
| nilg` | 07:27 | |
| LarstiQ | ok | 07:28 |
| nilg` | I can paste the whole output on pastebin if you want | 07:28 |
| LarstiQ | nilg`: nah, just wanted to make sure I'm not looking at the wrong version of the code for bughunting | 07:28 |
| vila | nilg`: what would be even better is to https://bugs.launchpad.net/bzr/+bug/957049/+affectsmetoo and explain that the bug leads to a confusing behavior | 07:29 |
| ubot5 | Ubuntu bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] | 07:29 |
| * LarstiQ runs the testsuite with a 'directory = directory_service.directories.dereference(directory)' thrown in | 07:36 | |
| mgz | morning all! | 07:59 |
| mgrandi | morn | 07:59 |
| LarstiQ | hey mgz, mgrandi | 08:15 |
| vila | mgz: o/ | 08:18 |
| * vila upgrades his last desktop to precise | 08:22 | |
| mgz | vila: when you're done with the upgrade, LarstiQ wants some help writing a config test, see bug 957049 mp | 09:03 |
| ubot5 | Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049 | 09:03 |
| * vila nods @ mgz, LarstiQ | 09:30 | |
| LarstiQ | vila: cheers. I keep not knowing what to do with the mps, should I resubmit, ask for a new review on this one, submit an entirely new one? | 09:56 |
| vila | LarstiQ: I think mgz landed it so wait for it to land and submit a new one | 09:57 |
| mgz | has landed, so a new one is fine | 09:57 |
| LarstiQ | k, just a moment | 09:57 |
| mgz | generally in response to review comments, just pushing up to the same branch and saying what you've changed in comment is fine | 09:58 |
| LarstiQ | mgz: except if it has already landed? | 09:58 |
| mgz | right, but you could still use the same local branch and just push it to a new location on lp | 09:59 |
| * LarstiQ nods | 10:00 | |
| LarstiQ | mgz: or well, I'm even using the same branch on lp for https://code.launchpad.net/~larstiq/bzr/xdg-config/+merge/104078 | 10:00 |
| LarstiQ | and after this I'm _really_ getting lunch :) | 10:01 |
| vila | LarstiQ: wrong target for the proposal ;) You want 2.5 not trunk ? | 10:05 |
| LarstiQ | vila: doh, you are right | 10:05 |
| vila | LarstiQ: sorry about that ;) | 10:05 |
| LarstiQ | vila: np. Just a sec while I retarget | 10:06 |
| LarstiQ | vila: done | 10:07 |
| mgz | vila: that branch failed on pqm, or there was some other issue? | 10:55 |
| vila | let me check | 10:55 |
| vila | hmm, no mail... | 10:56 |
| vila | ha, damn laptop | 10:57 |
| vila | the mail was blocked locally | 10:57 |
| vila | unblocked | 10:58 |
| natosha | Hello. Is there a more detailed developers guide than http://doc.bazaar.canonical.com/developers/HACKING.html ? Specifically, I am trying to figure out how, internally, Bazaar manages to so gracefully handle case collisions while merging. | 13:04 |
| natosha | I thought I'd ask here if there is more detailed documentation before starting to look at the source. | 13:05 |
| wgz | natosha: try <http://doc.bazaar.canonical.com/developers/case-insensitive-file-systems.html> | 13:09 |
| natosha | wgz, thanks, that gets me closer | 13:12 |
| === yofel_ is now known as yofel | ||
| james_w | maxb, hi, did you re-enable the cron job? | 14:17 |
| maxb | I did | 14:17 |
| maxb | I should have emailed about that | 14:18 |
| james_w | thanks | 14:18 |
| james_w | np | 14:18 |
| james_w | I went to do it and saw it was already done, so wanted to check it was you, or that you knew about it | 14:18 |
| maxb | We appear to have a new failure kind spiking, unfortunatly | 14:22 |
| maxb | It looks to me like a bug in bzr-builddeb | 14:23 |
| maxb | We get a LockContention during a set_tag operation, when it's trying to tag a new upstream version | 14:23 |
| maxb | I'm assuming someone's done something wrong with locking conventions surrounding use of a DistributionBranch | 14:24 |
| james_w | I don't remember any recent changes related to that though? | 14:25 |
| maxb | But I've had a hard time figuring out exactly what the intended use is, regarding the two trees and two branches you instantiate a DistributionBranch with | 14:25 |
| james_w | not that I've inspected all the changes closely | 14:25 |
| maxb | I don't either, but we're definitely seeing the rise of a new failure signature | 14:25 |
| james_w | yeah | 14:26 |
| james_w | "only" 80 instances, but that's probably just those that have had an update right? | 14:27 |
| maxb | Looks like it. Or, it may only be happening when the importer does a temporary re-import to test a collision | 14:29 |
| LarstiQ | newly exposed failure case maybe? | 14:30 |
| maxb | Quite possibly a codepath walked more in assessing branches newly copied to a new series | 14:32 |
| james_w | is Branch.lock_write() re-entrant? | 14:34 |
| maxb | If it's re-entrant at all, it would only be on the same Branch object | 14:49 |
| james_w | yeah | 14:49 |
| james_w | I'm wondering if it's that we're calling it twice, or that we have two references to the same branch | 14:50 |
| jam | james_w: lock_write and lock_read are concurrent (you can call lock_read on a branch which is in lock_write state, but you can't call lock_write if it started as lock_read) | 14:57 |
| james_w | jam, what about two lock_writes? | 14:58 |
| jam | james_w: fine as long as it is the same object, yes | 14:58 |
| james_w | thanks | 14:58 |
| mgz | you're meant to be queening jam! | 15:02 |
| LarstiQ | hah :) | 15:02 |
| * mgz isn't sure what this involves, something strange and dutch | 15:03 | |
| LarstiQ | mgz: with markets starting at 5 or 6 in the morning at this time of day it's enough to relax :) | 15:03 |
| mgz | ...getting up at 5 or 6 to go shopping doesn't sound like a holiday | 15:04 |
| LarstiQ | mgz: http://en.wikipedia.org/wiki/Koninginnedag#Activities has some hints | 15:04 |
| LarstiQ | mgz: shopping? Selling! :) | 15:04 |
| * LarstiQ heads home | 15:07 | |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| mgorny | is the size information while bzr fetches accurate? | 19:48 |
| mgorny | because I fail to understand why it downloads 740M (and time it takes suggests it does that indeed) while the resulting repo takes 140M | 19:49 |
| lifeless | what network protocol are you using ? | 19:53 |
| mgorny | lp:s25rttr | 19:58 |
| mgorny | no firewall so I guess whatever the default is | 19:58 |
| lifeless | mgorny: so that could be either ssh or http depending on whether you've done 'bzr lp-login' | 19:58 |
| lifeless | erm, that might be bzr launchpad-login, I forget. | 19:58 |
| mgorny | no login | 19:58 |
| lifeless | so, its going over HTTP | 19:58 |
| mgorny | and it seems to clone the repo via bzr branch | 19:59 |
| lifeless | which means its basically doing a virtual file system access to the branch data. | 19:59 |
| lifeless | logging in should make it massively faster. | 19:59 |
| lifeless | the repository may well need a pack as well, if its currently bloated at 700M | 19:59 |
| mgorny | bzr does autorepack after fetching? | 20:00 |
| mgorny | the proto seems to be very suboptimal | 20:00 |
| mgorny | and logging in is not a case, unless we're going to force random no of Gentoo users to create launchpad accounts | 20:01 |
| lifeless | why would random no of gentoo users be branching in the first place ? | 20:01 |
| mgorny | because of random no of upstreams using bzr for their programs, and users fetching sources then | 20:02 |
| lifeless | would tarballs work better for you ? | 20:02 |
| mgorny | for me yes | 20:03 |
| mgorny | I was mostly wondering whether we are doing something wrong | 20:03 |
| mgorny | I'm a git person and it looks weird to me to use 'branch' command to clone a repo | 20:03 |
| mgorny | but if it's upstream no-repack fault or proto limitation, I guess we can't do much | 20:03 |
| mgorny | just replace live-source ebuilds with snapshots | 20:04 |
| lifeless | so the smart streaming protocol is much more efficient | 20:04 |
| lifeless | http://bazaar.launchpad.net/~flosoft/s25rttr/trunk/tarball/head: | 20:04 |
| lifeless | should get you a tarball | 20:04 |
| mgorny | sadly, that won't work for us | 20:04 |
| mgorny | because tarballs have to be manifested with checksums | 20:05 |
| mgorny | and live tarballs = live checksums | 20:05 |
| mgorny | but we'll try to find something | 20:05 |
| * mgorny will just run a cruciate for git :P | 20:05 | |
| lifeless | so the tarball is 40M | 20:07 |
| lifeless | much less data | 20:07 |
| lifeless | you could create an account for gentoo downloads, with a single shared ssh key, and share that around; a bit awful, but as long as that was never given write privileges probably tolerable | 20:08 |
| mgorny | yes, though about that too. if it's launchpad tolerable then it's probably worth considering. i'd ask someone first to check whether that actually benefits us, however. | 20:09 |
| mgorny | thanks for the patience. | 20:09 |
| lifeless | we have a requested feature to run the streaming protocol over http | 20:09 |
| lifeless | but noone has had the time to glue it all together. | 20:10 |
| lifeless | the repository is a bit poorly packed atm, but not -terrible- | 20:10 |
| lifeless | I'd file a bug on bzr, 700M is unreasonable given the size of repository. | 20:10 |
| lifeless | mgorny: ^ | 20:10 |
| mgorny | ok. I'll just try to get someone to reproduce that first however/ | 20:12 |
| mgorny | thanks. I'll file it tomorrow or the day after tomorrow. good night. | 20:14 |
| lifeless | cool | 20:16 |
| maxb | We have a nasty bug in the Launchpad packaging branch uptodate check that's going to bite everyone accessing a precise branch of anything | 21:28 |
| maxb | Apparently the packaging uptodate check doesn't follow stacking properly | 21:28 |
| fullermd | Lucky for me I only ever deal with vague branches. | 21:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!