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 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] Modified build of LFS using pure cross-compilation and sysroot
On Sat, 2020-05-02 at 19:02 +0200, Thomas Trepl via lfs-dev wrote: > Am Freitag, den 01.05.2020, 15:53 +0200 schrieb Pierre Labastie via > lfs-dev: > > Hi, > > > > I propose a new way to build LFS, which removes the need for the > > /tools > > symlink, and decreases the number of tweaks needed when building > > gcc. > > > > The current build builds a cross-compiler in pass1, and uses it as > > a > > native compiler in pass2. This needs to use a non standard > > directory > > (/tools) to host the toolchain and insulate it from the build > > machine. > > > > The modified build uses the cross compiler to cross compile > > packages > > that need themselves to be rebuilt, thus insulating them > > automatically > > from the host, without the need for a non standard directory > > layout. > > Chroot is entered as soon as possible, and the remaining chapter 5 > > packages are built in chroot. > > Wow, quite interesting! I'd vote to have a deeper look to that > mechanism. > > > This is WIP: the text must be improved at several places, bison and > > flex may be moved to after chroot (to be tested). But the commands > > seem > > to produce an acceptable system, with almost clean ICA. > > > > You can view it at [1], only for sys V since I have not tested > > systemd > > yet (I do not expect many changes). > > > > There are pros and cons compared to the current method: > > > > pros: no /tools symlink, no need to tweak gcc sources, no need to > > build twice ld in binutils-pass2, no need to readjust the toolchain > > after chapter 6 glibc, no need to tweak the gcc specs, no need to > > reinstall kernel headers in chapter 6. > > The less we have to tweak core packages (and gcc is for sure one of > them), the better. I would see that as a great benefit. > > > cons: chroot is entered in the middle of chapter 5 (maybe chapter > > 5 > > should be split), the debug sections of several packages reference > > x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2 > > needs "enable-shared". > Ok, here is the "traditional" separation of Chapter 5 (as run with > host tools) and the Chapter 6 (running previously built tools in > chroot) in danger. But at the end, its just a naming issue. > > With your method we have kinda Chapter 5a building core tools, a > Chapter 5b building toolchain for full build using 5a in chroot and > finally the well-known Chapter 6. > > For the cost of entering the chroot in the middle of chap5, we got > rid > of the adjusting which sometimes causes trouble for newbies. This > knot > is simply untied. > > > Another pro, not tried, is that some simple packages built in > > chapter 5 > > may be built only once if testing them is not required. > > > > Comments and suggestions for improvement (there's a lot of room for > > improvement) welcome. > > Its great! I'd see that as a big evolution step in the LFS > ecosystem. > > I see a restart to continue not more complicated as it is now. When > continuing an interrupted build in chap5 now, user has also to > prepare > the environment carefully. Same in new chapter 5a so no change here. > Continuing in chap 5b, only need to reenter the chroot, this not any > different to want currently has to be done while it comes a few steps > earlier. > > Maybe the new Chapter 5 should end with leaving the chroot > environment > with unmounting the virtFS. It could be a proper end to chap5 as at > this stage, a backup of the system might be recommended (as a hint > for > the user). > The new chapter 6 should then reenter the chroot env again. IMHO this > would make the differentiation of chap5 and 6 a bit easier. > Thanks to all who answered. The book source is now available at: svn co svn://svn.linuxfromscratch.org/LFS/branches/cross-chap5 Some fixes have been done, but there is still a problem with ncurses: the terminfo database is not built because it needs tic from the build host, and we do not require it. Then using the terminal in chroot is painful (no backspace nor line editing capability). One simple fix would be to require tic on the build host with version greater than or equal to 6.0, and remove the --disable-db-install switch. Another fix would be to first build ncurses for the build host (no cross-compile), and use the just built tic (there are configure switches for that). Another fix is to cheat and use the cross-compiled tic on the build host (but it's not pure cross compilation anymore). 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 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
