] [07:11] here's the output of bzr config -d lp:opencog [07:11] http://pastebin.com/iRpKwqhB [07:12] right [07:12] so, this means 'bzr config' doesn't interpret lp:opencog *at all*, [07:13] so I guess a fix of that would be to take the bzr+ssh... address, right? [07:13] there is no 'branch:' part and locations.conf is matched just because the substring appears in the section name [07:13] yup [07:13] but as spiv mentioned, you'd better set append_revisions_only in the relevant branch.conf [07:14] right [07:15] nilg`: so for now a workaround is to do that with hitchhiker [07:15] vila: unless you have a better idea on how to get it set on launchpad? [07:15] huh ? If nilg` has write access to the branch, 'bzr config -d bzr+ssh://...' should work just fine [07:16] vila: you mean no need of --scope=branch? [07:16] I do have write access [07:16] ok, so just not use the lp: shorthand [07:17] yup, by default branch.conf is where the modifications go [07:17] LarstiQ: yup [07:18] and I see bug 957049 is already filed [07:18] Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049 [07:19] LarstiQ: ha damn, my memory is flaky coming back from vacations ;( [07:19] bzr config -d lp:opencog is still given me the same output [07:19] vila: I know the feeling [07:19] even if I set it to false [07:19] nilg`: don't use the lp: shortcut [07:20] vila: any idea how to tackle the bug? [07:20] http://pastebin.com/ApAA7EEg [07:21] oh, sure... [07:21] nilg`: right, so `bzr config -d bzr+ssh://bazaar.launchpad.net/+branch/opencog/` [07:21] should now show it [07:21] it does ;-) [07:22] good, good :) [07:22] nilg`: ok, so toggle to true, try the merge test again? [07:22] so before (with lp:opencog) I was writing somewhere else? [07:22] I'm confident that will work, but better safe than sorry [07:22] nilg`: yeah, to ~/.bazaar/locations.conf [07:22] ehm [07:23] if I'm not mistaken [07:23] 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:24] vila: ok [07:24] just to be sure (before I try) http://pastebin.com/BxrAS8vY [07:26] nilg`: that looks good [07:26] woohoo [07:26] 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] [07:26] it works, thanks a lot guys [07:26] nilg`: sorry it took so long [07:27] nilg`: for the record, which bzr version are you using? [07:27] Bazaar (bzr) 2.5.0 [07:27] [07:28] ok [07:28] I can paste the whole output on pastebin if you want [07:28] nilg`: nah, just wanted to make sure I'm not looking at the wrong version of the code for bughunting [07:29] 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] Ubuntu bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] [07:36] * LarstiQ runs the testsuite with a 'directory = directory_service.directories.dereference(directory)' thrown in [07:59] morning all! [07:59] morn [08:15] hey mgz, mgrandi [08:18] mgz: o/ [08:22] * vila upgrades his last desktop to precise [09:03] vila: when you're done with the upgrade, LarstiQ wants some help writing a config test, see bug 957049 mp [09:03] Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049 [09:30] * vila nods @ mgz, LarstiQ [09:56] 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:57] LarstiQ: I think mgz landed it so wait for it to land and submit a new one [09:57] has landed, so a new one is fine [09:57] k, just a moment [09:58] 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] mgz: except if it has already landed? [09:59] right, but you could still use the same local branch and just push it to a new location on lp [10:00] * LarstiQ nods [10:00] mgz: or well, I'm even using the same branch on lp for https://code.launchpad.net/~larstiq/bzr/xdg-config/+merge/104078 [10:01] and after this I'm _really_ getting lunch :) [10:05] LarstiQ: wrong target for the proposal ;) You want 2.5 not trunk ? [10:05] vila: doh, you are right [10:05] LarstiQ: sorry about that ;) [10:06] vila: np. Just a sec while I retarget [10:07] vila: done [10:55] vila: that branch failed on pqm, or there was some other issue? [10:55] let me check [10:56] hmm, no mail... [10:57] ha, damn laptop [10:57] the mail was blocked locally [10:58] unblocked [13:04] 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:05] I thought I'd ask here if there is more detailed documentation before starting to look at the source. [13:09] natosha: try [13:12] wgz, thanks, that gets me closer === yofel_ is now known as yofel [14:17] maxb, hi, did you re-enable the cron job? [14:17] I did [14:18] I should have emailed about that [14:18] thanks [14:18] np [14:18] 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:22] We appear to have a new failure kind spiking, unfortunatly [14:23] It looks to me like a bug in bzr-builddeb [14:23] We get a LockContention during a set_tag operation, when it's trying to tag a new upstream version [14:24] I'm assuming someone's done something wrong with locking conventions surrounding use of a DistributionBranch [14:25] I don't remember any recent changes related to that though? [14:25] 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] not that I've inspected all the changes closely [14:25] I don't either, but we're definitely seeing the rise of a new failure signature [14:26] yeah [14:27] "only" 80 instances, but that's probably just those that have had an update right? [14:29] Looks like it. Or, it may only be happening when the importer does a temporary re-import to test a collision [14:30] newly exposed failure case maybe? [14:32] Quite possibly a codepath walked more in assessing branches newly copied to a new series [14:34] is Branch.lock_write() re-entrant? [14:49] If it's re-entrant at all, it would only be on the same Branch object [14:49] yeah [14:50] I'm wondering if it's that we're calling it twice, or that we have two references to the same branch [14:57] 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:58] jam, what about two lock_writes? [14:58] james_w: fine as long as it is the same object, yes [14:58] thanks [15:02] you're meant to be queening jam! [15:02] hah :) [15:03] * mgz isn't sure what this involves, something strange and dutch [15:03] mgz: with markets starting at 5 or 6 in the morning at this time of day it's enough to relax :) [15:04] ...getting up at 5 or 6 to go shopping doesn't sound like a holiday [15:04] mgz: http://en.wikipedia.org/wiki/Koninginnedag#Activities has some hints [15:04] mgz: shopping? Selling! :) [15:07] * LarstiQ heads home === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [19:48] is the size information while bzr fetches accurate? [19:49] 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:53] what network protocol are you using ? [19:58] lp:s25rttr [19:58] no firewall so I guess whatever the default is [19:58] mgorny: so that could be either ssh or http depending on whether you've done 'bzr lp-login' [19:58] erm, that might be bzr launchpad-login, I forget. [19:58] no login [19:58] so, its going over HTTP [19:59] and it seems to clone the repo via bzr branch [19:59] which means its basically doing a virtual file system access to the branch data. [19:59] logging in should make it massively faster. [19:59] the repository may well need a pack as well, if its currently bloated at 700M [20:00] bzr does autorepack after fetching? [20:00] the proto seems to be very suboptimal [20:01] and logging in is not a case, unless we're going to force random no of Gentoo users to create launchpad accounts [20:01] why would random no of gentoo users be branching in the first place ? [20:02] because of random no of upstreams using bzr for their programs, and users fetching sources then [20:02] would tarballs work better for you ? [20:03] for me yes [20:03] I was mostly wondering whether we are doing something wrong [20:03] I'm a git person and it looks weird to me to use 'branch' command to clone a repo [20:03] but if it's upstream no-repack fault or proto limitation, I guess we can't do much [20:04] just replace live-source ebuilds with snapshots [20:04] so the smart streaming protocol is much more efficient [20:04] http://bazaar.launchpad.net/~flosoft/s25rttr/trunk/tarball/head: [20:04] should get you a tarball [20:04] sadly, that won't work for us [20:05] because tarballs have to be manifested with checksums [20:05] and live tarballs = live checksums [20:05] but we'll try to find something [20:05] * mgorny will just run a cruciate for git :P [20:07] so the tarball is 40M [20:07] much less data [20:08] 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:09] 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] thanks for the patience. [20:09] we have a requested feature to run the streaming protocol over http [20:10] but noone has had the time to glue it all together. [20:10] the repository is a bit poorly packed atm, but not -terrible- [20:10] I'd file a bug on bzr, 700M is unreasonable given the size of repository. [20:10] mgorny: ^ [20:12] ok. I'll just try to get someone to reproduce that first however/ [20:14] thanks. I'll file it tomorrow or the day after tomorrow. good night. [20:16] cool [21:28] 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] Apparently the packaging uptodate check doesn't follow stacking properly [21:29] Lucky for me I only ever deal with vague branches.