Hi Siddesh, > We recently encountered a case in our glibc patchwork instance on > sourceware, where a patch was dropped because it had x-unknown > charset. I used the following patch to fix this in our instance. The > fix I used was to fall back on a set of encodings (instead of just > utf-8) when the charset is not mentioned or if it is set as x-unknown.
I tried this patch with a testcase from the failing patch you forwarded me, and get the following: ERROR: testPatch (patchwork.tests.test_patchparser.CharsetFallbackPatchTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jk/devel/patchwork/apps/patchwork/tests/test_patchparser.py", line 432, in testPatch (patch, comment) = find_content(self.project, self.mail) File "/home/jk/devel/patchwork/apps/patchwork/bin/parsemail.py", line 180, in find_content decoded_payload = try_decode(payload, cset) File "/home/jk/devel/patchwork/apps/patchwork/bin/parsemail.py", line 152, in try_decode payload = unicode(payload, charset) LookupError: unknown encoding: none In this case, it looks like the encoding is actually ascii, but the "none" charset is causing trouble: Content-Type: text/plain; charset="none" Content-Transfer-Encoding: QUOTED-PRINTABLE So the failure there is due to the "none", and not the charset of the patch content. I've put together an updated change (will send it shortly), could you let me know if it looks OK to you? Regards, Jeremy _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork