| 00:12.08 | *** join/#asterisk-dev RoyK (n=roy@ip-27-3-149-91.dialup.ice.no) |
| 00:15.17 | *** join/#asterisk-dev anthm (n=anthm@68-31-2-14.area4.spcsdns.net) |
| 00:15.17 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 00:31.55 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 00:43.57 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:43.57 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:47.02 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 00:59.47 | *** join/#asterisk-dev jmesquita (n=jmesquit@200.170.114.149) |
| 01:20.54 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 01:25.52 | *** join/#asterisk-dev joshaidan (n=brianj@S0106001c1023e838.tb.shawcable.net) |
| 01:37.59 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 02:10.38 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 02:44.25 | *** join/#asterisk-dev philipp64 (n=chatzill@pool-71-112-43-66.sttlwa.dsl-w.verizon.net) |
| 02:54.21 | *** join/#asterisk-dev fujin (n=aj@unaffiliated/fujin) |
| 02:54.28 | fujin | any Queue-familiar devs around? |
| 03:04.49 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 03:35.28 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 03:53.38 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:53.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:15.51 | *** join/#asterisk-dev ZX81 (n=ZX81@202.20.97.211) |
| 04:17.13 | *** part/#asterisk-dev fujin (n=aj@unaffiliated/fujin) |
| 04:27.26 | *** join/#asterisk-dev joshaidan (n=brianj@S0106001c1023e838.tb.shawcable.net) |
| 04:51.48 | Juggie | russellb, you are permitted to sleep! |
| 04:51.57 | russellb | Juggie: orly? |
| 04:52.14 | Juggie | ya you know its late, it must be sleep time. |
| 04:52.23 | Juggie | i figured out the makefile crap a bit. |
| 04:52.39 | Juggie | i think i have a suitible solution to the problem, its just a oneliner. |
| 04:52.56 | Juggie | but i am 99% certain its correct, but not certain enough to commit it :) |
| 04:53.40 | *** join/#asterisk-dev suahmed (n=Administ@69.88.13.17) |
| 04:57.32 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 05:01.49 | russellb | Juggie: that's cool, if you post it, i'll take a look |
| 05:01.57 | russellb | you probably already did |
| 05:01.59 | russellb | i'll look tomorrow |
| 05:02.01 | russellb | for now, i sleep |
| 05:09.22 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 06:32.30 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.or.comcast.net) |
| 06:41.57 | *** join/#asterisk-dev oej (n=olle@114.62-97-206.bkkb.no) |
| 06:41.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:45.50 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 07:46.29 | *** join/#asterisk-dev steliosk (n=Stelios@79.131.65.61) |
| 07:52.34 | awk | hmm, anyone have some patch for 1.4.17 for the issue with IAX and running out of IO threads? |
| 07:54.54 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:10.47 | *** join/#asterisk-dev oej (n=olle@62.97.243.70) |
| 09:10.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:14.47 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 09:29.51 | *** join/#asterisk-dev kpfleming (n=kpflemin@216.207.245.1) |
| 09:29.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 09:30.02 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 09:30.02 | *** join/#asterisk-dev Deeewayne (n=dwayne@216.207.245.1) |
| 09:30.09 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 09:53.56 | *** join/#asterisk-dev simbol76ss (n=simbol@213-140-19-115.fastres.net) |
| 10:00.43 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 10:07.15 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-281704.home.otenet.gr) |
| 10:08.36 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 10:26.19 | *** join/#asterisk-dev RoyK (n=roy@box36.fortel.no) |
| 10:47.10 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 11:44.14 | *** join/#asterisk-dev oej (n=olle@62.97.243.70) |
| 11:44.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:55.38 | *** join/#asterisk-dev eusbreeves (n=chatzill@64.136.92.71) |
| 12:03.54 | jmls | heh. lol |
| 12:03.56 | jmls | http://www.theregister.co.uk/2008/03/13/dont_call_us/ |
| 12:09.49 | snuff-home | mm nice |
| 12:13.16 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:27.59 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:27.59 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:35.04 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 13:05.51 | *** join/#asterisk-dev jsmith (n=jsmith@216.207.245.1) |
| 13:05.51 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:07.20 | *** join/#asterisk-dev jeffg (i=RoENeeQp@pdpc/supporter/active/jeffg) |
| 13:12.42 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 13:14.39 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 14:02.07 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:02.07 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:09.47 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.227.137) |
| 14:42.25 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 14:52.34 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 14:58.26 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:58.26 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 15:06.08 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 15:17.50 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 15:17.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:25.15 | *** join/#asterisk-dev mitcheloc (n=mitchelo@216.207.245.1) |
| 15:26.27 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:26.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:28.24 | *** join/#asterisk-dev andrebarbosa (n=andrebar@212.13.49.67) |
| 15:38.00 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 15:38.00 | *** join/#asterisk-dev kannan (n=kann@123.201.60.116) |
| 15:52.44 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 15:52.44 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 15:53.05 | bkruse | mvanbaak: Major scrollback, but that was from actual testing with the prefix= in http.conf |
| 15:57.14 | atis_work | putnopvut: ping |
| 15:57.37 | mvanbaak | bkruse: ah. well, it's fixed anywayz |
| 15:57.38 | mvanbaak | :) |
| 15:57.51 | putnopvut | atis_work: pong. What's up? |
| 15:58.23 | atis_work | putnopvut: what do you tink about changing app_queue so that calls counter for member is updated upon answering instead of hangup |
| 15:58.54 | bkruse | mvanbaak: yep :] |
| 15:59.35 | putnopvut | atis_work: hmmmm...that makes sense to me. I'm trying to think of a situation where that might be problematic. |
| 16:00.20 | atis_work | well, i have some realtime changes, where call counter is stored in realtime.. so if restart happens call won't be counted.. but for now i'm just having troubles synchronizing it with my web frontend |
| 16:00.47 | atis_work | btw, i think i would want to update lastcall twice - upon answer and hangup |
| 16:01.05 | atis_work | just want to know how possible is that such changes would go into mainstream |
| 16:01.56 | putnopvut | I don't think two updates to lastcall really makes a lot of sense. |
| 16:02.33 | atis_work | well, that would indicate when answer has happened - so duration of call would more simple to show |
| 16:03.14 | atis_work | i mean - duration of agent connected |
| 16:03.21 | atis_work | oh, but with my changes that would be possible to achieve from dialplan.. ok, lets forget that :0 |
| 16:03.23 | atis_work | :) |
| 16:03.54 | atis_work | so, about call counter.. do you see any problems? |
| 16:04.18 | putnopvut | No, not yet. |
| 16:06.04 | putnopvut | The one thing that would make things a bit weird is the fact that queues have a statistic called "calls completed" |
| 16:06.44 | putnopvut | And if we updated a member's call count when he answers, then the numbers of calls completed in the queue would potentially not be the sum of the number of calls members have answered. |
| 16:12.01 | atis_work | well, that could/should be updated there too |
| 16:13.45 | atis_work | i just wonder what's callscompletedinsl that's updated at same time |
| 16:16.54 | atis_work | is ast_bridge_call blocking? i have to update counter before it? |
| 16:19.47 | putnopvut | It is a blocking call. |
| 16:19.53 | putnopvut | When it returns, the call has terminated. |
| 16:20.11 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 16:20.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:20.23 | russellb | atis_work: chanspy fix work? |
| 16:21.02 | atis_work | russellb: haven't tried yet. i just got testing machine freed so i'm gonna launch tests soon |
| 16:21.23 | russellb | ok :) |
| 16:21.38 | atis_work | russellb: btw you could fix the mantis-svnbot thingy, because i found out that you commited patch only mid-day today, when scrolled back irc log :) |
| 16:21.55 | russellb | eh? |
| 16:22.14 | atis_work | i don't get notifications from mantis when issue is closed by svnbot |
| 16:22.20 | jmls | guys, should I be worried with this ... |
| 16:22.21 | jmls | <PROTECTED> |
| 16:22.30 | russellb | jmls: nah |
| 16:22.37 | russellb | unless it spews the messages |
| 16:22.40 | atis_work | M11608 |
| 16:22.42 | MuffinMan | [assigned] [Asterisk] . I did not set the category correctly. 0011608: Mantis notification not sent when issue is commented and/or closed by SVNbot reported by atis http://bugs.digium.com/view.php?id=11608 |
| 16:22.55 | Juggie | i was just looking @ that bug last night |
| 16:23.04 | Juggie | was going to ask on it what was going on with it |
| 16:23.10 | russellb | nothing? |
| 16:23.11 | russellb | :) |
| 16:23.12 | jmls | russellb: thanks. What causes it ? |
| 16:23.26 | russellb | jmls: probably happens on channel hangup when a file is being played |
| 16:23.28 | russellb | nothing to worry about |
| 16:23.34 | Juggie | russellb, i went through some old bugs & bitched @ ppl last night when i could not sleep. |
| 16:23.41 | russellb | heh |
| 16:23.52 | putnopvut | Juggie: Was I at the tail end of any of the bitching? |
| 16:23.54 | jmls | cool. Could we change it to not a warning then ? Warnings, well, give me shivers .. :) |
| 16:24.00 | Juggie | putnopvut, i dont think so :) |
| 16:24.21 | russellb | if i was, i don't care! |
| 16:24.38 | Juggie | hahaha |
| 16:24.45 | file | zombies. |
| 16:26.04 | *** join/#asterisk-dev ctooley_ (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 16:31.00 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 16:50.32 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:55.11 | atis_work | putnopvut: have you looked at my last comment on 12127? |
| 16:55.25 | putnopvut | Not yet sorry. |
| 16:55.52 | atis_work | well, i could write that patch, i just wanted to know about re-iterating queues and members within update_status |
| 16:55.57 | atis_work | is that still necessary |
| 16:56.08 | putnopvut | hold on just a sec...I'm on the phone... |
| 16:56.26 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 16:56.26 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 16:56.34 | atis_work | heh, somebody is actually using phone for speaking :) |
| 16:56.48 | putnopvut | atis_work: yes, it is necessary. |
| 16:57.01 | putnopvut | Because an interface could be used in more than one queue. |
| 16:57.20 | putnopvut | So you would need to iterate through all members of all queues to be certain that you update the status for the correct members. |
| 16:59.21 | atis_work | putnopvut: but you just used member->status = ... in your patch, and handle_statechange is already iterating all the queues |
| 16:59.52 | atis_work | i'm referring to comment /* Since a reload could have taken place, we have to traverse the list to ... in update_status |
| 16:59.56 | putnopvut | Then I made a mistake in the patch. |
| 17:04.03 | atis_work | russellb: http://www.pastebin.org/23498 on SVN-branch-1.4-r108288M |
| 17:14.51 | atis_work | putnopvut: so in that case fetching new status would have to go most way of handle_statechange |
| 17:15.04 | atis_work | first check in list of interfaces, then traverse all queues.. |
| 17:28.34 | atis_work | huh, maybe there's some way how to poke devicestate thread, so that it raises statechange event for current state |
| 17:35.25 | atis_work | russellb: another one http://www.pastebin.org/23500 |
| 17:36.04 | atis_work | i already double-checked that i got your changes |
| 17:38.03 | atis_work | russellb: maybe i should check that one-minute-crash and try to reproduce? |
| 17:42.22 | atis_work | ping |
| 17:50.48 | atis_work | russellb: and another one http://www.pastebin.org/23504 |
| 17:50.58 | atis_work | seems that it doesn't help |
| 17:51.15 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 18:01.41 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 18:06.31 | tzafrir | russellb, once again I wonder as to when there's a planned Zaptel release . |
| 18:07.00 | russellb | 2 to 3 weeks |
| 18:15.41 | tzafrir | Would it be a problem to make a release sooner? (e.g: next week, end of it) |
| 18:16.13 | tzafrir | or is that not a good timing for the other work-in-progress branches (voicebus and such) |
| 18:18.42 | russellb | tzafrir: i don't know, i don't coordinate those anymore |
| 18:18.47 | russellb | tzafrir: talk to sruffell, i guess |
| 18:19.39 | sruffell | tzafrir: End of next week might be possible. I'm trying to get a candidate ready for testing tomorrow...but there won't be some cleanup in it. |
| 18:20.37 | tzafrir | russellb, who does coordinate? |
| 18:21.00 | russellb | sruffell and the rest of the hardware / driver guys |
| 18:21.03 | russellb | which does not include me :) |
| 18:21.13 | russellb | most of which don't hang out here |
| 18:21.46 | russellb | so, sruffell is your man :) |
| 18:22.30 | Juggie | heh |
| 18:24.14 | sruffell | although I will say...I only notice this window when someone types my name....otherwise I don't keep up. |
| 18:24.17 | tzafrir | sruffell, seeing that you represent everyone, do you know what's up with the battery_status branch of kpfleming ? |
| 18:24.23 | tzafrir | :-) |
| 18:24.40 | sruffell | It's been merged into the voicebus branch already and is slotted for inclusion in 1.4.10. |
| 18:24.51 | sruffell | I'm not aware of any additional outstanding issues. |
| 18:25.15 | sruffell | with it...but I'll admit I haven't combed through http://bugs.digium.com/view.php?id=12160 |
| 18:26.05 | sruffell | I merged it into the voicebus branch to sweep in beta testers to test it as well.... |
| 18:26.06 | tzafrir | sruffell, Oron posted about it to the -dev list |
| 18:26.15 | sruffell | hmm....checking. |
| 18:27.10 | tzafrir | one question is: where do we make the change? zaptel? asterisk? both? (none?) |
| 18:28.55 | sruffell | Can I postpone discussing that until tomorrow? I'll need to think more carefully about it when I look at issue 12160. |
| 18:29.09 | sruffell | ...and I'm right in the middle of something else. |
| 18:30.43 | tzafrir | sruffell, sure. But this needs to be decided before 1.4.10 . If this patch is decided against, we'll have to re-add some ugly code back into our driver |
| 18:31.11 | sruffell | ok....I'll hit you up if not tomorrow, then early next week. |
| 18:31.43 | kpfleming | what is 12160 about? |
| 18:32.06 | sruffell | about alarm generation when channels are opened. |
| 18:36.46 | tzafrir | asterisk starts and there is a channel already in alarm . What should happen? |
| 18:37.15 | tzafrir | How can Asterisk know about this? |
| 18:38.07 | tzafrir | http://lists.digium.com/pipermail/asterisk-dev/2008-March/032193.html |
| 18:48.54 | kpfleming | i thought we already decided on a simple solution in that thread on -dev with Oron |
| 18:51.39 | jmls | wow. 263 open issues. Someone's been busy ... |
| 18:51.45 | tzafrir | kpfleming, so move that bug to asterisk, then? |
| 18:51.56 | tzafrir | there's a patch there |
| 18:52.04 | kpfleming | let me look |
| 18:52.57 | kpfleming | yes, this is Asterisk's responsibility to deal with, not Zaptel's |
| 18:53.54 | kpfleming | other than a minor code formatting issue {if( -> if (} I'm fine with Oron's second patch in that issue |
| 18:54.23 | kpfleming | it should go into Asterisk trunk and 1.6.0 |
| 19:03.31 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 19:09.38 | *** join/#asterisk-dev miguel3239 (n=elguero@ns1.nashuacs.com) |
| 19:24.43 | Juggie | jmls, thats low or high? |
| 19:41.32 | snuff-home | 263 issues for *.. considering it has sat at 300 odd.. its not bad ;) |
| 19:42.17 | Qwell | snuff-home: it was up near 400 at one point... |
| 19:42.27 | Qwell | 400 total, that is |
| 19:43.01 | Juggie | there are lots of hanging issues there |
| 19:44.09 | putnopvut | I'm bouts to close one... |
| 19:44.29 | russellb | i think we were up near 500 a year ago |
| 19:45.19 | Qwell | was it 500? |
| 19:45.31 | Qwell | I guess it was over 400 ...hmm |
| 19:45.37 | snuff-home | think i remember seein 400 last year when i 1st started checking/reporting bugs |
| 19:45.39 | Qwell | so yeah |
| 19:45.41 | Juggie | i think you should make fun of the person with the oldest assigned bugg. |
| 19:45.44 | Juggie | *bug |
| 19:45.46 | Juggie | :) |
| 19:46.08 | Qwell | Juggie: that'd be kpfleming :p |
| 19:46.11 | Qwell | M3450 |
| 19:46.14 | MuffinMan | [assigned] [Asterisk] Core/NewFeature 0003450: [patch] adds support for SERVice maintenance messages reported by cmaj http://bugs.digium.com/view.php?id=3450 |
| 19:46.21 | putnopvut | Qwell: it was mattf until like a week ago on that issue though. |
| 19:46.30 | Juggie | :) |
| 19:46.53 | Juggie | oldest update an open issue goes to russell :) |
| 19:56.52 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 20:02.56 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 20:06.28 | kpfleming | yeah, but i started looking over that bug yesterday and thinking about how to handle it... should be pretty straightforward, although the existing patches won't be usable |
| 20:21.53 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 20:34.41 | jameswf | jsmith-teaching: what was the company that is selling IAX phones.... |
| 20:35.59 | tzafrir | atcom? |
| 20:36.24 | jameswf | no some german company (not snom) |
| 20:36.58 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:54.16 | *** join/#asterisk-dev mikecx (n=mikecx@pool-71-124-48-201.chi01.dsl-w.verizon.net) |
| 20:54.31 | mikecx | Is AGI the right thing to use for trying to get the status of all the channels? I'm writing a plugin for lcd4linux and trying to get zap status but AGI seems to halt for entry every time |
| 20:55.18 | *** join/#asterisk-dev oej (n=olle@114.62-97-206.bkkb.no) |
| 20:55.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:55.39 | atis_work | russellb: ping |
| 20:56.17 | atis_work | i think i suspect what could be problematic about chanspy and datastores |
| 20:56.27 | atis_work | queue, local channels and masquarade |
| 20:56.51 | atis_work | i analyzed that one-minute-crash log, and here's basic flow of call: http://www.pastebin.org/23532 |
| 21:09.34 | russellb | atis_work: i think you're right ... specifically, it's masquerades |
| 21:09.38 | russellb | i know what i want to do next |
| 21:09.43 | russellb | thanks for the debugging yet again |
| 21:09.54 | atis_work | good :) |
| 21:10.06 | atis_work | let's hope that would fix also second backtrace |
| 21:10.13 | atis_work | i got two different |
| 21:13.09 | atis_work | russellb: while on this - can you also make sure that answer-macro of dial command works correctly with chanspy/datastore magic |
| 21:13.20 | atis_work | that could be non-common too :) |
| 21:14.10 | jsmith-teaching | jameswf: allnet.de |
| 21:15.43 | russellb | atis_work: i'll just do stuff, and then if it breaks, you tell me :) |
| 21:15.46 | russellb | that's how this works :-p |
| 21:15.51 | atis_work | :D |
| 21:16.39 | atis_work | ok, when you fix it - please drop some comment in issue, because i still don't receive emails on commits |
| 21:17.04 | atis_work | i'll be going sleep within some 3 hours, so i could start tests before that |
| 21:17.55 | russellb | k, i'm going to try to do it now |
| 21:18.00 | russellb | it's not going to be a tiny patch, though ... |
| 21:18.11 | atis_work | well, maybe 4 hours.. i'ts never certain :) |
| 21:18.19 | mikecx | someone help with some php-ami stuff? |
| 21:18.33 | atis_work | well, you're my hope :) |
| 21:36.10 | *** join/#asterisk-dev atis_home (n=chatzill@193.238.213.215) |
| 21:38.21 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 21:38.21 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:38.22 | russellb | atis_home: ok, it's in 1.4 |
| 21:38.24 | russellb | A108583 |
| 21:38.41 | atis_home | good, going to test it |
| 21:40.13 | russellb | putnopvut: ping ... |
| 21:40.13 | putnopvut | russellb: pong |
| 21:40.29 | russellb | putnopvut: trunk doesn't compile for me... |
| 21:40.43 | russellb | manager.c: In function ?manager_modulecheck?: |
| 21:40.43 | russellb | manager.c:2637: error: invalid operands to binary - |
| 21:40.43 | russellb | manager.c:2644: error: invalid operands to binary - |
| 21:40.43 | putnopvut | oh you're f'ing kidding me. |
| 21:41.17 | putnopvut | Today is not a good day... |
| 21:41.32 | MuffinMan | [108583] Committed by russell on 2008-03-13 17:38:16: Fix another issue that was causing crashes in chanspy. This introduces a new |
| 21:44.10 | atis_home | putnopvut: oh, you're still around :) how about committing that update_dial_status for 1.4.19 - generally it's safe and offers good performance increase. my production is already working for ~3 days with that, so we could have some time to develop proper patch |
| 21:45.17 | putnopvut | atis_home: As soon as I get trunk compiling, I'll focus on that issue. |
| 21:45.24 | atis_home | sure :) |
| 21:47.37 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 21:48.45 | putnopvut | Got it... |
| 21:48.51 | putnopvut | Now, on to the queue stuff. |
| 21:50.38 | jpeeler | is dnsmgr turned on/off in sip.conf via the srvlookup setting? |
| 21:50.57 | russellb | jpeeler: it's configured in dnsmgr.conf |
| 21:51.29 | atis_home | well, i was trying to describe situation previously here. so, the update_status should do pretty much the same as handle_statechange does - search where interface is used, and then go trough all the queues |
| 21:51.31 | mvanbaak | wow, public svn server is SLOW |
| 21:51.34 | jpeeler | so if srvlookup=no, then dnsmgr wouldn't even be used then? |
| 21:52.41 | atis_home | putnopvut: i just don't see clearly how i could create reusable function for handle_statechange and dialstatus-fail |
| 21:53.09 | putnopvut | atis_home: I think I have an idea of how to do this... |
| 21:53.40 | atis_home | so, you have time for this? |
| 21:53.52 | putnopvut | Oh yeah. I'm devoting my full attention to it right now. |
| 21:54.24 | mvanbaak | wow |
| 21:54.40 | mvanbaak | svn up on a tree that is a week old already takes 13 minutes |
| 21:55.34 | mvanbaak | meh, 14 minutes total |
| 21:55.51 | atis_home | mvanbaak: and compiling? :p |
| 21:55.59 | mvanbaak | that should go fast |
| 21:56.07 | mvanbaak | box is a dual 3ghz |
| 21:56.24 | mvanbaak | asterisk:/usr/local/src/asterisk# time make |
| 21:56.31 | mvanbaak | real 0m0.123s |
| 21:56.33 | mvanbaak | gheh |
| 21:56.52 | mvanbaak | need to run configure ;) |
| 21:57.47 | atis_home | putnopvut: what's your idea? |
| 21:57.55 | atis_home | i got mine too |
| 21:59.51 | putnopvut | I liked your idea of taking the update_status function and making handle_statechange call it. |
| 22:00.08 | putnopvut | So update_status will now just take an interface string, and a status int. |
| 22:00.30 | putnopvut | Oh, crap... |
| 22:00.34 | putnopvut | Locking could be an issue. |
| 22:00.39 | putnopvut | I may need to rethink this. |
| 22:00.44 | atis_home | well, yes.. |
| 22:01.04 | atis_home | it should lock interfaces, and then queues |
| 22:02.11 | putnopvut | The problem with that is that the precedent has been set to lock queues and then interfaces. |
| 22:02.22 | putnopvut | There's a comment at the top of the file explaining the recommended lock order. |
| 22:02.28 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 22:02.39 | atis_home | if you could just take device name and status out of statechange structure, and pass it to new function, the same way as update_status does |
| 22:03.01 | atis_home | no, but interfaces and queues are two separate arrays |
| 22:03.04 | atis_home | *lists |
| 22:03.24 | atis_home | first interfaces get locked, then unlocked, and then - queues |
| 22:05.28 | putnopvut | Right. |
| 22:05.41 | putnopvut | I have a patch written if you'd like to take a look. |
| 22:05.53 | atis_home | sure |
| 22:06.29 | putnopvut | I'm getting the pastebin set up... |
| 22:06.50 | putnopvut | http://pastebin.ca/941737 |
| 22:07.31 | putnopvut | There's one locking issue I know of with the patch right now. |
| 22:07.59 | *** join/#asterisk-dev jeffg (i=zjhyt3Ah@pdpc/supporter/active/jeffg) |
| 22:08.51 | putnopvut | If ring_entry is called with the queue locked and ast_request fails, then the queue list lock will be locked. |
| 22:09.00 | atis_home | putnopvut: almost as i imagined |
| 22:09.04 | putnopvut | This violates the locking order described at the top of the file. |
| 22:09.08 | mvanbaak | hhmm, is trunk known to crash on start ? |
| 22:09.16 | putnopvut | atis_home: I haven't test compiled it yet, so it may not be perfect. |
| 22:09.23 | putnopvut | mvanbaak: um...no. |
| 22:09.26 | atis_home | i just wonder - isn't interfaces iterations necessary in update_status |
| 22:09.31 | mvanbaak | ah |
| 22:09.34 | mvanbaak | it's addons |
| 22:09.48 | mvanbaak | current addons makes * die |
| 22:09.49 | putnopvut | atis_home: Let's see... |
| 22:09.51 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 22:09.56 | mvanbaak | just updated both asterisk and addons |
| 22:10.07 | mvanbaak | asterisk: symbol lookup error: /usr/lib/asterisk/modules/cdr_addon_mysql.so: undefined symbol: ast_config_load |
| 22:10.24 | putnopvut | atis_home: no, it isn't. |
| 22:10.27 | mvanbaak | and yes, I cleaned /usr/lib/asterisk/modules before recompiling |
| 22:10.56 | putnopvut | The interface list is traversed in handle_statechange because it is called when the device state of any device changes, even those that are not queue members. |
| 22:11.07 | atis_home | ok |
| 22:11.11 | putnopvut | But update status is used to update the status of a device which we know is a queue member. |
| 22:11.13 | atis_home | that's clear now :) |
| 22:11.15 | putnopvut | Cool. |
| 22:11.48 | atis_home | so, will you get that locking order solved? |
| 22:12.53 | atis_home | cool, i can actually read diff vertically on 1200px screen :D |
| 22:13.06 | *** join/#asterisk-dev philipp64 (n=chatzill@131.107.152.19) |
| 22:13.25 | mvanbaak | ok, both cdr_addon_mysql as chan_ooh323 are borked |
| 22:13.42 | mvanbaak | s/as/and/ |
| 22:13.56 | mvanbaak | both same error |
| 22:14.00 | putnopvut | atis_home: yeah, I'll work on getting the locking issue solved. |
| 22:14.05 | putnopvut | It shouldn't take long. |
| 22:16.54 | putnopvut | atis_home: ah ha! I know how to fix it! |
| 22:17.08 | putnopvut | Wait, nevermind... crap. |
| 22:17.11 | atis_home | cool |
| 22:17.15 | putnopvut | I get too far ahead of myself. |
| 22:17.26 | mvanbaak | I'm too tired to fix addons |
| 22:17.58 | mvanbaak | should I post a bug or just go to bed and fix it once I'm having my first coffee again ? |
| 22:19.51 | putnopvut | atis_home: the thing that makes this difficult is that ring_entry is only sometimes called with the queue locked. |
| 22:20.08 | putnopvut | I wonder what the consequences would be if we always called it with the queue locked. |
| 22:20.48 | atis_home | i have no idea, i don't understand yet how consecutive locks work |
| 22:21.10 | snuff-work | atis_home: its not locking the same thing.. |
| 22:21.41 | atis_home | snuff-work: what same thing? |
| 22:22.32 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 22:31.33 | russellb | jpeeler: ping |
| 22:31.37 | russellb | jpeeler: CHANGES plz |
| 22:31.55 | jpeeler | dope |
| 22:32.58 | putnopvut | atis_home: I think I have the lock problem resolved. I'm going to test compile and upload the patch to the issue for testing. |
| 22:34.06 | jpeeler | russellb: what should i put it under? |
| 22:34.19 | russellb | Application Changes or something |
| 22:34.22 | russellb | new section .. |
| 22:34.28 | russellb | or Dialplan Applications |
| 22:34.57 | atis_home | putnopvut: ok, i could run automated tests tonight on it, and ask our tester for functionality tests tomorrow |
| 22:35.26 | putnopvut | atis_home: That would be great. Thank you very much! |
| 22:36.05 | atis_home | putnopvut: they won't cover all cases, just our usage |
| 22:36.21 | atis_home | so, maybe some more testing should be done |
| 22:36.37 | atis_home | there's lot of people monitoring issue, i think i could ask them to test :) |
| 22:36.42 | putnopvut | atis_home: okay. The big thing is that I want to make sure it doesn't just absolutely blow up when calls are run. |
| 22:36.48 | putnopvut | Yeah, that's a good idea. |
| 22:36.50 | atis_home | ok |
| 22:37.31 | jpeeler | russellb: also CLI output and doc/externalivr.txt? |
| 22:38.35 | russellb | jpeeler: UM |
| 22:38.37 | russellb | jpeeler: maybe? |
| 22:38.41 | russellb | jpeeler: probably? |
| 22:38.42 | atis_home | russellb: chanspy patch is running for 50 minutes now, it already exceeds average chanspy usage lifetime on our testing machine :) |
| 22:39.19 | russellb | yayyyyy |
| 22:39.33 | putnopvut | I need to look at what change was made... |
| 22:41.18 | putnopvut | russellb: cool fix :) |
| 22:41.23 | russellb | it completely did not account for masquerades |
| 22:41.50 | russellb | but it's happy now |
| 22:42.06 | atis_home | me too :) |
| 22:42.25 | russellb | 1.4.19-rc3 ... the first version of asterisk with chanspy that doesn't explode |
| 22:42.50 | atis_home | :D |
| 22:43.00 | russellb | now i went and jinxed it ... |
| 22:43.19 | russellb | A42 |
| 22:43.21 | MuffinMan | [42] Committed by markster on 1999-11-15 02:09:02: Version 0.1.4 from FTP |
| 22:43.31 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 22:43.37 | atis_home | huh, i just got scared.. as i spoke that i'm happy, i got sms, and sms i usually get for crashes on my servers :D |
| 22:43.47 | russellb | heh |
| 22:43.52 | atis_home | nop, it's ok, it's private :) |
| 22:46.24 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 22:46.24 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 22:51.35 | jpeeler | would this be the proper syntax to represent a choice for the required first paramenter? |
| 22:51.37 | jpeeler | <PROTECTED> |
| 22:52.24 | russellb | looks good |
| 22:53.25 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 22:54.36 | *** join/#asterisk-dev RoyK (n=roy@ip-27-3-149-91.dialup.ice.no) |
| 23:12.37 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 23:45.17 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 23:46.29 | *** join/#asterisk-dev janinge (i=j@ninge.net) |