| 00:00.31 | *** join/#asterisk-dev juanjoc (n=juanjoc@host179.190-30-155.telecom.net.ar) |
| 00:00.44 | philipp64 | was wondering if anyone could point me at the discussion for why Macro() was deprecated, and what people are supposed to use instead... |
| 00:00.59 | russellb | GoSub() |
| 00:01.09 | philipp64 | Gosub lacks arguments. |
| 00:01.14 | russellb | not in trunk |
| 00:01.16 | russellb | or 1.6 |
| 00:01.38 | russellb | and it's mostly implementation details as to why |
| 00:01.45 | russellb | Macro is limited in depth, GoSub is not |
| 00:02.11 | philipp64 | ok. I'm still using 1.4.18. |
| 00:02.26 | russellb | i wasn't aware that it was marked deprecated in 1.4 ... |
| 00:02.33 | philipp64 | I suppose I should start playing with trunk... |
| 00:03.27 | philipp64 | well, it's not. I filed a bug against the configs/extensions.conf.sample file as being of limited use... and setting bad examples by leaning heavily on default contexts... and posted fixes to it. |
| 00:03.46 | philipp64 | the fixes were rejected because they continue to use Macro(). |
| 00:04.29 | russellb | hmm, then yeah, seems like such documentation updates could be merged into 1.4 |
| 00:04.29 | philipp64 | so now I have to build trunk so I can test fixes for stdexten et al using Gosub instead. |
| 00:04.31 | russellb | and the examples converted to use GoSub when merged to trunk |
| 00:05.07 | philipp64 | Corydon76? |
| 00:05.22 | philipp64 | oh, he's offline isn't he... |
| 00:05.32 | russellb | Corydon76-dig: <<<<<< |
| 00:05.33 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 00:05.38 | russellb | but he's not at his computer right now |
| 00:06.31 | mvanbaak | he must be in the same room as you |
| 00:06.33 | mvanbaak | ;) |
| 00:07.00 | russellb | was just a minute ago |
| 00:10.54 | *** join/#asterisk-dev seanbright (i=seanbrig@65.207.74.18) |
| 00:11.09 | philipp64 | so the new Gosub functionality will never hit 1.4? |
| 00:11.20 | ACiDV | I try to debug a problem on my server and have coredump on include/asterisk/lock.h related to : res = pthread_mutex_lock(&t->mutex); .... if I prefix by : if (&t->mutex) res = .... then the problem is gone, does it sound a logic fix ? I have VERY low knowledge on C :( |
| 00:11.40 | russellb | philipp64: the argument support, probably not, no |
| 00:12.05 | philipp64 | damnation. |
| 00:12.17 | philipp64 | well, that's too bad. |
| 00:13.02 | philipp64 | it might be easier to get people to buy into upgrading to a more recent 1.4 release... but I don't know if they're willing to bite the bullet and leap to 1.6 any time soon. |
| 00:13.39 | mvanbaak | philipp64: right now, 1.6 is in beta |
| 00:13.46 | philipp64 | AciDV why isn't your mutex being created before it's used? |
| 00:13.47 | mvanbaak | but soon it will go into -rc |
| 00:13.58 | russellb | it would be interesting if we could write some macro replacement, which just uses gosub internally |
| 00:13.58 | mvanbaak | that will mean the 1.6.0 release wont be far |
| 00:14.08 | russellb | so the Macro() existing usage will never have to go away ... |
| 00:14.13 | mvanbaak | and if it is, it's the latest stable supported by the manufacturer |
| 00:14.46 | mvanbaak | philipp64: that's how I convince my users to upgrade to bleeding edge |
| 00:15.01 | mvanbaak | hell, I'm even running like 80% of the boxen on trunk |
| 00:15.04 | philipp64 | you know the bellheads... if s/w isn't tested by 15 years of extensive homologation suites, they won't touch it... :-( |
| 00:15.38 | seanbright | well that means they can't even run asterisk 0.1.0 :-/ |
| 00:16.05 | mvanbaak | philipp64: I know. some of our core stuff is still running 1.0.9 |
| 00:16.09 | ACiDV | philipp64, I try to debug ticket 12098 and have problems, t->track doesnt look to be initialized at line 302 so I initialize it (t->track = 0) then get a 2nd core related to t->mutex ... have add 2 lines on the code and now * no more crash (I have a call generator to flood my server) |
| 00:16.46 | ACiDV | philipp64, but totally unsure if this is a safe fix :P |
| 00:16.49 | philipp64 | over in AstLinux land, we have two camps: those that want us to keep up with new releases so they have current technology, and those that absolutely must have reliability, so "if it ain't broke don't fix it". it's a fine line to walk. |
| 00:17.35 | philipp64 | ACiDV: I'd have to stare at the code some... can't do that right now. remind me later. |
| 00:22.34 | philipp64 | say, here's a naive question... if you're running in a purely digital environment (either SS7 or VoIP), what's the "native" way to do text messaging? assuming you don't want to mess with FSK decoding of SMS... |
| 00:23.35 | JT | SS7 |
| 00:24.18 | philipp64 | (what's the name for the protocol in the SS7 domain? or is it a core part of the protocol? I always thought it was part of the GSM evolution...) |
| 00:24.42 | mvanbaak | or use a service like bayhamsystems |
| 00:25.53 | philipp64 | I'm trying to convince my trunk provider to support it. they don't get the "any-service/any-device" concept... "texting on hardphones? why would you want that?" |
| 00:26.23 | philipp64 | I've seen a lot of people complaining about the pricing of bayhamsystems... |
| 00:27.23 | philipp64 | Is there an SMPP-to-SS7-messaging resource? |
| 00:29.52 | philipp64 | mvanbaak: you're counting that as a 'feature'? |
| 00:39.10 | mvanbaak | <--- off to bed |
| 00:43.30 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 00:43.35 | *** join/#asterisk-dev jeffg (i=4Xt3p6l1@pdpc/supporter/active/jeffg) |
| 01:01.08 | tzanger | kpfleming: paging dr. kpfleming |
| 01:03.04 | russellb | the doctor has left for the day |
| 01:03.40 | tzanger | shit |
| 01:04.25 | philipp64 | qwell: ping? |
| 01:05.07 | philipp64 | seanbright: yo! |
| 01:05.28 | seanbright | eh? |
| 01:06.28 | philipp64 | I just tried the fix Qwell suggested in 12117... MENUSELECT_CORE_SOUNDS=-CORE-SOUNDS-EN-GSM ... no joy. |
| 01:06.40 | philipp64 | the sounds got included anyway. |
| 01:06.41 | Qwell | with the patch? |
| 01:06.58 | philipp64 | which patch? |
| 01:07.03 | seanbright | yeah, you'll need the patch he attached to the bug |
| 01:07.09 | seanbright | M12117 |
| 01:07.11 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0012117: menuselect - CORE-SOUNDS-EN-GSM cannot be replaced reported by pprindeville http://bugs.digium.com/view.php?id=12117 |
| 01:07.31 | seanbright | this patch -> http://bugs.digium.com/file_download.php?file_id=18098&type=bug |
| 01:07.36 | philipp64 | doh! |
| 01:07.52 | philipp64 | someone smack me. I missed the email saying there had been an attachment... |
| 01:07.55 | seanbright | glad i could help |
| 01:07.57 | seanbright | heh |
| 01:12.17 | philipp64 | building... |
| 01:19.05 | *** join/#asterisk-dev jsmith (n=user@72.21.36.138) |
| 01:19.05 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 01:24.09 | philipp64 | in the way that calls can be plumbed together, would it make sense having such facilities for plumbing messaging as well? |
| 01:24.40 | philipp64 | i.e. receiving and SMS message, and forwarding it on as TAP or SMPP? |
| 01:32.48 | philipp64 | Qwell: backported your fix to 1.4.18 and just testing it now. |
| 01:33.25 | Qwell | note that in 1.4, menuselect.makeopts is already in .PHONY |
| 01:34.31 | philipp64 | umm... right... well... having it in there twice didn't seem to be a problem. :-) |
| 01:34.45 | Qwell | it wouldn't |
| 01:34.51 | philipp64 | not sure I like the way that the new makefile does a wget of the sounds... |
| 01:35.01 | philipp64 | means I can't do builds on airplanes... |
| 01:35.13 | Qwell | sure you can.. just disable it |
| 01:35.50 | philipp64 | is there any way to have it cache locally? so that if you zap the directory and rebuild from scratch, it doesn't refetch it? |
| 01:40.32 | philipp64 | Qwell: you rock! |
| 01:42.39 | file | dang nabbit Polycom... |
| 01:47.11 | philipp64 | I'll include the patch in AstLinux. |
| 01:48.11 | philipp64 | is there at least a generalized API for text-messages? |
| 01:48.27 | philipp64 | I've not bored down into that part of the code... |
| 01:48.30 | file | nope, not really |
| 01:48.55 | file | you can exchange text frames... but some of us believe messaging is best left outside of Asterisk... |
| 01:49.09 | philipp64 | so there wouldn't be an easy way to have a message pop out of SS7, and handy it off to SMPP... |
| 01:49.20 | file | nope. |
| 01:49.32 | philipp64 | looks like I'll be busy this summer. |
| 01:49.41 | philipp64 | (why best left out of asterisk?) |
| 01:50.08 | file | because there are things outside that do it a lot better, and messaging (even presence) is rather complex |
| 01:50.13 | philipp64 | after all, text-messaging is one of those services that's cheap to provide, but you get nickeled and dimed by the carriers... |
| 01:50.39 | philipp64 | sorry, are we talking about the same sort of messaging? |
| 01:50.54 | file | probably not, thus the complex part |
| 01:50.56 | file | lol |
| 01:51.15 | philipp64 | I'm talking about TAP/PET/SMS type messaging... |
| 01:51.37 | file | you are basically on your own. |
| 01:52.06 | philipp64 | Ok. well, I guess I'll have to write it then. SMPP is simple enough. |
| 01:52.31 | philipp64 | figuring out the generic interface, plus the CLI glue to interwork the two... that will be more complicated. |
| 01:52.59 | file | dammit Polycom! |
| 01:53.17 | snuff-work | mm presence.. we love u devstate |
| 01:53.32 | file | ohhhhhh... |
| 02:03.04 | philipp64 | doh. SNPP, not SMPP. |
| 02:42.00 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-065-005-230-151.sip.lft.bellsouth.net) |
| 03:01.45 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 03:01.45 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 03:03.09 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 03:03.26 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 03:03.27 | *** join/#asterisk-dev VoicePulse_ (n=contact@unaffiliated/voicepulse) |
| 03:03.27 | *** join/#asterisk-dev MuffinMan (n=muffins@neutrino.joshua-colp.com) |
| 03:03.27 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) |
| 03:03.27 | *** mode/#asterisk-dev [+o file] by irc.freenode.net |
| 03:08.22 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 03:09.33 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 03:47.08 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 04:10.13 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 04:10.13 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:10.19 | *** join/#asterisk-dev philipp64 (n=chatzill@pool-71-112-32-143.sttlwa.dsl-w.verizon.net) |
| 04:17.24 | *** join/#asterisk-dev miguel3239 (n=elguero@ns1.nashuacs.com) |
| 05:07.22 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 05:21.00 | *** join/#asterisk-dev suahmed (n=Administ@69.88.13.17) |
| 05:22.07 | snuff-work | mm.. where was that handy perl script that converted pcaps to sipp ? |
| 05:32.47 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 05:52.16 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.193) |
| 06:03.01 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 07:31.31 | tzafrir | Why doesn't asterisk create core files by default? |
| 08:19.53 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.134) |
| 08:42.34 | *** join/#asterisk-dev IvanV3835 (n=Miranda@84.47.169.109) |
| 09:22.55 | mvanbaak | tzafrir: because mortal users dont know what to do with it |
| 09:23.26 | tzafrir | mere mortals don't know how to add -g |
| 09:23.42 | tzafrir | which is why safe_asterisk seems to add it by default |
| 09:26.18 | tzafrir | mvanbaak, asterisk shouldn't crash anyway, so mere mortals won't encounter it |
| 09:31.20 | snuff-work | mmm |
| 09:31.23 | snuff-work | mm.. where was that handy perl script that converted pcaps to sipp ? |
| 09:31.36 | snuff-work | i can't remember which repo it was under |
| 09:32.42 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:33.33 | jmls | tzafrir: fwiw I agree with you |
| 09:34.41 | tzafrir | snuff-work, someone posted to asterisk-users about it, right? |
| 09:37.10 | mvanbaak | yeah, asterisk shouldn't crash |
| 09:42.32 | snuff-work | but i've seen it past by in pastrychef |
| 09:42.54 | snuff-work | yes there was something mentioned in ast-users/ast-dev about the little script |
| 09:47.20 | mvanbaak | snuff-work: wasn't it some new repos ? |
| 09:47.27 | mvanbaak | http://svn.digium.com |
| 09:47.32 | mvanbaak | open it in your browser |
| 09:50.50 | snuff-work | ah.. sniff2sipp |
| 09:50.52 | snuff-work | :P |
| 09:53.32 | snuff-work | mm this tool i could see coming in handy.. automated cdr testing |
| 10:16.35 | *** join/#asterisk-dev synthetiq (n=roger@193.79.224.62) |
| 10:39.43 | *** join/#asterisk-dev RoyK (n=roy@box36.fortel.no) |
| 11:09.28 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 11:10.00 | awk | can anyone tell me if this will work, using chan_iax2.c file from 18 and compiling it in on 17 ? |
| 11:21.58 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 11:30.49 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 12:11.34 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:13.45 | *** part/#asterisk-dev jmls (n=jmls@mail.tessera.co.uk) |
| 12:16.09 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 12:50.16 | *** join/#asterisk-dev mcargile (n=mcargile@gateway.in-florida.net) |
| 12:59.34 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:59.34 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:13.05 | *** join/#asterisk-dev jsmith (n=jsmith@216.207.245.1) |
| 13:13.05 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:25.23 | *** join/#asterisk-dev jeffg (i=ciXsFfCC@pdpc/supporter/active/jeffg) |
| 13:28.21 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135) |
| 13:29.17 | *** part/#asterisk-dev suahmed (n=Administ@69.88.13.17) |
| 13:38.25 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 13:51.25 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 13:52.15 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) |
| 14:00.17 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:00.17 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:08.51 | JunK-Y | file: with ur recent confbridge work, i dont see any options (nor thru the AMI) to kick a participant. |
| 14:09.22 | file | no AMI interface has been written. |
| 14:09.36 | file | 'nor CLI |
| 14:09.39 | file | 'nor config file |
| 14:10.07 | jsmith | 'nor advanced features |
| 14:10.07 | JunK-Y | i think that project is really nice, do you have any todo regarding this? |
| 14:10.15 | jsmith | 'nor documentation |
| 14:10.19 | file | todo in what sense? |
| 14:10.29 | file | jsmith: I fixed up the application description lastnight |
| 14:10.36 | jsmith | file: Oh? |
| 14:10.46 | jsmith | file: I haven't caught up on the commits list yet this morning |
| 14:10.49 | file | so it lists usage, plus all the options currently implemented |
| 14:10.52 | jsmith | w00t! |
| 14:10.53 | JunK-Y | in what you have in mind regarding future development of that app. |
| 14:10.55 | jsmith | That rocks! |
| 14:11.31 | file | JunK-Y: there is nothing else really in mind... it already acts as a conference bridge, everything else I come across is just extra features |
| 14:14.36 | file | jsmith: and the code is doxygenified with lots of comments |
| 14:15.13 | jsmith | file: Yeah... I'm seeing that. |
| 14:15.26 | JunK-Y | ya, I noticed a lot of comments, good job. |
| 14:15.37 | jsmith | file: I like the fact that the enter/exit sounds are pulled from a channel variable |
| 14:15.59 | file | know why I did that? |
| 14:16.18 | file | the option to record your name and such... can be done in the dialplan |
| 14:16.23 | JunK-Y | cause u hate the enter.h and leave.h ? :) |
| 14:18.19 | mcargile | nice. I had to change enter.h and leave.h for a client and it was a pain in the butt |
| 14:20.21 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 14:27.00 | atis_work | a quick C question |
| 14:27.07 | atis_work | is it ok to use if (value[0]=='+') { |
| 14:27.20 | atis_work | for const char *value |
| 14:27.41 | Corydon76-dig | Yes |
| 14:27.46 | atis_work | of course i test "!ast_strlen_zero(value) && strlen(value)>=1" first |
| 14:27.52 | atis_work | thanks |
| 14:28.07 | Corydon76-dig | The second part isn't necessary |
| 14:28.10 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:28.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:28.23 | Corydon76-dig | !ast_strlen_zero MEANS the length is 1 or greater |
| 14:28.38 | atis_work | oh, correct |
| 14:28.40 | atis_work | thanks |
| 14:39.45 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 14:43.26 | Corydon76-dig | jsmith-teaching: ping |
| 14:44.06 | jameswf | anyone have a benchmark for calls per hour... 4000 fail.... 2000 fail.... |
| 14:45.12 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 14:49.41 | jsmith-teaching | Corydon76-dig: Pong |
| 14:49.58 | jsmith-teaching | jameswf: That depends on a *lot* of different factors |
| 14:51.23 | Corydon76-dig | jsmith-teaching: you found the Goo Goo Clusters? |
| 14:51.34 | Corydon76-dig | jsmith-teaching: I left them in there last night |
| 14:51.46 | jsmith-teaching | Corydon76-dig: I was wondering where those came from... are they fair game? |
| 14:51.53 | Corydon76-dig | Yes, they are |
| 14:52.15 | jsmith-teaching | Corydon76-dig: How'd class go? |
| 14:52.16 | Corydon76-dig | If there are any left, though, could you return the box to my office? |
| 14:52.25 | Corydon76-dig | It went fine |
| 14:52.26 | tzanger | paging dr kpfleming, dr kpfleming are you there? |
| 14:52.36 | file | he may or may not be there |
| 14:52.40 | kpfleming | i am here |
| 14:53.29 | jameswf | understood, just need a good starting point as optimism has failed... mixed digital analog, 48 channels, AMD 3300 (also tries everex cheap pc with simular result) |
| 14:54.40 | jameswf | oh no transcoding |
| 14:55.04 | jsmith-teaching | jameswf: I would say it's more a function of call setups/second than calls per hour -- how long is your average call? |
| 14:55.25 | jameswf | around 30 seconds. |
| 15:08.08 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:08.08 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:08.26 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 15:08.26 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:09.28 | tzafrir | Do those guys from Sun still shoot for 4000 simultanious calls? |
| 15:09.37 | tzafrir | (speaking of 4000 calls) |
| 15:13.06 | datachomper | translate.c:175 framein: no samples for lintoulaw |
| 15:13.20 | datachomper | translate.c:211 framein: lintoulaw did not update samples 0 |
| 15:13.36 | datachomper | How do I fix this? I'm running 1.4.18 |
| 15:14.14 | datachomper | The slin_ulaw_ex.h file is there ... |
| 15:16.21 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:16.35 | datachomper | Every frame I recieve via the soundhook.h api gives me this message |
| 15:16.37 | russellb | update |
| 15:16.42 | russellb | you can ignore that message |
| 15:16.45 | russellb | i think |
| 15:16.49 | russellb | oh |
| 15:21.33 | datachomper | Sorry, my internet crapped out. I can ignore this message, right? |
| 15:23.37 | russellb | um, probably not, actually |
| 15:23.43 | russellb | i was thinking of something else |
| 15:24.28 | *** join/#asterisk-dev ctooley_ (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 15:30.21 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:33.38 | jsmith-teaching | russellb: Any reason why the 1.4.19rc1 isn't on the downloads.digium.com server? |
| 15:33.46 | jsmith-teaching | russellb: (or am I just blind?) |
| 15:34.27 | Qwell | jsmith-teaching: shows up for me.. http://downloads.digium.com/pub/telephony/asterisk/releases/asterisk-1.4.19-rc1.tar.gz |
| 15:34.41 | kpfleming | what IP address do you have for the server, jsmith-teaching ? |
| 15:36.10 | *** join/#asterisk-dev datachomper (n=russ@75.146.194.59) |
| 15:36.40 | russellb | jsmith-teaching: you might not have looked in the releases dir |
| 15:36.47 | russellb | i didn't put it in the main dir since it's not an official release |
| 15:36.53 | russellb | speaking of 1.4.19, i need to do another rc ... |
| 15:36.55 | jsmith-teaching | kpfleming: 216.27.40.102 right now, but it was yesterday when I noticed it |
| 15:37.07 | kpfleming | ok, just checking whether internal or external |
| 15:37.43 | *** join/#asterisk-dev jmesquita (n=jmesquit@bd219853.virtua.com.br) |
| 15:40.25 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 15:43.51 | atis_work | russellb: our tests on 1.4.19 are all ok, we did manual feature testing (of what we use), and load test over night with ~40 simultenous calls |
| 15:44.12 | atis_work | altough i didn't included chanspy tests in load-testing |
| 15:48.14 | *** join/#asterisk-dev seanbright (i=seanbrig@65.207.74.18) |
| 15:49.00 | russellb | atis_work: great ... there was one crash reported that i fixed, so we'll have one more rc ... |
| 15:49.46 | atis_work | i just wonder, will all other commits to branch since rc1 will go to rc2? |
| 15:49.54 | file | if you do crash in chanspy it would be extremely helpful to have access... so far nobody has been able to give me access to look at the core dump |
| 15:50.26 | atis_work | file: i had a bunch of crashes in chanspy at 1.4.18-rc |
| 15:50.52 | atis_work | russellb: is rc2 coming out today? |
| 15:51.02 | russellb | yeah |
| 15:54.44 | JunK-Y | file: at least, ur latest fix for chanspy fix the only core i was able to duplicate. |
| 16:00.45 | datachomper | omg ./gentone just what I needed |
| 16:15.47 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 16:16.09 | puzzled | hi |
| 16:25.49 | *** join/#asterisk-dev jsmith-teaching (n=jsmith@216.207.245.1) |
| 16:25.49 | *** mode/#asterisk-dev [+o jsmith-teaching] by ChanServ |
| 16:28.06 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 16:28.06 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 16:28.56 | codefreeze | big welcomes to puzzled! |
| 16:29.29 | puzzled | :) |
| 16:39.31 | *** join/#asterisk-dev jdg (n=jdg@203.185.178.23) |
| 16:48.25 | *** part/#asterisk-dev mcargile (n=mcargile@gateway.in-florida.net) |
| 16:55.14 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 16:58.05 | *** join/#asterisk-dev oej (n=olle@62.97.243.70) |
| 16:58.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:04.08 | Qwell | tzafrir: ping? |
| 17:04.19 | tzafrir | here |
| 17:04.32 | Qwell | stupid question.. does xorcom hardware provide zaptel timing? |
| 17:04.39 | tzafrir | yes |
| 17:14.25 | *** join/#asterisk-dev JoseBravo (n=jbravo@190.156.225.15) |
| 17:16.59 | JoseBravo | Im getting this error "callerid.c: fsk_serie made mylen < 0 (-8)" in my full log. I have cidstart=ring, any idea? |
| 17:21.57 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 17:22.30 | Corydon76-dig | JoseBravo: Try #asterisk |
| 17:23.56 | JunK-Y | === Thread ID: -1209787488 (netconsole started at [ 1066] asterisk.c listener()) |
| 17:23.59 | JunK-Y | === ---> Lock #0 (loader.c): MUTEX 569 ast_module_reload &reloadlock 0x81c3380 (1) |
| 17:24.02 | JunK-Y | === ---> Lock #1 (loader.c): MUTEX 588 ast_module_reload &(&module_list)->lock 0x81c31c8 (1) |
| 17:24.06 | JunK-Y | === ---> Waiting for Lock #2 (res_config_ldap.c): MUTEX 1358 reload &ldap_lock 0x568280 (1) |
| 17:24.09 | JunK-Y | === --- ---> Locked Here: res_config_ldap.c line 1358 (reload) |
| 17:24.15 | *** mode/#asterisk-dev [+b %JunK-Y!*@*] by Corydon76-dig |
| 17:24.33 | Corydon76-dig | I don't think you meant to do that |
| 17:24.48 | *** mode/#asterisk-dev [-b %JunK-Y!*@*] by Corydon76-dig |
| 17:26.48 | JoseBravo | Corydon76-dig I tried but no help... |
| 17:27.17 | Corydon76-dig | JoseBravo: This is not a support channel |
| 17:29.40 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 17:32.41 | JoseBravo | Corydon76-vcch I don't know what more can I do... I have asked in the list and in the channel. |
| 17:32.54 | JunK-Y | file: with confbrige, where are you getting ur timing from? |
| 17:33.08 | JunK-Y | Corydon76-dig: it was only to paste when I just got |
| 17:33.21 | JoseBravo | It appears to be an error in the line: "ast_log(LOG_ERROR, "fsk_serie made mylen < 0 (%d)\n", mylen);" in callerid.c |
| 17:33.30 | file | JunK-Y: there's a module that uses zaptel, and a module that does some userspace timing/mixing stuff |
| 17:34.33 | file | if someone writes a better one they can go ahead and plug it right in... no changes required |
| 17:37.06 | codefreeze | JoseBravo: I remember playing with that code, what version of asterisk are you using? |
| 17:37.24 | JoseBravo | codefreeze 1.4.9 |
| 17:37.31 | JunK-Y | file: i dont have any zaptel module loaded and confbridge works well. |
| 17:37.58 | codefreeze | JoseBravo: oooo, old stuff... let me check |
| 17:38.08 | file | Linux? what kernel? |
| 17:38.30 | JunK-Y | Linux localhost.localdomain 2.6.9-67.0.4.EL |
| 17:38.42 | file | ah, it's compensating |
| 17:38.54 | JunK-Y | compensate what? |
| 17:39.00 | file | I've noticed the 2.6.24 kernel does a rather good job with timing |
| 17:39.04 | JunK-Y | btw, great job on that M. joshua! |
| 17:39.26 | file | the module responsible for userspace mixing, bridge_softmix, compensates for the lack of real time you get |
| 17:39.53 | JunK-Y | have you stress-test a little bit that app? |
| 17:40.00 | file | nope |
| 17:40.03 | file | not really |
| 17:40.19 | JunK-Y | i will ask QA to stress-test it a bit |
| 17:41.03 | codefreeze | JoseBravo: I'm looking it up now, but I remember putting that in, because, theoretically, mylen should never be negative |
| 17:41.08 | JunK-Y | im not sure to understand where the channel are mixed exactly, on the kernel land? |
| 17:41.15 | file | bridge_softmix.c |
| 17:41.19 | file | in the bridges directory |
| 17:41.51 | JunK-Y | we'll take a look at this |
| 17:43.23 | Corydon76-dig | codefreeze: it basically means that there's noise on the line |
| 17:44.07 | Corydon76-dig | So the checksum did not verify |
| 17:44.46 | codefreeze | Corydon76-dig: thanks. It definitely marks an error exit from that routine. result would be that callerid wouldn't register, I'd guess. |
| 17:45.13 | Corydon76-dig | Still not a development issue. ;-) |
| 17:45.37 | codefreeze | JoseBravo: does the above help you at all? |
| 17:46.27 | JoseBravo | codefreeze yes, can I "delete" the noise with the gains? |
| 17:47.25 | codefreeze | JoseBravo: Dunno. I just added that code so the routine wouldn't crash, which was the old behavior. You can try that, tho, I'd imagine. |
| 17:48.18 | JoseBravo | codefreeze thanks! |
| 17:48.30 | codefreeze | JoseBravo: best of luck! |
| 17:48.37 | JoseBravo | Thanks all! bye |
| 17:48.48 | Corydon76-dig | You can't delete noise with gains |
| 17:48.58 | JoseBravo | Corydon76-dig no? |
| 17:49.23 | JoseBravo | I have a CallerID device and it works fine... |
| 17:49.25 | Corydon76-dig | No. |
| 17:50.52 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 17:50.52 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 17:51.02 | Qwell | mvanbaak: ping |
| 17:52.01 | JoseBravo | Corydon76-dig how can I do that? |
| 17:52.36 | codefreeze | Corydon76-dig: I guess it'd be bad form to try to 'clip' noise by pumping up the gain so the noise saturates... most likely, wouldn't help.. |
| 17:52.38 | Corydon76-dig | I've found calling up the telco and bitching about the line noise works |
| 17:55.06 | codefreeze | ha! sometimes 'social' rather than 'technical' solutions are the best! |
| 17:56.23 | Corydon76-dig | codefreeze: well, it's technical, just not your tech. ;-) |
| 17:56.59 | codefreeze | yeah, and we all know how 'social' the telco can be about fixing stuff like that... ;) |
| 17:57.22 | Corydon76-dig | Besides, bitching at Ma Bell makes everyone feel better |
| 17:57.31 | codefreeze | lol |
| 17:57.48 | codefreeze | better them than the poor dog. |
| 17:58.43 | JunK-Y | file: whats the real advantage of bridge_softmix.c vs ztdummy? i mean that will take the same CPU usage, no^ |
| 17:58.59 | Qwell | it wouldn't be a kernel module |
| 17:59.28 | JunK-Y | so that will be a bit slower since that will not be in kernel-land, no? |
| 18:00.52 | mvanbaak | Qwell: pong |
| 18:04.27 | file | eh? oh? wha? |
| 18:04.40 | file | JunK-Y: will work (hopefully) on many platforms |
| 18:05.29 | file | the bridging core is totally pluggable... you can make it use zaptel if you want, or the mixing from a DSP on a board... |
| 18:05.42 | file | or userspace |
| 18:06.57 | file | what does the bridging is totally separated from what is using it, to a developer it all behaves the same |
| 18:07.39 | JunK-Y | ok |
| 18:07.52 | JunK-Y | if im getting a segfault, should I report this on mantis? |
| 18:08.37 | JunK-Y | (in bridging.c) |
| 18:08.41 | file | ummm, I would rather keep this off it for now... |
| 18:08.55 | JunK-Y | ok |
| 18:11.08 | JoseBravo | codefreeze I see the caller number in the full log, in DTMF lines. And its correct, I think the number is received... |
| 18:14.40 | JoseBravo | I just received a list response abiut sending this issue to the dev list. |
| 18:14.50 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.141) |
| 18:25.02 | codefreeze | JoseBravo: very interesting. When I handled the previous bug report, I had to extrapolate a possible condition where the code could crash. That was my best guess, so I made it report the data. The folks who had the crash reported several days of running with no probs, so it looked good. |
| 18:26.15 | codefreeze | Tell you what. open a new bug at bugs.digium.com, and report all this. I have an idea that might reveal the situation better... |
| 18:26.37 | codefreeze | Assign that bug to me (murf) |
| 18:27.07 | codefreeze | JoseBravo: How frequently do you see these messages? |
| 18:40.19 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 18:54.09 | JoseBravo | codefreeze evry call. If I put cidstart=polarity I don't receive the message but CID dons't work... |
| 18:54.22 | JoseBravo | Well, with cidstart=ring dons't work too. |
| 18:57.52 | JoseBravo | codefreeze I installed the 1.4.19 version, but I get the same result.. I'll try to modify the code and test again. |
| 18:58.12 | JoseBravo | What if I just ingnore if mylen < 0? |
| 19:02.11 | JoseBravo | Sorry, 1.4.18 |
| 19:15.44 | *** join/#asterisk-dev oej (n=olle@114.62-97-206.bkkb.no) |
| 19:15.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:15.51 | *** join/#asterisk-dev jbigB (n=jbigB@216.207.245.1) |
| 19:19.31 | *** join/#asterisk-dev atis_home (n=chatzill@193.238.213.215) |
| 19:23.27 | *** join/#asterisk-dev ACiDV (n=acidv@24-122-213-230.dr.cgocable.ca) |
| 19:24.48 | atis_home | putnopvut: ping |
| 19:25.24 | putnopvut | atis_home: pong |
| 19:25.44 | atis_home | so, what's the one case you wanted update_dial_status to remain? |
| 19:26.05 | ACiDV | ahah =) 12127 ;P I'm here to read about this |
| 19:26.06 | atis_home | i just don't feel that it's right to change member status based on dial status :) |
| 19:26.18 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 19:27.08 | putnopvut | atis_home: the situation I found was what I said on the bug note. |
| 19:27.24 | putnopvut | Where you unload a channel module and attempt to call the queue. |
| 19:28.06 | ACiDV | putnopvut: but this case will be 'rare' no ? who unload channel module like chan_sip during normal running ? |
| 19:28.28 | putnopvut | ACiDV: Yes, it should be rare, but that's no reason to just ignore the case. |
| 19:28.35 | atis_home | agreed |
| 19:28.37 | ACiDV | We are just impatient to see the patch =) hehe |
| 19:28.46 | putnopvut | ACiDV: :) |
| 19:29.33 | atis_home | but if you keep update_dial_status in one place, if ast_request fails, won't there be any other cases how it can be executed |
| 19:29.44 | atis_home | like i mentioned - codec incompatibility |
| 19:30.38 | atis_home | i think that channel driver should be responsible for notifying all devstate subscribers that devices are now invalid |
| 19:32.33 | putnopvut | atis_home: did you read the latest note I put on the issue? It address your codec incompatibility question. |
| 19:33.13 | putnopvut | Hmmm, tell me what you think of this: |
| 19:33.25 | atis_home | putnopvut: i have, but all you said - that it shouldn't, i'm just too curious about details |
| 19:34.26 | putnopvut | atis_home: I agree about the idea that the channel drivers should update the device state core about all state changes, that would be the best way to handle this. |
| 19:35.29 | putnopvut | The big problem is that in 1.4, you can't just update the device state to some specific state. |
| 19:36.01 | putnopvut | But I have a workaround in mind... |
| 19:36.20 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 19:36.28 | putnopvut | If the ast_request fails, call ast_device_state on the member's interface (or state interface in your case) to get the updated device state. |
| 19:36.35 | atis_home | putnopvut: does this have to do something with 1.4? i'm using bunch of backports anyway |
| 19:37.22 | putnopvut | atis_home: yes, 1.4 simply doesn't have the ability to change the device state to a specific value. |
| 19:37.32 | Juggie | seanbright: ping |
| 19:37.56 | putnopvut | It instead uses a function to tell the device state core that the device state has changed, then the core uses a callback in the channel driver to try to figure out what to change the device state to. |
| 19:38.29 | atis_home | hmm, i'm not familiar with device state that far |
| 19:39.55 | atis_home | putnopvut: but why do you still want to update device state from app_queue? |
| 19:40.09 | atis_home | i think it all should lay in channel driver |
| 19:40.21 | *** join/#asterisk-dev asteriskmonkey (n=asterisk@69.77.169.14) |
| 19:40.37 | putnopvut | atis_home: well, technically it will, but app_queue will be asking the channel driver for an updated device state. |
| 19:40.56 | putnopvut | And if the channel driver isn't there, then the device will be marked "invalid" |
| 19:41.29 | putnopvut | If it is there, then it will properly set the device to "busy" or whatever it is supposed to be. |
| 19:41.45 | atis_home | you mean member->state? |
| 19:42.04 | *** join/#asterisk-dev jsmith-teaching (n=jsmith@216.207.245.1) |
| 19:42.04 | *** mode/#asterisk-dev [+o jsmith-teaching] by ChanServ |
| 19:43.18 | putnopvut | member->status, yea. |
| 19:43.38 | jsmith-teaching | jsmith->status = luser |
| 19:43.55 | atis_home | i'm still afraid that in such way it can sometimes be different from actual status |
| 19:45.06 | putnopvut | That doesn't make sense though, because all we're doing is requesting the device state from the channel driver itself. |
| 19:45.18 | putnopvut | If the channel driver doesn't know the proper status, then there's a lot more wrong... |
| 19:45.54 | atis_home | ok, that convinced me :) |
| 19:46.34 | putnopvut | Cool. I'll have a patch on that issue real soon then. |
| 19:46.44 | putnopvut | You can give it a try and see if it works out for you. |
| 19:46.49 | atis_home | maybe we should also open issues regarding channel drivers - to raise devstate event upon module unload? |
| 19:48.37 | putnopvut | atis_home: yeah, that makes sense. |
| 19:50.14 | *** join/#asterisk-dev JoseBravo (n=jbravo@190.156.225.15) |
| 19:51.16 | atis_home | ok, so how about the proposal i mentioned.. that should probably be different issue, however i would like to hear your thoughts on that |
| 19:51.33 | atis_home | to combine status of interface and state_interface |
| 19:52.34 | putnopvut | What do you mean to combine the status of interface and state_interface? |
| 19:53.23 | atis_home | well, app_queue first dials to local channel, in 1.6 that would cause devstate of that channel to become INUSE, but actual interface specified in state_interface would still be NOT_INUSE |
| 19:53.54 | atis_home | so, another thread of app_queue shouldn't dial the same member when one of interfaces is INUSE |
| 19:54.15 | atis_home | or another member in another queue with exactly same interfaces |
| 19:54.44 | atis_home | that would probably mean subscribing to both interfaces, not only state_interface |
| 19:56.10 | putnopvut | I see...yeah, that would have to be a configuration option of some sort. |
| 19:57.37 | atis_home | so, no objections? |
| 19:58.00 | atis_home | i'm not sure is that more feature request or bug.. |
| 19:58.17 | putnopvut | atis_home: this is one of those fuzzy areas that's sort of a feature request and sort of a bug. |
| 19:58.48 | atis_home | i could probably write that myself, but not sure when.. i already have bunch of patches that i would like to merge, but don't have time to finish them |
| 20:00.00 | putnopvut | atis_home: I know what that's like :) |
| 20:00.13 | putnopvut | Oh, and I uploaded a patch to 12127. |
| 20:00.59 | ACiDV | kewl |
| 20:01.01 | ACiDV | I check |
| 20:01.41 | atis_home | huh, seems more simple than i imagined |
| 20:02.03 | ACiDV | :D |
| 20:02.12 | atis_home | btw, you should use ->state_interface, not ->interface |
| 20:02.28 | atis_home | as i remember, state_interface should always be set to something |
| 20:02.55 | putnopvut | atis_home: the patch is against 1.4 which does not have state_interface |
| 20:03.01 | ACiDV | now who can check 12098 lol =) |
| 20:03.10 | atis_home | M12098 |
| 20:03.11 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0012098: Segmentation fault in chan_sip.c reported by wegbert http://bugs.digium.com/view.php?id=12098 |
| 20:03.42 | putnopvut | atis_home: for trunk, state_interface will definitely be used. |
| 20:03.50 | putnopvut | I'll make a note on the bug report about that. |
| 20:03.51 | atis_home | ok, just don't forget that :) |
| 20:05.44 | atis_home | btw, shouldn't you lock before updating ->status? |
| 20:06.06 | putnopvut | No, the queue is locked at that point. |
| 20:06.20 | atis_home | and the next line - ast_mutex_lock? |
| 20:07.00 | atis_home | i'm just trying to understand all that locking better.. not sure how it works now :) |
| 20:07.13 | putnopvut | Hmmm, you make a good point...it seems like that may be a recursive lock. Let me double check. |
| 20:09.29 | putnopvut | atis_home: oh lovely...okay, so that function, ring_entry, is only called from ring_one. |
| 20:09.47 | putnopvut | The most common place that ring_one is called is in try_calling, and at that point the queue is locked. |
| 20:10.08 | putnopvut | But, it can also potentially be called from wait_for_answer, in which case the queue is NOT locked. |
| 20:10.30 | atis_home | oh, nice :) |
| 20:10.57 | putnopvut | Yes... |
| 20:12.36 | putnopvut | Yeah, it seems smart to move the status assignment inside the lock. |
| 20:12.44 | putnopvut | I'll update the patch. |
| 20:15.10 | putnopvut | Thanks for pointing that out! |
| 20:17.31 | atis_home | you're welcome :) |
| 20:26.58 | *** join/#asterisk-dev atis_home (n=chatzill@193.238.213.215) |
| 20:31.15 | jpeeler | does the TLS in Asterisk allow for the use of sDescriptions? |
| 20:32.15 | russellb | i've never heard of that, so probably not |
| 20:34.03 | *** join/#asterisk-dev dhelder (n=dhelder@widget.gizmolabs.org) |
| 20:34.51 | dhelder | hey, where should security bugs be submitted? |
| 20:35.17 | atis_home | putnopvut: i've noticed another problem :p |
| 20:35.41 | atis_home | if member status will be changed - there won't be a manager event, as it's in other cases |
| 20:36.25 | atis_home | maybe keep the update_status function and change it to request actual devstate |
| 20:36.54 | ACiDV | hmm, not sent on handle_statechange ? |
| 20:37.01 | atis_home | btw, i have a patch for realtime member status, and it would be better to have all the status change to become in one place |
| 20:37.19 | atis_home | ACiDV: no, on handle_statechange it's ok, but not if chan_sip is unloaded |
| 20:37.29 | ACiDV | kk |
| 20:38.27 | atis_home | actually handle_statechange could use update_status so that it's all in one place |
| 20:40.43 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:42.11 | atis_home | i'm just not sure what's q->maskmemberstatus about |
| 20:44.11 | outtolunc | it was to stop the outpour of memberstatus events as on some systems it would flood them <G> |
| 20:44.22 | atis_home | yup, just read that :) |
| 20:46.22 | JunK-Y | file: for ur confbridge, try to join 3 participants. |
| 20:46.36 | file | I have |
| 20:47.09 | JunK-Y | ive a lot of warning (bad file descriptor) and it segfaults. |
| 20:47.23 | file | it is entirely possible for it to go beserk right now if it can't move to a multiparty mixing module |
| 20:48.18 | file | dhelder: security@asterisk.org |
| 20:48.46 | Juggie | they can also be submitted to the bug tracker and flagged private |
| 20:49.30 | Juggie | espically if you have a patch |
| 20:49.34 | dhelder | ah, thanks |
| 20:51.03 | russellb | dhelder: and if it's serious enough that you want to encrypt the email, you can email me directly ... russell@digium.com ... key on pgp.mit.edu |
| 20:54.59 | seanbright | Juggie: yessir? |
| 20:56.05 | *** join/#asterisk-dev philipp64 (n=chatzill@131.107.152.19) |
| 20:56.36 | philipp64 | corydon76-dig: ping? |
| 20:56.55 | file | JunK-Y: if you turn on core debug and bump it up to 6 or so you'll get *tons* of debug messages in regards to bridging |
| 20:56.58 | file | it'll tell you exactly what is going on |
| 20:57.31 | philipp64 | Qwell: ping? |
| 20:57.52 | datachomper | So, apparently. Spitting out the frame data to the CLI for an entire call crashes asterisk |
| 20:58.27 | putnopvut | atis_home: sorry I stepped out of the office for a while... |
| 20:58.46 | Corydon76-dig | pong |
| 20:59.25 | philipp64 | seanbright: who are the bug marshals for 1.6? who decides what makes rc? |
| 20:59.37 | seanbright | philipp64: not really sure |
| 20:59.46 | Corydon76-dig | At this point, RC is feature-frozen |
| 21:00.12 | philipp64 | sure... I was thinking that Qwell's fix to 12117 would be nice to get in. it's not a destabilizing fix. |
| 21:00.31 | Corydon76-dig | Fix or feature? |
| 21:00.35 | philipp64 | fix. |
| 21:00.39 | Corydon76-dig | M12117 |
| 21:00.40 | file | M12117 |
| 21:00.41 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0012117: menuselect - CORE-SOUNDS-EN-GSM cannot be replaced reported by pprindeville http://bugs.digium.com/view.php?id=12117 |
| 21:00.46 | Qwell | debatable, imo |
| 21:00.52 | Corydon76-dig | Feature |
| 21:00.54 | philipp64 | how so? |
| 21:01.15 | Corydon76-dig | Convince me otherwise |
| 21:01.49 | Qwell | Corydon76-dig: it's impossible to disable en gsm without using the gui menuselect. |
| 21:02.03 | philipp64 | you can't easily build from sources without GSM sounds being included, whether you want them or not. this is incorrect behavior, and the patch fixes wrongness in the behavior. |
| 21:02.13 | Corydon76-dig | We don't support using anything but the GUI, though |
| 21:02.18 | Qwell | yes we do |
| 21:02.21 | philipp64 | it gets things to work the way they should have from the beginning, rather than adding "new" functionality. |
| 21:02.25 | Corydon76-dig | We do? |
| 21:02.27 | Qwell | USER_MAKEOPTS |
| 21:02.46 | Corydon76-dig | Qwell: mark it experimental |
| 21:02.48 | Qwell | it merges all of the files you supply in USER_ and GLOBAL_ MAKEOPTS |
| 21:03.03 | Qwell | (into menuselect.makeopts) |
| 21:03.21 | philipp64 | right. so you can put in, but you can't take out. |
| 21:04.06 | philipp64 | it's a very simple, straightforward fix, and it's in the build environment... not the runtimes. |
| 21:04.06 | Corydon76-dig | which bites only the people who know what they're doing and can work around it |
| 21:04.10 | Qwell | actually, in 1.6, I think menuselect.makeopts not being in .PHONY is a bug |
| 21:04.12 | philipp64 | low risk, in other words. |
| 21:04.35 | Qwell | well, trunk |
| 21:04.45 | atis_home | putnopvut: you read what i said about AMI event |
| 21:04.45 | philipp64 | work-around it by hand, yes. harder to work around in an automated build environment. |
| 21:05.34 | philipp64 | Qwell: so it gets to fix two bugs with a single patch. brilliant! :-) |
| 21:05.55 | Qwell | wow, I must've been tired when I wrote that patch |
| 21:06.17 | philipp64 | why? |
| 21:06.33 | Qwell | it's not pretty |
| 21:06.48 | philipp64 | you mean the negative logic? |
| 21:07.00 | Qwell | the code.. |
| 21:07.18 | philipp64 | looks ok to me. what am I not seeing? |
| 21:07.48 | Qwell | it's just kinda ugly |
| 21:08.07 | philipp64 | I'm not sure I'd use strncmp() on a single character... ;-) |
| 21:08.14 | Qwell | yes, that :p |
| 21:08.29 | philipp64 | nor "int" for a yes/no value... but other than that. |
| 21:08.35 | Qwell | yeah...like I said... heh |
| 21:08.44 | Qwell | I was clearly tired when I wrote that |
| 21:10.07 | philipp64 | you could also have done negate ^ cat->positive_output ... ok, someone stop me... I'm in terminal code nitpick mode... |
| 21:10.50 | Qwell | basically, the entire patch was done poorly.. I'll be the first to admit that |
| 21:11.04 | putnopvut | atis_home: yes, I did. I'll double check to make sure you're right about that. I have to work on something else first for a little while though. |
| 21:11.08 | Qwell | feel free to clean it up and add one for 1.4 |
| 21:11.14 | Qwell | well, maybe 1.4.. |
| 21:11.37 | philipp64 | isn't 1.4 frozen? |
| 21:11.58 | Qwell | hence the maybe.. depends whether it gets deemed a bug or not. |
| 21:12.07 | Qwell | brb |
| 21:12.10 | atis_home | putnopvut: sure, i could fix this myself, i'm just not sure how necessary is queue/member iteration in update_status |
| 21:12.24 | philipp64 | Corydon76-dig: bug or no bug? |
| 21:12.52 | Corydon76-dig | It's up to Qwell |
| 21:13.08 | philipp64 | I wonder how many distro releases via RPM there are... |
| 21:13.51 | Corydon76-dig | Too many |
| 21:22.39 | philipp64 | not a fan of RPM? |
| 21:25.15 | russellb | Corydon76-dig: so, CONFIG_FILEUNCHANGED will return the config from memory? |
| 21:26.40 | Corydon76-dig | No, it returns a special value to say that the file (and related includes) haven't changed |
| 21:26.47 | Corydon76-dig | since the last time you loaded that file |
| 21:27.32 | russellb | ok, makes sense |
| 21:27.59 | file | it would be cool if it also returned a special value to indicate that the file was found but discarded because it was invalid in some way |
| 21:28.13 | Qwell | ^^ what he said |
| 21:28.20 | file | Qwell: hint hint |
| 21:28.45 | Corydon76-dig | file: Invalid in some way? |
| 21:28.53 | Corydon76-dig | Could not be parsed? |
| 21:29.12 | file | M10690 |
| 21:29.12 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0010690: sip peer with missing close bracket causes all subsequent sip peers not to load reported by dtyoo http://bugs.digium.com/view.php?id=10690 |
| 21:29.12 | Qwell | M10690 |
| 21:29.12 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0010690: sip peer with missing close bracket causes all subsequent sip peers not to load reported by dtyoo http://bugs.digium.com/view.php?id=10690 |
| 21:29.24 | Qwell | MuffinMan: ? |
| 21:29.32 | file | Qwell: I asked him as well |
| 21:29.50 | Corydon76-dig | Is there an echo in here? |
| 21:31.56 | file | echo echo echo |
| 21:41.03 | CrashHD | nah, no echo, just file rambling to himself again |
| 21:42.37 | russellb | Corydon76-dig: if we wanted to get insane, we could write a pretty extensive config interface for the dialplan ... |
| 21:42.45 | russellb | store the config structure in a datastore ... |
| 21:42.51 | russellb | browse categories, browse variables |
| 21:43.01 | russellb | oh how that sounds insane |
| 21:43.31 | russellb | lol |
| 21:44.40 | Corydon76-dig | Heh |
| 21:46.27 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 21:49.48 | datachomper | So, I have a void pointer in a datastore which I need to cast out into another pointer |
| 21:50.17 | datachomper | Wouldn't it just be "pointy = (struct myStruct *)datastore->voidPointer" ? |
| 21:53.06 | putnopvut | jsmith-teaching: are you around? |
| 22:00.54 | Corydon76-dig | datachomper: generally, no |
| 22:01.32 | Corydon76-dig | datachomper: there is no need to cast a void pointer |
| 22:02.08 | datachomper | Well pointy is defined as "struct myStruct *pointy" |
| 22:02.31 | datachomper | It's still ok to just "pointy = datastore->voidPointer" ? |
| 22:03.15 | Qwell | iirc, you do need to cast void if you're casting to a const. heh |
| 22:03.47 | Qwell | void *foo = NULL; const char *bar = (const char *)foo; |
| 22:03.56 | Qwell | something like that...I forget. gcc 4.2 was unhappy with it though |
| 22:07.47 | russellb | Corydon76-dig: does the config file caching assume that only one place cares about its contents? |
| 22:08.00 | russellb | Corydon76-dig: because if chan_sip loads sip.conf with FILEUNCHANGED before I do ... |
| 22:08.27 | russellb | like ... how does it check, or does it at all, if it changed since the last time _I_ opened it |
| 22:09.14 | russellb | seems like this isn't going to work for this case .... |
| 22:14.30 | Corydon76-dig | russellb: Hrm |
| 22:14.55 | Corydon76-dig | You raise a good point |
| 22:14.59 | Corydon76-dig | And a bug |
| 22:15.17 | russellb | i doubt that it affects anything |
| 22:15.32 | russellb | but yeah, it's not going to work if more than one place loads the file with that flag |
| 22:15.47 | Corydon76-dig | russellb: a big bug |
| 22:18.50 | russellb | not as big of a bug as ... |
| 22:18.52 | russellb | well, nevermind |
| 22:18.52 | russellb | :-p |
| 22:21.12 | jsmith-teaching | putnopvut: Yeah... I'm in the training room. What's up?\ |
| 22:21.29 | jsmith-teaching | putnopvut: (which explains my slow response) |
| 22:21.47 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.or.comcast.net) |
| 22:22.10 | putnopvut | jsmith-teaching: I'm trying to set up odbc voicemail and was wondering if you could give me a hand. I'm using postgresql, and I knew that's your preferred db... |
| 22:22.28 | putnopvut | Specifically, I'm having difficulty setting up the BLOB for the messages. |
| 22:23.31 | jsmith-teaching | putnopvut: Sure, hold please |
| 22:23.41 | putnopvut | Thanks! |
| 22:24.01 | russellb | putnopvut: did you write the patch? |
| 22:24.11 | jsmith-teaching | putnopvut: Have you read through doc/voicemail_odbc_postgresql.txt by chance? |
| 22:24.14 | putnopvut | russellb: which patch? |
| 22:24.20 | russellb | putnopvut: urgent for odbc ... |
| 22:24.22 | jsmith-teaching | patch? |
| 22:24.23 | putnopvut | jsmith-teaching: yes, I have permissions issues when I type that. |
| 22:24.36 | putnopvut | russellb: no, I'm just trying to make sure I can set it up properly first. |
| 22:24.40 | russellb | ah. |
| 22:24.44 | russellb | mysql ftw, btw |
| 22:24.45 | jsmith-teaching | putnopvut: Oh? Does your database not belong to the user you created? |
| 22:24.51 | jsmith-teaching | russellb: Whatever. |
| 22:24.59 | putnopvut | jsmith-teaching: I um...don't know? |
| 22:25.10 | putnopvut | I guess not. |
| 22:25.21 | putnopvut | Let me see if I can find that out. |
| 22:25.38 | jsmith-teaching | putnopvut: OK, just to test, do this: |
| 22:25.45 | atis_home | oh, rc2 is out |
| 22:26.06 | russellb | atis_home: awesome |
| 22:26.28 | putnopvut | atis_home: you rule, dude! |
| 22:26.38 | jsmith-teaching | putnopvut: (Hold please... gotta get PostgreSQL installed on this lab machine) |
| 22:26.40 | russellb | jsmith-teaching: i think i ate too many brownies at lunch ... |
| 22:26.50 | putnopvut | jsmith-teaching: thanks for helping out. |
| 22:26.53 | russellb | headaccchheeee |
| 22:27.04 | putnopvut | I see that my "asterisk" database is owned by the "asterisk" role. |
| 22:27.08 | jsmith-teaching | russellb: w00t! |
| 22:27.19 | putnopvut | Now if I can just make sure the voicemessages table is in the asterisk database... |
| 22:27.30 | jsmith-teaching | putnopvut: Interesting... and you're logging into postgreSQL as the "asterisk" user, right? |
| 22:27.40 | jsmith-teaching | putnopvut: (where my instructions had "jsmith2") |
| 22:28.07 | putnopvut | That's correct. |
| 22:28.16 | putnopvut | psql -h 127.0.0.1 -U asterisk |
| 22:28.28 | jsmith-teaching | And you get to the postgres prompt? |
| 22:28.34 | putnopvut | That's correct. |
| 22:28.43 | jsmith-teaching | OK, testing it on a virgin machine here |
| 22:28.57 | putnopvut | Awesome. I'll print the error I'm seeing: |
| 22:29.47 | putnopvut | "ERROR: permission denied for language internal" |
| 22:30.05 | putnopvut | This is from the statement "CREATE FUNCTION loin (cstring) RETURNS lo AS 'oidin' LANGUAGE internal IMMUTABLE STRICT;" |
| 22:30.16 | putnopvut | So it doesn't like the LANGUAGE internal part... |
| 22:30.34 | putnopvut | But I don't even know what that means to begin with. I only know the most basic of SQL commands. |
| 22:35.40 | jsmith-teaching | What version of PostgreSQL are you using? |
| 22:35.57 | putnopvut | 8.2 I believe...I'll double check |
| 22:36.24 | putnopvut | 8.2.6 |
| 22:36.30 | jsmith-teaching | Hmmmn... setting it up here |
| 22:37.48 | jdg | Postgres docs says: "To be able to define a function, the user must have the USAGE privilege on the language" |
| 22:38.42 | putnopvut | jdg: Thanks! ...now to figure out how to do that. I'll google some. |
| 22:39.58 | jdg | Postgres docs says: "GRANT { USAGE | ALL [ PRIVILEGES ] } |
| 22:39.59 | jdg | <PROTECTED> |
| 22:39.59 | jdg | <PROTECTED> |
| 22:40.14 | putnopvut | jdg yeah I just found that, and it looks like I need to be a superuser. |
| 22:45.52 | putnopvut | Making myself a superuser seems to have done the trick! Thanks jdg and jsmith-teaching! |
| 22:46.07 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-55-239-242.dhcp.embarqhsd.net) |
| 22:46.17 | jsmith-teaching | putnopvut: Interesting. You learn something new every day |
| 22:46.24 | jsmith-teaching | putnopvut: I'll update my documentation. |
| 23:06.52 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 23:13.15 | atis_home | file: were you asking for some chanspy bt's? |
| 23:13.27 | atis_home | i got one fresh on rc2 |
| 23:13.53 | atis_home | http://pastebin.com/m3265becf |
| 23:14.54 | jsmith-teaching | putnopvut: I've got a patch for you ;-) I'll email it to you, since I can't check it in myself from here |
| 23:15.40 | putnopvut | jsmith-teaching: thanks! |
| 23:19.25 | *** join/#asterisk-dev RoyK (n=roy@ip-182-11-149-91.dialup.ice.no) |
| 23:21.10 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 23:25.38 | atis_home | huh, anybody interested in some chanspy/datastore backtraces? |
| 23:32.24 | russellb | me, i guess |
| 23:32.33 | russellb | just put it on bugs |
| 23:33.22 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 23:33.29 | russellb | and please mention how you made it happen |
| 23:33.34 | russellb | and how easy it is to make it happen |
| 23:33.59 | atis_home | russellb: i'm running automated tests, so it could be several users spying one or something like that |
| 23:34.03 | atis_home | i have no idea |
| 23:34.36 | atis_home | russellb: could you take a look at this http://pastebin.com/m3ea5f399 |
| 23:34.52 | russellb | that's fine |
| 23:34.54 | russellb | i saw it |
| 23:35.05 | atis_home | i just added bt full |
| 23:35.19 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 23:35.20 | russellb | k |
| 23:35.20 | atis_home | anything else i can get, or i should run valgrind? |
| 23:35.24 | russellb | i'll look tomorrow |
| 23:35.39 | russellb | i don't think valgrind will help much on this one |
| 23:35.48 | atis_home | so, i'll post at mantis |
| 23:36.03 | russellb | k |
| 23:36.52 | *** join/#asterisk-dev anthm (n=anthm@68-29-251-63.area4.spcsdns.net) |
| 23:36.52 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:39.20 | *** part/#asterisk-dev dhelder (n=dhelder@widget.gizmolabs.org) |
| 23:41.12 | atis_home | M12187 |
| 23:41.13 | MuffinMan | [new] [Asterisk] Applications/app_chanspy 0012187: Crash in ChanSpy /AST_LIST_TRAVERSE_SAFE_BEGIN reported by atis http://bugs.digium.com/view.php?id=12187 |