1

I noticed this problem yesterday, on the device with an embedded linux the behaviour is this:

$ python3
Python 3.5.6 (default, Feb 18 2019, 15:31:50) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> "\u00df"
'\xdf'

whereas on debian 9 it is:

$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> "\u00df"
'ß'

I tried adding two .bbappend files inspired by this

It's also got GLIBC_GENERATE_LOCALES and IMAGE_LINGUAS in it as per here but it still won't work.

Actually, during the build process it throws a few warnings:

WARNING: bash-4.4.18-r0 do_package_qa: QA Issue: bash-ptest rdepends on locale-base-de-de, but it isn't a build dependency? [build-deps]
WARNING: python3-3.5.6-r1.0 do_configure: QA Issue: python3: configure was passed unrecognised options: --enable-unicode [unknown-configure-option]
WARNING: libxml2-2.9.8-r0 do_package_qa: QA Issue: libxml2-ptest rdepends on locale-base-en-us, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-de-de, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-el-gr, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-en-gb, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-es-es, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-fa-ir, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-hr-hr, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-ja-jp.euc-jp, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-lt-lt, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-ru-ru, but it isn't a build dependency? [build-deps]
WARNING: glib-2.0-1_2.58.0-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-tr-tr, but it isn't a build dependency? [build-deps]

Any ideas what else I could try?

By the way, here is the output of the command "locale" on the system:

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Does not look all that healthy but not sure what to do about it..

cardamom
  • 6,873
  • 11
  • 48
  • 102
  • Which locale are you using? Try with `en_US.UTF-8 python3` (or `en_US.UTF8`, or... check which locales have you installed and the name convention of your OS and version). – Giacomo Catenazzi Feb 20 '19 at 16:48
  • @GiacomoCatenazzi what do you mean by 'name convention'? I posted some output above. I can switch it to Germany with `export LANG=de_DE.UTF-8` and `export LC_ALL=de_DE.UTF-8` but it still does not fix the problem with Python. – cardamom Feb 21 '19 at 09:37
  • you should check with `locale -a`. Some system recently changed the locale name from `en_US.UTF-8` to `en_US.utf8`. Note. You can use any language, just with the `utf8` at the end. Without that, you may still get an old non-unicode charset encoding. – Giacomo Catenazzi Feb 21 '19 at 09:47
  • You may use `dpkg-reconfigure -plow locales` to install locales (if it is debian based). – Giacomo Catenazzi Feb 21 '19 at 09:49
  • `locale -a` gives the 3 error lines above followed by two line, "C" on one line and "POSIX" on the next. This device does not have anything dpkg, I wish it did. – cardamom Feb 21 '19 at 09:52
  • You can compile a locale with `localedef`. You may get the "source" from your standard distribution (it is standardized), and put into your target system, and then you compile the new locale. The trick: locales depends on other locales, so you may transfer more files; and you should check where your system expect the compiled localed to be. – Giacomo Catenazzi Feb 21 '19 at 10:43
  • Thanks, am surprised to see that command actually exists on our system! Unfortunately its usage generates some errors - `localedef -f UTF-8 -i de_DE de_DE.UTF-8 ` gives `error] character map file `UTF-8' not found: No such file or directory` , `[error] cannot read character map directory /usr/share/i18n/charmaps': No such file or directory` . I wonder if someone tried to build this thing too lean.. – cardamom Feb 21 '19 at 10:51
  • You should download the sources of locales from your system. As I wrote, a source include an other which includes an other. You should get all of them, one will be the charmap [which is common in most of locales] -- get the files from an other systems. They are just sources [format defined in POSIX], so not really a problem – Giacomo Catenazzi Feb 21 '19 at 10:57

0 Answers0