Re: [lfs-dev] Final call for changes before LFS/BLFS 10.1 release
On 3/2/21 4:54 AM, Kevin Buckley wrote: On Sat, 27 Feb 2021 at 11:27, Bruce Dubbs via lfs-dev wrote: We are about ready to release LFS/BLFS 10.1. All tickets have been closed and all packages have been tested using the current instructions in the books. That said, there are probably issues that still need to be addressed. If LFS is printed out on paper, it is about 300 pages. If BLFS is printed out paper, it is over 2000 pages. This is the last call for change proposals before the books are released on Monday, March 1st. All proposals will be considered, but major changes probably will need to be delayed until the next cycle. However, minor changes can be done now. -- Bruce Only just came to download the sources I don'r already have, for 10.1 Checking that I had them all suggests that Readline was updated, from 8.0 to 8.1, but isn't listed in the "What's new" section. I note, in the SVN log, r12069 | bdubbs | 2020-12-15 05:45:13 +0800 (Tue, 15 Dec 2020) | 9 lines Update to libcap-2.46. Update to bc-3.2.4. Update to autoconf-2.70. Update to openssl-1.1.1i. Update to Python3-3.9.1. Update to linux-5.9.14. Update to bash-5.1 and readline-8.1. so and was wondering how it gets left out ? Because I forgot it. FWIW, I do something akin to links2 -width 132 -dump -html-numbered-links 0 LFS-BOOK-10.1-NOCHUNKS.html | \ grep Download: \ cut -d/ -f 3- > LFS-BOOK-10.1-SRC_PATHS.txt to get a list of "paths to" each Book's sources, so was wondering if something like that list being maintained, on the backend, might help in autogenerating the "What's new" list? I think that's a little more effort than it's worth. It's part of my routine to update the "What's new" list when I update the change log. Readline is a little different because it is pretty tightly coupled to bash. Thanks for pointing out the problem though. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS and BLFS Version 10.1 are released
The Linux From Scratch community is pleased to announce the release of LFS Version 10.1, LFS Version 10.1 (systemd), BLFS Version 10.1, and BLFS Version 10.1 (systemd). This release is a major update to both LFS and BLFS. The LFS release includes updates to glibc-2.33, and binutils-2.36.1. A total of 40 packages have been updated. Changes to text have been made throughout the book. The Linux kernel has also been updated to version 5.10.17. The BLFS version includes approximately 1000 packages beyond the base Linux From Scratch Version 10.0 book. This release has over 850 updates from the previous version in addition to numerous text and formatting changes. Thanks for this release goes to many contributors. Notably: Douglas Reno Pierre Labastie Ken Moffat Thomas Trepl Tim Tassonis Xi Ruoyao DJ Lucas You can read the books online[0]-[3], or download[4]-[7] to read locally. Please direct any comments about this release to the LFS development team at lfs-...@linuxfromscratch.org or blfs-...@linuxfromscratch.org. Registration for the mailing lists is required to avoid junk email. -- Bruce Dubbs LFS [0] http://www.linuxfromscratch.org/lfs/view/10.1/ [1] http://www.linuxfromscratch.org/blfs/view/10.1/ [2] http://www.linuxfromscratch.org/lfs/view/10.1-systemd/ [3] http://www.linuxfromscratch.org/blfs/view/10.1-systemd/ [4] http://www.linuxfromscratch.org/lfs/downloads/10.1/ [5] http://www.linuxfromscratch.org/blfs/downloads/10.1/ [6] http://www.linuxfromscratch.org/lfs/downloads/10.1-systemd/ [7] http://www.linuxfromscratch.org/blfs/downloads/10.1-systemd/ -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Final call for changes before LFS/BLFS 10.1 release
On 2/28/21 10:27 PM, Kevin Buckley wrote: On Sat, 27 Feb 2021 at 11:27, Bruce Dubbs via lfs-dev wrote: We are about ready to release LFS/BLFS 10.1. All tickets have been closed and all packages have been tested using the current instructions in the books. That said, there are probably issues that still need to be addressed. If LFS is printed out on paper, it is about 300 pages. If BLFS is printed out paper, it is over 2000 pages. This is the last call for change proposals before the books are released on Monday, March 1st. All proposals will be considered, but major changes probably will need to be delayed until the next cycle. However, minor changes can be done now. Very minor, and slightly pedantic, but as of 12146, this --- 1.2. What's new since the last release In this version of LFS, there has been a major reorganization of the book using techniques that avoid changing the host system and provides a more straight forward build process. Below is a list of package updates made since the previous release of the book. ... --- has missed the fact the major reorganization happened in 10.0, and that there hasn't been another major reorganization in "this version", ie 10.1, although I hear the distinction between "version" and "release". Perhaps then, given we are past the release in which the reorganization happened: As of LFS 10.0, there was a major reorganization of the book ... I also have a suggestion, and that would be to add the download URIs into the "What's new" section, so that someone with the downloads from the previous release could more easily generate a list of just the things they need to download for the latest release. You are right Kevin, we missed that needed text revision, but it is too late to change it now. We'll get it next time. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Final call for changes before LFS/BLFS 10.1 release
On 2/26/21 10:13 PM, Xi Ruoyao via lfs-dev wrote: On 2021-02-26 21:26 -0600, Bruce Dubbs via lfs-dev wrote: We are about ready to release LFS/BLFS 10.1. All tickets have been closed and all packages have been tested using the current instructions in the books. That said, there are probably issues that still need to be addressed. If LFS is printed out on paper, it is about 300 pages. If BLFS is printed out paper, it is over 2000 pages. This is the last call for change proposals before the books are released on Monday, March 1st. All proposals will be considered, but major changes probably will need to be delayed until the next cycle. However, minor changes can be done now. In section 11.3 (rebooting), it it better to replace those umount commands with a simple "umount -R $LFS"? That's a good idea. When I set up chroot, I do a little more than what in the book for work in chroot after LFS is completed: ├─/usr/src lfs91:/srv/src nfs ├─/mnt/lfs /dev/nvme0n1p8 ext4 │ ├─/mnt/lfs/dev devtmpfs devtmpfs │ │ └─/mnt/lfs/dev/pts devpts devpts │ ├─/mnt/lfs/proc proc proc │ ├─/mnt/lfs/sys sysfs sysfs │ ├─/mnt/lfs/run runtmpfs │ ├─/mnt/lfs/usr/src lfs91:/srv/src nfs │ ├─/mnt/lfs/boot /dev/nvme0n1p2 ext2 │ └─/mnt/lfs/home /dev/nvme0n1p5 ext4 When I do # umount -Rv $LFS, I get: umount: /mnt/lfs/dev/pts unmounted umount: /mnt/lfs/dev unmounted umount: /mnt/lfs/proc unmounted umount: /mnt/lfs/sys unmounted umount: /mnt/lfs/run unmounted Legacy NFS mount point detected lfs91:/srv/src umounted umount: /mnt/lfs/boot unmounted umount: /mnt/lfs/home unmounted umount: /mnt/lfs unmounted Which does seem to do the right thing. In spite of the message about NFS, it only umounts /mnt/lfs/usr/src and not /usr/src. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Final call for changes before LFS/BLFS 10.1 release
We are about ready to release LFS/BLFS 10.1. All tickets have been closed and all packages have been tested using the current instructions in the books. That said, there are probably issues that still need to be addressed. If LFS is printed out on paper, it is about 300 pages. If BLFS is printed out paper, it is over 2000 pages. This is the last call for change proposals before the books are released on Monday, March 1st. All proposals will be considered, but major changes probably will need to be delayed until the next cycle. However, minor changes can be done now. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Promote JS78.8.0 for 10.1 ?
On 2/24/21 12:13 PM, Ken Moffat via lfs-dev wrote: On Wed, Feb 24, 2021 at 03:48:05AM +, Ken Moffat via lfs-dev wrote: On Wed, Feb 24, 2021 at 04:31:12AM +0100, Pierre Labastie via lfs-dev wrote: On Wed, 2021-02-24 at 02:02 +, Ken Moffat via lfs-dev wrote: I see that people have been busy tagging things whilst I've been offline. One of those things is JS-78.8.0. Technically, the JS build does not appear to contain any security fixes, just one or two lines of python got changed. But firefox-78.8.0 does contain the usual crop of fixes rated as 'high'. Firefox has not yet been tagged, so no problem. I'd like to promote JS-78.8.0 for 10.1 so that we continue to use the same version of the tarball. Although I have not yet built this version of firefox on 10.1, I have built and measured on a system from 6th February with various later updates, and I've now got JS 78.8.0 running on two machines which have not yet got as far as firefox. FWIIW, js78 is a dependency of: - polkit: tagged - gjs: not tagged yet According to Xi Ruoyao, nothing dependent on polkit uses js. I'd say we need to test gjs (not tagged yet), and its dependencies (g-ir (optional), gnome-shell, libsecret (optional), gnome-maps, and gnome- weather) Pierre I've built polkit as part of my normal builds, as well as gobject-introspection. I normally build very little of gnome. Question: were those tested before JS78.7.1 was tagged ? In my case they were tested after JS78.7.1 was tagged -- Bruce I see that Doug has been given the ticket for JS, I'll temporarily separate the entities to keep JS at 78.7.1. ĸen -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Regression in top ?
On 2/22/21 8:43 PM, Ken Moffat via lfs-dev wrote: On Tue, Feb 23, 2021 at 02:30:38AM +, Ken Moffat wrote: Finally got a 10.1-rc1+ system booted. But lookign at 'top' on this 8-thread machine it only shows the even-numbered cores (Cpu0 .. 2 .. 4 .. 6). This is plain wierd, is it a regression in procps-ng-3.3.17 ? I so, I guess I'll have to revert to 3.3.16. ĸen Scratch that. I had not realised that the odd-numbered CPUs were shown on the right on the screen. Will be interesting to see how well that works on a narrow screen (at the moment I have 160 columns in a tty), but it saves rows so I guess all is good and that it will help if ever I get a decent number of cores. It's kinda needed on my 24 core system. At one per line, it would take up far too must screen real estate. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS-10.1-rc1 is released
The Linux From Scratch community announces the release of LFS Version 10.1-rc1. It is a preliminary release of LFS-10.1. The Linux From Scratch community announces the release of LFS Version 10.1-rc1. It is a preliminary release of LFS-10.1. Major changes include toolchain updates to binutils-2.36.1 and glibc-2.33. In total, 40 packages were updated since the last release. Changes to the text have also been made throughout the book. The Linux kernel has also been updated to version 5.10.17. We encourage all users to read through this release of the book and test the instructions so that we can make the final release as good as possible. You can read the book online [0], or download [1] to read locally. In coordination with this release, a new version of LFS using the systemd package is also being released. This package implements the newer systemd style of system initialization and control and is consistent with LFS in most packages. You can read the systemd version of the book online [2], or download [3] to read locally. -- Bruce [0] http://www.linuxfromscratch.org/lfs/view/10.1-rc1/ [1] http://www.linuxfromscratch.org/lfs/downloads/10.1-rc1/ [2] http://www.linuxfromscratch.org/lfs/view/10.1-systemd-rc1/ [3] http://www.linuxfromscratch.org/lfs/downloads/10.1-systemd-rc1/ -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] More glibc-2.33/binutils-2.36.1 fun
On 2/12/21 2:39 PM, Joe Locash via lfs-dev wrote: I haven't seen it mentioned and no reference to it in the dev book but I ran into this. A make check may fail for binutils-2.36.1 with glibc-2.33 with: FAIL: Run property 4 FAIL: Run property 4 (PIE) FAIL: Run property 5 FAIL: Run property 5 (PIE) All 4 related to CPU ISA level is lower than required. There is a patch available for binutils (or just ignore the failures - the patch just removes the checks). See https://sourceware.org/bugzilla/show_bug.cgi?id=27358 My build system is a core i5-540M. Yup. Everyone is getting these failures. We do need to tell users to ignore them. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] coreutils Ch.8 ("echo" command no longer needed)
On 2/11/21 12:29 PM, Ryan Marsaw via lfs-dev wrote: Hello. In chapter 8's Coreutils there's this line: echo '# deleted' > m4/std-gnu11.m4 The original "std-gnu11.m4" is now usable ever since the autoconf upgrade to 2.71. The echo line can be removed. Thanks. I'll test and make that change. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Possible binutils-2.36 problems
On 2/5/21 6:48 AM, Ken Moffat via lfs-dev wrote: While replying to Frans on -support re his inability to build glibc-2.33, I glanced at the binutils bugs https://www.mail-archive.com/bug-binutils@gnu.org/ and said that 2.36 might be buggy. At that time I hadn't read all the links gurgle found for me. One of them is https://www.linuxquestions.org/questions/linux-from-scratch-13/binutils-2-36-strip-4175689760/ which looks *really* annoying. I took a look at the above link, but I cannot reproduce the problem with LFS instructions. In my test build in /mnt/lfs/lib I have: [ /mnt/lfs/lib ]$ ll libc* lrwxrwxrwx 1 root root 14 Feb 2 16:20 libcap.so.2 -> libcap.so.2.47 -rwxr-xr-x 1 root root39440 Feb 2 17:44 libcap.so.2.47 lrwxrwxrwx 1 root root 17 Feb 2 17:44 libcom_err.so.2 -> libcom_err.so.2.1 -rwxr-xr-x 1 root root18776 Feb 2 17:44 libcom_err.so.2.1 -rwxr-xr-x 1 root root43288 Feb 2 17:44 libcrypt-2.33.so lrwxrwxrwx 1 root root 16 Feb 2 16:10 libcrypt.so.1 -> libcrypt-2.33.so -rwxr-xr-x 1 root root 1835448 Feb 2 17:44 libc-2.33.so -rwxrwxr-x 1 root root 11946280 Feb 2 17:44 libc-2.33.so.dbg lrwxrwxrwx 1 root root 12 Feb 2 16:10 libc.so.6 -> libc-2.33.so [ /mnt/lfs/lib ]$ file libc-2.33.so libc-2.33.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped [ /mnt/lfs/lib ]$ file libcap.so.2.47 libcap.so.2.47: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped So the book does what we want. On the other hand, we do not do an unconditional strip on anything. We start with find /lib /usr/lib -type f -name \*.so* ... so that would skip symlinks. We use the same structure in BLFS Section "Notes on Building Software". On the other hand, doing an explicit strip on a symlink does replace the symlink with the stripped version of the link's resolved file. I can confirm that running strip against a symlink on a system with binutils-2,25 does not affect the symlink. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Util-linux uuidd.service file specifies a user and group
On 1/28/21 2:18 PM, Brendan L via lfs-dev wrote:
On Thu, Jan 28, 2021 at 11:22 AM Bruce Dubbs via lfs-dev
wrote:
On 1/28/21 10:04 AM, Brendan L via lfs-dev wrote:
I thought I'd also mention that for the instructions, it currently
explicitly sets runstatedir=/run. You can have the same effect of
runstatedir=/run by just setting --localstatedir=/var. I found arch
does this in their builds.
That puts files in /var/run which is a symlink to /run. Better to just
go direct.
I think that's the normal outcome, but when I run configure on
util-linux with --localstatedir=/var, runstatedir is set the /run and
not /var/run when checking the config.log. It also show /run in the
configure summary.
Interesting. I checked configure.ac and see (with minor formatting):
# default for old versions without $runstatedir
AS_IF([test x"$runstatedir" = x], [runstatedir='${localstatedir}/run'])
# our default if $localstatedir unchanged
AS_CASE([$localstatedir:$runstatedir],
[NONE:'${localstatedir}/run' |
/var:'${localstatedir}/run' |
NONE:'/run' ],
[runstatedir=/run; AC_MSG_NOTICE([ --runstatedir defaults to /run])]
)
So it looks like a couple of ways to do what we want. The default for
$localstatedir if nothing is specified is /usr/var. As far as I can
tell though, nothing uses /usr/var although it does seem to be created.
The FHS does not mention /usr/var, so it looks like your suggestion
would eliminate that as well as fixing the run problem.
What to others think?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Util-linux uuidd.service file specifies a user and group
On 1/28/21 10:04 AM, Brendan L via lfs-dev wrote: I thought I'd also mention that for the instructions, it currently explicitly sets runstatedir=/run. You can have the same effect of runstatedir=/run by just setting --localstatedir=/var. I found arch does this in their builds. That puts files in /var/run which is a symlink to /run. Better to just go direct. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS 10.0 read-only file system failure
On 1/16/21 9:43 AM, Jamenson Espindula via lfs-dev wrote: To re-emphasize: I _solved_ the problem. How: creating a configuration file from scratch (make config); answering all the questions accepting the suggested default answers. After that, I have invoked (make menuconfig) and adjusted some hardware configurations. Compiling and installing the kernel just builded. Unfortunately, I accidentally erased the old configuration file. So, I can not tell exactly where the misconfiguration was. But, I have no doubt: the problem was raised by a kernel misconfiguration. I made a mistake. We all make mistakes. Glad you got it fixed. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS 10.0 read-only file system failure
On 1/13/21 11:45 PM, Jamenson Espindula via lfs-dev wrote: Em qua., 13 de jan. de 2021 às 12:47, Pierre Labastie via lfs-dev escreveu: On Wed, 2021-01-13 at 10:05 -0300, Jamenson Espindula via lfs-dev wrote: Looks like you haven't send the whole story. You should have seen something like: Mounting virtual file systems: /run /proc /sys /dev + maybe an error message before "FAILURE ..." The mail subject tells "read-only file system failure", but there is no evidence in the error message you sent us... Thank you for your response. In fact, there are other error messages. I am sorry. = = = = = Begin of transcription = = = = = chmod: cannot access '/run/lock': No such file or directory Lets start here. That is the very 1st boot script. It is doing: mount /run mkdir -p /run/lock /run/shm chmod 1777 /run/shm /run/lock And failing. - What we need is to see your file system. What is the output of 'ls /' (or 'ls /mnt/lfs' from the host). It should be. bin dev homeliblost+found mnt proc run sources sys usr boot etc lib64 media opt root sbin srv tmp var Second don't just say the /etc/fstab is right. Paste it in. It should be close to: /dev/ / ext4 defaults 1 1 /dev/ swap swap pri=1 0 0 proc /procproc nosuid,noexec,nodev 0 0 sysfs/sys sysfsnosuid,noexec,nodev 0 0 devpts /dev/pts devpts gid=5,mode=6200 0 tmpfs/run tmpfsdefaults 0 0 devtmpfs /dev devtmpfs mode=0755,nosuid 0 0 The last five lines should be identical to what you have. If /run is correctly mounted as a tmpfs, then the next two lines should not fail. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] cbindgen-0.16.0 and mozilla
On 12/27/20 3:14 PM, Ken Moffat via lfs-dev wrote:
On Sun, Dec 27, 2020 at 07:18:33PM +, Ken Moffat via lfs-dev wrote:
On Sun, Dec 27, 2020 at 07:28:33PM +0100, gabriele balducci via lfs-dev wrote:
hi
I'm running into a problem with cbindgen-0.16.0 first identified by
renodr. Both Thunderbird and Firefox fail in the same way.
if this can be of interest to you: at least for FF, the working version
of cbindgen can be found in one or the other of these two files:
taskcluster/scripts/misc/build-cbindgen.sh
build/moz.configure/bindgen.configure
cheers
-g
From memory, the bindgen.configure specified the *minimum* version
required (it's one of the places I look to see changed deps for new
non-esr versions). My impression of taskcluster is that it's part
of mozilla's infrastructure for its build machines.
In any case, all configure-style tests for versions can only know
about what was available at the time. This sounds like a new
cbindgen issue and I'll guess it should be reported to cbindgen's
upstream.
Glad someone tested it ;-)
So far, only Arch are using cbindgen-0.16.0. They use it for
thunderbird 78.6.0 with rust-1.48.0 (and a patch to allwo that).
Fedora are also using rust-1.48.0, but in thunderbird-78.6.0 they
put cbindgen-vendor-0.14.3.tar.xz into the source and then build
with the bundled cbindgen, see
https://src.fedoraproject.org/rpms/thunderbird/blob/master/f/thunderbird.spec
Specifically, at line 377 (blank lines removed)
%if 0%{?use_bundled_cbindgen}
mkdir -p my_rust_vendor
cd my_rust_vendor
%{__tar} xf %{SOURCE4}
cd -
mkdir -p .cargo
cat > .cargo/config <
Sorry. I started this thread on the wrong list (lfs-dev not blfs-dev),
but let's keep it here to maintain the conversation.
The only packages in BLFS that use cbindgen are TB and FF. If Fedora is
still using cbindgen-0.14.3, then if we stay at our current working
version (0.15.0), that should be good enough until mozilla straightens
things out.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] cbindgen-0.16.0 and mozilla
I'm running into a problem with cbindgen-0.16.0 first identified by renodr. Both Thunderbird and Firefox fail in the same way. In file included from Unified_cpp_dom_webgpu1.cpp:110: /build/firefox/firefox-78.6.0/dom/webgpu/ipc/WebGPUParent.cpp: In member function ‘mozilla::ipc::IPCResult mozilla::webgpu::WebGPUParent::RecvDeviceCreateBindGroup(mozilla::webgpu::RawId, const mozilla::webgpu::SerialBindGroupDescriptor&, mozilla::webgpu::RawId)’: /build/firefox/firefox-78.6.0/dom/webgpu/ipc/WebGPUParent.cpp:426:29: error: ‘struct mozilla::webgpu::ffi::WGPUBufferBinding’ has no member named ‘_0’ And several more places of "no member named ‘_0’". make[4]: *** [/build/firefox/firefox-78.6.0/config/rules.mk:748: Unified_cpp_dom_webgpu1.o] Error 1 make[3]: *** [/build/firefox/firefox-78.6.0/config/recurse.mk:74: dom/webgpu/target-objects] Error 2 ... make[2]: *** [/build/firefox/firefox-78.6.0/config/recurse.mk:34: compile] Error 2 make[1]: *** [/build/firefox/firefox-78.6.0/config/rules.mk:390: default] Error 2 Reverting to cbindgen-0.15.0 allows both packages to build and run fine. I did find https://forums.freebsd.org/threads/building-mail-thunderbird-78-6-0_1-always-fails.78182/ and as best I can tell their solution was to revert to cbindgen-0.15.0. It also seems like a similar problem with icecat on Arch: https://aur.archlinux.org/packages/icecat/ Also found https://phabricator.services.mozilla.com/D91572?id=357321 I suppose we ought to leave cbindgen alone until FF and TB get updated, but I would like other opinions. I did find this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1667736 - upstream again due to rust (seems to be a continuous issue with these f***ing devs, just look over the years here in this AUR package comments...always something with rust..) -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] systemd-247
On 12/25/20 12:14 PM, Roger Koehler wrote: On Fri, Dec 25, 2020 at 11:00 AM Bruce Dubbs wrote: On 12/25/20 10:36 AM, Roger Koehler wrote: Bruce, I moved my /usr/lib to its own partition and got a kernel panic because the following shared libraries were not in /lib: libcrypto.so.1.1 libp11-kit.so.0 libffi.so.7 I don't know what the implications of this are, but I would guess that you would want to add instructions to the book to either install them in /lib or move them after install. I just signed up for the lfs-dev list, but I thought maybe a personal email for this issue would suffice. A kernel panic for missing these libraries seems odd. From the subject line it looks like you are running systemd? What were you doing when the problem came up? When you moved the files, did it work OK? Yes. I am using it to write this email. I just did a "sudo cp -r" of the links and files to /lib. OK. Note that libcrypto.so, libp11-kit.so, and libffi.so need to still be on /usr/lib because they are used for building/linking software that needs them. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] blfs-book-10.0-html.tar.xz and lxqt
On 12/11/20 10:55 PM, scsijon via lfs-dev wrote: Sorry folks, but downloading this file from your site gives me a corrupted file with a not-supported attributes. I've tried it a number of times with the same result. The NOCHUNKS version however seems to be ok. There was a typo in the script that generated that file. I've fixed the script and the tarball so you should download it again. My intent is to use this as the basis of a LXQT build using the LXQT section from 8.2 as a base and then use that as a stepping stone to musl/clang/llvm. You know, I think, that we removed lxqt a few versions ago. Thanks for the report. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Texinfo no longer recognizes "--disable-static"
On 12/4/20 10:35 AM, Ryan Marsaw via lfs-dev wrote: Hello all. Since Texinfo 6.6, the configure switch "--disable-static" is no longer recognized. It's safe to remove it from the instructions. No static libs are installed now, and the ChangeLog mentions this as well. Thanks. I'll do that in my next commit, but it may be a few days. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Issue with GCC after leaving Chroot at end of Chap7 and re-entering it for Chap8
On 11/18/20 11:05 PM, Kevin Buckley via lfs-dev wrote: On Wed, 18 Nov 2020 at 00:18, Bruce Dubbs via lfs-dev wrote: I am in favor of just removing the strip section in Chapter 7. Saving 90 MB is not really significant for today's HW. We say that the user should have at least 5 GB free, so 90 MB is less than 2% of that. Despite having tripped over this, I feel that having the section in there, and the Book does say that it is optional, does give the user some introductory info, about stripping in general, that they probably won't get elsewhere unless it is presented there? It is presented in section 8.77. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Issue with GCC after leaving Chroot at end of Chap7 and re-entering it for Chap8
On 11/17/20 3:41 AM, Pierre Labastie via lfs-dev wrote: On Tue, 2020-11-17 at 15:45 +0800, Kevin Buckley via lfs-dev wrote: On Mon, 16 Nov 2020 at 14:49, Kevin Buckley < kevin.m.buck...@gmail.com> wrote: Pretty sure this will be an "end-user" issue but, just in case anyone has seen something similar and can thus point me in the right direction, I have seen this twice now, and i was more careful the second time. (Note: following the Multilib Book, plus some PkgUser additons) Get to the end of Chapter 7 Run test compile and readelf interrogations for all three "arch-s" so gcc dummy.c gcc -m32 dummy.c gcc -mx32 dummy.c Deep joy. Exit chroot and umount bind mouted FSes Backup temporary system Remount bind mouted FSes Re-enter chroot Try to perform a simple gcc dummy.c Deep sorrow! Output from the failed compilation suggest that there's a crtN.o file, with a GlibC version that has come from the host, being pulled in. Thought I'd chuck in the actual error message in case it rings any bells for anyone. GNU C17 (GCC) version 10.2.0 (x86_64-lfs-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.2.0, isl version isl-0.22.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 Compiler executable checksum: d384610cfa11eec261f14798a7f678e4 COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/bin/a s -v --64 -o /tmp/cc6W4Vah.o /tmp/ccvqsYQf.s GNU assembler version 2.35 (x86_64-lfs-linux-gnu) using BFD version (GNU Binutil s) 2.35 COMPILER_PATH=/usr/libexec/gcc/x86_64-lfs-linux- gnu/10.2.0/:/usr/libexec/gcc/x86 _64-lfs-linux-gnu/10.2.0/: /usr/libexec/gcc/x86_64-lfs-linux-gnu/: /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/: /usr/lib/gcc/x86_64-lfs-linux-gnu/: /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/: /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/lib/../lib/: /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/: /lib/../lib/: /usr/lib/../lib/: /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/lib/: /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../:/lib/: /usr/lib/ COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/collect2 -plugin /usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cctzwl1f.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crt1.o /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtbegin.o -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0 -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/lib/../lib -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib - L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/lib -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../.. /tmp/cc6W4Vah.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtend.o /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crtn.o /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs- linux-gnu/bin/ld: /usr/lib/gcc/x86_64-lfs-linux- gnu/10.2.0/../../../../lib/crt1.o(.text+0x26): unresolvable R_X86_64_NONE relocation against symbol `__libc_start_main@@GLIBC_2.2.5' collect2: error: ld returned 1 exit status Yes, I've seen this. It had something to do with stripping (so 1st question is: did you strip binaries? Old versions (don't ask the version, something around 2.28 IIRC) of strip do not recognize some R_X86_64_xxx relocation items and replace them with R_X86_64_NONE, which makes the symbol undefined... The cure is to use $LFS/usr/bin/strip for stripping. I'd say we should put that in the instructions, actually, or change binutils requirement to the first version which works. I am in favor of just removing the strip section in Chapter 7. Saving 90 MB is not really significant for today's HW. We say that the user should have at least 5 GB free, so 90 MB is less than 2% of that. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] eudev pkgconfig file
On 11/16/20 10:43 AM, Roger via lfs-dev wrote: eudev puts udev.pc in /usr/share/pkgconfig; all other packages use /usr/lib/pkgconfig. To put udev.pc in /usr/lib/pkgconfig change eudev's "make install" command to make sharepkgconfigdir=/usr/lib/pkgconfig install You can do that, but see https://people.freedesktop.org/~dbn/pkg-config-guide.html "... references the PKG_CONFIG_PATH environment variable. This variable is used to augment pkg-config's search path. On a typical Unix system, it will search in the directories /usr/lib/pkgconfig and /usr/share/pkgconfig. This will usually cover system installed modules. However, some local modules may be installed in a different prefix such as /usr/local. In that case, it's necessary to prepend the search path so that pkg-config can locate the .pc files." -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] A small patch to make sysklogd work on startup
On 11/16/20 8:42 AM, Joel Bion via lfs-dev wrote:
It's always bothered me that for some time (perhaps as long as I have
been using LFS?) that I could not get the kernel symbols properly loaded
by sysklogd, producing a message sequence like this:
Nov 15 15:45:38 www kernel: klogd 1.5.1, log source = /proc/kmsg started.
Nov 15 15:45:38 www kernel: Inspecting /boot/System.map-5.9.8
Nov 15 15:45:38 www kernel: Cannot find map file.
It's a very minor nuisance, but I didn't like it.
It turns out that sysklogd inspects the System.map file but cannot find
a particular symbol, one named Version_XX, where XX is the
encoded Linux version number that corresponds to this map file.
It further turns out that init/version.c is not producing this symbol if
CONFIG_KALLSYMS is define. Since it usually IS defined (and kind of
should be, at this point), then this doesn't work.
I am certainly not a kernel expert, but as far as I can see, there's no
downside to producing this symbol anyway - even if CONFIG_KALLSYMS is
defined.
So I removed the check for CONFIG_KALLSYMS not being defined, with this
patch included at the end of this email.
When I boot this kernel, I get the following result:
Nov 16 06:28:51 www kernel: Inspecting /boot/System.map-5.9.8
Nov 16 06:28:51 www kernel: Loaded 116685 symbols from
/boot/System.map-5.9.8.
Nov 16 06:28:51 www kernel: Symbols match kernel version 5.9.8.
Again, I don't know if I am creating unintended side-effects by allowing
this symbol to be defined. I mean, there must have been SOME reason to
remove the generation of the "Version_" symbol if KALLSYMS is defined -
but I couldn't find it.
Thoughts?
-Joel
diff -Naur linux-5.9.8.orig/init/version.c linux-5.9.8/init/version.c
--- linux-5.9.8.orig/init/version.c 2020-11-10 12:16:17.0 -0800
+++ linux-5.9.8/init/version.c 2020-11-16 06:15:48.559481272 -0800
@@ -16,13 +16,11 @@
#include
#include
-#ifndef CONFIG_KALLSYMS
#define version(a) Version_ ## a
#define version_string(a) version(a)
extern int version_string(LINUX_VERSION_CODE);
int version_string(LINUX_VERSION_CODE);
-#endif
struct uts_namespace init_uts_ns = {
.kref = KREF_INIT(2),
Interesting. I took a look at sysklogd-1.5.1/ksym.c and it may be
easier to just comment out line 226. A comment in the CHANGES file says:
- Rewrote the module symbol parser to read from /proc/kallsyms
...
- Only read kernel symbols from /proc/kallsyms if no System.map has been
So if /proc/kallsyms exists (I suspect from the definition of KALLSYMS
in the kernel configuration), then symbols are taken from there. I
suspect that is preferable as it is more dynamic and would include
symbols from loaded modules.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Formatting of Package download URIs
On 11/12/20 12:37 AM, Kevin Buckley via lfs-dev wrote: On Wed, 11 Nov 2020 at 23:57, Xi Ruoyao via lfs-dev wrote: Adding a link in package page will make it easier when some LFS package need to be upgraded in a completed system. -- Not sure that that's enough of a justification for having a BLFS style meta-info block, simply because the link is going to be version specific, and so the reader would still have to traverse the original path to find the newest version. When LFS was originally developed, a single URL was deemed sufficient. When BLFS was started we wanted an ftp URL because LFS had an ftp client, but we also wanted to offer http access. Over the years, upstream has changed and sometimes the ftp servers were dropped or http access added. In addition, we have also created tools for things like currency checks and automated building that depend on the current formats. Changing these tools would be a lot more work than just the appearance of the pages. What we have now works and honestly benefit of the suggested changes does not justify the effort required. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Formatting of Package download URIs
On 11/11/20 3:21 AM, Kevin Buckley via lfs-dev wrote: I was recently trying to generate a downlaod listing of the packages I had used when building my Pkguser based 9.1 system, inclduing the BLFS components that I'd merged into a single book. FWIW, so as to see what I needed to download from BLFS 10.0 I noticed that in BLFS, where the package download URIs are presented within the packages section, one ends up with entries akin to (links/lynx dump output) * Download (HTTP): https://www.domain.tld/path/to/taball.tar.xz * Download (FTP): ftp://ftp.domain.tld/path/to/taball.tar.xz however, in the LFS Book, where all of the package tarball URIs are listed in the one section, it's just * Download: https://www.domain.tld/path/to/taball.tar.xz or, for the odd package, * Download: ftp://ftp.domain.tld/path/to/taball.tar.xz I'm aware that there is no reason the LFS and BLS books should exhibit any consistency, but was wondering if having the LFS Book "adopt" the BLFS markup might be doable, or rather, if there was anything in way that the package download listing is generated that might prevent it being done? The design of LFS is that all the packages are expected to be built. In BLFS, the user chooses what packages to build. Another issue with LFS is that there are packages only built in the chroot environment. Downloading a package in chroot is not really practical. Also I'll note that users of the stable book can download everything with a single wget command in Chapter 3.1 or one tarball from ftp://ftp.osuosl.org/pub/lfs/lfs-packages/ or its mirrors. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] sysklogd replacement
On 10/30/20 11:00 AM, Tim Tassonis via lfs-dev wrote: On 10/29/20 1:31 PM, Bruce Dubbs via lfs-dev wrote: On 10/29/20 12:49 AM, Geoff Swan via lfs-dev wrote: Hi, I've build many LFS systems using sysklogd as per the book. However new remote logging systems are asking for logging features that sysklogd does not possess. These include port changes (other than what is in /etc/services, which is where syklogd picks up its port) and logs being sent over TCP with TLS on a configurable port (RFC5424/25). I examined a couple of replacements and see that rsyslog appears to include these features . Before starting on replacing the logger in my system build I thought I'd ask the question as to whether any thoughts had been given to upgrading LFS from sysklogd to a more modern package for remote logging? It's something to consider. I don't think many users actually use remote logging over TLS, but it would be nice to have that available. If you do add rsyslog, would you please get back to us to let us know anything you find out including build and configuration instructions. We probably would not add instructions for remote logging to the book, but a hint for that would be appropriate. I do that for myself for years, as I need the additional features rsyslog brings, so I can contribute some build scripts, if needed. Be aware thought that rsyslog is a bit of a maintenance nightmare, as it requires at least three separate libraries by the same author, which are not used by anyone/anything else in the whole wide world, and are not included in the source distribution of rsyslog. I have created a scripts that pre-builds them statically inside the rsyslog source tree, in order not to bloat my system with the unnecessary overhead of three libraries only needed by it: LIBE=`pwd`/libe export LIBE tar xf /lfs-src/libestr-0.1.10.tar.gz cd libestr-0.1.10 ./configure --prefix=$LIBE --enable-static --disable-shared --with-pic make || ext make install cd .. tar xf /lfs-src/libee-0.4.1.tar.gz cd libee-0.4.1 PKG_CONFIG_PATH=$LIBE/lib/pkgconfig ./configure --prefix=$LIBE --enable-static --disable-shared --with-pic make || exit make install cd .. tar xf /lfs-src/libfastjson-0.99.8.tar.gz cd libfastjson-0.99.8 PKG_CONFIG_PATH=$LIBE/lib/pkgconfig ./configure --prefix=$LIBE --enable-static --disable-shared --with-pic make || exit make install cd .. # and finally rsyslog PKG_CONFIG_PATH=$LIBE/lib/pkgconfig ./configure --prefix=/usr --disable-libgcrypt --disable-liblogging-stdlog Thanks Tim. I don't think we want to add that much overhead to LFS, but I'll listen to other opinions. A hint or possibly a BLFS page seems more appropriate. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] sysklogd replacement
On 10/29/20 12:49 AM, Geoff Swan via lfs-dev wrote: Hi, I've build many LFS systems using sysklogd as per the book. However new remote logging systems are asking for logging features that sysklogd does not possess. These include port changes (other than what is in /etc/services, which is where syklogd picks up its port) and logs being sent over TCP with TLS on a configurable port (RFC5424/25). I examined a couple of replacements and see that rsyslog appears to include these features . Before starting on replacing the logger in my system build I thought I'd ask the question as to whether any thoughts had been given to upgrading LFS from sysklogd to a more modern package for remote logging? It's something to consider. I don't think many users actually use remote logging over TLS, but it would be nice to have that available. If you do add rsyslog, would you please get back to us to let us know anything you find out including build and configuration instructions. We probably would not add instructions for remote logging to the book, but a hint for that would be appropriate. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding attributes in the source XML
On 10/6/20 7:59 PM, Kevin Buckley via lfs-dev wrote:
On Tue, 6 Oct 2020 at 20:03, Pierre Labastie via lfs-dev
wrote:
Where should such a declaration go?
The attribute has to be declared in the dtd (document type definition),
where anything pertaining to the xml document is declared (not only
attributes, but also tags and their content). For our docbook xml
sources, the dtd is pretty big, and comes from docbook. So you should
look at https://tdg.docbook.org/tdg/4.5/docbook.html, which gives the
details and the use of all tags and attributes. "revision" and "arch"
are attributes defined in the dtd. "pkguser" is not. But maybe,
condition="pkguser" could be used, since condition is a declared
attribute (
https://tdg.docbook.org/tdg/4.5/ref-elements.html#common.attributes),
and the stringparam profile.condition="pkguser" for profiling. Another
attribute name could be "userlevel"... Note that any attribute name
declared in the dtd could be used provided _you_ know what you use it
for, if you do not want to share your work.
Pierre
and Thomas echoed pointed out
Those attributes like 'arch', 'revision' etc. are defined somewhere in
the deepness of docbook. You cannot simply introduce new ones by
adding them to the string parameter list for the renderer. All the
attributes used in the {B,}LFS-book are predefined ones.
You may have allready seen the pages at
http://www.sagehill.net/docbookxsl/AddProfileAtt.html - the talk about
"how easy it is to add". Well, i didn't find it that easy, maybe you
have more luck.
--
Thomas
which suggests I missed picking up the knowledge as regards 'arch' and
'revision' NOT being something that LFS had added.
Wow!
All this time, and I had assumed that LFS had extended the Schema/DTD
so as to use certain attributes that appeared specific to LFS.
Cheers for pointing that out: I'll "make other plans" !
See https://tdg.docbook.org/tdg/4.5/ref-elements.html#common.attributes
for the defined attributes. To translate those attributes to html you
still need a custom xsl like stylesheets/lfs-chunked.xsl and the files
in stylesheets/lfs-xsl/. Learning xsl is definitely a non-trivial task.
It is not a procedural language. Generally we try to avoid changing
the xsl due to its complexity.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] connecting to the web in Ch 7 and 8
On 10/2/20 8:46 AM, John Burrell via lfs-dev wrote: If you use a script(s) to install LFS (majority here?) you might consider it best to download the sources through the scripts rather than storing them all up front before running the scripts. I've been playing with this and found that it is straightforward to do. What I did: You need to install wget at the end of Ch 6. This requires openssl to be installed first. The commands for openssl are: ./config --prefix=/usr \ --openssldir=/etc/ssl \ --libdir=lib \ shared make sed -i '/INSTALL_LIBS/s/libcrypto.a libssl.a//' Makefile make DESTDIR=$LFS MANSUFFIX=ssl install I don't know if all these are strictly necessary, but these are what I used, based on what is in Ch 8. I added these as 058-openssl at the end of lfs-commands/chapter06, after gcc-pass2. The commands for wget are: PKG_CONFIG_PATH=$LFS/usr/lib/pkgconfig \ ./configure --prefix=/usr \ --with-ssl=openssl \ --host=$LFS_TGT \ --build=$(build-aux/config.guess) make make DESTDIR=$LFS install These were added as 059-wget in chapter06. I needed PKG_CONFIG_PATH in order for wget to find openssl. Notice that openssl doesn't have a config.guess script but this didn't stop it compiling. Once wget is installed all you need is /etc/resolv.conf, specifying the nameserver, to connect to the web in Ch 7 and 8. Easy? There are no certificates installed but sites like Perl need --no-check-certificate to download. So it's a fairly painless solution to get your scripts to download the sources at install time when you're in chroot. Of course, where a source file is needed more than once, gcc, binutils and some in Ch 8, you don't need to download them again. Downsides? Seems pretty complicated for a first time user. An experienced user knows that many of the packages do not change often and they would already have those unchanged packages. Also it is easier to just use the wget-list at http://www.linuxfromscratch.org/lfs/downloads/development/ (or the stable version) and get everything right up front in chapter 3. For stable versions of LFS the user can download all packages in one tarball at ftp://ftp.osuosl.org/pub/lfs/lfs-packages/ Another alternative is to use jhalfs which has the option of downloading sources for you. That said, if you want to roll your own methods, that's fine. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS source md5sums
On 9/28/20 11:46 AM, John Burrell via lfs-dev wrote:
On Mon, 28 Sep 2020 at 16:42, Bruce Dubbs via lfs-dev
wrote:
On 9/28/20 10:13 AM, John Burrell via lfs-dev wrote:
I downloaded the SYSTEMD book and got the wget-list and md5sums files with:
make -j1 -f ${REPODIR}/Makefile -C $REPODIR BASEDIR=$SourceDir
${SourceDir}/wget-list ${SourceDir}/md5sums
which produces the correct wget-list file but the md5sums file is for
the 'sysv" version of the book. e.g. no dbus and systemd files, viz:
fcafcecde5a380415b12e9c574e0b2 check-0.15.2.tar.gz
022042695b7d5bcf1a93559a9735e668 coreutils-8.32.tar.xz
e1b07516533f351b3aba3423fafeffd6 dejagnu-1.6.2.tar.gz
4824adc0e95dbbf11dfbdfaad6a1e461 diffutils-3.7.tar.xz
6d906edfdb3202304059233f51f9a71d sed-4.8.tar.xz
4b05eff8a427cf50e615bda324b5bc45 shadow-4.8.1.tar.xz
c70599ab0d037fde724f7210c2c8d7f8 sysklogd-1.5.1.tar.gz
e11bc4b3eac6e6ddee7f8306230749a9 sysvinit-2.97.tar.xz
So is there a problem with my make command or a problem with the Makefile?
What does your package,ent file show. It should be:
https://libcheck.github.io/check;>
Somehow you are missing the leading 50 for check.
To make the systemd book, use 'make REV=systemd'
-- Bruce
--
yep, that's what I've got:
https://libcheck.github.io/check;>
so the 50 is there, but not in the md5sums file.
It's definitely the systemd book. Here is the start of general.ent:
The source xml is the same for both books. Chapter 3 does differentiate
the packages when generated. The wget-list file is generic and includes
all files for both books. The md5sum file is specific to systemd or
system V.
The default book is System V.
The packages that are specific to systemd are dbus and systemd/systemd
man pages. The packages that are specific to System V are eudev,
lfs-bootscripts, sysklogd, sysvinit, and udev-lfs.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] LFS source md5sums
On 9/28/20 10:13 AM, John Burrell via lfs-dev wrote:
I downloaded the SYSTEMD book and got the wget-list and md5sums files with:
make -j1 -f ${REPODIR}/Makefile -C $REPODIR BASEDIR=$SourceDir
${SourceDir}/wget-list ${SourceDir}/md5sums
which produces the correct wget-list file but the md5sums file is for
the 'sysv" version of the book. e.g. no dbus and systemd files, viz:
fcafcecde5a380415b12e9c574e0b2 check-0.15.2.tar.gz
022042695b7d5bcf1a93559a9735e668 coreutils-8.32.tar.xz
e1b07516533f351b3aba3423fafeffd6 dejagnu-1.6.2.tar.gz
4824adc0e95dbbf11dfbdfaad6a1e461 diffutils-3.7.tar.xz
6d906edfdb3202304059233f51f9a71d sed-4.8.tar.xz
4b05eff8a427cf50e615bda324b5bc45 shadow-4.8.1.tar.xz
c70599ab0d037fde724f7210c2c8d7f8 sysklogd-1.5.1.tar.gz
e11bc4b3eac6e6ddee7f8306230749a9 sysvinit-2.97.tar.xz
So is there a problem with my make command or a problem with the Makefile?
What does your package,ent file show. It should be:
"/libcheck/check/releases/download//check-.tar.gz">
https://libcheck.github.io/check;>
Somehow you are missing the leading 50 for check.
To make the systemd book, use 'make REV=systemd'
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Minor suggestion for 7.14. Cleaning up and Saving the Temporary System
On 9/25/20 10:39 AM, Tim Tassonis via lfs-dev wrote:
Hi all
In 7.14, the book recommends to remove the temporary domumentation, by
rm -rf /usr/share/{info,man,doc}/*
I think the same could be done with the locale files, by
find /usr/share/locale -name "*.mo" -delete
This would save another 70 MB of disk space. I highly doubt anyone would
want to perform chapter 8 in a different language, and after that, they
all got re-installed.
But what would that really save if the files are going to be immediately
replaced in Chapter 8? I suppose that it might save a little space in
the backup tarball if the user is going to create that, but is it a
significant amount of space if it is compressed?
If I were going remove the locale files, I would change:
rm -rf /usr/share/{info,man,doc}/*
to
rm -rf /usr/share/{info,man,doc,locale}/*
I don't have a partial LFS build at the present, but on a more complete
LFS/BLFS system my /usr/share/locale directory tree is 341M, but a
compressed tarball is only 57M for about a 6:1 compression ratio.
I would like to hear the opinion of others.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] TCL and Perl manpage clash
On 9/22/20 2:25 AM, Kevin Buckley via lfs-dev wrote: On Sun, 13 Sep 2020 at 14:59, Bruce Dubbs via lfs-dev wrote: On 9/12/20 9:35 PM, Kevin Buckley via lfs-dev wrote: One of those things you probably only notice if you are doing a PkgUser type build, as a root build will simply see the file overwritten without any warning, but wanted to point out that Chapter 8's TCL installs this manpage /usr/share/man/man3/Thread.3 and then Perl will also want to install its own version of that file. The content is different. I renamed the TCL one, on the assumption that I am more likely to want to read the Perl one! Indeed. I'll add a command to rename that page to Tcl_Thread.3 -- Bruce Just came across a "do you want a Tcl manpage or a system one" at work and, in recalling this thread, noticed that the Tcl manpage was the one in "n", whilst the system one, in this case, was in 8. I thought to check what that system made of a "man Thread" and was offered * Thread (3pm) thread (n) Man: What manual page do you want? Might there be a case for installing all Tcl manpages into the mann directory? I think we should keep things as close as possible to what upstream has. Users can always find a particular man page with the apropos command. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] TCL and Perl manpage clash
On 9/12/20 9:35 PM, Kevin Buckley via lfs-dev wrote: One of those things you probably only notice if you are doing a PkgUser type build, as a root build will simply see the file overwritten without any warning, but wanted to point out that Chapter 8's TCL installs this manpage /usr/share/man/man3/Thread.3 and then Perl will also want to install its own version of that file. The content is different. I renamed the TCL one, on the assumption that I am more likely to want to read the Perl one! Indeed. I'll add a command to rename that page to Tcl_Thread.3 -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] host /usr/share/config.site may break build
On 9/4/20 2:30 AM, Pierre Labastie via lfs-dev wrote:
On Fri, 2020-09-04 at 00:47 -0500, Bruce Dubbs via lfs-dev wrote:
On 9/3/20 10:53 PM, Xi Ruoyao via lfs-dev wrote:
Now we are using --prefix=/usr in "Ch. 6 Cross Compiling Temporary
Tools". The
problem is that configure scripts (generated by autoconf) will try
to load
${prefix}/share/config.site and ${prefix}/etc/config.site. These
things are
really "powerful" - they can even override some command line
options.
"/usr/etc" should not exist on any FHS-compilant distro, but
"/usr/share/config.site" exists on many distros.
My suggestion is to add `export CONFIG_SITE=/dev/null` in
/home/lfs/.bashrc. It
would override the default config.site search rule.
I don't know that we have ${prefix}/etc/config.site. I do not. I
do
have /usr/etc/xdg/autostart/xfce4-notifyd.desktop that was installed
yesterday when I updated xfce4-notifyd.
We probably need to specify --sysconfdir=/etc for that.
As an example, fedora has /usr/share/config.site in the autoconf
package. This one is smart and is skipped in case of cross compilation,
but just in case, I second Xi Ruoyao's proposal. Or even to have
CONFIG_SITE=$LFS/usr/share/config.site
We might then create a config.site for our own use, for example with
prefix=/usr
sysconfdir=/etc
localestatedir=/var
sharedstatedir=/var
That would prevent the need to have those in the configure commands...
It would hide those entries. I'd rather be specific in the book.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] host /usr/share/config.site may break build
On 9/3/20 10:53 PM, Xi Ruoyao via lfs-dev wrote:
Now we are using --prefix=/usr in "Ch. 6 Cross Compiling Temporary Tools". The
problem is that configure scripts (generated by autoconf) will try to load
${prefix}/share/config.site and ${prefix}/etc/config.site. These things are
really "powerful" - they can even override some command line options.
"/usr/etc" should not exist on any FHS-compilant distro, but
"/usr/share/config.site" exists on many distros.
My suggestion is to add `export CONFIG_SITE=/dev/null` in /home/lfs/.bashrc. It
would override the default config.site search rule.
I don't know that we have ${prefix}/etc/config.site. I do not. I do
have /usr/etc/xdg/autostart/xfce4-notifyd.desktop that was installed
yesterday when I updated xfce4-notifyd.
We probably need to specify --sysconfdir=/etc for that.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] gcc-9.2.0 test suite
On 9/2/20 3:04 PM, Tree Davies via lfs-dev wrote: On Wed, Sep 02, 2020 at 06:56:31PM +0200, Pierre Labastie via lfs-dev wrote: On Wed, 2020-09-02 at 07:52 -0700, Tree Davies via lfs-dev wrote: Hi Everyone, I automated my LFS build, and haven't had any issue with it. The other day during a rebuild, I notiiced that I had been running the gcc test suite as the root user. So I fixed it as in the intructions: http://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter06/gcc.html But now the test suite fails. The output: https://pastebin.com/jaqP9b5Y At line 6, it seems there is a "cd ..". It looks like this just follows the "chown -Rv nobody ." line. This is not what is in the book. Maybe you have a typo in your script? Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page I think it might have something to do with the nobody user. the instructions being run are: ``` rm ../gcc/testsuite/g++.dg/pr83239.C chown -Rv nobody . su nobody -s /bin/bash -c "PATH=$PATH make -k check" ``` When run as root 'make -k check', has no issue. Did you create the nobody user? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS and BLFS Version 10.0 are released
The Linux From Scratch community is pleased to announce the release of LFS Version 10.0, LFS Version 10.0 (systemd), BLFS Version 10.0, and BLFS Version 10.0 (systemd). This release is a major update to both LFS and BLFS. The LFS release includes updates to glibc-2.31, and binutils-2.34. A total of 35 packages have been updated. A new package, zstd-1.4.4, has also been added. Changes to text have been made throughout the book. The Linux kernel has also been updated to version 5.5.3. The BLFS version includes approximately 1000 packages beyond the base Linux From Scratch Version 9.1 book. This release has over 840 updates from the previous version in addition to numerous text and formatting changes. Thanks for this release goes to many contributors. Notably: Douglas Reno DJ Lucas Ken Moffat Thomas Trepl Pierre Labastie Tim Tassonis Xi Ruoyao You can read the books online[0]-[3], or download[4]-[7] to read locally. Please direct any comments about this release to the LFS development team at lfs-...@linuxfromscratch.org or blfs-...@linuxfromscratch.org. Registration for the mailing lists is required to avoid junk email. -- Bruce Dubbs LFS [0] http://www.linuxfromscratch.org/lfs/view/10.0/ [1] http://www.linuxfromscratch.org/blfs/view/10.0/ [2] http://www.linuxfromscratch.org/lfs/view/10.0-systemd/ [3] http://www.linuxfromscratch.org/blfs/view/10.0-systemd/ [4] http://www.linuxfromscratch.org/lfs/downloads/10.0/ [5] http://www.linuxfromscratch.org/blfs/downloads/10.0/ [6] http://www.linuxfromscratch.org/lfs/downloads/10.0-systemd/ [7] http://www.linuxfromscratch.org/blfs/downloads/10.0-systemd/ -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Typos
On 8/28/20 10:29 AM, Julien Lepiller via lfs-dev wrote: Same file (sorry for sending two messages…) "This then creates the specified directory if is is not" (should be "it is"). Both fixed. Thanks. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Very minor issue with bzip2 instructions
On 8/23/20 3:44 PM, DJ Lucas via lfs-dev wrote: /lib/libbz2.so.1.0 is not a symlink but a hard link. In the grand scheme of things, it doesn't matter, any real difference (again, super minor) only shows up when packaging. Suggest changing the following: cp -av libbz2.so* /lib ln -sv ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so to cp -av libbz2.so.1.0.8 /lib ln -sv libbz2.so.1.0.8 /lib/libbz2.so.1.0 ln -sv ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so Is this the wrong list? bzip2 is in LFS. In any case I have: lrwxrwxrwx 1 root root15 Aug 14 14:20 /lib/libbz2.so.1.0 -> libbz2.so.1.0.8 -rwxrwxr-x 1 root root 75056 Aug 14 18:27 /lib/libbz2.so.1.0.8 $ ll /usr/lib/libbz* lrwxrwxrwx 1 root root 23 Aug 14 14:20 /usr/lib/libbz2.so -> ../../lib/libbz2.so.1.0 I don't see a hard link. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Comments on the expected test results in the book
On 8/21/20 4:40 PM, Ken Moffat via lfs-dev wrote: I've now run the full set of tests on three different builds of 10.1-rc1, and I'm almost in agreement about the expected results. Two builds were on ryzen. Those used -O3 throughout, even in gcc where I had stopped doing that because of failures I described as in the torture tests. Reinstated because on a semi-decent development machine I want to build more quickly. The other build was one my i3 skylake using -O2 - it's not a main development machine. The following packages still cause me to query what the book says: tcl: I still think that the line Files with failing tests: http.test httpold.test should be mentioned in addition to the clock test (which exits with errors). gcc: I get two additional failures in libstdc++ on all three machines, FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test FAIL: 22_locale/numpunct/members/char/3.cc execution test Totals for unexpected failures in my builds: -O2 -O3 g++ 1717 and 18 gcc 721 libstdc++ 8 8 So, using -O3 still breaks some more gcc torture tests (but the build seems to work well). But I think those two extra libstdc++ failures ought to be mentoned. Python: for me, test_normalization passed on each build. Not sure if it still fails for you guys ? coreutils: We say test-getlogin is known to fail, but in each of my builds I have: SKIP: test-getlogin util-linux: we pass -k to make check without specifying any details. For me, column/invalid multibyte failed on each of my builds. Apart from these minor details of what to expect, this is now all looking really good. I'll also mention that for inetutils, where libls _may_ fail, it failed on the O2 build and one of the O3 builds, but not on the other O3 build. We are still working on tags fo rBLFS, so I opened a ticket on LFS so we don't forget. http://wiki.linuxfromscratch.org/lfs/ticket/4720 -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] M4 in chapter 6 fails to compile
On 8/20/20 11:28 AM, John Burrell via lfs-dev wrote: I get this result make[3]: Entering directory '/mnt/lfs/build/m4/m4-1.4.18/lib' CC gl_avltree_oset.o CC binary-io.o CC c-ctype.o CC c-stack.o CC c-strcasecmp.o CC c-strncasecmp.o CC clean-temp.o In file included from /mnt/lfs/usr/include/stdlib.h:1018, from ./stdlib.h:36, from clean-temp.c:29: /mnt/lfs/usr/include/bits/stdlib.h: In function 'wctomb': /mnt/lfs/usr/include/bits/stdlib.h:91:3: error: #error "Assumed value of MB_LEN_MAX wrong" 91 | # error "Assumed value of MB_LEN_MAX wrong" | ^ make[3]: *** [Makefile:1910: clean-temp.o] Error 1 make[3]: Leaving directory '/mnt/lfs/build/m4/m4-1.4.18/lib' make[2]: *** [Makefile:1674: all] Error 2 Arch applies quite a substantial patch which allows it to compile. I don't know which bit of the patch fixes the above problem I'm afraid Something weird on your host. MB_LEN_MAX should be defined as 16. Try to figure out where it is defined differently. Tell us about your host. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Typos
On 8/20/20 10:46 AM, Alexey Orishko via lfs-dev wrote: On Wed, Aug 19, 2020 at 6:05 PM Julien Lepiller via lfs-dev wrote: Thank you! More work for my translation though ^^ Fixed "optain", "envirnment", along with several other typos found by enchant at r12029. Just in case I found one in "10.4.1. Introduction" rc1: ... with the CONFIG_EFI_STUB *capabality* described Fixed. Thanks. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] SVN 2020-08-11 chapter 8.4 tcl
On 8/19/20 9:24 PM, Kevin Buckley via lfs-dev wrote: Either way, actually, given the four PoIs above, make that, whichever way, the LFS 10.0 TCL would seem to need a little more work, as it is missing the manual installation of the HTML docs. I came to realize that earlier today. It will be done before the final release. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS-10.0-rc1 is released
The Linux From Scratch community announces the release of LFS Version 10.0-rc1. It is a preliminary release of LFS-10.0. This version of the book has undergone a major reorganization. It uses enhanced cross-compilation techniques and an environment isolated from the host system to build tools for the final system. This reduces both the chance for changing the the host system and the potential of the host system influencing the LFS build process. Major changes include toolchain updates to binutils-2.35, gcc-10.2.0, and glibc-2.32. In total, 37 packages were updated since the last release. Changes to the text have also been made throughout the book. The Linux kernel has also been updated to version 5.8.1. We encourage all users to read through this release of the book and test the instructions so that we can make the final release as good as possible. You can read the book online [0], or download [1] to read locally. In coordination with this release, a new version of LFS using the systemd package is also being released. This package implements the newer systemd style of system initialization and control and is consistent with LFS in most packages. You can read the systemd version of the book online [2], or download [3] to read locally. -- Bruce [0] http://www.linuxfromscratch.org/lfs/view/10.0-rc1/ [1] http://www.linuxfromscratch.org/lfs/downloads/10.0-rc1/ [2] http://www.linuxfromscratch.org/lfs/view/10.0-systemd-rc1/ [3] http://www.linuxfromscratch.org/lfs/downloads/10.0-systemd-rc1/ -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Heads Up - Pending LFS-10.0-rc1 release
I am planning on committing Pending LFS-10.0-rc1 tomorrow. There are a few changes to the current development system (linux-5.8.1, iproute2-5.8.0, libpipeline-1.5.3, and man-pages-5.08) but these really shouldn't affect what is in the current development book much. There is a possibility that one or more new LFS package versions will be committed today and I will add those also. At -rc1 release, we will go into package freeze for LFS and only really major updates to LFS will be considered. We will also at the same time start the building/testing process for BLFS. There we test the book packages against the LFS release candidate and tag each package as we go. New package versions can be updated in BLFS if they are not yet tagged, but we will freeze any tagged versions. Target date for LFS/BLFS 10.0 is September 1st. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Typo: chapter04/settingenviron.xml
On 8/14/20 2:46 AM, Kevin Buckley via lfs-dev wrote: chapter04/settingenviron.xml, Line 35 - shell, which does not read, and execute, the conten of /etc/profile or + shell, which does not read, and execute, the content of /etc/profile or Thatks you. Will fix, but it should be 'contents'. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
On 8/13/20 11:32 PM, Kevin Buckley wrote: On Fri, 14 Aug 2020 at 11:48, Bruce Dubbs via lfs-dev wrote: I might have missed this in the email thread but why does the change, which I've seen at r12020, hard-code the version number and not use the entity ? ... .34 later versions? Probably an oversight. I'll fix it, but when I make the change for -rc1 on Saturday. One other thing I think I've spotted at, r12020, as regards that Perl fix then: :BOOK$ grep -A8 Dprefix= chapter07/perl.xml -Dprefix=/usr \ -Dvendorprefix=/usr \ -Dprivlib=/usr/lib/perl5/5.32/core_perl \ -Darchlib=/usr/lib/perl5/5.32/core_perl \ -Dsitelib=/usr/lib/perl5/5.32/site_perl \ -Dsitearch=/usr/lib/perl5/5.32/site_perl\ -Dvendorlib=/usr/lib/perl5/5.32/vendor_perl \ -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl :BOOK$ grep -A8 Dprefix= chapter08/perl.xml -Dprefix=/usr\ -Dvendorprefix=/usr \ -Dprivlib=/usr/lib/perl5/5.32/core_perl \ -Darchlib=/usr/lib/perl5/5.32/core_perl \ -Dsitelib=/usr/lib/perl5/5.32/site_perl \ -Dsitearch=/usr/lib/perl5/5.32/site_perl \ -Dvendorlib=/usr/share/perl5/vendor_perl \ -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl \ -Dman1dir=/usr/share/man/man1\ where the vendorlib define is different between the two chapters ? Yes, I'll address that too. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
On 8/13/20 10:29 PM, Kevin Buckley via lfs-dev wrote: I've also install git using a sed to put the modules into /usr/lib/perl5/5.32/site_perl.. All of perl itself is in /usr/lib/perl5/5.32/core_perl, all the extra modules are in /usr/lib/perl5/5.32/site_perl). I think we ought to change the book to do this, but I'm not sure everyone has read htis thread - I'll raise a ticket. ĸen I might have missed this in the email thread but why does the change, which I've seen at r12020, hard-code the version number and not use the entity ? This is a diff from my on-disk versions: --- LFS-r12002/chapter07/perl.xml 2020-07-18 11:25:51.172416499 +0800 +++ LFS-r12020/chapter07/perl.xml 2020-08-14 09:29:08.815665198 +0800 @@ -45,15 +45,15 @@ Prepare Perl for compilation: -sh Configure -des \ - -Dprefix=/usr\ - -Dvendorprefix=/usr \ - -Dprivlib=/usr/share/perl5/core_perl \ - -Darchlib=/usr/lib/perl5//core_perl \ - -Dsitelib=/usr/share/perl5/site_perl \ - -Dsitearch=/usr/lib/perl5//site_perl \ - -Dvendorlib=/usr/share/perl5/vendor_perl \ - -Dvendorarch=/usr/lib/perl5//vendor_perl +sh Configure -des \ + -Dprefix=/usr \ + -Dvendorprefix=/usr \ + -Dprivlib=/usr/lib/perl5/5.32/core_perl \ + -Darchlib=/usr/lib/perl5/5.32/core_perl \ + -Dsitelib=/usr/lib/perl5/5.32/site_perl \ + -Dsitearch=/usr/lib/perl5/5.32/site_perl\ + -Dvendorlib=/usr/lib/perl5/5.32/vendor_perl \ + -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl The meaning of the new Configure options: --- LFS-r12002/chapter08/perl.xml 2020-07-18 11:25:51.160422501 +0800 +++ LFS-r12020/chapter08/perl.xml 2020-08-14 09:29:08.735665198 +0800 @@ -58,12 +58,12 @@ sh Configure -des \ -Dprefix=/usr\ -Dvendorprefix=/usr \ - -Dprivlib=/usr/share/perl5/core_perl \ - -Darchlib=/usr/lib/perl5//core_perl \ - -Dsitelib=/usr/share/perl5/site_perl \ - -Dsitearch=/usr/lib/perl5//site_perl \ + -Dprivlib=/usr/lib/perl5/5.32/core_perl \ + -Darchlib=/usr/lib/perl5/5.32/core_perl \ + -Dsitelib=/usr/lib/perl5/5.32/site_perl \ + -Dsitearch=/usr/lib/perl5/5.32/site_perl \ -Dvendorlib=/usr/share/perl5/vendor_perl \ - -Dvendorarch=/usr/lib/perl5//vendor_perl \ + -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl \ -Dman1dir=/usr/share/man/man1\ -Dman3dir=/usr/share/man/man3\ -Dpager="/usr/bin/less -isR" \ The thread explains why the addition of the "perl-version-min" subdirectory is required. but why the hard-coding of 5.32 when that's what the entity value would be expanded to, given what's in packages.ent, vis: What happens when Perl5 moves to 5.33, 5.34 later versions? Probably an oversight. I'll fix it, but when I make the change for -rc1 on Saturday. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] grub with uefi for LFS 10?
On 8/5/20 2:25 AM, Xi Ruoyao via lfs-dev wrote: On 2020-08-05 14:37 +0800, Kevin Buckley via lfs-dev wrote: On Mon, 3 Aug 2020 at 00:46, Xi Ruoyao via lfs-dev wrote: It's nearly impossible. If we do that we'll have to introduce at least five new packages: dosfstools, popt, pciutils, efivar, and efibootmgr. Pciutils is recommended to be installed along with "which" (it's a package's name), and one of wget/curl/lynx to make update-pciids script usable. And, to make grub menu "showing normal" we'll need freetype. Freetype has a circular dependency with harfbuzz. Harfbuzz requires glib, graphite, and ICU to be fully functional. Worth pointing out, as the hint does, that you can install Freetype without the harfbuzz, so as to get enough to install an enhanced Grub, and then go back and install a Freetype+harfbuzz later. That's my approach, and OK for a hint. Another way: provide a binary unicode.pf2 file on Anduin, and skip freetype. It's just a font and it's not a problem not to build a font "from scratch". Similarly, the lack of an update-pciids script may not be a major problem as, when building the UEFI-aware Grub for the first time, you can download what that script would fetch, using the host system, and just put the payload into place on the LFS system. The problem is we have to defer the activation of update-usbids.timer (for systemd) or cron job (for sysv) after wget/curl/lynx is installed. Then where should we put the instruction? Not a technical problem but a book structure issue. It's probably way too far beyond LFS to have it in the LFS Book, but the basic capabilities are not as hard to add as one might come to think, just by following all of the BLFS Book's dependencies to the end of each chain. I think it might be better to put EFI grub and its dependencies into BLFS. There is BLFS #5379 (opened 6 years ago). If Bruce agrees I'll change the milestone to 10.1 (10.0 will be too hurry) and do it. And, William Harrington suggested that LFS should support some non-x86 architectures, which would require different bootloaders. They can be put into a new BLFS chapter "alternative bootloaders", along with EFI grub. If you can maintain it on an ongoing basis, I'm OK with adding a section on bootloaders in 10.1. I went ahead and added a 10.1 milestone to BLFS. When you are ready, we can discuss where it should go in the book. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Tcl failed soem tests
On 8/2/20 12:33 PM, Ken Moffat via lfs-dev wrote: On Thu, Jul 30, 2020 at 08:15:10PM -0500, Bruce Dubbs via lfs-dev wrote: On 7/30/20 6:22 PM, Ken Moffat via lfs-dev wrote: On my experimental build which is currently in progress, I managed to log the results of tcl's tests. At first I thought the tests had died, but in the end they completed (2.9 SBU with make -j8, most of the time obviously spent on tests which failed). The results do not look wonderful: Tests ended at Thu Jul 30 21:10:12 + 2020 all.tcl:Total 24996 Passed 21606 Skipped 3336Failed 54 Sourced 150 Test Files. Files with failing tests: http.test httpold.test Number of tests skipped for each constraint: 9 !ieeeFloatingPoint [snip] 2 xdev Test files exiting with errors: clock.test I see there were quite a lot of failures in the clock tests, several in http, and 1 in httpold. I've no idea if this is normal, but the timing seems to be more than a bit different from what the book says. For now I'll just mention it and ask if anyone else sees similar or better results. I've got the full log, but it's 99K so I won't bother uploading or attaching it for the moment. The expect tests were fine, as were the tests for dejagnu. As is normal, I'm using my normal CFLAGS and CXXFLAGS - they start out as (CFLAGS) -O3 -march=native -fstack-clash-protection -fstack-protector-strong (CXXFLAGS) -O3 -march=native -fstack-clash-protection -fstack-protector-strong -D_GLIBCXX_ASSERTIONS although I don't necessarily use all of those on all packages. I'm also using headers from linux-5.8.0-rc7 for this build (I said it was experimental!) and running a 5.8.0-rc5 kernel which has help up well for the past 4 days (sleeping some of the time) and for a few days before that. What I really think you need to do is do a full build without CFLAGS or CXXFLAGS set. Then compare with a build with those settings. My test logs are not complete, but if you really want me to, I can do a full build as of 20200721 with all tests. I can upload the test files to anduin for you to compare. -- Bruce I've now completed a build without any CFLAGS or CXXFLAGS as far as the end of chapter 8, again running all the tests. This is from my 'experimental' system, using the exact same versions and scripts. In the original build where I queried the tcl results (lack of data from anyone else) I now get exactly the same failing tests and test ending with errors. The other packages where I got different results from what the book specifically mentions (or, for glibc, from what I had previously seen) were: glibc-2.31 : both failed misc/tst-ttyname - the book mentions that, but in previous builds in the last couple of months it has passed. gcc-10.2 : Without flags I get one failue beyond what the book mentions, I'm fairly sure I've mentioned it before with 10.1 : FAIL: 22_locale/numpunct/members/char/3.cc execution test Adding my own flags, for gcc I *do* get an extra failure (again, I've seen it before with 10.1) : FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test Note that I have stopped forcing -O3 in my gcc builds because of the failures in the torture tests, here I'm only using -O2 -march=native -fstack-clash-protection -fstack-protector-strong and for CXX I add -D_GLIBCXX_ASSERTIONS so in this case either that allocate.cc test fails with one of these safe flags, or else it randomly fails. autoconf-2.69b (beta) all passed in both runs. automake-1.16.2 : te same 2 new failures from updated autoconf in both runs. util-linux-2.35.2 : column/invalid-multibyte failed in both runs. I've seen this before on this machine using util-linux-2.35.1, including a build where I forgot to set my CFLAGS. Summary: For gcc, adding sensible CFLAGS and more particularly CXXFLAGS *can* provoke extra test failures. Since I'm documenting this, I'll also mention that this week phoronix ran some tests where it looked as if -O2 in recent gcc is slow (that was on intel Comet Lake). Much of the (runtime) slowness in some tests was from using LTO, but in some cases the -O2 performance was much slower than on gcc9. https://www.phoronix.com/scan.php?page=article=gcc-10900k-compiler=1 I do not have elapsed times for either of my builds (in the first, I had breaks where tests failed unexpectedly for me, in the second the Python tests stalled overnight - and of course like many other packages there is no output from the tests until the end, so no idea where they stalled. However, I do have times (in seconds) for the various 'stamps' I create to mark a step as completed. For these, timing starts after untarring and creating an initial log of what is present, and stops before creating the log of what is now presnet and then processing the logs to find what got installed and modified. For the first run with my flags: 178.522s Without my flags: 297.926s A little of that difference might
Re: [lfs-dev] grub with uefi for LFS 10?
On 8/1/20 3:10 PM, Timothy Russo via lfs-dev wrote: With efi being more the standard now, I'd like to ask if we could default grub to supporting uefi instead of having to use the uefi hint. Or at last maybe formalize it and make it an option, where you can pick bios/mbr or uefi option. The only reason to use uefi is if you want to dual boot to Windows. It complicates LFS and will interfere with learning how simple a boot can be. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] More observations on directory creations
On 8/1/20 9:20 AM, Pierre Labastie via lfs-dev wrote:
Hi,
Exceptionally top-posting, because, I'll answer in the message body,
and I want to tell general things first.
First, thanks to Kevin to be our "quality assurance". Those messages
are bugging me, but make me think...
Second, presently, the whole management of directories is the result of
design decisions made at the beginning of the testing of the new
method. Some of those decisions may seem wrong now, but that was not
evident at the time. Specially, the first aim was to have a working
build, not necessarily the best explanations...
Third, one of those decisions was to keep $LFS owned and only writable
by root. At the time, it was thought that it could prevent unwanted
behavior in chapter 6, for example alert on non desirable directory
creation. In retrospect, it was maybe not necessary, and having $LFS
writable by lfs could simplify things a lot.
That said, here are a few comments...
On Sat, 2020-08-01 at 15:42 +0800, Kevin Buckley via lfs-dev wrote:
As some of you will be aware from other threads, I have been
spending way too much time looking at the way that the LFS
book goes about creating its directory hierarchy, but for those
of you who find these things interesting, here's some more.
Here's what the current (r12002) book does, as regards creating
the required directory hierarchy, in two separate parts:
4.2
mkdir -pv $LFS/{usr,lib,var,etc,bin,sbin}
the order is a result of adding directories as needed for chapter 6
installations. They did not come in alphabetical order. Now they can be
sorted...
case $(uname -m) in
x86_64) mkdir -pv $LFS/lib64 ;;
esac
mkdir -pv $LFS/tools
4.3
chown -v lfs $LFS/{usr,lib,var,etc,bin,sbin,tools}
alphabetical sort here too.
case $(uname -m) in
x86_64) chown -v lfs $LFS/lib64 ;;
esac
7.2
chown -R root:root $LFS/{usr,lib,var,etc,bin,sbin,tools}
and here again
case $(uname -m) in
x86_64) chown -R root:root $LFS/lib64 ;;
esac
7.5
mkdir -pv /{bin,boot,etc/{opt,sysconfig},home,lib/firmware,mnt,opt}
At first, /bin was not used in chapter 6. Now it is, and shouldn't
appear here.
/etc, and /lib already exist. the -p option is not needed
mkdir -pv /{media/{floppy,cdrom},srv,var}
Again, /var was added later in the minimal set. May be removed here.
/media does not exist yet, so the -p option is needed.
mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src}
Here, we should separate /usr and /usr/local:
/usr/{bin,include,lib,sbin} exist from chapter 6. The equivalent in
/usr/local does not. OTOH, we may want to have the whole structure in
one place (which means probably adding sbin to the first line)
mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}
Again, some of those already exist from chapter 6
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
Same here (terminfo)
mkdir -pv /usr/{,local/}share/man/man{1..8}
And again here
install -dv -m 1777 /tmp /var/tmp
install -dv -m 0750 /root
mkdir -v /var/{log,mail,spool}
ln -sv /run /var/run
ln -sv /run/lock /var/lock
mkdir -pv /var/{opt,cache,lib/{color,misc,locate},local}
Leaving aside the non-alphabetical ordering of the directories
in the Chapter 4 commands,
I wondered why the first two lines of commands in 7.5 duplicate
the creation, in 4.2, of
/bin
/var
answered above...
but not any of the other "top-level" directories from 4.2, so
/etc /lib /lib64 /sbin /usr
with mkdir -p, those directories would be created if they did not
exist. But I agree, /var could be left for later, when creating
subdirectories in /var (using mkdir -p)
that get created in 4.2?
I do note though that /etc, /lib and /usr are implicitly created
when subdirectories of them are, so could ask a slightly different
question, vis:
Why is the creation of /sbin not duplicated?
Good question. Having the whole directory structure on one page might
be better for understanding. I (and Thomas) wonder whether this
structure couldn't even be created in chapter 4, selectively changing
ownership of directories where the lfs user needs to be able to write.
I also wondered why the first mkdir for subdirectories of /var
mkdir -v /var/{log,mail,spool}
doesn't have a "-p", in common with all the other mkdir-s,
including the creation of the top-level directories.
It does not have a -p because it is not needed. But then the first line
does not need it either... Not very consistent, as you say.
I'd suggest that the 7.5 commands would be better laid out as
Create some root-level directories that are not in the limited set
required for Chapters 4, 5 and 6.
mkdir -pv /{boot,home,mnt,opt,srv}
Create the required set of subdirectories below the root-level
mkdir -pv /etc/{opt,sysconfig}
mkdir -pv /lib/firmware
mkdir -pv /media/{floppy,cdrom}
mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src}
mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv
Re: [lfs-dev] Some files on the final system are now created during the temporary tools phase
On 7/31/20 2:14 PM, Marcel van den Boer via lfs-dev wrote:
Thanks for this,
I compared a completed system of SVN-20200721 with a backup of the
temporary system and found that a few files from the temporary system
are not reinstalled on the final system as a side effect of the new way
of building LFS.
(1) Gawk hardlink.
/usr/bin/gawk-5.1.0 is still pointing to the temporary version of the
software. 'make install' does not replace this file if it already exists.
Possible fix is to just remove the link before rebuilding, or patch the
Makefile to always overwrite it.
I think
sed -i '/LN =/ s/$/ -f/' Makefile.in
can fix this. I've not tested yet.
(2) Perl.
Lots of files are not reinstalled, but are kept from the chapter 7 build
instead. Not sure if these should be removed, if they should have been
rebuilt in chapter 8, or if Perl is aware of these files and does not
reinstall them if they are already present.
-
/usr/lib/perl5/5.32/core_perl/{B,B.pm,Compress,Config.pod,Config_git.pl,Cwd.pm,...,more>}
-
/usr/share/perl5/core_perl/{AnyDBM_File.pm,App,Archive,Attribute,AutoLoader.pm,AutoSplit.pm,...,more>}
We can try 'rm -rf /usr/lib/perl5' at teh start of Chapter 8.
(3) Glibc header file (/usr/include/gnu/stubs-64.h).
Not sure about this one either. Could be that the build compares the
existing file and chooses not to overwrite it if it is unchanged. The
other 5 files in the same directory (like 'lib-names-64.h' and
'stubs.h') are re-created though.
We will need to wait for glibc-2.32 (due tomorrow) to check this.
(4) All Linux API Headers.
This is probably as intended in this new set up. But you may want to
clarify in the book that most (if not all) of these headers are kept on
the final system, even though they are installed during the
cross/temporary build phase.
Yes, the headers will not change between Chapters 7 and 10. I'm not sure
it is necessary to explain to the level of detail you suggest.
(5) A few symlinks are now created way before chapter 8.
This is not an issue for most LFS builders. But it is good to know that
these are left out on your system if you only capture the files built in
chapter 8 for package management.
- /bin/sh
- /lib64/ld-linux-x86-64.so.2
- /lib64/ld-lsb-x86-64.so.3
- /usr/bin/awk
- /usr/bin/cc
I'm used to making package archives from the builds that are now in
chapter 8, and if some files remain untouched in that phase, they are
not captured at all right now. So, if (2) and (3) are not bugs, then I
may have to change my capture mechanism to begin tracking files right
from the start of the build.
We really don't support package management directly in the book. I
think this type of information should go into a hint.
more_control_and_pkg_man.txt would be the most likely candidate if you
want to update it.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Bootscript checkfs anomoly
On 7/31/20 2:11 PM, William Harrington wrote:
On Jul 31, 2020, at 12:25, Bruce Dubbs via lfs-dev
wrote:
On 7/31/20 11:47 AM, William Harrington via lfs-dev wrote:
Greetings,
While checking file systems, the line at 131 will omit ‘Y’. The message ends up
being “ou may want to double-check that”. I had to remove the character before
‘Y’ to correct the output. Please verify.
The only place in that file that has the word 'You' is on line 97:
msg="\nWARNING:\n\nFile system errors "
msg="${msg}were found and have been corrected.\n"
msg="${msg} You may want to double-check that "
msg="${msg}everything was fixed properly."
log_warning_msg "$msg"
I think the number of spaces before 'You' may need to be increased by one
because the function log_warning_msg sets the cursor to column 1 and writes '
*** ' after the message has been written. Can you add that space and test?
Thanks.
Did you make your file system dirty and run that script. The deal is with the
character before ‘Y’
I built LFS 9.1 and have proof
For a workaround, do
sed -i "s/Y/ Y/" /etc/init.d/checkfs
We'll either do that or make an equivalent change in the next version of
the bootscripts.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Bootscript checkfs anomoly
On 7/31/20 11:47 AM, William Harrington via lfs-dev wrote:
Greetings,
While checking file systems, the line at 131 will omit ‘Y’. The message ends up
being “ou may want to double-check that”. I had to remove the character before
‘Y’ to correct the output. Please verify.
The only place in that file that has the word 'You' is on line 97:
msg="\nWARNING:\n\nFile system errors "
msg="${msg}were found and have been corrected.\n"
msg="${msg} You may want to double-check that "
msg="${msg}everything was fixed properly."
log_warning_msg "$msg"
I think the number of spaces before 'You' may need to be increased by
one because the function log_warning_msg sets the cursor to column 1 and
writes ' *** ' after the message has been written. Can you add that
space and test? Thanks.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Tcl failed soem tests
On 7/30/20 9:23 PM, Ken Moffat via lfs-dev wrote: On Thu, Jul 30, 2020 at 08:15:10PM -0500, Bruce Dubbs via lfs-dev wrote: On 7/30/20 6:22 PM, Ken Moffat via lfs-dev wrote: What I really think you need to do is do a full build without CFLAGS or CXXFLAGS set. Then compare with a build with those settings. You really distrust CFLAGS and CXXFLAGS, don't you. I take the view that security is important, as is optimising (now that everything builds so slowly).i Yes, sometimes CFLAGS _do_ screw up occasional packages. It's not that I distrust the flags, but I just think that upstream's knowledge of their code is better than mine. In addition, I've never been able to detect a speedup due to custom flags without instrumenting the program. Small speed improvements do not really improve the user experience. Also, introducing flags that may be HW dependent doesn't help the consistency of the books. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Tcl failed soem tests
On 7/30/20 6:22 PM, Ken Moffat via lfs-dev wrote: On my experimental build which is currently in progress, I managed to log the results of tcl's tests. At first I thought the tests had died, but in the end they completed (2.9 SBU with make -j8, most of the time obviously spent on tests which failed). The results do not look wonderful: Tests ended at Thu Jul 30 21:10:12 + 2020 all.tcl:Total 24996 Passed 21606 Skipped 3336Failed 54 Sourced 150 Test Files. Files with failing tests: http.test httpold.test Number of tests skipped for each constraint: 9 !ieeeFloatingPoint [snip] 2 xdev Test files exiting with errors: clock.test I see there were quite a lot of failures in the clock tests, several in http, and 1 in httpold. I've no idea if this is normal, but the timing seems to be more than a bit different from what the book says. For now I'll just mention it and ask if anyone else sees similar or better results. I've got the full log, but it's 99K so I won't bother uploading or attaching it for the moment. The expect tests were fine, as were the tests for dejagnu. As is normal, I'm using my normal CFLAGS and CXXFLAGS - they start out as (CFLAGS) -O3 -march=native -fstack-clash-protection -fstack-protector-strong (CXXFLAGS) -O3 -march=native -fstack-clash-protection -fstack-protector-strong -D_GLIBCXX_ASSERTIONS although I don't necessarily use all of those on all packages. I'm also using headers from linux-5.8.0-rc7 for this build (I said it was experimental!) and running a 5.8.0-rc5 kernel which has help up well for the past 4 days (sleeping some of the time) and for a few days before that. What I really think you need to do is do a full build without CFLAGS or CXXFLAGS set. Then compare with a build with those settings. My test logs are not complete, but if you really want me to, I can do a full build as of 20200721 with all tests. I can upload the test files to anduin for you to compare. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Expected package changes for LFS-10.0 ?
On 7/28/20 5:30 PM, Ken Moffat via lfs-dev wrote: On Tue, Jul 28, 2020 at 04:32:50PM -0500, Bruce Dubbs via lfs-dev wrote: The release will not be in time for LFS-10. Do you mean "old, with a broken test suite, but released" should always be preferred to "beta, but looks good" ? The old version with a broken test suite is a known quantity. We've used it for years. The beta is an unknown, other than the fact that regression tests now work. We don't use autoconf in LFS, but by my count there are 25 packages that use it in BLFS. Specifically, I found 23 that use autoreconf and two that use autoconf (id3lib and openldap). A lot of those packages are old. We could consider using the beta or git head if all those packages are tested. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Expected package changes for LFS-10.0 ?
On 7/28/20 3:53 PM, Ken Moffat via lfs-dev wrote: I'll now mention that a new release of autoconf is being prepared. 2.69b (i.e. beta) came out a few days ago. Looking at gnu git, there have been a few more fixes since then. I'm on the autoconf mailing list and built the beta. Parallel build is OK. Tests are slow and don't seem to be parallelizable. On a full system rhe tests pass with: 479 tests behaved as expected. 44 tests were skipped. Most of the skips were due to not having fortran, erlang, or go. There were also four expected failures. There are a fair number of issues on the list, but AFAICT, not for x86_64. The release will not be in time for LFS-10. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] procps-ng: seds and rm for testsuite unnecessary
On 7/28/20 10:06 AM, Ken Moffat via lfs-dev wrote: I think the following modifications to the procps-ng testsuite are unnecessary: sed -i -r 's|(pmap_initname)\\\$|\1|' testsuite/pmap.test/pmap.exp sed -i '/set tty/d' testsuite/pkill.test/pkill.exp rm testsuite/pgrep.test/pgrep.exp I dropped these a while ago, and now that I've completed a current build the results for procps-ng look fine (attached) OK, I'll make those changes when I do the large update this weekend. Thanks for pointing out the issue. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Expected package changes for LFS-10.0 ?
On 7/27/20 10:35 PM, Xi Ruoyao via lfs-dev wrote: On 2020-07-28 03:30 +0100, Ken Moffat via lfs-dev wrote: On Mon, Jul 27, 2020 at 09:05:32PM -0500, Douglas R. Reno via lfs-dev wrote: As far as I know, we have another binutils as well (2.35). I think there's a new version of Check as well, the kernel, and util-linux. Cheers. I'm on check-0.15.0 at the moment (haven't looked at any LFS testsuite results yet). Binutils is the sort of thing which might cause occasional breakage, util-linux less so in terms of building and testing packages (but potentially more so in terms of being able to run commands I usually run, of course). Glibc-2.32 will be released on Aug 1st. I suggest to wait for it since anyway we'll have to rebuild everything for it. That's my plan. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Expected package changes for LFS-10.0 ?
On 7/27/20 8:45 PM, Ken Moffat via lfs-dev wrote: I see that a newer gettext is now out, which probably allows bison-3.7.0 to build. Meanwhile, I'm hopeful that bison-3.7.1 will be out soon, with tests to detect whether it can use the functions added in 3.7 or must fall back to functions available in e.g. gettext-0.20.2. But meanwhile (and particularly re testing/measuring rust and its users in BLFS) I'm trying to get my head around what else in LFS is likely to change for LFS-10.0 - particularly toolchain packages. For the main toolchain, I think that gcc-10.2.0 will be in, and from what Bruce said the other day on BLFS, a newer glibc. AFAICS, llvm-11 will not arrive until September and therefore llvm-10.0.1 is as new as we'll be using. Anything else, anyone, or anything wrong in what I've written here ? All the tickets at http://wiki.linuxfromscratch.org/lfs/query?owner=~=assigned=new=reopened=milestone=id=summary=status=owner=type=time=owner Also, any thoughts on when we can start testing 10.0, and therefore which kernel series to use (5.8.0 will either be released on Sunday, or else a week later) - in my current build I've used what is in the book (5.7.9) rather than 5.8-rc, but it feels "so old" ;-) We will try to get everything that is current on Aug 15. After that thee will only be very limited updates -- nothing major. I'm trying to optimize my time for testing, and measuring, the packages which use rust - hopefully to propose 1.45.0, but also to measure their sizes and build-slowness with both gcc and clang. For example, with current rustc-1.42.0 I know that firefox using the book's options builds faster with gccc than with llvm-10.0.0. I'd like to be able to offer gcc as an option for thunderbird (for people who care about security - llvm is poor on security options). I'll be updating everything that's open this weekend. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Creating the Minimal directory layout in LFS filesystem
On 7/26/20 6:35 AM, Kevin Buckley via lfs-dev wrote:
At present, the LFS Book, at Revision r12002, says
4.2. Creating the Minimal directory layout in LFS filesystem
The first task performed in the LFS partition is to create a minimal
directory hierarchy so that programs compiled in Chapter 6 may be
installed in their final location. This is needed so that those
temporary programs be overwritten when rebuilding them in Chapter 8.
Create the required directory layout by running the following as root:
mkdir -pv $LFS/{usr,lib,var,etc,bin,sbin}
case $(uname -m) in
x86_64) mkdir -pv $LFS/lib64 ;;
esac
however, the "This is needed ..." statement is not actually true.
I've noticed that when building the Chapter 5 tools, that you only
really need
$LFS/usr
so as to allow Linux Headers to do this
cp -rv usr/include $LFS/usr
and
$LFS/lib
$LFS/lib64
because of the compatibility links that get added at the start of
Chapter 5's Glibc.
The install of Chapter 5's Glibc creates the following "top-level" directories
lib, var, etc, sbin
when it does, amongst other "mkdir -p" invocations, the following
mkdir -p -- /media/lfs10/lib
mkdir -p -- /media/lfs10/var/lib/nss_db
mkdir -p -- /media/lfs10/etc
mkdir -p -- /media/lfs10/sbin
and indeed, at the end of Chapter 5, there is still no /bin below $LFS.
As I see it, it's not until Chapter 6's Bash, where the bash binary
gets moved to /bin, that that directory is required, so perhaps the
minimal directory list could just be
mkdir -pv $LFS/{bin,lib,usr}
case $(uname -m) in
x86_64) mkdir -pv $LFS/lib64 ;;
esac
and even then the lib and lib64 directories are only required in the Glibc
section because explicit links are made there, so the creation of those
directories could be made part of Chapter 5's Glibc.
Note also that Chapter 6's Bash install, doesn't require $LFS/bin: it's
the "by-hand" move of the bash binary that requires it.
If the creation of /bin was made a part of the Chapter 6 Bash install,
as that is the first place that /bin is required, that would leave Chapter 4
with just this
mkdir -pv $LFS/usr
Just some observations that might be of use to some though,
I haven't checked, but I think you may be taking the word 'minimal' too
literally. Perhaps we should just change the description to:
Creating a Limited directory layout in LFS filesystem
Whether or not all the directories created in Chapter 4 are needed in
Chapters 5 and 6, they are certainly needed in Chapters 7 and 8. When
they are created is really not very important.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Hints Project link broken
On 7/24/20 5:14 AM, John Burrell via lfs-dev wrote: In section 8.2 Package Management, the 'Hints Project' link is broken. There are two of them on that page. Works for me, although the page simply has another link to the directory listing. I'll go ahead and link to the directory listing in my next commit. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] chapter 7 libstdc++ pass2 needs libfl.so.2
On 7/23/20 6:39 AM, John Burrell via lfs-dev wrote: When running as a package user I couldn't compile libstdc++ in chapter 7 because it couldn't find libfl.so.2 I had to go back and add flex to chapter 6 to provide this library. Then it worked. I assume that if you follow the book then this library is picked up from the host. Can I suggest that you add flex to chapter 6 to improve host independence. Flex is not needed for libstdc++ in Chapter 7 for a normal build. When I search for libfl or flex in my log for gcc-libstdc++-pass2-10.1.0, nothing is found. What is package user doing that requires this? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] The locales in Chapter 6 of the development book
On 7/22/20 4:06 AM, John Burrell via lfs-dev wrote: I'm experimenting with installing chapters 5 and 6 as a package user. Can I safely delete the directory $LFS/usr/share/locale for each package that is reinstalled in Chapter 8? I assume I can, but thought I should ask in case the locales from chapter 6 are used in some way in later chapters. AFAIK, the only use of locales in LFS are for tests in Chapter 8. The user may want to change the language after all packages are installed. I do not know of any reason that locales installed before Chapter 8 cannot be removed. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] 7.5. Creating Directories: Order of mode change descriptions wrong
On 7/21/20 6:10 AM, Kevin Buckley via lfs-dev wrote:
Noticed this in r11999 chapter07/creatingdirs.xml
...
mkdir -pv /usr/{,local/}share/man/man{1..8}
install -dv -m 1777 /tmp /var/tmp
install -dv -m 0750 /root
mkdir -v /var/{log,mail,spool}
ln -sv /run /var/run
ln -sv /run/lock /var/lock
mkdir -pv /var/{opt,cache,lib/{color,misc,locate},local}
Directories are, by default, created with permission mode 755, but
this is not desirable for all directories. In the commands above, two
changes are madeone to the home directory of user root, and another to the directories for
temporary files.
The first mode change ensures that not just anybody can enter
the /root directorythe
same as a normal user would do with his or her home directory. The
second mode change makes sure that any user can write to the
/tmp and /var/tmp directories, but cannot remove
another user's files from them.
but note that in the commands,the FIRST mode change is actually
the /tmp /var/tmp one and the SECOND one is for /root.
I'd suggest swapping around the commands, rather that editing the text,
but also note that the commands were in the order matching the text in
LFS 9.1 ?
Thanks. I'll do that in my next commit.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] The testers user: could it be a proto-lfs user?
On 7/20/20 3:21 AM, Kevin Buckley via lfs-dev wrote: Haven't got there in a build yet, as I'm looking at where to build Shadow, so as to get an su. but have noticed that there's an explicit "testers" user being created now, so as to run some Chapter 8 tests that should not be run as root. Given that, when starting from a older LFS installation and coming to use that as the host for a new LFS build, one has to create the 'lfs' user, I was wondering if there'd be any gain, in creating the lfs user inside the chroot, so that it would be there when finally booting into the new LFS system, and also using it for the Chapter 8 testing. At that point, it would be the same as any other non-root user. I could see that a failure to clean up properly before the chroot is first entered might mean that the "new" lfs user might have access to things that it should not have, depending on whether the UID in the host got reused but, for an LFS system, it seems likely that you would want an 'lfs' user at some point. Just another thought though, really, The name of the non-root user in Chapter 8 is not really significant. We use different names, lfs and tester, to indicate to the lfs user different roles. Using the same name is certainly possible, but would remove this distinction. Of course, your distro, your rules. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Bison: The tests are known to fail using multiple processors.
On 7/19/20 11:15 AM, Ken Moffat via lfs-dev wrote: Where tests for a past version have been known to fail using -jN, we tend to carry forward a warning. Perhaps it would be more useful to say 'have been known to fail'. For example, today I tested the bison dev version on a completed system, and was reminded how tlong that takes at -j1. So I retried at -j8 and had no problems. Then I did the same with the current 3.6.4 version and again had no problems. Yes, we can probably remove the warning. bison has been undergoing a lot of changes lately. There have bee seven updates in the last four months. I'll do it in my next commit. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Chapter 4: Could the lfs user perfrom the minimal directory hierachy creation?
On 7/13/20 6:18 AM, Kevin Buckley via lfs-dev wrote: At present, in Chapter 4, the host system's root user creates a minimal directory hierarchy, then creates the lfs user and then chown's the minimal directory hierarchy so as to be owned by th e lfs user, and finally does an su to the lfs user. I was thinking that the order could be altered so that, the host system's root user first creates the lfs user, then merely changes the ownership of the top of the $LFS partition, and then,after the su - lfs the lfs user would create the minimal directory hierarchy. I suppose it's worth floating the idea that the lfs user could even "download" the sources, although that would require the creation of the lfs user a lot further "up" the Book. Sure, that could be done, but why? There are a lot of ways to accomplish the same task, but I don't see the advantage of one way over the other. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Errors with Linux From Scratch Version SVN-20200707
On 7/11/20 7:38 AM, Xi Ruoyao via lfs-dev wrote: On 2020-07-11 11:28 +, John Frankish via lfs-dev wrote: A couple of errors found: Chapter 6. Cross Compiling Temporary Tools 6.7. File-5.39 Building gives the error: Cannot use the installed version of file (5.37) to cross-compile file 5.39 Please install file 5.39 locally first ..fixed by updating file on the host. Forcing a exact version of file in Host System Requirements is stupid. We'll have to install a file for host system in Chap. 5. There is also a FIXME in file-5.39/magic/Makefile.am: # FIXME: Build file natively as well so that it can be used to compile # the target's magic file; for now we bail if the local version does not match Could someone give upstream a patch for it? I don't know why this is happening in Chapter 6. On my log I have: checking whether we are cross compiling... no It worked fine for me when the host version of file was 5.38. Chapter 6. Cross Compiling Temporary Tools 6.10. Grep-3.4 Building pulls in a dep on libpcre from the host, which causes problems later, but can be fixed with "--disable-perl-regexp" It's because configure script picks up the host pkg-config. Other packages may have similar issue. I think we should create a "fake" x86_64-lfs-linux-gnu-pkg-config: ln -sv /bin/false /mnt/lfs/tools/bin/x86_64-lfs-linux-gnu-pkg-config I'll need to check into this a bit more. I do prefer a switch to a symlink. Also, but probably out of scope, Chapter 5. Compiling a Cross-Toolchain 5.5. Glibc-2.31 Fails for arm (RPi) with a long double error fixed with an upstream patch: https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html Glibc-2.32 will be released soon (the scheduled date is Aug. 1st). We will wait for Glibc-2.32. Thanks for the feedback. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] libelf
On 7/7/20 8:13 AM, Pierre Labastie via lfs-dev wrote: On Tue, 2020-07-07 at 11:56 +0100, Roger via lfs-dev wrote: Yesterday I built LFS-9.1 (sysvinit not systemd) with /usr on a separate partition. Localnet failed when I booted. This is because ip (from iproute2) links to libelf which is in /usr/lib. Localnet is run before mounting /usr which means that libelf is unavailable. My quick and easy solution was to move libelf* from /usr/lib to /lib. I've just looked at the latest SVN 2020-07-06 and libelf is still before iproute2 so the above would still happen. I don't see any configure option in iproute2 to stop the link to libelf so one solution would be to change the instructions for installing libelf. If there's a better way, feel free to use it. Thanks for the heads-up. It's good that somebody tests with a separate /usr partition! We can avoid linking by temporarily moving libelf.pc to another file. But I do not know what functionality would be lost in the process. Otherwise, I think we could just add --libdir=/lib to configure in libelf (and still install the .pc file to /usr/lib, and of course remove /lib/libelf.a). I don't think we need to do anything with libelf.pc. Just finish with mv -v /usr/lib/libelf-0.180.so libelf.so.1 /lib ln -sfv ../../lib/$(readlink /usr/lib/libelf.so) /usr/lib/libelf.so -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/21/20 5:33 AM, Xi Ruoyao via lfs-dev wrote: On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote: On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote: On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 8:30 PM, Bruce Dubbs wrote: On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. I wrote the above before I saw the messages in -support. I do note that in my debian system I used to get LFS up on my new system I edited /etc/bash.bashrc so the first line was 'return'. I did that primarily because I don't like polluting the environment with bash completion stuff. I think the problem is not 'exec env ... /bin/bash' directly, but the changes to bash invocation by some distros. I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. I'll do a test of that. I tested several options. That /etc/bash.bashrc thing is evil. I edited it to put at the top: echo "IN /etc/bash.bashrc" Even with your line exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash --posix (Note that I changed the file name to make it a non-hidden file.) it STILL runs bash.bashrc. --norc doesn't change that either. Nor does --init-file $HOME/lfs-bashrc In the case if ubuntu though the posix setting does not install the function command_not_found_handle, but I don't think we can really count on that. Really the I think the only way to handle this is to edit /etc/bash.bashrc to put a return in on the first line or to rename the file and let the user restore it if desired later. It's strange. I read bash code and commit history but found --norc should disable loading of SYS_BASHRC, since bash-2.0. It also really works on latest Arch (but it didn't work on Arch in Nov 2019). Which distro are you using? I tried Arch (latest) and Ubuntu (18.04) on my laptops, and SUSE (leap 15.2) on distrotest.net. On all of these --norc works so maybe we can throw every environment variables into env command in .bash_profile and use --norc. I was using the system installed by ubuntu-20.04-desktop-amd64.iso for testing. If you do 'env -i bash --norc' and then 'set', do you get all the bash complet
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 8:30 PM, Bruce Dubbs wrote: On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. I wrote the above before I saw the messages in -support. I do note that in my debian system I used to get LFS up on my new system I edited /etc/bash.bashrc so the first line was 'return'. I did that primarily because I don't like polluting the environment with bash completion stuff. I think the problem is not 'exec env ... /bin/bash' directly, but the changes to bash invocation by some distros. I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. I'll do a test of that. I tested several options. That /etc/bash.bashrc thing is evil. I edited it to put at the top: echo "IN /etc/bash.bashrc" Even with your line exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash --posix (Note that I changed the file name to make it a non-hidden file.) it STILL runs bash.bashrc. --norc doesn't change that either. Nor does --init-file $HOME/lfs-bashrc In the case if ubuntu though the posix setting does not install the function command_not_found_handle, but I don't think we can really count on that. Really the I think the only way to handle this is to edit /etc/bash.bashrc to put a return in on the first line or to rename the file and let the user restore it if desired later. It's strange. I read bash code and commit history but found --norc should disable loading of SYS_BASHRC, since bash-2.0. It also really works on latest Arch (but it didn't work on Arch in Nov 2019). Which distro are you using? I tried Arch (latest) and Ubuntu (18.04) on my laptops, and SUSE (leap 15.2) on distrotest.net. On all of these --norc works so maybe we can throw every environment variables into env command in .bash_profile and use --norc. I was using the system installed by ubuntu-20.04-desktop-amd64.iso for testing. If you do 'env -i bash --norc' and then 'set', do you get all the bash completion macros? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/20/20 8:30 PM, Bruce Dubbs wrote: On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME \ TERM=$TERM \ PS1='\u:\w\$ ' \ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. I wrote the above before I saw the messages in -support. I do note that in my debian system I used to get LFS up on my new system I edited /etc/bash.bashrc so the first line was 'return'. I did that primarily because I don't like polluting the environment with bash completion stuff. I think the problem is not 'exec env ... /bin/bash' directly, but the changes to bash invocation by some distros. I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. I'll do a test of that. I tested several options. That /etc/bash.bashrc thing is evil. I edited it to put at the top: echo "IN /etc/bash.bashrc" Even with your line exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash --posix (Note that I changed the file name to make it a non-hidden file.) it STILL runs bash.bashrc. --norc doesn't change that either. Nor does --init-file $HOME/lfs-bashrc In the case if ubuntu though the posix setting does not install the function command_not_found_handle, but I don't think we can really count on that. Really the I think the only way to handle this is to edit /etc/bash.bashrc to put a return in on the first line or to rename the file and let the user restore it if desired later. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. I wrote the above before I saw the messages in -support. I do note that in my debian system I used to get LFS up on my new system I edited /etc/bash.bashrc so the first line was 'return'. I did that primarily because I don't like polluting the environment with bash completion stuff. I think the problem is not 'exec env ... /bin/bash' directly, but the changes to bash invocation by some distros. I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. I'll do a test of that. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Some comments on the test results.
On 6/19/20 11:58 AM, Pierre Labastie via lfs-dev wrote: On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote: I've now been through my test logs for the new build (on my i7 haswell). Here are a few comments (in order of testing) bison-3.6.3 --- Here, I strongly disagree that the tests need to be run with -j1. On my i3 Skylake last December I had to use -j1 to get the package to compile, and therefore I also used -j1 on that machine if I ran the tests. But on other machines I'm using -j8 both for the compile and for the tests (and no failures). Could be changed I guess I added that because at -j22 the tests failed but passed at -j1. I suppose I could test again at -j8. -j1 is slooow. On my last test build bison was about twice as long as the next longest package. I'll note that I did not run tests on most packages, but only the ones I was updating at the time, but is was still longer than gcc without tests. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS
On 6/18/20 2:15 AM, Pierre Labastie via lfs-dev wrote: Thanks. This is "just" a typo here, but I guess we'll find some more errors: a big rewrite like that implies two very different tasks: - make the instructions work (lot of trial and error) - keep the text in sync with the instructions (not always easy since the first task is a moving target:) Yes, this is an iterative task. I spent several days reading every page of the book and still missed some of the needed corrections. Hopefully we can catch any remaining problems soon. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Stripping Again: loss of suid on some files
On 6/17/20 3:36 PM, Ken Moffat via lfs-dev wrote: On this build, after misreading 'stripping' earlier in the book (and trashing the partial system by running it from within chroot) I had to start over. So, before trying 'stripping again' I exited, unmounted, copied everything, then remounted before trying 'stripping again'. I guess that means I can look at the backup to confirm that stripping again did change the perms. Will do that later. Meanwhile, thanks for the correction for wall. Hmm. You did do the backup as root, right. Doing a tar or cp as a regular user can change permissions. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Stripping Again: loss of suid on some files
On 6/17/20 1:55 PM, Ken Moffat via lfs-dev wrote:
Bringing this here now that Scott Andrews has pointed me towards the
source of why users could not su on my new system: loss of suid.
In the past I have not usually run what was in 'Stripping Again'
because my CFLAGS drop debug information. But I've now started to
allow that in elfutils (to get the tests to pass), so I know that at
least those libs could be stripped.
What has happened on this build is that all of the bin programs lost
the suid bit, i.e.
/bin/{mount,ping,ping6,su,umount}
/usr/bin/{chage,chfn,chsh,expiry,gpasswd,newgidmap}}
/usr/bin/{newgidmap,newgrp,newuidmap,passwd,wall}
Since nobody else has reported this for the moment, I'm merely
reporting iti, not attempting to fix the book. In my own script for
Stripping Again I've now added
chmod -v 4755 /bin/{mount,ping,ping6,su,umount}
chmod -v 4755 /usr/bin/{chage,chfn,chsh,expiry,gpasswd}
chmod -v 4755 /usr/bin/{newgidmap,newgrp,newuidmap,passwd}
chmod -v 6755 /usr/bin/wall
All the files in the above match those permissions without doing
anything different from the book on my system. I did build the system
manually.
One exception, wall, has permissions 2755 (-rwxr-sr-x with group tty).
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] Major Changes to LFS have been made
The changes to LFS announced earlier are now incorporated into the main book. For those who checked out svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/, you only need to do an 'svn update' and rebuild the book. For those who checked out the entire repository, you will need to go to the head of the LFS repository to do the update. The old book is in the repository as LFS/branches/old-trunk. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS
On 6/15/20 6:28 AM, Kevin Buckley via lfs-dev wrote: Might I playfully suggest that LFS should find a package that could optionally be built with CMake, so as to introduce new readers to that build system here too, rather than making them wait for that joy in BLFS. It has been considered, but cmake has a dependency tail that we do not want to introduce into LFS. libuv curl (with it's own set of dependencies) libarchive (also with optional dependencies) For the most part we want to minimize the number of packages that are in both LFS and BLFS. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS
On 6/15/20 2:09 AM, Kevin Buckley via lfs-dev wrote: On Sat, 13 Jun 2020 at 20:46, Bruce Dubbs via lfs-dev wrote: In the last few weeks, the LFS editors have been working on a major overhaul of LFS. This work can be reviewed at http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/ Was there an SVN reference (branch) to pull the sources from? We welcome comments and criticisms large and small. -- Bruce These comments (or maybe criticisms - your interpretation: your rules) based on a very quick speed read: please take that into consideration when deciding. We appreciate your input. I'd like to see the "cross-compiling 101" sections, so Introduction Toolchain Technical Notes General Compilation Instructions in "chapter" 5, separated out from the package build sections there. We can possibly put a header in the table of contents like we do for Java in http://www.linuxfromscratch.org/blfs/view/stable/general/prog.html, but the new Chapter 5 is now only 8 pages long. A separate chapter doesn't make sense to me. Appreciate they would make for a very small introductory chapter but it somehow feels wrong as it is. Not sure if I'd favour the Pass1 and Pass2 sections all being within the same chapter or not though, or how one would entitle a chapter that just contained just those five package builds, plus yet another Introduction. The pass1/pass2 titles are all in Part III. In the full book there are really three builds for some packages. The -pass titles are really to emphasize that the same packages are being built with different procedures fo rthe creation of the tools. I am also aware that Ninja and Meson are still only "required" for the SystemD version, but that LFS has decided to build packages in the SysV revision with them, even though all required packages can still be built using an Autotools-based approach. (I 'm sure that claim is soon to be rendered invalid though?) In BLFS is is hard to get away from meson and ninja. A lot of packages are going to those (and in my opinion, not fast enough). LFS has never been about minimalism. If we did that we could omit things like man pages and vim. It is about building a solid base system from which a user can build the real applications that are needed. I appreciate there's a perception that the SysV and SysD books should align as much as possible, indeed I've even got some packages re-ordered on the basis of that view, but I'm less convinced that the SystemD tail should wag the LFS dog. It's doesn't really. When we had separate source it was a major effort to keep both books in sync. Over 90% of the two books are common so it makes sense to keep them together. Given that LFS used to start from the view that one only built what was needed to build the LFS-system, and never warming to the systemd camp fire, i've always felt Ninja and Meson to be a kind of feature-creep and so was wondering if that could be made more explicit, so that people could see that Ninja and Meson could happily be left out until BLFS. (Though there's no getting away from them there: more's the pity!) I generally don't do much with systemd either. In BLFS there are over 100 packages that use meson and over 100 others that use ninja. Recently I've become very unhappy with autotools because configure at -j1 takes as long as the make phase. These newer tools are really better. Then again, I could make the same claim for Intltool and a couple of other packages related to it. Looking forwards to trying it out though, Again, thanks for your input. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS
On 6/14/20 11:41 AM, Xi Ruoyao via lfs-dev wrote: On 2020-06-14 10:49 -0500, Bruce Dubbs via lfs-dev wrote: On 6/14/20 8:35 AM, Pierre Labastie via lfs-dev wrote: On Sun, 2020-06-14 at 15:15 +0200, Pierre Labastie via lfs-dev wrote: I am currently testing whether moving iana-etc before gcc may allow tests to pass, as reported by Joe Locash. If so, I'll commit it. Hmm, having iana-etc does not change anything to the "22_locale/time_get/..." failures, and there is still one failure in experimental/net/internet/resolver, even with a real /etc/host installed! Some details about the 22_locale/time_get/..." failures in gcc's libstdc++ tests. They all revolve around two files in the same way: libstdc++-v3/testsuite/22_locale/time_get/get_time/char/2.cc libstdc++-v3/testsuite/22_locale/time_get/get_time/wchar_t/2.c They both do: iterator_type is_it20(iss); tm time20; errorstate = good; tim_get.get_time(is_it20, end, iss, errorstate, ); VERIFY( time20.tm_sec == time_bday.tm_sec ); VERIFY( time20.tm_min == time_bday.tm_min ); VERIFY( time20.tm_hour == time_bday.tm_hour ); VERIFY( errorstate == ios_base::eofbit ); The failure is in the last VERIFY macro. I've tried to trace the logic of the tim_get.get_time function, but it's complicated. If that last VERIFY is commented out or changed to !=, then all the time_get failures go away. It's GCC PR71367: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 Nice find. It looks like the test is actually doing it's job in pointing out a problem. It does not seem like a priority to upstream because it has languished for over a year. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS
In the last few weeks, the LFS editors have been working on a major overhaul of LFS. This work can be reviewed at http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/ The elements of building LFS using cross compiling techniques have changed a lot. The old Chapter 5 has been split into three chapters that have a different focus for each chapter. Some of the advantages include not requiring a /tools symlink on the host system and not requiring a lot of hackish symlinks when starting the final build system. In addition, a lot of work was done to minimize the number of test failures in the different packages. Finally, every page in the new book was reviewed and textual updates made to clarify different elements of the LFS process. We welcome comments and criticisms large and small. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Future for LFS
On 6/12/20 10:00 PM, William Harrington via lfs-dev wrote: Greetings, I’ve noticed that LFS is only targeting i386 and AMD64. The is a great hunger for LFS to support ARM. Many have wished for the support. What is keeping LFS from supporting ARM? What I have seen while reading forums and IRC chat, LFS should be supporting ARM. Why is the book only targeting I386 and X86_64 and nothing else? There are ma y LFS users who have attempted to contribute their knowledge. Why is LFS not using g one archs ? You know, of course, that LFS is done 100% by volunteers. It's not just time, but also money. We pay of hosting and our development hardware. For my part, I spend well over 40 hours a week on LFS and work on it 7 days a week. I don't have time to add another architecture. I doubt the other editors do either. If you want to clone LFS for an ARM architecture, then you are more than welcome. We can even let it be hosted on the LFS servers. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Odd failure to make the book
On 6/12/20 7:14 PM, Ken Moffat via lfs-dev wrote: I've been updating my local copy of cross2, and creating that book, without noticing any obvious problems. But before I attempt to check my scripts agaisnt it I thought I'd better ensure that my copy of trunk (from which I update package versions etc) was up to date. It seems to be, but buildign the book errors - ken@llamedos ~/repos/LFS/trunk/BOOK $make Creating and cleaning /home/ken/tmp Processing bootscripts... Adjusting for revision sysv... Validating the book... Validation complete. Generating profiled XML for XHTML... Generating chunked XHTML files at ~/lfs-book/ ... Copying CSS code and images... mkdir: cannot create directory ‘/home/ken/lfs-book’: File exists make: *** [Makefile:41: book] Error 1 Any ideas, please ? You are in trunk, not cross2. I don't know where that mkdir is coming from. All the instances in the Makefile use -p for mkdir. The line after Copying CSS should be Running Tidy. @echo "Copying CSS code and images..." $(Q)mkdir -p $(BASEDIR)/stylesheets $(Q)cp stylesheets/lfs-xsl/*.css $(BASEDIR)/stylesheets $(Q)pushd $(BASEDIR)/ > /dev/null; \ # sed -i -e "s@../stylesheets@stylesheets@g" *.html; \ popd > /dev/null $(Q)mkdir -p $(BASEDIR)/images $(Q)cp images/*.png $(BASEDIR)/images @echo "Running Tidy and obfuscate.sh..." We probably should remove the three pushd...popd lines. Is your Makefile different? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] User 'tester' : why is the uid 1000 ?
On 6/6/20 4:39 PM, Ken Moffat via lfs-dev wrote: Well, again thanks, but I'm not at all certain. For example, the host system is the one where after its first boot I managed to run the 'check' tests without failures. Now (normal desktop installed, but same kernel) the tests which raise sigfpe again fail. You do a lot with different flags. I only use them when absolutely necessary. I suspect your issues have something to do with that. Have you ever done any benchmarks comparing a build with and without your different flags? If you are only changing installed space and/or execution time by a few percent then it seems that the benefit is not worth the effort. Even if a task takes two seconds and you have a 50% reduction to one second, is it really important? A 10% reduction from an hour to 54 minutes is really not significant either unless you are doing that task continuously. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] User 'tester' : why is the uid 1000 ?
On 6/6/20 2:05 PM, Ken Moffat via lfs-dev wrote: I can see that the tester user gets added by a command which uses ls -n $(tty) and I now see that this results for me in a value of 1000. What I don't understand is where that comes from. On my systems user 1000 happens to be the most important regular user (i.e. me) and (after trying a build without noticing this would duplicate the UID - I already set up my regular users on the way into chroot) I eventually discovered that coreutils was trying to chown to ken. So, before I try to use a number of my own choosing: is it important to match $(tty) ? I can see that /dev/tty1 where I'm logged in has an id of 1000, as do the /dev/pts for the terms I'm using. It is important for some tests. Look at the permissions for $ ls -l /dev/pts total 0 crw--w 1 1000 tty 136, 0 Jun 6 15:51 0 crw--w 1 1000 tty 136, 1 Jun 4 05:17 1 If the owner id doesn't match, then you can't read from the device. From memory, the book starts at user 1001 (some new-fangled change a few years ago, too awkward to change all my files) - but would that not mean that if I logged in as user 1001, ran startx (via elogind), su, su lfs, the value would be 1001 in that case, and therefore I would not be able to upload my user to /etc/passwd until LFS had been completed ? In the creating files section we have users:x:999: And in shadow sed -i 's/1000/999/' etc/useradd That sed makes /etc/default/useradd have 'GROUP=999'. The combination makes the first user created by useradd have uid and gid values of 1000 instead of the default 1001. Of course if 1000 is already in use, it uses the next numerical value not already used. I'm increasingly starting to think that I'm not cut out for this. Sure you are. We are all continuously learning new things. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: some improvements to LFS book
On 5/30/20 12:00 AM, Xi Ruoyao via lfs-dev wrote:
On 2020-05-15 15:09 +0800, Xi Ruoyao via lfs-dev wrote:
On 2020-05-11 23:05 +0800, Xi Ruoyao via lfs-dev wrote:
On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
I just redone LFS build for GCC-10.1.0. I proposed several
improvements during
the process:
At first, some changes suggested by Firas:
1. Remove bzip2 in Chap. 5. No other changes needed.
decreases the total number of SBUs by 0.1 :) why not, though
2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to
satisify
it.
Notes:
(1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one
module we don't
need.
(2) We moved readline before bc to satisify GNU bc, but now Gavin's
bc doesn't
need readline.
good point
(3) It slightly reduces the functionality of Chap. 5 bash. Long
command lines
won't be wrapped automatically anymore.
It does much more than that if the terminfo database is not installed:
no backspace (more exactly, backspace outputs only a space forward...)
left and right arrows not functional.
In short, no way to correct a typo
can be Ok if scripting though
So I'll not do that.
In a recent thread we discovered gettext somehow depends on ncurses. So it
should not be done, at all.
3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so
`ranlib` and
`ar` can link to libfl.so. It seems bison test suite does not
depends on flex
any more.
bison chapter 6 will be built after flex anyway, if we do the above, so
whether it depends on it or not is not important.
However Firas' other suggestions are proved to be impossible. Glibc
requires
bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred)
so all of
them need to stay in Chap. 5. Util-linux can't be removed from Chap.
5 due to
its circular dependency with systemd/eudev.
And:
4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and
use zstd to
compress LTO stream.
definitely to be done, independently on the other points.
5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It
seems
unneeded now.
6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
7. Add:
mkdir /tools/lib/locale
localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
into Chap. 5 Glibc. It will satisfy Chap. 6 man-db test.
Or link /tools/share/locale/locale-archive->/usr/share/locale/locale-
archive
allows also all bison tests to pass
8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
"Cleaning
up" section.
Independent on the other points and should be done for sure.
Are they OK to be committed into trunk?
I'd say point 2 shouldn't not be committed, or only with some tweak of
the terminfo database...
among the other points:
- 4 and 8 should be done for sure.
- I've not tested 5 and 6, but I guess you have tested them, so go for
them too
- I'd rather use the link for point 7 (less instructions in chap 5
glibc). This is just one more line in "creating essentials symlinks and
files".
I agree that a link is better.
- I'm not sure about point 3: building flex only once is tempting, but
can the tests be run, and is flex the same as if rebuilt at the end of
chap 6?
I'll retry 3, 5 and 6 again to make sure, ...
For 3:
They are same (`diff` returns 0 for flex and libfl.so). But I'm using some
CFLAGS w/o `-g` so the comparsion doesn't include debug information.
For 6:
Definitly OK.
For 5:
The configure script actually doesn't use pkg-config to find packages at all.
- Point 1 improves only marginally the build time, but why not?
Can we hold off on these changes for a week or so until we get BLFS
built with gcc10?
... in the meantime we can get BLFS built with gcc 10 :).
Now 7 is done (with a symlink), and 2 is ruled out. If there is no objection
I'll do other.
zstd? Go ahead.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)
On 5/26/20 7:49 AM, Pierre Labastie via lfs-dev wrote: [snip] I have changed mounting /dev/pts as --bind. We should allow the possibility to revert if we find out that some distros have gid!=5 for tty. It removes one failure in coreutils tests. I have changed the way to su to nobody for bash. There are still test failures (diff output), due to the fact that nobody does not have r/w access to /dev/stdin, /dev/stdout, or /dev/stderr. I think there are two possibilities to fix this: a - create a regular user, and use su - for this user b - use util-linux' su with the -P option (allows to allocate a private terminal for the su session, which is not possible with shadow's su) In chroot with /dev/pts as --bind I get: root:/$ ls -l /dev/pts total 0 crw--w 1 1000 tty 136, 1 May 26 09:13 1 crw--w 1 1000 tty 136, 2 May 25 12:12 2 c- 1 root root 5, 2 May 13 00:30 ptmx When we add user nobody, perhaps it would be sufficient to make that user a member of the tty group. Another thought is to create a user 'tester' with useradd with the required group membership and home directory and then at the end of Chapter 6 remove that user with userdel. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Automake: skip tags-lisp-space.sh
On 5/21/20 5:41 PM, Ken Moffat via lfs-dev wrote: At the moment we have a known failure in automake-1.16.2, tags-lisp-space.sh. This fails because etags is not present. The test tagsub similarly wants to use etags, but for that the test is skipped. The difference is that tagsub has required=etags whereas tags-lisp-space.sh has required='' This has already been fixed upstream: commit 77d39959511295f5a30332d5d03f0a6956bd9460 Author: Karl Berry Date: Tue Mar 24 18:30:18 2020 -0700 tests: require etags for tags-lisp-space test. * t/tags-lisp-space.sh (required): set to etags. diff --git a/t/tags-lisp-space.sh b/t/tags-lisp-space.sh index d0a940ba3568..44312b0b7ab7 100755 --- a/t/tags-lisp-space.sh +++ b/t/tags-lisp-space.sh @@ -18,7 +18,7 @@ # if there are CONFIG_HEADERS. # See automake bug#38139. -required='' +required=etags . test-init.sh # some AC_CONFIG_FILES header is needed to trigger the bug. I tend to come up with ugly seds, I'm using sed -i "/required=/s/=.*/=etags/" t/tags-lisp-space.sh Maybe there is a better sed variant ? It is always nice to reduce the number of test failures in LFS. There is only one instance of 'required' in t/tags-lisp-space.sh and only one instance of two adjacent single quotes. I suggest: sed -i "/''/etags/" t/tags-lisp-space.sh -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On 5/19/20 2:25 PM, Akira Urushibata via lfs-dev wrote: Is there any problem with making a new directory at the filesystem base level? In theory there could be a distribution which already has a /tool directory. But I have never heard of that. What alternatives are there to /tool ? If /tool is so abhored, why not try /usr/local instead ? What happens when you do that? The /usr/local directory must be empty for this to work and you shouldn't do anything other than build LFS on this system. But if you dislike /tool , it should be worth a try. We use /tools -> /mnt/lfs/tools as a location for creating the temporary tools used to build the system in Chapter 6. In that way files like /tools/bin/make can be found via the identical path from the host and from within chroot. When rebooting the completed system, the host's /mnt/lfs/tools becomes a directory, /tools, not a symlink, but is not used. The FHS says that "*distributions* should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability." LFS is not designed to be a distribution although many treat it that way. Your distro, your rules. Additionally, there is nothing preventing an LFS user from deleting or moving /tools from the host any time after Chapter 6. /tools and /mnt/lfs/tools are really only temporary constructs. I'll note that I have several non-FHS anointed entries in /: /build, /jhalfs, lost+found, and /sources. Actually lost+found is almost always found for all distributions but is not mentioned in the FHS. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] CFLAGS in fixing up for gcc-10.
On 5/13/20 11:33 PM, Ken Moffat via lfs-dev wrote:
I notice that in some places people have overridden any existing
CFLAGS when adding -fcommon. In most places, for those of us who
care the fix is obvious (CFLAGS="$CFLAGS -fcommon"). One or two
packages will turn out to be more painful.
The first I've found is freeglut, where the book uses
-DCMAKE_C_FLAGS=-fcommon
For people without any existing CFLAGS, that does the right thing
and respects the -O3 etc from specifying a Release build (seen by
using 'make VERBOSE=1') but for people who have extra flags such as
"-march=native -D_FORTIFY_SOURCE=2" those just get thrown away.
I'd assumed I could add
-DCMAKE_CFLAGS="$CFLAGS -fcommon"
but if I do that, cmake tells me that CFLAGS was not referenced.
In this case, I am getting the right results (testing on a gcc-9
system) with:
CFLAGS="${CFLAGS} -fcommon" \
cmake -DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE=Release \
-DFREEGLUT_BUILD_DEMOS=OFF \
-DFREEGLUT_BUILD_STATIC_LIBS=OFF \
-Wno-dev ..
Can I ask people to at least *consider* not trashing a user's
specified CFLAGS ?
Yes, we can do that, but right now we are trying to just get everything
to build with gcc10. When that is done, we can probably review and do
'grep -r CFLAGS; in the book's xml top and do the right thing where we
have had to make changes.
Also as new package releases address gcc10, we can probably remove a lot
of the CFLAGS entries that we've been making.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] proposal: some improvements to LFS book
On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
I just redone LFS build for GCC-10.1.0. I proposed several
improvements during
the process:
At first, some changes suggested by Firas:
1. Remove bzip2 in Chap. 5. No other changes needed.
decreases the total number of SBUs by 0.1 :) why not, though
2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to
satisify
it.
Notes:
(1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one
module we don't
need.
(2) We moved readline before bc to satisify GNU bc, but now Gavin's
bc doesn't
need readline.
good point
(3) It slightly reduces the functionality of Chap. 5 bash. Long
command lines
won't be wrapped automatically anymore.
It does much more than that if the terminfo database is not installed:
no backspace (more exactly, backspace outputs only a space forward...)
left and right arrows not functional.
In short, no way to correct a typo
can be Ok if scripting though
3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so
`ranlib` and
`ar` can link to libfl.so. It seems bison test suite does not
depends on flex
any more.
bison chapter 6 will be built after flex anyway, if we do the above, so
whether it depends on it or not is not important.
However Firas' other suggestions are proved to be impossible. Glibc
requires
bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred)
so all of
them need to stay in Chap. 5. Util-linux can't be removed from Chap.
5 due to
its circular dependency with systemd/eudev.
And:
4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and
use zstd to
compress LTO stream.
definitely to be done, independently on the other points.
5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It
seems
unneeded now.
6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
7. Add:
mkdir /tools/lib/locale
localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
into Chap. 5 Glibc. It will satisfy Chap. 6 man-db test.
Or link /tools/share/locale/locale-archive->/usr/share/locale/locale-
archive
allows also all bison tests to pass
8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
"Cleaning
up" section.
Independent on the other points and should be done for sure.
Are they OK to be committed into trunk?
I'd say point 2 shouldn't not be committed, or only with some tweak of
the terminfo database...
among the other points:
- 4 and 8 should be done for sure.
- I've not tested 5 and 6, but I guess you have tested them, so go for
them too
- I'd rather use the link for point 7 (less instructions in chap 5
glibc). This is just one more line in "creating essentials symlinks and
files".
- I'm not sure about point 3: building flex only once is tempting, but
can the tests be run, and is flex the same as if rebuilt at the end of
chap 6?
- Point 1 improves only marginally the build time, but why not?
Can we hold off on these changes for a week or so until we get BLFS
built with gcc10?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] chapter6: move Zstd before GCC?
On 5/9/20 9:13 PM, Xi Ruoyao via lfs-dev wrote: Now GCC optionally depends on zstd (using it like zlib to compress LTO IR). Should we move zstd before GCC? I think we can do that. I looked at the dependencies and all are in Chapter 5. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Add missing space...
On 5/5/20 10:45 AM, Firas Khalil Khana via lfs-dev wrote: For the sake of completeness, there's a missing space in Chapter 6, in E2fsprogs, and when listing Installed programs (between dumpe2fs and e2freefrag): "Installed programs: ... debugfs, dumpe2fs,e2freefrag, e2fsck ..." Will be fixed at next commit. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
