I intend to abandon support for DAHDI unless someone steps forward indicating they're not actively using it. My reasons are: 1. Upstream is slow to slow to respond and fix issues (if they do at all). 2. They are horrendous with new releases, with often years passing between releases. 3. They refuse to support non-Digium now Sangoma hardware in-tree resulting in having to maintain independent patch sets for other hardware. 4. Drives for Digium hardware are removed as the hardware reaches end-of-life - resulting in these getting patched back by myself, and other parties (for other distributions). 5. I don't use DAHDI myself anymore, so no longer have the required motivation to keep this working, and given the above it's an excessive amount of effort. 6. Keeping a stable dahdi is hard since due to using in-kernel APIs that have been deprecated for years (and in some cases I patched recently, decades), and for example a month after DAHDI 3.2.0 was released, it no longer compiled against the latest kernels. Should users step forward we can certainly talk about keeping this, or making a plain to keep it somehow, but as it stands I believe it's a lot of effort for very little if any gain for the Gentoo project. Reproducible: Always
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=669b69478f55bdbb5fa567032b652774e8b820a9 commit 669b69478f55bdbb5fa567032b652774e8b820a9 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2023-09-21 08:15:33 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-09-21 08:15:33 +0000 profiles: last-rite net-misc/dahdi (and related pkgs) Bug: https://bugs.gentoo.org/914477 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/package.mask | 13 +++++++++++++ 1 file changed, 13 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=609baae2abd62ad263bbb4f6ad6079991463dfff commit 609baae2abd62ad263bbb4f6ad6079991463dfff Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2023-09-21 08:13:40 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-09-21 08:13:40 +0000 profiles/base: package.use.mask */*[dahdi] - dahdi is being last-rited. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/base/package.use.mask | 6 ++++++ 1 file changed, 6 insertions(+)
What about changing upstream to the fork by osmocom? There are some people maintaining it and they've also restored support for older hardware. The repository can be found here: https://gitea.osmocom.org/retronetworking/dahdi-linux
Hi, Certainly that's AN option (which I have considered), but if no-one is using DAHDI in Gentoo any more, then what's the point? Even they don't have release tags, so effectively we can provide a -9999 ebuild, or hash/date-tagged versions, but this certainly is even more effort than a simple version tagged, to find an appropriate hash/date to tag on. All in all there are options, if we have users, we can make a plan, but if there are no confirmed users there is no point in spending anything more than zero time on this. DAHDI is going the way of the fax ... it probably won't die any time soon but it's certainly bleeding like crazy. I think point 5 above applies. Kind regards, Jaco
(In reply to Ayron from comment #2) > What about changing upstream to the fork by osmocom? There are some people > maintaining it and they've also restored support for older hardware. > The repository can be found here: > https://gitea.osmocom.org/retronetworking/dahdi-linux Are you using it or is this hypothetical? We want to know if people really do use it, but not if it's just for the benefit of imaginary users.
(In reply to Sam James from comment #4) > (In reply to Ayron from comment #2) > > What about changing upstream to the fork by osmocom? There are some people > > maintaining it and they've also restored support for older hardware. > > The repository can be found here: > > https://gitea.osmocom.org/retronetworking/dahdi-linux > > Are you using it or is this hypothetical? We want to know if people really > do use it, but not if it's just for the benefit of imaginary users. Hi Ayron, Would you mind getting back to us on this please? We're happy to make a plan for anyone that's genuinely using DAHDI, even if it is only a -9999 release against osmocon, but I'm not going to put in additional effort if there aren't actual consumers. Kind regards, Jaco
I'd like to step in as a potential user – I was about to install it but noticed that it's hevily masked. I'm not sure ripping it all of is a good idea, but certainly maintaining this for just a few people can be a questionable effort.
(In reply to 2857 from comment #6) > I'd like to step in as a potential user – I was about to install it but > noticed that it's hevily masked. I'm not sure ripping it all of is a good > idea, but certainly maintaining this for just a few people can be a > questionable effort. potential user? As in you have hardware that you want to use or are considering? If the former, then we can certainly make a plan. If the latter I'd highly recommend rather obtaining a SIP to FXS/FXO/BRI/PRI(E1|T1)/GSM gateway as appropriate and use that instead. Whilst DAHDI certainly gives you more control in asterisk about line status and the like, and monitoring yourself against that, the support from upstream only got worse since Sangoma bought out Digium. Of course Sangoma always had their own hardware which they're pushing, and that requires proprietary WANPIPE drivers (which are an even bigger pain than DAHDI). https://github.com/asterisk/dahdi-linux Seems to indicate that the situation *may* improve, but currently I cannot recommend anyone to actually go out and purchase DAHDI compatible hardware when there are alternatives. At least we had a 3.2.0 release slightly over a year back after months of fighting with them - just to not be able to stable that due to it not being able to compile against the newest (unreleased master branch) kernels - AT THE TIME OF RELEASE. We've been waiting for a working release ever since, even after providing patches. osmocom seems to incorporate things as and when needed, but they don't tag releases - so at best we can do snapshots, or a -9999 release only. Neither of which is something I'm keen on doing given that we're talking voice here. Stability is critical, the only aspect in IT I'm aware off where people scream more than with email not working flawlessly (by whatever definition) is voice. I'm happy to add a (masked) 3.3.0-rc1 release for you if you want to test that, and if it turns out to be better than 3.2.0 then sure, but as it stands, I suspect that 3.3.0-rc1 is already screwed in that the master branch already saw compilation fixes for 6.1 and newer kernels, which it doesn't look like these fixes are headed into 3.3.0 - so essentially, the planned "we're coming to the party release" is already a failure (in my personal opinion, since I doubt it'll work on anything newer than a 6.1.61 kernel). Their opinion of fixing code is to pull in compatibility macro's and inline functions that used to be in kernel tree in order to maintain temporary backwards compatibility whilst people migrate code to newer APIs into the DAHDI tree. For example, the diff for fixing dahdi to compile against 6.6.x kernels is to take the #define for flush_scheduled_work() and put that in the dahdi/kernel.h header file instead. Since these backwards compatibility stuff generally holds back other developments and improvements, I suspect it'll generally be subject to further breakage. The fix for 6.1.62 and newer kernels also changes behaviour - so I'd be surprised if it works on older kernels (it'll compile, but result in kernel OOPS), not to mention that it degrades performance: if (s->name) is changed to if (strlen(s->name)) - which implies s->name could previously have been NULL, or the code has always been broken, and now strlen() computes the length of the string just to determine if it's non-empty? Should that not become if (s->name && *s->name) rather? Kind of fixes. I just have almost no trust in the project any more, and the deeper the rabbit hole goes the worse it seems to get. Sorry if this seems negative ... but I am.
Hi Jaco, Thanks for detailed answer! Project state you're describing is truly pretty depressing... I'm late to the whole Asterisk party but want to try it out nevertheless. My plan is to use TDM410 PCI card (with 4 FXS modules) to setup a small local instance of Asterisk interfacing 4 phones. Using dedicated HW is not an option since I already have the card, and I'd like to have it in the server I control. I intend to use 6.1 LTS stable kernel only, so I'm okay with ifdefs (if they are going to work, of course). Of course, I can unmask latest 6.1 ebuild if needed. I would be happy with either upstream or osmocom fork (whichever works), and also if main tree seems like too much to maintain maybe it's better to move ebuilds to an overlay? From my limited knowledge card seems to be still supported by mainline driver.
