Packages

BLFS general/python-modules.html. Last prerequisite for the Phase 1.5 GTK3+PyGObject installer -- lets Python drive real GTK3 dialogs (disk picker, progress bar, confirmation screens) via `from gi.repository import Gtk`. Requires glib2 and gtk3 to both already be rebuilt with introspection enabled, and gobject-introspection itself already built. Depends on `glib2` in the manifest graph (for build ordering against a fresh checkout), but in practice also needs gtk3's introspection data present at runtime for the installer's own Gtk.Window/Gtk.Dialog usage -- gtk3 isn't a hard build-time dependency of PyGObject itself (only glib/gobject/gio), so it's not listed here, but must be rebuilt with introspection=true before the installer app can actually import Gtk.

User-requested: PySide6 (Qt6 Python bindings), so a real PySide6 example app can run on LinuxDoors. Not in BLFS. Builds shiboken6 (the C++-to-Python binding generator, needs libclang -- confirmed this project's own existing packages/llvm build already provides a real /usr/lib/libclang.so + /usr/include/clang-c headers via LLVM_ENABLE_PROJECTS=clang, built originally for the Firefox/Rust chain, so no new LLVM work needed) and PySide6 itself in one combined build (pyside-setup's own real, documented setup.py entry point -- confirmed directly from the real README.pyside6.md: `python setup.py install --qtpaths=<path>/qtpaths6`). Depends on packages/qt6-full (not qt6-base) and packages/qtwebengine specifically so the generated bindings include PySide6.QtWebEngineWidgets/QtWebEngineCore, matching the user's explicit ask for the webengine module to be available from Python too. Kept OUT of the ISO via ship_in_iso=false, same mechanism as gimp/audacity/qt6-base/qt6-full/qtwebengine -- download-only. Installs into the system Python's site-packages (matching pip-style installs elsewhere in this project) rather than a separate /opt prefix, since it's a Python module, not a standalone toolkit. Real build failure hit and fixed: pyside-setup's own build uses patchelf to bake the correct RPATH (pointing at /opt/qt6-full/lib) into the built shiboken6/PySide6 binaries -- a real, previously-unbuilt tool, added as packages/patchelf (small, standalone, no dependencies).

LFS ch8, final build (ch7's python-tmp was a bootstrap version, built --without-ensurepip). This one does NOT disable ensurepip, so it should come with a working pip3 -- needed by flit-core/packaging/wheel/setuptools right after. Skips the optional test suite and the optional HTML docs install.

LFS ch7, inside the chroot. Some optional modules (e.g. ssl) are expected to fail to build at this stage per the book -- only the top-level `make` needs to succeed. Superseded by chapter 8's full python build.

linuxmint/python3-xapp -- the `xapp` Python module (xapp.os / xapp.settings / xapp.GSettingsWidgets). Separate repo from the C `xapp` library. cinnamon-screensaver, cinnamon-settings and Cinnamon applets `import xapp`. Master branch snapshot @ 3.0.3. Cinnamon 6.4 desktop, ship_in_iso=false.

Not in BLFS's own list -- same real build-time discovery as mako (mesa's meson.build also requires Python's yaml module). Uses the pure-Python YAML parser (we haven't built libyaml, so no C extension speedup, which is fine for build-time-only usage).

QCoro -- C++20 coroutines for Qt6. plasma-workspace/powerdevil (Plasma 6.7) require QCoro6. ship_in_iso=false, KDE Plasma chain.

KDE Frameworks 6 (6.29) -- the 'org.kde.desktop' QtQuick Controls style, Kdenlive's default. Without it Kdenlive's Splash.qml fails to load and Splash::Splash() segfaults on rootObjects().at(0) of an empty list (diagnosed via gdb on .101). ship_in_iso=false (Kdenlive stack = packages only). ECM+CMake+Ninja, Qt6 from /opt/qt6-full, --libdir=lib.

libqrencode -- QR code generator. KF6 Prison needs it for barcode rendering. ship_in_iso=false -- KDE Plasma is a Packages-page / Package Manager install, deliberately kept off linuxdoors.iso (XFCE + MATE are the shipped desktops). Built on .101 against the existing KF6 6.29 + Qt6 (/opt/qt6-full) stack from the Kdenlive work.

The lightweight of two Qt6 options (see also packages/qt6-full) -- just the qtbase submodule (QtCore/QtGui/QtWidgets/QtNetwork/etc, no QtDeclarative/QtSvg/QtMultimedia/QtWebEngine). Real, standalone submodule tarball from download.qt.io (verified it exists and is genuinely just qtbase, not the 972MB qt-everywhere monolith) -- enough to run a basic PySide6 QtWidgets example app without the multi-hour full build. User-requested extra, kept OUT of the ISO via ship_in_iso=false (same mechanism as packages/gimp, packages/audacity) -- download-only. Installs to /opt/qt6-base per BLFS's own recommendation (installing Qt6 into /usr makes it hard to find components/upgrade later) -- a distinct prefix from qt6-full so both could coexist if ever installed together, though in practice a user picks one or the other. Build commands adapted from BLFS x/qt6.html's own ./configure invocation, applied to the qtbase-only source tree.

BLFS x/qt6.html -- the full Qt-everywhere source tree (QtBase, QtDeclarative, QtSvg, QtMultimedia, QtWayland, QtQuick3D, etc). The heavyweight of two Qt6 options (see also packages/qt6-base, the qtbase-only lightweight alternative) -- 972MB source, real BLFS-documented multi-hour build. Follows BLFS's own real commands verbatim: qt3d/qtquick3dphysics/qtopcua removed (the book's own reasoning -- qt3d needs external libs this project doesn't have, qtquick3dphysics fails on 32-bit which is irrelevant here but kept for fidelity, qtopcua breaks against OpenSSL 3/4). qtwebengine is deliberately NOT removed from the source tree here (unlike the book, which drops it since it's genuinely a separate submodule/package -- see packages/qtwebengine, which depends on this package and is built as its own follow-on afterward against this installed Qt6). Installs to /opt/qt6-full (BLFS's own recommendation against installing into /usr). User-requested extra, kept OUT of the ISO via ship_in_iso=false (download-only, same mechanism as gimp/audacity/qt6-base). Cups and ICU included as real dependencies since both were already built in this project (Cups for BLFS/LinuxUltraOffice printing, ICU for the Chromium/Firefox chain) and Qt6 picks them up as real recommended features when present. Real operational note: because ship_in_iso=false means this package's destdir is never rsynced onto the live $LFS, packages/qtwebengine and packages/pyside6 -- which both genuinely need a real, usable Qt6 install inside the chroot at build time (qt-cmake, moc, uic, etc, not just a zip) -- needed a one-off manual `rsync -a .../qt6-full/destdir/ /mnt/lfs/` to temporarily make it available, with `/mnt/lfs/opt/qt6-full` removed again once those follow-on builds finished so it never leaks into a real ISO build.

LXQt's terminal emulator (built on qtermwidget). LXQt 2.4 minimal-but-real desktop stack, ship_in_iso=false (Packages-page / Package Manager install only, like KDE Plasma). Built on .101 against /opt/qt6-full + KF6 6.29. cmake/meson --libdir=lib for LinuxDoors' non-multiarch layout.

Terminal-emulator widget library (fork of Konsole's kpty/TerminalDisplay). LXQt 2.4 minimal-but-real desktop stack, ship_in_iso=false (Packages-page / Package Manager install only, like KDE Plasma). Built on .101 against /opt/qt6-full + KF6 6.29. cmake/meson --libdir=lib for LinuxDoors' non-multiarch layout.

Qt 6 Wayland add-on module (Qt6WaylandClient / Qt6WaylandCompositor). The prebuilt /opt/qt6-full was built X11-only; KF6 kguiaddons/kwindowsystem (KWaylandExtras) and Plasma's kwayland/layer-shell-qt/kwin all need it, even for the X11 Plasma session. Installs into /opt/qt6-full. ship_in_iso=false -- KDE Plasma is a Packages-page / Package Manager install, deliberately kept off linuxdoors.iso (XFCE + MATE are the shipped desktops). Built on .101 against the existing KF6 6.29 + Qt6 (/opt/qt6-full) stack from the Kdenlive work.

BLFS x/qtwebengine.html -- Chromium's rendering engine embedded in Qt (genuinely Chromium-scale: BLFS's own estimate is 12GB disk, 44 SBU build time). User-requested addition to the Qt6 package set, built as its OWN separate package against the already-installed packages/qt6-full (a real separate submodule tarball, not part of qt-everywhere -- confirmed directly from the book). Kept OUT of the ISO via ship_in_iso=false, same as qt6-base/qt6-full/gimp/audacity. Real dependency chain confirmed against the live book: required deps html5lib (pip-installed inline, a tiny pure-Python package, not worth its own LinuxDoors package entry), nodejs, nss, pciutils, rust-bindgen, Cups, and Qt6 itself -- nodejs/nss/rust-bindgen were already built for this project's earlier Chromium/Firefox chain work, and icu/cups/pciutils were likewise already present, so the only genuinely new dependency is html5lib. Deliberately does NOT force QT_FEATURE_webengine_system_ffmpeg=ON or QT_FEATURE_webengine_webrtc_pipewire=ON the way the book's own literal command does -- this project has neither a system ffmpeg nor pipewire package built, and forcing those flags ON would hard-fail configure (same class of gotcha hit repeatedly in the GIMP dependency chain: an explicit =ON feature flag needs the real library present, no auto-fallback). Left at their default (auto) instead, which falls through to QtWebEngine's own bundled/vendored copies of ffmpeg and WebRTC internals within its Chromium-derived third_party/ tree -- the same 'build using the vendored copy rather than pre-building every codec library separately' approach that already worked cleanly for this project's real ungoogled-chromium build. QT_FEATURE_webengine_system_icu=ON is kept (a real freebie -- ICU is already built) and QT_FEATURE_webengine_proprietary_codecs=ON is kept (H.264/AAC support, a compile-time flag with no extra package cost). Real operational gotcha hit and worth remembering: since qt6-full itself has ship_in_iso=false, its destdir is never rsynced onto the live $LFS by the normal engine flow -- but qtwebengine's own build genuinely needs a real, usable Qt6 install inside the chroot at build time (qt-cmake, moc, uic, etc.), not just a downloadable zip. Fixed by manually rsync-ing qt6-full's already-captured destdir (/mnt/lfs/build-tmp/qt6-full/destdir/) onto the live $LFS directly (bypassing the engine, a one-off `rsync -a .../destdir/ /mnt/lfs/`) just long enough to build qtwebengine and pyside6 against it, then removing /mnt/lfs/opt/qt6-full again afterward so it never leaks into a real ISO build. A second real gotcha, hit while polling this exact build: `pgrep -f` matches the FULL command line of every process, including the poller's OWN invoking shell if the search pattern text appears in it -- an unbracketed `pgrep -f 'qt6-full/build.sh'` falsely reported the qt6-full build as 'still running' for 4+ hours after it had genuinely finished (ground truth: destdir file count stable, qmake6/qtpaths6 present with real timestamps matching the log's last-write time, zero real ninja/cc1plus/make processes in the actual process tree). Same failure class already documented elsewhere in this project for `pkill -f`. Fixed by bracketing the pattern's first character (`[q]twebengine/build.sh`) in the poller used for this build. A third real gotcha, caught by an actual build failure: Qt6's own tools (qtpaths, moc, uic, ...) installed under /opt/qt6-full can't find their own shared libraries at runtime ('libQt6Core.so.6: cannot open shared object file') since that prefix was never added to the dynamic linker's search path -- fixed with `export LD_LIBRARY_PATH=/opt/qt6-full/lib:$LD_LIBRARY_PATH` in build.sh (same fix applied to packages/pyside6 proactively, since it depends on the same tools).

Runtime companion CLI (qtxdg-mat) for libqtxdg's default-app / mime handling. LXQt 2.4 minimal-but-real desktop stack, ship_in_iso=false (Packages-page / Package Manager install only, like KDE Plasma). Built on .101 against /opt/qt6-full + KF6 6.29. cmake/meson --libdir=lib for LinuxDoors' non-multiarch layout.

LFS ch8. Skips the optional doc/*.{ps,pdf,html,dvi} install step (not always fully generated, and not essential).

Real gap found while building packages/ungoogled-chromium with real Rust wired in for the first time (rust_sysroot_absolute=/opt/rustc-chromium): ninja failed wanting '../../third_party/rust-toolchain/bin/bindgen', a SEPARATE GN arg (rust_bindgen_root, build/config/rust.gni) from rust_sysroot_absolute -- Chromium's own Rust toolchain bundles bindgen-cli + rustfmt + libclang together under third_party/rust-toolchain, but rust_sysroot_absolute only covers the rustc/cargo/std side. bindgen itself is not part of the Rust distribution at all -- it's a real, independent crates.io tool (rust-lang/rust-bindgen, the C/C++-header-to-Rust-FFI-bindings generator), confirmed via crates.io's own API (max_stable_version 0.72.1) rather than guessed. Built here via `cargo install bindgen-cli --locked --root <destdir>/opt/rust-bindgen-tools`, using this project's own already-built rustc/cargo (packages/rustc, 1.97.1 -- bindgen-cli's own MSRV is well below that) and clang-chromium's libclang.so (LIBCLANG_PATH, since bindgen-cli's own build links against libclang via the clang-sys crate) rather than trying to build a fourth LLVM/clang from scratch. Chromium's build/rust/rust_bindgen.gni expects rust_bindgen_root to contain bin/bindgen, bin/rustfmt, and lib/ (for libclang) all under ONE root -- rustfmt and libclang aren't produced by this package's own build, so build.sh symlinks them in from packages/rustc (/opt/rustc/bin/rustfmt) and packages/clang-chromium (/opt/clang-chromium/lib) respectively, both of which already exist permanently on the real system by the time ungoogled-chromium builds (declared as this package's own real deps). packages/ungoogled-chromium/build.sh then sets rust_bindgen_root="/opt/rust-bindgen-tools" in args.gn -- an absolute-path override of the same kind already proven working for rust_sysroot_absolute.

BLFS general/rust.html. Foundational piece for real Firefox (user's explicit 'reopen the Rust question' direction). Downloads a prebuilt stage0 bootstrap binary at build time (standard rustc bootstrap, requires the chroot to reach the internet -- confirmed working since the DHCP/networking fix). Installs to /opt/rustc-1.97.1 with a /opt/rustc symlink, NOT /usr -- this is the book's own convention (rustc ships its own toolchain layout), so downstream packages (Firefox) need /opt/rustc/bin on PATH. Uses DESTDIR="$PKG_DESTDIR" ./x.py install like every other destdir-capture package in this project; if x.py's installer doesn't honor DESTDIR the way autotools/cmake do, this needs revisiting after a real build attempt (see CLAUDE.md's verify-against-real-build discipline).

The real, from-source Chromium-pinned Rust toolchain -- explicit user choice ('build a matching Chromium-pinned Rust toolchain') after discovering Chromium 151's own //base has MANDATORY (not optional) Rust code (JSON parsing via serde_json_lenient, logging via rust_logger) that a plain enable_rust=false can't route around. The exact commit is confirmed directly from packages/ungoogled-chromium's own real Chromium source tree (DEPS file, 'src/third_party/rust-toolchain' gcs entry): rustc commit b998449636a48e2c4a362809085b600a0174e1f2, built against the exact same LLVM commit as packages/clang-chromium (llvmorg-23-init-19482-g53d18800) -- confirmed via WebFetch against chromium.googlesource.com's own mirror that this is a real, plain, UNMODIFIED upstream rust-lang/rust commit (a real bors auto-merge, not a Google/Chromium fork), so building it from the real upstream repo is equivalent to what Chromium's own prebuilt package contains. The 'source' entry here is a placeholder -- this can't be a plain tarball download (GitHub's archive endpoint doesn't include git submodules, and this rust-lang/rust checkout needs several: library/backtrace, src/tools/cargo, src/doc/*, src/gcc, src/llvm-project, src/tools/enzyme, src/tools/rustc-perf), so the real source was produced via `git clone` + `git checkout <commit>` + `git submodule update --init --recursive --depth 1` on the dev VM's own outer Debian root (git installed there via apt specifically for this, matching this project's existing precedent for host build tools), then tarred (excluding .git dirs, which aren't needed for the actual build) and fed in as this package's pinned source, real sha256 computed from that real tarball. Bootstraps using this project's OWN already-built rustc (packages/rustc, 1.97.1) as the stage0 compiler -- confirmed viable directly from the real source tree's own src/version file (1.98.0) and Rust's own well-documented N-1-bootstraps-N policy, avoiding any external stage0 download (neither Google's nor even rust-lang.org's official one) for a fully self-hosted build. Points bootstrap.toml's llvm-config at /opt/clang-chromium/bin/llvm-config (our own already-built matching-commit LLVM) instead of letting rustc build or download its own vendored LLVM copy -- avoids a THIRD from-scratch LLVM build (already built once for clang-chromium, no reason to build it again here). Installs to /opt/rustc-chromium, separate from both the system's real /opt/rustc-1.97.1 and /opt/clang-chromium -- packages/ungoogled-chromium's build.sh installs this into its own source tree's third_party/rust-toolchain/ (the fixed relative path Chromium's own build expects, confirmed via build/config/rust.gni), not by adding it to any system PATH.

sassc -- CLI Sass compiler (uses libsass). libadwaita compiles its GTK stylesheet with it at build time. ship_in_iso=false, built on .101.

Not a BLFS book package -- verified against the real sched-ext/scx GitHub repo (README, Cargo.toml files) before writing this, including confirming the real current release tag (v1.1.2, originally) after an initial fetch looked stale. Builds only scx_bpfland and scx_lavd (via `cargo build --release -p scx_bpfland -p scx_lavd`), not the full workspace -- confirmed neither needs protobuf-compiler/libseccomp-dev (those are only pulled in by unrelated workspace tools like scxtop). The BPF side compiles automatically as part of the normal cargo build (scx_utils vendors a portable vmlinux.h, and each scheduler's build.rs drives clang-with-BPF-target via the scx_cargo crate) -- no manual vmlinux.h/bpftool step needed, so bpftool was never built as a separate package. libbpf-rs (a crates.io Rust binding, pinned by scx's own Cargo.toml, not vendored) needs real network access during `cargo build` -- works since the chroot's DHCP fix. Part of the sched_ext (BPF-pluggable CPU scheduler) chain, per explicit user request following the squashfs zstd kernel optimization work -- kernel rebuilt separately (see packages/linux) with CONFIG_SCHED_CLASS_EXT + the BPF_SYSCALL/BPF_JIT/DEBUG_INFO_BTF it depends on, using the new `dwarves`/`pahole` package for BTF generation. Bumped 1.1.2 -> 1.1.3 (real upstream release, verified via the GitHub releases API, sha256 computed directly from the downloaded tarball) after the linux kernel 7.1.7 -> 7.2 bump broke sched_ext: `scx_bpfland`/`scx_lavd` both failed with `Error: Failed to load BPF program / Invalid argument (os error 22)` at the top-level `bpf_object__load()` step, with no per-program verifier message anywhere in a full `RUST_LOG=debug` capture -- the signature of a struct_ops layout mismatch (the kernel's own `struct sched_ext_ops` shape, matched via BTF at load time, not a plain CO-RE field-offset issue that would otherwise self-heal across kernel versions) rather than a Kconfig fix. v1.1.3's own real changelog (PR #3743, `htejun`, the scx maintainer) is titled exactly "Update vmlinux.h and sync include files with kernel sched_ext/for-7.3" -- a direct re-sync of scx_utils' vendored vmlinux.h/struct_ops layout against the current kernel sched_ext branch, which is exactly the fix this failure needed.

BLFS general/sdl2.html -- SDL 2. Runtime-required by Shotcut (audio preview) and used by MLT's sdl2/sdl2_audio consumers for A/V preview in Shotcut and Kdenlive. ship_in_iso=false (video-editing feature = packages only). CMake build, --libdir=lib; PulseAudio/wayland/pipewire deliberately off (ALSA + X11 only, matching this project's audio stack). No Vulkan (Qt6 here has no vulkan either).

LFS ch8, final native build. Skips make html (docs) and the optional test suite.