[10:55] <lifeless> mgz: I summon thee
[14:11] <mario-kemper> hi there, does anyone know a way to keep version info up-to-date when committing changes to a branch?
[14:12] <mario-kemper> something like subversion properties?
[14:12] <spiv> Perhaps you are looking for the bzr-keywords plugin?
[14:13] <mario-kemper> ah, I'll have a look at it
[16:29] <mgz> missed a lifeless summoning...
[16:29] <mgz> he got some funny test failures, look fixable when the sun is round the other side of the planet again though
[18:32] <Jerry_Cottage> 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.
[18:32] <Jerry_Cottage> 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] <Jerry_Cottage> How do I make my local repo forget about the "remembered submit location", and once again only use the .../project_jinx/trunk ?
[18:35] <mgz> --remember with the old location
[18:37] <Jerry_Cottage> mgz: Great, worked.  I kept trying to do a switch but that didn't work.
[20:20] <lifeless> moin oin
[20:37] <jelmer> hey lifeless
[20:37] <lifeless> hiya
[20:43] <mgz> 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] <mgz> I'm happy to be told to do rearrangements by the way
[20:46] <lifeless> mgz: I know
[20:46] <lifeless> mgz: I meant
[20:46] <lifeless> 'I'm not bouncing it for shallow stuff
[20:46] <lifeless> or cosmetic is perhaps a better work
[20:53] <lifeless> mgz: so, I should merge again and retry ?
[20:53] <mgz> yup, pull and test.
[20:53] <lifeless> mgz: I realised upon waking that the constructor probably has to accept bytestrings
[20:53] <mgz> if so, can just decode them there maybe?
[20:53] <lifeless> mgz: but I'd like to try not accepting them at all
[20:54] <lifeless> and giving a Warning perhaps, on requests for __str__
[20:54] <mgz> if it's like my nix box, there will still be one failure, due to... something weird
[20:55] <lifeless> heh
[20:55] <lifeless> you'd like me to dig?
[20:55] <mgz> I'll go through tokenizer.c again later and try and work out why it's acting up on nix
[20:55] <mgz> well, the problem seems to be simple,
[20:56] <mgz> stick a breakpoint in compat.py on ~line 195 and the line in the SyntaxError has "???" rather than "\xa7\xa7\xa7"
[20:56] <mgz> I just... am not clear on why
[20:57] <lifeless> a secret replace clause somewhere?
[20:57] <mgz> it's not really a big issue, just need to work out what the cause is
[20:59] <mgz> something like that, I'll check blame on the source in svn
[21:00] <mgz> meh, yeah:
[21:00] <mgz> http://svn.python.org/view/python/trunk/Parser/tokenizer.c?view=log#rev57961
[21:00] <mgz> behaviour change *during* 2.5
[21:01] <mgz> presumably arrived on the lenny 2.5 but not the mozilla 2.5 I've been using as my 2.5
[21:02] <mgz> and it's bogus in this case.
[21:03] <mgz> I'll just expectedFailure it for the moment based on minor version I think
[21:16] <lifeless> mgz: btw
[21:16] <lifeless> in #subunit, there is a hudson bot that tests testtools
[21:16] <lifeless> wow
[21:17] <lifeless> doesn't that mean it should be a unicode object
[21:17] <lifeless> rather than str ?
[21:23] <mgz> 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] <mgz> then each decoded line is encoded as utf-8
[21:24] <mgz> 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] <lifeless> OMFG
[21:25] <mgz> 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] <lifeless> wtf wtf omg omg wtf
[21:25] <mgz> depending on what the encoding of the file is, and what Python version it is
[21:25] <lifeless> I can't express the sympathy I have for you doing this work
[21:26] <mgz> and as debian backport things without changing the minor version, I can't even check sys.version_info I think
[21:26] <lifeless> no
[21:26] <mgz> I'll... do an end run around all this, and just re-read the file
[21:26] <lifeless> only security stuff, as a rule
[21:26] <lifeless> but yeah
[21:27] <lifeless> EBROKENINTERFACE
[21:27] <fullermd> All you need to do now is put the errors into a .doc file, and email it to the user...
[21:27] <lifeless> actually
[21:28] <lifeless> you should put it in the topic of #python
[21:28] <lifeless> with 'not ready for use'
[21:48] <lifeless> its time for some patch reviews
[21:55] <lifeless> any reviewers around?
[21:56] <mgz> okay, back to plan b again, using linecache is a pain... man I'm glad I wrote these tests
[21:56] <mgz> 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] <lifeless> doko is pretty good about what he accepts as chrrypicks
[21:59] <mgz> 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] <lifeless> import insanity; insanity.python_encoding()
[23:08] <cjb> 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] <lifeless> you need to do a merge to join the graphs
[23:09] <lifeless> the merge-into plugin was the best way to do that for a while; dunno if it still is
[23:09] <cjb> there's no common ancestor, since they're entirely independent repos
[23:09] <cjb> ah, thanks.  I'll look into that plugin..
[23:18] <cjb> lifeless: it worked.  thanks again!
[23:19] <fullermd> join does the same as merge-into...