Online Devel Meeting - 2023-12-05

Note: the online meeting is planned to be hosted on a Matrix room. See more details below.

Date:

  • Proposed: 15:00 UTC, Tuesday, Dec 05, 2023
  • can attend: dcm, vseva, qxork, ...
  • cannot attend:

Time of the meeting across the world:

  • 16:00 - Berlin, Germany
  • 15:00 - London, UK
  • 10:00 - New York, USA
  • 07:00 - Seattle, USA

Place:

Utilities:

Participants

Participation is open to anyone, just join the chat room if you want to participate.

People adding notes in the agenda using abbreviations:

  • dcm - Daniel-Constantin Mierla
  • vseva - Victor Seva
  • qxork - Fred Posner

Agenda

Kamailio Development Status:

  • summary and follow up on Dusseldorf devel meeting (dcm)
  • open issues (dcm)
  • minor releases for 5.6 and 5.7 branches (dcm)
  • tracker issues review:
  • https://github.com/kamailio/kamailio/issues/
  • summary of packaging and distributions
  • summary of using github actions

Administration:

  • servers maintenance
  • community interaction and communication channels
  • existing mailing lists review

Kamailio 5.8 (next major release):

  • aim for 5.8 or 6.0
  • roadmap
  • features
  • anything relevant that is missing?
  • priorities

Documentation:

  • updates for wiki with markdown and mkdocs (github markdown)

Collaborative Projects:

  • unit testing, documentation, etc.
  • community announcements

Transcript

time (-0500 EST) matrix user content
10:17:25 @miconda:matrix.kamailio.dev Sorry, still 5min
10:24:24 @miconda:matrix.kamailio.dev ready to start
10:24:36 @miconda:matrix.kamailio.dev sorry again for the delay!
10:24:57 @miconda:matrix.kamailio.dev Hello everybody!
10:25:31 @miconda:matrix.kamailio.dev a little bit of an agenda at: https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings/2023a.md
10:27:42 @miconda:matrix.kamailio.dev hopefully those interested in the meetings are still around, so, the first topic would be the follow up after the Dusseldorf in-person meeting
10:28:17 @miconda:matrix.kamailio.dev the most topic debated so far was about obsoleting a group of modules
10:28:40 @miconda:matrix.kamailio.dev feedback on mailing list showed that some are still used
10:29:29 @miconda:matrix.kamailio.dev so I am considering to split the group of proposed obsoleted modules in two, one to be very soon relocated to a dedicated repo, and another one that should be kept for a while, but with an explicit warning
10:29:58 @henning:matrix.kamailio.dev A warning for such that are still used is surely a good idea, e.g. for one release period
10:30:00 @miconda:matrix.kamailio.dev that might even be something like don't start kamailio unless some (new) core parameter or modparam is set
10:30:06 @henning:matrix.kamailio.dev and then we could remove them
10:30:12 @henning:matrix.kamailio.dev also possible, strict warning :)
10:31:18 @miconda:matrix.kamailio.dev not sure if we should keep the list of such modules in the core and check as core loads modules
10:31:28 @miconda:matrix.kamailio.dev or have the code in each such module
10:31:55 @vseva:matrix.kamailio.dev a warning in each module seems fine to me
10:32:03 @miconda:matrix.kamailio.dev ok
10:32:13 @henning:matrix.kamailio.dev
10:33:15 @fred:matrix.lod.com Trying to remember which modules these were...
10:34:12 @miconda:matrix.kamailio.dev here is the email announcing them: https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/message/56MTKAXALSMBPFCA4KRMUQPJXMU65XLV/
10:34:13 @fred:matrix.lod.com Found them
10:35:01 @henning:matrix.kamailio.dev there have been not much feedback on the list
10:35:03 @miconda:matrix.kamailio.dev with the correction that uri_db was mistakenly added there
10:35:12 @henning:matrix.kamailio.dev
10:35:17 @fred:matrix.lod.com
10:35:32 @henning:matrix.kamailio.dev * there have been not much feedback on the list - so its probably fine for the people
10:36:36 @miconda:matrix.kamailio.dev ok, so we will follow up on mailing list on this topic
10:37:01 @miconda:matrix.kamailio.dev the second one coming out of Dusseldorf was the introduction of github actions for some automatic management of issues and PRs
10:37:30 @miconda:matrix.kamailio.dev that brought also some discussions, I think at this moment we are good with the process, having options to reopen such closed items
10:37:57 @miconda:matrix.kamailio.dev initially we thought it was already possible, but proved not to be, luckily Victor found some solution
10:38:20 @henning:matrix.kamailio.dev there were some feedback of surprised users, it would be good next time when we change something like this to announce it before ;-)
10:38:34 @miconda:matrix.kamailio.dev what could be done is tuning, for example the time lines, if someone thinks that it is too short 6 weeks to stale + 2 weeks to closing
10:39:16 @fred:matrix.lod.com
10:39:19 @miconda:matrix.kamailio.dev it was done in a let's try fashion, because time in Dusseldorf was only 2 days
10:39:52 @miconda:matrix.kamailio.dev and they were not closed, it was first coming as a "reminder" that they were stale
10:40:35 @miconda:matrix.kamailio.dev anyhow I am going to review and probably open several that I had in mind to investigate, but didn't find the time for
10:41:07 @vseva:matrix.kamailio.dev remember that bug tag keeps them open
10:41:12 @fred:matrix.lod.com Right now it's 42 days before stale, right? Seems fine
10:41:18 @henning:matrix.kamailio.dev I marked a few ones to work on it and re-open/keep open already
10:41:22 @miconda:matrix.kamailio.dev we anyhow wrote in many feature requests that the might be closed after one month of so, but then nobody look over them again
10:41:35 @henning:matrix.kamailio.dev
10:42:05 @fred:matrix.lod.com I think how the job is now works good... an improvement for sure.
10:43:30 @miconda:matrix.kamailio.dev ok ... anyhow, this work flow can be tuned at any time, just make suggestions via tracker or mailing lists
10:44:26 @miconda:matrix.kamailio.dev another topic that should be propagated to larger community was about the eventual need of making application shut down in two steps
10:45:21 @miconda:matrix.kamailio.dev apparently there are crashes at shut down because some modules depend on the other and one can destroy its records but other ones may still need to access them
10:46:20 @miconda:matrix.kamailio.dev to be like prepare-to-shutdown: when the module should write to db or other sync tasks, but still keep its records/structures in memory
10:46:53 @miconda:matrix.kamailio.dev and 2nd step: simply destroy everything about caring of locks/mutexes, or others needing to access local records
10:47:26 @miconda:matrix.kamailio.dev no change was done in Dusseldorf, this would require updates of the structures for module exports
10:47:52 @miconda:matrix.kamailio.dev but it is good to be aware of and eventually report cases when such change would be useful
10:48:20 @miconda:matrix.kamailio.dev it a good task to do at a future in-person meeting, if meanwhile is considered good to have
10:48:28 @vseva:matrix.kamailio.dev shutdown gracefully
10:48:56 @werebear73:matrix.org
10:49:23 @vseva:matrix.kamailio.dev yes, it would imply some changes. Maybe a online meeting??
10:49:39 @miconda:matrix.kamailio.dev that's an option as well
10:50:05 @vseva:matrix.kamailio.dev we should try to organize a kind of hands-on online meeting
10:50:11 @miconda:matrix.kamailio.dev also from Dusseldorf: analyzing the impact of FLAVOUR that can be set in the Makefiles, now defaulting to kamailio, but can be also ser or sip-router, iirc
10:50:33 @miconda:matrix.kamailio.dev my guess is that Juha uses a different flavour than the default one
10:50:45 @henning:matrix.kamailio.dev I wondered already a few times if we could not remove the FLAVOUR, maybe ask on the list if people are still using it
10:50:56 @miconda:matrix.kamailio.dev the real question is if there is still different behaviour inside the code
10:51:28 @miconda:matrix.kamailio.dev keeping the option to compile with different binary name could be fine, but if the behaviour changes, then we have to clean that somehow
10:52:02 @henning:matrix.kamailio.dev agree
10:52:09 @miconda:matrix.kamailio.dev iirc, one of the reasons was that if $xyz is not found as pseudo-variable, then the flavour=ser would consider that an avp, like $avp(xyz)
10:52:45 @miconda:matrix.kamailio.dev with flavour=kamailio, not finding $xyz should be considered an error
10:53:32 @miconda:matrix.kamailio.dev but that was proposed during 2009-2010 merge, I haven't done this part of the merge and I am not sure how it ended up, as I using onli flavour=kamailio
10:53:56 @miconda:matrix.kamailio.dev ok, so probably the first step is to ask on mailing list, as proposed above
10:54:08 @miconda:matrix.kamailio.dev then see whre it leads based on feeback
10:54:27 @vseva:matrix.kamailio.dev
10:54:44 @miconda:matrix.kamailio.dev another discussion in Dusseldorf was about eventual alternative to the "makefiles", maybe cmake
10:55:17 @miconda:matrix.kamailio.dev I think we discussed the topic in the past, like everyone would be ok to switch to something else if proves to be easier to maintain
10:55:34 @miconda:matrix.kamailio.dev but nothing was coming out of the past discussions
10:56:06 @vseva:matrix.kamailio.dev someone has to do the work and there's a lot of details in the Makefiles
10:56:08 @miconda:matrix.kamailio.dev anyone, one conclusion was that maybe we should review supported gcc versions, because they make the makefiles quite big now
10:56:20 @miconda:matrix.kamailio.dev as well as other compilers like suncc and icc
10:56:38 @henning:matrix.kamailio.dev this is a good idea to remove the really old gcc versions, like 2.9.x etc..
10:56:46 @henning:matrix.kamailio.dev 3.x, 4.x
10:56:58 @miconda:matrix.kamailio.dev for gcc, either remove the extremely old ones, or try to join those that set similar options
10:57:26 @miconda:matrix.kamailio.dev yes, 2.x and 3.x could be good candidates for removing
10:58:13 @miconda:matrix.kamailio.dev 4.x - I think there are some distro still using them, in the way that those distros might not be maintained, but people still run them
10:58:24 @miconda:matrix.kamailio.dev centos 6?!?
11:00:13 @miconda:matrix.kamailio.dev nex and probably last one from Dusseldorf, more for information ...
11:00:36 @miconda:matrix.kamailio.dev the addition of pre-commit hooks that could help formatting the code, removing trailing whitespaces, etc ...
11:00:48 @miconda:matrix.kamailio.dev if you missed the email about it, here it is: https://kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kamailio.org/message/7PSVLEKOMSCDMUYN4VZLIO4ZBRBJXMF6/
11:01:04 @miconda:matrix.kamailio.dev same one was sent to sr-users
11:02:07 @vseva:matrix.kamailio.dev hope it's helping
11:02:43 @vseva:matrix.kamailio.dev you can always skip checks with SKIP=<name> too
11:03:00 @miconda:matrix.kamailio.dev being the id of the check?
11:03:06 @vseva:matrix.kamailio.dev yes
11:03:54 @miconda:matrix.kamailio.dev to conclude on Dusseldorf meeting, if I missed something relevant from there, anyone that participated just write the topic here
11:04:50 @miconda:matrix.kamailio.dev ok, then next ...
11:05:19 @miconda:matrix.kamailio.dev open issue, more from the perspective of someone here knowing about issues not reported yet (open on your side)
11:05:51 @miconda:matrix.kamailio.dev from the reported ones, it seems there are cases of crashes when tls with libssl 3.x is used
11:06:16 @vseva:matrix.kamailio.dev I'm having that TLS + openssl 3 issue in a customer right now :-(
11:06:28 @vseva:matrix.kamailio.dev double free
11:06:37 @miconda:matrix.kamailio.dev trying to investigate, but it's not easy as crashing happen at tls layer (e.g., encryption negotiation)
11:08:18 @miconda:matrix.kamailio.dev because in some cases I noticed errors related to memory chunk tail overwritten, I thought there could be a buffer overflow, which might not be in the kamailio code, but in external libraries (like libmysqlclient or libcurl)
11:08:21 @vseva:matrix.kamailio.dev tlsa didn't help
11:08:51 @miconda:matrix.kamailio.dev I haven't looked at this libs to see if they reported such bugs for some of their older version that might be deployed on distros
11:09:20 @miconda:matrix.kamailio.dev anyhow, I added a core parameter in kamailio (master) that will allow to specify extra size for each allocated chunk
11:09:57 @miconda:matrix.kamailio.dev so at least one can protect in case off by 1-byte writes are discovered/reported in logs
11:10:44 @miconda:matrix.kamailio.dev so if no other ones to report right now, we have to dive deeper in the one related to tls and libssl 3.x
11:10:55 @miconda:matrix.kamailio.dev so next topic ...
11:12:33 @miconda:matrix.kamailio.dev communication channels: I think we should move from mailing list forums, not to be the last ones using mailing lists ... ok this just a joke, as I saw some hot discussions on such topic in other projects ...
11:13:20 @miconda:matrix.kamailio.dev but, as usual, if one wants to suggest new tools for making the interaction easier, simplify workflow, just do it at any time
11:13:41 @miconda:matrix.kamailio.dev lifting load from administrative point of view is always good
11:14:07 @fred:matrix.lod.com
11:14:49 @fred:matrix.lod.com I think what we have now works... I don't know what the slack area is like though
11:15:03 @fred:matrix.lod.com I also don't know if anyone still uses IRC
11:15:05 @vseva:matrix.kamailio.dev I'm fine with what we got
11:15:16 @vseva:matrix.kamailio.dev I'm connected to IRC... just silence there
11:15:33 @miconda:matrix.kamailio.dev ok -- and yes, maybe we can remove references to irc on the website
11:15:44 @fred:matrix.lod.com Great idea
11:15:52 @henning:matrix.kamailio.dev
11:15:57 @miconda:matrix.kamailio.dev if they are still uses, they can stay as just community
11:16:11 @henning:matrix.kamailio.dev
11:16:11 @devopsec:matrix.org i moved to matrix since irc was dead, no problems with matrix though
11:16:50 @fred:matrix.lod.com I'm happy with matrix most days ;)
11:16:51 @miconda:matrix.kamailio.dev then we can move on to releases
11:17:18 @miconda:matrix.kamailio.dev (keeping a high pace, since I was late and some might have to leave early)
11:17:34 @miconda:matrix.kamailio.dev minors from 5.6 and 5.7 were out pretty recently
11:18:06 @miconda:matrix.kamailio.dev probably a new one from 5.7 will happen in a matter of weeks, for 5.6 sometime later
11:18:09 @marrold:matrix.org
11:18:31 @miconda:matrix.kamailio.dev for a major release, I am not sure yet when
11:19:10 @miconda:matrix.kamailio.dev we could try a 5.8 in 2024 somehow earlier than usual, let's say to aim for march
11:19:41 @miconda:matrix.kamailio.dev * we could try a 5.8 in 2024 somehow earlier than usual, let's say to aim for March
11:20:02 @henning:matrix.kamailio.dev 5.7.0 was in May this year
11:20:09 @miconda:matrix.kamailio.dev that could be good if we want to go afterwards for a 6.0 with some major changes
11:20:45 @miconda:matrix.kamailio.dev yes, we ended up releasing like May or June lately, like 1 year time frames in between
11:20:52 @vseva:matrix.kamailio.dev
11:22:05 @miconda:matrix.kamailio.dev probably we can decide at the begining of the next year, after the season holidays, maybe we can plan it better
11:22:52 @fred:matrix.lod.com I'd love to move on to 6... but agree there should be something major for that change.
11:23:03 @henning:matrix.kamailio.dev
11:23:59 @miconda:matrix.kamailio.dev ok, so let's leave it for mailing lists
11:24:39 @miconda:matrix.kamailio.dev on server administration side I think we are ok ... is debian 11 still maintained?
11:25:19 @miconda:matrix.kamailio.dev or we have some pressure to migrate to debian 12?!?
11:25:31 @fred:matrix.lod.com no pressure yet I hope
11:25:33 @fred:matrix.lod.com ;)
11:26:00 @fred:matrix.lod.com July 2024
11:26:28 @miconda:matrix.kamailio.dev ok, still time
11:26:42 @fred:matrix.lod.com Oh wait, thats 10
11:26:46 @fred:matrix.lod.com even longer =)
11:26:55 @fred:matrix.lod.com June 2026
11:26:55 @henning:matrix.kamailio.dev
11:27:07 @vseva:matrix.kamailio.dev https://wiki.debian.org/LTS
11:27:24 @henning:matrix.kamailio.dev
11:27:48 @vseva:matrix.kamailio.dev image.png
11:28:34 @vseva:matrix.kamailio.dev no real rush but I would try to move to bookworm
11:28:39 @devopsec:matrix.org just a side note, this tool this awesome for checking EOL dates, here is the debian entry https://endoflife.date/debian
11:29:33 @vseva:matrix.kamailio.dev I think the hard part was already done migrating the mailman
11:29:38 @fred:matrix.lod.com speaking of fun url's.... https://rtfm.tel/kamailio ;)
11:30:27 @miconda:matrix.kamailio.dev yep, hopefully debian 11 to 12 is going to be easier than 10 to 11
11:30:40 @fred:matrix.lod.com I need to move kama3 to 11
11:30:57 @miconda:matrix.kamailio.dev removal of python2 brought some headaches with many apps, including unavailability of mailman2
11:31:30 @miconda:matrix.kamailio.dev next one then ...
11:31:50 @miconda:matrix.kamailio.dev from the mailing list, when this meeting was announced, someone proposed about handling REFER, this being more like a feature request: while it may not require a full b2bua behaviour, it should need a new module to track sdps and parties involved in call ... so, as usual, some development. Personally I don't have a need for it
11:32:36 @miconda:matrix.kamailio.dev otherwise I haven't spotted more proposals to discuss
11:33:43 @vseva:matrix.kamailio.dev about the changes needed to isolate global variables in modules ... can you please provide an example of what you would like things to be?
11:34:01 @henning:matrix.kamailio.dev we could switch to C++ :D
11:34:15 @vseva:matrix.kamailio.dev so I can later go module by module and do it
11:35:48 @miconda:matrix.kamailio.dev it's how was done while porting some patches from an external (cloned) repository
11:35:59 @miconda:matrix.kamailio.dev if you look at ims_qos module, it has now:
11:36:32 @miconda:matrix.kamailio.dev ims_qos_params_t _imsqos_params = { .recv_mode = 0, .dlg_direction = DLG_MOBILE_REGISTER};
11:37:08 @miconda:matrix.kamailio.dev with:
11:37:09 @miconda:matrix.kamailio.dev typedef struct ims_qos_params {int recv_mode;int dlg_direction;}ims_qos_params_t;
11:37:36 @miconda:matrix.kamailio.dev for everybody else, this is actually also from in-person Dusseldorf meeting
11:37:51 @miconda:matrix.kamailio.dev a discussion about how to avoid global variables conflicts
11:38:23 @miconda:matrix.kamailio.dev because sometimes it happens different modules have same global variables for similar purposes, like the db_url
11:38:33 @vseva:matrix.kamailio.dev ACK. I didn't noticed. Thanks!
11:39:03 @vseva:matrix.kamailio.dev I will try to work on that on my spare time
11:39:33 @miconda:matrix.kamailio.dev however, in some cases, because symbols are made globals when opening the .so files, they can conflict, the linker may find first the db_url global variable of another module ...
11:39:52 @miconda:matrix.kamailio.dev the use of db_url is to give the example here
11:41:05 @miconda:matrix.kamailio.dev one of the proposals in Dusseldorf was to create a structure to collect parameters and have one global variable for that structure with a name specific to the module
11:41:25 @miconda:matrix.kamailio.dev so I took that approach when I ported some stuff for ims_qos module from an external repo
11:41:51 @henning:matrix.kamailio.dev usually we prefix the module name or a part of the module name as part of the variable, e.g. cr_db_url (carrierroute) etc..
11:42:45 @miconda:matrix.kamailio.dev for more context, I met the guy that wrote those patches at an event a few months ago and I said I could help to port them to our master branch, because they were done for 5.3.x
11:43:16 @miconda:matrix.kamailio.dev yes, we prefix with the module name, that's ok, but some PRs come without
11:43:58 @miconda:matrix.kamailio.dev maybe it would be better if the external contributors discover we use a structure for modparams and they add fields there
11:44:13 @miconda:matrix.kamailio.dev anyhow, this was just a proposal, not something that must to be done
11:44:37 @miconda:matrix.kamailio.dev it was considered good to use such approach in the future, for new params, ...
11:44:58 @miconda:matrix.kamailio.dev of course, if one wants to do it for own modules, it's fine
11:45:25 @vseva:matrix.kamailio.dev If we have it... people will just add new parameters the same way
11:45:46 @miconda:matrix.kamailio.dev yes, that would be the scope
11:46:34 @henning:matrix.kamailio.dev My suggestion to use C++ was not completely meant as joke, this would help of course with this kind of global namespace issues. But of course it would be a serious change and we would need to really define the subset of C++ we want to use, otherwise its getting way to complex.
11:47:15 @henning:matrix.kamailio.dev and of course its a major effort in the end unfortunately
11:47:40 @henning:matrix.kamailio.dev So its probably not realistic
11:47:58 @vseva:matrix.kamailio.dev I would prefer to use glib instead :-)
11:48:46 @henning:matrix.kamailio.dev something like boost would be of course great. No personal experience with glib from my side, though
11:49:32 @miconda:matrix.kamailio.dev is glib on *BSD? if I am not wrong thinking g comes from GNU?!?
11:50:33 @henning:matrix.kamailio.dev LGPL-2.1-or-later
11:51:03 @miconda:matrix.kamailio.dev is LGPL, so probably *BSD guys have nothing againt it, like they usually have against pure GPL software :-)
11:51:39 @miconda:matrix.kamailio.dev anyhow, I am not familiar with as well, if found useful somewhere, it can be considered of course
11:51:50 @miconda:matrix.kamailio.dev I think rtpengine uses it extensively ...
11:52:32 @vseva:matrix.kamailio.dev https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/glib2/index.html
11:52:33 @henning:matrix.kamailio.dev yes, its used from rtpengine
11:52:45 @miconda:matrix.kamailio.dev as there are no major topics I can add here, everyone feel free to propose ... we can aproach in the order of posting ...
11:53:35 @miconda:matrix.kamailio.dev it's like 1h30min since we started ... time flies quickly ...
11:54:43 @miconda:matrix.kamailio.dev on packaging and docker, I think Victor wanted to merge some repos ... not sure if was sorted out somehow, whether is possible or note
11:54:48 @miconda:matrix.kamailio.dev * on packaging and docker, I think Victor wanted to merge some repos ... not sure if was sorted out somehow, whether is possible or not
11:55:20 @miconda:matrix.kamailio.dev iirc, one was used more by Sergey for rpms (?!?), the other one was more for debs
11:56:41 @miconda:matrix.kamailio.dev also, on ci/cd, as it seems that github actions are powerful, if anyone is aware of some that could bring more magic to kamailio work flows, just suggest them here or on mailing list
11:57:53 @vseva:matrix.kamailio.dev I did some work to keep what it was running... I've not response from Sergey
11:58:09 @miconda:matrix.kamailio.dev ok
11:58:44 @miconda:matrix.kamailio.dev anything else that one wants to discuss officially as part of the devel meeting (which means it can get in the transcript)
11:58:46 @vseva:matrix.kamailio.dev * I did some work to keep what it was running... I've no response from Sergey
11:59:32 @miconda:matrix.kamailio.dev if not, we can end the official devel meeting and start free discussions (not in transcript)
12:00:01 @vseva:matrix.kamailio.dev Thanks to everyone
12:00:18 @miconda:matrix.kamailio.dev Thanks all!
12:00:36 @fred:matrix.lod.com Thank you all for all that you do.
12:01:04 @miconda:matrix.kamailio.dev Once again sorry for keeping you waiting for me at the beginning, sometime a little snow and ice blocks Berlin at the end of working hours!
12:01:25 @miconda:matrix.kamailio.dev then free discussions ...
12:01:38 @miconda:matrix.kamailio.dev what's new and worth discussing from RTC space
12:01:48 @miconda:matrix.kamailio.dev * what's new and worth discussing from RTC space?!?
12:02:48 @miconda:matrix.kamailio.dev noticed some hot debates around Matrix changing the license and requiring CLA, ... Asterisk willing to close mailing lsits ... anything else that I missed?
12:03:43 @miconda:matrix.kamailio.dev btw, FOSDEM 2024 has again an RTC devroom: https://lists.fosdem.org/pipermail/fosdem/2023q4/003518.html
12:03:59 @fred:matrix.lod.com The matrix change should be fun ;)
12:04:06 @miconda:matrix.kamailio.dev not sure I can go at this edition, I will try, but I don't know at this moment
12:05:12 @miconda:matrix.kamailio.dev is matrix now AGPL? or what they changed to? I think I saw it but I forgot ...
12:06:18 @fred:matrix.lod.com the new forks will use AGPLv3
12:06:33 @fred:matrix.lod.com with a contributor license agreement
12:07:02 @fred:matrix.lod.com They still haven't described how/when forks will happen, so upgrading is still unknown.
12:07:32 @henning:matrix.kamailio.dev interesting development
12:07:44 @fred:matrix.lod.com Matrix announcement
12:09:16 @miconda:matrix.kamailio.dev we can go back to IRC if matrix derails :-)
12:09:54 @fred:matrix.lod.com xmpp ;)
12:11:23 @henning:matrix.kamailio.dev regarding open source support, I've had some discussion about similar topics some weeks ago with the homer guys https://github.com/sipcapture/homer-ui/issues/627
12:12:32 @henning:matrix.kamailio.dev unfortunately it seems not many companies support their open source development efforts
12:13:57 @henning:matrix.kamailio.dev they also looking more into moving to homer 10, which would be basically use grafana to do some of the infrastruture stuff
12:15:06 @miconda:matrix.kamailio.dev is H 10 out? or work in progress (eta in such case)?
12:15:15 @fred:matrix.lod.com This just reminded me how much I love SIPDUMP by the way
12:16:25 @miconda:matrix.kamailio.dev - sipdump for tls is magnificent ... + sngrep
12:19:28 @vseva:matrix.kamailio.dev I forgot about kamcmd => kamcli
12:19:55 @vseva:matrix.kamailio.dev * I forgot about kamcmd/kamctl => kamcli
12:19:56 @henning:matrix.kamailio.dev homer 10 is still in development
12:20:00 @miconda:matrix.kamailio.dev that's something we discuseed at past editions, so I haven't put it back on table
12:20:56 @miconda:matrix.kamailio.dev maybe we could "forget" old tools when starting a fresh 6.x series :-)
12:21:07 @vseva:matrix.kamailio.dev
12:21:39 @vseva:matrix.kamailio.dev I've to leave. See you!
12:22:19 @miconda:matrix.kamailio.dev Thanks! Bye!
12:22:58 @miconda:matrix.kamailio.dev Soon I'll have to hunt something for dinner as well ...
12:24:43 @miconda:matrix.kamailio.dev I am going to check here from time to time in case something new pops up ... but I say bye now to those that are going to leave!