On Fri, Feb 15, 2019 at 10:58:34PM +0000, Adam Cooper wrote:
> Hi,—I'm working through LFS 8.3. In the test suite for tar, two tests fail.
> 
> ## ------------------------ ##
> ## Summary of the failures. ##
> ## ------------------------ ##
> Failed tests:
> GNU tar 1.30 test suite test groups:
> 
>  NUM: FILE-NAME:LINE     TEST-GROUP-NAME
>       KEYWORDS
> 
>  117: dirrem01.at:34     directory removed before reading
>       create incremental listed dirchange dirrem dirrem01
>  118: dirrem02.at:31     explicitly named directory removed before reading
>       create incremental listed dirchange dirrem dirrem02
> 
> ----------------------------------------
> 
> The redacted log can be seen here: https://pastebin.com/EFvnUEGL . With 
> abandon, I forged ahead, and when I eventually logged out and logged into a 
> new chroot environment, and got to ch. 7.2 LFS Bootscripts, the tar command 
> was not found. I presume it's due to these test failures after the tar 
> compilation. Does anyone know how I can get those tests passing? Thanks,—Adam.
> 
It seems unlikely that those two test failures would prevent the
install working.  But if you are running a scripted build which
exits on error, but somehow fails to stop the overall script that is
controlling the build and lets that merrily continue, then yes, test
failures can do that.

Looking at my own logs, on my server with 8.3 I got one different
failure.  But I tend to use ' || true' in my scripts for packages
where I'm running tests.

OTOH, if you are doing it all manually (i.e. paste command from
browser, run it, paste next command, etc) then all I can think is
that somehow you did not run all the instructions.

If I was a betting man, I'd say you were running a script.  Yes, LFS
users should be using scripts if they continue to build it after
their first successful build, but part of successful scripting is
understanding *how* your own scripts are likely to fail.

But as a longstop to avoid other problems: Go back into chroot with
the PATH which has /tools/bin at the end of it.  Then type

 type -pa tar # i.e. which tar

If that reports /usr/bin/tar, run ldd on it to find out what it is
linked to (presumably something on the host system).  That is the
sort of problem which happens if you log out but do not correctly
restore the environment when you resume.  And if it shows
/tools/bin/tar then please try rerunning your build of tar.

ĸen
-- 
The beauty of reading a page of de Selby is that it leads one
inescapably to the conclusion that one is not, of all nincompoops,
the greates.            -- du Garbandier
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Reply via email to