IRC log for #asterisk-dev on 20170323

03:02.00*** join/#asterisk-dev infobot (ibot@rikers.org)
03:02.00*** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev
03:38.47*** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-70-164-41-93.dc.dc.cox.net)
03:39.44*** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za)
07:08.25*** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107)
07:33.31*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
07:33.31*** mode/#asterisk-dev [+o oej] by ChanServ
07:41.12*** join/#asterisk-dev jkroon (~jkroon@154.73.35.201)
07:58.19*** join/#asterisk-dev CELYA_ (~Thunderbi@80.13.86.73)
08:05.02*** join/#asterisk-dev tsearle (~tsearle@37.19.10.33)
08:10.27*** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com)
08:10.28*** mode/#asterisk-dev [+o tzafrir] by ChanServ
08:10.42*** join/#asterisk-dev tsearle (~tsearle@37.19.10.33)
08:18.21*** join/#asterisk-dev ggo (~quassel@37.19.10.33)
08:18.39*** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::3f)
08:25.14*** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net)
09:56.03*** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107)
09:58.03*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
09:58.03*** mode/#asterisk-dev [+o oej] by ChanServ
11:51.34*** join/#asterisk-dev Dovid (~dovid@69.115.165.37)
12:05.23*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
12:05.23*** mode/#asterisk-dev [+o oej] by ChanServ
12:42.25*** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net)
13:06.25*** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
13:06.25*** mode/#asterisk-dev [+o cresl1n] by ChanServ
13:10.06*** join/#asterisk-dev joshelson (~joshelson@73.34.214.163)
13:11.20cresl1nwaves
13:11.26filehola
13:19.40seanbrightwith RAII_VAR
13:20.07seanbrightif that is called in a thread function, and that thread is canceled with pthread_cancel(), does the destructor get called?
13:24.38fileI... would... hope... so...
13:25.11seanbrighti guess i could test it
13:25.18seanbrightas much as i hate testing
13:25.27tsearlereal men test in prod
13:30.08seanbrightfile: negative
13:30.16filefun!
13:30.21seanbrightwell hold on
13:30.39fileto that feelin'
13:30.49seanbrightyeah, doesn't run
13:30.53seanbrightgood times
13:31.32tsearleout of curiosity, how did you manage to get C to auto destroy on descope?
13:31.58seanbrighttsearle: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
13:32.01seanbrightsearch for 'cleanup'
13:32.29tsearleinteresting
13:32.38tsearleso I assume this is a gcc proprietary extension to c?
13:32.48seanbrightclang supports it too
13:32.54seanbrightbut it's an extension, yes
13:35.35*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
13:35.35*** mode/#asterisk-dev [+o oej] by ChanServ
13:36.33*** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-rstadrywrnhytqgj)
13:36.33*** mode/#asterisk-dev [+o newtonr] by ChanServ
13:37.58tsearlebut on a related note, isn't pthread_cancel() really bad to use? it's a hard kill
13:38.15tsearlethought you should request the thread to end it's loop then do pthread_join()
13:38.46*** join/#asterisk-dev samoied (~samoied@186.222.23.155)
13:44.03cresl1nIIRC, that's what we do in chan_dahdi
13:44.24cresl1nor something roughly equivalent
13:47.24seanbrightnothing is wrong with pthread_cancel
13:47.29seanbrightyou just have to code for it
13:47.45seanbrightpthread_kill is a hard kill
13:50.01seanbrightif i have a thread with a sleep(90) in it, pthread_cancel is the only option
13:50.16seanbrightunless you want to have your user wait around for 90 seconds
14:15.40*** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ebdnzceimopkpsyt)
14:15.40*** mode/#asterisk-dev [+o kharwell] by ChanServ
14:15.48*** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson)
14:15.48*** mode/#asterisk-dev [+o putnopvut] by ChanServ
14:53.13*** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-mbpcvmjzbmpldlru)
14:53.13*** mode/#asterisk-dev [+o rmudgett] by ChanServ
15:40.50ggoIn asterisk 13, for a sip call that gets closed because of rtp_timeout, the cause is  AST_CAUSE_NORMAL_CLEARING
15:41.31ggoDoes this sound correct? Is it normal clearing?
15:42.09ggoI don't see a specific cause for rtp timeout in causes.h
15:43.50seanbright"sip call" = chan_sip or chan_pjsip?
15:45.35ggochan_pjsip
15:46.22seanbrightlet me take a look, hold please
15:48.39seanbrightchan_pjsip doesn't do anything special to the channel when it hangs it up because of an RTP timeout
15:49.44seanbrightchan_sip sets it to 44 (or 'Requested channel not available')
15:49.56seanbrightlet me see how hard it would be to add to pjsip
15:50.57dan_jAnyone know if this is a known issue? Was running fine for 2 weeks before the crash.
15:51.00dan_jhttps://www.irccloud.com/pastebin/w2vznsr5/
15:51.55seanbrightdan_j: https://issues.asterisk.org/jira/browse/ASTERISK-26835
15:52.00seanbrightbeing worked on
15:52.59dan_jgood news.
15:53.23ggoThanks sean. I'm doing the same myself
15:53.32seanbrightggo: want to try a patch?
15:54.20ggoI will try to produce a patch
15:54.27seanbrighti have one i would like you to test
15:54.31ggoA
15:54.32ggoOk
15:54.43ggoI can try it now
15:54.51*** join/#asterisk-dev samoied (~samoied@186.222.23.155)
15:56.06seanbrightggo: https://gist.github.com/seanbright/4881a03727948833f7fa40e6614f1d36
15:56.21seanbrighti haven't tested, so no guarantees
15:58.52rmudgettseanbright: Are you trying for contributor of the month?
15:59.00rmudgett:)
15:59.27seanbrightrmudgett: just trying to keep you guys busy
15:59.33seanbrightand i like seeing my face on gerrit
15:59.36seanbrightit's soothing
16:03.07kharwellgtjoseph: regarding https://issues.asterisk.org/jira/browse/ASTERISK-26814 - increasing the timeout is easy enough. However if the configure fails due to downloading and one tries to run make separately for pjproject DOWNLOAD_TIMEOUT is not exported thus not used in that case
16:03.30gtjosephhmmmm
16:03.32kharwellDo we care if someone is running it manually that the timeout is there?
16:03.49gtjosephprobably not but you can set a default in the Makefile
16:04.12kharwelldefault timeout?
16:04.15gtjosephso if it's not defined previously it gets 10 seconds or something
16:04.18ggosean I will get back at you tomorrow. Atm my enviromnent seems to be broken and I have to leave
16:04.35seanbrightk
16:04.40gtjosephDEFAULT_TIMEOUT?=10 or something
16:04.47ggoThanks!
16:04.52gtjosephsorry DOWNLOAD_TIMEOUT
16:05.08kharwellgtjoseph: I'm assuming it'll have to check which download  mechanism it is using as well
16:05.24kharwellwget vs curl vs fetch that is
16:05.25gtjosephoh yeah, nevermind
16:05.38gtjosephforget about it
16:06.01kharwellya I figured that was the point of putting it in the Asterisk configure script so it could check to see which of those program were installed
16:06.06gtjosephi think there's actually a check to say that you must run .astroot/configure at least once
16:06.22gtjosephbefore running make in pjproject anyway
16:06.51gtjosephoh yeah...  did i put a note on the internal issue about removing the progress bard for wget?
16:07.02gtjosephmjordan removed it for curl
16:07.07kharwelldon't think so
16:07.42gtjosephrats i thought i did.  if you're going to touch configure.ac, remove the progress bar for wget's DOWNLOAD_TO_STDOUT
16:07.43kharwellIt appears it has been removed for wget and not curl though. So remove from curl?
16:07.54gtjosephyou sure it's not th eother way around?
16:08.23gtjosepheither way, let's make them totally silent
16:08.53kharwellI only see a progress option specified for the curl option: DOWNLOAD="${CURL} -O --progress-bar -w \"%{url_effective}\n\""
16:09.16kharwellactually though I don't think DOWNLOAD gets called/used that I can tell. just DOWNLOAD_TO_STDOUT
16:09.18kharwellhrm
16:09.37gtjosephyeah.  i left DOWNLOAD there just in case
16:09.42kharwellwhich I think seemed to still work when manually running make
16:10.06gtjosephyep
16:10.12kharwellmeaning DOWNLOAD_TO_STDOUT appeared to be retrieved
16:10.21gtjosephyep
16:10.22kharwellI wonder why DOWNLOAD_TIMEOUT wasn't
16:11.08kharwellI'll fiddle with it some more. Maybe it's something else I am doing
16:11.48gtjosephdid youput it in makeopts.in?
16:12.29kharwellprob not cause I haven't touched that. But put what in?
16:12.59gtjosephDOWNLOAD_TIMEOUT=@DOWNLOAD_TIMEOUT@
16:13.27kharwellaah wonder if that is it. There is a DOWNLOAD_MAX_TIMEOUT defined but no DOWNLOAD_TIMEOUT
16:13.28gtjosephwcgrep DOWNLOAD_TO_STDOUT and follow its pattern
16:13.41gtjosephah
16:13.57gtjosephmaybe i messed that up earlier
16:15.47kharwellcan I modify that directly or is that set somewhere else and that file generated?
16:15.58gtjosephmakeopts.in is the template
16:16.26gtjosephit'll generate makeopts on ./configure
16:19.30kharwellthat appears to have fixed the export problem
16:19.44gtjosephcool
16:27.24*** join/#asterisk-dev joshelson (~joshelson@50-206-225-8-static.hfc.comcastbusiness.net)
17:22.27*** join/#asterisk-dev samoied (~samoied@186.222.23.155)
18:39.16*** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za)
18:41.45*** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-bdatkiljphoziqjd)
19:15.59seanbrightkharwell: i'm letting the mispelling of 'response' slide (don't worry, i won't tell anyone else)
19:17.29fileseanbright: how dare you
19:17.29kharwellI see what you did there :-)
19:19.16*** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
19:19.16*** mode/#asterisk-dev [+o cresl1n] by ChanServ
19:25.59kharwellpreempts rmudgett's -1
19:51.22cresl1nkharwell: I just finished going through your dynamic payload reviews
19:51.41cresl1nI had four comments, all of which were resolved after getting further through the code involved
19:51.45cresl1ngood job :-)
19:52.15filekharwell: any problems caused by it is your fault
19:52.16kharwellexcellent. I blame file for any outstanding issues, but I'll take the positive feedback
19:52.24filenope! I already forwarded any fault
19:52.26kharwelldang beat me too it
19:52.35cresl1nhe can't do it, he left for the day
19:52.37cresl1n:-)
19:52.47kharwellooh excellent and true
19:52.55fileforwards to cresl1n then
19:53.09cresl1nso, question about the testsuite
19:53.19cresl1nspecifically about the tests involved
19:54.32cresl1nI suppose we don't have to make a test that changes the rtp_use_dynamic option and tests it in both positions because we're counting on the testsuite running on master and 14 which should catch both behaviors, right?
19:56.01kharwellami version bump review up and verified. If someone would take a quick look and submit it would be much appreciated as I can then get started on the release candidates
19:56.47kharwellcresl1n: yeah as far as I know the testsuite should run against both branches
19:56.52cresl1ncool
19:57.06cresl1nI suppose that'll do
20:03.53*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
20:03.53*** mode/#asterisk-dev [+o oej] by ChanServ
20:07.21*** join/#asterisk-dev ipengineer (~zconkle@71.252.134.63)
20:11.58cresl1nthanks for the explanation on the testsuite test kharwell
20:12.02cresl1nI changed it to a +1
20:12.16kharwellnp thanks for looking
21:49.38*** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net)
21:49.38*** mode/#asterisk-dev [+o tzafrir] by ChanServ
22:00.24cresl1ngtg, dad time
22:00.28cresl1nsee you all later
22:02.38*** join/#asterisk-dev pchero (~pchero@109.70.54.56)
22:30.19*** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net)
22:42.18*** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102)
22:42.18*** mode/#asterisk-dev [+o snuff-work] by ChanServ
23:39.49*** join/#asterisk-dev Dovid (~dovid@ool-4573a525.dyn.optonline.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.