| 00:00.21 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:00.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 02:55.15 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 02:55.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 03:23.31 | *** join/#asterisk-dev rpm (n=russell@S0106000c29898b7e.cg.shawcable.net) |
| 03:25.13 | rpm | In asterisk 1.6.1.9 in the subscriber sections when set to either type=friend, or type=peer the accountcode= attribute is never made available through ${ACCOUNTCODE} or ${CDR(accountcode)}. If I set the accountcode= attribute under the [general] section I can access with either method ${ACCOUNTCODE} or ${CDR(accountcode)} |
| 03:37.35 | snuff-work | mm.. well it should be available via ${CDR(accountcode)}.. using ${ACCOUNTCODE} is the 'depricated way' |
| 03:38.44 | rpm | snuff-work: it's not available either way, unless defined under the [general] section - which defeats the purpose of a per-user/per-peer accounting code |
| 03:46.11 | *** join/#asterisk-dev Corydon76-dig (i=black@c-68-52-33-133.hsd1.tn.comcast.net) |
| 03:46.12 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 03:55.57 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:55.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:33.35 | *** join/#asterisk-dev alecdavis (n=alec@202-78-149-14.cable.telstraclear.net) |
| 07:21.33 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 07:51.31 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 07:51.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:09.10 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:31.50 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 09:40.12 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 09:40.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 09:47.21 | *** join/#asterisk-dev edguy3 (n=edguy3@80.169.133.251) |
| 09:50.38 | *** join/#asterisk-dev sgimeno (n=sgimeno@80.33.64.226) |
| 10:22.54 | *** join/#asterisk-dev ghenry (n=ghenry@pdpc/supporter/monthlybyte/ghenry) |
| 10:23.00 | ghenry | Hi |
| 10:23.14 | ghenry | I've got a patch to chan_sip.c in my LDAP tracker |
| 10:23.27 | ghenry | https://issues.asterisk.org/file_download.php?file_id=23806&type=bug |
| 10:23.36 | ghenry | The contributor wants to add this to it |
| 10:24.18 | ghenry | * IMPORTANT: Anytime you add a new parameter to be updated, you must also add it to contrib/scripts/asterisk.ldap-schema and to configs/res_ldap.conf.sample as described in bugs 15156 and 15895 * |
| 10:24.31 | ghenry | What is the general view on this type of thing? |
| 10:26.50 | snuff-home | well.. generally we'd ask when it was 'up for review' |
| 10:26.55 | snuff-home | to add those |
| 10:40.49 | ghenry | ok, I'll leave it for now |
| 10:55.25 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:03.06 | atis_work | couldn't this config generation be implemented with new realtime architecture? |
| 11:03.23 | atis_work | doesn't LDAP support something to add new parameters dynamically? |
| 11:07.21 | ghenry | Yes, you can add them on the fly but you still need the base file to add them from like sql files |
| 11:07.41 | ghenry | or you could do it direct from the c code |
| 11:08.10 | atis_work | well, there's a mechanism in realtime architecture to change sql databases when necessary |
| 11:08.12 | ghenry | but that would have to be keyed from the mapped parameters in res_conf_ldap.cfg |
| 11:08.15 | atis_work | perhaps it could be done with ldap too |
| 11:08.38 | ghenry | depends also how ldap server is configured |
| 11:08.39 | atis_work | i don't really follow your thought as i'm not familiar with ldap :) |
| 11:08.56 | ghenry | some are configured to allow dynamic config/schema updates |
| 11:09.02 | ghenry | that are persistent over a restart |
| 11:09.10 | ghenry | some are driven from text files always |
| 11:09.22 | atis_work | ah, ok |
| 11:09.25 | ghenry | OpenLDAP can be set for either as can 389 direct, OpenDS etc. |
| 11:11.16 | atis_work | well, it would be really hard to make every commit that changes something in realtime structure - adds or renames a field to be completely documented in all possible engines |
| 11:12.01 | atis_work | not to mention that developer might not be familiar with all supported engines and some supposedly simple change would be wrong |
| 11:13.14 | atis_work | oh, cool, now we have spam in mantis |
| 11:13.34 | atis_work | any bugmarshall here? |
| 11:13.40 | mvanbaak | where ? |
| 11:13.44 | atis_work | festuswilla |
| 11:13.50 | atis_work | M16197 |
| 11:13.52 | MuffinMan | [acknowledged] [Asterisk] Channels/chan_sip/General 0016197: Core dump in vsnprintf / ast_rtp_get_quality / sip_hangup reported by atis (Karma: +18.00) https://issues.asterisk.org/view.php?id=16197 |
| 11:14.09 | atis_work | M16193 |
| 11:14.13 | MuffinMan | [acknowledged] [Asterisk] Applications/app_dial 0016193: Segfault with limit data L(x:y) and verbosity >= 3 reported by asgaroth (Karma: neutral) https://issues.asterisk.org/view.php?id=16193 |
| 11:14.40 | atis_work | mvanbaak: can you block him before he sends some more of that? |
| 11:14.43 | mvanbaak | I see no spam |
| 11:14.48 | mvanbaak | ;) |
| 11:14.51 | mvanbaak | it's removed |
| 11:14.57 | atis_work | Dear, |
| 11:14.57 | atis_work | I am Mr Festus Williams,nationality Zimbabwean,residing currently in uk. |
| 11:14.57 | atis_work | I want to know if can be possible for us to know each other,if that is |
| 11:15.00 | mvanbaak | no, I dont have that many privileges |
| 11:15.48 | mvanbaak | but the spam has been removed |
| 11:16.08 | atis_work | it's still on 16193 |
| 11:16.22 | atis_work | and probably some more |
| 11:18.15 | mvanbaak | uhhuh |
| 11:18.17 | mvanbaak | 17 more |
| 11:18.31 | atis_work | can you beat he's bot in speed? |
| 11:19.58 | snuff-home | mm.. which reminds me.. |
| 11:22.44 | mvanbaak | ok, they are all deleted |
| 11:23.21 | mvanbaak | atis_work: I did ! |
| 11:23.23 | mvanbaak | awesome |
| 11:23.32 | atis_work | for now |
| 11:24.10 | atis_work | hmm, i could forward him my backtraces :P |
| 11:25.30 | mvanbaak | lol |
| 11:25.57 | atis_work | i have a script called from safe_asterisk that launches gdb automatically and emails the result on every crash |
| 11:27.01 | snuff-home | mm.. now to remember my svn pass for cert.. |
| 11:29.03 | mvanbaak | atis_work: sweet |
| 11:29.51 | atis_work | it would probably make a good contribution, but i'm unsure what should be the best place for it, as it has to be separate script (in order to not make safe_asterisk wait) |
| 11:30.30 | mvanbaak | add it in the same dir as safe_asterisk is |
| 11:31.28 | atis_work | i don't like to put it in /usr/sbin - it's not that important |
| 11:32.27 | atis_work | and it would have to be added to "make install".. |
| 11:34.12 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:34.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:47.05 | atis_work | mvanbaak: feel free to comment your thoughts: 16213 |
| 11:49.27 | snuff-home | russellb: ping? |
| 12:39.25 | leifmadsen | snuff-home: probably not up yet |
| 12:39.31 | leifmadsen | 6:39am CST |
| 12:43.21 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 12:46.20 | mvanbaak | slacker |
| 13:17.02 | *** join/#asterisk-dev TheDavidFactor (n=chatzill@fw1.safedataisp.net) |
| 13:19.32 | *** join/#asterisk-dev jamesh1 (n=jhenders@xob.neospire.net) |
| 13:21.22 | *** join/#asterisk-dev kazaa_lite (n=msaleem@94-193-98-124.zone7.bethere.co.uk) |
| 13:23.18 | kazaa_lite | hi all.... since load_module() takes no parameters, so is there no way to pass parameters to Asterisk module? |
| 13:34.33 | *** join/#asterisk-dev nirs (n=Nir@87.69.148.100) |
| 13:34.35 | nirs | hello all |
| 13:34.56 | TheDavidFactor | nods in nirs direction |
| 13:35.15 | nirs | Hi TDF |
| 13:35.30 | nirs | I've encountered an interesting bug (I think) |
| 13:35.57 | nirs | was wondering if anyone experienced a situation where a channel might die, without invoking the "h" extension |
| 13:37.43 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 13:39.26 | TheDavidFactor | I have no idea |
| 13:40.07 | nirs | are you familiar with FastAGI ? |
| 13:40.19 | TheDavidFactor | no |
| 13:40.23 | nirs | bummer |
| 13:40.31 | TheDavidFactor | sorry |
| 13:49.09 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:49.10 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:58.35 | TheDavidFactor | leifmadsen, mornin' |
| 13:58.41 | leifmadsen | TheDavidFactor: morn! |
| 13:58.57 | leifmadsen | I was up way too early today... 6:20am so I could do a PRI switch over at 7am, then they cancelled it |
| 13:59.08 | mnicholson | is there a way to test if the calling thread owns a lock on a given mutex? |
| 13:59.55 | leifmadsen | o.O |
| 14:00.00 | TheDavidFactor | wow |
| 14:00.07 | leifmadsen | sorry, beyond the scope of my knowledge :) |
| 14:00.09 | TheDavidFactor | that sucks! |
| 14:00.37 | TheDavidFactor | ctooley, ping |
| 14:22.48 | *** join/#asterisk-dev pgarcia (n=root@yoda.kanatek.com) |
| 14:25.36 | pgarcia | hi there, I'm wondering if it is possible from an external module or app know whether the sip channel is currently using dtmfmode = rfc2833 or inband (considering it is configured as auto in sip.conf). |
| 14:26.26 | *** join/#asterisk-dev nirs (n=Nir@87.69.148.100) |
| 14:29.11 | TheDavidFactor | leifmadsen, I've got a simple documentation patch I submitted |
| 14:29.15 | TheDavidFactor | M16211 |
| 14:29.17 | MuffinMan | [ready for review] [Asterisk] Documentation 0016211: [patch] Event collision in ExternalIVR resolved by documenting issue reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16211 |
| 14:30.27 | TheDavidFactor | I've asked for review on the dev list and in the issue, how long should I wait before committing? I wanted to use this to practice committing on something that wouldn't cause heartache and heartburn if I messed it up. |
| 14:32.06 | leifmadsen | TheDavidFactor: I will review it shortly |
| 14:34.45 | leifmadsen | TheDavidFactor: for documentation, you don't typically need to wait very long for a review. If you're confident that it is the correct move, then you can just commit it. |
| 14:34.51 | leifmadsen | with that said, I'll look at it now! :) |
| 14:34.56 | TheDavidFactor | ok, thanks |
| 14:36.47 | leifmadsen | TheDavidFactor: so basically that is saying if you have a 'data' element, then the D tag is not DTMF |
| 14:37.05 | TheDavidFactor | exactly |
| 14:37.11 | leifmadsen | ok works for me! |
| 14:37.14 | leifmadsen | commit away young man |
| 14:37.24 | *** part/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 14:37.44 | *** join/#asterisk-dev |Cybex| (n=John@atwork-20.r-212.178.82.atwork.nl) |
| 14:44.30 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 14:44.38 | *** part/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 14:47.01 | ctooley | TheDavidFactor, Here now |
| 14:47.57 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-247.hsd1.al.comcast.net) |
| 14:47.58 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:48.56 | ctooley | TheDavidFactor, patch to docs looks good |
| 14:49.10 | *** part/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 14:49.27 | TheDavidFactor | great, thanks for reading it |
| 14:49.42 | leifmadsen | TheDavidFactor: thanks for submitting it! |
| 14:50.29 | leifmadsen | note that you'll have conflicts when merging between 1.4 and trunk because of the XML usage in the application documentation now (you may have already noticed that) |
| 14:58.10 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:58.10 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:05.37 | TheDavidFactor | actually that documentation file is text so no issues; I was looking for something easy ;-) |
| 15:15.11 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:15.11 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:17.55 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:17.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:26.54 | Deeewayne | jpeeler, ping |
| 15:27.32 | jpeeler | Deeewayne: pong |
| 15:29.28 | *** join/#asterisk-dev moy (n=moy@74.12.130.190) |
| 15:37.45 | TheDavidFactor | leifmadsen, I can't commit, is this something you can help me or do you know who could? |
| 15:37.57 | leifmadsen | TheDavidFactor: sure, what issues are you having? |
| 15:38.56 | TheDavidFactor | I've modified my ~/.subversion/servers file as Russell told me to and I've saved the two certs. I get this error when I try to commit: |
| 15:38.58 | TheDavidFactor | svn: Commit failed (details follow): |
| 15:38.59 | TheDavidFactor | svn: MKACTIVITY of '/svn/asterisk/!svn/act/d31cb298-f2ba-4474-9d13-db66b859c9f2': 403 Forbidden (http://svn.digium.com) |
| 15:39.22 | jpeeler | you must use origsvn.digium.com i believe |
| 15:39.56 | sruffell | https://origsvn.digium.com |
| 15:40.38 | TheDavidFactor | do I have to checkout from there, or how do I specify which server to commit to? I don't see anything in svn's help |
| 15:40.52 | file | checkout. |
| 15:40.58 | TheDavidFactor | ok, thanks |
| 15:42.46 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:50.20 | TheDavidFactor | ok, now I get an error trying to check out from origsvn: |
| 15:50.22 | TheDavidFactor | svn: PROPFIND of '/asterisk/trunk': 405 Method Not Allowed (https://origsvn.digium.com) |
| 15:50.32 | file | it's /svn/asterisk/trunk |
| 15:50.35 | leifmadsen | svn co https://origsvn.digium.com/svn/asterisk/trunk |
| 15:50.51 | TheDavidFactor | oh, is this documented in any of that stuff you sent me? |
| 15:51.05 | TheDavidFactor | if so I'm sorry, I will go reread it all |
| 15:51.05 | leifmadsen | probably somewhere :) |
| 15:51.39 | leifmadsen | you'll also need the other branches you're going to merge to: /svn/asterisk/branches/1.4, /svn/asterisk/branches/1.6.0, etc... |
| 16:03.25 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 16:03.25 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:13.21 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:14.30 | *** join/#asterisk-dev moy (n=moy@bas1-montreal42-1178046072.dsl.bell.ca) |
| 16:18.18 | leifmadsen | mvanbaak: thanks for taking care of all those zimbabwean notes |
| 16:32.13 | *** join/#asterisk-dev davidbrillert (n=aragon12@h216-235-8-130.host.egate.net) |
| 16:34.27 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:41.04 | jpeeler | atis_work: ping |
| 16:41.12 | atis_work | jpeeler: pong |
| 16:41.37 | atis_work | leifmadsen: what i meant is that safe_asterisk should know where the backtrace grabbing script resides, and preferrably if "make install" sets up all the paths |
| 16:41.52 | jpeeler | atis_work: i hear you have a test system available |
| 16:42.01 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:42.07 | jpeeler | i don't know what else to ask beyond that, trying to debug 16058 |
| 16:42.12 | atis_work | leifmadsen: so some kind of generation would be necessary for safe_asterisk if it's about to work out of box |
| 16:42.37 | atis_work | jpeeler: yeah, i wanted to run some tests tonight |
| 16:42.59 | atis_work | i also have lots of logs from production box with my debug patch in place |
| 16:43.07 | leifmadsen | atis_work: gotcha, well that could be done I;m sure, but I'm not the one to do it :) |
| 16:43.37 | jpeeler | atis_work: the patch i uploaded? can i get access to this system? ideally it would be best to test with DO_CRASH enabled |
| 16:44.06 | jpeeler | if it crashes where i want it to it should reveal the problem source |
| 16:47.37 | atis_work | leifmadsen: well, i yet don't have any idea how config samples are generated with correct paths.. so there are two options - either install everything in system in known places or generate safe_asterisk with source path |
| 16:47.55 | atis_work | jpeeler: what's your skype or email? |
| 16:48.09 | jpeeler | my nick at digium.com |
| 16:48.23 | leifmadsen | cool... maybe this is a discussion to be brought up on the asterisk-dev mailing list, as I'm not really going to be able to answer your questions. I can do a lot of nodding and stating that your ideas intrigue me, and that I wish to subscribe to your periodical |
| 16:48.40 | russellb | O.O |
| 16:48.41 | atis_work | jpeeler: i don't remember any crashes on testing system, but i have to grep logs to verify that |
| 16:49.05 | jpeeler | atis_work: so you've put my patch in place and enabled do_crash? that's what we need |
| 16:49.07 | atis_work | leifmadsen: heh, ok.. i'll try to find time for writing email :) |
| 16:49.15 | atis_work | jpeeler: ok, will do |
| 16:49.33 | atis_work | russellb: morning :) |
| 16:49.34 | TheDavidFactor | hey russellb, good to see you |
| 16:50.40 | atis_work | is deleting 4gb core dumps and preparing for a fresh test run |
| 16:52.37 | russellb | HI!!!!!!!!!! |
| 16:52.49 | russellb | Welcome to Tuesday. |
| 16:53.00 | TheDavidFactor | ok, I've got 1.4, 1.6.0, 1.6.1, 1.6.2 & trunk; I've read the "Branches and Branch Merging" doc three times and I'm still hazy on how I'm supposed to patch these. I think I'm supposed to patch 1.4 then merge that patch to each of the others, is that correct? |
| 16:53.03 | leifmadsen | russellb: hi! |
| 16:53.27 | russellb | TheDavidFactor: commit to 1.4, merge to trunk (merge4trunk), then merge from trunk to each 1.6.X using mergetrunk6 in the 1.6.X checkouts |
| 16:53.40 | atis_work | jpeeler: hmm, i'm not sure that testing system will help, it's not reproducable there.. i'll see if i can find something on production |
| 16:53.45 | TheDavidFactor | 'k thanks |
| 16:56.07 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:56.21 | jpeeler | atis_work: yeah reproducing is key, let me know if you do get it to crash |
| 16:58.31 | atis_work | jpeeler: i wonder why did you made patch for T38 |
| 16:58.48 | atis_work | originally i had problem with Control/Hold |
| 16:58.50 | jpeeler | ? |
| 16:59.54 | putnopvut | atis_work: you're misreading the patch |
| 16:59.57 | atis_work | jpeeler: ah, there are probably more cases than AST_CONTROL_T38_PARAMETERS |
| 16:59.59 | atis_work | yeah |
| 17:00.52 | jpeeler | yeah that's not even the important part... hopefully it will crash before due to the assert |
| 17:01.48 | atis_work | ok, i've found one Hold frame on my production today, so it's the matter of reproducing it |
| 17:15.32 | atis_work | hmm, can anyone remind me where to enable DO_CRASH |
| 17:15.56 | russellb | it's probably only available if you run configure with --enable-dev-mode |
| 17:16.00 | atis_work | ah |
| 17:18.07 | atis_work | still don't see it in menuselect |
| 17:18.23 | russellb | maybe we removed it i dunno, heh |
| 17:19.06 | atis_work | why? it sounds nice.. i sometimes even have a need for "CLI>core crash now" :p |
| 17:19.14 | jpeeler | no... under compiler flags - development |
| 17:19.37 | russellb | heh, I guess we could add that command |
| 17:19.44 | russellb | *CLI> core crash now yes I really mean it thanks |
| 17:20.16 | atis_work | with autocomplete.. |
| 17:20.33 | russellb | you get it automatically if it's part of the command :-) |
| 17:21.03 | atis_work | ah, "make dist-clean" helped |
| 17:21.24 | atis_work | woohaa, a lot of _CRASH options :) |
| 17:43.04 | *** join/#asterisk-dev Praise (n=Fat@unaffiliated/praise) |
| 17:59.47 | atis_work | heh, there seems to be some stack problem with gosub->agi->gosub->return |
| 18:00.25 | atis_work | is the stack for application GoSub() and agi command GOSUB the same? |
| 18:00.40 | Corydon76-dig | Pretty much |
| 18:04.29 | atis_work | Corydon76-dig: do you have any idea why Return from cdr_block_end jumps back to realtime context, not AGI? http://pastebin.ca/1665170 |
| 18:12.40 | Corydon76-dig | Nope |
| 18:15.01 | atis_work | uhh, ok.. i'll create an issue |
| 18:17.51 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:20.24 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 18:33.06 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:33.06 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:33.25 | Corydon76-dig | atis_work: you going to file that issue anytime soon? |
| 18:34.22 | Corydon76-dig | atis_work: I can haz patch |
| 18:36.20 | Corydon76-dig | http://asterisk.drunkcoder.com/patches/20091110__atis_work.diff.txt |
| 18:38.04 | Corydon76-dig | I can haz lunchies |
| 18:57.20 | atis_work | Corydon76-dig: u can haz bugburger: 16216 |
| 18:58.33 | TheDavidFactor | I'm working on fixing bugs in EIVR, however fixing the bugs will change current behavior. I was asked to consider them enhancements so that they wouldn't be fixed in 1.4 and cause problems for existing users. Is that an acceptable why to handle it? |
| 18:59.25 | atis_work | well, it depends.. if some things are really considered bugs, then behaviour change might be acceptable with separate config option |
| 19:00.33 | leifmadsen | TheDavidFactor: ya, anything that would cause backwards incompatibility would probably be best discussed on asterisk-dev mailing list to make sure it's accepted by the community, or that there isn't some other approach. If it must change, then it would be a trunk only change, and would need to be documented in UPGRADE.txt |
| 19:01.58 | TheDavidFactor | 'k, thx |
| 19:02.08 | snuff-home | russellb: ping? |
| 19:13.32 | atis_work | jpeeler: i can't reproduce the issue |
| 19:14.30 | jpeeler | atis_work: i was afraid you'd say that. |
| 19:14.43 | jpeeler | same version? |
| 19:14.48 | atis_work | yes |
| 19:15.30 | atis_work | jpeeler: i could put that patch on production, while keeping mine.. so i would see in log if it has not happened in few days |
| 19:16.22 | atis_work | ah, or assertion without DO_CRASH should be noticeable too |
| 19:16.26 | jpeeler | it's really only going to be useful if it crashes at my assert statement though |
| 19:17.23 | jpeeler | or actually it would be useful for your debug message to show up, but not the assert |
| 19:17.27 | jpeeler | so yes, do that |
| 19:18.12 | jpeeler | i guess i'll check back in a few days |
| 19:20.16 | atis_work | jpeeler: could you explain more? you supposedly fixed generation of control frames with datalen=0? then they won't show up in my debug message |
| 19:20.40 | jpeeler | oh yeah, just leave the assert statement |
| 19:21.18 | atis_work | jpeeler: btw, i also get my debug message for all DTMF frames, but they don't crash anything |
| 19:22.25 | jpeeler | goes to look at how dtmf frames are passed along |
| 19:23.20 | atis_work | i would have noticed crashes on DTMF without my fix |
| 19:23.37 | jpeeler | of course |
| 19:24.04 | atis_work | ah, and there are also TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (74) |
| 19:25.30 | atis_work | subclass 73-75 |
| 19:26.19 | jpeeler | looks like ast_frame_dump doesn't know about CNG frames |
| 19:26.38 | atis_work | doesn't know either |
| 19:27.51 | atis_work | actually a lot more some days |
| 19:27.57 | atis_work | 57-127 |
| 19:28.20 | atis_work | the same issue - datalen=0 |
| 19:28.29 | atis_work | not sure if that would crash or not |
| 19:32.58 | *** join/#asterisk-dev elliot98 (n=windows@unaffiliated/elliot98) |
| 19:33.04 | elliot98 | hello! |
| 19:33.47 | elliot98 | I am in the midst of embedding asterisk onto a router and want to know the feasibility of coding FXO/FXS drivers |
| 19:34.37 | jpeeler | atis_work: were you still talking about frametype 10? |
| 19:34.43 | jsmith | elliot98: It's certainly feasible... it's been done before. That begin said, I'm not sure it would qualify as "easy" |
| 19:35.04 | atis_work | jpeeler: yes, frametype 10, subclass range 57-127 |
| 19:35.36 | elliot98 | well, I am trying to find out if it is realistic to embed linux/asterisk on a simple ata with and FXO and FXS port |
| 19:36.00 | atis_work | well, as i recall Linksys did something like that.. |
| 19:36.08 | elliot98 | I don't think the embedding should be that difficult, since Linux has been ported to device chipsets before |
| 19:36.29 | atis_work | but it was only few applications and old old asterisk |
| 19:36.46 | elliot98 | the real challenge would be for Linux and asterisk to recognize and be able to use the phone ports |
| 19:38.18 | elliot98 | so it would require a device driver, such as dahdi, and then another layer in asterisk |
| 19:38.23 | elliot98 | as far as I see it |
| 19:41.26 | *** part/#asterisk-dev rpm (n=russell@S0106000c29898b7e.cg.shawcable.net) |
| 19:43.29 | *** join/#asterisk-dev davidbrillert (n=aragon12@h216-235-8-130.host.egate.net) |
| 19:54.31 | *** join/#asterisk-dev alecdavis (n=alec@202.36.76.21) |
| 19:58.49 | russellb | snuff-home: email me with the error message you get and i'll try to resolve it asap |
| 20:01.36 | *** join/#asterisk-dev errotan (n=errotan@a1621.adsl.pool.eol.hu) |
| 20:40.15 | *** join/#asterisk-dev Gugge (n=gugge@vlan2.dlxhosting.dk) |
| 20:49.48 | elliot98 | do queues sometimes overload a system? Some queues on ringall give a busy status for agents sometimes |
| 20:51.31 | ctooley | TheDavidFactor, I personally don't think we should change any of the messaging in release versions. The flaws in messaging have been there for a long time. A note in the documentation should be made though. |
| 20:51.54 | ctooley | I agree with fixing them, and updating things to reflex the changes, but only in trunk. |
| 20:54.40 | leifmadsen | agrees with ctooley |
| 20:56.18 | seanbright | russellb: what is the big spike between may 09 and sep 09? |
| 20:56.34 | russellb | moving addons into trunk |
| 20:56.38 | seanbright | ahh |
| 20:59.29 | TheDavidFactor | leifmadsen, as I said in my email to -dev I don't really care where it gets fixed as long as it does. And actually, fixing trunk only is easier for me because then I don't have to go through the merge process. However, from an issue standpoint how should I create/update issues? Should these changes to EIVR be identified as features requests? |
| 21:00.28 | leifmadsen | Hmmm.... I guess ya, just call them features |
| 21:00.49 | leifmadsen | it doesn't *really* matter what you classify them as since you'll be the one doing the fixing |
| 21:01.30 | TheDavidFactor | would it be best to modify the documentation for EIVR to reflect everything that's broken and then go from there on fixing them? Or can I leave the documentation as is and just start fixing things in trunk? |
| 21:01.53 | leifmadsen | I'd make the documentation fixes as you make the bug fixes so everything stays in sync |
| 21:02.03 | leifmadsen | (assuming the documentation is related to the bug fixes) |
| 21:02.14 | TheDavidFactor | well, the documentation is already "fixed" it says EIVR does stuff it doesn't do |
| 21:02.22 | leifmadsen | ah gotcha |
| 21:02.50 | ctooley | TheDavidFactor, anyone currently using it is likely already aware of the issues |
| 21:03.01 | leifmadsen | my opinion is that in releases the documentation should reflect what the code actually does, and if you want to add the "features" back into EIVR and keep the documentation as-is, then I'd do that |
| 21:03.48 | leifmadsen | IMHO, documentation should reflect code in branches, and trunk is fair game to add the "features" that the documentation discusses |
| 21:04.22 | TheDavidFactor | ok, then I'll modify the documentation to note the "lack" of features. After which I will start fixing bugs and update the documentation with each bug fix. |
| 21:10.31 | *** join/#asterisk-dev tzafrir (n=tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 21:10.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:24.33 | TheDavidFactor | M16220 |
| 21:24.35 | MuffinMan | [assigned] [Asterisk] Documentation 0016220: [patch] Fix ExternalIVR Documentation in 1.4 reported by thedavidfactor (Karma: neutral) https://issues.asterisk.org/view.php?id=16220 |
| 21:24.46 | TheDavidFactor | leifmadsen, how is this? |
| 21:25.07 | leifmadsen | czeching |
| 21:27.05 | leifmadsen | note added |
| 21:37.41 | Corydon76-dig | Czech king |
| 21:47.32 | leifmadsen | TheDavidFactor: don't forget to merge into the 1.6.x branches as well if applicable. I always forget how to do the merging when applicable to everything but trunk |
| 21:48.12 | leifmadsen | I think you do a block to trunk, then just commit individually to the 1.6.x branches, but I totally forget :) |
| 21:48.58 | TheDavidFactor | well, I went back and checked and the documentation is different between the versions. I think it makes more sense to update them separately. |
| 21:49.10 | leifmadsen | ok coolio |
| 21:49.21 | leifmadsen | don't worry about creating separate issues on the bug tracker for each one |
| 21:49.30 | leifmadsen | just reference the issue you closed before |
| 21:49.45 | TheDavidFactor | 'k |
| 21:54.14 | TheDavidFactor | sorry to bounce around like a baby on caffeine, but since it currently doesn't work in trunk and I'm going to add it back in to both the code and the documentation, I believe it does' make sense to do a full merge, which I will do. |
| 21:56.43 | leifmadsen | TheDavidFactor: works for me |
| 22:16.14 | Corydon76-dig | TheDavidFactor: In the future, when merging changes between branches, please use the 'mergetrunk6' tool in the repotools repo |
| 22:18.27 | Corydon76-dig | TheDavidFactor: or recordtrunk6, if you're going to do the merge manually |
| 22:19.16 | Corydon76-dig | (from 1.4 to trunk, it's merge4trunk and record4trunk, respectively) |
| 22:23.20 | TheDavidFactor | Corydon76-dig, that's what I used, what did I do wrong? |
| 22:26.20 | leifmadsen | commit to 1.4, then merge4trunk <revision_commited_in_1.4> ? |
| 22:28.04 | TheDavidFactor | yes, and then mergetrunk6 on each of the three 1.6.x branches |
| 22:35.05 | Corydon76-dig | TheDavidFactor: on the documentation, when I updated, I only saw the file changed, not the properties, which signalled that you hadn't used the tools |
| 22:35.36 | TheDavidFactor | oh, I know what happened. |
| 22:37.17 | TheDavidFactor | When I ran merge4trunk and then attempted to commit it failed. Some where in the process of trying to figure out what was wrong I reverted the directory. |
| 22:37.38 | TheDavidFactor | I'll be much more careful about that, and I'm sorry for messing it up this time. |
| 22:38.15 | Corydon76-dig | Yeah, if your revision is not the latest, your commit will fail |
| 22:38.38 | Corydon76-dig | You probably forgot to 'svn update' prior to the mergetrunk6 |
| 22:38.55 | TheDavidFactor | that wasn't the problem, the problem was there were changes in the common parts of the unified diff between 1.4 and trunk |
| 22:39.04 | Corydon76-dig | Ah |
| 22:39.19 | TheDavidFactor | but I didn't realize that until after I had reverted |
| 22:39.29 | Corydon76-dig | So you resolve it by editing the file, then run 'svn resolved filename' |
| 22:39.44 | TheDavidFactor | ok, thank you |
| 22:40.43 | kpfleming | or if you are using emacs in debian sid or ubuntu karmic, it will auto-resolve for you |
| 22:40.58 | TheDavidFactor | vim on centos |
| 22:46.16 | *** join/#asterisk-dev kazaa_lite (n=msaleem@94-193-98-124.zone7.bethere.co.uk) |
| 22:57.43 | *** join/#asterisk-dev ecrane (n=ecrane@o1-69-19-166-10.static.o1.com) |
| 23:12.41 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 23:12.42 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:48.17 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:48.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |