gotwig | hey | 06:17 |
---|---|---|
gotwig | can you tell me how I can make a bzr commit and push online? | 06:18 |
lifeless | bzr commit; bzr push ? | 06:22 |
gotwig | lifeless: yeah, but on the web. | 06:25 |
gotwig | lifeless: I dont have bzr installed here | 06:25 |
gotwig | lifeless: you know | 06:26 |
lifeless | you could use wikkid | 06:28 |
gotwig | lifeless: whats that | 06:36 |
bob2 | a wiki thing that uses bzr | 06:42 |
bob2 | likely you just want to isntall bzr though | 06:42 |
gotwig | bob2: -..- | 06:59 |
gotwig | I can't | 06:59 |
gotwig | with git i can use something like koding.com or c9.io | 06:59 |
gotwig | for bzr I dont found anything like that | 07:00 |
mgz | morning all | 07:01 |
gotwig | mgz: jo | 07:01 |
gotwig | I'd really like to use bzr somehow online | 07:02 |
gotwig | so I dont need it on my pc | 07:02 |
mgz | gotwig: I sympathise with that | 07:07 |
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:09 |
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:10 |
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) | 07:11 |
mgz | okay, branch proposed with those backports | 08:10 |
mgz | will land and merge up after it gets checked | 08:10 |
vila | mgz: great, waiting for your ping | 08:15 |
mgz | vila: do we want jelmer to look at that mp? | 08:24 |
vila | mgz: wouldn't hurt | 08:24 |
jelmer | are new translation strings ok in a minor release? | 08:25 |
vila | especially given he's credited as author ;) | 08:25 |
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:26 |
mgz | trivial edits to translatable strings in a minor release would certainly be bad manners. | 08:27 |
vila | jelmer: so, except for the translation bits, do you approve the mp ? ;) | 08:31 |
=== gthorslund_ is now known as gthorslund | ||
jelmer | vila: døne :) | 08:33 |
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:34 |
jelmer | I'm just using fancy characters. Because I can. | 08:35 |
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:36 |
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:37 |
mgz | ø you mean? | 08:38 |
jelmer | mgz: that's just a question mark ;) | 08:39 |
jelmer | ah, the joys of character encoding.. | 08:39 |
mgz | hm, worrying, pqm doesn't have merge up. | 08:45 |
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:55 |
vila | :-/ | 08:56 |
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 | 08:57 |
vila | mgz: reproduce with lp:~vila/bzr/stats-config, freshly created/pushed on lp ;-/ | 09:04 |
vila | reproduceD | 09:04 |
mgz | from #launchpad is a db lag issue with http url rewrite rules | 09:06 |
mgz | so, good part is should just be able to wait till can see the branch over http then pqm merge will work | 09:07 |
mgz | bad part is jumping up and down won't make that happen faster. | 09:08 |
vila | yeah, better stay up after the first jump | 09:09 |
vila | mgz: alternatively you can use another existing branch no ? | 09:23 |
=== yofel_ is now known as yofel | ||
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:29 |
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:30 |
hrw | bye | 09:37 |
=== smspilla1 is now known as smspillaz | ||
vila | mgz: lp seems to breath better | 13:14 |
vila | mgz: ha, 1/2 hour late I can see ;) | 13:14 |
vila | mgz: on the other hand, I was awaiting your ping. You don't intend to land anything else right ? | 13:18 |
mgz | I sent it then went to lunch | 13:19 |
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:20 |
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:21 |
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:22 |
vila | bummer, lp:bzr/2.4 doesn't merge cleanly into 2.5 :-( | 13:25 |
fullermd | It does if you push hard enough. | 13:25 |
vila | ghaa, so do 2.1, 2.2, 2.3 :-( | 13:27 |
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:29 |
jelmer | vila: do you mean in general? merging up isn't necessary for the feature flags proposals themselves | 13:30 |
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:32 |
vila | for the feature flags, I know each branch got a specific fix but I assumed you merged up to avoid bad resolutions | 13:33 |
jelmer | I did for everything except 2.4 -> 2.5 I believe | 13:35 |
vila | doesn't look like it, every merge --preview raises conflicts | 13:36 |
* jelmer tries | 13:41 | |
jelmer | vila: 2.1 -> 2.2 seems fine here | 13:48 |
vila | >-/ fine here too now, wth | 13:49 |
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:50 |
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:51 |
vila | doing the release includes a *check* that things are clean, that's how I found the issue ;) | 13:52 |
vila | bzr lock lp:bzr/2.5 | 14:08 |
vila | 6 new translations: cs, he, my, nb, sv and vi (where is emacs ?) | 14:09 |
fullermd | bzr ran out of memory trying to repack it. | 14:10 |
vila | ha, silly me, I shouldn't have attempted that *under* emacs itself... | 14:11 |
* fullermd thinks of that as good general advice for pretty much everything ;p | 14:19 | |
vila | kids these days... | 14:19 |
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... | 14:55 |
vila | mgz: use bzr+ssh as lp spprt is broken ? | 15:15 |
vila | support | 15:16 |
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:17 |
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:19 |
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:20 |
vila | bzr unlock lp:bzr/2.5 | 15:32 |
vila | 2.5.1 is frozen, packagers of the bzr world unite ! | 15:33 |
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 | 16:43 |
lifeless | vila: ?!?? | 17:00 |
vila | lifeless: explore lp:udd running selftest.py, will be clearer (EODed) | 17:01 |
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/) | 17:10 |
exarkun | How do I add a file with a ":" in its name to a bzr branch? | 20:11 |
exarkun | Using "bzr add <name>" fails: bzr: ERROR: Unsupported protocol for url "015. Yurt II: The Yurt Returns.html" | 20:12 |
maxb | exarkun: refer to it as ./015... would be a way | 20:18 |
exarkun | maxb: thanks | 21:12 |
=== cinerama_ is now known as ceinrama | ||
=== ceinrama is now known as cinerama | ||
thumper | hey folks | 23:09 |
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:10 |
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:11 |
mwhudson | thumper: are you committing from the command line or with bzrlib? | 23:23 |
jelmer | thumper: not easily AFAIK | 23:31 |
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:32 |
thumper | jelmer: the second sounds promising | 23:33 |
thumper | jelmer: is there any help on how to do that? | 23:33 |
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:34 |
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:36 |
thumper | :( | 23:38 |
jelmer | thumper: maybe vila has some clever ideas tomorrow | 23:38 |
thumper | jelmer: what about committing from a revision tree? | 23:38 |
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:39 |
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:40 |
thumper | interesting | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!