Make it possible to set a different mirror for debian-stretch-titan than
for all other containers. 2021q1 doesn't have the eclipse-titan package
and it doesn't make sense to build it there.
I've thought about adding OSMOCOM_REPO_TESTSUITE_PATH and
OSMOCOM_REPO_TESTSUITE_VERSION too, but we don't have any use for these
right now. Let's add them later if we should need them.
Allow to change the path between OSMOCOM_REPO_MIRROR and
OSMOCOM_REPO_VERSION. While at it, tweak related comments (comment above
the variable as usually, replace "repo" wording with "feed" for the
latest/nightly variable as we usually refer to it as feed), and mention
OSMOCOM_REPO_* in README.md.
In order to be able to use a different mirror for testsuite and systems
under test, the testsuite related Dockerfiles (osmocom-bb-host-master,
debian-stretch-titan) are not using OSMOCOM_REPO_PATH. We could add a
OSMOCOM_REPO_TESTSUITE_PATH on demand, as mentioned in the next commit.
it has been deprecated in libosmocore.git 2.5 years ago:
Author: Neels Hofmeyr <email@example.com>
Date: Mon Sep 10 20:58:52 2018 +0200
mongo-db is only available for x86_64 from their third party
repository. Don't attempt to install it for another architecture. As
this is part of the open5gs dependencies, don't install any of them
This should fix the currently failing "update-osmo-ci-on-slaves"
jenkins job. I've considered disabling the build of the osmo-gsm-tester
container for ARM altogether, but the osmo-gsm-tester manual explicitly
mentions ARM trails.
When testing gbproxy with an IP BSS, we want to use IP-SNS as that
is the more relaistic use case in practice.
This un-breaks the dockerized tests since I90bd101096979b170c38fa2a80abb80d296c4d2e
was merged in osmo-ttcn3-hacks.git
Display an overview of installed Osmocom packages at the start of each
ttcn3-*/jenkins.sh script (and others making use of
The OGT build setup and the physicial setup use now debian buster. Let's
update this container too to buster to avoid different versions of libs
during build and runtime (such as libasan).
+ docker container rm jenkins-ttcn3-fr-test-109-frnet jenkins-ttcn3-fr-test-109-ttcn3-fr-test
Error response from daemon: You cannot remove a running container 4f5ec7f412b2d37d00b2738b2bcddffada36efebfe7ce32ed196543ee436154e. Stop the container before attempting removal or force remove
In I3ec86c8610b3b43d39ea8e3da444861d317ced4e the container-individual
respawn.sh has been replaced with a common one - but unfortuantely
missing to update the debian-stretch-build, which made (at least)
ttcn3-bts-test builds fail for two nights now.
Maintaining several versions of the same file in different folders
is a bad idea, because at some point their content gets out of sync.
This is exactly what happened to 'respawn.sh': sleep()ing was only
implemented in 'osmo-bts-master/respawn.sh', other versions of this
file would simply ignore '$SLEEP_BEFORE_RESPAWN'.
The easiest solution would be to have all common files in a single
directory, however Docker does not allow to ADD files from outside
of the build context. In other words, all files must be in the
same directory as the Dockerfile itself.
Modify 'make/Makefile' in order to copy the contents of common
directory to the current build context ('pre-build' target) and
remove it after building ('post-build' target).
Change debian-stretch-build-dist to be based on
debian-stretch-obs-latest instead of debian-stretch-build. The latter
installs the nightly OBS repository now (as that is what we need for the
TTCN-3 builds using debian-stretch-build), but debian-stretch-build-dist
needs to install packages from OBS latest.
Fixes jenkins failures:
The following packages have unmet dependencies:
libasn1c-dev : Depends: osmocom-latest but it is not going to be installed
The missing dependency is being added to osmo-msc master's
contrib/osmo-msc.spec.in file. Until the next release is done, which
contains the patch, install the library explicitly to fix:
<0009> db.c:648 Failed to create database connection to sqlite3 db 'sms.db';
Is the sqlite3 database driver for libdbi installed on this system?
In binary packages for Debian, osmo-bts-omldummy is (for some reason)
part of 'osmo-bts-virtual' package. For CentOS this binary is
shipped properly in a separate package, so let's install it.
This change fixes ttcn3-bsc-test under CentOS failing with:
/usr/local/bin/respawn.sh: line 9: osmo-bts-omldummy: command not found
This reverts commit b70b3c1a80110329aa7c6a8be5a9e0ced511be13.t
The patch was merged too quickly before osmo-ttcn3-hacks.git one.
Revert temporarily to avoid all tests failing due to non-existant module