| 01:17.03 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 01:17.03 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 01:35.30 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 01:41.00 | *** join/#asterisk-dev jkroon (~jkroon@vc-nat-gp-n-41-13-68-42.umts.vodacom.co.za) |
| 02:28.43 | *** join/#asterisk-dev jkroon (~jkroon@vc-nat-gp-n-41-13-68-42.umts.vodacom.co.za) |
| 06:03.24 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:14.02 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 06:16.36 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:16.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:56.41 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:56.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:20.50 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 07:38.28 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 07:38.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:53.11 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:05.18 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::141c) |
| 08:12.48 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 08:12.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:23.04 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:40.25 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:57.08 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 08:57.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:20.28 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 10:27.05 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 11:18.47 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 13:22.11 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 13:41.11 | *** join/#asterisk-dev oej (~oej@194.15.212.5) |
| 13:41.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:17.49 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-jjzkrgpmslzvxmzk) |
| 14:17.49 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:19.57 | gtjoseph | in case anyone noticed an issue with the downloads, we've got them fixed up again. |
| 14:31.17 | *** join/#asterisk-dev ulexus (~ulexus@2601:c6:4101:6b01:2e56:dcff:fe38:7208) |
| 14:32.07 | gtjoseph | @file: would a channel driver ever want to set a topology on a channel but NOT set nativeformats? |
| 14:32.38 | file | gtjoseph: no - for the purposes of compatibility for the moment |
| 14:32.59 | file | hum |
| 14:33.26 | file | if a channel is multistream capable we could also produce a nativeformats using the formats of all the default streams |
| 14:33.35 | gtjoseph | should i remove the check for MULTIPLE in ast_channel_nativeformats_set |
| 14:33.56 | gtjoseph | oh, thereverse of ast_channel_nativeformats_set |
| 14:34.00 | ulexus | @file asterisk-14.30.0.tar.gz now fixed, and now the pjproject-2.5.5.tar.bz2 fails its md5 validation. |
| 14:34.40 | gtjoseph | that file doesn't come from us |
| 14:35.05 | gtjoseph | if you're using bundled pjproject it's downloaded directly from their site. |
| 14:35.21 | ulexus | Yeah, I know; it's a ridiculous comedy of simultaneity |
| 14:36.40 | file | gtjoseph: I think... leave it for now, just set default streams when a topology is explicitly set on a channel |
| 14:37.13 | gtjoseph | ok, so new ast_channel_topology_set |
| 14:38.12 | file | yeah |
| 14:45.46 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-shcqnnvebulldmlr) |
| 15:04.42 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zhoaklvvznwysgly) |
| 15:04.42 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:09.48 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 15:09.48 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 15:24.56 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:24.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:34.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:34.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:35.58 | *** join/#asterisk-dev WIMPy (~wimpy@yeti.dk) |
| 15:35.58 | cresl1n | waves |
| 15:39.03 | cresl1n | Anybody else having trouble logging into gerrit today? |
| 15:44.08 | seanbright | cresl1n: i did earlier |
| 15:44.17 | seanbright | cleared up for me, but i haven't tested in the last few minutes |
| 15:44.27 | gtjoseph | working for me |
| 15:45.30 | cresl1n | darn |
| 15:45.39 | cresl1n | maybe I need to flush browser cache or something |
| 15:45.41 | gtjoseph | you in the office? |
| 15:45.44 | cresl1n | yeah |
| 15:45.52 | gtjoseph | what's not working? |
| 15:46.19 | gtjoseph | crowd maybe and not gerrit itself? |
| 15:47.28 | cresl1n | maybe |
| 15:48.46 | cresl1n | the SSO return page (from crowd) is failing to work |
| 15:48.50 | kharwell | I'm having a problem as well. Says page not found or I don't have permissions |
| 15:48.57 | cresl1n | yep, that's it |
| 15:49.08 | gtjoseph | can you log into crowd.asterisk.org directly? |
| 15:49.11 | file | well that's fun |
| 15:49.14 | gtjoseph | i can |
| 15:49.17 | cresl1n | gtjoseph: yep |
| 15:49.28 | cresl1n | Just if I try to login from gerrit |
| 15:49.32 | cresl1n | I get the failure |
| 15:49.34 | cresl1n | yay |
| 15:49.34 | file | oh |
| 15:49.39 | cresl1n | Did we change anything? |
| 15:49.47 | file | argh |
| 15:49.48 | file | hold |
| 15:49.59 | file | if it is what I think it is I'm going to be grumbly |
| 15:50.12 | cresl1n | turns file's grumble mode on |
| 15:50.45 | file | Crowd and Gerrit are out of sync in time |
| 15:50.57 | gtjoseph | which one's correct? |
| 15:51.22 | file | neither technically |
| 15:51.22 | file | :P |
| 15:51.47 | cresl1n | oh snap that would do it |
| 15:51.52 | gtjoseph | <PROTECTED> |
| 15:51.52 | gtjoseph | <PROTECTED> |
| 15:51.53 | gtjoseph | ============================================================================== |
| 15:51.53 | gtjoseph | <PROTECTED> |
| 15:51.56 | file | I don't have access to Crowd, but it was the problem before |
| 15:51.57 | gtjoseph | from gerrit :) |
| 15:52.13 | file | which is why I'm grumbly because this was supposed to have been fixed |
| 15:52.43 | gtjoseph | i'm trying to fix gerrit |
| 15:54.21 | file | gerrit wasn't impacted by yesterday's issue, it has remained untouched |
| 15:54.34 | file | Crowd was probably impacted and restarted |
| 15:55.46 | file | EUS filed for Crowd |
| 15:56.17 | gtjoseph | try now. gerrit was off by 157 seconds |
| 15:57.22 | file | ooh that may have done it |
| 15:57.49 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-kbfvczvflitxpihi) |
| 15:57.49 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:03.35 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.63.94) |
| 16:08.50 | seanbright | is there a way to search for issues in jira that have code patches attached? |
| 16:09.04 | file | hum |
| 16:09.23 | seanbright | the advanced query syntax might have something |
| 16:09.24 | seanbright | i'm checking |
| 16:09.27 | file | yeah |
| 16:09.33 | file | it'd have to be something creative |
| 16:10.38 | seanbright | so you can query for attachments, but not specifically for patches |
| 16:10.48 | seanbright | and apparently "[patch]" is not a valid search criteria |
| 16:10.50 | seanbright | silly jira |
| 16:12.58 | file | doesn't look like it is possible without an addon |
| 16:13.10 | seanbright | ah well |
| 16:14.29 | file | and every time I've tried to install an addon in JIRA it has gone poorly |
| 16:20.44 | gtjoseph | @file: how complex is ast_write_stream going to be. is it basically renaming ast_write to ast_write_stream, updating it for streams, then having ast_write call it? |
| 16:20.58 | gtjoseph | or is it a whole new implementation? |
| 16:21.37 | file | gtjoseph: it's not a whole new implementation |
| 16:22.08 | gtjoseph | cool |
| 16:22.10 | file | but ast_write does a lot, so figuring out where stuff should live could be messy - for example, should ast_write_stream handle control frames and other types? |
| 16:22.29 | file | or should ast_write handle that still and call ast_write_stream for the default streams instead? |
| 16:22.54 | gtjoseph | yeah it definitely needs more discussion |
| 16:39.16 | file | bugsssss |
| 16:45.41 | file | gtjoseph: I have bad news on your last change |
| 16:45.47 | file | I had to use the 'm' word in a finding |
| 16:46.06 | gtjoseph | ew |
| 16:47.38 | gtjoseph | crap. you talked about having an empty topology to start |
| 16:47.48 | gtjoseph | do we want to allow NULL then |
| 16:48.17 | gtjoseph | and what should happen to the default streams, all removed? |
| 16:48.35 | cresl1n | Anybody know why this code review hasn't merged yet? |
| 16:48.36 | cresl1n | https://gerrit.asterisk.org/#/c/4884/ |
| 16:48.48 | cresl1n | It's one that putnopvut +2'd already |
| 16:48.56 | gtjoseph | it has a dependecy on a parent |
| 16:49.01 | cresl1n | ah... |
| 16:49.02 | cresl1n | thank |
| 16:49.13 | cresl1n | s/thank/thank you/ |
| 16:49.31 | gtjoseph | it's 4754 |
| 16:49.39 | cresl1n | is there an easy way to tell that from gerrit? |
| 16:50.08 | gtjoseph | yep. if you see the button "submit including parents" it means there's a parent outstanding. |
| 16:50.23 | gtjoseph | if tou then hover over the parent(s) commit hash it'll tell you which one |
| 16:50.27 | cresl1n | cool |
| 16:50.29 | cresl1n | thanks a bunch |
| 16:51.24 | gtjoseph | in this case, 4754 is dependent on 4753 |
| 16:51.31 | gtjoseph | so you've got a chain goin |
| 16:55.08 | cresl1n | nice |
| 16:55.10 | cresl1n | merci |
| 16:55.27 | cresl1n | sorry if that was a silly question :-) |
| 16:55.42 | file | cresl1n: Taco Tuesday |
| 16:55.46 | cresl1n | YES |
| 16:56.05 | gtjoseph | no silly questions here |
| 16:59.43 | file | I think I'll wait for those findings and the other reviews to get sorted... before putting yet another up |
| 17:01.55 | gtjoseph | actually shoul dbe quick on mine |
| 17:03.37 | kharwell | gtjoseph: file: since a stream should not be destroyed outside a topology if in one then maybe check to see if the position is set or not set before destroying? |
| 17:04.34 | kharwell | (was thinking about it when looking at the unit test review since I didn't notice a test for that) |
| 17:05.22 | gtjoseph | well i guess the question is "should the default stream array always mirror the topology?" |
| 17:05.51 | gtjoseph | it's really just a convenience so you don't have to iterate over the topology every time |
| 17:07.08 | gtjoseph | i think anytime the topology is set (even if set to null) we do a set default streams and that should set the default to null if topology is null |
| 17:10.43 | file | agreed |
| 17:11.32 | gtjoseph | so if nativeformat_set is called with null should we reset the topology even for MULTISTREAM channels? |
| 17:12.34 | gtjoseph | and do we still want to have an empty topology always until destruction? |
| 17:12.45 | gtjoseph | at least an empty topology |
| 17:13.44 | gtjoseph | i.e. should there always be a topology on a channel even if it's empty? |
| 17:15.59 | gtjoseph | oh, here's another related question... Should a non-MULTISTREAM channel be able to call the stream APIs? |
| 17:16.16 | file | I think it is easier for consumers if an empty topology is always there |
| 17:16.21 | file | and which stream APIs? |
| 17:16.47 | gtjoseph | cool. ast_channel_set_stream_topology specifically |
| 17:16.51 | file | no |
| 17:16.59 | gtjoseph | anything that alters the lock to nativeformats |
| 17:17.02 | gtjoseph | ok, good |
| 17:17.37 | gtjoseph | one more... |
| 17:18.09 | gtjoseph | does the MULTISTREAM flag need to be on tech or can it be promoted to channel? |
| 17:18.38 | gtjoseph | i ask since we did just have a case where nativeformat was called with a null tech |
| 17:18.50 | gtjoseph | so we couldn't retrieve the flag |
| 17:18.53 | file | I don't think it _needs_ to be, but it was easiest |
| 17:19.09 | file | right, because it's a unit test which minimally created the channel at that point |
| 17:19.25 | gtjoseph | yeah, not sure if that was a real-life pattern |
| 17:19.34 | gtjoseph | or just an oddity of the test |
| 17:19.34 | file | let's see... |
| 17:21.04 | file | chan_sip and chan_pjsip set the tech almost immediately after allocation |
| 17:21.28 | file | same for iax2 and dahdi |
| 17:21.56 | file | I think the unit test is the odd one out |
| 17:22.06 | gtjoseph | ok. i'll fix the test |
| 17:22.21 | gtjoseph | actually is there a tech we can set in that test?? |
| 17:22.52 | file | yes? |
| 17:23.14 | file | if it's the voicemail one it is set at the end instead of the beginning |
| 17:23.26 | gtjoseph | ok. i'll fix it |
| 17:23.35 | file | the core should still tolerate it though |
| 17:23.42 | gtjoseph | but i'll add assert checks for it being null |
| 17:24.06 | gtjoseph | well, define tolerate :) |
| 17:24.15 | file | it shouldn't crash |
| 17:24.38 | gtjoseph | ok with assert or should we do a real check? |
| 17:24.41 | file | hum |
| 17:25.00 | file | I think if no tech is set yet then do the non-multistream capable logic |
| 17:25.21 | gtjoseph | it's the opposite i'm worried about |
| 17:25.38 | file | like what? |
| 17:25.40 | gtjoseph | if there's n o tech should we allow set topology? |
| 17:25.57 | gtjoseph | oh wait, that's what you just said :) |
| 17:26.19 | file | for nativeformats set if there's no tech or the property isn't set, do the topology from caps |
| 17:26.24 | gtjoseph | except it'd be reversed for natriveformats |
| 17:26.33 | gtjoseph | yeha ok |
| 17:26.44 | file | for the explicit stream topology set function if no tech is present or the flag isn't set, then scream |
| 17:27.11 | gtjoseph | yep |
| 17:44.00 | gtjoseph | so just to be clear... if you call ast_channel_set_stream_topology with a NULL topology it should set chan->topology to an empty one right ? |
| 17:44.45 | file | yes |
| 17:44.54 | gtjoseph | mean another public api for the destructor since the destructor is in channel and not channel_internal_api |
| 17:45.13 | file | hmm? |
| 17:46.20 | gtjoseph | the destructor already calls nativeformats_set with NULL which will cleanup the topology but it a;so replaces it with an empty one |
| 17:46.54 | gtjoseph | so the destructor needs a way to really destroy the topology |
| 17:47.11 | gtjoseph | it could call get_topology then destroy it i guess |
| 17:47.47 | gtjoseph | leaving default_streams and topology set on chan but since chan is going away immediately, who cares. |
| 17:48.18 | file | ast_channel_internal_cleanup ? |
| 17:48.33 | file | oh, that's called before |
| 17:48.33 | gtjoseph | is there one already? |
| 17:48.45 | file | which is fine |
| 17:49.30 | gtjoseph | no because nativeformats will create a dummy one again |
| 17:49.42 | gtjoseph | let me see if i can move it |
| 17:50.06 | file | well, or you could set topology to NULL in the cleanup and then you'd know the channel is in a see you later state |
| 17:50.08 | file | shrugs |
| 17:50.37 | file | small detail |
| 17:51.14 | gtjoseph | or check chan->finalized maybe. |
| 17:51.22 | gtjoseph | looks to see where that gets set |
| 17:54.08 | gtjoseph | eh, finalized gets set on alloc? |
| 17:54.44 | gtjoseph | i guess it's not quite as final as the name suggests |
| 17:55.06 | file | it indicates that the initialization of the channel is done |
| 17:55.41 | gtjoseph | so the initialize is final |
| 17:56.20 | gtjoseph | new item for the 15 wish list... fix names that don't mean what they do. |
| 18:00.56 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 18:12.00 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.63.169) |
| 18:14.30 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 18:14.30 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:28.48 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 18:28.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:28.50 | *** join/#asterisk-dev tzafrir_ (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 18:28.50 | *** mode/#asterisk-dev [+o tzafrir_] by ChanServ |
| 18:29.21 | gtjoseph | @file: next revision up without the masquerade stuff. you can review it while i'm at lunch and i'll do the masquerade afterwards |
| 18:29.29 | file | ack |
| 18:30.24 | gtjoseph | actually it doesn't compile so give me a minute :) |
| 18:41.43 | file | cresl1n: should that OpenSSL stuff have been done in 13 and 14? |
| 18:41.55 | cresl1n | Good question |
| 18:41.57 | cresl1n | what do you think? |
| 18:41.59 | file | (the previous 1.1.0 was) |
| 18:42.00 | cresl1n | I'd suppose it should |
| 18:42.29 | cresl1n | Too late for me to cherry pick it? |
| 18:42.42 | file | you can still try, but I vaguely recall trying and it not cherry picking cleanly |
| 18:42.50 | file | so you'd have to manually do it :P |
| 18:46.02 | gtjoseph | file: i'm going to have to fix things after lunch. currently you can't set even an empty topology from channel_alloc because of the MULTISTREAM check |
| 18:46.20 | file | k |
| 18:47.20 | gtjoseph | i'll have to create an ast_channel_internal_setup_topology |
| 18:47.28 | gtjoseph | but i'm very hungry |
| 19:45.24 | tzafrir_ | OK. I see a conflict in 13. Looking into it. |
| 19:59.55 | cresl1n | tzafrir: are you looking into cherry picking your OpenSSL patches into 13 and 14? |
| 20:00.08 | cresl1n | I forgot to ask about that on gerrit |
| 20:00.58 | gtjoseph | @file: review back up still without masquerade |
| 20:01.09 | file | let's see |
| 20:04.35 | file | let's see if these crash |
| 20:04.41 | file | ooh |
| 20:04.56 | gtjoseph | what? |
| 20:05.20 | file | nothing, just a new test I added failing |
| 20:05.36 | gtjoseph | oh. at least voicemail isn't causing a crash |
| 20:06.08 | file | I'm only running stream right now |
| 20:06.28 | file | it sets a topology on a channel and makes sure it gets that topology back when queried |
| 20:06.59 | gtjoseph | from a masquerade perspective i'm thinking that we should set the topology on the cloneclannel just after the set of the raw formats |
| 20:07.14 | gtjoseph | that failed?? |
| 20:07.18 | file | yes. |
| 20:07.40 | gtjoseph | what did you pass in? |
| 20:07.49 | file | a topology I had just created |
| 20:07.56 | file | on a mock channel with the MULTISTREAM property set |
| 20:08.12 | file | no assertion either, so it knew the property was set |
| 20:08.17 | file | a bit odd |
| 20:08.21 | gtjoseph | you called set_stream_topology, then get_stream_topology? |
| 20:08.32 | file | yes |
| 20:08.50 | file | a |
| 20:08.51 | file | h |
| 20:08.55 | gtjoseph | check what the set returned (it returns something now) |
| 20:09.01 | file | if (!new_topology) { |
| 20:09.01 | file | ast_channel_internal_set_stream_topology(chan, new_topology); |
| 20:09.01 | file | } |
| 20:09.20 | gtjoseph | pgffft |
| 20:09.28 | file | go go unit tests |
| 20:09.57 | gtjoseph | fixed. pull it again |
| 20:11.04 | gtjoseph | it just dawned on me that there's no separate topology for read and write |
| 20:11.11 | gtjoseph | by design? |
| 20:11.46 | file | yes, there aren't separate topologies for direction |
| 20:11.49 | gtjoseph | and scroll up to see my question on masquerade |
| 20:12.15 | file | you can have a state for unidirectional on a stream, that's about it |
| 20:12.17 | file | and yes, one sec |
| 20:12.29 | file | 0 failed |
| 20:12.37 | gtjoseph | nice |
| 20:12.38 | file | up for review, I'll rebase after masquerade |
| 20:12.50 | gtjoseph | kk |
| 20:13.29 | file | yes, seems like a sane place |
| 20:13.48 | gtjoseph | can the original and clone be different techs? |
| 20:14.07 | file | yes, but that doesn't matter |
| 20:14.10 | tzafrir | cresl1n, yes, working on it. |
| 20:14.55 | cresl1n | thanks so much tzafrir :-) |
| 20:15.21 | file | gtjoseph: don't go looking or trying to understand - just swap the two sides... >_> |
| 20:15.28 | gtjoseph | well, can't just unconditionally clone the topology |
| 20:15.46 | file | no, don't clone |
| 20:15.50 | file | swap the pointers for it all |
| 20:15.54 | gtjoseph | ok, swap |
| 20:16.23 | gtjoseph | so regardless of either channel's MULTI statis? |
| 20:16.28 | file | yes |
| 20:16.28 | gtjoseph | status |
| 20:16.38 | file | it's literally swapping the guts of two ast_channel instances |
| 20:16.54 | cresl1n | hums the masquerade song |
| 20:17.18 | gtjoseph | hmmm. how's that going to interact with nativeformats_set me wonders. |
| 20:17.20 | file | so the tech will also swap, along with many other things |
| 20:17.46 | file | an excellent question! I have faith you'll find out :D |
| 20:17.51 | file | cresl1n: yessssssss |
| 20:18.10 | gtjoseph | i'm hoping that nativeformats_set takes care of everthing :) |
| 20:18.56 | file | it can't for the multistream case since you'd need to move the topology for that case |
| 20:19.00 | file | for the non-multistream case it should be fine |
| 20:19.08 | gtjoseph | yeah |
| 20:19.35 | gtjoseph | which is why i need to know if the channels are MULTI or not |
| 20:31.05 | gtjoseph | so i see where we're copying the nativeformats from the clone channel, then we call set_write_format and set_read_format also on original (which calls nativeformat_set again) |
| 20:31.23 | gtjoseph | bu tnot seeing where we set them on the cloned channel |
| 20:32.42 | gtjoseph | and i see where we swap rawread and rawwrite |
| 20:34.37 | gtjoseph | actually when we call set_read_format and set_write_format on the original channel, we're setting them back to where they were originally. |
| 20:43.55 | gtjoseph | @file: so do you wane me to swap the topologies BEFORE all the other format shenanigans are done, or AFTER? |
| 20:44.06 | file | I don't really care :P |
| 20:44.23 | file | as long as the topologies are where they should be when the channels are unlocked, yolo |
| 20:45.09 | gtjoseph | well, i'm going to do after then |
| 20:45.23 | file | oh and that it doesn't crash |
| 20:55.20 | gtjoseph | I probably shouldn't ask should I? |
| 20:55.20 | gtjoseph | /* |
| 20:55.21 | gtjoseph | <PROTECTED> |
| 20:55.21 | gtjoseph | <PROTECTED> |
| 20:55.21 | gtjoseph | <PROTECTED> |
| 20:57.50 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 20:59.21 | file | you can ask, doesn't mean anyone will answer |
| 20:59.28 | file | limited exposure is the best approach |
| 21:00.44 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 21:00.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:01.21 | gtjoseph | testing now |
| 21:03.24 | gtjoseph | i don't suppose we have any unit tests that do masquerade? |
| 21:04.09 | file | unknown |
| 21:04.38 | gtjoseph | Did you know? You can't run the app_voicemail tests twice without crashing asterisk? |
| 21:04.48 | gtjoseph | Fun Fact |
| 21:08.53 | rmudgett | gtjoseph: Did you know the testsuite tests/masquerade test no longer tests masquerades? It now only tests local channel optimizations. |
| 21:09.05 | gtjoseph | figures |
| 21:09.10 | gtjoseph | i'm trying local channels |
| 21:09.25 | gtjoseph | anything that does? |
| 21:09.50 | rmudgett | Not since the bridge rearchitecting. Thats why that test no longer tests masquerades. |
| 21:10.02 | gtjoseph | nice |
| 21:10.18 | gtjoseph | oh well. as file says... yolo |
| 21:10.19 | rmudgett | Call pickups do a masquerade |
| 21:10.24 | file | masquerade usage was reduced... a nice amount |
| 21:10.25 | gtjoseph | and the review is up with masquerade |
| 21:21.31 | file | seanbright: I was gonna do that! |
| 21:22.11 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 21:22.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:32.38 | tzafrir | cresl1n, reviews added. |
| 21:46.45 | seanbright | file: i love rebasing |
| 21:46.56 | file | do you rebase for no reason sometimes? |
| 21:47.00 | seanbright | i do |
| 21:47.13 | file | what a waste of electrons! |
| 21:49.21 | seanbright | didn't notice that the 14 one was busted too |
| 21:49.24 | seanbright | just fixed |
| 22:09.51 | rmudgett | gtjoseph: In subscription_tree_destructor() should you also cancel the scheduled task? Otherwise the NULL check is unnecessary with ao2_cleanup(). |
| 22:10.05 | gtjoseph | can look in a sec |
| 22:13.56 | gtjoseph | no ok. i think i thought that if the task had been cancelled without NULLing sub_tree->expiration_task |
| 22:14.05 | gtjoseph | but now i'm thinking |
| 22:15.39 | gtjoseph | i wonder if i meanto to cancel it |
| 22:17.26 | rmudgett | And here I was about to +1 it. :) |
| 22:18.41 | gtjoseph | well i do cancel the timer in pubsub_oon_evsub_state |
| 22:19.00 | gtjoseph | and i do unref andf set it to null |
| 22:19.17 | gtjoseph | maybe the "if" was a leftover from when I had the cancel there. |
| 22:19.47 | gtjoseph | let me make sure there's no other path to destruction |
| 22:22.21 | gtjoseph | i don't think there's a way to get to the with the timer still running BUT how about I put a cencel in that if? |
| 22:22.25 | gtjoseph | just in case? |
| 22:22.42 | gtjoseph | get to the destructor that is |
| 22:24.00 | gtjoseph | @rmudgett: you OK with that? |
| 22:24.03 | rmudgett | sure |
| 22:25.16 | gtjoseph | done. hopefully for the last time |
| 22:26.48 | gtjoseph | @file: had a chance to look at the stream/channel review or are you really done for the day? |
| 22:27.00 | gtjoseph | cuz I am |
| 22:27.12 | file | I'm done for the day |
| 22:27.23 | file | will pick stuff back up in the morning |
| 22:27.51 | gtjoseph | sounds good |
| 22:31.10 | rmudgett | Was looking at the ast_sip_schedule_task() API. When you create the expiration task you bump the ind->sub_tree ref as the scheduled task data. |
| 22:31.55 | rmudgett | The call can be told that the task_data is an ao2 object. Also if the task fails to get scheduled the bump is not released. |
| 22:42.27 | *** join/#asterisk-dev seanbrig1t (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 22:42.27 | *** mode/#asterisk-dev [+o seanbrig1t] by ChanServ |
| 22:47.17 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 22:47.17 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 22:50.38 | rmudgett | Crap. The expiration_task is leaking sub_tree's. |
| 22:51.04 | rmudgett | If fails to get initially scheduled and if canceled |
| 22:53.44 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-ihqbqioaodfgoxrx) |
| 23:04.56 | *** join/#asterisk-dev file (uid178970@asterisk/developer-and-muffin-lover/file) |
| 23:04.56 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 23:55.58 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-zhoaklvvznwysgly) |