[U-Boot] [U-Boot,1/3] nand: Clean up nand_util

Andreas Bießmann andreas.devel at googlemail.com
Wed May 8 07:50:35 EST 2013

Hi all,

On 17.11.12 14:59, Andreas Bießmann wrote:
> Dear Scott Wood,
> On 16.11.12 19:38, Scott Wood wrote:
>> On 11/16/2012 01:43:24 AM, Andreas Bießmann wrote:
>>> Dear Scott Wood,
>>> On 16.11.12 08:20, Andreas Bießmann wrote:
>>>> Dear Scott Wood,
>>>> On 16.11.12 01:29, Scott Wood wrote:
>>>>> On 11/15/2012 06:22:11 PM, Scott Wood wrote:
>>>>>> On Mon, Nov 05, 2012 at 10:15:46AM -0000,
>>> =?utf-8?q?Beno=C3=AEt_Th=C3=A9baudeau_=3Cbenoit=2Ethebaudeau=40advans?==?utf-8?q?ee=2Ecom=3E?=
>>>>>> wrote:
>>>>> Sigh, it looks like either patchwork is mangling the From address or
>>>>> mutt is failing to understand something valid (I assume the latter
>>> since
>>>>> "git am" didn't seem to have a problem with it)...  I don't see this
>>>>> encoding in the original e-mail.

as I understood RFC 2822 3.4 the From header should contain the '<' and
'>' as described in the 'angle-addr' spec. There are some exceptions but
this is the default. The domain and user parts of the address however
must consist of 'quoted-string' which is US-ASCII without some special
chars. Therefore patchwork is false here due to wrongly coding the address.

>>>> patchwork has no influence her. AFAIK the mail header should only
>>>> contain ASCII,
>> This is how I got it in the original e-mail:
>> From: =?iso-8859-1?q?Beno=EEt_Th=E9baudeau?=
>> \t<benoit.thebaudeau at advansee.com>
>> I found another e-mail on the U-Boot list where it did arrive encoded,
>> and both Balsa (which also fails on the Patchwork-produced mbox) and
>> mutt decode it fine.
>> Another example straight from the list that both decode fine is:
>> From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=
>> <benoit.thebaudeau at advansee.com>
>> From Patchwork it becomes:
>> From:
>> =?utf-8?q?Beno=C3=AEt_Th=C3=A9baudeau_=3Cbenoit=2Ethebaudeau=40advans?=
>>  =?utf-8?q?ee=2Ecom=3E?=
>> So patchwork is re-encoding these into UTF-8 (if it was originally
>> something else) and encoding the entire address, not just the comment
>> section. 
> You are right. I did only investigate the mails on list, but patchwork
> must re-encode the header here.

I had some time to dive into this and found the root cause of the
re-coded From header.

> I checked for example http://patchwork.ozlabs.org/patch/199686/. If you
> show the header on webpage you will find the unchanged 'From:' as on the
> list. But if you get the mbox via
> http://patchwork.ozlabs.org/patch/199686/mbox/ the 'From:' is recoded.

Patchwork recodes the 'From' header of the mail in the Patch model. The
following snippet might fix it, unfortunately I have no clue how to
verify it really works without installing the whole thing:

diff --git a/apps/patchwork/models.py b/apps/patchwork/models.py
index 9129aab..606ffe0 100644
--- a/apps/patchwork/models.py
+++ b/apps/patchwork/models.py
@@ -281,7 +281,9 @@ class Patch(models.Model):
         mail['Subject'] = self.name
         mail['Date'] = email.utils.formatdate(
-        mail['From'] = unicode(self.submitter)
+        mail['From'] = email.utils.formataddr(
+                        str(Header(self.submitter.name, 'utf-8')),
+                        self.submitter.email)
         mail['X-Patchwork-Id'] = str(self.id)
         mail['Message-Id'] = self.msgid
         mail.set_unixfrom('From patchwork ' + self.date.ctime())

Maybe the Person model should be expanded by some method to provide a
correctly formatted Header() for the 'From' field?

Best regards

Andreas Bießmann

More information about the Patchwork mailing list