| 00:14.31 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 01:04.18 | *** join/#asterisk-dev _eric (i=eric@gorecki.5stops.com) |
| 01:07.27 | *** join/#asterisk-dev troy42 (i=troy@z.paranode.com) |
| 01:27.24 | *** join/#asterisk-dev grimsy (n=chatzill@203-217-17-50.perm.iinet.net.au) |
| 01:49.15 | troy42 | anyone know whether bridging in 1.4 is complete enough for AGI or AMI to add a 3rd or nth participant to a current chan, w/o an ad-hoc conference? |
| 01:49.59 | *** join/#asterisk-dev moy (n=moyhu@189.169.99.88) |
| 01:50.03 | troy42 | been browsing the source to res_features and file's 1.6 bridging stuff |
| 01:56.42 | snuff-work | mm doubt your going to get lot of response.. it is superbowl.. |
| 01:56.49 | snuff-work | ;) |
| 02:17.41 | troy42 | hah, touche |
| 02:17.49 | troy42 | that's the perfect time to be hacking, right? ;-) |
| 02:35.47 | file | troy42: the answer is negative |
| 02:48.51 | troy42 | file: thanks much. is the best way to do a 3-way call still using a dynamically-created conf? |
| 02:49.00 | troy42 | s/best/only/ |
| 02:50.24 | troy42 | and in case no one's said it on super bowl sunday, thanks for the bridging work. |
| 02:51.46 | file | yes, that is the best way in 1.4 |
| 02:51.53 | file | and yay thanks :D |
| 02:52.30 | troy42 | teehee |
| 02:52.42 | troy42 | i gave jbot my last cookie :-) |
| 03:21.10 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:21.10 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:27.59 | troy42 | evening |
| 03:30.44 | tzanger | hello russellb |
| 03:32.42 | jameswf-home | jbot: hug russellb |
| 03:32.42 | jbot | ACTION jumps into russellb's lap and huggles and *hugs* russellb |
| 03:32.43 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 04:07.20 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 04:13.57 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 04:29.07 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 04:29.39 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 04:30.58 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 04:41.49 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 05:50.32 | snuff-work | mm anyone about.. question with codec_zap.. |
| 05:50.51 | snuff-work | now its crashed but i suspect its to do with having a TC400B card |
| 05:51.14 | snuff-work | do i still post on bugs.digium or will you just close it? |
| 05:51.27 | tzafrir_home | snuff-home, or contact support? |
| 05:51.50 | tzafrir_home | do you see anything in the kernel logs? |
| 05:52.04 | snuff-work | mm not for this one |
| 05:52.20 | tzafrir_home | you needed to reboot? |
| 05:53.13 | snuff-work | nope.. thank god.. |
| 05:53.24 | snuff-work | it just nicely segfaulted instead of kern paniced |
| 05:53.50 | snuff-work | 30sec outage vs 5minutes |
| 05:56.51 | snuff-work | posted bug |
| 05:57.11 | tzafrir_home | I suspect this is related to Asterisk, then |
| 05:57.53 | snuff-work | seems to be that its accessing something that may have been free'd.. |
| 05:58.29 | snuff-work | i have my bigger hard kern panic.. but support haven't said more than 10 words to me since i've lodged it 3 weeks ago |
| 06:38.57 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:38.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:44.39 | *** join/#asterisk-dev steliosk (n=Stelios@85.72.95.177) |
| 06:55.57 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:55.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:53.53 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:54.30 | sergee | morning all |
| 07:55.00 | jmls | morning |
| 07:55.09 | sergee | what is the proper way to convert %d to %s? are there any specail ast_* calls? or should i simply use sprintf? |
| 07:56.07 | jmls | very carefully ;) |
| 07:57.57 | mvanbaak | mornin |
| 07:58.29 | jmls | good morrow to you, kind sir |
| 09:00.22 | atis_work | good morning |
| 09:00.30 | atis_work | sergee: i'm using snprintf |
| 09:05.34 | sergee | atis_work: mee too :)) |
| 09:27.37 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 09:28.12 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:46.43 | *** join/#asterisk-dev RoyK (n=roy@213.160.242.90) |
| 10:06.30 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 10:50.23 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 11:14.15 | jmls | using realtime, if there is a uniqueid for a table, shouldn't the engine pass that along as well for a query ? |
| 11:14.36 | jmls | For example, the queuemembers has only "queue_name" passed. |
| 11:14.58 | jmls | I would have thought that the Queue uniqueid would be passed as well |
| 11:51.32 | atis_work | jmls: which query are you refering to? |
| 11:52.48 | atis_work | i think uniqueid is implemented only to queuemembers |
| 11:53.37 | atis_work | you would want queuemembers to contain queue_uniqueid? |
| 12:11.56 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 12:16.21 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 12:24.03 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:33.21 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 12:35.18 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:38.26 | jmls | atis_work: yes |
| 12:38.51 | atis_work | i don't think that there's a point for that |
| 12:39.15 | atis_work | after my patch will get merged, queue members will be queried by queue_name and interface only once |
| 12:39.17 | jmls | if queue_name is unique, why do we need uniqueid in the queues table ? |
| 12:39.18 | atis_work | then by uniqueid |
| 12:39.32 | atis_work | queue_name is not unique |
| 12:39.37 | jmls | _exactly_ |
| 12:39.51 | jmls | but it is queue_name that is passed to the engine for queuemembers |
| 12:39.59 | atis_work | yes |
| 12:40.38 | atis_work | but not only queue_name |
| 12:40.48 | jmls | basicially, what I am saying, is that for realtime, we should use uniqueid for all tables, and all relations |
| 12:40.54 | jmls | and not the other fields. |
| 12:41.24 | jmls | at the moment, we use queue_name for queues, uniqueid for queuemembers, peername for sip, mailbox for voicemail |
| 12:41.45 | atis_work | hmm, logically that would be good |
| 12:41.46 | jmls | etc |
| 12:41.54 | atis_work | but would require lot of changes |
| 12:41.57 | jmls | yeah |
| 12:42.07 | jmls | but it would be much more consistent |
| 12:42.15 | atis_work | plus you would have to keep uniqueid's in every structure |
| 12:42.29 | jmls | a keyfield has to be kept right now |
| 12:42.47 | jmls | queue_members have queue_name |
| 12:43.03 | jmls | so, queuemembers would have queue_uniqueid instead |
| 12:43.22 | mvanbaak | that will be a lot of work |
| 12:43.25 | jmls | so it would be consistent across static and realtime |
| 12:43.34 | mvanbaak | and probably break most realtime installations out there |
| 12:43.46 | jmls | mvanbaak: you could still pass the "old" keyfield |
| 12:43.59 | jmls | uniqueid=foo,queue_name=bar |
| 12:44.41 | jmls | so for a queuemember query/update |
| 12:44.57 | mvanbaak | indeed |
| 12:44.58 | jmls | uniqueid=foo,queue_name=bar,queue_uniqueid=abc |
| 12:45.09 | mvanbaak | ok, less will break ;) |
| 12:45.13 | jmls | heh |
| 12:45.17 | atis_work | jmls, you are speaking too much res_curl :p |
| 12:45.18 | mvanbaak | but still, loads of work |
| 12:45.39 | Corydon76-dig | jmls: you can't pass 2 key fields with the realtime interface |
| 12:46.00 | jmls | Corydon76-dig: I know |
| 12:46.04 | Corydon76-dig | That is precisely why uniqueid was even implemented for voicemail |
| 12:46.41 | Corydon76-dig | Because otherwise, we had 2 columns that together formed a unique key |
| 12:47.07 | jmls | it's just the inconsistencies that are getting me |
| 12:47.18 | jmls | in realtime queue, I use "name" |
| 12:47.35 | jmls | in queuemembers, I use queue_name |
| 12:47.40 | atis_work | btw, i'm not sure that the term "uniqueid" for realtime is the best.. |
| 12:47.44 | Corydon76-dig | Who told you that computers had to be pretty? |
| 12:47.48 | atis_work | it would conflict with uniqueid of channels |
| 12:47.48 | jmls | heh |
| 12:48.16 | jmls | RealtimeUniqueID |
| 12:48.19 | atis_work | :D |
| 12:48.29 | atis_work | i think in db it's called just "id" |
| 12:48.33 | jmls | RealtimeUniqueIDNotTheCallUniqueID |
| 12:48.39 | atis_work | LOL |
| 12:48.51 | jmls | ok, wtf is a "Hello Kitty" interface |
| 12:49.21 | Corydon76-dig | Mandrake has previously been known as the Hello Kitty Linux |
| 12:49.38 | jmls | oh. that's just nice |
| 12:49.44 | jmls | dammit |
| 12:49.47 | jmls | oh. that's just not nice |
| 13:01.59 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 13:21.38 | *** join/#asterisk-dev oej (n=olle@gw-sthlm01.rebtel.com) |
| 13:21.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:27.22 | *** join/#asterisk-dev ZaVoid (n=zavoid@66-95-182-90.client.dsl.net) |
| 13:31.39 | oej | tzafrir? |
| 13:33.01 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 13:43.00 | tzafrir | oej, here |
| 13:43.52 | oej | tzafrir: About the dual core, it wasn't INtel, it was AMD dual core |
| 13:44.35 | tzafrir | Was it a one-time case, or reproducable? |
| 13:44.46 | oej | We have problems on five servers |
| 13:44.51 | tzafrir | Also: what versions (zaptel, asterisk)? |
| 13:45.08 | tzafrir | and what distro/kernel? |
| 13:45.19 | oej | Asterisk 1.2.24, zaptel 1.2.22 |
| 13:45.26 | oej | Centos |
| 13:45.29 | oej | Centos % |
| 13:45.35 | oej | s/%/5/ |
| 13:45.37 | oej | :-) |
| 13:45.57 | oej | We've tested with ztdummy, wctdm and the pri cards |
| 13:46.39 | oej | Dual-Core AMD Opteron 2218 according to cpuinfo |
| 13:47.16 | tzafrir | sounds strange... |
| 13:47.33 | oej | yes, I am tearing my hair on it |
| 13:47.45 | oej | We have a Intel Dual Core that works like clockwork here in the lab |
| 13:48.06 | oej | Taking an AMD dual core out of production now to stress-test |
| 13:53.29 | tzafrir | CPU? chipset? |
| 13:54.16 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 13:55.20 | tzafrir | Do you see 1000 interrupts per second in /proc/interrupts ? |
| 13:55.31 | tzafrir | watch -n1 -d cat /proc/interrupts |
| 13:55.54 | oej | CPU as above, how do I check chipset |
| 13:57.34 | oej | the timer jumps between cpu's on one machine |
| 13:57.38 | mvanbaak | lspci |
| 13:58.30 | oej | What do you need from lspci - this is a HP machine |
| 13:58.46 | oej | AMD K8 Athlon64/Opteron |
| 14:00.01 | oej | Hmm. Should the timer jump between CPU's? |
| 14:01.12 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 14:16.38 | tzafrir | chips made by? nvidia? ati? anyone else? |
| 14:16.55 | oej | Which of them? |
| 14:16.58 | tzafrir | (I have no idea if it is relevant at all) |
| 14:17.02 | oej | A lot of Broadcom |
| 14:34.22 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:34.22 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:34.39 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:34.39 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:35.04 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:35.04 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:35.36 | lmadsen | greetings, salutations, and good tidings! |
| 14:37.21 | tzanger | morning |
| 14:39.51 | mvanbaak | hello mr madsen |
| 14:41.01 | lmadsen | allo boys |
| 14:44.19 | oej | allo Lajf |
| 14:53.10 | lmadsen | oej: oi! |
| 14:59.06 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:59.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:08.23 | *** join/#asterisk-dev ManxPower (n=manxpowe@251.sub-70-222-176.myvzw.com) |
| 15:17.11 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 15:19.55 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 15:19.55 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:22.31 | oej | Seems like an agi script messes up the timer. |
| 15:33.54 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:46.19 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 15:56.26 | mvanbaak | that's...........weird |
| 15:59.56 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 16:03.19 | *** join/#asterisk-dev _Krieger_ (n=krieger@193.39.118.158) |
| 16:03.59 | _Krieger_ | is there any docs on asterisk or callweaver that have specs on such internal functions as ast_{stopstream,streamfile,generator_activate} (what that functions are intended for)? |
| 16:04.10 | *** join/#asterisk-dev Deeewayne (n=dwayne@216.207.245.1) |
| 16:04.10 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:04.58 | mvanbaak | _Krieger_: http://www.asterisk.org/developers/documentation |
| 16:05.31 | mvanbaak | if you have doxygen on your system you can do: make progdocs |
| 16:25.09 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:25.09 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:34.58 | *** join/#asterisk-dev miguel3239 (n=elguerom@h-68-167-124-171.cmbrmaor.covad.net) |
| 16:43.02 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 16:43.02 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 16:44.41 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:46.28 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:59.45 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 17:49.46 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 17:50.17 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 17:50.17 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 18:03.35 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:03.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:04.14 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:05.19 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 18:14.49 | *** join/#asterisk-dev troy42 (i=troy@z.paranode.com) |
| 18:16.01 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 18:16.01 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 18:49.42 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:49.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:51.34 | *** join/#asterisk-dev ManxPower (n=manxpowe@251.sub-70-222-176.myvzw.com) |
| 19:07.34 | *** join/#asterisk-dev _ys (n=yuri@236-069.nat.mns.ru) |
| 19:15.00 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 19:27.29 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 19:38.08 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:38.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:46.03 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:56.20 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 19:56.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:17.08 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:17.22 | *** join/#asterisk-dev RoyK (n=roy@ip-8-8-149-91.dialup.ice.no) |
| 20:35.13 | *** join/#asterisk-dev AdamWest (n=Leif@CPE001d7e2f9574-CM0012c9db3d2e.cpe.net.cable.rogers.com) |
| 20:36.27 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 20:43.02 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 20:45.41 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:59.21 | *** part/#asterisk-dev RoyK (n=roy@ip-8-8-149-91.dialup.ice.no) |
| 21:46.15 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 22:24.32 | *** join/#asterisk-dev Whisk (n=Whisk@82-44-94-242.cable.ubr04.croy.blueyonder.co.uk) |
| 22:34.55 | *** join/#asterisk-dev walhala (n=walhala@asterisk-friends.com) |
| 22:37.32 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 22:58.49 | jmls | Corydon76-dig: ping |
| 23:00.43 | Corydon76-lap | pong |
| 23:00.49 | jmls | hey |
| 23:00.54 | jmls | just wanted to let you know that we have been running in production for nearly two weeks now with res_config_curl for voicemail without a single hiccup. it works fantastically well. Thanks ! |
| 23:01.04 | Corydon76-lap | Excellent |
| 23:01.27 | jmls | we're currently testing realtime queues and queue members. Will keep you informed ;) |
| 23:01.45 | lmadsen | I've been using realtime queues and members for a while now |
| 23:01.50 | lmadsen | they also work well |
| 23:01.59 | jmls | lmadsen: with curl ? |
| 23:02.02 | lmadsen | oh, no |
| 23:02.06 | jmls | ;) me smirks |
| 23:02.43 | jmls | lmadsen: it is really cool. You can have all the benefits of realtime with no db requirements on the asterisk server. |
| 23:03.03 | jmls | we've gone from around 2 segfaults a day with my crappy odbc drivers to zero for the last month |
| 23:03.24 | jmls | so I thought I'd just say thanks to the devs. |
| 23:04.46 | lmadsen | jmls: excellent! guess I've been fairly lucky with the crashing... I found crashes with the ODBC drivers to PostgreSQL, but worked around them by finding out kinda what caused the crash and doing checks to make sure I didn't pass it the data it didn't like |
| 23:05.13 | lmadsen | of course now that I've put it into the standard way of writing dialplans I never see the crashes anymore, but I can't remember exactly what it was that was causing the crashes :) |
| 23:06.04 | jmls | lmadsen: I wasn't so lucky. The damned thing would crash on a query that had been executed before a hundred times. |
| 23:06.10 | lmadsen | eeeesh |
| 23:06.53 | jmls | at least with curl you can now execute application procedure to return the required data instead of just a db query. |
| 23:09.52 | jmls | is there any ay of finding out what dependencies are required for a set of MenuSelect options ? |
| 23:11.22 | jmls | for example, I select func_curl as an option, can I interrogate the selected options for the dependencies required ? |
| 23:14.16 | *** join/#asterisk-dev jsmith-away (n=njsmith@72.21.36.138) |
| 23:14.16 | *** mode/#asterisk-dev [+o jsmith-away] by ChanServ |
| 23:17.42 | snuff-work | mm.. they generally tell you.. like i dont have curl installed and it says req libcurl.. |
| 23:17.48 | Corydon76-lap | jmls: you mean find out what depends upon func_curl? |
| 23:18.05 | Corydon76-lap | or what func_curl depends upon? |
| 23:18.18 | jmls | the latter |
| 23:18.46 | Corydon76-lap | Just highlight the row and look at the bottom of your screen |
| 23:19.02 | jmls | I was wanting to write a program / script to read the menuselect options and spit out a: |
| 23:19.18 | jmls | you need libcurl ... etc |
| 23:19.18 | Corydon76-lap | Then you're looking at an XML parser |
| 23:19.53 | Corydon76-lap | jmls: you can also pass configure options that will make it error out if it doesn't find those packages |
| 23:20.00 | Corydon76-lap | which should save you some time |
| 23:20.37 | jmls | What I am looking to do is to have my dev machine, select the options required and build & test asterisk. |
| 23:21.28 | jmls | then, I want to build a "lite" linux, with only the options / libraries required in order to create my own "Custom Asterisk" so that if there is a problem at work, the techs can simply pop in a cd and rebuild very quickly |
| 23:24.32 | jmls | I'll have to check out these rpm thingies as well. |
| 23:24.39 | jmls | but that is for tomorrow ;) |
| 23:24.41 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 23:24.49 | jmls | sleep is now the order of the day |
| 23:25.01 | jmls | night all |
| 23:33.52 | jsmith | Corydon76-lap: Ping? |
| 23:35.02 | Corydon76-lap | jsmith: pong |
| 23:35.13 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 23:35.35 | jsmith | Corydon76-lap: Which revision contains the fix you referenced in bug 11189? |
| 23:35.53 | jsmith | Corydon76-lap: I didn't see anything on the SVN commit list that looked like it applied |
| 23:36.04 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:36.04 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:37.02 | Corydon76-lap | A100465 |
| 23:37.05 | MuffinMan | [100465] Committed by tilghman on 2008-01-27 17:59:53: When deleting a task from the scheduler, ignoring the return value could |
| 23:37.05 | MuffinMan | : Corydon76, flujan, stuarth` |
| 23:37.25 | Corydon76-lap | That one |
| 23:37.27 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:37.27 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:38.12 | jsmith | Corydon76-dig: Ah, gotcha ;-) |
| 23:38.44 | Corydon76-lap | When dealing with memory corruption issues, where you get corruption can be in a completely different module from where you see a problem |
| 23:38.57 | jsmith | I understand that |
| 23:39.10 | Corydon76-lap | which is why they're so frustrating |
| 23:39.15 | jsmith | Obviously ;-) |
| 23:39.50 | jsmith | Let me guess -- this bug didn't exist in 1.2, right? |
| 23:40.08 | Corydon76-lap | It could have; I honestly didn't look |
| 23:40.30 | Corydon76-lap | Could have existed in 1.0 and previous, too |
| 23:42.31 | Corydon76-lap | The difference is how often we're getting into those situations. The problem of not checking the return value is universal, though |
| 23:43.00 | jsmith | Gotcha |
| 23:43.15 | jsmith | You mean real programmers *actually check* the return values? |
| 23:43.24 | Corydon76-lap | Occasionally |
| 23:43.35 | jsmith | I know... it's easy to forget |
| 23:43.43 | Corydon76-lap | They might also know what the return values actually mean |
| 23:43.56 | jsmith | You get in the habit of assuming there's memory, disk space, and that memory allocations never fail |
| 23:44.15 | Corydon76-lap | Uh, memory allocations never fail... on Linux |
| 23:44.30 | lmadsen | jsmith: you gonna be around for 15-20 more mins? |
| 23:44.46 | jsmith | lmadsen: I should be, unless I get *really* hungry... |
| 23:44.46 | lmadsen | I have a quick question, but wanna finish what I'm doing first |
| 23:44.55 | Corydon76-lap | Well, by default, they don't fail, anyway |
| 23:44.56 | jsmith | lmadsen: For you, I'll stick around 20 minutes |
| 23:45.13 | lmadsen | jsmith: actually, got a second now you can call me? It should really take < 60 seconds |
| 23:45.19 | lmadsen | 6105 |
| 23:45.31 | Corydon76-lap | M6105 |
| 23:45.33 | MuffinMan | [closed] [Asterisk] Core/General 0006105: [patch] misplaced lock and store translators using linked list macros reported by russell http://bugs.digium.com/view.php?id=6105 |
| 23:45.40 | jsmith | Green..... green.... |