Zugschlus
Marc "Zugschlus" Haber
Zugschluss is the German word for a train's tail signal which plays an important role in railroad safety systems. Truncated to ?IRCnet's former 9 character limit, Zugschlus has become my nickname for most of my network related activities since the Millennium.
I became a DebianDeveloper in 2001. I am maintainer of a number of less important packages, and member of the maintainer team for some other and more important packages, most prominently adduser, sudo, aide and atop. In the past, I have contributed to exim4, Debian's default MTA for many years.
Take a look at my Packages Overview
How to find me on the Network
https://www.zugschlus.de/ is my private home page
https://www.incluesion.de/ is my (german language) business home page. I am available for hire as a freelance consultant and also to do actual work regarding Debian, Linux, and Networks.
https://blog.zugschlus.de/ is my blog. I mainly blog in German (sorry) but the category Debian-English has some articles about Debian in English language. Pleased note that Debian-English is currently not syndicated on Planet Debian.
For bi-directional communication, you can reach me using one of the following media:
on IRC as Zugschlus on IRCnet (and sometimes on oftc as well).
My E-Mail address is mh+wiki.debian.org@zugschlus.de.
I am also reachable by a number of Instant Messengers (including Signal, Telegram and the unavoidable ?WhatsApp) listed on my business web page.
Zugschlus' Helper Scripts
I intend to publish some of my helper scripts that are too small to form a "real" Debian package here real soon now.
- package-pool-helper, a collection of easy scripts that are used to manage a local package pool
- makekernel, a collection of scripts to build Linux kernels using Debian's kernel-package with some bells and whistles including automatic module packages build and dependency helpers that allow automatic upgrades even across kernel versions.
- debinterdiff, a script which builds an interdiff between the last two versions of a source package. This script is quite helpful in managing backports.
- chroot-helper, a collection of scripts that are helpful in working with chroots for package development, building and testing.
editchanges, a script that allows editing the local changelog of the system with some safety and auditing bells and whistles.
- muttdebbug, a script that calls up a bug report's mbox in mutt and configures mutt in a way that replying and forwarding is quite easy and powerful.
The Zg2ShellStartup page shows some useful things I have implemented in my shell startup files to make things easier. That includes a scheme to easily build the appropriate contents of ~/.ssh automatically.
Zugschlus' Nifty Admin Tricks
This future page will contain a list of the admin tricks I use on my server systems to easy my daily work. The following list gives an overview about what will be described here RSN.
- cron-apt
- checkrestart
- apt-listchanges
- apt-listbugs
- aide
- sshd configuration
- installation
- the partitioning scheme used on my systems, LVM, mountpoint handling, backups etc.
- using policy-rc.d to stop freshly installed packages from starting their daemons immediately
Random Stuff
Incomplete List of Wiki Pages I feel responsible for
Managing patches with gbp
This was originally intended as a suggestion for text that could be on PackagingWithGit that Andrew Sayers is currently (2025-05-27) actively working on.
Manage files outside of debian/ patches
git-buildpackage works nicely with the 3.0 (quilt) package format. This chapter aims to explain the interaction between our packaging tools.
Generally, it is common to not make direct changes to the files released by upstream outside of the debian/ directory. If you want to change files outside debian/, create a patch-queue in debian/patches. Then during the package build, the patches will be automatically applied in the order listed in debian/patches/series.
Despite the source format being called 3.0 (quilt), package maintainers can maintain their patch queue without using quilt. gbp pq is another common approach that allows to maintain a patch queue with git methods: gbp pq import will convert the patches from your package's patch queue to git commits. This happens on a dedicated branch under patch-queue, and will move you to that branch. You can switch back and forth between the branches using gbp pq switch.
On the patch-queue branch, you can then use git rebase to edit the patches, adapt them to upstream changes, combine and/or re-order them and do other things with them. New patches can be added as new commits. In this stage, after gbp pq import, your patches are applied to the source package and you will see the patched source.
After work is finished, gbp pq export will convert each patch commit back to one patch file in debian/patches/, populating the patch metadata with information from the respective commit message.
You will almost certainly want to keep patches unapplied on the git branches that you plan to publish on salsa. While it is technically possible to publish a branch with patches applied, this is rather uncommon and is likely to confuse people who want to work with your package, as for an NMU or a security update.
When Debian tool documentation says that a Debian source package has the Debian patches applied, don't be confused by the fact that the source package is actually the .dsc file and the files referenced by the .dsc file _after_ calling dpkg-source -x. To make things worse, the orig.tar file is the unchanged (and unpatched) upstream source, while the debian.tar contains just the debian/ directory. It is therefore technically impossible to have those files in "patches applied" state. Please note that dpkg-source ignores some files during build of the source package (mainly .git, .gitignore, .pc, debian/source/local-options etc). See dpkg-source documentation for details.
Your published git branch (for example debian/latest on salsa) is also NOT a source package in this sense. So, even if a Debian source package usually has patches applied, your git should have them unapplied.
dpkg-source will generally do the right thing for a 3.0 (quilt) package:
Building the source package does not touch the orig.tar, it just tars up debian/. It is thus unimportant whether the working directory has patches applied or not when the source package is built.
Unpacking a source package with dpkg-source -x will unpack the tars and then apply the patch queue, yielding a source tree with patches appplied. Since the patch queue is applied in a normal way, you can use quilt commands to work with patches including applying and unapplying them.
- Building the package will apply all unapplied patches before beginning the build. After successful build, the patches that were applied during the process get unapplied again. The latter does not happen if the build aborts with an error.
Some documentation recommends to put unapply-patches in debian/source/local-options. This does not affect the source package build at all, it just unapplies all patches after building the binary packages. Your source tree therefore is then in a different state than it was after dpkg-source -x which might cause additional confusion.
Please note that you usually won't work in a directory created by dpkg-source -x if you want a git-based workflow. gbp (especially gbp pq) won't work in such a directory.