Some unit tests in those repositories started failing due to a fix in
libosmocore logging system where extra coloring tags were printed when not
needed.
Unit tests in current master of those repositories are fixed to work with
both old and new versions of libosmocore since they got coloring disabled
in their output, and new patch releases have been done containing the
fix, which means last releases already work with both libosmocore
version. However, older releases are expected to fail when built against
libosmocore master.
Change-Id: I03ca926b903a4dcc9967ab5fe455d715cdb9ed45
The osmo-python-tests will be used to test vty commands.
The old python2 package are only required to test old images because
the current master is only supporting python3.
Installing both doesn't conflict because the python site-packages are
different for the two version.
Change-Id: Ica279e83b763389ababb526336ebd95d45beee7a
This reverts commit e17a4d66d0, i.e.
we are back to building the latest tag, now that v20.07.1 has been
released, which actually builds again.
However, the package name in debian/changelog has not been updated to
reflect that version change, resulting in v20.07.1 being packaged
in a package called v20.07.0.
Change-Id: I01b77f03924a0b303103fb737dfee15b9c4b0c9c
overlayfs2 should be the default anyway. Enable it on all hosts,
since it was enabled on older hosts.
Change-Id: I20728d6017204c3978e23376baa89de6e91fed1e
See https://github.com/myriadrf/LimeSuite/issues/313
This also reverts the previous commits that removed the work-around for
building LimeSuite on Debian10, as that one is still required for
v20.01.0 (and not for v20.07.0).
Change-Id: Ib70418f0b8a4c6aafa3098b6fa3e240f89112b59
As of yesterday (upstream commit fdfe3d340506a7de4f41d74296e1f32a906700f2),
LimeSuite upstream finally builds without patches on Debian 10
Change-Id: Ibbed53f57ac750f39ea20ac73c28c4773c244a6f
We used to install patchelf 0.10 in a specific path to only use it for
some binaries which had bugs with patchelf 0.9 (and other binaries had
bugs with 0.10, so we couldn't use 0.10 for all binaries and hence put
it in binary).
However, 0.11 is fixing both issues so we can use it in all cases, hence
we can put it in PATH (/usr/local/bin).
Related: OS#4389
Change-Id: Ica30807ecab7b60daee31fe7824b7c848d20c904
There was a directry refactoring a few weeks ago in osmo-gsm-tester and
this path was not updated correctly.
Change-Id: I580cd9d4a602b3ed1839fb0990ac3816c5e42cbe
The only part that we haven't migrated elsewhere is osmo-bsc_nat,
which is also really unmaintained at this point. Let's not confuse
people into thinking they should actually use this software anymore.
Change-Id: Icee165422a52bfe04be103a5b7ebb5c8909c0321
common.sh tries to set OSMO_CI_DIR now; however this does not work when
common.sh was sourced with ". ./common.sh":
realpath: scripts/..: No such file or directory
Fixes: 7cb8e2d0 ("OBS: add debian10 specific patch for limesuite")
Related: https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/455/console
Change-Id: Ib326eb0fa769528398335c9cf06dc9c9576c882e
Fill the "next" feed with source packages generated from the "next"
branch of each Osmocom project, if it exists, with fallback to the
"master" branch. Implement as wrapper around osmocom-nightly-packages.sh,
so we don't duplicate code and don't need to add more logic to the jenkins
job.
Adjust all osmo_obs_prepare_conflict calls. Add a comment line on top of
each osmocom-*-packages.sh script stating the feed they can be used with.
Related: SYS#4887
Change-Id: I0542b6243bdd29d08381fcc82368dcbd30bf9dce
For the upcoming network:osmocom:next repository, it would be
inconsistent to have the debian package conflict mechanism only support
latest and nightly, even if the next repository is currently not built
for debian.
Change-Id: I2c07313fbbdffe5571e447059b08fe74c853cef0
Rename osmocom-debian-install.yml to repo-install-test.yml to get debian
out of the name. Extend it with a new distro parameter and update the
description. Adjust the shell section to run the script from its new
location (in osmo-ci.git, not docker-playground.git). Turn it into a
matrix job, so we can have two parameters (distro, feed) for each job.
Related: OS#4563
Change-Id: I777098f19d75f7efbd68b837ccdcd83309429c39
The "run-inside-docker.sh" script is running as root (in order to be
able to install packages). Do not mount an outside directory as /data
inside the image anymore, where the script would write temporary data.
This causes problems on jenkins, as the temporary files are written as
root and jenkins is then unable to wipe the workspace.
I had used this for debugging when I wrote the script initially, but
almost the same can be done now with INTERACTIVE=1 and cat on the
temporary files.
Related: OS#4563
Change-Id: If7e1d83580c2951e7e50181ba7e755b987675e4b
Keep downloaded binary packages to make test cycles shorter during
development. While at it, also document all environment variables.
Change-Id: I4d6ebaf460e47f29e023acb0bd78ef52ca80c7cd
Make it consistent with run-inside-docker.sh by also using -e and -x.
This makes development easier.
Change-Id: I733164829bf076fb42df3fde725f3e330f8abecc
Make the script work on a debian10 host. I had developed it initially on
debian9, where this was not necessary, and the Jenkins servers are also
running debian9. Fixes:
Failed to mount tmpfs at /run/lock: Permission denied
[!!!!!!] Failed to mount API filesystems, freezing.
Freezing execution.
Change-Id: I5127356031a5dd080473aa650c2beae2a81a697f
Prepare the repo-install-test to be extended to cover centos8 as well.
Move the scripts to osmo-ci.git first, so we can mount them as shared
files into the docker containers from here.
Move files without any changes. Integration will be done in a follow-up
commit, so we have a clean git log.
debian-repo-install-test/jenkins.sh
=> scripts/repo-install-test.sh
debian-repo-install-test/testdata/blacklist.txt
=> scripts/repo-install-test/blacklist.txt
debian-repo-install-test/testdata/repo-install-test.sh
=> scripts/repo-install-test/run-inside-docker.sh
Related: OS#4563
Related: If93f37e8d46597a9abc67a4529be9addd65780f5 (docker-playground)
Change-Id: Ia678cc15e66630bd6b75b6c89bc75c1e27afd66c
The list is incomplete, and we have a programmatic check for required
binaries in common-obs.sh now. The next patch will add a new one of
these scripts, so let's clean it up a bit.
Change-Id: Ifab635e0d7a162142a8e80f3223d024888114f3f
Add a patch to replace libwxgtk3.0-dev with libwxgtk3.0-gtk3-dev in
debian/control. Adjust OBS scripts to apply such patches from this
repository if they exist here, and fall back to the project's
repository (osmo-trx, osmo-gsm-manuals patches are there).
Related: OS#4562
Change-Id: I8dfb60e999bf9f61e6cd11983dba033a4c6107ad
Refactor checkout_copy_debian8_jessie from osmocom-latest-packages.sh
and osmocom-nightly-packages.sh to take the distribution name as
argument and merge both to osmo_obs_checkout_copy in common-obs.sh.
Use debian8 as distribution name instead of debian8-jessie, so the
distribution name matches the suffix of the patch file
(build-for-debian8.patch).
A follow-up commit will apply a debian10 specific patch with this new
function.
Related: OS#4562
Change-Id: I2b69571ebc08a920c9147ce544fa8a2e6d950e65
Prevent the following error:
ERROR: please install obs-service-format_spec_file or use the --noservice option
Build step 'Execute shell' marked build as failure
Related: https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/976/console
Change-Id: Ib2fbaace47b3c12462860419f19b01a5b4d192e8
osmocom-*-packages.sh take some time to execute and has quite a few
programs that are not commonly installed. Check the required
dependencies first, so it doesn't abort in the middle of the scripts if
these are missing. I just ran into this with the new meson dependency.
Change-Id: I46cf1aeedd61dbd4fc8fa3f24c60e29033339ead
sdcc does not build for centos 8 without diving deeper into the
dependency hell:
nothing provides gputils,
nothing provides python3-base,
nothing provides inkscape,
nothing provides lyx,
nothing provides makeinfo
So let's not build libusrp for centos 8 for now. We can build osmo-trx
without the usrp1 backend (already configured in the spec.in file).
Related: OS#4550
Change-Id: Icfb289b0eeeb7215d23517fb8a4e56f2a8d774f1
Use existing osmocom-*-packages.sh scripts to add RPM spec.in files. Set
the same version, as in the debian .dsc files.
Related: OS#4550
Change-Id: If93b9d95e4c18cf1c29594c0802cbffaea27101c
Since osmo-gsm-tester.git Change-Id Ieca65b71b543c44cfcec8e83efd0fe053c432e55,
the -c parameter holds the config file and not the directory where it is contained.
Change-Id: I9aca57c4dd3180367eb17ec92177b90a9c411a6a
As of osmo-gsm-tester.git Change-Id
I7eb69f870d0dcb5906d45ae067d6bed1aabf5862, jenkins-run.sh script uses
the sysmocom value by default, so let's avoid setting it to simplify
stuff.
Change-Id: I8edfb93d53376930f60e0bd8d36a82ec6c11ed85
osmo-gsm-tester needs it in rfemu_amarisoftctrl.py to connect to
Amarisoft CTRL interface (which is implemented through a websocket).
Change-Id: Iab03cfdcfb1c197ae002d95e0bb56d86e0aac97b
Harald Welte
Neels Hofmeyr
Pau Espin
Oliver Smith