Update to vim-9.1.1016.
Update to iana-etc-20250108.
Update to util-linux-2.40.4.
Update to sysvinit-3.13.
Update to sysklogd-2.7.0.
Update to shadow-4.17.2.
Update to setuptools-75.8.0.
Update to linux-6.12.9.
Update to gettext-0.23.1.
The host distro may have an insane default for root_owner and/or
root_perms in /etc/mke2fs.conf, so let's make it sane on our own. Note
that MKE2FS_CONFIG=/dev/null makes mke2fs refuse to run so we cannot
suppress the host mke2fs.conf.
I know some distros are using a different default and we are having
reports of some mysterious permission issue via lfs-support those I
highly suspect as some umask issue. Let's just explicitly set it (like
setting $LFS) to protect us from such distros without changing every
"mkdir -pv" to "install -vdm755".
The preceding commit uses <systemitem> elements to mark the lfs
user and group in commands. Unfortunately, this change the
rendering in html, because now lfs appears in an italic font.
Using <userinput remap='group'> or <userinput remap='user'> allows
parsing the XML for jhalfs, but does not change the html rendering.
I still think it's cleaner for jhalfs to just use a different user name
(for example "lfs1") if the user lfs already exists. This will allow
jhalfs to easily use a different user name.
Update to iana-etc-20241220.
Update to texinfo-7.2.
Update to sysvinit-3.12.
Update to shadow-4.17.0.
Update to procps-ng-4.0.5.
Update to meson-1.6.1.
Update to linux-6.12.7.
Update to kbd-2.7.1.
Update to jinja2-3.1.5.
This field was introduced with systemd-257. For development books, we'll
use "development" here, but when we do the next release we should change
this to say "stable".
This reverts commit 8f493a6377.
When I was building LFS, I somehow forgot to mount /dev/sdb7 to
/mnt/lfs on my system. I ended up chrooting into /mnt/lfs, and it was a
directory, not a filesystem.
This happens from time to time, not sure why I did it this time!
The tests that I had marked as failed no longer fail, but at the same
time, now test-namespace does. Let's undo this commit...
The upstream fix is explicitly checking libxml2 version so it's not
practical to be turned into a sed. But I don't want to upload another
patch just for such a "temporary" issue (as it'll be fixed for 0.23.1
anyway). This alternative fix relies on:
1. The fact that the return type of xmlCtxtGetLastError and the arg type
of xmlStructuredErrorFunc are changed in the same commit
61034116d0a3 ("error: Make more xmlError structs constant").
2. GCC supports typeof(expr) to get the type of expr w/o really
evaluating it.
So it should have the same effect as the upstream fix.
Tested with both --with-included-libxml2 and --without-included-libxml2
on BLFS.
The second expression
's/xmlError *err/const &/'
does nothing, because " *" actually matches zero, one, or several white
spaces, not a white space and an asterisk.
And the first expression
'/libxml\/xmlerror.h/i #include <libxml/xmlversion.h>'
includes a header, but we are not using anything in the header.
The intention of the sed command is fix a compatibility issue with
system libxml, but LFS does not have a system libxml so the fix is not
needed for LFS. And, if we just fix up the second expression to
's/xmlError \*err/const &/'
making it actually work, it'll cause a FTBFS with shipped libxml (used
in LFS because system does not have libxml), so we cannot easily fix it
either.
For now just remove the sed. If gettext-0.23.1 isn't released before
LFS 12.3 freeze, we can either apply the upstream patch to make it work
for both shipped libxml and system libxml, or add the corrected sed with
"nodump" and some alarming texts.
Update to vim-9.1.0927.
Update to iana-etc-20241206.
Update to systemd-257.
Update to Python-3.13.1.
Update to libcap-2.73.
Update to linux-6.12.5.
Update to kbd-2.7.
Update to gettext-0.23.
Besides Rainer's suggestion, also use a vague "not stored in the
repository" instead of the over-precise "generated": there are also
vendored external source copies (as Git submodules or manually embedded
during Release Engineering, for example the gnulib copies in many
GNU packages); and maybe other cases.
Suggested-by: Rainer Fiebig <jrf@mailbox.org>
Since the previous commit, we've ensured the kernel displaying via DRM
even in the early stage. Now enable DRM_PANIC so the kernel will
correctly show the last lines of the kernel messages in case a panic
happens.
Tested with an incorrect root= line in 3 configurations:
- A QEMU VM booted via BIOS
- A real machine booted via BIOS
- A real machine booted via UEFI
And in all configurations the panic message is correctly dumped.
In 1024x768 we can get 48 lines (twice of 24 lines in VGA console).
Currently on a LFS system booted via legacy BIOS (intead of UEFI), the
users can make two different configurations:
1. The DRM driver for the GPU is built as a module. Then before the
module is loaded (i.e. the root fs is properly mounted) the kernel
messages are displayed via the VGA console.
2. The DRM driver for the GPU is built into the kernel image. Then the
kernel messages are displayed via the DRM-emulated framebuffer
console since a very early stage (before the root fs is properly
mounted).
When the system is booted via UEFI, we use SimpleDRM on the EFI
framebuffer for displaying kernel messages, thus it's always the case 2.
Both are not good for diagnostic in case the root fs cannot be mounted
properly (it's very frequent on lfs-support):
- With 1 the VGA console can only fit 80x24 characters, so the relevent
information is often flushed away.
- With 2 the panic message is often displayed improperly when a DRM
driver is running.
The "DRM panic" feature introduced since Linux 6.11 (but it'll only
become usable for LFS since Linux 6.12) can fix the case 2, while case
1 just cannot be fixed. So start to make LFS booted via legacy BIOS
to use method 2 now, then we can enable DRM panic and fix this
long-standing issue.
Update to file-5.46.
Update to iproute2-6.12.0.
Update to libtool-2.5.4.
Update to linux-6.12.1.
Update to setuptools-75.6.0 (Python Module).
Update to wheel-0.45.1 (Python Module).
