=== naoki is now known as naoki-away === naoki-away is now known as naoki === jfroy_ is now known as jfroy === naoki is now known as naoki-away === naoki-away is now known as naoki [10:55] mgz: I summon thee === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away === naoki-away is now known as naoki [14:11] hi there, does anyone know a way to keep version info up-to-date when committing changes to a branch? [14:12] something like subversion properties? [14:12] Perhaps you are looking for the bzr-keywords plugin? [14:13] ah, I'll have a look at it === naoki is now known as naoki-away === naoki-away is now known as naoki === naoki is now known as naoki-away [16:29] missed a lifeless summoning... [16:29] he got some funny test failures, look fixable when the sun is round the other side of the planet again though === naoki-away is now known as naoki === radoe_ is now known as radoe === nlisgo_ is now known as nlisgo === naoki is now known as naoki-away [18:32] I'd been keeping a local branch on my desktop in sync with a parent repo, ".../project_jinx/trunk". For a bit, I switched to merging from a different parent, ".../project_jinx/bobTest16". Now it's time to switch back. So I do a "bzr merge .../project_jinx/trunk" and reconcile & commit. === naoki-away is now known as naoki [18:32] That works ok. But if I just do a "bzr merge" in my local branch, it still reports "Merging from remembered submit location .../project_jinx/bobTest16" [18:33] How do I make my local repo forget about the "remembered submit location", and once again only use the .../project_jinx/trunk ? [18:35] --remember with the old location [18:37] mgz: Great, worked. I kept trying to do a switch but that didn't work. [20:20] moin oin [20:37] hey lifeless [20:37] hiya [20:43] lifeless: I think I've resolved your issues, there might be one remaining but it's not clear what the right answer is [20:44] I'm happy to be told to do rearrangements by the way [20:46] mgz: I know [20:46] mgz: I meant [20:46] 'I'm not bouncing it for shallow stuff [20:46] or cosmetic is perhaps a better work [20:53] mgz: so, I should merge again and retry ? [20:53] yup, pull and test. [20:53] mgz: I realised upon waking that the constructor probably has to accept bytestrings [20:53] if so, can just decode them there maybe? [20:53] mgz: but I'd like to try not accepting them at all [20:54] and giving a Warning perhaps, on requests for __str__ [20:54] if it's like my nix box, there will still be one failure, due to... something weird [20:55] heh [20:55] you'd like me to dig? [20:55] I'll go through tokenizer.c again later and try and work out why it's acting up on nix [20:55] well, the problem seems to be simple, [20:56] stick a breakpoint in compat.py on ~line 195 and the line in the SyntaxError has "???" rather than "\xa7\xa7\xa7" [20:56] I just... am not clear on why [20:57] a secret replace clause somewhere? [20:57] it's not really a big issue, just need to work out what the cause is [20:59] something like that, I'll check blame on the source in svn [21:00] meh, yeah: [21:00] http://svn.python.org/view/python/trunk/Parser/tokenizer.c?view=log#rev57961 [21:00] behaviour change *during* 2.5 [21:01] presumably arrived on the lenny 2.5 but not the mozilla 2.5 I've been using as my 2.5 [21:02] and it's bogus in this case. [21:03] I'll just expectedFailure it for the moment based on minor version I think [21:16] mgz: btw [21:16] in #subunit, there is a hudson bot that tests testtools [21:16] wow [21:17] doesn't that mean it should be a unicode object [21:17] rather than str ? [21:23] no, it's daftness, the tokenizer sets up a stream reader from the coding declaration that decodes iff the coding is not latin-1 or utf-8, [21:23] then each decoded line is encoded as utf-8 [21:24] and that patch then adds some code that decodes from utf-8, and encodes back to the original encoding, for a line with a SyntaxError [21:25] OMFG [21:25] but overall it means when I get a line from a SyntaxError, it could be any of latin-1, utf-8, or the encoding of the file [21:25] wtf wtf omg omg wtf [21:25] depending on what the encoding of the file is, and what Python version it is [21:25] I can't express the sympathy I have for you doing this work [21:26] and as debian backport things without changing the minor version, I can't even check sys.version_info I think [21:26] no [21:26] I'll... do an end run around all this, and just re-read the file [21:26] only security stuff, as a rule [21:26] but yeah [21:27] EBROKENINTERFACE [21:27] All you need to do now is put the errors into a .doc file, and email it to the user... [21:27] actually [21:28] you should put it in the topic of #python [21:28] with 'not ready for use' [21:48] its time for some patch reviews [21:55] any reviewers around? [21:56] okay, back to plan b again, using linecache is a pain... man I'm glad I wrote these tests [21:56] also was mistaken, the mozilla-build bundled python is 2.5.0 not .2 so it's not debian being evil with backporting things, they're different minor versions [21:57] doko is pretty good about what he accepts as chrrypicks [21:59] I'm still slightly screwed on knowing the encoding, but can at least use a version check, now, when did that patch land... [21:59] import insanity; insanity.python_encoding() === davidstrauss_ is now known as davidstrauss [23:08] Hi folks. I've got two distinct bzr repos that I'd like to join; one as a subdir inside the other. What's the right way to do that? They don't touch any of the same files, so there's no merging required. [23:08] you need to do a merge to join the graphs [23:09] the merge-into plugin was the best way to do that for a while; dunno if it still is [23:09] there's no common ancestor, since they're entirely independent repos [23:09] ah, thanks. I'll look into that plugin.. [23:18] lifeless: it worked. thanks again! [23:19] join does the same as merge-into...