Hello all, For some reason pjsip was removed in the past, see 522732. But for the new SIP stack in Asterisk pjsip is a hard dependency. I grabbed an ebuild from an overlay ("booboo") and changed it around a bit. I'll attach it to this report. Kind regards, Sebastian Reproducible: Always
Created attachment 416664 [details] ebuild
please add a "static-libs" use flag and append the following lines at the end of the install section: # Remove static libraries if needed use static-libs || rm -f "${D}"/usr/lib*/lib*.a
Created attachment 417472 [details, diff] This is a patch to the asterisk 13.5.0 configure.ac to avoid pjsip compilation errors Added patch for asterisk pjsip_distributor compilation error.
Created attachment 417474 [details] asterisk-13.6.0.ebuild This is the ebuild for asterisk 13.6.0 that enables net-libs/pjsip dependancy and uses the patch above for fixing compilation issues.
Added Tony Vroon to contacts as support
Created attachment 417482 [details] pjsip-2.4.5 updated ebuild with ipv6 and static-libs use flags Added ipv6 support and static libs inclusion to the original ebuild.
In current ebuild form pjsip will build without SSL support, which makes it unusable in Asterisk with error while loading pjsip modules: res_pjsip.so: undefined symbol: pj_ssl_cipher_name removing $(use_enable ssl) \ from ebuild solves the problem - makes pjsip build with SSL support.
PJSIP ebuild maybe used as standalone library package for other developments. Please consider to add an ssl use flag to pjsip as asterisk forcibly enables it. I will check if it is possible to put the same ssl use flag even in the asterisk ebuild. Thanks for reporting. Federico
Agreed. However in a current form $(use_enable ssl) \ generates --enable-ssl configure script parameter, which pjsip's configure script does not have. pjproject-2.4.5$ ./configure --help | grep ssl --disable-ssl Exclude SSL support the build (default: autodetect) --with-ssl=DIR Specify alternate libssl prefix It only appears to have "disable-ssl" flag. The problem is that with that "--enable-ssl" configure script parameter pjsip is build without SSL somehow.
Created attachment 421344 [details] Updated PJSIP 2.4.5 ebuild Updated PJSIP 2.4.5 ebuild: * fixed 'ssl' use flag issue; * fixed openh264 support; * improved 'ilbc' use flag functionality; * added 'srtp' use flag to allow internal srtp handling;
Created attachment 429066 [details] pjsip-2.4.5-r4.ebuild
Thanks for everything you guys added! - added USE debug; if not enabled NDEBUG is set; see https://wiki.asterisk.org/wiki/display/AST/Building+and+Installing+pjproject - inherit flag-o-matic; without it append-flag doesn't work (needed for debug and ipv6) - removed USE srtp; having USE srtp suggests that you can disable it, which you can't, so the USE is misleading; we just depend on libsrtp so that pjsip doesn't build its own copy
Created attachment 429068 [details] pjsip-2.4.5-r4.ebuild
Created attachment 433894 [details] pjsip-2.4.5.ebuild please put asterisk patches in a separate bug. regarding this ebuild, the remaining tasks are: 1. add python support 2. verify all components working (I only tested compile+install) probably more I forgot, but putting this here as a first draft.
Created attachment 434076 [details] pjsip-2.4.5.ebuild tested USE=most compile and working with asterisk (requires pjsip[ssl] else runtime symbol error) python support still not included but I don't know any projects that use it.
Created attachment 434078 [details, diff] pjsip-resample_libsamplerate-include.patch
Created attachment 436004 [details, diff] 0001-asterisk-pjsip-pjprotect-support.patch Not really a "hard" dependency, but definitely something we should include. The attachment is a patch to the main portage tree that includes an ebuild for 2.5 for pjproject (rather than pjsip since the archive is called pjproject - it includes much more than just SIP). The ebuild itself has a number of flaws, some of which is fixed in the 2.4.5 version here (thus why I didn't deprecate anything): * Improved dependencies * Simpler (shorter). This one has a wider range of codec selection controls etc ... so most likely we need to pick the best from both sides. repoman moans about emake -j1 ... I assume that's an upstream issue. Wish I had more time to look at this at the moment.
Created attachment 436006 [details] pjproject-2.5.ebuild This is the ebuild from the formatted patch - for easier review for those who don't have the git tree checked out.
Oh, in the 2.5 ebuild I don't like: resample-dll vs shared. The 2.4.5 uses static-libs. My opinion is that dynamic building should be the default, and only if static-libs is specified should things be linked statically. Then again - this could relate to building separate .so files that aren't normally built. A bunch of video related flags should probably depend on video support, eg, ffmpeg, v4l2, openh264, libyuv are all video related and I don't know if any of those USE flags makes sense without video also being set. These also makes little sense to me: $(use_with speex external-speex) \ $(use_with gsm external-gsm) \ $(use_with srtp external-srtp) \ $(use_with portaudio external-pa) there are builtin alternatives to some of these, which we should maybe explicitly disable always. Do we care about ipp at all? I know asterisk-g72x supports IPP - but based on experience that's horrid torture and I eventually fixed that ebuild to have that as optional and rather depend on the gstreamer bcd code to get g729. Resample also has a bunch of different use flags, I'm not sure what the implication of large-filter vs small-filter is - what's their relation and do we really need these many USE flags? Sorry, I know this raises more questions than answers, some guidance would be appreciated. @ Tony - I also took the liberty of putting you as maintainer for pjproject in metadata.xml - I hope that's in order (let me know if not).
(In reply to Jaco Kroon from comment #19) > My opinion is that dynamic building should be the default, and only if > static-libs is specified should things be linked statically. Agreed. > A bunch of video related flags should probably depend on video support, eg, > ffmpeg, v4l2, openh264, libyuv are all video related and I don't know if any > of those USE flags makes sense without video also being set. A good case for REQUIRED_USE. > there are builtin alternatives to some of these Indeed, the Gentoo way is to use external libraries. > @ Tony - I also took the liberty of putting you as maintainer for pjproject > in metadata.xml - I hope that's in order (let me know if not). That is fine, thank you.
(In reply to Jaco Kroon from comment #17) > Created attachment 436004 [details, diff] [details, diff] why did you not base your ebuild on the one I posted here? > This one has a wider range of codec selection controls etc ... so most > likely we need to pick the best from both sides. what codecs? all 7 codecs that pjsip supports are already in my ebuild here. > repoman moans about emake -j1 ... I assume that's an upstream issue. Wish I > had more time to look at this at the moment. did you test it? (In reply to Jaco Kroon from comment #19) > resample-dll vs shared. The 2.4.5 uses static-libs. My opinion is that > dynamic building should be the default, and only if static-libs is specified > should things be linked statically. Then again - this could relate to > building separate .so files that aren't normally built. that's a crappy override of installed libraries with bundled ones. I don't think I've ever seen anything so horrible. use grep to find what they do. > A bunch of video related flags should probably depend on video support, eg, > ffmpeg, v4l2, openh264, libyuv are all video related and I don't know if any > of those USE flags makes sense without video also being set. > > These also makes little sense to me: > > $(use_with speex external-speex) \ > $(use_with gsm external-gsm) \ > $(use_with srtp external-srtp) \ > $(use_with portaudio external-pa) > > there are builtin alternatives to some of these, which we should maybe > explicitly disable always. which I already did in my ebuild. > Resample also has a bunch of different use flags, I'm not sure what the > implication of large-filter vs small-filter is - what's their relation and > do we really need these many USE flags? no, because external libraries should always be used if possible. use grep. (In reply to Tony Vroon from comment #20) > > A bunch of video related flags should probably depend on video support, eg, > > ffmpeg, v4l2, openh264, libyuv are all video related and I don't know if any > > of those USE flags makes sense without video also being set. > > A good case for REQUIRED_USE. it most definitely isn't. if "video" does anything by itself (which it probably doesn't), automatically enable it with an ewarn if a codec requiring it is enabled; otherwise, transparently handle it for the user. REQUIRED_USE should only be used when it is absolutely necessary, per https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags.
Created attachment 436216 [details] pjproject-2.5.1.ebuild Bump to 2.5.1 and numerous fixes and improvements, incorporating both previous ebuilds (mainly building on 2.4.5), a few highlights I can remember at the moment: * Full codec list based on ./configure --help * Full video list * working alsa + portaudio (external sound) * Dropped python stuff (if someone needs it let me know) * Dropped resamplerate patch due to already applied. * Fixed all --enable/disable --with/without uses to be always specified, forcing them to the one or the other (don't rely on ./configure defaults). Stuff that I don't seem to get right: * OSS support (suggest we just drop it). * ilbc still builds under third-party, there is no --with-external-ilbc so I'm guessing that this cannot be fixed at this point without patching code. I've left the DEPEND but based on lld output I don't think this will be needed. * Ditto for G.7221.1 except that there isn't even an ebuild for g7221 that I could locate. General comments: * I suspect the epoll related support has a race condition in the makefile but since it's marked as experimental I'm not going to spend time on it. I had it fail at least twice with the linker unable to locate input files suggesting that files that needs to be linked are still being compiled. I test-compiled with: USE="-* amr debug doc epoll examples ipv6 opus resample silk ssl static-libs webrtc g711 g722 g7221 gsm ilbc speex l16 sdl ffmpeg v4l2 openh264 libyuv alsa" ebuild pjproject-2.5.1.ebuild digest clean compile @ Tony - if you're happy with this I'll provide the metadata.xml and changes to asterisk ebuild as well again as a formatted patch.
(In reply to Jaco Kroon from comment #22) > Created attachment 436216 [details] > pjproject-2.5.1.ebuild > for t in ${VIDEO_LAGS}; do VIDEO_FLAGS
(In reply to Alex Xu (Hello71) from comment #23) > (In reply to Jaco Kroon from comment #22) > > Created attachment 436216 [details] > > pjproject-2.5.1.ebuild > > > for t in ${VIDEO_LAGS}; do > > VIDEO_FLAGS ARGH! Well spotted thanks. Any other suggestions/corrections (I've fixed this locally so long). Any advise on the OSS / iLBC or the G.722.1 problems I mentioned? Alex - btw, do you know of a way for portage (bash?) to report on such variables that aren't defined/initialized? JK
Created attachment 436766 [details, diff] 0001-asterisk-pjsip-pjprotect-support.patch As per IRC discussion with Tony, we'll be merging as is, in spite of the two outstanding problems: 1. OSS support doesn't seem to function. 2. external libs (iLBC + G.722.1). For iLBC there is an in-tree build apparently, I just can't get this to use that. This patch includes changes to asterisk ebuild to prevent "random" builds depending on whether pjproject is installed or not, as well as to actually provide the required support. As far as I can tell the USE flag requirements from asterisk's side is sane but we're bound to pick more things up here. Tony, to apply: git apply 0001-asterisk-pjsip-pjprotect-support.patch This command applies the patch but does not create a commit. To have it commit as well, just replace apply with am (you probably rather want apply).
That is in the tree now, thank you all.
