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: PullRequest
Depends on:
Blocks: 908706 713988 780069 831353 906179 907215 910422 912346 914434
  Show dependency tree
 
Reported: 2023-09-20 20:43 UTC by Jaco Kroon
Modified: 2024-01-16 16:16 UTC (History)
5 users (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.
Comment 9 2857 2023-12-07 21:36:55 UTC
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.
Comment 10 Jaco Kroon 2023-12-08 06:25:11 UTC
(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.
Comment 11 2857 2023-12-08 17:59:34 UTC
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?
Comment 12 Jaco Kroon 2023-12-09 07:51:50 UTC
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.
Comment 13 2857 2023-12-10 05:38:47 UTC
(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.
Comment 14 Larry the Git Cow gentoo-dev 2023-12-16 08:27:45 UTC
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(-)
Comment 15 Jaco Kroon 2023-12-27 15:50:05 UTC
@arthurzam@gentoo.org
Comment 16 Jaco Kroon 2023-12-27 15:51:24 UTC
@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.
Comment 17 Larry the Git Cow gentoo-dev 2023-12-27 21:24:44 UTC
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(+)
Comment 18 Larry the Git Cow gentoo-dev 2024-01-05 05:14:10 UTC
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(+)
Comment 19 Douglas Paul 2024-01-12 21:16:01 UTC
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.
Comment 20 Jaco Kroon 2024-01-13 14:34:42 UTC
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.
Comment 21 Douglas Paul 2024-01-16 16:16:27 UTC
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.