Build fixed in 17a6bab150bd70954b00645c8d1f18ce3ccf8948 https://gerrit.osmocom.org/568

I pushed the commit through without peer review to fix the build, so maybe have a look whether I need to improve something.

~Neels

On Sun, Jul 24, 2016 at 01:11:33PM +0200, Neels Hofmeyr wrote:

Just to let you know, the addition of GSM_PCHAN_TCH_F_TCH_H_PDCH in libosmocore implicitly broke the ctrl interface tests in openbsc.

FAIL: testBtsChannelLoad (__main__.TestCtrlBSC)

Traceback (most recent call last): File "./ctrl_test_runner.py", line 237, in testBtsChannelLoad self.assertEquals(r['value'], 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0') AssertionError: 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0 unknown 0xb,0,0' != 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0'

because this is unexpected output: "unknown 0xb,0,0"

So *any* commit submitted to openbsc will currenty fail. I'll probably fix it shortly with a commit to openbsc...

This also directed my attention towards the pchan_load mechanics. It always shows a TCH/F_PDCH entry, but in PDCH mode those would not have any load. I guess it makes sense in the current scheme of things, though it could make even more sense to record channel load not as separate TCH/F_PDCH but in the TCH/F slot, depending on current pchan mode? Similarly for upcoming TCH/F_TCH/H_PDCH: record in the TCH/F or TCH/H slot according to current pchan mode... (For now I'm focusing on completion of TCH/F_TCH/H_PDCH usability, if at all pchan_load tweaks would come later)

~Neels