[issue1079] decode_header does not follow RFC 2047

2012-05-29 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: On Mon, May 28, 2012 at 08:15:05PM +, R. David Murray wrote: R. David Murray rdmur...@bitdance.com added the comment: Ralf, thanks very much for this patch. I'm considering applying it. Given that the current code breaks

[issue1079] decode_header does not follow RFC 2047

2012-01-03 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: Fine, I see what you mean, this involves very careful reading of the RFC and could have been a little more verbose ... Right. Should have been a ')' Adding the RFC tests would be great (patches gladly accepted). Fixes for ones we fail

[issue1079] decode_header does not follow RFC 2047

2012-01-03 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: enclosed please find a fixed patch -- decode_header consolidates multiple encoded strings with the same encoding into a single entry in the returned parts. -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source

[issue1079] decode_header does not follow RFC 2047

2012-01-03 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: Attached please find a patch that - keeps all spaces between non-encoded and encoded parts - doesn't create spaces between non-encoded and encoded parts in case these are already there or not needed (because they are non-ctext characters

[issue1467619] Header.decode_header eats up spaces

2012-01-02 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: I've been bitten by this too (in python up to 2.7 in roundup the bug-tracker). We're currently using a workaround that re-inserts spaces, see git on roundup.sourceforge.net file mailgw.py method _decode_header_to_utf8 RFC2047 even has

[issue1079] decode_header does not follow RFC 2047

2012-01-02 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: maybe it would be a good start to include the examples at the end of RFC2047 into the regression tests? These examples at least support the case that a '?' may immediately follow an encoded string: encoded form

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

2011-07-07 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: On Thu, Jul 07, 2011 at 10:52:51AM +, STINNER Victor wrote: Can't you only work with Unicode and avoid the MBCS encoding? I'm trying to build a windows binary package on Linux. This usually works fine -- as long as the package

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

2011-05-13 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: I've just been bitten by this when trying to do a new release of roundup, why not make the mbcs codec available on non-windows platforms as has been proposed (and rejected) in issue1251921 -- any non-technical reasons for not including

[issue8954] wininst regression: errors when building on linux

2011-05-13 Thread Ralf Schlatterbeck
Ralf Schlatterbeck r...@runtux.com added the comment: 2.6 already produces a .linux-i686.exe package instead of .win32.exe when running bdist_wininst. I've now used python2.5 for producing a binary windows installer for roundup. -- nosy: +runtux versions: +Python 2.6