| 00:17.04 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-vjdiyjmnxmaanljj) |
| 01:19.08 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:19.08 | *** 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 |
| 02:18.13 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.58.35.152) |
| 03:54.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.174) |
| 05:19.43 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:b049:5aa8:b5a2:e158) |
| 05:19.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:22.02 | *** join/#asterisk-dev malby (~malby@malloy.xyz) |
| 05:23.32 | *** part/#asterisk-dev malby (~malby@malloy.xyz) |
| 05:36.14 | *** join/#asterisk-dev Oooohboy (~Oooohboy@72-48-251-4.dyn.grandenetworks.net) |
| 06:09.08 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-190-32-9.ph.ph.cox.net) |
| 06:24.06 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:44.58 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:44.58 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 08:14.03 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:14.03 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:20.42 | jkroon | if output by AMI to sockets end up blocking - I'm assuming that could cause problems inside of asterisk itself? |
| 09:51.55 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:01.48 | AsteriskRoss | @file Re: ASTERISK-27706 - Would you mind taking a look at an the full core dump for this to confirm where the lock is? I beleive it may be related to chan_pjsip |
| 10:21.34 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:32.04 | *** join/#asterisk-dev Samot (sid133316@gateway/web/irccloud.com/x-fzaximvfjwfwvahq) |
| 13:34.53 | *** part/#asterisk-dev Samot (sid133316@gateway/web/irccloud.com/x-fzaximvfjwfwvahq) |
| 13:47.13 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-stovjeolhrtpqgat) |
| 13:47.13 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:00.58 | *** join/#asterisk-dev edolix (~edolix@host178-66-dynamic.244-95-r.retail.telecomitalia.it) |
| 14:02.32 | *** join/#asterisk-dev xkraty (~xkraty@host208-57-dynamic.20-79-r.retail.telecomitalia.it) |
| 14:02.50 | *** part/#asterisk-dev xkraty (~xkraty@host208-57-dynamic.20-79-r.retail.telecomitalia.it) |
| 14:20.30 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 14:49.16 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:49.16 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:02.45 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ddssdzolipbktnwt) |
| 15:02.45 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:04.18 | *** join/#asterisk-dev sibiria (~sibiria@unaffiliated/sibiria) |
| 15:04.54 | sibiria | is it alright to bring up a potential bug or quirky behavior here, or do you prefer a file a report elsewhere? |
| 15:05.30 | file | if you want to discuss it you can bring it up here, but in the end all bugs need to have a JIRA issue created too |
| 15:06.50 | sibiria | i've been looking for a way to save the call-id of a transferred call. we currently transfer by calling an AGI app (due to some advanced database requirements) which simply calls Dial and then pulls some channel variables after Dial returns |
| 15:07.29 | sibiria | i tried using a pre-dial handler for this, and Return'ing the new call-id, but GOSUB_RETVAL doesn't follow back to the calling context |
| 15:07.43 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:07.43 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:08.09 | sibiria | the console clearly shows GOSUB_RETVAL is being set |
| 15:08.15 | sibiria | this is on 18.13.2 |
| 15:08.17 | sibiria | outgoing calls |
| 15:09.32 | sibiria | Return and GOSUB_RETVAL "sticks" as it should during a normal GoSub, but not in an implied GoSub part of a pre-dial handler |
| 15:24.00 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:24.00 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:31.42 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fcghkxprikxeoara) |
| 15:31.42 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:34.10 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-jvwcukhnnojvsdkx) |
| 15:34.10 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:45.38 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:17.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.41.161) |
| 16:45.45 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.41.161) |
| 16:56.22 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:56.22 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:56.53 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:56.53 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:57.44 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:57.44 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:58.28 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:58.28 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:59.24 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:59.24 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 17:20.12 | AsteriskRoss | I've started getting a lot of deadlocks in PJSIP after applying the patch for 'res_pjsip_refer.c: Fix attended transfer race condition crash.' I've removed the commit and testing. But in theory would that commit cause deadlocks? |
| 17:35.10 | rmudgett | That patch cleans up a deferred termination request on the correct thread. |
| 18:44.21 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:44.21 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:51.59 | *** join/#asterisk-dev Worldexe_ (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 20:01.01 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hvtbwycegtuvlnjl) |
| 20:01.01 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:40.16 | coreyfarrell | I just noticed Asterisk 13 is supported until 2020? does this mean that 2018 won't have a new LTS? |
| 20:40.35 | cresl1n | Hush you. |
| 20:40.49 | cresl1n | Also, I think the goal is to make 16 an LTS |
| 20:40.59 | cresl1n | so AFAIK 2018 will have an LTS |
| 20:41.05 | cresl1n | assuming we make a major release this year |
| 20:41.20 | cresl1n | (which we always have, so there's low likelihood of it not happening) |
| 20:41.39 | coreyfarrell | except 2015 :/ |
| 20:41.43 | cresl1n | yep |
| 20:41.47 | cresl1n | good point |
| 20:42.44 | coreyfarrell | so are LTS going to be 6 years now? |
| 20:44.14 | coreyfarrell | I'm hoping you say no.. can only backport so much and even with the normal 4 years the old LTS starts to diverge in the final year. |
| 20:44.37 | file | god no |
| 20:44.39 | cresl1n | No |
| 20:44.55 | file | can only keep so much in active memory |
| 20:44.57 | cresl1n | There were some choices that accumulated to make the gap so large |
| 20:46.21 | coreyfarrell | that's a relief! |
| 20:49.22 | coreyfarrell | speaking of Asterisk 16, can we make jansson-2.11 required/minimum version? even if it involves offering `./configure --with-jansson-bundled` the new version has some important bug fixes and some really great new features (especially in json_pack). |
| 20:50.37 | coreyfarrell | I don't think we should necessarily use the new json_pack features now, but it would be nice once Asterisk 13 is done/gone if we could start using those features in 16+, but to do that we'd have to decide to require 2.11 before asterisk-16.0.0. |
| 20:54.48 | file | we're in training so few Digifolk are here |
| 21:07.01 | cresl1n | coreyfarrell: My first question would be to wonder how widely deployed that version of jansson is before making a decision |
| 21:21.51 | coreyfarrell | cresl1n: it's not, it was released a month ago. fedora hasn't even updated yet, I don't know about debian or other systems. it wouldn't surprise me if redhat dragged their feet and jansson is included in EL7. |
| 21:30.16 | cresl1n | ugh |
| 21:32.59 | coreyfarrell | jsmith: I just noticed you recently updated the fedora jansson.spec to include 'BuildRequires: gcc'. if I got a patch to you for 2.11 could you help get that merged? sorry I don't really know the fedora process. |
| 21:50.26 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 21:50.26 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:55.05 | rmudgett | coreyfarrell: I don't think there'll be any more things for the DEBUG_ATLEAST patches. |
| 21:56.17 | coreyfarrell | rmudgett: so you think leave the chan_dahdi changes as is (ast_verbose only if debug is on)? |
| 21:56.57 | rmudgett | When I have a patch that doesn't cherry-pick between branches I have a local branch for each patch. When I make changes, I commit a fix patch and then cherry-pick the fix patch to the other branches before merging/squashing them. |
| 21:59.01 | rmudgett | Those chan_dahdi ones are strange but functional. |
| 21:59.33 | rmudgett | The one in man/config.c is just wrong. |
| 21:59.52 | rmudgett | *main/config.c |
| 22:04.56 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:7197:9033:7c6d:de7b) |
| 22:04.56 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:26.47 | coreyfarrell | kharwell: can't you just fast-forward the testsuite branches instead of cherry-picking? |
| 23:27.23 | coreyfarrell | I guess it doesn't matter too much just figured I'd ask |
| 23:28.29 | kharwell | hrm probably I think. didn't think about it |
| 23:34.03 | kharwell | coreyfarrell: was wondering about the gerrit repercussions of doing that. spoke with gtjoseph and it's prob safest to cherry pick the changes so just going to leave as is |
| 23:35.59 | coreyfarrell | sounds good |