Beyond Linux® From Scratch (systemd Edition)

Version 12.2

The BLFS Development Team

Copyright © 1999-2024, The BLFS Development Team

All rights reserved.

This book is licensed under a Creative Commons License.

Computer instructions may be extracted from the book under the MIT License.

Linux® is a registered trademark of Linus Torvalds.

Published 2024-04-01

Revision History
Revision 12.2 2024-09-01 Thirtieth Release
Revision 12.1 2024-03-01 Twenty-ninth Release
Revision 12.0 2023-09-01 Twenty-eighth Release
Revision 11.3 2023-03-01 Twenty-seventh Release
Revision 11.2 2022-09-01 Twenty-sixth Release
Revision 11.1 2022-03-01 Twenty-fifth Release
Revision 11.0 2021-09-01 Twenty-fourth Release
Revision 10.1 2021-03-01 Twenty-third Release
Revision 10.0 2020-09-01 Twenty-second Release
Revision 9.1 2020-03-01 Twenty-first Release
Revision 9.0 2019-09-01 Twentieth release
Revision 8.4 2019-03-01 Nineteenth release
Revision 8.3 2018-09-01 Eighteenth release
Revision 8.2 2018-03-02 Seventeenth release
Revision 8.1 2017-09-01 Sixteenth release
Revision 8.0 2017-02-25 Fifteenth release
Revision 7.10 2016-09-07 Fourteenth release
Revision 7.9 2016-03-08 Thirteenth release
Revision 7.8 2015-10-01 Twelfth release
Revision 7.7 2015-03-06 Eleventh release
Revision 7.6 2014-09-23 Tenth release
Revision 7.5 2014-03-05 Ninth release
Revision 7.4 2013-09-14 Eighth release
Revision 6.3 2008-08-24 Seventh release
Revision 6.2 2007-02-14 Sixth release
Revision 6.1 2005-08-14 Fifth release
Revision 6.0 2005-04-02 Fourth release
Revision 5.1 2004-06-05 Third release
Revision 5.0 2003-11-06 Second release
Revision 1.0 2003-04-25 First release

Abstract

This book follows on from the Linux From Scratch book. It introduces and guides the reader through additions to the system including networking, graphical interfaces, sound support, and printer and scanner support.


Dedication

This book is dedicated to the LFS community

Table of Contents

Preface

Having helped out with Linux From Scratch for a short time, I noticed that we were getting many queries as to how to do things beyond the base LFS system. At the time, the only assistance specifically offered relating to LFS were the LFS hints (https://www.linuxfromscratch.org/hints). Most of the LFS hints are extremely good and well written but I (and others) could still see a need for more comprehensive help to go Beyond LFS — hence BLFS.

BLFS aims to be more than the LFS-hints converted to XML although much of our work is based around the hints and indeed some authors write both hints and the relevant BLFS sections. We hope that we can provide you with enough information to not only manage to build your system up to what you want, whether it be a web server or a multimedia desktop system, but also that you will learn a lot about system configuration as you go.

Thanks as ever go to everyone in the LFS/BLFS community; especially those who have contributed instructions, written text, answered questions and generally shouted when things were wrong!

Finally, we encourage you to become involved in the community; ask questions on the mailing list or news gateway and join in the fun on #lfs and #lfs-support at Libera. You can find more details about all of these in the Introduction section of the book.

Enjoy using BLFS.

Mark Hymers
markh <at> linuxfromscratch.org
BLFS Editor (July 2001–March 2003)

I still remember how I found the BLFS project and started using the instructions that were completed at the time. I could not believe how wonderful it was to get an application up and running very quickly, with explanations as to why things were done a certain way. Unfortunately, for me, it wasn't long before I was opening applications that had nothing more than "To be done" on the page. I did what most would do, I waited for someone else to do it. It wasn't too long before I am looking through Bugzilla for something easy to do. As with any learning experience, the definition of what was easy kept changing.

We still encourage you to become involved as BLFS is never really finished. Contributing or just using, we hope you enjoy your BLFS experience.

Larry Lawrence
larry <at> linuxfromscratch.org
BLFS Editor (March 2003–June 2004)

The BLFS project is a natural progression of LFS. Together, these projects provide a unique resource for the Open Source Community. They take the mystery out of the process of building a complete, functional software system from the source code contributed by many talented individuals throughout the world. They truly allow users to implement the slogan Your distro, your rules.

Our goal is to continue to provide the best resource available that shows you how to integrate many significant Open Source applications. Since these applications are constantly updated and new applications are developed, this book will never be complete. Additionally, there is always room for improvement in explaining the nuances of how to install the different packages. To make these improvements, we need your feedback. I encourage you to participate on the different mailing lists, news groups, and IRC channels to help meet these goals.

Bruce Dubbs
bdubbs <at> linuxfromscratch.org
BLFS Editor (June 2004–December 2006 and February 2011–now)

My introduction to the [B]LFS project was actually by accident. I was trying to build a GNOME environment using some how-tos and other information I found on the web. A couple of times I ran into some build issues and Googling pulled up some old BLFS mailing list messages. Out for curiosity, I visited the Linux From Scratch web site and shortly thereafter was hooked. I've not used any other Linux distribution for personal use since.

I can't promise anyone will feel the sense of satisfaction I felt after building my first few systems using [B]LFS instructions, but I sincerely hope that your BLFS experience is as rewarding for you as it has been for me.

The BLFS project has grown significantly the last couple of years. There are more package instructions and related dependencies than ever before. The project requires your input for continued success. If you discover that you enjoy building BLFS, please consider helping out in any way you can. BLFS requires hundreds of hours of maintenance to keep it even semi-current. If you feel confident enough in your editing skills, please consider joining the BLFS team. Simply contributing to the mailing list discussions with sound advice and/or providing patches to the book's XML will probably result in you receiving an invitation to join the team.

Randy McMurchy
randy <at> linuxfromscratch.org
BLFS Editor (December 2006–January 2011)

Foreword

This version of the book is intended to be used when building on top of a system built using the LFS book. Every effort has been made to ensure accuracy and reliability of the instructions. Many people find that using the instructions in this book after building the current stable or development version of LFS provides a stable and very modern Linux system.

Enjoy!

Randy McMurchy
August 24th, 2008

Who Would Want to Read this Book

This book is mainly aimed at those who have built a system based on the LFS book. It will also be useful for those who are using other distributions, and for one reason or another want to manually build software and need some assistance. Note that the material in this book, in particular the dependency listings, assumes that you are using a basic LFS system with every package listed in the LFS book already installed and configured. BLFS can be used to create a range of diverse systems and so the target audience is probably as wide as that of the LFS book. If you found LFS useful, you should also like this!

Since Release 7.4, the BLFS book version has matched the LFS book version. This book may be incompatible with a previous or later release of the LFS book.

Organization

This book is divided into the following fourteen parts.

Part I - Introduction

This part contains essential information which is needed to understand the rest of the book.

Part II - Post LFS Configuration and Extra Software

Here we introduce basic configuration and security issues. We also discuss a range of text editors, file systems, and shells which aren't covered in the main LFS book.

Part III - General Libraries and Utilities

In this section we cover libraries which are often needed throughout the book, as well as system utilities. Information on programming (including recompiling GCC to support its full range of languages) concludes this part.

Part IV - Basic Networking

Here we explain how to connect to a network when you aren't using the simple static IP setup presented in the main LFS book. Networking libraries and command-line networking tools are also covered here.

Part V - Servers

Here we show you how to set up mail and other servers (such as FTP, Apache, etc.).

Part VI - X + Window Managers

This part explains how to set up a basic X Window System, along with some generic X libraries and Window managers.

Part VII - KDE

This part is for those who want to use the K Desktop Environment, or parts of it.

Part VIII - GNOME

GNOME is the main alternative to KDE in the Desktop Environment arena.

Part IX - Xfce

Xfce is a lightweight alternative to GNOME and KDE.

Part X - LXQt

LXDE is another lightweight alternative to GNOME and KDE.

Part XI - More X Software

Office programs and graphical web browsers are important to most people. They, and some generic X software, can be found in this part of the book.

Part XII - Multimedia

Here we cover multimedia libraries and drivers, along with some audio, video, and CD-writing programs.

Part XIII - Printing, Scanning and Typesetting (PST)

This part covers document handling, from applications like Ghostscript, CUPS, and DocBook, all the way to texlive.

Appendices

The Appendices present information which doesn't belong in the body of book; they are included as reference material. The glossary of acronyms is a handy feature.

Part I. Introduction

Chapter 1. Welcome to BLFS

The Beyond Linux From Scratch book is designed to carry on from where the LFS book leaves off. But unlike the LFS book, it isn't designed to be followed straight through. Reading the Which sections of the book? part of this chapter should help guide you through the book.

Please read most of this part of the book carefully as it explains quite a few of the conventions used throughout the book.

Which Sections of the Book Do I Want?

Unlike the Linux From Scratch book, BLFS isn't designed to be followed in a linear manner. LFS provides instructions on how to create a base system which can become anything from a web server to a multimedia desktop system. BLFS attempts to guide you in the process of going from the base system to your intended destination. Choice is very much involved.

Everyone who reads this book will want to read certain sections. The Introduction, which you are currently reading, contains generic information. Take special note of the information in Chapter 2, Important Information, as this contains comments about how to unpack software, issues related to the use of different locales, and various other considerations which apply throughout the book.

The part on Post LFS Configuration and Extra Software is where most people will want to turn next. This deals not only with configuration, but also with Security (Chapter 4, Security), File Systems (Chapter 5, File Systems and Disk Management -- including GRUB for UEFI), Text Editors (Chapter 6, Text Editors), and Shells (Chapter 7, Shells). Indeed, you may wish to reference some parts of this chapter (especially the sections on Text Editors and File Systems) while building your LFS system.

Following these basic items, most people will want to at least browse through the General Libraries and Utilities part of the book. This contains information on many items which are prerequisites for other sections of the book, as well as some items (such as Chapter 13, Programming) which are useful in their own right. You don't have to install all of the libraries and packages found in this part; each BLFS installation procedure tells you which other packages this one depends upon. You can choose the program you want to install, and see what it needs. (Don't forget to check for nested dependencies!)

Likewise, most people will probably want to look at the Networking section. It deals with connecting to the Internet or your LAN (Chapter 14, Connecting to a Network) using a variety of methods such as DHCP and PPP, and with items such as Networking Libraries (Chapter 17, Networking Libraries), plus various basic networking programs and utilities.

Once you have dealt with these basics, you may wish to configure more advanced network services. These are dealt with in the Servers part of the book. Those wanting to build servers should find a good starting point there. Note that this section also contains information on several database packages.

The next twelve chapters deal with desktop systems. This portion of the book starts with a part talking about Graphical Components. This part also deals with some generic X-based libraries (Chapter 25, Graphical Environment Libraries). After that, KDE, GNOME, Xfce, and LXQt are given their own parts, followed by one on X Software.

The book then moves on to deal with Multimedia packages. Note that many people may want to use the ALSA instructions from this chapter when first starting their BLFS journey; the instructions are placed here because it is the most logical place for them.

The final part of the main BLFS book deals with Printing, Scanning and Typesetting. This is useful for most people with desktop systems, but even those who are creating dedicated server systems may find it useful.

We hope you enjoy using BLFS. May you realize your dream of building the perfectly personalized Linux system!

Conventions Used in this Book

Typographical Conventions

To make things easy to follow, a number of conventions are used throughout the book. Here are some examples:

./configure --prefix=/usr

This form of text should be typed exactly as shown unless otherwise noted in the surrounding text. It is also used to identify references to specific commands.

install-info: unknown option
`--dir-file=/mnt/lfs/usr/info/dir'

This form of text (fixed width font) shows screen output, probably the result of issuing a command. It is also used to show filenames such as /boot/grub/grub.conf

Note

Please configure your browser to display fixed-width text with a good monospaced font, with which you can distinguish the glyphs of Il1 or O0 clearly.

Emphasis

This form of text is used for several purposes, but mainly to emphasize important points, or to give examples of what to type.

https://www.linuxfromscratch.org/

This form of text is used for hypertext links external to the book, such as HowTos, download locations, websites, etc.

seamonkey-2.53.18.2

This form of text is used for links internal to the book, such as another section describing a different package.

cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF

This style is mainly used when creating configuration files. The first command (in bold) tells the system to create the file $LFS/etc/group from whatever is typed on the following lines, until the sequence EOF is encountered. Therefore, this whole section is usually typed exactly as shown. Remember, copy and paste is your friend!

<REPLACED TEXT>

This form of text is used to encapsulate text that should be modified, and is not to be typed as shown, or copied and pasted. The angle brackets are not part of the literal text; they are part of the substitution.

root

This form of text is used to show a specific system user or group reference in the instructions.

 

Conventions Used for Package Dependencies

When new packages are created, the software's authors depend on prior work. In order to build a package in BLFS, these dependencies must be built before the desired package can be compiled. For each package, prerequisites are listed in one or more separate sections: Required, Recommended, and Optional.

Required Dependencies

These dependencies are the bare minimum needed to build the package. Packages in LFS, and the required dependencies of these required packages, are omitted from this list. Always remember to check for nested dependencies. If a dependency is said to be runtime, it is not needed for building the package, but only to use it after installation.

Recommended Dependencies

These are dependencies the BLFS editors have determined are important to give the package reasonable capabilities. If a recommended dependency is not said to be runtime, package installation instructions assume it is installed. If it is not installed, the instructions may require modification, to accommodate the missing package. A recommended runtime dependency does not need to be installed before building the package, but must be built afterwards for running the package with reasonable capabilities.

Optional Dependencies

These are dependencies the package may use. Integration of optional dependencies may be automatic by the package, or additional steps not presented by BLFS may be necessary. Optional dependencies are sometimes listed without explicit BLFS instructions. In this case you must determine how to perform the installation yourself.

 

Conventions Used for Kernel Configuration Options

Some packages require specific kernel configuration options. The general layout for these looks like this:

Master section --->
  Subsection --->
    [*]     Required parameter                                        [REQU_PAR]
    <*>     Required parameter (not as module)                   [REQU_PAR_NMOD]
    <*/M>   Required parameter (could be a module)                [REQU_PAR_MOD]
    <M>     Required parameter (as a module)                 [REQU_PAR_MOD_ONLY]
    < /*/M> Optional parameter                                         [OPT_PAR]
    < /M>   Optional parameter (as a module if enabled)       [OPT_PAR_MOD_ONLY]
    [ ]     Incompatible parameter                                  [INCOMP_PAR]
    < >     Incompatible parameter (even as module)             [INCOMP_PAR_MOD]

[...] on the right gives the symbolic name of the option, so you can easily check whether it is set in your .config file. Note that the .config file contains a CONFIG_ prefix before all symbolic names. The meaning of the various entries is:

Master section top level menu item
Subsection submenu item
Required parameter the option can either be built-in, or not selected: it must be selected
Required parameter (not as module) the option can be built-in, a module, or not selected (tri-state): it must be selected as built-in
Required parameter (could be a module) the option can be built-in, a module, or not selected: it must be selected, either as built-in or as a module
Required parameter (as a module) the option can be built-in, a module, or not selected: it must be selected as a module; selecting it as built-in may cause unwanted effects
Optional parameter the option can be built-in, a module, or not selected: it may be selected as a module or built-in if you need it for driving the hardware or optional kernel features
Optional parameter (as a module if enabled) the option can be built-in, a module, or not selected: it may be selected as a module if you need it for driving the hardware or optional kernel features, but selecting it as built-in may cause unwanted effects
Incompatible parameter the option can either be built-in or not selected: it must not be selected
Incompatible parameter (even as module) the option can be built-in, a module, or not selected: it must not be selected

Note that, depending on other selections, the angle brackets (<>) in the configuration menu may appear as braces ({}) if the option cannot be unselected, or even as dashes (-*- or -M-), when the choice is imposed. The help text describing the option specifies the other selections on which this option relies, and how those other selections are set.

The letter in blue is the hotkey for this option. If you are running make menuconfig, you can press a key to quickly traverse all the options with this key as the hotkey on the screen.

 

SBU values in BLFS

As in LFS, each package in BLFS has a build time listed in Standard Build Units (SBUs). These times are relative to the time it took to build binutils in LFS, and are intended to provide some insight into how long it will take to build a package. Most times listed are for a single processor or core to build the package. In some cases, large, long running builds tested on multi-core systems have SBU times listed with comments such as '(parallelism=4)'. These values indicate testing was done using multiple cores. Note that while this speeds up the build on systems with the appropriate hardware, the speedup is not linear and to some extent depends on the individual package and the specific hardware used.

For packages which use ninja (i.e., anything using meson) or rust, by default all cores are used; similar comments will be seen on such packages even when the build time is minimal.

Where even a parallel build takes more than 15 SBU, on certain machines the time may be considerably greater even when the build does not use swap. In particular, different micro-architectures will build some files at different relative speeds, and this can introduce delays when certain make targets wait for another file to be created. Where a large build uses a lot of C++ files, processors with Simultaneous Multi Threading will share the Floating Point Unit and can take 45% longer than when using four 'prime' cores (measured on an intel i7 using taskset and keeping the other cores idle).

Some packages do not support parallel builds; for these, the make command must specify -j1. Packages that are known to impose such limits are so marked in the text.

Book Version

This is BLFS-BOOK version 12.2 dated September 1st, 2024. This is the 12.2-systemd branch of the BLFS book, currently targeting the LFS 12.2-systemd book. For development versions, if this version is older than a month, it's likely that your mirror hasn't been synchronized recently and a newer version is probably available for download or viewing. Check one of the mirror sites at https://www.linuxfromscratch.org/mirrors.html for an updated version.

Mirror Sites

The BLFS project has a number of mirrors set up world-wide to make it easier and more convenient for you to access the website. Please visit the https://www.linuxfromscratch.org/mirrors.html website for the list of current mirrors.

Getting the Source Packages

Within the BLFS instructions, each package has two references for finding the source files for the package—an HTTP link and an FTP link (some packages may only list one of these links). Every effort has been made to ensure that these links are accurate. However, the World Wide Web is in continuous flux. Packages are sometimes moved or updated and the exact URL specified is not always available.

To overcome this problem, the BLFS Team, with the assistance of Oregon State University Open Source Lab, has made an HTTP/FTP site available through world wide mirrors. See https://www.linuxfromscratch.org/blfs/download.html#sources for a list. These sites have all the sources of the exact versions of the packages used in BLFS. If you can't find the BLFS package you need at the listed addresses, get it from these sites.

We would like to ask a favor, however. Although this is a public resource for you to use, please do not abuse it. We have already had one unthinking individual download over 3 GB of data, including multiple copies of the same files that are placed at different locations (via symlinks) to make finding the right package easier. This person clearly did not know what files he needed and downloaded everything. The best place to download files is the site or sites set up by the source code developer. Please try there first.

Change Log

Current release: 12.2 – September 1st, 2024

Changelog Entries:

  • September 1st, 2024

    • [bdubbs] - Release of BLFS-12.2.

  • August 30th, 2024

    • [renodr] - Update to libreoffice-24.8.0.3. Fixes #20263.

  • August 27th, 2024

    • [renodr] - Fix building Brasero with GCC-14. Fixes #20278.

    • [renodr] - Restore libgedit-gtksourceview as it's needed by gedit.

    • [renodr] - Update to pipewire-1.2.3. Fixes #20264.

    • [bdubbs] - Update to kde-gear-24.08.0. Includes falkon, kate, and k3b. Fixes 19954.

    • [renodr] - Update to gnome-desktop-44.1. Fixes #20255.

  • August 26th, 2024

    • [bdubbs] - Archive libquicktime and transcode.

    • [bdubbs] - Update to mlt-7.26.0. Fixes 20272.

  • August 25th, 2024

    • [bdubbs] - Update to mc-4.8.32. Fixes 20267.

    • [bdubbs] - Update to Vulkan-Headers 1.3.294 and Vulkan-Loader-1.3.294. Fixes 20269.

  • August 23th, 2024

    • [bdubbs] - Update to libbytesize-2.11. Fixes 20252.

    • [bdubbs] - Update to LVM2-2.03.26. Fixes 20266.

  • August 23rd, 2024

    • [bdubbs] - Update to gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-bad, gst-plugins-ugly, and gst-libav versions 1.24.7. Fixes 20256.

    • [renodr] - Fix building ghostscript with GCC-14. Fixes #20265.

  • August 21st, 2024

    • [renodr] - Update to numpy-2.1.0. Fixes 20247.

    • [renodr] - Fix building Subversion with GCC 14. Fixes #20257.

    • [bdubbs] - Update to Net-DNS-1.46 (Perl module). Fixes #20253.

  • August 20th, 2024

    • [renodr] - Fix three security vulnerabilities in p7zip. Fixes #20251.

  • August 19th, 2024

    • [xry111] - Disable buggy expat support in libarchive-3.7.4. Fixes #20249.

    • [xry111] - Patch libxml2-2.13.3 to fix an issue causing bogus warning with xmlcatalog --create. Fixes #20248.

  • August 18th, 2024

    • [renodr] - Update to dtc-1.7.1. Fixes #20245.

    • [renodr] - Update to pax-20240817. Fixes #20244.

    • [renodr] - Update to vulkan-headers and vulkan-loader 1.3.293. Fixes #20242.

    • [renodr] - Update to gtk-4.14.5. Fixes #20243.

    • [renodr] - Fix a segmentation fault in Libreoffice caused by the Boost patch. Fixes #20229.

  • August 17th, 2024

    • [bdubbs] - Update to librsvg-2.58.3. Fixes #20240.

    • [xry111] - Update to rust-bindgen-0.70.0. Fixes #20241.

  • August 16th, 2024

    • [renodr] - Fix a regression in WebKitGTK that causes crashes when rendering some websites. Fixes #20235.

    • [renodr] - Update to asymptote-2.91. Fixes #20239.

    • [renodr] - Update cups-browsed and cups-filters to 2.0.1. Fixes #20233.

    • [renodr] - Update to dovecot-2.3.17.1 (Security Update). Fixes #20231.

    • [renodr] - Update to enchant-2.8.2. Fixes #20230.

    • [renodr] - Fix building Libreoffice with boost-1.86.0.

    • [renodr] - Update to boost-1.86.0. Fixes #20229.

    • [bdubbs] - Update to unbound-1.21.0. Fixes #20238.

    • [bdubbs] - Update to btrfs-progs-6.10.1. Fixes #20237.

    • [bdubbs] - Update to gnutls-3.8.7.1. Fixes #20236.

  • August 15th, 2024

    • [renodr] - Update to sentry_sdk-2.13.0 (Python Module). Fixes #20062.

    • [renodr] - Update to x265-3.6. Fixes #20234.

    • [bdubbs] - Update to xfce4-notifyd-0.9.6. Fixes #20227.

    • [bdubbs] - Update to sqlite-autoconf-3460100. Fixes #20226.

    • [bdubbs] - Update to freetype-2.13.3. Fixes #20223.

    • [bdubbs] - Update to python3-3.12.5. Fixes #20202.

  • August 12th, 2024

    • [renodr] - Update to WebKitGTK-2.44.3. Fixes #20225.

    • [thomas] - Update to xfburn-0.7.2. Fixes #20224.

  • August 12th, 2024

    • [renodr] - Update to x265-20240812. Fixes #20221.

    • [renodr] - Update to x264-20240812. Fixes #20221.

    • [renodr] - Update to ImageMagick-7.1.1-36. Fixes #20222.

    • [renodr] - Update python module dependencies for BLFS 12.2. This includes alabaster-1.0.0, attrs-24.2.0, babel-2.16.0, certifi-2024.7.4, chardet-5.2.0, charset-normalizer-3.3.2, idna-3.7, markdown-3.6, msgpack-1.0.8, sphinxcontrib-devhelp-2.0.0, sphinxcontrib-qthelp-2.0.0, sphinxcontrib-serializinghtml-2.0.0, and urllib3-2.2.2. Note that urllib3 and idna are security updates. Fixes #20220.

    • [renodr] - Update perl module dependencies for BLFS 12.2. This includes Alien-Build-2.83, Business-ISBN-Data-20240807.001, DateTime-Locale-1.43, HTTP-Message-6.46, Path-Tiny-0.146, Term-Table-0.022, Test-Without-Module-0.23, Test2-Plugin-NoWarnings-0.10, and Text-CSV_XS-1.56. Fixes #20219.

    • [renodr] - Replace Test2-Suite with Test-Simple. Fixes #20219.

    • [renodr] - Update to lxml-5.3.0 (Python Module). Fixes #20215.

    • [renodr] - Update to NetworkManager-1.48.8. Fixes #20212.

    • [renodr] - Update to sentry_sdk-2.12.0 (Python Module). Fixes #20062.

    • [bdubbs] - Update to vim-9.1.0660 (sync with LFS). Addresses #12241.

    • [bdubbs] - Update to highlight-4.13. Fixes #20218.

    • [bdubbs] - Update to graphviz-12.1.0. Fixes #20217.

    • [xry111] - Update to cbindgen-0.27.0. Fixes #20214.

    • [thomas] - Update to vte-0.76.4. Fixes #20213.

  • August 11th, 2024

    • [bdubbs] - Update to kwayland, libkscreen, and layer-shell-qt 6.1.4 (for lxqt). Fixes #19973.

    • [bdubbs] - Update to kconfig, kidletime, kwindowsystem, and solid 6.5.0 (for lxqt). Fixes #19922.

    • [bdubbs] - Update to plasma-6.1.4. Fixes #19973.

    • [bdubbs] - Add new package pulseaudio-qt-1.5.0 in support of the plasma-pa-6.1.4 package in the plasma-6.1.4 suite.

    • [rahul] - Update to protobuf-27.3. Fixes #20163.

    • [rahul] - Update to pipewire-1.2.2. Fixes #20165.

    • [bdubbs] - Update to kirigami-addons-1.4.0. Fixes #20131.

    • [bdubbs] - Update to kf6-6.5.0. Includes extra-cmake-modules, and breeze-icons. Fixes #19921.

  • August 9th, 2024

    • [renodr] - Update to FreeRDP-3.7.0. Fixes #20211.

    • [renodr] - Update to postgresql-16.4 (Security Update). Fixes #20210.

    • [renodr] - Update to Regexp-Common-2024080801 (Perl Module). Fixes #20208.

    • [xry111] - Update to polkit-125. Fixes #20207.

    • [xry111] - Update to rustc-1.80.1. Fixes #20209.

  • August 8th, 2024

    • [bdubbs] - Update to mpg123-1.32.7. Fixes #20205.

    • [bdubbs] - Update to xwayland-24.1.2. Fixes #20203.

    • [bdubbs] - Update to libei-1.3.0. Fixes #20204.

    • [bdubbs] - Update to doxygen-1.12.0. Fixes #20201.

  • August 7th, 2024

    • [renodr] - Update to gnome-online-accounts-3.50.4. Fixes #20200.

    • [renodr] - Update evolution and evolution-data-server to 3.52.4. Fixes #20199.

    • [renodr] - Update to samba-4.20.4. Fixes #20196.

    • [renodr] - Update to gnome-control-center-46.4. Fixes #20193.

    • [renodr] - Update to pavucontrol-6.1. Fixes #20185.

    • [renodr] - Update to thunderbird-128.1.0esr (Security Update). Fixes #20153.

    • [renodr] - Update to firefox-128.1.0esr (Security Update). Fixes #20194.

    • [renodr] - Update to spidermonkey-115.14.0 (Security Update). Fixes #20195.

  • August 6th, 2024

    • [bdubbs] - Update to pyyaml-6.0.2. Fixes #20198.

    • [bdubbs] - Update to hwdata-0.385. Fixes #20197.

    • [rahul] - Update to nss-3.103. Fixes #20167.

    • [bdubbs] - Update to cython-3.0.11. Fixes #20192.

  • August 5th, 2024

    • [renodr] - Update to gnome-user-docs-46.4. Fixes #20191.

    • [renodr] - Update to mutter-46.4. Fixes #20189.

    • [renodr] - Update to gnome-shell-46.4. Fixes #20188.

    • [renodr] - Update to ffmpeg-7.0.2. Fixes #20184.

    • [renodr] - Update to epiphany-46.3. Fixes #20183.

    • [renodr] - Update to gnome-bluetooth-46.1. Fixes #20182.

    • [renodr] - Update to cmake-3.30.2. Fixes #20180.

  • August 4th, 2024

    • [bdubbs] - Update to sysmon-qt-2.0.1.

    • [bdubbs] - Update to cracklib-2.10.2. Fixes #20187.

  • August 3rd, 2024

    • [bdubbs] - Update to SDL2-2.30.6. Fixes #20186.

    • [bdubbs] - Update to libadwaita-1.5.3. Fixes #20181.

    • [bdubbs] - Update to libnvme-1.10. Fixes #20179.

    • [bdubbs] - Update to Vulkan-Headers 1.3.292 and Vulkan-Loader-1.3.292. Fixes #20114.

  • August 2nd, 2024

    • [renodr] - Update to c-ares-1.33.0. Fixes #20178.

    • [renodr] - Update to samba-4.20.3. Fixes #20177.

    • [renodr] - Update to lcms2-2.16. Fixes #20175.

    • [renodr] - Update to eog-45.4. Fixes #20173.

    • [renodr] - Update to libshumate-1.2.3. Fixes #20173.

    • [bdubbs] - Update to libFS-1.0.10, libXfont2-2.0.7, and libXtst-1.2.5 (Xorg libraries). Fixes #20172.

    • [bdubbs] - Update to poppler-24.08.0. Fixes #20169.

    • [bdubbs] - Update to gcc-14.2.0. Fixes #20166.

    • [renodr] - Update to php-8.3.10. Fixes #20171.

    • [renodr] - Update to mercurial-6.8.1. Fixes #20170.

    • [renodr] - Update to abseil-cpp-20240722.0. Fixes #20168.

  • August 1st, 2024

    • [bdubbs] - Update to btrfs-progs-v6.10. Fixes #20155.

    • [bdubbs] - Update to sphinx-8.0.2. Also updated to sphinxcontrib-applehelp-2.0.0. Fixes #20117.

    • [bdubbs] - Update to gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-bad, gst-plugins-ugly, and gst-libav versions 1.24.6. Fixes #19984.

    • [thomas] - Update to ISC Kea-dhcpd-2.6.1. Fixes #20164.

    • [renodr] - Update to SPIRV-LLVM-Translator-18.1.3. Fixes #20162.

  • July 31st, 2024

    • [renodr] - Update to mesa-24.1.5. Fixes #20159.

    • [renodr] - Update to HTML-Parser-3.83 (Perl Module). Fixes #20157.

    • [renodr] - Update to libavif-1.1.1. Fixes #20156.

    • [renodr] - Update to cryptsetup-2.7.4. Fixes #20154.

    • [renodr] - Update to curl-8.9.1 (Security Update). Fixes #20160.

    • [thomas] - Update to thunar-4.18.11. Fixes #20158.

    • [renodr] - Update to systemd-256.4 (sync with LFS). Fixes #20084.

  • July 30th, 2024

    • [bdubbs] - Update to git-2.46.0. Fixes #20152.

  • July 29th, 2024

    • [bdubbs] - Update to links-2.30. Fixes #20150.

    • [bdubbs] - Update to libX11-1.8.10 (Xorg library). Fixes #20151.

  • July 27th, 2024

    • [bdubbs] - Update to rpcbind-1.2.7. Fixes #20145.

    • [xry111] - Update to rustc-1.80.0. Fixes #20145.

  • July 26th, 2024

    • [bdubbs] - Update to cracklib-2.10.1. Fixes #20143.

    • [renodr] - Update to pangomm-2.54.0. Fixes #20147.

    • [renodr] - Update to NetworkManager-1.48.6. Fixes #20146.

    • [renodr] - Update to pytest-8.3.2 (Python Modules). Fixes #20144.

  • July 25th, 2024

    • [bdubbs] - Update to tigervnc-1.14.0. Fixes #20140.

    • [bdubbs] - Update to mupdf-1.24.8. Fixes #20142.

    • [bdubbs] - Update to nss-3.102.1. Fixes #20135.

    • [thomas] - Update to c-ares-1.32.3. Fixes #20136.

    • [renodr] - Update to dvisvgm-3.4. Fixes #20141.

    • [renodr] - Update to libtirpc-1.3.5. Fixes #20139.

    • [renodr] - Update to libxml2-2.13.3 (Security Update). Fixes #20136.

    • [renodr] - Update to node.js-20.16.0. Fixes #20137.

    • [renodr] - Update to OpenJDK-22.0.2 (Security Update). Fixes #20101.

  • July 24th, 2024

    • [bdubbs] - Update to v4l-utils-1.28.1. Fixes #20133.

    • [renodr] - Update to curl-8.9.0 (Security Update). Fixes #20134.

    • [renodr] - Update to BIND-9.20.0. Fixes #20132.

  • July 23rd, 2024

    • [thomas] - Update to xfs-progs-6.9.0. Fixes #20127.

    • [renodr] - Update to BIND-9.18.28 (Security Update). Fixes #20130.

    • [renodr] - Update to evince-46.3.1. Fixes #20129.

    • [renodr] - Update to SPIRV-Headers and SPIRV-Tools 1.3.290. Fixes #20128.

  • July 22nd, 2024

    • [renodr] - Update to fetchmail-6.4.39. Fixes #20119.

    • [renodr] - Fix CVE-2023-43361 in vorbis-tools (Security Update). Fixes #20125.

    • [renodr] - Fix building compface with GCC 14. Fixes #20126.

    • [renodr] - Adapt QtWebEngine to use system ffmpeg. Fixes #20102.

    • [bdubbs] - Update to intel-media-24.2.5/intel-gmmlib-22.4.1. Fixes #20124.

    • [bdubbs] - Update to numpy-2.0.1 (Python module). Fixes #20123.

  • July 21st, 2024

    • [bdubbs] - Update to libcdio-paranoia-10.2+2.0.2 (Part of libcdio). Fixes #20121.

    • [bdubbs] - Update to ldns-1.8.4. Fixes #20120.

    • [bdubbs] - Update to wpa_supplicant-2.11. Fixes #20118.

    • [bdubbs] - Update to fmt-11.0.2. Fixes #20115.

    • [bdubbs] - Update to pytest-8.3.1 (Python module). Fixes #20116.

  • July 20th, 2024

    • [bdubbs] - Update to mupdf-1.24.7. Fixes #20113.

    • [bdubbs] - Update to v4l-utils-1.28.0. Fixes #20112.

    • [bdubbs] - Update to libnl-3.10.0. Fixes #20110.

    • [bdubbs] - Update to sphinx-7.4.6 (Python module). Fixes #20109.

  • July 18th, 2024

    • [bdubbs] - Update to qt-5.15.14 (components). Fixes #19442.

    • [renodr] - Update to exiv2-0.28.3 (Security Update). Fixes #20105.

    • [bdubbs] - Update to xapian-core-1.4.26. Fixes #20108.

  • July 18th, 2024

    • [bdubbs] - Update to httpd-2.4.62 (Security Update). Fixes #20103.

    • [bdubbs] - Update to cmake-3.30.1. Fixes #20106.

    • [bdubbs] - Update to mesa-24.1.4. Fixes #20104.

    • [bdubbs] - Archive gtk2. Fixes #18531. Also archive pygtk, mplayer, gtk-engines, hexchat, and pidgin.

    • [bdubbs] - Archive python2. Fixes #11549.

    • [bdubbs] - Update to gimp-20240711 (gimp-3.0 snapshot). Fixes #19886.

  • July 17th, 2024

    • [bdubbs] - Update to qemu-9.0.2. Fixes #20098.

    • [bdubbs] - Update to sphinx-7.4.5 (Python module). Fixes #20100.

    • [bdubbs] - Update to asciidoc-10.2.1 (Python module). Fixes #20099.

    • [renodr] - Archive libgrss.

    • [bdubbs] - Archive vsftpd.

  • July 16th, 2024

    • [renodr] - Update to gsettings-desktop-schemas-46.1. Fixes #20097.

    • [renodr] - Update to python-dbusmock-0.32.1 (Python Module). Fixes #20093.

    • [renodr] - Update to gnome-keyring-46.2. Fixes #20085.

    • [renodr] - Update to gvfs-1.54.2. Fixes #20075.

    • [renodr] - Update to gnome-online-accounts-3.50.3. Fixes #20074.

    • [xry111] - Update to hatchling-1.25.0 (Python dependency). Addresses #18562.

    • [xry111] - Update to trove_classifiers-2024.7.2 (Python dependency). Addresses #18562.

    • [renodr] - Update to evolution-3.52.3. Fixes #20073.

    • [renodr] - Update to evolution-data-server-3.52.3. Fixes #20073.

    • [renodr] - Update to gnome-control-center-46.3. Fixes #20036.

    • [renodr] - Update to epiphany-46.2. Fixes #20024.

    • [renodr] - Update to mutter-46.3.1. Fixes #20023.

    • [renodr] - Update to gnome-shell-46.3.1. Fixes #20022.

    • [renodr] - Update to gexiv2-0.14.3. Fixes #20017.

    • [renodr] - Update to mercurial-6.8. Fixes #20060.

    • [renodr] - Archive telepathy-glib because nothing uses it anymore.

    • [renodr] - Add gnome-connections to the book. Fixes #19960.

    • [renodr] - Archive Vinagre. This is a part of #19960.

    • [renodr] - Add FreeRDP to the book in support of gnome-connections. This is a part of #19960.

    • [renodr] - Update to Thunderbird-128.0esr (Security Update). Fixes #19717.

    • [xry111] - Archive typing_extensions (Python dependency).

    • [xry111] - Update to setuptools_scm-8.1.0 (Python dependency). Addresses #18562.

    • [bdubbs] - Update to c-ares-1.32.2. Fixes #20096.

    • [bdubbs] - Update to sphinx-7.4.4 (Python module). Fixes #20095.

    • [bdubbs] - Update to babel-2.15.0 (Python module). Needed by sphinx-7.4.4.

  • July 15th, 2024

    • [bdubbs] - Update to xfburn-0.7.1. Fixes #20094.

    • [bdubbs] - Update to IO-Socket-SSL-2.088 (Perl Module). Fixes #20092.

  • July 14th, 2024

    • [bdubbs] - Add konversation to the kf6 applications in the book.

    • [rahul] - Update to nodejs-20.15.1. Fixes #19983.

    • [rahul] - Update to bluez-5.77. Fixes #20058.

    • [rahul] - Update to nss-3.102. Fixes #20012.

    • [bdubbs] - Update to SDL2-2.30.5. Fixes #20091.

    • [bdubbs] - Update to make-ca-1.14. Fixes #20090.

    • [bdubbs] - Update to cracklib-2.10.0. Fixes #20089.

    • [bdubbs] - Update to Vulkan-Headers and Vulkan-Loader 1.3.290. Fixes #20087.

    • [bdubbs] - Update to imlib2-1.12.3. Fixes #20088.

  • July 13th, 2024

    • [bdubbs] - Update to libreoffice-24.2.5.2. Fixes #20078.

    • [bdubbs] - Update to pipewire-1.2.1. Fixes #20086.

    • [bdubbs] - Update to librsvg-2.58.2. Fixes #20083.

    • [bdubbs] - Update to LVM2.2.03.25. Fixes #20082.

    • [bdubbs] - Update to libavif-1.1.0. Fixes #20080.

    • [bdubbs] - Update to gdb-15.1. Fixes #20054.

  • July 12th, 2024

    • [bdubbs] - Update to mupdf-1.24.6. Fixes #20069.

    • [bdubbs] - Update to xwayland-24.1.1. Fixes #20067.

    • [bdubbs] - Update to wireshark-4.2.6. Fixes #20065.

    • [bdubbs] - Update to c-ares-1.32.1. Fixes #20064.

    • [bdubbs] - Update to unix-tree-2.1.3. Fixes #20063.

    • [renodr] - Update to firefox-128.0esr (Security Update). Fixes #20056.

    • [renodr] - Update to mozjs-115.13.0. Fixes #20076.

    • [renodr] - Update to gtk+-3.24.43 (Security Update). Fixes #20068.

    • [renodr] - Update to ruby-3.3.4. Fixes #20061.

    • [renodr] - Update to NetworkManager-1.48.4. Fixes #20052.

    • [renodr] - Fix building libgsf with libxml2-2.13. Fixes #20071.

    • [renodr] - Update to asymptote-2.90. Fixes #19989.

    • [renodr] - Update to libwacom-2.12.2. Fixes #19987.

    • [renodr] - Update to systemd-256.1. Fixes #19967.

    • [ken] - Patch gimp-2.10.38 to build with gcc14. Fixes 19886.

    • [thomas] - Upgrade to nano-8.1. Fixes 20081.

    • [thomas] - Upgrade to xterm-393. Fixes 20079.

    • [ken] - Patch gtk+-2.24.33 to build with gcc14.. Fixes 19887.

  • July 11th, 2024

    • [timtas] - Update to exim-4.98. Fixes #20066.

    • [bdubbs] - Update to IO-Socket-SSL-2.087 (Perl Module). Fixes #20059.

    • [bdubbs] - Update to glib-2.80.4. Fixes #20057.

    • [bdubbs] - Update to SCons-4.8.0. Fixes #20055.

  • July 8th, 2024

    • [rahul] - Update to mesa-24.1.3. Fixes #20041.

    • [rahul] - Update to php-8.3.9. Fixes #20049.

    • [rahul] - Update to libxslt-1.1.42. Fixes #20046.

    • [rahul] - Update to graphviz-12.0.0. Fixes #20047.

    • [rahul] - Update to p11-kit-0.25.5. Fixes #20044.

    • [rahul] - Update to libxml2-2.13.2. Fixes #20045.

    • [rahul] - Update to gnutls-3.8.6. Fixes #20038.

    • [rahul] - Update to c-ares-1.32.0. Fixes #20050.

  • July 6th, 2024

    • [bdubbs] - Update to sentry_sdk-2.7.1. Fixes #19910.

    • [bdubbs] - Update to fmt-11.0.1. Fixes #20053.

  • July 5th, 2024

    • [bdubbs] - Update to hwdata-0.384. Fixes #20048.

    • [bdubbs] - Update to IO-Socket-SSL-2.086 (Perl Module). Fixes #20042.

    • [bdubbs] - Update to sysstat-12.7.6. Fixes #20040.

    • [bdubbs] - Update to pinentry-1.3.1. Fixes #20039.

  • July 4th, 2024

    • [timtas] - Update to httpd-2.4.61 (Security Update). Fixes #20031.

  • July 3rd, 2024

    • [bdubbs] - Update to libass-0.17.3. Fixes #20037.

    • [bdubbs] - Update to libva-2.22.0. Fixes #20034.

    • [bdubbs] - Update to libplacebo-7.349.0 (note unusual version number change). Fixes #20033.

    • [bdubbs] - Update to p11-kit-0.25.4. Fixes #20032.

    • [bdubbs] - Update to unix-tree-2.1.2. Fixes #20030.

    • [bdubbs] - Update to libqalculate-5.2.0. Fixes #20029.

    • [bdubbs] - Update to fmt-11.0.0. Fixes #20028.

  • July 1st, 2024

    • [bdubbs] - Update to poppler-24.07.0. Fixes #19947.

    • [bdubbs] - Update to SPIRV-LLVM-Translator-18.1.2. Fixes #20025.

    • [bdubbs] - Update to openssh-9.8p1 (Security Update). Fixes #20027.

    • [bdubbs] - Update to feh-3.10.3. Fixes #20026.

    • [bdubbs] - Update to shadow-4.16.0. Fixes #19965.

  • June 29th, 2024

    • [bdubbs] - Update to highlight-4.12. Fixes #20021.

    • [rahul] - Update to wireplumber-0.5.5. Fixes #20020.

    • [bdubbs] - Update to libadwaita-1.5.2. Fixes #20015.

    • [bdubbs] - Update to Vulkan-Headers and Vulkan-Loader 1.3.289. Fixes #20014.

    • [bdubbs] - Update to libndp-1.9. Fixes #20013.

  • June 28th, 2024

    • [bdubbs] - Update to qtermwidget and qterminal-2.0.1. Fixes #20007.

    • [bdubbs] - Update to libjxl-0.10.3. Fixes #20010.

    • [bdubbs] - Update to libinput-1.26.1 (Xorg input driver). Fixes #20009.

    • [bdubbs] - Update to mupdf-1.24.5. Fixes #20008.

    • [bdubbs] - Update to harfbuzz-9.0.0. Fixes #20011.

  • June 27th, 2024

    • [rahul] - Update to wireplumber-0.5.4. Fixes #20004.

    • [rahul] - Update to pipewire-1.2.0. Fixes #20005.

    • [bdubbs] - Update to kirigami-addons-1.3.0. Fixes #20002.

    • [bdubbs] - Update to btrfs-progs-v6.9.2. Fixes #20001.

    • [bdubbs] - Update to xmlto-0.0.29. Fixes #20006.

    • [bdubbs] - Update to krb5-1.21.3 (Security Update). Fixes #20000.

    • [bdubbs] - Update to libdrm-2.4.122. Fixes #20003.

    • [bdubbs] - Update to glslang-14.3.0. Fixes #19999.

    • [bdubbs] - Update to lua-5.4.7. Fixes #19998.

    • [bdubbs] - Update to protobuf-27.2. Fixes #19997.

  • June 25th, 2024

    • [bdubbs] - Update to qca-2.3.9. Fixes #19996.

    • [bdubbs] - Update to NetworkManager-1.48.2. Fixes #19995.

    • [bdubbs] - Update to libassuan-3.0.1. Fixes #19994.

    • [thomas] - Update to btrfs-progs-6.9.1. Fixes #19993.

  • June 23rd, 2024

    • [bdubbs] - Update to guile-3.0.10. Fixes #19992.

  • June 22nd, 2024

    • [bdubbs] - Update to emacs-29.4 (Security Update). Fixes #19991.

    • [bdubbs] - Update to mupdf-1.24.4. Fixes #19990.

    • [bdubbs] - Update to pycairo-1.26.1 (Python module). Fixes #19988.

    • [bdubbs] - Update to libksba-1.6.7. Fixes #19986.

    • [timtas] - Update to samba-4.20.2. Fixes #19979.

  • June 21st, 2024

    • [bdubbs] - Update to libdisplay-info-0.2.0. Fixes #19982.

  • June 20th, 2024

    • [bdubbs] - Update to mesa-24.1.2. Fixes #19980.

    • [bdubbs] - Update to libxslt-1.1.41. Fixes #19978.

    • [bdubbs] - Update to libxml2-2.13.1. Fixes #19977.

    • [bdubbs] - Update to libgcrypt-1.11.0. Fixes #19975.

    • [bdubbs] - Update to libgpg-error-1.50. Fixes #19976.

  • June 19th, 2024

    • [xry111] - Remove qtlocation from qt5 and qt5-components. Addresses #19442.

    • [bdubbs] - Update to uhttpmock-0.11.0. Fixes #19972.

    • [bdubbs] - Update to psutil-6.0.0 (Python module). Fixes #19971.

    • [bdubbs] - Update to c-ares-1.31.0. Fixes #19969.

    • [bdubbs] - Update to libassuan-3.0.0. Fixes #19966.

    • [bdubbs] - Update to qt6-6.7.2 and qtwebengine-6.7.2. Fixes #19970.

    • [timtas] - Update to cups-2.4.10. Fixes #19974.

  • June 18th, 2024

    • [rahul] - Update to cryptsetup-2.7.3 (Security Update). Fixes #19964.

  • June 17th, 2024

    • [timtas] - Update to thunderbird-115.12.0. Fixes #19958.

    • [renodr] - Update to intel-media-driver-24.1.5. Fixes #19704.

    • [bdubbs] - Update to numpy-2.0.0 (Python module). Fixes #19962.

    • [bdubbs] - Update to icewm-3.6.0. Fixes #19963.

    • [bdubbs] - Update to nettle-3.10. Fixes #19961.

  • June 15th, 2024

    • [bdubbs] - Update to libinput-1.26.0 (Xorg input driver). Fixes #19905.

    • [bdubbs] - Update to SDL2-2.30.3. Fixes #19904.

    • [bdubbs] - Update to protobuf-27.1. Fixes #19902.

    • [bdubbs] - Update Vulkan-Headers and Vulkan-Loader to version 1.3.288. Fixes #19957.

    • [bdubbs] - Update to enchant-2.8.1. Fixes #19952.

    • [bdubbs] - Update to freeglut-3.6.0. Fixes #19949.

    • [bdubbs] - Update to mercurial-6.7.4. Fixes #19948.

    • [ken] - Patch OpenSP to compile with gcc-14. Fixes #19956.

  • June 14th, 2024

    • [xry111] - Update to systemd-256. Fixes #19940.

    • [xry111] - Patch libxml2-2.13.0 to fix several issues breaking various downstream packages. Fixes #19955.

    • [bdubbs] - Update to audacious/audacious-plugins-4.4. Fixes #19950.

    • [bdubbs] - Update to libxslt-1.1.40. Fixes #19946.

    • [bdubbs] - Update to tcsh-6.24.13. Fixes #19945.

    • [bdubbs] - Update to Python3-3.12.4 (Security Update). Fixes #19909.

    • [xry111] - Update to rustc-1.79.0. Fixes #19953.

  • June 12th, 2024

    • [bdubbs] - Update to alsa-lib alsa-plugins alsa-utils 1.2.12. Fixes #19939.

    • [bdubbs] - Update to ruby-3.3.3. Fixes #19941.

    • [bdubbs] - Update to XML-LibXSLT-2.003000 (Perl module). Fixes #19942.

    • [renodr] - Update to libxml2-2.13.0. Fixes #19944.

    • [renodr] - Update to libwacom-2.12.1. Fixes #19938.

  • June 11th, 2024

    • [renodr] - Update to Spidermonkey-115.12.0 (Security Update). Fixes #19933.

    • [renodr] - Update to firefox-115.12.0esr (Security Update). Fixes #19934.

    • [renodr] - Update to cups-2.4.9 (Security Update). Fixes #19937.

    • [renodr] - Update to mesa-24.1.1. Includes adding the Ply python module, rust-bindgen, SPIRV-LLVM-Translator, and the libclc packages. Fixes #19832.

    • [bdubbs] - Update to qemu-9.0.1. Fixes #19926.

    • [bdubbs] - Update to glib-2.80.3. Fixes #19932.

    • [bdubbs] - Update to libaom-3.9.1 (Security update). Fixes #19935.

    • [renodr] - Update to xfce4-settings-4.18.6. Fixes #19936.

    • [renodr] - Archive telepathy-mission-control since it is not needed by any other packages.

    • [bdubbs] - Update to btrfs-progs-v6.9. Fixes #19915.

  • June 10th, 2024

    • [bdubbs] - Update to pango-1.54.0. Fixes #19928.

    • [bdubbs] - Update to packaging-24.1 (Python module). Fixes #19927.

    • [timtas] - Update to xfce4-settings-4.18.5. Fixes #19931.

    • [timtas] - Update to xfce4-session-4.18.4. Fixes #19930.

    • [timtas] - Update to xfce4-power-manager-4.18.4. Fixes #19929.

  • June 9th, 2024

    • [bdubbs] - Update to xscreensaver-6.09. Fixes #19925.

    • [bdubbs] - Update to pciutils-3.13.0. Fixes #19924.

  • June 8th, 2024

    • [bdubbs] - Update to nss-3.101. Fixes #19923.

    • [bdubbs] - Update to xkeyboard-config-2.42. Fixes #19920.

    • [bdubbs] - Update to c-ares-1.30.0. Fixes #19919.

    • [bdubbs] - Update to qpdf-11.9.1. Fixes #19918.

    • [bdubbs] - Update to fribidi-1.0.15. Fixes #19917.

    • [bdubbs] - Update to pcre2-10.44. Fixes #19916.

  • June 7th, 2024

    • [bdubbs] - Update Vulkan-Headers and Vulkan-Loader to version 1.3.287. Fixes #19879.

    • [bdubbs] - Update to llvm-18.1.7. Fixes #19903.

    • [bdubbs] - Update to mupdf-1.24.3. Fixes #19914.

    • [bdubbs] - Update to icewm-3.5.1. Fixes #19911.

    • [renodr] - Update to libreoffice-24.2.4.2 (Security Update). Fixes #19912.

    • [renodr] - Update to php-8.3.8 (Security Update). Fixes #19908.

    • [renodr] - Update to vlc-3.0.21 (Security Update). Fixes #19913.

    • [renodr] - Update to libwacom-2.12.0. Fixes #19906.

    • [renodr] - Update to cmake-3.29.5. Fixes #19907.

  • June 5th, 2024

    • [bdubbs] - Archive gstreamer-vaapi. Fixes #19899.

    • [bdubbs] - Update to sentry_sdk-2.4.0 (Python module). Fixes #19901.

    • [bdubbs] - Update to pytest-8.2.2 (Python module). Fixes #19900.

    • [bdubbs] - Update to cmake-3.29.4. Fixes #19898.

    • [bdubbs] - Update to poppler-24.06.0. Fixes #19896.

    • [bdubbs] - Update to opencv and opencv_contrib-4.10.0. Fixes #19895.

    • [renodr] - Update to vte-0.76.3 (Security Update). Fixes #19897.

    • [renodr] - Update to wireplumber-0.5.3. Fixes #19894.

    • [renodr] - Update to NetworkManager-1.48.0. Fixes #19876.

    • [renodr] - Update to procmail-3.24. Fixes #19891.

    • [renodr] - Fix building ncftp-3.2.7 with gcc-14. Fixes #19889.

    • [renodr] - Fix building libgee-0.20.6 with gcc-14. Fixes #19884.

  • June 4th, 2024

    • [renodr] - Fix building telepathy-glib-0.24.2 with gcc14. Fixes #19885.

    • [renodr] - Fix building gtksourceview-3.24.11 with gcc14. Fixes #19883.

    • [renodr] - Fix building xine-lib with ffmpeg-7. Fixes #19718.

  • June 2nd, 2024

    • [bdubbs] - Update to logrotate-3.22.0. Fixes #19892.

    • [bdubbs] - Update to highway-1.2.0. Fixes #19881.

    • [bdubbs] - Update xorg-server tearfree patch for gcc13.

    • [bdubbs] - Update to libevdev-1.13.2. Fixes #19878.

    • [bdubbs] - Update to libdrm-2.4.121. Fixes #19893.

    • [thomas] - Fix a gcc14 issue in cyrus-sasl. Fixes #19890.

  • June 1st, 2024

    • [bdubbs] - Update gtk-doc dependencies. Fixes #19880.

    • [bdubbs] - Update to lynx2.9.2. Fixes #19877.

    • [bdubbs] - Update to hwdata-0.383. Fixes #19874.

    • [bdubbs] - Update to git-2.45.2. Fixes #19875.

    • [xry111] - Update to LLVM-18.1.6. Fixes #19438.

  • May 31st, 2024

    • [renodr] - Update to epiphany-46.1. Fixes #19872.

    • [renodr] - Update to gtksourceview-5.12.1. Fixes #19871.

    • [renodr] - Update to gucharmap-15.1.5. Fixes #19856.

    • [renodr] - Update to gnome-terminal-3.52.2. Fixes #19855.

    • [renodr] - Update to nautilus-46.2. Fixes #19852.

    • [renodr] - Update to libshumate-1.2.2. Fixes #19850.

    • [renodr] - Update to transmission-4.0.6. Fixes #19867.

    • [bdubbs] - Update to libvpx-1.14.1. Fixes #19873.

    • [bdubbs] - Update to ruby-3.3.2. Fixes #19870.

    • [bdubbs] - Update to wayland-1.23.0. Fixes #19869.

    • [bdubbs] - Update to libcap-2.70. Fixes #19814.

    • [renodr] - Update to gdm-46.2. Fixes #19868.

    • [renodr] - Update to gnome-control-center-46.2. Fixes #19860.

    • [renodr] - Update to xdg-desktop-portal-gnome-46.2. Fixes #19854.

    • [renodr] - Update to mutter-46.2. Fixes #19851.

    • [renodr] - Update gnome-shell and gnome-shell-extensions to 46.2. Fixes #19849.

    • [renodr] - Update to gnome-online-accounts-3.50.2. Fixes #19848.

    • [renodr] - Update to evolution-data-server and evolution 3.52.2. Fixes #19842.

    • [bdubbs] - Restore PyYAML.

  • May 30th, 2024

    • [renodr] - Update to firefox-115.11.0esr (Security Update). Fixes #19792.

    • [renodr] - Disable the sandbox in Firefox on i686 due to issues with system call filtering. Fixes #19775.

    • [renodr] - Update to spidermonkey-115.11.0 (Security Update). Fixes #19787.

    • [renodr] - Update to thunderbird-115.11.1 (Security Update). Fixes #19798.

    • [bdubbs] - Update to gstreamer-1.24.4 and associated plugins. Fixes #19864.

    • [bdubbs] - Update to mariadb-10.11.8 (Security Update). Fixes #19865.

    • [bdubbs] - Update to requests-2.32.3 (Python module). Fixes #19866.

  • May 29th, 2024

    • [renodr] - Update to OpenJDK-22.0.1 (Security Update). Fixes #19508.

    • [renodr] - Update to webkitgtk-2.44.2 (Security Update). Fixes #19805.

    • [renodr] - Update to postgresql-16.3 (Security Update). Fixes #19779.

    • [bdubbs] - Update to node-20.14.0. Fixes #19862.

    • [bdubbs] - Add dolphin and dolphin-plugins to KDE applications.

    • [thomas] - Update to ISC Kea-2.6.0. Fixes #19863.

  • May 28th, 2024

    • [bdubbs] - Update to ffmpeg-7.0.1. Fixes #19861.

    • [bdubbs] - Update to adwaita-icon-theme-46.2. Fixes #19859.

    • [bdubbs] - Update to enchant-2.8.0. Fixes #19857.

    • [bdubbs] - Update to gsl-2.8. Fixes #19846.

    • [bdubbs] - Update to pipewire-1.0.7. Fixes #19845.

  • May 27th, 2024

    • [bdubbs] - Add a correction to xine-lib to handle ffmpeg-7. Fixes #19718.

    • [bdubbs] - Add patches to vlc to handle ffmpeg-7 and gcc-14. Addresses #19718.

    • [bdubbs] - Update to protobuf-27.0. Fixes #19834.

    • [bdubbs] - Update to libadwaita-1.5.1. Fixes #19841.

    • [bdubbs] - Update to librsvg-2.58.1. Fixes #19838.

    • [bdubbs] - Update to plasma-wayland-protocols-1.13.0. Fixes #19837.

    • [bdubbs] - Update to sentry_sdk-2.3.1 (Python module). Fixes #19835.

    • [thomas] - Update to evince-46.3. Fixes #19844.

  • May 26th, 2024

    • [bdubbs] - Update to kf6 and plasma packages used by lxqt. Fixes #19781.

    • [bdubbs] - Update to plasma-6.0.5. Fixes #19680.

    • [timtas] - Update to vte-0.76.2. Fixes #19853.

    • [timtas] - Update to gvfs-1.54.1. Fixes #19843.

    • [bdubbs] - Update to kde-gear-24.05.0 including falkon and kate. Fixes #19833.

    • [thomas] - Update to ntp-4.2.8p18. Fixes #19847.

  • May 25th, 2024

    • [bdubbs] - Update to kf6-6.2.0 including extra-cmake-modules-6.2.0. Fixes #19780.

    • [thomas] - Update to c-ares-1.29.0. Fixes #19840.

    • [thomas] - Update to dhcpcd-10.0.8. Fixes #19839.

    • [thomas] - Update to sqlite-3.46.0. Fixes #19836.

  • May 23rd, 2024

    • [bdubbs] - Update to xterm-392. Fixes #19831.

    • [bdubbs] - Update to pavucontrol-6.0. Fixes #19830.

    • [bdubbs] - Update to curl-8.8.0. Fixes #19829.

    • [bdubbs] - Update to umockdev-0.18.3. Fixes #19825.

    • [bdubbs] - Update to qt6-6.7.1 and qtwebengine-6.7.1. Fixes #19822.

    • [bdubbs] - Update latest Intel microcode version (Security Update). Fixes #19797.

  • May 22nd, 2024

    • [renodr] - Update to SPIRV-Headers and SPIRV-Tools 1.3.283.0. Fixes #19795.

    • [renodr] - Update Vulkan-Headers and Vulkan-Loader to 1.3.285. Fixes #19760.

    • [renodr] - Update to gnome-maps-46.11. Fixes #19785.

    • [renodr] - Update to file-roller-44.3. Fixes #19770.

    • [renodr] - Update to snapshot-46.3. Fixes #19759.

    • [renodr] - Update to gnome-calculator-46.1. Fixes #19758.

    • [renodr] - Fix a regression in gnome-shell that appears when using glib-2.80.2.

    • [renodr] - Update to glib-2.80.2 (Security Update). Fixes #19764.

    • [bdubbs] - Update to icewm-3.5.0. Fixes #19824.

    • [bdubbs] - Update to hicolor-icon-theme-0.18. Fixes #19823.

    • [bdubbs] - Update to libass-0.17.2. Fixes #19817.

    • [rahul] - Update to nodejs-20.13.1. Fixes #19765.

    • [rahul] - Update to mesa-24.0.8. Fixes #19767.

    • [rahul] - Update to harfbuzz-8.5.0. Fixes #19789.

    • [rahul] - Update to bluez-5.76. Fixes #19806.

    • [rahul] - Update to pipewire-1.0.6. Fixes #19782.

    • [bdubbs] - Update to requests-2.32.2 (Python module). Fixes #19821.

    • [bdubbs] - Update to gi_docgen-2024.1 (Python module). Fixes #19820.

    • [bdubbs] - Update to Mako-1.3.5 (Python module). Fixes #19790.

    • [bdubbs] - Update to lxml-5.2.2 (Python module). Fixes #19783.

    • [bdubbs] - Update to sentry_sdk-2.2.1 (Python module). Fixes #19826.

    • [timtas] - Update to openldap-2.6.8. Fixes #19827.

  • May 21st, 2024

    • [bdubbs] - Update to doxygen-1.11.0. Fixes #19819.

    • [bdubbs] - Update to nghttp2-1.62.1. Fixes #19816.

    • [bdubbs] - Update to ghostscript-10.03.1 (Security Update). Fixes #19813.

    • [bdubbs] - Update to pytest-8.2.1 (Python module). Fixes #19815.

  • May 20th, 2024

    • [bdubbs] - Update to gdk-pixbuf-2.42.12 (Security Update). Fixes #19803.

    • [bdubbs] - Update to libxml2-2.12.7 (Security Update). Fixes #19788.

    • [bdubbs] - Update to xfsprogs-6.8.0. Fixes #19809.

    • [bdubbs] - Update to LVM2.2.03.24. Fixes #19808.

  • May 19th, 2024

    • [bdubbs] - Update to wireshark-4.2.5 (Security Update). Fixes #19801.

    • [bdubbs] - Update to xwayland-24.1.0. Fixes #19802.

    • [bdubbs] - Update to unrar-7.0.9. Fixes #19799.

  • May 18th, 2024

    • [bdubbs] - Update to iw-6.9. Fixes #19811.

    • [bdubbs] - Update to asciidoctor-2.0.23. Fixes #19810.

    • [bdubbs] - Update to sentry_sdk-2.2.0 (Python module). Fixes #19807.

    • [bdubbs] - Update to lxqt-openssh-askpass-2.0.1. Fixes #19786.

    • [bdubbs] - Update to qtermwidget and qterminal-2.0.0. Fixes #19812.

    • [bdubbs] - Update to kirigami-addons-1.2.1. Fixes #19776.

    • [bdubbs] - Update to gcc-14.1. Fixes #19762.

    • [bdubbs] - Update to lxqt-panel-2.0.1. Fixes #19772.

    • [bdubbs] - Update to libfm-qt-2.0.2. Fixes #19771.

    • [bdubbs] - Update to unbound-1.20.0. Fixes #19769.

    • [timtas] - Update to gtk+3-3.24.42. Fixes #19804.

  • May 16th, 2024

    • [thomas] - Update to mupdf-1.24.2. Fixes #19773.

    • [thomas] - Update to libslirp-4.8.0. Fixes #19778.

    • [thomas] - Update to nghttp2-1.62.0. Fixes #19791.

    • [thomas] - Update to bind-9.18.27, bind-utils-9.18.27. Fixes #19800.

  • May 15th, 2024

    • [timtas] - Update to git-2.45.1. Fixes #19796.

    • [timtas] - Update to gimp-2.10.38. Fixes #19793.

    • [thomas] - Update to php-8.3.7. Fixes #19777.

    • [thomas] - Update to xterm-391. Fixes #19784.

  • May 14th, 2024

    • [renodr] - Fix building Inkscape with poppler-24.05.0. Fixes #19794.

    • [renodr] - Fix building gst-libav with ffmpeg-7.

  • May 13th, 2024

    • [renodr] - Fix building sphinx_rtd_theme with docutils-0.21.x. This fixes an error about incompatible versions, but upstream has changed the version range so that it's compatible.

    • [timtas] - Update to samba-4.20.1. Fixes #19768.

  • May 11th, 2024

    • [thomas] - Update to nss-3.100. Fixes #19763.

  • May 10th, 2024

    • [thomas] - Update to cmake-3.29.3. Fixes #19766.

  • May 6th, 2024

    • [bdubbs] - Update to libqalculate-5.1.1. Fixes #19757.

    • [bdubbs] - Update to sentry_sdk-2.1.1 (Python module). Fixes #19757.

    • [bdubbs] - Update to mercurial-6.7.3. Fixes #19756.

  • May 6th, 2024

    • [bdubbs] - Update to lxml-5.2.1 (Python module). Fixes #19068.

    • [bdubbs] - Update to sphinx-7.3.7 (Python module). Fixes #19676.

    • [bdubbs] - Update to sphinxcontrib_applehelp-1.0.8 (Python module).

    • [bdubbs] - Update to alabaster-0.7.16 (Python module).

    • [bdubbs] - Update to Cython-3.0.10 (Python module). Fixes #18303.

    • [bdubbs] - Archive PyYaml. Addresses #18303.

  • May 5th, 2024

    • [xry111] - Update to rustc-1.78.0. Fixes #19557.

    • [bdubbs] - Update to libfm-qt-2.0.1, lximage-qt-2.0.1, and lxqt-notificationd-2.0.1. Fixes #19753.

    • [bdubbs] - Update to xdg-desktop-portal-lxqt-1.0.2. Fixes #19754.

    • [bdubbs] - Update to pygments-2.18.0 (Python module). Fixes #19752.

    • [bdubbs] - Update to enchant-2.7.3. Fixes #19751.

    • [xry111] - Update Python dependencies: attrs-23.2.0, meson_python-0.16.0, and pyproject-metadata-0.8.0. Add hatch-fancy-pypi-readme-24.1.0 to support attrs-23.2.0. Addresses #18562.

    • [xry111] - Update Python dependencies: editables-0.5, hatchling-1.24.2, hatch-vcs-0.4.0, pathspec-0.12.1, pluggy-1.5.0, setuptools_scm-8.0.4, and typing_extensions-4.11.0. Add trove-classifiers-2024.4.10 to support hatchling-1.24.2. Addresses #18562.

  • May 4th, 2024

    • [xry111] - Archive py which is no longer needed by pytest.

  • May 3rd, 2024

    • [bdubbs] - Update to libnvme-1.9. Fixes #19749.

    • [bdubbs] - Update to hwdata-0.382. Fixes #19750.

    • [bdubbs] - Update to libreoffice-24.2.3.2. Fixes #19745.

    • [bdubbs] - Update to ibus-1.5.30. Fixes #19747.

    • [bdubbs] - Update to lynx2.9.1. Fixes #19748.

    • [thomas] - Update to btrfs-progs-6.8.1. Fixes #19742.

  • May 2nd, 2024

    • [renodr] - Update to Net-DNS-1.45 (Perl Module). Fixes #19743.

    • [renodr] - Update to glslang-14.2.0. Fixes #19744.

    • [renodr] - Update to gtk4-4.14.4. Fixes #19746.

    • [renodr] - Update to tracker and tracker-miners 3.7.3. Fixes #19716.

    • [bdubbs] - Update to poppler-24.05.0. Fixes #19741.

    • [bdubbs] - Update to nano-8.0. Fixes #19740.

  • May 1st, 2024

    • [timtas] - Update to cups-2.4.8. Fixes #19729.

  • April 30th, 2024

    • [bdubbs] - Update the gstreamer stack to 1.24.3. Fixes #19737.

    • [renodr] - Update to tracker and tracker-miners 3.7.2. Fixes #19716.

    • [renodr] - Update to gnome-tweaks-46.1. Fixes #19728.

    • [thomas] - Update to git-2.45.0. Fixes #19736.

    • [thomas] - Update to evince-46.1. Fixes #19732.

  • April 29th, 2024

    • [bdubbs] - Update to graphviz-11.0.0. Fixes #19735.

    • [bdubbs] - Update to gedit-47.0. Fixes #19734.

    • [bdubbs] - Update to sentry-sdk-2.0.1 (Python module). Fixes #19723.

  • April 28th, 2024

    • [bdubbs] - Update to mlt-7.24.0. Fixes #19733.

    • [bdubbs] - Update to jasper-4.2.4. Fixes #19731.

    • [bdubbs] - Update to libgedit-gtksourceview-299.2.1. Fixes #19730.

  • April 27th, 2024

    • [bdubbs] - Update to valgrind-3.23.0. Fixes #19727.

    • [bdubbs] - Update to libarchive-3.7.4 (Security Update). Fixes #19724.

    • [bdubbs] - Update to AppStream-1.0.3. Fixes #19714.

    • [bdubbs] - Update to pytest-8.2.0 (Python module). Fixes #19726.

    • [bdubbs] - Update to wayland-protocols-1.36. Fixes #19725.

    • [bdubbs] - Update to unrar-7.0.8. Fixes #19722.

    • [bdubbs] - Update to fribidi-1.0.14. Fixes #19721.

    • [bdubbs] - Update to enchant-2.7.2. Fixes #19719.

    • [bdubbs] - Update to libgpg-error-1.49. Fixes #19720.

    • [bdubbs] - Update to ed-1.20.2. Fixes #19713.

    • [bdubbs] - Update to libaom-3.9.0. Fixes #19712.

  • April 26th, 2024

    • [bdubbs] - Update to docutils-0.21.2 (Python module). Fixes #19710.

  • April 25th, 2024

    • [timtas] - Update to mesa-24.0.6. Fixes #19715.

    • [timtas] - Update to qemu-9.0.0. Fixes #19517.

    • [xry111] - Patch SeaMonkey to unbreak building with ICU-75.1.

  • April 24th, 2024

    • [renodr] - Update to ruby-3.3.1 (Security Update). Fixes #19711.

  • April 23rd, 2024

    • [renodr] - Update to gnome-control-center-46.1. Fixes #19708.

    • [renodr] - Update to xdg-desktop-portal-gnome-46.1. Fixes #19702.

    • [renodr] - Update to nautilus-46.1. Fixes #19701.

    • [renodr] - Update to mutter-46.1. Fixes #19700.

    • [renodr] - Update to gnome-user-docs-46.1. Fixes #19699.

    • [renodr] - Update to gnome-shell-extensions-46.1. Fixes #19698.

    • [renodr] - Update to gnome-shell-46.1. Fixes #19698.

    • [renodr] - Update to gucharmap-15.1.4. Fixes #19696.

    • [renodr] - Update to wireplumber-0.5.2. Fixes #19709.

    • [renodr] - Update to gnome-terminal-3.52.1. Fixes #19695.

    • [renodr] - Update to gnome-maps-46.10. Fixes #19694.

    • [renodr] - Update to vte-0.76.1. Fixes #19693.

    • [renodr] - Update to libshumate-1.2.1. Fixes #19692.

    • [renodr] - Update to evolution-3.52.1. Fixes #19690.

    • [renodr] - Update to evolution-data-server-3.52.1. Fixes #19690.

    • [renodr] - Update Vulkan-Headers and Vulkan-Loader to 1.3.283. Fixes #19689.

    • [bdubbs] - Update to nmap-7.95. Fixes #19707.

    • [bdubbs] - Update to libxmlb-0.3.19. Fixes #19706.

    • [bdubbs] - Update to libgusb-0.4.9. Fixes #19705.

  • April 22nd, 2024

    • [bdubbs] - Update to solid-6.1.1. Fixes #19703.

    • [bdubbs] - Update to enchant-2.7.0. Fixes #19697.

    • [bdubbs] - Update to gdk-pixbuf-2.42.11. Fixes #19691.

    • [bdubbs] - Update to vala-0.56.17. Fixes #19688.

  • April 21st, 2024

  • April 20th, 2024

    • [rahul] - Update to ffmpeg-7.0. Fixes #19604.

    • [rahul] - Update to nodejs-20.12.2. Fixes #19638.

    • [rahul] - Update to mesa-24.0.5. Fixes #19641.

    • [rahul] - Update to power-profiles-daemon-0.21. Fixes #19581.

  • April 19th, 2024

    • [renodr] - Update to thunderbird-115.10.1. Fixes #19685.

    • [renodr] - Update to gtk-4.14.3. Fixes #19686.

  • April 18th, 2024

    • [renodr] - Update to mpv-0.38.0. Fixes #19682.

    • [bdubbs] - Update to icu-75.1. Fixes #19674.

    • [bdubbs] - Update to wayland-protocols-1.35. Fixes #19675.

    • [bdubbs] - Update to glibmm-2.66.7. Fixes #19673.

    • [thomas] - Update to bind-9.18.26, bind-utils-9.18.26. Fixes #19679.

    • [thomas] - Update to xfsprogs-6.7.0. Fixes #19677.

    • [thomas] - Update to NASM-2.16.03. Fixes #19678.

  • April 17th, 2024

    • [bdubbs] - Update to Vulkan-Loader-1.3.282. Fixes #19670.

    • [bdubbs] - Update to util-macros-1.20.1. Fixes #19669.

    • [bdubbs] - Update to libXmu-1.2.1 (Xorg library). Fixes #19668.

    • [renodr] - Update to thunderbird-115.10.0 (Security Update). Fixes #19671.

    • [renodr] - Update to firefox-115.10.0esr (Security Update). Fixes #19664.

    • [renodr] - Update to spidermonkey-115.10.0 (Security Update). Fixes #19666.

    • [renodr] - Update to pipewire-1.0.5. Fixes #19665.

  • April 16th, 2024

    • [bdubbs] - Update to php-8.3.6 (security update). Fixes #19645.

    • [bdubbs] - Update to sqlite-autoconf-3450300 (3.45.3). Fixes #19662.

    • [bdubbs] - Update to boost-1.85.0. Fixes #19660.

    • [ken] - Change details for KDE in tuning fontconfig and note much earlier that the settings for fontconfig may be ignored by applications and desktop environments. Fixes #19667.

    • [renodr] - Update to xf86-input-wacom-1.2.2. Fixes #19663.

    • [renodr] - Update to libwacom-2.11.0. Fixes #19661.

    • [renodr] - Update to gnome-system-monitor-46.0. Fixes #19606.

    • [renodr] - Add gtkmm-4.14.0 to the book. Fixes #14443.

    • [renodr] - Add atkmm-2.36.3 to the book. Fixes #14406.

    • [renodr] - Add pangomm-2.52.0 to the book. Fixes #14405.

    • [renodr] - Add cairomm-1.18.0 to the book. Fixes #14172.

    • [renodr] - Add glibmm-2.80.0 to the book. Fixes #14403.

    • [renodr] - Add libsigc++3 to the book. Fixes #16086.

    • [bdubbs] - Update to bluez-5.75. Fixes #19655.

    • [bdubbs] - Fix a build problem for sphinx-7.2.6. Fixes #19659.

    • [bdubbs] - Update to elogind-255.4-r2. Fixes #19298.

  • April 15th, 2024

    • [renodr] - Update to gucharmap-15.1.3. Fixes #19477.

    • [renodr] - Update to gnome-terminal-3.52.0. Fixes #19476.

    • [renodr] - Update to gnome-logs-45.0. Fixes #19603.

    • [renodr] - Update to gnome-disk-utility-46.0. Fixes #19602.

    • [renodr] - Update to gnome-calculator-46.0. Fixes #19599.

    • [renodr] - Update to file-roller-44.1. Fixes #19598.

    • [renodr] - Update to evince-46.0. Fixes #19490.

    • [renodr] - Update to dvisvgm-3.3. Fixes #19642.

    • [renodr] - Update to asymptote-2.89. Fixes #19543.

    • [renodr] - Fix bugs in latex2e and dvipdfm-x in texlive. Fixes #19571.

    • [renodr] - Update to EOG-45.3. Fixes #19475.

    • [renodr] - Update to baobab-46.0. Fixes #19601.

    • [renodr] - Update to simple-scan-46.0. Fixes #19620.

    • [bdubbs] - Update to Python3-3.12.3. Fixes #19633.

    • [renodr] - Fix CVE-2024-25081 and CVE-2024-25082 in FontForge. Fixes #19545.

    • [renodr] - Update to libxcb-1.17.0. Fixes #19658.

    • [renodr] - Update to xcb-proto-1.17.0. Fixes #19657.

    • [renodr] - Update to vulkan-headers-1.3.282. Fixes #19656.

    • [renodr] - Update to gtk-4.14.2. Fixes #19583.

  • April 14th, 2024

    • [bdubbs] - Update the gstreamer stack to 1.24.2. Fixes #19634.

    • [bdubbs] - Remove overwriting of terminfo data in xterm. Fixes #19611.

    • [bdubbs] - Update to lxqt-qtplugin-1.4.1. Fixes #19652.

    • [bdubbs] - Update to plasma-6.0.3. Fixes #19733.

    • [thomas] - Update to libwebp-1.4.0. Fixes #19654.

    • [thomas] - Update to opus-1.5.2. Fixes #19653.

  • April 12th, 2024

    • [bdubbs] - Update to kf6-6.1.0. Fixes #19649.

  • April 12th, 2024

    • [renodr] - Update to gnome-user-docs-46.0. Fixes #19497.

    • [renodr] - Update to gnome-tweaks-46.0. Fixes #19496.

    • [renodr] - Update to gnome-session-46.0. Fixes #19504.

    • [renodr] - Update to gnome-shell-extensions-46.0. Fixes #19472.

    • [bdubbs] - Update to cmake-3.29.2. Fixes #19644.

    • [bdubbs] - Update to cryptsetup-2.7.2. Fixes #19630.

    • [renodr] - Update to gdm-46.0. Fixes #19505.

    • [renodr] - Update to gnome-shell-46.0. Fixes #19472.

    • [renodr] - Update to mutter-46.0. Fixes #19473.

    • [renodr] - Update to gnome-control-center-46.0.1. Fixes #19502.

    • [renodr] - Update to tecla-46.0. Fixes #19486.

    • [renodr] - Update to gnome-settings-daemon-46.0. Fixes #19485.

    • [renodr] - Update to gnome-bluetooth-46.0. Fixes #19503.

    • [renodr] - Update to nautilus-46.0. Fixes #19501.

    • [bdubbs] - Update to libxmlb-0.3.18. Fixes #19631.

    • [bdubbs] - Update to taglib-2.0.1. Fixes #19635.

    • [bdubbs] - Update to sentry-sdk-1.45.0 (Python module). Fixes #19640.

    • [bdubbs] - Update to xorg-server-21.1.13. Fixes #19650.

    • [bdubbs] - Update to xwayland-23.2.6. Fixes #19623.

    • [renodr] - Update to snapshot-46.2. Fixes #19648.

    • [renodr] - Update to gnome-online-accounts-3.50.1. Fixes #19647.

    • [renodr] - Update to gcr4-4.3.0. Fixes #19646.

    • [renodr] - Update to libgtop-2.41.3. Fixes #19627.

    • [renodr] - Update to epiphany-46.0. Fixes #19491.

    • [renodr] - Update to WebKitGTK-2.44.1. Fixes #19622.

    • [bdubbs] - Update to docutils-0.21.1 (Python module). Fixes #19632.

    • [bdubbs] - Update to Mako-1.3.3 (Python module). Fixes #19639.

  • April 11th, 2024

    • [renodr] - Add libjxl to the book in support gnome-backgrounds and other packages. Fixes #19626.

    • [renodr] - Add highway to the book in support of libjxl. Fixes #19626.

    • [thomas] - Update to Linux-PAM-1.6.1. Fixes #19629.

    • [bdubbs] - Update to seamonkey-2.53.18.2. Fixes #19617.

  • April 10th, 2024

    • [bdubbs] - Update to upower-v1.90.4. Fixes #19621.

    • [bdubbs] - Update to libarchive-3.7.3. Fixes #19618.

    • [bdubbs] - Update to js-115.9.1 (spidermonkey). Fixes #19616.

    • [timtas] - Update to rsync-3.3.0. Fixes #19614.

    • [xry111] - Patch pipewire-1.0.4 to fix an issue breaking snapshot-46.1. Fixes #19637.

  • April 9th, 2024

    • [renodr] - Update to xdg-desktop-portal-gnome-46.0. Fixes #19624.

    • [bdubbs] - Update to qt6-6.7.0 and qtwebengine-6.7.0. Fixes #19575.

    • [renodr] - Update to gnome-backgrounds-46.0. Fixes #19625.

    • [renodr] - Update to tracker-miners-3.7.1. Fixes #19482.

    • [renodr] - Update to tracker-3.7.1. Fixes #19482.

    • [renodr] - Update to evolution-3.52.0. Fixes #19481.

    • [renodr] - Update to evolution-data-server-3.52.0. Fixes #19481.

    • [renodr] - Update to gnome-maps-46.0. Fixes #19506.

    • [renodr] - Update to libshumate-1.2.0. Fixes #19492.

    • [renodr] - Add abseil-cpp, protobuf, and protobuf-c in support of libshumate and other packages. Part of #19492.

  • April 8th, 2024

    • [renodr] - Update TigerVNC to use xorg-server-21.1.12. This protects Xvnc against the security vulnerabilities fixed in that update.

    • [bdubbs] - Update to httpd-2.4.59 (Security Update). Fixes #19507.

    • [renodr] - Update to gnome-online-accounts-3.50.0. Fixes #19480.

    • [renodr] - Update to pygobject-3.48.2 (Python Module). Fixes #19613.

    • [renodr] - Archive gnome-video-effects. Fixes #19488.

    • [renodr] - Update to gtksourceview-5.12.0. Fixes #19590.

    • [renodr] - Update to gnome-keyring-46.1. Fixes #19484.

    • [bdubbs] - Update to xwayland-23.2.5 (Security Update). Fixes #19579.

    • [bdubbs] - Update to xorg-server-21.1.12 (Security Update). Addresses #19579.

    • [bdubbs] - Update to nghttp2-1.61.0 (Security Update). Fixes #19596.

  • April 7th, 2024

    • [bdubbs] - Update to libX11-1.8.9 (Xorg library). Fixes #19610.

    • [bdubbs] - Update to mtdev-1.1.7. Fixes #19608.

    • [bdubbs] - Update to tcsh-6.24.12. Fixes #19607.

    • [bdubbs] - Update to tepl-6.9.0. Fixes #19591.

    • [bdubbs] - Update to libgedit-gtksourceview-299.1.0. Fixes #19515.

    • [rahul] - Update to nodejs-20.12.1 (Security Update). Fixes #19552.

    • [rahul] - Update to samba-4.20.0 (Security Update). Fixes #19554.

    • [rahul] - Update to mesa-24.0.4. Fixes #19556.

  • April 6th, 2024

    • [bdubbs] - Move luit from xorg apps to it's own page. Fixes #19578.

    • [bdubbs] - Update to gnutls-3.8.5. Fixes #19592.

    • [bdubbs] - Update to enchant-2.6.9. Fixes #19593.

    • [bdubbs] - Update to hwdata-0.381. Fixes #19594.

    • [bdubbs] - Update to at-spi2-core-2.52.0. Fixes #19587.

    • [bdubbs] - Update to sentry-sdk-1.44.1. Fixes #19582.

    • [bdubbs] - Move libwnck from gnome section to xfce section. Fixes #19577.

    • [thomas] - Update to pciutils-3.12.0. Fixes #19609.

  • April 5th, 2024

    • [bdubbs] - Update to libxmlb-0.3.17. Fixes #19580.

    • [thomas] - Update to gtkmm-3.24.9. Fixes #19589.

    • [thomas] - Update to cairomm-1.14.5. Fixes #19588.

    • [thomas] - Update to poppler-24.04.0. Fixes #19574.

    • [thomas] - Update to mupdf-1.24.1. Fixes #19576.

    • [thomas] - Update to mpg123-1.32.6. Fixes #19605.

    • [thomas] - Update to nasm-2.16.02. Fixes #19595.

    • [xry111] - Update to LLVM-18.1.2. Addresses #19438.

  • April 4th, 2024

    • [renodr] - Update to gnome-weather-46.0. Fixes #19586.

    • [renodr] - Update to libgweather-4.4.2. Fixes #19522.

    • [renodr] - Adapt Firefox to use Google's Location Service by removing our MLS API key. Fixes #19541.

    • [renodr] - Adapt Geoclue to use Google's Location Service due to the Mozilla Location Service shutdown. Fixes #19541.

    • [renodr] - Update to gjs-1.80.2. Fixes #19487.

    • [renodr] - Update to snapshot-46.1. Fixes #19507.

    • [renodr] - Update to wireplumber-0.5.1. Fixes #19567.

    • [thomas] - Update to pango-1.52.2. Fixes #19585.

    • [thomas] - Update to cmake-3.29.1. Fixes #19584.

  • April 3rd, 2024

    • [renodr] - Update to libadwaita-1.5.0. Fixes #19489.

    • [renodr] - Update the gstreamer stack to 1.24.1. Fixes #19408.

  • April 2nd, 2024

    • [bdubbs] - Update to libreoffice-24.2.2.2. Fixes #19559.

    • [bdubbs] - Update to kirigami-addons-1.1.0. Fixes #19573.

    • [bdubbs] - Update to gobject-introspection-1.80.1. Fixes #19572.

    • [ken] - Update to biber-2.20 with biblatex-3.20 and update related perl items: Module-Build-0.4234 (Perl Module), Alien-Build-2.80, B-Hooks-EndOfScope-0.28, CPAN-Meta-Check-0.18, DateTime-1.65, DateTime-Locale-1.40, DateTime-TimeZone=2.62, Devel-StackTrace-2.05, Exporter-Tiny-1.006002, File-Listing-6.16, HTML-Tagset-3.24, HTTP-Cookies-6.11, HTTP-Date-6.06, HTTP-Message-6.45, Net-SSLeay-1.94, Test-Warnings-0.033, Tie-Cycle-1.228, Variable-Magic-0.64, XML-LibXML-2.0210 (Perl Dependent Modules). Archive: Importer, Module-Pluggable, Sub-Info (Perl Dependent Modules). Thanks to Stephen Berman for reporting Net-SSLeay no-longer passed its tests, and to Bruce for diagnosing this. Fixes #19528.

  • April 1st, 2024

    • [thomas] - Upgrade c-ares-1.28.1. Fixes #19566.

    • [renodr] - Fix building Inkscape with poppler-24.03.0. Fixes #19570.

    • [bdubbs] - Update to libical-3.0.18. Fixes #19568.

    • [bdubbs] - Update to jasper-4.2.3. Fixes #19565.

    • [bdubbs] - Update to soundtouch-2.3.3. Fixes #19564.

    • [bdubbs] - Update to mercurial-6.7.2. Fixes #19562.

    • [bdubbs] - Update to harfbuzz-8.4.0. Fixes #19561.

  • March 31st, 2024

    • [renodr] - Update to librsvg-2.58.0. Fixes #19433.

  • March 30th, 2024

    • [bdubbs] - Update to wireshark-4.2.4 (Security update). Fixes #19555.

    • [bdubbs] - Update to sentry-sdk-1.44.0 (Python module). Fixes #19558.

    • [thomas] - Update to c-ares-1.28.0. Fixes #19563.

  • March 29th, 2024

    • [thomas] - Update to shadow-4.15.1. Fixes #19532.

  • March 28th, 2024

    • [bdubbs] - Update to qt6-6.6.3 and qtwebengine-6.6.3. Fixes #19551.

  • March 28th, 2024

    • [timtas] - Update to libva-2.21.0. Fixes #19546.

    • [bdubbs] - Update to bubblewrap-0.9.0. Fixes #19549.

    • [bdubbs] - Update to URI-5.28 (Perl Module). Fixes #19550.

    • [bdubbs] - Update to libblockdev-3.1.1. Fixes #19548.

    • [bdubbs] - Update to btrfs-progs-v6.8. Fixes #19547.

    • [bdubbs] - Update to xorgproto-2024.1. Fixes #19544.

  • March 27th, 2024

    • [timtas] - Update to cURL-8.7.1 (Security Update). Fixes #19553.

    • [thomas] - Fix a misconfiguration in LibreOffice on i686 systems.

    • [timtas] - Force vlc to compile against lua52.

  • March 26th, 2024

    • [renodr] - Update to Vulkan-Headers and Vulkan-Loader 1.3.281. Fixes #19434.

    • [bdubbs] - Update to icewm-3.4.7. Fixes #19542.

    • [bdubbs] - Update to Xorg libraries libX11-1.8.8 and libXmu-1.2.0. Fixes #19539.

    • [bdubbs] - Update to emacs-29.3 (Security Update). Fixes #19537.

  • March 25th, 2024

    • [timtas] - Update to cryptsetup-2.7.1. Fixes #19425.

    • [renodr] - Update to gsettings-desktop-schemas-46.0. Fixes #19479.

  • March 24th, 2024

    • [bdubbs] - Update to umockdev-0.18.1. Fixes #19538.

    • [bdubbs] - Added Python modules certifi, psutil, pygdbmi, and sentry-sdk in support of plasma. Fixes #19536.

    • [bdubbs] - Added Python modules html5lib and webencodings in support of qtwebengine. Fixes #19535.

  • March 24th, 2024

    • [bdubbs] - Update to libpciaccess-0.18.1 (xorg library). Fixes #19534.

    • [bdubbs] - Update to libxkbcommon-1.7.0. Fixes #19533.

    • [bdubbs] - Update to SPIRV-Tools-1.3.280.0. Fixes #19531.

    • [bdubbs] - Update to enchant-2.6.8. Fixes #19530.

  • March 23rd, 2024

    • [thomas] - Update to gnutls-3.8.4 (Security Update). Fixes #19510.

    • [xry111] - Update to rustc-1.77.0. Fixes #19527.

  • March 22nd, 2024

    • [rahul] - Update to cmake-3.29.0. Fixes #19525.

    • [rahul] - Update to gtk4-4.14.1. Fixes #19464.

    • [rahul] - Update to pipewire-1.0.4. Fixes #19462.

    • [renodr] - Update to spidermonkey-115.9.1 (Security Update). Fixes #19500.

    • [ken] - Update to firefox-115.9.1 (Security Update). Fixes #19529.

    • [bdubbs] - Update to mercurial-6.7.1. Fixes #19526.

  • March 21st, 2024

    • [bdubbs] - Update to bind utilities/bind-9.18.25. Fixes #19521.

    • [bdubbs] - Update to wayland-protocols-1.34. Fixes #19520.

    • [bdubbs] - Update to libcloudproviders-0.3.6. Fixes #19519.

    • [bdubbs] - Update to SPIRV-Headers-1.3.280.0. Fixes #19518.

    • [bdubbs] - Update to mupdf-1.24.0. Fixes #19516.

    • [bdubbs] - Update to adwaita-icon-theme-46.0. Fixes #19514.

    • [bdubbs] - Update to pinentry-1.3.0. Fixes #19513.

    • [bdubbs] - Update to glad-2.0.6. Fixes #19512.

  • March 20th, 2024

    • [bdubbs] - Update to elogind-252.23. Fixes #19509.

    • [bdubbs] - Update to harfbuzz-8.3.1. Fixes #19494.

    • [bdubbs] - Update to mercurial-6.7. Fixes #19469.

    • [ken] - Update to texlive 2024. Fixes #19463.

    • [ken] - Remove old ConTeXt fixes from texlive source. Fixes #18349.

    • [timtas] - Update to vte-0.76.0. Fixes #19474.

    • [renodr] - Adapt rsync to LZ4 now being in LFS.

    • [bdubbs] - Update to bluefish-2.2.15. Fixes #19493.

    • [bdubbs] - Update to wireplumber-0.5.0. Fixes #19089.

    • [timtas] - Update to thunderbird-115.9.0. Fixes #19515.

    • [thomas] - Update to libpaper-2.2.5. Fixes #19511.

  • March 19th, 2024

    • [bdubbs] - Update to tk8.6.14. Fixes #19498.

    • [bdubbs] - Update to SCons-4.7.0. Fixes #19495.

    • [bdubbs] - Update to glib-networking-2.80.0. Fixes #19470.

    • [ken] - Update to firefox-115.9.0 (Security Update). Fixes #19499.

    • [bdubbs] - Update to nss-3.99. Fixes #19467.

    • [bdubbs] - Update to vala-0.56.16. Fixes #19465.

    • [bdubbs] - Update to libaom-3.8.2. Fixes #19461.

    • [thomas] - Update to libpaper-2.2.3. Fixes #19445.

    • [bdubbs] - Update to tcsh-6.24.11. Fixes #19457.

    • [bdubbs] - Update to jasper-4.2.2. Fixes #19454.

    • [bdubbs] - Update to libqalculate-5.0.0. Fixes #19453.

  • March 18th, 2024

    • [bdubbs] - Update to xapian-core-1.4.25. Fixes #19427.

    • [bdubbs] - Update to iceauth-1.0.10 (Xorg app). Fixes #19450.

    • [bdubbs] - Update to libXaw-1.0.16 (Xorg library). Fixes #19451.

    • [bdubbs] - Update to packaging-24.0 (Python module). Fixes #19448.

    • [bdubbs] - Update to pygobject3-3.48.1 (Python module). Fixes #19440.

    • [bdubbs] - Update to pytest-8.1.1 (Python module). Fixes #19443.

    • [timtas] - Update to gvfs-1.54.0. Fixes #19483.

    • [bdubbs] - Update to HTML-Parser-3.82 (Perl module). Fixes #19458.

    • [bdubbs] - Update to libwww-perl-6.77 (Perl module). Fixes #19447.

    • [bdubbs] - Update to LWP-Protocol-https-6.14 (Perl module). Fixes #19446.

    • [bdubbs] - Update to asciidoctor-2.0.22. Fixes #19437.

    • [bdubbs] - Update to shadow-4.15.0. Fixes #19432.

    • [thomas] - Update to glslang-14.1.0. Fixes #19435.

    • [thomas] - Update to php-8.3.4. Fixes #19466.

    • [thomas] - Update to wget-1.24.5. Fixes #19449.

    • [thomas] - Update to at-spi2-core-2.50.2. Fixes #19471.

  • March 17th, 2024

    • [bdubbs] - Update to sddm-0.21.0. Fixes #19360.

    • [bdubbs] - Add xdotool-3.20211022.1 in support of plasma6. Addresses #19373.

    • [bdubbs] - Add libdisplay-info-0.1.1 in support of plasma6. Addresses #19373.

    • [bdubbs] - Add hwdata-0.380 in support of plasma6. Addresses #19373.

    • [bdubbs] - Add kirigami-addons-1.0.1 in support of plasma6. Addresses #19373.

    • [bdubbs] - Add qcoro-0.10.0 in support of plasma6. Addresses #19373.

    • [thomas] - Update to libxml2-2.12.6. Fixes #19468.

    • [xry111] - Archive wpebackend-fdo and libwpe. Fixes #18460.

    • [xry111] - Update to WebKitGTK-2.44.0. Fixes #19478.

  • March 16th, 2024

    • [timtas] - Update to mesa-24.0.3. Fixes #19459.

  • March 15th, 2024

    • [rahul] - Update to icewm-3.4.6. Fixes #19430.

    • [rahul] - Update to unbound-1.19.3 (Security Update). Fixes #19429.

    • [rahul] - Update to bluez-5.73. Fixes #19428.

    • [rahul] - Update to gnupg-2.4.5. Fixes #19426.

    • [thomas] - Upgrade to sqlite-3.45.2. Fixes #19456.

  • March 14th, 2024

    • [xry111] - Add dtc-1.7.0 for supporting qemu-8.2.2.

  • March 12th, 2024

    • [ken] - Update to mutt-2.2.13. Fixes #19441.

    • [thomas] - Update to openssh-9.7p1, ssh-askpass-9.7p1. Fixes #19452.

  • March 10th, 2024

    • [ken] - Update to asymptote-2.88. Fixes #19372.

    • [xry111] - Update to glib-2.80.0. Fixes #19444.

    • [xry111] - Update to gobject-introspection-1.80.0. Fixes #19439.

    • [xry111] - Combine gobject-introspection into glib page to better handle the circular dependency between these two packages.

  • March 9th, 2024

    • [ken] - Update to dvisvgm-3.2.2. Fixes #19384.

    • [ken] - Update to ghostscript-10.03.0 (Security Update). Fixes #19423.

    • [thomas] - Upgrade to postfix-3.9.0. Fixes #19436.

    • [thomas] - Upgrade to libxfce4ui-4.18.6. Fixes #19436.

  • March 7th, 2024

    • [bdubbs] - Revert to pytest-8.0.2 (Python Module). Fixes #19417.

    • [renodr] - Update to pyparsing-3.1.2 (Python Module). Fixes #19416.

    • [renodr] - Update to libassuan-2.5.7. Fixes #19415.

    • [renodr] - Update to SDL2-2.30.1. Fixes #19412.

    • [renodr] - Update to umockdev-0.18.0. Fixes #19399.

    • [renodr] - Update to opus-1.5.1. Fixes #19409.

    • [renodr] - Update to uhttpmock-0.10.0. Fixes #19406.

    • [renodr] - Update to vala-0.56.15. Fixes #19405.

    • [renodr] - Update to mkfontscale-1.2.3, xauth-1.1.3, xev-1.2.6, xmessage-1.0.7, xpr-1.2.0, and xrefresh-1.1.0 (Xorg Applications). Fixes #19402.

    • [renodr] - Update to gdb-14.2. Fixes #19398.

  • March 6th, 2024

    • [xry111] - Update to SeaMonkey-2.53.18.1 (Security Update). Fixes #19420.

    • [xry111] - Update to LLVM-18.1.0. Fixes #19413.

    • [renodr] - Update to thunderbird-115.8.1 (Security Update). Fixes #19411.

    • [renodr] - Update to xf86-input-wacom-1.2.1 (Xorg Driver). Fixes #19403.

    • [renodr] - Update to gtk-doc-1.34.0. Fixes #19410.

    • [renodr] - Update to gnome-maps-45.5. Fixes #19397.

    • [renodr] - Update to gcr-4.2.1. Fixes #19396.

    • [renodr] - Update to libadwaita-1.4.4. Fixes #19395.

    • [renodr] - Update to pytest-8.1.0 (Python Module). Fixes #19401.

    • [bdubbs] - Finish updating to kf6-apps. Fixes #19375.

    • [xry111] - Archive PCRE1. Fixes #18893.

  • March 5th, 2024

    • [renodr] - Update to libreoffice-24.2.1.2. Fixes #19382.

    • [timtas] - Update to qemu-8.2.2. Fixes #19404.

  • March 4th, 2024

    • [bdubbs] - Update to poppler-24.03.0. Fixes #19400.

  • March 4th, 2024

    • [bdubbs] - Update to kImageAnnotator-0.7.1. Fixes #19388.

    • [bdubbs] - Update to kColorPicker-0.3.1. Fixes #19387.

    • [bdubbs] - Preliminary update to kf6-6.0.0.

  • March 3rd, 2024

    • [bdubbs] - Update to encodings-1.1.0 (Xorg Font). Fixes #19393.

    • [bdubbs] - Update to libXcursor-1.2.2 (Xorg Library) and libfontenc-1.1.8 (Xorg Library). Fixes #19392 and #19389.

    • [bdubbs] - Update to libxcb-1.16.1. Fixes #19391.

    • [bdubbs] - Update to libXdmcp-1.1.5. Fixes #19394.

    • [bdubbs] - Update to nghttp2-1.60.0. Fixes #19386.

    • [bdubbs] - Update to mdadm-4.3. Fixes #19377.

    • [bdubbs] - Update to pixman-0.43.4. Fixes #19376.

    • [bdubbs] - Update to mesa-24.0.2. Fixes #19374.

    • [bdubbs] - Update to a52dec-0.8.0. Fixes #19368.

    • [bdubbs] - Update to swig-4.2.1. Fixes #19365.

    • [bdubbs] - Update to qpdf-11.9.0. Fixes #19363.

    • [bdubbs] - Update to libunistring-1.2. Fixes #19361.

    • [bdubbs] - Update to libpng-1.6.43. Fixes #19354.

    • [bdubbs] - Update to mupdf-1.23.11. Fixes #19347.

    • [bdubbs] - Update to polkit-qt-1-0.200.0. Fixes #19345.

    • [bdubbs] - Update to python-dbusmock-0.31.1 (Python module). Fixes #19356.

    • [bdubbs] - Update to npth-1.7. Fixes #19353.

    • [bdubbs] - Update to libksba-1.6.6. Fixes #19352.

    • [bdubbs] - Update to libgpg-error-1.48. Fixes #19351.

    • [thomas] - Update to pciutils-3.11.1. Fixes #19364.

    • [xry111] - Update to shadow-4.14.6. Fixes #19385.

  • March 2nd, 2024

    • [renodr] - Update to epiphany-45.3. Fixes #19381.

    • [renodr] - Update to glib-networking-2.78.1. Fixes #19378.

    • [renodr] - Update to AppStream-1.0.2. Fixes #19362.

    • [renodr] - Update to libsecret-0.21.4. Fixes #19358.

    • [renodr] - Update to glm-1.0.1. Fixes #19369.

    • [renodr] - Update to OpenJPEG-2.5.2 (Security Update). Fixes #19370.

    • [renodr] - Update to c-ares-1.27.0 (Security Update). Fixes #19357.

    • [renodr] - Update to NetworkManager-1.46.0. Fixes #19350.

    • [renodr] - Update to Spidermonkey-115.8.0. Fixes #19344.

    • [bdubbs] - Update to asciidoctor-2.0.21. Fixes #19341.

    • [bdubbs] - Update to mpg123-1.32.5. Fixes #19328.

    • [bdubbs] - Update to pytest-8.0.2 (Python module). Fixes #19326.

    • [bdubbs] - Update to pcre2-10.43. Fixes #19062.

    • [renodr] - Enable support for Vulkan in ffmpeg again. Fixes #19390.

    • [renodr] - Update to jasper-4.2.1. Fixes #19340.

    • [renodr] - Update to Vulkan-Headers and Vulkan-Loader 1.3.279. Fixes #19327.

    • [renodr] - Update to giflib-5.2.2 (Security Update). Fixes #19335.

    • [bdubbs] - Update to unrar-7.0.7. Fixes #18768.

    • [timtas] - Update to xfce4-panel-4.18.6. Fixes #19379.

    • [timtas] - Update to xarchiver-0.5.4.23. Fixes #19383.

    • [timtas] - Update to xfce4-terminal-1.1.3. Fixes #19380.

  • March 1st, 2024

    • [bdubbs] - Release of BLFS-12.1.

Mailing Lists

The linuxfromscratch.org server is hosting a number of mailing lists that are used for the development of the BLFS book. These lists include, among others, the main development and support lists.

For more information regarding which lists are available, how to subscribe to them, archive locations, etc., visit https://www.linuxfromscratch.org/mail.html.

Editor Notes

The BLFS Project has created a Wiki for editors to comment on pages and instructions at https://wiki.linuxfromscratch.org/blfs/wiki.

When editor notes are present, a link appears in the form https://wiki.linuxfromscratch.org/blfs/wiki/pkgname right below the dependency list. The idea behind the editor notes is to give additional information about the package and/or its build instructions, common pitfalls or maybe even more sophisticated configuration for special cases of use.

The vast majority of the packages do not have editor notes.

Note

The editor notes might be outdated. Even though the pages should be reviewed when a package is updated, it might happen that there are notes referring to an obsolete version and therefore, the notes might be out of date. Always check the date of the notes and more importantly, the version of the package the notes refer to.

Asking for Help and the FAQ

If you encounter a problem while using this book, and your problem is not listed in the FAQ (https://www.linuxfromscratch.org/faq), you will find that most of the people on Internet Relay Chat (IRC) and on the mailing lists are willing to help you. An overview of the LFS mailing lists can be found in Mailing lists. To assist us in diagnosing and solving your problem, include as much relevant information as possible in your request for help.

Things to Check Prior to Asking

Before asking for help, you should review the following items:

  • Is the hardware support compiled into the kernel or available as a module to the kernel? If it is a module, is it configured properly in modprobe.conf and has it been loaded? You should use lsmod as the root user to see if it's loaded. Check the sys.log file or run modprobe <driver> to review any error message. If it loads properly, you may need to add the modprobe command to your boot scripts.

  • Are your permissions properly set, especially for devices? LFS uses groups to make these settings easier, but it also adds the step of adding users to groups to allow access. A simple usermod -G audio <user> may be all that's necessary for that user to have access to the sound system. Any question that starts out with It works as root, but not as ... requires a thorough review of permissions prior to asking.

  • BLFS liberally uses /opt/<package>. The main objection to this centers around the need to expand your environment variables for each package placed there (e.g., PATH=$PATH:/opt/kde/bin). In most cases, the package instructions will walk you through the changes, but some will not. The section called Going Beyond BLFS is available to help you check.

Things to Mention

Apart from a brief explanation of the problem you're having, the essential things to include in your request are:

  • the version of the book you are using (being 12.2),

  • the package or section giving you problems,

  • the exact error message or symptom you are receiving,

  • whether you have deviated from the book or LFS at all,

  • if you are installing a BLFS package on a non-LFS system.

(Note that saying that you've deviated from the book doesn't mean that we won't help you. It'll just help us to see other possible causes of your problem.)

Expect guidance instead of specific instructions. If you are instructed to read something, please do so. It generally implies that the answer was way too obvious and that the question would not have been asked if a little research was done prior to asking. The volunteers in the mailing list prefer not to be used as an alternative to doing reasonable research on your end. In addition, the quality of your experience with BLFS is also greatly enhanced by this research, and the quality of volunteers is enhanced because they don't feel that their time has been abused, so they are far more likely to participate.

An excellent article on asking for help on the Internet in general has been written by Eric S. Raymond. It is available online at http://www.catb.org/~esr/faqs/smart-questions.html. Read and follow the hints in that document and you are much more likely to get a response to start with and also to get the help you actually need.

Credits

Many people have contributed both directly and indirectly to BLFS. This page lists all of those we can think of. We may well have left people out and if you feel this is the case, drop us a line. Many thanks to all of the LFS community for their assistance with this project.

Current Editors

  • Rahul Chandra

  • Bruce Dubbs

  • Pierre Labastie

  • Ken Moffat

  • Douglas Reno

  • Xi Ruoyao

  • Thomas Trepl

Contributors and Past Editors

The list of contributors is far too large to provide detailed information about the contributions for each contributor. Over the years, the following individuals have provided significant inputs to the book:

  • Timothy Bauscher

  • Daniel Bauman

  • Jeff Bauman

  • Andy Benton

  • Wayne Blaszczyk

  • Paul Campbell

  • Nathan Coulson

  • Jeroen Coumans

  • Guy Dalziel

  • Robert Daniels

  • Richard Downing

  • Manuel Canales Esparcia

  • Jim Gifford

  • Manfred Glombowski

  • Ag Hatzimanikas

  • Mark Hymers

  • James Iwanek

  • David Jensen

  • Jeremy Jones

  • Seth Klein

  • Alex Kloss

  • Eric Konopka

  • Larry Lawrence

  • D-J Lucas

  • Chris Lynn

  • Andrew McMurry

  • Randy McMurchy

  • Denis Mugnier

  • Billy O'Connor

  • Fernando de Oliveira

  • Alexander Patrakov

  • Olivier Peres

  • Andreas Pedersen

  • Henning Rohde

  • Matt Rogers

  • James Robertson

  • Henning Rohde

  • Chris Staub

  • Jesse Tie-Ten-Quee

  • Ragnar Thomsen

  • Tushar Teredesai

  • Jeremy Utley

  • Zack Winkles

  • Christian Wurst

  • Igor Živković

General Acknowledgments

  • Fernando Arbeiza

  • Miguel Bazdresch

  • Gerard Beekmans

  • Oliver Brakmann

  • Jeremy Byron

  • Ian Chilton

  • David Ciecierski

  • Jim Harris

  • Lee Harris

  • Marc Heerdink

  • Steffen Knollmann

  • Eric Konopka

  • Scot McPherson

  • Ted Riley

Contact Information

Please direct your emails to one of the BLFS mailing lists. See Mailing lists for more information on the available mailing lists.

Chapter 2. Important Information

This chapter is used to explain some of the policies used throughout the book, to introduce important concepts and to explain some issues you may see with some of the included packages.

Notes on Building Software

Those people who have built an LFS system may be aware of the general principles of downloading and unpacking software. Some of that information is repeated here for those new to building their own software.

Each set of installation instructions contains a URL from which you can download the package. The patches; however, are stored on the LFS servers and are available via HTTP. These are referenced as needed in the installation instructions.

While you can keep the source files anywhere you like, we assume that you have unpacked the package and changed into the directory created by the unpacking process (the source directory). We also assume you have uncompressed any required patches and they are in the directory immediately above the source directory.

We can not emphasize strongly enough that you should start from a clean source tree each time. This means that if you have had an error during configuration or compilation, it's usually best to delete the source tree and re-unpack it before trying again. This obviously doesn't apply if you're an advanced user used to hacking Makefiles and C code, but if in doubt, start from a clean tree.

Building Software as an Unprivileged (non-root) User

The golden rule of Unix System Administration is to use your superpowers only when necessary. Hence, BLFS recommends that you build software as an unprivileged user and only become the root user when installing the software. This philosophy is followed in all the packages in this book. Unless otherwise specified, all instructions should be executed as an unprivileged user. The book will advise you on instructions that need root privileges.

Unpacking the Software

If a file is in .tar format and compressed, it is unpacked by running one of the following commands:

tar -xvf filename.tar.gz
tar -xvf filename.tgz
tar -xvf filename.tar.Z
tar -xvf filename.tar.bz2

Note

You may omit using the v parameter in the commands shown above and below if you wish to suppress the verbose listing of all the files in the archive as they are extracted. This can help speed up the extraction as well as make any errors produced during the extraction more obvious to you.

You can also use a slightly different method:

bzcat filename.tar.bz2 | tar -xv

Finally, sometimes we have a compressed patch file in .patch.gz or .patch.bz2 format. The best way to apply the patch is piping the output of the decompressor to the patch utility. For example:

gzip -cd ../patchname.patch.gz | patch -p1

Or for a patch compressed with bzip2:

bzcat ../patchname.patch.bz2 | patch -p1

Verifying File Integrity

Generally, to verify that the downloaded file is complete, many package maintainers also distribute md5sums of the files. To verify the md5sum of the downloaded files, download both the file and the corresponding md5sum file to the same directory (preferably from different on-line locations), and (assuming file.md5sum is the md5sum file downloaded) run the following command:

md5sum -c file.md5sum

If there are any errors, they will be reported. Note that the BLFS book includes md5sums for all the source files also. To use the BLFS supplied md5sums, you can create a file.md5sum (place the md5sum data and the exact name of the downloaded file on the same line of a file, separated by white space) and run the command shown above. Alternately, simply run the command shown below and compare the output to the md5sum data shown in the BLFS book.

md5sum <name_of_downloaded_file>

MD5 is not cryptographically secure, so the md5sums are only provided for detecting unmalicious changes to the file content. For example, an error or truncation introduced during network transfer, or a stealth update to the package from the upstream (updating the content of a released tarball instead of making a new release properly).

There is no 100% secure way to make sure the genuity of the source files. Assuming the upstream is managing their website correctly (the private key is not leaked and the domain is not hijacked), and the trust anchors have been set up correctly using make-ca-1.14 on the BLFS system, we can reasonably trust download URLs to the upstream official website with https protocol. Note that BLFS book itself is published on a website with https, so you should already have some confidence in https protocol or you wouldn't trust the book content.

If the package is downloaded from an unofficial location (for example a local mirror), checksums generated by cryptographically secure digest algorithms (for example SHA256) can be used to verify the genuity of the package. Download the checksum file from the upstream official website (or somewhere you can trust) and compare the checksum of the package from unofficial location with it. For example, SHA256 checksum can be checked with the command:

Note

If the checksum and the package are downloaded from the same untrusted location, you won't gain security enhancement by verifying the package with the checksum. The attacker can fake the checksum as well as compromising the package itself.

sha256sum -c file.sha256sum

If GnuPG-2.4.5 is installed, you can also verify the genuity of the package with a GPG signature. Import the upstream GPG public key with:

gpg --recv-key keyID

keyID should be replaced with the key ID from somewhere you can trust (for example, copy it from the upstream official website using https). Now you can verify the signature with:

gpg --recv-key file.sig file

The advantage of GnuPG signature is, once you imported a public key which can be trusted, you can download both the package and its signature from the same unofficial location and verify them with the public key. So you won't need to connect to the official upstream website to retrieve a checksum for each new release. You only need to update the public key if it's expired or revoked.

Creating Log Files During Installation

For larger packages, it is convenient to create log files instead of staring at the screen hoping to catch a particular error or warning. Log files are also useful for debugging and keeping records. The following command allows you to create an installation log. Replace <command> with the command you intend to execute.

( <command> 2>&1 | tee compile.log && exit $PIPESTATUS )

2>&1 redirects error messages to the same location as standard output. The tee command allows viewing of the output while logging the results to a file. The parentheses around the command run the entire command in a subshell and finally the exit $PIPESTATUS command ensures the result of the <command> is returned as the result and not the result of the tee command.

Using Multiple Processors

For many modern systems with multiple processors (or cores) the compilation time for a package can be reduced by performing a "parallel make" by either setting an environment variable or telling the make program to simultaneously execute multiple jobs.

For instance, an Intel Core i9-13900K CPU contains 8 performance (P) cores and 16 efficiency (E) cores, and the P cores support SMT (Simultaneous MultiThreading, also known as Hyper-Threading) so each P core can run two threads simultaneously and the Linux kernel will treat each P core as two logical cores. As a result, there are 32 logical cores in total. To utilize all these logical cores running make, we can set an environment variable to tell make to run 32 jobs simultaneously:

export MAKEFLAGS='-j32'

or just building with:

make -j32

If you have applied the optional sed when building ninja in LFS, you can use:

export NINJAJOBS=32

when a package uses ninja, or just:

ninja -j32

If you are not sure about the number of logical cores, run the nproc command.

For make, the default number of jobs is 1. But for ninja, the default number of jobs is N + 2 if the number of logical cores N is greater than 2; or N + 1 if N is 1 or 2. The reason to use a number of jobs slightly greater than the number of logical cores is keeping all logical processors busy even if some jobs are performing I/O operations.

Note that the -j switches only limits the parallel jobs started by make or ninja, but each job may still spawn its own processes or threads. For example, ld.gold will use multiple threads for linking, and some tests of packages can spawn multiple threads for testing thread safety properties. There is no generic way for the building system to know the number of processes or threads spawned by a job. So generally we should not consider the value passed with -j a hard limit of the number of logical cores to use. Read the section called “Use Linux Control Group to Limit the Resource Usage” if you want to set such a hard limit.

Generally the number of processes should not exceed the number of cores supported by the CPU too much. To list the processors on your system, issue: grep processor /proc/cpuinfo.

In some cases, using multiple processes may result in a race condition where the success of the build depends on the order of the commands run by the make program. For instance, if an executable needs File A and File B, attempting to link the program before one of the dependent components is available will result in a failure. This condition usually arises because the upstream developer has not properly designated all the prerequisites needed to accomplish a step in the Makefile.

If this occurs, the best way to proceed is to drop back to a single processor build. Adding -j1 to a make command will override the similar setting in the MAKEFLAGS environment variable.

Important

Another problem may occur with modern CPU's, which have a lot of cores. Each job started consumes memory, and if the sum of the needed memory for each job exceeds the available memory, you may encounter either an OOM (Out of Memory) kernel interrupt or intense swapping that will slow the build beyond reasonable limits.

Some compilations with g++ may consume up to 2.5 GB of memory, so to be safe, you should restrict the number of jobs to (Total Memory in GB)/2.5, at least for big packages such as LLVM, WebKitGtk, QtWebEngine, or libreoffice.

Use Linux Control Group to Limit the Resource Usage

Sometimes we want to limit the resource usage when we build a package. For example, when we have 8 logical cores, we may want to use only 6 cores for building the package and reserve another 2 cores for playing a movie. The Linux kernel provides a feature called control groups (cgroup) for such a need.

Enable control group in the kernel configuration, then rebuild the kernel and reboot if necessary:

General setup --->
  [*] Control Group support --->                                       [CGROUPS]
    [*] Memory controller                                                [MEMCG]
    [*] Cpuset controller                                              [CPUSETS]

Ensure Systemd-256.4 and Shadow-4.16.0 have been rebuilt with Linux-PAM-1.6.1 support (if you are interacting via a SSH or graphical session, also ensure the OpenSSH-9.8p1 server or the desktop manager has been built with Linux-PAM-1.6.1). As the root user, create a configuration file to allow resource control without root privilege, and instruct systemd to reload the configuration:

mkdir -pv /etc/systemd/system/user@.service.d &&
cat > /etc/systemd/system/user@.service.d/delegate.conf << EOF &&
[Service]
Delegate=memory cpuset
EOF
systemctl daemon-reload

Then logout and login again. Now to run make -j5 with the first 4 logical cores and 8 GB of system memory, issue:

systemctl   --user start dbus                &&
systemd-run --user --pty --pipe --wait -G -d \
            -p MemoryHigh=8G                 \
            -p AllowedCPUs=0-3               \
            make -j5

With MemoryHigh=8G , a soft limit of memory usage is set. If the processes in the cgroup (make and all the descendants of it) uses more than 8 GB of system memory in total, the kernel will throttle down the processes and try to reclaim the system memory from them. But they can still use more than 8 GB of system memory. If you want to make a hard limit instead, replace MemoryHigh with MemoryMax. But doing so will cause the processes killed if 8 GB is not enough for them.

AllowedCPUs=0-3 makes the kernel only run the processes in the cgroup on the logical cores with numbers 0, 1, 2, or 3. You may need to adjust this setting based the mapping between the logical cores and the physical cores. For example, with an Intel Core i9-13900K CPU, the logical cores 0, 2, 4, ..., 14 are mapped to the first threads of the eight physical P cores, the logical cores 1, 3, 5, ..., 15 are mapped to the second threads of the physical P cores, and the logical cores 16, 17, ..., 31 are mapped to the 16 physical E cores. So if we want to use four threads from four different P cores, we need to specify 0,2,4,6 instead of 0-3. Note that the other CPU models may use a different mapping scheme. If you are not sure about the mapping between the logical cores and the physical cores, run the lscpu --extended command which will output logical core IDs in the CPU column, and physical core IDs in the CORE column.

When the nproc or ninja command runs in a cgroup, it will use the number of logical cores assigned to the cgroup as the system logical core count. For example, in a cgroup with logical cores 0-3 assigned, nproc will print 4, and ninja will run 6 (4 + 2) jobs simultaneously if no -j setting is explicitly given.

Read the man pages systemd-run(1) and systemd.resource-control(5) for the detailed explanation of parameters in the command.

Automated Building Procedures

There are times when automating the building of a package can come in handy. Everyone has their own reasons for wanting to automate building, and everyone goes about it in their own way. Creating Makefiles, Bash scripts, Perl scripts or simply a list of commands used to cut and paste are just some of the methods you can use to automate building BLFS packages. Detailing how and providing examples of the many ways you can automate the building of packages is beyond the scope of this section. This section will expose you to using file redirection and the yes command to help provide ideas on how to automate your builds.

File Redirection to Automate Input

You will find times throughout your BLFS journey when you will come across a package that has a command prompting you for information. This information might be configuration details, a directory path, or a response to a license agreement. This can present a challenge to automate the building of that package. Occasionally, you will be prompted for different information in a series of questions. One method to automate this type of scenario requires putting the desired responses in a file and using redirection so that the program uses the data in the file as the answers to the questions.

This effectively makes the test suite use the responses in the file as the input to the questions. Occasionally you may end up doing a bit of trial and error determining the exact format of your input file for some things, but once figured out and documented you can use this to automate building the package.

Using yes to Automate Input

Sometimes you will only need to provide one response, or provide the same response to many prompts. For these instances, the yes command works really well. The yes command can be used to provide a response (the same one) to one or more instances of questions. It can be used to simulate pressing just the Enter key, entering the Y key or entering a string of text. Perhaps the easiest way to show its use is in an example.

First, create a short Bash script by entering the following commands:

cat > blfs-yes-test1 << "EOF"
#!/bin/bash

echo -n -e "\n\nPlease type something (or nothing) and press Enter ---> "

read A_STRING

if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed"
else A_STRING="You entered '$A_STRING'"
fi

echo -e "\n\n$A_STRING\n\n"
EOF
chmod 755 blfs-yes-test1

Now run the script by issuing ./blfs-yes-test1 from the command line. It will wait for a response, which can be anything (or nothing) followed by the Enter key. After entering something, the result will be echoed to the screen. Now use the yes command to automate the entering of a response:

yes | ./blfs-yes-test1

Notice that piping yes by itself to the script results in y being passed to the script. Now try it with a string of text:

yes 'This is some text' | ./blfs-yes-test1

The exact string was used as the response to the script. Finally, try it using an empty (null) string:

yes '' | ./blfs-yes-test1

Notice this results in passing just the press of the Enter key to the script. This is useful for times when the default answer to the prompt is sufficient. This syntax is used in the Net-tools instructions to accept all the defaults to the many prompts during the configuration step. You may now remove the test script, if desired.

File Redirection to Automate Output

In order to automate the building of some packages, especially those that require you to read a license agreement one page at a time, requires using a method that avoids having to press a key to display each page. Redirecting the output to a file can be used in these instances to assist with the automation. The previous section on this page touched on creating log files of the build output. The redirection method shown there used the tee command to redirect output to a file while also displaying the output to the screen. Here, the output will only be sent to a file.

Again, the easiest way to demonstrate the technique is to show an example. First, issue the command:

ls -l /usr/bin | less

Of course, you'll be required to view the output one page at a time because the less filter was used. Now try the same command, but this time redirect the output to a file. The special file /dev/null can be used instead of the filename shown, but you will have no log file to examine:

ls -l /usr/bin | less > redirect_test.log 2>&1

Notice that this time the command immediately returned to the shell prompt without having to page through the output. You may now remove the log file.

The last example will use the yes command in combination with output redirection to bypass having to page through the output and then provide a y to a prompt. This technique could be used in instances when otherwise you would have to page through the output of a file (such as a license agreement) and then answer the question of do you accept the above?. For this example, another short Bash script is required:

cat > blfs-yes-test2 << "EOF"
#!/bin/bash

ls -l /usr/bin | less

echo -n -e "\n\nDid you enjoy reading this? (y,n) "

read A_STRING

if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key"
else A_STRING="You did NOT enter the 'y' key"
fi

echo -e "\n\n$A_STRING\n\n"
EOF
chmod 755 blfs-yes-test2

This script can be used to simulate a program that requires you to read a license agreement, then respond appropriately to accept the agreement before the program will install anything. First, run the script without any automation techniques by issuing ./blfs-yes-test2.

Now issue the following command which uses two automation techniques, making it suitable for use in an automated build script:

yes | ./blfs-yes-test2 > blfs-yes-test2.log 2>&1

If desired, issue tail blfs-yes-test2.log to see the end of the paged output, and confirmation that y was passed through to the script. Once satisfied that it works as it should, you may remove the script and log file.

Finally, keep in mind that there are many ways to automate and/or script the build commands. There is not a single correct way to do it. Your imagination is the only limit.

Dependencies

For each package described, BLFS lists the known dependencies. These are listed under several headings, whose meaning is as follows:

  • Required means that the target package cannot be correctly built without the dependency having first been installed, except if the dependency is said to be runtime which means the target package can be built but cannot function without it.

    Note that a target package can start to function in many subtle ways: an installed configuration file can make the init system, cron daemon, or bus daemon to run a program automatically; another package using the target package as a dependency can run a program from the target package in the building system; and the configuration sections in the BLFS book may also run a program from a just installed package. So if you are installing the target package without a Required (runtime) dependency installed, You should install the dependency as soon as possible after the installation of the target package.

  • Recommended means that BLFS strongly suggests this package is installed first (except if said to be runtime, see below) for a clean and trouble-free build, that won't have issues either during the build process, or at run-time. The instructions in the book assume these packages are installed. Some changes or workarounds may be required if these packages are not installed. If a recommended dependency is said to be runtime, it means that BLFS strongly suggests that this dependency is installed before using the package, for getting full functionality.

  • Optional means that this package might be installed for added functionality. Often BLFS will describe the dependency to explain the added functionality that will result. Some optional dependencies are automatically picked up by the target package if the dependency is installed, while others also need additional configuration options to be enabled when the target package is built. Such additional options are often documented in the BLFS book. If an optional dependency is said to be runtime, it means you may install the dependency after installing the target package to support some optional features of the target package if you need these features.

    An optional dependency may be out of BLFS. If you need such an external optional dependency for some features you need, read Going Beyond BLFS for the general hint about installing an out-of-BLFS package.

Using the Most Current Package Sources

On occasion you may run into a situation in the book when a package will not build or work properly. Though the Editors attempt to ensure that every package in the book builds and works properly, sometimes a package has been overlooked or was not tested with this particular version of BLFS.

If you discover that a package will not build or work properly, you should see if there is a more current version of the package. Typically this means you go to the maintainer's web site and download the most current tarball and attempt to build the package. If you cannot determine the maintainer's web site by looking at the download URLs, use Google and query the package's name. For example, in the Google search bar type: 'package_name download' (omit the quotes) or something similar. Sometimes typing: 'package_name home page' will result in you finding the maintainer's web site.

Stripping One More Time

In LFS, stripping of debugging symbols and unneeded symbol table entries was discussed a couple of times. When building BLFS packages, there are generally no special instructions that discuss stripping again. Stripping can be done while installing a package, or afterwards.

Stripping while Installing a Package

There are several ways to strip executables installed by a package. They depend on the build system used (see below the section about build systems), so only some generalities can be listed here:

Note

The following methods using the feature of a building system (autotools, meson, or cmake) will not strip static libraries if any is installed. Fortunately there are not too many static libraries in BLFS, and a static library can always be stripped safely by running strip --strip-unneeded on it manually.

  • The packages using autotools usually have an install-strip target in their generated Makefile files. So installing stripped executables is just a matter of using make install-strip instead of make install.

  • The packages using the meson build system can accept -D strip=true when running meson. If you've forgot to add this option running the meson, you can also run meson install --strip instead of ninja install.

  • cmake generates install/strip targets for both the Unix Makefiles and Ninja generators (the default is Unix Makefiles on linux). So just run make install/strip or ninja install/strip instead of the install counterparts.

  • Removing (or not generating) debug symbols can also be achieved by removing the -g<something> options in C/C++ calls. How to do that is very specific for each package. And, it does not remove unneeded symbol table entries. So it will not be explained in detail here. See also below the paragraphs about optimization.

Stripping Installed Executables

The strip utility changes files in place, which may break anything using it if it is loaded in memory. Note that if a file is in use but just removed from the disk (i.e. not overwritten nor modified), this is not a problem since the kernel can use deleted files. Look at /proc/*/maps and it is likely that you'll see some (deleted) entries. The mv just removes the destination file from the directory but does not touch its content, so that it satisfies the condition for the kernel to use the old (deleted) file. But this approach can detach hard links into duplicated copies, causing a bloat which is obviously unwanted as we are stripping to reduce system size. If two files in a same file system share the same inode number, they are hard links to each other and we should reconstruct the link. The script below is just an example. It should be run as the root user:

cat > /usr/sbin/strip-all.sh << "EOF"
#!/usr/bin/bash

if [ $EUID -ne 0 ]; then
  echo "Need to be root"
  exit 1
fi

last_fs_inode=
last_file=

{ find /usr/lib -type f -name '*.so*' ! -name '*dbg'
  find /usr/lib -type f -name '*.a'
  find /usr/{bin,sbin,libexec} -type f
} | xargs stat -c '%m %i %n' | sort | while read fs inode file; do
       if ! readelf -h $file >/dev/null 2>&1; then continue; fi
       if file $file | grep --quiet --invert-match 'not stripped'; then continue; fi

       if [ "$fs $inode" = "$last_fs_inode" ]; then
         ln -f $last_file $file;
         continue;
       fi

       cp --preserve $file    ${file}.tmp
       strip --strip-unneeded ${file}.tmp
       mv ${file}.tmp $file

       last_fs_inode="$fs $inode"
       last_file=$file
done
EOF
chmod 744 /usr/sbin/strip-all.sh

If you install programs in other directories such as /opt or /usr/local, you may want to strip the files there too. Just add other directories to scan in the compound list of find commands between the braces.

For more information on stripping, see https://www.technovelty.org/linux/stripping-shared-libraries.html.

Working with different build systems

There are now three different build systems in common use for converting C or C++ source code into compiled programs or libraries and their details (particularly, finding out about available options and their default values) differ. It may be easiest to understand the issues caused by some choices (typically slow execution or unexpected use of, or omission of, optimizations) by starting with the CFLAGS, CXXFLAGS, and LDFLAGS environment variables. There are also some programs which use Rust.

Most LFS and BLFS builders are probably aware of the basics of CFLAGS and CXXFLAGS for altering how a program is compiled. Typically, some form of optimization is used by upstream developers (-O2 or -O3), sometimes with the creation of debug symbols (-g), as defaults.

If there are contradictory flags (e.g. multiple different -O values), the last value will be used. Sometimes this means that flags specified in environment variables will be picked up before values hardcoded in the Makefile, and therefore ignored. For example, where a user specifies -O2 and that is followed by -O3 the build will use -O3.

There are various other things which can be passed in CFLAGS or CXXFLAGS, such as allowing using the instruction set extensions available with a specific microarchitecture (e.g. -march=amdfam10 or -march=native), tune the generated code for a specific microarchitecture (e. g. -mtune=tigerlake or -mtune=native, if -mtune= is not used, the microarchitecture from -march= setting will be used), or specifying a specific standard for C or C++ (-std=c++17 for example). But one thing which has now come to light is that programmers might include debug assertions in their code, expecting them to be disabled in releases by using -D NDEBUG. Specifically, if Mesa-24.1.5 is built with these assertions enabled, some activities such as loading levels of games can take extremely long times, even on high-class video cards.

Autotools with Make

This combination is often described as CMMI (configure, make, make install) and is used here to also cover the few packages which have a configure script that is not generated by autotools.

Sometimes running ./configure --help will produce useful options about switches which might be used. At other times, after looking at the output from configure you may need to look at the details of the script to find out what it was actually searching for.

Many configure scripts will pick up any CFLAGS or CXXFLAGS from the environment, but CMMI packages vary about how these will be mixed with any flags which would otherwise be used (variously: ignored, used to replace the programmer's suggestion, used before the programmer's suggestion, or used after the programmer's suggestion).

In most CMMI packages, running make will list each command and run it, interspersed with any warnings. But some packages try to be silent and only show which file they are compiling or linking instead of showing the command line. If you need to inspect the command, either because of an error, or just to see what options and flags are being used, adding V=1 to the make invocation may help.

CMake

CMake works in a very different way, and it has two backends which can be used on BLFS: make and ninja. The default backend is make, but ninja can be faster on large packages with multiple processors. To use ninja, specify -G Ninja in the cmake command. However, there are some packages which create fatal errors in their ninja files but build successfully using the default of Unix Makefiles.

The hardest part of using CMake is knowing what options you might wish to specify. The only way to get a list of what the package knows about is to run cmake -LAH and look at the output for that default configuration.

Perhaps the most-important thing about CMake is that it has a variety of CMAKE_BUILD_TYPE values, and these affect the flags. The default is that this is not set and no flags are generated. Any CFLAGS or CXXFLAGS in the environment will be used. If the programmer has coded any debug assertions, those will be enabled unless -D NDEBUG is used. The following CMAKE_BUILD_TYPE values will generate the flags shown, and these will come after any flags in the environment and therefore take precedence.

Value Flags
Debug -g
Release -O3 -D NDEBUG
RelWithDebInfo -O2 -g -D NDEBUG
MinSizeRel -Os -D NDEBUG

CMake tries to produce quiet builds. To see the details of the commands which are being run, use make VERBOSE=1 or ninja -v.

By default, CMake treats file installation differently from the other build systems: if a file already exists and is not newer than a file that would overwrite it, then the file is not installed. This may be a problem if a user wants to record which file belongs to a package, either using LD_PRELOAD, or by listing files newer than a timestamp. The default can be changed by setting the variable CMAKE_INSTALL_ALWAYS to 1 in the environment, for example by export'ing it.

Meson

Meson has some similarities to CMake, but many differences. To get details of the defines that you may wish to change you can look at meson_options.txt which is usually in the top-level directory.

If you have already configured the package by running meson and now wish to change one or more settings, you can either remove the build directory, recreate it, and use the altered options, or within the build directory run meson configure, e.g. to set an option:

meson configure -D <some_option>=true

If you do that, the file meson-private/cmd_line.txt will show the last commands which were used.

Meson provides the following buildtype values, and the flags they enable come after any flags supplied in the environment and therefore take precedence.

  • plain: no added flags. This is for distributors to supply their own CFLAGS, CXXFLAGS and LDFLAGS. There is no obvious reason to use this in BLFS.

  • debug: -g - this is the default if nothing is specified in either meson.build or the command line. However it results large and slow binaries, so we should override it in BLFS.

  • debugoptimized: -O2 -g - this is the default specified in meson.build of some packages.

  • release: -O3 (occasionally a package will force -O2 here) - this is the buildtype we use for most packages with Meson build system in BLFS.

The -D NDEBUG flag is implied by the release buildtype for some packages (for example Mesa-24.1.5). It can also be provided explicitly by passing -D b_ndebug=true.

To see the details of the commands which are being run in a package using meson, use ninja -v.

Rustc and Cargo

Most released rustc programs are provided as crates (source tarballs) which will query a server to check current versions of dependencies and then download them as necessary. These packages are built using cargo --release. In theory, you can manipulate the RUSTFLAGS to change the optimize-level (default for --release is 3, i. e. -Copt-level=3, like -O3) or to force it to build for the machine it is being compiled on, using -Ctarget-cpu=native but in practice this seems to make no significant difference.

If you are compiling a standalone Rust program (as an unpackaged .rs file) by running rustc directly, you should specify -O (the abbreviation of -Copt-level=2) or -Copt-level=3 otherwise it will do an unoptimized compile and run much slower. If you are compiling the program for debugging it, replace the -O or -Copt-level= options with -g to produce an unoptimized program with debug info.

Like ninja, by default cargo uses all logical cores. This can often be worked around, either by exporting CARGO_BUILD_JOBS=<N> or passing --jobs <N> to cargo. For compiling rustc itself, specifying --jobs <N> for invocations of x.py (together with the CARGO_BUILD_JOBS environment variable, which looks like a belt and braces approach but seems to be necessary) mostly works. The exception is running the tests when building rustc, some of them will nevertheless use all online CPUs, at least as of rustc-1.42.0.

Optimizing the build

Many people will prefer to optimize compiles as they see fit, by providing CFLAGS or CXXFLAGS. For an introduction to the options available with gcc and g++ see https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html. The same content can be also found in info gcc.

Some packages default to -O2 -g, others to -O3 -g, and if CFLAGS or CXXFLAGS are supplied they might be added to the package's defaults, replace the package's defaults, or even be ignored. There are details on some desktop packages which were mostly current in April 2019 at https://www.linuxfromscratch.org/~ken/tuning/ - in particular, README.txt, tuning-1-packages-and-notes.txt, and tuning-notes-2B.txt. The particular thing to remember is that if you want to try some of the more interesting flags you may need to force verbose builds to confirm what is being used.

Clearly, if you are optimizing your own program you can spend time to profile it and perhaps recode some of it if it is too slow. But for building a whole system that approach is impractical. In general, -O3 usually produces faster programs than -O2. Specifying -march=native is also beneficial, but means that you cannot move the binaries to an incompatible machine - this can also apply to newer machines, not just to older machines. For example programs compiled for amdfam10 run on old Phenoms, Kaveris, and Ryzens, but programs compiled for a Kaveri will not run on a Ryzen because certain op-codes are not present. Similarly, if you build for a Haswell not everything will run on a SandyBridge.

Note

Be careful that the name of a -march setting does not always match the baseline of the microarchitecture with the same name. For example, the Skylake-based Intel Celeron processors do not support AVX at all, but -march=skylake assumes AVX and even AVX2.

When a shared library is built by GCC, a feature named semantic interposition is enabled by default. When the shared library refers to a symbol name with external linkage and default visibility, if the symbol exists in both the shared library and the main executable, semantic interposition guarantees the symbol in the main executable is always used. This feature was invented in an attempt to make the behavior of linking a shared library and linking a static library as similar as possible. Today only a small number of packages still depend on semantic interposition, but the feature is still on by the default of GCC, causing many optimizations disabled for shared libraries because they conflict with semantic interposition. The -fno-semantic-interposition option can be passed to gcc or g++ to disable semantic interposition and enable more optimizations for shared libraries. This option is used as the default of some packages (for example Python-3.12.5), and it's also the default of Clang.

There are also various other options which some people claim are beneficial. At worst, you get to recompile and test, and then discover that in your usage the options do not provide a benefit.

If building Perl or Python modules, in general the CFLAGS and CXXFLAGS used are those which were used by those parent packages.

For LDFLAGS, there are three options can be used for optimization. They are quite safe to use and the building system of some packages use some of these options as the default.

With -Wl,-O1, the linker will optimize the hash table to speed up the dynamic linking. Note that -Wl,-O1 is completely unrelated to the compiler optimization flag -O1.

With -Wl,--as-needed, the linker will disregard unnecessary -lfoo options from the command line, i. e. the shared library libfoo will only be linked if a symbol in libfoo is really referred from the executable or shared library being linked. This can sometimes mitigate the excessive dependencies to shared libraries issues caused by libtool.

With -Wl,-z,pack-relative-relocs, the linker generates a more compacted form of the relative relocation entries for PIEs and shared libraries. It reduces the size of the linked PIE or shared library, and speeds up the loading of the PIE or shared library.

The -Wl, prefix is necessary because despite the variable is named LDFLAGS, its content is actually passed to gcc (or g++, clang, etc.) during the link stage, not directly passed to ld.

Options for hardening the build

Even on desktop systems, there are still a lot of exploitable vulnerabilities. For many of these, the attack comes via javascript in a browser. Often, a series of vulnerabilities are used to gain access to data (or sometimes to pwn, i.e. own, the machine and install rootkits). Most commercial distros will apply various hardening measures.

In the past, there was Hardened LFS where gcc (a much older version) was forced to use hardening (with options to turn some of it off on a per-package basis). The current LFS and BLFS books are carrying forward a part of its spirit by enabling PIE (-fPIE -pie) and SSP (-fstack-protector-strong) as the defaults for GCC and clang. And, the linkers (ld.bfd and ld.gold) have also enabled -Wl,-z,relro which makes a part of the Global Offset Table (GOT) immutable, by default since Binutils 2.27. What is being covered here is different - first you have to make sure that the package is indeed using your added flags and not over-riding them.

For hardening options which are reasonably cheap, there is some discussion in the 'tuning' link above (occasionally, one or more of these options might be inappropriate for a package). These options are -D _FORTIFY_SOURCE=2 (or -D _FORTIFY_SOURCE=3 which is more secure but with a larger performance overhead) and (for C++) -D _GLIBCXX_ASSERTIONS. On modern machines these should only have a little impact on how fast things run, and often they will not be noticeable.

The main distros use much more, such as:

  • -Wl,-z,now: disables lazy binding to enhance -Wl,-z,relro, so the entire GOT can be made immutable.

  • -fstack-clash-protection: prevents the attacker from using an offset large enough and not adequately checked to jump over the stack guard page placed by the kernel and the stack canary placed by -fstack-protector=strong, and modify the stack from a heap address, or vice versa.

  • -ftrivial-auto-var-init=zero: initializes some variables by filling zero bytes if they are not initialized by other means.

  • -fcf-protection=full: utilizes Intel and AMD CET technology to limit the target addresses of control-flow transfer instructions. To make it really effective for a package, all packages providing a shared library for the package to use must be built with this option, as well as that package itself, Glibc must be configured with the --enable-cet option enabled, and the system must run on Intel Tiger Lake or newer, or AMD Zen 3 or newer. If the criteria is not met the program compiled with this option will still run, but not really protected by CET.

In GCC 14, the option -fhardened is a shorthand to enable all the hardening options mentioned above. It sets -D _FORTIFY_SOURCE=3 instead of -D _FORTIFY_SOURCE=2.

You may also encounter the so-called userspace retpoline (-mindirect-branch=thunk etc.) which is the equivalent of the spectre mitigations applied to the linux kernel in late 2018. The kernel mitigations caused a lot of complaints about lost performance, if you have a production server you might wish to consider testing that, along with the other available options, to see if performance is still sufficient.

Whilst gcc has many hardening options, clang/LLVM's strengths lie elsewhere. Some options which gcc provides are said to be less effective in clang/LLVM.

The /usr Versus /usr/local Debate

Should I install XXX in /usr or /usr/local?

This is a question without an obvious answer for an LFS based system.

In traditional Unix systems, /usr usually contains files that come with the system distribution, and the /usr/local tree is free for the local administrator to manage. The only really hard and fast rule is that Unix distributions should not touch /usr/local, except perhaps to create the basic directories within it.

With Linux distributions like Red Hat, Debian, etc., a possible rule is that /usr is managed by the distribution's package system and /usr/local is not. This way the package manager's database knows about every file within /usr.

LFS users build their own system and so deciding where the system ends and local files begin is not straightforward. So the choice should be made in order to make things easier to administer. There are several reasons for dividing files between /usr and /usr/local.

  • On a network of several machines all running LFS, or mixed LFS and other Linux distributions, /usr/local could be used to hold packages that are common between all the computers in the network. It can be NFS mounted or mirrored from a single server. Here local indicates local to the site.

  • On a network of several computers all running an identical LFS system, /usr/local could hold packages that are different between the machines. In this case local refers to the individual computers.

  • Even on a single computer, /usr/local can be useful if you have several distributions installed simultaneously, and want a place to put packages that will be the same on all of them.

  • Or you might regularly rebuild your LFS, but want a place to put files that you don't want to rebuild each time. This way you can wipe the LFS file system and start from a clean partition every time without losing everything.

Some people ask why not use your own directory tree, e.g., /usr/site, rather than /usr/local?

There is nothing stopping you, many sites do make their own trees, however it makes installing new software more difficult. Automatic installers often look for dependencies in /usr and /usr/local, and if the file it is looking for is in /usr/site instead, the installer will probably fail unless you specifically tell it where to look.

What is the BLFS position on this?

All of the BLFS instructions install programs in /usr with optional instructions to install into /opt for some specific packages.

Optional Patches

As you follow the various sections in the book, you will observe that the book occasionally includes patches that are required for a successful and secure installation of the packages. The general policy of the book is to include patches that fall in one of the following criteria:

  • Fixes a compilation problem.

  • Fixes a security problem.

  • Fixes a broken functionality.

In short, the book only includes patches that are either required or recommended. There is a Patches subproject which hosts various patches (including the patches referenced in the books) to enable you to configure your LFS the way you like it.

BLFS Systemd Units

The BLFS Systemd Units package contains the systemd unit files that are used throughout the book.

The BLFS Systemd Units package will be used throughout the BLFS book for systemd unit files. Each systemd unit has a separate install target. It is recommended that you keep the package source directory around until completion of your BLFS system. When a systemd unit is requested from BLFS Systemd Units, simply change to the directory, and as the root user, execute the given make install-<systemd-unit> command. This command installs the systemd unit to its proper location (along with any auxiliary configuration scripts) and also enables it by default.

Note

It is advisable to peruse each systemd unit before installation to determine whether the installed files meet your needs.

About Libtool Archive (.la) files

Files with a .la extension

In LFS and BLFS, many packages use an internally shipped libtool copy to build on a variety of Unix platforms. This includes platforms such as AIX, Solaris, IRIX, HP-UX, and Cygwin as well as Linux. The origins of this tool are quite dated. It was intended to manage libraries on systems with less advanced capabilities than a modern Linux system.

On a Linux system, libtool specific files are generally unneeded. Normally libraries are specified in the build process during the link phase. Since a linux system uses the Executable and Linkable Format (ELF) for executables and dynamic libraries, information needed to complete the task is embedded in the files. Both the linker and the program loader can query the appropriate files and properly link or execute the program.

Static libraries are rarely used in LFS and BLFS. And, nowadays most packages store the information needed for linking against a static library into a .pc file, instead of relying on libtool. A pkg-config --static --libs command will output the sufficient flags for the linker to link against a static library without any libtool magic.

The problem is that libtool usually creates one or more text files for package libraries called libtool archives. These small files have a ".la" extension and contain information that is similar to that embedded in the libraries or pkg-config files. When building a package that uses libtool, the process automatically looks for these files. Sometimes a .la file can contains the name or path of a static library used during build but not installed, then the build process will break because the .la file refers to something nonexistent on the system. Similarly, if a package is updated and no longer uses the .la file, then the build process can break with the old .la files.

The solution is to remove the .la files. However there is a catch. Some packages, such as ImageMagick-7.1.1-36, use a libtool function, lt_dlopen, to load libraries as needed during execution and resolve their dependencies at run time. In this case, the .la files should remain.

The script below, removes all unneeded .la files and saves them in a directory, /var/local/la-files by default, not in the normal library path. It also searches all pkg-config files (.pc) for embedded references to .la files and fixes them to be conventional library references needed when an application or library is built. It can be run as needed to clean up the directories that may be causing problems.

cat > /usr/sbin/remove-la-files.sh << "EOF"
#!/bin/bash

# /usr/sbin/remove-la-files.sh
# Written for Beyond Linux From Scratch
# by Bruce Dubbs <bdubbs@linuxfromscratch.org>

# Make sure we are running with root privs
if test "${EUID}" -ne 0; then
    echo "Error: $(basename ${0}) must be run as the root user! Exiting..."
    exit 1
fi

# Make sure PKG_CONFIG_PATH is set if discarded by sudo
source /etc/profile

OLD_LA_DIR=/var/local/la-files

mkdir -p $OLD_LA_DIR

# Only search directories in /opt, but not symlinks to directories
OPTDIRS=$(find /opt -mindepth 1 -maxdepth 1 -type d)

# Move any found .la files to a directory out of the way
find /usr/lib $OPTDIRS -name "*.la" ! -path "/usr/lib/ImageMagick*" \
  -exec mv -fv {} $OLD_LA_DIR \;
###############

# Fix any .pc files that may have .la references

STD_PC_PATH='/usr/lib/pkgconfig
             /usr/share/pkgconfig
             /usr/local/lib/pkgconfig
             /usr/local/share/pkgconfig'

# For each directory that can have .pc files
for d in $(echo $PKG_CONFIG_PATH | tr : ' ') $STD_PC_PATH; do

  # For each pc file
  for pc in $d/*.pc ; do
    if [ $pc == "$d/*.pc" ]; then continue; fi

    # Check each word in a line with a .la reference
    for word in $(grep '\.la' $pc); do
      if $(echo $word | grep -q '.la$' ); then
        mkdir -p $d/la-backup
        cp -fv  $pc $d/la-backup

        basename=$(basename $word )
        libref=$(echo $basename|sed -e 's/^lib/-l/' -e 's/\.la$//')

        # Fix the .pc file
        sed -i "s:$word:$libref:" $pc
      fi
    done
  done
done

EOF

chmod +x /usr/sbin/remove-la-files.sh

Libraries: Static or shared?

Libraries: Static or shared?

The original libraries were simply an archive of routines from which the required routines were extracted and linked into the executable program. These are described as static libraries, with names of the form libfoo.a on UNIX-like operating systems. On some old operating systems they are the only type available.

On almost all Linux platforms there are also shared (or equivalently dynamic) libraries (with names of the form libfoo.so) – one copy of the library is loaded into virtual memory, and shared by all the programs which call any of its functions. This is space efficient.

In the past, essential programs such as a shell were often linked statically so that some form of minimal recovery system would exist even if shared libraries, such as libc.so, became damaged (e.g. moved to lost+found after fsck following an unclean shutdown). Nowadays, most people use an alternative system install or a USB stick if they have to recover. Journaling filesystems also reduce the likelihood of this sort of problem.

Within the book, there are various places where configure switches such as --disable-static are employed, and other places where the possibility of using system versions of libraries instead of the versions included within another package is discussed. The main reason for this is to simplify updates of libraries.

If a package is linked to a dynamic library, updating to a newer library version is automatic once the newer library is installed and the program is (re)started (provided the library major version is unchanged, e.g. going from libfoo.so.2.0 to libfoo.so.2.1. Going to libfoo.so.3 will require recompilation – ldd can be used to find which programs use the old version). If a program is linked to a static library, the program always has to be recompiled. If you know which programs are linked to a particular static library, this is merely an annoyance. But usually you will not know which programs to recompile.

One way to identify when a static library is used, is to deal with it at the end of the installation of every package. Write a script to find all the static libraries in /usr/lib or wherever you are installing to, and either move them to another directory so that they are no longer found by the linker, or rename them so that libfoo.a becomes e.g. libfoo.a.hidden. The static library can then be temporarily restored if it is ever needed, and the package needing it can be identified. This shouldn't be done blindly since many libraries only exist in a static version. For example, some libraries from the glibc and gcc packages should always be present on the system (libc_nonshared.a, libg.a, libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a as of glibc-2.36 and gcc-12.2).

If you use this approach, you may discover that more packages than you were expecting use a static library. That was the case with nettle-2.4 in its default static-only configuration: It was required by GnuTLS-3.0.19, but also linked into package(s) which used GnuTLS, such as glib-networking-2.32.3.

Many packages put some of their common functions into a static library which is only used by the programs within the package and, crucially, the library is not installed as a standalone library. These internal libraries are not a problem – if the package has to be rebuilt to fix a bug or vulnerability, nothing else is linked to them.

When BLFS mentions system libraries, it means shared versions of libraries. Some packages such as Firefox-128.1.0 and ghostscript-10.03.1 bundle many other libraries in their build tree. The version they ship is often older than the version used in the system, so it may contain bugs – sometimes developers go to the trouble of fixing bugs in their included libraries, other times they do not.

Sometimes, deciding to use system libraries is an easy decision. Other times it may require you to alter the system version (e.g. for libpng-1.6.43 if used for Firefox-128.1.0). Occasionally, a package ships an old library and can no longer link to the current version, but can link to an older version. In this case, BLFS will usually just use the shipped version. Sometimes the included library is no longer developed separately, or its upstream is now the same as the package's upstream and you have no other packages which will use it. In those cases, you'll be lead to use the included library even if you usually prefer to use system libraries.

Locale Related Issues

This page contains information about locale related problems and issues. In the following paragraphs you'll find a generic overview of things that can come up when configuring your system for various locales. Many (but not all) existing locale related problems can be classified and fall under one of the headings below. The severity ratings below use the following criteria:

  • Critical: The program doesn't perform its main function. The fix would be very intrusive, it's better to search for a replacement.

  • High: Part of the functionality that the program provides is not usable. If that functionality is required, it's better to search for a replacement.

  • Low: The program works in all typical use cases, but lacks some functionality normally provided by its equivalents.

If there is a known workaround for a specific package, it will appear on that package's page.

The Needed Encoding is Not a Valid Option in the Program

Severity: Critical

Some programs require the user to specify the character encoding for their input or output data and present only a limited choice of encodings. This is the case for the -X option in Enscript-1.6.6, the -input-charset option in unpatched Cdrtools-3.02a09, and the character sets offered for display in the menu of Links-2.30. If the required encoding is not in the list, the program usually becomes completely unusable. For non-interactive programs, it may be possible to work around this by converting the document to a supported input character set before submitting to the program.

A solution to this type of problem is to implement the necessary support for the missing encoding as a patch to the original program or to find a replacement.

The Program Assumes the Locale-Based Encoding of External Documents

Severity: High for non-text documents, low for text documents

Some programs, nano-8.1 or JOE-4.6 for example, assume that documents are always in the encoding implied by the current locale. While this assumption may be valid for the user-created documents, it is not safe for external ones. When this assumption fails, non-ASCII characters are displayed incorrectly, and the document may become unreadable.

If the external document is entirely text based, it can be converted to the current locale encoding using the iconv program.

For documents that are not text-based, this is not possible. In fact, the assumption made in the program may be completely invalid for documents where the Microsoft Windows operating system has set de facto standards. An example of this problem is ID3v1 tags in MP3 files. For these cases, the only solution is to find a replacement program that doesn't have the issue (e.g., one that will allow you to specify the assumed document encoding).

Among BLFS packages, this problem applies to nano-8.1, JOE-4.6, and all media players except Audacious-4.4.

Another problem in this category is when someone cannot read the documents you've sent them because their operating system is set up to handle character encodings differently. This can happen often when the other person is using Microsoft Windows, which only provides one character encoding for a given country. For example, this causes problems with UTF-8 encoded TeX documents created in Linux. On Windows, most applications will assume that these documents have been created using the default Windows 8-bit encoding.

In extreme cases, Windows encoding compatibility issues may be solved only by running Windows programs under Wine.

The Program Uses or Creates Filenames in the Wrong Encoding

Severity: Critical

The POSIX standard mandates that the filename encoding is the encoding implied by the current LC_CTYPE locale category. This information is well-hidden on the page which specifies the behavior of Tar and Cpio programs. Some programs get it wrong by default (or simply don't have enough information to get it right). The result is that they create filenames which are not subsequently shown correctly by ls, or they refuse to accept filenames that ls shows properly. For the GLib-2.80.4 library, the problem can be corrected by setting the G_FILENAME_ENCODING environment variable to the special "@locale" value. Glib2 based programs that don't respect that environment variable are buggy.

The Zip-3.0 and UnZip-6.0 have this problem because they hard-code the expected filename encoding. UnZip contains a hard-coded conversion table between the CP850 (DOS) and ISO-8859-1 (UNIX) encodings and uses this table when extracting archives created under DOS or Microsoft Windows. However, this assumption only works for those in the US and not for anyone using a UTF-8 locale. Non-ASCII characters will be mangled in the extracted filenames.

The general rule for avoiding this class of problems is to avoid installing broken programs. If this is impossible, the convmv command-line tool can be used to fix filenames created by these broken programs, or intentionally mangle the existing filenames to meet the broken expectations of such programs.

In other cases, a similar problem is caused by importing filenames from a system using a different locale with a tool that is not locale-aware (e.g., OpenSSH-9.8p1). In order to avoid mangling non-ASCII characters when transferring files to a system with a different locale, any of the following methods can be used:

  • Transfer anyway, fix the damage with convmv.

  • On the sending side, create a tar archive with the --format=posix switch passed to tar (this will be the default in a future version of tar).

  • Mail the files as attachments. Mail clients specify the encoding of attached filenames.

  • Write the files to a removable disk formatted with a FAT or FAT32 filesystem.

  • Transfer the files using Samba.

  • Transfer the files via FTP using RFC2640-aware server (this currently means only wu-ftpd, which has bad security history) and client (e.g., lftp).

The last four methods work because the filenames are automatically converted from the sender's locale to UNICODE and stored or sent in this form. They are then transparently converted from UNICODE to the recipient's locale encoding.

The Program Breaks Multibyte Characters or Doesn't Count Character Cells Correctly

Severity: High or critical

Many programs were written in an older era where multibyte locales were not common. Such programs assume that C "char" data type, which is one byte, can be used to store single characters. Further, they assume that any sequence of characters is a valid string and that every character occupies a single character cell. Such assumptions completely break in UTF-8 locales. The visible manifestation is that the program truncates strings prematurely (i.e., at 80 bytes instead of 80 characters). Terminal-based programs don't place the cursor correctly on the screen, don't react to the "Backspace" key by erasing one character, and leave junk characters around when updating the screen, usually turning the screen into a complete mess.

Fixing this kind of problems is a tedious task from a programmer's point of view, like all other cases of retrofitting new concepts into the old flawed design. In this case, one has to redesign all data structures in order to accommodate to the fact that a complete character may span a variable number of "char"s (or switch to wchar_t and convert as needed). Also, for every call to the "strlen" and similar functions, find out whether a number of bytes, a number of characters, or the width of the string was really meant. Sometimes it is faster to write a program with the same functionality from scratch.

Among BLFS packages, this problem applies to xine-ui-0.99.14 and all the shells.

The Package Installs Manual Pages in Incorrect or Non-Displayable Encoding

Severity: Low

LFS expects that manual pages are in the language-specific (usually 8-bit) encoding, as specified on the LFS Man DB page. However, some packages install translated manual pages in UTF-8 encoding (e.g., Shadow, already dealt with), or manual pages in languages not in the table. Not all BLFS packages have been audited for conformance with the requirements put in LFS (the large majority have been checked, and fixes placed in the book for packages known to install non-conforming manual pages). If you find a manual page installed by any of BLFS packages that is obviously in the wrong encoding, please remove or convert it as needed, and report this to BLFS team as a bug.

You can easily check your system for any non-conforming manual pages by copying the following short shell script to some accessible location,

#!/bin/sh
# Begin checkman.sh
# Usage: find /usr/share/man -type f | xargs checkman.sh
for a in "$@"
do
    # echo "Checking $a..."
    # Pure-ASCII manual page (possibly except comments) is OK
    grep -v '.\\"' "$a" | iconv -f US-ASCII -t US-ASCII >/dev/null 2>&1 \
        && continue
    # Non-UTF-8 manual page is OK
    iconv -f UTF-8 -t UTF-8 "$a" >/dev/null 2>&1 || continue
    # Found a UTF-8 manual page, bad.
    echo "UTF-8 manual page: $a" >&2
done
# End checkman.sh

and then issuing the following command (modify the command below if the checkman.sh script is not in your PATH environment variable):

find /usr/share/man -type f | xargs checkman.sh

Note that if you have manual pages installed in any location other than /usr/share/man (e.g., /usr/local/share/man), you must modify the above command to include this additional location.

Going Beyond BLFS

The packages that are installed in this book are only the tip of the iceberg. We hope that the experience you gained with the LFS book and the BLFS book will give you the background needed to compile, install and configure packages that are not included in this book.

When you want to install a package to a location other than /, or /usr, you are installing outside the default environment settings on most machines. The following examples should assist you in determining how to correct this situation. The examples cover the complete range of settings that may need updating, but they are not all needed in every situation.

  • Expand the PATH to include $PREFIX/bin.

  • Expand the PATH for root to include $PREFIX/sbin.

  • Add $PREFIX/lib to /etc/ld.so.conf or expand LD_LIBRARY_PATH to include it. Before using the latter option, check out http://xahlee.info/UnixResource_dir/_/ldpath.html. If you modify /etc/ld.so.conf, remember to update /etc/ld.so.cache by executing ldconfig as the root user.

  • Add $PREFIX/man to /etc/man_db.conf.

  • Add $PREFIX/info to INFOPATH.

  • Add $PREFIX/lib/pkgconfig to PKG_CONFIG_PATH. Some packages are now installing .pc files in $PREFIX/share/pkgconfig, so you may have to include this directory also.

  • Add $PREFIX/include to CPPFLAGS when compiling packages that depend on the package you installed.

  • Add $PREFIX/lib to LDFLAGS when compiling packages that depend on a library installed by the package.

If you are in search of a package that is not in the book, the following are different ways you can search for the desired package.

Some general hints on handling new packages:

  • Many of the newer packages follow the ./configure && make && make install process. Help on the options accepted by configure can be obtained via the command ./configure --help.

  • Most of the packages contain documentation on compiling and installing the package. Some of the documents are excellent, some not so excellent. Check out the homepage of the package for any additional and updated hints for compiling and configuring the package.

  • If you are having a problem compiling the package, try searching the LFS archives at https://www.linuxfromscratch.org/search.html for the error or if that fails, try searching Google. Often, a distribution will have already solved the problem (many of them use development versions of packages, so they see the changes sooner than those of us who normally use stable released versions). But be cautious - all builders tend to carry patches which are no longer necessary, and to have fixes which are only required because of their particular choices in how they build a package. You may have to search deeply to find a fix for the package version you are trying to use, or even to find the package (names are sometimes not what you might expect, e.g. ghostscript often has a prefix or a suffix in its name), but the following notes might help, particularly for those who, like the editors, are trying to build the latest versions and encountering problems:

    • Arch https://www.archlinux.org/packages/ - enter the package name in the 'Keywords' box, select the package name, select the 'Source Files' field, and then select the PKGBUILD entry to see how they build this package.

    • Debian http://ftp.debian.org/debian/pool (use your country's version if there is one) - the source will be in .tar.gz tarballs (either the original upstream .orig source, or else a dfsg containing those parts which comply with Debian's free software guidelines) accompanied by versioned .diff.gz or .tar.gz additions. These additions often show how the package is built, and may contain patches. In the .diff.gz versions, any patches create files in debian/patches.

    • Fedora package source gets reorganized from time to time. At the moment the package source for rpms is at https://src.fedoraproject.org/projects/rpms/%2A and from there you can try putting a package name in the search box. If the package is found you can look at the files (specfile to control the build, various patches) or the commits. If that fails, you can download an srpm (source rpm) and using rpm2cpio (see the Tip at the bottom of the page). For rpms go to https://dl.fedoraproject.org/pub/fedora/linux/ and then choose which repo you wish to look at - development/rawhide is the latest development, or choose releases for what was shipped in a release, updates for updates to a release, or updates/testing for the latest updates which might work or might have problems.

    • Gentoo - First use a search engine to find an ebuild which looks as if it will fix the problem, or search at https://packages.gentoo.org/ - use the search field. Note where the package lives in the portage hierarchy, e.g. app-something/. In general you can treat the ebuild as a sort of pseudo-code / shell combination with some functions you can hazard a guess at, such as dodoc. If the fix is just a sed, try it. However, in most cases the fix will use a patch. To find the patch, use a gentoo-portage mirror: Two links to mirrors in the U.S.A. which seem to usually be up to date are https://mirror.rackspace.com/gentoo-portage/ and https://mirror.steadfast.net/gentoo-portage/. Navigate down the tree to the package, then to the files/ directory to look for the patch. Sometimes a portage mirror has not yet been updated, particularly for a recent new patch. In a few cases, gentoo batch the patches into a tarball and the ebuild will have a link in the form https://dev.gentoo.org/~${PATCH_DEV}/distfiles/${P}-patches-${PATCH_VER}.tar.xz here, look for PATCH_DEV and PATCH_VER in the build and format the full URL in your browser or for wget. Remember the '~' before the developer's ID and note that trying to search the earlier levels of the URL in a browser may drop you at www.gentoo.org or return 403 (forbidden).

    • openSUSE provide a rolling release, some package versions are in https://download.opensuse.org/source/tumbleweed/repo/oss/src/ but others are in ../update/openSUSE-current/src - the source only seems to be available in source rpms.

    • Slackware - the official package browser is currently broken. The site at https://slackbuilds.org/ has current and previous versions in their unofficial repository with links to homepages, downloads, and some individual files, particularly the .SlackBuild files.

    • Ubuntu http://ftp.ubuntu.com/ubuntu/pool/ - see the Debian notes above.

    If everything else fails, try the blfs-support mailing-list.

Tip

If you have found a package that is only available in .deb or .rpm format, there are two small scripts, rpm2targz and deb2targz that are available at https://anduin.linuxfromscratch.org/BLFS/extras/deb2targz.tar.bz2 and https://anduin.linuxfromscratch.org/BLFS/extras/rpm2targz.tar.bz2 to convert the archives into a simple tar.gz format.

You may also find an rpm2cpio script useful. The Perl version in the linux kernel archives at https://lore.kernel.org/all/20021016121842.GA2292@ncsu.edu/2-rpm2cpio works for most source rpms. The rpm2targz script will use an rpm2cpio script or binary if one is on your path. Note that rpm2cpio will unpack a source rpm in the current directory, giving a tarball, a spec file, and perhaps patches or other files.

Part II. Post LFS Configuration and Extra Software

Chapter 3. After LFS Configuration Issues

The intention of LFS is to provide a basic system which you can build upon. There are several things about tidying up the system which many people wonder about once they have done the base install. We hope to cover these issues in this chapter.

Most people coming from non-Unix like backgrounds to Linux find the concept of text-only configuration files slightly strange. In Linux, just about all configuration is done via the manipulation of text files. The majority of these files can be found in the /etc hierarchy. There are often graphical configuration programs available for different subsystems but most are simply pretty front ends to the process of editing a text file. The advantage of text-only configuration is that you can edit parameters using your favorite text editor, whether that be vim, emacs, or any other editor.

The first task is making a recovery boot device in Creating a Custom Boot Device because it's the most critical need. Hardware issues relevant to firmware and other devices is addressed next. The system is then configured to ease addition of new users, because this can affect the choices you make in the two subsequent topics—The Bash Shell Startup Files and The vimrc Files.

There is one remaining topic: Customizing your Logon with /etc/issue. It doesn't have much interaction with the other topics in this chapter.

Creating a Custom Boot Device

Decent Rescue Boot Device Needs

This section is really about creating a rescue device. As the name rescue implies, the host system has a problem, often lost partition information or corrupted file systems, that prevents it from booting and/or operating normally. For this reason, you must not depend on resources from the host being "rescued". To presume that any given partition or hard drive will be available is a risky presumption.

In a modern system, there are many devices that can be used as a rescue device: floppy, cdrom, usb drive, or even a network card. Which one you use depends on your hardware and your BIOS. In the past, a rescue device was thought to be a floppy disk. Today, many systems do not even have a floppy drive.

Building a complete rescue device is a challenging task. In many ways, it is equivalent to building an entire LFS system. In addition, it would be a repetition of information already available. For these reasons, the procedures for a rescue device image are not presented here.

Creating a Rescue Floppy

The software of today's systems has grown large. Linux 2.6 no longer supports booting directly from a floppy. In spite of this, there are solutions available using older versions of Linux. One of the best is Tom's Root/Boot Disk available at http://www.toms.net/rb/. This will provide a minimal Linux system on a single floppy disk and provides the ability to customize the contents of your disk if necessary.

Creating a Bootable CD-ROM

There are several sources that can be used for a rescue CD-ROM. Just about any commercial distribution's installation CD-ROMs or DVDs will work. These include RedHat, Ubuntu, and SuSE. One very popular option is Knoppix.

Also, the LFS Community has developed its own LiveCD available at https://www.linuxfromscratch.org/livecd/. This LiveCD, is no longer capable of building an entire LFS/BLFS system, but is still a good rescue CD-ROM. If you download the ISO image, use xorriso to copy the image to a CD-ROM.

The instructions for using GRUB2 to make a custom rescue CD-ROM are also available in LFS Chapter 10.

Creating a Bootable USB Drive

A USB Pen drive, sometimes called a Thumb drive, is recognized by Linux as a SCSI device. Using one of these devices as a rescue device has the advantage that it is usually large enough to hold more than a minimal boot image. You can save critical data to the drive as well as use it to diagnose and recover a damaged system. Booting such a drive requires BIOS support, but building the system consists of formatting the drive, adding GRUB as well as the Linux kernel and supporting files.

About Console Fonts

An LFS system can be used without a graphical desktop, and unless or until you install a graphical environment you will have to work in the console. Most, if not all, PCs boot with an 8x16 font - whatever the actual screen size. There are a few things you can do to alter the display on the console. Most of them involve changing the font, but the first alters the commandline used by grub.

Setting a smaller screen size in grub

Modern screens often have a lot more pixels then the screens used in the past. If your screen is 1600 pixels wide, an 8x16 font will give you 200 columns of text - unless your monitor is enormous, the text will be tiny. One of the ways to work around this is to tell grub to use a smaller size, such as 1024x768 or 800x600 or even 640x480. Even if your screen does not have a 4:3 aspect ratio, this should work.

To try this, you can reboot and edit grub's command-line to insert a 'video=' parameter between the 'root=/dev/sdXn' and 'ro', for example root=/dev/sda2 video=1024x768 ro based on the example in LFS section 10.4.4 : ../../../../lfs/view/12.2-systemd/chapter10/grub.html.

If you decide that you wish to do this, you can then (as the root user) edit /boot/grub/grub.cfg.

Using the standard psf fonts

In LFS the kbd package is used. The fonts it provides are PC Screen Fonts, usually called PSF, and they were installed into /usr/share/consolefonts. Where these include a unicode mapping table, the file suffix is often changed to .psfu although packages such as terminus-font (see below) do not add the 'u'. These fonts are usually compressed with gzip to save space, but that is not essential.

The initial PC text screens had 8 colours, or 16 colours if the bright versions of the original 8 colours were used. A PSF font can include up to 256 characters (technically, glyphs) while allowing 16 colours, or up to 512 characters (in which case, the bright colours will not be available). Clearly, these console fonts cannot be used to display CJK text - that would need thousands of available glyphs.

Some fonts in kbd can cover more than 512 codepoints ('characters'), with varying degrees of fidelity: unicode contains several whitespace codepoints which can all be mapped to a space, varieties of dashes can be mapped to a minus sign, smart quotes can map to the regular ASCII quotes rather than to whatever is used for "codepoint not present or invalid", and those cyrillic or greek letters which look like latin letters can be mapped onto them, so 'A' can also do duty for cyrillic A and greek Alpha, and 'P' can also do duty for cyrillic ER and greek RHO. Unfortunately, where a font has been created from a BDF file (the method in terminus and Debian's console-setup ) such mapping of additional codepoints onto an existing glyph is not always done, although the terminus ter-vXXn fonts do this well.

There are over 120 combinations of font and size in kbd: often a font is provided at several character sizes, and sometimes varieties cover different subsets of unicode. Most are 8 pixels wide, in heights from 8 to 16 pixels, but there are a few which are 9 pixels wide, some others which are 12x22, and even one (latarcyrheb-sun32.psfu) which has been scaled up to 16x32. Using a bigger font is another way of making text on a large screen easier to read.

Testing different fonts

You can test fonts as a normal user. If you have a font which has not been installed, you can load it with :

setfont /path/to/yourfont.ext

For the fonts already installed you only need the name, so using gr737a-9x16.psfu.gz as an example:

setfont gr737a-9x16

To see the glyphs in the font, use:

showconsolefont

If the font looks as if it might be useful, you can then go on to test it more thoroughly.

When you find a font which you wish to use, as the root user) edit /etc/vconsole.conf as described in LFS section 9.6 ../../../../lfs/view/12.2-systemd/chapter09/console.html..

For fonts not supplied with the kbd package you will need to optionally compress it / them with gzip and then install it / them as the root user.

Editing fonts using psf-tools

Although some console fonts are created from BDF files, which is a text format with hex values for the pixels in each row of the character, there are more-modern tools available for editing psf fonts. The psftools package allows you to dump a font to a text representation with a dash for a pixel which is off (black) and a hash for a pixel which is on (white). You can then edit the text file to add more characters, or reshape them, or map extra codepoints onto them, and then create a new psf font with your changes.

Using fonts from Terminus-font

The Terminus Font package provides fixed-width bitmap fonts designed for long (8 hours and more per day) work with computers. Under 'Character variants' on that page is a list of patches (in the alt/ directory). If you are using a graphical browser to look at that page, you can see what the patches do, e.g. 'll2' makes 'l' more visibly different from 'i' and '1'.

By default terminus-fonts will try to create several types of font, and it will fail if bdftopcf from Xorg Applications has not been installed. The configure script is only really useful if you go on to install all the fonts (console and X11 bitmap) to the correct directories, as in a distro. To build only the PSF fonts and their dependencies, run:

make psf

This will create more than 240 ter-*.psf fonts. The 'b' suffix indicates bright, 'n' indicates normal. You can then test them to see if any fit your requirements. Unless you are creating a distro, there seems little point in installing them all.

As an example, to install the last of these fonts, you can gzip it and then as the root user:

install -v -m644 ter-v32n.psf.gz /usr/share/consolefonts

About Firmware

On some recent PCs it can be necessary, or desirable, to load firmware to make them work at their best. There is a directory, /lib/firmware, where the kernel or kernel drivers look for firmware images.

Currently, most firmware can be found at a git repository which can be viewed in the browser with the URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain. For convenience, the LFS Project has created a mirror, updated daily, where these firmware files can be accessed via wget or a web browser at https://anduin.linuxfromscratch.org/BLFS/linux-firmware/.

To get the firmware, point a browser to one of the above repositories and then download the item(s) which you need. If you want all these firmware files (for example you are distributing the system onto multiple hardware systems), either install git-2.46.0 and clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, or open this URL in a browser and download the latest snapshot listed in the Tag table.

For some other firmware, particularly for Intel microcode and certain wifi devices, the needed firmware is not available in the above repository. Some of this will be addressed below, but a search of the Internet for needed firmware is sometimes necessary.

Firmware files are conventionally referred to as blobs because you cannot determine what they will do. Note that firmware is distributed under various different licenses which do not permit disassembly or reverse-engineering.

Firmware for PCs falls into four categories:

  • Updates to the CPU to work around errata, usually referred to as microcode.

  • Firmware for video controllers. On x86 machines this is required for ATI devices (Radeon and AMDGPU chips) and may be useful for Intel (Skylake and later) and Nvidia (Kepler and later) GPUs.

    ATI Radeon and AMDGPU devices all require firmware to be able to use KMS (kernel modesetting - the preferred option) as well as for Xorg. For old radeon chips (before the R600), the firmware is still in the kernel source.

    Intel integrated GPUs from Skylake onwards can use firmware for GuC (the Graphics microcontroller), and also for the HuC (HEVC/H265 microcontroller which offloads to the GPU) and the DMC (Display Microcontroller) to provide additional low-power states. The GuC and HuC have had a chequered history in the kernel and updated firmware may be disabled by default, depending on your kernel version. Further details may be found at 01.org and Arch linux.

    Nvidia GPUs from Kepler onwards require signed firmware, otherwise the nouveau driver is unable to provide hardware acceleration. Nvidia has now released firmware up to Ampere (GeForce30 series) to linux-firmware. Note that faster clocks than the default are not enabled by the released firmware.

  • Firmware updates for wired network ports. Most of them work even without the updates, but they will probably work better with the updated firmware. For some modern laptops, firmware for both wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca) is required before the wired network can be used.

  • Firmware for other devices, such as wireless NICs. These devices are not required for the PC to boot, but need the firmware before these devices can be used.

Note

Although not needed to load a firmware blob, the following tools may be useful for determining, obtaining, or preparing the needed firmware in order to load it into the system: cpio-2.15, git-2.46.0, pciutils-3.13.0, and Wget-1.24.5

Microcode updates for CPUs

In general, microcode can be loaded by the BIOS or UEFI, and it might be updated by upgrading to a newer version of those. On linux, you can also load the microcode from the kernel if you are using an AMD family 10h or later processor (first introduced late 2007), or an Intel processor from 1998 and later (Pentium4, Core, etc), if updated microcode has been released. These updates only last until the machine is powered off, so they need to be applied on every boot.

Intel provide updates of their microcode for Skylake and later processors as new vulnerabilities come to light, and have in the past provided updates for processors from SandyBridge onwards, although those are no-longer supported for new fixes. New versions of AMD firmware are rare and usually only apply to a few models, although motherboard manufacturers get AGESA (AMD Generic Encapsulated Software Architecture) updates to change BIOS values, e.g. to support more memory variants, new vulnerability fixes or newer CPUs.

There were two ways of loading the microcode, described as 'early' and 'late'. Early loading happens before userspace has been started, late loading happens after userspace has started. However, late loading is known to be problematic and not supported anymore (see the kernel commit x86/microcode: Taint and warn on late loading). Indeed, early loading is needed to work around one particular erratum in early Intel Haswell processors which had TSX enabled. (See Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP, Broadwell-Y.) Without this update glibc can do the wrong thing in uncommon situations.

In previous versions of this book, late loading of microcode to see if it gets applied was recommended, followed by using an initrd to force early loading. But now that the contents of the Intel microcode tarball is documented, and AMD microcode can be read by a Python script to determine which machines it covers, there is no real reason to use late loading.

It might be still possible to manually force late loading of microcode. But it may cause kernel malfunction and you should take the risk yourself. You will need to reconfigure your kernel for late loading, but early loading is always supported by Linux kernel version 6.6 or later on a x86 (no matter 32-bit or 64-bit) system. The instructions here will show you how to create an initrd for early loading. It is also possible to build the same microcode bin file into the kernel, which allows early loading but requires the kernel to be recompiled to update the microcode.

To confirm what processor(s) you have (if more than one, they will be identical) look in /proc/cpuinfo. Determine the decimal values of the cpu family, model and stepping by running the following command (it will also report the current microcode version):

head -n7 /proc/cpuinfo

Convert the cpu family, model and stepping to pairs of hexadecimal digits, and remember the value of the microcode field. You can now check if there is any microcode available.

If you are creating an initrd to update firmware for different machines, as a distro would do, go down to 'Early loading of microcode' and cat all the Intel blobs to GenuineIntel.bin or cat all the AMD blobs to AuthenticAMD.bin. This creates a larger initrd - for all Intel machines in the 20200609 update the size was 3.0 MB compared to typically 24 KB for one machine.

Intel Microcode for the CPU

The first step is to get the most recent version of the Intel microcode. This must be done by navigating to https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/ and downloading the latest file there. As of this writing the most secure version of the microcode is microcode-20240813. Extract this file in the normal way, the microcode is in the intel-ucode directory, containing various blobs with names in the form XX-YY-ZZ. There are also various other files, and a release note.

In the past, intel did not provide any details of which blobs had changed versions, but now the release note details this. You can compare the microcode version in /proc/cpuinfo with the version for your CPU model in the releasenote to know if there is an update.

The recent firmware for older processors is provided to deal with vulnerabilities which have now been made public, and for some of these such as Microarchitectural Data Sampling (MDS) you might wish to increase the protection by disabling hyperthreading, or alternatively to disable the kernel's default mitigation because of its impact on compile times. Please read the online documentation at https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html.

For an Tigerlake mobile (described as Intel(R) Core(TM) i5-11300H CPU) the relevant values are cpu family 6, model 140, stepping 1 so in this case the required identification is 06-8c-01. The releasenote says the latest microcode for it is versioned 0xb8. If the value of the microcode field in /proc/cpuinfo is 0xb8 or greater, it indicates the microcode update is already applied by the BIOS. Otherwise, proceed to the section called “Early loading of microcode”.

AMD Microcode for the CPU

Begin by downloading a container of firmware for your CPU family from https://anduin.linuxfromscratch.org/BLFS/linux-firmware/amd-ucode/. The family is always specified in hex. Families 10h to 14h (16 to 20) are in microcode_amd.bin. Families 15h, 16h, 17h (Zen, Zen+, Zen2) and 19h (Zen3) have their own containers, but very few machines are likely to get updated microcode. Instead, AMD provide an updated AGESA to the motherboard makers, who may provide an updated BIOS using this. There is a Python3 script at https://github.com/AMDESE/amd_ucode_info/blob/master/amd_ucode_info.py. Download that script and run it against the bin file to check which processors have updates.

For the very old Athlon(tm) II X2 in these examples the values were cpu family 16, model 5, stepping 3 giving an identification of Family=0x10 Model=0x05 Stepping=0x03. One line of the amd_ucode_info.py script output describes the microcode version for it:

Family=0x10 Model=0x05 Stepping=0x03: Patch=0x010000c8 Length=960 bytes

If the value of the microcode field in /proc/cpuinfo is 0x10000c8 or greater, it indicates the BIOS has already applied the microcode update. Otherwise, proceed to the section called “Early loading of microcode”.

Early loading of microcode

If you have established that updated microcode is available for your system, it is time to prepare it for early loading. This requires an additional package, cpio-2.15 and the creation of an initrd which will need to be added to grub.cfg.

It does not matter where you prepare the initrd, and once it is working you can apply the same initrd to later LFS systems or newer kernels on this same machine, at least until any newer microcode is released. Use the following commands:

mkdir -p initrd/kernel/x86/microcode
cd initrd

For an AMD machine, use the following command (replace <MYCONTAINER> with the name of the container for your CPU's family):

cp -v ../<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin

Or for an Intel machine copy the appropriate blob using this command:

cp -v ../intel-ucode/<XX-YY-ZZ> kernel/x86/microcode/GenuineIntel.bin

Now prepare the initrd:

find . | cpio -o -H newc > /boot/microcode.img

You now need to add a new entry to /boot/grub/grub.cfg and here you should add a new line after the linux line within the stanza. If /boot is a separate mountpoint:

initrd /microcode.img

or this if it is not:

initrd /boot/microcode.img

If you are already booting with an initrd (see the section called “About initramfs”), you should run mkinitramfs again after putting the appropriate blob or container into /lib/firmware. More precisely, put an intel blob in a /lib/firmware/intel-ucode directory or an AMD container in a /lib/firmware/amd-ucode directory before running mkinitramfs. Alternatively, you can have both initrd on the same line, such as initrd /microcode.img /other-initrd.img (adapt that as above if /boot is not a separate mountpoint).

You can now reboot with the added initrd, and then use the following command to check that the early load worked:

dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'

If you updated to address vulnerabilities, you can look at the output of the lscpu command to see what is now reported.

The places and times where early loading happens are very different in AMD and Intel machines. First, an example of an Intel (Tigerlake mobile) with early loading:

[    0.000000] Linux version 6.10.4 (xry111@stargazer) (gcc (GCC) 14.2.0, GNU ld (GNU Binutils) 2.43) #4 SMP PREEMPT_DYNAMIC Tue Aug 15 18:04:11 CST 2024
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.10.0 root=PARTUUID=<CLASSIFIED> ro
[    0.585605] microcode: Current revision: 0x000000b8
[    0.585611] microcode: Updated early from: 0x00000086

A historic AMD example:

[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
               #2 SMP Sun Feb 18 02:32:03 GMT 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
[    0.307619] microcode: microcode updated early to new patch_level=0x010000c8
[    0.307678] microcode: CPU0: patch_level=0x010000c8
[    0.307723] microcode: CPU1: patch_level=0x010000c8
[    0.307795] microcode: Microcode Update Driver: v2.2.

Firmware for Video Cards

Firmware for ATI video chips (R600 and later)

These instructions do NOT apply to old radeons before the R600 family. For those, the firmware is in the kernel's /lib/firmware/ directory. Nor do they apply if you intend to avoid a graphical setup such as Xorg and are content to use the default 80x25 display rather than a framebuffer.

Early radeon devices only needed a single 2K blob of firmware. Recent devices need several different blobs, and some of them are much bigger. The total size of the radeon firmware directory is over 500K — on a large modern system you can probably spare the space, but it is still redundant to install all the unused files each time you build a system.

A better approach is to install pciutils-3.13.0 and then use lspci to identify which VGA controller is installed.

With that information, check the RadeonFeature page of the Xorg wiki for Decoder ring for engineering vs marketing names to identify the family (you may need to know this for the Xorg driver in BLFS — Southern Islands and Sea Islands use the radeonsi driver) and the specific model.

Now that you know which controller you are using, consult the Radeon page of the Gentoo wiki which has a table listing the required firmware blobs for the various chipsets. Note that Southern Islands and Sea Islands chips use different firmware for kernel 3.17 and later compared to earlier kernels. Identify and download the required blobs then install them:

mkdir -pv /lib/firmware/radeon
cp -v <YOUR_BLOBS> /lib/firmware/radeon

Building the kernel amdgpu driver as a module is recommended because the firmware files need to be accessible at the time it is loaded. If you are building it as a part of the kernel image for any reason, you need to either include the firmware files in the initramfs (read the section called “About initramfs” for details), or include them in the kernel image itself (read the section called “Include Firmware Blobs in the Kernel Image” for details).

Firmware for AMD/ATI amdgpu video chips

All video controllers using the amdgpu kernel driver require firmware, whether you will be using the xorg amdgpu driver, the xserver's modesetting driver, or just kernel modesetting to get a console framebuffer larger than 80x25.

Install pciutils-3.13.0 and use that to check the model name (look for 'VGA compatible controller:'). If you have an APU (Accelerated Processing Unit, i.e. CPU and video on the same chip) that will probably tell you the name. If you have a separate amdgpu video card you will need to search to determine which name it uses (e.g. a card described as Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] needs Polaris11 firmware. There is a table of "Family, Chipset name, Product name and Firmware" at the end of the Kernel sections in AMDGPU page of the Gentoo wiki.

Once you have identified the firmware name, install all the relevant files for it. For example, the Baffin card mentioned above has 21 different polaris11* files, APUs such as renoir and picasso have at least 12 files and might gain more in future updates (e.g. the raven APU now has a 13th file, raven_ta.bin).

mkdir -pv /lib/firmware/amdgpu
cp -v <YOUR_BLOBS> /lib/firmware/amdgpu

If disk space is not a problem, you could install all the current amdgpu firmware files and not worry about exactly which chipset is installed.

Building the kernel amdgpu driver as a module is recommended because the firmware files need to be accessible at the time it is loaded. If you are building it as a part of the kernel image for any reason, you need to either include the firmware files in the initramfs (read the section called “About initramfs” for details), or include them in the kernel image itself (read the section called “Include Firmware Blobs in the Kernel Image” for details).

Firmware for Nvidia video chips

Nvidia has released basic signed firmware for recent graphics chips, but significantly after the chips and its own binary drivers were first available. For other chips it has been necessary to extract the firmware from the binary driver.

For more exact information about which chips need extracted firmware, see https://nouveau.freedesktop.org/VideoAcceleration.html.

If the necessary firmware is available in the nvidia/ directory of linux-firmware, copy it to /lib/firmware/nouveau.

If the firmware has not been made available in linux-firmware, for the old chips mentioned in the nouveau wiki link above run the following commands:

wget https://anduin.linuxfromscratch.org/BLFS/nvidia-firmware/extract_firmware.py
wget https://us.download.nvidia.com/XFree86/Linux-x86/340.32/NVIDIA-Linux-x86-340.32.run
sh NVIDIA-Linux-x86-340.32.run --extract-only
python3 extract_firmware.py
mkdir -p /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/

Firmware for Network Interfaces

The kernel likes to load firmware for some network drivers, particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory, but they generally appear to work without it. Therefore, you can boot the kernel, check dmesg for messages about this missing firmware, and if necessary download the firmware and put it in the specified directory in /lib/firmware so that it will be found on subsequent boots. Note that with current kernels this works whether or not the driver is compiled in or built as a module, there is no need to build this firmware into the kernel. Here is an example where the R8169 driver has been compiled in but the firmware was not made available. Once the firmware had been provided, there was no mention of it on later boots.

dmesg | grep firmware | grep r8169
[    7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
[    7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)

Firmware for Regulatory Database of Wireless Devices

Different countries have different regulations on the radio spectrum usage of wireless devices. You can install a firmware to make the wireless devices obey local spectrum regulations, so you won't be inquired by local authority or find your wireless NIC jamming the frequencies of other devices (for example, remote controllers). The regulatory database firmware can be downloaded from https://kernel.org/pub/software/network/wireless-regdb/. To install it, simply extract regulatory.db and regulatory.db.p7s from the tarball into /lib/firmware. Note that either the cfg80211 driver needs to be selected as a module for the regulatory.* files to be loaded, or those files need to be included as firmware into the kernel, as explained above in the section called “Firmware for Video Cards”.

The access point (AP) would send a country code to your wireless NIC, and wpa_supplicant-2.11 would tell the kernel to load the regulation of this country from regulatory.db, and enforce it. Note that several AP don't send this country code, so you may be locked to a rather restricted usage (specially if you want to use your interface as an AP).

Sound Open Firmware

Some systems (especially budget laptops) utilize a DSP shipped with the CPU for connection with the audio codec. The Sound Open Firmware must be loaded onto the DSP to make it functional. These firmware files can be downloaded from https://github.com/thesofproject/sof-bin/releases. Extract the tarball and changing into the extracted directory, then as the root user install the firmware:

install -vdm755 /usr/lib/firmware/intel    &&
cp -av -T --no-preserve=ownership sof      \
   /usr/lib/firmware/intel/sof             &&
cp -av -T --no-preserve=ownership sof-tplg \
   /usr/lib/firmware/intel/sof-tplg

alsa-lib-1.2.12 needs Use Case Manager configuration files for the systems using Sound Open Firmware as well. Read the alsa-lib-1.2.12 page for the instructions to install them. Once the firmware is loaded (you may need a reboot so the kernel will load them) and the UCM configuration files are installed, following the section called “Configuring ALSA Utilities” to set up your sound card for ALSA properly.

Firmware for Other Devices

Identifying the correct firmware will typically require you to install pciutils-3.13.0, and then use lspci to identify the device. You should then search online to check which module it uses, which firmware, and where to obtain the firmware — not all of it is in linux-firmware.

If possible, you should begin by using a wired connection when you first boot your LFS system. To use a wireless connection you will need to use a network tools such as iw-6.9, Wireless Tools-29, or wpa_supplicant-2.11.

Firmware may also be needed for other devices such as some SCSI controllers, bluetooth adaptors, or TV recorders. The same principles apply.

Include Firmware Blobs in the Kernel Image

Some drivers, notably the drivers for ATI or AMD GPU, requires the firmware files accessible at the time it is loaded. The easiest method to handle these drivers is building them as a kernel module. An alternative method is creating an initramfs (read the section called “About initramfs” for details) including the firmware files. If you don't want to use either methods, you may include the firmware files in the kernel image itself. Install the needed firmware files into /lib/firmware first, then set the following kernel configuration and rebuild the kernel:

Device Drivers --->
  Generic Driver Options --->
    Firmware loader --->
      <*>                   Firmware loading facility                [FW_LOADER]
      (xx/aa.bin xx/bb.bin)   Build named firmware blobs into the kernel binary
                                                           ...  [EXTRA_FIRMWARE]
      (/lib/firmware)           Firmware blobs root directory
                                                       ...  [EXTRA_FIRMWARE_DIR]

Replace xx/aa.bin xx/bb.bin with a whitespace-separated list of paths to the needed firmware files, relative to /lib/firmware. A method easier than manually typing the list (it may be long) is running the following command:

echo CONFIG_EXTRA_FIRMWARE='"'$({ cd /lib/firmware; echo amdgpu/* })'"' >> .config
make oldconfig

Replace amdgpu/* with a shell pattern matching the needed firmware files.

Warning

Do not distribute a kernel image containing the firmware to others or you may violate the GPL.

About Devices

Although most devices needed by packages in BLFS and beyond are set up properly by udev using the default rules installed by LFS in /etc/udev/rules.d, there are cases where the rules must be modified or augmented.

Multiple Sound Cards

If there are multiple sound cards in a system, the "default" sound card becomes random. The method to establish sound card order depends on whether the drivers are modules or not. If the sound card drivers are compiled into the kernel, control is via kernel command line parameters in /boot/grub/grub.cfg. For example, if a system has both an FM801 card and a SoundBlaster PCI card, the following can be appended to the command line:

snd-fm801.index=0 snd-ens1371.index=1

If the sound card drivers are built as modules, the order can be established in the /etc/modprobe.conf file with:

options snd-fm801 index=0
options snd-ens1371 index=1

USB Device Issues

USB devices usually have two kinds of device nodes associated with them.

The first kind is created by device-specific drivers (e.g., usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass storage device would be /dev/sdb, and a USB printer would be /dev/usb/lp0. These device nodes exist only when the device-specific driver is loaded.

The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is the bus number and DDD is the device number) are created even if the device doesn't have a kernel driver. By using these "raw" USB device nodes, an application can exchange arbitrary USB packets with the device, i.e., bypass the possibly-existing kernel driver.

Access to raw USB device nodes is needed when a userspace program is acting as a device driver. However, for the program to open the device successfully, the permissions have to be set correctly. By default, due to security concerns, all raw USB devices are owned by user root and group root, and have 0664 permissions (the read access is needed, e.g., for lsusb to work and for programs to access USB hubs). Packages (such as SANE and libgphoto2) containing userspace USB device drivers also ship udev rules that change the permissions of the controlled raw USB devices. That is, rules installed by SANE change permissions for known scanners, but not printers. If a package maintainer forgot to write a rule for your device, report a bug to both BLFS (if the package is there) and upstream, and you will need to write your own rule.

Before Linux-2.6.15, raw USB device access was performed not with /dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD pseudofiles. Some applications still use only this deprecated technique and can't use the new device nodes. They cannot work with Linux kernel version 3.5 or newer. If you need to run such an application, contact the developer of it for a fix.

Udev Device Attributes

Fine-tuning of device attributes such as group name and permissions is possible by creating extra udev rules, matching on something like this. The vendor and product can be found by searching the /sys/devices directory entries or using udevadm info after the device has been attached. See the documentation in the current udev directory of /usr/share/doc for details.

SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \
  GROUP:="scanner", MODE:="0660"

Note

The above line is used for descriptive purposes only. The scanner udev rules are put into place when installing SANE-1.2.1.

Devices for DVD Drives

If the initial boot process does not set up the /dev/dvd device properly, it can be installed using the following modification to the default udev rules. As the root user, run:

sed '1d;/SYMLINK.*cdrom/ a\
KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", OPTIONS+="link_priority=-100"' \
/lib/udev/rules.d/60-cdrom_id.rules > /etc/udev/rules.d/60-cdrom_id.rules

Configuring for Adding Users

Together, the /usr/sbin/useradd command and /etc/skel directory (both are easy to set up and use) provide a way to assure new users are added to your LFS system with the same beginning settings for things such as the PATH, keyboard processing and other environmental variables. Using these two facilities makes it easier to assure this initial state for each new user added to the system.

The /etc/skel directory holds copies of various initialization and other files that may be copied to the new user's home directory when the /usr/sbin/useradd program adds the new user.

Useradd

The useradd program uses a collection of default values kept in /etc/default/useradd. This file is created in a base LFS installation by the Shadow package. If it has been removed or renamed, the useradd program uses some internal defaults. You can see the default values by running /usr/sbin/useradd -D.

To change these values, simply modify the /etc/default/useradd file as the root user. An alternative to directly modifying the file is to run useradd as the root user while supplying the desired modifications on the command line. Information on how to do this can be found in the useradd man page.

/etc/skel

To get started, create an /etc/skel directory and make sure it is writable only by the system administrator, usually root. Creating the directory as root is the best way to go.

The mode of any files from this part of the book that you put in /etc/skel should be writable only by the owner. Also, since there is no telling what kind of sensitive information a user may eventually place in their copy of these files, you should make them unreadable by "group" and "other".

You can also put other files in /etc/skel and different permissions may be needed for them.

Decide which initialization files should be provided in every (or most) new user's home directory. The decisions you make will affect what you do in the next two sections, The Bash Shell Startup Files and The vimrc Files. Some or all of those files will be useful for root, any already-existing users, and new users.

The files from those sections that you might want to place in /etc/skel include .inputrc, .bash_profile, .bashrc, .bash_logout, .dircolors, and .vimrc. If you are unsure which of these should be placed there, just continue to the following sections, read each section and any references provided, and then make your decision.

You will run a slightly modified set of commands for files which are placed in /etc/skel. Each section will remind you of this. In brief, the book's commands have been written for files not added to /etc/skel and instead just sends the results to the user's home directory. If the file is going to be in /etc/skel, change the book's command(s) to send output there instead and then just copy the file from /etc/skel to the appropriate directories, like /etc, ~ or the home directory of any other user already in the system.

When Adding a User

When adding a new user with useradd, use the -m parameter, which tells useradd to create the user's home directory and copy files from /etc/skel (can be overridden) to the new user's home directory. For example (perform as the root user):

useradd -m <newuser>

If you are sharing a /home or /usr/src with another Linux distro (for example, the host distro used for building LFS), you can create a user with the same UID (and, same primary group GID) to keep the file ownership consistent across the systems. First, on the other distro, get the UID of the user and the GID of the user's primary group:

getent passwd <username> | cut -d ':' -f 3,4

The command should output the UID and GID, separated by a colon. Now on the BLFS system, create the primary group and the user:

groupadd -g <GID> <username> &&
useradd -u <UID> -g <username> <username>

About System Users and Groups

Throughout BLFS, many packages install programs that run as daemons or in some way should have a user or group name assigned. Generally these names are used to map a user ID (uid) or group ID (gid) for system use. Generally the specific uid or gid numbers used by these applications are not significant. The exception of course, is that root has a uid and gid of 0 (zero) that is indeed special. The uid values are stored in /etc/passwd and the gid values are found in /etc/group.

Customarily, Unix systems classify users and groups into two categories: system users and regular users. The system users and groups are given low numbers and regular users and groups have numeric values greater than all the system values. The cutoff for these numbers is found in two parameters in the /etc/login.defs configuration file. The default UID_MIN value is 1000 and the default GID_MIN value is 1000. If a specific uid or gid value is not specified when creating a user with useradd or a group with groupadd the values assigned will always be above these cutoff values.

Additionally, the Linux Standard Base recommends that system uid and gid values should be below 100.

Below is a table of suggested uid/gid values used in BLFS beyond those defined in a base LFS installation. These can be changed as desired, but provide a suggested set of consistent values.

Table 3.1. UID/GID Suggested Values

Name uid gid
bin 1
lp 9
adm 16
atd 17 17
messagebus 18 18
lpadmin   19
named 20 20
gdm 21 21
fcron 22 22
systemd-journal 23 23
apache 25 25
smmsp 26 26
polkitd 27 27
rpc 28 28
exim 31 31
postfix 32 32
postdrop 33
sendmail 34
mail 34
vmailman 35 35
news 36 36
kdm 37 37
fetchmail 38
mysql 40 40
postgres 41 41
dovecot 42 42
dovenull 43 43
ftp 45 45
proftpd 46 46
vsftpd 47 47
rsyncd 48 48
sshd 50 50
stunnel 51 51
dhcpcd 52 52
svn 56 56
svntest 57
git 58 58
games 60 60
kvm 61
wireshark 62
sddm 64 64
lightdm 65 65
scanner 70
colord 71 71
systemd-journal-gateway 73 73
systemd-journal-remote 74 74
systemd-journal-upload 75 75
systemd-network 76 76
systemd-resolve 77 77
systemd-timesync 78 78
systemd-coredump 79 79
uuidd 80 80
systemd-oom 81 81
ldap 83 83
avahi 84 84
avahi-autoipd 85 85
netdev 86
ntp 87 87
unbound 88 88
plugdev 90
wheel 97
anonymous 98
nobody 65534
nogroup 65534

The Bash Shell Startup Files

The shell program /bin/bash (hereafter referred to as just "the shell") uses a collection of startup files to help create an environment. Each file has a specific use and may affect login and interactive environments differently. The files in the /etc directory generally provide global settings. If an equivalent file exists in your home directory it may override the global settings.

An interactive login shell is started after a successful login, using /bin/login, by reading the /etc/passwd file. This shell invocation normally reads /etc/profile and its private equivalent ~/.bash_profile (or ~/.profile if called as /bin/sh) upon startup.

An interactive non-login shell is normally started at the command-line using a shell program (e.g., [prompt]$/bin/bash) or by the /bin/su command. An interactive non-login shell is also started with a terminal program such as xterm or konsole from within a graphical environment. This type of shell invocation normally copies the parent environment and then reads the user's ~/.bashrc file for additional startup configuration instructions.

A non-interactive shell is usually present when a shell script is running. It is non-interactive because it is processing a script and not waiting for user input between commands. For these shell invocations, only the environment inherited from the parent shell is used.

The file ~/.bash_logout is not used for an invocation of the shell. It is read and executed when a user exits from an interactive login shell.

Many distributions use /etc/bashrc for system wide initialization of non-login shells. This file is usually called from the user's ~/.bashrc file and is not built directly into bash itself. This convention is followed in this section.

For more information see info bash -- Nodes: Bash Startup Files and Interactive Shells.

Note

Most of the instructions below are used to create files located in the /etc directory structure which requires you to execute the commands as the root user. If you elect to create the files in user's home directories instead, you should run the commands as an unprivileged user.

Editor Notes: https://wiki.linuxfromscratch.org/blfs/wiki/bash-shell-startup-files

/etc/profile

Here is a base /etc/profile. This file starts by setting up some helper functions and some basic parameters. It specifies some bash history parameters and, for security purposes, disables keeping a permanent history file for the root user. It also sets a default user prompt. It then calls small, single purpose scripts in the /etc/profile.d directory to provide most of the initialization.

For more information on the escape sequences you can use for your prompt (i.e., the PS1 environment variable) see info bash -- Node: Printing a Prompt.

cat > /etc/profile << "EOF"
# Begin /etc/profile
# Written for Beyond Linux From Scratch
# by James Robertson <jameswrobertson@earthlink.net>
# modifications by Dagmar d'Surreal <rivyqntzne@pbzpnfg.arg>

# System wide environment variables and startup programs.

# System wide aliases and functions should go in /etc/bashrc.  Personal
# environment variables and startup programs should go into
# ~/.bash_profile.  Personal aliases and functions should go into
# ~/.bashrc.

# Functions to help us manage paths.  Second argument is the name of the
# path variable to be modified (default: PATH)
pathremove () {
        local IFS=':'
        local NEWPATH
        local DIR
        local PATHVARIABLE=${2:-PATH}
        for DIR in ${!PATHVARIABLE} ; do
                if [ "$DIR" != "$1" ] ; then
                  NEWPATH=${NEWPATH:+$NEWPATH:}$DIR
                fi
        done
        export $PATHVARIABLE="$NEWPATH"
}

pathprepend () {
        pathremove $1 $2
        local PATHVARIABLE=${2:-PATH}
        export $PATHVARIABLE="$1${!PATHVARIABLE:+:${!PATHVARIABLE}}"
}

pathappend () {
        pathremove $1 $2
        local PATHVARIABLE=${2:-PATH}
        export $PATHVARIABLE="${!PATHVARIABLE:+${!PATHVARIABLE}:}$1"
}

export -f pathremove pathprepend pathappend

# Set the initial path
export PATH=/usr/bin

# Attempt to provide backward compatibility with LFS earlier than 11
if [ ! -L /bin ]; then
        pathappend /bin
fi

if [ $EUID -eq 0 ] ; then
        pathappend /usr/sbin
        if [ ! -L /sbin ]; then
                pathappend /sbin
        fi
        unset HISTFILE
fi

# Set up some environment variables.
export HISTSIZE=1000
export HISTIGNORE="&:[bf]g:exit"

# Set some defaults for graphical systems
export XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/share}
export XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS:-/etc/xdg}
export XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR:-/tmp/xdg-$USER}

# Set up a red prompt for root and a green one for users.
NORMAL="\[\e[0m\]"
RED="\[\e[1;31m\]"
GREEN="\[\e[1;32m\]"
if [[ $EUID == 0 ]] ; then
  PS1="$RED\u [ $NORMAL\w$RED ]# $NORMAL"
else
  PS1="$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL"
fi

for script in /etc/profile.d/*.sh ; do
        if [ -r $script ] ; then
                . $script
        fi
done

unset script RED GREEN NORMAL

# End /etc/profile
EOF

The /etc/profile.d Directory

Now create the /etc/profile.d directory, where the individual initialization scripts are placed:

install --directory --mode=0755 --owner=root --group=root /etc/profile.d

/etc/profile.d/bash_completion.sh

Note

Using the bash completion script below is controversial. Not all users like it. It adds many (usually over 1000) lines to the bash environment and makes it difficult to use the 'set' command to examine simple environment variables. Omitting this script does not interfere with the ability of bash to use the tab key for file name completion.

This script imports bash completion scripts, installed by many other BLFS packages, to allow TAB command line completion.

cat > /etc/profile.d/bash_completion.sh << "EOF"
# Begin /etc/profile.d/bash_completion.sh
# Import bash completion scripts

# If the bash-completion package is installed, use its configuration instead
if [ -f /usr/share/bash-completion/bash_completion ]; then

  # Check for interactive bash and that we haven't already been sourced.
  if [ -n "${BASH_VERSION-}" -a -n "${PS1-}" -a -z "${BASH_COMPLETION_VERSINFO-}" ]; then

    # Check for recent enough version of bash.
    if [ ${BASH_VERSINFO[0]} -gt 4 ] || \
       [ ${BASH_VERSINFO[0]} -eq 4 -a ${BASH_VERSINFO[1]} -ge 1 ]; then
       [ -r "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion" ] && \
            . "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion"
       if shopt -q progcomp && [ -r /usr/share/bash-completion/bash_completion ]; then
          # Source completion code.
          . /usr/share/bash-completion/bash_completion
       fi
    fi
  fi

else

  # bash-completions are not installed, use only bash completion directory
  if shopt -q progcomp; then
    for script in /etc/bash_completion.d/* ; do
      if [ -r $script ] ; then
        . $script
      fi
    done
  fi
fi

# End /etc/profile.d/bash_completion.sh
EOF

Make sure that the directory exists:

install --directory --mode=0755 --owner=root --group=root /etc/bash_completion.d

For a more complete installation, see https://wiki.linuxfromscratch.org/blfs/wiki/bash-shell-startup-files#bash-completions.

/etc/profile.d/dircolors.sh

This script uses the ~/.dircolors and /etc/dircolors files to control the colors of file names in a directory listing. They control colorized output of things like ls --color. The explanation of how to initialize these files is at the end of this section.

cat > /etc/profile.d/dircolors.sh << "EOF"
# Setup for /bin/ls and /bin/grep to support color, the alias is in /etc/bashrc.
if [ -f "/etc/dircolors" ] ; then
        eval $(dircolors -b /etc/dircolors)
fi

if [ -f "$HOME/.dircolors" ] ; then
        eval $(dircolors -b $HOME/.dircolors)
fi

alias ls='ls --color=auto'
alias grep='grep --color=auto'
EOF

/etc/profile.d/extrapaths.sh

This script adds some useful paths to the PATH and can be used to customize other PATH related environment variables (e.g. LD_LIBRARY_PATH, etc) that may be needed for all users.

cat > /etc/profile.d/extrapaths.sh << "EOF"
if [ -d /usr/local/lib/pkgconfig ] ; then
        pathappend /usr/local/lib/pkgconfig PKG_CONFIG_PATH
fi
if [ -d /usr/local/bin ]; then
        pathprepend /usr/local/bin
fi
if [ -d /usr/local/sbin -a $EUID -eq 0 ]; then
        pathprepend /usr/local/sbin
fi

if [ -d /usr/local/share ]; then
        pathprepend /usr/local/share XDG_DATA_DIRS
fi

# Set some defaults before other applications add to these paths.
pathappend /usr/share/info INFOPATH
EOF

Note

The man program automatically deduce the search path for man pages by examining the content of the PATH variable, see manpath(5) for details. Setting the MANPATH variable may override the automatic deduction, so the BLFS editors do not recommend to set it. If you must set it for any reason, it's better to start its value with a colon (:), for example MANPATH=:/opt/somepkg/share/man:/opt/otherpkg/share/man so the paths listed in the MANPATH variable will be appended to the automatically deduced value instead of overriding it.

/etc/profile.d/readline.sh

This script sets up the default inputrc configuration file. If the user does not have individual settings, it uses the global file.

cat > /etc/profile.d/readline.sh << "EOF"
# Set up the INPUTRC environment variable.
if [ -z "$INPUTRC" -a ! -f "$HOME/.inputrc" ] ; then
        INPUTRC=/etc/inputrc
fi
export INPUTRC
EOF

/etc/profile.d/umask.sh

Setting the umask value is important for security. Here the default group write permissions are turned off for system users and when the user name and group name are not the same.

cat > /etc/profile.d/umask.sh << "EOF"
# By default, the umask should be set.
if [ "$(id -gn)" = "$(id -un)" -a $EUID -gt 99 ] ; then
  umask 002
else
  umask 022
fi
EOF

/etc/profile.d/i18n.sh

This script sets an environment variable necessary for native language support. A full discussion on determining this variable can be found on the Configuring the System Locale page.

cat > /etc/profile.d/i18n.sh << "EOF"
# Set up i18n variables
for i in $(locale); do
  unset ${i%=*}
done

if [[ "$TERM" = linux ]]; then
  export LANG=C.UTF-8
else
  source /etc/locale.conf

  for i in $(locale); do
    key=${i%=*}
    if [[ -v $key ]]; then
      export $key
    fi
  done
fi
EOF

Other Initialization Values

Other initialization can easily be added to the profile by adding additional scripts to the /etc/profile.d directory.

/etc/bashrc

Here is a base /etc/bashrc. Comments in the file should explain everything you need.

cat > /etc/bashrc << "EOF"
# Begin /etc/bashrc
# Written for Beyond Linux From Scratch
# by James Robertson <jameswrobertson@earthlink.net>
# updated by Bruce Dubbs <bdubbs@linuxfromscratch.org>

# System wide aliases and functions.

# System wide environment variables and startup programs should go into
# /etc/profile.  Personal environment variables and startup programs
# should go into ~/.bash_profile.  Personal aliases and functions should
# go into ~/.bashrc

# Provides colored /bin/ls and /bin/grep commands.  Used in conjunction
# with code in /etc/profile.

alias ls='ls --color=auto'
alias grep='grep --color=auto'

# Provides prompt for non-login shells, specifically shells started
# in the X environment. [Review the LFS archive thread titled
# PS1 Environment Variable for a great case study behind this script
# addendum.]

NORMAL="\[\e[0m\]"
RED="\[\e[1;31m\]"
GREEN="\[\e[1;32m\]"
if [[ $EUID == 0 ]] ; then
  PS1="$RED\u [ $NORMAL\w$RED ]# $NORMAL"
else
  PS1="$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL"
fi

unset RED GREEN NORMAL

# End /etc/bashrc
EOF

~/.bash_profile

Here is a base ~/.bash_profile. If you want each new user to have this file automatically, just change the output of the command to /etc/skel/.bash_profile and check the permissions after the command is run. You can then copy /etc/skel/.bash_profile to the home directories of already existing users, including root, and set the owner and group appropriately.

cat > ~/.bash_profile << "EOF"
# Begin ~/.bash_profile
# Written for Beyond Linux From Scratch
# by James Robertson <jameswrobertson@earthlink.net>
# updated by Bruce Dubbs <bdubbs@linuxfromscratch.org>

# Personal environment variables and startup programs.

# Personal aliases and functions should go in ~/.bashrc.  System wide
# environment variables and startup programs are in /etc/profile.
# System wide aliases and functions are in /etc/bashrc.

if [ -f "$HOME/.bashrc" ] ; then
  source $HOME/.bashrc
fi

if [ -d "$HOME/bin" ] ; then
  pathprepend $HOME/bin
fi

# Having . in the PATH is dangerous
#if [ $EUID -gt 99 ]; then
#  pathappend .
#fi

# End ~/.bash_profile
EOF

~/.profile

Here is a base ~/.profile. The comments and instructions for using /etc/skel for .bash_profile above also apply here. Only the target file names are different.

cat > ~/.profile << "EOF"
# Begin ~/.profile
# Personal environment variables and startup programs.

if [ -d "$HOME/bin" ] ; then
  pathprepend $HOME/bin
fi

# Set up user specific i18n variables
#export LANG=<ll>_<CC>.<charmap><@modifiers>

# End ~/.profile
EOF

~/.bashrc

Here is a base ~/.bashrc.

cat > ~/.bashrc << "EOF"
# Begin ~/.bashrc
# Written for Beyond Linux From Scratch
# by James Robertson <jameswrobertson@earthlink.net>

# Personal aliases and functions.

# Personal environment variables and startup programs should go in
# ~/.bash_profile.  System wide environment variables and startup
# programs are in /etc/profile.  System wide aliases and functions are
# in /etc/bashrc.

if [ -f "/etc/bashrc" ] ; then
  source /etc/bashrc
fi

# Set up user specific i18n variables
#export LANG=<ll>_<CC>.<charmap><@modifiers>

# End ~/.bashrc
EOF

~/.bash_logout

This is an empty ~/.bash_logout that can be used as a template. You will notice that the base ~/.bash_logout does not include a clear command. This is because the clear is handled in the /etc/issue file.

cat > ~/.bash_logout << "EOF"
# Begin ~/.bash_logout
# Written for Beyond Linux From Scratch
# by James Robertson <jameswrobertson@earthlink.net>

# Personal items to perform on logout.

# End ~/.bash_logout
EOF

/etc/dircolors

If you want to use the dircolors capability, then run the following command. The /etc/skel setup steps shown above also can be used here to provide a ~/.dircolors file when a new user is set up. As before, just change the output file name on the following command and assure the permissions, owner, and group are correct on the files created and/or copied.

dircolors -p > /etc/dircolors

If you wish to customize the colors used for different file types, you can edit the /etc/dircolors file. The instructions for setting the colors are embedded in the file.

Finally, Ian Macdonald has written an excellent collection of tips and tricks to enhance your shell environment. You can read it online at https://www.caliban.org/bash/index.shtml.

The /etc/vimrc and ~/.vimrc Files

The LFS book installs Vim as its text editor. At this point it should be noted that there are a lot of different editing applications out there including Emacs, nano, Joe and many more. Anyone who has been around the Internet (especially usenet) for a short time will certainly have observed at least one flame war, usually involving Vim and Emacs users!

The LFS book creates a basic vimrc file. In this section you'll find an attempt to enhance this file. At startup, vim reads the global configuration file (/etc/vimrc) as well as a user-specific file (~/.vimrc). Either or both can be tailored to suit the needs of your particular system.

Here is a slightly expanded .vimrc that you can put in ~/.vimrc to provide user specific effects. Of course, if you put it into /etc/skel/.vimrc instead, it will be made available to users you add to the system later. You can also copy the file from /etc/skel/.vimrc to the home directory of users already on the system, such as root. Be sure to set permissions, owner, and group if you do copy anything directly from /etc/skel.

" Begin .vimrc

set columns=80
set wrapmargin=8
set ruler

" End .vimrc

Note that the comment tags are " instead of the more usual # or //. This is correct, the syntax for vimrc is slightly unusual.

Below you'll find a quick explanation of what each of the options in this example file means here:

  • set columns=80: This simply sets the number of columns used on the screen.

  • set wrapmargin=8: This is the number of characters from the right window border where wrapping starts.

  • set ruler: This makes vim show the current row and column at the bottom right of the screen.

More information on the many vim options can be found by reading the help inside vim itself. Do this by typing :help in vim to get the general help, or by typing :help usr_toc.txt to view the User Manual Table of Contents.

Customizing your Logon with /etc/issue

When you first boot up your new LFS system, the logon screen will be nice and plain (as it should be in a bare-bones system). Many people however, will want their system to display some information in the logon message. This can be accomplished using the file /etc/issue.

The /etc/issue file is a plain text file which will also accept certain escape sequences (see below) in order to insert information about the system. There is also the file issue.net which can be used when logging on remotely. ssh however, will only use it if you set the option in the configuration file and will not interpret the escape sequences shown below.

One of the most common things which people want to do is clear the screen at each logon. The easiest way of doing that is to put a "clear" escape sequence into /etc/issue. A simple way of doing this is to issue the command clear > /etc/issue. This will insert the relevant escape code into the start of the /etc/issue file. Note that if you do this, when you edit the file, you should leave the characters (normally '^[[H^[[2J') on the first line alone.

Note

Terminal escape sequences are special codes recognized by the terminal. The ^[ represents an ASCII ESC character. The sequence ESC [ H puts the cursor in the upper left hand corner of the screen and ESC 2 J erases the screen. For more information on terminal escape sequences see https://invisible-mirror.net/xterm/ctlseqs/ctlseqs.html

The following sequences are recognized by agetty (the program which usually parses /etc/issue). This information is from man agetty where you can find extra information about the logon process.

The issue file can contain certain character sequences to display various information. All issue sequences consist of a backslash (\) immediately followed by one of the letters explained below (so \d in /etc/issue would insert the current date).

b   Insert the baudrate of the current line.
d   Insert the current date.
s   Insert the system name, the name of the operating system.
l   Insert the name of the current tty line.
m   Insert the architecture identifier of the machine, e.g., i686.
n   Insert the nodename of the machine, also known as the hostname.
o   Insert the domainname of the machine.
r   Insert the release number of the kernel, e.g., 2.6.11.12.
t   Insert the current time.
u   Insert the number of current users logged in.
U   Insert the string "1 user" or "<n> users" where <n> is the
    number of current users logged in.
v   Insert the version of the OS, e.g., the build-date etc.

Chapter 4. Security

Security takes many forms in a computing environment. After some initial discussion, this chapter gives examples of three different types of security: access, prevention and detection.

Access for users is usually handled by login or an application designed to handle the login function. In this chapter, we show how to enhance login by setting policies with PAM modules. Access via networks can also be secured by policies set by iptables, commonly referred to as a firewall. The Network Security Services (NSS) and Netscape Portable Runtime (NSPR) libraries can be installed and shared among the many applications requiring them. For applications that don't offer the best security, you can use the Stunnel package to wrap an application daemon inside an SSL tunnel.

Prevention of breaches, like a trojan, are assisted by applications like GnuPG, specifically the ability to confirm signed packages, which recognizes modifications of the tarball after the packager creates it.

Finally, we touch on detection with a package that stores "signatures" of critical files (defined by the administrator) and then regenerates those "signatures" and compares for files that have been changed.

Vulnerabilities

About vulnerabilities

All software has bugs. Sometimes, a bug can be exploited, for example to allow users to gain enhanced privileges (perhaps gaining a root shell, or simply accessing or deleting other user's files), or to allow a remote site to crash an application (denial of service), or for theft of data. These bugs are labelled as vulnerabilities.

The main place where vulnerabilities get logged is cve.mitre.org. Unfortunately, many vulnerability numbers (CVE-yyyy-nnnn) are initially only labelled as "reserved" when distributions start issuing fixes. Also, some vulnerabilities apply to particular combinations of configure options, or only apply to old versions of packages which have long since been updated in BLFS.

BLFS differs from distributions—there is no BLFS security team, and the editors only become aware of vulnerabilities after they are public knowledge. Sometimes, a package with a vulnerability will not be updated in the book for a long time. Issues can be logged in the Trac system, which might speed up resolution.

The normal way for BLFS to fix a vulnerability is, ideally, to update the book to a new fixed release of the package. Sometimes that happens even before the vulnerability is public knowledge, so there is no guarantee that it will be shown as a vulnerability fix in the Changelog. Alternatively, a sed command, or a patch taken from a distribution, may be appropriate.

The bottom line is that you are responsible for your own security, and for assessing the potential impact of any problems.

The editors now issue Security Advisories for packages in BLFS (and LFS), which can be found at BLFS Security Advisories, and grade the severity according to what upstream reports, or to what is shown at nvd.nist.gov if that has details.

To keep track of what is being discovered, you may wish to follow the security announcements of one or more distributions. For example, Debian has Debian security. Fedora's links on security are at the Fedora wiki. Details of Gentoo linux security announcements are discussed at Gentoo security. Finally, the Slackware archives of security announcements are at Slackware security.

The most general English source is perhaps the Full Disclosure Mailing List, but please read the comment on that page. If you use other languages you may prefer other sites such as heise.de (German) or cert.hr (Croatian). These are not linux-specific. There is also a daily update at lwn.net for subscribers (free access to the data after 2 weeks, but their vulnerabilities database at lwn.net/Alerts is unrestricted).

For some packages, subscribing to their 'announce' lists will provide prompt news of newer versions.

make-ca-1.14

Introduction to make-ca

Public Key Infrastructure (PKI) is a method to validate the authenticity of an otherwise unknown entity across untrusted networks. PKI works by establishing a chain of trust, rather than trusting each individual host or entity explicitly. In order for a certificate presented by a remote entity to be trusted, that certificate must present a complete chain of certificates that can be validated using the root certificate of a Certificate Authority (CA) that is trusted by the local machine.

Establishing trust with a CA involves validating things like company address, ownership, contact information, etc., and ensuring that the CA has followed best practices, such as undergoing periodic security audits by independent investigators and maintaining an always available certificate revocation list. This is well outside the scope of BLFS (as it is for most Linux distributions). The certificate store provided here is taken from the Mozilla Foundation, who have established very strict inclusion policies described here.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

Note

This package ships a CA certificate for validating the identity of https://hg.mozilla.org/. If the trust chain of this website has been changed after the release of make-ca-1.14, it may fail to get the revision of certdata.txt from server. Use an updated make-ca release at the release page if this issue happens.

make-ca Dependencies

Required

p11-kit-0.25.5 (runtime, built after libtasn1-4.19.0, required in the following instructions to generate certificate stores from trust anchors, and each time make-ca is run)

Optional (runtime)

nss-3.103 (to generate a shared NSSDB)

Installation of make-ca and Generation of the CA-certificates stores

The make-ca script will download and process the certificates included in the certdata.txt file for use as trust anchors for the p11-kit-0.25.5 trust module. Additionally, it will generate system certificate stores used by BLFS applications (if the recommended and optional applications are present on the system). Any local certificates stored in /etc/ssl/local will be imported to both the trust anchors and the generated certificate stores (overriding Mozilla's trust). Additionally, any modified trust values will be copied from the trust anchors to /etc/ssl/local prior to any updates, preserving custom trust values that differ from Mozilla when using the trust utility from p11-kit to operate on the trust store.

To install the various certificate stores, first install the make-ca script into the correct location. As the root user:

make install &&
install -vdm755 /etc/ssl/local

Note

Technically, this package is already installed at this point. But most packages listing make-ca as a dependency actually require the system certificate store set up by this package, rather than the make-ca program itself. So the instructions for using make-ca for setting up the system certificate store are included in this section. You should make sure the required runtime dependency for make-ca is satisfied now, and continue to follow the instructions.

As the root user, download the certificate source and prepare for system use with the following command:

Note

If running the script a second time with the same version of certdata.txt, for instance, to update the stores when make-ca is upgraded, or to add additional stores as the requisite software is installed, replace the -g switch with the -r switch in the command line. If packaging, run make-ca --help to see all available command line options.

/usr/sbin/make-ca -g

You should periodically update the store with the above command, either manually, or via a systemd timer. A timer is installed at /usr/lib/systemd/system/update-pki.timer that, if enabled, will check for updates weekly. Execute the following commands, as the root user, to enable the systemd timer:

systemctl enable update-pki.timer

Configuring make-ca

For most users, no additional configuration is necessary, however, the default certdata.txt file provided by make-ca is obtained from the mozilla-release branch, and is modified to provide a Mercurial revision. This will be the correct version for most systems. There are several other variants of the file available for use that might be preferred for one reason or another, including the files shipped with Mozilla products in this book. RedHat and OpenSUSE, for instance, use the version included in nss-3.103. Additional upstream downloads are available at the links included in /etc/make-ca/make-ca.conf.dist. Simply copy the file to /etc/make-ca.conf and edit as appropriate.

About Trust Arguments

There are three trust types that are recognized by the make-ca script, SSL/TLS, S/Mime, and code signing. For OpenSSL, these are serverAuth, emailProtection, and codeSigning respectively. If one of the three trust arguments is omitted, the certificate is neither trusted, nor rejected for that role. Clients that use OpenSSL or NSS encountering this certificate will present a warning to the user. Clients using GnuTLS without p11-kit support are not aware of trusted certificates. To include this CA into the ca-bundle.crt, email-ca-bundle.crt, or objsign-ca-bundle.crt files (the GnuTLS legacy bundles), it must have the appropriate trust arguments.

Adding Additional CA Certificates

The /etc/ssl/local directory is available to add additional CA certificates to the system trust store. This directory is also used to store certificates that were added to or modified in the system trust store by p11-kit-0.25.5 so that trust values are maintained across upgrades. Files in this directory must be in the OpenSSL trusted certificate format. Certificates imported using the trust utility from p11-kit-0.25.5 will utilize the x509 Extended Key Usage values to assign default trust values for the system anchors.

If you need to override trust values, or otherwise need to create an OpenSSL trusted certificate manually from a regular PEM encoded file, you need to add trust arguments to the openssl command, and create a new certificate. For example, using the CAcert roots, if you want to trust both for all three roles, the following commands will create appropriate OpenSSL trusted certificates (run as the root user after Wget-1.24.5 is installed):

wget http://www.cacert.org/certs/root.crt &&
wget http://www.cacert.org/certs/class3.crt &&
openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 1 root" \
        -addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
        > /etc/ssl/local/CAcert_Class_1_root.pem &&
openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert Class 3 root" \
        -addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
        > /etc/ssl/local/CAcert_Class_3_root.pem &&
/usr/sbin/make-ca -r

Overriding Mozilla Trust

Occasionally, there may be instances where you don't agree with Mozilla's inclusion of a particular certificate authority. If you'd like to override the default trust of a particular CA, simply create a copy of the existing certificate in /etc/ssl/local with different trust arguments. For example, if you'd like to distrust the "Makebelieve_CA_Root" file, run the following commands:

openssl x509 -in /etc/ssl/certs/Makebelieve_CA_Root.pem \
             -text \
             -fingerprint \
             -setalias "Disabled Makebelieve CA Root" \
             -addreject serverAuth \
             -addreject emailProtection \
             -addreject codeSigning \
       > /etc/ssl/local/Disabled_Makebelieve_CA_Root.pem &&
/usr/sbin/make-ca -r

Using make-ca with Python3

When Python3 was installed in LFS, it included the pip3 module with vendored certificates from the Certifi module. That was necessary, but it means that whenever pip3 is used it can reference those certificates, primarily when creating a virtual environment or when installing a module with all its wheel dependencies in one go.

It is generally considered that the System Administrator should be in charge of which certificates are available. Now that make-ca-1.14 and p11-kit-0.25.5 have been installed and make-ca has been configured, it is possible to make pip3 use the system certificates.

The vendored certificates installed in LFS are a snapshot from when the pulled-in version of Certifi was created. If you regularly update the system certificates, the vendored version will become out of date.

To use the system certificates in Python3, you should set _PIP_STANDALONE_CERT to point to them, e.g for the bash shell:

export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt

Warning

If you have created virtual environments, for example when testing modules, and those include the Requests and Certifi modules in ~/.local/lib/python3.12/, then those local modules will be used instead of the system certificates unless you remove the local modules.

To use the system certificates in Python3 with the BLFS profiles, add the following variable to your system or personal profiles:

mkdir -pv /etc/profile.d &&
cat > /etc/profile.d/pythoncerts.sh << "EOF"
# Begin /etc/profile.d/pythoncerts.sh

export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt

# End /etc/profile.d/pythoncerts.sh
EOF

Contents

Installed Programs: make-ca
Installed Directories: /etc/ssl/{certs,local} and /etc/pki/{nssdb,anchors,tls/{certs,java}}

Short Descriptions

make-ca

is a shell script that adapts a current version of certdata.txt, and prepares it for use as the system trust store

CrackLib-2.10.2

Introduction to CrackLib

The CrackLib package contains a library used to enforce strong passwords by comparing user selected passwords to words in chosen word lists.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

Additional Downloads

Recommended word list for English-speaking countries:

There are additional word lists available for download, e.g., from https://wiki.skullsecurity.org/index.php/Passwords. CrackLib can utilize as many, or as few word lists you choose to install.

Important

Users tend to base their passwords on regular words of the spoken language, and crackers know that. CrackLib is intended to filter out such bad passwords at the source using a dictionary created from word lists. To accomplish this, the word list(s) for use with CrackLib must be an exhaustive list of words and word-based keystroke combinations likely to be chosen by users of the system as (guessable) passwords.

The default word list recommended above for downloading mostly satisfies this role in English-speaking countries. In other situations, it may be necessary to download (or even create) additional word lists.

Note that word lists suitable for spell-checking are not usable as CrackLib word lists in countries with non-Latin based alphabets, because of word-based keystroke combinations that make bad passwords.

Installation of CrackLib

Install CrackLib by running the following commands:

./configure --prefix=/usr    \
            --disable-static \
            --with-default-dict=/usr/lib/cracklib/pw_dict &&
make

Now, as the root user:

make install

Issue the following commands as the root user to install the recommended word list and create the CrackLib dictionary. Other word lists (text based, one word per line) can also be used by simply installing them into /usr/share/dict and adding them to the create-cracklib-dict command.

install -v -m644 -D    ../cracklib-words-2.10.2.xz \
                         /usr/share/dict/cracklib-words.xz    &&

unxz -v                  /usr/share/dict/cracklib-words.xz    &&
ln -v -sf cracklib-words /usr/share/dict/words                &&
echo $(hostname) >>      /usr/share/dict/cracklib-extra-words &&
install -v -m755 -d      /usr/lib/cracklib                    &&

create-cracklib-dict     /usr/share/dict/cracklib-words \
                         /usr/share/dict/cracklib-extra-words

If desired, check the proper operation of the library as an unprivileged user by issuing the following command:

make test

Important

If you are installing CrackLib after your LFS system has been completed and you have the Shadow package installed, you must reinstall Shadow-4.16.0 if you wish to provide strong password support on your system. If you are now going to install the Linux-PAM-1.6.1 package, you may disregard this note as Shadow will be reinstalled after the Linux-PAM installation.

Command Explanations

--with-default-dict=/usr/lib/cracklib/pw_dict: This parameter forces the installation of the CrackLib dictionary to the /lib hierarchy.

--disable-static: This switch prevents installation of static versions of the libraries.

install -v -m644 -D ...: This command creates the /usr/share/dict directory (if it doesn't already exist) and installs the compressed word list there.

ln -v -s cracklib-words /usr/share/dict/words: The word list is linked to /usr/share/dict/words as historically, words is the primary word list in the /usr/share/dict directory. Omit this command if you already have a /usr/share/dict/words file installed on your system.

echo $(hostname) >>...: The value of hostname is echoed to a file called cracklib-extra-words. This extra file is intended to be a site specific list which includes easy to guess passwords such as company or department names, user names, product names, computer names, domain names, etc.

create-cracklib-dict ...: This command creates the CrackLib dictionary from the word lists. Modify the command to add any additional word lists you have installed.

Contents

Installed Programs: cracklib-check, cracklib-format, cracklib-packer, cracklib-unpacker, cracklib-update, and create-cracklib-dict
Installed Libraries: libcrack.so and the _cracklib.so (Python module)
Installed Directories: /usr/lib/cracklib, /usr/share/dict and /usr/share/cracklib

Short Descriptions

cracklib-check

is used to determine if a password is strong

cracklib-format

is used to format text files (lowercases all words, removes control characters and sorts the lists)

cracklib-packer

creates a database with words read from standard input

cracklib-unpacker

displays on standard output the database specified

create-cracklib-dict

is used to create the CrackLib dictionary from the given word list(s)

libcrack.so

provides a fast dictionary lookup method for strong password enforcement

cryptsetup-2.7.4

Introduction to cryptsetup

cryptsetup is used to set up transparent encryption of block devices using the kernel crypto API.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

cryptsetup Dependencies

Required

JSON-C-0.17, LVM2-2.03.26, and popt-1.19

Optional

asciidoctor-2.0.23, libpwquality-1.4.5, argon2, libssh, and passwdqc

Kernel Configuration

Encrypted block devices require kernel support. To use it, the appropriate kernel configuration parameters need to be set:

Device Drivers --->
  [*] Multiple devices driver support (RAID and LVM) --->                   [MD]
    <*/M> Device mapper support                                     [BLK_DEV_DM]
    <*/M>   Crypt target support                                      [DM_CRYPT]

-*- Cryptographic API --->                                              [CRYPTO]
  Block ciphers --->
    <*/M> AES (Advanced Encryption Standard)                        [CRYPTO_AES]
    # For tests:
    <*/M> Twofish                                               [CRYPTO_TWOFISH]
  Length-preserving ciphers and modes --->
    <*/M> XTS (XOR Encrypt XOR with ciphertext stealing)            [CRYPTO_XTS]
  Hashes, digests, and MACs --->
    <*/M> SHA-224 and SHA-256                                    [CRYPTO_SHA256]
  Userspace interface --->
    <*/M> Symmetric key cipher algorithms             [CRYPTO_USER_API_SKCIPHER]

Installation of cryptsetup

Install cryptsetup by running the following commands:

./configure --prefix=/usr       \
            --disable-ssh-token \
            --disable-asciidoc  &&
make

To test the result, issue as the root user: make check. Some tests will fail if appropriate kernel configuration options are not set. Some additional options that may be needed for tests are:

CONFIG_SCSI_LOWLEVEL,
CONFIG_SCSI_DEBUG,
CONFIG_BLK_DEV_DM_BUILTIN,
CONFIG_CRYPTO_USER,
CONFIG_CRYPTO_CRYPTD,
CONFIG_CRYPTO_LRW,
CONFIG_CRYPTO_XTS,
CONFIG_CRYPTO_ESSIV,
CONFIG_CRYPTO_CRCT10DIF,
CONFIG_CRYPTO_AES_TI,
CONFIG_CRYPTO_AES_NI_INTEL,
CONFIG_CRYPTO_BLOWFISH,
CONFIG_CRYPTO_CAST5,
CONFIG_CRYPTO_SERPENT,
CONFIG_CRYPTO_SERPENT_SSE2_X86_64,
CONFIG_CRYPTO_SERPENT_AVX_X86_64,
CONFIG_CRYPTO_SERPENT_AVX2_X86_64, and
CONFIG_CRYPTO_TWOFISH_X86_64

Now, as the root user:

make install

Command Explanations

--disable-ssh-token: This switch is required if the optional libssh dependency is not installed.

--disable-asciidoc: This switch disables regeneration of the man pages. Remove this switch if you have asciidoctor-2.0.23 installed and wish to regenerate the man pages. Note that even if this switch is used, the pre-generated man pages are shipped in the tarball and they'll still be installed.

Configuring cryptsetup

Because of the number of possible configurations, setup of encrypted volumes is beyond the scope of the BLFS book. Please see the configuration guide in the cryptsetup FAQ.

Contents

Installed Programs: cryptsetup, cryptsetup-reencrypt, integritysetup, and veritysetup
Installed Libraries: libcryptsetup.so
Installed Directories: None

Short Descriptions

cryptsetup

is used to setup dm-crypt managed device-mapper mappings

cryptsetup-reencrypt

is a tool for offline LUKS device re-encryption

integritysetup

is a tool to manage dm-integrity (block level integrity) volumes

veritysetup

is used to configure dm-verity managed device-mapper mappings. The Device-mapper verity target provides read-only transparent integrity checking of block devices using the kernel crypto API

Cyrus SASL-2.1.28

Introduction to Cyrus SASL

The Cyrus SASL package contains a Simple Authentication and Security Layer implementation, a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

Cyrus SASL Dependencies

Recommended
Optional

Linux-PAM-1.6.1, MIT Kerberos V5-1.21.3, MariaDB-10.11.8 or MySQL, OpenLDAP-2.6.8, PostgreSQL-16.4, sphinx-8.0.2, SQLite-3.46.1, Berkeley DB (deprecated), krb4, Dmalloc, and Pod::POM::View::Restructured

Installation of Cyrus SASL

Note

This package does not support parallel build.

First, fix a problem revealed by gcc-14:

sed '/saslint/a #include <time.h>'       -i lib/saslutil.c &&
sed '/plugin_common/a #include <time.h>' -i plugins/cram.c

Install Cyrus SASL by running the following commands:

./configure --prefix=/usr                       \
            --sysconfdir=/etc                   \
            --enable-auth-sasldb                \
            --with-dblib=lmdb                   \
            --with-dbpath=/var/lib/sasl/sasldb2 \
            --with-sphinx-build=no              \
            --with-saslauthd=/var/run/saslauthd &&
make -j1

This package does not come with a test suite. If you are planning on using the GSSAPI authentication mechanism, test it after installing the package using the sample server and client programs which were built in the preceding step. Instructions for performing the tests can be found at https://www.linuxfromscratch.org/hints/downloads/files/cyrus-sasl.txt.

Now, as the root user:

make install &&
install -v -dm755                          /usr/share/doc/cyrus-sasl-2.1.28/html &&
install -v -m644  saslauthd/LDAP_SASLAUTHD /usr/share/doc/cyrus-sasl-2.1.28      &&
install -v -m644  doc/legacy/*.html        /usr/share/doc/cyrus-sasl-2.1.28/html &&
install -v -dm700 /var/lib/sasl

Command Explanations

--with-dbpath=/var/lib/sasl/sasldb2: This switch forces the sasldb database to be created in /var/lib/sasl instead of /etc.

--with-saslauthd=/var/run/saslauthd: This switch forces saslauthd to use the FHS compliant directory /var/run/saslauthd for variable run-time data.

--enable-auth-sasldb: This switch enables SASLDB authentication backend.

--with-dblib=gdbm: This switch forces GDBM to be used instead of LMDB.

--with-ldap: This switch enables the OpenLDAP support.

--enable-ldapdb: This switch enables the LDAPDB authentication backend.

--enable-login: This option enables unsupported LOGIN authentication.

--enable-ntlm: This option enables unsupported NTLM authentication.

install -v -m644 ...: These commands install documentation which is not installed by the make install command.

install -v -m700 -d /var/lib/sasl: This directory must exist when starting saslauthd or using the sasldb plugin. If you're not going to be running the daemon or using the plugins, you may omit the creation of this directory.

Configuring Cyrus SASL

Config Files

/etc/saslauthd.conf (for saslauthd LDAP configuration) and /etc/sasl2/Appname.conf (where "Appname" is the application defined name of the application)

Configuration Information

See https://www.cyrusimap.org/sasl/sasl/sysadmin.html for information on what to include in the application configuration files.

See file:///usr/share/doc/cyrus-sasl-2.1.28/LDAP_SASLAUTHD for configuring saslauthd with OpenLDAP.

See https://www.cyrusimap.org/sasl/sasl/gssapi.html#gssapi for configuring saslauthd with Kerberos.

Systemd Unit

If you need to run the saslauthd daemon at system startup, install the saslauthd.service unit included in the blfs-systemd-units-20240801 package using the following command:

make install-saslauthd

Note

You'll need to modify /etc/default/saslauthd and modify the MECHANISM parameter with your desired authentication mechanism. The default authentication mechanism is "shadow".

Contents

Installed Programs: pluginviewer, saslauthd, sasldblistusers2, saslpasswd2, and testsaslauthd
Installed Library: libsasl2.so
Installed Directories: /usr/include/sasl, /usr/lib/sasl2, /usr/share/doc/cyrus-sasl-2.1.28 and /var/lib/sasl

Short Descriptions

pluginviewer

is used to list loadable SASL plugins and their properties

saslauthd

is the SASL authentication server

sasldblistusers2

is used to list the users in the SASL password database sasldb2

saslpasswd2

is used to set and delete a user's SASL password and mechanism specific secrets in the SASL password database sasldb2

testsaslauthd

is a test utility for the SASL authentication server

libsasl2.so

is a general purpose authentication library for server and client applications

GnuPG-2.4.5

Introduction to GnuPG

The GnuPG package is GNU's tool for secure communication and data storage. It can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440 and the S/MIME standard as described by several RFCs. GnuPG 2 is the stable version of GnuPG integrating support for OpenPGP and S/MIME.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

GnuPG 2 Dependencies

Required

libassuan-3.0.1, libgcrypt-1.11.0, libksba-1.6.7, npth-1.7, and OpenLDAP-2.6.8

Recommended
Optional

cURL-8.9.1, Fuse-3.16.2, ImageMagick-7.1.1-36 (for the convert utility, used for generating the documentation), libusb-1.0.27, an MTA, SQLite-3.46.1, texlive-20240312 (or install-tl-unx), fig2dev (for generating documentation), and GNU adns

Installation of GnuPG

Install GnuPG by running the following commands:

mkdir build &&
cd    build &&

../configure --prefix=/usr           \
             --localstatedir=/var    \
             --sysconfdir=/etc       \
             --docdir=/usr/share/doc/gnupg-2.4.5 &&
make &&

makeinfo --html --no-split -I doc -o doc/gnupg_nochunks.html ../doc/gnupg.texi &&
makeinfo --plaintext       -I doc -o doc/gnupg.txt           ../doc/gnupg.texi &&
make -C doc html

If you have texlive-20240312 installed and you wish to create documentation in the pdf format, issue the following command:

make -C doc pdf

To test the results, issue: make check.

Now, as the root user:

make install &&

install -v -m755 -d /usr/share/doc/gnupg-2.4.5/html            &&
install -v -m644    doc/gnupg_nochunks.html \
                    /usr/share/doc/gnupg-2.4.5/html/gnupg.html &&
install -v -m644    ../doc/*.texi doc/gnupg.txt \
                    /usr/share/doc/gnupg-2.4.5 &&
install -v -m644    doc/gnupg.html/* \
                    /usr/share/doc/gnupg-2.4.5/html

If you created the pdf format of the documentation, install them using the following command as the root user:

install -v -m644 doc/gnupg.pdf \
                 /usr/share/doc/gnupg-2.4.5

Command Explanations

mkdir build && cd build: the Gnupg2 developers recommend to build the package in a dedicated directory.

--docdir=/usr/share/doc/gnupg-2.4.5: This switch changes the default docdir to /usr/share/doc/gnupg-2.4.5.

--enable-all-tests: This switch allows more tests to be run with make check.

--enable-g13: This switch enables building the g13 program.

Contents

Installed Programs: addgnupghome, applygnupgdefaults, dirmngr, dirmngr-client, g13 (optional), gpg-agent, gpg-card, gpg-connect-agent, gpg, gpgconf, gpgparsemail, gpgscm, gpgsm, gpgsplit, gpgtar, gpgv, gpg-wks-client, gpg-wks-server, kbxutil, and watchgnupg
Installed Libraries: None
Installed Directories: /usr/share/doc/gnupg-2.4.5 and /usr/share/gnupg

Short Descriptions

addgnupghome

is used to create and populate a user's ~/.gnupg directories

applygnupgdefaults

is a wrapper script used to run gpgconf with the --apply-defaults parameter on all user's GnuPG home directories

dirmngr

is a tool that takes care of accessing the OpenPGP keyservers

dirmngr-client

is a tool to contact a running dirmngr and test whether a certificate has been revoked

g13

is a tool to create, mount or unmount an encrypted file system container (optional)

gpg-agent

is a daemon used to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities

gpg-card

is a tool to manage smart cards and tokens

gpg-connect-agent

is a utility used to communicate with a running gpg-agent

gpg

is the OpenPGP part of the GNU Privacy Guard (GnuPG). It is a tool used to provide digital encryption and signing services using the OpenPGP standard

gpgconf

is a utility used to automatically and reasonably safely query and modify configuration files in the ~/.gnupg home directory. It is designed not to be invoked manually by the user, but automatically by graphical user interfaces

gpgparsemail

is a utility currently only useful for debugging. Run it with --help for usage information

gpgscm

executes the given scheme program or spawns an interactive shell

gpgsm

is a tool similar to gpg used to provide digital encryption and signing services on X.509 certificates and the CMS protocol. It is mainly used as a backend for S/MIME mail processing

gpgsplit

splits an OpenPGP message into packets

gpgtar

is a tool to encrypt or sign files into an archive

gpgv

is a verify only version of gpg

gpg-wks-client

is a client for the Web Key Service protocol

gpg-wks-server

provides a server for the Web Key Service protocol

kbxutil

is used to list, export and import Keybox data

watchgnupg

is used to listen to a Unix Domain socket created by any of the GnuPG tools

GnuTLS-3.8.7.1

Introduction to GnuTLS

The GnuTLS package contains libraries and userspace tools which provide a secure layer over a reliable transport layer. Currently the GnuTLS library implements the proposed standards by the IETF's TLS working group. Quoting from the TLS 1.3 protocol specification :

TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.

GnuTLS provides support for TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, and (optionally) SSL 3.0 protocols. It also supports TLS extensions, including server name and max record size. Additionally, the library supports authentication using the SRP protocol, X.509 certificates, and OpenPGP keys, along with support for the TLS Pre-Shared-Keys (PSK) extension, the Inner Application (TLS/IA) extension, and X.509 and OpenPGP certificate handling.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

Note

When extracting this package tarball, it expands to the gnutls-3.8.7 directory, instead of the expected gnutls-3.8.7.1 directory.

GnuTLS Dependencies

Required

Nettle-3.10

Recommended
Optional

Brotli-1.1.0, Doxygen-1.12.0, GTK-Doc-1.34.0, libidn-1.42 or libidn2-2.3.7, libseccomp-2.5.5, Net-tools-2.10 (used during the test suite), texlive-20240312 or install-tl-unx, Unbound-1.21.0 (to build the DANE library), Valgrind-3.23.0 (used during the test suite), autogen, cmocka and datefudge (used during the test suite if the DANE library is built), and Trousers (Trusted Platform Module support)

Note

Note that if you do not install libtasn1-4.19.0, a version shipped in the GnuTLS tarball will be used instead.

Installation of GnuTLS

Install GnuTLS by running the following commands:

./configure --prefix=/usr \
            --docdir=/usr/share/doc/gnutls-3.8.7.1 \
            --with-default-trust-store-pkcs11="pkcs11:" &&
make

One test hangs the test procedure. Disable it: sed '/ocsp-must-staple-connection/d' -i tests/Makefile. To test the results, now issue: make check.

Now, install the package as the root user:

make install

Command Explanations

--with-default-trust-store-pkcs11="pkcs11:": This switch tells gnutls to use the PKCS #11 trust store as the default trust. Omit this switch if p11-kit-0.25.5 is not installed.

--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt: This switch tells configure where to find the legacy CA certificate bundle and to use it instead of PKCS #11 module by default. Use this if p11-kit-0.25.5 is not installed.

--enable-gtk-doc: Use this parameter if GTK-Doc is installed and you wish to rebuild and install the API documentation.

--enable-openssl-compatibility: Use this switch if you wish to build the OpenSSL compatibility library.

--without-p11-kit: use this switch if you have not installed p11-kit.

--with-included-unistring: uses the bundled version of libunistring, instead of the system one. Use this switch if you have not installed libunistring-1.2.

--disable-dsa: completely disables DSA algorithm support.

Contents

Installed Programs: certtool, danetool, gnutls-cli, gnutls-cli-debug, gnutls-serv, ocsptool, p11tool, psktool, and srptool
Installed Libraries: libgnutls.so, libgnutls-dane.so, libgnutlsxx.so, and libgnutls-openssl.so (optional)
Installed Directories: /usr/include/gnutls and /usr/share/doc/gnutls-3.8.7.1

Short Descriptions

certtool

is used to generate X.509 certificates, certificate requests, and private keys

danetool

is a tool used to generate and check DNS resource records for the DANE protocol

gnutls-cli

is a simple client program to set up a TLS connection to some other computer

gnutls-cli-debug

is a simple client program to set up a TLS connection to some other computer and produces very verbose progress results

gnutls-serv

is a simple server program that listens to incoming TLS connections

ocsptool

is a program that can parse and print information about OCSP requests/responses, generate requests and verify responses

p11tool

is a program that allows handling data from PKCS #11 smart cards and security modules

psktool

is a simple program that generates random keys for use with TLS-PSK

srptool

is a simple program that emulates the programs in the Stanford SRP (Secure Remote Password) libraries using GnuTLS

libgnutls.so

contains the core API functions and X.509 certificate API functions

GPGME-1.23.2

Introduction to GPGME

The GPGME package is a C library that allows cryptography support to be added to a program. It is designed to make access to public key crypto engines like GnuPG or GpgSM easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification and key management.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

GPGME Dependencies

Required

libassuan-3.0.1

Optional

Doxygen-1.12.0 and Graphviz-12.1.0 (for API documentation), GnuPG-2.4.5 (required if Qt or SWIG are installed; used during the test suite), Clisp-2.49, qt5-components-5.15.14, and SWIG-4.2.1 (for language bindings)

Installation of GPGME

Install GPGME by running the following commands:

mkdir build &&
cd    build &&

../configure --prefix=/usr --disable-gpg-test &&
make PYTHONS=

If SWIG-4.2.1 is installed, build the Python 3 binding as a wheel:

if swig -version > /dev/null; then
  srcdir=$PWD/../lang/python \
  top_builddir=$PWD          \
  pip3 wheel -w dist --no-build-isolation --no-deps --no-cache-dir $PWD/lang/python
fi

To test the results, you should have GnuPG-2.4.5 installed and remove the --disable-gpg-test above. If SWIG-4.2.1 is installed, it's necessary to adapt the test suite to use the Python 3 binding just built as a wheel as well. Issue:

if swig -version > /dev/null; then
  python3 -m venv testenv                                              &&
  testenv/bin/pip3 install --no-index --find-links=dist --no-cache-dir \
                           gpg                                         &&
  sed '/PYTHON/s#run-tests.py#& --python-libdir=/dev/null#'            \
      -i lang/python/tests/Makefile
fi &&

make -k check PYTHONS= PYTHON=$PWD/testenv/bin/python3

One test named t-quick-key-manipulation.py is known to fail.

Now, as the root user:

make install PYTHONS=

If SWIG-4.2.1 is installed, still as the root user, install the Python 3 binding:

if swig -version > /dev/null; then
  pip3 install --no-index --find-links=dist --no-cache-dir --no-user gpg
fi

Command Explanations

--disable-gpg-test: if this parameter is not passed to configure, the test programs are built during make stage, which requires GnuPG-2.4.5. This parameter is not needed if GnuPG-2.4.5 is installed.

PYTHONS=: Disable building Python binding using the deprecated python3 setup.py build command. The explicit instruction to build the Python 3 binding with the pip3 wheel command is provided.

Contents

Installed Program: gpgme-json, and gpgme-tool
Installed Libraries: libgpgme.so, libgpgmepp.so, and libqgpgme.so
Installed Directory: /usr/include/{gpgme++,qgpgme,QGpgME}, /usr/lib/cmake/{Gpgmepp,QGpgme}. /usr/lib/python3.12/site-packages/gpg{,-1.23.2.dist-info}, and /usr/share/common-lisp/source/gpgme

Short Descriptions

gpgme-json

outputs GPGME commands in JSON format

gpgme-tool

is an assuan server exposing GPGME operations, such as printing fingerprints and keyids with keyservers

libgpgme.so

contains the GPGME API functions

libgpgmepp.so

contains the C++ GPGME API functions

libqgpgme.so

contains API functions for handling GPG operations in Qt applications

iptables-1.8.10

Introduction to iptables

iptables is a userspace command line program used to configure the Linux 2.4 and later kernel packet filtering ruleset.

This package is known to build and work properly using an LFS 12.2 platform.

Package Information

iptables Dependencies

Optional

libpcap-1.10.4 (required for BPF compiler or nfsynproxy support), bpf-utils (required for Berkeley Packet Filter support), libnfnetlink (required for connlabel support), libnetfilter_conntrack (required for connlabel support), and nftables

Kernel Configuration

A firewall in Linux is accomplished through the netfilter interface. To use iptables to configure netfilter, the following kernel configuration parameters are required:

[*] Networking support --->                                                [NET]
  Networking options --->
    [*] Network packet filtering framework (Netfilter) --->          [NETFILTER]
      [*] Advanced netfilter configuration                  [NETFILTER_ADVANCED]
      Core Netfilter Configuration --->
        <*/M> Netfilter connection tracking support               [NF_CONNTRACK]
        <*/M> Netfilter Xtables support (required for ip_tables)
                                                        ...  [NETFILTER_XTABLES]
        <*/M>   LOG target support                     [NETFILTER_XT_TARGET_LOG]
      IP: Netfilter Configuration --->
        <*/M> IP tables support (required for filtering/masq/NAT)
                                                           ...  [IP_NF_IPTABLES]

Include any connection tracking protocols that will be used, as well as any protocols that you wish to use for match support under the "Core Netfilter Configuration" section. The above options are enough for running Creating a Personal Firewall With iptables below.

Installation of iptables

Note

The installation below does not include building some specialized extension libraries which require the raw headers in the Linux source code. If you wish to build the additional extensions (if you aren't sure, then you probably don't), you can look at the INSTALL file to see an example of how to change the KERNEL_DIR= parameter to point at the Linux source code. Note that if you upgrade the kernel version, you may also need to recompile iptables and that the BLFS team has not tested using the raw kernel headers.

Install iptables by running the following commands:

./configure --prefix=/usr      \
            --disable-nftables \
            --enable-libipq    &&
make

This package does not come with a test suite.

Now, as the root user:

make install

Command Explanations

--disable-nftables: This switch disables building nftables compatibility.

--enable-libipq: This switch enables building of libipq.so which can be used by some packages outside of BLFS.

--enable-nfsynproxy: This switch enables installation of nfsynproxy SYNPROXY configuration tool.

Configuring iptables

Note

In the following example configurations, LAN1 is used for the internal LAN interface, and WAN1 is used for the external interface connected to the Internet. You will need to replace these values with appropriate interface names for your system.

Personal Firewall

A Personal Firewall is designed to let you access all the services offered on the Internet while keeping your computer secure and your data private.

Below is a slightly modified version of Rusty Russell's recommendation from the Linux 2.4 Packet Filtering HOWTO. It is still applicable to the Linux 6.x kernels.

install -v -dm755 /etc/systemd/scripts

cat > /etc/systemd/scripts/iptables << "EOF"
#!/bin/sh

# Begin /etc/systemd/scripts/iptables

# Insert connection-tracking modules
# (not needed if built into the kernel)
modprobe nf_conntrack
modprobe xt_LOG

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects

# Do not send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface, where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians

# be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# disable Explicit Congestion Notification
# too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local-only connections
iptables -A INPUT  -i lo -j ACCEPT

# Free output on any interface to any ip for any service
# (equal to -P ACCEPT)
iptables -A OUTPUT -j ACCEPT

# Permit answers on already established connections
# and permit new connections related to established ones
# (e.g. port mode ftp)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Log everything else.
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "

# End /etc/systemd/scripts/iptables
EOF
chmod 700 /etc/systemd/scripts/iptables

This script is quite simple, it drops all traffic coming into your computer that wasn't initiated from your computer, but as long as you are simply surfing the Internet you are unlikely to exceed its limits.

If you frequently encounter certain delays at accessing FTP servers, take a look at BusyBox with iptables example number 4.

Even if you have daemons or services running on your system, these will be inaccessible everywhere but from your computer itself. If you want to allow access to services on your machine, such as ssh or ping, take a look at Creating a BusyBox With iptables.

Masquerading Router

A Network Firewall has two interfaces, one connected to an intranet, in this example LAN1, and one connected to the Internet, here WAN1. To provide the maximum security for the firewall itself, make sure that there are no unnecessary servers running on it such as X11. As a general principle, the firewall itself should not access any untrusted service (think of a remote server giving answers that makes a daemon on your system crash, or even worse, that implements a worm via a buffer-overflow).

install -v -dm755 /etc/systemd/scripts

cat > /etc/systemd/scripts/iptables << "EOF"
#!/bin/sh

# Begin /etc/systemd/scripts/iptables

echo
echo "You're using the example configuration for a setup of a firewall"
echo "from Beyond Linux From Scratch."
echo "This example is far from being complete, it is only meant"
echo "to be a reference."
echo "Firewall security is a complex issue, that exceeds the scope"
echo "of the configuration rules below."

echo "You can find additional information"
echo "about firewalls in Chapter 4 of the BLFS book."
echo "https://www.linuxfromscratch.org/blfs"
echo

# Insert iptables modules (not needed if built into the kernel).

modprobe nf_conntrack
modprobe nf_conntrack_ftp
modprobe xt_conntrack
modprobe xt_LOG
modprobe xt_state

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

# Don't send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# Be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# Disable Explicit Congestion Notification
# Too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local connections
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow forwarding if the initiated on the intranet
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD ! -i WAN1 -m conntrack --ctstate NEW       -j ACCEPT

# Do masquerading
# (not needed if intranet is not using private ip-addresses)
iptables -t nat -A POSTROUTING -o WAN1 -j MASQUERADE

# Log everything for debugging
# (last of all rules, but before policy rules)
iptables -A INPUT   -j LOG --log-prefix "FIREWALL:INPUT "
iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD "
iptables -A OUTPUT  -j LOG --log-prefix "FIREWALL:OUTPUT "

# Enable IP Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# The following sections allow inbound packets for specific examples
# Uncomment the example lines and adjust as necessary

# Allow ping on the external interface
#iptables -A INPUT  -p icmp -m icmp --icmp-type echo-request -j ACCEPT
#iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply   -j ACCEPT

# Reject ident packets with TCP reset to avoid delays with FTP or IRC
#iptables -A INPUT  -p tcp --dport 113 -j REJECT --reject-with tcp-reset

# Allow HTTP and HTTPS to 192.168.0.2
#iptables -A PREROUTING -t nat -i WAN1 -p tcp --dport 80 -j DNAT --to 192.168.0.2
#iptables -A PREROUTING -t nat -i WAN1 -p tcp --dport 443 -j DNAT --to 192.168.0.2
#iptables -A FORWARD -p tcp -d 192.168.0.2 --dport 80 -j ACCEPT
#iptables -A FORWARD -p tcp -d 192.168.0.2 --dport 443 -j ACCEPT

# End /etc/systemd/scripts/iptables
EOF
chmod 700 /etc/systemd/scripts/iptables

With this script your intranet should be reasonably secure against external attacks. No one should be able to setup a new connection to any internal service and, if it's masqueraded, makes your intranet invisible to the Internet. Furthermore, your firewall should be relatively safe because there are no services running that a cracker could attack.

BusyBox

This scenario isn't too different from the Creating a Masquerading Router With iptables, but additionally offers some services to your intranet. Examples of this can be when you want to administer your firewall from another host on your intranet or use it as a proxy or a name server.

Note

Outlining specifically how to protect a server that offers services on the Internet goes far beyond the scope of this document. See the references in the section called “Extra Information” for more information.

Be cautious. Every service you have enabled makes your setup more complex and your firewall less secure. You are exposed to the risks of misconfigured services or running a service with an exploitable bug. A firewall should generally not run any extra services. See the introduction to the Creating a Masquerading Router With iptables for some more details.

If you want to add services such as internal Samba or name servers that do not need to access the Internet themselves, the additional statements are quite simple and should still be acceptable from a security standpoint. Just add the following lines into the script before the logging rules.

iptables -A INPUT  -i ! WAN1  -j ACCEPT
iptables -A OUTPUT -o ! WAN1  -j ACCEPT

If daemons, such as squid, have to access the Internet themselves, you could open OUTPUT generally and restrict INPUT.

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT

However, it is generally not advisable to leave OUTPUT unrestricted. You lose any control over trojans who would like to "call home", and a bit of redundancy in case you've (mis-)configured a service so that it broadcasts its existence to the world.

To accomplish this, you should restrict INPUT and OUTPUT on all ports except those that it's absolutely necessary to have open. Which ports you have to open depends on your needs: mostly you will find them by looking for failed accesses in your log files.

Have a Look at the Following Examples:

  • Squid is caching the web:

    iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
    iptables -A INPUT  -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED \
      -j ACCEPT
  • Your caching name server (e.g., named) does its lookups via UDP:

    iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
  • You want to be able to ping your computer to ensure it's still alive:

    iptables -A INPUT  -p icmp -m icmp --icmp-type echo-request -j ACCEPT
    iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply   -j ACCEPT
  • If you are frequently accessing FTP servers or enjoy chatting, you might notice delays because some implementations of these daemons query an identd daemon on your system to obtain usernames. Although there's really little harm in this, having an identd running is not recommended because many security experts feel the service gives out too much additional information.

    To avoid these delays you could reject the requests with a 'tcp-reset' response:

    iptables -A INPUT  -p tcp --dport 113 -j REJECT --reject-with tcp-reset
  • To log and drop invalid packets (packets that came in after netfilter's timeout or some types of network scans) insert these rules at the top of the chain:

    iptables -I INPUT 0 -p tcp -m conntrack --ctstate INVALID \
      -j LOG --log-prefix "FIREWALL:INVALID "
    iptables -I INPUT 1 -p tcp -m conntrack --ctstate INVALID -j DROP
  • Anything coming from the outside should not have a private address, this is a common attack called IP-spoofing:

    iptables -A INPUT -i WAN1 -s 10.0.0.0/8     -j DROP
    iptables -A INPUT -i WAN1 -s 172.16.0.0/12  -j DROP
    iptables -A INPUT -i WAN1 -s 192.168.0.0/16 -j DROP

    There are other addresses that you may also want to drop: 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/3 (multicast and experimenta