The other day while working on pgrx based postgresql extensions, I saw a weird errors in the build log.

warning: line 29: Possible unexpanded macro in: Provides:       postgresql18-someextension-llvmjit = %{version}-%{release}
warning: line 29: Possible unexpanded macro in: Obsoletes:      postgresql18-someextension-llvmjit < %{version}-%{release}

This is odd. The Version and Release are set. So what is going on here:

%if "%{pg_name}" == ""
Name:           %{ext_name}
ExclusiveArch:  do_not_build
%else
Name:           %{pg_name}-%{ext_name}
BuildRequires:  %{pg_name}-pgrx
%pg_server_requires
%endif
Version:        1.0.0
Release:        0

The warning comes from %pg_server_requires, which then calls %pg_obsolete_llvm_subpackage. This preamble block was a slight deviation from the pattern I was usually following. I made the change because I saw “wait I can group up some stuff”

zypp makes sure that it not just randomly moves between repositories of different vendors. Vendors in this case can be the (open)SUSE base packages and different buildservice repositories. If you want to do it via

zypper dup --from <repoid>

You get a lot of questions for “do you really want to change the vendor?”. When you do that e.g. to test the next GNOME major release from GNOME:Next, that is a lot of questions. Like a few hundred times. My manual way involved putting 1\n into the mouse cut buffer and pasting with my middle mouse button.

Declarative packaging is all the rage lately. I stopped counting how often I was asked “Do you have something like nix packages?”

Back in 2019 Florian Festi gave a nice talk called Re-Thinking Spec Files. It showed many nice ideas on how packaging could be easier.

Since RPM 4.20 we actually have declarative builds. Let us explore this a bit.

Exploring the possibilities

One of the first packages in openSUSE, which switched to declarative builds was gnome-text-editor. But to focus on the basics we will use my converted minisign package.

A while ago we looked at conditional building in rpm. One point we did not cover yet was how we can control build conditionals within the open buildservice.

Back in the good old days

When using osc build --with=build_docs --without=run_tests rpm internally defines 2 variables:

_with_build_docs
_without_run_tests

Which is also something we used when integrate it with the buildservice:

%define _with_ruby34 1
%define _without_apparmor 1
Macros:
%_with_ruby34 1
%_without_apparmor 1
:Macros

This was working mostly well. We could have one spec file which then had features turned on and off depending on the _with(out)_something defines. But it completely failed if an user later wanted to toggle the decision made on the base distro.

Or said in another way: How to run openSUSE on Hetzner dedicated servers.

TL;DR:

1. Install any other linux distribution from their installer.
2. Follow the SDB article about remote installation
3. Install openSUSE via SSH.

Why not build an image for their installimage tool? I have that too. But last time I used that, the install tool logged more things to their logging server than I liked. And it did so via plain HTTP.

This whole blog post was born from the idea to clarify how to nicely force a newer compiler on older distros. But of course we have to start with the basics.

RPM conditionals basics

RPM supports two main forms of conditionals %if and %ifarch. The last one is easy … it lets us do architecture specific things:

%ifarch x86_64 aarch64
[snip]
%endif

The %if is a bit more flexible. We can use it to compare strings.

It is actually relatively simple

1. install the php imagick extension with libheif support
2. enable the preview providers

For openSUSE Tumbleweed the php8-imagick package is already built with libheif support. Though the library in the distribution lacks H.256 support. We can easily remedy that situation by using the libheif1 package from packman instead.

# cat /etc/zypp/repos.d/isv-packman.repo
[isv-packman]
enabled=1
autorefresh=1
baseurl=https://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/
type=rpm-md
gpgcheck=1

Then we can install the new libheif1 with

zypper in --from isv-packman libheif1

Afterwards you have to restart Apache or php-fpm depending on what you use.

So the OBS supports packaging Debian packages for a while now. Is it perfect? No. But it works well enough. Though one problem I recently ran into …

How to get past lintian?

The obvious answer is of course: Fix the errors it spits out. And I agree. I have done that. For all but one …

bad-distribution-in-changes-file

For many of the debian packages, I helped to start, we used:

pkgname (1.2.3-1.1) unstable; urgency=medium

Back when i started using Let’s Encrypt I wanted a lightweight client. Danimo recommended dehydrated. Well it still had a different name back then. But details. So for years I had been a very happy camper with it. Then I learned that many daemons now support that you can run ECDSA and RSA certs at the same time and the server picks the right cert depending on the client. So we will solve this first.

TL;DR

Operating systems let you customize the sensitivity of the microphone allowing you to suppress environmental noise such as keyboard strokes. Video conferences software unfortunately tends to override such settings using autogain making your customization void. While some video conferencing tools let you control autogain via the settings, Jitsi does not have such an option.

However, you can use https://your.jitsi.server/someroom#config.disableAGC=true when joining your Jitsi meetings to disable autogain and have more control over your microphone.