Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 07:24:45PM +0100, Ken Moffat via lfs-dev wrote: > > When I get back to my system where I was trying to fix this I'll try > to remember to check that all 13 bison failures were locale-related. > If they were, for my own builds I'll go back to expecting test > failures in bison and man-db. > Yes, all 13 failures were where ittried to use the en_US.utf8 locale. ĸen -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 10:57:23AM -0500, Bruce Dubbs via lfs-dev wrote: > On 5/4/20 3:22 AM, Pierre Labastie via lfs-dev wrote: > > On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote: > > Does this pass after rebooting into the new LFS system? If so, I think we > should stop spending time on this and just add a statement like we have in > glibc: > >misc/tst-ttyname >is known to fail in the LFS chroot environment. > > We also do this in gzip, inetutils, and findutils. > > Alternatively, we can just disable the test like we do in several places in > BLFS. > Fair comment, for our current build system. When I get back to my system where I was trying to fix this I'll try to remember to check that all 13 bison failures were locale-related. If they were, for my own builds I'll go back to expecting test failures in bison and man-db. ĸen -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 10:22:22AM +0200, Pierre Labastie via lfs-dev wrote: > On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote: > > On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev > > wrote: > > > > Doesn't really explain why man-db has sometimes failed, but > > > > passed > > > > other times (for various builders). Maybe there is something > > > > else > > > > there. > > > > > > In sysv book, there was no util-linux in chap. 5 (until Pierre > > > added them to fix > > > problems found by ICA). So the tests using util-linux tools would > > > be skipped. > > > > That make sense. I'll blame Pierre ! ;-) > > > > No, obviously I won't blame Pierre, but this is still very much work > > in progress. > > > > I did blame myself :) > http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-May/073696.html > > so could it be that packages built in chap 5 look for locales in > /tools/share? > > A few experiments (the "toto" command is just to have bash printing an > error message): > root [ / ]# echo $LC_ALL > fr_FR.UTF-8 > root [ / ]# exec /bin/bash > root [ / ]# toto > bash: toto : commande introuvable > > root [ / ]# exec /tools/bin/bash > bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8) > root [ / ]# echo $LC_ALL > fr_FR.UTF-8 > root [ / ]# toto > bash: toto: command not found > > So /tools/bin/bash is not seeking locales in /usr/lib/locale/locale- > archive (where compiled locales are stored, man localedef for details). > > I guess it is the same for col from util-linux. > > One possible fix is: > mkdir /tools/lib/locale > ln -s /usr/lib/locale/locale-archive /tools/lib/locale > > with that: > root [ / ]# export LC_ALL=fr_FR.UTF-8 > root [ / ]# exec /tools/bin/bash > root [ / ]# toto > bash: toto : commande introuvable > > Another tweak needed because of a separate /tools... > > Pierre > Thanks for looking at this. You've convinced me that your cross-build will be the way to go. ĸen -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 5/4/20 3:22 AM, Pierre Labastie via lfs-dev wrote: On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote: On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev wrote: Doesn't really explain why man-db has sometimes failed, but passed other times (for various builders). Maybe there is something else there. In sysv book, there was no util-linux in chap. 5 (until Pierre added them to fix problems found by ICA). So the tests using util-linux tools would be skipped. That make sense. I'll blame Pierre ! ;-) No, obviously I won't blame Pierre, but this is still very much work in progress. I did blame myself :) http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-May/073696.html so could it be that packages built in chap 5 look for locales in /tools/share? A few experiments (the "toto" command is just to have bash printing an error message): root [ / ]# echo $LC_ALL fr_FR.UTF-8 root [ / ]# exec /bin/bash root [ / ]# toto bash: toto : commande introuvable root [ / ]# exec /tools/bin/bash bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8) root [ / ]# echo $LC_ALL fr_FR.UTF-8 root [ / ]# toto bash: toto: command not found So /tools/bin/bash is not seeking locales in /usr/lib/locale/locale- archive (where compiled locales are stored, man localedef for details). I guess it is the same for col from util-linux. One possible fix is: mkdir /tools/lib/locale ln -s /usr/lib/locale/locale-archive /tools/lib/locale with that: root [ / ]# export LC_ALL=fr_FR.UTF-8 root [ / ]# exec /tools/bin/bash root [ / ]# toto bash: toto : commande introuvable Another tweak needed because of a separate /tools... Does this pass after rebooting into the new LFS system? If so, I think we should stop spending time on this and just add a statement like we have in glibc: misc/tst-ttyname is known to fail in the LFS chroot environment. We also do this in gzip, inetutils, and findutils. Alternatively, we can just disable the test like we do in several places in BLFS. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote: > On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev > wrote: > > > Doesn't really explain why man-db has sometimes failed, but > > > passed > > > other times (for various builders). Maybe there is something > > > else > > > there. > > > > In sysv book, there was no util-linux in chap. 5 (until Pierre > > added them to fix > > problems found by ICA). So the tests using util-linux tools would > > be skipped. > > That make sense. I'll blame Pierre ! ;-) > > No, obviously I won't blame Pierre, but this is still very much work > in progress. > I did blame myself :) http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-May/073696.html so could it be that packages built in chap 5 look for locales in /tools/share? A few experiments (the "toto" command is just to have bash printing an error message): root [ / ]# echo $LC_ALL fr_FR.UTF-8 root [ / ]# exec /bin/bash root [ / ]# toto bash: toto : commande introuvable root [ / ]# exec /tools/bin/bash bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8) root [ / ]# echo $LC_ALL fr_FR.UTF-8 root [ / ]# toto bash: toto: command not found So /tools/bin/bash is not seeking locales in /usr/lib/locale/locale- archive (where compiled locales are stored, man localedef for details). I guess it is the same for col from util-linux. One possible fix is: mkdir /tools/lib/locale ln -s /usr/lib/locale/locale-archive /tools/lib/locale with that: root [ / ]# export LC_ALL=fr_FR.UTF-8 root [ / ]# exec /tools/bin/bash root [ / ]# toto bash: toto : commande introuvable Another tweak needed because of a separate /tools... Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 12:50:12PM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-04 04:12 +0100，Ken Moffat via lfs-dev wrote:
> > On Mon, May 04, 2020 at 03:34:53AM +0100, Ken Moffat via lfs-dev wrote:
> > > On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> > > > On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > > > > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev
> > > > > wrote:
> > > > > > I'm building with LFS as at 25th April. My previous build was in
> > > > > > early April, and I think this is the first time I've seen a failure
> > > > > > in the man-db tests. With man-db-2.9.1 :
> > > > > >
> > > > > > FAIL: man-missing-locales
> > > > > >
> > > > > > and src/tests/test-suite.log has:
> > > > > >
> > > > > > FAIL: man-missing-locales
> > > > > > =
> > > > > >
> > > > > > col: failed on line 319: Invalid or incomplete multibyte or wide
> > > > > > character
> > > > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p
> > > > > > -x
> > > > > > | sed
> > > > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > > > > FAIL: missing locales
> > > > > > FAIL man-missing-locales (exit status: 1)
> > > > > >
> > > > > > Given that things have changed since my previous build, is anyone
> > > > > > else seeing this ? I suspect the error might be "mine, all mine",
> > > > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > > > unless it really is common. Looking at my glibc log I did
> > > > > > apparently install the en_US.UTF-8 locale.
> > > > > >
> > > > > > ĸen
> > > > >
> > > > > Update: I'm doing a fresh build to look at the test failures in this
> > > > > and in bison (and also to make sure I've fixed my own screw-up in
> > > > > removing the symlinked headers before rebuilding util-linux).
> > > > >
> > > > > Got to bison, failures as before. First is
> > > > >
> > > > > 131. diagnostics.at:107: testing Warnings ...
> > > > > ./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug
> > > > > -Wall
> > > > > input.y
> > > > > --- experr 2020-05-03 23:20:06.028040360 +
> > > > > +++ /building/bison-3.5.4/tests/testsuite.dir/at-
> > > > > groups/131/stderr 2020-
> > > > > 05-03 23:20:06.057040734 +
> > > > > @@ -1,3 +1,4 @@
> > > > > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale
> > > > > (en_US.utf8)
> > > > > input.y:9.12-14: warning: symbol FOO redeclared
> > > > > [-Wother]
> > > > > 9 | %token FOO FOO FOO
> > > > >|^~~
> > > > > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > > > > (diagnostics.at:107)
> > > > >
> > > > > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > > > > variants. The capitalized version is definitely installed, accoding
> > > > > to my log from glibc.
> > > >
> > > > So I think the issue is: we are using chapter 5 bash for bison, and
> > > > chapter 5
> > > > util-linux for man-db. Chapter 5 tools' locale archive is
> > > > /tools/lib/locale/locale-archive, which is not installed.
> > > >
> > > > Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this
> > > > problem.
> > > > --
> > > > Xi Ruoyao
> > > > School of Aerospace Science and Technology, Xidian University
> > > >
> > >
> > > Sounds plausible. Will give it a try.
> > >
> > > ĸen
> >
> > Came back to it to check that glibc had got through my additions,
> > then checked the logs. In all three runs glibc seems to have
> > installed a LOT of locales in /tools/hare/i18n/locales/
>
> They are "uncompiled" locale data. Use:
>
> install -vdm755 /tools/lib/locale
> /tools/bin/localedef -i en_US -f UTF-8 en_US.UTF-8
>
> to make a /tools/bin/locale/locale-archive (which is necessary at runtime, to
> use locales) from them.
>
What I added after make install was:
mkdir -pv /tools/lib/locale
localedef -i en_US -f UTF-8 en_GB.UTF-8
And since I was running as the lfs user, I don't think using a path
on localedef is necessary.
> > No longer hopeful, but will let it run.
> >
13 failures, as before.
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev wrote: > > > > Doesn't really explain why man-db has sometimes failed, but passed > > other times (for various builders). Maybe there is something else > > there. > > In sysv book, there was no util-linux in chap. 5 (until Pierre added them to > fix > problems found by ICA). So the tests using util-linux tools would be skipped. That make sense. I'll blame Pierre ! ;-) No, obviously I won't blame Pierre, but this is still very much work in progress. After the tests failed this time, I exited chroot and re-entered it. Tried passing LC_ALL=en_US.UTF-8 ; date - again got the error message about the locale. Rebuilt bison anyway, tests similarly failed. Feeling old, going to bed! (see .sig:) ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 2020-05-04 04:19 +0100, Ken Moffat via lfs-dev wrote: > On Sun, May 03, 2020 at 09:13:27PM -0500, Bruce Dubbs via lfs-dev wrote: > > On 5/3/20 8:15 PM, Ken Moffat via lfs-dev wrote: > > > > > root in chroot /# export LC_ALL=en_US.iISO-8859-1 && date > > > bash: warning: setlocale: LC_ALL: cannot change locale > > > (en_US.ISO-8859-1): > > > No such file or directory > > > Mon May 4 00:50:46 UTC 2020 > > > > export LC_ALL=en_US.iISO-8859-1 && date > > bash: warning: setlocale: LC_ALL: cannot change locale (en_US.iISO-8859-1): > > No such file or directory > > > > Note the typo. > > > > Yeah, shit happens - I noticed my first attempt had been .SO-8859-1 > and thought I'd fixed it, forgetting this was bash not vim. > > > Is it because the locales are not available until after glibc and then > > leaving/reentering chroot? > > > > -- Bruce > > Possible. A bit of a pain if that is so. Still building /tools for > this run, then I'll let it run (following xry111's suggestion to add > the locale in /tools glibc, although I now doubt that - see what I > just posted). > > Assuming bison still fails its tests, I'll try that. > > Doesn't really explain why man-db has sometimes failed, but passed > other times (for various builders). Maybe there is something else > there. In sysv book, there was no util-linux in chap. 5 (until Pierre added them to fix problems found by ICA). So the tests using util-linux tools would be skipped. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 2020-05-04 04:12 +0100，Ken Moffat via lfs-dev wrote:
> On Mon, May 04, 2020 at 03:34:53AM +0100, Ken Moffat via lfs-dev wrote:
> > On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> > > On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > > > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > > > > I'm building with LFS as at 25th April. My previous build was in
> > > > > early April, and I think this is the first time I've seen a failure
> > > > > in the man-db tests. With man-db-2.9.1 :
> > > > >
> > > > > FAIL: man-missing-locales
> > > > >
> > > > > and src/tests/test-suite.log has:
> > > > >
> > > > > FAIL: man-missing-locales
> > > > > =
> > > > >
> > > > > col: failed on line 319: Invalid or incomplete multibyte or wide
> > > > > character
> > > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x
> > > > > | sed
> > > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > > > FAIL: missing locales
> > > > > FAIL man-missing-locales (exit status: 1)
> > > > >
> > > > > Given that things have changed since my previous build, is anyone
> > > > > else seeing this ? I suspect the error might be "mine, all mine",
> > > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > > unless it really is common. Looking at my glibc log I did
> > > > > apparently install the en_US.UTF-8 locale.
> > > > >
> > > > > ĸen
> > > >
> > > > Update: I'm doing a fresh build to look at the test failures in this
> > > > and in bison (and also to make sure I've fixed my own screw-up in
> > > > removing the symlinked headers before rebuilding util-linux).
> > > >
> > > > Got to bison, failures as before. First is
> > > >
> > > > 131. diagnostics.at:107: testing Warnings ...
> > > > ./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug
> > > > -Wall
> > > > input.y
> > > > --- experr 2020-05-03 23:20:06.028040360 +
> > > > +++ /building/bison-3.5.4/tests/testsuite.dir/at-
> > > > groups/131/stderr 2020-
> > > > 05-03 23:20:06.057040734 +
> > > > @@ -1,3 +1,4 @@
> > > > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> > > > input.y:9.12-14: warning: symbol FOO redeclared
> > > > [-Wother]
> > > > 9 | %token FOO FOO FOO
> > > >|^~~
> > > > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > > > (diagnostics.at:107)
> > > >
> > > > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > > > variants. The capitalized version is definitely installed, accoding
> > > > to my log from glibc.
> > >
> > > So I think the issue is: we are using chapter 5 bash for bison, and
> > > chapter 5
> > > util-linux for man-db. Chapter 5 tools' locale archive is
> > > /tools/lib/locale/locale-archive, which is not installed.
> > >
> > > Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this
> > > problem.
> > > --
> > > Xi Ruoyao
> > > School of Aerospace Science and Technology, Xidian University
> > >
> >
> > Sounds plausible. Will give it a try.
> >
> > ĸen
>
> Came back to it to check that glibc had got through my additions,
> then checked the logs. In all three runs glibc seems to have
> installed a LOT of locales in /tools/hare/i18n/locales/
They are "uncompiled" locale data. Use:
install -vdm755 /tools/lib/locale
/tools/bin/localedef -i en_US -f UTF-8 en_US.UTF-8
to make a /tools/bin/locale/locale-archive (which is necessary at runtime, to
use locales) from them.
> No longer hopeful, but will let it run.
>
> ĸen
> --
> See You Later, Holy Poppadom!
> -- Red Dwarf, The Promised Land
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Sun, May 03, 2020 at 09:13:27PM -0500, Bruce Dubbs via lfs-dev wrote: > On 5/3/20 8:15 PM, Ken Moffat via lfs-dev wrote: > > > root in chroot /# export LC_ALL=en_US.iISO-8859-1 && date > > bash: warning: setlocale: LC_ALL: cannot change locale (en_US.ISO-8859-1): > > No such file or directory > > Mon May 4 00:50:46 UTC 2020 > > export LC_ALL=en_US.iISO-8859-1 && date > bash: warning: setlocale: LC_ALL: cannot change locale (en_US.iISO-8859-1): > No such file or directory > > Note the typo. > Yeah, shit happens - I noticed my first attempt had been .SO-8859-1 and thought I'd fixed it, forgetting this was bash not vim. > Is it because the locales are not available until after glibc and then > leaving/reentering chroot? > > -- Bruce Possible. A bit of a pain if that is so. Still building /tools for this run, then I'll let it run (following xry111's suggestion to add the locale in /tools glibc, although I now doubt that - see what I just posted). Assuming bison still fails its tests, I'll try that. Doesn't really explain why man-db has sometimes failed, but passed other times (for various builders). Maybe there is something else there. ĸen -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 03:34:53AM +0100, Ken Moffat via lfs-dev wrote:
> On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > > > I'm building with LFS as at 25th April. My previous build was in
> > > > early April, and I think this is the first time I've seen a failure
> > > > in the man-db tests. With man-db-2.9.1 :
> > > >
> > > > FAIL: man-missing-locales
> > > >
> > > > and src/tests/test-suite.log has:
> > > >
> > > > FAIL: man-missing-locales
> > > > =
> > > >
> > > > col: failed on line 319: Invalid or incomplete multibyte or wide
> > > > character
> > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x
> > > > | sed
> > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > > FAIL: missing locales
> > > > FAIL man-missing-locales (exit status: 1)
> > > >
> > > > Given that things have changed since my previous build, is anyone
> > > > else seeing this ? I suspect the error might be "mine, all mine",
> > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > unless it really is common. Looking at my glibc log I did
> > > > apparently install the en_US.UTF-8 locale.
> > > >
> > > > ĸen
> > >
> > > Update: I'm doing a fresh build to look at the test failures in this
> > > and in bison (and also to make sure I've fixed my own screw-up in
> > > removing the symlinked headers before rebuilding util-linux).
> > >
> > > Got to bison, failures as before. First is
> > >
> > > 131. diagnostics.at:107: testing Warnings ...
> > > ./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug -Wall
> > > input.y
> > > --- experr 2020-05-03 23:20:06.028040360 +
> > > +++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr
> > > 2020-
> > > 05-03 23:20:06.057040734 +
> > > @@ -1,3 +1,4 @@
> > > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> > > input.y:9.12-14: warning: symbol FOO redeclared
> > > [-Wother]
> > > 9 | %token FOO FOO FOO
> > >|^~~
> > > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > > (diagnostics.at:107)
> > >
> > > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > > variants. The capitalized version is definitely installed, accoding
> > > to my log from glibc.
> >
> > So I think the issue is: we are using chapter 5 bash for bison, and chapter
> > 5
> > util-linux for man-db. Chapter 5 tools' locale archive is
> > /tools/lib/locale/locale-archive, which is not installed.
> >
> > Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this
> > problem.
> > --
> > Xi Ruoyao
> > School of Aerospace Science and Technology, Xidian University
> >
>
> Sounds plausible. Will give it a try.
>
> ĸen
Came back to it to check that glibc had got through my additions,
then checked the logs. In all three runs glibc seems to have
installed a LOT of locales in /tools/hare/i18n/locales/
No longer hopeful, but will let it run.
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Mon, May 04, 2020 at 09:53:04AM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> > On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > > I'm building with LFS as at 25th April. My previous build was in
> > > early April, and I think this is the first time I've seen a failure
> > > in the man-db tests. With man-db-2.9.1 :
> > >
> > > FAIL: man-missing-locales
> > >
> > > and src/tests/test-suite.log has:
> > >
> > > FAIL: man-missing-locales
> > > =
> > >
> > > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x |
> > > sed
> > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > FAIL: missing locales
> > > FAIL man-missing-locales (exit status: 1)
> > >
> > > Given that things have changed since my previous build, is anyone
> > > else seeing this ? I suspect the error might be "mine, all mine",
> > > so I'm reluctant to add to the noise by reporting iti upstream
> > > unless it really is common. Looking at my glibc log I did
> > > apparently install the en_US.UTF-8 locale.
> > >
> > > ĸen
> >
> > Update: I'm doing a fresh build to look at the test failures in this
> > and in bison (and also to make sure I've fixed my own screw-up in
> > removing the symlinked headers before rebuilding util-linux).
> >
> > Got to bison, failures as before. First is
> >
> > 131. diagnostics.at:107: testing Warnings ...
> > ./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug -Wall
> > input.y
> > --- experr 2020-05-03 23:20:06.028040360 +
> > +++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr
> > 2020-
> > 05-03 23:20:06.057040734 +
> > @@ -1,3 +1,4 @@
> > +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> > input.y:9.12-14: warning: symbol FOO redeclared
> > [-Wother]
> > 9 | %token FOO FOO FOO
> >|^~~
> > 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> > (diagnostics.at:107)
> >
> > So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> > variants. The capitalized version is definitely installed, accoding
> > to my log from glibc.
>
> So I think the issue is: we are using chapter 5 bash for bison, and chapter 5
> util-linux for man-db. Chapter 5 tools' locale archive is
> /tools/lib/locale/locale-archive, which is not installed.
>
> Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this problem.
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
>
Sounds plausible. Will give it a try.
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 5/3/20 8:15 PM, Ken Moffat via lfs-dev wrote: BUT in chroot I can only set the locale to C or POSIX: Interesting. If I go into chroot on a completed jhalfs build, I get: root in chroot /# export LC_ALL=en_US.UTF-8 && date bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory Mon May 4 00:48:39 UTC 2020 root:/#export LC_ALL=en_US.UTF-8 && date Sun 03 May 2020 09:05:12 PM CDT root in chroot /# export LC_ALL=fr_FR.UTF-8 && date bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8): No such file or directory Mon May 4 00:48:52 UTC 2020 root:/#export LC_ALL=fr_FR.UTF-8 && date dim. 03 mai 2020 21:05:37 CDT root in chroot /# export LC_ALL=en_US.utf8 && date bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) Mon May 4 00:50:01 UTC 2020 root:/#export LC_ALL=en_US.utf8 && date Sun 03 May 2020 09:06:37 PM CDT root in chroot /# export LC_ALL=en_US.iISO-8859-1 && date bash: warning: setlocale: LC_ALL: cannot change locale (en_US.ISO-8859-1): No such file or directory Mon May 4 00:50:46 UTC 2020 export LC_ALL=en_US.iISO-8859-1 && date bash: warning: setlocale: LC_ALL: cannot change locale (en_US.iISO-8859-1): No such file or directory Note the typo. root:/#export LC_ALL=en_US.ISO-8859-1 && date Sun 03 May 2020 09:07:24 PM CDT root in chroot /# export LC_ALL=C && date Mon May 4 00:51:16 UTC 2020 root:/#export LC_ALL=C && date Sun May 3 21:08:55 CDT 2020 root in chroot /# export LC_ALL=C.UTF-8 && date bash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file or directory Mon May 4 00:51:27 UTC 2020 root:/#export LC_ALL=C.UTF-8 && date Sun May 3 21:09:37 CDT 2020 root in chroot /# export LC_ALL=POSIX && date Mon May 4 00:51:37 UTC 2020 root:/#export LC_ALL=POSIX && date Sun May 3 21:10:01 CDT 2020 Is it because the locales are not available until after glibc and then leaving/reentering chroot? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > I'm building with LFS as at 25th April. My previous build was in
> > early April, and I think this is the first time I've seen a failure
> > in the man-db tests. With man-db-2.9.1 :
> >
> > FAIL: man-missing-locales
> >
> > and src/tests/test-suite.log has:
> >
> > FAIL: man-missing-locales
> > =
> >
> > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
> > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > FAIL: missing locales
> > FAIL man-missing-locales (exit status: 1)
> >
> > Given that things have changed since my previous build, is anyone
> > else seeing this ? I suspect the error might be "mine, all mine",
> > so I'm reluctant to add to the noise by reporting iti upstream
> > unless it really is common. Looking at my glibc log I did
> > apparently install the en_US.UTF-8 locale.
> >
> > ĸen
>
> Update: I'm doing a fresh build to look at the test failures in this
> and in bison (and also to make sure I've fixed my own screw-up in
> removing the symlinked headers before rebuilding util-linux).
>
> Got to bison, failures as before. First is
>
> 131. diagnostics.at:107: testing Warnings ...
> ./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug -Wall
> input.y
> --- experr 2020-05-03 23:20:06.028040360 +
> +++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr 2020-
> 05-03 23:20:06.057040734 +
> @@ -1,3 +1,4 @@
> +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> input.y:9.12-14: warning: symbol FOO redeclared
> [-Wother]
> 9 | %token FOO FOO FOO
>|^~~
> 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> (diagnostics.at:107)
>
> So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> variants. The capitalized version is definitely installed, accoding
> to my log from glibc.
So I think the issue is: we are using chapter 5 bash for bison, and chapter 5
util-linux for man-db. Chapter 5 tools' locale archive is
/tools/lib/locale/locale-archive, which is not installed.
Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this problem.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> I'm building with LFS as at 25th April. My previous build was in
> early April, and I think this is the first time I've seen a failure
> in the man-db tests. With man-db-2.9.1 :
>
> FAIL: man-missing-locales
>
> and src/tests/test-suite.log has:
>
> FAIL: man-missing-locales
> =
>
> col: failed on line 319: Invalid or incomplete multibyte or wide character
> man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
> -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> FAIL: missing locales
> FAIL man-missing-locales (exit status: 1)
>
> Given that things have changed since my previous build, is anyone
> else seeing this ? I suspect the error might be "mine, all mine",
> so I'm reluctant to add to the noise by reporting iti upstream
> unless it really is common. Looking at my glibc log I did
> apparently install the en_US.UTF-8 locale.
>
> ĸen
Update: I'm doing a fresh build to look at the test failures in this
and in bison (and also to make sure I've fixed my own screw-up in
removing the symlinked headers before rebuilding util-linux).
Got to bison, failures as before. First is
131. diagnostics.at:107: testing Warnings ...
./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug -Wall
input.y
--- experr 2020-05-03 23:20:06.028040360 +
+++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr
2020-05-03 23:20:06.057040734 +
@@ -1,3 +1,4 @@
+/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
input.y:9.12-14: warning: symbol FOO redeclared
[-Wother]
9 | %token FOO FOO FOO
|^~~
131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
(diagnostics.at:107)
So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
variants. The capitalized version is definitely installed, accoding
to my log from glibc.
On the system completed on Sunday, from which I am building the new
test one, I can do things like:
ken@deluxe ~ $echo $LC_ALL
en_GB.UTF-8
ken@deluxe ~ $export LC_ALL=en_US.UTF-8 && date
Mon 04 May 2020 02:02:15 AM BST
ken@deluxe ~ $export LC_ALL=en_US.utf8 && date
Mon 04 May 2020 02:02:23 AM BST
ken@deluxe ~ $export LC_ALL=fr_FR.utf8 && date
lun. 04 mai 2020 02:02:50 BST
(that latter is just to prove that something changes)
BUT in chroot I can only set the locale to C or POSIX:
root in chroot /# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
root in chroot /# export LC_ALL=en_US.UTF-8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such
file or directory
Mon May 4 00:48:39 UTC 2020
root in chroot /# export LC_ALL=fr_FR.UTF-8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8): No such
file or directory
Mon May 4 00:48:52 UTC 2020
root in chroot /# export LC_ALL=en_US.utf8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Mon May 4 00:50:01 UTC 2020
root in chroot /# export LC_ALL=en_US.iISO-8859-1 && date
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.ISO-8859-1): No
such file or directory
Mon May 4 00:50:46 UTC 2020
root in chroot /# export LC_ALL=C && date
Mon May 4 00:51:16 UTC 2020
root in chroot /# export LC_ALL=C.UTF-8 && date
bash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file
or directory
Mon May 4 00:51:27 UTC 2020
root in chroot /# export LC_ALL=POSIX && date
Mon May 4 00:51:37 UTC 2020
Puzzled.
From the test logs for the complited build I can see PASS against
'utf8' in grep, make, Python (and a fail in acl, but I expect acl to
fail).
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Sun, 2020-05-03 at 01:18 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/2/20 11:44 PM, Ken Moffat via lfs-dev wrote:
> > On Sun, May 03, 2020 at 12:02:12PM +0800, Xi Ruoyao via lfs-dev
> > wrote:
> > > On 2020-05-03 04:18 +0100, Ken Moffat via lfs-dev wrote:
> > > > I'm building with LFS as at 25th April. My previous build was
> > > > in
> > > > early April, and I think this is the first time I've seen a
> > > > failure
> > > > in the man-db tests. With man-db-2.9.1 :
> > > >
> > > > FAIL: man-missing-locales
> > > >
> > > > and src/tests/test-suite.log has:
> > > >
> > > > FAIL: man-missing-locales
> > > > =
> > > >
> > > > col: failed on line 319: Invalid or incomplete multibyte or
> > > > wide character
> > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col
> > > > -b -p -x | sed
> > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > >FAIL: missing locales
> > > > FAIL man-missing-locales (exit status: 1)
> > > >
> > > > Given that things have changed since my previous build, is
> > > > anyone
> > > > else seeing this ? I suspect the error might be "mine, all
> > > > mine",
> > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > unless it really is common. Looking at my glibc log I did
> > > > apparently install the en_US.UTF-8 locale.
> > >
> > > I've seen this many times (almost each time I built LFS).
> >
> > I'm surprised - as I just replied to Doug, this is the first time
> > this has hit me. Will take a look on the completed system, to see
> > if it breaks there.
>
> The man-db test failure may be due to some other package that we've
> added since 9.1. However
>
> http://www.linuxfromscratch.org/lfs/build-logs/9.1/i7-5820K/test-logs/135-man-db-2.9.0
>
> shows no failures. But the systemd log Doug uploaded (i5-6600k)
> does
> show it. AFAICT, the differences are minor. In my sysv system
> util-linux was not built in Chapter 5, but it is built in Doug's
> systemd
> build.
>
> I will also note that the sysv instructions have the extra
> configuration
> items:
>
> --with-systemdtmpfilesdir= \
> --with-systemdsystemunitdir=
>
> and there is a sed in systemd version that is not in the sysv
> version.
> A cursory look at those changes doesn't indicate to me an issue that
> would cause the man-missing-locales test to fail.
>
> If someone really wants to track this down, look at
> src/tests/testlib.sh
> and src/tests/man-missing-locales. They are relatively short sh
> scripts.
The log alludes to "col" which is an util-linux program. And util-linux
has been in chapter 5 for a while in the systemd book, while it has
been added recently to the SysV book (to "clean" ICA). So it really
looks like a candidate to explain the failure!
Note also that on a completed system, the tests pass, so my guess is
that it works after util-linux is installed in chapter 6 (to be
verified).
Now the call to col is internal to "man", so it may take some time to
find how to print more explicit errors...
Will try to remove util-linux and run the tests on a completed system.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 5/2/20 11:44 PM, Ken Moffat via lfs-dev wrote:
On Sun, May 03, 2020 at 12:02:12PM +0800, Xi Ruoyao via lfs-dev wrote:
On 2020-05-03 04:18 +0100, Ken Moffat via lfs-dev wrote:
I'm building with LFS as at 25th April. My previous build was in
early April, and I think this is the first time I've seen a failure
in the man-db tests. With man-db-2.9.1 :
FAIL: man-missing-locales
and src/tests/test-suite.log has:
FAIL: man-missing-locales
=
col: failed on line 319: Invalid or incomplete multibyte or wide character
man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
-e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
FAIL: missing locales
FAIL man-missing-locales (exit status: 1)
Given that things have changed since my previous build, is anyone
else seeing this ? I suspect the error might be "mine, all mine",
so I'm reluctant to add to the noise by reporting iti upstream
unless it really is common. Looking at my glibc log I did
apparently install the en_US.UTF-8 locale.
I've seen this many times (almost each time I built LFS).
I'm surprised - as I just replied to Doug, this is the first time
this has hit me. Will take a look on the completed system, to see
if it breaks there.
The man-db test failure may be due to some other package that we've
added since 9.1. However
http://www.linuxfromscratch.org/lfs/build-logs/9.1/i7-5820K/test-logs/135-man-db-2.9.0
shows no failures. But the systemd log Doug uploaded (i5-6600k) does
show it. AFAICT, the differences are minor. In my sysv system
util-linux was not built in Chapter 5, but it is built in Doug's systemd
build.
I will also note that the sysv instructions have the extra configuration
items:
--with-systemdtmpfilesdir= \
--with-systemdsystemunitdir=
and there is a sed in systemd version that is not in the sysv version.
A cursory look at those changes doesn't indicate to me an issue that
would cause the man-missing-locales test to fail.
If someone really wants to track this down, look at src/tests/testlib.sh
and src/tests/man-missing-locales. They are relatively short sh scripts.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Sun, May 03, 2020 at 12:02:12PM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-03 04:18 +0100, Ken Moffat via lfs-dev wrote:
> > I'm building with LFS as at 25th April. My previous build was in
> > early April, and I think this is the first time I've seen a failure
> > in the man-db tests. With man-db-2.9.1 :
> >
> > FAIL: man-missing-locales
> >
> > and src/tests/test-suite.log has:
> >
> > FAIL: man-missing-locales
> > =
> >
> > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
> > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > FAIL: missing locales
> > FAIL man-missing-locales (exit status: 1)
> >
> > Given that things have changed since my previous build, is anyone
> > else seeing this ? I suspect the error might be "mine, all mine",
> > so I'm reluctant to add to the noise by reporting iti upstream
> > unless it really is common. Looking at my glibc log I did
> > apparently install the en_US.UTF-8 locale.
>
> I've seen this many times (almost each time I built LFS).
I'm surprised - as I just replied to Doug, this is the first time
this has hit me. Will take a look on the completed system, to see
if it breaks there.
Thanks.
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On Sat, May 02, 2020 at 10:58:11PM -0500, Douglas R. Reno via lfs-dev wrote:
>
> On 5/2/20 10:18 PM, Ken Moffat via lfs-dev wrote:
> > I'm building with LFS as at 25th April. My previous build was in
> > early April, and I think this is the first time I've seen a failure
> > in the man-db tests. With man-db-2.9.1 :
> >
> > FAIL: man-missing-locales
> >
> > and src/tests/test-suite.log has:
> >
> > FAIL: man-missing-locales
> > =
> >
> > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x |
> > sed -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> >FAIL: missing locales
> > FAIL man-missing-locales (exit status: 1)
> >
> > Given that things have changed since my previous build, is anyone
> > else seeing this ? I suspect the error might be "mine, all mine",
> > so I'm reluctant to add to the noise by reporting iti upstream
> > unless it really is common. Looking at my glibc log I did
> > apparently install the en_US.UTF-8 locale.
> >
> > ĸen
>
> Hi Ken,
>
> I got that failure on my last build too (SVN-20200501):
>
> renodr [ /mnt/lfs/jhalfs/test-logs ]$ grep FAIL 137-man-db-2.9.1
> FAIL: man-missing-locales
>
> From what I gather, I have the same problem. My guess is that it's a bug in
> the test suite, but I'm not sure on that. I do use the en_US locale as my
> primary. I normally do a jhalfs build after Bruce does an update to LFS to
> verify that packages such as meson don't break systemd like they did in the
> past.
>
> Looking back on it - I have this failure with man-db-2.9.0 as well, on my
> build on 20200201! I didn't review the test suite logs on that one :(
>
>
> - Doug
>
Hi Doug,
that's interesting. My previous build was for LFS 20200403 on a
different machine, but with 2.9.1, and that did not fail (I only
noticed because recently man-db tests have not failed for me, so any
new failure stops the build - on packages where I expect one or more
tests to fail I add ' || true').
Assuming that the new build boots, and allows me to get past the
current firefox-68.8.0 candidate (build 2), I'll look at this in the
completed system. Similarly with bison which is still failing.
Oh well, it will make a change from looking at the details of fonts,
and maybe put off when I have to address cantarell in BLFS ;-)
[ Current cantarell also installs a -VF file which seems to contain
at least all the main variants, but breaks xelatex, and it no longer
includes cyrillic glyphs - Noto Sans UI was recommended as an
alternative, but Noto Sans Display seems to have replaced that -
available from debian, otherwise only git versions - and in any case
Noto fonts need overrides before fontconfig will use them if
preferred fonts such as DejaVu Sans, which is probably larger, are
present. Supposedly, kde also prefers Noto, with a similar issue
for non latin/cyrillic/greek languages, but I've long since given up
on building kde. ]
Plus ça change!
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 2020-05-03 04:18 +0100, Ken Moffat via lfs-dev wrote:
> I'm building with LFS as at 25th April. My previous build was in
> early April, and I think this is the first time I've seen a failure
> in the man-db tests. With man-db-2.9.1 :
>
> FAIL: man-missing-locales
>
> and src/tests/test-suite.log has:
>
> FAIL: man-missing-locales
> =
>
> col: failed on line 319: Invalid or incomplete multibyte or wide character
> man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
> -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> FAIL: missing locales
> FAIL man-missing-locales (exit status: 1)
>
> Given that things have changed since my previous build, is anyone
> else seeing this ? I suspect the error might be "mine, all mine",
> so I'm reluctant to add to the noise by reporting iti upstream
> unless it really is common. Looking at my glibc log I did
> apparently install the en_US.UTF-8 locale.
I've seen this many times (almost each time I built LFS).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Test failure in man-db
On 5/2/20 10:18 PM, Ken Moffat via lfs-dev wrote:
I'm building with LFS as at 25th April. My previous build was in
early April, and I think this is the first time I've seen a failure
in the man-db tests. With man-db-2.9.1 :
FAIL: man-missing-locales
and src/tests/test-suite.log has:
FAIL: man-missing-locales
=
col: failed on line 319: Invalid or incomplete multibyte or wide character
man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed -e
'/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
FAIL: missing locales
FAIL man-missing-locales (exit status: 1)
Given that things have changed since my previous build, is anyone
else seeing this ? I suspect the error might be "mine, all mine",
so I'm reluctant to add to the noise by reporting iti upstream
unless it really is common. Looking at my glibc log I did
apparently install the en_US.UTF-8 locale.
ĸen
Hi Ken,
I got that failure on my last build too (SVN-20200501):
renodr [ /mnt/lfs/jhalfs/test-logs ]$ grep FAIL 137-man-db-2.9.1
FAIL: man-missing-locales
From what I gather, I have the same problem. My guess is that it's a
bug in the test suite, but I'm not sure on that. I do use the en_US
locale as my primary. I normally do a jhalfs build after Bruce does an
update to LFS to verify that packages such as meson don't break systemd
like they did in the past.
Looking back on it - I have this failure with man-db-2.9.0 as well, on
my build on 20200201! I didn't review the test suite logs on that one :(
- Doug
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
