CentOS Linux 8 is EOL, attempting to install packages in it results in
an error. CentOS Linux is a rebuild of RHEL (stable versions). The
CentOS projects recommends to use CentOS Stream instead, which is a
build of the "public development branch for RHEL".
After the early EOL was announced on 2020-12-08, alternative projects
AlmaLinux and Rocky Linux have been established as binary compatible
forks of RHEL 8 (stable versions).
Both Alma and Rocky seem to be solid projects, see related Wikipedia
articles and their sources. Pick Alma and adjust the whole tree to use
the almalinux:8 docker image instead of centos:centos8.
Fix for:
Error: Failed to download metadata for repo 'appstream': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Related: SYS#5818
Related: https://www.centos.org/cl-vs-cs/
Related: https://www.centos.org/centos-linux-eol/
Related: https://bugs.centos.org/view.php?id=18394
Related: https://en.wikipedia.org/wiki/AlmaLinux
Related: https://en.wikipedia.org/wiki/Rocky_Linux
Change-Id: I30e1a773b901b1d2187214445116c7f2aecc4e36
This enables the test suite to obtain talloc reports between the
test case executions, which get stored together with the PCAP files.
Change-Id: I4e5474e8fc51d2ba8a0baca68e11df1346d7d4ab
This enables the test suite to obtain talloc reports between the
test case executions, which get stored together with the PCAP files.
Change-Id: Ia9525778fcecc60177be651624e2b2cf9bc75422
On some systems /bin/sh is a symbolic link to bash, so everything
works fine. On systems where /bin/sh is a real sh, copy fails:
cp: cannot access 'open5gs-{smf,upf,nrf}.yaml': No such file or directory
Change-Id: I64e9ddefdb6deb21b3bce3bc1af875a92919e6c9
Related: SYS#5602
Starting with release 1.2.0 of both repos, osmo-hnbgw binary is in
osmo-hnbgw.git, not osmo-iuh.git anymore.
Change-Id: I4ac6ede6a5b25ada211674bf3c46d79d7720a4bc
Newer osmo-hnodeb no longer depend on libgtp, get rid od the dependency.
Depends: osmo-hnodeb.git Change-Id I53ad4915aaed3bc7574036e963be10514e370fe2
Related: SYS#5516
Change-Id: I4e223823d08c7e9e17d87f54d9554429d31c8091
Fix for failing ttcn3-remsim-test-latest, in osmo-remsim-client.log:
/bin/sh: 1: osmo-remsim-client-shell: not found
Change-Id: Ia3041ea6f19ebe53e05117806acf88d3f86d4479
After the default UPSTREAM_DISTRO was changed from debian:stretch to
debian:bullseye, the "debian9-repo-install-test" container has gotten
built with bullseye instead of stretch. This is the reason for failures
of the jenkins job Osmocom-repo-install-debian9 we have seen over the
past days.
With this patch applied, it runs through again:
https://jenkins.osmocom.org/jenkins/job/Osmocom-repo-install-debian9/339/
Change-Id: I98a19184ba936114c03cd5cc4f54a3173cbd9cfe
Add the package providing "ip", as debian bullseye doesn't have it
installed by default anymore.
Fix for:
/kernel-test/qemu-ifup.sh: 9: ip: not found
Related: OS#4969
Change-Id: I95560868a899169bf0cb05a02d5034d9a77b6af7
Get rid of -nodefconfig, it has been removed in qemu 3.1. We are
supposed to use -no-user-config instead, which we already do.
Fix for this error we see since migrating to debian-bullseye:
qemu-system-x86_64: -nodefconfig: invalid option
Related: OS#4969
Related: https://qemu.readthedocs.io/en/stable/about/removed-features.html#nodefconfig-removed-in-3-1
Change-Id: I4a00f90980bf6d141ef8d86786e08d405db6db0b
Add ping, so ttcn3-tcpdump-start.sh from osmo-ttcn3-hacks.git works as
expected. It is supposed to wait until tcpdump is properly capturing
packets, by generating dummy packets with ping and waiting until the
pcap file gains size. However since ping is currently not installed, it
will just wait 10 seconds before executing tests.
Fix for:
Waiting for packet dumper to start... 0
Waiting for packet dumper to start... 1
Waiting for packet dumper to start... 2
Waiting for packet dumper to start... 3
Waiting for packet dumper to start... 4
Waiting for packet dumper to start... 5
Waiting for packet dumper to start... 6
Waiting for packet dumper to start... 7
Waiting for packet dumper to start... 8
Waiting for packet dumper to start... 9
Related: OS#4969
Change-Id: I46cf22e7eab7dcd4b3835a8c7aa48654aef6c65a
Add missing container for -latest tests. Currently this causes the
-latest tests to fail.
Related: OS#4969
Change-Id: I1230e87784bc21b5a6424db0bd8734181ead9bfd
The test suites require guile-2.0 so we have to stay with buster
and cannot upgrade to bullseye (guile-3.0 only).
Related: OS#4969
Change-Id: I30c05efbc6c7a21cad71b207e723ef958f1ac9be
So far we were using ancient Debian 9 (stretch) for our IUT
containers. Let's upgrade that to Debian 11 (bullseye).
Related: OS#4969
Change-Id: Ic6bece9cb695e6eccfcb1e83fdbf1048724a3cf9
So far we were executing all our TTCN-3 tests from a container
image with Debian stretch (9) plus a custom more recent eclipse-titan
package from the osmocom feed.
Let's update the container base OS from stretch (9) to bullseye (11)
while using the same packaged eclipse-titan version (8.0.0) for running
the tests. So this should be a low-risk change, as titan runtime
remains identical.
I've executed all test suites locally and couldn't see any regressions.
Related: OS#4969
Change-Id: Ib3bdfa3bec8f8ef42c55ca61cdee8fbca923874f
Support running multiple TTCN-3 testsuites in parallel when the
jenkins.sh scripts get called from outside of jenkins too.
Closes: OS#5358
Change-Id: Iaaf5719f758553687f2ab57975be275e7ac07e36
Before this patch the printing of the junit.xml to stdout fails:
+ collect_logs
+ cat '/tmp/tmp.CzafJpQyw8/*/junit-*.log'
cat: '/tmp/tmp.CzafJpQyw8/*/junit-*.log': No such file or directory
+ true
Change-Id: I600d3bdb3de23ef6f381cd5b81e2b851856b2b9b
I don't really see the point of crating 19 MBytes of logs for every
ttcn3-bsc-* test run that consists mainly of debug messages about
sending a message from left to right. osmo-stp is not the IUT here,
but merely a part of the test fixture. Let's reduce log verbosity.
Change-Id: If1d22814d89c4e52b3b7804110256d896b7cc99f
It seems a manual 'make' in the respective directories no longer
works, as always the default distro is used as upstream reference.
Let's work around this by adding DISTRO variable assignments to the
respective makefiles.
Change-Id: I8769d504ca7afde07d4a0ad1f03aaaec892bf576
This enables the test suite to obtain talloc reports between the
test case executions, which get stored together with the PCAP files.
Change-Id: I61fef7763e6445c231ff2664036e243a9ac96ff6
Related: Icd4c2d80db934535d499598282ed9416d8088163
It's better if we run ttcn3-bts-test with the default values, given
that they were significantly reduced some time ago.
Change-Id: If8438adfdbc506d2b6b7858ea8a0ea859ba246a1
Related: I7da3d0948f38e12342fb714b29f8edc5e9d0933d (osmo-bts)
Related: OS#4487
Adjust to the package not being split in rpm packaging. This was not
noticed before, because we did not run TTCN-3 tests for osmo-pcap with
CentOS8.
Related: SYS#5754
Change-Id: I775776ff7f358fee3d085f814c295c49225f5170
Don't attempt to install libosmo-netif in this Dockerfile. I've noticed
this because we want to build osmo-pcap for CentOS7 with this container
to run the TTCN-3 tests, and we don't have libosmo-netif for CentOS7.
Add pkgconfig(libosmogb), which is required to build osmo-pcap
according to configure.ac. In Debian, this gets installed as part of
libosmocore-dev.
Related: SYS#5754
Change-Id: I9c3a3b43ee7c25c06042f3303b9edb4005e7db31
Add dependencies for osmo-gsm-manuals, so we can build the release
tarballs for it (autoreconf -fi; ./configure; make dist-bzip2) in the
related jenkins job. During update of the list of projects for which we
build these tarballs, it became apparent that it was missing. Following
patches will add dependencies needed to build release tarballs for all
other projects that were missing from the list.
Related: OS#5347
Change-Id: Iba2e71b2e757bc527561d0f3e4a1af5f024a3cd7
Pull debian-stretch-titan from registry.osmocom.org if the repository is
enabled. Otherwise the image gets only pulled the first time, and does
not get updated once it becomes outdated.
Fixes: OS#5336
Change-Id: I1cf998c21e4ee1f723c3b783703e339328377f3e
Do not build debian-stretch-titan, when registry.osmocom.org is enabled.
The image that would be built at this point is not useful, since other
images like ttcn3-msc-test will use the debian-stretch-titan image from
the registry instead of the one that was just built locally.
Related: OS#5336
Change-Id: I7127e3ebac3a6a985c3ba50ba8c7cb8c5de978d9
The Iu/UMTS specific test cases in ttcn3-msc-test expect no
encryption in Security Mode Command by default (only integrity),
while osmo-msc would permit both UEA1 and UEA2 unless configured
explicitly. This causes the related test cases to fail.
A similar change was merged to osmo-ttcn3-hacks, updating the
osmo-msc.cfg in there, however the actual configuration file
that is used to execute test cases on Jenkins was not updated.
Change-Id: I43f80e3fbd73be21fb89006e16de0e1df9ba03f5
Related: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26389
Fixes: OS#5333