| 00:43.48 | snuff-work | grumbles about chan_mobile talk with 6 emails all about commands to execute |
| 03:17.29 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 05:05.04 | *** join/#asterisk-dev errotan (n=errotan@5403E43A.catv.pool.telekom.hu) |
| 05:34.04 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.73) |
| 05:52.03 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 05:52.04 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 05:58.26 | *** join/#asterisk-dev fiddur (n=fiddur@192.121.104.122) |
| 06:06.46 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:06.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:06.56 | *** join/#asterisk-dev Dovid (n=annon@213.8.121.90) |
| 06:44.22 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-22-114.hsd1.sc.comcast.net) |
| 06:44.22 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 06:47.38 | fiddur | Hi. I think I found a bug in realtime sip peers, but I don't understan how anyone could have used it (without rtcachefriends atleast); so I thought I'd hear with you before posting a new issue. It seems the expire-timer isn't reset when a peer re-registers; so when a edvice renews the register before it has expired, it still expires when the timeout is reached, leaving the device unregistered most of the time. see here: http://pastebin.com/m627b9 |
| 06:50.39 | *** join/#asterisk-dev spikie (n=spikie@ven69-2-82-241-121-171.fbx.proxad.net) |
| 06:58.29 | snuff-work | fiddur: best to post to bug tracker.. |
| 06:58.48 | snuff-work | is it the same on trunk? |
| 06:59.08 | snuff-work | if the issue exists on trunk then its most likely to exist in other branches |
| 07:03.26 | fiddur | snuff-work: right now I'm on 1.6.1.2; but I remember I had the same problem in 1.6.0 and I don't find any resolved issues about it... maybe I have to cmoppile a trunk to test it now though.... |
| 07:20.39 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 07:32.36 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:32.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:34.23 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 07:34.23 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 07:53.13 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:53.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:16.24 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 08:16.24 | *** join/#asterisk-dev spikie (n=spikie@ven69-2-82-241-121-171.fbx.proxad.net) |
| 08:16.24 | *** join/#asterisk-dev fiddur (n=fiddur@192.121.104.122) |
| 08:16.25 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.73) |
| 08:16.25 | *** join/#asterisk-dev mohawk (n=ross@host217-40-110-153.in-addr.btopenworld.com) |
| 08:16.25 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 08:16.25 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) [NETSPLIT VICTIM] |
| 08:16.25 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-22e2e921f12eb219) |
| 08:16.25 | *** join/#asterisk-dev jsmith-away (n=njsmith@asterisk/training-and-documentation-guru/jsmith) |
| 08:16.25 | *** mode/#asterisk-dev [+ooo malcolmd snuff-work jsmith-away] by irc.freenode.net |
| 08:55.25 | *** join/#asterisk-dev lmsteffan (n=laurent@114.69.180.59) |
| 09:48.20 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 09:55.46 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 10:35.34 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 10:35.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:42.28 | freddyk | russellb: ping |
| 10:54.42 | freddyk | Qwell: ping |
| 11:25.18 | *** join/#asterisk-dev KazaLite (n=KazaLite@94-193-98-124.zone7.bethere.co.uk) |
| 11:25.23 | KazaLite | hi all |
| 11:25.47 | KazaLite | can you tell me how in comming call is "routed" to my codec? |
| 11:26.13 | KazaLite | i mean which function is called and which function select which codec is need to handle the call? |
| 11:36.53 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:36.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:53.04 | oej | kazalite: that's a way too generic question. Which channel are we talking about? |
| 11:54.33 | KazaLite | say i have a codec....which is loaded and everything is ok...its properly registered....now i make a g729 call, but asterisk does not call my encoder/decored functions |
| 11:55.04 | KazaLite | so i need to check the complete path whether asterisk got the call and searched for the codec to be used |
| 11:55.37 | KazaLite | i am quite sure there would be some function, that would be cheking among registered codecs that which codec it should use |
| 11:56.10 | KazaLite | i dial 500, call is reached till asterisk....but my codec is never used:p |
| 12:26.49 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:26.49 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:58.47 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 12:58.47 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:19.32 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:50.00 | oej | kazalite: Don't start with the source, start with CLI tools and configurations. |
| 13:50.09 | oej | There's a lot of help to be found in the application. |
| 13:52.13 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 13:54.30 | steliosk | Greetings ! I have seen some recent patches on 1.4 for utf8 handling, but still looks like there are issues i.e when using gotoif and an expression that has UTF8 chars. |
| 13:54.56 | steliosk | the expression validates to false all the time |
| 14:01.41 | oej | can you tell us more on what you've done and why? |
| 14:01.56 | oej | sorry, misunderstood |
| 14:02.47 | oej | patches on 1.4 for utf? |
| 14:05.35 | steliosk | oej : reading a variable from an sql db, using * mysql function and then doing an gotoif where the variable is compared to a utf8 string |
| 14:06.00 | steliosk | the result is always false |
| 14:06.21 | steliosk | if i set the variable in the dialplan with the set command it works |
| 14:09.01 | *** join/#asterisk-dev puzzled (n=foobar@188.90.134.167) |
| 14:11.13 | steliosk | before when executing the gotoif with utf8 data i was getting this https://issues.asterisk.org/view.php?id=14498 |
| 14:12.05 | steliosk | is it possible the the same problem exists in the add-ons ? |
| 14:18.52 | oej | Asterisk is not very good in handling utf8, if it works, it is mostly by accident |
| 14:21.06 | seanbright | wtf is the PP7 wizard? |
| 14:22.26 | file | something to keep my sanity while trying to get my house ready for a party on Saturday |
| 14:23.09 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:23.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:24.16 | russellb | party! are we invited? |
| 14:24.33 | file | YES! |
| 14:24.41 | file | I ordered too many sandwiches and wraps... |
| 14:24.59 | file | so if you don't come then I'll have leftovers ;( |
| 14:26.30 | seanbright | PP7 is either a battery, or a weapon in goldeneye 007 |
| 14:27.13 | russellb | aw man, great game. |
| 14:27.53 | seanbright | indeed |
| 14:28.00 | seanbright | it was my designated hangover cure |
| 14:28.22 | file | one of my friends says a happy meal and gatorade is a great hangover cure... |
| 14:28.24 | file | I don't believe her |
| 14:28.52 | russellb | so, eating food and hydrating ... |
| 14:29.03 | file | crazy talk |
| 14:30.41 | seanbright | anything greasy works |
| 14:30.53 | seanbright | gatorade is good too, but it has too much sugar in it |
| 14:31.04 | seanbright | cut it with some water and you're good to go |
| 14:33.04 | *** join/#asterisk-dev jtodd (i=du9qkt2d@ns.fox-den.com) |
| 14:33.04 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 14:43.03 | *** join/#asterisk-dev moy (n=moy@74.12.123.137) |
| 14:50.12 | tzafrir_laptop | hmmm... anybody else having problems with the pre-commit hook? (in dahdi?) |
| 14:50.33 | tzafrir_laptop | I still can't add a file |
| 14:50.45 | tzafrir_laptop | tools/trunk/xpp/astribank_is_starting.c : svn:mime-type is not set |
| 14:50.46 | tzafrir_laptop | but: |
| 14:51.00 | russellb | there are 3 properties you must set i think |
| 14:51.28 | russellb | svn:mime-type, svn:eol-style, and svn:keywords |
| 14:51.33 | tzafrir_laptop | $ svn propget svn:mime-type xpp/astribank_is_starting.c |
| 14:51.33 | tzafrir_laptop | text/plain |
| 14:51.42 | seanbright | propset_txt from the repotools project |
| 14:51.48 | seanbright | it's so wonderful |
| 14:52.01 | tzafrir_laptop | I have my own |
| 14:52.04 | seanbright | svn pl -v xpp/astribank_is_starting.c |
| 14:52.43 | tzafrir_laptop | Properties on 'xpp/astribank_is_starting.c': |
| 14:52.43 | tzafrir_laptop | <PROTECTED> |
| 14:52.43 | tzafrir_laptop | <PROTECTED> |
| 14:52.43 | tzafrir_laptop | <PROTECTED> |
| 14:52.58 | seanbright | hmm |
| 14:53.49 | seanbright | try creating a new file, setting the props, and committing that |
| 14:53.57 | seanbright | maybe that file is just borked for whatever reason |
| 14:54.11 | seanbright | tries |
| 14:54.58 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:54.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:55.56 | seanbright | wfm |
| 14:56.28 | seanbright | (that probably isn't helpful) |
| 14:56.57 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:56.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:57.55 | tzafrir_laptop | ok, that worked. |
| 14:58.46 | seanbright | strange. must be something weird about that file. |
| 14:59.15 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:59.15 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:59.21 | seanbright | the dahdi changelog is going to look awesome during the next release :) |
| 14:59.46 | tzafrir_laptop | that's why my "hello" was outside |
| 15:00.26 | seanbright | ah yes. |
| 15:38.00 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 15:47.11 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:50.01 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:50.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:06.04 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:15.51 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 16:28.17 | *** join/#asterisk-dev xpot-mobile (n=james@66-182-88-85.static.sdyl010.digis.net) |
| 17:22.58 | *** join/#asterisk-dev ctooley (n=ctooley@c-68-52-165-168.hsd1.tn.comcast.net) |
| 17:22.58 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 17:23.55 | *** join/#asterisk-dev stephank (n=traveler@2002:52c5:cf78:7:21c:c4ff:fece:ea94) |
| 17:59.30 | *** join/#asterisk-dev errotan (n=errotan@5403E6F6.catv.pool.telekom.hu) |
| 18:14.28 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 18:19.14 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 18:27.49 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:50.57 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 19:11.40 | philipp64 | got a question about configure... it seems to set CURL_DIR with --with-curl='s value, but I can't find where it gets used anywhere. |
| 19:11.59 | philipp64 | who's familiar with asterisk's configure script? |
| 19:13.46 | seanbright | if it was used it out be in makeopts.in |
| 19:13.54 | seanbright | CURL_DIR=@CURL_DIR@ |
| 19:13.57 | seanbright | but it's not there |
| 19:13.59 | seanbright | so it's not used |
| 19:14.08 | seanbright | the variable itself is set up by AST_EXT_LIB_SETUP |
| 19:14.14 | seanbright | autoconfig/ast_ext_lib.m4 |
| 19:14.20 | seanbright | err, autoconf/ast_ext_lib.m4 |
| 19:18.08 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 19:21.36 | kpfleming | that's just default behavior for all libraries we can find during configure |
| 19:26.01 | philipp64 | if you're cross compiling, you might not have the xxx_config foo in place. you still need to be able to hardwire paths. |
| 19:32.46 | philipp64 | i'll file a bug. |
| 19:39.14 | kpfleming | it's not just paths |
| 19:39.29 | philipp64 | meaning? |
| 19:39.33 | kpfleming | building against some of those libraries requires output from their _config tools to know what compiler flags and linker options to set |
| 19:40.11 | philipp64 | if you're cross-compiling, there's a good chance you want to override those anyway. |
| 19:40.11 | kpfleming | if curl was built against gnutls, for example, we may have to include gnutls libraries in the linker arguments |
| 19:40.12 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 19:40.36 | kpfleming | then just override them by editing makeopts directly |
| 19:40.49 | kpfleming | what is the value of specifying them to configure only to have it spit them out into makeopts? |
| 19:41.21 | philipp64 | well, it maintains the black-boxiness of things. :-) |
| 19:41.24 | kpfleming | but it's not |
| 19:41.37 | kpfleming | because you are going to manually specify everything configure would generate for that library anyway |
| 19:52.54 | *** join/#asterisk-dev zmb (n=zm23@zaara.cuit.columbia.edu) |
| 20:02.23 | philipp64 | curl-config is intrinsically broken. it gets generated at build time, but when you install it via "make install DESTDIR=..." all of the values are wrong. |
| 20:02.56 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 20:07.36 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 20:17.40 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:17.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:17.58 | kpfleming | philipp64: then complain to the CURL people :-) |
| 20:18.53 | seanbright | M15714 |
| 20:18.54 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0015714: Asterisk won't build with curl unless curl_config is present reported by pprindeville (Karma: +4.00) https://issues.asterisk.org/view.php?id=15714 |
| 20:18.58 | seanbright | wheeeeeeeeeeeee |
| 20:19.42 | kpfleming | i see no reason for us to do anything about that; we are following the recommendations of the makers of CURL, which is to use curl_config to learn how to build against it |
| 20:37.48 | zmb | client is connected to the manager interface, /tmp keeps filling with ast-ami-xxxxx (zero byte) files... several files are being created within a minute |
| 20:37.48 | zmb | <PROTECTED> |
| 20:37.48 | zmb | <PROTECTED> |
| 20:38.22 | zmb | <PROTECTED> |
| 20:38.29 | JunK-Y | they should be deleted. |
| 20:39.15 | zmb | did not experience this before upgrading to 1.4.24.. last one used was 1.4.18 |
| 20:39.52 | zmb | no /tmp files if manager client loges in and logs off |
| 20:41.10 | zmb | in 7 minutes there are 93 /tmp/ast-ami files |
| 20:41.44 | zmb | lsof command shows asterisk as using them all |
| 20:41.46 | JunK-Y | when they logged out, the file is not deleted? thats a problem. |
| 20:42.38 | zmb | no, the client does not log off... it is supposed to stay connected to receive event information.. .(using web-meetme cdEnd.php script) |
| 20:43.31 | JunK-Y | so thats normal. |
| 20:43.57 | zmb | 3-4 files in a minute? in /tmp ? all zero bytes? |
| 20:44.20 | zmb | it eats up all the inodes in a week |
| 20:44.31 | JunK-Y | if you get 3-4 connections within a minute, thats normal. |
| 20:44.36 | mvanbaak | JunK-Y !!!!!!!1 |
| 20:44.56 | JunK-Y | they will be deleted when the ami user logs out. |
| 20:45.00 | JunK-Y | mvanbaak: !!!!! |
| 20:45.21 | zmb | client only logs in once |
| 20:45.28 | zmb | and stays logged in |
| 20:45.38 | zmb | it is supposed to get event notifications |
| 20:46.00 | mvanbaak | JunK-Y: how'z you man ? |
| 20:46.03 | JunK-Y | so if you get 1000 ami users and they stay logged in, there will be 1000 files in ur /tmp |
| 20:46.11 | JunK-Y | why not using a proxy instead? |
| 20:46.11 | zmb | also note that when using 1.4.18 this did not occur |
| 20:46.37 | JunK-Y | mvanbaak: nothing, i get braces in my mouth today, its so weird |
| 20:46.42 | mvanbaak | make sure to use an ami proxy that does not create a socket in /tmp either |
| 20:46.48 | zmb | i understand that .. but in this case... only one user... still connected and /tmp/ gets these files constantly growing |
| 20:46.48 | mvanbaak | otherwise you'll end up with the same |
| 20:46.49 | mvanbaak | ;) |
| 20:46.52 | JunK-Y | and tuesday, ive got 2 accidents within 1 hour!!! |
| 20:46.59 | mvanbaak | JunK-Y: wow ! |
| 20:47.18 | JunK-Y | so i pass from 0 to 2 accidnets in my life really quickly! |
| 20:47.20 | JunK-Y | hehhee |
| 20:47.29 | mvanbaak | indeed |
| 20:47.38 | philipp64 | kpfleming: god forbid they might have missed any corner cases... which cross-compilation seems to be filled with. |
| 20:48.08 | kpfleming | but who are we to figure out what the right thing to do is? we can't put that sort of logic/information into a package that just uses curl |
| 20:48.17 | zmb | mvanbaak: ami proxy? asterisk comes with one? i'm not familiar with ami proxy |
| 20:48.31 | philipp64 | there's a word for this: workaround. |
| 20:48.40 | philipp64 | our industry is filled with them. |
| 20:48.43 | kpfleming | and because our configure script generates simple-to-edit files, there is a simple workaround available |
| 20:48.48 | mvanbaak | zmb: no, asterisk does not come with one |
| 20:48.55 | mvanbaak | zmb: but there are a couple out there |
| 20:48.57 | JunK-Y | zmb: no if theres only 1 connected (and events are dispatched to ur application), there will be only one file in ur tmp |
| 20:49.24 | philipp64 | ok, why have CURL_DIR even be present in ./configure if it doesn't get used? it isn't even spit into makeopts. |
| 20:49.30 | philipp64 | that's broken. |
| 20:50.00 | philipp64 | "it doesn't have to be pretty. it just has to work." |
| 20:50.06 | zmb | JunK-Y i wish there was only one :-( asterisk is creating multiple files every minute |
| 20:50.14 | kpfleming | because it's done by a macro that does the same thing for all libraries, and it's not hurting anything |
| 20:50.28 | philipp64 | it's not helping either. :-( |
| 20:50.43 | zmb | tahts why i am here ... should i report this as a bug? |
| 20:50.45 | kpfleming | neither does all the configure script testing for non-Unix shells, but we don't remove that stuff |
| 20:50.45 | Corydon76-dig | philipp64: try the patch I just uploaded |
| 20:50.52 | JunK-Y | zmb: thats not a bug |
| 20:51.03 | JunK-Y | its cause you are getting many ami users. |
| 20:51.13 | Corydon76-dig | philipp64: I found a contributed m4 patch for libcurl detection that might help you |
| 20:51.14 | zmb | there is only one user |
| 20:51.32 | zmb | well.. one user connected to asterisk |
| 20:51.36 | JunK-Y | zmb: i will try ur version to see. |
| 20:51.46 | philipp64 | Corydon76-dig: holy sh*t you type fast! |
| 20:52.07 | philipp64 | oh, wait. shouldn't have told me that. I was much more impressed before. |
| 20:52.07 | mvanbaak | lol |
| 20:52.45 | Corydon76-dig | philipp64: I modified it to conform to our conventions |
| 20:52.59 | zmb | Junk-Y thanks.. really appreciate your help |
| 20:56.04 | Corydon76-dig | philipp64: remember that you need to run the bootstrap.sh to regen configure |
| 20:56.05 | philipp64 | I think the mime-type is wrong on the first file... |
| 20:56.51 | philipp64 | Cannot display: file marked as a binary type. |
| 20:57.14 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 20:57.20 | Corydon76-dig | No, that's intentional |
| 20:57.29 | Corydon76-dig | rerun the bootstrap |
| 20:57.41 | philipp64 | svn:mime-type = application/octet-stream |
| 20:58.03 | philipp64 | so I just need the 2nd and 3rd files? |
| 20:58.33 | Corydon76-dig | Yeah, 1st and 4th get regen automatically |
| 20:59.04 | zmb | JunK-Y should i check back with you here or ? |
| 20:59.28 | JunK-Y | zmb: yes, i just need to finish something first |
| 21:01.54 | philipp64 | building... |
| 21:02.31 | philipp64 | checking for curl-config... no |
| 21:02.32 | philipp64 | checking whether libcurl is usable... yes |
| 21:02.34 | philipp64 | checking for curl_free... yes |
| 21:03.07 | Corydon76-dig | Is that acceptable? |
| 21:03.24 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 21:03.27 | philipp64 | almost... |
| 21:03.51 | jameswf | are the DAHDI coding guidelines the same as the Asterisk coding guidelines |
| 21:04.01 | philipp64 | problem is that libcurl.a lives in $(STAGING_DIR)/lib and libcurl.so lives in $(TARGET_DIR)/lib... |
| 21:04.33 | kpfleming | jameswf: sort of... the dahdi-linux guidelines are really the linux kernel guidelines |
| 21:04.42 | kpfleming | the dahdi-tools guidelines would be the same as the asterisk ones |
| 21:04.44 | Corydon76-dig | philipp64: and which are you compiling against? |
| 21:04.56 | philipp64 | staging. |
| 21:04.59 | russellb | and luckily, the asterisk ones are almost identical to the kernel guidelines in the areas that are applicable |
| 21:05.12 | philipp64 | might need to leave a copy of libcurl.so in staging_dir... |
| 21:05.14 | kpfleming | well, except for some notable changes |
| 21:05.22 | jameswf | kpfleming: mind if I pm |
| 21:05.24 | Corydon76-dig | philipp64: if you're compiling against a static libary, then no problems |
| 21:05.33 | kpfleming | like we prefer to have braces around all conditionals, and the linux standards are only for multi-line conditionals |
| 21:05.36 | kpfleming | jameswf: no, go ahead |
| 21:06.02 | philipp64 | Corydon76-dig: how do you mean? |
| 21:06.06 | Corydon76-dig | philipp64: If that's all you need from us, I can go ahead and commit, then |
| 21:07.31 | philipp64 | even leaving a copy of libcurl.so in the right place (staging_dir) doesn't fix it... hmmm. |
| 21:08.10 | Corydon76-dig | I really can't help you, there. |
| 21:09.42 | philipp64 | hold off on the commit... let me play with it. |
| 21:10.58 | KazaLite | hi all |
| 21:11.07 | KazaLite | can you guys do me a favour? |
| 21:11.20 | Corydon76-dig | Probably not |
| 21:11.28 | tzafrir_laptop | M15454 |
| 21:11.30 | MuffinMan | [new] [DAHDI-tools] General 0015454: [patch] dahdi-tools installes files under /etc/modprobe.d without a .conf extension reported by tzafrir (Karma: +120.50) https://issues.asterisk.org/view.php?id=15454 |
| 21:11.34 | KazaLite | either buy callweaver or get it closed forever |
| 21:11.53 | KazaLite | it has the worst support one could imagine ever in life |
| 21:11.53 | tzafrir_laptop | What do you think about renaming those files? |
| 21:12.05 | Qwell | KazaLite: how exactly do you plan on buying an open source project? and how is that relevant to this channel? |
| 21:12.08 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 21:12.52 | KazaLite | relevant to this channel because couple of days back when i was porting asterisk 1.4 codec to 1.6 you guys were very helpful |
| 21:13.20 | philipp64 | what's the status of 15370? my OCDness needs closure on that. :-) |
| 21:13.31 | russellb | M15370 |
| 21:13.31 | kpfleming | umm.. no, that does not make it relevant to a channel about asterisk source code |
| 21:13.33 | MuffinMan | [feedback] [Asterisk] Core/BuildSystem 0015370: [patch] Repeatedly building the asterisk directory repeatedly downloads the sounds files reported by pprindeville (Karma: +4.00) https://issues.asterisk.org/view.php?id=15370 |
| 21:13.45 | KazaLite | but proting codec to callweaver is just pain in the ass because no documentation is there ... no people who know bla bla bla |
| 21:13.57 | kpfleming | that can't be true, downloads aren't done until 'make install' is run |
| 21:14.16 | Qwell | kpfleming: after a dist-clean |
| 21:14.17 | tzafrir_laptop | KazaLite, callweaver is at #callweaver |
| 21:14.27 | kpfleming | Qwell: no, still not until 'make install' |
| 21:14.37 | Qwell | kpfleming: he's proposing a variable for a cache that stays around after a dist-clean |
| 21:14.53 | kpfleming | then update the bug summary to match what is actually being talked about :-) |
| 21:21.25 | tzafrir_laptop | What's the point of using $(BS) instead of a plain '\' at the end of a line? |
| 21:21.29 | Qwell | grr.. why can't svn propset allow -m directly on URLs? |
| 21:23.01 | philipp64 | if you put backslash at the end of the line, then "make" interprets it as a continuation. if you put $(BS) at the end of the line, then it gets passed through transparently. |
| 21:23.37 | tzafrir_laptop | philipp64, also, what happens if a download is incomplete and you re-download? |
| 21:23.58 | tzafrir_laptop | you have an incomplete copy at the cache dir. Because it exists, no further download is done |
| 21:24.01 | philipp64 | you lost me. |
| 21:24.26 | Corydon76-dig | philipp64: you'd need checksums to verify that the files are complete |
| 21:25.10 | philipp64 | well, for WGET, it usually loads the file into file.part and then renames it to "file" when the download is complete. |
| 21:25.12 | *** join/#asterisk-dev korihor (n=korihor@190.77.83.180) |
| 21:25.17 | Corydon76-dig | Even zero-length files would fail your tests for downloading the version anew |
| 21:25.34 | Corydon76-dig | philipp64: that assumes the latest version of wget |
| 21:25.43 | philipp64 | it's been that way for a while... |
| 21:26.13 | tzafrir_laptop | curl as well? |
| 21:26.25 | Corydon76-dig | You cannot depend upon that without checking the version |
| 21:26.29 | kpfleming | you could have the makefile optionally download the .asc file as well and use gpg to both check that the download is complete and is 'correct' |
| 21:26.45 | kpfleming | although that's way overkill :-) |
| 21:26.48 | tzafrir_laptop | Is there an explicit option to ask it to do that? |
| 21:27.09 | kpfleming | it will fail the signature verification if it's not complete or the contents are changed |
| 21:28.44 | Qwell | kpfleming: I don't know though.. that might be a decent improvement if it was done all the time. I wonder if we could guarantee gpg being installed though |
| 21:28.49 | tzafrir_laptop | checking for md5sums shouldn't be too tricky. |
| 21:28.52 | Qwell | probably not |
| 21:29.04 | tzafrir_laptop | Assuming you know the name of the md5sum tool :-) |
| 21:29.12 | kpfleming | and you have the md5sum already |
| 21:29.14 | Qwell | tzafrir_laptop: there's logic somewhere for that already |
| 21:29.29 | Qwell | forget why.. something with build_tools/ |
| 21:29.34 | kpfleming | just write it in portable sh :) |
| 21:30.07 | Corydon76-dig | Rewrite md5sum in shell commands! |
| 21:30.13 | Qwell | build_tools/make_buildopts_h |
| 21:30.41 | kpfleming | Corydon76-dig: exactly |
| 21:30.50 | kpfleming | but not bash, it has to work in dash and others too |
| 21:30.59 | file | trollsssssss |
| 21:31.08 | Corydon76-dig | and in filesh |
| 21:31.32 | Corydon76-dig | Or is that just called josh? |
| 21:31.52 | kpfleming | snap! |
| 21:31.53 | Qwell | we could POST the contents of the tarball to a Digium server, and have it spit out an md5 for what we POST. |
| 21:32.02 | kpfleming | lol |
| 21:32.07 | kpfleming | that's efficient |
| 21:32.11 | Qwell | extremely |
| 21:32.15 | russellb | only if the md5 server is on our LAN |
| 21:32.21 | russellb | we need to carefully guard it |
| 21:32.38 | tzafrir_laptop | bah, it's sha1sum |
| 21:32.47 | Corydon76-dig | Even better! |
| 21:32.49 | kpfleming | yes, md5 can be cracked, you know |
| 21:33.12 | JunK-Y | md5 collision can happen really quickly. |
| 21:33.40 | philipp64 | well, how about committing it... then filing another bug against the md5 sums? |
| 21:33.59 | Corydon76-dig | How about you fix it first? |
| 21:34.41 | tzafrir_laptop | my 'download_digium()' function basically downloads the sha1 file, |
| 21:34.44 | philipp64 | well... the problem is that if it takes 2-3 weeks to find that it's missing something, it becomes a kind of slow process... |
| 21:34.48 | tzafrir_laptop | runs: if sha1sum -c --status $file.sha1; then return; fi |
| 21:34.48 | kpfleming | how about you just disable all sounds from being downloaded and installed in menuselect and do it yourself? |
| 21:34.54 | Corydon76-dig | tzafrir has a good point about incomplete downloads. Whether you choose to fix it with md5 sums or another technique, you should still address it |
| 21:35.00 | tzafrir_laptop | if successful: we already downloaded before |
| 21:35.12 | tzafrir_laptop | If not: just wget -c |
| 21:35.47 | kpfleming | won't wget check the file length and avoid the redownload as well? |
| 21:36.08 | Corydon76-dig | kpfleming: only if you use --continue |
| 21:36.15 | philipp64 | that assumes that unversioned files don't change... might be better off starting at the beginning rather than continuing. |
| 21:36.45 | Corydon76-dig | I can guarantee you that unversioned files will not change |
| 21:37.11 | Corydon76-dig | If there's a change, we'll increment the version number on the file |
| 21:37.40 | Corydon76-dig | (in the filename, that is) |
| 21:38.43 | philipp64 | looking in http://downloads.asterisk.org/pub/telephony/asterisk/releases/ and the asterisk-sounds file don't have sha's. |
| 21:39.02 | Corydon76-dig | I can fix that |
| 21:46.00 | philipp64 | cobbling up something... can someone else test it? |
| 21:48.23 | tzafrir_laptop | sruffell, here? |
| 21:48.55 | sruffell | I am |
| 21:50.56 | philipp64 | ftp://ftp.redfish-solutions.com/pub/asterisk-bugid15370-1.6%233.patch |
| 21:51.14 | philipp64 | I'll upload... |
| 21:51.15 | tzafrir_laptop | I'd like to merge a few changes to 2.2 |
| 21:51.28 | tzafrir_laptop | Do you use svnmerge there? |
| 21:51.34 | sruffell | I have been...yes. |
| 21:52.02 | tzafrir_laptop | manually merge specific fixes or the other way around? |
| 21:52.14 | sruffell | all manually merged. |
| 21:52.21 | sruffell | svnmerge merge -r xxxx,xxx |
| 21:52.28 | sruffell | so far anyway. |
| 21:52.50 | tzafrir_laptop | ok |
| 22:00.34 | philipp64 | uploaded... into the bug. |
| 22:01.48 | tzafrir_laptop | hmm... I can't seem to write to linux/branches/2.2 in dahdi |
| 22:02.22 | kpfleming | will fix |
| 22:03.21 | philipp64 | M15730 ... can someone take it out of feedback state? |
| 22:03.40 | kpfleming | tzafrir_laptop: should be fixed |
| 22:04.27 | tzafrir_laptop | indeed it is. Thanks :-) |
| 22:04.58 | philipp64 | on another subject... got a DSL card.. the Traverse Technologies Solos card. it has a direct (raw) interface and API. |
| 22:05.27 | philipp64 | seems AAL0 is supported... wonder what would be involved in doing telephony over that, for people connected via copper to a Calix or Tellabs head-end... |
| 22:06.19 | philipp64 | the signalling would have to be either SS7 or Q931.bis over IP... |
| 22:06.37 | philipp64 | or is that too esoteric to interest anyone? |
| 22:07.28 | kpfleming | i suspect so |
| 22:07.29 | kpfleming | especially since actually using it would probably require cooperation from the DSL operator, which is usually unlikely |
| 22:07.36 | philipp64 | that depends. |
| 22:07.44 | philipp64 | for a large RBOC, it's unlikely. |
| 22:07.58 | philipp64 | for a small greenfield CLEC... more likely. |
| 22:08.11 | kpfleming | so the potential userbase is teeny-tiny then :-) |
| 22:08.43 | philipp64 | Corydon76-dig: how does fix look? |
| 22:08.54 | kpfleming | and most CLECs don't operate the DSL infrastructure anyway, they ride on the RBOC's ATM network and DSLAMs |
| 22:09.09 | philipp64 | (wget ... $@ $@.sha1 && sha1sum -c --status $@) || exit 1 |
| 22:09.31 | philipp64 | except in greenfields... where there is no RBOC. |
| 22:09.48 | kpfleming | um... ok |
| 22:09.53 | kpfleming | sure, there are a few of those |
| 22:10.03 | philipp64 | where I live in Idaho, for instance, the whole development is less than 8 years old. |
| 22:10.06 | kpfleming | so now there are like 20 people who would ever use this solution :-) |
| 22:10.30 | kpfleming | right, but in those cases there are better solutions to deploy than simple DSL with voice over ATM |
| 22:10.38 | kpfleming | like... cable :-) |
| 22:10.41 | philipp64 | a rural telco bought the rights to the entire development, and did DSL in the first 4 phases (Tellabs), and PONS (Calix) in the latest 2. |
| 22:11.04 | kpfleming | that wasn't very forward thinking of them |
| 22:11.19 | philipp64 | except that when they bought the rights, they bought that right too... everything is over twisted pair... |
| 22:11.31 | philipp64 | kpfleming: which wasn't? |
| 22:11.51 | kpfleming | deploying DSL |
| 22:11.56 | philipp64 | you can do optical to coax conversion over PONS. |
| 22:12.02 | kpfleming | right |
| 22:12.18 | philipp64 | the distances are short enough that they can do VaDSL. |
| 22:12.25 | seanbright | can't we just 'gzip -t' the sound files to see if they are valid gzip files? |
| 22:12.35 | seanbright | instead of all this sha1 and md5sum stuff |
| 22:12.35 | Qwell | Man telephony geeks like acronyms. |
| 22:12.40 | philipp64 | grrr... I already fixed that. |
| 22:12.58 | seanbright | whatever. i'm going home. |
| 22:13.00 | philipp64 | should have spoken up sooner... |
| 22:13.05 | kpfleming | oh yes, but not as much as the military (qwell) |
| 22:13.27 | Qwell | kpfleming: I just read your sentence above, and like half of it was acronyms. thought it was funny |
| 22:14.24 | philipp64 | nice thing about sha1sum is that it can be a wrapper around "openssl sha1"... which, if built with linux-ocf and the right hardware, is *very* fast. |
| 22:15.53 | seanbright | all of this will need to be tested by mvanbaak on the various bsds as well |
| 22:15.58 | seanbright | ok, really going home now. |
| 22:44.52 | *** join/#asterisk-dev Kobaz (n=kobaz@its.kobaz.net) |
| 22:45.02 | Kobaz | do de do |
| 22:49.19 | tzafrir_laptop | hmm... now svnmerge hangs... |
| 22:49.29 | Kobaz | i gots a question |
| 22:49.33 | tzafrir_laptop | 'svnmerge merge' that is |
| 22:49.39 | Qwell | Kobaz: so ask it... |
| 22:49.43 | Kobaz | yeap |
| 22:49.46 | Kobaz | typeing it out |
| 22:50.18 | Kobaz | anything i do in an 'h' extension, on a 'slow' box, will make asterisk make the server grind to a halt for 20-30 seconds |
| 22:50.49 | Kobaz | if the box is 'really slow' like 500mhz, it will completely lock the box, where a reset is needed |
| 22:51.23 | Kobaz | if I do the same experiments on a dual core 2ghz box, (same asterisk version, linux kernel, etc), nothing bad happens |
| 22:51.59 | Kobaz | soooo... what's a good spot to start debugging |
| 22:52.45 | russellb | o.O |
| 22:52.49 | tzafrir_laptop | Kobaz, is asterisk running with -p ? |
| 22:53.05 | russellb | get a dump of the process when it happens, use gcore and gdb or something |
| 22:53.09 | Kobaz | <PROTECTED> |
| 22:53.20 | tzafrir_laptop | what kernel version? |
| 22:53.36 | Kobaz | 2.6.30 |
| 22:53.38 | Qwell | When you said "everything", you meant stuff that forks? |
| 22:53.42 | Kobaz | and it also happns on 2.6.22 |
| 22:53.49 | Qwell | I see you mentioned TrySystem earlier |
| 22:53.56 | Kobaz | Qwell: yeah, i suppose it's stuff that forks... actually |
| 22:54.03 | Kobaz | TrySystem, ODBC functions |
| 22:54.10 | Kobaz | i think noop's work fine actually |
| 22:54.26 | Qwell | That narrows it down slightly, eh? |
| 22:54.27 | tzafrir_laptop | also: make sure you have the manager interface running, and when you have troubles, try connecting with a remote astman and killing channels |
| 22:54.30 | Kobaz | yeah |
| 22:54.47 | Qwell | Are you sure it's only the h exten that this is happening under? |
| 22:55.00 | Kobaz | let me see |
| 22:55.14 | tzafrir_laptop | alternatively, do you have traces? (verbose logs would do) |
| 22:55.34 | Kobaz | yeah |
| 22:55.38 | Kobaz | it's only on the h extension |
| 22:55.47 | Kobaz | how would i enable tracing |
| 22:57.14 | Kobaz | let me try some more stuff |
| 22:57.23 | Kobaz | it might have happened once or twice in a non-h extension |
| 22:59.15 | Kobaz | hmm |
| 22:59.26 | Kobaz | well, i can't make it happen in a non-h extension right now |
| 22:59.41 | Kobaz | but i had the 500mhz box going... i think when doing a TrySystem anywhere... it would completely lock |
| 23:02.41 | tzafrir_laptop | anybody else having problems with svnmerge? |
| 23:03.30 | kpfleming | it is not the fastest tool in the world, especially over a remote connection |
| 23:04.39 | Kobaz | gcore isn't telling me much |
| 23:04.59 | Kobaz | the deepest info i get is still in base libs |
| 23:05.00 | Kobaz | #5 0xb7be94e5 in start_thread () from /lib/i686/cmov/libpthread.so.0 |
| 23:05.00 | Kobaz | #6 0xb7ce310e in clone () from /lib/i686/cmov/libc.so.6 |
| 23:05.36 | Kobaz | i can kill it with sigquit so it will dump core |
| 23:07.02 | Kobaz | hmm |
| 23:07.10 | Kobaz | without the -p... it doesn't kill the box |
| 23:09.27 | russellb | tzafrir_laptop: did you recently upgrade to svn 1.5 by chance? |
| 23:09.40 | russellb | if so, and you have not disabled interactive conflicts, the script will hang on you if there is a conflict |
| 23:11.25 | Kobaz | Qwell: russellb: I'm not getting anywhere with gdb... i would have to set some breakpoints... if i hang up, and then attach to the process... the time time it attaches, it's in the main thread again |
| 23:11.41 | russellb | thread apply all bt |
| 23:12.24 | Kobaz | hmm |
| 23:12.36 | Kobaz | oh |
| 23:12.39 | Kobaz | didn't know about that |
| 23:12.47 | Kobaz | i'm not familiar at all with debugging threads |
| 23:13.17 | Kobaz | wow there's a lot of threads |
| 23:13.32 | russellb | yeah :-) |
| 23:13.50 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 23:13.50 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 23:13.50 | Kobaz | every single one is in start_thread -> clone |
| 23:13.53 | russellb | i was just thinking that we might be able to see if there was a thread doing something odd |
| 23:13.57 | russellb | o.O |
| 23:14.00 | russellb | that's not very useful :-) |
| 23:14.45 | Kobaz | yeah like |
| 23:14.48 | Kobaz | the box gets so slow |
| 23:14.54 | Kobaz | that the attach takes forever |
| 23:15.01 | Kobaz | even the kill sigquit |
| 23:15.06 | Corydon76-dig | clone is a kernel operation... if it's hanging there, there's something wrong in the kernel structure... probably corruption of some kind |
| 23:15.46 | Kobaz | happens after i dont get any kernel panics or anything |
| 23:16.02 | Kobaz | http://pastebin.ca/1528716 |
| 23:16.06 | Corydon76-dig | or a pthread library mutex is not getting released |
| 23:16.51 | Corydon76-dig | That's not hanging in clone |
| 23:17.13 | Corydon76-dig | That thread is hanging out in nanosleep, and it's as designed |
| 23:17.19 | Kobaz | i never said it's hanging in clone |
| 23:17.38 | Kobaz | all the threads are in clone, at the time i get the core |
| 23:17.42 | Corydon76-dig | [18:13:51] <Kobaz> every single one is in start_thread -> clone |
| 23:17.44 | tzafrir_laptop | russellb, any problem if I just use the original /usr/bin/svnmerge for svnmerge.real ? |
| 23:18.01 | Kobaz | i didn't say it's 'hanging' |
| 23:18.36 | Corydon76-dig | tzafrir_laptop: nope |
| 23:18.53 | Corydon76-dig | tzafrir_laptop: that's exactly what svnmerge.real is, after all |
| 23:19.12 | russellb | well, we have modifications to it ... |
| 23:19.22 | russellb | custom additional options |
| 23:19.27 | Kobaz | anyways |
| 23:19.32 | russellb | so it might be a problem, dunno |
| 23:19.35 | Kobaz | so what are the drawbacks of running without -p |
| 23:19.47 | Corydon76-dig | don't know of any |
| 23:19.49 | *** join/#asterisk-dev DarkRift (n=dark@65.92.169.171) |
| 23:20.07 | Kobaz | without -p, the lockups don't happen |
| 23:20.19 | Corydon76-dig | Then don't use realtime priority |
| 23:20.30 | Kobaz | heh |
| 23:20.31 | Kobaz | k |
| 23:20.31 | Corydon76-dig | Kobaz: are you, perchance, using realtime at all? |
| 23:20.46 | Kobaz | i'm using realtime static configuration from odbc |
| 23:20.55 | Kobaz | but i'm not setting asterisk to realtime prioity |
| 23:20.58 | Kobaz | canary doesn't even run |
| 23:21.36 | Corydon76-dig | because it's possible for a realtime process to cause resource starvation to other processes |
| 23:22.09 | Corydon76-dig | and if Asterisk depends upon the results of those processes, a complete deadlock may result |
| 23:22.11 | tzafrir_laptop | Hmm.... fails. It adds --non-interactive, which breaks prompting for a passphrase |
| 23:22.58 | Kobaz | yeah |
| 23:23.02 | Kobaz | that's what i've seen |
| 23:23.12 | Kobaz | i've had a box run perfectly fine for weeks, months |
| 23:23.20 | Kobaz | and then randomly lock up with asterisk being at 99% cpu |
| 23:23.33 | Corydon76-dig | I'd say nobody should use realtime priority unless they're keenly aware of the repercussions |
| 23:24.07 | tzafrir_laptop | Kobaz, again, do you see anything in the logs? Asterisk writes the logs so it should be able to do that at "lockup time" |
| 23:24.40 | Kobaz | tzafrir_laptop: don't see anything in the logs other than the dialplan... and i enabled core debug and max verbose |
| 23:24.40 | Corydon76-dig | If ANY library uses a busy loop under Asterisk, that will cause resource starvation |
| 23:25.11 | tzafrir_laptop | Kobaz, is it just painfully slow, or completely hang? |
| 23:25.15 | Kobaz | depends on the box |
| 23:25.21 | tzafrir_laptop | in 2.6.30 ? |
| 23:25.28 | Kobaz | on this 1.4ghz box, it will be painfully slow until the h extension is done |
| 23:25.37 | Kobaz | on a 500mhz box, it will completely lock |
| 23:25.44 | Kobaz | i've left it for hours, and it's still dead |
| 23:25.47 | Corydon76-dig | What all is in your h extension? |
| 23:25.48 | Kobaz | 2.6.30. yeah |
| 23:25.59 | Kobaz | Corydon76-dig: some odbc function calls |
| 23:26.05 | Kobaz | simple stuff.. i can paste it |
| 23:26.19 | tzafrir_laptop | odbc uses a subprocess? |
| 23:26.21 | Kobaz | but basically like, updating one row, on a small table, that has an index on the column i'm updating |
| 23:26.22 | Corydon76-dig | Whose ODBC backend are you running? |
| 23:26.27 | Kobaz | the build in one ? |
| 23:26.30 | Kobaz | res_odbc func_odbc |
| 23:26.48 | Corydon76-dig | No, I mean the ODBC driver |
| 23:26.48 | Kobaz | if i do a TrySystem... the same thing happens |
| 23:26.51 | Kobaz | postgres |
| 23:27.30 | Kobaz | ii odbc-postgresql 1:08.03.0200-1 ODBC driver for PostgreSQL |
| 23:27.35 | tzafrir_laptop | Kobaz, can you tell if it is only called once or called in a loop? |
| 23:27.47 | Kobaz | http://psqlodbc.projects.postgresql.org/ |
| 23:27.59 | tzafrir_laptop | This is something you can easily get from a log |
| 23:28.01 | Kobaz | tzafrir_laptop: it's called once in my dialplan |
| 23:28.14 | Kobaz | which log are you looking fr? |
| 23:28.23 | tzafrir_laptop | right. But is that extension getting called again and again? In the same channel? |
| 23:28.43 | Kobaz | oh... no |
| 23:28.46 | Kobaz | it's not an infinite loop |
| 23:28.51 | Kobaz | it just does it's thing in sequence |
| 23:28.53 | Kobaz | and ends normally |
| 23:29.07 | Kobaz | lemme paste |
| 23:29.49 | Kobaz | http://pastebin.ca/1528730 |
| 23:36.12 | Kobaz | well I'm really happy I have a fix for it now... (not using -p) |
| 23:36.29 | Kobaz | it's the default for which ever asterisk init.d script i've been using |
| 23:37.46 | Corydon76-dig | Kobaz: pastebin your /etc/odbcinst.ini |
| 23:38.01 | Kobaz | k |
| 23:38.29 | Kobaz | other things took forever too |
| 23:38.37 | Kobaz | like, using Monitor... and hanging up |
| 23:38.50 | Kobaz | the in/out mixing took forever |
| 23:38.59 | Kobaz | now without -p, it's okay |
| 23:39.08 | Kobaz | # cat /etc/odbcinst.ini |
| 23:39.08 | Kobaz | bogger {~} root# |
| 23:39.44 | Corydon76-dig | Um, perhaps your config is in /usr/local/etc/odbcinst.ini ? |
| 23:39.59 | Kobaz | http://pastebin.ca/1528741 |
| 23:40.02 | Kobaz | i have my /etc/odbc.ini |
| 23:40.54 | Corydon76-dig | Okay, to the driver section, add "Threading=2" |
| 23:40.58 | Kobaz | k |
| 23:42.29 | Corydon76-dig | The default is 3, btw |
| 23:43.26 | Corydon76-dig | This changes how UnixODBC controls concurrency. The default is full serialization of all database queries |
| 23:43.48 | Kobaz | didn't help |
| 23:43.55 | Kobaz | well, didn't help with using asterisk -p |
| 23:43.58 | Corydon76-dig | Try Threading=1, then |
| 23:44.07 | Kobaz | without -p, it seems a little faster |
| 23:44.25 | Corydon76-dig | Yes, it will be faster |
| 23:45.02 | Corydon76-dig | http://www.egenix.com/mailman-archives/egenix-users/2005-October/113974.html |
| 23:45.55 | Kobaz | nope. no affect with -p |
| 23:46.54 | Corydon76-dig | Okay, then it's not that particular issue |
| 23:47.15 | Corydon76-dig | However, that's still a nice little optimization |
| 23:48.33 | Kobaz | yeah |
| 23:57.42 | JunK-Y | :1806 |
| 23:57.44 | JunK-Y | doh |
| 23:59.29 | russellb | there are much worse things to accidentally type into an IRC window ... |