Hello, 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 systemd.
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 --disable-werror flag. 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. Alain Le 2 juin 2017 23:52, "Bruce Dubbs" <[email protected]> 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 >> completion. >> >> 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 > > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
