VTY and CTRL tests pass fine with python3. Drop the python2 requirement,
so we can use debian 12 in CI. Some of the files in openbsc/contrib
probably still need python2, but since this is a legacy project we
probably don't care.
Related: OS#5950
Change-Id: I052c59dcc21b8e1dd4a3460cf8af9ccbeed6de5b
Build without this script, as it is being removed from osmo-ci.git in
favor of using ccache. See Id94d6126b476077d57839e4a884621b8c034f0c6
for reasoning.
Related: OS#5848
Change-Id: Ib3272feec76b30412ca60dec204255b64e33831b
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I2697ec547468019a544b66daf9dbb58aa8d9772b
Related: OS#5034
* add messages at start-up and to the VTY
* users must explicitly confirm they want to run osmo-nitb
Change-Id: I5d5c0ff386dbc2e7b7dd02d6c33d1f9fec70707b
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I3371783e04c7bce12d11d6f9cc7021bf290489ea
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ie884be1f3e1d5ead912aafd0a78e1a0a97258ab8
Fixes: OS#4865
It's really not used and only adds unneeded variabilities to output.
Older libosmocore versions had a bug where extra color format characters
were printed while newer versions have that fixed.
Fixes: OS#4759
Change-Id: Idce85aa355d334929d8abdf5b99dad0622ecff58
Those adoc files are only used by osmo-bsc.git and openbsc.git
(osmo-nitb), and the later is deprecated and no longer maintained, which
means new features are only added to BSC. Hence it makes no sense to
keep the doc shared between both. As a result, they will be dropped from
osmo-gsm-manuals.git and we keep an unmodified copy here.
Change-Id: Ic3b4192238be3147f61779845521eae84511fb7e
Backport of osmo-bsc 6b9e0e4e8834428f85f169106ed7b6141f5b185b (1)
and 60d6d530ac6883db4f5c0394541ad654ddfd526c (2)
(1) TS 48.058 sec 8.4.1 CHANNEL ACTIVATION and state:
"""
The BS and MS Power Parameters elements are included to indicate that BS
and/or MS power control is to be performed by BTS. The maximum power to
be used is indicated in the BS and MS Power elements respectively.
"""
Since we always want the BTS to do autonomous MS power control, let's
add it.
(2)Send IE MS Power Param to osmocom BTS models only
Since MS Power Param IE content is operator dependant, it's currently
not known which kind of content non-osmocom BTS support/allow, so let's
avod possibily breaking those BTS until each BTS has been checked
separately.
Change-Id: Ieb51d5f2202ebd2861d3c33f2b5598e6b29d78eb
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: Id7d006f892198bb8a7c0d4a8a8ea00b8d0e62df4
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: I7d9d477b983b0d62f01237d90acaa7ce455c3c3d
Related: OS#4138
The function is never called in osmo-bsc-nat, and logging_vty_add_cmds()
is called directly in main().
Change-Id: Ie13cf5dc7f8dfa6fc6c3953dfcacaed7d5feb114
RFC3435 states most text (except SDP) must be handled as case
insensitive.
Since we are no longer using strstr(msg->l2h), we need to iterate per
line and call related extract/handle function for that line.
Call to bsc_mgcp_osmux_confirm() is left at the end because it needs to
be called too in case no matching line is found. In that case, it will
release the CID. Similar stuff ocurrs for bsc_mgcp_extract_ci().
Related: OS#4001
Change-Id: Iadc004064a5a237c93009f242cb943ebc4d2d7e6
libdbi on debian unstable (at least)
outputs: "no table in statement !"
breaking the db_test.
Redirect stdout to /dev/null and restore
after the function completes.
Closes OS#4016
Change-Id: I8227aa8fa44d3237019db52dd0825f827797261b
There's no real need to allocate it using talloc. Allocating it on the
stack simplifies the code, avoids mem leaks and makes it faster.
Change-Id: I66c44890952339f15131081e2f629a2824b6d3ba
In bsc_nat_parse(), parsed is allocated this way:
"""parsed = talloc_zero(msg, struct bsc_nat_parsed);"""
So parsed is a child of msg, and so it's freed when msg is freed.
Since libosmocore c7f52c4c84d6a8898048738c4db9266289c40b45,
osmo_wqueue_enqueue() correctly detects queue full and returns an error,
and then queue_for_msc() calls msgb_free(). Code in osmo-bsc-nat was
probably written before that change in behavior, so that's why probably
the bug was not hit before.
The "if (parsed)" condition is removed since it's actually fine to
talloc_free(NULL).
Related: SYS#4548
Change-Id: I209d3e2d809a67915ec43c874e68f7f746a565f0
According to documentation (and personal experience), AM_PATH_PYTHON
selects the highest version of python, no matter if major version is
different, which means if both python2 and 3 are available, 3 will be
chosen an PYTHON will point to "/.../python" which is python3. Apparently,
the macro cannot be easily used to pick highest python2 version.
chosen an PYTHON will point to "/.../python" which is python3. Apparently,
the macro cannot be easily used to pick highest python2 version.
As {vty,ctrl}_test_runner.py require python2 and are incompatible with
python3, let's instead rely on the system having a "python2" binary
available, which is the case in most distros.
cherry-picked from: osmo-bsc.git 7e78681f0f740bd68ed5255b506a1efa08a231b1.
Change-Id: Icc147c8457116ad551d166313f3a79e1c2107a22
Might be useful in the future for its callers, since sometimes actions
need to be taken place based on whether enqueuing failed (and msg was
freed).
Change-Id: I9f172f9c9ca9db18f6adcf9267db23c73e9d5bc6
Oliver Smith
Vadim Yanitskiy
Pau Espin
Harald Welte
Pau Espin Pedrol
Keith Whyte
Daniel Willmann