Do not build these utils implicitly if libsqlite3/libpcap/libcdk are
installed. Add configure flags for explicit building and fail if
dependencies are missing.
Keep behavior in deb and rpm packaging:
* deb: build meas_vis
* rpm: build none of these (libcdk dependency for meas_vis is not
available in most rpm-based distributions we build for)
Fixes: OS#5173
Depends: docker-playground I015b6d7cb834e99ea5d04206ba5f8c519c4e6af1
Change-Id: I8b3d5efb769437a5d3036e1e627b8d477275d93e
There is no such option in the configure.ac:
configure: WARNING: unrecognized options: --enable-vty-tests
Change-Id: I04421af0b250651a598a7aeb5bed55dbacec2f7c
cat-testlogs.sh does "exit 1", so no workspace.tar.xz is created.
Call this script after archiving the workspace.
Change-Id: Ibcb842f32418e66a186d6b21bb5861cf4a0b7c4a
Fixes: d33a66b779 "contrib/jenkins: create workspace.tar.xz on error"
Related: OS#5665
In order to figure out why we sometimes get a coredump in the jenkins
master jobs, add a quick hack to get all relevant binaries on libraries
on error.
Related: OS#5665
Change-Id: I1439c06316edbe11f162c14774c2d507152b97a7
As pointed out in code review, for nanobts we need to be able to combine
the reported features with a list of features we assume that the bts
model supports. This is because the enum of features is based on what
nanobts is able to report, but was extended for osmo-bts.
Related: SYS#5922, OS#5538
Change-Id: I7bdbf28c148877275048e070dce7f503ca5e6226
Make sure we don't check against bts->model->features instead of
bts->features by accident.
Related: SYS#5922, OS#5538
Change-Id: I47eef4978aaf9e20fc00a3ca029568671bd09d8d
Run "make maintainer-clean" after publishing manuals, not the other way
around. Otherwise jenkins.sh fails when running for the master branch,
because docs/manuals/Makefile gets deleted although it is still needed
to publish the manuals.
Related: OS#3047
Fixes: 471fd92170 ("contrib/jenkins.sh: run "make maintainer-clean"")
Change-Id: I8ba5369b0948b61c68f43d807312c52465119aa5
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: Ief6ce94013612a968183e82abef421f116ed37c3
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
The libosmocore version requirements are fine already but for jenkins
tests to pass we have to have Ic77866ce65acf524b768882c751a4f9c0635740b
merged into libosmocore master.
Change-Id: Ia57bf1300525cf3c247284fe966b1c415c2d53e2
Related: OS#1694
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I9b6afb59f0a8037d1510a7fddb63927f10d653e5
There is no Iu in a BSC, this was from old times with OsmoNITB. This
configure option now lives in osmo-msc.git
Change-Id: I9cf1c430855fe8a59fea1cf0abb3242c38d45cea
smpp_mirror is maintained in osmo-msc.git, so let's remove it
(and the associated libsmpp34 build requirement).
Change-Id: Ia7b242cc52cf261b1a5dd3c287da2868e1a2b9a8
This is the OsmoBSC project. Disabling the build of the BSC would be
somewhat odd, so let's remove the option.
Also, OsmoBSC depends on libosmo-sccp now, so we must unconditionally
depend on it. As a result, we can remove the --enable-nat option,
as this was only to avoid a mandatory libosmo-sccp requirement in
historical times.
Change-Id: Icfee8a904d33b7c13ab8d185d64fb5c2337d8640
Rewire build and includes to libosmo-legacy-mgcp.
Drop osmo-bsc_mgcp and related python tests, now found in osmo-mgw.git.
libosmo-legacy-mgcp is installed from osmo-mgw, hence add the dependency to
jenkins.sh (so far using the pre_release branch).
Change-Id: Ic99d681759edce11564da62500c2aac5cf5fffe2
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.
Implement AoIP in osmo-msc and osmo-bsc.
Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.
From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN
jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.
Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
Necessary since libosmocore I513835be2d931d0a931cdfc996f361a451bc1a15
removes the script from libosmocore/contrib.
Change-Id: I02d7e1c0151c687fd9341d21a09ca15cbf5a1938
Enable various components according to the build matrix during make distcheck.
Add python tests, osmo-bsc, nat, ...
Change-Id: Ic724cf61d44409337414dc58c8795896b4b97a8a
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
We are building with libosmo-sccp tag 'old_sua' until the new sigtran has
been applied. Since osmo-iuh commit
0f88c110093935305143987638e46dc6db304a3e
"migrate osmo-hnbgw to libosmo-sigtran's SCCP/M3UA"
osmo-iuh requires libosmo-sccp master. A similar 'old_sua' tag is in place in
osmo-iuh.git, to match libosmo-sccp 'old_sua'. Do that to fix the jenkins
build of --enable-iu.
Change-Id: I70f731db0b74ed48ae6dd713ed4c3247222ef0de
Have a bash function to build each dependency with the same commands. There is
a tradeoff: having each dependency build with the same function means you can't
easily tweak one of the dependencies. OTOH having a unified function means a)
more readable script, b) that we're sure not to forget some steps and c) no
need to do the same edit n times.
Set the PKG_CONFIG_PATH globally. Also a tradeoff: if a future addition
wouldn't need the same PKG_CONFIG_PATH, this would make things ugly. But that
is actually quite unlikely, and the readability improvement is substantial.
Use env variables to remember local paths. That means we always are sure to cd
to the same absolute base path, which a 'cd ..' can't guarantee; also, we avoid
possible typos for e.g. "$deps/install".
Change-Id: Ib23f86c6cc1441d882de59bcdde5de87fa4e9fdf
Oliver Smith
Vadim Yanitskiy
Pau Espin
Max
Harald Welte
Neels Hofmeyr
Philipp Maier