[06:17] <gotwig> hey
[06:18] <gotwig> can you tell me how I can make a bzr commit and push online?
[06:22] <lifeless> bzr commit; bzr push ?
[06:25] <gotwig> lifeless: yeah, but on the web.
[06:25] <gotwig> lifeless: I dont have bzr installed here
[06:26] <gotwig> lifeless: you know
[06:28] <lifeless> you could use wikkid
[06:36] <gotwig> lifeless: whats that
[06:42] <bob2> a wiki thing that uses bzr
[06:42] <bob2> likely you just want to isntall bzr though
[06:59] <gotwig> bob2: -..-
[06:59] <gotwig> I can't
[06:59] <gotwig> with git i can use something like koding.com or c9.io
[07:00] <gotwig> for bzr I dont found anything like that
[07:01] <mgz> morning all
[07:01] <gotwig> mgz: jo
[07:02] <gotwig> I'd really like to use bzr somehow online
[07:02] <gotwig> so I dont need it on my pc
[07:07] <mgz> gotwig: I sympathise with that
[07:09] <gotwig> mgz: like you already can do it with mercurial and git
[07:09] <gotwig> becouse they are way more popular
[07:09] <gotwig> at c9.io
[07:09] <gotwig> or kodingen.com or koding.com
[07:09] <gotwig> etc., etc.
[07:09] <vila> then bug the web sites admin to support bzr :)
[07:10] <vila> the issue is to edit remote files
[07:10] <gotwig> vila: its not easy for them, too.
[07:10] <gotwig> and the interesst has to be great
[07:10] <gotwig> vila: ^, right?
[07:11] <vila> imho, editing remote files will consume far more bandwidth and suffer latency than the push which is supposed to transfer only the resulting diff (and some overhead)
[08:10] <mgz> okay, branch proposed with those backports
[08:10] <mgz> will land and merge up after it gets checked
[08:15] <vila> mgz: great, waiting for your ping
[08:24] <mgz> vila: do we want jelmer to look at that mp?
[08:24] <vila> mgz: wouldn't hurt
[08:25] <jelmer> are new translation strings ok in a minor release?
[08:25] <vila> especially given he's credited as author ;)
[08:26] <vila> I'd say no on principle but the benefit outweight the issue in this case imho
[08:26] <jelmer> works for me
[08:26] <mgz> jelmer: sometimes not, but given our translations are pretty incomplete anyway and we're not removing an already translated string, should be fine
[08:26] <jelmer> I guess it's also not really an issue since we don't have full coverage for any language (except English) atm
[08:27] <mgz> trivial edits to translatable strings in a minor release would certainly be bad manners.
[08:31] <vila> jelmer: so, except for the translation bits, do you approve the mp ? ;)
[08:33] <jelmer> vila: dÃ¸ne :)
[08:34] <vila> hmm, I missed the joke but that's probably because the font I use can't display it correctly ;)
[08:34] <vila> kernel upgrade, reboot needed, bbl
[08:35] <jelmer> I'm just using fancy characters. Because I can.
[08:36] <mgz> approve (code)?
[08:36] <mgz> I hope you'd approve the code, you wrote it :D
[08:36] <vila> it renders as d\~A,ne with the comma looking a bit fancy
[08:36] <vila> and the \~A is a the ~ above the A
[08:37] <jelmer> hmm
[08:37] <jelmer> it should be a combination of / and o
[08:37] <vila> hehe, yeah, o should be slashed not the 0 as late comers to the game thought in last century ;)
[08:38] <mgz> ø you mean?
[08:39] <jelmer> mgz: that's just a question mark ;)
[08:39] <jelmer> ah, the joys of character encoding..
[08:45] <mgz> hm, worrying, pqm doesn't have merge up.
[08:55] <mgz> okay, what is pqm trying to tell me
[08:55] <mgz> got a failure back with just this in the output:
[08:55] <mgz> Could not determine branch type for 'http://bazaar.launchpad.net/~gz/bzr/2.5_backport_rmbranch_fixes'
[08:56] <vila> :-/
[08:57] <mgz> ...and indeed that's not a branch
[08:57] <mgz> what the hey
[08:57] <mgz> exists over bzr+ssh but not over http
[09:04] <vila> mgz: reproduce with lp:~vila/bzr/stats-config, freshly created/pushed on lp ;-/
[09:04] <vila> reproduceD
[09:06] <mgz> from #launchpad is a db lag issue with http url rewrite rules
[09:07] <mgz> so, good part is should just be able to wait till can see the branch over http then pqm merge will work
[09:08] <mgz> bad part is jumping up and down won't make that happen faster.
[09:09] <vila> yeah, better stay up after the first jump
[09:23] <vila> mgz: alternatively you can use another existing branch no ?
[09:29] <mgz> vila: you mean push over an existing branch I happen to have, put up an mp for that, approve and merge it?
[09:29] <vila> yup
[09:29] <mgz> I guess, though I'd prefer not to.
[09:30] <vila> it would validate that nothing else is broken before I start cutting the release ;)
[09:30] <vila> and the end result should be the same (minus the branch nick maybe)
[09:37] <hrw> bye
[13:14] <vila> mgz: lp seems to breath better
[13:14] <vila> mgz: ha, 1/2 hour late I can see ;)
[13:18] <vila> mgz: on the other hand, I was awaiting your ping. You don't intend to land anything else right ?
[13:19] <mgz> I sent it then went to lunch
[13:20] <mgz> that's all that should land I think,
[13:20] <mgz> just the merge up to do (which doesn't get in your way)
[13:21] <vila> I'll do it (I need to do one anyway)
[13:21] <vila> Unless you expect tricky conflicts in which case I'm happy to merge up only the release ;)
[13:22] <mgz> well, apart from news I don't expect anything too bad provided it works out the same changes have happened on both branches
[13:22] <vila> ok, don't bother then ;)
[13:25] <vila> bummer, lp:bzr/2.4 doesn't merge cleanly into 2.5 :-(
[13:25] <fullermd> It does if you push hard enough.
[13:27] <vila> ghaa, so do 2.1, 2.2, 2.3 :-(
[13:29] <vila> jelmer: you didn't merged up after landing your feature flags proposals, would you mind looking into it once 2.5.1 is released ?
[13:30] <jelmer> vila: do you mean in general? merging up isn't necessary for the feature flags proposals themselves
[13:32] <vila> I mean I try to merge lp:bzr/2.x branches into lp:bzr/2.x+1 to ensure all bug fixes bubble up, this is expected to always merge cleanly
[13:33] <vila> for the feature flags, I know each branch got a specific fix but I assumed you merged up to avoid bad resolutions
[13:35] <jelmer> I did for everything except 2.4 -> 2.5 I believe
[13:36] <vila> doesn't look like it, every merge --preview raises conflicts
[13:41]  * jelmer tries
[13:48] <jelmer> vila: 2.1 -> 2.2 seems fine here
[13:49] <vila> >-/ fine here too now, wth
[13:50] <mgz> vila: sorry, I think I did some of that merge up, but not all
[13:50] <vila> but 2.2 -> 2.3 still broken
[13:51] <jelmer> vila: 2.2 -> 2.3 has conflicts in bzrdir.py, but those changes from 2.2 can just be discarded
[13:51] <vila> sure, but that's not part of doing a release :)
[13:52] <vila> doing the release includes a *check* that things are clean, that's how I found the issue ;)
[14:08] <vila> bzr lock lp:bzr/2.5
[14:09] <vila> 6 new translations: cs, he, my, nb, sv and vi (where is emacs ?)
[14:10] <fullermd> bzr ran out of memory trying to repack it.
[14:11] <vila> ha, silly me, I shouldn't have attempted that *under* emacs itself...
[14:19]  * fullermd thinks of that as good general advice for pretty much everything   ;p
[14:19] <vila> kids these days...
[14:55] <mgz> what's the sftp trick again to get the conf of a branch on launchpad?
[14:55] <mgz> does it block you from getting ones with branches you don't own...
[15:15] <vila> mgz: use bzr+ssh as lp spprt is broken ?
[15:16] <vila> support
[15:17] <mgz> vila: this is related to working out what's up with borked branches, if you could just branch it there wouldn't be an issue
[15:19] <vila> I miss the context, when you said 'conf of branches' I understood 'bzr config -d <url>'
[15:19] <vila> what kind of borking are you referring to ?
[15:19] <mgz> see #launchpad
[15:20] <mgz> ending up at a location that doesn't exist basically
[15:20] <vila> ha, no way to get a conf there indeed ;)
[15:20] <mgz> after some slightly bogus renaming of branches with the lp api.
[15:20] <vila> .bzr/branch/location tricks involved ?
[15:32] <vila> bzr unlock lp:bzr/2.5
[15:33] <vila> 2.5.1 is frozen, packagers of the bzr world unite !
[16:43] <vila> cunning way to avoid test failures (i.e. ensure your test suite is passing): call sys.exit() in the system under test... unsuspecting devs passing after you won't notice
[17:00] <lifeless> vila: ?!??
[17:01] <vila> lifeless: explore lp:udd running selftest.py, will be clearer (EODed)
[17:10] <dobey> hi all
[17:10] <dobey> what does the LockNotHeld error mean exactly?
[17:10] <dobey> as in: 17:02:01 E: bzrlib.errors.LockNotHeld: Lock not held: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/u1db/.bzr/)
[20:11] <exarkun> How do I add a file with a ":" in its name to a bzr branch?
[20:12] <exarkun> Using "bzr add <name>" fails: bzr: ERROR: Unsupported protocol for url "015. Yurt II: The Yurt Returns.html"
[20:18] <maxb> exarkun: refer to it as ./015... would be a way
[21:12] <exarkun> maxb: thanks
[23:09] <thumper> hey folks
[23:10] <thumper> is there a way in bzrlib that I can override the need for signed commits?
[23:10] <thumper> in particular I have a situation where my standard bazaar config specifies the need for them
[23:10] <thumper> however I have some scripts that I'm writing where I can't have it
[23:11] <thumper> right now I have an override in the locations.conf to specify create_signatures = never
[23:11] <thumper> but I need to be able to specify that when I open the branch
[23:11] <thumper> any ideas?
[23:23] <mwhudson> thumper: are you committing from the command line or with bzrlib?
[23:31] <jelmer> thumper: not easily AFAIK
[23:32] <thumper> mwhudson: from withing bzrlib
[23:32] <thumper> this is for the wiki stuff
[23:32] <jelmer> thumper: the only way I can think of is to either modify the command line overrides to set "create_signatures=never"
[23:32] <jelmer> thumper: or alternatively (cleaner but more complex) to add a dummy ConfigStore that sets create_signatures=never and add that to the config stack that you pass in when you commit
[23:33] <thumper> jelmer: the second sounds promising
[23:33] <thumper> jelmer: is there any help on how to do that?
[23:34] <jelmer> thumper: You want to call IniFileStore() to create a new store
[23:34] <jelmer> thumper: then store._load_from_striong("create_signatures=never")
[23:36] <jelmer> urgh, except we seem to've made it pretty hard to actually override the config stack when you commit from a working tree
[23:38] <thumper> :(
[23:38] <jelmer> thumper: maybe vila has some clever ideas tomorrow
[23:38] <thumper> jelmer: what about committing from a revision tree?
[23:39] <jelmer> thumper: do you mean from a MemoryTree of some sort?
[23:39] <jelmer> revision trees are immutable, so committing them is usually pretty pointless
[23:39] <jelmer> thumper: or do you perhaps mean committing using the commit builder?
[23:39] <thumper> yeah, so working directly with the branch, not a working tree
[23:39] <jelmer> thumper: in that case you can pass in a custom config stack easily
[23:39] <thumper> not entirely sure what I'm referring to :)
[23:39] <jelmer> thumper: Branch.get_commit_builder and Repository.get_commit_builder allow you to pass in a custom stack.
[23:40] <jelmer> so presumably you'd take the branch config (Branch.get_config_stack), make a copy of it and add your custom store in front of the other stores
[23:40] <jelmer> and then pass that custom stack to Branch.get_config_stack
[23:40] <jelmer> euhm
[23:40] <jelmer> and then pass that custom stack to Branch.get_commit_builder
[23:41] <thumper> interesting