OpenBSC December 2018

openbsc@lists.osmocom.org

21 participants
34 discussions

build slave segfaults
by Neels Hofmeyr 12 Dec '18

12 Dec '18

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'

4 4

Re: Build failed in Jenkins: master-osmo-pcu » origin/nrw/litecell15,0,osmocom-master-debian9,lc15,True #1068
by Neels Hofmeyr 12 Dec '18

12 Dec '18

whoops, another one On Wed, Dec 12, 2018 at 01:22:09PM +0000, jenkins(a)lists.osmocom.org wrote: > make[1]: Entering directory '<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…'> > CXX gprs_debug.lo > CXX csn1.lo > CXX gsm_rlcmac.lo > CXX gprs_bssgp_pcu.lo > CXX gprs_rlcmac.lo > CXX gprs_rlcmac_sched.lo > CXX gprs_rlcmac_meas.lo > CXX gprs_rlcmac_ts_alloc.lo > gprs_bssgp_pcu.cpp:982:2: warning: #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" [-Wcpp] > #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" > ^~~~~~~ > CXX gprs_ms.lo > CXX gprs_ms_storage.lo > CXX gsm_timer.lo > CXX pcu_l1_if.lo > CC pcu_vty.lo > CXX pcu_vty_functions.lo > CC mslot_class.lo > CXX tbf.lo > CXX tbf_ul.lo > CXX tbf_dl.lo > /bin/bash: line 2: 9155 Segmentation fault /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"osmo-pcu\" -DPACKAGE_TARNAME=\"osmo-pcu\" -DPACKAGE_VERSION=\"0.5.1.38-5b52\" -DPACKAGE_STRING=\"osmo-pcu\ 0.5.1.38-5b52\" -DPACKAGE_BUGREPORT=\"osmocom-net-gprs(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"osmo-pcu\" -DVERSION=\"0.5.1.38-5b52\" -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/\" -DSTDC_HEADERS=1 -I. -I../include -Wall -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -fno-strict-aliasing -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -DENABLE_DIRECT_PHY -I<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…> -I./osmo-bts-litecell15 -Wall -ldl -pthread -g -O2 -MT tbf_ul.lo -MD -MP -MF $depbase.Tpo -c -o tbf_ul.lo tbf_ul.cpp > Makefile:779: recipe for target 'tbf_ul.lo' failed > make[1]: *** [tbf_ul.lo] Error 139 > make[1]: *** Waiting for unfinished jobs.... > make[1]: Leaving directory '<https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=or…'> > Makefile:466: recipe for target 'all-recursive' failed > make: *** [all-recursive] Error 1 > Build step 'Execute shell' marked build as failure > [WARNINGS]Skipping publisher since build result is FAILURE -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

1 0

vty expect script
by Neels Hofmeyr 12 Dec '18

12 Dec '18

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

1 0

voting in gerrit: merge at +3? (+2+1 / +1+1+1)
by Stefan Sperling 12 Dec '18

12 Dec '18

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

7 43

Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #321
by jenkins＠lists.osmocom.org 09 Dec '18

09 Dec '18

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

3 3

libosmocore builds non-concurrent
by Neels Hofmeyr 08 Dec '18

08 Dec '18

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

2 2

Rationale for having master builds in docker containers?
by Harald Welte 08 Dec '18

08 Dec '18

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)

6 8

building and publishing manuals for osmo-gsm-tester.git
by Oliver Smith 07 Dec '18

07 Dec '18

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

2 1

TTCN-3 failures of osmo-bsc-tests[-sccplite]
by Harald Welte 07 Dec '18

07 Dec '18

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)

2 2

jenkins build slaves: disks full
by Neels Hofmeyr 06 Dec '18

06 Dec '18

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

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2018