Similar to what is already done with DISTRO, which points to given image
of ours based on name. This time we do the same with upstream images,
such as debian:stretch or centos:centos8.
This way, for instance calling docker_images_require
"osmo-bsc-latest-centos8" would try to build the
osmo-bsc-latest/Dockerfile file starting from a centos8 image.
This is initialized to docker.io, keeping the default behaviour
if not specified. However, it allows us to specify a private
registry later on.
OsmoGGSN is not able to use the tun4 device from the default config in
docker. Since the more strict config checking in , it does not just
report a warning, but fails to start:
<0002> ggsn.c:189 APN(internet): Opening TUN device tun4
<0001> tun.c:184 errno=2/No such file or directory open() failed
<0002> ggsn.c:191 APN(internet): Failed to configure tun device
Error occurred during reading the below line:
Failed to open config file: '/etc/osmocom/osmo-ggsn.cfg'
Fix the repo install test jenkins job by not checking osmo-ggsn anymore.
In theory, we could probably create the tun device on the host, and
mount it inside the docker container. But that would require some
additional logic to clean it up properly, and it does not seem worth the
effort right now.
 libosmocore Ic9c1b566ec4a459f03e6319cf369691903cf9d00
Enable test of systemd services for osmo-sgsn, osmo-pcu, osmo-hnbgw and
osmo-bts-virtual. Add issue ID to failing osmo-ctrl2cgi and
Depends: Id892e1f4ab2daabbe9824b819b5fed985373b97a (osmo-sgsn)
Depends: Ie8001611756b661ff1871508c6248b2e990ba1d7 (osmo-bsc)
Depends: I354140f014854f1755b649e40a65e5d88b99c0ec (osmo-iuh)
Run systemd services of Osmocom programs, to check if any are not
starting properly. Use a whitelist to determine which services must
start up, because some are currently broken.
Modify the docker run command to support changing the CPU scheduling
policy/priority in systemd service files (used by osmo-bts).
The container grows heavily in size as the test runs, so make sure to
always kill existing ones (from stopped jobs) before starting a new
one. In order to do that, do not use $BUILD_TAG as container name,
which changes with every new jenkins run.
Add own container with systemd, so we can (in a follow-up commit) run
the Osmocom systemd services in this test job. Rewrite the
"interactive shell" logic to support the new systemd docker container,
and enable it with an INTERACTIVE environment variable instead of
hardcoding 'interactive="true"' in the script. While at it, move the
Repository.key install to the Dockerfile so it works more like the other
docker containers we have.
Fix conflict in debian-repo-test-latest by not explicitly installing
dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package soapysdr0.5-2-module-lms7:amd64 16.12.0+dfsg-1
I have tested locally, that debian-repo-test passes with this patch with
both FEED=latest and FEED=nightly.
With this patch, the debian-repo-install-test script checks if
the Osmocom programs as installed from the Debian repository have
"UNKNOWN" in their --version output.
Installs most packages from the Osmocom Debian repository into a plain
debian:stretch container and call the osmo-* binaries with --version
The list of packages is automatically generated with aptitude, so the
job does not need to be changed for every new package. There's also a
new blacklist.txt file with a list of packages, that will not be
installed in this test. Currently, this is filled with all packages
built from the legacy openbsc.git project (some of them are
conflicting with newer repositories) and the soapysdr packages (see
The feed ("latest", "nightly") can be specified with the FEED
environment variable, it gets read by jenkins.sh (defaults to nightly).