Module: sip-router
Branch: master
Commit: 23a22e2c8d73843798d66ec1bebe22cf7702213b
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=23a22e2…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Sun Mar 3 23:53:14 2013 +0100
Makefile: split module groups definitions in Makefile.groups
- the part was quite big and it is more config related than build rules
- it has to be updated with the current list of modules
---
Makefile | 243 +------------------------------------------------------
Makefile.groups | 245 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 247 insertions(+), 241 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=23a…
Hello,
from my point of view, the last to sort out for v4.0.0 is packaging (I
just sent a dedicated email to decide on that). Personally I have been
testing v4.0.0 thoroughly in various cases, no critical issue being on
my list at this moment. Also, v4.0 is running for quite some time on
voipuser.org (our usual life testing platform).
I propose releasing v4.0.0 next Monday, on March 11, 2013. The second
option, if more people prefer it, would be Thursday, March 14, 2013.
Opinions? If anybody has other dates in mine, let us know here.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#275 - FIFO deadlock after dispatcher reload
User who did this - Dmitry (dmdm21)
----------
It looks like instead of lock_destroy() we should be using lock_release() in ds_ht_clear_slots() ds_ht.c.
After making this change I'm not getting locks anymore.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=275#comment786
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#274 - not able to compile Kamailio 3.3.4
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Not a bug
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=274
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#274 - not able to compile Kamailio 3.3.4
User who did this - Daniel-Constantin Mierla (miconda)
----------
It was actually about glib (standard c lib). Anyhow, from devel list this was sorted out, by using linux kernel instead of bsd one.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=274#comment785
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hello,
(cross-posting as this decision may be done properly with feedback from
both developers and users community).
Now that we have some band new modules but also several that were not
packaged by Kamailio, just by ser (due to single modules directory), I
was thinking we may want to reconsider a bit the packages we do for v4.0.0.
1) A new package is related to the bunch of IMS modules, that is pretty
much obvious.
2) There are few modules targeting development samples or
troubleshooting: print, print_lib and malloc_test - I think they should
not be packaged.
3) I would create a special package for the modules using uid-based
database schema: db2_ops uid_auth_db uid_avp_db uid_domain uid_gflags
uid_uri_db uri_db
4) Maybe we should merge some packages by dependencies:
- a) some depend on libxml2: cpl-c xhttp_pi xmlrpc xmlops
- b) some depend on libssl: tls auth_identity outbound
5) Some experimental modules with external deps will stay unpackaged
like so far: db_oracle
Opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -