openbsc build broken due to new GSM_PCHAN value

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 -- - 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