Hi! Please find attached openser-0.10.0.ebuild and an init script for it. Quoted from http://openser.org/about.php: "OpenSER is a project spawned from FhG FOKUS SIP Express Router (SER). The reason for this new venture is the lack of progressing and contributions to the SER project from the other SER team members as well as the reticience to new contributions from project's community members. We want to accelerate the integration of public contributions to the SER project." This ebuild is based on the ebuild file contained in the OpenSER source tarball. I made it works for my Gentoo Linux (Portage 2.0.51.22-r2), with the help of ser-0.9.4.ebuild that is already in the Portage tree. Since ser is in net-misc category at the moment, I suggest that openser goes there as well, unless there is plan for creating a new category like net-voip. - Cheng Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 69392 [details] openser-0.10.0.ebuild
Created attachment 69393 [details] openser.init
Sorry that I forgot to mention the OpenSER 0.10.0 release isn't final yet. The official website and mailing list announced the release date is by the end of Sep. 2005. So for the moment, you need to get CVS snapshot tarball from http://www.openser.org/downloads/snapshots/.
- the ebuild header is invalid, see http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3 - bison and flex are part of the base profile, just drop the DEPEND - do MY_P="${P}_src", use ${MY_P} in SRC_URI and unpack ${A}" instead "unpack ${P}..." - check_mods() is unnecessary, do that directly in src_compile - instead "make all" use emake - cfg-target=/etc/openser -> cfg-target=${ROOT}/etc/openser - modules-target=/usr/lib/openser/modules/ -> modules-target=${ROOT}/usr/lib/openser/modules/ - doc-dir=${P} -> doc-dir=${PF} - /etc/init.d/openser stop >/dev/null -> ${ROOT}/etc/init.d/openser stop >/dev/null
Thanks for the comment. I will fix it. (It's my first time to submit ebuild. Guess that I didn't read the dev handbook carefully enough. :-)) (In reply to comment #4)
Created attachment 69407 [details] openser.init
Please fix the following and reopen: * http://dev.gentoo.org/~ciaranm/docs/mw-faq/spacing.txt * S= is redundant * check_mods should probably be pkg_setup, and have an export * http://dev.gentoo.org/~ciaranm/docs/mw-faq/keywords.txt
I posted a question about modifying this ebuild on Gentoo forum, which is http://forums.gentoo.org/ viewtopic-t-386407-highlight-.html. Would somebody here please answer that?
OpenSER 1.0.0 is set to be released on Friday, October 28. I have updated the ebuild according to comments above and tested with latest CVS snapshot (dated 10-26).
Created attachment 71548 [details] openser-1.0.0.ebuild
this path needs to be applied to openser.cfg otherwise all the paths are wrong and openser can't start diff -u openser.cfg.orig openser.cfg --- openser.cfg.orig 2005-12-17 13:31:43.000000000 +0100 +++ openser.cfg 2005-12-17 13:32:46.000000000 +0100 @@ -36,20 +36,20 @@ # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database -#loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/mysql.so" +#loadmodule "/usr/lib/openser/modules/mysql.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/sl.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/tm.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/rr.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/maxfwd.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/usrloc.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/registrar.so" -loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/textops.so" +loadmodule "/usr/lib/openser/modules/sl.so" +loadmodule "/usr/lib/openser/modules/tm.so" +loadmodule "/usr/lib/openser/modules/rr.so" +loadmodule "/usr/lib/openser/modules/maxfwd.so" +loadmodule "/usr/lib/openser/modules/usrloc.so" +loadmodule "/usr/lib/openser/modules/registrar.so" +loadmodule "/usr/lib/openser/modules/textops.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! -#loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/auth.so" -#loadmodule "/var/tmp/portage/openser-1.0.0/image//usr/lib/openser/modules/auth_db.so" +#loadmodule "/usr/lib/openser/modules/auth.so" +#loadmodule "/usr/lib/openser/modules/auth_db.so" # ----------------- setting module-specific parameters ---------------
And do you have anyplans for tls/ssl support?
And do you have anyp lans for tls/ssl support?
mysql.so gets built but is left out during install
No at this moment. But you are welcome to enhance the ebuild. (In reply to comment #12) > And do you have anyplans for tls/ssl support? >
That's supposed to be the job of "make install" of openser Makefile. Would you please check into and provide a patch? (In reply to comment #14) > mysql.so gets built but is left out during install >
- unpack ${A} - ${S}/Makefile.defs saves one directory change
Created attachment 80524 [details] all-in-one ebuild I rip the ebuild from the opense tls tar ball, made some bug fixes here and there. This has tls support, paths in the config file are correct and mysql.so gets installed. xming
version 1.0.1 is released, just bump the version
Please, integrate it as soon as possible :)
yes, please do : )
renaming to 1.0.1 works for latest version, however, init script seems to be broken. (using ser script it seems, as it tries to run /usr/sbin/ser instead of /usr/sbin/openser) Also, it doesn't install the postgres plugin. It is build properly. It exists int he build dir just fine, just won't get installed. I'm thinking it's upstream problem, but I'm reporting it here. If you want postgresql support, manually copy postgres.so from the modules dir from your PORTAGE_TMP to /usr/lib/openser as a quick work around.
Created attachment 88666 [details] Openser 1.0.1 All in one tar.gz file This file now installs postgres module, also fixes openser.cfg that after the "sed -e" command gets wiped, also in /usr/share/${P} installs the scripts fo creating the database on mysql and postgres. It can be improved a little bit more but can help.
Version 1.1.0 is out Merged the openser 1.1.0 official ebuild with all the changes here. - download problem (missing tls in the filename) - a openser init script (last one was still ser) - build problems (missing tls in the dirname) - install mysql & postgresql modules - sed the openser config file
Created attachment 91518 [details] all-in-one ebuild for 1.1.0 here is the attachment
Maybe it's time to give openser a /etc/conf.d entry aswell. This because right now openSER sets its domain name(s) to whatever you have is in /etc/hosts which sometimes doesn't always reflect all the domains that point to your IP. From what I gather they mention this in their documentation: first set the environment variable SIP_DOMAIN to your domain name Though I do think that that is only for the openserctl utility. Maybe someone who's more into openser (I just installed it and started using/testing it) knowlegde kan shed some light here?
just renaming the 1.1.0 ebuild to 1.2.2 seems to work. It compiles fine in uclibc. this package is probably easy to maintain (which asterisk is not).
by way of fellow gentoo dev Jeremy Olexa (darkside): Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manor. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
openser is in the voip overlay (from 1.0.0 to 1.3.1) But openser has changed to opensips [1] and we will have to update openser ebuild to opensips before adding it to the tree. [1] http://www.opensips.org/
Created attachment 189836 [details] openser-1.3.1 ebuild from the voip overlay Ebuild for "historical reason". It's from the voip overlay but it's going to be removed because the project is dead (see my previous comment). If someone want to do an ebuild for opensips, it could be interesting.
Looks like kamailio is maybe the renamed openser project and opensips a fork (see bug 224717). Anyway, they are both related to the dead openser.
Created attachment 209193 [details] Opensips ebuild These is ebuild for opensips 1.6.0 from http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=6258 with little fix
Created attachment 209197 [details] Init for opensips 1.6.0 These is init.d/opensips file for opensips 1.6.0 from http://opensips.svn.sourceforge.net/viewvc/opensips/trunk/packaging/gentoo/opensips.init?view=markup&pathrev=6258
Created attachment 296341 [details] Updated Ebuild for OpenSips 1.7.1 I took the time to update the ebuild file for OpenSips 1.7.1 (current version). Fixed a dependency and modified the unpack as the folder name doesn't match the tar file name. Installed on 32 bit empty system with no issues.
Hello, It could be really interesting to add the new version of sip-router/kamailio. Today we only have net-misc/ser which is pretty old. Also, notes that they already bundle an ebuild and everything ready for gentoo in their sources : http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=tree;f=pkg/ser/gentoo;h=344201ba4c6fb7a8b999e21896ca8ec9d4a220a3;hb=refs/heads/master
Modified ebuild for 1.8.0 (based on Anthony ebuild) with slight modification regarding wrong /share path and addititional patch for 1.8.0 for emake to succeed (seems broken for installation osipsconfig) available at my overlay: http://code.google.com/p/barzog-gentoo-overlay/ Compiles on amd64 without problems.
the kamailio package is awfully complex in terms of modules and dependencies If the maintainer of the http://git.overlays.gentoo.org/gitweb/?p=user/caio.git;a=tree;f=net-misc/sip-router;h=46c3288043944b97dae84cc7405749260b2de442;hb=HEAD overlay is interested, then we could clean it up together.
I've created an ebuild for the current stable version which kinda sorta works. Not tested at all though, and I have only built about half the modules so far. Produces (naturally) a lot of warnings with GCC 6.2.0-r1, but it does build. It's based off caio's version, with a complete rewrite of the deps according to 4.4.x documentation.
Created attachment 448628 [details] Preliminary ebuild for current 4.4.3 version
Created attachment 448630 [details] files/kamailio.default
Created attachment 448632 [details] files/kamailio.service
Created attachment 448636 [details] Alternative ebuild with USE_EXPAND You need USE_EXPAND="${USE_EXPAND} KAMAILIO_MODULES" or similar in your make.conf for this to work as intended.
Thanks George! @ Tony - what's your feeling re USE_EXPAND? I personally like the way it ends up looking during the verbose merge - it's clear these things are specific to this ebuild, and logically dictates what belongs where, but that said I recall we had some issues previously with getting a USE_EXPAND into mainline (asterisk-g729) and ended up using "normal" USE flags. @ George - a few comments (ebuild untested). You seem to only include a systemd service file here. A lot of us are not using systemd preferring to stick to openrc (call us die-hard but we just know and understand openrc so much better). I don't mind writing that init script for you (I'm the cook of most of the current /etc/init.d/asterisk anyway). There is a HUGE number of USE flags - do we really need all of them? Guessing kamailio is a monster of different proportions and I'll admit the sheer number of choices to be made is intimidating. The EXCMODULES variable is defined in src_unpack but not used again anywhere. Spotted whilst trying to track down where you're determining which modules gets included and which gets excluded. My opinion is most of what's in src_unpack really belongs in src_configure, and that you don't need a custom src_unpack at all. KAMODULES_ALL is for the most part a repeat of IUSE - perhaps define KAMODULES_ALL and then include that into IUSE rather? Since KAMODULES_ALL is dealt with using the for loop currently in src_unpack it would make it easier to verify the other (non-module) USE flags are dealt with since they'll be easier to pick out. REQUIRED_USE is a beast. It'll be tricky to verify all that. Ditto on DEPEND.
(In reply to Jaco Kroon from comment #43) > > You seem to only include a systemd service file here. A lot of us are not > using systemd preferring to stick to openrc (call us die-hard but we just > know and understand openrc so much better). I don't mind writing that init > script for you (I'm the cook of most of the current /etc/init.d/asterisk > anyway). Sure, go for it. Only reason I provided systemd service file is I'm running it on my system. > There is a HUGE number of USE flags - do we really need all of them? > Guessing kamailio is a monster of different proportions and I'll admit the > sheer number of choices to be made is intimidating. I don't know. My OCD kicked in so I went for it. Maybe it would make more sense to expose group_ module setting instead as setting modules individually won't provide needed functionality without the rest of its group. This is now handled in REQUIRED_USE, I'm sure there's much overlap with group_ settings. I'll see if there are any corner cases and adjust accordingly when I become more familiar with the software. > The EXCMODULES variable is defined in src_unpack but not used again > anywhere. Spotted whilst trying to track down where you're determining > which modules gets included and which gets excluded. Yes, it was a remnant from a previous ebuild. I have made an updated version where it's actually used, because kamailio's makefile will implicitly build any modules not depending on other modules, so I'm using this variable to enforce honouring of our USE flags. > My opinion is most of what's in src_unpack really belongs in src_configure, > and that you don't need a custom src_unpack at all. You're right. It's fixed in latest revision. > KAMODULES_ALL is for the most part a repeat of IUSE - perhaps define > KAMODULES_ALL and then include that into IUSE rather? Since KAMODULES_ALL > is dealt with using the for loop currently in src_unpack it would make it > easier to verify the other (non-module) USE flags are dealt with since > they'll be easier to pick out. Yes. IT's only present in the non-USE_EXPAND ebuild, because I had some troubles with bash :-) (which I'm slowly and painfully learning along the way). In the USE_EXPAND version module names are not repeated in IUSE. > REQUIRED_USE is a beast. It'll be tricky to verify all that. Ditto on > DEPEND. I'm launching an overlay with this ebuild and some others. I've also made ebuilds for rtpengine, sipcapture-homer, asterisk g72x codecs (beware of patent law) and some of their dependencies. It's now available at https://github.com/gedia/discworld-overlay. If anyone's interested in providing feedback, I'd appreciate it. Maybe I'll open separate bug reports for the other packages if there's interest for them...
Created attachment 450204 [details] Alternative ebuild with USE_EXPAND - updated
(In reply to George Diamantopoulos from comment #44) > I'm launching an overlay with this ebuild and some others. I've also made > ebuilds for rtpengine, sipcapture-homer, asterisk g72x codecs (beware of > patent law) and some of their dependencies. It's now available at > https://github.com/gedia/discworld-overlay. We've already got asterisk-g729 mainline in the tree. I've got an ebuild for asterisk-g72x which we discussed merging but decided against due to the patent problems. Kind Regards, Jaco
I reassign the ticket to maintainer-wanted, because the package is not in the tree and hence has no maintainer. I think this ebuild is far too complex to maintain it by a proxied maintainer alone in the official tree. But this is what overlays are good for.
