5.2 KiB
categories | comments | date | disable_share | draft | omit_header_text | tags | title | toc | |||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
true | 2021-01-05 15:23:49+01:00 | true | true | true |
|
Providing KDE software updates from git for fun and profit in openSUSE | true |
If I look back at the last post I made on ths blog... let's say quite a lot of time has passed. The reason? Well, first of all, one would call it a lack of motivation1, and afterwards, the emergence of a small yet quite annoying pathogen which caused a bit of a stir worldwide. But today I'm not going to talk about viruses: perhaps some other time when you can avoid hear about it for breakfast, lunch, and dinner.
OBS and KDE
Yes, today I'm going to talk about the OBS, that is the Open Build Service, not to be confused with another highly successful open source project.
As you know, since ages, the openSUSE KDE team provides a series of repositories which track the latest state of the git repositories in KDE, be them either Frameworks, Plasma, or the applications part of the Release Service. This also allows to create Live CDs which can be useful for testing out the software.
But the question that I've seen every now and then is... how it is actually done? Is everything provided by the OBS, or does someone need to add some glue on top of that?
Source services
From the official documentation:
Source Services are tools to validate, generate or modify sources in a trustable way.
Ok, that doesn't tell us much, does it? Luckily, the concept is simple. It is that, for packages built in the OBS, we can use tools (internal or external) to perform operations on the source(s) the packages are built from. These are done before any actual building starts.
The openSUSE wiki has some examples of what a source service can do, of which one immediately jumps to our eye:
Checkout service - checks out from SVC system (svn, git, ...) and creates a tarball.
That means that we can, theoretically, ask the OBS to do a checkout from git, and automatically generate a tarball from there. In addition, a source service can add version information to the RPM spec file - the blueprint of an openSUSE package - including some data taken off git, for example the date and the revision hash of the checkout.
Source services are implemented as files named _service
which live in the OBS for each package. Let's take a look at the one for kcoreaddons
in the KDE:Unstable::
<services>
<service name="obs_scm">
<param name="url">https://invent.kde.org/frameworks/kcoreaddons.git</param>
<param name="scm">git</param>
<param name="versionformat">VERSIONgit.%ci~%h</param>
</service>
<service name="set_version_kf5" mode="buildtime"/>
<service mode="buildtime" name="tar" />
<service mode="buildtime" name="recompress">
<param name="file">*.tar</param>
<param name="compression">xz</param>
</service>
<service mode="buildtime" name="set_version" />
</services>
obs_scm
The first line inside service
tells us that we're using the obs_scm
service, which is a built-in service in openSUSE's OBS instance to checkout the sources from the url, using git. The versionformat
parameter sets the version to a literal VERSION
(more on that later) and adds the git
suffix, and then adds %ci
, which is replaced by the checkout date (example: 20210102T122329
) and %h
, which puts the short git revision hash in the version (example: 5d069715
).
The whole data is compressed in a cpio archive with the obscpio
extension. At this point, we don't have a tarball yet.
After the checkout
THe next services run when the package is actually built, as you can see by the mode="builtime"
in their definitions. The first one (set_version_kf5
) is actually a service made by Fabian Vogt (fellow member of the KDE team) which replaces VERSION
by the current version present in the KDE git (done manually: it is read from the OBS project configuration, and bumped every time it happens upstream). The following lines set the version in the spec file, and compress the whole thing into a tarball.
At this point, the build system starts building the actual source and creating the package.
Manual labor
Just when are these kind of source services run? If left by themselves, never. You need to actually signal the OBS (trigger, in OBS-speak) to run the service. An example is with the osc
command line utility:
osc service remoterun KDE:Unstable:Frameworks kcoreaddons
Or there's a button in the OBS web interface which can allow you to do just that:
-
Also called laziness. ↩︎