| 00:03.26 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 00:03.38 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 00:41.32 | superscrat | <PROTECTED> |
| 01:38.21 | *** join/#asterisk-dev spditner (~simon@69-165-137-174.dsl.teksavvy.com) |
| 01:51.33 | *** join/#asterisk-dev sgalarneau (~Adium@user-24-96-87-214.knology.net) |
| 03:20.59 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 03:34.14 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 04:52.41 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 05:43.06 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-hsxyyzhmpztvhpfa) |
| 06:03.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 06:03.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:14.50 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:19.41 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:26.36 | *** join/#asterisk-dev fish9370 (~Miranda@psy.iptelefon.su) |
| 11:12.42 | stefan27 | file can you elaborate what you wanted from comment on Line 1631 on https://gerrit.asterisk.org/#/c/490 |
| 11:13.09 | file | one sec |
| 11:13.51 | stefan27 | under what conditions can ast_rtp_ice_on_complete be called more than once for same rtp instance? |
| 11:16.04 | file | I can't remember if hold/unhold from a SIP based WebRTC client will do an ICE re-negotiation or not |
| 11:16.49 | file | yup, it can |
| 11:17.12 | stefan27 | Aha, we disabled SIP-based hold/unhold for our webrtc clients, so i havent tested that |
| 11:17.46 | stefan27 | (because there was a bug with hold/unhold with old SIPml+webrtc2sip) |
| 11:18.54 | stefan27 | so do you think dtls_perform_handshake should ever be called from ast_rtp_on_ice_complete while rtp->dtls.dtls_setup != AST_RTP_DTLS_SETUP_PASSIVE is true? |
| 11:19.39 | file | so, that function does a few things |
| 11:19.56 | file | it sets the state of the SSL instance, changes our internal state, and does the handshake |
| 11:20.27 | file | I think it should be called and change our internal state... but without diving into OpenSSL I'm not sure if we have to set the state if we are re-negotiating DTLS |
| 11:22.46 | file | as well - is it fine if we don't call SSL_do_handshake if we're passive? |
| 11:23.04 | file | these are the questions |
| 11:25.00 | stefan27 | I don't remember... All i know empirically is that _always_ calling dtls_perform_handshake from ast_rtp_on_ice_complete while passive was bad because two different threads could be operating on the same ssl struct (one from dtls_perform_handshake) other from the ssl-part of __rtp_recvfrom() in that case |
| 11:25.35 | stefan27 | I have much less knowledge of openssl and asterisk than you :) |
| 11:25.42 | file | I don't know OpenSSL |
| 11:26.16 | stefan27 | me neither, i just inspected thread stacks upon crash. I couldn't make sense of the doc |
| 11:26.37 | file | and this isn't really an Asterisk specific issue, it's more - how should we be using OpenSSL, are we using it wrong, should we be protecting things, is there stuff we're doing that we shouldn't be doing |
| 11:26.55 | file | and answering those questions is hard |
| 11:29.15 | file | and this is where I hide in a corner and rock back and forth |
| 11:29.23 | stefan27 | you're right... i'm least suitable person to address those questions. my only interest was pushing up an empirical fix hoping someone could turn it into a proper fix. |
| 11:30.46 | file | I wouldn't wish OpenSSL on my worst enemy. |
| 11:32.03 | file | but, at least it's Friday |
| 11:32.12 | stefan27 | did you read the russian guy's patch https://issues.asterisk.org/jira/browse/ASTERISK-24651 . I think he tried to address the same issue but by mutexing all calls to SSL stuff among other things |
| 11:32.19 | file | yes |
| 11:32.39 | stefan27 | his patch didn't work for me on ast 13 though i might have applied it wrong |
| 11:34.11 | stefan27 | but the only bad races in openssl ive witnessed are from the calls from __rtp_recv_from and dtls_perform_handshake when asterisk has passive role |
| 11:35.48 | stefan27 | The guy that commented on reviewboard had nickname one47 or something was that one of you or someone else? |
| 11:36.08 | file | ummm someone else I think |
| 11:36.46 | stefan27 | https://reviewboard.asterisk.org/r/4521/ |
| 11:36.48 | file | it's too bad they did not say their research |
| 11:37.00 | stefan27 | he said something about having done research why it worked |
| 11:37.53 | stefan27 | but it's always possible this patch solves the problem in my setup and creates 3 other problems in other setups |
| 11:38.13 | file | that's been the general theme with changes in this area |
| 11:39.20 | file | I'm sure someone will get to a full analysis eventually |
| 11:43.11 | stefan27 | I have more personal interest in ASTERISK-24925 anyways. That issue is just as obscure but with pjnath in place of openssl |
| 11:45.33 | stefan27 | I doubt I will ever get to a full analysis of 24832 myself unless i educate myself in C, openssl and asterisk for months only |
| 11:46.02 | stefan27 | rather years |
| 11:47.19 | stefan27 | oh well hopefully someone with extensive openssl-knowledge gets a final word some day |
| 11:47.44 | file | well, or someone with time to go through OpenSSL and research |
| 12:05.54 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:09.35 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-ainoiiikorbbdpmq) |
| 12:39.00 | *** join/#asterisk-dev doome (~doome@82.150.48.146) |
| 12:44.31 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-pcadjjfxrfxsqxxo) |
| 13:08.02 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-juibasflzvzeqmrj) |
| 13:30.45 | *** join/#asterisk-dev sgalarneau (Adium@nat/digium/x-sjggbmpdcldxpahb) |
| 13:50.29 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:50.29 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:57.46 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 13:57.46 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 14:02.52 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-iwiqpexwumyrnbbw) |
| 14:11.45 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-hhxagsvfniiacgjh) |
| 14:11.45 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:41.19 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:45.59 | gtjoseph | mjordan: 13.4 is closed now right? So changes to CHANGES for the AMI event should go in a 13.5 section? |
| 14:49.19 | mjordan | gtjoseph: Yup, 13.5 |
| 14:49.25 | gtjoseph | cool |
| 14:49.44 | mjordan | we've got about 100 issues in 13.4, since it took awhile for me to get the scripts ported. It's a hefty release :-P |
| 14:50.19 | gtjoseph | yeah, I noticed. Nice to get them cleaned out. |
| 15:18.47 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-cqvkabxvhbrjuqno) |
| 15:18.47 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:25.02 | tm1000 | "ASTERISK-25040 - pbx: Improve performance of reloads by making |
| 15:25.02 | tm1000 | <PROTECTED> |
| 15:25.10 | tm1000 | mjordan: /me dances |
| 15:25.46 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 15:28.21 | Qwell | "performant" is such an awesome word |
| 15:36.58 | file | I like tacos more. |
| 15:37.51 | sgalarneau | that's not a difficult choice |
| 15:38.08 | sgalarneau | a word that isn't technically a word, or yummy mexican food |
| 15:44.53 | file | reviews 498 and 499 could use some eyes |
| 15:46.02 | file | mjordan, I plan on looking at your caching over the long weekend fyi |
| 15:52.20 | mjordan | file: ack |
| 15:53.04 | mjordan | file: so long as I can still use a bucket backend for the actual HTTP portion, then any findings you have should be just fine. It feels like we're implementing similar things in multiple locations in Asterisk, but with slightly different purposes such that it may not be possible to pull them all together |
| 15:53.40 | file | mjordan, that's where my initial glance led me - and trying to pull them together would harm either use case |
| 16:01.47 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-tabsngycnzoelrpd) |
| 16:06.59 | mjordan | file: one minor thought on the sorcery cache |
| 16:07.10 | mjordan | file: given how often we have to write lock the cache, we may find that a regular mutex is more effective |
| 16:07.17 | mjordan | I wouldn't change anything just yet |
| 16:07.21 | file | aye |
| 16:07.23 | mjordan | but we may want to play around with that at some point in testing |
| 16:07.58 | file | 'tis easy enough to change and toy with |
| 16:09.52 | mjordan | yup yup |
| 16:36.41 | coreyfarrell | mjordan: did your review fix the release summary or just the change log? |
| 16:53.19 | mjordan | coreyfarrell: the release summary already skipped merge commits. The existing errors in the release summary in 13.4 (which is pretty messed up) was caused by a bad version of the underlying JIRA library on the build agent |
| 16:57.49 | coreyfarrell | weird it looks like it over-counted in 'Coders'. Says I coded for 31 bugs, but then I'm only listed under 27 bugs. the reporters look like they are counted double - like it's counting the JIRA reporter even when it counts "Reported by:". |
| 17:17.35 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-71-215.user.veloxzone.com.br) |
| 17:26.46 | mjordan | coreyfarrell: yeah, I'm not sure what happened there yet. I do know there are some funky things happening with unicode that are going to force me to redo some of the author tracking. |
| 17:27.00 | file | mjordan, I'll let you cherry pick that one... |
| 17:27.12 | file | yay |
| 17:27.48 | mjordan | file: fix all the things |
| 17:40.39 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 17:42.39 | hexanol | I'm porting some code to asterisk 13 and have a question |
| 17:43.00 | hexanol | is the struct ast_features_pickup_config returned from ast_get_chan_features_pickup_config can be considered immutable ? |
| 17:43.49 | mjordan | yes. |
| 17:44.09 | mjordan | Any struct that holds in-memory values pulled from a configuration file should not be changed by modules. You're invalidating the configuration provided by the user. |
| 17:44.16 | hexanol | because I was at looking at chan_sip for the usage of this function and there's the following code: |
| 17:44.16 | hexanol | /* Don't need to duplicate since channel is locked for the duration of this function */ |
| 17:44.16 | hexanol | pickupexten = pickup_cfg->pickupexten; |
| 17:44.23 | mjordan | If you need to hold that value somewhere else where something else may mutate it, you should copy that into some other struct that your module manages. |
| 17:45.01 | hexanol | alright |
| 17:45.17 | coreyfarrell | mjordan: did you see my reply on https://gerrit.asterisk.org/481? |
| 17:45.28 | mjordan | coreyfarrell: yeah, I'm still mulling it over. |
| 17:45.29 | hexanol | so the comment in chan_sip is then wrong... it's not because it is holding the channel lock that the value of pickup_cfg->pickupexten will not change |
| 17:45.53 | hexanol | it just doesn't change at all; if it does, it will be a new astobj2 |
| 17:45.54 | mjordan | coreyfarrell: I really dislike adding nolock variants for any API that wraps an opaque object. |
| 17:46.06 | mjordan | locking for an opaque object should be provided by the API |
| 17:46.24 | mjordan | it requires consumers of the API to know *way* too much about the internals of the thing that they are supposed to be protected from |
| 17:46.34 | coreyfarrell | mjordan: ahh.. so my biggest reasoning for most of the changes is that all other procedures which either accept a 'struct ast_context*' parameter or return one requires the caller to have a lock. |
| 17:46.42 | mjordan | yeah |
| 17:46.46 | coreyfarrell | I don't much like it, but that's how pbx.c works |
| 17:46.48 | mjordan | pbx.h is fundamentally sucky |
| 17:47.05 | mjordan | it is similar to the old channel.h code. |
| 17:48.06 | mjordan | hexanol: not really |
| 17:48.16 | mjordan | hexanol: the configuration may be coming off of a channel in that case |
| 17:48.26 | mjordan | hexanol: in either case, you should be treating it as immutable |
| 17:48.50 | hexanol | ok thanks |
| 17:51.17 | coreyfarrell | rmudgett: if you have time can you take a look at 481 as well? |
| 17:52.39 | rmudgett | coreyfarrell: k |
| 18:20.33 | leifmadsen | mjordan, ping |
| 18:20.43 | leifmadsen | mjordan, who can I make recommendations to for naming of release files :) |
| 18:21.00 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 18:21.03 | leifmadsen | lol |
| 18:21.06 | file | we're in a meeting, but you could bring it up on -dev... although naming? |
| 18:21.16 | leifmadsen | mjordan, Marquis42 wants to know what you hate packages so much :) |
| 18:21.38 | leifmadsen | file, very simple.... certified-asterisk-13.1-cert2 should be certified-asterisk-13.2.cert2 |
| 18:21.40 | Marquis42 | s/what/why/ |
| 18:21.42 | Marquis42 | :) |
| 18:21.47 | file | oh, formatting |
| 18:21.49 | leifmadsen | otherwise it messes with RPM builds |
| 18:22.12 | leifmadsen | Marquis42, it's not my fault I've had a couple beers |
| 18:22.19 | leifmadsen | ...or maybe it is. Get off my lawn! |
| 18:22.42 | leifmadsen | I wonder if I'm actually subscribed to asterisk-dev at all heh |
| 18:22.53 | Marquis42 | heh |
| 18:22.58 | leifmadsen | turns out I'm not |
| 18:23.00 | leifmadsen | maybe I will be shortly |
| 18:23.59 | leifmadsen | right after mod approval :D |
| 18:24.07 | leifmadsen | in the mean time this is something i can fix with tar :D |
| 18:34.57 | roramirez | Hi guys! |
| 18:43.41 | roramirez | i dont know file is Joshua. I knew when read old logs on my client IRC. |
| 18:43.52 | file | hi |
| 18:44.11 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 18:48.59 | roramirez | file, you can help me with a doubts in a reviews? |
| 18:49.18 | file | I'm in a meeting but if you have a question I, or others, may be able to answer |
| 18:50.23 | roramirez | is a review abandon https://gerrit.asterisk.org/191/ |
| 18:51.12 | roramirez | this review is associate a issue ASTERISK-24992, i send the feedback but i think is not checked. |
| 18:51.15 | coreyfarrell | roramirez: yes.. |
| 18:51.31 | roramirez | what happend in this cases... after make a new review? |
| 18:51.56 | file | that code was changed |
| 18:52.10 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:52.13 | file | that workspace code |
| 18:52.32 | file | looks |
| 18:52.55 | file | ah it was the serialize variables |
| 18:53.22 | roramirez | my question is only for know the process for try do good the things. |
| 18:53.54 | file | Matt hasn't gotten to it, but you can always push something to gerrit again for review |
| 18:55.13 | roramirez | ok i understand. |
| 18:58.17 | roramirez | other thing... file do can explain a little more about the comment review https://gerrit.asterisk.org/404/ . Is possible you don't found (sorry, bad joke) |
| 19:00.56 | file | roramirez, there is no lock protecting file_csv_master, meaning if you reload when it is getting used the value may be incorrect in csv_log |
| 19:02.59 | roramirez | file, i make a lock a file_csv_master or you thinks is a wasted time for a little fix? |
| 19:05.29 | file | I don't know if it would really make much of a difference in reality |
| 19:07.36 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 19:35.18 | leifmadsen | w00t! certified-asterisk 13.1.cert2 RPMs built :) |
| 19:54.19 | zerohalo | woot! |
| 20:35.41 | *** join/#asterisk-dev y_ateya (~y_ateya@41.45.104.36) |
| 20:40.23 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:51.12 | roramirez | someone use a Debian 8? i check in the script install_prereq to a package to install is libgmime-dev (virtal, i suppose) but in Debian 8 i not found. |
| 21:51.40 | gtjoseph | it's the same on fedora. i don't think it's needed anymore |
| 21:52.46 | mjordan | it is used by res_http_post |
| 21:52.52 | mjordan | or at least, pretty sure it is |
| 21:53.48 | gtjoseph | hmmm. i compile that module. |
| 21:54.01 | gtjoseph | install_rprereq looks for gmime22 and i don |
| 21:54.04 | gtjoseph | t have it |
| 21:54.24 | roramirez | i try a do "regular expresion" for the package list but after check in other Debian version is not work :( https://gerrit.asterisk.org/#/c/508/1..2/contrib/scripts/install_prereq |
| 21:55.18 | mjordan | fair enough - the only thing I could recall was that res_http_post used gmime, but that might be provided by something else |
| 21:58.17 | roramirez | in a Ubuntu exists a virtual called libgmime-dev on Debian i can not find. |
| 21:58.42 | gtjoseph | roramirez: just try compiling without it. |
| 22:00.31 | coreyfarrell | are we still supposed to put 'Reported by:' in commit messages or can we just let the release scripts lookup the reporter from JIRA? |
| 22:00.31 | roramirez | yep, gtjoseph, i want find a way to fixed this in install_rprerep |
| 22:01.25 | gtjoseph | ah. i think removing it from install prereq might be the way to go. while you there, remove subversion. |
| 22:02.49 | mjordan | coreyfarrell: you can let the release scripts do it. The only real reason to put Reported by is if the person who created the issue in JIRA is not necessarily the right person. |
| 22:03.09 | coreyfarrell | I don't understand why subversion was ever installed by that script... I mean if you have install_prereq then you're either using a tarball or you already did a checkout/clone. |
| 22:04.13 | coreyfarrell | gtjoseph, roramirez: actually 'svn' is used by contrib/scripts/get_mp3_source.sh |
| 22:04.26 | gtjoseph | really? |
| 22:04.29 | roramirez | exists other function of script use svn co |
| 22:04.39 | gtjoseph | oh well |
| 22:04.44 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-cqvkabxvhbrjuqno) |
| 22:05.37 | coreyfarrell | not sure that the mp3 addon module is a good enough reason to install subversion, just wanted to mention it. |
| 22:08.16 | *** join/#asterisk-dev kasanop (~kasanop@ivanpoddubny.com) |
| 23:23.58 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-zqbwfuorazqsnmey) |