After a lot of work[1] the gsm tester can finally:
* Start a virtual bts
* Mobile/virtphy processes
* Complete LUs for 10 MS.
The next step (besides having a proper test verdict) is scaling this beyond what a simple physical set-up can provide. Let's go to 100+ BTS and 10k subscribers but somehow I am still holding it wrongly and would like to have feedback to see how to evolve the gsm tester.
What do I need to change to scale this up and how to externally parameterize it?
* suite.conf:
Add one line per virtual bts to reserve (I would prefer to specify type+num)
* resources.prod.conf:
Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs.
* register_default_mass.py:
I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable.
What's missing:
* High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is.
* ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool.
* IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers.
* Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change).
Any idea or comment on how to achieve this?
cheers
holger
[1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile but getting the GSM tester to spawn the network and we are unfortunately not done yet.
Hello Everyone
I was trying to set priority bit in paging type 1. I tried modifying the function rsl_paging_cmd in abis_rsl.c . But when i am checking the same in wireshark, I couldn't view it. Any help on this.
BR
Dear fellow Osmocom developers,
I'm a bit surprised to notice that not more people have signed up for
OsmoDevCon 2019. I guess it was mostly an oversight when the date was
originally announced, and not a lack of interest? ;)
All details about the event are available at the related wiki page at:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2019.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I have trx, bts, bsc, msc, stp, hlr, and sip installed...
asterisk runs on a separate machine, i.e. my ordinary pbx, with just the
recomended
changes to sip and extensions.
When dialling an external number I do not get any call progress
(ringing) in the MS.
Phone is quiet as I dial the number, when the call is answered voice is
"suddenly" there,
this is a difference from "latest" where call progress was audiable but
had only oneway audio.
I run HLR with the -U switch, there seems to be a difference between
"latest" and "nightly",
what does the -U switch do, modify the database, or just run HLR in
backward compatibility mode?
Should I delete / reregister phones?
Regards,
Gullik
Hie
My last work with osmo when it was an NITB. I noticed that with the new
split, we have sigtran SS7. I woul like to know if it can handle roaming
with other GSM networks.
Regards
shingy
Hi,
Where am I supposed to set initial rx-gain and tx-power ( tx-attenuation) ?
I see no suitable keywords in the BTS ( bts-uhd ) nor in the BSC.
btw, sdr is Ettus B100 driven by uhd-trx, and shows 10 dB attenuation.
Regards,
Gullik
Hello,
I have recently started to deploy OpenBSC . Initially I hope to
contribute to manuals and howtos
and with bug reports and testing. I have followed the suggested line,
and installed everything from
binarys, which puts for instance osmo-msc at 1.2.0. The platform is
Orange Pi Zero, and UHD / B100,
but will evolve to OPI Z + limesdr-mini.
I have encountered the "swapped address" bug reported some 3-4 months
ago, but is there in
osmo-msc 1.2.0, i.e. resulting in one way audio, since the sdp is
addressed to a byte reversed
address. Apart from that problem I have some minor stability issues
(more later ).
so, my entry #1
Latest .deb packages have an issue with requesting the RTP stream for
audio TO Mobile
with a bogus IP address:
16:20:17.739790 IP (tos 0x0, ttl 64, id 50362, offset 0, flags [none],
proto UDP (17), length 698)
orangepizero.lan.5065 > slottet.lan.sip: [udp sum ok] SIP, length: 670
INVITE sip:1000@192.168.1.80:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.1.170:5065;rport;branch=z9hG4bKcgB6KF1r9Z8Zj
Max-Forwards: 70
From: <sip:0757576000@192.168.1.170:5065>;tag=9U40t8B3a8p5r
To: <sip:1000@192.168.1.80:5060>
Call-ID: 590931be-7be8-1237-51bb-0242ed556d0c
CSeq: 938485738 INVITE
Contact: <sip:192.168.1.170:5065>
User-Agent: sofia-sip/1.12.11devel
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE,
SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Length: 129
v=0
o=Osmocom 0 0 IN IP4 170.1.168.192
s=GSM Call
c=IN IP4 170.1.168.192
t=0 0
m=audio 4036 RTP/AVP 0
a=rtpmap:0 GSM/8000
Asterisk on 192.168.1.80, osmo stack on 192.168.1.170,
Best Regards,
Gullik
Dear Osmocom community,
Who deals with configuration of nano3g ip.access here? How do you configure it?
We use the latest ip.access firmware that has a bunch of bugfixes and it doesn't
support "older" telnet configuration methodology:
https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_i…
So, do you just use other/older firmware or do you have TR069 ACS set up?
Kind regards,
Mykola
Re
commit 6cb833608fa39943c1ce9fe046992922e09f4266
rename CELL_IDENT_LAI_AND_LAC to CELL_IDENT_LAI
The name "LAI AND LAC" makes no sense because a LAC
is part of a LAI. Keep the old name available for
API backwards compatibility.
Change-Id: I2749cf75b7b45de0cd43cf4c696a6b6984f5a065
Related: OS#3124
I remember giving similar code review during the gsm0808_cell_ident patches,
and I think the conclusion was that even the specs speak of LAI_AND_LAC.
Well, anyway, I'm glad that sanity made it to the CELL_IDENT API finally :)
~N
Hello,
It is about how I got a voice working between UE connected to Osmocom 3G
(external call handling - Kamailio PBX) and VoIP softphone connected to the PBX.
The part about is IuUP only. (Transcoding comes later)
I have a traces of a call where a commercial NITB was used and I compared them
to traces which I got from a call where Osmocom system was used.
(Osmocom Core consisted of libosmocore of branch laforge/iu_up, osmo-mgw of
branch neels/iuup and other stuff from Nightly Builds)
My femtocell (nano3g ip.access) uses AMR 12.2k as a codec.
The difference in IuUP <-> AMR conversion between two.
When converting from IuUP to AMR:
- Osmo-mgw only strips IuUP header from RTP payload;
- Commercial NITB strips IuUP header and prepends AMR header to RTP payload;
When converting from AMR to IuUP:
- Osmo-mgw only prepends IuUP header to RTP payload;
- Commercial NITB strips AMR header and prepends IuUP header to RTP payload;
So that means basically that my femtocell sends AMR payload as IuUP payload
without AMR header. And expects AMR payload inside IuUP message without AMR
header.
IuUP header is 4 bytes. AMR header for octet-aligned mode is 2 bytes.
To test this I've modified the code of iuup_cn_node.c so that it does:
- when converting from IuUP data (rx_data): after stripping IuUP header it
prepends 0xf03c as a header (it is for AMR 12.2k).
- when converting to IuUP data (osmo_iuup_cn_tx_payload): before prepending IuUP
header it strips AMR header.
The call performed had voice on both sides. It was performed between a regular
phone connected to a femtocell and a VoIP softphone connected to Kamailio PBX.
Kind regards,
Mykola
Hi Community,
Does anyone successfully run a 3G network using OSMOCOM elements?
Currently we are trying to run the following OSMO elements using this URL "https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I….
Instead of using a 3G femto cell as HnodeB, does anyone tried to use UMTRX, B210, and LimeSDR?
Is there other software that will act as HnodeB between the SDR and OSMOHNBGW?
TIA.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Dear Osmocom community,
Did somebody try to use nano3g ip.access femtocells and Osmocom system with
external call handling? What I am trying to do is to make calls work between
VoIP phones connected to PBX and UEs connected to Osmocom system. I've tried two
PBXs: Kamailio with rtpengine and Asterisk. Signalling worked good between VoIP
phone and UE with both PBXs; calls between two UEs registered on Osmocom system
worked good also... But I fail to do transcoding (calls between VoIP phone and
UE). The problem is that it is unknown which codec is used by nano3g ip.access
femtocell.
So, the question is: Do you know what codecs were used for speech in your setup
with nano3g ip.access femtocells? Or do you know how to find out that
information? (It was stated by ip.access that they use AMR but I failed to match
AMR specs with RTP payload that was sent by femtocell...).
I would be very grateful for any ideas.
Kind regards, Mykola
There are obvious problems with the current +3 enforcing scheme on gerrit.
a) if a patch has +2, the summary shows a tick mark, you don't see that another
+1 is needed.
b) if a patch has three +1s, the summary shows +1, you don't see that it can be
merged.
c) voting +1 for an own patch has an effect on the mergability.
Ideas to improve:
a) +2 hides missing +1
On IRC, we agreed that it is a good idea to require two reviews (by two people)
-- three is too much. Currently that would be one +2 vote plus one +1 vote.
(alternatively 3x +1, too).
Idea: if we remove the "+2" ability, we avoid the problem that a +2 hides the
missing +1.
Everyone has only +1 votes, and we add up using that plugin.
To require only two reviews, we merge once a sum of +2 is reached.
b) 3x +1 == "+1"
There's no solution short of fixing what gerrit shows in the summary. Everyone
will still click on the patch and then see that it already has three votes.
c) +1 to self
The solution is that you don't vote for your own patches, unless it is
really super trivial and not worth wasting others' review time on.
Let's see for a few days how we fare with these quirks.
~N
Hi,
if anyone owns a sysmoBTS and either comes to 35c3 or can easily pass it on:
can we use your sysmoBTS for the GSM installation, please?
They will get insured by the event, we just need the serial number(s).
I might also ask you personally later this week / at sysmocom office.
Thanks!
~N
I see sporadic segfaults during jenkins builds every now and then...
Let's keep an eye on it.
This one built on build2-deb9build-ansible
~N
On Wed, Dec 12, 2018 at 12:52:59AM +0000, jenkins(a)lists.osmocom.org wrote:
> See <https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/IU=--enable-iu,WITH…>
>
...
> CC auth_milenage.lo
> /bin/bash: line 2: 6091 Segmentation fault (core dumped) /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -I/usr/include/p11-kit-1 -DBUILDING_LIBOSMOCORE -Wall -Wall -g -O2 -DBUILDING_LIBOSMOCORE -Wall -MT auth_milenage.lo -MD -MP -MF $depbase.Tpo -c -o auth_milenage.lo auth_milenage.c
> make[3]: *** [auth_milenage.lo] Error 139
> Makefile:582: recipe for target 'auth_milenage.lo' failed
> make[3]: *** Waiting for unfinished jobs....
> make[3]: Leaving directory '/build/deps/libosmocore/src/gsm'
Hi Keith,
I'm now using your vty expect script from
https://gerrit.osmocom.org/#/c/osmo-dev/+/11811/ in our congress gsmcore setup,
and I absolutely love it!
I tweaked the logging, and next to it I also put vty_sticky, which re-opens the
vty when the program gets restarted. Attached my current versions.
Such a simple and nice way to customize logging, easily attach and detach,
quickly change some log levels... much simpler than navigating journalctl.
Thanks for that!
~N
There has been some face-to-face discussion about Osmocom's code review
process within sysmocom recently. I am posting to this list now with the
consent of everyone involved so far, in order to involve the Osmocom
community at large in this discussion as well.
There has been a lack of code review from people who don't have "+2"
super powers in Gerrit. This applies to anyone among us, independently
of any individual's relationship with sysmocom. The bulk of the work
involved in reviewing code falls on Harald's shoulders, with Pau and
Neels sharing most of the rest between themselves.
At present, while people who add a +1 have their voices heard, their
input does not formally affect the decision to merge a change.
A change still has to pass by the pre-selected +2 gatekeepers in order
to be merged, no matter how many other people have provided input.
The implication for developers without +2 powers is that their time
is more effectively spent on advancing their own changes towards
a +2 vote, rather than spending time on whatever else is waiting
in Gerrit. This may not apply to everyone, of course. But at least
for me, this is certainly the case; I have only been reviewing other
people's patches when I was explicitly asked to do so.
Myself and several other developers hope that with a change to our review
process we can fix this inertia, spread code review across more shoulders
and encourage more collaborative code review in Osmocom.
The basic idea is that everyone's input should count for something.
If those among us with +1 powers were given a partial say on the fate
of every change, our decisions will carry more weight and our influence
within the project will slightly increase. We'd also be encouraged to step
out of our own corners of expertise every now and then, and look at what
other developers are working on. On the flip side, this means we'd carry
more responsibility than we do now. We wouldn't always be relying on our
+2 gate keepers and would have to apply our own judgement more carefully.
The concrete proposal is to make votes in Gerrit accumulative.
Each change would require a total score of +3 to be merged. This score can
consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes.
Also, +2 developers would keep their ability to unilaterally block or revert
changes under this new model. They'd keep their existing role as arbiters
in case of disputes.
Max figured out how Gerrit could be configured for this behaviour.
It involves Prolog code, but since we're all quite smart we should be able
to figure that out, right?
https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_…
We'd be interested to hear what the community thinks about this proposal.
Thanks,
Stefan
See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/321/display/redire…>
------------------------------------------
[...truncated 1.18 MB...]
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking dependency style of gcc... gcc3
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether g++ supports C++11 features by default... yes
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for rm... /bin/rm
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether byte ordering is bigendian... no
checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOCTRL... yes
checking for UHD... no
checking for UHD... yes
checking whether C++ compiler accepts -msse3... yes
checking whether C++ compiler accepts -msse4.1... yes
checking whether gcc has __builtin_cpu_supports built-in... yes
checking for LIBUSB... yes
checking for FFTWF... yes
checking boost/config.hpp usability... yes
checking boost/config.hpp presence... yes
checking for boost/config.hpp... yes
CPPFLAGS=""
CFLAGS="-g -O2"
CXXFLAGS="-g -O2"
LDFLAGS=""
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating CommonLibs/Makefile
config.status: creating GSM/Makefile
config.status: creating Transceiver52M/Makefile
config.status: creating Transceiver52M/arch/Makefile
config.status: creating Transceiver52M/arch/common/Makefile
config.status: creating Transceiver52M/arch/arm/Makefile
config.status: creating Transceiver52M/arch/x86/Makefile
config.status: creating Transceiver52M/device/Makefile
config.status: creating Transceiver52M/device/uhd/Makefile
config.status: creating Transceiver52M/device/usrp1/Makefile
config.status: creating Transceiver52M/device/lms/Makefile
config.status: creating tests/Makefile
config.status: creating tests/CommonLibs/Makefile
config.status: creating tests/Transceiver52M/Makefile
config.status: creating doc/Makefile
config.status: creating doc/examples/Makefile
config.status: creating contrib/Makefile
config.status: creating contrib/systemd/Makefile
config.status: creating doc/manuals/Makefile
config.status: creating config.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 8
make all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
Making all in doc
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc'
Making all in examples
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples'
Making all in manuals
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc'
Making all in CommonLibs
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
CXX BitVector.lo
CXX LinkedLists.lo
CXX Sockets.lo
CXX Threads.lo
CXX Timeval.lo
CC trx_vty.lo
CXX Logger.lo
CC debug.lo
CXXLD libcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs'
Making all in GSM
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
CXX GSMCommon.lo
CXXLD libGSM.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM'
Making all in Transceiver52M
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Making all in arch
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch'
Making all in common
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common'
CC convolve_base.lo
CC convert_base.lo
CC fft.lo
CCLD libarch_common.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common'
Making all in x86
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86'
CC convolve.lo
CC convert.lo
CC libarch_sse_3_la-convolve_sse_3.lo
CC libarch_sse_3_la-convert_sse_3.lo
CC libarch_sse_4_1_la-convert_sse_4_1.lo
CCLD libarch_sse_4_1.la
CCLD libarch_sse_3.la
ar: `u' modifier ignored since `D' is the default (see `U')
ar: `u' modifier ignored since `D' is the default (see `U')
CCLD libarch.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86'
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch'
Making all in device
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device'
Making all in uhd
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd'
CXX UHDDevice.lo
CXXLD libdevice.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd'
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
CXX radioInterface.lo
CXX radioVector.lo
CXX radioClock.lo
CXX radioBuffer.lo
CXX sigProcLib.lo
CXX signalVector.lo
CXX Transceiver.lo
CXX ChannelizerBase.lo
/bin/bash: line 2: 11309 Illegal instruction /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I../CommonLibs -I../GSM -I./arch/common -I./device -lpthread -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -MT signalVector.lo -MD -MP -MF $depbase.Tpo -c -o signalVector.lo signalVector.cpp
Makefile:729: recipe for target 'signalVector.lo' failed
make[3]: *** [signalVector.lo] Error 132
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Makefile:833: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M'
Makefile:516: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx'
Makefile:447: recipe for target 'all' failed
make: *** [all] Error 2
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 2313 C/C++ compilation units (100%) successfully
2313 C/C++ compilation units (100%) are ready for analysis
For more details, please look at:
/home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure
I'm noticing that the libosmocore gerrit builds actually wait for each single one to finish.
I guess we can turn on concurrent builds there? ... osmith? :)
~N
Hi!
I'm currently wondering why on earth we'd be running our master builds
inside docker containers on the build slaves.
According to https://git.osmocom.org/osmo-ci/tree/jobs/master-builds.yml
we're currently building the following projects inside a container:
* openbsc.git
* osmo-bsc.git
* osmo-mgw.git
* osmo-msc.git
* osmo-sgsn.git
but none of the others.
AFAIR, Holger originally introduced the dockerized builds for speeding
up the build tests? I'm not sure how that
In terms of the history that we have on the jenkins job builder files in
osmo-ci.git, the dockerized builds in master-builds.yml were copied from
the gerrit-verifications.yml. But the git history of course doesn't go
back to why the [manual jenkins jobs] used the docker container in the
first place.
My line of thought would be to have [at least] all master builds run
natively on the build slave. They are all generated by ansible these
days, and should contain a well-defined environment.
Any comments?
Regards,
Harald
p.s.: The underlying topic is that SSH agent forwarding doesn't exceed
into the docker container, and hence it is not possible to use jenkins
credentials for uploading resulting build artefacts such as the
manuals...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi everyone,
the manuals have been moved to the project specific repositories. I'm
wondering what's the best way implement gerrit build verification and
publishing the manuals for osmo-gsm-tester.git.
With typical Osmocom projects, we have gerrit-verifications.yml and
master-builds.yml, which build the projects when patches land in gerrit
and when commits are merged to master. The latter is also able to
publish the generated PDFs. No osmo-gsm-tester related jobs are created
in both configs so far. Instead, there is a section in
osmo-gsm-tester_runner.yml, which generates the osmo-gsm-tester_gerrit job.
This osmo-gsm-tester_gerrit job works differently than the
gerrit-verifications and master-builds jobs; they do not seem to have
the osmo-ci scripts available (which are used to build and install
dependencies and to clean up the workspace). The way I've implemented
building and publishing manuals in the other projects makes use of both
scripts (the dependency that gets installed is osmo-gsm-manuals, which
has the shared manuals content).
So far, the osmo-gsm-tester_gerrit job runs a few smoke test to make
sure that the osmo-gsm-tester is not completely broken. It does not do a
full run, as this would take 15 hours.
I see the following solutions now:
a) remove osmo-gsm-tester_gerrit and add an entry in
gerrit-verifications and master-builds instead. Then implement
manuals building and publishing just like in the other projects.
b) extend osmo-gsm-tester_gerrit to build manuals, without the osmo-ci
scripts (so it's maybe 10 more lines of shell code), and create an
entry in master-builds for publishing the manuals (together with a
new jenkins script, e.g. contrib/jenkins-publish-manuals.sh)
c) do not do build the manuals in osmo-gsm-tester_gerrit, but keep that
job and add an *additional* job in gerrit-verifications just for
building the manuals (also add the same job in master-builds to build
and publish the manuals).
Regarding c), I am not sure how this would look like in gerrit. Two jobs
would get triggered for each new patch, but jenkins should only give the
verification +1 if both jobs ran through - can it do that?
Regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi all,
after osmo-bsc doesn't crash running the TTCN3 tests anymore, we have integration
result tests again. Thanks to Daniel for looking into this. Please let's all
work together to ensure a situation like this doesn't persist for week[s] ever
again in the future.
Looking at the results, I see the following deterioration of test results:
1) TC_chan_exhaustion consistently fails since build 421. This is a clear
regression. If I would have to take a guess, I would suspect some dynamic
PDCH related changes could have had an impact on this. I've created
https://osmocom.org/issues/3721 to track this one. If anyone feels like
he has some knowledge on what caused the regression on Nov 22nd/23rd,
please take this issue.
2) TC_paging_resp_unsol was newly introduced and failed from day one.
It was introduced by Pau related to OS#3680 (making T3113 dynamic).
Hoewver, even though we have merged the patch to make it dynamic,
the test still fails. @pau: Please investigate. Maybe we simply need
to update the config file?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
We recently hit a bunch of jenkins failures, due to a full disk.
Just now I removed 172G worth of docker images from build2-deb9build-ansible;
I thought we had the docker cleanup automated by now?
Even after that, build-2 still uses 244G of its root file system, which doesn't
seem right. most of it is also in the deb9build-ansible lxc:
root@build-2 /var/lib/lxc/deb9build-ansible/rootfs # du -hs * | sort -h
[...]
2.2G opt
5.8G usr
8.1G tmp (what!
33G home
153G var
The tmp/ has many folders like
196M tmp.u3y02wgBNI
which are all from March to May this year. I will delete them now.
home:
root@build-2 /var/lib/lxc/deb9build-ansible/rootfs/home/osmocom-build # du -hs *
0 bin
19G jenkins
14G jenkins_build_artifact_store
1.2G osmo-ci
Interesting, I wasn't aware of us using the artifact store.
Seems to come from some manual builds between April-October.
Removing.
jenkins workspaces of 19G seems ok.
But osmo-ci of 1.2G!?
That seems to be a manual build of the coverity job -- though the date is
pretty recent, so is our coverity job actually building in
~osmocom-build/osmo-ci instead of in a workspace?
Even after the docker cleanup commands I used from the osmocom.org servers wiki page:
docker rm $(docker ps -a -q)
docker rmi $(docker images -q -f dangling=true)
There are still 321 docker images around, most of which are months old.
Not sure why above cleanups don't catch those.
I'm just going to indiscriminately blow all of them away now.
Maybe a good cleanup strategy would be to every week or so automatically wipe
out the entire build slave lxc and re-create it from scratch?
After this, we have on build-2:
Filesystem Size Used Avail Use% Mounted on
/dev/md2 438G 83G 333G 20% /
------ host-2
Similar story on host-2 deb9build-ansible lxc: tons of docker images, just removed all of them.
But after that we still have
root@host2 ~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md2 438G 311G 105G 75% /
On host-2 though there are a lot of services running.
root@host2 / # du -hs * | sort -h
[...]
1.2G usr
59G var
75G home
176G external
[...]
2.7G gerrit
3.1G redmine-20170530-before-upgrade-to-3.4.tar
4.3G mailman
5.7G openmoko-wiki
7.8G gitolite
9.9G openmoko-people
29G redmine
112G jenkins
root@host2 /external/jenkins/home/jobs # du -hs * | sort -h
171M nplab-m3ua-test
198M master-osmo-pcu
241M ttcn3-sip-test
251M osmo-gsm-tester_build-osmo-bsc
262M ttcn3-ggsn-test
287M gerrit-osmo-ttcn3-hacks
297M master-osmo-bsc
322M master-libosmo-sccp
328M osmo-gsm-tester_build-osmo-sgsn
355M master-osmo-mgw
359M master-libosmo-netif
365M osmo-gsm-tester_build-osmo-iuh
390M gerrit-asn1c
392M gerrit-osmo-bsc
419M ttcn3-nitb-sysinfo
445M osmo-gsm-tester_build-osmo-msc
456M osmo-gsm-tester_manual-build-all
461M master-libosmocore
461M TEST_osmocomBB_with_libosmocore_dep
482M master-osmo-iuh
611M master-osmo-sgsn
704M gerrit-osmo-bts
748M master-osmo-msc
756M gerrit-osmo-msc
929M master-openbsc
1.1G master-osmo-bts
1.1G ttcn3-hlr-test
1.2G gerrit-libosmocore
1.2G ttcn3-mgw-test
1.9G osmo-gsm-tester-rnd_run
2.0G ttcn3-sgsn-test
3.0G ttcn3-msc-test
3.2G osmo-gsm-tester_run
3.5G master-asn1c
4.2G ttcn3-bsc-test-sccplite
4.7G osmo-gsm-tester_run-rnd
6.2G osmo-gsm-tester_gerrit
6.3G osmo-gsm-tester_run-prod
7.5G osmo-gsm-tester_ttcn3
8.5G ttcn3-bsc-test
43G ttcn3-bts-test
It seems we are caching 211 ttcn3-bts-test builds. That seems a tad much.
Indeed https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/configure
has "[ ] Discard old builds" (unchecked).
Looking in osmo-ci, the jobs/ttcn3-testsuites.yml has no 'build-discarder' set.
I guess we should add one? Any discard option preferences? A month? A year?
(compare master-builds.yml)
----- admin-2
It seems I can not login there, or at least I don't know the IP address...
ssh: Could not resolve hostname admin2.osmocom.org: Name or service not known
So I guess I can't check there.
~N
See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/318/display/redire…>
------------------------------------------
Started by timer
Building remotely on build2-deb9build-ansible (ttcn3 osmo-gsm-tester-build osmocom-gerrit-debian9 osmocom-master-debian9 coverity) in workspace <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/>
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git://git.osmocom.org/osmo-ci
> git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/> # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/>
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:772)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to build2-deb9build-ansible
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:955)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1028.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy79.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1146)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/"> returned status code 1:
stdout:
stderr: <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/.git>: No space left on device
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770)
... 11 more
ERROR: Error cloning remote repo 'origin'
Hi all,
we have doxygen API doc in libosmocore. The doxygen format, even though well
defined, is often a distraction from code review because we often fail to get
it right and need another review cycle.
I'm looking for ways how I don't need to write review on doxygen comments.
Ideas:
- We introduce hard doxygen validation in the gerrit jobs.
Difficulties:
- we'd probably first need to fix *all* current doxygen errors.
- we'd need to add doxygen to all projects, because some of us add doxygen
comments even there, and it is odd to use the format but fail to do it
right.
- there is no way to make sure the initial summary is ended in '.',
because the script cannot understand human semantics.
- I don't think anyone uses it. So we could just drop doxygen.
(I find it much more useful to just browse the code with ctags.)
If we drop doxygen, we can just use the comments whichever way we like, omit
'.' whereever and I don't need to nitpick on it. And we can drop all those
\param and \a and \ref bits that break the flow of reading a C comment.
libosmocore is the only git tree actually building doxygen docs.
OTOH, when removing doxygen, would we also drop all those \file and other
section markers?
- Or, I stop giving a damn about doxygen and let everyone commit all sorts of
doxygen formatting errors, because no-one is reading the HTML version anyway.
thoughts welcome...
~N
Hello everyone,
I implemented decoding of the [O|H]PLMNwAcT elementary file in pySim.
Here https://github.com/lazlo/pysim-dec-plmn you will also find unit tests
for the code I wrote.
Let me know if I should further refactor the code (maybe to use more of the
existing conversions functions in pySim/util.py). I'm aware it is not the
most elegant code but it does its job.
Best,
Lazlo
See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/315/display/redire…>
Changes:
[Oliver Smith] cosmetic: gerrit-verifications: format docker cmd
------------------------------------------
[...truncated 670.25 KB...]
from ../../include/osmocom/ranap/RANAP_CriticalityDiagnostics-IE-List.h:14,
from RANAP_CriticalityDiagnostics-IE-List.c:7:
../../include/osmocom/ranap/RANAP_CriticalityDiagnostics-IE-List.h:28:23: warning: ‘struct MemberG’ declared inside parameter list will not be visible outside of this definition or declaration
A_SEQUENCE_OF(struct MemberG {
^
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^~~~
../../include/osmocom/ranap/RANAP_CriticalityDiagnostics-IE-List.h:28:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct MemberG {
^~~~~~~~~~~~~
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0,
from ../../include/osmocom/ranap/RANAP_MessageStructure.h:14,
from RANAP_MessageStructure.c:7:
../../include/osmocom/ranap/RANAP_MessageStructure.h:27:23: warning: ‘struct MemberL’ declared inside parameter list will not be visible outside of this definition or declaration
A_SEQUENCE_OF(struct MemberL {
^
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^~~~
../../include/osmocom/ranap/RANAP_MessageStructure.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct MemberL {
^~~~~~~~~~~~~
CC RANAP_ClassmarkInformation3.lo
CC RANAP_CN-ID.lo
CC RANAP_CN-DomainIndicator.lo
CC RANAP_Correlation-ID.lo
CC RANAP_CSFB-Information.lo
CC RANAP_CSG-Id.lo
CC RANAP_CSG-Id-List.lo
CC RANAP_CSG-Membership-Status.lo
CC RANAP_DataPDUType.lo
CC RANAP_DataVolumeReference.lo
CC RANAP_DataVolumeReportingIndication.lo
CC RANAP_DCH-ID.lo
CC RANAP_DeliveryOfErroneousSDU.lo
CC RANAP_DeliveryOrder.lo
CC RANAP_DeltaRAListofIdleModeUEs.lo
CC RANAP_NewRAListofIdleModeUEs.lo
CC RANAP_RAListwithNoIdleModeUEsAnyMore.lo
CC RANAP_ForwardingIndication.lo
CC RANAP_DL-GTP-PDU-SequenceNumber.lo
CC RANAP_DL-N-PDU-SequenceNumber.lo
CC RANAP_D-RNTI.lo
CC RANAP_DRX-CycleLengthCoefficient.lo
CC RANAP_DSCH-ID.lo
CC RANAP_EARFCN-Extended.lo
CC RANAP_E-DCH-MAC-d-Flow-ID.lo
CC RANAP_ENB-ID.lo
CC RANAP_EncryptionAlgorithm.lo
CC RANAP_EncryptionInformation.lo
CC RANAP_EncryptionKey.lo
CC RANAP_End-Of-CSFB.lo
CC RANAP_EquipmentsToBeTraced.lo
CC RANAP_E-UTRAN-Service-Handover.lo
CC RANAP_Event.lo
CC RANAP_Event1F-Parameters.lo
CC RANAP_Event1I-Parameters.lo
CC RANAP_ExtendedGuaranteedBitrate.lo
CC RANAP_ExtendedMaxBitrate.lo
CC RANAP_ExtendedRNC-ID.lo
CC RANAP_FrameSequenceNumber.lo
CC RANAP_FrequenceLayerConvergenceFlag.lo
CC RANAP_GANSS-PositioningDataSet.lo
CC RANAP_GANSS-PositioningMethodAndUsage.lo
CC RANAP_GeographicalArea.lo
CC RANAP_GeographicalCoordinates.lo
CC RANAP_GA-AltitudeAndDirection.lo
CC RANAP_GA-EllipsoidArc.lo
CC RANAP_GA-Point.lo
CC RANAP_GA-PointWithAltitude.lo
CC RANAP_GA-PointWithAltitudeAndUncertaintyEllipsoid.lo
CC RANAP_GA-PointWithUnCertainty.lo
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0,
from ../../include/osmocom/ranap/RANAP_IE-Extensions.h:15,
from ../../include/osmocom/ranap/RANAP_GeographicalCoordinates.h:16,
from ../../include/osmocom/ranap/RANAP_GA-Point.h:14,
from ../../include/osmocom/ranap/RANAP_GeographicalArea.h:14,
from RANAP_GeographicalArea.c:7:
../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:23: warning: ‘struct Member’ declared inside parameter list will not be visible outside of this definition or declaration
A_SEQUENCE_OF(struct Member {
^
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^~~~
../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct Member {
^~~~~~~~~~~~~
CC RANAP_GA-PointWithUnCertaintyEllipse.lo
CC RANAP_GA-Polygon.lo
CC RANAP_GA-UncertaintyEllipse.lo
CC RANAP_GERAN-BSC-Container.lo
CC RANAP_GERAN-Cell-ID.lo
CC RANAP_GERAN-Classmark.lo
CC RANAP_GlobalCN-ID.lo
CC RANAP_GlobalRNC-ID.lo
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0,
from ../../include/osmocom/ranap/RANAP_GA-Polygon.h:14,
from RANAP_GA-Polygon.c:7:
../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:23: warning: ‘struct Member’ declared inside parameter list will not be visible outside of this definition or declaration
A_SEQUENCE_OF(struct Member {
^
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^~~~
../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct Member {
^~~~~~~~~~~~~
CC RANAP_GTP-TEI.lo
CC RANAP_GuaranteedBitrate.lo
CC RANAP_HigherBitratesThan16MbpsFlag.lo
CC RANAP_HS-DSCH-MAC-d-Flow-ID.lo
CC RANAP_IMEI.lo
CC RANAP_IMEIGroup.lo
CC RANAP_IMEIList.lo
CC RANAP_IMEISV.lo
CC RANAP_IMEISVGroup.lo
CC RANAP_IMEISVList.lo
CC RANAP_ImmediateMDT.lo
CC RANAP_IMSI.lo
CC RANAP_IncludeVelocity.lo
CC RANAP_InformationExchangeID.lo
CC RANAP_InformationExchangeType.lo
CC RANAP_InformationRequested.lo
CC RANAP_InformationRequestType.lo
CC RANAP_InformationTransferID.lo
CC RANAP_InformationTransferType.lo
CC RANAP_IntegrityProtectionAlgorithm.lo
CC RANAP_IntegrityProtectionInformation.lo
CC RANAP_IntegrityProtectionKey.lo
CC RANAP_InterSystemInformationTransferType.lo
CC RANAP_InterSystemInformation-TransparentContainer.lo
CC RANAP_IPMulticastAddress.lo
CC RANAP_IuSignallingConnectionIdentifier.lo
CC RANAP_IuTransportAssociation.lo
CC RANAP_KeyStatus.lo
CC RANAP_LA-LIST.lo
CC RANAP_LAC.lo
CC RANAP_LAI.lo
CC RANAP_LastKnownServiceArea.lo
CC RANAP_LastVisitedUTRANCell-Item.lo
In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0,
from ../../include/osmocom/ranap/RANAP_LA-LIST.h:14,
from RANAP_LA-LIST.c:7:
../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration
A_SEQUENCE_OF(struct MemberA {
^
/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^~~~
../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct MemberA {
^~~~~~~~~~~~~
CC RANAP_LHN-ID.lo
CC RANAP_Links-to-log.lo
CC RANAP_ListOF-SNAs.lo
CC RANAP_ListOfInterfacesToTrace.lo
CC RANAP_InterfacesToTraceItem.lo
CC RANAP_LoadValue.lo
CC RANAP_LocationRelatedDataRequestType.lo
CC RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.lo
CC RANAP_LocationReportingTransferInformation.lo
CC RANAP_ReportChangeOfSAI.lo
CC RANAP_PeriodicReportingIndicator.lo
CC RANAP_DirectReportingIndicator.lo
CC RANAP_L3-Information.lo
CC RANAP_M1Report.lo
CC RANAP_M2Report.lo
CC RANAP_M4Report.lo
CC RANAP_M4-Collection-Parameters.lo
CC RANAP_M4-Period.lo
CC RANAP_M4-Threshold.lo
CC RANAP_M5Report.lo
CC RANAP_M5-Period.lo
CC RANAP_M6Report.lo
CC RANAP_M6-Period.lo
CC RANAP_M7Report.lo
CC RANAP_M7-Period.lo
CC RANAP_Management-Based-MDT-Allowed.lo
CC RANAP_MaxBitrate.lo
CC RANAP_MaxSDU-Size.lo
CC RANAP_MBMS-PTP-RAB-ID.lo
CC RANAP_MBMSBearerServiceType.lo
CC RANAP_MBMSCNDe-Registration.lo
CC RANAP_MBMSCountingInformation.lo
CC RANAP_MBMSHCIndicator.lo
CC RANAP_MBMSIPMulticastAddressandAPNRequest.lo
CC RANAP_MBMSLinkingInformation.lo
CC RANAP_MBMSRegistrationRequestType.lo
CC RANAP_MBMSServiceArea.lo
CC RANAP_MBMSSessionDuration.lo
CC RANAP_MBMSSessionIdentity.lo
CC RANAP_MBMSSessionRepetitionNumber.lo
CC RANAP_MDT-Activation.lo
../../libtool: line 1748: 1801 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.3.0.11-319c\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_MBMSLinkingInformation.lo -MD -MP -MF .deps/RANAP_MBMSLinkingInformation.Tpo -c RANAP_MBMSLinkingInformation.c -o RANAP_MBMSLinkingInformation.o > /dev/null 2>&1
../../libtool: line 1748: 1802 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.3.0.11-319c\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_MBMSSessionDuration.lo -MD -MP -MF .deps/RANAP_MBMSSessionDuration.Tpo -c RANAP_MBMSSessionDuration.c -o RANAP_MBMSSessionDuration.o > /dev/null 2>&1
../../libtool: line 1748: 1800 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.3.0.11-319c\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_MBMSRegistrationRequestType.lo -MD -MP -MF .deps/RANAP_MBMSRegistrationRequestType.Tpo -c RANAP_MBMSRegistrationRequestType.c -o RANAP_MBMSRegistrationRequestType.o > /dev/null 2>&1
[ERROR] capture: cannot update build log: No space left on device
[ERROR] capture: cannot update build log: No space left on device
[ERROR] capture: cannot update build log: ../../libtool: line 1751: 1808 Aborted $RM $removelist
No space left on device
../../libtool: line 1751: 1809 Aborted $RM $removelist
../../libtool: line 1751: 1807 Aborted $RM $removelist
Makefile:2506: recipe for target 'RANAP_MBMSLinkingInformation.lo' failed
make[4]: *** [RANAP_MBMSLinkingInformation.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
Makefile:2506: recipe for target 'RANAP_MBMSRegistrationRequestType.lo' failed
make[4]: *** [RANAP_MBMSRegistrationRequestType.lo] Error 1
[ERROR] capture: cannot update build log: No space left on device
Makefile:2506: recipe for target 'RANAP_MBMSSessionDuration.lo' failed
make[4]: *** [RANAP_MBMSSessionDuration.lo] Error 1
gcc: internal compiler error: Aborted (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
[ERROR] capture: cannot update build log: Makefile:2506: recipe for target 'RANAP_MBMSSessionIdentity.lo' failed
make[4]: *** [RANAP_MBMSSessionIdentity.lo] Error 1
No space left on device
../../libtool: line 1751: 1814 Aborted $RM $removelist
Makefile:2506: recipe for target 'RANAP_MBMSIPMulticastAddressandAPNRequest.lo' failed
make[4]: *** [RANAP_MBMSIPMulticastAddressandAPNRequest.lo] Error 1
RANAP_MBMSServiceArea.c:142:1: fatal error: closing dependency file .deps/RANAP_MBMSServiceArea.Tpo: No space left on device
};
^
compilation terminated.
Makefile:2506: recipe for target 'RANAP_MBMSServiceArea.lo' failed
make[4]: *** [RANAP_MBMSServiceArea.lo] Error 1
[ERROR] capture: cannot update build log: No space left on device
../../libtool: line 1748: 1790 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.3.0.11-319c\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_MDT-Activation.lo -MD -MP -MF .deps/RANAP_MDT-Activation.Tpo -c RANAP_MDT-Activation.c -fPIC -DPIC -o .libs/RANAP_MDT-Activation.o
Makefile:2506: recipe for target 'RANAP_MDT-Activation.lo' failed
make[4]: *** [RANAP_MDT-Activation.lo] Error 1
[ERROR] capture: cannot update build log: No space left on device
../../libtool: line 1748: 1796 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.3.0.11-319c\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_MBMSSessionRepetitionNumber.lo -MD -MP -MF .deps/RANAP_MBMSSessionRepetitionNumber.Tpo -c RANAP_MBMSSessionRepetitionNumber.c -fPIC -DPIC -o .libs/RANAP_MBMSSessionRepetitionNumber.o
Makefile:2506: recipe for target 'RANAP_MBMSSessionRepetitionNumber.lo' failed
make[4]: *** [RANAP_MBMSSessionRepetitionNumber.lo] Error 1
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src/ranap'
Makefile:642: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src'
Makefile:454: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src'
Makefile:458: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh'
Makefile:382: recipe for target 'all' failed
make: *** [all] Error 2
/home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/emit/build2-deb9build-ansible/emit-db: UPDATE CovBuildInvocation SET refct = $COV_BINDING1 WHERE (CovBuildInvocation.rowid = $COV_BINDING2) ;: disk I/O error [write]
Build step 'Execute shell' marked build as failure