- Update to linux-7.0.7 (Security Update)
- Update to tcl-8.6.18
- Update to expat-2.8.1 (Security Update)
- Update to vim-9.2.0481 (Security Update)
- Fix CVE-2026-7210 and CVE-2026-8328 in Python
- Update chapter01/whatsnew.xml with a current list of added patches
Updating a couple of days before the normal mid-month commit.
This is to establish the initial baseline for fixing numerous
packages in BLFS that will need to updated for linux-7 and
openssl-4.
Update to vim-9.2.0461 (Security Update).
Update to sqlite-3.53.2.
Update to Python-3.14.5.
Update to openssl-4.0.0.
Update to linux-7.0.5.
Update to iana-etc-20260604.
Add Python-3.14.5 linux7 build patch.
Add glibc linux7 fixes patch (Security Fix).
Add systemd openssl4 build patch.
The original warning is inaccurate/misleading in many aspects.
The critical thing is GCC version. There's nothing to do with the
OpenSSL version (as nothing in ch5 or 6 ever uses OpenSSL). There's
also nothing to do with the kernel "major" version as the "major"
version is just an arbitary choice to make the minor version not greater
than 19 by Linus. It does not imply any aspect of the ABI, unlike the
"major" version in a SONAME or something. The inablility to build Glibc
with Linux 7.0 API headers is simply a coincidence. If another API
header change happens in Linux 7.6, it may break Glibc build as well.
And I cannot see how the Linux API header version of the host distro can
ever affect LFS. LFS builds ch05 Glibc with its own Linux API header
installed just before Glibc, not the installation from the host distro.
So Glibc should just build fine with the 6.19 API header just installed
into $LFS/usr/include. I know it would fail to build with Linux 7.0 API
headers but why it can ever find one - if it really finds the host
distro's API header instead of the one in $LFS/usr/include we have a
serious bug and it will have to be fixed instead of papered over by
limiting the host distro.
I also know the req test will fail if the host distro has Linux 7.0 but
I've no idea if the test failure is really related to the "massive
breakage of rseq" (I assume it refers to the jemalloc breakage? But
AFAIK nothing in LFS uses jemalloc). And the glibc upstream has just
fixed the test file simply. We always treat test-file-only fixes as
"known failures" instead of "bugs requiring a fix" unless it aborts the
entire test suite too early. Add a note in the glibc page to note there
can be additional failures with Linux >= the version we use for LFS.
And there's also nothing to do with the "rolling release." For example,
you cannot build LFS 12.0 on LFS 12.4 because ch06 bash uses the host
compiler to build some code generators, and those generators are not
compatible with C23 (the default of GCC 15.2 shipped by LFS 12.4). LFS
12.4 is definitely not a rolling release...
A rolling release just catches the breakage earlier and we shouldn't
blame it to do so. IMO we should avoid the unfair accusion on rolling
distros as the same unfair accusion is often towards LFS (notably the
way we develop BLFS is very similar to a rolling release distro).
In the hostreqs page we already states building with a GCC newer than
the version specified for LFS in the book is "not tested and not
recommended." I don't know why people must ignore it (AFAIU "not
recommended" in LFS means "not supported; don't report any bug" already:
for example those "recommended" dependencies in BLFS). Make it more
explicit with assertive language and <warning>.
Twice in the past span of a year, Arch Linux has updates to new versions
of software rather quickly that causes LFS to be impossible without
modifications. The first instance was updating to GCC-15.1, of which
that disaster may be repeated with GCC-16.1. The second, most recent,
instance is that they updated to Linux-7. This changed behavior of
rseq, tables, and the ABI feature from 32 to 33, which messes with
Glibc, meaning users will need to use a host that has Linux <= 6.19.x
for now.
This distructive nature needs to be explained to the users to help to
prevent them from using broken hosts.
So many issues have popped up over on Discord and Reddit, and as an
aside and personal vent, I've been getting pretty tired of it each time
Arch pulls off something like this when it clearly isn't time yet.
The Gentoo GUI LiveCD (and Gentoo itself in general) is a good example
of how to treat the software set, and too not update too early.
Fix the explanation for CSM (here M stands for Module, not Mode).
Keep the terminology "BIOS" soly for "booting via MBR" and use
"firmware" instead for other purposes.
"UEFI bootloaders" normally stands for things like GRUB or systemd-boot,
instead of firmware. And it seems we are using "standard" location
instead of "hardcoded" location elsewhere.
- Use "firmware setup" instead of "BIOS": in the context of the grub
page "BIOS" almost always means "MBR boot," but here it means the
firmware setup interface.
- We may manipulate any EFI variable (unless the firmware makes it read
only) by directly writing the efivarfs, but GRUB needs efibootmgr.
- We don't necessarily install LFS into the same disk where ESP exists.
