Instead of calling various foo_debian and foo_centos8 versions with
foo_$DISTRO, create new foo functions that call the right
distro-specific function based on debian* or centos* being in DISTRO.
Rename all foo_centos8 functions to foo_centos.
This is in preparation to run this script with debian10 too, not just
debian9. This can also be used to test a different centos version in the
future.
Related: OS#4969
Change-Id: Ibb9f93af16af7ebe947f7efcd4e709f3e62d12c0
Install one Osmocom package from one package feed and attempt to install
a second package from a different feed. Verify that the package manager
exits with error and mentions the conflict in its output.
Related: OS#4733
Change-Id: Icf2a3a1d1de2ff42b1dc9aadf2075e5e1ff40291
Prepare for future conflicts test, which will configure repositories
with a different PROJ.
Related: OS#4733
Change-Id: Ib9946b5a02f8692efc8515907ba84048026474f9
Download and add the release key for the debian repository from OBS.
This is useful for manually testing the existing tests with a different
PROJ for debugging, and it will be used by a future conflict test to
install a second repository (e.g. nightly and latest at the same time).
Note that this is not needed for rpm, because the dnf package manager
automatically downloads the key if it is missing.
Related: OS#4733
Change-Id: I91e7a208d8f5cb50f8baa2fde0eb979aae91da8f
Use $PROJ instead of $FEED in the repository name, so we can add $PROJ
as parameter to the repo configuration functions later without worrying
about having a matching $FEED.
Related: OS#4733
Change-Id: Ic316add6b2d9b6f50335cad762628bb16da61d82
Don't call the file osmocom-latest regardless of the feed name. This becomes
important in a future conflict test where we will have two repositories
from two feeds configured.
Related: OS#4733
Change-Id: I8926443a9ff70f285d9467d39658e64456972b07
Move the two debian-specific variables to the debian-related functions
where they are used. Both are only used once, and having them global is
misleading since the test isn't just for debian anymore, but also for
centos8.
Make the variables lowercase to indicate that they aren't used globally.
Related: OS#4733
Change-Id: I1dfddbd9311d741c03ceedb12aee9aeae6abdab8
Make debugging easier by having a PROJ variable that can be overridden
by an environment variable of the same name. Pass it to docker and use
it to generate all related URLs etc.
Add functions in run-inside-docker.sh to convert the PROJ variable into
the two other formates needed (with slashes, with underscore), so a
future patch can use these functions with a different PROJ variable too.
Related: OS#4733
Change-Id: I0ac05a79ad65b5664b5ba37227b65e3b1422a4bf
Create a rpmlint config, which makes the shlib-fixed-dependency check
non-fatal, as it caused builds for openSUSE_Leap_15.2 to fail. The check
is supposed to warn about libraries depending on specific versions of
other packages. However, for the nightly and next packages, this is
exactly what we want to do to ensure that users will always upgrade all
Osmocom packages to the builds from a specific day, and not mix them.
Messages from the check:
[ 307s] libosmocodec0.armv7hl: E: shlib-fixed-dependency (Badness: 440) osmocom-nightly = 1.0.0.202101181006
...
[ 307s] libosmovty4.armv7hl: E: shlib-fixed-dependency (Badness: 440) osmocom-nightly = 1.0.0.202101181006
[ 307s] Your shared library package requires a fixed version of another package. The
[ 307s] intention of the Shared Library Policy is to allow parallel installation of
[ 307s] multiple versions of the same shared library, hard dependencies likely make
[ 307s] that impossible. Please remove this dependency and instead move it to the
[ 307s] runtime uses of your library.
[ 307s]
[ 307s] (none): E: badness 3960 exceeds threshold 1000, aborting.
Related: OS#4733
Related: https://en.opensuse.org/openSUSE:Packaging_checks#Disarming_Fatal_Errors
Change-Id: I560b4adf80b5785d396a17afefa590559ad5ca5a
Now that we have the proper fix of making a clone of
osmo-gsm-manuals.git available before builds start, and not using
'osmo-build-dep.sh osmo-gsm-manuals' in the contrib/jenkins.sh files
anymore, we can remove the temporary solution. This reverts commit
4cbc445616.
Related: OS#4912
Depends: https://gerrit.osmocom.org/q/topic:jenkins-no-manuals-dep
Change-Id: I88d57ee04775dc75e6ca3152d7edfa7f47608c8a
Make sure that each time osmocom-nightly-packages.sh and
osmocom-next-packages.sh runs, we get a different date appended to the
versions, even if it runs twice on the same day (e.g. because the
jenkins job was triggered manually).
This is in preparation to let all packages depend on a specific version
(with that date) of the conflicting dummy package.
DT in osmocom-latest-packages.sh is adjusted for consistency (though it
is not appended to the package versions, only used in the commit message
when pushing the latest packages).
Related: OS#4733
Change-Id: I7f08c694a549f1b3dd938a68e05082f2c31fdb92
Rename $spec to $spec_in and add $spec to hold the destination path, to
avoid constructing it multiple times below.
Related: OS#4733
Change-Id: I4f3d4f8a8bc83ff22983e49f6a496dc8318b53cd
Check if we are trying to make a package depend on itself, and skip in
that case. This happens for the osmocom-nightly etc. metapackages, as
they go through the same code path as regular packages. While at it, use
proper variable names in the function.
Add the new variable as second argument and not as third, because a
fourth argument will be added with the dependency version, and because
this order will be consistent with osmo_obs_add_rpm_spec() when it gets
extended in a future commit.
Fix the following warning:
W: osmocom-nightly source: package-depends-on-itself osmocom-nightly depends
Related: OS#4733
Change-Id: I439079c00259d73a18cb8617a3e76d05df5a7a35
Change name to osmo_obs_add_depend_deb. I'll add a _rpm function in a
future patch, and so we get consistent names.
Related: OS#4733
Change-Id: Icf444b86df993184c9fe4db8d3e67ab4bb06bd47
Move logic to create the package directory, change into it, and to put
the directory into a git repository and tag it with the package version,
into the common function. Again, in preparation to add a _rpm function.
Related: OS#4733
Change-Id: I3066147ef5469cce9d269b119d9ffa3e53f00403
Prepare to move the 'put in git repository' code from _deb to the main
function by having the pkgver available outside of the _deb function.
Change the version to 1.0.0 while at it, as it looks better than 0.0.0.
Related: OS#4733
Change-Id: Ic56ff12b5f2fe596d73b341e1e7750a9e202ed6b
Prepare to add the _rpm function by moving the debian code to its own
function and tweaking the comment above the function.
Related: OS#4733
Change-Id: Ic8d55c432c6035e7ac855cf6869d2c86ace468df
Prepare to add another function that creates similar dummy packages for
rpm (current version only works for deb).
Related: OS#4733
Change-Id: I29a5f54fe3a09610cffa0eacb5f0ad99154612f7
Save time by only cloning the repository, and not running autoreconf
-fi, ./configure, make and make install. Especially the tests during
make took up significant time, that slowed every project depending on
osmo-gsm-manuals down while being built through master-builds or
gerrit-verifications jobs. Set OSMO_GSM_MANUALS_DIR to the clone
location.
This is an interim measure, I'll submit more patches soon that remove
the 'osmo-build-dep.sh osmo-gsm-manuals' calls from all projects.
Change-Id: I5238cf3f93ded97ed2b44d27868123a646e122dc
Related: OS#4912
We use centos8 instead of centos in all docker-playground.git setups and
the infrastructure there expects that kind of naming.
Related: OS#4888
Change-Id: Idfbb2c4fc1ca10741406c8ab8930dabe8ce632ee
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
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
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
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
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
Oliver Smith
Alexander Couzens
Harald Welte
Pau Espin