| 01:19.43 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 01:39.34 | *** join/#asterisk-dev jsmith (n=jsmith@library.xwi.xmission.com) |
| 01:39.34 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 01:57.42 | paravoid | hrm, format_mp3 compiled with 1.4.12.1 headers segfaults on 1.4.11 |
| 01:57.46 | paravoid | i.e. abi change |
| 02:04.36 | paravoid | russellb: you broke the ABI on struct ast_filestream with r81599 |
| 02:04.45 | paravoid | you added a member to the middle of the struct |
| 02:05.05 | paravoid | so external modules compiled with older versions (in my case, format_mp3) crash |
| 02:10.44 | tzanger | SWEET |
| 02:10.48 | tzanger | I love when people break ABI |
| 02:11.50 | jsmith | ABIs... just like Grandma use to break... |
| 02:12.12 | tzanger | hahaa |
| 02:17.14 | russellb | paravoid: alright, well let me look at changing it in the morning |
| 02:17.26 | tzanger | come on russellb just leave it |
| 02:17.29 | tzanger | force everyone to upgrade |
| 02:17.30 | paravoid | I fixed it for our version |
| 02:17.35 | tzanger | or at least recompile |
| 02:17.38 | paravoid | I just moved orig_chan_name to the end of the struct |
| 02:17.45 | tzanger | man no food and 2 beer just leave me *FUCKED* |
| 02:17.52 | tzanger | I had no idea I was such a lightweight without food |
| 02:18.03 | russellb | paravoid: ah, right, good point ... |
| 02:18.13 | russellb | ok, i can just do that |
| 02:18.28 | paravoid | runtime-tested with format_mp3 and worked |
| 02:18.37 | russellb | makes sense |
| 02:18.41 | russellb | thanks for pointing it out |
| 02:19.38 | paravoid | of course, now you'll break the ABI with 1.4.12 :) |
| 02:19.53 | paravoid | i.e. modules compiled against 1.4.12(.1) will not work with 1.4.13 |
| 02:19.54 | russellb | heh, i suppose so |
| 02:21.06 | russellb | well, not sure which is worse |
| 02:21.25 | paravoid | I'd say keep the ABI that the whole 1.4.0 cycle had |
| 02:21.52 | paravoid | those that recompiled modules for 1.4.12 will probably recompile them for 1.4.13 too... |
| 02:21.52 | russellb | that's what i'm thinking, too. |
| 02:24.44 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 02:26.01 | paravoid | russellb: what happened with the release cycle discussion? |
| 02:26.06 | paravoid | did you reach a consensus? |
| 02:26.22 | russellb | pretty much have |
| 02:26.28 | russellb | i documented it this week |
| 02:26.47 | russellb | passed it to a few other developers, then going to publish to the -dev list later this week |
| 02:27.18 | paravoid | ah, nice |
| 02:30.29 | paravoid | btw, I added a really crude hack on our tree |
| 02:30.45 | paravoid | to build IMAP and ODBC variants of app_voicemail (and app_directory) |
| 02:31.00 | russellb | ha |
| 02:31.15 | paravoid | I'm building them as app_voicemail_imap.so and app_voicemail_odbc.so |
| 02:31.21 | russellb | heh, that's what i figured |
| 02:31.28 | russellb | and default modules.conf lines that noload 2 of them? |
| 02:31.33 | paravoid | yep |
| 02:31.42 | paravoid | but even if you don't have that, asterisk refuses to load them |
| 02:31.47 | paravoid | because they provide the same applications |
| 02:31.56 | paravoid | Voicemail(), VoicemailMain() etc |
| 02:32.09 | russellb | right, assuming it gracefully exits and doesn't have bugs in the code when load fails :) |
| 02:32.25 | russellb | that's a common place where modules potentially leak all kinds of memory and such |
| 02:32.39 | paravoid | I don't know about leaking memory, but it doesn't crash :) |
| 02:32.43 | paravoid | it's a hack |
| 02:32.57 | russellb | cool, well that's the best you can do with what's there |
| 02:32.57 | paravoid | but it was the only way to provide packages with IMAP and ODBC support for voicemail |
| 02:33.07 | Qwell | I've done that too, heh |
| 02:33.11 | paravoid | it'd be great if this was a runtime option |
| 02:33.12 | Qwell | for file and odbc |
| 02:33.21 | Qwell | paravoid: we're trying to get there |
| 02:33.33 | paravoid | with minivoicemail etc.? |
| 02:34.00 | paravoid | or is this irrelevant? |
| 02:34.46 | russellb | that's sort of the other thing people want to do with voicemail |
| 02:34.55 | tzanger | damn you guys are still talking about voicemail |
| 02:34.58 | russellb | there is making it runtime changeable, and configuratble per mailbox |
| 02:35.11 | russellb | and then there is also wanting to break it up into multiple apps for more dialplan control |
| 02:35.39 | russellb | so, 2 things sort of being worked on, to some degree, at least |
| 02:37.15 | russellb | the ast_storage stuff is coming along niely |
| 02:37.18 | russellb | nicely* |
| 02:37.30 | paravoid | what's that? |
| 02:37.31 | russellb | not sure if anyone is working on minivm right now, though |
| 02:37.40 | paravoid | oh, the first part |
| 02:37.48 | russellb | a storage API for that, yeah |
| 02:37.49 | Qwell | paravoid: splits out all the storage stuff - not just voicemail - into an API |
| 02:37.51 | russellb | among other things |
| 02:38.00 | paravoid | interesting |
| 02:38.02 | Qwell | so even playback/record and such could use it |
| 02:38.08 | russellb | yeah, pretty neat stuff |
| 02:38.11 | paravoid | btw, what's with astobj2? |
| 02:38.14 | russellb | what about it |
| 02:38.22 | Qwell | in theory, everything that plays a file - you could just have a config option that says to play all files from odbc or whatever |
| 02:38.28 | paravoid | I did a diff on {1.4.11,1.4.12}/include to check for ABI issues |
| 02:38.35 | russellb | oh, ha |
| 02:38.43 | paravoid | and saw astobj2 |
| 02:38.46 | russellb | right. |
| 02:39.15 | russellb | i needed to use reference tracking to fix some bugs in chan_iax2, introduced by the multithreading changes made for 1.4 |
| 02:39.43 | russellb | and that had been being worked on for a long time |
| 02:39.51 | russellb | and has been in a developer branch |
| 02:39.58 | russellb | so i opted to just bring it in so i could use it to fix the problems |
| 02:41.09 | russellb | shouldn't cause any ABI issues, though. |
| 02:41.19 | paravoid | oh yes, I know it won't |
| 02:41.30 | russellb | well, i guess a 1.4.12 chan_iax2 wouldn't work with asterisk 1.4.11 ... |
| 02:41.34 | paravoid | I'm just curious of what it is :) |
| 02:41.41 | russellb | gotcha |
| 02:41.45 | Qwell | russellb: should it be expected to? |
| 02:41.55 | paravoid | nah, who cares if chan_iax2 would work :) |
| 02:42.01 | russellb | :( |
| 02:42.04 | russellb | i like iax2 ! |
| 02:42.34 | paravoid | oh, I like it too; I meant who cares if 1.4.12 chan_iax2 would work on older versions :) |
| 02:42.53 | russellb | hA |
| 02:43.40 | paravoid | I'm trying to merge all of our patches in a way or another |
| 02:43.49 | paravoid | but it's not going to be easy |
| 02:43.55 | paravoid | some need extensive changes |
| 02:44.10 | paravoid | e.g. I want to completely refactor the module loader |
| 02:44.40 | paravoid | it's inefficient now and this triggers a bug of libopenh323 |
| 02:47.42 | symlink | we just rewrote it ... |
| 02:47.47 | paravoid | you did? |
| 02:47.58 | paravoid | oh, I haven't been following trunk |
| 02:48.03 | symlink | I mean in 1.4 |
| 02:48.05 | russellb | not in trunk |
| 02:48.07 | russellb | some people did for 1.4 |
| 02:48.15 | paravoid | oh, it's "buggy" in a sense |
| 02:48.42 | paravoid | in many senses actually :) |
| 02:48.48 | symlink | do tell |
| 02:49.10 | paravoid | a) RTLD_NOLOAD | RTLD_NOW | RTLD_LOCAL is a no-op |
| 02:49.31 | paravoid | this is undocumented, but apparently _NOLOAD is for _LOCAL/_GLOBAL only |
| 02:50.02 | paravoid | at least for glibc |
| 02:50.23 | paravoid | hrm, wait, I had a mail prepared to asterisk-dev that never got through |
| 02:50.29 | paravoid | I was trying to send it for days without success :) |
| 02:50.57 | paravoid | probably because my mailman subscription has disabled delivery |
| 02:52.09 | paravoid | sent again |
| 02:54.40 | paravoid | russellb: regarding the ABI break, should I submit a bug report or you'll remember it? |
| 02:54.51 | russellb | i should remember |
| 02:54.57 | paravoid | ok |
| 02:57.10 | paravoid | mail still not getting through :/ |
| 02:59.42 | tzanger | http://ph3.info/images/Img427.jpg |
| 02:59.46 | tzanger | there we go |
| 03:06.14 | russellb | heh |
| 03:07.52 | paravoid | any ideas why my mail doesn't get through? |
| 03:08.04 | paravoid | I enabled delivery on mailman, just to be sure |
| 03:09.21 | russellb | i don't knw, but i think we have been having some issues since we moved into our new building |
| 03:10.16 | russellb | kpfleming posted some building pics to flickr: http://flickr.com/photos/kpfleming |
| 03:10.35 | paravoid | it's like the 10th time I'm trying to sent this mail |
| 03:11.19 | paravoid | nice :) |
| 03:13.16 | paravoid | btw, 2.6.23 is (finally!) out :) |
| 03:26.29 | snuff-work | holy crap.. i thought it would take rc10 :P |
| 03:27.18 | snuff-work | 4meg changelog.. bigger than others i remember |
| 03:30.38 | paravoid | symlink: I can't get the mail through, so, basically my biggest problem for a totally unrelated reason) was that the dynamic loader loads and unloads modules all the time |
| 03:30.51 | paravoid | i.e. if you have chan_foo.so |
| 03:31.03 | paravoid | it will do something like that: |
| 03:31.03 | paravoid | <PROTECTED> |
| 03:31.03 | paravoid | <PROTECTED> |
| 03:31.03 | paravoid | <PROTECTED> |
| 03:31.04 | paravoid | <PROTECTED> |
| 03:31.18 | paravoid | which should just be |
| 03:31.19 | paravoid | <PROTECTED> |
| 03:31.19 | paravoid | <PROTECTED> |
| 03:31.52 | paravoid | and for res_foo.so (= a module that is providing global symbols) |
| 03:31.56 | paravoid | it will do |
| 03:31.56 | paravoid | <PROTECTED> |
| 03:31.56 | paravoid | <PROTECTED> |
| 03:31.56 | paravoid | <PROTECTED> |
| 03:31.57 | paravoid | <PROTECTED> |
| 03:32.22 | paravoid | 4 dlopens instead of just the first two |
| 03:33.15 | symlink | how would you propose it be changed? |
| 03:34.26 | paravoid | well, I told you how it's supposed to work |
| 03:34.36 | paravoid | in terms of libc calls |
| 03:34.42 | paravoid | I'll try to work on a patch |
| 03:34.58 | paravoid | I was trying to get a mail that explains the problems in case I've missed something |
| 03:35.02 | paravoid | before I started working on this |
| 04:01.11 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 04:24.41 | *** join/#asterisk-dev denon (n=denon@208.122.43.201) |
| 05:01.54 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 05:39.58 | *** join/#asterisk-dev jtodd (n=jtodd@204.11.231.198.static.etheric.net) |
| 06:21.51 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 06:25.35 | *** join/#asterisk-dev denon (n=denon@208.122.43.201) |
| 06:38.31 | *** join/#asterisk-dev denon (n=denon@208.122.43.201) |
| 06:46.08 | *** join/#asterisk-dev IvanV3835 (n=Miranda@styx.mcn.ru) |
| 07:08.16 | *** join/#asterisk-dev gk1 (n=Greg@pool-72-87-135-18.lsanca.dsl-w.verizon.net) |
| 07:56.40 | *** join/#asterisk-dev rati (n=rati@124.125.254.227) |
| 08:00.15 | *** join/#asterisk-dev snuff-work (n=bradl@61.29.30.137) |
| 08:28.37 | *** join/#asterisk-dev tengulre (n=tengulre@222.90.66.10) |
| 08:52.51 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 08:52.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:21.03 | *** join/#asterisk-dev agallo (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:34.01 | mvanbaak | anyone alive ? |
| 10:39.18 | *** part/#asterisk-dev agallo (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:44.34 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 10:56.39 | key2 | yes |
| 11:06.22 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 11:27.56 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 11:30.14 | jmls_away | no |
| 11:59.41 | rati | whats meaning on inbond call and out bond call |
| 12:00.04 | rati | hey key2 u r alive na |
| 12:00.32 | SimonPerreault | mmm? |
| 12:00.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:01.12 | *** join/#asterisk-dev harryr (n=harryr@77.240.56.17) |
| 12:03.58 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 12:06.52 | key2 | rati: is it a dev question? |
| 12:08.09 | mvanbaak | what's kevins email again ? |
| 12:45.52 | *** join/#asterisk-dev SimonPerreault (n=simon@ringo.viagenie.ca) |
| 12:46.34 | *** part/#asterisk-dev SimonPerreault (n=simon@ringo.viagenie.ca) |
| 12:48.56 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 12:57.08 | *** join/#asterisk-dev hermuli (n=Eladamri@xdsl-83-145-207-63.nebulazone.fi) |
| 13:03.37 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 13:12.05 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 13:17.14 | codefreeze | looks like today will be a "Trouble Communicating with Digium" day! |
| 13:21.49 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:23.57 | blitzrage | morning all! |
| 13:25.56 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:35.35 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-443beb8869e20611) |
| 13:35.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:36.29 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.168.48) |
| 13:38.12 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:38.12 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:39.57 | *** join/#asterisk-dev Juggie (n=Juggie@99.224.171.141) |
| 13:50.25 | jmls | mmm. You can set a var in sip.conf, yes .. |
| 13:50.53 | jmls | where is this variable set ? |
| 13:51.08 | jmls | as in, in what structure does it reside .. |
| 13:51.15 | jmls | because it's not a channel |
| 13:51.22 | symlink | wha? you mean setvar? |
| 13:52.43 | jmls | symlink: yes |
| 13:53.35 | symlink | there is a list of variables on either the user or peer structure, when the call is authenticated and the channel created in Asterisk the list is iterated through and each variable set |
| 13:53.55 | jmls | what I want to do is to change the value of a variable defined in there |
| 13:54.29 | jmls | or even add a variable to the list |
| 13:55.04 | symlink | you can't manipulate that from the dialplan |
| 13:55.08 | jmls | bugger |
| 13:55.28 | jmls | would be nice. You can simulate it by using astdb I suppose |
| 14:06.00 | *** join/#asterisk-dev SimonPerreault (n=simon@ringo.viagenie.ca) |
| 14:06.25 | *** part/#asterisk-dev SimonPerreault (n=simon@ringo.viagenie.ca) |
| 14:10.51 | *** join/#asterisk-dev callguy (n=callguy@pool-72-70-79-233.bstnma.east.verizon.net) |
| 14:12.25 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.155.185) |
| 14:25.17 | *** part/#asterisk-dev IvanV3835 (n=Miranda@styx.mcn.ru) |
| 14:27.46 | codefreeze | where oh where did digium jabber go? |
| 14:28.12 | codefreeze | oh where, oh where, did it go? |
| 14:28.13 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:34.05 | blitzrage | another moving pain.. :( |
| 14:34.26 | blitzrage | ok, going to get some breakfast .... grocery shopping time again! |
| 14:48.41 | codefreeze | file: you cut off, too? |
| 14:49.02 | symlink | yes, as is everyone else I bet |
| 14:49.18 | codefreeze | symlink? |
| 14:49.51 | codefreeze | hmmmm. how.... symbolic |
| 14:51.07 | *** join/#asterisk-dev xpot (n=jim@c-71-195-241-115.hsd1.ma.comcast.net) |
| 15:01.42 | *** join/#asterisk-dev joetester (n=joeteste@216.191.34.13) |
| 15:02.11 | joetester | Hey russellb! I finally got that "core show locks" for the sip deadlock! |
| 15:04.08 | joetester | Whoops he's not around is he? |
| 15:04.13 | joetester | Where is everyone? |
| 15:04.36 | putnopvut | I don't know? |
| 15:04.48 | putnopvut | That shouldn't have ended with a question mark. |
| 15:05.19 | joetester | Hey put! |
| 15:05.25 | joetester | Didn't see you. |
| 15:10.42 | *** join/#asterisk-dev miguel3239 (n=elguerom@h-68-167-124-171.cmbrmaor.covad.net) |
| 15:12.14 | putnopvut | Here's joetester's core show locks output: http://pastebin.ca/731950 |
| 15:19.32 | joetester | It's the first time I see none of the "Corydons" around. |
| 15:20.11 | symlink | indeed |
| 15:24.01 | *** join/#asterisk-dev _mihai_ (n=_mihai_@ool-4573271f.dyn.optonline.net) |
| 15:24.08 | _mihai_ | hi all |
| 15:25.44 | *** join/#asterisk-dev Corydon76-home (i=five@pdpc/supporter/bronze/Corydon76-home) |
| 15:25.44 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 15:25.53 | symlink | Corydon76-home: aha there you are! |
| 15:25.56 | symlink | _mihai_: hola |
| 15:26.29 | *** join/#asterisk-dev Corydon76-dig (i=grey@pdpc/supporter/bronze/Corydon76-home) |
| 15:26.29 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 15:26.43 | putnopvut | That's two...waiting on lap or vcch... |
| 15:28.46 | _mihai_ | so guys, I hear some rumors on the -dev list ... something about problems with IAX and jitterbuffer |
| 15:28.56 | _mihai_ | and I tend to get nervous when I hear that... |
| 15:29.12 | _mihai_ | does anybody have more info on this? |
| 15:33.03 | russellb | _mihai_: i wish i had more to tell you |
| 15:33.21 | russellb | various people report lockups of asterisk when they turn on the jitterbuffer in iax.conf |
| 15:33.31 | russellb | but i haven't had access to any system with the problem to figure out any more than that |
| 15:34.00 | _mihai_ | that's weird... we're using that combination on a daily basis and we haven't noticed anything |
| 15:34.11 | russellb | yeah, tons of people are |
| 15:34.29 | _mihai_ | plus we stress-tested the crap of it, again with no problems |
| 15:34.35 | russellb | if you're willing to look at it, could you post to the -dev list and ask people to speak up that have seen the problem? |
| 15:35.00 | _mihai_ | sure |
| 15:35.02 | _mihai_ | will do |
| 15:35.21 | russellb | i haven't bugged you guys directly about it because i had no info to give you |
| 15:36.40 | _mihai_ | oh well, I'll see if i can get more info |
| 15:36.46 | russellb | awesome |
| 15:36.58 | _mihai_ | any of the people who reported this ever hang out on this channel? |
| 15:40.34 | *** join/#asterisk-dev ManxPower (n=manxpowe@120.sub-70-223-120.myvzw.com) |
| 15:41.02 | symlink | _mihai_: I doubt it |
| 15:41.15 | russellb | not that i can think of |
| 15:42.37 | russellb | there used to be a bug about it ... |
| 15:42.40 | russellb | i can't find it though |
| 15:42.48 | russellb | must have been closed by someone since it was reported against 1.2 originally |
| 15:43.06 | russellb | and we were hoping 1.4 would fix whatever it was, guess it didn't |
| 15:45.53 | _mihai_ | oh well, we'll see how it goes ... |
| 15:46.19 | _mihai_ | please let me know if you find the bug... or any other info for that matter |
| 15:49.12 | blitzrage | ohio |
| 15:49.56 | Qwell | interesting. the -users list booted me over the weekend |
| 15:50.45 | russellb | same here |
| 15:53.18 | joetester | Whoa that sip deadlock has been going at it like crazy since this morning. |
| 15:53.24 | Juggie | sigh |
| 15:53.36 | Juggie | phoenix was an expensive phone bill. |
| 15:54.22 | mvanbaak | there was no sip there ? |
| 15:54.41 | Juggie | there was if you brought a wifi phone or whatver i mean my cell phone bill |
| 15:54.48 | Juggie | i have roaming data, roaming text messages, etc. |
| 15:56.22 | joetester | Hey mvanbaak I have a cisco question |
| 15:58.20 | mvanbaak | joetester: shoot |
| 15:58.58 | *** join/#asterisk-dev jsmith (n=jsmith@68.178.10.62) |
| 15:58.58 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:03.09 | russellb | i had a bug like that once. |
| 16:03.39 | bmd | heisenbug |
| 16:03.44 | russellb | and it turned out to be a macro that didn't properly use braces or something |
| 16:04.36 | bmd | http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs |
| 16:05.27 | *** topic/#asterisk-dev by russellb -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@misery.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release expected November 2007 -=- Tier 2 and Tier 3.14159 support is in #asterisk -=- New Digium Building: http://flickr.com/photos/kpfleming/sets/72157602339837221/ |
| 16:06.12 | jsmith | codefreeze: When you get done with that bug, I have some dialplan pattern-matching questions for you |
| 16:06.42 | codefreeze | I've been santa claus!! Checking it twice, thrice, ten times. Comments in attempt_transfer in chan_zap.c, and comments in ast_bridge_call in res_features.c; with them both, all is well. Without either/both, all is messola. |
| 16:07.40 | codefreeze | jsmith-- ask away. Don't be surprised, tho, to see messages of aggravation and despair interspersed throughout the day! |
| 16:08.09 | jsmith | codefreeze: Give me a second to test one thing, and then I'll bug you |
| 16:08.25 | bmd | who's writing res_telepathy? |
| 16:08.29 | russellb | codefreeze: symlink Deeewayne putnopvut Qwell Corydon76-dig ... 1.4.13 signage plz |
| 16:09.22 | Qwell | bmd: you are |
| 16:09.22 | blitzrage | I am |
| 16:09.22 | russellb | i am |
| 16:09.22 | symlink | russellb: aight |
| 16:09.22 | russellb | putnopvut: is the advisory published? |
| 16:09.22 | putnopvut | yes. |
| 16:09.22 | codefreeze | dont look at me, nobody WANTS to know WHAT I'M THINKING at the moment! |
| 16:09.22 | russellb | thank you |
| 16:09.22 | putnopvut | And the release is signed. |
| 16:09.24 | Juggie | hmmmm |
| 16:09.31 | putnopvut | published as in, on downloads.digium.com |
| 16:09.36 | Juggie | get this, 400kb of data in the usa cost me 20.45! |
| 16:09.37 | putnopvut | Not sent to mailing lists yet. |
| 16:09.42 | codefreeze | russellb: ok, I'll take a moment off AGGRAVATION, and sign. |
| 16:09.50 | russellb | heh, ok |
| 16:09.50 | Qwell | done |
| 16:10.10 | snuff-away | hehehe.. Juggie see its not the voip business where the money is.. its mobiles and roaming fees :P |
| 16:10.13 | bmd | what sorta things will res_telepathy be able to do? |
| 16:10.38 | symlink | signed |
| 16:10.40 | Juggie | snuff-away, clearly, my cell phone bill is 272$ this month. |
| 16:10.43 | russellb | you don't already know? |
| 16:10.50 | russellb | res_telepathy needs some more work, then |
| 16:10.56 | bmd | har |
| 16:11.19 | bmd | I'm assuming it's this: http://telepathy.freedesktop.org/ |
| 16:12.02 | snuff-away | btw.. with documenting of * variables.. i've got a list i'm going to start working with in the next week or so :) |
| 16:12.41 | bmd | I think dbus isn't a bad idea for exporting some of asterisk apis to third party apps |
| 16:12.42 | jsmith | snuff-away: You saw doc/channelvariables.txt, right? |
| 16:13.15 | snuff-away | yes but.. i've also just grepped out every chan_helper.. in source to check against :P |
| 16:14.00 | jsmith | Ah, very nice |
| 16:15.48 | Juggie | i'm just happy fastagi/agi seems to be working all happy for everyone again |
| 16:16.09 | snuff-away | *gone sleep for real now* |
| 16:17.47 | codefreeze | russellb: murf's sig is done |
| 16:18.04 | russellb | okie dokie. |
| 16:19.17 | brookshire | hi |
| 16:19.18 | brookshire | :) |
| 16:20.14 | Qwell | brookshire: can you hit my lights? :p |
| 16:20.30 | Qwell | (I kid..) |
| 16:20.45 | Juggie | hah |
| 16:20.55 | Juggie | dont you keep your office dark like all geeks |
| 16:21.05 | Qwell | I wish |
| 16:21.19 | Juggie | the only light in my office is out in the hallway, i had them turn off the two in my office |
| 16:21.28 | Juggie | and then there is also one i can control which is off |
| 16:22.28 | Qwell | haha |
| 16:22.40 | Qwell | brookshire walked over to my office, and hit the switch :P |
| 16:22.53 | Qwell | I love being in the same building as everybody else again. |
| 16:23.12 | symlink | because you can make other people your slaves? |
| 16:23.18 | Qwell | well, no |
| 16:27.24 | brookshire | mmmmm... sweet tarts and gold coins for lunch! |
| 16:28.17 | brookshire | blitzrage!!! |
| 16:28.31 | brookshire | the whole reason i even got on irc |
| 16:29.14 | symlink | brookshire: you didn't come to say hi to me? sad. |
| 16:29.34 | brookshire | nope, i find you on jabber |
| 16:33.43 | *** join/#asterisk-dev gaspiz (n=gaspiz@86.35.240.238) |
| 16:34.54 | gaspiz | hi: rookie question I know but what is the param for unified diff format? diff -???? old_version new version? |
| 16:35.04 | russellb | -u |
| 16:35.05 | symlink | diff -u |
| 16:35.13 | gaspiz | thanks ;) |
| 16:35.15 | symlink | svn diff is also nifty |
| 16:35.35 | jsmith | codefreeze: Never mind about the pattern matching... I was right all along, and the person who told me otherwise was obviously wrong ;-) |
| 16:35.57 | *** join/#asterisk-dev wunderkin (n=wunderki@ip72-223-86-126.ph.ph.cox.net) |
| 16:38.37 | codefreeze | Perhaps, someday, jsmith, you will reveal to me this mystery over a root beer or sprite. |
| 16:39.51 | *** part/#asterisk-dev _mihai_ (n=_mihai_@ool-4573271f.dyn.optonline.net) |
| 16:41.05 | Juggie | could you kick the ugly pastel orange off it too? |
| 16:41.12 | Juggie | orange gradient. |
| 16:41.21 | russellb | i like the orange |
| 16:41.28 | russellb | in fact, it is an official digium|Asterisk color |
| 16:41.31 | russellb | so, get over it |
| 16:41.32 | russellb | :-p |
| 16:41.35 | Juggie | orange is fine, orange to purple gradient, eugh. |
| 16:41.38 | putnopvut | I'm still adjusting to having to like orange. |
| 16:42.39 | codefreeze | If only it could emit the SMELL of a newly peeled orange.... ahhhhh..... |
| 16:42.41 | Juggie | just the look & feel though, seems like it was designed in 1998 |
| 16:43.25 | jsmith | I know, I know... mktg already knows my opinion on it too |
| 16:43.28 | russellb | if you would like to help design another one, contact our marketing department. |
| 16:43.31 | blitzrage | brookshire: ACK !!! |
| 16:43.44 | Juggie | russellb: i'm no designer. |
| 16:44.05 | russellb | ok, well in the open source world, you don't get to complain without providing alternatives :) |
| 16:44.38 | blitzrage | sure you do! |
| 16:44.40 | codefreeze | hey, howabout, instead of just orange, it's got that orange peel dimple texture to it? |
| 16:45.51 | codefreeze | with maybe an occasional fruit fly or something |
| 16:47.16 | jsmith | codefreeze: Sounds good to me... orange peeled back in a semi-asterisk-shaped manner?!? |
| 16:49.39 | codefreeze | uh, no, but that sounds neat, too |
| 16:50.37 | russellb | this chair is not very comfortable. |
| 16:50.41 | russellb | needs more cushion, badly |
| 16:50.44 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 16:50.53 | blitzrage | more cushion for the push'n! |
| 16:51.03 | putnopvut | exactly! |
| 16:51.12 | Qwell | russellb: I kinda like them... |
| 16:51.39 | blitzrage | welp... off to write documentation I suppose |
| 16:51.40 | blitzrage | :) |
| 16:51.45 | blitzrage | either that... or a nap |
| 16:51.45 | jsmith | blitzrage: w00t! |
| 16:51.47 | russellb | i would like it with more cushion. |
| 16:51.52 | Qwell | blitzrage: document the nap |
| 16:52.06 | blitzrage | Step 1: lay down in a horizontal position |
| 16:52.14 | blitzrage | Step 2: seriously... turn off your laptop and get off IRC |
| 16:52.22 | Qwell | oh...hmm.. I've been doing it all wrong |
| 16:52.26 | blitzrage | indeed |
| 16:52.33 | blitzrage | that's why we have docs! |
| 16:52.45 | Juggie | build a bed under your desk like george when he worked for the yankees |
| 16:52.51 | blitzrage | heh |
| 16:52.56 | Qwell | Juggie: already on it |
| 16:53.21 | Juggie | Qwell, you would fit anywhere :) |
| 16:57.44 | russellb | we have a nap area, sort of |
| 16:57.54 | russellb | but they were sneaky, and made the chairs kinda stiff |
| 16:57.59 | russellb | so you can't get _too_ comfortable |
| 17:01.12 | russellb | in fact ... i think i'm going to lay down and work from my laptop for a little bit |
| 17:08.17 | russellb | that wasn't very successful |
| 17:08.45 | blitzrage | lol |
| 17:09.18 | blitzrage | I need a bed that lets me have a tray and arm rests so I can lay down flat and have the laptop facing down to me so I don't have to strain my neck |
| 17:09.35 | blitzrage | the arm rests would be used to keep my arms up high enough to reach the keyboard |
| 17:09.40 | russellb | yeah, nice |
| 17:12.05 | ManxPower | go ask Google if they have any? 8-) |
| 17:14.06 | codefreeze | don't they have 'glasses' that can act as a viewscreen these days? |
| 17:18.11 | codefreeze | and two flexible usb cloth keypads. One on your left, one on your right. No armrest. Although hitting the left shift may not coordinate with a right keypress of P, say.... |
| 17:23.16 | symlink | moo. |
| 17:31.10 | *** join/#asterisk-dev mitcheloc (n=mitchel@adsl-67-127-235-238.dsl.irvnca.pacbell.net) |
| 17:34.07 | Netgeeks | hey, quick question concerning stack corruption from too many nested macros. is this a per call concern, or a concern overall for a single instannce of asterisk? In other words is it just a limit for each call, or is it a limit that is affected not only by the number of nested macros as well as the number of concurrent calls executing those nested macros? |
| 17:34.27 | russellb | per-call |
| 17:34.41 | Netgeeks | hrm, strange |
| 17:34.47 | russellb | unless you're on a very small embedded platform |
| 17:34.50 | russellb | then things could get more interesting |
| 17:35.52 | Netgeeks | nah my dev and test environment is a moderate platform, 2G mem, 3GHz cpu... and the production environ is much more, 4G mem, dual core 2 duo xeons... |
| 17:36.07 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 17:36.07 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 17:37.33 | Netgeeks | the 'hrm, strange' was due to the fact that I have a hard problem causing the failure in the test environment, but I put the same source code and same dialplan on my production environment and I get the corruption almost immediately |
| 17:38.23 | Netgeeks | no big deal, tho, just was wondering the original question I had, thanks |
| 17:38.24 | russellb | Corydon76-dig: were you in agreement with me in regards to version naming, or do we need to look at it some more? |
| 17:38.31 | russellb | Netgeeks: np |
| 17:38.59 | Corydon76-lap | russellb, I'd really like to see something a bit more obvious |
| 17:39.21 | Corydon76-lap | russellb, that's why I brought up using 1.5 as the release candidates |
| 17:39.45 | russellb | well, calling 1.6.0 release candidates 1.5 only helps part of the issue |
| 17:39.48 | russellb | you still have 1.6.3-rc1 |
| 17:39.58 | russellb | i thought that kind of naming was pretty common |
| 17:40.03 | Corydon76-lap | No, RC for 1.6.3 will be 1.5.3 |
| 17:40.20 | russellb | ugh, i find that much less obvious |
| 17:40.36 | Corydon76-lap | People who "know" can get 1.5... people who don't get 1.6 |
| 17:41.18 | Corydon76-lap | See, what you know is obvious... what you don't know isn't as obvious. That was the point of my email |
| 17:41.26 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 17:41.37 | Corydon76-lap | and there are far more people out there who don't know than who know |
| 17:42.36 | russellb | alright, well how about i email the -dev list to poll for opinions |
| 17:42.55 | Corydon76-lap | Sure |
| 17:43.35 | Corydon76-lap | How about the -users list, instead? |
| 17:44.05 | Corydon76-lap | If we want to avoid confusing people, we should ask the people who are most likely to be confused |
| 17:44.11 | russellb | heh |
| 17:44.14 | russellb | fair enough |
| 17:47.24 | jmls | could someone point me to the right file where the variables defined in sip.conf with a peer are copied into the channel when the peer is about to make a call ? |
| 17:47.55 | Corydon76-lap | jmls, it's definitely in chan_sip.c |
| 17:48.11 | jmls | damn! knew you would say that. |
| 17:48.43 | Corydon76-lap | Look for a loop in which pbx_builtin_setvar_helper is called |
| 17:50.32 | jmls | oh, for the love of god. there it is. |
| 17:50.59 | Corydon76-lap | Line 4043? |
| 17:51.22 | Corydon76-lap | "Set channel variables for this call from configuration" |
| 17:52.11 | jmls | uh huh |
| 17:52.33 | jmls | probably looking at chan_zap all this time :) |
| 17:53.03 | Corydon76-lap | Helps when you know what you're looking for |
| 17:53.29 | jmls | I'm wanting to set up an auto group when the call is initiated |
| 17:53.38 | jmls | like an OUTBOUND_GROUP in reverse |
| 17:54.56 | jmls | so I was going to check the peer vars and if GROUP=foo@bar is defined, create the group count for the new channel |
| 17:55.44 | Corydon76-lap | Well, I suppose you could set a function from sip.conf |
| 17:56.06 | Corydon76-lap | I don't see any reason why that wouldn't work, atm |
| 17:56.51 | jmls | and how would you do that, then ? |
| 17:57.56 | Corydon76-lap | setvar=GROUP(bar)=foo |
| 17:58.13 | Corydon76-lap | I'm pretty sure that will work |
| 17:58.48 | Corydon76-lap | Pretty neat, eh? |
| 17:59.38 | jmls | omg. |
| 18:00.06 | jmls | it worked |
| 18:00.11 | Corydon76-lap | Heh |
| 18:00.32 | jmls | wow, you could even use func_odbc here |
| 18:00.50 | Netgeeks | pretty neat |
| 18:00.58 | jmls | that seriously needs documentation |
| 18:00.59 | Corydon76-lap | For that matter, you wouldn't even need the callerid= anymore, you could just do: setvar=CALLERID(all)=Some User <1234> |
| 18:01.31 | Corydon76-lap | jmls, why would it need documentation? ;-) |
| 18:06.08 | Juggie | Corydon76-dig: my 2 cents is we do 1.5.x SVN *ONLY* then 1.6.x RC's as tar balls. |
| 18:06.11 | Corydon76-lap | Qwell, oh come on... that's a GOOD idea... ;-) |
| 18:07.15 | Juggie | Corydon76, what do ou think of that? |
| 18:09.08 | *** join/#asterisk-dev joetester (n=joeteste@216.191.34.13) |
| 18:09.25 | *** join/#asterisk-dev popvoxdave (n=popvoxda@64.240.183.2) |
| 18:10.56 | jmls | Corydon76-dig: nope. cannot seem to get this working |
| 18:11.02 | popvoxdave | hey all. I am wanting to learn about the new bridging model, whispering, etc. Is there a best place to start looking? |
| 18:13.19 | russellb | symlink: ^^^ |
| 18:13.45 | symlink | popvoxdave: well the bridging stuff is in a branch in my team directory, and the whispering stuff is in trunk as audiohook.c in the main directory |
| 18:13.59 | symlink | there's examples for usage of both things |
| 18:14.32 | popvoxdave | ok, so I am looking at audiohook.c and getting my head wrapped around that. |
| 18:14.56 | popvoxdave | where can I check out the bridging stuff? is it in a branch? |
| 18:15.15 | symlink | svn co http://svn.digium.com/svn/asterisk/team/file/bridging |
| 18:15.34 | symlink | main/bridging.c, bridges directory for the bridge technologies, and app_bridgetest.c |
| 18:15.58 | joetester | symlink: Is that trunk audiohook whispering the successor to the current chanspy? |
| 18:16.10 | symlink | joetester: *nod* |
| 18:16.12 | popvoxdave | josh didn't realize you had been turned into a symlink? |
| 18:16.16 | popvoxdave | is file deprecated? |
| 18:16.30 | symlink | I am a symlink to file for now |
| 18:16.34 | symlink | file shall return! |
| 18:16.40 | popvoxdave | gotcha... irc nick issues? |
| 18:16.44 | Juggie | russellb: have you decided to start @ 1.5 or 1.6 as of yet? |
| 18:16.46 | russellb | he was directory yesterday. |
| 18:16.52 | symlink | nope, just change |
| 18:16.52 | joetester | rm file... no he won't |
| 18:16.53 | *** join/#asterisk-dev kkjoe (n=kvirc@p509893b3.dip0.t-ipconnect.de) |
| 18:16.56 | symlink | although... |
| 18:16.56 | russellb | Juggie: probably 1.6, but there is still some debate |
| 18:17.31 | popvoxdave | ok, and I was talking to mark a little bit about the bridging model w.r.t. conference calling... |
| 18:17.46 | popvoxdave | the new bridging model is also the successor to meetme at this point? |
| 18:17.57 | joetester | Are you ready for windows vista, partition? |
| 18:18.03 | partition | it easily can be, and will probably be |
| 18:18.17 | kkjoe | is here someone who knows the libpri stuff well ? |
| 18:19.52 | Juggie | russellb: my opinion for what its worth, was to do w/ 1.5.x freeze it, test it as best we can to work all the bugs out, then do a 1.6rc# as a general tar balled release. Then once 1.6.0 is out follow the kernel release model. |
| 18:20.42 | russellb | would you rather 1.6.X release candidates be named like 1.6.3-rc1? or 1.5.3.1 ? |
| 18:21.52 | russellb | there was debate over which was more obvious that it wasn't a real release |
| 18:22.32 | Juggie | it depends on how you want to test everything... traditionally uneven releases as you know are used as testing releases, and if we dont use them then i wonder why we skip the nubmers at all. |
| 18:22.36 | Juggie | *numbers. |
| 18:22.56 | russellb | historical precedence at this point is the main reason to continue skipping them. |
| 18:23.55 | kkjoe | im getting a lot of sabme messages when i disconnect the line to telco on an pri interface, is there a way to avoid there sabme messages ? |
| 18:26.23 | Juggie | i guess it depends on what testing model you'd like to follow, i was thinking the best way to go would be a small usage test among developers but in a more controled way, we could have 25 devs running trunk, but they could all be different code, which is why i thought tagging a 1.5 release might make sense but as svn only.. then finally release it on a larger scale as 1.6-rc# that said if you want to do only one starge of testing then i think 1.6rc# i |
| 18:26.35 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 18:26.36 | tzafrir | russellb, if you're going for quick release cycle: go for 1.5 |
| 18:26.45 | tzafrir | But are you going for that? |
| 18:27.26 | russellb | a quick release cycle, yeah |
| 18:27.29 | russellb | that's what i would like |
| 18:27.34 | popvoxdave | symlink when do you think the bridging code will be trunk? |
| 18:27.59 | partition | I do not know |
| 18:28.04 | Juggie | my thoughts were simply, tag a 1.5, do some releases of it until we feel its ready for general consumption.. then for 1.6rc# release tarballs but not for 1.5 |
| 18:28.19 | partition | figure out the release cycle stuff first... |
| 18:28.31 | Corydon76-lap | Juggie, my thought was to use 1.5 as a staging area for 1.6 |
| 18:28.48 | popvoxdave | and will the new bridging stuff make it into 1.6? |
| 18:28.59 | russellb | Corydon76-lap: i suppose that makes sense. |
| 18:29.03 | Juggie | Corydon76-dig, if you look @ the kernel, they use #.uneven as a dev area and #.even as release. |
| 18:29.06 | russellb | Corydon76-lap: i'm becoming convinced |
| 18:29.10 | Juggie | but #.even still has release candidates. |
| 18:29.13 | russellb | Juggie: not anymore .. |
| 18:29.30 | partition | popvoxdave: probably |
| 18:29.42 | Juggie | russellb, really? i thought they had done a 2.5.x before 2.6 unless its changed since then. |
| 18:29.59 | Corydon76-lap | Juggie, 2.5 was staging for 2.4, actually |
| 18:30.00 | russellb | right, well, they did |
| 18:30.12 | russellb | but there is not 2.7, and no plans for one, or a 2.8 |
| 18:30.18 | russellb | they are just putting all new stuff into 2.6 |
| 18:30.26 | Juggie | no i know that, there is no reason to release a 2.8 |
| 18:30.31 | tzafrir | How much automated testing can you do with asterisk? What can you test with 'make test'? |
| 18:30.59 | Juggie | Corydon76-dig, when did 2.4 or 2.6 kernel release? |
| 18:31.23 | tzafrir | For instance: how can you test code from various modules without running asterisk? |
| 18:31.26 | Corydon76-lap | A long time ago in a galaxy far far away |
| 18:32.00 | tzafrir | Kernels actully had odd numbers (unstable). Asterisk never had |
| 18:32.29 | tzafrir | well, not since 1.0 |
| 18:32.42 | russellb | hm? |
| 18:36.04 | Juggie | Corydon76-dig, are you sure 2.5 staged 2.4, it doesnt look that way to me.. the first 2.5 tarball was released nov 23rd 2001.. but 2.4.0 was released jan4th, 2001. |
| 18:36.55 | Corydon76-lap | Juggie, pretty sure, yes |
| 18:37.02 | Juggie | i think your wrong on this one sorry :) |
| 18:37.11 | Juggie | the timestamps dont lie. |
| 18:37.38 | Juggie | the last 2.5.x release was mid 2003, and 2.6 rwas released end 2003 |
| 18:38.18 | Corydon76-lap | Juggie, right, it was abandoned for the 2.6 release |
| 18:38.28 | Juggie | right, but you said 2.5 staged 2.4 |
| 18:38.37 | Juggie | when infact 2.5 staged 2.6 |
| 18:38.50 | Corydon76-lap | Juggie, stuff in 2.5 showed up in 2.4 |
| 18:39.25 | Juggie | backporting happens all the time... but i would say if you diffed the last 2.5 and 2.6.0-test1 you would find very ltitle difference :) |
| 18:39.37 | russellb | Corydon76-lap: i emailed -users by the way |
| 18:39.44 | Corydon76-lap | russellb, cool |
| 18:40.00 | Corydon76-lap | Juggie, in any case, it's irrelevant to the issue at hand |
| 18:40.06 | Juggie | and given that the http://www.kernel.org/pub/linux/kernel/v2.6/pre-releases/ChangeLog-2.6.0-test1 says 'Summary of changes from v2.5.75 to v2.6.0-test1' i finally win an argument on you :) |
| 18:40.19 | Juggie | and i have to say, its about time! :) |
| 18:41.28 | Corydon76-lap | Juggie, what has been staging 2.6, since, then? |
| 18:41.42 | Juggie | Corydon76-dig, nothing, they changed the model. |
| 18:42.04 | Corydon76-lap | So 2.5 doesn't stage 2.6 |
| 18:42.04 | Juggie | just rc and other testing releases now. |
| 18:42.14 | Juggie | well it staged 2.6.0 |
| 18:42.15 | putnopvut | I think you two have different definitions of the word "staging" |
| 18:42.18 | Juggie | and then they changed the model. |
| 18:42.48 | Corydon76-lap | putnopvut, probably, I think he means development that took place prior to the release |
| 18:43.04 | Juggie | i mean the dev that took place prior to 2.6.0 |
| 18:43.13 | Juggie | or in this case. 2.6.0-test1. |
| 18:43.14 | Corydon76-lap | while I'm talking about development that directly leads to a release |
| 18:43.20 | Juggie | ah |
| 18:43.25 | Corydon76-lap | -test1 is not a release |
| 18:43.54 | Juggie | it was a testing release, it was a tarballed release. |
| 18:44.12 | Corydon76-lap | A snapshot |
| 18:44.22 | Juggie | ok i'll agree to that :) |
| 18:44.34 | Corydon76-lap | Releases are snapshots, but snapshots are not necessarily releases |
| 18:45.23 | Juggie | i just think that if we jump right from trunk to a 1.6rc1 and people try it and find lots of outstanding issues we are going to great a bigger release confidence issue then already exists in 1.4 given the number of people still running 1.2 |
| 18:46.50 | Corydon76-lap | which is why I suggested we release 1.5.0.0 through 1.5.0.n, which then becomes 1.6.0 |
| 18:47.20 | Corydon76-lap | then we do 1.5.1.0 through 1.5.1.n, which becomes 1.6.1 |
| 18:47.32 | Juggie | in my 2 cents, theres too much of a difference between 1.4 and trunk to bang out all the problems in a couple of release candidates which is why i agree w/ corydon that we do 1.5 |
| 18:48.06 | Juggie | right, but i thought the idea was to follow the kernel model, that would not be doing so at all. |
| 18:48.15 | Corydon76-lap | Actually, architecturally, there are very few differences currently between 1.4 and trunk |
| 18:48.31 | Corydon76-lap | not like the differences between 1.2 and 1.4 or between 1.0 and 1.2. |
| 18:48.58 | Juggie | true true.. but there are still some big changes or additions. |
| 18:50.36 | Juggie | i dont disagree perse with your idea i just think it will be confusing for people.. my thoughts are just to go through a 1.5.x process similar to what you have said, but then end that branch when 1.6 is deemed ready to be released. |
| 18:52.06 | Juggie | russellb: is your intention to do release candidates like the kernel, eg, 1.6.5rc1 and then release 1.6.5 when there are no major outsanding issues? |
| 18:52.13 | russellb | yes |
| 18:54.30 | Juggie | then i agree, i just think we cant bang everything out in 1.6.0rc# there will be to many, plus you'll get people who try it, find some major issue and go 'o shit, 1.6 is going to suck, it will never be ready' etc... So i think due to the fact this is 1+ years of dev, we tag a 1.5 and freeze it, ask all the devs nicely to test etc... work out the bugs.. do some releases of it, and then move to 1.6.0rc1 release which is the model you want.. |
| 18:55.31 | Juggie | then of course once 1.6.0 comes out, then its theres an unfrozen window for 1.6.1 like the kernel. |
| 18:56.25 | Juggie | and then from this point on as you described to me, we only have small portions of changes to test which makes new releases considerabally easier. |
| 18:58.03 | tzafrir | one thing about the naming: "1.6.3-rc1" sorts after "1.6.3" and 1.6.3.1 |
| 18:58.30 | tzafrir | But there's no decent way out of this, AFAIK. Numbers simply come first |
| 18:58.35 | Juggie | if you look @ the kernel ftp |
| 18:58.38 | Juggie | they keep them seperate |
| 18:58.57 | Juggie | theres kernel/v2.6 and the inside there is a dir called pre-releases |
| 18:59.19 | tzafrir | Debian introduced the special separator "~" at some point to work around such issues |
| 18:59.24 | Juggie | er sorry, thats testing... |
| 18:59.37 | brookshire | hi! |
| 18:59.39 | tzafrir | Not sure about rpm sorting order |
| 18:59.49 | Juggie | pre releases wa s for testing 2.6.0 |
| 19:00.04 | Juggie | tzafrir, if someone releases 1.6.0rc1 as an rpm i give you permission to kick them |
| 19:00.12 | Juggie | that would be idiotic |
| 19:00.28 | brookshire | dang.. blitz left |
| 19:00.33 | tzafrir | Juggie, but what about 1.6.3-rc1 ? |
| 19:00.57 | Juggie | tzafrir, i dont personally think that has any business being a rpm. |
| 19:00.59 | tzafrir | is that greater than 1.6.3.1 ? |
| 19:01.34 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 19:01.40 | tzafrir | Juggie, so if someone only uses RPMs, he will never get to test pre-releases? bad |
| 19:01.43 | Juggie | tzafrir, there is no easy way around that though. |
| 19:01.59 | Juggie | tell me how you would fix that |
| 19:02.01 | Juggie | there is no way |
| 19:02.17 | tzafrir | There must be, because "rc" is used in many packages |
| 19:02.47 | tzafrir | puzzled, what do you think? |
| 19:02.49 | Juggie | if you want to test * and cannot figure out how to rpm -e myoldpackage, rpm -i mynewpackage |
| 19:02.53 | Juggie | then i cannot help you save your soul. |
| 19:02.59 | paravoid | have a look at dovecot |
| 19:03.04 | paravoid | it most certainly has -rc in its name |
| 19:03.28 | Juggie | tzafrir, yes it is true that an upgrade may not work flawlessly w/ the rc versions. |
| 19:03.50 | Juggie | so you just rpm -e and then rpm -i |
| 19:04.05 | Juggie | that is not a huge deal, given that rc's should not ever make it into a repo i dont see how that would be a problem. |
| 19:21.00 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 19:29.39 | jmls | Corydon76-lap: if "architecturally, there are very few differences currently between 1.4 and trunk" |
| 19:30.16 | jmls | could you not make trunk a release of 1.4 , which might encorage more people to move from 1.2 |
| 19:30.31 | jmls | deviously even |
| 19:30.55 | jmls | call it 1.4.60 |
| 19:31.34 | Corydon76-lap | jmls, um, in terms of what could be done, we _could_ release it as a 1.2 or even a 1.0... we're not going to, though we could |
| 19:32.24 | Corydon76-lap | We're not trying to be devious; we're trying to raise the level of trust, both in our actions as well as in our code |
| 19:34.05 | tzafrir | Is Cresl1n around? |
| 19:35.43 | brookshire | he's not in his office, so i assume not :) |
| 19:36.02 | jsmith | Probably at school |
| 19:36.57 | Qwell | gah, did nobody try to run any of the versions of RH or Fedora made in the last 18 months before release time? |
| 19:37.08 | Qwell | silly people |
| 19:37.16 | puzzled | tzafrir: was afk, lemme read back a bit |
| 19:40.38 | puzzled | tzafrir: iirc the proper syntax is something like 1.6.0-1.rc1.fc7.i386. is that what you are looking for? |
| 19:43.11 | tzafrir | puzzled, regarding recent discussion in asterisk-dev |
| 19:43.46 | jsmith | Qwell: I have, and still do. In fact, I'm downloading Fedora 8 Test 3 right now |
| 19:44.21 | Qwell | jsmith: did it actually...work? |
| 19:44.29 | Qwell | I'm having problems with every single version I'm trying |
| 19:45.22 | puzzled | Qwell: I don't have any issues with 1.2 on F7 and know that the people who use my rpms on CentOS 4.5 & 5 neither have issues. but that's only with 1.2 |
| 19:45.43 | puzzled | tzafrir: sorry don't understand. what's the question exactly? |
| 19:45.45 | Qwell | hmm, I guess I forgot to qualify that.. "in vmware" |
| 19:46.21 | tzafrir | puzzled, so your workaround is to add the rc part to the revision |
| 19:46.29 | puzzled | yup |
| 19:46.44 | tzafrir | But then rc1 is still greater than the release itself |
| 19:47.02 | tzafrir | "rc" > "fc" |
| 19:47.16 | puzzled | if there's an rc2 than you bump the rel too: 1.6.0-2.rc2 |
| 19:47.17 | *** join/#asterisk-dev joetester (n=joeteste@216.191.34.13) |
| 19:47.35 | tzafrir | But what will be the final 1.6.0 release? |
| 19:47.42 | puzzled | 1.6.0-3 |
| 19:48.23 | puzzled | and should that be necessary than you can also use the evil epoch: 0:1.6.0-1.rc1 versus 1:1.6.0-2 |
| 19:48.50 | puzzled | but that's only as a last resort which I don't think will be necessary |
| 19:48.56 | tzafrir | You don't use an epoch. But your solution doesn't really enable very automated packaging... |
| 19:49.25 | tzafrir | well, if you're comfortable with that (movinfg part of the version string to the release part)... |
| 19:49.29 | puzzled | not based on the tarball itself no. it requires manual tweaking of the spec file |
| 19:49.40 | puzzled | rc's are always a bith |
| 19:49.43 | puzzled | bitch even |
| 19:51.27 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:52.31 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-72-70-79-233.bstnma.east.verizon.net) |
| 20:02.50 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 20:02.50 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 20:28.36 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.160.16) |
| 20:49.49 | *** join/#asterisk-dev mitcheloc (n=mitchel@adsl-67-127-235-238.dsl.irvnca.pacbell.net) |
| 21:05.35 | jmls | using AMI and local channels to make an outbound call, there are 2 local channels, yes ?. One to make the call, the other to call the context / extension specified in the originate command |
| 21:06.00 | jmls | when should the second start ? As soon as the first is answered ? |
| 21:06.53 | jmls | the second is not inheriting variables defined by the first. Is that defined behaviour, or a bug ? |
| 21:12.07 | jsmith | jmls: They'll only get inherited if you prefix them with an underscore or two |
| 21:12.19 | jsmith | At least, I think that's the way to make them get inherited |
| 21:12.26 | jsmith | I haven't done it in forever |
| 21:16.30 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 21:19.53 | blitzrage | jsmith: you are correct |
| 21:20.01 | blitzrage | I do it all the time :) |
| 21:21.35 | jmls | I'm having a problem. I use local channels to call a zap channel. When the zap channel answers, I run a macro that sets __ZAPCHAN=${CHANNEL} |
| 21:21.44 | jmls | but that variable does not appear in the second leg |
| 21:21.54 | blitzrage | are you setting it before the 2nd leg? |
| 21:22.11 | blitzrage | got a snippet of the dialplan? |
| 21:22.13 | jmls | I'm setting it in the macro the first leg runs when connected. |
| 21:22.30 | jmls | exten => _X.,n,Dial(Zap/G3/${EXTEN},35,M(dialleranswered)) |
| 21:22.46 | jmls | dialleranswered: exten => s,1,Set(__ZAPCHANNEL=${CHANNEL}) |
| 21:22.47 | jsmith | jmls: I think you have to set it *before* you call Dial() |
| 21:22.53 | blitzrage | aye |
| 21:22.57 | jmls | aha - that's the problem |
| 21:22.59 | blitzrage | I've never done it there... |
| 21:23.11 | jmls | how do I know what the zap channel is *before* i dial ??? |
| 21:23.38 | jsmith | ChanIsAvail()? |
| 21:23.55 | jmls | another call may grab it |
| 21:24.01 | jsmith | (and possibly MacroExclusive) |
| 21:24.25 | jmls | can't use macroexclusive whilst I dial .. it may take 40 seconds to answer ;) |
| 21:24.31 | blitzrage | jmls: does M() not execute before the answer though? |
| 21:24.47 | jmls | no, M executes upon connection |
| 21:25.06 | blitzrage | hrmmm |
| 21:25.10 | *** join/#asterisk-dev Corydon76-vcch (n=tilghman@pdpc/supporter/bronze/Corydon76-home) |
| 21:25.10 | *** mode/#asterisk-dev [+o Corydon76-vcch] by ChanServ |
| 21:25.17 | jmls | <PROTECTED> |
| 21:25.25 | blitzrage | seems like it should be available....... |
| 21:25.43 | blitzrage | unless it's because it's a macro.... they always do weird things to me :) |
| 21:25.45 | jmls | I dumpChan on the second leg. It's _not_ there |
| 21:26.13 | jmls | I think the second leg kicks off before the macro on the first leg runs |
| 21:26.29 | jmls | I think the second should only start _after_ the post-connect macro is run |
| 21:26.32 | jmls | imho |
| 21:26.36 | jmls | <PROTECTED> |
| 21:27.27 | jmls | I could store the channel in astb, but there is a possibility that the db won't be written before the second leg gets to read it |
| 21:28.43 | blitzrage | I thought of a dirty hack using global vars, but it's so dirty I won't even suggest it :) |
| 21:28.56 | jmls | heh - I probably had the same really dirty thought |
| 21:29.02 | jmls | eeeuuuuwwww |
| 21:29.03 | blitzrage | indeed :) |
| 21:29.06 | blitzrage | ewwwwwww is right |
| 21:29.11 | blitzrage | it'd probably work... but.... ewwwww |
| 21:29.27 | jmls | the potential for screwing it all up is horrendous |
| 21:29.30 | blitzrage | lots of extra dialplan handling to loop through all the vars until you find what you want |
| 21:29.38 | blitzrage | and that |
| 21:30.28 | blitzrage | well... you rant... I just got back from a run, so I'm going to freshen up then eat dinner... then probably work on some docs |
| 21:30.46 | blitzrage | it's amazing how hard writing new documentation can be... especially when it's not just an article on something cool |
| 21:30.56 | jmls | what happens if you redirect a local channel that is connected to a zap channel ? |
| 21:31.02 | jmls | Will it work, or is it fraught ? |
| 21:31.16 | blitzrage | redirect? |
| 21:31.29 | jmls | yeah - to meeting rooms and out again :) |
| 21:31.46 | jmls | using the AMI redirect command |
| 21:31.47 | blitzrage | no idea... |
| 21:31.48 | blitzrage | ah |
| 21:31.56 | blitzrage | that's what I wasn't sure you were using |
| 21:32.11 | jmls | lol |
| 21:32.13 | blitzrage | which means I'm much too hungry to think |
| 21:32.16 | jmls | I was about to make a comment ... ;) |
| 21:32.26 | blitzrage | back latah :) |
| 21:32.34 | jmls | thanks for the help so far. |
| 21:46.18 | jsmith | jmls: I had a thought |
| 21:47.01 | jsmith | jmls: What if you assigned the channel to a group using OUTBOUND_GROUP... |
| 21:48.16 | *** join/#asterisk-dev jsmith (n=jsmith@68.178.10.62) |
| 21:48.17 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 21:48.26 | jsmith | jmls: I had a thought |
| 21:48.29 | jsmith | jmls: What if you assigned the channel to a group using OUTBOUND_GROUP... |
| 21:49.04 | jsmith | jmls: ... and then used the GROUP_LIST function |
| 21:49.28 | jsmith | It's hackish, but sounds better to me than globar variables or MacroExclusive... |
| 21:49.46 | Corydon76-vcch | globar? |
| 21:50.13 | Corydon76-vcch | Is that like a glo-stick? |
| 21:50.17 | jsmith | s/globar/global/ |
| 21:50.44 | Corydon76-vcch | What about func_lock ? ;-) |
| 21:51.09 | jsmith | Corydon76-vcch: Quick question for you... why does GotoIfTime only have two-minute resolution? |
| 21:51.18 | Corydon76-vcch | Because |
| 21:52.11 | jsmith | I'm sure there's a perfectly valid technical reason |
| 21:52.39 | Corydon76-vcch | It uses an array of integers, each integer is 32-bits |
| 21:53.07 | Corydon76-vcch | Hence 30 of them are used for minutes |
| 21:53.25 | jmls | jsmith: thanks, I'll give it a try |
| 21:53.54 | Corydon76-vcch | More specifically, Mark wrote it that way, and nobody has yet felt the overwhelming need to change it |
| 21:54.28 | jsmith | I see... |
| 21:54.48 | Corydon76-vcch | It's essentially set up like a bitfield |
| 21:55.40 | callguy | Corydon76: I just uploaded a patch to 10571 which should eliminate the issue with crashing if DEBUG_THREADS is enabled |
| 21:59.24 | jmls | jsmith: solved it. In 2 lines ;) |
| 22:00.13 | Corydon76-vcch | callguy: does that also work if DEBUG_THREADS is disabled? |
| 22:00.38 | Corydon76-vcch | I would think changing those values would be bad if debugging code is not turned on |
| 22:01.00 | callguy | Let me take another look - but I don't think it should have any effect |
| 22:01.27 | callguy | that code is only called if DEBUG_THREADS is defined, otherwise it's ignored completely |
| 22:01.57 | Corydon76-vcch | And NO! You may NOT comment out structure elements. They are there because they are needed for debugging |
| 22:03.12 | Corydon76-vcch | so that patch is a non-starter |
| 22:03.32 | callguy | which structure elements are you talking about? |
| 22:03.32 | jsmith | jmls: Oh, did that do the trick? |
| 22:03.48 | jmls | nope. did something *much* easier ;) |
| 22:03.52 | jmls | line 1: exten => ConnectToAgent,n,Set(ARRAY(BASECHAN)="${CHANNEL}") |
| 22:03.59 | Corydon76-vcch | callguy: in ast_mutex_info |
| 22:04.00 | putnopvut | Corydon76-vcch: they're commented out but replaced with a different struct. |
| 22:04.02 | jmls | line 2: exten => ConnectToAgent,n,ImportVar(__ZAPCHANNEL=${BASECHAN}\,2,BRIDGEPEER) |
| 22:04.11 | Corydon76-vcch | putnopvut: oh |
| 22:04.13 | putnopvut | the ast_mutex_reentrant_info struct. |
| 22:04.19 | jsmith | jmls: Sweet! |
| 22:04.35 | Corydon76-vcch | putnopvut: I'll let you take care of it, then |
| 22:04.37 | jmls | lateral thinking |
| 22:05.08 | putnopvut | Corydon76-vcch: ...really? |
| 22:05.26 | Corydon76-vcch | putnopvut: why not? |
| 22:06.00 | blitzrage | jmls: I've never even heard of that app |
| 22:06.46 | putnopvut | Well, I guess you're right. If people test it and it works properly, then that's cool. |
| 22:06.52 | Corydon76-vcch | callguy: if you're going to remove structure elements, remove them entirely. don't just comment them out |
| 22:07.31 | Corydon76-vcch | otherwise the question becomes WHY are they commented out? |
| 22:08.17 | jmls | yeah, the problem was that I didn't know what the zap channel was ;) So, use the first leg to get a variable of the second leg (the zap connected leg). The variable is BRIDGEPEER, which gives you the channel that the second leg is bridged to |
| 22:08.45 | anonymouz666 | bridgepeer is great while using with channelredirect |
| 22:09.32 | blitzrage | aha... BRIDGEPEER |
| 22:09.35 | blitzrage | neato |
| 22:10.22 | callguy | Corydon76-vcch: Fair enough, I will clean that up, everything commented out was simply replaced by a different struct so it will be thread safe. And I just double checked - everything seems to be fine with DEBUG_THREADS turned off |
| 22:11.45 | blitzrage | awesome... XMMS works through an SSH Xtunnel as long as I don't move it on my desktop :) |
| 22:17.13 | putnopvut | callguy: while you're at it, could you also change your spaces to tabs in your patch? Thanks. |
| 22:21.43 | callguy | putnopvut: no problem. |
| 22:22.00 | putnopvut | Cool. Thanks :) |
| 22:37.46 | *** part/#asterisk-dev popvoxdave (n=popvoxda@64.240.183.2) |
| 23:03.23 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.159.138) |
| 23:22.14 | *** join/#asterisk-dev Corydon76-vcch (n=tilghman@pdpc/supporter/bronze/Corydon76-home) |
| 23:22.14 | *** mode/#asterisk-dev [+o Corydon76-vcch] by ChanServ |
| 23:25.52 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.148.36) |
| 23:27.09 | anonymouz666 | get_header(req, "Call-ID"); will find... CALL-ID header ? |
| 23:31.01 | blitzrage | probably not |
| 23:41.36 | *** join/#asterisk-dev Itiliti (n=Itiliti@c-76-29-86-174.hsd1.il.comcast.net) |
| 23:41.53 | Itiliti | How can I compile res_bonjour into asterisk? |
| 23:44.22 | blitzrage | very carefully |
| 23:44.25 | blitzrage | see #asterisk pls |
| 23:58.04 | jtodd | the res_bonjour stuff advertises statuses via DNS. Pretty nifty, but has been unfortunately created in a way that does not allow it's inclusion into the main code branches. |
| 23:58.18 | jtodd | Therefore, probably will get tougher to integrate as time goes on and code grows stale. |
