This bug aims to point on bugs linked to spandsp API breakage and to see how we should fix that: masking most versions of spandsp (>=0.0.3 ), patching breaked package if possible, masking breaked packages. At the moment, we have: media-libs/libsupertone breaks with >=0.0.6 net-misc/asterisk-app_rtxfax breaks with >= 0.0.3 (a patch can move to >=0.0.5) I was not able to test: net-libs/libmfcr2 net-misc/asterisk-chan_unicall
0.0.6_pre12 has been added to the tree but according to so naming, there is no API change. But, we should probably also test this version to get a real state of the spandsp-related breakage in the tree.
spandsp-0.0.6_pre12 isn't breaking anything more than other versions. Here is a detailed status: Compilation succesfull with 0.0.6_pre12: - media-radio/svxlink - net-misc/asterisk-1.6.1* Compilation success but no link so a running test is recommanded: - net-libs/libunicall - net-misc/asterisk-spandsp_codec_g726 Need to be tested with zaptel: - net-libs/libmfcr2 - net-misc/asterisk-chan_unicall Not working with at least 0.0.6*: - media-libs/libsupertone - net-misc/asterisk-app_rtxfax
I'm adding asterisk-1.6 unmasking as blocked because of this because. Indeed, it needs a new version of spandsp. I think a valid fix would be to remove: - net-misc/asterisk-chan_unicall - media-libs/libsupertone - net-libs/libmfcr2 (needs libsupertone, only used by asterisk-chan_unicall) And we will have to fix yate. As asterisk-chan_unicall is not needed anymore with asterisk-1.6, it sounds reasonnable. May I have some feedback on that ?
Last rites have been sent for: net-misc/asterisk-chan_unicall media-libs/libsupertone net-libs/libmfcr2 net-libs/libunicall app_rtfax will wait for Chainsaw word. yate will have to be fixed.
All fixed.
