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: Sometimes the OBS has trouble with build-depends that depend on a choice of two other build-depends, such as libjpeg-dev and libjpeg62-turbo-dev. ( Hover the mouse over the "unresovable" error to see what's going on) In this particular case, just add libjpeg-dev to the build-depends in debian/control--or whatever "general" build-depend the mouse hover reveals, then rebuild the sources again, delete the debian.tar.xz and .dsc file from the OBS, and upload your new versions of those.
Note 3: The OBS now seems to support the "+" symbols in package versions. I've tried to update the guide to cover this, but keep this in mind if I missed anything.
(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).
1. 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.
2. Have the "devscripts" package installed on our machine. You may also need to have
certain of the build-depends installed on your machine to rebuild the source files.
3. Source packages to load into the OBS. If you're now not interested in doing a
smooth in-place upgrade to the next Debian release with your backport installed,
you could try directly downloading and installing the source packages from
Debian, though often you can tweak those to use debhelper 10 in Stretch instead
of Buster's debhelper 11, or other alternative build-depends. Then you need to
rebuild the sources as explained below. Smooth upgrades also require changing
the version as explained.
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 web 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
will make that a lower version than the first, and the user will be able to upgrade
smoothly to the new Debian stable version.
J̶e̶s̶s̶i̶e̶-̶b̶a̶c̶k̶p̶o̶r̶t̶s̶ ̶a̶d̶d̶s̶ ̶"̶~̶b̶p̶o̶8̶0̶+̶1̶,̶ ̶a̶n̶d̶ ̶o̶r̶d̶i̶n̶a̶r̶i̶l̶y̶ ̶w̶e̶'̶d̶ ̶b̶e̶ ̶a̶b̶l̶e̶ ̶t̶o̶ ̶u̶p̶l̶o̶a̶d̶ ̶t̶h̶o̶s̶e̶ ̶s̶o̶u̶r̶c̶e̶ ̶p̶a̶c̶k̶a̶g̶e̶s̶ ̶d̶i̶r̶e̶c̶t̶l̶y̶,̶ ̶b̶u̶t̶ ̶u̶n̶f̶o̶r̶t̶u̶n̶a̶t̶e̶l̶y̶,̶ ̶t̶h̶e̶ ̶O̶B̶S̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶r̶e̶c̶o̶g̶n̶i̶z̶e̶ ̶t̶h̶e̶ ̶"̶+̶"̶ ̶s̶y̶m̶b̶o̶l̶,̶ ̶s̶o̶ ̶w̶e̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶e̶i̶t̶h̶e̶r̶ ̶a̶d̶d̶ ̶a̶ ̶n̶e̶w̶ ̶d̶e̶b̶i̶a̶n̶/̶c̶h̶a̶n̶g̶e̶l̶o̶g̶ ̶s̶t̶a̶n̶z̶a̶ ̶w̶i̶t̶h̶ ̶a̶ ̶m̶o̶d̶i̶f̶i̶e̶d̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶(̶~̶b̶p̶o̶8̶0̶.̶1̶)̶,̶ ̶p̶e̶r̶ ̶t̶h̶e̶ ̶w̶i̶k̶i̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶a̶b̶o̶v̶e̶,̶ ̶o̶r̶ ̶d̶i̶r̶e̶c̶t̶l̶y̶ ̶e̶d̶i̶t̶ ̶t̶h̶e̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶s̶t̶r̶i̶n̶g̶ ̶i̶n̶ ̶t̶h̶e̶ ̶e̶x̶i̶s̶t̶i̶n̶g̶ ̶f̶i̶r̶s̶t̶ ̶s̶t̶a̶n̶z̶a̶.̶
Update: the OBS now allows the "+" symbol. 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-1~bpo9+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.
If your build requires a lot of RAM or disk space, such as for web browsers,
Debian kernels, or llvm backports, you can request the OBS supply build machines
with those by also uploading a "_constraints" file with the sources. Here's one I use
for Pale Moon:
Code: Select all
<?xml version="1.0"?> <constraints> <hardware> <disk> <size unit="G">30</size> </disk> <memory> <size unit="M">10000</size> </memory> </hardware> </constraints>
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 ~bpo9~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.