Created attachment 457630 [details] dev-libs:libpcre2-10.22:20161228-160234.log >>> Test phase: dev-libs/libpcre2-10.22 * .hppa: running multilib-minimal_abi_src_test make -j3 check make check-am make[1]: Entering directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' make make[2]: Entering directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' make all-am make[3]: Entering directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' make[2]: Leaving directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' make check-TESTS make[2]: Entering directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' make[3]: Entering directory '/var/tmp/portage/dev-libs/libpcre2-10.22/work/pcre2-10.22-.hppa' FAIL: RunTest PASS: RunGrepTest ============================================================================ Testsuite summary for PCRE2 10.22 ============================================================================ # TOTAL: 2 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See ./test-suite.log ============================================================================ Makefile:2534: recipe for target 'test-suite.log' failed
Created attachment 457634 [details] test-suite.log
Created attachment 457636 [details] 603946-teststdout
Exactly same error here on ia64 with fr_FR locale. Émeric
So it's a stack direction issue?
Does it still happen for you nowadays? I tried to reproduce test failure on ia64 (guppy) and no tests failed: $ FEATURES=test USE="bzip2 elibc_glibc hppa kernel_linux pcre16 readline recursion-limit unicode userland_GNU zlib" LANG=fr_FR emerge -v1 =dev-libs/libpcre2-10.22 PASS: RunTest PASS: RunGrepTest ============================================================================ Testsuite summary for PCRE2 10.22 ============================================================================ # TOTAL: 2 # PASS: 2 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================
(In reply to Sergei Trofimovich from comment #5) > Does it still happen for you nowadays? Yes. > I tried to reproduce test failure on ia64 (guppy) and no tests failed: > > $ FEATURES=test USE="bzip2 elibc_glibc hppa kernel_linux pcre16 readline > recursion-limit unicode userland_GNU zlib" LANG=fr_FR emerge -v1 > =dev-libs/libpcre2-10.22 Interesting, the USE flags on my system are quite different: [ebuild R ~] dev-libs/libpcre2-10.22::gentoo USE="bzip2 readline recursion-limit unicode zlib (-jit) -libedit -pcre16 -pcre32 -static-libs" Naive question: what's the setting of ACCEPT_KEYWORDS on guppy? I'm running ia64, not ~ia64. Of course, some installed packages are ~ia64, but I'm sticking with ia64 globally. Émeric
(In reply to Émeric Maschino from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > Does it still happen for you nowadays? > > Yes. > > > I tried to reproduce test failure on ia64 (guppy) and no tests failed: > > > > $ FEATURES=test USE="bzip2 elibc_glibc hppa kernel_linux pcre16 readline > > recursion-limit unicode userland_GNU zlib" LANG=fr_FR emerge -v1 > > =dev-libs/libpcre2-10.22 > > Interesting, the USE flags on my system are quite different: > > [ebuild R ~] dev-libs/libpcre2-10.22::gentoo USE="bzip2 readline > recursion-limit unicode zlib (-jit) -libedit -pcre16 -pcre32 -static-libs" > > Naive question: what's the setting of ACCEPT_KEYWORDS on guppy? I'm running > ia64, not ~ia64. Of course, some installed packages are ~ia64, but I'm > sticking with ia64 globally. I'm using all-stable chroot for this test. The only ~ia64 package is =dev-libs/libpcre2-10.22. $ FEATURES=test USE="-* bzip2 readline recursion-limit unicode zlib" LANG=fr_FR emerge -v1 =dev-libs/libpcre2-10.22 The original test failure looks like 'fr_FR' locale was treated like ASCII as if the locale would not be present at all. Do you use locale filter through /etc/locale.gen? Simplest locale test would be: $ LANG=fr_FR date mar. mai 23 21:56:34 UTC 2017
(In reply to Sergei Trofimovich from comment #7) > > I'm using all-stable chroot for this test. The only ~ia64 package is > =dev-libs/libpcre2-10.22. OK, so we're "nearly" compatible, except that I'm not chrooted and that I have additional packages with ~ia64 keyword (basically, everything GNOME-related). > $ FEATURES=test USE="-* bzip2 readline recursion-limit unicode zlib" > LANG=fr_FR emerge -v1 =dev-libs/libpcre2-10.22 > > The original test failure looks like 'fr_FR' locale > was treated like ASCII as if the locale would not be present at all. > > Do you use locale filter through /etc/locale.gen? I don't think so. I simply have: fr_FR UTF-8 > Simplest locale test would be: > $ LANG=fr_FR date > mar. mai 23 21:56:34 UTC 2017 emeric@longspeak ~ $ LANG=fr_FR date mer. mai 24 00:09:20 CEST 2017 And as a cross-test: emeric@longspeak ~ $ date mer. mai 24 00:09:34 CEST 2017 Seems fine to me. Émeric
Yeah, looks fine. Can you post your 'emerge --info =dev-libs/libpcre2-10.22' so i could diff it against guppy's system in hopes to get a clue where difference lies.
> > Do you use locale filter through /etc/locale.gen? > > I don't think so. I simply have: > > fr_FR UTF-8 Aha! That's the trigger! Default 'fr_FR' locale is 1-byte: ISO-8859-1. To trigger failure it's enough to have this file: $ cat /etc/locale.gen #fr_FR ISO-8859-1 fr_FR UTF-8 Fails as bad on amd64 \o/
(In reply to Sergei Trofimovich from comment #10) > > > Do you use locale filter through /etc/locale.gen? > > > > I don't think so. I simply have: > > > > fr_FR UTF-8 > > Aha! That's the trigger! Default 'fr_FR' locale is 1-byte: ISO-8859-1. > To trigger failure it's enough to have this file: > > $ cat /etc/locale.gen > > #fr_FR ISO-8859-1 > fr_FR UTF-8 > > Fails as bad on amd64 \o/ Having chatted on #gentoo-dev this list looks like a canonical mapping of locale without charset to a charset: https://github.com/lattera/glibc/blob/master/localedata/SUPPORTED#L206 fr_FR.UTF-8/UTF-8 fr_FR/ISO-8859-1 fr_FR@euro/ISO-8859-15 I think it means glibc users can safely assume that 'fr_FR' is 'ISO-8859-1'-compatible. and you need to use 'fr_FR.UTF-8' to get UTF-8. IN local-gen syntax it would be: $ cat /etc/locale.gen fr_FR.UTF-8 UTF-8 and in LANG syntax it's LANG="fr_FR.UTF-8".
(In reply to Sergei Trofimovich from comment #11) > > > > Aha! That's the trigger! Default 'fr_FR' locale is 1-byte: ISO-8859-1. > > To trigger failure it's enough to have this file: > > > > $ cat /etc/locale.gen > > > > #fr_FR ISO-8859-1 > > fr_FR UTF-8 > > > > Fails as bad on amd64 \o/ Well catched! > Having chatted on #gentoo-dev this list looks like a canonical mapping > of locale without charset to a charset: > > https://github.com/lattera/glibc/blob/master/localedata/SUPPORTED#L206 > > fr_FR.UTF-8/UTF-8 > fr_FR/ISO-8859-1 > fr_FR@euro/ISO-8859-15 Fixed on my system right now. > I think it means glibc users can safely assume that 'fr_FR' is > 'ISO-8859-1'-compatible. and you need to use 'fr_FR.UTF-8' to get UTF-8. IN > local-gen syntax it would be: > > > $ cat /etc/locale.gen > fr_FR.UTF-8 UTF-8 OK. I was mislead by the comment in /etc/locale.gen: # Where <locale name> starts with a name as found in /usr/share/i18n/locales/. as there are only fr_FR and fr_FR@euro, no UTF-8 reference there. > and in LANG syntax it's LANG="fr_FR.UTF-8". Actually, it seems it's rather LANG="fr_FR.utf8". This is at least how eselect locale {list|set} configured it in /etc/env.d/02locale. Now that everything's correctly configured, I can confirm that dev-libs/libpcre2 emerges successfully with tests enabled. So, in the end, was it really a problem with dev-libs/libpcre2 or simply because Jeroen and my systems were/are misconfigured? Jeroen, how are your locales configured? Émeric
Reassigning to jer@ to clarify fr_FR charset on dev box.
Created attachment 573512 [details] test-suite.log # grep fr_ /etc/locale.gen fr_FR ISO-8859-15 fr_FR UTF-8 fr_FR@euro ISO-8859-15 test-suite.log for dev-libs/libpcre2-10.33
(In reply to Jeroen Roovers from comment #14) > Created attachment 573512 [details] > test-suite.log > > # grep fr_ /etc/locale.gen > fr_FR ISO-8859-15 > fr_FR UTF-8 Do you see it as a valid configuration? I would expect a few problems: - one locale overrides another mchanically in /usr/lib*/locale/ - 'fr_FR UTF-8' generates a 'fr_FR' locale in an unusual encoding (as the test suite shows) > fr_FR@euro ISO-8859-15 > > test-suite.log for dev-libs/libpcre2-10.33
(In reply to Sergei Trofimovich from comment #15) > (In reply to Jeroen Roovers from comment #14) > > # grep fr_ /etc/locale.gen > > fr_FR ISO-8859-15 > > fr_FR UTF-8 > > Do you see it as a valid configuration? I am not sure what is valid any more. I would expect this to work because it has worked in the past. The comment in /etc/locale.gen does not say the first field should be unique, and it explains for both fields where to look them up. locale-gen finishes with no errors.
Perhaps local-gen changed ordering (when parallel mode was added) of locale merging and now it exposed problem in this configuration. toolchain@ will try to make locale-gen more clear about duplicate locales.
At least after a fix of bug #697908 (glibc-9999 only so far) locale-gen now fails loudly when tries to overwrite just generated locale. locale-gen also complains about a duplicate (does it since times of bug #550884, bug #235555). * These locales have been duplicated in your config: fr_FR ISO-8859-15 fr_FR UTF-8 * Some might be filtered, but you must fix it. * Generating 4 locales (this might take a while) with 8 jobs * (3/4) Generating fr_FR.ISO-8859-15@euro ... [ ok ] * (1/4) Generating fr_FR.ISO-8859-15 ... [ ok ] * (4/4) Generating C.UTF-8 ... [ ok ] * (2/4) Generating fr_FR.UTF-8 ... failed to set locale! [error] cannot write output files to `fr_FR': File exists [ !! ] * Generation complete * Adding locales to archive ... [ !! ]
Let's close it as WONTFIX as it's a fr_FR locale misconfiguration.
