On Fri, May 22, 2020 at 4:05 AM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > Hi distro kernel maintainers, > > I currently have build.wireguard.com 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 build.wireguard.com 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" \ https://git.centos.org/api/0/rpms/kernel/git/tags | 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: * http://vault.centos.org/7.8.2003/os/Source/SPackages/ * http://vault.centos.org/7.8.2003/updates/Source/SPackages/ CentOS 8.1 is a bit simpler, with only the one location: http://vault.centos.org/8.1.1911/BaseOS/Source/SPackages/ 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 http://vault.centos.org/8.1.1911/BaseOS/Source/SPackages/${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. [1]: https://git.centos.org/rpms/kernel [2]: https://pagure.io/api [3]: http://vault.centos.org/7.8.2003/ [4]: http://vault.centos.org/8.1.1911/ -- 真実はいつも一つ!/ Always, there's only one truth!