Hello- Asterisk 14.0.2 is out. I've tried doing a rename bump in my personal overlay, and it seems to work just fine (patches apply cleanly, source configures/compiles as expected, final merged binary runs without error). It doesn't need to get in-tree anytime soon (I've not *needed* any functionality in Asterisk 14, and I'm happy to continue to use robinkverlay for my Asterisk 14 needs), but it'd be good to eventually get it in-tree to get more and better eyeballs on it so that it can be cleared for eventual unkeywording. Just for reference, the renamed ebuild is (current a/o 2016-10-13 22:02Z) repo/gentoo.git's net-misc/asterisk/asterisk-13.11.2-r1.ebuild. I'd link you to my overlay, but it's literally (not figuratively) that very ebuild, just with a different filename. If you have any other info you need, or run into issues while doing a rename/configure/compile, please don't hesitate to ask, and while I may not be able to smooth anything out, I will do my due diligence in terms of trying to research/reproduce the issue at hand, and there's a decent chance that someone with a deeper and more apropos skillset will see this bug as well. I should also mention that I'm running pjproject 2.5.5 (there's a really irritating issue with the configure script that I'm running into; if it persists and I don't figure out a workaround I'll post a bug (first to pjsip.org's Trac, and then here if I get a fix), and hopefully at least bring the issue to the attention of the right people). It's also in my overlay, but it's another rename bump (with $(use_enable ssl) removed (again, will file an issue here once I know why the $#^& --enable-ssl disables SSL support)). -Robin K.
Reviewing http://www.asterisk.org/downloads/asterisk/all-asterisk-versions there are a number of versions missing from tree, including upstream stable versions it would be worthwhile Gentoo stabilising internally. @Chainsaw - do you think you could have a tidy-up of this package? I'll organise a PR if you don't have time, perhaps .. ;).
(In reply to Michael Everitt (IRC: veremit) from comment #1) > @Chainsaw - do you think you could have a tidy-up of this package? I'll > organise a PR if you don't have time, perhaps .. ;). Happy to work with actionable intel. "Have a tidy up" is not actionable, bumping to 14.0.2 is.
Any update on this? Asterisk 14.5.0 has been released on 2017-05-30 while 14.x is not an LTS version, it would be great to have a 14.x version available (Opus codec support and other improvements) at least until the next LTS version (15.x) is available around October ( https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions )
The 13.7.2 ebuild is the priority at the moment, issues with PJproject 2.6 remain to be sorted before a 14 ebuild is viable.
The full support phase for 14.x has ended (but still gets security fixes til 2018-09-26). But 15.x still gets full support [1]. @Chainsaw: 15.x uses the bundled PJproject by default [2]. This may simplify things. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions [2] https://wiki.asterisk.org/wiki/display/AST/New+in+15
(In reply to Skruppy from comment #5) Meanwhile 16.x LTS is available. Are the PJproject issues still a blocker or could we expect a new ebuild in tree soon?
*** Bug 681154 has been marked as a duplicate of this bug. ***
Created attachment 570118 [details] asterisk 16.1.0 My draft of ebuild. It work for me with pjsip as well w/o SSL support (some errors with load pjsip module)
Created attachment 573004 [details] with pjproject-2.8 FEATURES="-network-sandbox" needed for emegre.
Asterisk 16.3.0 has been out since April 4th. I attempted to modify the Gentoo ebuild for this but it failed during configure with a syntax error (which happened to relate to "JANSSON_DEFINE_JSON_INT()" appearing in ./configure. The gentoo patches still applied cleanly though. There is no good reason to build 16.2.1 now that 16.3.0 LTS is out so the title of this bug ought to be updated. I'm currently trying to troubleshoot some Cisco Phones with 3rd Party Call Control firmware with h264 SIP/Video not working, and I'd like to be testing with a later version than 13 if at all possible.
Asterisk 16.6.1 is out on Oct 16, 2019: https://www.asterisk.org/downloads/asterisk-news/asterisk-1661-now-available
Asterisk 17.0.0 is out on Oct 28, 2019: https://www.asterisk.org/downloads/asterisk-news/asterisk-1700-now-available
Is asterisk dead on Gentoo? The only available version is 4 Years old now.
There is currently a proxy-maintainer jkroon, who is now hardly working to bring a asterisk update to Gentoo :-)
(In reply to Conrad Kostecki from comment #14) > There is currently a proxy-maintainer jkroon, who is now hardly working to > bring a asterisk update to Gentoo :-) "working hard" I believe ('lots of') rather than "hardly working" ('not very much') .. fyi :]
(In reply to Conrad Kostecki from comment #14) > There is currently a proxy-maintainer jkroon, who is now hardly working to > bring a asterisk update to Gentoo :-) that is great :) Thanks for the info and thank you jkroon
(In reply to Michael 'veremitz' Everitt from comment #15) > (In reply to Conrad Kostecki from comment #14) > > There is currently a proxy-maintainer jkroon, who is now hardly working to > > bring a asterisk update to Gentoo :-) > > "working hard" I believe ('lots of') rather than "hardly working" ('not very > much') .. fyi :] Whoops, you are right ;-)
Just so that all knows, my first aim is just to bump 13 to newest. I believe that's ready. Then I'll bump pjproject to 2.9 either this evening or over the weekend (more likely ... got some nasty asterisk usage blocking bugs that I need to first patch). How's the uptake/demand/need for 16.X? I'd be great if we can have multiple branches and some for users to specify which branch they'd like to track, which to me sounds like SLOTing, however, we can still only have one version of asterisk installed on any given host, so if someone can guide me on how we can achieve that it'd be great. Jaco
> I'd be great if we can have multiple branches and some for users to specify > which branch they'd like to track, which to me sounds like SLOTing, however, > we can still only have one version of asterisk installed on any given host, > so if someone can guide me on how we can achieve that it'd be great. > > Jaco You only really need slots if you want several versions installed _at the same time_. Otherwise, you can just have several version of the package and let the user decide which to install.
(In reply to Jaco Kroon from comment #18) > How's the uptake/demand/need for 16.X? +1 for 16.X. I have quite some annoyance with 13.x and I'm longing for something fresher like 16.x. When 16.x is out I won't be using 13.x anymore. Konstantin
> Installed versions: 16.4.0[1]
Created attachment 600644 [details] Asterisk LTS 16.7.0 ebuild * Removes the split-tinfo patch for multiselect. * Adds eautoreconf for third-party/jansson (unneeded, tho) * Adds --without-{jansson,pjsip}-bundled to not use the bundled ones This builds. I reviewed the jansson and pjsip patches on git as of tag 16.7, but I couldn't find any valid reason to use the bundled versions instead of upstream other than support for CentOS. Perhaps someone more versed in the hows and whys could chime in. Then again, this ebuild gives me a working 16.7 (current LTS).
Hi, (In reply to Martin Cyr from comment #22) > Created attachment 600644 [details] > Asterisk LTS 16.7.0 ebuild > > * Removes the split-tinfo patch for multiselect. > * Adds eautoreconf for third-party/jansson (unneeded, tho) > * Adds --without-{jansson,pjsip}-bundled to not use the bundled ones > > This builds. I reviewed the jansson and pjsip patches on git as of tag 16.7, > but I couldn't find any valid reason to use the bundled versions instead of > upstream other than support for CentOS. Perhaps someone more versed in the > hows and whys could chime in. For PJSIP the issue is primarily around the site_config.h file. I've updated the gentoo variant to as close as possible, using what makes most sense in *my personal opinion*. If there is PJSIP related issues, please file bugs. > Then again, this ebuild gives me a working 16.7 (current LTS). Could you please rebase off of 13.29.1 which I've committed to tree via PR towards end of 2019? Please also update Copyright notice. Please don't change (whitespace) indentation. Specifically, 13.29.1 was quite a big update: commit b44a1be8b8e28517ce843e630e30ccc1ddf3fae4 Author: Jaco Kroon <jaco@uls.co.za> Date: Sun Nov 10 20:29:19 2019 +0200 net-misc/asterisk: version bump to 13.29.1 + maintainership Converted to GLEP 81 for user+group. Consolidated a few DEPEND issues. Dropped pkg_config phase function. Took maintainership. Fixed a bunch of other issues from pkgcheck (${D} and ${ROOT} not having a / following it directly). Bumped to EAPI=7 Use $ED over $D where applicable. Fix statsd integration. Update depend on virtual/mysql to db/mysql-connector-c Enable NOISY_BUILD as requested (instructed) by slyfox. Fix /usr/share/doc/${PV} being asterisk: owned. Make SSL optional. This commit enables progress on the GLSA bug: https://bugs.gentoo.org/689796 Might close: https://bugs.gentoo.org/594160 (SIGILL, may be GRSEC, or #667498) Package-Manager: Portage-2.3.76, Repoman-2.3.16 Closes: https://bugs.gentoo.org/631464 Closes: https://bugs.gentoo.org/654710 Closes: https://bugs.gentoo.org/656472 Closes: https://bugs.gentoo.org/666004 Closes: https://bugs.gentoo.org/667498 Closes: https://bugs.gentoo.org/670522 Closes: https://bugs.gentoo.org/679804 Closes: https://bugs.gentoo.org/686906 Closes: https://bugs.gentoo.org/692696 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/13649 Signed-off-by: Joonas Niilola <juippis@gentoo.org> Does anyone know of a sensible way in which we can have both 13 and 16 "branches" in the tree and some configuration variable selects which branch to stay in. My concern is functional changes from 13 to 16 which might bite users. I'd prefer that explicit action is required to move from 13 to 16, but that users actioning new installs get 16 by default.
(In reply to Jaco Kroon from comment #23) > Does anyone know of a sensible way in which we can have both 13 and 16 > "branches" in the tree and some configuration variable selects which branch > to stay in. > > My concern is functional changes from 13 to 16 which might bite users. I'd > prefer that explicit action is required to move from 13 to 16, but that > users actioning new installs get 16 by default. The common way to do this is slotting, or by selective masking. The latter is probably easier, as you're unlikely to want/need both on a given system. So I'd potentially mask off the older one, with a friendly news item, and einfo notices in the package, etc. News items usually go to -dev ML for review, the rest can be managed by the files in profiles, and you can figure einfo within the ebuilds I'm sure ;).
As per last round of teamviewer releases, SLOTing is not an option. I'm guessing it may technically be *possible* to install multiple versions of asterisk on the same system though by using alternate library prefixes and install locations, but I frankly really don't think that effort is worth it. The selective masking option seems more interesting, however, based on personal experience (I'm guilty myself) news items are often not properly read. My aim: * If you have 13, don't automatically upgrade to 16, however, this shouldn't be prevented completely, ie, if user requests update, proceed. * If a new user installs, install version 16. I'm not aware of a way, other than stable both (SLOT=0), with subslotting perhaps, since stuff building against asterisk needs rebuilding (eg, asterisk-g729 will require an update too if asterisk updates) and users have to manually mask >=14.0 if they want to stick with 13. Any other better ideas would be much appreciated. I for one am not quite ready yet to jump to 16 just yet (but happy to get 16 in the tree).
If I may suggest a dirty hack, you can use slots and make them mutually block each other, so they'll never be installed at the same time.
As nasty as that may sound ... it might actually also solve issues with for example asterisk-g729 (and -opus hopefully soon) whereby the builds are for specific asterisk branches. So asterisk-g729-13* could depend on net-misc/asterisk:13 (for example). Strictly speaking asterisk-g729 doesn't actually depend on asterisk at all though, but neither is a DEP in the other direction appropriate because asterisk really doesn't depend on asterisk-g729 either. However, when they are BOTH installed we require compatible versions. NOTE: One could argue that asterisk-g729 cannot function without asterisk, this makes sense, but in theory anyone can dlopen() the library and use it to transcode g729 data if they know and use the correct ABI (and provide appropriate functions to the module that asterisk would normally supply). Happy to leave the DEP though since this is an abstract use-case which I've not personally done, and know of no-one that has. Need to think about this would all stick together but the idea merits some extra thought. Would be ideal if we don't need to explicitly update each branch independently so that we can maintain as closely compatible ebuilds as possible.
You could trigger rebuilds of asterisk-g729 and such with subslots. If you're willing to add more complexity on top of complexity.
Created attachment 608564 [details] Asterisk LTS 16.7.0 ebuild This ebuild is rebased against asterisk-13.29.1.ebuild.
Created attachment 608566 [details] Asterisk 17.1.0 ebuild This ebuild is based on asterisk-13.29.1.ebuild
Differences in both these ebuilds (16.7 and 17.1) vs 13.29.1: * libedit seems to be required for the build (--without-libedit fails on configure) * uses --without-{janssons,pjproject}-bundled * fixes a typo in NOISY_BUILD
Created attachment 608572 [details] Asterisk LTS 16.7.0 ebuild Removed libedit from USE and conditional DEPEND
Created attachment 608574 [details] Asterisk 17.1.0 ebuild Removed libedit from USE and conditional DEPEND
Created attachment 612798 [details] Asterisk LTS 16.7.0 ebuild Replaces DEPENDS on dev-libs/ilbc-rfc3951 with media-libs/libilbc.
Created attachment 612800 [details] Asterisk 17.1.0 ebuild Replaces DEPENDS on dev-libs/ilbc-rfc3951 with media-libs/libilbc.
Hi All, So I'm finally in a sensible position to start thinking about >13. For now I'm fairly stuck on 13 (and even some systems still on 11), but alas, the future beckons. As I've got it the current branches for asterisk (upstream) are: LTS: 13 LTS: 16 Standard: 17 Development mostly happens on master nowadays, and most bug fixes gets back ported to 13, 16 and 17 from there. As soon as a new LTS gets released 17 will go away. I'm not sure till when 13 will still be available. What's clear is that we need to allow for multiple branches inside of Gentoo. Currently we have 11 (which is currently hard masked due to security concerns and I'm hoping to axe in the next 3 to 6 months completely) and 13 (And I'm trying to keep up to date). My current thinking is as follows: * I'd like to keep the ebuilds as close as possible for the different branches. * I'd like to keep the branches limited to LTS but am not opposed to a 17 branch currently (non-LTS would remain ~). The exact strategy is a bit unclear. We could possibly use slotting to allow merging a specific branch, but we'd need to prevent trying to merge multiple slots. Slots were (as I understand) designed to install multiple versions of the same thing (which frankly is not even an objective here). Another alternative is to simply have stable and ~ builds in each branch and depend on users to mask/unmask/keyword what they want/don't want. This may be the simplest approach. My ideal approach will: Upon first install of asterisk, install the newest stable, and then on update stick to that specific branch, unless the system administrator specifically requests a jump between branches. I'm not sure this will be possible. For those worried (me, hopefully I'm not alone). From memory there were at last two jumps that were particularly painful. 1.4 to 1.6/1.8 and then 11 to 13. Last I spoke with Matt (Friederickson aka creslin) my impression was that he agreed with this assessment, and assured me that the jumps (as far as he was aware) from 13 onwards were not nearly as painful and should in fact be drop-in style. If this is the case I may be able to move onto 16 soon enough. As such, the further question is whether it will be worth the effort to maintain a 13 branch at all going forward. I would greatly appreciate feedback from actual users of asterisk on Gentoo regarding the above, and your specific needs such that we can see what the best way going forward is. I'm generally on #gentoo-voip if you'd like to discuss anything. Or grab my email from the bug report.
Update on the PR. I finally bumped into an issue which will require me to move onto newer asterisk. This is mostly the 13.32.0-r1 build, with minor changes to deal with upstream changes that I could find in their logs on the wiki. You're welcome to start testing on that. Based on the information I've got on 17 it looks like most of the functionality has been made available in the other branches too, and I can't find anything that is purely in 17 only, but I'll grant that I didn't dig particularly hard. Kind Regards, Jaco
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d278a7d8e8fd994ac9ddba627d96a2f50a014c9 commit 9d278a7d8e8fd994ac9ddba627d96a2f50a014c9 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2020-04-08 07:17:47 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-04-13 07:41:30 +0000 net-misc/asterisk: version bump to 16.9.0 Minor changes to accomodate upstream. Primarily: 1. Explicitly do not use bundled pjsip / janson. 2. Depend on libedit explicitly (it's no longer bundled at all). 3. Allow for SRV/NAPTR processing via libunbound. 4. Asterisk 16 requires pjsip 2.9. 5. Depend on dev-libs/jansson-2.11 Eliminate use of MY_P (very, very old versions of asterisk used _ in name apparently, this is no longer the case so just use P instead). Closes: https://bugs.gentoo.org/597082 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-misc/asterisk/Manifest | 1 + net-misc/asterisk/asterisk-16.9.0.ebuild | 323 +++++++++++++++++++++++++++++++ net-misc/asterisk/metadata.xml | 1 + 3 files changed, 325 insertions(+)
