| 00:49.48 | *** join/#asterisk-dev Tim_Toady (n=moi@adsl96-115.ath.forthnet.gr) |
| 01:22.27 | *** join/#asterisk-dev snuff-work (n=aaa@120.17.228.53) |
| 01:22.27 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:35.42 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 01:39.57 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:39.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:46.56 | Kobaz | is there a doxygen for the asterisk source around? |
| 01:53.31 | kpfleming | there should be on asterisk.org but it disappeared when the new version of the site was put online and it hasn't reappeared yet |
| 02:02.00 | Kobaz | yeah |
| 02:02.50 | Kobaz | quick question |
| 02:03.06 | Kobaz | i wrote a new dialplan application that returns a list of channels |
| 02:03.14 | Kobaz | what would be the preferred method to return said list |
| 02:03.20 | Kobaz | right now it's comma seperated |
| 02:03.36 | Kobaz | <PROTECTED> |
| 02:03.48 | Kobaz | and the code: |
| 02:03.49 | Kobaz | <PROTECTED> |
| 02:03.56 | Kobaz | <PROTECTED> |
| 02:04.08 | Kobaz | i was thinking it would be nice to have an itterator type thing |
| 02:05.03 | Kobaz | like ChanList(myhandle,foo); and then ChanListNext(myhandle); and then ChanListDone(myhandle); |
| 02:05.06 | Kobaz | sort of thing |
| 02:06.09 | kpfleming | that is the model we are following with other new dialplan functions; usually they create a datastore on the channel, populate it with the results, and then the iterator function pulls values off one at a time |
| 02:06.18 | Kobaz | ah okay |
| 02:06.29 | Kobaz | and if the use never free's the iterator? |
| 02:07.15 | Kobaz | so, how should i restructure, so it gets accepted as a new app? |
| 02:08.05 | kpfleming | the datastore will be destroyed when the channel is destroyed, they have destructors |
| 02:08.28 | Kobaz | ah okay |
| 02:08.28 | kpfleming | take a look at any function in the funcs directory that uses datastores |
| 02:08.35 | Kobaz | k |
| 02:08.56 | Kobaz | know one in particular? |
| 02:09.16 | kpfleming | no, i'm sitting on the sofa watching tv, not thinking about code |
| 02:09.54 | Kobaz | aww |
| 02:12.55 | Kobaz | so... should my thing be a function, or an application |
| 02:23.51 | paravoid | pheww, that was a long night |
| 02:24.09 | paravoid | been working on Debian's asterisk packages for the past 10 hours... |
| 03:49.24 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 03:49.24 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 03:49.27 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 03:49.27 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 03:53.38 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 03:53.38 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 03:53.55 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 03:53.55 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 04:23.52 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 04:23.52 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 04:35.21 | *** join/#asterisk-dev xpot (n=xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 05:29.37 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 05:29.37 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:20.19 | *** join/#asterisk-dev oej (n=olle@host-90-232-57-254.mobileonline.telia.com) |
| 06:20.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:47.08 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 06:52.54 | *** join/#asterisk-dev |Cybex| (n=John@212.178.82.20) |
| 07:12.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:12.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:37.33 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@local.xorcom.com) |
| 07:37.33 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |
| 08:03.19 | *** join/#asterisk-dev Gugge (n=gugge@vlan2.dlxhosting.dk) |
| 08:24.49 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:27.58 | *** join/#asterisk-dev Melifaro (n=melifaro@me.asl.ru) |
| 09:44.40 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 09:44.40 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 10:00.46 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 10:00.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:01.58 | tzafrir | I still get a strange error building chan_dahdi in dev-mode without HAVE_SS7: |
| 10:02.12 | tzafrir | chan_dahdi.c:13027: error: unused variable âpollersâ |
| 11:09.10 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:22.03 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:22.03 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:36.56 | *** join/#asterisk-dev sgimeno (n=sgimeno@226.Red-80-33-64.staticIP.rima-tde.net) |
| 11:39.53 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:39.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:46.00 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:46.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:05.15 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 12:05.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:21.22 | atis_work | is there some official AGI protocol description in source tree? |
| 12:21.47 | atis_work | i think there are some inconsitencies, just want to check |
| 12:30.59 | kpfleming | i don't think there is, beyond res_agi.c itself |
| 12:35.50 | atis_work | kpfleming: don't you find strange that GET DATA returns entered number in result=value not data as other commands |
| 12:36.27 | seanbright | i don't find that strange |
| 12:36.41 | seanbright | now the geoduck... that is strange |
| 12:47.00 | *** join/#asterisk-dev davidbrillert (n=aragon12@h216-235-8-130.host.egate.net) |
| 12:53.45 | kpfleming | i have never really used AGI, so i can't say that i even know what you are talking about |
| 13:01.32 | paravoid | doc/tex/backtrace.tex still mentions bugs.digium.com instead of issues.asterisk.org, anyone here for a small fix? |
| 13:01.48 | paravoid | opening and closing a bug is more effort than actually fixing it :) |
| 13:02.21 | kpfleming | seanbright is good at that stuff |
| 13:05.47 | seanbright | is not sure how to take that |
| 13:08.09 | tzafrir | M15054 |
| 13:08.11 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_dahdi/NewFeature 0015054: [patch] span numbers in pri debug / error messages reported by tzafrir (Karma: +123.50) https://issues.asterisk.org/view.php?id=15054 |
| 13:08.37 | tzafrir | Small patch (Extra feature). I like it and use it. Commit or go through review? |
| 13:12.05 | tzafrir | 'bugs.digium.com' has been completely extermenated from trunk, but is still present in 1.6.2 |
| 13:13.09 | kpfleming | there's really no reason to change it in non-trunk branches, the bugs.digium.com name will continue to work indefinitely |
| 13:16.45 | tzafrir | reason: actual distributions in the real world for the time being |
| 13:17.07 | tzafrir | Not that I care that much about this |
| 13:18.45 | kpfleming | like i said, though, the hostname will continue to work, it's fine if there are documents out there five years from now that still point people there |
| 14:26.01 | *** join/#asterisk-dev gardo (n=gardo@121.96.137.100) |
| 14:39.49 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:39.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:41.49 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:41.50 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:50.04 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 14:50.04 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:50.09 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:50.09 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:50.15 | jsmith | otherwiseguy: OK, I'll ask here |
| 14:50.40 | jsmith | otherwiseguy: [Oct 24 16:59:07] WARNING[7529] res_http_post.c: Unable to open asterisk//var/spool/asterisk/uploads//test1.txt for writing file from a POST! |
| 14:50.56 | otherwiseguy | jsmith: http show status |
| 14:50.58 | jsmith | otherwiseguy: Am I doing something wrong, or is Asterisk doing something wrong? |
| 14:52.23 | jsmith | otherwiseguy: http://asterisk.pastebin.com/m678f522b |
| 14:53.30 | otherwiseguy | jsmith: can you also use `ngrep -q -Wbyline port 8088` to show me the POST request? |
| 14:53.35 | kpfleming | and what are the permissions/owernship of that directory? |
| 14:53.46 | otherwiseguy | it is the leading "asterisk" that is the problem. |
| 14:53.56 | kpfleming | oh, yeah |
| 14:54.10 | jsmith | permissions are fine |
| 14:54.31 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:54.31 | otherwiseguy | i'm assuming that the request is mangled somehow--since we haven't touched that code in ages. |
| 14:58.17 | seanbright | jsmith: what does http.conf look like? |
| 14:58.43 | *** join/#asterisk-dev moy (n=moy@74.12.131.148) |
| 14:59.23 | jsmith | otherwiseguy: http://asterisk.pastebin.com/d62f9aa56 |
| 14:59.39 | jsmith | seanbright: It looks like you'd expect it to... and you can see all the setting from my previous pastebin |
| 15:01.09 | seanbright | i have no expectation of how it looks :-) |
| 15:13.39 | jsmith | seanbright: http://asterisk.pastebin.com/d7feea3fb, for the sake of completeness |
| 15:14.14 | jsmith | otherwiseguy: Did my pastebin make sense? Did I mess it up somehow? |
| 15:16.50 | otherwiseguy | jsmith: It looks ok, I suppose. Nothing is jumping out at me, anyway. I'll see if I can look at the code later today. Not feeling too well this morning. |
| 15:17.12 | otherwiseguy | curses control-enter on Colloquy |
| 15:18.20 | jsmith | otherwiseguy: OK... I'm happy to share a short snippet of PHP (no snickers, please) code that uploads the file, if it's helpful. |
| 15:18.46 | kpfleming | there is file upload code in asterisk-gui already that we know works... you might want to compare |
| 15:21.53 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:28.13 | tzafrir | Who is the guest operator? |
| 15:32.34 | jsmith | kpfleming: I looked there first, but didn't see anything obvious there |
| 15:33.25 | kpfleming | tzafrir: looks like bkruse, an ex-digium employee |
| 15:43.47 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 15:45.52 | *** join/#asterisk-dev jetsnoc (n=brian@72.22.242.66) |
| 15:46.09 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 15:52.23 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 15:59.22 | ebroad | anyone seeing unclosed rtp ports in the latest svn trunk revision? |
| 16:01.19 | *** join/#asterisk-dev denon (i=denon@sassinak.net) |
| 16:16.24 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:41.27 | ebroad | jpeeler, ping |
| 16:41.42 | jpeeler | pong |
| 16:41.49 | jsmith-busy | otherwiseguy: Should I open a ticket with the details I shared earlier, so they don't get lost? |
| 16:41.55 | jsmith-busy | otherwiseguy: Or should I just be patient? |
| 16:42.58 | ebroad | jpeeler, just curious, any update on the acl issue? |
| 16:43.20 | jpeeler | ebroad: it should all be taken care of today |
| 16:43.28 | ebroad | jpeeler, sweet, thanx! |
| 16:45.43 | TSM2 | is there a way for me to make it so that the number that is said when you park a call is just repeated again and again? do i need to modify the code and recompile? |
| 16:49.28 | Qwell | TSM2: That's a #asterisk question |
| 16:53.51 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:53.51 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:05.12 | ebroad | where there any recent changes to directmedia? |
| 17:05.50 | ebroad | on svn trunk(latest revision) asterisk is sending reinvites even though directmedia is explicitly set to no |
| 17:11.10 | TSM2 | not sure if this could be included in, res/res_features.so:535 can a ast_hangup be inlcuded after the digits have been said, im going to compile my own one but im sure its annoyed other people |
| 17:11.54 | kpfleming | ebroad: i am not aware of any changes that should have caused that |
| 17:12.14 | kpfleming | have you confirmed via 'sip show peer' that directmedia is set to no for at least one of the peers in the call? |
| 17:12.38 | kpfleming | and is the reinvite a direct media reinvite, as opposed to T.38, hold/unhold, etc. |
| 17:13.51 | ebroad | kpfleming, directmedia is disabled and the reinvite is voice(the internal peer is a cisco 7940, so no t38 there) |
| 17:14.07 | kpfleming | does the reinvite have the peer's IP address for media in it? |
| 17:14.15 | ebroad | yup |
| 17:14.26 | ebroad | and i have nat set to yes for my sip trunk |
| 17:14.33 | kpfleming | and you've confirmed that 'sip show peers' show directmedia set to no |
| 17:14.37 | ebroad | yup |
| 17:14.38 | kpfleming | sorry, sip show peer |
| 17:14.42 | kpfleming | well, that's very odd |
| 17:14.50 | kpfleming | is this only in trunk, or also in 1.6.2? |
| 17:14.50 | ebroad | heres the strange part |
| 17:14.53 | ebroad | trunk |
| 17:14.57 | ebroad | recent |
| 17:15.06 | kpfleming | can you test 1.6.2? |
| 17:15.12 | ebroad | this started around 225380 or so |
| 17:15.57 | ebroad | i thought it was 224565, but reverting didn't help |
| 17:16.41 | ebroad | the strange part is, once the call is done, the rtp ports are still open |
| 17:17.41 | kpfleming | so something is badly broken |
| 17:17.51 | kpfleming | please test 1.6.2 and see if the breakage is present there as well |
| 17:17.54 | ebroad | sure |
| 17:21.07 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:21.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:30.49 | seanbright | "5 - G.729 Codecc" |
| 17:31.41 | seanbright | the register utility has that typo in it. |
| 17:31.47 | seanbright | fwiw |
| 17:32.34 | file | kpfleming / ebroad: it seems to be trunk only, and I think it's a dialog refcount issue (destroy function isn't getting called it seems) |
| 18:03.13 | ebroad | file, thanks! kpfleming, i am reverting your recent astobj2 changes to see if thats what did it, i will let you know once the sounds finish d/l'ing |
| 18:23.29 | ebroad | kpfleming, it was the astobj2 OBJ_MULTIPLE changes |
| 18:23.45 | ebroad | im can reproduce it after r225245 |
| 18:23.52 | ebroad | s/im/i/ |
| 18:26.34 | ebroad | make that 225244 |
| 18:41.57 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200.171.132.124) |
| 19:04.41 | seanbright | digium online store suggestion: have a checkbox to include company name with the credit card transaction. |
| 19:04.48 | seanbright | and no, i will not email the webmaster. |
| 19:04.50 | seanbright | :) |
| 19:04.58 | file | then no soup for you |
| 19:05.08 | seanbright | then no money for you |
| 19:05.25 | seanbright | well, not "you" specifically |
| 19:24.24 | *** join/#asterisk-dev securevoip (n=securevo@173-15-197-73-BusName-Richmond.hfc.comcastbusiness.net) |
| 19:27.13 | *** join/#asterisk-dev tzafrir (n=tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 19:27.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:46.11 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 20:01.32 | The_Boy_Wonder | DUDE |
| 20:06.57 | ebroad | The_Boy_Wonder, you rang? :P |
| 20:07.58 | *** join/#asterisk-dev TheDavidFactor (n=chatzill@fw1.safedataisp.net) |
| 20:08.41 | The_Boy_Wonder | ha, the "DUDE" was a result of my window focus not being on the chat I thought it was on... good thing it wasn't a password :p |
| 20:10.26 | TheDavidFactor | Do you all take kindly to noob code questions? |
| 20:10.27 | ebroad | yup, you better be carefull, Corydon76-dig p'wned file's box that way :p |
| 20:10.35 | *** part/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 20:12.30 | TheDavidFactor | why is there a ast_gethostbyname in main/utils.c & utils/utils.c and how do I know what uses which? |
| 20:13.50 | *** join/#asterisk-dev securevoip (n=securevo@173-15-197-73-BusName-Richmond.hfc.comcastbusiness.net) |
| 20:15.34 | ebroad | TheDavidFactor, which version? |
| 20:15.46 | TheDavidFactor | 1.6.1.6 |
| 20:16.49 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:17.12 | TheDavidFactor | I've got a problem, where ast_gethostbyname seems to be return 0.0.0.0 for any IP Address and I'm trying to track it down, before claiming it's a bug |
| 20:17.44 | ebroad | in svn trunk, utils/utils.c doesn't exist |
| 20:17.55 | ebroad | so you might want to use the one under main |
| 20:19.00 | ebroad | um, in 1.6.1.6 release, there is no utils/utils.c |
| 20:22.35 | TheDavidFactor | there is in the tarball I have, I downloaded it from asterisk.org; but you answered my question so thanks! :-) |
| 20:22.54 | ebroad | wierd, i just downloaded, and its not in there |
| 20:23.01 | ebroad | oh well, your welcome |
| 20:24.37 | TheDavidFactor | I'm actually trying to work with app_externalivr, but it's using ast_gethostbyname and if I give ExternalIVR a hostname it works, but if I give it an IP Address it tries to connect to 0.0.0.0; like I said though, I want to trace it down before claiming I've found a bug |
| 20:38.09 | ebroad | TheDavidFactor, has this ever worked on any other version? |
| 20:39.31 | *** join/#asterisk-dev denon (i=denon@sassinak.net) |
| 20:45.10 | TheDavidFactor | don't know, I found some other stuff that I know for sure hasn't |
| 20:46.13 | ebroad | there is code in ast_gethostbyname() to handle ip addresses and convert them via inet_pton() |
| 20:47.30 | ebroad | app_externalivr may be trying to convert them again, i havent had a chance to look at the code |
| 20:50.04 | TheDavidFactor | I'll look at that, I'm trying to printf the inet_pton output, but I'm getting an error when I try to use inet_ntoa, but if I use ast_inet_ntoa I get an error stating that there's an incompatible type for argument 1 |
| 20:50.51 | ebroad | use inet_ntop |
| 20:53.43 | TheDavidFactor | thanks for the pointer |
| 20:55.53 | *** part/#asterisk-dev securevoip (n=securevo@173-15-197-73-BusName-Richmond.hfc.comcastbusiness.net) |
| 21:05.25 | kpfleming | file: ebroad: what were you guys talking about? i was in a meeting for a while |
| 21:05.47 | ebroad | he was asking about ast_gethostbyname(), app_externalivr and ip addresses |
| 21:06.10 | ebroad | woops |
| 21:06.51 | ebroad | kpfleming, file mentioned that the issue is due to a refcount, looks like the dialog still has 1 ref alive |
| 21:06.57 | ebroad | so it does not get destroyed |
| 21:07.21 | kpfleming | umm... i don't quite understand how the OBJ_MULTIPLE changes could have affected that |
| 21:07.25 | ebroad | i confirmed that it was your astobj2 OBJ_MULTIPLE changes that did it |
| 21:07.30 | kpfleming | which revision was the culprit? |
| 21:07.38 | ebroad | beats me, im too tired to change ref counts |
| 21:07.42 | ebroad | 225244 |
| 21:08.45 | kpfleming | umm... that revision didn't even touch chan_sip |
| 21:08.56 | kpfleming | what else is running on this box that might be iterating over channels? |
| 21:13.03 | TheDavidFactor | ebroad, I figured out what is going on. In ast_gethostbyname() if it detects an IP it sets the length to zero, this never gets changed. For a hostname the length is set appropriately. app_externalivr does a memcpy based on that length so it's copying zero bytes. Is this a bug in app_externalivr or in ast_gethostbyname? |
| 21:14.10 | mvanbaak | I would say it's a bug in ast_gethostbyname |
| 21:14.47 | mvanbaak | but that is without looking at the code and the documentation of ast_gethostbyname |
| 21:15.02 | TheDavidFactor | but, ast_gethostbyname is working in all other known cases (I assume) |
| 21:15.13 | mvanbaak | check the doxygen stuff if it tells you that it will be 0 when handed an ip address |
| 21:15.30 | TheDavidFactor | I would think that this would have been tripped some where else if it were a problem with ast_gethostbyname |
| 21:15.54 | mvanbaak | well, maybe no other place uses the length for a memcpy |
| 21:16.25 | *** join/#asterisk-dev work|philipp64 (n=chatzill@66.232.79.143) |
| 21:18.32 | ebroad | TheDavidFactor, i would agree with mvanbaak in this case |
| 21:18.39 | TheDavidFactor | where could I find the doxygen stuff, asterisk.org/doxygen appears to be usage related not code related |
| 21:20.36 | ebroad | actually, h_length never gets set |
| 21:20.53 | ebroad | mvanbaak, it could be everywhere else we are using sizeof() |
| 21:21.12 | mvanbaak | yuh |
| 21:21.36 | TheDavidFactor | should I submit a patch or are you guys going to handle it? |
| 21:21.43 | ebroad | TheDavidFactor, can you try this |
| 21:21.51 | kpfleming | TheDavidFactor: you'll have to build your own doxygen stuff at this point, the stuff on asterisk.org is currently broken |
| 21:22.02 | ebroad | change hp.hp.h_length to sizeof(hp.hp.h_addr) |
| 21:22.51 | ebroad | kpfleming, re astobj2, there is nothing else on the box |
| 21:22.58 | ebroad | and r225243 works fine |
| 21:23.13 | TheDavidFactor | you're talking about in the memcpy in app_externalivr, right? |
| 21:23.14 | kpfleming | anything connecting over manager interface? |
| 21:23.23 | ebroad | TheDavidFactor, yes |
| 21:23.49 | ebroad | nope, vanilla asterisk, i manage my config with nano :) |
| 21:24.02 | Qwell | infobot: ebroad++ |
| 21:24.10 | kpfleming | ok, i'll double check |
| 21:24.17 | Qwell | Soon, we will outnumber you all. |
| 21:24.18 | mvanbaak | whehehehe, I was waiting for that Qwell |
| 21:24.23 | TheDavidFactor | that works as expected. Is that the correct solution, or is having ast_gethostbyname set h_length the correct solution? |
| 21:25.10 | mvanbaak | I still thing h_length should be set correctly in ast_gethostbyname |
| 21:25.30 | TheDavidFactor | so doing both might be best? |
| 21:25.41 | ebroad | well, either way will work, though i agree with mvanbaak on this, we should grab the pointer from inet_pton |
| 21:25.45 | ebroad | sizeof |
| 21:25.50 | ebroad | and set h_length |
| 21:26.16 | mvanbaak | yup |
| 21:26.35 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:28.30 | ebroad | Qwell, you sound like a res_mysql man |
| 21:28.33 | ebroad | ;) |
| 21:28.43 | kpfleming | ebroad: wait a second... there was a bug in the code that was committed as r225244, which was fixed later, which involved refcount leaks. that revision is known to be broken, so i don't think it's your problem. |
| 21:29.33 | ebroad | kpfleming, so 225406 is broken as well? |
| 21:29.35 | Qwell | ebroad: nano |
| 21:29.57 | ebroad | Qwell, i think we need a res_nano |
| 21:30.05 | ebroad | or res_vi |
| 21:30.14 | kpfleming | ebroad: the bug was fixed in 225405 |
| 21:30.25 | kpfleming | but that was a different type of problem |
| 21:30.27 | kpfleming | so maybe not |
| 21:30.36 | kpfleming | let me try to run it here and see what happens |
| 21:30.39 | ebroad | kpfleming, mean 405 |
| 21:30.48 | ebroad | *meant |
| 21:34.34 | ebroad | TheDavidFactor, file a bug on the issue tracker(if you haven't already) and ill try to put together a patch later on this evening |
| 21:48.19 | TheDavidFactor | ebroad, I've created patches, I'll include them in the bug report |
| 21:48.38 | ebroad | TheDavidFactor, that works too, makes my life easier :p |
| 21:52.33 | kpfleming | ebroad: getting close to finding the problem... stay tuned |
| 21:52.51 | ebroad | kpfleming, holding my breath :p |
| 21:52.56 | ebroad | kpfleming, thanx! |
| 21:58.44 | TheDavidFactor | ebroad, do you have a suggestion for a Category for the util.c patch? I read through the list but don't really see anything that directly applies, would Core/Netsock be applicable? |
| 21:59.27 | ebroad | TheDavidFactor, i guess so, it sorta fall in to that category |
| 22:03.37 | kpfleming | ebroad: r225955 has the fix |
| 22:03.47 | ebroad | kpfleming, sweet |
| 22:03.55 | kpfleming | thanks for testing! |
| 22:05.08 | ebroad | building right now |
| 22:05.47 | kpfleming | r225405 fixed one problem, but caused another one :-) |
| 22:06.57 | mvanbaak | kpfleming: now onto something totally different |
| 22:07.07 | kpfleming | good |
| 22:07.15 | mvanbaak | kpfleming: I remember you guys had to resync the public svn server couple of times |
| 22:07.29 | kpfleming | we've had to do that many times in the past |
| 22:07.43 | mvanbaak | kpfleming: based on the time that took, I guess you just reset the mirror to 0 and run svnsync to sync the whole repo |
| 22:07.46 | mvanbaak | right ? |
| 22:07.50 | kpfleming | yeah |
| 22:07.58 | mvanbaak | ok, that can be done differently |
| 22:08.11 | mvanbaak | just found out and saved hours and hours of syncing |
| 22:08.22 | TheDavidFactor | ebroad, done, there should be two new issues out there for you ;-) |
| 22:08.35 | mvanbaak | svnadmin dump the master |
| 22:08.44 | mvanbaak | init a new repo on the public mirror |
| 22:08.47 | mvanbaak | svnsync init |
| 22:08.53 | mvanbaak | load the dump in the mirror |
| 22:09.14 | mvanbaak | set a revprop on r0 to the last commit number that was in the dump |
| 22:09.17 | mvanbaak | run svnsync |
| 22:09.19 | mvanbaak | and be happy |
| 22:09.30 | ebroad | TheDavidFactor, re 16137 |
| 22:09.55 | ebroad | if we set h_length correctly, then we no longer need sizeof(), we can continue with the current code |
| 22:10.00 | kpfleming | mvanbaak: yes, i am aware of that method |
| 22:10.12 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 22:10.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:10.12 | kpfleming | however, that would not work us, because our mirroring process changes the contents of some revisions as they mirror out |
| 22:10.20 | mvanbaak | svn propset svn:sync-last-merged-rev --revprop -r0 <last_commit> http://public-svn.box/repo |
| 22:10.32 | TheDavidFactor | ok, but I thought the consensus was to do both. |
| 22:11.02 | TheDavidFactor | that is was more consistent to use sizeof; but that h_length should be set |
| 22:11.11 | mvanbaak | kpfleming: you mean the autotags ? |
| 22:11.22 | kpfleming | the URLs in svn:externals |
| 22:11.23 | TheDavidFactor | if you don't want it, you can just close it, it won't hurt my feelings ;-) |
| 22:11.33 | mvanbaak | kpfleming: you can fix those in the svndump with svnfilter |
| 22:11.46 | kpfleming | that's much slower, in our experience |
| 22:11.52 | mvanbaak | really ? |
| 22:11.55 | kpfleming | yes |
| 22:12.04 | mvanbaak | wow. that's a suprise to me |
| 22:12.15 | ebroad | TheDavidFactor, im not sure it we use sizeof elsewhere, i would assume so given that the function seems to work elsewhere, i h_length is set, we might as well use it |
| 22:12.17 | mvanbaak | but I bet you guys tested the hell out of it |
| 22:12.57 | ebroad | TheDavidFactor, not a problem, ill close it out a duplicate and mark 16135 as ready for review |
| 22:13.11 | TheDavidFactor | k |
| 22:13.24 | TheDavidFactor | thanks |
| 22:13.24 | mvanbaak | kpfleming: sorry for the noise then. |
| 22:13.33 | kpfleming | no worries then |
| 22:14.06 | mvanbaak | we are now running svnsync to the sf.net svn setup |
| 22:14.20 | mvanbaak | use sf.net as public read-only mirror |
| 22:14.48 | kpfleming | yes, svnsync is very nice |
| 22:14.54 | mvanbaak | uhhuh |
| 22:15.02 | kpfleming | and modifying it to change the revision contents was not particularly hard either |
| 22:15.03 | mvanbaak | even copies revprop changes if you instruct it to do so |
| 22:15.16 | kpfleming | yep, we do |
| 22:15.28 | kpfleming | otherwise when we edit log messages they wouldn't mirror |
| 22:15.34 | mvanbaak | indeed ! |
| 22:16.36 | mvanbaak | we came up with a way to handle the 'multiple mergesource available' stuff in svn-automerge |
| 22:16.53 | mvanbaak | with the vanilla svnmerge and a modified version of your svn-automerge |
| 22:17.44 | ebroad | kpfleming, works like a treat |
| 22:17.49 | mvanbaak | http://covide.svn.sourceforge.net/viewvc/covide/tools/svnautomerge?revision=6862&view=markup |
| 22:17.58 | ebroad | thanks! |
| 22:18.07 | kpfleming | glad to hear it |
| 22:18.25 | kpfleming | that is some complex code in internal_ao2_callback(), for sure |
| 22:18.55 | ebroad | yes, that is why i took one look and almost choked on my coffee |
| 22:19.01 | ebroad | ;) |
| 22:19.15 | mvanbaak | we are now only using the patch for exit codes in svnmerge and the one to not need a WC in svnmerge avail |
| 22:20.06 | ebroad | M16112 |
| 22:20.08 | MuffinMan | [ready for review] [Asterisk] Channels/chan_sip/General 0016112: [patch] SIP Realtime not reading database for changes to realtime peers after initial registration reported by ajohnson (Karma: +1.75) https://issues.asterisk.org/view.php?id=16112 |
| 22:20.34 | ebroad | kpfleming, i wonder if this is an ao2 callback issue as well |
| 22:20.48 | ebroad | and my patch just short circuits it |
| 22:21.17 | mvanbaak | kpfleming: thanks again for sharing the repotools :) |
| 22:21.20 | kpfleming | which branches is that in? those changes were onl in trunk |
| 22:21.22 | kpfleming | mvanbaak: you are welcome! |
| 22:21.41 | ebroad | 1.6.2rc3 i believe |
| 22:22.00 | kpfleming | you'd need to double check, but i believe the OBJ_MULTIPLE changes only went into trunk |
| 22:22.06 | ebroad | would ao2_t_callback_data find realtime peers as well? |
| 22:22.14 | ebroad | they were trunk only |
| 22:22.22 | kpfleming | no, astobj2 has nothing to do with realtime |
| 22:23.38 | ebroad | so looking for the peer in realtime first before we go to ao2 would be the "correct" way to search for a peer? |
| 22:23.46 | kpfleming | no |
| 22:23.52 | kpfleming | because the peer may already be in memory in the container |
| 22:24.08 | ebroad | ah, ok |
| 22:24.48 | ebroad | do we keep peers in the container between registrations |
| 22:25.11 | kpfleming | if caching is enabled |
| 22:26.06 | ebroad | the reported had caching disabled, and asterisk wouldn't update the peer data bewteen registrations even though it changed in the database |
| 22:26.11 | ebroad | *reporter |
| 22:26.23 | kpfleming | then yes, that could be a refcount problem |
| 22:26.38 | kpfleming | if the previous registration was not properly torn down, the peer would still be in memory |
| 22:26.57 | ebroad | so my patch short circuited the ao2 lookup by moving the realtime lookup to the top of the find_peer() method |
| 22:27.40 | kpfleming | right, but that would kill performance if caching is enabled |
| 22:28.22 | ebroad | i guess i could check for rtcachefriends, but that would gloss over a possible bigger issue |
| 22:28.32 | kpfleming | yes, the real issue should be found |
| 22:30.10 | ebroad | hmm, looks like i need to setup mysql for realtime |
| 22:30.34 | kpfleming | any database will work |
| 22:30.43 | kpfleming | postgres, anything that you can talk to over odbc |
| 22:30.51 | ebroad | i already have mysql for cdr |
| 22:30.54 | ebroad | so why not |
| 22:31.00 | kpfleming | ahh, yeah |
| 22:31.45 | ebroad | i need to head out, kpfleming, thanks alot for the help and the advice |
| 22:31.56 | kpfleming | thanks for your help as well |
| 22:32.04 | kpfleming | it's good to see more people getting into the code |
| 22:32.23 | ebroad | np, i try, but c is not my forte...yet |
| 22:59.45 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 23:39.53 | *** join/#asterisk-dev snuff-work (n=aaa@120.19.35.213) |
| 23:39.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:45.03 | *** join/#asterisk-dev tzafrir__laptop (n=tzafrir@212.179.75.202) |
| 23:45.03 | *** mode/#asterisk-dev [+o tzafrir__laptop] by ChanServ |