Building Instructions We will use an incus trixie VM to perform the build so we don t clutter our own machine.

incus launch images:debian/trixie <instance-name> --vm

Then let s hop into the machine and install the dependencies.

incus shell <instance-name>

And

apt install git distrobuilder

Let s clone the repository with the yaml definition to build a buster container.

git clone --branch support-debian-buster https://github.com/charles2910/lxc-ci.git
# and cd into it
cd lxc-ci

Then all we need is to pass the correct arguments to distrobuilder so it can build the image. It can output the image in the current directory or in a pre-defined place, so let s create an easy place for the images.

mkdir -p /tmp/images/buster/container
# and perform the build
distrobuilder build-incus images/debian.yaml /tmp/images/buster/container/ \
            -o image.architecture=amd64 \
            -o image.release=buster \
            -o image.variant=default  \
            -o source.url="http://archive.debian.org/debian"

It requires a build definition written in yaml format to perform the build. If you are curious, check the images/ subdir. If all worked correctly, you should have two files in your pre-defined target directory. In our case, /tmp/images/buster/container/ contains:

incus.tar.xz  rootfs.squashfs

Let s copy it to our host so we can add the image to our incus server.

incus file pull <instance-name>/tmp/images/buster/container/incus.tar.xz .
incus file pull <instance-name>/tmp/images/buster/container/rootfs.squashfs .
# and import it as debian/10
incus image import incus.tar.xz rootfs.squashfs --alias debian/10

If we are lucky, we can run our Debian buster container now!

incus launch local:debian/10 <debian-buster-instance>
incus shell <debian-buster-instance>

Well, now all that is left is to install Freexian s ELTS package repository and update the image to get a lot of CVE fixes.

apt install --assume-yes wget
wget https://deb.freexian.com/extended-lts/archive-key.gpg -O /etc/apt/trusted.gpg.d/freexian-archive-extended-lts.gpg
cat <<EOF >/etc/apt/sources.list.d/extended-lts.list
deb http://deb.freexian.com/extended-lts buster-lts main contrib non-free
EOF
apt update
apt --assume-yes upgrade

• it can update and upgrade the container (currently commented-out)
• it fetches the repository key in ascii form from the llvm.org site
• it creates the sources entry for, here tagged for llvm current (22 at time of writing)
• it sets up the required ~/.R/Makevars to use that compiler
• it installs clang-22 (and clang++-22) (still using the g++ C++ library)

#!/bin/sh

## Update does not hurt but is not strictly needed
#apt update --quiet --quiet
#apt upgrade --yes

## wget -qO- https://apt.llvm.org/llvm-snapshot.gpg.key   sudo tee /etc/apt/trusted.gpg.d/apt.llvm.org.asc
## or as we are root in container
wget -qO- https://apt.llvm.org/llvm-snapshot.gpg.key > /etc/apt/trusted.gpg.d/apt.llvm.org.asc

cat <<EOF >/etc/apt/sources.list.d/llvm-dev.sources
Types: deb
URIs: http://apt.llvm.org/unstable/
# for clang-21 
#   Suites: llvm-toolchain-21
# for current clang
Suites: llvm-toolchain
Components: main
Signed-By: /etc/apt/trusted.gpg.d/apt.llvm.org.asc
EOF

test -d ~/.R   mkdir ~/.R
cat <<EOF >~/.R/Makevars
CLANGVER=-22
# CLANGLIB=-stdlib=libc++
CXX=clang++\$(CLANGVER) \$(CLANGLIB)
CXX11=clang++\$(CLANGVER) \$(CLANGLIB)
CXX14=clang++\$(CLANGVER) \$(CLANGLIB)
CXX17=clang++\$(CLANGVER) \$(CLANGLIB)
CXX20=clang++\$(CLANGVER) \$(CLANGLIB)
CC=clang\$(CLANGVER)
SHLIB_CXXLD=clang++\$(CLANGVER) \$(CLANGLIB)
EOF

apt update
apt install --yes clang-22

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

• Add backlight brightness handling (MR)
• Handle brightness keybinding (MR)
• Use stevia (MR)
• Test suite improvements (MR)
• Simplify keybinding generation (MR)
• Allow g-c-c to work against nested phosh (MR)
• Hide demo plugins (MR)

• Unbreak type to search (MR)
• Update to wlroots 0.19.1 (MR)
• Relese 0.50~rc1
• Catch up with wlroots git (MR)
• Damage tracking and render simplifications (MR)

• Allow to hide plugins (MR)
• Release 0.50~rc1
• Hide demo plugins by default (MR)
• Sink floating refs properly (MR)
• Simplify includes (MR)

• Fix meson warning (MR)
• Update URLs (MR)
• Make backspace more clever (MR)
• presage: Better handle predictions vs completions: (MR)

• Update to pfs 0.0.5 (MR)
• Release 0.50~rc1
• Allow to disable Rust portal (MR)
• Use release ashpd (MR)

• Release 0.0.5 (MR)

• Modernize and release 0.0.7 (MR)

• Bump libphosh dependency to 0.0.7 (MR)

• Release 0.8.5 (MR)
• Publish API docs (MR)

• Release 0.8.6 (MR)

• 0.46 backports for trixie: (MR) - testers needed!
• cellbroadcastd: Upload to sid (MR)
• meta-phosh: Update deps (MR)
• meta-phosh: Adjust deps for 0.49 (MR)
• phosh-tour: Upload to unstable (MR)
• xdg-desktop-portal-phosh: Upload 0.50~rc1
• xdg-desktop-portal-phosh: Enable Rust based portal (MR)
• wlroots: Upload 0.19.1
• rust-libphosh: Update to 0.0.7
• Release Phosh 0.50~rc1
• Release phosh-mobile-seettings 0.50~rc1
• Release feedbackd 0.8.5
• Release feedbackd-device-themes 0.8.6
• Release phoc 0.50~rc1

• Fix brightness values (MR)

• Make gbp import-orig --uscan useful again when passing in a version (MR)
• Make dsc component tests fetch from salsa (MR)

• Fix gcc-15 build (MR)

• Fix missing application icon (MR)

• Avoid 404 on each page load (MR)
• Fingerprint custom CSS (MR)

• Fix alias in systemd unit (MR)
• Document support items (MR)

• Add backlight support for Shift6MQ (v1, v2, v3)

• udev: Don't leak parent device (MR)

• Don't require gsd-49 yet (MR)

• Fix links (MR)
• Update several entries (MR)
• Mention nonprofit (MR)
• Automatic deploy (MR)

• p-m-s: Tweaks parsing (MR)
• p-m-s: Prefer char over gchar (MR)
• p-m-s/tweaks: Add .XResources backend (MR)
• p-m-s/tweaks: Add Symlink backend (MR)
• p-m-s/tweaks: Cleanup includes (MR)
• p-m-s/tweaks: Cleanup self ref (MR)
• p-m-s/tweaks: Menu toggle (MR)
• p-m-s/tweaks: i18n support (MR)
• p-m-s/tweaks: Use toasts for errors (MR)
• p-m-s/run: Add gdb invocation (MR)
• p-m-s: Appinfo tweaks (MR)
• p-m-s: Hide Config tweaks menu entry when not needed (MR)
• m-b-p-i provider updates: (MR)
• m-b-p-i emergency number updates: (MR, MR, MR)
• pfs: Switch to gtk-rs 0.10 (MR)
• x-d-p-p: Switch to gtk-rs 0.10 (MR)
• x-d-p-p: Port file chooser portal to Rust (MR)
• phosh: custom lockscreen message (MR)
• libcmatrix: Bump endpoint versions (MR)
• phosh-recipes: Add gnome-software-plugin-flatpak (MR)

Context

• See hibernate-pocket, hibernate-pocket-2, hibernate-pocket-3, hibernate-pocket-4,hibernate-pocket-5, hibernate-pocket-6, hibernate-pocket-7, hibernate-pocket-8, hibernate-pocket-9 hibernate-pocket-10 hibernate-pocket-11

Update to latest rockchip-devel For some reason I decided to try re-applying the PCI series. Good news: the pci series finally applies cleanly.

$ git fetch collabora && git switch -c tmp collabora  # [1]
$ b4 am 20250715-pci-port-reset-v6-0-6f9cce94e7bb@oss.qualcomm.com
$ git switch reform-patches  # [2]
$ git rebase -i tmp

1. https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux.git#rockchip-devel
2. https://salsa.debian.org/bremner/collabora-rockchip-3588#reform-patches

Rebuild the kernel

$ cp /boot/config-6.17.0-rc7+ .config
$ make olddefconfig
$ yes ''   make localmodconfig
$ make KBUILD_IMAGE=arch/arm64/boot/Image bindeb-pkg -j$(nproc)

try the hibernation test, again Running the following test script

set -x
echo platform >  /sys/power/pm_test
echo reboot > /sys/power/disk
sleep 2
rmmod mt76x2u
sleep 2
echo disk >  /sys/power/state
sleep 2
modprobe mt76x2u

Initially there is some output like this

[  151.752683] rockchip-dw-pcie a40c00000.pcie: Failed to receive PME_TO_Ack
[  151.754035] PM: hibernation: hibernation debug: Waiting for 5 second(s).
[  157.821584] rockchip-dw-pcie a40c00000.pcie: Phy link never came up
[  157.822139] rockchip-dw-pcie a40c00000.pcie: fail to resume
[  157.822636] rockchip-dw-pcie a40c00000.pcie: PM: dpm_run_callback(): genpd_restore_noirq returns -110
[  157.823442] rockchip-dw-pcie a40c00000.pcie: PM: failed to restore noirq: error -110

A small amount of detective work suggests that a40c00000.pcie corresponds to the first PCI bridge on the rk3588 SOC.

$ ls -l /sys/bus/pci/devices
total 0
lrwxrwxrwx 1 root root 0 Sep 23 10:32 0003:30:00.0 -> ../../../devices/platform/a40c00000.pcie/pci0003:30/0003:30:00.0
lrwxrwxrwx 1 root root 0 Sep 23 10:32 0004:40:00.0 -> ../../../devices/platform/a41000000.pcie/pci0004:40/0004:40:00.0
lrwxrwxrwx 1 root root 0 Sep 23 10:32 0004:41:00.0 -> ../../../devices/platform/a41000000.pcie/pci0004:40/0004:40:00.0/0004:41:00.0

Then after a pause,

[ 1032.039237] watchdog: CPU5: Watchdog detected hard LOCKUP on cpu 6
[ 1032.039778] Modules linked in: xt_CHECKSUM xt_tcpudp nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat x_tables bridge stp llc nf_tables aes_neon_bs aes_neon_blk ccm dwmac_rk binfmt_misc mt76x2_common mt76x02_usb mt76_usb mt76x02_lib mt76 rk805_pwrkey snd_soc_tlv320aic31xx snd_soc_simple_card mac80211 rockchip_saradc reform2_lpc(OE) industrialio_triggered_buffer libarc4 kfifo_buf cfg80211 industrialio rockchip_thermal rockchip_rng cdc_acm rfkill snd_soc_rockchip_i2s_tdm hantro_vpu rockchip_rga panthor v4l2_vp9 v4l2_jpeg snd_soc_audio_graph_card videobuf2_dma_sg v4l2_h264 drm_gpuvm snd_soc_simple_card_utils drm_exec evdev joydev dm_mod nvme_fabrics efi_pstore configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic xor xor_neon raid6_pq mali_dp snd_soc_meson_axg_toddr snd_soc_meson_axg_fifo snd_soc_meson_codec_glue panfrost drm_shmem_helper gpu_sched ao_cec_g12a meson_vdec(C) videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videodev
[ 1032.039834]  videobuf2_common mc dw_hdmi_i2s_audio meson_drm meson_canvas meson_dw_mipi_dsi meson_dw_hdmi mxsfb mux_mmio panel_edp imx_dcss ti_sn65dsi86 nwl_dsi mux_core pwm_imx27 hid_generic usbhid hid onboard_usb_dev nvme nvme_core nvme_keyring nvme_auth snd_soc_hdmi_codec snd_soc_core xhci_plat_hcd xhci_hcd snd_pcm_dmaengine snd_pcm snd_timer snd soundcore rtc_pcf8523 fan53555 micrel phy_package stmmac_platform stmmac pcs_xpcs phylink mdio_devres rk808_regulator of_mdio sdhci_of_dwcmshc fixed_phy sdhci_pltfm fwnode_mdio libphy sdhci phy_rockchip_usbdp dw_mmc_rockchip dw_mmc_pltfm typec phy_rockchip_naneng_combphy pwm_rockchip dw_wdt phy_rockchip_samsung_hdptx dwc3 cqhci dw_mmc mdio_bus rockchip_dfi ehci_platform rockchipdrm ulpi ehci_hcd dw_hdmi_qp ohci_platform udc_core ohci_hcd analogix_dp dw_mipi_dsi i2c_rk3x cpufreq_dt usbcore phy_rockchip_inno_usb2 dw_mipi_dsi2 drm_dp_aux_bus usb_common [last unloaded: mt76x2u]
[ 1032.039886] Sending NMI from CPU 5 to CPUs 6:

previous episode

1. You can use a traditional display and keyboard just long enough to input the kernel parameters described above
2. You can edit the bootloader configuration on the installer s filesystem prior to booting from it

serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1
terminal_input console serial
terminal_output console serial

[Service]
ExecStart=
ExecStart=-/sbin/agetty --wait-cr -8 -h -L=always %I 57600 vt510

• wait-cr means to wait for the user to press Return at the terminal before attempting to display the login prompt
• -8 tells it to assume 8-bit mode on the serial line
• -h enables hardware flow control
• -L=always enables local line mode, disabling monitoring of modem control lines
• %I substitutes the name of the port from systemd
• 57600 gives the desired speed, and vt510 gives the desired setting for the TERM environment variable

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1"

en_US ISO-8859-1
en_US.IBM437 IBM437
en_US.UTF-8 UTF-8 

if [  tty  = "/dev/ttyS0" -o "$TERM" = "vt510" ]; then
        stty -iutf8
        # might add ixon ixoff
        export LANG=en_US
        export MANOPT="-E ascii"
        stty rows 25
fi
if [ "$TERM" = "screen" -o "$TERM" = "vt100" ]; then
    export LANG=en_US.utf8
fi

defencoding UTF-8
startup_message off
vbell off
termcapinfo * XC=B%, -,
maptimeout 5
bindkey -k ku stuff ^[OA
bindkey -k kd stuff ^[OB
bindkey -k kr stuff ^[OC
bindkey -k kl stuff ^[OD

make install-build-deps

$ git clone https://salsa.debian.org/cloud-team/debian-vagrant-images.git

$ make install-build-deps

$ make help
To run this makefile, run:
   make <DIST>-<CLOUD>-<ARCH>
  WHERE <DIST> is bullseye, buster, stretch, sid or testing
    And <CLOUD> is azure, ec2, gce, generic, genericcloud, nocloud, vagrant, vagrantcontrib
    And <ARCH> is amd64, arm64, ppc64el
Set DESTDIR= to write images to given directory.
$ make trixie-vagrant-amd64
umask 022; \
./bin/debian-cloud-images build \
  trixie vagrant amd64 \
  --build-id vagrant-cloud-images-master \
  --build-type official
usage: debian-cloud-images build
debian-cloud-images build: error: argument RELEASE: invalid value: trixie
make: *** [Makefile:22: trixie-vagrant-amd64] Error 2

$ git clone https://salsa.debian.org/debian/debian-vagrant-images.git
Cloning into &aposdebian-vagrant-images&apos...
remote: Enumerating objects: 5310, done.
remote: Counting objects: 100% (256/256), done.
remote: Compressing objects: 100% (96/96), done.
remote: Total 5310 (delta 141), reused 241 (delta 135), pack-reused 5054 (from 1)
Receiving objects: 100% (5310/5310), 629.81 KiB   548.00 KiB/s, done.
Resolving deltas: 100% (2875/2875), done.
$ cd debian-vagrant-images/
$ git checkout 8975eb0 #the commit id of MR 

$ make help
To run this makefile, run:
   make <DIST>-<CLOUD>-<ARCH>
  WHERE <DIST> is bullseye, buster, stretch, sid or testing
    And <CLOUD> is azure, ec2, gce, generic, genericcloud, nocloud, vagrant, vagrantcontrib
    And <ARCH> is amd64, arm64, ppc64el
Set DESTDIR= to write images to given directory.
$ make trixie-vagrant-amd64
umask 022; \
./bin/debian-cloud-images build \
  trixie vagrant amd64 \
  --build-id vagrant-cloud-images-master \
  --build-type official
2025-09-17 00:36:25,919 INFO Adding class DEBIAN
2025-09-17 00:36:25,919 INFO Adding class CLOUD
2025-09-17 00:36:25,919 INFO Adding class TRIXIE
2025-09-17 00:36:25,920 INFO Adding class VAGRANT
2025-09-17 00:36:25,920 INFO Adding class AMD64
2025-09-17 00:36:25,920 INFO Adding class LINUX_IMAGE_BASE
2025-09-17 00:36:25,920 INFO Adding class GRUB_PC
2025-09-17 00:36:25,920 INFO Adding class LAST
2025-09-17 00:36:25,921 INFO Running FAI: sudo env PYTHONPATH=/home/rajudev/dev/salsa/michael/debian-vagrant-images/src/debian_cloud_images/build/../.. CLOUD_BUILD_DATA=/home/rajudev/dev/salsa/michael/debian-vagrant-images/src/debian_cloud_images/data CLOUD_BUILD_INFO= "type": "official", "release": "trixie", "release_id": "13", "release_baseid": "13", "vendor": "vagrant", "arch": "amd64", "build_id": "vagrant-cloud-images-master", "version": "20250917-1"  CLOUD_BUILD_NAME=debian-trixie-vagrant-amd64-official-20250917-1 CLOUD_BUILD_OUTPUT_DIR=/home/rajudev/dev/salsa/michael/debian-vagrant-images CLOUD_RELEASE_ID=vagrant CLOUD_RELEASE_VERSION=20250917-1 fai-diskimage --verbose --hostname debian --class DEBIAN,CLOUD,TRIXIE,VAGRANT,AMD64,LINUX_IMAGE_BASE,GRUB_PC,LAST --size 100G --cspace /home/rajudev/dev/salsa/michael/debian-vagrant-images/src/debian_cloud_images/build/fai_config debian-trixie-vagrant-amd64-official-20250917-1.raw
..... continued

• The console is a different size on every screen both in terms of size of letters and the dimensions of it
• If a given machine has more than one display, one or both of them will have parts of the console chopped off
• My system seems to run with three different resolutions or fonts at different points of the boot process. One during the initrd, and two different ones during the remaining boot.

• Introduction and some stats
• Recent UI/UX improvements
• Why we are still in beta
  • Retrying on Salsa-side failures
• Other notable ongoing work
• Common problems
  • Reuse of version numbers, and attempts to re-tag
  • Discrepancies between git and orig tarballs
• Get involved

1. Separate application-specific users with granular permissions allowing only necessary access and no more.
2. Distributing and storing passwords and credentials securely
3. Ensuring all remote connections are properly encrypted

How encrypting database connections with TLS differs from web server HTTP(S) Even though MariaDB (and other databases) use the same SSL/TLS protocol for encrypting remote connections as web servers and HTTPS, the way it is implemented is significantly different, and the different security assumptions are important for a database administrator to grasp. Firstly, most HTTP requests to a web server are unauthenticated, meaning the web server serves public web pages and does not require users to log in. Traditionally, when a user logs in over a HTTP connection, the username and password were transmitted in plaintext as a HTTP POST request. Modern TLS, which was previously called SSL, does not change how HTTP works but simply encapsulates it. When using HTTPS, a web browser and a web server will start an encrypted TLS connection as the very first thing, and only once established, do they send HTTP requests and responses inside it. There are no passwords or other shared secrets needed to form the TLS connection. Instead, the web server relies on a trusted third party, a Certificate Authority (CA), to vet that the TLS certificate offered by the web server can be trusted by the web browser. For a database server like MariaDB, the situation is quite different. All users need to first authenticate and log in to the server before getting being allowed to run any SQL and getting any data out of the server. The database server and client programs have built-in authentication methods, and passwords are not, and have never been, sent in plaintext. Over the years, MySQL and its successor, MariaDB, have had multiple password authentication methods: the original SHA-1-based hashing, later double SHA-1-based mysql_native_password, followed by sha256_password and caching_sha256_password in MySQL and ed25519 in MariaDB. The MariaDB.org blog post by Sergei Golubchik recaps the history of these well. Even though most modern MariaDB installations should be using TLS to encrypt all remote connections in 2025, having the authentication method be as secure as possible still matters, because authentication is done before the TLS connection is fully established. To further harden the authentication agains man-in-the-middle attacks, a new password the authentication method PARSEC was introduced in MariaDB 11.8, which builds upon the previous ed25519 public-key-based verification (similar to how modern SSH does), and also combines key derivation with PBKDF2 with hash functions (SHA512,SHA256) and a high iteration count. At first it may seem like a disadvantage to not wrap all connections in a TLS tunnel like HTTPS does, but actually not having the authentication done in a MitM resistant way regardless of the connection encryption status allows a clever extra capability that is now available in MariaDB: as the database server and client already have a shared secret that is being used by the server to authenticate the user, it can also be used by the client to validate the server s TLS certificate and no third parties like CAs or root certificates are needed. MariaDB 11.8 was the first LTS version to ship with this capability for zero-configuration TLS. Note that the zero-configuration TLS also works on older password authentication methods and does not require users to have PARSEC enabled. As PARSEC is not yet the default authentication method in MariaDB, it is recommended to enable it in installations that use zero-configuration TLS encryption to maximize the security of the TLS certificate validation.

Why the root user in MariaDB has no password and how it makes the database more secure Relying on passwords for security is problematic, as there is always a risk that they could leak, and a malicious user could access the system using the leaked password. It is unfortunately far too common for database passwords to be stored in plaintext in configuration files that are accidentally committed into version control and published on GitHub and similar platforms. Every application or administrative password that exists should be tracked to ensure only people who need it know it, and rotated at regular intervals to ensure old employees etc won t be able to use old passwords. This password management is complex and error-prone. Replacing passwords with other authentication methods is always advisable when possible. On a database server, whoever installed the database by running e.g. apt install mariadb-server, and configured it with e.g. nano /etc/mysql/mariadb.cnf, already has full root access to the operating system, and asking them for a password to access the MariaDB database shell is moot, since they could circumvent any checks by directly accessing the files on the system anyway. Therefore, MariaDB, since version 10.4 stopped requiring the root user to enter a password when connecting locally, and instead checks using socket authentication whether the user is the operating-system root user or equivalent (e.g. running sudo). This is an elegant way to get rid of a password that was actually unnecessary to begin with. As there is no root password anymore, the risk of an external user accessing the database as root with a leaked password is fully eliminated. Note that socket authentication only works for local connections on the same server. If you want to access a MariaDB server remotely as the root user, you would need to configure a password for it first. This is not generally recommended, as explained in the next section.

Create separate database users for normal use and keep root for administrative use only Out of the box a MariaDB installation is already secure by default, and only the local root user can connect to it. This account is intended for administrative use only, and for regular daily use you should create separate database users with access limited to the databases they need and the permissions required. The most typical commands needed to create a new database for an app and a user the app can use to connect to the database would be the following:

sql Copy

CREATE DATABASE app_db; CREATE USER 'app_user'@'%' IDENTIFIED BY 'your_secure_password'; GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'%'; FLUSH PRIVILEGES;

CREATE DATABASE app_db;
CREATE USER 'app_user'@'%' IDENTIFIED BY 'your_secure_password';
GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

Alternatively, if you want to use the parsec authentication method, run this to create the user:

sql Copy

CREATE OR REPLACE USER 'app_user'@'%' IDENTIFIED VIA parsec USING PASSWORD('your_secure_password');

CREATE OR REPLACE USER 'app_user'@'%'
 IDENTIFIED VIA parsec
 USING PASSWORD('your_secure_password');

Note that the plugin auth_parsec is not enabled by default. If you see the error message ERROR 1524 (HY000): Plugin 'parsec' is not loaded fix this by running INSTALL SONAME 'auth_parsec';. In the CREATE USER statements, the @'%' means that the user is allowed to connect from any host. This needs to be defined, as MariaDB always checks permissions based on both the username and the remote IP address or hostname of the user, combined with the authentication method. Note that it is possible to have multiple user@remote combinations, and they can have different authentication methods. A user could, for example, be allowed to log in locally using the socket authentication and over the network using a password. If you are running a custom application and you know exactly what permissions are sufficient for the database users, replace the ALL PRIVILEGES with a subset of privileges listed in the MariaDB documentation. For new permissions to take effect, restart the database or run FLUSH PRIVILEGES.

Allow MariaDB to accept remote connections and enforce TLS Using the above 'app_user'@'%' is not enough on its own to allow remote connections to MariaDB. The MariaDB server also needs to be configured to listen on a network interface to accept remote connections. As MariaDB is secure by default, it only accepts connections from localhost until the administrator updates its configuration. On a typical Debian/Ubuntu system, the recommended way is to drop a new custom config in e.g. /etc/mysql/mariadb.conf.d/99-server-customizations.cnf, with the contents:

Copy

[mariadbd] # Listen for connections from anywhere bind-address = 0.0.0.0 # Only allow TLS encrypted connections require-secure-transport = on

[mariadbd]
# Listen for connections from anywhere
bind-address = 0.0.0.0
# Only allow TLS encrypted connections
require-secure-transport = on

For settings to take effect, restart the server with systemctl restart mariadb. After this, the server will accept connections on any network interface. If the system is using a firewall, the port 3306 would additionally need to be allow-listed. To confirm that the settings took effect, run e.g. mariadb -e "SHOW VARIABLES LIKE 'bind_address';" , which should now show 0.0.0.0. When allowing remote connections, it is important to also always define require-secure-transport = on to enforce that only TLS-encrypted connections are allowed. If the server is running MariaDB 11.8 and the clients are also MariaDB 11.8 or newer, no additional configuration is needed thanks to MariaDB automatically providing TLS certificates and appropriate certificate validation in recent versions. On older long-term-supported versions of the MariaDB server one would have had to manually create the certificates and configure the ssl_key, ssl_cert and ssl_ca values on the server, and distribute the certificate to the clients as well, which was cumbersome, so good it is not required anymore. In MariaDB 11.8 the only additional related config that might still be worth setting is tls_version = TLSv1.3 to ensure only the latest TLS protocol version is used. Finally, test connections to ensure they work and to confirm that TLS is used by running e.g.:

shell Copy

mariadb --user=app_user --password=your_secure_password \ --host=192.168.1.66 -e '\s'

mariadb --user=app_user --password=your_secure_password \
 --host=192.168.1.66 -e '\s'

The result should show something along:

Copy

-------------- mariadb from 11.8.3-MariaDB, client 15.2 for debian-linux-gnu (x86_64) ... Current user: app_user@192.168.1.66 SSL: Cipher in use is TLS_AES_256_GCM_SHA384, cert is OK ...

--------------
mariadb from 11.8.3-MariaDB, client 15.2 for debian-linux-gnu (x86_64)
...
Current user: app_user@192.168.1.66
SSL: Cipher in use is TLS_AES_256_GCM_SHA384, cert is OK
...

If running a Debian/Ubuntu system, see the bundled README with zcat /usr/share/doc/mariadb-server/README.Debian.gz to read more configuration tips.

Should TLS encryption be used also on internal networks? If a database server and app are running on the same private network, the chances that the connection gets eavesdropped on or man-in-the-middle attacked by a malicious user are low. However, it is not zero, and if it happens, it can be difficult to detect or prove that it didn t happen. The benefit of using end-to-end encryption is that both the database server and the client can validate the certificates and keys used, log it, and later have logs audited to prove that connections were indeed encrypted and show how they were encrypted. If all the computers on an internal network already have centralized user account management and centralized log collection that includes all database sessions, reusing existing SSH connections, SOCKS proxies, dedicated HTTPS tunnels, point-to-point VPNs, or similar solutions might also be a practical option. Note that the zero-configuration TLS only works with password validation methods. This means that systems configured to use PAM or Kerberos/GSSAPI can t use it, but again those systems are typically part of a centrally configured network anyway and are likely to have certificate authorities and key distribution or network encryption facilities already set up. In a typical software app stac however, the simplest solution is often the best and I recommend DBAs use the end-to-end TLS encryption in MariaDB 11.8 in most cases. Hopefully with these tips you can enjoy having your MariaDB deployments both simpler and more secure than before!

Please consider supporting my work in Debian and elsewhere through Liberapay. Debian stable updates work through three main channels: point releases, security repositories, and the updates repository. Understanding these ensures your system stays secure and current.

A note about suite names Every Debian release, or suite, has a codename the most recent major release was trixie, or Debian 13. The codename uniquely identifies that suite. We also use changeable aliases to add meaning to the suite s lifecycle. For example, trixie currently has the alias stable, but when forky becomes stable instead, trixie will become known as oldstable. This post uses either codenames or aliases depending on context. In source lists, codenames are generally preferred since that avoids surprise major upgrades right after a release is made.

The stable suites (point releases) stable and oldstable (currently trixie and bookworm) are only updated during a point release. This is a minor update released to a major version. For example, 13.1 is the first minor update to trixie. It s not possible to install older minor versions of a suite except via the snapshots mechanism (not covered here). It s possible to view past versions via snapshot.debian.org, which preserves historical Debian archives. There are also the testing and unstable aliases for the development suites. However, these are not relevant for users who want to run officially released versions. Almost every stable installation of Debian will be opted into a stable or oldstable base suite. An example APT source might look like:

Type: deb
URIs: http://deb.debian.org/debian
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Or, in legacy sources.list style:

deb https://deb.debian.org/debian trixie main

The security suites (DSAs explained) For urgent security-related updates, the Security Team maintains a counterpart suite for each stable suite. These are called stable-security and oldstable-security when maintained by Debian s security team, and oldstable-security, oldoldstable-security, etc when maintained by the LTS team. Example APT source:

Type: deb
URIs: https://deb.debian.org/debian-security
Suites: trixie-security
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Or, in legacy sources.list style:

deb https://deb.debian.org/debian-security trixie-security main

The Debian installer enables the security suites by default. Debian Security Announcements (DSAs) are published to debian-security-announce@lists.debian.org.

The updates suites (SUAs and maintenance) For urgent non-security updates, the final recommended suites are stable-updates and oldstable-updates. This is where updates staged for a point release, but needed sooner, are published. Examples include virus database updates, timezone changes, urgent bug fixes for specific problems and corrections to errors in the release process itself. Example APT source:

Type: deb
URIs: https://deb.debian.org/debian
Suites: trixie-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Or, in legacy sources.list style:

deb https://deb.debian.org/debian trixie-updates main

Debian enables the updates suites by default. Stable Update Announcements (SUAs) are published to debian-stable-announce@lists.debian.org. This is also where announcements of forthcoming point releases are published.

Summary These are the recommended suites for all production Debian systems:

Suite	Example codename	Purpose	Announcements
stable	trixie	Base suite containing all the available software for a release. Point releases every 2 4 months including lower-severity security fixes that do not require immediate release.	Debian Release Announcements on debian-announce
stable-security	trixie-security	Urgent security updates.	Debian Security Announcements on debian-security-announce
stable-updates	trixie-updates	Urgent non-security updates, data updates and release maintenance.	Stable Update Announcements on debian-stable-announce

After a release moves from oldstable to unsupported status, Long Term Support (LTS) takes over for several more years. LTS provides urgent security updates for selected architectures. For details, see wiki.debian.org/LTS. If you d like to stay informed, the official Debian announcement lists and release.debian.org share the latest schedules and updates.

---

Photo by Brian Wangenheim on Unsplash

Debian Contributions: 2025-08 Contributing to Debian is part of Freexian s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

Preparing for setup.py install deprecation, by Colin Watson setuptools upstream will be removing the setup.py install command on 31 October. While this may not trickle down immediately into Debian, it does mean that in the near future nearly all Python packages will have to use pybuild-plugin-pyproject (though they don t necessarily have to use pyproject.toml; this is just a question of how the packaging runs the build system). Some of the Python team talked about this a bit at DebConf, and Colin volunteered to write up some notes on cases where this isn t straightforward. This page will likely grow as the team works on this problem.

Salsa CI, by Santiago Ruano Rinc n Santiago fixed some pending issues in the MR that moves the pipeline to sbuild+unshare, and after several months, Santiago was able to mark the MR as ready. Part of the recent fixes include handling external repositories, honoring the RELEASE autodetection from d/changelog (thanks to Ahmed Siam for spotting the main reason of the issue), and fixing a regression about the apt resolver for *-backports releases. Santiago is currently waiting for a final review and approval from other members of the Salsa CI team, and being able to merge it. Thanks to all the folks who have helped testing the changes or provided feedback so far. If you want to test the current MR, you need to include the following pipeline definition in your project s CI config file:

---
include:
  - https://salsa.debian.org/santiago/pipeline/raw/sbuild-unshare-02-salsa-ci/salsa-ci.yml
  - https://salsa.debian.org/santiago/pipeline/raw/sbuild-unshare-02-salsa-ci/pipeline-jobs.yml

As a reminder, this MR will make the Salsa CI pipeline build the packages more similar to how it s built by the Debian official builders. This will also save some resources, since the default pipeline will have one stage less (the provisioning) stage, and will make it possible for more projects to be built on salsa.debian.org (including large projects and those from the OCaml ecosystem), etc. See the different issues being fixed in the MR description.

Debian 13 trixie release, by Emilio Pozuelo Monfort On August 9th, Debian 13 trixie was released, building on two years worth of updates and bug fixes from hundreds of developers. Emilio helped coordinate the release, communicating with several teams involved in the process.

DebConf 26 Site Visit, by Stefano Rivera Stefano visited Santa Fe, Argentina, the site for DebConf 26 next year. The aim of the visit was to help build a local team and see the conference venue first-hand. Stefano and Nattie represented the DebConf Committee. The local team organized Debian meetups in Buenos Aires and Santa Fe, where Stefano presented a talk on Debian and DebConf. Venues were scouted and the team met with the university management and local authorities.

Miscellaneous contributions

• Rapha l updated tracker.debian.org after the trixie release to add the new forky release in the set of monitored distributions. He also reviewed and deployed the work of Scott Talbert showing open merge requests from salsa in the action needed panel.
• Rapha l reviewed some DEP-3 changes to modernize the embedded examples in light of the broad git adoption.
• Rapha l configured new workflows on debusine.debian.net to upload to trixie and trixie-security, and officially announced the service on debian-devel-announce, inviting Debian developers to try the service for their next upload to unstable.
• Carles created a merge request for django-compressor upstream to fix an error when concurrent node processing happened. This will allow removing a workaround added in openstack-dashboard and avoid the same bug in other projects that use django-compressor.
• Carles prepared a system to detect packages that Recommends packages which don t exist in unstable. Processed (either reported or ignored due to mis-detected problems or temporary problems) 16% of the reports. Will continue next month.
• Carles got familiar and gave feedback for the freedict-wikdict package. Planned contributions with the maintainer to improve the package.
• Helmut responded to queries related to /usr-move.
• Helmut adapted crossqa.d.n to the release of trixie .
• Helmut diagnosed sufficient failures in rebootstrap to make it work with gcc-15.
• Helmut fixed the CI pipeline of debvm.
• Helmut sent patches for 19 cross build problems.
• Faidon discovered that the Multi-Arch hinter would emit confusing hints about :any annotations. Helmut identified the root cause to be the handling of virtual packages and fixed it.
• Enrico took some dust off python-debiancontributors and prototyped a receiving end for salsa webpings, to start followup work to contributors.debian.org discussions at DebConf25.
• Colin upgraded about 70 Python packages to new upstream versions, which is around 10% of the backlog; this included a complicated Pydantic upgrade in collaboration with the Rust team.
• Colin fixed a bug in debbugs that caused incoming emails to bugs.debian.org with certain header contents to go missing.
• Thorsten uploaded sane-airscan, which was already in experimental, to unstable.
• Thorsten created a script to automate the upload of new upstream versions of foomatic-db. The database contains information about printers and regularly gets an update. Now it is possible to keep the package more up to date in Debian.
• Stefano prepared updates to almost all of his packages that had new versions waiting to upload to unstable. (beautifulsoup4, hatch-vcs, mkdocs-macros-plugin, pypy3, python-authlib, python-cffi, python-mitogen, python-pip, python-pipx, python-progress, python-truststore, python-virtualenv, re2, snowball, soupsieve).
• Stefano uploaded two new python3.13 point releases to unstable.
• Stefano updated distro-info-data in stable releases, to document the trixie release and expected EoL dates.
• Stefano did some debian.social sysadmin work (keeping up quotas with growing databases and filesystems).
• Stefano supported the Debian treasurers in processing some of the DebConf 25 reimbursements.
• Lucas uploaded ruby3.4 to experimental. It was already approved by FTP masters.
• Lucas uploaded ruby-defaults to experimental to add support for ruby3.4. It will allow us to start triggering test rebuilds and catch any FTBFS with ruby3.4.
• Lucas did some administrative work for Google Summer of Code (GSoC) and replied to some queries from mentors and students.
• Anupa helped to organize release parties for Debian 13 and Debian Day events.
• Anupa did the live coverage for the Debian 13 release and prepared the Bits post for the release announcement and 32nd Debian Day as part of the Debian Publicity team.
• Anupa attended a Debian Day event organized by FOSS club SSET as a speaker.

1. The checksums for every block help detect potential silent data corruption
2. Instant snapshots make consistent backups of live systems a lot easier, and without the hassle and wasted space of LVM snapshots
3. Transparent compression and dedup can save a lot of space in storage-constrained environments

Welcome to the August 2025 report from the Reproducible Builds project! Welcome to the latest report from the Reproducible Builds project for August 2025. These monthly reports outline what we ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. If you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website. In this report:

1. Reproducible Builds Summit 2025
2. Reproducible Builds and live-bootstrap at WHY2025
3. DALEQ Explainable Equivalence for Java Bytecode
4. Reproducibility regression identifies issue with AppArmor security policies
5. Rust toolchain fixes
6. Distribution work
7. diffoscope
8. Website updates
9. Reproducibility testing framework
10. Upstream patches

Reproducible Builds Summit 2025 Please join us at the upcoming Reproducible Builds Summit, set to take place from October 28th 30th 2025 in Vienna, Austria!** We are thrilled to host the eighth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin, Hamburg and Athens. Our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving. If you re interesting in joining us this year, please make sure to read the event page which has more details about the event and location. Registration is open until 20th September 2025, and we are very much looking forward to seeing many readers of these reports there!

Reproducible Builds and live-bootstrap at WHY2025 WHY2025 (What Hackers Yearn) is a nonprofit outdoors hacker camp that takes place in Geestmerambacht in the Netherlands (approximately 40km north of Amsterdam). The event is organised for and by volunteers from the worldwide hacker community, and knowledge sharing, technological advancement, experimentation, connecting with your hacker peers, forging friendships and hacking are at the core of this event . At this year s event, Frans Faase gave a talk on live-bootstrap, an attempt to provide a reproducible, automatic, complete end-to-end bootstrap from a minimal number of binary seeds to a supported fully functioning operating system . Frans talk is available to watch on video and his slides are available as well.

DALEQ Explainable Equivalence for Java Bytecode Jens Dietrich of the Victoria University of Wellington, New Zealand and Behnaz Hassanshahi of Oracle Labs, Australia published an article this month entitled DALEQ Explainable Equivalence for Java Bytecode which explores the options and difficulties when Java binaries are not identical despite being from the same sources, and what avenues are available for proving equivalence despite the lack of bitwise correlation:

[Java] binaries are often not bitwise identical; however, in most cases, the differences can be attributed to variations in the build environment, and the binaries can still be considered equivalent. Establishing such equivalence, however, is a labor-intensive and error-prone process.

Jens and Behnaz therefore propose a tool called DALEQ, which:

disassembles Java byte code into a relational database, and can normalise this database by applying Datalog rules. Those databases can then be used to infer equivalence between two classes. Notably, equivalence statements are accompanied with Datalog proofs recording the normalisation process. We demonstrate the impact of DALEQ in an industrial context through a large-scale evaluation involving 2,714 pairs of jars, comprising 265,690 class pairs. In this evaluation, DALEQ is compared to two existing bytecode transformation tools. Our findings reveal a significant reduction in the manual effort required to assess non-bitwise equivalent artifacts, which would otherwise demand intensive human inspection. Furthermore, the results show that DALEQ outperforms existing tools by identifying more artifacts rebuilt from the same code as equivalent, even when no behavioral differences are present.

Jens also posted this news to our mailing list.

Reproducibility regression identifies issue with AppArmor security policies Tails developer intrigeri has tracked and followed a reproducibility regression in the generation of AppArmor policy caches, and has identified an issue with the 4.1.0 version of AppArmor. Although initially tracked on the Tails issue tracker, intrigeri filed an issue on the upstream bug tracker. AppArmor developer John Johansen replied, confirming that they can reproduce the issue and went to work on a draft patch. Through this, John revealed that it was caused by an actual underlying security bug in AppArmor that is to say, it resulted in permissions not (always) matching what the policy intends and, crucially, not merely a cache reproducibility issue. Work on the fix is ongoing at time of writing.

Rust toolchain fixes Rust Clippy is a linting tool for the Rust programming language. It provides a collection of lints (rules) designed to identify common mistakes, stylistic issues, potential performance problems and unidiomatic code patterns in Rust projects. This month, however, Sosth ne Gu don filed a new issue in the GitHub requesting a new check that would lint against non deterministic operations in proc-macros, such as iterating over a HashMap .

Distribution work In Debian this month:

• Holger made extensive updates to Debian package reproducibility testing infrastructure this month, including:
  • Upgrading all of the nodes to Debian trixie.
  • Adding tests for the new Debian forky release.
  • Dropping tests for Debian bookworm.
  • Dropping support for the armhf architecture. From July 2015, Vagrant Cascadian has been hosting a zoo of approximately 35 armhf systems which were used for building Debian packages for that architecture.
• Holger Levsen also uploaded strip-nondeterminism, our program that improves reproducibility by stripping out non-deterministic information such as timestamps or other elements introduced during packaging. This new version, 1.14.2-1, adds some metadata to aid the deputy tool. ( #1111947)
• 8 reviews of Debian packages were added, 5 were updated and 5 were removed this month adding to our knowledge about identified issues.
• Marc Haber posted to our mailing list this month asking for assistance with the duperemove package in Debian, which appears to be an issue where the order the object files are linked together is dependent on the underlying filesystem . Chris Lamb provided a detailed analysis, including a suggestion that this can be resolved by adding a locale-agnostic sort.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their work there.

diffoscope diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions, 303, 304 and 305 to Debian:

• Improvements:
  • Use sed(1) backreferences when generating debian/tests/control to avoid duplicating ourselves. [ ]
  • Move from a mono-utils dependency to versioned mono-devel mono-utils dependency, taking care to maintain the [!riscv64] architecture restriction. [ ]
  • Use sed over awk to avoid mangling dependency lines containing = (equals) symbols such as version restrictions. [ ]
• Bug fixes:
  • Fix a test after the upload of systemd-ukify version 258~rc3. [ ]
  • Ensure that Java class files are named .class on the filesystem before passing them to javap(1). [ ]
  • Do not run jsondiff on files over 100KiB as the algorithm runs in O(n^2) time. [ ]
  • Don t check for PyPDF version 3 specifically; check for >= 3. [ ]
• Misc:
  • Update copyright years. [ ][ ]

In addition, Martin Joerg fixed an issue with the HTML presenter to avoid crash when page limit is None [ ] and Zbigniew J drzejewski-Szmek fixed compatibility with RPM 6 [ ]. Lastly, John Sirois fixed a missing requests dependency in the trydiffoscope tool. [ ]

Website updates Once again, there were a number of improvements made to our website this month including:

• Chris Lamb:
  • Write and publish a news entry for the upcoming summit. [ ]
  • Add some assets used at FOSSY, such as the badges and the paper handouts. [ ]
• Holger Levsen:
  • Restructure the new project history pages pages [ ] and add some recent news entries [ ].
  • Mark the OpenWrt tests as disabled on the Who is Involved. [ ]
  • Various changes to the upcoming Reproducible Builds Summit page. [ ]
• Jochen Sprickerhof made various improvements to the Vienna summit page. [ ][ ]
• Mattia Rizzolo also made various improvements to the Vienna summit page. [ ][ ][ ][ ][ ][ ][ ]
• kpcyrd made a number of changes to the new project history pages [ ][ ]

Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In August, however, a number of changes were made by Holger Levsen, including:

• reproduce.debian.net-related:
  • Run 4 workers on the o4 node again in order to speed up testing. [ ][ ][ ][ ]
  • Also test trixie-proposed-updates and trixie-updates etc. [ ][ ]
  • Gather seperate statistics for each tested release. [ ]
  • Support sources from all Debian suites. [ ]
  • Run new code from the prototype database rework branch for the amd64-pull184 pseudo-architecture. [ ][ ]
  • Add a number of helpful links. [ ][ ][ ][ ][ ][ ][ ][ ][ ]
  • Temporarily call debrebuild without the --cache argument to experiment with a new version of devscripts. [ ][ ][ ]
  • Update public TODO. [ ]
• Installation tests:
  • Add comments to explain structure. [ ]
  • Mark more old jobs as old or dead . [ ][ ][ ]
  • Turn the maintenance job into a no-op. [ ]
• Jenkins node maintenance:
  • Increase penalties if the osuosl5 or ionos7 nodes are down. [ ]
  • Stop trying to fix network automatically. [ ]
  • Correctly mark ppc64el architecture nodes when down. [ ]
  • Upgrade the remaining arm64 nodes to Debian trixie in anticipation of the release. [ ][ ]
  • Allow higher SSD temperatures on the riscv64 architecture. [ ]
• Debian-related:
  • Drop the armhf architecture; many thanks to Vagrant for physically hosting the nodes for ten years. [ ][ ]
  • Add Debian forky, and archive bullseye. [ ][ ][ ][ ][ ][ ][ ]
  • Document the filesystem space savings from dropping the armhf architecture. [ ]
  • Exclude i386 and armhfr from JSON results. [ ]
  • Update TODOs for when Debian trixie and forky have been released. [ ][ ]
• tests.reproducible-builds.org-related:
  • Add a link to reproduce.debian.net. [ ]
  • Improve the dashboard graphs. [ ][ ][ ]
• Misc:
  • Detect errors with openQA erroring out. [ ]
  • Drop the long-disabled openwrt_rebuilder jobs. [ ]
  • Use qa-jenkins-dev@alioth-lists.debian.net as the contact for jenkins.debian.net. [ ]
  • Redirect reproducible-builds.org/vienna25 to reproducible-builds.org/vienna2025. [ ]
  • Disable all OpenWrt reproducible CI jobs, in coordination with the OpenWrt community. [ ][ ]
  • Make reproduce.debian.net accessable via IPv6. [ ]
  • Ignore that the megacli RAID controller requires packages from Debian bookworm. [ ]

In addition,

• James Addison migrated away from deprecated toplevel deb822 Python module in favour of debian.deb822 in the bin/reproducible_scheduler.py script [ ] and removed a note on reproduce.debian.net note after the release of Debian trixie [ ].
• Jochen Sprickerhof made a huge number of improvements to the reproduce.debian.net statistics calculation [ ][ ][ ][ ][ ][ ] as well as to the reproduce.debian.net service more generally [ ][ ][ ][ ][ ][ ][ ][ ].
• Mattia Rizzolo performed a lot of work migrating scripts to SQLAlchemy version 2.0 [ ][ ][ ][ ][ ][ ] in addition to making some changes to the way openSUSE reproducibility tests are handled internally. [ ]
• Lastly, Roland Clobus updated the Debian Live packages after the release of Debian trixie. [ ][ ]

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • cpython
  • hashcat
  • neochat
  • pocketbase
• Chris Lamb:
  • #1111497 filed against neon27.
• Jochen Sprickerhof:
  • #1111620 filed against pcbasic.
  • #1111624 filed against shellia.
  • #1111625 filed against bup.
• Mark Johnston:
  • FreeBSD
  • FreeBSD
  • FreeBSD
  • FreeBSD
• Robin Candau:
  • syd

Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Mastodon: @reproducible_builds@fosstodon.org
• Mailing list: rb-general@lists.reproducible-builds.org

 noahm@debian.org
host stravinsky.debian.org [2001:41b8:202:deb::311:108]
SMTP error from remote mail server after end of data:
550-malware detected: Sanesecurity.Phishing.Fake.30934.1.UNOFFICIAL:
550 message rejected
submit@bugs.debian.org
host stravinsky.debian.org [2001:41b8:202:deb::311:108]
SMTP error from remote mail server after end of data:
550-malware detected: Sanesecurity.Phishing.Fake.30934.1.UNOFFICIAL:
550 message rejected

• aioftp
• aiosignal (building on work by IanLucca)
• audioop-lts
• celery
• djangorestframework
• djoser
• fpylll
• frozenlist
• git-repo-updater
• ipykernel
• klepto
• kombu
• multipart
• netmiko (sponsoring work by Eduardo Silva; contributed supporting fix upstream)
• pathos
• ppft
• pydantic
• pydantic-core
• pydantic-settings
• pylsqpack
• pymssql
• pytest-mock
• pytest-pretty
• pytest-repeat
• pytest-rerunfailures
• python-a2wsgi
• python-apptools (sponsoring work by Kathlyn Lara Murussi)
• python-asgiref
• python-asyncssh
• python-bitarray
• python-bitstring
• python-bytecode
• python-channels-redis
• python-charset-normalizer
• python-daphne
• python-django-analytical
• python-django-guid
• python-django-health-check
• python-django-pgbulk
• python-django-pgtrigger
• python-django-postgres-extra
• python-django-storages
• python-holidays
• python-httpx-sse
• python-icalendar
• python-lazy-model
• python-line-profiler
• python-lz4
• python-marshmallow-dataclass
• python-mastodon
• python-model-bakery
• python-oauthlib
• python-parse-type
• python-pathvalidate
• python-pgspecial
• python-processview
• python-pytest-subtests
• python-roman
• python-semantic-release
• python-testfixtures
• python-time-machine
• python-tokenize-rt
• python-typeguard
• python-typing-extensions
• python-urllib3
• pyupgrade
• requests (fixing CVE-2024-47081)
• responses
• zope.deferredimport
• zope.schema
• zope.testrunner

• billiard
• lazr.config
• python-timeline
• zope.sqlalchemy
• zope.testing

• aiosmtplib
• blinker
• ipykernel
• ipyparallel
• quart

• austin: binutils now has a libsframe-dev package, please add an explicit build dependency
• python-django-pgbulk: Missing dependency on python3-typing-extensions (contributed upstream)
• python-maturin: Upcoming rust-which update

• rust-serde
• rust-serde-derive
• rust-serde-json
• rust-smallvec
• rust-speedate
• rust-time
• rust-time-core
• rust-time-macros

• Debian packages:
  • chrony:
    • Bugs:
      • opened #1111222: 099-scfilter system test is flaky
  • debian-policy:
    • Bugs:
      • opened and replied to #1111126: Copyright format does not explain how to describe a license text itself
  • devscripts:
    • Bugs:
      • opened #1112065: uscan: Regression of handling @PACKAGE@ in upstream URL
  • firmware-free:
    • Merge requests:
      • merged !10: Build CIS files and keyspan_pda firmware from source
  • firmware-nonfree:
    • Bugs:
      • closed #920937: firmware-atheros: Firmware QCA6174 crashes on wakeup from suspend
      • closed #934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
      • closed #988335: RTL8125B Failure of key exchange and association
      • closed #1023631: firmware-misc-nonfree: Possibly missing firmware for Creative Labs Sound Blaster Z PCIe sound card
      • closed #1050852: firmware-misc-nonfree: System crashes and reboots when i915/kbl_dmc_ver1_04.bin is present
      • closed #1061430: firmware-realtek: Realtek 10ec:8136 wrongly identified as Fast Ethernet instead of Gigabit
      • closed #1062817: firmware-amd-graphics: Invalid UVD handle causes the graphics driver to crash
      • closed #1085387: iwlwifi: wifi does not work at startup, starts working after 2-3 reboots and then works fine
      • closed #1093167: firmware-nonfree: AMD NPU firmware is not packaged
      • replied to #1105064: firmware-realtek: Please add rtl_bt/rtl8723ds_fw.bin
      • replied to #1109015: Wifi not working anymore with new atheros firmware from experimental
    • Merge requests:
      • opened and merged !126: Refactor build for next upstream version and forky release cycle
      • opened and merged !127: Update to 20250808
    • Uploads:
      • uploaded version 20250808-1 to unstable
  • initramfs-tools:
    • Bugs:
      • closed #1108204: initramfs-tools: update-initramfs trigger does not update the initramfs in some cases
      • closed #1108924: initramfs-tools: Cannot boot Trixie d-i rc2 USB storage target riscv64 MODULES=most (missing: cdns3 cdns3_starfive)
    • Merge requests:
      • reviewed and closed !182: unmkinitramfs: handle both uppercase and lowercase hex numbers
      • merged !183: hook-functions: add modules for non-default checksums on btrfs
      • opened and merged !184: unmkinitramfs: Accept lower-case hex digits in cpio headers
    • Uploads:
      • uploaded version 0.150 to unstable
  • kernel-handbook:
    • Merge requests:
      • closed !7: Add disabling SECURITY_LOCKDOWN_LSM to chapter-common-tasks
      • reviewed and merged !10: chapter-common-tasks: Update linux headers common binary parameter
  • kernel-team:
    • Merge requests:
      • merged !9: Improvements to find-recent-urgent for meeting agenda
  • ktls-utils:
    • Uploads:
      • uploaded version 1.2.1-2 to unstable
      • uploaded version 1.2.1-3 to unstable
  • kup:
    • Uploads:
      • uploaded version 0.3.6-6 to unstable
  • linux:
    • Bugs:
      • closed #1106386: Bluetooth: btusb: Add RTL8851BE device 13d3:3601
      • replied to and closed #1108271: e2fsprogs: orphan_file prevents ro LVM snapshots from being mounted
      • replied to #1110193: r8169 Rx very slow; r8168 works fine
      • closed #1110780: linux-image-6.12.38+deb13-amd64: HID BPF support is not enabled by default
      • replied to #1111455: linux-image-6.12.41+deb13-amd64: kernel BUG at fs/netfs/read_collect.c:316 netfs: Can t donate prior to front
      • opened and closed #1111670: ext4 regression in 6.16.1
    • Merge requests:
      • reviewed !1382: Store build time signing key encrypted
      • closed !1507: Drop yama: Disable by default and use upstream default to restrict ptrace
      • reviewed !1577: [arm64] udeb: Add USB TYPE-C modules for usb-modules. Then enable MT6359_AUXADC and panel KD070FHFID015 for MediaTek devices
      • merged !1588: linux-misc-tools: Fix FTBFS on sparc64
      • merged !1597: [armhf] Add phy-gmii-sel module to nic-shared-modules udeb
      • merged !1598: d/c/defines.toml: Bump abi_suffix to +deb14 for unstable releases and define forky and trixie-backports releases
      • (LTS) opened !1600: Sign modules using an ephemeral key; bump ABI for every upload
      • merged !1601: Enable DRM_NOUVEAU_GSP_DEFAULT for Nvidia
      • reviewed !1602: Backport Store build time signing key encrypted
      • (LTS) opened and merged !1603: Sign modules using an ephemeral key; bump ABI for every upload
      • opened and merged !1613: bootconfig: Fix negative seeks on 32-bit with LFS enabled
      • opened !1615: Draft: Support for drivers in Rust
      • merged !1622: Sign modules and support lockdown always
    • Uploads:
      • uploaded version 6.16.3-1 to unstable
    • (LTS) Added some regression fixes to the bullseye-security branch, but did not upload it
  • (LTS) linux-6.1:
    • Uploads:
      • uploaded version 6.1.147-1~deb11u1 to bullseye-security
  • linux-base:
    • Bugs:
      • replied to #1111052: Please increase default UDP receive buffer size (rmem_max)
    • Uploads:
      • uploaded version 4.14 to unstable
  • wireless-regdb:
    • Uploads:
      • (LTS) uploaded version 2025.07.10-1~deb12u1 to bookworm
• Debian non-package bugs:
  • general:
    • closed #1111472: general: Big issues with ThinkPad s Dual Mouse (Trackpad/Trackpoint) setup
  • installation-reports:
    • replied to #1111507: firmware-realtek-udeb missing rtl8168e-3.fw (needed for d-i)
  • release.debian.org:
    • (LTS) opened #1110340: bookworm-pu: package wireless-regdb/2025.07.10-1~deb12u1
• Mailing lists:
  • debian-devel:
    • replied to How do I fully test a watch file
    • replied to Please check open Merge Requests before your next upload
    • replied to Request to reconsider i386 (x86) port for Debian 13
  • debian-events-eu:
    • posted Debian Day/release party near Leuven, 16 August
  • debian-kernel:
    • replied to Agenda items for kernel-team meeting on 2025-08-06
    • posted Agenda items for kernel-team meeting on 2025-08-27
    • replied to Kernel Handbook - Out of date ABI maintenance info
  • debian-lts-announce:
    • posted [SECURITY] [DLA 4271-1] linux-6.1 security update
  • debian-www:
    • posted Stale copy of Debian Kernel Handbook
  • initramfs:
    • posted initramfs-tools 0.150 release
  • linux-trace-kernel:
    • posted [PATCH] bootconfig: Fix negative seeks on 32-bit with LFS enabled
  • stable:
    • replied to [PATCH 6.12 164/444] bootconfig: Fix unaligned access when building footer

GitLab Salsa: @Spaarsh

GitHub: Spaarsh

Introduction I am Spaarsh Thakkar, a final-year Computer Science Engineering undergrad from India. My interests lie in research and systems. My recent work has been in and around Graphics Processing Units and I also hold a keen interest in Computer Networks. At the time of writing, I have been an open-source contributor for almost a year.

Proposal Description (as shown on GSoC Project Profile¹) Due to Debian s open-source nature, no Debian package in main can have a proprietary GPU package listed as a dependency. While AI and HPC workloads increasingly rely on GPU acceleration, many Debian packages still focus solely on CUDA, which is proprietary. With the advent of ROCm, an open-source GPU computing platform, we can now integrate full-fledged AMD GPU support into Debian packages. This will improve the experience of developers working in AI/ML and HPC while positioning Debian as a strong OS choice for GPU-driven workloads. The proposal aims to aid in solving the aforementioned program by packaging several ROCm packages for debian and add ROCm support to some existing debian packages. The deliverables are as follows:

1. New Debian packages with GPU support
2. Enhanced GPU support within existing Debian packages
3. More autopackagetests running on the Debian ROCm CI

Key Objectives Enable ROCm in:

1. dbcsr
2. gloo
3. cp2k

Publish the following packages to debian apt archive:

1. hipblas-common
2. hipBLASlt

Work Report

1. Publishing hipblas-common to apt This objective was successfully completed, resulting in hipblas-common being published in the apt repository². The process involved the following steps:

1. Filing a Intent-To-Package (ITP)³
2. Pulling the upstream source code repository from GitHub
3. Adding the debian/ packaging files
4. Testing the package locally
5. Creating the corresponding project under rocm-team⁴
6. Applying the necessary changes
7. Building the package
8. Testing it using sbuild
9. Signing the package files
10. Uploading the package to the mentors.debian.net archive(now in official archive)⁵
11. Addressing review feedback and making changes
12. Requesting sponsorship⁶
13. Securing sponsorship, which led to the package being accepted into the experimental branch of apt

Since the beginning of GSoC, the package has also been promoted to the unstable branch².

---

2. DBCSR ROCm and Multi-Arch Support During my GSoC project, I worked on extending the DBCSR (Distributed Block Compressed Sparse Row)⁷ package to improve its ROCm/HIP support, and handling multi-architecture GPU kernels in a way that is both practical for upstream maintainers and debian package developers. The code changes can be found at my dbcsr fork here⁸.

ROCm/HIP Enablement

• Enabled ROCm backend support to DBCSR, allowing GPU acceleration beyond CUDA by enabling HIP-based builds.
• Investigated and resolved build issues specific to HIP kernels within DBCSR.

Multi-Architecture GPU Kernel Handling (The following content was presented in greater detail at DebConf 25 as well. The presentation video can be found here⁹ and the presentation slide can be found here¹⁰).

• DBCSR contains GPU kernels that are heavily optimized for specific architectures. By default, these are built for a single target architecture, which poses challenges for packaging where binaries need to support multiple possible GPU targets.
• Explored different strategies for solving the multi-arch GPU kernel distribution problem, including:
  • Option 1: Fat binaries (embedding multiple GPU architectures into a single binary, with runtime dispatch). This is ideal for end-users but requires deeper changes upstream and is not straightforward with HIP/ROCm.
  • Option 2: Arch-specific libraries (e.g., libdbcsr.gfxXXX.a), where the alternatives system or explicit user selection would determine which one is used. This solves the problem but pushes complexity downstream into packaging and user configuration.
  • Option 3: Prefixed functions inside a single file, where kernels are compiled separately per architecture, functions are renamed with an arch prefix, and runtime logic in DBCSR decides which kernel to invoke. This shifts complexity upstream but could give a clean downstream experience.
• I critically analyzed these options in the context of Debian packaging and upstream maintainability. Arch-specific .a files introduce exponential dependency complexity. The prefixed-function approach seemed like a plausible way forward, though it requires upstream buy-in.
• After consulting with my mentor, these concerns were raised in the dbcsr repository as a discussion here¹¹

Summary My work involved:

• Enabling HIP/ROCm support in DBCSR.
• Prototyping strategies for handling GPU multi-arch builds.
• Evaluating the trade-offs between upstream maintainability and downstream packaging complexity.

---

3. gloo, hipification and source code issues One of the other packages that were targeted was gloo¹². It is a collective communications library and has the implementations of different Machine Learning communication algorithms. The code changes can be found at my gloo fork here¹³ (some changes have not be committed at the time of writing).

HIP/ROCm Enablement

1. Fixing old ROCm CMake functions The upstream Gloo codebase still used old ROCm CMake functions that began with the hip_ prefix (for example, hip_add_executable). These functions have since been deprecated/removed. I updated the build system to use the modern ROCm CMake equivalents so that the package can build properly in a current ROCm environment.
2. Debian packaging changes I modified debian/control to add a new package, libgloo-rocm, in addition to the existing packages. This allows proper separation and handling of ROCm-enabled builds in Debian.
3. First successful library build After these changes, I was able to successfully build the library. However, I ran into issues when trying to produce the shared library: there were undefined symbol errors at link time.

Source Code Issue On investigating the undefined symbol errors, I identified that these came from a lack of explicit template instantiation for some Gloo classes. Since C++ templates only get compiled when explicitly used or instantiated, this resulted in missing symbols in the shared library. To solve this, I explored the source code and noticed that the HIP backend code was not natively written it was generated from the CUDA backend using a custom hipification script maintained by the repo.

• I experimented with modifying the HIPification process itself, trying out hipify-perl¹⁴ instead of the repository s custom Python script.
• I also tried tweaking the source code in places where template instantiations were missing, so that the ROCm build would correctly export the needed symbols.

Summary The issue is still unresolved. The core problem lies in how the source code is structured: the HIP backend is almost entirely auto-generated from CUDA code, and the process does not handle template instantiations correctly. Because of this, the Debian package for Gloo with ROCm support is not yet ready for release, and further source-level fixes are required to make the ROCm build reliable.

---

4. cp2k CP2K¹⁵ is a quantum chemistry and solid state physics software package that can perform atomistic simulations of solid state, liquid, molecular, periodic, material, crystal, and biological systems.

HIP/ROCm Enablement cp2k depends on dbcsr and hence, HIP/ROCm enablement in this package required the dbcsr¹⁶ package to get through. Even though dbcsr isn t ready yet, it was worthwhile to plan how it shall be built with HIP/ROCm once we have dbcsr in place. Upon doing this, it was realized that the architecture-wise libraries provided by the dbcsr package will result in a complicated building process for cp2k. No changes have been made to this package yet and more concrete steps shall be taken once the dbcsr package work is completed.

Summary The multi-arch build process for cp2k maybe complicated by the one static-library-per-architecture method used in the dependent package, dbcsr.

---

Auxiliary Work & Activities While working on the aformentioned GSoC Goals, there were a few other things that were also done.

1. libamdhip64-dev bug file¹⁷ While trying to enable HIP/ROCm in dbcsr, CMakeDetermineHIPCompiler.cmake was unable to find HIP runtime CMake package. After going through some similar issues faced by other developers earlier, it was decided to file a bug report under the libamdhip64-dev package. After discussions with and trying the changes suggested by Cory (my mentor) under the bug, the issue was resolved. Turns out, the wrong compiler was being used by me! The gcc compiler was supposed to be used and I was using hipcc. The bug was closed since it was not due an issue with the package. Cory suggested that I add this info under the ROCm wiki page. It is yet to be done and hopefully I get it done soon.
2. DebConf25 Talk After facing the multi-arch build dilemma with dbcsr (and also getting to know about the issues faced by other fellow package developers), I came to realise that this was more than a packaging, build or programming issue. GPU-packaging was facing a policy issue. Hence, I decided to cover this problem in greater detail at my DebConf25 Virtual Presentation under the Outreach Session. Shoutout to Cory for his support and Lucas Kanashiro for encouraging me to present my work!
3. Bi-Weekly AMD ROCm Meetings Shortly after the Coding period started, Cory began the initiative of Bi-Weekly AMD ROCm Meetings¹⁸. Being a part of the meetings (participated in all but one!), seeing the work the other folks are doing and being able to discuss my own problems was a delight.
4. (Upcoming) IndiaFOSS 2025 Talk After understanding the nuances and beauty of the debian packaging ecosystem in these months, I decided to spread the work about debian packaging and packaging software in general. My talk¹⁹ for the same got accepted in the upcoming IndiaFOSS 2025²⁰ conference! I hope this beings more people towards the packaging ecosystem and to the debian developer ecosystem.

Conclusion My GSoC time was fantastic! I plan to complete the work that I have started during my GSoC and beyond. Working with Cory²¹ and Utkarsh²² (a fellow GSoC 25 contributor under Cory) has been a very positive experience. HIP/ROCm GPU-packaging is in a nascent stage. It is an exciting time to be in this space right now. The problems are new and never encountered before (CPU packaging isn t architecture specific!). The problems were shall face in the coming time, and our solutions to them will set a precendent for the future.

References 1 : https://summerofcode.withgoogle.com/programs/2025/projects/9s4jUjV0 2 : https://tracker.debian.org/pkg/hipblas-common 3 : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105114 4 : https://salsa.debian.org/rocm-team 5 : https://packages.debian.org/source/sid/hipblas-common 6 : https://lists.debian.org/debian-ai/2025/05/msg00088.html 7 : https://www.cp2k.org/dbcsr 8 : https://salsa.debian.org/Spaarsh/dbcsr/ 9 : https://drive.google.com/file/d/14WQuTMcI-L0lbi3zkUc9pT6RGwwVY0j1/view?usp=sharing 10 : https://docs.google.com/presentation/d/1p-nkHPgg5C5jKGy7ySZ8rts5G2vNFQpQJQ8UySOWgVE 11 : https://github.com/cp2k/dbcsr/discussions/933 12 : https://github.com/pytorch/gloo 13 : https://salsa.debian.org/Spaarsh/gloo 14 : https://tracker.debian.org/pkg/hipify 15 : https://www.cp2k.org/ 16 : https://tracker.debian.org/pkg/dbcsr 17 : https://bugs.debian.org/cgi-bin/bugreport.cgi?https://fossunited.org/indiafoss/2025bug=1108159 18 : https://lists.debian.org/debian-ai/2025/05/msg00113.html 19 : https://fossunited.org/c/indiafoss/2025/cfp/dpq0b26ece 20 : https://fossunited.org/indiafoss/2025 21 : https://salsa.debian.org/cgmb 22 : https://salsa.debian.org/utk4r-sh

Motivation On the 8th of August 2025 (a day before the Debian Trixie release), I was upgrading my personal laptop from Debian Bookworm to Trixie. It was a major update. However, the update didn t go smoothly, and I ran into some errors. From the Debian support IRC channel, I got to know that it would be best if I removed the texlive packages. However, it was not so easy to just remove texlive with a simple apt remove command. I had to remove the texlive packages from /usr/bin. Then I ran into other errors. Hours after I started the upgrade, I realized I preferred having my system as it was before, as I had to travel to Noida the next day. Needless to say, I wanted to go to sleep rather than fix my broken system. Only if I had a way to go back to my system before I started upgrading, it would have saved a lot of trouble for me. I ended up installing Trixie from scratch. It turns out that there was a way to recover to the state before the upgrade - using Timeshift to roll back the system to a state (in our example, it is the state before the upgrade process started) in the past. However, it needs the Btrfs filesystem with appropriate subvolumes, not provided by Debian installer in their guided partitioning menu. I have set it up after a few weeks of the above-mentioned incident. Let me demonstrate how it works.

Check the screenshot above. It shows a list of snapshots made by Timeshift. Some of them were made by me manually. Others were made by Timeshift automatically as per the routine - I have set up hourly backups and weekly backups etc. In the above-mentioned major update, I could have just taken a snapshot using Timeshift before performing the upgrade and could have rolled back to that snapshot when I found that I cannot spend more time on fixing my installation errors. Then I could just perform the upgrade later.

Installation In this tutorial, I will cover how I installed Debian with Btrfs and disk encryption, along with creating subvolumes @ for root and @home for /home so that I can use Timeshift to create snapshots. These snapshots are kept on the same disk where Debian is installed, and the use-case is to roll back to a working system in case I mess up something or to recover an accidentally deleted file. I went through countless tutorials on the Internet, but I didn t find a single tutorial covering both the disk encryption and the above-mentioned subvolumes (on Debian). Debian doesn t create the desired subvolumes by default, therefore the process requires some manual steps, which beginners may not be comfortable performing. Beginners can try distros such as Fedora and Linux Mint, as their installation includes Btrfs with the required subvolumes. Furthermore, it is pertinent to note that I used Debian Trixie s DVD iso on a real laptop (not a virtual machine) for my installation. Debian Trixie is the codename for the current stable version of Debian. Then I took screenshots in a virtual machine by repeating the process. Moreover, a couple of screenshots are from the installation I did on the real laptop. Let s start the tutorial by booting up the Debian installer.

The above screenshot shows the first screen we see on the installer. Since we want to choose Expert Install, we select Advanced Options in the screenshot above.

Let s select the Expert Install option in the above screenshot. It is because we want to create subvolumes after the installer is done with the partition, and only then proceed to installing the base system. Non-expert install modes proceed directly to installing the system right after creating partitions without pausing for us to create the subvolumes.

After selecting the Expert Install option, you will get the screen above. I will skip to partitioning from here and leave the intermediate steps such as choosing language, region, connecting to Wi-Fi, etc. For your reference, I did create the root user.

Let s jump right to the partitioning step. Select the Partition disks option from the menu as shown above.

Choose Manual.

Select your disk where you would like to install Debian.

Select Yes when asked for creating a new partition.

I chose the msdos option as I am not using UEFI. If you are using UEFI, then you need to choose the gpt option. Also, your steps will (slightly) differ from mine if you are using UEFI. In that case, you can watch this video by the YouTube channel EF Linux in which he creates an EFI partition. As he doesn t cover disk encryption, you can continue reading this post after following the steps corresponding to EFI.

Select the free space option as shown above.

Choose Create a new partition.

I chose the partition size to be 1 GB.

Choose Primary.

Choose Beginning.

Now, I got to this screen.

I changed mount point to /boot and turned on the bootable flag and then selected Done setting up the partition.

Now select free space.

Choose the Create a new partition option.

I made the partition size equal to the remaining space on my disk. I do not intend to create a swap partition, so I do not need more space.

Select Primary.

Select the Use as option to change its value.

Select physical volume for encryption.

Select Done setting up the partition.

Now select Configure encrypted volumes.

Select Yes.

Select Finish.

Selecting Yes will take a lot of time to erase the data. Therefore, I would say if you have hours for this step (in case your SSD is like 1 TB), then I would recommend selecting Yes. Otherwise, you could select No and compromise on the quality of encryption. After this, you will be asked to enter a passphrase for disk encryption and confirm it. Please do so. I forgot to take the screenshot for that step.

Now select that encrypted volume as shown in the screenshot above.

Here we will change a couple of options which will be shown in the next screenshot.

In the Use as menu, select btrfs journaling file system.

Now, click on the mount point option.

Change it to / - the root file system.

Select Done setting up the partition.

This is a preview of the paritioning after performing the above-mentioned steps.

If everything is okay, proceed with the Finish partitioning and write changes to disk option.

The installer is reminding us to create a swap partition. I proceeded without it as I planned to add swap after the installation.

If everything looks fine, choose yes for writing the changes to disks.

Now we are done with partitioning and we are shown the screen in the screenshot above. If we had not selected the Expert Install option, the installer would have proceeded to install the base system without asking us. However, we want to create subvolumes before proceeding to install the base system. This is the reason we chose Expert Install. Now press Ctrl + F2.

You will see the screen as in the above screenshot. It says Please press Enter to activate this console. So, let s press Enter.

After pressing Enter, we see the above screen.

The screenshot above shows the steps I performed in the console. I followed the already mentioned video by EF Linux for this part and adapted it to my situation (he doesn t encrypt the disk in his tutorial). First we run df -h to have a look at how our disk is partitioned. In my case, the output was:

# df -h
Filesystem              Size  Used  Avail   Use% Mounted on
tmpfs                   1.6G  344.0K  1.6G    0% /run
devtmpfs                7.7G       0  7.7G   0% /dev
/dev/sdb1               3.7G    3.7G    0   100% /cdrom
/dev/mapper/sda2_crypt  952.9G  5.8G  950.9G  0% /target
/dev/sda1               919.7M  260.0K  855.8M  0% /target/boot

df -h shows us that /dev/mapper/sda2_crypt and /dev/sda1 are mounted on /target and /target/boot respectively. Let s unmount them. For that, we run:

# umount /target
# umount /target/boot

Next, let s mount our root filesystem to /mnt.

# mount /dev/mapper/sda2_crypt /mnt

Let s go into the /mnt directory.

# cd /mnt

Upon listing the contents of this directory, we get:

/mnt # ls
@rootfs

Debian installer has created a subvolume @rootfs automatically. However, we need the subvolumes to be @ and @home. Therefore, let s rename the @rootfs subvolume to @.

/mnt # mv @rootfs @

Listing the contents of the directory again, we get:

/mnt # ls
@

We only one subvolume right now. Therefore, let us go ahead and create another subvolume @home.

/mnt # btrfs subvolume create @home
Create subvolume './@home'

If we perform ls now, we will see there are two subvolumes:

/mnt # ls
@ @home

Let us mount /dev/mapper/sda2_crypt to /target

/mnt # mount -o noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=@ /dev/mapper/sda2_crypt /target/

Now we need to create a directory for /home.

/mnt # mkdir /target/home/

Now we mount the /home directory with subvol=@home option.

/mnt # mount -o noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=@home /dev/mapper/sda2_crypt /target/home/

Now mount /dev/sda1 to /target/boot.

/mnt # mount /dev/sda1 /target/boot/

Now we need to add these options to the fstab file, which is located at /target/etc/fstab. Unfortunately, vim is not installed in this console. The only way to edit is Nano.

nano /target/etc/fstab

Edit your fstab file to look similar to the one in the screenshot above. I am pasting the fstab file contents below for easy reference.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda2_crypt /        btrfs   noatime,compress=zstd,ssd,discard=async,space_cache=v2,subvol=@ 0       0
/dev/mapper/sda2_crypt /home    btrfs   noatime,compress=zstd,ssd,discard=async,space_cache=v2,subvol=@home 0       0
# /boot was on /dev/sda1 during installation
UUID=12842b16-d3b3-44b4-878a-beb1e6362fbc /boot           ext4    defaults        0       2
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Please double check the fstab file before saving it. In Nano, you can press Ctrl+O followed by pressing Enter to save the file. Then press Ctrl+X to quit Nano. Now, preview the fstab file by running

cat /target/etc/fstab

and verify that the entries are correct, otherwise you will booted to an unusable and broken system after the installation is complete. Next, press Ctrl + Alt + F1 to go back to the installer.

Proceed to Install the base system.

Screenshot of Debian installer installing the base system.

I chose the default option here - linux-image-amd64. After this, the installer will ask you a few more questions. For desktop environment, I chose KDE Plasma. You can choose the desktop environment as per your liking. I will not cover the rest of the installation process and assume that you were able to install from here.

Post installation Let s jump to our freshly installed Debian system. Since I created a root user, I added the user ravi to the suoders file (/etc/sudoers) so that ravi can run commands with sudo. Follow this if you would like to do the same. Now we set up zram as swap. First, install zram-tools.

sudo apt install zram-tools

Now edit the file /etc/default/zramswap and make sure to have the following lines are uncommented:

ALGO=lz4
PERCENT=50

Now, run

sudo systemctl restart zramswap

If you run lsblk now, you should see the below-mentioned entry in the output:

zram0          253:0    0   7.8G  0 disk  [SWAP]

This shows us that zram has been activated as swap. Now we install timeshift, which can be done by running

sudo apt install timeshift

After the installation is complete, run Timeshift and schedule snapshots as you please. We are done now. Hope the tutorial was helpful. See you in the next post and let me know if you have any suggestions and questions on this tutorial.