Instead of filtering with several blacklist_* files that must contain
the exact names of packages to be filtered, add a shell function that
uses fnmatch for filtering. Combine all lists into one.
This fixes the error we get with each limesuite release, without the
need to increase the version in the txt files every time. Currently the
repo-install-tests are failing for all debian versions because of this.
Change-Id: I6745b10804685119d68b089f129ec9b0cde8cdf5
Don't attempt to install limesuite-images. It runs a post-install script
that downloads files from an external server and fails currently, as
there are no images for 23.10. While we have limesuite-images packages
in our OBS repository, this is just a side-effect of building limesuite.
What we are really interested in is liblimesuite for osmo-trx, as I
understand.
Add --no-install-recommends to the apt-get install line in
install_repo_packages_debian, because the main limesuite package has
limesuite-images in recommends and would pull it in otherwise.
Change-Id: I237408c805977c831f352a57a301ea45753d1ac1
The repo-install-test started to fail on debian 10 with the following
error. Apparently this happens when installing ca-certificates-java
after installing java. Add a workaround.
Setting up ca-certificates-java (20190405) ...
head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or directory
Exception in thread "main" java.lang.InternalError: Error loading java.security file
Change-Id: I00b9c97d9d85fb37ba33a48caa732cd50de99683
Allow overriding the downloads.osmocom.org domain of the url where
packages are downloaded from, so we can download them from
people.osmocom.org instead while developing / debugging, e.g.:
https://people.osmocom.org/packages/home:/osmith:/nightly/
Change-Id: I36bc0eae9fdee75512c1dbdca84cd6224b8c192a
Don't check the osmo-upf service until it's fixed, so we don't miss
other errors that repo-install-test may find.
Related: OS#5905
Change-Id: I970cad1bdb4586afa8ba5b4dac31bb9ac02b7b2d
Apparently the output of repoquery isn't always sorted, it started
failing on jenkins after moving the test inside qemu. Add an explicit
sort.
Fix for:
+ comm -23 osmocom_packages_all.txt blacklist.txt
comm: file 1 is not in sorted order
Related: OS#5365
Change-Id: Icb00df102555e06b66b1c2597488b625e3c77f1c
While I'm developing this, Jenkins is currently failing here. Make it
easier to debug this by printing the file contents.
Related: OS#5365
Change-Id: Ifbf4ca7f49c1f4441f84695aea0936515e01ffd4
The DISTRO variable is either debian10 or debian11, fix the broken
check. This condition is there in the first place, because we don't
build the usrp1 backend for centos8.
Change-Id: I987f27db257961faf06824df2dcc8f9db1fedccf
Related: OS#5365
Add services from new projects and enable previously disabled services,
now that this test runs in qemu and services have more permissions like
setting realtime priorities.
Related: OS#5365
Change-Id: Iec7db433cac4c77226e0f1ae2ba502de0d1a8a2b
Change repo-install-test to run inside of qemu instead of docker. This
job needs to run systemd to verify that the systemd services start up
properly. Running systemd inside docker was never officially supported,
it worked with cgroups1 but does not work anymore with cgroups2.
An alternative approach was running inside podman instead of docker
(running systemd inside of podman is officially supported). However we
would have needed various workarounds with podman and wouldn't be able
to test all Osmocom systemd services in the end, due to lack of
permissions (see review of I394918fc61de36acce65ffb33defcb8fc21801c4).
By running with a separate kernel inside qemu we can run all Osmocom
services.
Related: OS#5365
Change-Id: Ie7f1bccb05779cb3614016c0b965b810bbb1471b