## TOC * Preamble * Poudriere installation * Removing unwanted dependencies * More complex examples of deWaylandization * Ports flavors * Patching Makefile * Results and thoughts * Notes ## Preamble My everyday FreeBSD system has two good old components for graphics and sound — the X Server and the OSS. There are simple reasons to use these components — they are mature, they have tons of user documentation, use case examples, etc. I also like the way these things have been used in the FreeBSD world. Let me quote vermaden, who wrote well (about the OSS) in the Quare FreeBSD? blogpost: > Not many people expect from FreeBSD to shine in that department but it shines a lot here and not from yesterday but from decades. Remember when Linux got rid of the old OSS subsystem with one channel and came up with ‘great’ idea to write ALSA? I remember because I used Linux back then. Disaster is very polite word to describe Linux audio stack back then … and then PulseAudio came and whole Linux audio system got much worse. > > … > > Lets get back to FreeBSD audio then. What FreeBSD offered? A whooping 256 OSS channels mixed live in kernel for low latency. Everything audio related just worked out of the box – and still works today. This is where I see the pattern. If in the Linux world there are many examples of throwing away software that has served people for years or decades and can (and should, I think) be updated to adapt to the changed reality (e.g. `ifconfig`). Then in the FreeBSD world such software just … gets the necessary updates and continues to be used. In my journey to install and use the simple system with the good old software I encountered some problems. Sometimes, when I install a simple program, like conky or dunst — the pkg tries to install Wayland as a dependency! Or PulseAudio (thankfully, there is no SystemD in the FreeBSD world). Of course, I **do not want** these things in my simple system based on the X server, OSS and good old initialization scripts. As stated @[email protected] — some binary packages for FreeBSD have been built with the same dependencies that came from upstream — to minimize maintainer's work, which is obviously hard1. As a result, some packages came to my machine with unwanted dependencies or compile-time options that were not ideal for me. For example, the native for BSD `sndio` sound server is disabled by default in the `mutlimedia/audacious-plugins` port. But those "linuxisms" — like PulseAudio and PipeWire — are enabled🤷‍♂️. I was very surprised to see the `pulseaudio` process in the top 5 CPU consuming processes while listening to my music. My sound system using OSS and sndio, why is PulseAudio here?!🤔 After that I started to think about removing unwanted dependencies from my packages completely… Or another example — when I install some graphical application based on the QT6 or GTK3/GTK4 — not only the necessary graphical libraries are installed as dependencies but also a lot of Wayland stuff. Even if my system doesn't use Wayland, I have packages of _these things_ installed: % pkg info -a | /usr/bin/grep wayland qt6-wayland-6.8.2 Qt6 wrapper for Wayland wayland-1.23.1 Core Wayland window system code and protocol wayland-protocols-1.39 Wayland protocols At some point, I decided to override this and get my versions of packages without unwanted dependencies. A naive approach — just build some packages without unwanted compile-time options via the Ports infrastructure — almost works for me. Almost. When the corresponding package from the FreeBSD repository was updated — it overwrites my custom package, built with ports. A solution I found — were far from ideal solution. I can lock my package so that it will not be updated with the same binary package from the repository. And temporarily unlock it when I want to update the _my_ package via the ports infrastructure. In the FreeBSD Handbook, section 4.6 "Building Packages with poudriere", there was another way to accomplish my task without such update problems. I can build my own local repository with some packages that have PulseAudio/Wayland dependencies removed. And this is not a some hacky thing — as far as I can see, the poudriere used by the FreeBSD maintainers to build the binary packages: % pkg info emacs ... Annotations : FreeBSD_version: 1401000 build_timestamp: 2025-02-27T01:04:32+0000 built_by : poudriere-git-3.4.2 And it works pretty simple — poudriere just reuses existing FreeBSD infrastructure to build packages. Package sources taken from ports (via git/https), binary packages downloaded from existing FreeBSD repositories via the pkg, build process itself runs inside the jail and all corresponding files can be stored in the separate ZFS dataset — so the dataset with the root filesystem will not be polluted by the build-time dependencies or building artifacts, like object files or logs. At the end, poudriere will create the local repository with packages. The same repository as the main FreeBSD repository, but _local_ and with only necesary packages. Poudriere doesn't force me to build the whole system on my machine. The main selling point is that all packages installed from this repository will be updated through **this** repository. They will not be overwritten by updates from the main FreeBSD repository. This is because the `pkg` adds the annotation with repository name to the installed package and uses it when updating: % pkg info -A conky conky-1.22.1: FreeBSD_version: 1402000 build_timestamp: 2025-03-23T14:58:18+0000 built_by : poudriere-git-3.4.2 cpe : cpe:2.3conky:conky:1.22.1:::::freebsd14:x64 port_checkout_unclean: no port_git_hash : 6bcf1e971 ports_top_checkout_unclean: no ports_top_git_hash: 3fe34c578 repo_type : binary repository : LocalRepo The second selling point: I can setup all these machinery on a separate disk, which I mainly use for QEMU/bhyve VMs and other _big things_. This way, my build infrastructure doesn't take up space on the root filesystem. ## Poudriere installation Before I welcomed poudriere to my laptop, I created a separate dataset for poudriere-related files: # zfs create hdd/poudriere # zfs set compression=gzip hdd/poudriere The only files, which are stored in the root filesystem are configuration files: * Build options for the ports — stored in the `/usr/local/etc/poudriere.d/jail-port-set-options/`. * Blacklist for unwanted ports: `/usr/local/etc/poudriere.d/blacklist`. * `make.conf` for poudriere jails: `/usr/local/etc/poudriere.d/make.conf`. * And the poudriere configuration itself, of course. Then, after installing the poudriere package, I slightly changed the default configuration file and added the following options to use `/hdd/poudriere/` dataset as the main path for both the jail and the local repository, not my main dataset with the root filesystem: ZPOOL=hdd #NO_ZFS=yes ZROOTFS=/poudriere # The directory where poudriere will store jails and ports BASEFS=/hdd/poudriere TIMESTAMP_LOGS=yes MAX_EXECUTION_TIME=259200 Also, I increased max time of build process to 3 days — because 1 day may not be enough to build _big things_. And because it is very sad to spend 24 hours for building and receive nothing as a result😟. By the way, I don't want to build LLVM, or Rust, or other build-time dependencies from sources — I'm fine with the packaged versions. So to don't spend a time for it, I instruct poudriere to download and use binary packages for these dependencies: PACKAGE_FETCH_BRANCH=quarterly PACKAGE_FETCH_BLACKLIST="pipewire* pulseaudio* wayland*" PACKAGE_FETCH_WHITELIST="gcc* binutils coreutils mpfr nasm mpdecimal bison llvm* libclc-llvm* spirv-llvm-translator-llvm* rust node* lua* perl* python* ruby* ghc* tcl86 bison gmake gsed gawk pcre2 pkgconf autoconf* automake* m4 flex mercurial subversion git cppunit readline bash* curl readline gmp gettext* indexinfo boost* hs-* cmake* help2man html2text pkgconf jsoncpp asciidoc rhash zstd itstool brotli meson tex* doxygen sdocbook-xml docbook* texi2html gnupg gnutls sqlite3 suiteparse* fribidi gdbm utf8cpp xmlstarlet c-ares minizip gtk-doc iso8879 gperf highway p11-kit gcab nettle py3* p5* ninja pygobject* double-conversion dbus dbus-glib evdev-proto gnome-common icu orc ca_root_nss expat xmlcatmgr xmlcharent yelp* json-glib dav1d lame polkit intltool minixmlto sassc redis aom svt-av1 x265 flac neon opusfile wavpack vmaf shaderc opus sndio libbinio xxhash frei0r taglib upnp ffnvcodec-headers v4l_compat yasm speex speexdsp twolame bdftopcf dejavu encodings font-bh-ttf font-misc-ethiopic font-misc-meltho font-util mkfontscale xorg-fonts-truetype xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm spirv-tools glslang alsa-lib gsettings-desktop-schemas woff2 openjpeg geoclue glib-networking harfbuzz-icu enchant2 hunspell hyphen openal-soft rnnoise webrtc-audio-processing abseil crc32c glibmm2* kf6* microsoft-gsl protobuf range-v3 tl-expected libiconv libffi libtextstyle libxml2 libyaml liblz4 libidn2 libxslt libgcrypt libunistring libuv libgpg-error libtool libdeflate libinotify libnghttp2 libtasn* libpsl libssh* libarchive libdaemon libdatrie libevent libgudev libgusb libthai libudev-devd libunwind duktape-lib libsecret libsass libass libedit libvorbis libogg libx264 libsidplayfp libunibreak libv4l libvdpau libvpx libcdio libcdio-paranoia libcue libdvbpsi libepoll-shim libsamplerate libinput libevdev libmtdev libidn libmatroska libtheora libebml libfontenc libXpm libwacom libXv libxshmfence libmysofa libada libb2 libdispatch libfmt libsigc++* libsoup* libproxy" Also, I put the next lines to the `/usr/local/etc/poudriere.d/make.conf`, to prevent enabling the unwanted options when configuring the port(s): DISABLE_LICENSES=yes OPTIONS_UNSET+=JACK PIPEWIRE PULSEAUDIO WAYLAND OPTIONS_SET+=OSS SNDIO X11 To the `/usr/local/etc/poudriere.d/blacklist` I've added the next lines: audio/pulseaudio graphics/wayland multimedia/pipewire With this configuration poudriere will neither install unwanted packages from repository, nor build it from ports. The next steps, including initializing the jail and ports, are well described in the corresponding chapter of the FreeBSD Handbook. With one **valuable** exception! When I create the poudriere ports, the proper quarterly branch should be specified! Like this: # poudriere ports -c -p local -m git+https -B 2025Q1 Without the proper branch I'll faced the obscure dependency problems when downloading the build-time depenedencies as packages: [00:00:48] [Dry Run] Package fetch: Skipping cmake-core-3.31.6: remote version mismatch: cmake-core-3.31.3 [00:00:48] [Dry Run] Package fetch: Skipping gettext-runtime-0.23.1: remote version mismatch: gettext-runtime-0.23 [00:00:48] [Dry Run] Package fetch: Skipping hs-pandoc-3.6.4: remote version mismatch: hs-pandoc-3.6.1 [00:00:48] [Dry Run] Package fetch: Skipping gettext-tools-0.23.1: remote version mismatch: gettext-tools-0.23 [00:00:48] [Dry Run] Package fetch: Skipping libedit-3.1.20250104,1: remote version mismatch: libedit-3.1.20240808,1 [00:00:48] [Dry Run] Package fetch: Skipping lua53-5.3.6_1: deps wanted: libedit-3.1.20250104,1 [00:00:48] [Dry Run] Package fetch: Skipping lua53-5.3.6_1: deps remote: libedit-3.1.20240808,1 [00:00:48] [Dry Run] Package fetch: Will fetch hs-cabal-install-3.12.1.0_1 At the end I have an initialized2 and working jail with ports and the necessary build environment inside. Now it's time to remove unwanted dependencies from the system! ## Removing unwanted dependencies For example, let's work with Wayland. First, I got a list of `wayland`-dependent packages via `pkg required-depends`: % pkg required-depends wayland mesa-dri-24.1.7_1 gtk4-4.16.12 conky-1.22.0 sdl2-2.30.10_1 mesa-libs-24.1.7_1 gstreamer1-plugins-gl-1.24.10 vulkan-loader-1.4.304 dunst-1.10.0 libva-2.22.0 gtk3-3.24.43 libxkbcommon-1.7.0_1 redshift-1.12_2 webkit2-gtk3-2.34.6_10 Let's take `conky` and rebuild it without Wayland dependencies! First, I need an _origin_ of this package (it's name in the ports) to build it with poudriere. The `pkg` gave me the answer and I wrote it to the text file — the list of packages to rebuild: % pkg info -o conky conky-1.22.0 sysutils/conky # echo 'sysutils/conky' >> /hdd/poudriere/14amd64-local-workstation-pkglist Then I configured all the necessary ports with help of the next zsh function: SHELL="/usr/bin/env zsh" xterm -fa Hack-14 -e \ "sudo poudriere options -j 14amd64 -p local -z workstation -c $1" This function takes string with origin as a single argument. It may look a bit tricky — but I'm using it because ncurses interface to configure build options is not displaying correctly inside my EAT. So I start a separate shell in XTerm and configure conky and all it's dependencies inside this shell: After that I start the necessary machinery with the next zsh function: DUNST_OPTS=(-I ~/.config/dunst/icons/update.svg) PKGLIST="/hdd/poudriere/14amd64-local-workstation-pkglist" POUDRIERE_OPTS=(-j 14amd64 -p local -z workstation -f $PKGLIST) sudo poudriere jail -u -j 14amd64 dunstify "Poudriere" "Jail 14amd64 updated" $DUNST_OPTS sudo poudriere ports -p local -u dunstify "Poudriere" "Ports updated" $DUNST_OPTS while true; do dunstify "Poudriere" \ "Dry run start.\nCheck that all will build correctly before the real😎 build" \ $DUNST_OPTS sudo poudriere bulk $POUDRIERE_OPTS -b quarterly -vn read ANSWER?"Is all correct? [y/n/q] " if [ "$ANSWER" = "y" ]; then break elif [ "$ANSWER" = "q" ]; then return fi; done dunstify "Poudriere" "Ports build start..." $DUNST_OPTS sudo poudriere bulk $POUDRIERE_OPTS -b quarterly dunstify "Poudriere" "Ports build end" $DUNST_OPTS There are the next things happen: 1. `local` poudriere ports update and FreeBSD system inside the jail `14amd64` update. If there are already built ports and they got updates — the necessary ports and its' dependencies will be rebuilt during the next stages. 2. Dry-run the build process (`-n`) with the verbose output (`-v`). This is necessary to check that all build-time dependencies, specified in the `PACKAGE_FETCH_WHITELIST` configuration option, will not be built from sources and so on. 3. Ask user about correctness of logs in the console. If not — return to the previous stage. Assuming that user will fix something in the `/usr/local/etc/poudriere.conf` before answering `n` to recheck logs of dry run stage. 4. Start build packages in multiple processes, each on it's own CPU core: The "dry-run" stage is necessary to avoid special sort of problems — when the build-time dependency will not be installed with `pkg` because it depends from another build-time dependency, not listed in `PACKAGE_FETCH_WHITELIST`. [00:01:23] [Dry Run] Checking packages for missing dependencies [00:01:23] [Dry Run] Deleting cmake-core-3.31.3.pkg: missing dependency: expat-2.6.4 [00:01:23] [Dry Run] Deleting gettext-tools-0.23.pkg: missing dependency: libtextstyle-0.23 [00:01:23] [Dry Run] Deleting py311-libxml2-2.11.9_1.pkg: missing dependency: libxml2-2.11.9 The solution is simple — just add necessary package(s) to the `PACKAGE_FETCH_WHITELIST` or decide to build it from ports. Ideally, here should be an option to stop the build process if packages listed in the `PACKAGE_FETCH_WHITELIST` will not be fetched. But it is not added yet to the recent version of poudriere, so I'm using an infinite cycle as a workaround. The build process is fast enough, even on my Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz. Obviously, the big software, like Qt or GTK, will build for hours. Fortunately, the packages that depend on it were waiting while they were building, so other CPU cores were free3 and I could use my system as usual, without any drawbacks😎. After successfull completion, poudriere will create a local FreeBSD repository that I can use to install **my** versions of packages without unwanted dependencies. To use this repo, I simply created the `/usr/local/etc/pkg/repos/LocalRepo.conf` file with the next contents: LocalRepo: { url: "//hdd/poudriere/data/packages/14amd64-local-workstation" } Then I launched `pkg update` as usual: # pkg update Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating FreeBSD-kmods repository catalogue... Fetching data.pkg: 100% 14 KiB 14.6kB/s 00:01 Processing entries: 100% FreeBSD-kmods repository update completed. 44 packages processed. Updating LocalRepo repository catalogue... LocalRepo repository is up to date. All repositories are up to date. And now I'm able to reinstall the conky and get rid of a wayland dependency. To simplify things, I've just added the next alias to `/etc/pkg.conf`: ALIAS { ... poudriere-install = "install -r LocalRepo -f" } And called the next command: # pkg poudriere-install conky Updating LocalRepo repository catalogue... Fetching meta.conf: 100% 179 B 0.2kB/s 00:01 Fetching data.pkg: 100% 132 KiB 135.4kB/s 00:01 Processing entries: 100% LocalRepo repository update completed. 383 packages processed. LocalRepo is up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: conky: 1.22.0 -> 1.22.1 [LocalRepo] Number of packages to be upgraded: 1 Proceed with this action? [y/N]: y [1/1] Upgrading conky from 1.22.0 to 1.22.1... [1/1] Extracting conky-1.22.1: 100% Note, that only the necessary package(s) have been reinstalled. The pkg will not install all the packages from the `LocalRepo`, only the bare minimum to provide the working program in the existing system. As a result, conky has disappeared from the list of wayland-dependent packages and receive the proper `repository` annotation: % pkg required-depends wayland mesa-dri-24.1.7_1 gtk4-4.16.12 sdl2-2.30.10_1 mesa-libs-24.1.7_1 gstreamer1-plugins-gl-1.24.10 vulkan-loader-1.4.304 dunst-1.10.0 libva-2.22.0 gtk3-3.24.43 libxkbcommon-1.7.0_1 redshift-1.12_2 webkit2-gtk3-2.34.6_10 % pkg query "%n: %R" conky conky: LocalRepo ## More complex examples of deWaylandization Sometimes it may be necessary to revisit build options and/or reconfigure the already built package. In my case there was a `libva`. I already built it as a dependency when rebuilding VLC, but I want to recheck the selected options before reinstalling the package. This is where the `poudriere options` comes to the rescue. I can use the `-s` option to view the package options and the `-c` option to reconfigure them. Instead of specifying the list of origins to build with the `-f` option, I just specify the one necessary origin. Note the `-n` option — without it the poudriere will print configuration for the all packages required by the specified origin. # poudriere options -j 14amd64 -p local -z workstation -ns multimedia/libva [00:00:01] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:01] Working on options directory: /usr/local/etc/poudriere.d/14amd64-local-workstation-options [00:00:01] Using ports from: /hdd/poudriere/jails-ports/ports/local ===> The following configuration options are available for libva-2.22.0: WAYLAND=off: Wayland (graphics) support X11=on: X11 (graphics) support ===> Use 'make config' to modify these settings [00:00:01] Re-run 'poudriere options' with the -c flag to modify the options. Looks like the `libva` was configured correctly and I can just install it from my local repo without any problems. Much more complex example comes with a `graphics/mesa-dri`. Unfortunately, I built it with Wayland support, so I will have to reconfigure and rebuild it. This is where the custom zsh function `bsd-poudriere-reconfigure` comes in to save me a tons of typing: Finally, to rebuild the `mesa-dri` and it's dependencies I used the next command: # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -C graphics/mesa-dri And install it from `LocalRepo` the same way as I used for `conky` package. ### Ports flavors There are some packages exists, without the corresponding ports. For example, the package `audacious-gtk3` can be installed, but there is only `multimedia/audactious` port and there are no "Qt/GTK/whatever" options to configure: /usr/ports % pkg info -o audacious-gtk3 audacious-gtk3-4.4.2_1 multimedia/audacious /usr/ports % ls -d multimedia/audacious* multimedia/audacious/ multimedia/audacious-plugins/ /usr/ports % pkg query '%n: %Ok' audacious-gtk3 audacious-gtk3: EXECINFO audacious-gtk3: LIBARCHIVE audacious-gtk3: NLS When I built this port as usual, I got the Qt-based package. But I want a GTK based package because it can display my favourite skin as I want to: It's time to meet the flavors! Some ports can be built in multiple variants. And the variants itself can be observed with the simple `fgrep`: /usr/ports % fgrep 'FLAVORS=' multimedia/audacious/Makefile FLAVORS= qt6 qt5 gtk3 gtk2 So, according to the link above, I can build my `audacious-gtk3` package just by adding line `multimedia/audacious@gtk3` instead of simple `multimedia/audacious` to the my `/hdd/poudriere/14amd64-local-workstation-pkglist`. **Note:** the flavor is specified after the _[at]_ symbol. ### Patching Makefile One of the biggest problems I met, during the recompiling some packages — is the Qt 6 dependent packages. There were two of them: Telegram Desktop and the Qmapshack. Telegram Desktop is directly depends from Qt 6 and the Qmapshack depends on the `bsdisks` package, which depends from the Qt 6 itself (despite the Qmapshack depends on the Qt 5): ~ % pkg rquery '%n: %dn %dv : %do' telegram-desktop | /usr/bin/grep qt telegram-desktop: qt6-shadertools 6.8.2 : x11-toolkits/qt6-shadertools telegram-desktop: qt6-declarative 6.8.2 : x11-toolkits/qt6-declarative telegram-desktop: qt6-wayland 6.8.2 : graphics/qt6-wayland telegram-desktop: qt6-svg 6.8.2 : graphics/qt6-svg telegram-desktop: qt6-lottie 6.8.2 : graphics/qt6-lottie telegram-desktop: qt6-imageformats 6.8.2 : graphics/qt6-imageformats telegram-desktop: qt6-base 6.8.2_1 : devel/qt6-base telegram-desktop: qt6-5compat 6.8.2 : devel/qt6-5compat ~ % pkg rquery '%n: %dn %dv : %do' qmapshack | /usr/bin/grep bsdisks qmapshack: bsdisks 0.36 : sysutils/bsdisks ~ % pkg rquery '%n: %dn %dv : %do' bsdisks | /usr/bin/grep qt bsdisks: polkit-qt-1-qt6 0.200.0 : sysutils/polkit-qt-1 bsdisks: qt6-base 6.8.2_1 : devel/qt6-base And the problem is in `devel/qt6-base` — it depends from the Wayland directly and there is no knob to build it without Wayland support: LIB_DEPENDS= libatk-1.0.so:accessibility/at-spi2-core \ libatk-bridge-2.0.so:accessibility/at-spi2-core \ ... libvulkan.so:graphics/vulkan-loader \ libwayland-client.so:graphics/wayland \ libxkbcommon.so:x11/libxkbcommon \ ... OPTIONS_DEFINE= CUPS X11 OPTIONS_DEFAULT= CUPS X11 OPTIONS_SUB= yes I tried to remove this line with `graphics/wayland` dependency from the Makefile but `qt6-base` failed to compile in this case. I hope the option to compile `devel/qt6-base` without Wayland dependency will be added in the future. But for now I can just stick with Qt 5. First package, dependent from Qt 6 — the Telegram Desktop — was simply removed from my machine. I always encountered problems with this app — it likes to overload my CPU in random times. So I switched to web version and have no problems since. Second package — Qmapshack, dependent from `sysutils/bsdisks`, require more work on it. Bsdisks itself was pulled to my system directly by Qmapshack and wasn't necessary for other programs. So, the necessity of bsdisks was questionable — why is it needed for the mapping program, when I don't use Garmin or other GPS devices for mapping? % pkg rquery '%e' bsdisks UDisks2 service provides interfaces to enumerate and perform operations on disks and storage devices via D-Bus API. Bsdisks is an implementation of UDisks2 service for FreeBSD. Of course, there is no configuration option to build the `astro/qmapshack` without `sysutils/bsdisks`. But … it was marked as a runtime dependency in the Makefile, not a compile time dependency: RUN_DEPENDS= ${LOCALBASE}/bin/bsdisks:sysutils/bsdisks So, it's time to slightly patch the necessary port and try to build Qmapshack without bsdisks. First, I opened the `/hdd/poudriere/ports/local/astro/qmapshack/Makefile` and commented this line. Then, I add `astro/qmapshack` to the `/hdd/poudriere/14amd64-local-workstation-pkglist` and initiated the build without updating the ports, so my change will not clash with the updates from the main repository (if any): # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -nv -C astro/qmapshack ... [00:00:42] [Dry Run] Dry run mode, cleaning up and exiting [00:00:42] [Dry Run] Would build 3 packages using 3 builders [00:00:42] [Dry Run] Ports to build: astro/qmapshack graphics/gdal www/qt5-webengine ... # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -C astro/qmapshack And it successfully builds and running correctly without `bsdisks`! [14:00:58] [01] [14:00:02] Finished www/qt5-webengine | qt5-webengine-5.15.18p5_1: Success [14:01:01] [01] [00:00:00] Building astro/qmapshack | qmapshack-1.17.1_5 [15:08:33] [01] [01:07:32] Finished astro/qmapshack | qmapshack-1.17.1_5: Success [15:08:33] Stopping 3 builders [15:08:37] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [15:09:05] Committing packages to repository: /hdd/poudriere/data/packages/14amd64-local-workstation/.real_1743306462 via .latest symlink [15:09:05] Removing old packages [15:09:05] Built ports: graphics/gdal www/qt5-webengine astro/qmapshack _Main window of Qmapshack GIS software_ Last step: after successfull compilation I reverted my changes in `astro/qmapshack/Makefile` to avoid unnecessary problems with ports updates. ## Results and thoughts Before, I was using a Gentoo (and compiling the whole system, of course) which `emerge` system was inspired by FreeBSD ports. Comparing these two system, I can say that ports infrastructure looks like simplier for me. When I recompiled the program in the Gentoo with the new options I usually did the next: 1. Run `emerge --ask program-name` to see the USE flags of program **and** it's dependencies. 2. If I want to change something and need to see the exact meaning of some USE flag, I call `equery uses program-name`. Then I open a text file somewhere in `/etc/portage/package.use/` and add package atom and the necessary USE flags' settings. 3. After that I could start compilation with necessary options. Looks like for me, the same process in the FreeBSD is simpler. I can configure build-time options for program and it's dependencies with a single call of `poudriere options ...` which provides me a useful TUI menu with descriptions of all of the options. And I don't need to copy it to the some configuration file — all of them will be inserted in the right place themselves. Also, all ports infrastructure looks like simplier — it is just a Makefile and a bunch of human-readable text files with package descriptions and so on! Of course there are drawbacks: * Some packages I think (like Qt 6) lack the configuration options. * If I want to update packages, it is better to update my local repository first. Instead, some of the packages will be dependent from the old libraries which are already updated in the `FreeBSD` repository. Sometimes it will work as usual without any problems, but sometimes, I think, it will be break due to API changes. * If I will update my OS to something like FreeBSD 14.3 — then I should to checkout corresponding branch for local ports and update my 14amd64 jail to the right version of OS. * The same is true for major updates. * And every quarter I should checkout the right branch for the ports, to have a synchronization between the binary packages from the FreeBSD repository and the ports. BTW, I got one sudden and major result of un-waylanding of my system. Before, I was constantly struggling from strange glitches on my display, that looks like this: I thought what this is because: 1. I used the outdated method of acceleration for X server `intel` driver. So, I switched from UXA to Glamor. And this is not helped to me. 2. I used the wrong options for video card powersaving. Revised it and … nothing changed. 3. My soldering of AGAN X230 expansion card were bad. So, I recheck it and found nothing suspicios. 4. I compiled coreboot not the right way because I specified the wrong initial framebuffer resolution when the machine is booting. I switched to precompiled libreboot and properly configure it. Aaand … nothing changed. 5. I started to suspect my video card. Maybe my hardware is dying?…🤔 But after I removed Qt6 and Wayland related stuff from my machine, I'm not seeing these glitches anymore. Before, I was seeing it almost every day. But for now, two days already passed and all is OK. * * * ## Notes 1 https://mastodon.bsd.cafe/@TomAoki/114209804382234562 2 It may be necessary to build a `ports-mgmt/pkg` before building anything in the jail. In my case poudriere won't install `cmake-core` because it has unsatisfied dependency — the `pkg`. Despite the `pkg` of necessary version was previously bootstrapped to install binary packages in the jail. 3 Except the Qt building process. There is a line in `/usr/local/etc/poudriere.conf`, which instructs to build some packages on the all accessible CPU cores: # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* vlc qt*" I added the Qt to it, because it builds so slooow on the one CPU core…

## TOC * Preamble * Poudriere installation * Removing unwanted dependencies * More complex examples of deWaylandization * Ports flavors * Patching Makefile * Results and thoughts * Notes ## Preamble My everyday FreeBSD system has two good old components for graphics and sound — the X Server and the OSS. There are simple reasons to use these components — they are mature, they have tons of user documentation, use case examples, etc. I also like the way these things have been used in the FreeBSD world. Let me quote vermaden, who wrote well (about the OSS) in the Quare FreeBSD? blogpost: > Not many people expect from FreeBSD to shine in that department but it shines a lot here and not from yesterday but from decades. Remember when Linux got rid of the old OSS subsystem with one channel and came up with ‘great’ idea to write ALSA? I remember because I used Linux back then. Disaster is very polite word to describe Linux audio stack back then … and then PulseAudio came and whole Linux audio system got much worse. > > … > > Lets get back to FreeBSD audio then. What FreeBSD offered? A whooping 256 OSS channels mixed live in kernel for low latency. Everything audio related just worked out of the box – and still works today. This is where I see the pattern. If in the Linux world there are many examples of throwing away software that has served people for years or decades and can (and should, I think) be updated to adapt to the changed reality (e.g. `ifconfig`). Then in the FreeBSD world such software just … gets the necessary updates and continues to be used. In my journey to install and use the simple system with the good old software I encountered some problems. Sometimes, when I install a simple program, like conky or dunst — the pkg tries to install Wayland as a dependency! Or PulseAudio (thankfully, there is no SystemD in the FreeBSD world). Of course, I **do not want** these things in my simple system based on the X server, OSS and good old initialization scripts. As stated @[email protected] — some binary packages for FreeBSD have been built with the same dependencies that came from upstream — to minimize maintainer's work, which is obviously hard1. As a result, some packages came to my machine with unwanted dependencies or compile-time options that were not ideal for me. For example, the native for BSD `sndio` sound server is disabled by default in the `mutlimedia/audacious-plugins` port. But those "linuxisms" — like PulseAudio and PipeWire — are enabled🤷‍♂️. I was very surprised to see the `pulseaudio` process in the top 5 CPU consuming processes while listening to my music. My sound system using OSS and sndio, why is PulseAudio here?!🤔 After that I started to think about removing unwanted dependencies from my packages completely… Or another example — when I install some graphical application based on the QT6 or GTK3/GTK4 — not only the necessary graphical libraries are installed as dependencies but also a lot of Wayland stuff. Even if my system doesn't use Wayland, I have packages of _these things_ installed: % pkg info -a | /usr/bin/grep wayland qt6-wayland-6.8.2 Qt6 wrapper for Wayland wayland-1.23.1 Core Wayland window system code and protocol wayland-protocols-1.39 Wayland protocols At some point, I decided to override this and get my versions of packages without unwanted dependencies. A naive approach — just build some packages without unwanted compile-time options via the Ports infrastructure — almost works for me. Almost. When the corresponding package from the FreeBSD repository was updated — it overwrites my custom package, built with ports. A solution I found — were far from ideal solution. I can lock my package so that it will not be updated with the same binary package from the repository. And temporarily unlock it when I want to update the _my_ package via the ports infrastructure. In the FreeBSD Handbook, section 4.6 "Building Packages with poudriere", there was another way to accomplish my task without such update problems. I can build my own local repository with some packages that have PulseAudio/Wayland dependencies removed. And this is not a some hacky thing — as far as I can see, the poudriere used by the FreeBSD maintainers to build the binary packages: % pkg info emacs ... Annotations : FreeBSD_version: 1401000 build_timestamp: 2025-02-27T01:04:32+0000 built_by : poudriere-git-3.4.2 And it works pretty simple — poudriere just reuses existing FreeBSD infrastructure to build packages. Package sources taken from ports (via git/https), binary packages downloaded from existing FreeBSD repositories via the pkg, build process itself runs inside the jail and all corresponding files can be stored in the separate ZFS dataset — so the dataset with the root filesystem will not be polluted by the build-time dependencies or building artifacts, like object files or logs. At the end, poudriere will create the local repository with packages. The same repository as the main FreeBSD repository, but _local_ and with only necesary packages. Poudriere doesn't force me to build the whole system on my machine. The main selling point is that all packages installed from this repository will be updated through **this** repository. They will not be overwritten by updates from the main FreeBSD repository. This is because the `pkg` adds the annotation with repository name to the installed package and uses it when updating: % pkg info -A conky conky-1.22.1: FreeBSD_version: 1402000 build_timestamp: 2025-03-23T14:58:18+0000 built_by : poudriere-git-3.4.2 cpe : cpe:2.3conky:conky:1.22.1:::::freebsd14:x64 port_checkout_unclean: no port_git_hash : 6bcf1e971 ports_top_checkout_unclean: no ports_top_git_hash: 3fe34c578 repo_type : binary repository : LocalRepo The second selling point: I can setup all these machinery on a separate disk, which I mainly use for QEMU/bhyve VMs and other _big things_. This way, my build infrastructure doesn't take up space on the root filesystem. ## Poudriere installation Before I welcomed poudriere to my laptop, I created a separate dataset for poudriere-related files: # zfs create hdd/poudriere # zfs set compression=gzip hdd/poudriere The only files, which are stored in the root filesystem are configuration files: * Build options for the ports — stored in the `/usr/local/etc/poudriere.d/jail-port-set-options/`. * Blacklist for unwanted ports: `/usr/local/etc/poudriere.d/blacklist`. * `make.conf` for poudriere jails: `/usr/local/etc/poudriere.d/make.conf`. * And the poudriere configuration itself, of course. Then, after installing the poudriere package, I slightly changed the default configuration file and added the following options to use `/hdd/poudriere/` dataset as the main path for both the jail and the local repository, not my main dataset with the root filesystem: ZPOOL=hdd #NO_ZFS=yes ZROOTFS=/poudriere # The directory where poudriere will store jails and ports BASEFS=/hdd/poudriere TIMESTAMP_LOGS=yes MAX_EXECUTION_TIME=259200 Also, I increased max time of build process to 3 days — because 1 day may not be enough to build _big things_. And because it is very sad to spend 24 hours for building and receive nothing as a result😟. By the way, I don't want to build LLVM, or Rust, or other build-time dependencies from sources — I'm fine with the packaged versions. So to don't spend a time for it, I instruct poudriere to download and use binary packages for these dependencies: PACKAGE_FETCH_BRANCH=quarterly PACKAGE_FETCH_BLACKLIST="pipewire* pulseaudio* wayland*" PACKAGE_FETCH_WHITELIST="gcc* binutils coreutils mpfr nasm mpdecimal bison llvm* libclc-llvm* spirv-llvm-translator-llvm* rust node* lua* perl* python* ruby* ghc* tcl86 bison gmake gsed gawk pcre2 pkgconf autoconf* automake* m4 flex mercurial subversion git cppunit readline bash* curl readline gmp gettext* indexinfo boost* hs-* cmake* help2man html2text pkgconf jsoncpp asciidoc rhash zstd itstool brotli meson tex* doxygen sdocbook-xml docbook* texi2html gnupg gnutls sqlite3 suiteparse* fribidi gdbm utf8cpp xmlstarlet c-ares minizip gtk-doc iso8879 gperf highway p11-kit gcab nettle py3* p5* ninja pygobject* double-conversion dbus dbus-glib evdev-proto gnome-common icu orc ca_root_nss expat xmlcatmgr xmlcharent yelp* json-glib dav1d lame polkit intltool minixmlto sassc redis aom svt-av1 x265 flac neon opusfile wavpack vmaf shaderc opus sndio libbinio xxhash frei0r taglib upnp ffnvcodec-headers v4l_compat yasm speex speexdsp twolame bdftopcf dejavu encodings font-bh-ttf font-misc-ethiopic font-misc-meltho font-util mkfontscale xorg-fonts-truetype xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm spirv-tools glslang alsa-lib gsettings-desktop-schemas woff2 openjpeg geoclue glib-networking harfbuzz-icu enchant2 hunspell hyphen openal-soft rnnoise webrtc-audio-processing abseil crc32c glibmm2* kf6* microsoft-gsl protobuf range-v3 tl-expected libiconv libffi libtextstyle libxml2 libyaml liblz4 libidn2 libxslt libgcrypt libunistring libuv libgpg-error libtool libdeflate libinotify libnghttp2 libtasn* libpsl libssh* libarchive libdaemon libdatrie libevent libgudev libgusb libthai libudev-devd libunwind duktape-lib libsecret libsass libass libedit libvorbis libogg libx264 libsidplayfp libunibreak libv4l libvdpau libvpx libcdio libcdio-paranoia libcue libdvbpsi libepoll-shim libsamplerate libinput libevdev libmtdev libidn libmatroska libtheora libebml libfontenc libXpm libwacom libXv libxshmfence libmysofa libada libb2 libdispatch libfmt libsigc++* libsoup* libproxy" Also, I put the next lines to the `/usr/local/etc/poudriere.d/make.conf`, to prevent enabling the unwanted options when configuring the port(s): DISABLE_LICENSES=yes OPTIONS_UNSET+=JACK PIPEWIRE PULSEAUDIO WAYLAND OPTIONS_SET+=OSS SNDIO X11 To the `/usr/local/etc/poudriere.d/blacklist` I've added the next lines: audio/pulseaudio graphics/wayland multimedia/pipewire With this configuration poudriere will neither install unwanted packages from repository, nor build it from ports. The next steps, including initializing the jail and ports, are well described in the corresponding chapter of the FreeBSD Handbook. With one **valuable** exception! When I create the poudriere ports, the proper quarterly branch should be specified! Like this: # poudriere ports -c -p local -m git+https -B 2025Q1 Without the proper branch I'll faced the obscure dependency problems when downloading the build-time depenedencies as packages: [00:00:48] [Dry Run] Package fetch: Skipping cmake-core-3.31.6: remote version mismatch: cmake-core-3.31.3 [00:00:48] [Dry Run] Package fetch: Skipping gettext-runtime-0.23.1: remote version mismatch: gettext-runtime-0.23 [00:00:48] [Dry Run] Package fetch: Skipping hs-pandoc-3.6.4: remote version mismatch: hs-pandoc-3.6.1 [00:00:48] [Dry Run] Package fetch: Skipping gettext-tools-0.23.1: remote version mismatch: gettext-tools-0.23 [00:00:48] [Dry Run] Package fetch: Skipping libedit-3.1.20250104,1: remote version mismatch: libedit-3.1.20240808,1 [00:00:48] [Dry Run] Package fetch: Skipping lua53-5.3.6_1: deps wanted: libedit-3.1.20250104,1 [00:00:48] [Dry Run] Package fetch: Skipping lua53-5.3.6_1: deps remote: libedit-3.1.20240808,1 [00:00:48] [Dry Run] Package fetch: Will fetch hs-cabal-install-3.12.1.0_1 At the end I have an initialized2 and working jail with ports and the necessary build environment inside. Now it's time to remove unwanted dependencies from the system! ## Removing unwanted dependencies For example, let's work with Wayland. First, I got a list of `wayland`-dependent packages via `pkg required-depends`: % pkg required-depends wayland mesa-dri-24.1.7_1 gtk4-4.16.12 conky-1.22.0 sdl2-2.30.10_1 mesa-libs-24.1.7_1 gstreamer1-plugins-gl-1.24.10 vulkan-loader-1.4.304 dunst-1.10.0 libva-2.22.0 gtk3-3.24.43 libxkbcommon-1.7.0_1 redshift-1.12_2 webkit2-gtk3-2.34.6_10 Let's take `conky` and rebuild it without Wayland dependencies! First, I need an _origin_ of this package (it's name in the ports) to build it with poudriere. The `pkg` gave me the answer and I wrote it to the text file — the list of packages to rebuild: % pkg info -o conky conky-1.22.0 sysutils/conky # echo 'sysutils/conky' >> /hdd/poudriere/14amd64-local-workstation-pkglist Then I configured all the necessary ports with help of the next zsh function: SHELL="/usr/bin/env zsh" xterm -fa Hack-14 -e \ "sudo poudriere options -j 14amd64 -p local -z workstation -c $1" This function takes string with origin as a single argument. It may look a bit tricky — but I'm using it because ncurses interface to configure build options is not displaying correctly inside my EAT. So I start a separate shell in XTerm and configure conky and all it's dependencies inside this shell: After that I start the necessary machinery with the next zsh function: DUNST_OPTS=(-I ~/.config/dunst/icons/update.svg) PKGLIST="/hdd/poudriere/14amd64-local-workstation-pkglist" POUDRIERE_OPTS=(-j 14amd64 -p local -z workstation -f $PKGLIST) sudo poudriere jail -u -j 14amd64 dunstify "Poudriere" "Jail 14amd64 updated" $DUNST_OPTS sudo poudriere ports -p local -u dunstify "Poudriere" "Ports updated" $DUNST_OPTS while true; do dunstify "Poudriere" \ "Dry run start.\nCheck that all will build correctly before the real😎 build" \ $DUNST_OPTS sudo poudriere bulk $POUDRIERE_OPTS -b quarterly -vn read ANSWER?"Is all correct? [y/n/q] " if [ "$ANSWER" = "y" ]; then break elif [ "$ANSWER" = "q" ]; then return fi; done dunstify "Poudriere" "Ports build start..." $DUNST_OPTS sudo poudriere bulk $POUDRIERE_OPTS -b quarterly dunstify "Poudriere" "Ports build end" $DUNST_OPTS There are the next things happen: 1. `local` poudriere ports update and FreeBSD system inside the jail `14amd64` update. If there are already built ports and they got updates — the necessary ports and its' dependencies will be rebuilt during the next stages. 2. Dry-run the build process (`-n`) with the verbose output (`-v`). This is necessary to check that all build-time dependencies, specified in the `PACKAGE_FETCH_WHITELIST` configuration option, will not be built from sources and so on. 3. Ask user about correctness of logs in the console. If not — return to the previous stage. Assuming that user will fix something in the `/usr/local/etc/poudriere.conf` before answering `n` to recheck logs of dry run stage. 4. Start build packages in multiple processes, each on it's own CPU core: The "dry-run" stage is necessary to avoid special sort of problems — when the build-time dependency will not be installed with `pkg` because it depends from another build-time dependency, not listed in `PACKAGE_FETCH_WHITELIST`. [00:01:23] [Dry Run] Checking packages for missing dependencies [00:01:23] [Dry Run] Deleting cmake-core-3.31.3.pkg: missing dependency: expat-2.6.4 [00:01:23] [Dry Run] Deleting gettext-tools-0.23.pkg: missing dependency: libtextstyle-0.23 [00:01:23] [Dry Run] Deleting py311-libxml2-2.11.9_1.pkg: missing dependency: libxml2-2.11.9 The solution is simple — just add necessary package(s) to the `PACKAGE_FETCH_WHITELIST` or decide to build it from ports. Ideally, here should be an option to stop the build process if packages listed in the `PACKAGE_FETCH_WHITELIST` will not be fetched. But it is not added yet to the recent version of poudriere, so I'm using an infinite cycle as a workaround. The build process is fast enough, even on my Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz. Obviously, the big software, like Qt or GTK, will build for hours. Fortunately, the packages that depend on it were waiting while they were building, so other CPU cores were free3 and I could use my system as usual, without any drawbacks😎. After successfull completion, poudriere will create a local FreeBSD repository that I can use to install **my** versions of packages without unwanted dependencies. To use this repo, I simply created the `/usr/local/etc/pkg/repos/LocalRepo.conf` file with the next contents: LocalRepo: { url: "//hdd/poudriere/data/packages/14amd64-local-workstation" } Then I launched `pkg update` as usual: # pkg update Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating FreeBSD-kmods repository catalogue... Fetching data.pkg: 100% 14 KiB 14.6kB/s 00:01 Processing entries: 100% FreeBSD-kmods repository update completed. 44 packages processed. Updating LocalRepo repository catalogue... LocalRepo repository is up to date. All repositories are up to date. And now I'm able to reinstall the conky and get rid of a wayland dependency. To simplify things, I've just added the next alias to `/etc/pkg.conf`: ALIAS { ... poudriere-install = "install -r LocalRepo -f" } And called the next command: # pkg poudriere-install conky Updating LocalRepo repository catalogue... Fetching meta.conf: 100% 179 B 0.2kB/s 00:01 Fetching data.pkg: 100% 132 KiB 135.4kB/s 00:01 Processing entries: 100% LocalRepo repository update completed. 383 packages processed. LocalRepo is up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: conky: 1.22.0 -> 1.22.1 [LocalRepo] Number of packages to be upgraded: 1 Proceed with this action? [y/N]: y [1/1] Upgrading conky from 1.22.0 to 1.22.1... [1/1] Extracting conky-1.22.1: 100% Note, that only the necessary package(s) have been reinstalled. The pkg will not install all the packages from the `LocalRepo`, only the bare minimum to provide the working program in the existing system. As a result, conky has disappeared from the list of wayland-dependent packages and receive the proper `repository` annotation: % pkg required-depends wayland mesa-dri-24.1.7_1 gtk4-4.16.12 sdl2-2.30.10_1 mesa-libs-24.1.7_1 gstreamer1-plugins-gl-1.24.10 vulkan-loader-1.4.304 dunst-1.10.0 libva-2.22.0 gtk3-3.24.43 libxkbcommon-1.7.0_1 redshift-1.12_2 webkit2-gtk3-2.34.6_10 % pkg query "%n: %R" conky conky: LocalRepo ## More complex examples of deWaylandization Sometimes it may be necessary to revisit build options and/or reconfigure the already built package. In my case there was a `libva`. I already built it as a dependency when rebuilding VLC, but I want to recheck the selected options before reinstalling the package. This is where the `poudriere options` comes to the rescue. I can use the `-s` option to view the package options and the `-c` option to reconfigure them. Instead of specifying the list of origins to build with the `-f` option, I just specify the one necessary origin. Note the `-n` option — without it the poudriere will print configuration for the all packages required by the specified origin. # poudriere options -j 14amd64 -p local -z workstation -ns multimedia/libva [00:00:01] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:01] Working on options directory: /usr/local/etc/poudriere.d/14amd64-local-workstation-options [00:00:01] Using ports from: /hdd/poudriere/jails-ports/ports/local ===> The following configuration options are available for libva-2.22.0: WAYLAND=off: Wayland (graphics) support X11=on: X11 (graphics) support ===> Use 'make config' to modify these settings [00:00:01] Re-run 'poudriere options' with the -c flag to modify the options. Looks like the `libva` was configured correctly and I can just install it from my local repo without any problems. Much more complex example comes with a `graphics/mesa-dri`. Unfortunately, I built it with Wayland support, so I will have to reconfigure and rebuild it. This is where the custom zsh function `bsd-poudriere-reconfigure` comes in to save me a tons of typing: Finally, to rebuild the `mesa-dri` and it's dependencies I used the next command: # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -C graphics/mesa-dri And install it from `LocalRepo` the same way as I used for `conky` package. ### Ports flavors There are some packages exists, without the corresponding ports. For example, the package `audacious-gtk3` can be installed, but there is only `multimedia/audactious` port and there are no "Qt/GTK/whatever" options to configure: /usr/ports % pkg info -o audacious-gtk3 audacious-gtk3-4.4.2_1 multimedia/audacious /usr/ports % ls -d multimedia/audacious* multimedia/audacious/ multimedia/audacious-plugins/ /usr/ports % pkg query '%n: %Ok' audacious-gtk3 audacious-gtk3: EXECINFO audacious-gtk3: LIBARCHIVE audacious-gtk3: NLS When I built this port as usual, I got the Qt-based package. But I want a GTK based package because it can display my favourite skin as I want to: It's time to meet the flavors! Some ports can be built in multiple variants. And the variants itself can be observed with the simple `fgrep`: /usr/ports % fgrep 'FLAVORS=' multimedia/audacious/Makefile FLAVORS= qt6 qt5 gtk3 gtk2 So, according to the link above, I can build my `audacious-gtk3` package just by adding line `multimedia/audacious@gtk3` instead of simple `multimedia/audacious` to the my `/hdd/poudriere/14amd64-local-workstation-pkglist`. **Note:** the flavor is specified after the _[at]_ symbol. ### Patching Makefile One of the biggest problems I met, during the recompiling some packages — is the Qt 6 dependent packages. There were two of them: Telegram Desktop and the Qmapshack. Telegram Desktop is directly depends from Qt 6 and the Qmapshack depends on the `bsdisks` package, which depends from the Qt 6 itself (despite the Qmapshack depends on the Qt 5): ~ % pkg rquery '%n: %dn %dv : %do' telegram-desktop | /usr/bin/grep qt telegram-desktop: qt6-shadertools 6.8.2 : x11-toolkits/qt6-shadertools telegram-desktop: qt6-declarative 6.8.2 : x11-toolkits/qt6-declarative telegram-desktop: qt6-wayland 6.8.2 : graphics/qt6-wayland telegram-desktop: qt6-svg 6.8.2 : graphics/qt6-svg telegram-desktop: qt6-lottie 6.8.2 : graphics/qt6-lottie telegram-desktop: qt6-imageformats 6.8.2 : graphics/qt6-imageformats telegram-desktop: qt6-base 6.8.2_1 : devel/qt6-base telegram-desktop: qt6-5compat 6.8.2 : devel/qt6-5compat ~ % pkg rquery '%n: %dn %dv : %do' qmapshack | /usr/bin/grep bsdisks qmapshack: bsdisks 0.36 : sysutils/bsdisks ~ % pkg rquery '%n: %dn %dv : %do' bsdisks | /usr/bin/grep qt bsdisks: polkit-qt-1-qt6 0.200.0 : sysutils/polkit-qt-1 bsdisks: qt6-base 6.8.2_1 : devel/qt6-base And the problem is in `devel/qt6-base` — it depends from the Wayland directly and there is no knob to build it without Wayland support: LIB_DEPENDS= libatk-1.0.so:accessibility/at-spi2-core \ libatk-bridge-2.0.so:accessibility/at-spi2-core \ ... libvulkan.so:graphics/vulkan-loader \ libwayland-client.so:graphics/wayland \ libxkbcommon.so:x11/libxkbcommon \ ... OPTIONS_DEFINE= CUPS X11 OPTIONS_DEFAULT= CUPS X11 OPTIONS_SUB= yes I tried to remove this line with `graphics/wayland` dependency from the Makefile but `qt6-base` failed to compile in this case. I hope the option to compile `devel/qt6-base` without Wayland dependency will be added in the future. But for now I can just stick with Qt 5. First package, dependent from Qt 6 — the Telegram Desktop — was simply removed from my machine. I always encountered problems with this app — it likes to overload my CPU in random times. So I switched to web version and have no problems since. Second package — Qmapshack, dependent from `sysutils/bsdisks`, require more work on it. Bsdisks itself was pulled to my system directly by Qmapshack and wasn't necessary for other programs. So, the necessity of bsdisks was questionable — why is it needed for the mapping program, when I don't use Garmin or other GPS devices for mapping? % pkg rquery '%e' bsdisks UDisks2 service provides interfaces to enumerate and perform operations on disks and storage devices via D-Bus API. Bsdisks is an implementation of UDisks2 service for FreeBSD. Of course, there is no configuration option to build the `astro/qmapshack` without `sysutils/bsdisks`. But … it was marked as a runtime dependency in the Makefile, not a compile time dependency: RUN_DEPENDS= ${LOCALBASE}/bin/bsdisks:sysutils/bsdisks So, it's time to slightly patch the necessary port and try to build Qmapshack without bsdisks. First, I opened the `/hdd/poudriere/ports/local/astro/qmapshack/Makefile` and commented this line. Then, I add `astro/qmapshack` to the `/hdd/poudriere/14amd64-local-workstation-pkglist` and initiated the build without updating the ports, so my change will not clash with the updates from the main repository (if any): # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -nv -C astro/qmapshack ... [00:00:42] [Dry Run] Dry run mode, cleaning up and exiting [00:00:42] [Dry Run] Would build 3 packages using 3 builders [00:00:42] [Dry Run] Ports to build: astro/qmapshack graphics/gdal www/qt5-webengine ... # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -C astro/qmapshack And it successfully builds and running correctly without `bsdisks`! [14:00:58] [01] [14:00:02] Finished www/qt5-webengine | qt5-webengine-5.15.18p5_1: Success [14:01:01] [01] [00:00:00] Building astro/qmapshack | qmapshack-1.17.1_5 [15:08:33] [01] [01:07:32] Finished astro/qmapshack | qmapshack-1.17.1_5: Success [15:08:33] Stopping 3 builders [15:08:37] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [15:09:05] Committing packages to repository: /hdd/poudriere/data/packages/14amd64-local-workstation/.real_1743306462 via .latest symlink [15:09:05] Removing old packages [15:09:05] Built ports: graphics/gdal www/qt5-webengine astro/qmapshack _Main window of Qmapshack GIS software_ Last step: after successfull compilation I reverted my changes in `astro/qmapshack/Makefile` to avoid unnecessary problems with ports updates. ## Results and thoughts Before, I was using a Gentoo (and compiling the whole system, of course) which `emerge` system was inspired by FreeBSD ports. Comparing these two system, I can say that ports infrastructure looks like simplier for me. When I recompiled the program in the Gentoo with the new options I usually did the next: 1. Run `emerge --ask program-name` to see the USE flags of program **and** it's dependencies. 2. If I want to change something and need to see the exact meaning of some USE flag, I call `equery uses program-name`. Then I open a text file somewhere in `/etc/portage/package.use/` and add package atom and the necessary USE flags' settings. 3. After that I could start compilation with necessary options. Looks like for me, the same process in the FreeBSD is simpler. I can configure build-time options for program and it's dependencies with a single call of `poudriere options ...` which provides me a useful TUI menu with descriptions of all of the options. And I don't need to copy it to the some configuration file — all of them will be inserted in the right place themselves. Also, all ports infrastructure looks like simplier — it is just a Makefile and a bunch of human-readable text files with package descriptions and so on! Of course there are drawbacks: * Some packages I think (like Qt 6) lack the configuration options. * If I want to update packages, it is better to update my local repository first. Instead, some of the packages will be dependent from the old libraries which are already updated in the `FreeBSD` repository. Sometimes it will work as usual without any problems, but sometimes, I think, it will be break due to API changes. * If I will update my OS to something like FreeBSD 14.3 — then I should to checkout corresponding branch for local ports and update my 14amd64 jail to the right version of OS. * The same is true for major updates. * And every quarter I should checkout the right branch for the ports, to have a synchronization between the binary packages from the FreeBSD repository and the ports. BTW, I got one sudden and major result of un-waylanding of my system. Before, I was constantly struggling from strange glitches on my display, that looks like this: I thought what this is because: 1. I used the outdated method of acceleration for X server `intel` driver. So, I switched from UXA to Glamor. And this is not helped to me. 2. I used the wrong options for video card powersaving. Revised it and … nothing changed. 3. My soldering of AGAN X230 expansion card were bad. So, I recheck it and found nothing suspicios. 4. I compiled coreboot not the right way because I specified the wrong initial framebuffer resolution when the machine is booting. I switched to precompiled libreboot and properly configure it. Aaand … nothing changed. 5. I started to suspect my video card. Maybe my hardware is dying?…🤔 But after I removed Qt6 and Wayland related stuff from my machine, I'm not seeing these glitches anymore. Before, I was seeing it almost every day. But for now, two days already passed and all is OK. * * * ## Notes 1 https://mastodon.bsd.cafe/@TomAoki/114209804382234562 2 It may be necessary to build a `ports-mgmt/pkg` before building anything in the jail. In my case poudriere won't install `cmake-core` because it has unsatisfied dependency — the `pkg`. Despite the `pkg` of necessary version was previously bootstrapped to install binary packages in the jail. 3 Except the Qt building process. There is a line in `/usr/local/etc/poudriere.conf`, which instructs to build some packages on the all accessible CPU cores: # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* vlc qt*" I added the Qt to it, because it builds so slooow on the one CPU core…

## TOC * Preamble * Poudriere installation * Removing unwanted dependencies * More complex examples of deWaylandization * Ports flavors * Patching Makefile * Results and thoughts * Notes ## Preamble My everyday FreeBSD system has two good old components for graphics and sound — the X Server and the OSS. There are simple reasons to use these components — they are mature, they have tons of user documentation, use case examples, etc. I also like the way these things have been used in the FreeBSD world. Let me quote vermaden, who wrote well (about the OSS) in the Quare FreeBSD? blogpost: > Not many people expect from FreeBSD to shine in that department but it shines a lot here and not from yesterday but from decades. Remember when Linux got rid of the old OSS subsystem with one channel and came up with ‘great’ idea to write ALSA? I remember because I used Linux back then. Disaster is very polite word to describe Linux audio stack back then … and then PulseAudio came and whole Linux audio system got much worse. > > … > > Lets get back to FreeBSD audio then. What FreeBSD offered? A whooping 256 OSS channels mixed live in kernel for low latency. Everything audio related just worked out of the box – and still works today. This is where I see the pattern. If in the Linux world there are many examples of throwing away software that has served people for years or decades and can (and should, I think) be updated to adapt to the changed reality (e.g. `ifconfig`). Then in the FreeBSD world such software just … gets the necessary updates and continues to be used. In my journey to install and use the simple system with the good old software I encountered some problems. Sometimes, when I install a simple program, like conky or dunst — the pkg tries to install Wayland as a dependency! Or PulseAudio (thankfully, there is no SystemD in the FreeBSD world). Of course, I **do not want** these things in my simple system based on the X server, OSS and good old initialization scripts. As stated @[email protected] — some binary packages for FreeBSD have been built with the same dependencies that came from upstream — to minimize maintainer's work, which is obviously hard1. As a result, some packages came to my machine with unwanted dependencies or compile-time options that were not ideal for me. For example, the native for BSD `sndio` sound server is disabled by default in the `mutlimedia/audacious-plugins` port. But those "linuxisms" — like PulseAudio and PipeWire — are enabled🤷‍♂️. I was very surprised to see the `pulseaudio` process in the top 5 CPU consuming processes while listening to my music. My sound system using OSS and sndio, why is PulseAudio here?!🤔 After that I started to think about removing unwanted dependencies from my packages completely… Or another example — when I install some graphical application based on the QT6 or GTK3/GTK4 — not only the necessary graphical libraries are installed as dependencies but also a lot of Wayland stuff. Even if my system doesn't use Wayland, I have packages of _these things_ installed: % pkg info -a | /usr/bin/grep wayland qt6-wayland-6.8.2 Qt6 wrapper for Wayland wayland-1.23.1 Core Wayland window system code and protocol wayland-protocols-1.39 Wayland protocols At some point, I decided to override this and get my versions of packages without unwanted dependencies. A naive approach — just build some packages without unwanted compile-time options via the Ports infrastructure — almost works for me. Almost. When the corresponding package from the FreeBSD repository was updated — it overwrites my custom package, built with ports. A solution I found — were far from ideal solution. I can lock my package so that it will not be updated with the same binary package from the repository. And temporarily unlock it when I want to update the _my_ package via the ports infrastructure. In the FreeBSD Handbook, section 4.6 "Building Packages with poudriere", there was another way to accomplish my task without such update problems. I can build my own local repository with some packages that have PulseAudio/Wayland dependencies removed. And this is not a some hacky thing — as far as I can see, the poudriere used by the FreeBSD maintainers to build the binary packages: % pkg info emacs ... Annotations : FreeBSD_version: 1401000 build_timestamp: 2025-02-27T01:04:32+0000 built_by : poudriere-git-3.4.2 And it works pretty simple — poudriere just reuses existing FreeBSD infrastructure to build packages. Package sources taken from ports (via git/https), binary packages downloaded from existing FreeBSD repositories via the pkg, build process itself runs inside the jail and all corresponding files can be stored in the separate ZFS dataset — so the dataset with the root filesystem will not be polluted by the build-time dependencies or building artifacts, like object files or logs. At the end, poudriere will create the local repository with packages. The same repository as the main FreeBSD repository, but _local_ and with only necesary packages. Poudriere doesn't force me to build the whole system on my machine. The main selling point is that all packages installed from this repository will be updated through **this** repository. They will not be overwritten by updates from the main FreeBSD repository. This is because the `pkg` adds the annotation with repository name to the installed package and uses it when updating: % pkg info -A conky conky-1.22.1: FreeBSD_version: 1402000 build_timestamp: 2025-03-23T14:58:18+0000 built_by : poudriere-git-3.4.2 cpe : cpe:2.3conky:conky:1.22.1:::::freebsd14:x64 port_checkout_unclean: no port_git_hash : 6bcf1e971 ports_top_checkout_unclean: no ports_top_git_hash: 3fe34c578 repo_type : binary repository : LocalRepo The second selling point: I can setup all these machinery on a separate disk, which I mainly use for QEMU/bhyve VMs and other _big things_. This way, my build infrastructure doesn't take up space on the root filesystem. ## Poudriere installation Before I welcomed poudriere to my laptop, I created a separate dataset for poudriere-related files: # zfs create hdd/poudriere # zfs set compression=gzip hdd/poudriere The only files, which are stored in the root filesystem are configuration files: * Build options for the ports — stored in the `/usr/local/etc/poudriere.d/jail-port-set-options/`. * Blacklist for unwanted ports: `/usr/local/etc/poudriere.d/blacklist`. * `make.conf` for poudriere jails: `/usr/local/etc/poudriere.d/make.conf`. * And the poudriere configuration itself, of course. Then, after installing the poudriere package, I slightly changed the default configuration file and added the following options to use `/hdd/poudriere/` dataset as the main path for both the jail and the local repository, not my main dataset with the root filesystem: ZPOOL=hdd #NO_ZFS=yes ZROOTFS=/poudriere # The directory where poudriere will store jails and ports BASEFS=/hdd/poudriere TIMESTAMP_LOGS=yes MAX_EXECUTION_TIME=259200 Also, I increased max time of build process to 3 days — because 1 day may not be enough to build _big things_. And because it is very sad to spend 24 hours for building and receive nothing as a result😟. By the way, I don't want to build LLVM, or Rust, or other build-time dependencies from sources — I'm fine with the packaged versions. So to don't spend a time for it, I instruct poudriere to download and use binary packages for these dependencies: PACKAGE_FETCH_BRANCH=quarterly PACKAGE_FETCH_BLACKLIST="pipewire* pulseaudio* wayland*" PACKAGE_FETCH_WHITELIST="gcc* binutils coreutils mpfr nasm mpdecimal bison llvm* libclc-llvm* spirv-llvm-translator-llvm* rust node* lua* perl* python* ruby* ghc* tcl86 bison gmake gsed gawk pcre2 pkgconf autoconf* automake* m4 flex mercurial subversion git cppunit readline bash* curl readline gmp gettext* indexinfo boost* hs-* cmake* help2man html2text pkgconf jsoncpp asciidoc rhash zstd itstool brotli meson tex* doxygen sdocbook-xml docbook* texi2html gnupg gnutls sqlite3 suiteparse* fribidi gdbm utf8cpp xmlstarlet c-ares minizip gtk-doc iso8879 gperf highway p11-kit gcab nettle py3* p5* ninja pygobject* double-conversion dbus dbus-glib evdev-proto gnome-common icu orc ca_root_nss expat xmlcatmgr xmlcharent yelp* json-glib dav1d lame polkit intltool minixmlto sassc redis aom svt-av1 x265 flac neon opusfile wavpack vmaf shaderc opus sndio libbinio xxhash frei0r taglib upnp ffnvcodec-headers v4l_compat yasm speex speexdsp twolame bdftopcf dejavu encodings font-bh-ttf font-misc-ethiopic font-misc-meltho font-util mkfontscale xorg-fonts-truetype xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm spirv-tools glslang alsa-lib gsettings-desktop-schemas woff2 openjpeg geoclue glib-networking harfbuzz-icu enchant2 hunspell hyphen openal-soft rnnoise webrtc-audio-processing abseil crc32c glibmm2* kf6* microsoft-gsl protobuf range-v3 tl-expected libiconv libffi libtextstyle libxml2 libyaml liblz4 libidn2 libxslt libgcrypt libunistring libuv libgpg-error libtool libdeflate libinotify libnghttp2 libtasn* libpsl libssh* libarchive libdaemon libdatrie libevent libgudev libgusb libthai libudev-devd libunwind duktape-lib libsecret libsass libass libedit libvorbis libogg libx264 libsidplayfp libunibreak libv4l libvdpau libvpx libcdio libcdio-paranoia libcue libdvbpsi libepoll-shim libsamplerate libinput libevdev libmtdev libidn libmatroska libtheora libebml libfontenc libXpm libwacom libXv libxshmfence libmysofa libada libb2 libdispatch libfmt libsigc++* libsoup* libproxy" Also, I put the next lines to the `/usr/local/etc/poudriere.d/make.conf`, to prevent enabling the unwanted options when configuring the port(s): DISABLE_LICENSES=yes OPTIONS_UNSET+=JACK PIPEWIRE PULSEAUDIO WAYLAND OPTIONS_SET+=OSS SNDIO X11 To the `/usr/local/etc/poudriere.d/blacklist` I've added the next lines: audio/pulseaudio graphics/wayland multimedia/pipewire With this configuration poudriere will neither install unwanted packages from repository, nor build it from ports. The next steps, including initializing the jail and ports, are well described in the corresponding chapter of the FreeBSD Handbook. With one **valuable** exception! When I create the poudriere ports, the proper quarterly branch should be specified! Like this: # poudriere ports -c -p local -m git+https -B 2025Q1 Without the proper branch I'll faced the obscure dependency problems when downloading the build-time depenedencies as packages: [00:00:48] [Dry Run] Package fetch: Skipping cmake-core-3.31.6: remote version mismatch: cmake-core-3.31.3 [00:00:48] [Dry Run] Package fetch: Skipping gettext-runtime-0.23.1: remote version mismatch: gettext-runtime-0.23 [00:00:48] [Dry Run] Package fetch: Skipping hs-pandoc-3.6.4: remote version mismatch: hs-pandoc-3.6.1 [00:00:48] [Dry Run] Package fetch: Skipping gettext-tools-0.23.1: remote version mismatch: gettext-tools-0.23 [00:00:48] [Dry Run] Package fetch: Skipping libedit-3.1.20250104,1: remote version mismatch: libedit-3.1.20240808,1 [00:00:48] [Dry Run] Package fetch: Skipping lua53-5.3.6_1: deps wanted: libedit-3.1.20250104,1 [00:00:48] [Dry Run] Package fetch: Skipping lua53-5.3.6_1: deps remote: libedit-3.1.20240808,1 [00:00:48] [Dry Run] Package fetch: Will fetch hs-cabal-install-3.12.1.0_1 At the end I have an initialized2 and working jail with ports and the necessary build environment inside. Now it's time to remove unwanted dependencies from the system! ## Removing unwanted dependencies For example, let's work with Wayland. First, I got a list of `wayland`-dependent packages via `pkg required-depends`: % pkg required-depends wayland mesa-dri-24.1.7_1 gtk4-4.16.12 conky-1.22.0 sdl2-2.30.10_1 mesa-libs-24.1.7_1 gstreamer1-plugins-gl-1.24.10 vulkan-loader-1.4.304 dunst-1.10.0 libva-2.22.0 gtk3-3.24.43 libxkbcommon-1.7.0_1 redshift-1.12_2 webkit2-gtk3-2.34.6_10 Let's take `conky` and rebuild it without Wayland dependencies! First, I need an _origin_ of this package (it's name in the ports) to build it with poudriere. The `pkg` gave me the answer and I wrote it to the text file — the list of packages to rebuild: % pkg info -o conky conky-1.22.0 sysutils/conky # echo 'sysutils/conky' >> /hdd/poudriere/14amd64-local-workstation-pkglist Then I configured all the necessary ports with help of the next zsh function: SHELL="/usr/bin/env zsh" xterm -fa Hack-14 -e \ "sudo poudriere options -j 14amd64 -p local -z workstation -c $1" This function takes string with origin as a single argument. It may look a bit tricky — but I'm using it because ncurses interface to configure build options is not displaying correctly inside my EAT. So I start a separate shell in XTerm and configure conky and all it's dependencies inside this shell: After that I start the necessary machinery with the next zsh function: DUNST_OPTS=(-I ~/.config/dunst/icons/update.svg) PKGLIST="/hdd/poudriere/14amd64-local-workstation-pkglist" POUDRIERE_OPTS=(-j 14amd64 -p local -z workstation -f $PKGLIST) sudo poudriere jail -u -j 14amd64 dunstify "Poudriere" "Jail 14amd64 updated" $DUNST_OPTS sudo poudriere ports -p local -u dunstify "Poudriere" "Ports updated" $DUNST_OPTS while true; do dunstify "Poudriere" \ "Dry run start.\nCheck that all will build correctly before the real😎 build" \ $DUNST_OPTS sudo poudriere bulk $POUDRIERE_OPTS -b quarterly -vn read ANSWER?"Is all correct? [y/n/q] " if [ "$ANSWER" = "y" ]; then break elif [ "$ANSWER" = "q" ]; then return fi; done dunstify "Poudriere" "Ports build start..." $DUNST_OPTS sudo poudriere bulk $POUDRIERE_OPTS -b quarterly dunstify "Poudriere" "Ports build end" $DUNST_OPTS There are the next things happen: 1. `local` poudriere ports update and FreeBSD system inside the jail `14amd64` update. If there are already built ports and they got updates — the necessary ports and its' dependencies will be rebuilt during the next stages. 2. Dry-run the build process (`-n`) with the verbose output (`-v`). This is necessary to check that all build-time dependencies, specified in the `PACKAGE_FETCH_WHITELIST` configuration option, will not be built from sources and so on. 3. Ask user about correctness of logs in the console. If not — return to the previous stage. Assuming that user will fix something in the `/usr/local/etc/poudriere.conf` before answering `n` to recheck logs of dry run stage. 4. Start build packages in multiple processes, each on it's own CPU core: The "dry-run" stage is necessary to avoid special sort of problems — when the build-time dependency will not be installed with `pkg` because it depends from another build-time dependency, not listed in `PACKAGE_FETCH_WHITELIST`. [00:01:23] [Dry Run] Checking packages for missing dependencies [00:01:23] [Dry Run] Deleting cmake-core-3.31.3.pkg: missing dependency: expat-2.6.4 [00:01:23] [Dry Run] Deleting gettext-tools-0.23.pkg: missing dependency: libtextstyle-0.23 [00:01:23] [Dry Run] Deleting py311-libxml2-2.11.9_1.pkg: missing dependency: libxml2-2.11.9 The solution is simple — just add necessary package(s) to the `PACKAGE_FETCH_WHITELIST` or decide to build it from ports. Ideally, here should be an option to stop the build process if packages listed in the `PACKAGE_FETCH_WHITELIST` will not be fetched. But it is not added yet to the recent version of poudriere, so I'm using an infinite cycle as a workaround. The build process is fast enough, even on my Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz. Obviously, the big software, like Qt or GTK, will build for hours. Fortunately, the packages that depend on it were waiting while they were building, so other CPU cores were free3 and I could use my system as usual, without any drawbacks😎. After successfull completion, poudriere will create a local FreeBSD repository that I can use to install **my** versions of packages without unwanted dependencies. To use this repo, I simply created the `/usr/local/etc/pkg/repos/LocalRepo.conf` file with the next contents: LocalRepo: { url: "//hdd/poudriere/data/packages/14amd64-local-workstation" } Then I launched `pkg update` as usual: # pkg update Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating FreeBSD-kmods repository catalogue... Fetching data.pkg: 100% 14 KiB 14.6kB/s 00:01 Processing entries: 100% FreeBSD-kmods repository update completed. 44 packages processed. Updating LocalRepo repository catalogue... LocalRepo repository is up to date. All repositories are up to date. And now I'm able to reinstall the conky and get rid of a wayland dependency. To simplify things, I've just added the next alias to `/etc/pkg.conf`: ALIAS { ... poudriere-install = "install -r LocalRepo -f" } And called the next command: # pkg poudriere-install conky Updating LocalRepo repository catalogue... Fetching meta.conf: 100% 179 B 0.2kB/s 00:01 Fetching data.pkg: 100% 132 KiB 135.4kB/s 00:01 Processing entries: 100% LocalRepo repository update completed. 383 packages processed. LocalRepo is up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: conky: 1.22.0 -> 1.22.1 [LocalRepo] Number of packages to be upgraded: 1 Proceed with this action? [y/N]: y [1/1] Upgrading conky from 1.22.0 to 1.22.1... [1/1] Extracting conky-1.22.1: 100% Note, that only the necessary package(s) have been reinstalled. The pkg will not install all the packages from the `LocalRepo`, only the bare minimum to provide the working program in the existing system. As a result, conky has disappeared from the list of wayland-dependent packages and receive the proper `repository` annotation: % pkg required-depends wayland mesa-dri-24.1.7_1 gtk4-4.16.12 sdl2-2.30.10_1 mesa-libs-24.1.7_1 gstreamer1-plugins-gl-1.24.10 vulkan-loader-1.4.304 dunst-1.10.0 libva-2.22.0 gtk3-3.24.43 libxkbcommon-1.7.0_1 redshift-1.12_2 webkit2-gtk3-2.34.6_10 % pkg query "%n: %R" conky conky: LocalRepo ## More complex examples of deWaylandization Sometimes it may be necessary to revisit build options and/or reconfigure the already built package. In my case there was a `libva`. I already built it as a dependency when rebuilding VLC, but I want to recheck the selected options before reinstalling the package. This is where the `poudriere options` comes to the rescue. I can use the `-s` option to view the package options and the `-c` option to reconfigure them. Instead of specifying the list of origins to build with the `-f` option, I just specify the one necessary origin. Note the `-n` option — without it the poudriere will print configuration for the all packages required by the specified origin. # poudriere options -j 14amd64 -p local -z workstation -ns multimedia/libva [00:00:01] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:01] Working on options directory: /usr/local/etc/poudriere.d/14amd64-local-workstation-options [00:00:01] Using ports from: /hdd/poudriere/jails-ports/ports/local ===> The following configuration options are available for libva-2.22.0: WAYLAND=off: Wayland (graphics) support X11=on: X11 (graphics) support ===> Use 'make config' to modify these settings [00:00:01] Re-run 'poudriere options' with the -c flag to modify the options. Looks like the `libva` was configured correctly and I can just install it from my local repo without any problems. Much more complex example comes with a `graphics/mesa-dri`. Unfortunately, I built it with Wayland support, so I will have to reconfigure and rebuild it. This is where the custom zsh function `bsd-poudriere-reconfigure` comes in to save me a tons of typing: Finally, to rebuild the `mesa-dri` and it's dependencies I used the next command: # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -C graphics/mesa-dri And install it from `LocalRepo` the same way as I used for `conky` package. ### Ports flavors There are some packages exists, without the corresponding ports. For example, the package `audacious-gtk3` can be installed, but there is only `multimedia/audactious` port and there are no "Qt/GTK/whatever" options to configure: /usr/ports % pkg info -o audacious-gtk3 audacious-gtk3-4.4.2_1 multimedia/audacious /usr/ports % ls -d multimedia/audacious* multimedia/audacious/ multimedia/audacious-plugins/ /usr/ports % pkg query '%n: %Ok' audacious-gtk3 audacious-gtk3: EXECINFO audacious-gtk3: LIBARCHIVE audacious-gtk3: NLS When I built this port as usual, I got the Qt-based package. But I want a GTK based package because it can display my favourite skin as I want to: It's time to meet the flavors! Some ports can be built in multiple variants. And the variants itself can be observed with the simple `fgrep`: /usr/ports % fgrep 'FLAVORS=' multimedia/audacious/Makefile FLAVORS= qt6 qt5 gtk3 gtk2 So, according to the link above, I can build my `audacious-gtk3` package just by adding line `multimedia/audacious@gtk3` instead of simple `multimedia/audacious` to the my `/hdd/poudriere/14amd64-local-workstation-pkglist`. **Note:** the flavor is specified after the _[at]_ symbol. ### Patching Makefile One of the biggest problems I met, during the recompiling some packages — is the Qt 6 dependent packages. There were two of them: Telegram Desktop and the Qmapshack. Telegram Desktop is directly depends from Qt 6 and the Qmapshack depends on the `bsdisks` package, which depends from the Qt 6 itself (despite the Qmapshack depends on the Qt 5): ~ % pkg rquery '%n: %dn %dv : %do' telegram-desktop | /usr/bin/grep qt telegram-desktop: qt6-shadertools 6.8.2 : x11-toolkits/qt6-shadertools telegram-desktop: qt6-declarative 6.8.2 : x11-toolkits/qt6-declarative telegram-desktop: qt6-wayland 6.8.2 : graphics/qt6-wayland telegram-desktop: qt6-svg 6.8.2 : graphics/qt6-svg telegram-desktop: qt6-lottie 6.8.2 : graphics/qt6-lottie telegram-desktop: qt6-imageformats 6.8.2 : graphics/qt6-imageformats telegram-desktop: qt6-base 6.8.2_1 : devel/qt6-base telegram-desktop: qt6-5compat 6.8.2 : devel/qt6-5compat ~ % pkg rquery '%n: %dn %dv : %do' qmapshack | /usr/bin/grep bsdisks qmapshack: bsdisks 0.36 : sysutils/bsdisks ~ % pkg rquery '%n: %dn %dv : %do' bsdisks | /usr/bin/grep qt bsdisks: polkit-qt-1-qt6 0.200.0 : sysutils/polkit-qt-1 bsdisks: qt6-base 6.8.2_1 : devel/qt6-base And the problem is in `devel/qt6-base` — it depends from the Wayland directly and there is no knob to build it without Wayland support: LIB_DEPENDS= libatk-1.0.so:accessibility/at-spi2-core \ libatk-bridge-2.0.so:accessibility/at-spi2-core \ ... libvulkan.so:graphics/vulkan-loader \ libwayland-client.so:graphics/wayland \ libxkbcommon.so:x11/libxkbcommon \ ... OPTIONS_DEFINE= CUPS X11 OPTIONS_DEFAULT= CUPS X11 OPTIONS_SUB= yes I tried to remove this line with `graphics/wayland` dependency from the Makefile but `qt6-base` failed to compile in this case. I hope the option to compile `devel/qt6-base` without Wayland dependency will be added in the future. But for now I can just stick with Qt 5. First package, dependent from Qt 6 — the Telegram Desktop — was simply removed from my machine. I always encountered problems with this app — it likes to overload my CPU in random times. So I switched to web version and have no problems since. Second package — Qmapshack, dependent from `sysutils/bsdisks`, require more work on it. Bsdisks itself was pulled to my system directly by Qmapshack and wasn't necessary for other programs. So, the necessity of bsdisks was questionable — why is it needed for the mapping program, when I don't use Garmin or other GPS devices for mapping? % pkg rquery '%e' bsdisks UDisks2 service provides interfaces to enumerate and perform operations on disks and storage devices via D-Bus API. Bsdisks is an implementation of UDisks2 service for FreeBSD. Of course, there is no configuration option to build the `astro/qmapshack` without `sysutils/bsdisks`. But … it was marked as a runtime dependency in the Makefile, not a compile time dependency: RUN_DEPENDS= ${LOCALBASE}/bin/bsdisks:sysutils/bsdisks So, it's time to slightly patch the necessary port and try to build Qmapshack without bsdisks. First, I opened the `/hdd/poudriere/ports/local/astro/qmapshack/Makefile` and commented this line. Then, I add `astro/qmapshack` to the `/hdd/poudriere/14amd64-local-workstation-pkglist` and initiated the build without updating the ports, so my change will not clash with the updates from the main repository (if any): # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -nv -C astro/qmapshack ... [00:00:42] [Dry Run] Dry run mode, cleaning up and exiting [00:00:42] [Dry Run] Would build 3 packages using 3 builders [00:00:42] [Dry Run] Ports to build: astro/qmapshack graphics/gdal www/qt5-webengine ... # poudriere bulk -j 14amd64 -p local -z workstation -b quarterly -C astro/qmapshack And it successfully builds and running correctly without `bsdisks`! [14:00:58] [01] [14:00:02] Finished www/qt5-webengine | qt5-webengine-5.15.18p5_1: Success [14:01:01] [01] [00:00:00] Building astro/qmapshack | qmapshack-1.17.1_5 [15:08:33] [01] [01:07:32] Finished astro/qmapshack | qmapshack-1.17.1_5: Success [15:08:33] Stopping 3 builders [15:08:37] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [15:09:05] Committing packages to repository: /hdd/poudriere/data/packages/14amd64-local-workstation/.real_1743306462 via .latest symlink [15:09:05] Removing old packages [15:09:05] Built ports: graphics/gdal www/qt5-webengine astro/qmapshack _Main window of Qmapshack GIS software_ Last step: after successfull compilation I reverted my changes in `astro/qmapshack/Makefile` to avoid unnecessary problems with ports updates. ## Results and thoughts Before, I was using a Gentoo (and compiling the whole system, of course) which `emerge` system was inspired by FreeBSD ports. Comparing these two system, I can say that ports infrastructure looks like simplier for me. When I recompiled the program in the Gentoo with the new options I usually did the next: 1. Run `emerge --ask program-name` to see the USE flags of program **and** it's dependencies. 2. If I want to change something and need to see the exact meaning of some USE flag, I call `equery uses program-name`. Then I open a text file somewhere in `/etc/portage/package.use/` and add package atom and the necessary USE flags' settings. 3. After that I could start compilation with necessary options. Looks like for me, the same process in the FreeBSD is simpler. I can configure build-time options for program and it's dependencies with a single call of `poudriere options ...` which provides me a useful TUI menu with descriptions of all of the options. And I don't need to copy it to the some configuration file — all of them will be inserted in the right place themselves. Also, all ports infrastructure looks like simplier — it is just a Makefile and a bunch of human-readable text files with package descriptions and so on! Of course there are drawbacks: * Some packages I think (like Qt 6) lack the configuration options. * If I want to update packages, it is better to update my local repository first. Instead, some of the packages will be dependent from the old libraries which are already updated in the `FreeBSD` repository. Sometimes it will work as usual without any problems, but sometimes, I think, it will be break due to API changes. * If I will update my OS to something like FreeBSD 14.3 — then I should to checkout corresponding branch for local ports and update my 14amd64 jail to the right version of OS. * The same is true for major updates. * And every quarter I should checkout the right branch for the ports, to have a synchronization between the binary packages from the FreeBSD repository and the ports. BTW, I got one sudden and major result of un-waylanding of my system. Before, I was constantly struggling from strange glitches on my display, that looks like this: I thought what this is because: 1. I used the outdated method of acceleration for X server `intel` driver. So, I switched from UXA to Glamor. And this is not helped to me. 2. I used the wrong options for video card powersaving. Revised it and … nothing changed. 3. My soldering of AGAN X230 expansion card were bad. So, I recheck it and found nothing suspicios. 4. I compiled coreboot not the right way because I specified the wrong initial framebuffer resolution when the machine is booting. I switched to precompiled libreboot and properly configure it. Aaand … nothing changed. 5. I started to suspect my video card. Maybe my hardware is dying?…🤔 But after I removed Qt6 and Wayland related stuff from my machine, I'm not seeing these glitches anymore. Before, I was seeing it almost every day. But for now, two days already passed and all is OK. * * * ## Notes 1 https://mastodon.bsd.cafe/@TomAoki/114209804382234562 2 It may be necessary to build a `ports-mgmt/pkg` before building anything in the jail. In my case poudriere won't install `cmake-core` because it has unsatisfied dependency — the `pkg`. Despite the `pkg` of necessary version was previously bootstrapped to install binary packages in the jail. 3 Except the Qt building process. There is a line in `/usr/local/etc/poudriere.conf`, which instructs to build some packages on the all accessible CPU cores: # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* vlc qt*" I added the Qt to it, because it builds so slooow on the one CPU core…

TOC    Preamble Poudriere installation Removing unwanted dependencies More complex examples of deWaylandization Ports flavors Patching Makefile Results and thoughts Notes Preamble My everyday FreeBSD system has two good old components for graphics and sound — the X Server and the OSS. There are simple reasons to use these components — they are mature, they have tons of user documentation, use case examples, etc. I also like the way these things have been used in the FreeBSD world. Let me quote vermaden, who wrote well (about the OSS) in the Quare FreeBSD? blogpost:

I've never quite understood what d-bus is for and what it does. What kind of things wouldn't work without it? I have personally never went out of my way to enable it programs like chrome or firefox always start the session anyways, someone told me it's a security concern, is that true? edit: when i say the 'freebsd' desktop i mean a desktop without linuxisms

I've never quite understood what d-bus is for and what it does. What kind of things wouldn't work without it? I have personally never went out of my way to enable it programs like chrome or firefox always start the session anyways, someone told me it's a security concern, is that true? edit: when i say the 'freebsd' desktop i mean a desktop without linuxisms

AI/LLMs have been hugely beneficial to my FreeBSD experience, but you'll notice that responses bias significantly towards Linuxisms. You can overcome this somewhat by specifying obvious opening tags like: "_In FreeBSD {command, config, system, /etc}, how/why/do {X,Y, and/or Z}. POSIX preferred "_ But if you want to massively improve the response quality and avoid Linuxisms, **upload the relevant manpages.** Not copy/pasted as text, but as a file. **Upload your config file too.** I've found improved quality responses with statements like: * _Take a look at the manpage and let me know if you can find {options, syntax, explanations, etc}_ * _Be careful not to make things up. Read the manpage carefully, and let me know if there is any clarity regarding {Y}_ * [Copy/pasting terminal output with diagnostic errors] * _Are you completely sure about that? Can you double check the manpage because I thought that {Z}, but I 'm not totally sure._ * _It 's okay if you dont know. If you need the manual for {command} or additional reference material, I can provide that._ Another important note is conversation management. If the thing starts hallucinating early on and making mistakes, scrap the thread and try again, or else it's likely to just keep on faulting. Adjust your opening verbaige to avoid the original errors. Conversely, I've found that threads can get into a sweet spot, where the AI understands the assignment. Interested in what other tips some of you have found for improving AI/LLM experience. Personally I used Claude.