| 00:43.59 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 00:57.14 | snuff-work | man that jw-asterisk guy is well.. damn.. |
| 02:27.50 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 02:31.22 | *** join/#asterisk-dev steliosk (~Stelios@ipa107.2.tellas.gr) |
| 02:57.34 | *** join/#asterisk-dev snuff-work (~aaa@120.17.35.9) |
| 02:57.34 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:34.05 | *** join/#asterisk-dev janinge (j@ninge.net) |
| 05:39.53 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 06:28.32 | *** join/#asterisk-dev niekvlessert (~niek@92.70.112.34) |
| 07:17.26 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 07:17.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:20.05 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:56.39 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 09:38.34 | *** join/#asterisk-dev pyite (~dschreibe@unaffiliated/pyite) |
| 10:25.42 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 10:25.42 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:30.17 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 12:24.35 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:46.33 | *** join/#asterisk-dev jdoe_ (jdoe@falseprophet.ca) |
| 12:46.52 | *** join/#asterisk-dev brookshi1e (mbrooks@65.172.243.127) |
| 12:47.37 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 13:05.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:05.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:06.48 | *** join/#asterisk-dev xpot (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 13:41.45 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:41.45 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:15.45 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:16.48 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 14:43.09 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:43.10 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:52.42 | *** join/#asterisk-dev ccesario (~ccesario@189.88.3.2) |
| 15:04.07 | *** join/#asterisk-dev moy (~chatzilla@74.12.129.100) |
| 15:07.50 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 15:07.50 | *** join/#asterisk-dev xpot (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 15:07.50 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 15:21.41 | Kobaz | leifmadsen: well... hehe... there's always AMI |
| 15:21.43 | Kobaz | er |
| 15:22.03 | atis_work | umm, any hints on what could be wrong with AST_LIST_REMOVE(&moh->parent->members, moh, list); |
| 15:22.21 | leifmadsen | your question is a little too general me thinks :) |
| 15:22.22 | atis_work | $1 = (struct mohdata *) 0x2aaaac1e2648 |
| 15:22.35 | atis_work | $2 = {first = 0x63, last = 0x636f72706b736174} |
| 15:22.40 | Kobaz | atis_work: depends what type moh is.. and if list is your list pointer |
| 15:22.54 | atis_work | i can't print list in gdb |
| 15:23.46 | atis_work | is playing around realtime musiconhold and breaking directories while moh is playin |
| 15:24.08 | Kobaz | well, the reason you can't print it, is it's not a local variable |
| 15:24.10 | atis_work | got a lot of interesting crashes :) |
| 15:24.15 | Kobaz | it's the list pointer in your structure |
| 15:24.31 | Kobaz | you would have to print out the structure members |
| 15:24.42 | atis_work | moh->list = {next = 0x0} |
| 15:24.51 | Kobaz | so you're at the end |
| 15:24.58 | atis_work | ah |
| 15:25.09 | atis_work | so it's already removed |
| 15:25.27 | atis_work | or not |
| 15:25.33 | Kobaz | actually, your one from the end |
| 15:25.46 | Kobaz | if i remember how to read gdb output |
| 15:26.12 | Kobaz | list is pointing to something, that has a next of null |
| 15:27.42 | Kobaz | atis_work: your next mission... |
| 15:28.06 | Kobaz | is help me fix this pri crash |
| 15:28.07 | Kobaz | :P |
| 15:28.08 | Kobaz | http://pastebin.ca/1823838 |
| 15:28.14 | atis_work | haha |
| 15:28.22 | atis_work | ouch |
| 15:28.59 | atis_work | i have no idea what's q921 and how it differs from q931 :D |
| 15:29.03 | Kobaz | so it's an incoming call on a t1, and it runs some dialplan which runs some agi. and then it crashes |
| 15:29.06 | Kobaz | yeah me neither |
| 15:29.30 | Kobaz | and i cant get a consistant reproduction |
| 15:29.39 | atis_work | what does AGI do? |
| 15:29.40 | Kobaz | and this is on a production box... and this is the second time that same crash happened |
| 15:29.42 | atis_work | EXEC what? |
| 15:29.49 | atis_work | Dial? |
| 15:29.49 | Kobaz | so guaratneed it's going to crash again, and often |
| 15:30.01 | Kobaz | yeah, it runs some stuff... figures out who to call. and then does a dial sip |
| 15:30.05 | atis_work | try answering before Dial |
| 15:30.19 | atis_work | some indication problems |
| 15:30.46 | atis_work | i would guess that DAHDI doesn't know how to indicate ringing |
| 15:30.58 | Kobaz | it does know how... most of the time |
| 15:30.59 | Kobaz | heh |
| 15:31.44 | atis_work | just don't indicate.. answer and put r in Dial |
| 15:32.09 | Kobaz | that may work |
| 15:32.13 | Kobaz | i can try |
| 15:32.39 | atis_work | caller's bill will be higher :p |
| 15:33.13 | Kobaz | it's all local |
| 15:33.22 | atis_work | local DAHDI? |
| 15:33.24 | atis_work | :o |
| 15:33.28 | Kobaz | like, pbx to pbx |
| 15:34.13 | atis_work | that's freaking.. good luck debugging :D |
| 15:34.22 | Kobaz | oh |
| 15:34.24 | Kobaz | you know |
| 15:34.28 | Kobaz | i do do an Answer |
| 15:34.45 | Kobaz | since i have to play a track before i do my dialing |
| 15:35.07 | Kobaz | what's weird |
| 15:35.16 | Kobaz | is they have an avaya definity we're hooked up to |
| 15:35.24 | Kobaz | and i have an avaya definity here in the office |
| 15:35.31 | Kobaz | and i've never ever had libpri crash |
| 15:35.45 | Kobaz | it's a much newwer system they got through |
| 15:35.47 | Kobaz | tough |
| 15:35.49 | Kobaz | though |
| 15:36.16 | atis_work | well, then it's strange why there's some indication.. answer would make pure audio go through.. |
| 15:37.08 | atis_work | why didn't you made "bt full"? |
| 15:37.56 | Kobaz | Answer(); Wait(1); Playback(..) AGI() |
| 15:38.02 | Kobaz | i can do one |
| 15:38.41 | atis_work | do it.. it's much more debug than just 'bt' |
| 15:38.48 | Kobaz | yeah i kno |
| 15:38.50 | Kobaz | w |
| 15:39.04 | Kobaz | (gdb) bt fuldf |
| 15:39.09 | Kobaz | er |
| 15:39.11 | Kobaz | http://pastebin.ca/1823849 |
| 15:40.38 | Kobaz | it's crashing because f is out of bounds |
| 15:40.58 | atis_work | (int)f :D |
| 15:41.27 | atis_work | something bad there... |
| 15:41.34 | Kobaz | something very bad |
| 15:41.38 | atis_work | i'm going back to my moh :p |
| 15:41.54 | Kobaz | http://pastebin.ca/index.php |
| 15:41.55 | Kobaz | aw |
| 15:42.06 | atis_work | aw.. pastebin :D |
| 15:42.19 | Kobaz | heh |
| 15:42.22 | Kobaz | f = 0x4 |
| 15:42.29 | Kobaz | on 490 |
| 15:42.58 | Kobaz | i could do a hack of some sort |
| 15:43.14 | Kobaz | if f is 0x4 then just bail from the function |
| 15:43.20 | atis_work | not really.. |
| 15:43.24 | atis_work | it could be 0x234234 |
| 15:43.24 | Kobaz | it crashes with the same value |
| 15:43.27 | Kobaz | yeah |
| 15:43.36 | Kobaz | but this is the second crash, and all the data is the same |
| 15:43.57 | atis_work | how is it assigned? |
| 15:43.59 | Kobaz | no idea |
| 15:44.01 | Kobaz | hehe |
| 15:44.06 | atis_work | well, you got the source |
| 15:44.19 | Kobaz | yeah i do |
| 15:44.27 | Kobaz | need to break some other stuff first |
| 15:44.53 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 15:47.41 | atis_work | i need to fix some stuff :D |
| 15:52.15 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 15:52.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:55.45 | *** join/#asterisk-dev davidbrillert (~aragon125@h216-235-8-130.host.egate.net) |
| 15:58.03 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:58.03 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:02.14 | atis_work | damn, it seems that moh->parent gets corrupted somehow |
| 16:05.33 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 16:05.33 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:06.35 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 16:10.02 | *** part/#asterisk-dev lupine_85 (~lupine_85@unaffiliated/lupine-85/x-7392152) |
| 16:16.43 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:22.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:22.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:24.17 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 16:24.17 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:26.44 | kpfleming | someone on the -users list has a server with 'Dual Zenon' processors |
| 16:27.14 | jsmith | kpfleming: Awesome... I'm holding out for the Quad-Argon ones myself |
| 16:38.30 | Kobaz | stop |
| 16:38.31 | Kobaz | er |
| 16:43.45 | *** join/#asterisk-dev ccesario_ (~ccesario@189.88.3.2) |
| 16:45.42 | russellb | hammertime |
| 16:46.49 | kpfleming | is not wearing hammer pants |
| 16:47.13 | Corydon76-dig | Can't touch this... |
| 16:56.19 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 17:01.00 | jsmith | Corydon76-dig: Question for you re: variable expansion, if you have a second. |
| 17:07.44 | *** join/#asterisk-dev m_c_le (~marcello@2001:470:1f0b:d4b:2e0:4dff:fe6c:9372) |
| 17:25.40 | m_c_le | hi |
| 17:26.02 | russellb | HI!!!!!!!!!!!!!! |
| 17:26.20 | m_c_le | i found one bug in app_voicemail for 1.6.2.6-rc1 |
| 17:26.35 | m_c_le | line 4814 |
| 17:26.55 | m_c_le | ...OR dir = '%s%s/%s/Urgent |
| 17:27.26 | m_c_le | one ' after Urgent is missing |
| 17:27.39 | russellb | Corydon76-dig: I guess that fix went in after the RCs? |
| 17:27.46 | russellb | yeah, that was late last night ... |
| 17:28.16 | russellb | leifmadsen: I think that regression is important enough for another RC. :-( |
| 17:28.40 | leifmadsen | doh! didn't think of that one before the RCs |
| 17:28.49 | m_c_le | and ther is one more |
| 17:28.50 | russellb | same here |
| 17:29.28 | leifmadsen | ok, well I guess this is a good opportunity to "train" everyone how we'll do RCs going forward by using the existing RC and just merging certain changes |
| 17:29.46 | leifmadsen | however, first, I need lunch badly, so once I return we can take this up! |
| 17:29.56 | m_c_le | [Mar 5 17:55:56] WARNING[15622]: res_odbc.c:616 ast_odbc_prepare_and_execute: SQL Execute returned an error -1: 42000: [MySQL][ODBC 3.51 Driver][mysqld-5.0.51a-24+lenny2]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''/var/spool/asterisk/voicemail/default/301/Urgent' at line 1 (246) |
| 17:30.00 | leifmadsen | actually, I guess I can survive long enough to create the tags |
| 17:30.32 | leifmadsen | russellb: so I should just copy the current RCs into new tags right? |
| 17:31.03 | russellb | yeah, trying to see which versions need to be updated first |
| 17:31.12 | leifmadsen | ok cool |
| 17:31.14 | russellb | looks like 1.6.1 and 1.6.2 |
| 17:31.15 | leifmadsen | thanks for looking |
| 17:31.20 | leifmadsen | ok, I'll start with those then |
| 17:31.25 | russellb | so, not 1.4 and 1.6.0 |
| 17:31.50 | leifmadsen | ok coolio |
| 17:38.44 | leifmadsen | russellb: ok, 1.6.1 and 1.6.2 are ready to go. Someone just needs to make the commits and update the ChangeLog between the version notes I added |
| 17:39.44 | russellb | Corydon76-dig: can you please merge that fix into those RC tags and update the ChangeLog with a note for the fix? |
| 17:40.54 | leifmadsen | I'll run the mkrelease scripts after I return from lunch |
| 17:40.55 | leifmadsen | thanks! |
| 17:45.54 | *** join/#asterisk-dev upb (cmpxchg@88.80.13.92) |
| 17:49.28 | upb | hi. can anyone advise about the asterisk build system? Where should i add libraries to be linked and include paths for a res module_ |
| 17:50.48 | kpfleming | otherwiseguy: so when would not ast_rtp_new_source() NOT want to both set the marker bit *and* change the SSRC? |
| 17:52.10 | kpfleming | it seems to me that maybe part of the issue here is that ast_rtp_new_source() should have been changing the SSRC all along but was not |
| 17:53.07 | otherwiseguy | kpfleming: I'm assuming any time the audio source changes as that was the original implementation. I believe there were issues that people left that regarding hold not working properly for instance. the ssrc should definitely not change every time it was called. file originally had it that way, but had to take it out. |
| 17:53.21 | kpfleming | hmm |
| 17:53.28 | kpfleming | then i am confused |
| 17:53.32 | otherwiseguy | one problem is that when asterisk is generating dtmf in a normal bridge, the ssrc would change with every digit press. |
| 17:53.47 | otherwiseguy | because the source of the media changed every time. |
| 17:53.51 | kpfleming | you mean generating DTMF inband? |
| 17:54.26 | otherwiseguy | i mean if you do a dial(SIP/whatever,,hH) or something where asterisk then generates the dtmf itself. |
| 17:54.38 | otherwiseguy | so every rfc2833 digit would have a different ssrc. |
| 17:55.33 | kpfleming | well... that's sort of the right thing to do. if asterisk tries to use timestamps based on the timestamps it was receiving from the peer, without changing SSRC, then when it drops back to bridging audio, it's entirely possible that the timestamps coming from the peer will overlap the ones that asterisk generated |
| 17:55.48 | kpfleming | i have to go downstairs to a meeting, but i think this needs some more discussion |
| 17:56.19 | kpfleming | if asterisk is going to insert packets into the RTP stream, and absorb the ones coming from the stream source, then it *is* a change of media source |
| 17:56.20 | otherwiseguy | SRCUPDATE is sent every time a bridge is started/finished. and it is definitely not right to change the ssrc every time a digit is pressed. it totally breaks most implementations. |
| 17:56.36 | otherwiseguy | yes, but not one that requires a new ssrc. setting the marker bit should be sufficient. |
| 17:56.48 | otherwiseguy | at least in practice. |
| 17:56.55 | kpfleming | doesn't remember enough about what the marker bit indicates to comment |
| 17:57.07 | otherwiseguy | it basically means "hey, something changed!" |
| 17:57.11 | otherwiseguy | watch out1 |
| 17:57.12 | kpfleming | but now i must go |
| 17:57.14 | otherwiseguy | ok |
| 18:12.53 | Corydon76-dig | jsmith: pong! |
| 18:17.38 | jsmith | Corydon76-dig: If my memory serves me right, you were the one to make the changes to the Set() application between 1.4 and 1.6, right? |
| 18:17.58 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:18.04 | jsmith | Corydon76-dig: A friend is reporting to me that in 1.4, he could put double quotes around a value to keep variable expansion from happening |
| 18:18.12 | jsmith | Corydon76-dig: Let me give you an example: |
| 18:18.32 | jsmith | Assuming we have "foo|bar" as a value for the key "test" in the AstDB |
| 18:19.06 | jsmith | He's saying that Set(TEST=${ASTDB(test)}) would only set TEST to foo, which makes perfect sense |
| 18:19.33 | jsmith | but if he did Set(TEST="${DB(test)}) it would set TEST equal to "foo|bar" |
| 18:19.41 | jsmith | used ASTDB instead of DB above... oops |
| 18:19.55 | jsmith | Following so far? |
| 18:24.14 | Corydon76-dig | Yep |
| 18:24.40 | Corydon76-dig | This was because Set, in 1.4, took multiple arguments, which we've eliminated in 1.6 |
| 18:24.57 | Corydon76-dig | unless you have app_set=1.4 in [compat] in asterisk.conf |
| 18:25.08 | Corydon76-dig | In which case, it uses MSet, instead |
| 18:28.02 | Corydon76-dig | jsmith: I suppose that preemptively answered your question? |
| 18:29.49 | jsmith | Corydon76-dig: Nope... the problem is, he's claiming that he can't set it in 1.6 at all if it has a pipe in the value |
| 18:30.13 | jsmith | Corydon76-dig: (I haven't tested, as I only have access to trunk this afternoon... was hoping you could confirm/deny) |
| 18:30.22 | jsmith | Corydon76-dig: (Seems to work fine for me on trunk) |
| 18:30.42 | Corydon76-dig | Ask him if he has app_set=1.4 in [compat] |
| 18:31.09 | jsmith | I checked, he says he doesn't |
| 18:31.44 | Corydon76-dig | What error does he get, if any? |
| 18:32.17 | jsmith | Trying to track that down. |
| 18:32.33 | jsmith | He says it's similar to this one, but this one has enough issues to make me want to cringe: http://freepbx.org/v2/ticket/4100 |
| 18:32.44 | Corydon76-dig | and secondarily, what proof does he have that the value is not getting set? |
| 18:32.57 | jsmith | Again, I'm trying to have him get me logs |
| 18:33.11 | jsmith | I told him to use Verbose() or NoOp() to print the values to the CLI |
| 18:33.20 | Corydon76-dig | I mean, is the issue that the value isn't getting set, or is it that his application no longer works because he's using pipes to separate application arguments? |
| 18:34.29 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:34.31 | jsmith | No, in this case, the problem appears to be that the value isn't getting set |
| 18:34.39 | Corydon76-dig | jsmith: I think you need to stop being tier1 support and just send him into #asterisk |
| 18:35.05 | jsmith | Corydon76-dig: I don't do that to friends... too many bad experiences, to be blatantly honest |
| 18:35.31 | Corydon76-dig | jsmith: Well, I'd be very interested to see those logs, then |
| 18:35.38 | jsmith | Corydon76-dig: Anyhoo, sorry to bother you... just looking for ideas |
| 18:35.59 | Corydon76-dig | jsmith: My idea is that he's doing something wrong |
| 18:36.30 | jsmith | That's my best guess as well, but I thought I'd ask you, since you obviously know a lot more than I do |
| 18:36.36 | Corydon76-dig | What, I don't know, but as soon as I see logs, it will probably be blatantly obvious |
| 18:37.06 | Corydon76-dig | Also, which 1.6 is he using? |
| 18:37.37 | Corydon76-dig | Saying he's using 1.6 is as clear as saying that he using version 1 |
| 18:37.38 | jsmith | Don't know that either... still waiting for him to come back online so I can get more details |
| 18:37.44 | jsmith | I know |
| 18:38.47 | kpfleming | 1.6.0.-42 |
| 18:39.01 | kpfleming | otherwiseguy: back |
| 18:39.12 | otherwiseguy | kpfleming: welcome |
| 18:39.15 | otherwiseguy | doh |
| 18:39.26 | kpfleming | so... maybe part of the problem here is that ast_rtp_new_source() is mis-named |
| 18:39.30 | otherwiseguy | i really need to rain myself not to hit control-return here. |
| 18:40.06 | otherwiseguy | ast_rtp_new_source() is "that which is called when we get a SRCUPDATE" from what I can tell. |
| 18:40.34 | kpfleming | right |
| 18:40.50 | kpfleming | but you don't actually call it when you are really switching to a new source |
| 18:40.56 | kpfleming | only when the source has 'updated' something |
| 18:42.44 | otherwiseguy | correct. and it may be "technically correct" (which I have on the highest authority is the best kind of "correct") for us to update the ssrc when we switch back and forth between asterisk generating the audio and passing it on from the other side. But if no one likes getting packets with new ssrc all the time, it doesn't really matter if we are "technically correct". |
| 18:43.01 | kpfleming | right |
| 18:43.16 | kpfleming | so... i'd suggest renaming ast_rtp_new_source() to ast_rtp_source_update() |
| 18:43.28 | kpfleming | and then adding ast_rtp_source_change(), and possible AST_CONTROL_SRCCHANGE |
| 18:44.00 | otherwiseguy | and it apparently is something that everyone thinks should be done, at first. So far it has been changed back and forth 2 or 3 times now. :-) |
| 18:44.43 | kpfleming | well... it could go either way. SSRC means 'synchronization source', and as long as both sources of media are synched to each other, there is not any need to change ssrc just because you changed media sources |
| 18:45.19 | kpfleming | and our RTP stack does use the same timestamp space as the incoming media for generating RFC2833 packets, so it's 'in sync' |
| 18:50.53 | otherwiseguy | I can go ahead and split out the update/change into a different control frame and function instead of overloading the SRCUPDATE with data if you prefer. I was just trying to avoid adding another similar frame type that is only going to be used in one very specific instance. |
| 18:52.40 | kpfleming | but repurposing an existing control frame to do something different is bad |
| 18:52.56 | kpfleming | if the name was not so specific, sure |
| 18:53.04 | otherwiseguy | Well, I'm just repurposing it to do what it was originally purposed to do, though. ;-) |
| 18:53.11 | kpfleming | no, you aren't |
| 18:53.19 | otherwiseguy | It originally changed the ssrc. |
| 18:53.24 | kpfleming | rigth |
| 18:53.29 | kpfleming | but that was wrong |
| 18:53.48 | otherwiseguy | if I pile up enough wrongs, eventually something right has to happen. |
| 18:53.49 | kpfleming | so let's define it clearly: SRCUPDATE means we received a marker bit without an SSRC change, or we need to generate one |
| 18:54.03 | otherwiseguy | sounds good. |
| 18:54.04 | kpfleming | SRCCHANGE means we received a marker bit *with* an SSRC change, or we need to generate one |
| 18:54.41 | otherwiseguy | but, how will I confuse anyone with my code if I am that explicit? |
| 18:54.47 | kpfleming | snickers |
| 19:11.59 | *** join/#asterisk-dev korihor (~korihor@201.210.226.98) |
| 19:20.51 | otherwiseguy | chan_sip.c |
| 19:20.59 | otherwiseguy | woah, wrong window there. |
| 19:22.12 | russellb | there are much worse things to type into the wrong window. |
| 19:24.11 | otherwiseguy | this is true. What i'm not quite sure of is how it changed to the wrong window in the middle of typing 'vim channels/chan_sip.c' |
| 19:25.56 | ctooley | otherwiseguy, an incorrectly handled [TAB]? |
| 19:27.24 | ctooley | I do that all the time on this stupid keyboard due to incorrectly sized keys |
| 19:32.42 | seanbright | like your password |
| 19:32.51 | seanbright | which i hvave done |
| 19:32.59 | seanbright | like last week |
| 19:33.00 | seanbright | heh |
| 19:33.16 | ctooley | Worse than my password... my ssh key passphrase. |
| 19:33.52 | ctooley | got to spend the next 6 hours renovating authorized_keys files one day. |
| 19:37.36 | otherwiseguy | learned the hard way that `rm -rf .*` is not a good way to delete all the hidden files in /root |
| 19:38.02 | otherwiseguy | stupid .. directory. |
| 19:38.37 | ctooley | :-) |
| 19:42.09 | otherwiseguy | man the whitespace in addons/chan_ooh323.c is attrocious |
| 19:45.19 | kpfleming | it's C... you could remove all of it |
| 19:45.25 | russellb | not all of it |
| 19:45.30 | russellb | int a; |
| 19:45.36 | kpfleming | most of it then |
| 19:45.40 | russellb | agreed :-) |
| 19:45.57 | kpfleming | all non-quoted repeated spaces/tabs, all line endings that aren't in macros |
| 19:47.23 | otherwiseguy | kpfleming: the changes you requested are making the patch must bigger. :-p |
| 19:47.28 | kpfleming | of course |
| 19:47.31 | kpfleming | bigger == gooder |
| 19:47.32 | otherwiseguy | Obviously, bigger is better though. |
| 19:47.37 | otherwiseguy | doh, you beat me to it. |
| 19:52.02 | otherwiseguy | It's the times that I make a comment change to files like frame.h that I really appreciate ccache. |
| 19:53.37 | kpfleming | indeed |
| 19:55.22 | *** join/#asterisk-dev xpot-mobile (~xpot@66.60.101.91) |
| 19:57.39 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 20:15.57 | upb | hm.... |
| 20:17.02 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:17.22 | upb | i wonder if this chat is for * developers or could someone spare a minute to help out a guy who doesnt work at digium ?:P |
| 20:21.56 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 20:22.39 | otherwiseguy | kpfleming: ok, new version with AST_CONTROL_SRCCHANGE posted for your viewing pleasure. |
| 20:22.51 | kpfleming | pleasure? yeah, sure. |
| 20:26.09 | |Rain| | does all of 1.6.x use the event subsystem? |
| 20:28.13 | |Rain| | (ast_event_*) |
| 20:29.51 | Kobaz | no |
| 20:32.17 | kpfleming | bye-bye, gtkconsole! |
| 20:33.09 | seanbright | sucks |
| 20:33.12 | seanbright | i miss it already |
| 20:53.14 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:53.14 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 20:53.37 | Deeewayne | is chan_telepathy done yet ? |
| 20:54.20 | seanbright | it is res_telepathy |
| 20:54.32 | Deeewayne | smacks forehead |
| 20:54.35 | Deeewayne | seanbright, thanks! |
| 20:54.55 | seanbright | don't make those kinds of mistakes in the future |
| 20:54.59 | seanbright | you make us all look silly |
| 20:55.01 | seanbright | :P |
| 20:55.09 | kpfleming | that's not hard to do |
| 20:55.20 | Deeewayne | I guess I should have asked in #asterisk too |
| 21:01.53 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 21:04.39 | |Rain| | eek. |
| 21:04.51 | |Rain| | cached events are badly broken in 2.6.[12].x |
| 21:05.30 | Kobaz | some more info would be helpful |
| 21:07.29 | |Rain| | working on a bug report, but the short version is that ast_event_cmp() doesn't set a payload type in ie_val, so every match_ie_val only checks for the presence of an IE (AST_EVENT_IE_PLTYPE_EXISTS = 0) |
| 21:07.33 | seanbright | and howto instructions to build your time machine would be useful as well |
| 21:07.56 | seanbright | since you're a full major version ahead of us |
| 21:08.20 | |Rain| | oops |
| 21:08.21 | |Rain| | :) |
| 21:08.37 | kpfleming | |Rain|: that's already been fixed |
| 21:10.03 | |Rain| | doh |
| 21:10.56 | |Rain| | I didn't see anything relevant last time I looked at the changelog, but it's been a bit (I had some other stuff to do before I could actually look at this bug very hard) |
| 21:11.10 | seanbright | commit asterisk 240411 |
| 21:11.12 | kpfleming | it's probably only in the latest -rcs |
| 21:11.13 | MuffinMan | [240411] Committed by russell on 2010-01-15T20:41:11.813938Z: Ensure payload type is properly checked when comparing against cached events. |
| 21:11.13 | MuffinMan | .. |
| 21:11.13 | MuffinMan | ..(closes issue #16607) |
| 21:11.13 | MuffinMan | ..Reported by: ddv2005 |
| 21:11.13 | MuffinMan | ..Patches: |
| 21:11.15 | MuffinMan | .. event.patch uploaded by ddv2005 (license 769) |
| 21:11.18 | MuffinMan | .. |
| 21:11.20 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=240411 |
| 21:11.41 | |Rain| | danke |
| 21:16.17 | |Rain| | in that case, my fix for 16660 should work fine |
| 21:17.25 | kpfleming | seanbright: language! such language... |
| 21:17.29 | seanbright | hmm? |
| 21:17.34 | kpfleming | 'whip it out' |
| 21:17.37 | seanbright | heh |
| 21:17.47 | seanbright | you should have seen what was after that |
| 21:17.50 | seanbright | i censored myself |
| 21:17.59 | seanbright | just for you prudes |
| 21:18.00 | seanbright | heh |
| 21:20.30 | russellb | The_Boy_Wonder: your latest commit has invalid XML documentation |
| 21:20.42 | russellb | bamboo tests for it and shows the error, but for some reason, it didn't fail the build |
| 21:20.54 | russellb | you have been spared. |
| 21:21.03 | russellb | unless I fix bamboo before you fix the docs! |
| 21:21.30 | Deeewayne | are there odds for this race ? |
| 21:22.39 | |Rain| | hrm. I'm a little confused -- from #16607, it looks to me like the fix was merged into 1.6.1 and 1.6.2, but it's really not in any 1.6.2.x release yet (judging by the diffs between versions, anyway.) does something else need to happen for a fix to make it into a release? |
| 21:22.59 | kpfleming | time |
| 21:23.02 | Qwell | Deeewayne: I'll give you 2.5:1 on Deeewayne |
| 21:23.02 | |Rain| | or is it just a matter of security issues prompting all the releases since 1.6.2.2 and no other changes being included because of that? |
| 21:23.04 | Qwell | err, The_Boy_Wonder |
| 21:23.06 | Qwell | points out that he has root on bamboo, and can hinder the fixage |
| 21:23.43 | Qwell | |Rain|: time needs to pass |
| 21:25.30 | |Rain| | is there some set period of time that needs to pass (and if so, does someone actually test release releases in svn?), or has there just not been enough developer time to make it all happen yet? |
| 21:26.07 | russellb | The_Boy_Wonder has been idle for 32 minutes, odds are on me at this point. |
| 21:26.16 | Qwell | russellb: see above :p |
| 21:26.29 | kpfleming | |Rain|: release candidates get made, they wait for community feedback, they get turned into releases |
| 21:26.30 | russellb | yeah, but I have giant drumsticks that could be used as weapons |
| 21:26.40 | kpfleming | when sceurity release get made, they delay that process |
| 21:27.21 | |Rain| | ok. so the delay really is ultimately due to the only releases since the bugfix being security releases. |
| 21:27.28 | russellb | yes |
| 21:27.39 | |Rain| | fair enough, danke |
| 21:29.53 | kpfleming | huh... airtran starting up direct flights between HSV and BWI |
| 21:30.00 | kpfleming | now seanbright has no excuse for not visiting |
| 21:33.40 | Corydon76-dig | other than their safety record, back when they were known as ValuJet? |
| 21:35.45 | |Rain| | <PROTECTED> |
| 21:35.46 | |Rain| | <PROTECTED> |
| 21:35.47 | |Rain| | ha, LIAR! |
| 21:36.17 | russellb | aw what the heck ... bamboo shows the failure, but blames me since the build was manually triggered by me |
| 21:36.24 | russellb | pouts |
| 21:42.29 | seanbright | Corydon76-dig: there are no everglades between BWI and HSV, so i think i'm safe |
| 21:42.36 | seanbright | or was that Jet Blue?/ |
| 21:42.57 | Corydon76-dig | No, it was AirTran |
| 21:43.01 | Qwell | seanbright: Make sure your pilot has had his heart checked recently. |
| 21:43.22 | Kobaz | arent there usually two pilots |
| 21:43.25 | Corydon76-dig | http://en.wikipedia.org/wiki/ValuJet_Airlines |
| 21:43.36 | Qwell | Kobaz: plus the passenger in the back to taxi you back to the gate just in case |
| 21:43.42 | Qwell | ...apparently that's how United rolls. |
| 21:43.51 | Qwell | ...based on my recent travel experience |
| 21:44.28 | Kobaz | lets start astiair |
| 21:44.35 | seanbright | god no |
| 21:44.52 | seanbright | unless the engines are refcounted |
| 21:45.04 | Qwell | refcounted properly* |
| 21:45.47 | Corydon76-dig | The problem wasn't the pilots; it was the illegal storage of oxygen tanks in the cargo hold |
| 22:00.33 | kpfleming | russellb: PRINT MODE ERROR |
| 22:01.17 | russellb | starts smashing stuff with a giant drumstick |
| 22:01.35 | seanbright | it's friday |
| 22:02.07 | russellb | working on bamboo stuff sometimes is as exciting as watching paint try |
| 22:02.13 | russellb | make a tweak, watch asterisk build again ... |
| 22:02.31 | Corydon76-dig | It builds remarkably fast, though |
| 22:02.33 | russellb | OH LOOK AT THAT, IT TURNED A .c INTO A .o ! |
| 22:02.37 | russellb | indeed. |
| 22:03.40 | Corydon76-dig | Who can turn a C into an I? Who can turn an I into an O? It's not too hard to see, it's G-C-C! |
| 22:04.02 | Corydon76-dig | (with apologies to Tom Lehrer and the Electric Company) |
| 22:08.42 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 22:25.28 | *** join/#asterisk-dev mnick86 (~mnick86@95-90-248-233-dynip.superkabel.de) |
| 22:40.44 | seanbright | could we put editline in thirdparty and svn:external'ize it? |
| 22:41.31 | kpfleming | absolutely |
| 22:42.19 | seanbright | cool |
| 22:49.11 | seanbright | could i have access to do that? |
| 22:49.22 | seanbright | or one of you add it to the todo list? |
| 22:49.59 | kpfleming | i can do that while i'm waiting on a build... hang on |
| 22:51.13 | kpfleming | thirdparty/editline now exists, you should have permissions to it |
| 22:51.21 | seanbright | thanks |
| 22:51.28 | kpfleming | it's empty, doesn't even have any structure yet |
| 23:01.59 | *** join/#asterisk-dev korihor (~korihor@201.210.226.98) |
| 23:02.56 | seanbright | mmmkay |
| 23:04.31 | wedhorn | mvanbaak: another patch for skinny rtp. Should be fine now. |
| 23:28.54 | mnick86 | do we have a document "how to write a unit test" ?! |
| 23:29.26 | russellb | mnick86: see include/asterisk/test.h ... there is documentation there |
| 23:29.32 | russellb | also see tests/test_skel.c |
| 23:30.05 | mnick86 | allright, thanks |
| 23:32.59 | mnick86 | do we create a new file in tests/test_ .c for a new unit test, or do we code it inside the related file like app/app_ and use "ifdev TEST_FRAMEWORK" |
| 23:47.32 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 23:47.32 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |