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
signature.asc
Description: Digital signature
