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