Adding Debian, Ubuntu, OpenSUSE, RHEL, CentOS kernels to WireGuard CI: Seeking URLs

Neal Gompa ngompa13 at
Sat May 23 09:07:04 CEST 2020

On Fri, May 22, 2020 at 4:05 AM Jason A. Donenfeld <Jason at> wrote:
> Hi distro kernel maintainers,
> I currently have churning away at every new kernel
> release between 3.10 and 5.5 for each and every wireguard-linux-compat
> commit, making sure that we don't break anything. It's a pretty CPU
> intensive, but it means we don't break mainline kernels ever when
> releasing. Scroll down to the bottom to see what I mean.
> This is not the case, however, with distro kernels, which differ
> notoriously from mainline in surprising ways. There's been some
> breakage, and unless we do something about it, I imagine there will
> continue to be much breakage. Because so many users use Linux via your
> kernels, it seems imperative that we support these well. And with
> distros like Ubuntu now supporting WireGuard directly through
> wireguard-linux-compat, it seems ever more important that we minimize
> breakage so as to not create release delays downstream of us.
> At the moment, wireguard-linux-compat supports:
> - Debian oldoldstable (8), oldstable (9), stable (10), testing (11), sid
> - Ubuntu 14.04, 16.04, 18.04, 19.04, 19.10, 20.04
> - OpenSUSE 42, 15, 15.2 (leap)
> - RHEL 7.8, 8.2
> - CentOS 8.1
> The logic here is that we support the latest single kernel for each
> major supported release of these distros. For example, on Debian
> stable, we support 4.19.0-9 but not 4.19.0-8 anymore.
> I'd like to put these on to mitigate breakage. In
> order to make this happen, I'll need two things:
> - A URL I can scape that will give me the latest kernel versions for
> relevant distros.
> - A URL I can construct using a selected version to download a boring
> kernel source tarball.
> I would prefer to not involve git, if possible, and for these URLs to
> point to the sources for actual kernels that are shipping as the
> standard latest-kernel for each of the above releases.
> If you can provide those pieces of information for my CI scripts, it
> seems likely that we can drastically reduce breakage for your
> distribution frankenkernels. If you cannot provide that, but other
> distros can, I will probably naturally prioritize support for those
> other distros that make maintenance easier, simply as a matter of
> habit rather than something intentional.

For CentOS kernels, you can query the kernel builds that have been
made for CentOS 7 and CentOS 8 by requesting the list of tags from the
kernel package[1].

The Pagure API[2] provides a straightforward way to do this, even with
curl and jq:

$ curl --silent --header "Content-Type: application/json" \ | jq '.["tags"] '

This will return a JSON list of tags. For CentOS 7, you'd want the
tags beginning with "imports/c7/". For CentOS 8, you'd want the tags
beginning with "imports/c8/". The string after the prefix is the NVR
(name-version-release) of the package, and is the main part of the
Source RPM file name. The highest NVR in each tag namespace is the
latest package. There are various ways to do the comparison, but the
simplest one would be to sort them with the highest number on top, as
the numbers are guaranteed to numerically advance. I'm not good with
jq, so I couldn't figure out how to do it as a one-liner.

Sources are shipped in the form of Source RPMs and pushed to the
CentOS Vault[3][4]. Sources are archived at each CentOS point release,
meaning that you need to be aware of the CentOS point release where
the kernel was shipped.

So for example, for CentOS 7.8, you'd be looking at the following
locations for source packages:

CentOS 8.1 is a bit simpler, with only the one location:

With the information from the API and knowing the location of where
the packages are, you can fetch a kernel source package like so:

$ wget${kernel_version_release}.src.rpm

All the stuff in the source RPM is enough to rebuild the kernel. If
you just want to grab the tarball inside, then you can grab it by
unpacking the Source RPM and grabbing the tarball inside.


真実はいつも一つ!/ Always, there's only one truth!

More information about the WireGuard mailing list