python-config is slightly broken in 3.4.4, 3.4.5 and maybe all other versions (haven't checked). LC_ALL=en_US.utf8 python3-4m-config --libs /usr/bin/python3.4m-config: line 45: LDVERSION: command not found /usr/bin/python3.4m-config: line 48: VERSION: command not found /usr/bin/python3.4m-config: line 50: prefix: command not found /usr/bin/python3.4m-config: line 50: VERSION: command not found -lpython3.4m -lpthread -ldl -lutil -lm It sets variables using a variable before it's actually set, and does it via $() instead of ${}, trying to launch it. Just upgraded to latest python:3.4 from git tree; before that 3.4.4 I had since some months ago had the same issue. Spams QA bug claims to other packages calling python3.4m-config
I have no clue how you got that... For me, python-3.4.5 has: 45:LDLIBRARY="libpython${LDVERSION}.so" etc. -- i.e. ${}, not $(). Therefore, obviously the errors don't pop up.
Probably LC_COLLATE="et_EE.UTF-8" A-Z doesn't include T, U, V, W, X, Y; same for a-z. If using sed with [A-Za-Z] or wahtever, have to use C or some english locale; or EAPI-6 I hear.
(In reply to Mart Raudsepp from comment #2) > Probably LC_COLLATE="et_EE.UTF-8" > A-Z doesn't include T, U, V, W, X, Y; same for a-z. > If using sed with [A-Za-Z] or wahtever, have to use C or some english > locale; or EAPI-6 I hear. Yep, yer crazy language breaks everyfink! Quoting Makefile.pre.in: # Replace makefile compat. variable references with shell script compat. ones; $(VAR) -> ${VAR} sed -e 's,\$$(\([A-Za-z0-9_]*\)),\$$\{\1\},g' < Misc/python-config.sh >python-config I suggest reporting that upstream, so they can have some laugh too.
I suppose we could add "export LC_ALL=C" to src_compile to work around this.
(In reply to Mike Gilbert from comment #4) > I suppose we could add "export LC_ALL=C" to src_compile to work around this. We should probably also extend python_export_utf8* and Portage stuff to account for this insanity. PMS says: > The package manager must ensure that the LC_CTYPE and LC_COLLATE locale categories are equivalent to the POSIX locale, as far as characters in the ASCII range (U+0000 to U+007F) are concerned. I think this includes the order of characters in character classes. CC-ing pms-bugs@ to confirm.
I reported problem to upstream: https://bugs.python.org/issue28258
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #6) > I reported problem to upstream: https://bugs.python.org/issue28258 Thanks!
(In reply to Michał Górny from comment #5) > PMS says: > > > The package manager must ensure that the LC_CTYPE and LC_COLLATE locale categories are equivalent to the POSIX locale, as far as characters in the ASCII range (U+0000 to U+007F) are concerned. > > I think this includes the order of characters in character classes. Yes: $ echo t | grep "[a-z]" t $ echo t | LC_COLLATE="et_EE.UTF-8" grep "[a-z]" $ (In reply to Michał Górny from comment #5) > We should probably also extend ... Portage stuff to > account for this insanity. Portage already sets C locale in EAPI 6: if eapi_attrs.posixish_locale: split_LC_ALL(mydict) mydict["LC_COLLATE"] = "C" dev-lang/python uses EAPI 4 or 5.
Fixed without a revbump; I don't imagine many people are affected by this. commit bf783868c0aa5cc4ca2db8d9fb56ec3d29322d5d Author: Mike Gilbert <floppym@gentoo.org> Date: Fri Sep 23 16:48:44 2016 -0400 dev-lang/python: LC_COLLATE=C Bug: https://bugs.gentoo.org/594768 Package-Manager: portage-2.3.0_p43 dev-lang/python/python-2.7.10-r1.ebuild | 4 ++++ dev-lang/python/python-2.7.12.ebuild | 4 ++++ dev-lang/python/python-3.4.3-r1.ebuild | 4 ++++ dev-lang/python/python-3.4.5.ebuild | 4 ++++ dev-lang/python/python-3.5.2.ebuild | 4 ++++ 5 files changed, 20 insertions(+)
