On Thu, 31 Aug 2017, Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > On 08/31/17 09:36, Jani Nikula wrote: >> On Thu, 31 Aug 2017, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: >>> On Thu, 31 Aug 2017, Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: >>>> On 08/31/17 07:17, Jonathan Corbet wrote: >>>>> On Thu, 31 Aug 2017 10:56:26 -0300 >>>>> Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> wrote: >>>>> >>>>>> It should have something to do with python version and/or to some >>>>>> locale info at the system, as neither I or Jon can reproduce it. >>>>> >>>>> I can't reproduce it here, but I have certainly seen situations where >>>>> Python 2 wants to run with the ascii codec by default. >>>>> >>>>> Note that the exception happens in our Sphinx extension, not in Sphinx >>>>> itself. We've had other non-ascii text in our docs, so I think Sphinx is >>>>> doing the right thing. The problem is with our own code. If I could >>>>> reproduce it, it shouldn't be too hard to track down - take out that >>>>> massive "except anything" block and see where it explodes. >>>>> >>>>> Randy, which distribution are you running, and are you using their version >>>>> of Sphinx? >>>> >>>> opensuse LEAP 42.2 >>>> Yes, their sphinx 1.3.1. >>> >>> What's your LANG setting? I think that's what it boils down to, and >>> trying to work around non-UTF-8 LANG in both python 2 and 3 compatible >>> ways. >>> >>> The odd thing is that I can reproduce the issue using a small python >>> snippet, but not through Sphinx. >> >> Your original error message suggests your Sphinx actually uses python >> 3. Can you check that? The clue is that it's the *decode* that fails. > > Where do you see that clue? The message, "'ascii' codec can't decode byte 0xe2 in position 6368: ordinal not in range(128)". In my testing I could only get that *decode* error message using python 3. > My /usr/bin/python is linked to python2.7: > >> ll /usr/bin/python > lrwxrwxrwx 1 root root 9 Jun 10 19:59 /usr/bin/python -> python2.7* Sure, but how about 'head $(which sphinx-build)'? I could be completely mistaken too. ;) >> Does the below patch help? It avoids the implicit ascii decoding due to >> universal_newlines=True and your LANG setting, and does explicit utf-8 >> decoding instead. >> >> Fingers crossed. > > testing now. Thanks. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
