[lfs-dev] Oddities while testing.
atoussaint1976 at gmail.com
Sat Jun 3 09:57:37 PDT 2017
I've recently registered to this mailing list some time ago to report on an
LFS svn build for which I had to disable the gold linker for the build of
I just restarted a new build using the 2017-06-02 version of LFS. So far,
the first oddity is that chapter 5 glibc need to be built with the
I'm compiling and installing in a pair of 16GiB tmpfs (the system has 32GiB
of ram) using -j$(nproc) which is 8 core calculated.
This is for an installation on a bootable usb key later.
Le 2 juin 2017 23:52, "Bruce Dubbs" <bruce.dubbs at gmail.com> a écrit :
> Ken Moffat wrote:
>> I've been building a partial system so that I'm ready for the 2017
>> texlive. A large part of the eventual test will be all the deps for
>> biber (something like 100+ perl modules, including those needed for
>> testing each dependency) so I wanted to use perl-5.26 in case any are
>> not yet up-to-date.
>> I built a system on another machine using 2017-05-13 versions, so I
>> figured I would stick with those versions and just update perl (and
>> try the rpc "replacement" for BLFS - I've already documented that).
>> Well, apart from the fun of the perl-5.26.0 build with static libs
>> (thanks, Armin, for explaining the problem), I had two odd issues.
>> I build in Xorg, with one (urxvt) term for the build.
>> In perl, I run the tests in chroot with 'make test >some.log 2>&1'.
>> I've had issues in the past with lib/Benchmark.t hanging (bad kernel
>> config), so when I noticed the perl tests seemed to be taking a long
>> time I opened another term and ran 'tail -f' on the log. To my
>> consternation, the only thing in the log was the output from building
>> the test progs, nothing from the tests themselves. Fortunately, the
>> tests did complete (with the normal extra failures for that machine)
>> and at that point the log showed all the results.
>> But I'm sure I've run 'tail -f' on perl test logs in chroot on some
>> previous builds without problem.
>> The other odd thing was vim - I run the tests, and then I add '||
>> true' so that the expected failure won't break my script by
>> returning false. But the tests got to there, and then nothing more
>> happened, i.e. it did not start to install vim (it just sat there
>> for hours). I cancelled that, retried, again it hung. So for the
>> moment I've commented out the vim tests. Unfortunately I overwrote
>> the original vim testlog when I retried, but it looked like a normal
>> At the moment these are just two more data points for the continuing
>> "ain't life weird?" saga. Hope your builds are not so odd as mine
> Interesting comments Ken. I just did a fresh update today via jhalfs. My
> initial attempt of perl in Chapter 5 didn't work, but I used Armin's patch
> (translated to a sed) and all the tests seemed pretty normal. There were a
> couple of new failures in the overall lfs tests, but when I reran the tests
> in chroot but after Chapter 6 was completed, those new tests passed. At
> that point I just documented the issue in the book and committed.
> The util-linux tests may need some attention. In the log is:
> "Executing the tests in parallel (12 jobs)"
> The only real problem with that is that it throws off the timing data a
> bit. The total build/test time of 42 seconds is pretty quick. :)
> As far as blfs tests go, I've started using a construct like
> (make -k check || true) &&
> I find that running the tests in a subshell seems to encapsulate the tests
> and handle the return code better.
> I'll also note that I do not have any issues with nfs using the current
> packages/instructions in BLFS using gcc7 based lfs systems, but security is
> not a big factor as I am the only one using my internal network and it is
> protected fairly well from the outside.
> -- Bruce
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lfs-dev