| 06:55.28 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 06:55.28 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Hell hath frozen over: Asterisk is moving to Git -=- Follow on Twitter at @AsteriskDev |
| 07:20.13 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:35.16 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:40.48 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:40.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:55.44 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7c02:587e:414a:11c6) |
| 10:11.18 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 10:11.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:13.11 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 10:13.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:33.25 | file | glares at pip |
| 10:33.57 | coreyfarrell | pip? |
| 10:34.09 | file | yes, python pip |
| 10:34.25 | file | my requests module somehow got trashed so now pip won't work |
| 10:34.31 | coreyfarrell | oh fun |
| 10:38.03 | file | all better! when in doubt ditch the system package |
| 10:40.04 | file | coreyfarrell, your ASTERISK_REGISTER_FILE change has made me found another bug in our git migration, make ari-stubs doesn't work because there is no doc/rest-api directory |
| 10:40.18 | coreyfarrell | that's in the other review |
| 10:40.23 | coreyfarrell | since it applies to 13 and master |
| 10:40.44 | file | ah |
| 10:40.54 | file | your one liner doesn't reflect that :P |
| 10:44.41 | coreyfarrell | yeah I guess the doc/rest-api fix is kind of slipped in. if you really want I can split it off |
| 10:47.05 | file | it'd be nice, I'd almost be tempted to say the PJSIP cleanup should go into another commit but *shrug* on that |
| 10:49.43 | coreyfarrell | I'll split off both in like 45 minutes. marking that review WIP. |
| 10:49.51 | file | ack |
| 10:52.01 | coreyfarrell | hmm if I split off the PJSIP thing it should go in first, since the ARI fixes required looking at MODULEINFO from additional sources |
| 10:54.45 | file | you could do it as a series, that'll keep it in order |
| 11:00.01 | file | definitely a Wednesday |
| 11:11.58 | coreyfarrell | I don't know how to do a series |
| 11:13.21 | file | it's multiple commits |
| 11:13.33 | file | disclaimer: haven't done it myself - but read about it |
| 11:15.15 | file | russellb posted on -dev about it |
| 11:33.14 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:33.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:56.03 | coreyfarrell | file: so one lesson I just learned, cherry pick on the web ui does not work for series |
| 12:17.09 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:27.25 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-hnumdaocznselfsj) |
| 12:27.25 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:45.36 | file | I'm not surprised |
| 12:59.37 | russellb | correct ... you need to rebuild the series locally |
| 13:16.51 | *** join/#asterisk-dev mjordan (~mjordan@104-145-12-182.dedicated.allstream.net) |
| 13:16.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:33.02 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-cjctelnqdlzontsk) |
| 13:35.53 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-znboglzpahbrtuuo) |
| 13:35.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:00.00 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:08.35 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-sdcxbzwpoutagclc) |
| 14:18.15 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:18.38 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:21.24 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:24.30 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-97-196.user.veloxzone.com.br) |
| 14:27.59 | *** join/#asterisk-dev roramirez (~rodrigo@190.54.225.167) |
| 14:28.04 | roramirez | Hello |
| 14:29.18 | file | hello |
| 14:31.14 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fafmfvinhcawlavf) |
| 14:38.44 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 14:48.21 | mjordan | superscrat: Can you cherry-pick https://gerrit.asterisk.org/#/c/254/ to 13? |
| 14:48.44 | superscrat | Yes, I can do that, mjordan. Sorry - that was meant to happen yesterday. |
| 14:48.50 | mjordan | no worries :-) |
| 14:49.43 | file | I was on the verge of cherry picking it myself but wanted to see how long you'd take :P |
| 14:53.57 | superscrat | Oh, come on you guys. It just slipped my mind yesterday :p |
| 14:54.01 | superscrat | It is done. |
| 14:55.01 | superscrat | Here is a joke for you: Git. May the forks be with you. |
| 14:55.22 | file | I only have a spoon |
| 14:56.17 | Marquis42 | There is no spoon |
| 14:56.17 | superscrat | File, do you also have ice cream? |
| 14:56.27 | file | no, I have frozen yogurt |
| 14:57.29 | superscrat | That will work, file. |
| 14:57.39 | file | that it will |
| 15:05.44 | mjordan | huh, looks like we might have a compilation error in 13? |
| 15:05.45 | mjordan | https://bamboo.asterisk.org/bamboo/download/AST-ATSF1-C632TE/build_logs/AST-ATSF1-C632TE-248.log |
| 15:06.23 | file | mjordan, did - past tense |
| 15:06.38 | mjordan | yay |
| 15:06.51 | mjordan | sorry, showing tm1000 bamboo and saw it was failing |
| 15:07.24 | file | the future is buildier! |
| 15:09.18 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:15.00 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-pofntkwkohjlvzgq) |
| 15:18.34 | coreyfarrell | newtonr: did you want me to do something with ASTERISK-19533? |
| 15:24.34 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:24.39 | newtonr | coreyfarrell, nope, it just auto-assigned back to you. I'm asking the FreePBX guys about it via IRC/Email to see if it is still an issue. |
| 15:28.21 | roramirez | A question. In cdr/cdr_odbc.c was introduced a feature newcdrcolumns. (https://github.com/asterisk/asterisk/commit/358080e86ebd1258a288ede50d9ae9f29d7fcd90). I've been watching the others CDR backends and neither is logged the new columns introduced in 1.8. |
| 15:30.39 | roramirez | i can do for other backend. What do you thinks is best configuration on cdr.conf or this configuration for each backend config file? |
| 15:39.27 | rmudgett | superscrat's patch that just went in has a syntax error. |
| 15:40.16 | file | oh god, it does |
| 15:40.26 | file | missing ) |
| 15:41.19 | malcolmd | yop |
| 15:42.04 | file | rmudgett, are you submitting a review to fix it? |
| 15:42.27 | rmudgett | I just noticed it when glancing at the commit email. |
| 15:42.38 | rmudgett | I wasn't in the process of fixing it. :) |
| 15:42.44 | file | k |
| 15:45.07 | roramirez | sorry guys, somebody can give a light? |
| 15:47.33 | file | fix is up |
| 15:47.46 | file | roramirez, personally I think per-backend |
| 15:49.57 | file | and merged |
| 15:50.39 | mjordan | file: roramirez: apologies, in meetings, but yes, I'd do it per backend that needs it. The CDR core doesn't have hooks into the backends to tell them which columns to write out |
| 15:51.25 | mjordan | file: roramirez: it'd be nice if it did, but it isn't worth breaking ABI for it |
| 15:53.59 | roramirez | file: mjordan: good, i'll do. |
| 16:03.54 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 16:17.13 | stefan27 | hello asterisk-people |
| 16:22.12 | *** part/#asterisk-dev roramirez (~rodrigo@190.54.225.167) |
| 16:25.07 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 16:27.08 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-mmikwjddedivtavx) |
| 16:54.57 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 17:00.06 | coreyfarrell | rmudgett: am I correct to assume that recursively locking an ao2 object is not ok? |
| 17:01.27 | rmudgett | You can recursively lock a mutex in Asterisk. You only run into problems when trying to avoid a deadlock situation. |
| 17:01.57 | rmudgett | You cannot recursively lock a rd/wr lock. |
| 17:02.26 | coreyfarrell | this is about the ao2_weakproxy_ref_object, I had avoided ao2_lock for delta < 0 because __ao2_ref will lock the weakproxy |
| 17:02.45 | rmudgett | There are many places in Asterisk where a channel lock is held several times by a single thread. |
| 17:04.11 | coreyfarrell | do you think I should just get rid of the flags / OBJ_NOLOCK for that function? the __ao2_ref for delta < 0 always locks. |
| 17:05.21 | coreyfarrell | or I guess what is the point of OBJ_NOLOCK for any of the weakproxy functions? I thought I was doing it to avoid locking recursion :) |
| 17:06.02 | rmudgett | Keeping the flag is fine. It just says you already have the lock and avoids the slight overhead of locking it again. |
| 17:06.27 | coreyfarrell | got it |
| 17:16.14 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 17:26.13 | rmudgett | coreyfarrell: I'm not sure how useful the ao2_weakproxy_ref_object function will be. |
| 17:30.02 | coreyfarrell | rmudgett: I have a use for it. |
| 17:57.18 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 17:59.19 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 18:03.48 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:03.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:35.19 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 18:37.32 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 18:40.38 | mjordan | putnopvut: I'm assuming https://gerrit.asterisk.org/#/c/291 doesn't apply to 13 due to the media overhaul? |
| 18:41.02 | putnopvut | mjordan: that is correct |
| 18:51.41 | coreyfarrell | mjordan: looks like gerrit stopped sending to asterisk-code-review |
| 18:59.14 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-qspjkuqtwziucfnv) |
| 19:02.42 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-kebbwltuefxyiyut) |
| 19:04.44 | file | coreyfarrell, mailman hates it sometimes |
| 19:35.02 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:35.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:35.59 | auntie | I have a test in the testsuite (using apptest.py) that *passes* according to the logs. However, it always hangs indefinitely at the end of the test with Reactor timeout: '30' seconds. I have to kill it with SIGINT |
| 19:36.38 | auntie | this seems to happen to a lot of other tests, most of them I assume are broken because I don't have sipp installed on my vm... is this hanging a known problem? or am I doing something terribly wrong? |
| 19:38.02 | superscrat | auntie, you probably need to have some code that will stop the reactor once you are sure the test is done. |
| 19:38.11 | superscrat | err, the twisted.reactor |
| 19:40.02 | auntie | superscrat: the apptest.py module has a built in end-scenario action that I use and the test logs confirm that... |
| 19:40.27 | auntie | looking at other apptest.py tests that pass, I can't seem to figure out what I'm overlooking :s |
| 19:41.16 | auntie | I'm surprised the "reactor timeout" does not fail my tests. I wish it would :/ |
| 19:42.49 | superscrat | auntie, look at the end_scenario method inside of apptest.py and follow that around. See if you are doing what the other tests do with respect to stopping the reactor |
| 19:54.03 | auntie | mmmm... it makes a chain of deferred callbacks, and it manages to stop asterisk... |
| 19:54.16 | auntie | but the __stop_reactor callback never seems to get called |
| 19:54.35 | auntie | at least I know where to point a debugger |
| 19:55.45 | superscrat | :) |
| 19:59.12 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 20:21.40 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-yacxtbqyfnsrkckx) |
| 20:25.30 | mjordan | hm. |
| 20:26.44 | file | mjordan, yes. |
| 20:30.02 | mjordan | I think steve davies DTLS patch is causing memory corruptions |
| 20:30.13 | mjordan | if you do a core reload |
| 20:30.27 | mjordan | http://pastebin.com/NdBM9Cwy |
| 20:33.07 | file | mjordan, I bet dtls_cfg_free is being called twice, looks like the stuff in the struct isn't set to NULL afterwards |
| 20:38.34 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 20:41.03 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 21:05.43 | mjordan | file: going to take a look at that now |
| 21:22.28 | mjordan | yay, that appears to have fixed it |
| 21:33.17 | file | mjordan, 'tis applicable to 11 too |
| 21:35.20 | mjordan | kk |
| 21:40.41 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:48.08 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-ltyzcqwcxlsguybx) |
| 22:08.11 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-znboglzpahbrtuuo) |
| 22:20.11 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 23:04.52 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 23:05.04 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-sdcxbzwpoutagclc) |