Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 914477 - last-rite: net-misc/dahdi and related
Summary: last-rite: net-misc/dahdi and related
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Jaco Kroon
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-20 20:43 UTC by Jaco Kroon
Modified: 2023-11-30 00:03 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaco Kroon 2023-09-20 20:43:05 UTC
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
Comment 1 Larry the Git Cow gentoo-dev 2023-09-21 08:16:42 UTC
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(+)
Comment 2 Ayron 2023-10-07 00:29:22 UTC
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
Comment 3 Jaco Kroon 2023-10-10 07:41:01 UTC
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
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-10-10 07:43:21 UTC
(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.
Comment 5 Jaco Kroon 2023-10-26 07:13:57 UTC
(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
Comment 6 2857 2023-11-24 21:16:24 UTC
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.
Comment 7 Jaco Kroon 2023-11-25 06:56:11 UTC
(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.
Comment 8 2857 2023-11-30 00:03:22 UTC
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.