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.
While trying to compile Asterisk (both 18 and 20 version) I've noticed that dahdi use flag is also filtered, which makes it hard to make use of DAHDI if it won't be present in the official repo anymore – in that case it wouldn't be possible to enable it in already compiled Asterisk as chan_dahdi will be disabled etc.
(In reply to 2857 from comment #9) > While trying to compile Asterisk (both 18 and 20 version) I've noticed that > dahdi use flag is also filtered, which makes it hard to make use of DAHDI if > it won't be present in the official repo anymore – in that case it wouldn't > be possible to enable it in already compiled Asterisk as chan_dahdi will be > disabled etc. It's already to make hard off, and was already hard to make use off even before the mask. 3.3.0 was released yesterday, so I'm going to try and add that to the tree today, if both our testing pans out I'm willing to for the time being at least give DAHDI another shot at life.
Sharing my findings from IRC here: so I've managed to successfully build osmocom fork on 6.6.4 using this patch: https://dpaste.org/ZScd7 as host kernel was lacking CONFIG_PPP and CONFIG_HDLC. Not sure about original code motivation, since offending change was made way back in 2010: https://github.com/asterisk/dahdi-linux/commit/ccf5487ac9bee760584b8f314b23616e0032d87c. So far osmocom fork looks promising, what about integrating current patchset there?
What do you propose we do with the lack of releases on osmocom side? Current plan is to see if I can get dahdi 3.3.0 working.
(In reply to Jaco Kroon from comment #12) > What do you propose we do with the lack of releases on osmocom side? > > Current plan is to see if I can get dahdi 3.3.0 working. I'd vote for dahdi-osmocom-9999, but that probably belongs to an overlay. Current plan sounds great! Let me know if I can help.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b23bb0ae40afd13783064727b382671692b3714a commit b23bb0ae40afd13783064727b382671692b3714a Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-12-16 08:13:03 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-12-16 08:27:14 +0000 net-misc/openr2: treeclean Closes: https://bugs.gentoo.org/914477 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> net-misc/openr2/Manifest | 1 - .../files/openr2-1.3.0-fix-build-system.patch | 30 ------------------- net-misc/openr2/metadata.xml | 8 ----- net-misc/openr2/openr2-1.3.0.ebuild | 35 ---------------------- profiles/package.mask | 10 ------- 5 files changed, 84 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e157726349d8fe33cbb77b44f05b5cc9ace99c34 commit e157726349d8fe33cbb77b44f05b5cc9ace99c34 Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-12-16 08:11:59 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-12-16 08:27:13 +0000 net-misc/dahdi: treeclean Closes: https://bugs.gentoo.org/914477 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> net-misc/dahdi/Manifest | 25 -------- net-misc/dahdi/dahdi-3.1.0-r3.ebuild | 107 ------------------------------- net-misc/dahdi/dahdi-3.1.0-r4.ebuild | 120 ----------------------------------- net-misc/dahdi/dahdi-3.2.0.ebuild | 120 ----------------------------------- net-misc/dahdi/metadata.xml | 19 ------ profiles/package.mask | 1 - 6 files changed, 392 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b195f220594513e94954633d2c754ddd1f253fd7 commit b195f220594513e94954633d2c754ddd1f253fd7 Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-12-16 08:09:35 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-12-16 08:27:13 +0000 net-misc/dahdi-tools: treeclean Closes: https://bugs.gentoo.org/914477 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> net-misc/dahdi-tools/Manifest | 2 - net-misc/dahdi-tools/dahdi-tools-3.1.0-r2.ebuild | 70 ------ net-misc/dahdi-tools/dahdi-tools-3.1.0-r4.ebuild | 74 ------ net-misc/dahdi-tools/dahdi-tools-3.2.0.ebuild | 73 ------ net-misc/dahdi-tools/files/dahdi-autoconf.conf2 | 40 --- .../dahdi-tools/files/dahdi-autoconf.init-3.1.0-r4 | 271 --------------------- net-misc/dahdi-tools/files/dahdi-autoconf.init2 | 225 ----------------- .../files/dahdi-nondigium-blacklist.patch | 12 - .../files/dahdi-tools-3.1.0-cplusplusexternc.patch | 26 -- .../files/dahdi-tools-3.1.0-execinfo.patch | 40 --- .../files/dahdi-tools-3.1.0-fno-common.patch | 39 --- ...dahdi-tools-3.1.0-parallel-make-no-config.patch | 19 -- .../dahdi-tools/files/dahdi-tools-3.2.0-lto.patch | 61 ----- net-misc/dahdi-tools/files/dahdi.init2 | 36 --- net-misc/dahdi-tools/metadata.xml | 18 -- profiles/package.mask | 1 - 16 files changed, 1007 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9cf9e165c0025b84d62e571a3d3ad7377859f94 commit d9cf9e165c0025b84d62e571a3d3ad7377859f94 Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-12-16 08:26:41 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-12-16 08:27:14 +0000 net-misc/asterisk: remove masked IUSE="dahdi" The package behind the USE flag was just tree-cleaned, so remove the USE flag (which was masked, so NOP). Bug: https://bugs.gentoo.org/914477 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> net-misc/asterisk/asterisk-16.30.0.ebuild | 10 ++++------ net-misc/asterisk/asterisk-16.30.1.ebuild | 10 ++++------ net-misc/asterisk/asterisk-18.17.0.ebuild | 10 ++++------ net-misc/asterisk/asterisk-18.18.0.ebuild | 10 ++++------ net-misc/asterisk/asterisk-18.18.1.ebuild | 10 ++++------ net-misc/asterisk/asterisk-20.3.0.ebuild | 10 ++++------ net-misc/asterisk/asterisk-20.3.1.ebuild | 10 ++++------ net-misc/asterisk/metadata.xml | 1 - profiles/base/package.use.mask | 5 ----- 9 files changed, 28 insertions(+), 48 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=546086695a47bbf4d0f3899c5b5476a4cfb3e07c commit 546086695a47bbf4d0f3899c5b5476a4cfb3e07c Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-12-16 08:15:41 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-12-16 08:27:14 +0000 net-voip/yate: remove masked IUSE="dahdi" The package behind the USE flag was just tree-cleaned, so remove the USE flag (which was masked, so NOP). Bug: https://bugs.gentoo.org/914477 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> net-voip/yate/metadata.xml | 1 - net-voip/yate/yate-6.2.0.ebuild | 7 +++---- net-voip/yate/yate-9999.ebuild | 7 +++---- profiles/arch/arm/package.use.mask | 4 ---- profiles/base/package.use.mask | 1 - 5 files changed, 6 insertions(+), 14 deletions(-)
@arthurzam@gentoo.org
@arthurzam@gentoo.org In response to the treecleaning, please note that Removal date: # Removal on 2024-03-01. Can you please as a matter of reasonable urgency revert all relevant commits that you've made? As per this bug we were still looking to resurrect.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b1d01dc53eaff37a58faf406d66494343551b3e commit 3b1d01dc53eaff37a58faf406d66494343551b3e Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:15:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:16:27 +0000 Revert "net-voip/yate: remove masked IUSE="dahdi"" This reverts commit 546086695a47bbf4d0f3899c5b5476a4cfb3e07c. Removal date was not yet met & there are plans to possibly resurrect dahdi, per the bug. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Sam James <sam@gentoo.org> net-voip/yate/metadata.xml | 1 + net-voip/yate/yate-6.2.0.ebuild | 7 ++++--- net-voip/yate/yate-9999.ebuild | 7 ++++--- profiles/arch/arm/package.use.mask | 4 ++++ profiles/base/package.use.mask | 1 + 5 files changed, 14 insertions(+), 6 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71c29bdbd17e75bc52a033709095038ae77e0352 commit 71c29bdbd17e75bc52a033709095038ae77e0352 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:15:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:16:24 +0000 Revert "net-misc/asterisk: remove masked IUSE="dahdi"" This reverts commit d9cf9e165c0025b84d62e571a3d3ad7377859f94. Removal date was not yet met & there are plans to possibly resurrect dahdi, per the bug. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Sam James <sam@gentoo.org> net-misc/asterisk/asterisk-16.30.0.ebuild | 10 ++++++---- net-misc/asterisk/asterisk-16.30.1.ebuild | 10 ++++++---- net-misc/asterisk/asterisk-18.17.0.ebuild | 10 ++++++---- net-misc/asterisk/asterisk-18.18.0.ebuild | 10 ++++++---- net-misc/asterisk/asterisk-18.18.1.ebuild | 10 ++++++---- net-misc/asterisk/asterisk-20.3.0.ebuild | 10 ++++++---- net-misc/asterisk/asterisk-20.3.1.ebuild | 10 ++++++---- net-misc/asterisk/metadata.xml | 1 + profiles/base/package.use.mask | 5 +++++ 9 files changed, 48 insertions(+), 28 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=21c2b7afc6cf22dbb9448c3adf04fed88949a274 commit 21c2b7afc6cf22dbb9448c3adf04fed88949a274 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:15:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:16:21 +0000 Revert "net-misc/dahdi-tools: treeclean" This reverts commit b195f220594513e94954633d2c754ddd1f253fd7. Removal date was not yet met & there are plans to possibly resurrect dahdi, per the bug. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Sam James <sam@gentoo.org> net-misc/dahdi-tools/Manifest | 2 + net-misc/dahdi-tools/dahdi-tools-3.1.0-r2.ebuild | 70 ++++++ net-misc/dahdi-tools/dahdi-tools-3.1.0-r4.ebuild | 74 ++++++ net-misc/dahdi-tools/dahdi-tools-3.2.0.ebuild | 73 ++++++ net-misc/dahdi-tools/files/dahdi-autoconf.conf2 | 40 +++ .../dahdi-tools/files/dahdi-autoconf.init-3.1.0-r4 | 271 +++++++++++++++++++++ net-misc/dahdi-tools/files/dahdi-autoconf.init2 | 225 +++++++++++++++++ .../files/dahdi-nondigium-blacklist.patch | 12 + .../files/dahdi-tools-3.1.0-cplusplusexternc.patch | 26 ++ .../files/dahdi-tools-3.1.0-execinfo.patch | 40 +++ .../files/dahdi-tools-3.1.0-fno-common.patch | 39 +++ ...dahdi-tools-3.1.0-parallel-make-no-config.patch | 19 ++ .../dahdi-tools/files/dahdi-tools-3.2.0-lto.patch | 61 +++++ net-misc/dahdi-tools/files/dahdi.init2 | 36 +++ net-misc/dahdi-tools/metadata.xml | 18 ++ profiles/package.mask | 1 + 16 files changed, 1007 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc1bf849d92534c7607d5eebc0516605743e3d27 commit cc1bf849d92534c7607d5eebc0516605743e3d27 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:15:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:16:16 +0000 Revert "net-misc/dahdi: treeclean" This reverts commit e157726349d8fe33cbb77b44f05b5cc9ace99c34. Removal date was not yet met & there are plans to possibly resurrect dahdi, per the bug. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Sam James <sam@gentoo.org> net-misc/dahdi/Manifest | 25 ++++++++ net-misc/dahdi/dahdi-3.1.0-r3.ebuild | 107 +++++++++++++++++++++++++++++++ net-misc/dahdi/dahdi-3.1.0-r4.ebuild | 120 +++++++++++++++++++++++++++++++++++ net-misc/dahdi/dahdi-3.2.0.ebuild | 120 +++++++++++++++++++++++++++++++++++ net-misc/dahdi/metadata.xml | 19 ++++++ profiles/package.mask | 1 + 6 files changed, 392 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ebe86585e288a9cecfb9c08255da44035831fbfb commit ebe86585e288a9cecfb9c08255da44035831fbfb Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:15:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:15:57 +0000 Revert "net-misc/openr2: treeclean" This reverts commit b23bb0ae40afd13783064727b382671692b3714a. Removal date was not yet met & there are plans to possibly resurrect dahdi, per the bug. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Sam James <sam@gentoo.org> net-misc/openr2/Manifest | 1 + .../files/openr2-1.3.0-fix-build-system.patch | 30 +++++++++++++++++++ net-misc/openr2/metadata.xml | 8 +++++ net-misc/openr2/openr2-1.3.0.ebuild | 35 ++++++++++++++++++++++ profiles/package.mask | 10 +++++++ 5 files changed, 84 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c929eca080cee2c639e36f178c9f93c101444e09 commit c929eca080cee2c639e36f178c9f93c101444e09 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2024-01-04 18:23:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-05 05:12:42 +0000 Revert "net-libs/libpri: treeclean" This reverts commit f63bbe0e048e4d66750b67b20508441f3504f026. Removal date was not yet met & there are plans to possibly resurrect dahdi, per the bug. Bug: https://bugs.gentoo.org/914477 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Sam James <sam@gentoo.org> net-libs/libpri/Manifest | 1 + net-libs/libpri/files/libpri-1.4.13-multilib.patch | 51 +++++++++++++++++++++ .../libpri/files/libpri-1.4.13-no-static-lib.patch | 35 ++++++++++++++ .../files/libpri-1.6.0-respect-user-flags.patch | 53 ++++++++++++++++++++++ net-libs/libpri/libpri-1.6.0.ebuild | 33 ++++++++++++++ net-libs/libpri/metadata.xml | 12 +++++ profiles/package.mask | 1 + 7 files changed, 186 insertions(+)
Just wanted to comment that I am a user of this, currently, still with a TDM-410, but I understand the frustration felt towards Digium/Sangoma because I share it as well. I was also bit by their attitude also when they pulled support for this card when it reached end-of-life for spurious reasons of them not wanting to ensure testing. For a little while, before the great maintainers here started doing it for me, was manually patching the ebuild to revert their (trivial) commit to remove support. Considering that no one was ever asking for them to guarantee full functionality any more, I don't understand this. Especially when you take into account the amount of positively ancient hardware that works perfectly well with recent Linux kernels. The other arguments about the code quality just scare me however. Since I'm only using FXS, replacing everything with some sort of ATA is looking like a distinct possibility at this point. The amount of effort that has gone into this just looks quite hard to justify, and I'm very thankful you have been willing to take this on as long as you have.
I had some discussions with parties on the asterisk team and explained my frustrations. I subsequently got some attention from the DAHDI side of things and it looks like things are *slowly* moving in a direction. Regarding the TDM4xx issue, that was pretty nasty, but the moment I noticed they yanked support I re-added. Would it be acceptable in the immediate term to pull the mask, but also mark all versions as ~ currently? Ie, if there are current stables, to pull them? I think we've established we *need* to keep dahdi in-tree, there are sufficient users for it. I've got three large projects ongoing right at the moment so having some serious time related problems to spend on this. I did manage to push a few PRs recently (whilst waiting for large data copies over open internet), but this 3.3.0 bump I'm somewhat hesitant on and don't want to rush it, so would prefer a slot where I've got a good two to three hours to make sure that it works at least on whatever kernel I've got on my laptop currently (Which I think is somewhat old already given it's like 6.4.something). If someone would like to take over maintainership or assist on it, I'm happy to guide around the process I followed. As stated I've got no more consumers of this, although, whilst the team cleaned up the office we did discover that we still have a few TDM4xx cards, a TDM24xx, a Digium 4-port BRI as well as 4-port PRI and a 4-port BRI Junghauns card lying around unused. So we do have hardware we can in theory use to test against, or to set up in a Gentoo machine whereto we can give other maintainers access if needed for whatever reason.
I'm personally perfectly fine if stable is dropped from all the related packages. My ability to test is a bit limited due to not having FXO ports but if I do run into issues I don't mind trying to diagnosing them and providing patches if possible.
Just to put my head above the parapet. I am a user of Dahdi, and actually need a customised version with extra vendor drivers. I'm happy hacking on support for my own stuff (which is on arm, so also need antique vendor kernels with their own bugs and problems). However, it would be very useful to be able to keep support in the gentoo asterisk package, even if this just with it on life support and package masks? I wonder if anyone looked over if 3.3.0 gives it a brief respite?
Hey. Short version: I've been struggling the last 4 to 6 months to keep head above water to work on things like this. DAHDI is *low priority* for me. If someone would like to co-maintain, I'm happy to assist in getting said person going. Happy to assist and guide with what I've got, including giving access to my git repositories (on github) for gentoo patchsets, and some help on using those. Currently these are hosted downloads.uls.co.za so I'd need to create a dedicated ftp user to give said person access for hosting, or we should consider using github release tarballs instead? DAHDI 3.3.0 looked to be (mostly) a step in the right direction, but enough has changed that the existing gentoo patches no longer cleanly apply, and this will take some effort to rectify. Given the *public* statements from sangoma/digium, it *sounds* like they intend to do the right thing, permitting patches for older hardware etc ... however: so far their actions have not reflected this intent.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=877e1be575a5a133915711622ae531c4905cf095 commit 877e1be575a5a133915711622ae531c4905cf095 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-04-13 14:30:11 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-04-13 14:30:11 +0000 net-libs/libpri: Remove last-rited pkg Closes: https://bugs.gentoo.org/914477 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-libs/libpri/Manifest | 1 - net-libs/libpri/files/libpri-1.4.13-multilib.patch | 51 --------------------- .../libpri/files/libpri-1.4.13-no-static-lib.patch | 35 -------------- .../files/libpri-1.6.0-respect-user-flags.patch | 53 ---------------------- net-libs/libpri/libpri-1.6.0-r1.ebuild | 32 ------------- net-libs/libpri/libpri-1.6.0.ebuild | 33 -------------- net-libs/libpri/metadata.xml | 12 ----- profiles/package.mask | 10 ---- 8 files changed, 227 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6fd8b208b5a925b2005cd010b665597a6ea1b564 commit 6fd8b208b5a925b2005cd010b665597a6ea1b564 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-04-13 14:29:42 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-04-13 14:29:42 +0000 net-misc/dahdi: Remove last-rited pkg Closes: https://bugs.gentoo.org/914477 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/dahdi/Manifest | 25 -------- net-misc/dahdi/dahdi-3.1.0-r3.ebuild | 107 ------------------------------- net-misc/dahdi/dahdi-3.1.0-r4.ebuild | 120 ----------------------------------- net-misc/dahdi/dahdi-3.2.0.ebuild | 120 ----------------------------------- net-misc/dahdi/metadata.xml | 19 ------ profiles/package.mask | 1 - 6 files changed, 392 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82db2a6ca21961c8d4d75784e4d79036999d7f06 commit 82db2a6ca21961c8d4d75784e4d79036999d7f06 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-04-13 14:29:29 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-04-13 14:29:29 +0000 net-misc/dahdi-tools: Remove last-rited pkg Closes: https://bugs.gentoo.org/914477 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/dahdi-tools/Manifest | 2 - net-misc/dahdi-tools/dahdi-tools-3.1.0-r2.ebuild | 70 ------ net-misc/dahdi-tools/dahdi-tools-3.1.0-r4.ebuild | 74 ------ net-misc/dahdi-tools/dahdi-tools-3.2.0.ebuild | 73 ------ net-misc/dahdi-tools/files/dahdi-autoconf.conf2 | 40 --- .../dahdi-tools/files/dahdi-autoconf.init-3.1.0-r4 | 271 --------------------- net-misc/dahdi-tools/files/dahdi-autoconf.init2 | 225 ----------------- .../files/dahdi-nondigium-blacklist.patch | 12 - .../files/dahdi-tools-3.1.0-cplusplusexternc.patch | 26 -- .../files/dahdi-tools-3.1.0-execinfo.patch | 40 --- .../files/dahdi-tools-3.1.0-fno-common.patch | 39 --- ...dahdi-tools-3.1.0-parallel-make-no-config.patch | 19 -- .../dahdi-tools/files/dahdi-tools-3.2.0-lto.patch | 61 ----- net-misc/dahdi-tools/files/dahdi.init2 | 36 --- net-misc/dahdi-tools/metadata.xml | 18 -- profiles/package.mask | 1 - 16 files changed, 1007 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0ac9a8d00ed09a9b08d669d52cdc26a25f527a90 commit 0ac9a8d00ed09a9b08d669d52cdc26a25f527a90 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-04-13 14:29:02 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-04-13 14:29:02 +0000 net-misc/openr2: Remove last-rited pkg Closes: https://bugs.gentoo.org/914477 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/openr2/Manifest | 1 - .../files/openr2-1.3.0-fix-build-system.patch | 30 ------------------- net-misc/openr2/metadata.xml | 8 ----- net-misc/openr2/openr2-1.3.0.ebuild | 35 ---------------------- profiles/package.mask | 1 - 5 files changed, 75 deletions(-)
