| 01:14.25 | *** join/#asterisk-dev mjordan (~mjordan@user-24-236-95-234.knology.net) |
| 01:14.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:36.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:36.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:36.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 04:36.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:12.41 | *** join/#asterisk-dev oej (~olle@212.36.67.3) |
| 07:12.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:15.39 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:15.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:18.59 | *** join/#asterisk-dev anny__ (~chatzilla@77.42.241.114) |
| 09:19.04 | anny__ | hi all |
| 09:19.41 | anny__ | can anyone tell me what are zombie channels, and why they appear? |
| 11:10.23 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:10.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:42.27 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:42.27 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 13:05.57 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uneqiiafzdesucjk) |
| 13:05.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:07.53 | mjordan | opticron: with your offer/answer patch for trunk, how do you want to handle the SDP_offer_answer test in the testsuite? |
| 13:11.25 | opticron | I'll need to tweak some of the scenarios |
| 13:11.35 | opticron | oh...right |
| 13:12.11 | opticron | I should be able to tweak them to pass on both trunk and on older versions without the new support |
| 13:13.20 | leifmadsen | mjordan: ping |
| 13:13.25 | opticron | it'll just require a little bit of creativity in the sipp scenarios |
| 13:14.26 | leifmadsen | mjordan: I saw you changed a couple of modules around to be 'core' support -- just a friendly reminder to also update the filters in jira for that so you see the issues reported against them |
| 13:14.39 | kpfleming | if there are any :-) |
| 13:14.43 | leifmadsen | right :) |
| 13:14.49 | leifmadsen | I meant going forward in the future :D |
| 13:14.57 | leifmadsen | oh wait |
| 13:15.03 | leifmadsen | that should probably be directed at rnewton |
| 13:15.10 | kpfleming | except he's on vacation |
| 13:15.14 | leifmadsen | WHAT?! |
| 13:15.24 | leifmadsen | he gets promoted and takes vacation |
| 13:15.46 | russellb | leifmadsen: mad skills |
| 13:16.01 | mjordan | leifmadsen: will do, forgot about your component filters |
| 13:16.43 | mjordan | opticron: if it gets too hideous, we may want to consider alternatives - I'd hate for there to be a lot of goofiness in the actual test itself |
| 13:16.59 | leifmadsen | mjordan: no problem -- feel free to send rnewton over my way for a run down of how I used to use the filters if he wishes |
| 13:17.28 | leifmadsen | mjordan: might not even be a bad idea to add a small wiki document stating the things that need to be updated if a modules status changes |
| 13:18.14 | mjordan | yeah, it isn't something we've had to do before. |
| 13:18.31 | opticron | mjordan, it should be fairly straightforward, but I'll let you know if it becomes an issue |
| 13:18.55 | leifmadsen | mjordan: which is why I was suggesting a wiki document to outline the things you did since it's fresh in your head :) |
| 13:23.38 | kpfleming | would you like to extend SharePoint across your Information Architecture? |
| 13:25.19 | leifmadsen | omg no |
| 13:25.31 | leifmadsen | Roberts Signs & Awnings has SharePoint |
| 13:25.39 | leifmadsen | it's awful |
| 13:30.15 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-whmlxjkrhzblhjfa) |
| 13:36.13 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 13:42.51 | mjordan | Aw, I created issue 20000 and turned it into an SWP :-( |
| 13:56.14 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:56.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:00.01 | kpfleming | mjordan: it will live forever in infamy |
| 14:16.14 | mjordan | can anyone think of any reason why we should support playing back audio files to a channel in the 'h' extension |
| 14:19.43 | file | ugh |
| 14:19.54 | leifmadsen | o.O |
| 14:19.56 | mjordan | yeah |
| 14:20.19 | leifmadsen | I don't get why you would want that... ? |
| 14:20.20 | mjordan | apparently, "it worked" in previous versions (1.4, 1.6.2), but I'd chalk that up to undefined behavior |
| 14:20.27 | leifmadsen | agreed |
| 14:20.33 | file | mjordan, right |
| 14:20.59 | mjordan | before I slammed the door shut on it, wanted to make sure no one said "but that's the best behavior ever!!!" :-) |
| 14:23.30 | leifmadsen | "late media" |
| 14:24.14 | opticron | but that's the best behavior ever!!! |
| 14:24.20 | mjordan | EVAR. |
| 14:24.24 | opticron | I NEEDS IT |
| 14:45.52 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:45.52 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:06.52 | mjordan | putnopvut: no idea why, but features.c fails to find the adsi symbols during linking with your Makefile patch - gcc version 4.6.3 |
| 15:08.19 | putnopvut | mjordan: weird. Didn't happen on my test VM. What distro is this on? I can set up a VM and see what's up. |
| 15:08.48 | putnopvut | Wait, last gcc I tried was actually 4.5, not 4.6. Let me see if that happens with 4.6 on my test VM |
| 15:09.25 | opticron | is thinking about removing the reading of the sendonly/sendrecv/recvonly/inactive parameter from video streams in chan_sip since we don't actually use it and have no real way to handle it without major rework |
| 15:09.47 | mjordan | putnopvut: Fedora 15. otherwiseguy ran into the same problem - my Fedora 14 box doesn't have the problem with gcc 4.5 |
| 15:10.10 | putnopvut | Okay. I'm currently trying 4.6 on the Ubuntu 12.04 test VM to see what happens there. |
| 15:10.28 | mjordan | putnopvut: heh, someone just ran into it on the asterisk-dev list |
| 15:10.35 | putnopvut | effing poop |
| 15:10.40 | mjordan | indeed |
| 15:11.29 | mjordan | and this is why we need more test agents :-) |
| 15:14.28 | putnopvut | Yeah, on my test VM 4.6 has the linking errors. |
| 15:16.45 | Qwell | wtf |
| 15:18.35 | leifmadsen | just spin them up on EC2 |
| 15:18.35 | putnopvut | So the original Makefile code was embedding res_adsi if weak symbol support did not exist. I guess weak symbol resolution is not present and not embedding res_adsi results in the linking errors...but only for 4.6 |
| 15:18.42 | leifmadsen | is half joking :D |
| 15:19.01 | leifmadsen | putnopvut: sorry for finding that issue :( |
| 15:19.26 | elguero | putnopvut: seems to happen on Centos 5.8 too, gcc 4.1.2 |
| 15:19.42 | Qwell | russellb: Fix your compilers, kthx. |
| 15:20.05 | putnopvut | elguero: Yeah, I think that original Makefile block was targeted for 4.1 |
| 15:20.50 | putnopvut | My temporary solution is to revert the change, because having an extra module loaded is not nearly as bad as the code not linking properly. |
| 15:23.51 | Qwell | putnopvut: Do you have a makeopts file sitting around from the 4.6 build? |
| 15:23.57 | putnopvut | let's see |
| 15:24.21 | putnopvut | Do you mean menuselect.makeopts or something else? |
| 15:24.28 | Qwell | just a file called makeopts |
| 15:24.29 | putnopvut | or just makeopts |
| 15:24.41 | putnopvut | Yeah, I have it. What do you want to know from it? |
| 15:24.42 | Qwell | What's HAVE_DYNAMIC_LIST say? |
| 15:24.56 | putnopvut | HAVE_DYNAMIC_LIST=1 |
| 15:25.04 | Qwell | shrugs |
| 15:25.09 | Qwell | best I had. |
| 15:25.21 | Qwell | putnopvut: Go to lunch early, maybe elguero will fix it. :p |
| 15:25.26 | putnopvut | ha! |
| 15:25.56 | Qwell | elguero: (I kid, of course - the joke is that you found the issue while he was out to lunch yesterday) |
| 15:26.15 | elguero | Qwell: oh ya, I knew what you meant :) |
| 15:27.07 | Qwell | putnopvut: hell, what does WEAKREF say in makeopts? |
| 15:27.15 | Qwell | If that's 0, then bricks will be thrown. |
| 15:27.27 | putnopvut | It's 0, yo |
| 15:27.36 | Qwell | unlocks the pitchfork cabinet |
| 15:28.56 | putnopvut | I kind of figured it would be 0, but then that doesn't really explain why gcc 4.5 didn't have linking errors after the changed. |
| 15:29.00 | putnopvut | s/changed/change/ |
| 15:29.15 | Qwell | presumably 4.5 has weakrefs set |
| 15:29.23 | putnopvut | Let's find out, shall we. |
| 15:33.09 | putnopvut | oh are you freaking kidding me? Now gcc 4.5 has the linking errors? THIS MAKES NO SENSE! |
| 15:41.32 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 15:42.10 | russellb | Qwell: what? |
| 15:43.43 | russellb | looks back at backlog |
| 15:43.59 | russellb | gcc version fun, *runs away* |
| 15:46.34 | putnopvut | So...my naive way of fixing this is to do similarly to what app_voicemail does. Basically, the global functions call into functions in some core file. Then this core file farms the work out to modules if they are loaded. When the module loads, it will call a registration or installation API so that the core file can know how to farm out the work. |
| 15:46.48 | putnopvut | Does anyone have a better suggestion? |
| 15:49.30 | mjordan | putnopvut: whoops, I missed that line in sip.conf as well |
| 15:50.31 | mjordan | putnopvut: I'm curious why res_smdi is not having this problem |
| 15:51.52 | putnopvut | mjordan: where in the Asterisk core is res_smdi stuff called from? |
| 15:52.07 | mjordan | putnopvut: yeah, that's what I'm checking. Looks like its just apps/channel drivers. |
| 15:52.27 | mjordan | which makes me wonder what would happen if those shared objects would load, assuming you got the Asterisk binary to link |
| 15:52.59 | otherwiseguy | oej: I was looking at your review here: https://reviewboard.asterisk.org/r/1887/ and I see lots of comments from you replying "Done" but it doesn't you actually updated the review after that. If you update the review, I'd be happy to go overt it on this fantastic Code Review Thursday. :-) |
| 15:53.14 | otherwiseguy | s/overt/over/ |
| 15:58.28 | putnopvut | oh, kpfleming isn't here. |
| 15:58.44 | putnopvut | I was going to ask him what the optional API stuff is supposed to do if WEAKREF isn't supported. |
| 15:59.36 | putnopvut | Like, is OPTIONAL_API supposed to affect compilation, or is it simply a run-time aide? |
| 15:59.38 | otherwiseguy | oh, oej also isn't here. |
| 15:59.58 | putnopvut | I wonder if the two of them are having a butter eating contest |
| 16:00.14 | otherwiseguy | ick. |
| 16:00.18 | putnopvut | Butter eating: even if you win, you lose. |
| 16:07.32 | mjordan | otherwiseguy: might have to e-mail oej, I think he's in spain right now doing the SIP Masterclass |
| 16:07.50 | otherwiseguy | mjordan: yep, I'm writing the email as we speak. |
| 16:12.33 | jrose_atDigium | ASTERISK-19562 |
| 16:12.39 | jrose_atDigium | https://issues.asterisk.org/jira/browse/ASTERISK-19562 |
| 16:13.38 | jrose_atDigium | I have a design question concerning the use of mixing users with wait_marked=yes, and users with neither wait_marked=yes or marked=yes |
| 16:15.10 | jrose_atDigium | I'm not sure whether I agree with the reporter that wait_marked users shouldn't be woken up when a non marked, non wait_marked user enters the conference. |
| 16:16.30 | jrose_atDigium | At the same time, the current behavior kinda renders the marked property somewhat moot since just having wait_marked set to 'no' would effectively be the same thing as having a marked user. |
| 16:18.43 | mjordan | jrose_atDigium: having wait_marked=no does mean that a user being marked or not does not affect that user. That's the intended purpose |
| 16:19.42 | mjordan | the behavior of wait_marked is to not start the conference until a marked user shows up. That, as far as I know, is the only defined behavior of that flag. The behavior of the conference prior to the marked user showing up should probably be defined by the bridge profile |
| 16:20.03 | jrose_atDigium | wait_marked isn't a conference property though, it's a user property. |
| 16:20.46 | jrose_atDigium | What I'm wondering is if a conference is started by a non wait_marked user, should wait_marked users still have to wait for a marked user to join to participate. |
| 16:21.05 | jrose_atDigium | mjordan ^ |
| 16:22.12 | mjordan | I don't think the conference has that granularity, nor was it designed to do so |
| 16:22.56 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:24.41 | jrose_atDigium | mjordan: I'm sorry, I don't quite understand what that means in this context.... granularity? |
| 16:25.43 | mjordan | jrose_atDigium: I think you need to explore and define the behavior a bit further, because I'm not confident this scenario was thought through. Granularity, in this case, being ConfBridge supporting and understanding a 'waiting area' for channels with wait_marked, channels without wait_marked and marked 'talking', and channels that are 'marked' triggering the inclusion of others |
| 16:26.18 | mjordan | to me, that implies supporting multiple bridges simultaneously: a "waiting area" bridge for channels waiting for the marked user, and the "conference" bridge for those channels that were put into the conference |
| 16:27.12 | mjordan | that concept is fine, but it isn't something that ConfBridge - as far as I know - was intended to support. There is only a single bridge being mixed, not multiple bridges. |
| 16:27.53 | jrose_atDigium | I don't think there was ever any intention of having the wait_marked users talking in a separate subconference. It's just that they are supposed to wait in music on hold until the conference actually is started. |
| 16:28.08 | jrose_atDigium | except there is the ambiguity with marked users and users that just don't have to wait for marked users... |
| 16:28.21 | mjordan | correct. And that can be triggered either by a marked user, or by a user who is not marked and does not have wait_marked |
| 16:28.38 | jrose_atDigium | In which case, having marked user is redundant. |
| 16:28.41 | mjordan | no, its not |
| 16:29.01 | mjordan | marked users can, potentially, imply other benefits |
| 16:29.07 | mjordan | even if that isn't currently implemented |
| 16:29.22 | jrose_atDigium | Ok, if that's all there is to it then, no problem. |
| 16:30.16 | mjordan | jrose_atDigium: for example, consider the end_marked bridge profile option |
| 16:30.18 | *** join/#asterisk-dev dms (~dms@nat/digium/x-ypfjacenojnncibo) |
| 16:30.33 | mjordan | you could have a non-marked user start the conference, but want only a single marked user to count as ending the conference |
| 16:30.49 | jrose_atDigium | right, that makes sense. |
| 16:51.37 | Corydon76-home | putnopvut: ping |
| 16:53.56 | putnopvut | Corydon76-home: pong |
| 16:54.06 | Corydon76-home | re: optional_api |
| 16:54.35 | Corydon76-home | Any time weak references aren't supported, optional_api essentially completely breaks |
| 16:54.45 | putnopvut | oh lovely |
| 16:55.48 | Corydon76-home | and so we tried to do the best stuff possible, which was to turn optional modules into mandatory modules. That all works great except in this one case, where module symbols are needed in the core |
| 16:57.37 | Corydon76-home | and I really hate stub functions |
| 16:58.11 | Corydon76-home | but this is probably a case where they cannot be avoided, similar to the voicemail api functions |
| 17:01.40 | Corydon76-home | btw, from your commit last week, changing the ast_install_vm_functions API... probably should have converted it to take a pointer to a structure of function points, instead. |
| 17:01.57 | Corydon76-home | s/points/pointers/ |
| 17:02.11 | putnopvut | Instead of taking individual function pointers as parameters? |
| 17:02.54 | Corydon76-home | Right. We did that with ast_custom_function, and it has meant that we've been able to add more stuff to the structure, instead of changing the API |
| 17:03.58 | russellb | and if you do that, add a version to the struct |
| 17:04.24 | Corydon76-home | Makes upgrades less painless, especially if someone else has an alternative provider for the voicemail functions |
| 17:04.27 | russellb | so that stuff doesn't have to get recompiled just because you added something to the end of the struct |
| 17:04.55 | Corydon76-home | err, less painful |
| 17:05.02 | russellb | or if you do break ABI, you can detect ABI skew |
| 17:05.38 | Corydon76-home | Right |
| 17:08.52 | putnopvut | Got an example of a struct in Asterisk that has a version associated with it? |
| 17:10.22 | Corydon76-home | How about astobj2? |
| 17:10.58 | putnopvut | Thanks |
| 17:11.16 | Corydon76-home | data.h has it, also |
| 17:11.28 | Corydon76-home | struct ast_data_handler |
| 17:37.09 | *** join/#asterisk-dev bklang (~bklang@h1-spike.adsl.indra.com) |
| 18:44.08 | russellb | putnopvut: include/asterisk/security_events_defs.h |
| 18:46.08 | russellb | cel.h too it appears |
| 18:52.25 | seanbright | MS (and i'm sure others) used to put a size member as the first thing in the struct, so you had to do something like: |
| 18:52.45 | seanbright | struct foo f; f.size = sizeof(f); ... some_func(&f); |
| 18:52.56 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:52.56 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 18:53.39 | seanbright | and then some_func() could check the size and react appropriately |
| 18:55.19 | seanbright | i guess 32/64 throws a monkey in that wrench |
| 19:04.25 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:04.25 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:53.13 | Qwell | So with today being flag day, do we celebrate by making some non-backwards compatible change? |
| 19:54.02 | kpfleming | forklift! |
| 20:03.22 | russellb | heh |
| 20:03.27 | russellb | remove module support |
| 20:03.36 | russellb | they're overrated |
| 20:18.19 | blitzrage | soooooooo |
| 20:18.27 | russellb | so |
| 20:18.44 | blitzrage | perhaps I missed it, but was there a feature freeze announcement sent on the 3rd Wed. of May? |
| 20:18.54 | mjordan | it was sent slightly later |
| 20:18.57 | blitzrage | ok sweet |
| 20:19.01 | blitzrage | I missed it then :) |
| 20:19.01 | mjordan | (sorry) |
| 20:19.05 | russellb | blitzrage: slacker |
| 20:19.06 | blitzrage | no just thought of it now |
| 20:19.08 | russellb | even I saw it |
| 20:19.10 | blitzrage | glad it was taken care of! |
| 20:19.22 | blitzrage | russellb: I'm not sure what you're implying |
| 20:19.25 | blitzrage | and I don't like it |
| 20:19.40 | mjordan | blitzrage: is your asterisk-dev rule just forwarding everything into the trash? |
| 20:19.45 | russellb | less implying, more saying it straight up |
| 20:19.56 | blitzrage | mjordan: i hate thunderbird and it's what handles my mailing list traffic |
| 20:20.04 | russellb | blitzrage: don't make me knock you off a sky bridge |
| 20:20.06 | blitzrage | so I don't check it as much as I should |
| 20:20.11 | blitzrage | russellb: already done! |
| 20:20.26 | blitzrage | russellb: I'll get you back when you least expect it |
| 20:20.32 | russellb | heh |
| 20:22.15 | blitzrage | I can't believe feature freeze day is just around the corner! |
| 20:23.39 | russellb | at least i got one feature into 11 ... s/res_ais/res_corosync/ ... |
| 20:23.42 | russellb | that's probably it :( |
| 20:24.51 | blitzrage | russellb: you should step up your game |
| 20:25.43 | russellb | blitzrage: oh, okay... |
| 20:26.03 | blitzrage | I've noticed you've been stepping it up the last 2 days |
| 20:26.40 | russellb | quite. |
| 20:36.46 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 20:39.16 | wedhorn | mjordan: ping |
| 20:39.31 | mjordan | wedhorn: pong |
| 20:39.56 | wedhorn | not sure your skinny fix is correct for trunk |
| 20:40.10 | mjordan | which portion? |
| 20:40.18 | wedhorn | i'd submitted a patch that makes l->device pretty much always valid |
| 20:40.37 | mjordan | I can revert the patch in trunk and run their attack script and see what happens |
| 20:40.48 | wedhorn | r368680 |
| 20:41.35 | wedhorn | okay, that would be good. Also worth checking with your patch. |
| 20:47.18 | mjordan | wedhorn: it survived the script without the patch |
| 20:47.57 | mjordan | and survived it with the patch as well |
| 20:48.37 | wedhorn | okay, given r3683680 makes testing l->device redundant, that makes sense |
| 20:49.02 | mjordan | wedhorn: I leave it up to you if you want to blow it out |
| 20:49.27 | wedhorn | yeah okay, I'll remove it as a redundant test at some stage |
| 21:08.23 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 22:03.03 | *** join/#asterisk-dev bklang (~bklang@h1-spike.adsl.indra.com) |
| 22:12.04 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-uneqiiafzdesucjk) |
| 22:20.19 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 22:20.20 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:46.20 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |