| 00:10.16 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 00:15.21 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 01:21.38 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-tubrqkjuqofabbhy) |
| 01:36.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 01:49.28 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 01:49.28 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 01:49.28 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 01:49.28 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 01:49.28 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 01:49.28 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 01:49.28 | *** join/#asterisk-dev coreyf1513 (~cfarrell@ws2.cfware.com) |
| 01:49.28 | *** mode/#asterisk-dev [+ooo newtonr putnopvut jsmith] by asimov.freenode.net |
| 02:08.07 | *** join/#asterisk-dev X-Rob (sid14615@gateway/web/irccloud.com/x-pkrxfqmghhekalcw) |
| 04:08.03 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 04:08.24 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 04:08.47 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 04:08.47 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 04:36.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 04:39.11 | *** join/#asterisk-dev ccesario (~ccesario@helpdesk.tecnomega.com.br) |
| 05:35.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:18.26 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:18.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:10.27 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:10.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:47.46 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 07:47.46 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 07:48.56 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:48.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:50.36 | *** join/#asterisk-dev Onyx47 (~onyx@213.147.127.88) |
| 07:51.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 07:55.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 07:58.15 | Onyx47 | Hello. I'm trying to get an OpenVox GSM card to work with latest asterisk and dahdi, I got to the point where it compiles without any issues but dahdi is complaining that the spantype is not specified. I'm guessing it's passing a wrong argument somewhere but at this point I'm a bit lost, could anyone point me at a function call I should take a look at? |
| 09:49.58 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 11:09.16 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:39.23 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:39.24 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:00.37 | *** join/#asterisk-dev snuff-work (~snuffy@1.147.206.253) |
| 12:00.37 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:05.00 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 12:09.22 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:45.10 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 12:45.10 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:55.04 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:58.23 | *** join/#asterisk-dev Greenlight (~wluke@host217-36-239-33.in-addr.btopenworld.com) |
| 13:06.38 | seanbright | morning o/ |
| 13:22.33 | newtonr | seanbright, hey hey |
| 13:22.42 | file | yo yo |
| 13:38.15 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-iamwljrjbwpdemah) |
| 13:41.31 | sgriepentrog | coreyf1513: you have shipits on rb3376 - did you want to check that in or have me do it? |
| 13:59.11 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-eugcoddkkhcqlaiu) |
| 14:05.46 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 14:10.34 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 14:11.31 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gfphrjpemnhxooej) |
| 14:22.57 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:26.53 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-asbujstpqabgtnyw) |
| 14:26.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:39.29 | *** join/#asterisk-dev kaii (~kh@ciphron.de) |
| 14:41.10 | *** join/#asterisk-dev vlad_starkov (~vlad_star@193.33.185.132) |
| 14:58.19 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 15:02.14 | *** join/#asterisk-dev oej (~Adium@213.132.102.114) |
| 15:02.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:33.39 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 15:59.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@m842836d0.tmodns.net) |
| 16:04.46 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-vzrgkpyiwvtigmdt) |
| 16:04.46 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:09.05 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6935:9f1c:8bc0:c951) |
| 16:30.09 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-lcwyjqjgjwcnqfum) |
| 16:30.09 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:57.49 | coreyf1513 | sgriepentrog: I got it |
| 17:06.57 | coreyf1513 | one question on committing r3376, how should I credit dlee / r390122? |
| 17:07.20 | coreyf1513 | since I didn't write ast_register_cleanup, I just copied from that change |
| 17:32.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 17:38.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 17:41.10 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 18:16.48 | sgriepentrog | coreyf1513 I would just mention the rev you backported from, that should suffice. |
| 18:20.02 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:20.41 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 18:22.11 | italorossi | Can anyone take a look at https://issues.asterisk.org/jira/browse/ASTERISK-23547 and tell me if this makes sense? |
| 18:41.02 | coreyf1513 | sgriepentrog: thanks |
| 18:42.03 | jsmith | italorossi: Makes sense to me |
| 18:47.50 | sgriepentrog | coref1513: np, ditto |
| 18:49.14 | coreyf1513 | sgriepentrog: for your http/manager shutdown review, any reason that doesn't apply to 1.8 / 11? |
| 18:49.29 | coreyf1513 | socket shutdown that is. |
| 18:50.01 | mjordan | coreyf1513: It would |
| 18:50.42 | sgriepentrog | coreyf1513: initially was 12 issue due to ari, but you are right, will adjust |
| 18:50.53 | coreyf1513 | cool thanks :) |
| 18:50.59 | italorossi | jsmith: (y) thanks! |
| 18:52.07 | italorossi | mjordan: any chance to get this commited? https://issues.asterisk.org/jira/browse/ASTERISK-23547 |
| 18:54.37 | sgriepentrog | italorossi: you should be able to post it to reviewboard.asterisk.org - that will get devs looking at it faster |
| 18:57.36 | mjordan | italorossi: I'm not a commit bot ;-) |
| 18:59.01 | mjordan | italorossi: the wiki has information on the workflow for issues. https://wiki.asterisk.org/wiki/display/AST/Issue+Tracker+Workflow and https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process |
| 18:59.04 | coreyf1513 | how can I record a merge without automatically merging the code? I need to apply a separate patch to each version, but commit as a merge |
| 18:59.26 | mjordan | coreyf1513: usually what I do is run the merge script, then either make the changes or revert everything but the property changes |
| 18:59.34 | mjordan | coreyf1513: you can also edit the properties manually |
| 18:59.50 | putnopvut | Alternately, you can use record<branch><otherbranch> similar to how you do merge<branch><otherbranch> |
| 18:59.59 | mjordan | putnopvut's suggestion is much better |
| 18:59.59 | putnopvut | e.g. record12trunk 12345678 |
| 19:00.01 | italorossi | mjordan: thank you and sorry about that |
| 19:00.05 | italorossi | sgriepentrog: thanks |
| 19:00.12 | mjordan | italorossi: no worries, was just setting expectations. |
| 19:00.40 | coreyf1513 | putnopvut: so record* will update property of '.' without merging the code? sounds like exactly what I need thanks |
| 19:00.43 | mjordan | italorossi: it looks like a trivial change. I'd post it to review board just so someone else takes a look at it - app_queue is nasty and dangerous |
| 19:01.43 | italorossi | mjordan: yeah.. it is... :-) I'm posting right now |
| 19:01.59 | file | trivial changes can have unintended consequences >_> |
| 19:08.52 | coreyf1513 | putnopvut: only thing is record* has different contents for ../merge.msg :( |
| 19:15.43 | putnopvut | coreyf1513: what's different? |
| 19:18.20 | coreyf1513 | "Recorded merge of revisions ..." instead of "Merged revisions..". Also the merge message is added before the original commit message, instead of after |
| 19:19.32 | coreyf1513 | the different text seems somewhat reasonable, the reordering of ../merge.msg seems odd |
| 19:19.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 19:21.10 | mjordan | file: putnopvut: I always forget how we handle domains in pjsip.conf. IIRC, the name of the endpoint has to be [alice@foo.com] . Does the auth/aors/other objects have to use the same name as the endpoint? |
| 19:21.50 | file | auth doesn't, aor can |
| 19:22.04 | file | (suggestions on improvements also welcome) |
| 19:25.58 | mjordan | file: couldn't remember if there was an implicit restriction there |
| 19:27.46 | putnopvut | Yes, what file said. Sorry was looking at code reviews :) |
| 19:27.55 | file | no restriction yarrrr |
| 19:29.16 | coreyf1513 | awesome that reviewboard is automatically marking submitted, it looks like the comment "Committed in revision ..." is being updated by auto-merge (r3386 says it was committed in 411335, which isn't a revision I committed) |
| 19:42.10 | mjordan | yeah... it might be a little zealous on how often it does that. |
| 20:24.05 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 20:31.30 | jrose_atDigium | https://reviewboard.asterisk.org/r/3379/ -- seeking review |
| 20:54.52 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:08.30 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:23.47 | coreyf1513 | gtjoseph: ping |
| 21:23.59 | gtjoseph | coreyf1513: pong |
| 21:24.30 | coreyf1513 | I had a question on your performance tests for ast_spinlock. did your test do any work while the lock was held? |
| 21:24.55 | gtjoseph | yes. integer compares and dummy floating point math |
| 21:25.18 | gtjoseph | the threads also did some work outside the lock |
| 21:26.49 | gtjoseph | there's also a test to make sure the lock actually worked and nothing got stomped on. |
| 21:28.21 | coreyf1513 | my reason for asking is I believe the different methods could perform differently depending on how long the lock is held. so a test that compares an integer in the lock section might do different than a test that compares matching strings |
| 21:29.42 | gtjoseph | yep absolutely. in the single thread run there's obviously no locking but in the multi thread runs there's a high probability of locking because that's all the threads do. |
| 21:30.02 | gtjoseph | so the more work, the longer other threads will spin. |
| 21:30.58 | gtjoseph | that's why I put the floating point math in the lock. |
| 21:31.10 | gtjoseph | I can try with a string compare though. |
| 21:31.50 | coreyf1513 | did you run 1 test with integer, and a different test with floating point? or just integer and floating point in all tests? |
| 21:32.21 | gtjoseph | all threads ran the same test. |
| 21:32.50 | mjordan | jrose: newtonr: continue on. |
| 21:33.21 | mjordan | jrose_atDigium: newtonr: or rather: ASTERISK-23397 and what the purpose of TimeoutChannel should be |
| 21:33.31 | jrose_atDigium | Ok, so if TimeoutChannel is specified, we don't expect it to receive announcements. |
| 21:33.38 | mjordan | jrose_atDigium: I think we interpreted the purpose of that field incorrectly |
| 21:33.49 | mjordan | yes, it is used to construct the dial string callback |
| 21:33.57 | mjordan | but if it does happen to be a real channel, it used to get the announcement |
| 21:34.12 | newtonr | mjordan, jrose_atDigium : i feel like there should be a third option to specify who gets the announcement, as you may not want it to be the parked channel or the channel that eventually gets a callback |
| 21:34.27 | mjordan | newtonr: I'd be fine with that. It'd be backwards compatible at least |
| 21:34.48 | mjordan | we already broke the backwards compatibility with 1.8/11 by deprecating the Channel2 field |
| 21:34.56 | coreyf1513 | gtjoseph: I'm interested in seeing the results when we only change the amount of work done during a lock. so if we have two tests with 4 threads, one test do a single integer compare, the other test do a (more expensive) string compare. |
| 21:34.57 | mjordan | this would just be an addition |
| 21:35.17 | gtjoseph | coreyf1513: I can do that. |
| 21:35.53 | jrose_atDigium | <PROTECTED> |
| 21:36.02 | coreyf1513 | gtjoseph: also if we're going to make a decision based on performance results I think it would be good to run tests in a profiler |
| 21:36.04 | newtonr | mjordan, it would also be more flexible that way, as i may want the callback to eventually go to a queue or something, but i may immediately know who is talking to the channel i want to park, and want to inform that party where they are being parked |
| 21:36.19 | newtonr | *where the other party is being parked |
| 21:37.02 | jrose_atDigium | Alright. Well, I'm down with adding an announcement channel argument as well. |
| 21:37.14 | jrose_atDigium | I'll tinker with it tomorrow if I have a little extra time. |
| 21:37.30 | gtjoseph | coreyf1513: absolutely. I'll get some runs done later today. |
| 21:37.43 | newtonr | jrose_atDigium, cool, i'll add notes to the issue and open it up |
| 21:37.58 | coreyf1513 | gtjoseph: thanks! |
| 21:38.15 | jrose_atDigium | As for the timeout behavior... |
| 21:38.58 | jrose_atDigium | If it's just setting the timeout channel to be the same as the parked channel, that may be fine due to how transfers into parking lots work. But if the behavior when the call actually leaves parking is that it tries to dial itself, that's a bug. |
| 21:39.56 | newtonr | jrose_atDigium, i believe it is the former, let me check at the CLI what it shows |
| 21:40.25 | mjordan | newtonr: when you accept the issue, note what the recommended solution is going to be |
| 21:40.53 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 21:40.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:41.37 | newtonr | mjordan, will do, that is what i meant to say by "i'll add notes to the issue and open it up" |
| 21:41.56 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-dyneqsemwtijrcgl) |
| 21:45.18 | putnopvut | dammit mjordan, you snaked my review on /r/3379 :-P |
| 21:46.26 | mjordan | did we have the same findings? |
| 21:46.27 | mjordan | jinx! |
| 21:46.44 | putnopvut | mjordan: some, but not all. |
| 21:54.38 | newtonr | jrose_atDigium, so when parking with only Channel specified and without TimeoutChannel, "parking show default" shows http://pastebin.com/VgutU52T , so it looks like the Parker Dial String is set to a dial string derived from the "Channel" specified |
| 21:56.15 | jrose_atDigium | newtonr: As long as when the channel comes out of parking afterwards, it isn't attempting to dial itself, that's all expected. It's just part of the logic used when someone transfers someone else into parking. |
| 21:56.52 | newtonr | jrose_atDigium, I think it would make more sense if we could remedy that and have it so that without TimeoutChannel specified, there is no call back to the channel parked. No it doesn't appear that the channel is dialing itself |
| 21:57.25 | jrose_atDigium | That might be true. |
| 21:58.06 | jrose_atDigium | I'm not against the change. I don't know if there is logic in place for not having a timeout channel currently though. |
| 21:58.18 | jrose_atDigium | If not it should be fairly straight forward to deal with... |
| 21:58.22 | jrose_atDigium | I hope. |
| 21:58.45 | newtonr | it looks like the logic is to just set the Parker Dial String to the Channel parked, which doesn't make sense in my opinion |
| 21:59.08 | jrose_atDigium | It makes sense in the context of the parking application, which the park AMI action was just kind of glued into. |
| 22:01.20 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:01.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:01.36 | jrose_atDigium | It also might be more appropriate to just suppress output of the timeout string in the CLI dialogs if it's one that matches the parkee's channel though. |
| 22:02.55 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-vzrgkpyiwvtigmdt) |
| 22:03.28 | newtonr | If I understand that correctly, it sounds like that would have the result I'm leaning for. I'll make sure to note that we should at least look into that and see if it is sensible to change. At a basic level I'd assume that if a user didn't specify a TimeoutChannel that they don't want anything to be called upon a timeout, or essentially there should be no timeout. |
| 22:05.38 | newtonr | goes to write things on the issue |
| 22:05.52 | newtonr | and get food out of microwave |
| 22:21.33 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 22:29.32 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 23:01.58 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-gfphrjpemnhxooej) |
| 23:08.13 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 23:11.14 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |