I'm using the elog mail interface. Even though my subject setting is at its default from make.globals, i.e. PORTAGE_ELOG_MAILSUBJECT="[portage] ebuild log for \${PACKAGE} on \${HOST}" the subjects get displayed on my system with a tabulator character instead of a space after the word "on". In past versions of Thunderbird, this has caused a somewhat larger space, but recently a dotted box containing the letters "HT" for "horizontal tab" is shown instead, further reducing the legibility of those lines. Looking at the source of a mail in question, I find the SUbject line has been folded at that position, replacing " " by "\n\t" or even "\r\n\t". According to http://tools.ietf.org/html/rfc5322#section-2.2.3 unfolding only removes CRLF pairs, and doesn't change the whitespace itself in any way, so this seems to be proper behaviour on the part of Thunderbird. I would assume that the cause of this problem is the continuation_ws='\t' hardcoded into email.Generator._write_headers in email/generator.py of Python 2.5. Probably http://bugs.python.org/issue1974 is about just this issue. My experience is that mail related python bugs take a long time to fix upstream. The remotely related http://bugs.python.org/issue1670765 for example is open for two years now despite it being a patch submission, not only a bug report. So if you see any real chance at getting this included into python, either upstream or at the distro level, fixing that part of python might be a solution. If not, you should probably work around that broken lib somehow.
Update: http://bugs.python.org/msg84698 Python upstream has addressed this for 2.7, but won't backport the fix.
Created attachment 186855 [details, diff] Use Header object http://bugs.python.org/msg84755 provides a simple workaround by using a header object instead of a simple string for the subject. This uses spaces instead of tabs, solving the issue unless the subject actually contains tabs, which I consider pretty rare. Tested the attached patch, works here, please include.
Thanks, your patch is in svn r13261.
This is fixed in 2.2_rc29.
What about to close this bug?
Since portage-2.2_rc* is masked, I'll close this after it's in an unmasked release.
This is fixed in 2.1.6.12.
