- OpenBSC - lists.osmocom.org

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

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

06 Dec '18

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'

1 1

survey: doxygen
by Neels Hofmeyr 05 Dec '18

05 Dec '18

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

4 5

pySim patch - decode EF_[O|H]PLMNwAcT
by Daniel Laszlo Sitzer 04 Dec '18

04 Dec '18

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

2 2