| 02:46.08 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:46.08 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 04:48.05 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 04:48.05 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:45.18 | wedhorn | snuff-work: pretty sure 8.5.4 is v17 |
| 06:46.44 | snuff-work | mm.. but i know i tried 9.x fw's too |
| 06:47.05 | snuff-work | getting closer to pushing my phones onto *.. |
| 06:47.25 | snuff-work | making dialplan foo that can be the same over 3 sites |
| 06:47.43 | snuff-work | just taking lil bit of time :) |
| 06:47.59 | snuff-work | i do still like working in good old extensions.conf though.. |
| 06:53.08 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 06:53.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:53.27 | snuff-work | ello oej |
| 06:57.57 | oej | Morning! |
| 08:04.51 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:20.03 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 08:32.09 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 08:32.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:32.31 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1004) |
| 08:32.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:02.00 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 09:20.16 | bombev | hi all |
| 09:46.38 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:46.38 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:48.37 | *** join/#asterisk-dev alsuren__ (~dlaban@80.169.133.251) |
| 10:49.38 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:49.39 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:50.51 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 11:06.42 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 11:41.44 | *** join/#asterisk-dev italorossi (~italoross@189.124.196.68) |
| 13:15.49 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ittlxwtidgtbziic) |
| 13:15.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:38.07 | russellb | is this line correct? ao2_ref(events, -1); ... https://code.asterisk.org/code/browse/asterisk/trunk/main/manager.c?hb=true#to7187 |
| 13:38.11 | russellb | if so, why? |
| 13:38.30 | russellb | oh nevermind, I see it up above |
| 13:38.33 | russellb | carry on. |
| 13:44.51 | mjordan | hm. I should have used RAII_VAR there. |
| 13:45.19 | russellb | all these fancy new toys i need to learn |
| 13:45.26 | mjordan | there is actually a leak on line 7191 |
| 13:45.40 | russellb | mjordan: good catch |
| 13:45.52 | mjordan | RAII_VAR would have prevented that :-( |
| 13:46.00 | mjordan | I blame the developer. |
| 13:46.03 | mjordan | hides |
| 13:46.07 | russellb | :-p |
| 13:55.28 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-thfmbykodwbnlqrm) |
| 14:02.29 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:02.29 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:08.31 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-oyheenwqqnwsfeqd) |
| 14:17.37 | oej | Afternoon sirs |
| 14:18.49 | mjordan | g'morning |
| 14:18.50 | mjordan | :-) |
| 14:49.35 | WIMPy | oej: re cause2sip: I know that it's the current situation, but I thought that was to be an improvement. Or it it just prepareational work? |
| 15:01.22 | oej | The improvement is just that you can add your own translation table in sip2cause.conf. |
| 15:01.57 | oej | To do it right, the core pbx will need to handle sip causes across a bridge, since SIP has so many more codes than poor old ISDN. Having ISDN in the core makes us loose information. |
| 15:02.15 | oej | One patch at a time, not trying to solve all problems with one patch :-) |
| 15:02.47 | WIMPy | Asterisk only uses a small fraction of it so far. |
| 15:02.52 | WIMPy | Ok. |
| 15:04.35 | WIMPy | It's just that I already had to add a string compare to that function in the past. |
| 15:13.24 | oej | Wasn't that commit to trunk a bit premature? I thought we tried to implement a waiting period for all time zones? and the commit message doesn't refer to reviewboard. |
| 15:14.20 | russellb | what, the tab completion thing? it was a trivial patch ... |
| 15:14.28 | russellb | will fix reviewboard link though, thanks |
| 15:15.38 | mjordan | oej: we haven't formalized that yet, but it is something that was verbally discussed and agreed as being a 'good idea' at dev-con |
| 15:16.00 | *** join/#asterisk-dev rbd_ (~rbd@cpe-173-095-178-212.nc.res.rr.com) |
| 15:16.02 | oej | We have discussed it many times on the -dev maililng list before. |
| 15:16.16 | russellb | I think it should be based on common sense and trust amongst committers based on the invasiveness of the patch |
| 15:16.44 | seanbright | agreed. russellb's commits are the bomb. |
| 15:16.59 | rbd_ | hi guys... we're using MRCPRecog and passing a dialplan variable into that, but are finding that our dialplan variables are limited to between 100 and 200 characters in length (asterisk 1.6.x)... is there any way to expand this limit? |
| 15:17.03 | mjordan | counter point: one person's sanity is another' |
| 15:17.08 | mjordan | another's insanity :-) |
| 15:17.22 | seanbright | dude, put up a review to 'svn rm' asterisk trunk |
| 15:17.22 | russellb | meh |
| 15:17.30 | seanbright | i will put a "ship it!" on it immediately |
| 15:17.31 | russellb | this is such a stupid thing to get upset about |
| 15:17.57 | russellb | really makes me want to keep contributing |
| 15:18.40 | russellb | but it's not the projects fault, it's just certain people annoying the crap out of me, so i'll deal with it |
| 15:19.24 | mjordan | russellb: trivialness of the patch aside, you do happen to live in a timezone that makes it easy to get things reviewed. Its understandable that given the global nature of the project, people in other timezones want an opportunity to review things. I'm open to suggestions on how to get there without having a waiting period |
| 15:20.00 | russellb | i think a rule around that is overkill. if it was something more complex, invasive, or controversial, i would have waited at least a day or more |
| 15:20.47 | russellb | otherwise it's an artificial progress rate limiter |
| 15:21.24 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 15:21.42 | russellb | there aren't even "official" rules about whether a patch goes to reviewboard or not, are there? or who can give a ship it? or other more fundamental questions ...why are we talking about rulse around review times? |
| 15:23.42 | mjordan | russellb: agreed that things aren't documented as much as they should be. Its on my list of things to get done from AstriCon. Currently working on the process to have new features included in general - which doesn't even get to the review policies :-) |
| 15:24.38 | russellb | ok |
| 15:26.05 | mjordan | goes back to working on his patch to svn rm chan_sip |
| 15:26.23 | oej | That's way to small for reviewboard. Just commit. |
| 15:26.45 | mjordan | oej: it'd close out a lot of issues on the issue tracker as "can't reproduce" |
| 15:27.08 | oej | Problem solved. |
| 15:28.36 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-146-98.user.veloxzone.com.br) |
| 15:30.07 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:30.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:02.00 | oej | mjordan: will the speed matter with only a handful of codes, really? |
| 16:02.18 | oej | We're not talking about thousands of entries here. |
| 16:03.01 | mjordan | it is used a lot however. Granted, its not in a critical path, but when things have keys I usually think "hash tables" |
| 16:05.58 | oej | hash tables mean a lot of overhead too. |
| 16:06.05 | *** join/#asterisk-dev klobucar (uid1012@gateway/web/irccloud.com/x-hmwjkvlusrjsxusv) |
| 16:06.11 | oej | I don't see a risk of us having 1000 entries or more here. |
| 16:06.21 | oej | Keep it simple. :-) |
| 16:06.38 | oej | It's used at hangups, which is not time critical. |
| 16:07.46 | tzafrir_laptop | rmeyerriecks, any point in keeping dahdi_echocan_sec and dahdi_echocan_sec2 ? |
| 16:07.57 | tzafrir_laptop | Likewise: dahdi_echocan_kb1 |
| 16:19.14 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:19.14 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:19.32 | Qwell | heck yeah, jpah not on the cut list |
| 16:27.48 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:34.12 | rmeyerriecks | tzafrir_laptop: I've not personally ever compiled any of those. |
| 16:36.52 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b481:89a7:a1e9:9271) |
| 16:39.03 | WIMPy | If you're concerned about speed, you culd sort the table and use a binary search, but I doubt it's worth it. |
| 16:45.07 | mjordan | in the end, I like to use data structures that fit the data stored in them (plus, I use ao2 containers a lot, so I'm used to them) |
| 16:48.16 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:51.55 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1006) |
| 16:51.55 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 16:53.20 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:55.51 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:55.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:08.46 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1006) |
| 17:08.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:18.26 | leifmadsen | russellb: I think the tab completion for acl could be fit into the "bug fix" situation |
| 17:18.36 | leifmadsen | that is functionality I would have expected to have existed |
| 17:18.52 | Qwell | +1 |
| 17:19.15 | russellb | fine with me, mjordan ? |
| 17:20.53 | mjordan | russellb: fine with me |
| 17:23.24 | russellb | I'd like to add it to agi show command <...> |
| 17:23.36 | russellb | but it's more difficult due to some res_agi implementation details |
| 17:38.01 | file | elguero, sorry for not getting to your mixmonitor review sooner ^_^ |
| 17:40.52 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:40.52 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:59.47 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:59.47 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:06.25 | sruffell | tzafrir_laptop, rmeyerriecks: Only dahdi_echocan_mg2 and dahdi_echocan_oslec need be kept. IMO. I know kpfleming said he didn't have a problem with that either before he left. |
| 19:07.28 | tzafrir_laptop | Maybe also dahdi_echocan_jpah (for testing) |
| 19:08.04 | sruffell | possibly, then just not compiled by default? |
| 19:14.23 | Qwell | There's no reason JPAH needs to be compiled by default, heh |
| 19:14.38 | Qwell | It was totally useful that one time I used it though. |
| 19:22.52 | *** join/#asterisk-dev italorossi (~italoross@189.124.196.68) |
| 19:59.01 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 21:38.39 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:38.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:44.36 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ittlxwtidgtbziic) |
| 22:47.45 | jsmith | putnopvut: Ping? |
| 22:47.55 | jsmith | putnopvut: (regarding the patch in 20226) |
| 22:48.41 | putnopvut | jsmith: pong |
| 22:49.00 | putnopvut | hopes it hasn't suddenly caused awfulness |
| 22:49.20 | jsmith | putnopvut: Hey, I just saw the announcements for 1.8.18.1 and 1.8.19-rc3, but neither seemed to contain the commit for that patch |
| 22:49.35 | jsmith | putnopvut: Which release version whould I expect to see that patch in? |
| 22:49.41 | Qwell | jsmith: it wasn't a regression |
| 22:49.45 | putnopvut | No, those only have the security fixes. The crash patch will go into the next non-security non-regression version |
| 22:49.50 | putnopvut | So 1.8.20 |
| 22:50.00 | jsmith | Ah |
| 22:50.03 | putnopvut | would be the best guess. |
| 22:50.26 | jsmith | From the announcements, it didn't look like 1.8.18.1 or 1.8.19-rc3 were security patches (but the numbering made me wonder) |
| 22:50.34 | Qwell | regression releases |
| 22:50.37 | Qwell | the .1, anyways |
| 22:50.57 | putnopvut | ah, oops, meant regression. |
| 22:51.09 | jsmith | OK, just making sure I understood |
| 22:51.28 | jsmith | putnopvut: System uptime: 2 weeks, 17 hours, 28 minutes, 59 seconds. 499408 calls processed. |
| 22:51.38 | putnopvut | nice. |
| 22:51.40 | Qwell | aww, so close |
| 22:51.53 | jsmith | Qwell: I know, right? |
| 22:52.11 | file | yay half a million |
| 22:52.28 | jsmith | yay arbitrary large number! |
| 22:52.54 | jsmith | That large number makes jsmith more able to spend time contributing to Asterisk :-) |
| 22:53.25 | jsmith | Qwell: We're now at 499606 -- a few more minutes, and we'll hit it |
| 22:53.40 | Qwell | ANTICIPATION |
| 22:53.55 | file | should I call and help?!? |
| 22:54.00 | Qwell | call 400 times! |
| 22:55.10 | file | jsmith, I *may* have just tweeted that |
| 22:55.21 | file | well, just the uptime / calls processed |
| 22:55.53 | jsmith | 499914 calls processed |
| 22:56.00 | putnopvut | quite the rate |
| 22:58.17 | jsmith | 500045 calls processed |
| 22:58.22 | file | yay |
| 22:59.04 | jsmith | Whee! |