* NOTE: as explained below, more and more backports are requiring a newer debhelper
and dh-autoreconf in each repository (project) we create. We can cut down on the
work by backporting everything we do in one project, so they all use the backported
debhelper and dh-autoreconf we've already added to the project.
The alternative is to just remove the need for those newer build tools. This can usually
be done by commenting out the two lines in the override section for dh_strip in /debian/rules,
and dropping the minimum required version of the debhelper build-depend in the debian/control
and compat files if necessary (often the maintainer forgets to bump the B-D) We have the
choice--whatever's the least trouble.
Note 2: Sometime the OBS has trouble with build-depends that list virtual packages such as libjack-dev
. In that case, just add the real package that provides it, usually listed in the error message, to the build-depends in debian/control. In this case it would be libjack-jackd2-dev
. Then rebuild the sources again, delete the debian.tar.xz and .dsc file from the OBS, and upload your new versions of those.
(Part 1 of 3)
OBS = openSUSE Build Service: https://build.opensuse.org/
The free and easy to join openSUSE Build Service builds and hosts both Linux rpm
and deb packages from source packages. This guide focuses on building packages
for Debian and Ubuntu (deb format).
Prerequisites: an account at the OBS, which is easy to create via their web
interface. Once we're logged in, currently a cookie will keep us logged in for 24
hours, or until we log out.
Have the "devscripts" package installed on our machine.
Source packages to load into the OBS.
Source packages can be obtained from upstream Debian, Ubuntu, PPAs, or other
repositories as described here: https://wiki.debian.org/SimpleBackportCreation
If we don't plan to actually build any packages on our own machine, we should
be able to get by with just an install of devscripts instead of the bigger
packaging-dev metapackage. Source packages can also be directly downloaded to
our machine from packages.debian.org,
or surfing down into the package pool in a PPA, for example. This can be quicker
than modifying our software sources,downloading, then reverting the changes.
Often, the upstream Debian source packages can be directly uploaded into the OBS
without changes. However, if we, like the official backports crew, are concerned
with allowing users a smooth upgrade in place to the next Debian release, adding a
tilde "~" symbol allows our version to be seen as a lower version than the same
one in the new stable. So if the upstream version is
at the time of the stable transition, changing that to foo 1.2.3-1~
will make that a lower version than the first, and the user will be able to upgrade
smoothly to the new Debian stable version. Jessie-backports adds "~bpo80+1, and
ordinarily we'd be able to upload those source packages directly, but
unfortunately, the OBS does not recognize the "+" symbol, so we have to either
add a new debian/changelog stanza with a modified version (~bpo80.1), per the wiki
process above, or directly edit the version string in the existing first stanza.
I'll do that below in my example--what's important is the "~" to allow the
upgrade process. If we aren't concerned about a smooth upgrade, perhaps if the
package isn't in upstream Debian and probably won't be in the next release, then
this isn't a problem.
The OBS can build for multiple Debian and Ubuntu releases from one set of source
packages, such as in my Pale Moon repository, so in that case, the version
shouldn't be distro-specific. Since PM isn't in those distros, I just use a version
like "26.5.0-1" in the changelog. Having distro-specific versioning, such as
"26.5.0-1bpo80.1", would require having a separate subproject repository (see below)
for each distro with its own specific source packages, plus a single distro build
target for each subproject. That's not a problem if we're just doing backports
for one release, of course.
In addition to not allowing the "+" symbol, the virtual machines that the OBS
provides have limited RAM. Almost all packages will build, but memory-hungry
ones that eat a lot of RAM during the build, such as llvm or Chromium, will fail.
Some packages may also just get a random build failure that is usually cured by
triggering a rebuild. ¯\_(ツ)_/¯ ??
The OBS will also trigger a rebuild of everything in a repository if you upgrade
one of the base build-dependencies. For example, I have a multimedia repository in
which most of the packages depend on the latest ffmpeg release. Upgrading ffmpeg
also ends up triggering a rebuild of most packages. Upgrading an ffmpeg build-
depend such as libx265-dev also triggers a ffmpeg rebuild and the rest of the
cascade. Though this might take a few hours to complete, this is actually more
of a feature, since it ensures that all those multimedia packages remain compatible
across soname bumps, which can cause breakages deb-multimedia and even jessie-
backports have had trouble avoiding.
So, we created a new account on the OBS. We automatically get assigned a "home
project". For my example below, since I already have Pale Moon in my home project's
repository, I'll create a separate subproject so the repositories remain separate.
So, since we'll modifying the source, and this is a modern 3.0 (quilt) source
format package, we only need to download the two highlighted files shown in the
previous image. Then the two tarballs are extracted:
and the version in the first stanza of the /debian/changelog file is modified,
per the wiki backporting guide. If we're really following Debian policy exactly,
we go through the procedure to add a new stanza, but for the OBS, we can get away
with just adding something like ~bpo80.obs to the existing version. In this case,
I already added a new stanza for the MX 15 backport, so I'm just going to edit that:
As before, the "~" is often the most important symbol. If you don't care about that,
just try downloading and uploading all the Debian source packages (usually three).
Also note that the build tools are really picky about syntax in this file, so if
we accidentally delete one of two whitespaces between words in certain places in
this file, the build system can throw a fit. Other places, it doesn't care. Safest to
just not change them, just carefully change words.