[05:59] <nilg`> hi, how to set append-revisions-only otherwise than at init?
[06:00] <spiv> With bzr config
[06:00] <spiv> Something like 'bzr config append_revisions_only=true'
[06:01] <nilg`> thanks a lot!
[06:10] <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:11] <nilg`> same thing when I try to push
[06:13] <LarstiQ> nilg`: you can do `bzr config -d bzr+ssh://server/path/to/remote append_revisions_only=true`
[06:14] <nilg`> awesome, thx
[06:16] <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:17] <LarstiQ> nilg`: do you know the `bzr missing` command btw?
[06:30] <nilg`> nsoi010
[06:30] <nilg`> wrong window...
[06:32] <nilg`> useful thanks
[06:43] <nilg`> hmmm, it didn't work, I can still "violate causality"
[06:52] <LarstiQ> nilg`: ok, how did you do that?
[06:54] <LarstiQ> nilg`: does `bzr config -d remote/branch` show append_revisions_only is correctly set?
[06:56] <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:58] <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:59] <nilg`> then bzr merge
[06:59] <nilg`> then bzr commit -m "merge"
[06:59] <nilg`> and finally bzr push lp:opencog
[07:00] <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:01] <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:02] <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:03] <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:04] <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:05] <vila> the section name is indeed weird but that means it shouldn't apply to *any* branch
[07:06] <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:07] <vila> [<section name>]
[07:11] <nilg`> here's the output of bzr config -d lp:opencog
[07:11] <nilg`> http://pastebin.com/iRpKwqhB
[07:12] <vila> right
[07:12] <vila> so, this means 'bzr config' doesn't interpret lp:opencog *at all*,
[07:13] <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:14] <LarstiQ> right
[07:15] <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:16] <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:17] <vila> yup, by default branch.conf is where the modifications go
[07:17] <vila> LarstiQ: yup
[07:18] <LarstiQ> and I see bug 957049 is already filed
[07:19] <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:20] <LarstiQ> vila: any idea how to tackle the bug?
[07:20] <nilg`> http://pastebin.com/ApAA7EEg
[07:21] <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:22] <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:23] <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:24] <LarstiQ> vila: ok
[07:24] <nilg`> just to be sure (before I try) http://pastebin.com/BxrAS8vY
[07:26] <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:27] <LarstiQ> nilg`: for the record, which bzr version are you using?
[07:27] <nilg`> Bazaar (bzr) 2.5.0
[07:27] <nilg`>  
[07:28] <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:29] <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:36]  * LarstiQ runs the testsuite with a 'directory = directory_service.directories.dereference(directory)' thrown in
[07:59] <mgz> morning all!
[07:59] <mgrandi> morn
[08:15] <LarstiQ> hey mgz, mgrandi
[08:18] <vila> mgz: o/
[08:22]  * vila upgrades his last desktop to precise
[09:03] <mgz> vila: when you're done with the upgrade, LarstiQ wants some help writing a config test, see bug 957049 mp
[09:30]  * vila nods @ mgz, LarstiQ
[09:56] <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:57] <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:58] <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:59] <mgz> 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] <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:01] <LarstiQ> and after this I'm _really_ getting lunch :)
[10:05] <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:06] <LarstiQ> vila: np. Just a sec while I retarget
[10:07] <LarstiQ> vila: done
[10:55] <mgz> vila: that branch failed on pqm, or there was some other issue?
[10:55] <vila> let me check
[10:56] <vila> hmm, no mail...
[10:57] <vila> ha, damn laptop
[10:57] <vila> the mail was blocked locally
[10:58] <vila> unblocked
[13:04] <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:05] <natosha> I thought I'd ask here if there is more detailed documentation before starting to look at the source.
[13:09] <wgz> natosha: try <http://doc.bazaar.canonical.com/developers/case-insensitive-file-systems.html>
[13:12] <natosha> wgz, thanks, that gets me closer
[14:17] <james_w> maxb, hi, did you re-enable the cron job?
[14:17] <maxb> I did
[14:18] <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:22] <maxb> We appear to have a new failure kind spiking, unfortunatly
[14:23] <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:24] <maxb> I'm assuming someone's done something wrong with locking conventions surrounding use of a DistributionBranch
[14:25] <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:26] <james_w> yeah
[14:27] <james_w> "only" 80 instances, but that's probably just those that have had an update right?
[14:29] <maxb> Looks like it. Or, it may only be happening when the importer does a temporary re-import to test a collision
[14:30] <LarstiQ> newly exposed failure case maybe?
[14:32] <maxb> Quite possibly a codepath walked more in assessing branches newly copied to a new series
[14:34] <james_w> is Branch.lock_write() re-entrant?
[14:49] <maxb> If it's re-entrant at all, it would only be on the same Branch object
[14:49] <james_w> yeah
[14:50] <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:57] <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:58] <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
[15:02] <mgz> you're meant to be queening jam!
[15:02] <LarstiQ> hah :)
[15:03]  * 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:04] <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:07]  * LarstiQ heads home
[19:48] <mgorny> is the size information while bzr fetches accurate?
[19:49] <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:53] <lifeless> what network protocol are you using ?
[19:58] <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:59] <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
[20:00] <mgorny> bzr does autorepack after fetching?
[20:00] <mgorny> the proto seems to be very suboptimal
[20:01] <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:02] <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:03] <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:04] <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:05] <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:07] <lifeless> so the tarball is 40M
[20:07] <lifeless> much less data
[20:08] <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:09] <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:10] <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:12] <mgorny> ok. I'll just try to get someone to reproduce that first however/
[20:14] <mgorny> thanks. I'll file it tomorrow or the day after tomorrow. good night.
[20:16] <lifeless> cool
[21:28] <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:29] <fullermd> Lucky for me I only ever deal with vague branches.