OpenBSC January 2017

openbsc@lists.osmocom.org

24 participants
58 discussions

Build failure of network:osmocom:nightly/osmo-trx in xUbuntu_16.10/x86_64
by OBS Notification 17 Jan '17

17 Jan '17

Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… Package network:osmocom:nightly/osmo-trx failed to build in xUbuntu_16.10/x86_64 Check out the package for editing: osc checkout network:osmocom:nightly osmo-trx Last lines of build log: [ 119s] #define HAVE_SYS_TYPES_H 1 [ 119s] #define HAVE_SYS_STAT_H 1 [ 119s] #define HAVE_STDLIB_H 1 [ 119s] #define HAVE_STRING_H 1 [ 119s] #define HAVE_MEMORY_H 1 [ 119s] #define HAVE_STRINGS_H 1 [ 119s] #define HAVE_INTTYPES_H 1 [ 119s] #define HAVE_STDINT_H 1 [ 119s] #define HAVE_UNISTD_H 1 [ 119s] #define HAVE_DLFCN_H 1 [ 119s] #define LT_OBJDIR ".libs/" [ 119s] #define STDC_HEADERS 1 [ 119s] #define HAVE_BYTESWAP_H 1 [ 119s] #define TIME_WITH_SYS_TIME 1 [ 119s] [ 119s] configure: exit 1 [ 119s] dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking returned exit code 1 [ 119s] debian/rules:6: recipe for target 'build' failed [ 119s] make: *** [build] Error 2 [ 119s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [ 119s] [ 119s] lamb04 failed "build osmo-trx_0.1.9.20170117.dsc" at Tue Jan 17 19:54:41 UTC 2017. [ 119s] [ 119s] ### VM INTERACTION START ### [ 122s] [ 109.442861] reboot: Power down [ 122s] ### VM INTERACTION END ### [ 122s] [ 122s] lamb04 failed "build osmo-trx_0.1.9.20170117.dsc" at Tue Jan 17 19:54:45 UTC 2017. [ 122s] -- Configure notifications at https://build.opensuse.org/user/notifications openSUSE Build Service (https://build.opensuse.org/)

1 0

Build failure of network:osmocom:nightly/osmo-trx in xUbuntu_16.04/i586
by OBS Notification 17 Jan '17

17 Jan '17

Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… Package network:osmocom:nightly/osmo-trx failed to build in xUbuntu_16.04/i586 Check out the package for editing: osc checkout network:osmocom:nightly osmo-trx Last lines of build log: [ 145s] #define HAVE_SYS_TYPES_H 1 [ 145s] #define HAVE_SYS_STAT_H 1 [ 145s] #define HAVE_STDLIB_H 1 [ 145s] #define HAVE_STRING_H 1 [ 145s] #define HAVE_MEMORY_H 1 [ 145s] #define HAVE_STRINGS_H 1 [ 145s] #define HAVE_INTTYPES_H 1 [ 145s] #define HAVE_STDINT_H 1 [ 145s] #define HAVE_UNISTD_H 1 [ 145s] #define HAVE_DLFCN_H 1 [ 145s] #define LT_OBJDIR ".libs/" [ 145s] #define STDC_HEADERS 1 [ 145s] #define HAVE_BYTESWAP_H 1 [ 145s] #define TIME_WITH_SYS_TIME 1 [ 145s] [ 145s] configure: exit 1 [ 145s] dh_auto_configure: ./configure --build=i686-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/i386-linux-gnu --libexecdir=${prefix}/lib/i386-linux-gnu --disable-maintainer-mode --disable-dependency-tracking returned exit code 1 [ 145s] debian/rules:6: recipe for target 'build' failed [ 145s] make: *** [build] Error 255 [ 145s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [ 145s] [ 146s] lamb04 failed "build osmo-trx_0.1.9.20170117.dsc" at Tue Jan 17 19:54:15 UTC 2017. [ 146s] [ 146s] ### VM INTERACTION START ### [ 149s] [ 135.329906] reboot: Power down [ 149s] ### VM INTERACTION END ### [ 149s] [ 149s] lamb04 failed "build osmo-trx_0.1.9.20170117.dsc" at Tue Jan 17 19:54:19 UTC 2017. [ 149s] -- Configure notifications at https://build.opensuse.org/user/notifications openSUSE Build Service (https://build.opensuse.org/)

1 0

What hardware is needed for 3G
by Akib Sayyed 17 Jan '17

17 Jan '17

Dear list I would like to know what hardware is needed for running 3G network. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

3 5

AMR SID length?
by Max 17 Jan '17

17 Jan '17

Hi. There seems to be a disagreement between Osmocom libraries as to which is the length of AMR SID RTP payload. According to libosmocodec it's 7 bytes (see amr_len_by_ft in gsm690.c), according to libosmo-netif it's 6 bytes (see amr_ft_to_bytes in amr.c). However, than I look at 3GPP TS 26.101 Table 6 it seems like it should be 8 bytes. Reading http://www.rfc-base.org/txt/rfc-4867.txt did not shed a light except that it can't be lower than 5 bytes. Please help me out - what's the right number of bytes? -- Max Suraev <msuraev(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

jenkins.osmocom.org build slave
by Neels Hofmeyr 16 Jan '17

16 Jan '17

Previously I wrote about the "Broken Pipe" error sporadically causing our gerrit tests to fail for unknown reasons. To try and avoid those (successfully as it seems), I reduced the nr of executors for our OsmocomBuild1 debian slave to 2; used to be 6 IIRC. My argument was that 'make -j 9' would anyway utlize the resources, except during the python testing phase. But the build slave queue is getting awfully long sometimes and builds are just sitting and waiting for a long time. But when I 'top' on the build slave, I see the CPU idling between 50% and 90% ... assuming that the CPU activity in docker is also shown on the host OS. So now I increased the nr of executors to 3, seraching the optimum that still avoids the 'Broken Pipe' error. Would of course be much nicer to fix this particular curious failure and just hammer the nr of executors up to the roof again. ~N -- - 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

2 1

[PATCH 4/4] core/conv: Add optimized Viterbi decoding
by Vadim Yanitskiy 16 Jan '17

16 Jan '17

Hi Tom and all, After a quick look at the 4th patch, related to your optimized Viterbi decoder, I have noticed that currently the convolutional code definitions from the 'src/gsm/gsm0503_conv.c' are out of the 'tests/conv' test coverage... So, I would like to extend the test coverage. All I need are the test vectors, which I'll add to existing ones. Some of them I already found in your 4th patch, but some pending I need to write myself. Right now I have a simple question... Let's look at one example: { .name = "GSM RACH (non-recursive, flushed, not punctured)", .code = &gsm_conv_rach, .in_len = 14, .out_len = 36, // ??? .has_vec = 0, .vec_in = { }, .vec_out = { }, } As I noticed, the 'in_len' may be taken from the code definition: const struct osmo_conv_code gsm0503_rach = { .N = 2, .K = 5, .len = 14, // The 'in_len' is here! .next_output = xcch_output, .next_state = xcch_state, }; But I don't know how to calculate the 'out_len'... Could you please give me some hint? I already started to work on your 4th patch: https://gerrit.osmocom.org/1542 https://gerrit.osmocom.org/1543 With best regards, Vadim Yanitskiy.

1 1

jenkins env update
by Max 12 Jan '17

12 Jan '17

Hi. Please add autoconf-archive package to jenkins build slaves. It contains handy macro necessary for gerrit #1368. -- Max Suraev <msuraev(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

2 2

gerrit #1411, asan fix for egprs_puncturing_values
by Neels Hofmeyr 11 Jan '17

11 Jan '17

I would like to see https://gerrit.osmocom.org/#/c/1411/ fixed and merged. Firstly, the way the code is written leaves it unclear whether it works as intended. Secondly, this is blocking the effort to do more sanitizer builds in jenkins / gerrit build jobs. Aravind, would you please provide feedback on your availability -- will you get around to this any time soon, or should we try to assign this to someone else? Thanks! ~N -- - 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

2 3

redmine main page
by Neels Hofmeyr 10 Jan '17

10 Jan '17

I find the link https://osmocom.org/news/ quite valuable, but it's not easy to get there. I would expect a "News" link on http://osmocom.org to point there, so I placed one. We do have a "Planet" link -> http://planet.osmocom.org/ , which is currently broken. Firefox outright refuses to display it: the certificate is invalid/unknown/expired and the site is marked as "only show when secure", so one cannot add a security exception (fail: that should be the user's choice!). Chromium redirects to https://admin-trac.openmoko.org/trac/ ... doesn't match. So I took the liberty to remove the "Planet" link -- for now? All this by editing, in our redmine jail, file /usr/local/www/redmine-3.2.3/plugins/impressum_plugin/init.rb Feedback welcome! ~N -- - 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

4 9

Quectel EC20 question
by Petr Štetiar 10 Jan '17

10 Jan '17

Hi, according to a lot of sources one would think, that EC20 is based around the Qualcomm MDM9615, but the picture of naked EC20[1] clearly shows, that there is Qualcomm MDM9215 chip soldered on the board. Which source is true? :-) Or it's just a wrong text on that BGA? 1. https://osmocom.org/attachments/download/2501/ec20-naked-top.jpg -- ynezz

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2017