| 01:17.34 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 02:40.06 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 03:25.41 | *** join/#asterisk-dev otherwiseguy_ (~terry@69.76.217.40) |
| 03:43.06 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:43.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:48.31 | *** join/#asterisk-dev CaptainPants (~CaptainPa@nat/digium/x-kipmaidfcwmekoto) |
| 03:48.47 | *** join/#asterisk-dev CaptainPants (~CaptainPa@nat/digium/x-tudpdvfjlldkcwrm) |
| 03:55.28 | *** join/#asterisk-dev russellb (~russellb@asterisk/digium-open-source-team-lead/russellb) |
| 03:55.28 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:06.37 | *** join/#asterisk-dev russellb (~russellb@asterisk/digium-open-source-team-lead/russellb) |
| 04:06.37 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:52.24 | *** join/#asterisk-dev irroot (~irroot@dsl-185-122-97.dynamic.wa.co.za) |
| 05:04.47 | *** join/#asterisk-dev tengulre (~tengulre@125.71.208.16) |
| 06:05.51 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:05.53 | schmidts | good morning |
| 07:11.50 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:11.50 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:25.24 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:29.11 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:34.53 | *** join/#asterisk-dev frawd (~francois@132.Red-81-38-142.dynamicIP.rima-tde.net) |
| 11:49.14 | *** join/#asterisk-dev luckman212 (~irc@2001:470:1f07:1225:7c23:92b3:7e50:df74) |
| 11:50.29 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:50.29 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:55.06 | *** join/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 12:12.42 | *** join/#asterisk-dev luckman212_ (~irc@2001:470:1f07:1225:7c23:92b3:7e50:df74) |
| 12:51.53 | irroot | SIP_PAGE2_SUBSCRIBEMWIONLY issue MWI Only When/If subscribed too |
| 12:53.31 | irroot | chan_sip this is not clear and is treated both ways in the code |
| 12:53.43 | irroot | so effectivly never works / is broken |
| 13:05.09 | *** join/#asterisk-dev Mw3 (mw3@mw3.hu) |
| 13:23.25 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:23.25 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:46.11 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 13:46.11 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:06.56 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:06.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:30.54 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:30.54 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:51.26 | tzafrir_laptop | I believe Centos4 has no sqlite3 |
| 14:52.16 | russellb | is CentOS4 still relevant? |
| 14:52.29 | russellb | and i'm sure you can get it on CentOS4 if you use EPEL repos |
| 14:54.04 | Kobaz | sadly old stuff is always relevant |
| 14:54.09 | Kobaz | because people still use old stuff |
| 14:54.48 | russellb | well at some point we can't make sub-optimal decisions for bleeding edge asterisk based on ancient other software |
| 14:54.52 | Kobaz | speaking of non-old stuff... i found this truely totally awesome sip soft phone for android, csipsimple |
| 14:55.28 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:55.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:02.35 | Marquis42 | Kobaz: Thanks for the pointer, I've recently started to look at SIP softphones for mobile devices. I've been messing around with Bria, but a free alternative is better. :) |
| 15:07.08 | Kobaz | yeah |
| 15:07.51 | Kobaz | i played with sipdroid, linphone and some other one |
| 15:07.54 | Kobaz | they are all terrible |
| 15:08.17 | Kobaz | they usually arent even funtional enough to make a phone call |
| 15:08.26 | Kobaz | a sipdroid only supports one user account and linphone only supports one i think |
| 15:08.41 | Kobaz | csipsimple you can just add new accounts |
| 15:09.53 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:09.53 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:09.53 | t_dot_zilla | when using perl+DBI with AGI is it better to run an AGI server or call agi script each time in dialplan? |
| 15:10.04 | Kobaz | fastagi |
| 15:10.23 | Kobaz | calling the agi each time will incur a startup cost on each channel |
| 15:10.37 | t_dot_zilla | ah, thanks Kobaz |
| 15:10.49 | Kobaz | Marquis42: and csipsimple can actually make phone calls |
| 15:11.04 | Corydon76-home | The other side of that is whether you can write a fastagi server without leaks |
| 15:11.53 | t_dot_zilla | Corydon76-home: what do you mean "leaks" ? agi script is pretty simple... only 70 lines |
| 15:12.07 | Kobaz | memory leaks |
| 15:12.08 | Corydon76-home | and whether the leaks are bad enough that it needs a restart more often than your normal scheduled downtime, if you even have any |
| 15:12.15 | Corydon76-home | Memory leaks, resource leaks |
| 15:12.24 | Kobaz | i don;t have no stinkin leaks |
| 15:12.52 | Corydon76-home | Kobaz: of course not! All of the code you produce is perfect the first time! |
| 15:13.23 | t_dot_zilla | Corydon76-home: script simply queries a mysql table, sets context a few variables and executes either "Dial" or "VoiceMail" |
| 15:13.47 | t_dot_zilla | something as simple as that could cause memory leaks? |
| 15:13.54 | Corydon76-home | t_dot_zilla: and of that resultset, is it completely freed each time? |
| 15:14.03 | Kobaz | Corydon76-home: i use a forking server, so the parent program is really small and simple |
| 15:14.30 | t_dot_zilla | eek, im new to perl... using DBI, i'lll have to look at clearing resultset |
| 15:15.51 | t_dot_zilla | i dont understand how to clear the resultset... i just googled it, there is nothing related |
| 15:15.53 | Corydon76-home | t_dot_zilla: scripting languages have a tendency to grow in use of memory over time. They're really best suited to short runs |
| 15:16.01 | russellb | this conversation should be in #asterisk |
| 15:16.20 | t_dot_zilla | russellb: i'd gladly join #asterisk if someone could unban our IP |
| 15:16.38 | leifmadsen | looks at Qwell |
| 15:16.41 | russellb | there was a reason you got banned, that doesn't mean the conversation can move here |
| 15:17.12 | t_dot_zilla | russellb: a former employee was banned from asterisk, no reason our entire IP block should be |
| 15:17.42 | kpfleming | seanbright: nice work! |
| 15:17.54 | *** mode/#asterisk-dev [+q t_dot_zilla!*@*] by russellb |
| 15:18.10 | Kobaz | hmm |
| 15:18.28 | *** part/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 15:18.30 | *** join/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 15:18.36 | seanbright | kpfleming: thanks |
| 15:18.38 | Kobaz | russellb: is that necessary? |
| 15:19.31 | russellb | i've had that conversation about a dozen times, i don't time for it, so yes |
| 15:19.49 | Kobaz | k |
| 15:19.54 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:19.54 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:20.21 | russellb | on-topic in here is pretty important to me, i try to read everything to stay on top of what's going on. |
| 15:20.30 | Kobaz | yeah |
| 15:20.41 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 15:20.57 | Kobaz | good point |
| 15:21.20 | seanbright | Kobaz: and now we have to ban you for asking |
| 15:21.27 | seanbright | heh |
| 15:21.40 | *** join/#asterisk-dev Sipster (~Sipster@modemcable143.199-202-24.mc.videotron.ca) |
| 15:25.17 | leifmadsen | seanbright: you are banned for stating the obvious |
| 15:25.49 | kpfleming | is it possible to anti-ban someone, in order to force them to always be in the channel? |
| 15:26.12 | jsmith | Qwell: Ping? (re: RPMs for dahdi-firmware) |
| 15:26.15 | russellb | kpfleming: you are banned for making a joke |
| 15:26.23 | kpfleming | russellb: rock on! |
| 15:32.11 | Qwell | jsmith: pong |
| 15:32.29 | jsmith | Qwell: You don't by chance have any modern dahdi-firmware RPMs for RHEL/CentOS, do you? |
| 15:32.39 | Qwell | jsmith: They're on packages.digium.com |
| 15:32.56 | Qwell | well, partially |
| 15:33.26 | Qwell | no, not partially anymore. I moved it all there. Right. |
| 15:33.58 | jsmith | Latest one I'm seeing is from April of last year |
| 15:34.00 | jsmith | http://packages.digium.com/centos/5/current/i386/RPMS/dahdi-firmware-2.0.2-1_centos5.noarch.rpm |
| 15:34.08 | jsmith | Is that the most current? |
| 15:34.11 | irroot | is installign 3CX :P |
| 15:34.25 | irroot | see if i get ban for that hehe |
| 15:36.36 | *** part/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 15:36.44 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 15:36.44 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 15:36.49 | Qwell | stupid ctrl-w... |
| 15:37.04 | Qwell | jsmith: yes, that's the latest available in AsteriskNOW |
| 15:37.14 | Qwell | t_dot_zilla: No. Stop asking. |
| 15:37.29 | *** join/#asterisk-dev CaptainPants (~CaptainPa@nat/digium/x-nptqqnafzwynzbxm) |
| 15:38.37 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:39.03 | jsmith | Qwell: Latest available in AsteriskNOW, or the latest versions of the firmware? |
| 15:39.31 | Qwell | jsmith: That's the latest the little birdies have told me are available. I can go through the Makefile and see if there's newer that should be available though. |
| 15:39.48 | jsmith | Qwell: I'd appreciate it :-) |
| 15:42.36 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9825:7887:95b2:715a) |
| 15:43.27 | Qwell | jsmith: They are all up-to-date, according to the Makefile. You should, however, ignore the vpmadt032 package. That's built as a kernel module now. |
| 15:44.24 | jsmith | Qwell: OK, so just to make sure I'm on the right page here -- I need both the dahdi-firmware package + the individual dahdi-firmware-xxx packages (minus vpmadt032), correct? |
| 15:45.04 | Qwell | Correct. dahdi-firmware is just a metapackage that requires the other 5 (4, + the fwload kmod package) |
| 15:45.36 | jsmith | OK, make sense |
| 15:47.23 | Kobaz | so does 3cx do anything useful |
| 15:47.26 | Qwell | -prereq: include/dahdi/version.h firmware-loaders |
| 15:47.26 | Qwell | +prereq: include/dahdi/version.h #firmware-loaders |
| 15:47.30 | Kobaz | other than the usual |
| 15:47.37 | Qwell | jsmith: You'll also want something like that in the dahdi-linux package. Makes it easy. |
| 15:47.45 | jsmith | Of course... |
| 15:50.42 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 15:55.03 | russellb | JonathanRose: for patches that come in and you review them, you don't need to post to reviewboard. |
| 15:55.08 | russellb | JonathanRose: in those cases, you are the reviewer. :-) |
| 15:55.13 | Qwell | t_dot_zilla: No, bribing me will not get you unbanned from #asterisk. Just stop asking. |
| 16:05.44 | JonathanRose | alrighty |
| 16:29.06 | seanbright | otherwiseguy: didn't file try that conversion (bdb -> sqlite) before and find that it didn't perform adequately? |
| 16:29.18 | otherwiseguy | seanbright: no. |
| 16:29.27 | otherwiseguy | he tried it, but the performance wasn't the problem. |
| 16:29.35 | otherwiseguy | no one got around to writing the conversion utility |
| 16:29.42 | otherwiseguy | (which is one of the easier parts) |
| 16:30.05 | otherwiseguy | It is 4x slower or so, but it does 50,000 inserts/sec on a vm on my laptop. |
| 16:30.22 | otherwiseguy | (as long as you use transactions--which I do) |
| 16:31.09 | seanbright | cool |
| 16:31.23 | seanbright | well then proceed, good sir. |
| 16:31.31 | otherwiseguy | I have also not run into a situation where the library gets into an infinite loop consuming all available resources on the machine. :-) |
| 16:31.36 | russellb | a tad slower, but at that rate, that's not going to be the bottleneck |
| 16:31.52 | seanbright | otherwiseguy: sounds like a feature to me |
| 16:31.52 | russellb | and it's also going to allow a much more powerful built-in database |
| 16:31.53 | otherwiseguy | Without transactions, it is much much worse. |
| 16:31.58 | russellb | instead of lame key-value storage |
| 16:32.53 | otherwiseguy | yeah, eventually I (or someone else) can add a different set of API functions that expose more than the weird /family/subfamily[]/key : value thing we have. |
| 16:32.57 | file | who wants to buy me a Tandberg video phone? |
| 16:33.09 | Qwell | file: ON IT |
| 16:33.11 | Qwell | not really |
| 16:33.13 | file | (although tecnically they are Cisco now, but I refuse to call them that) |
| 16:33.17 | russellb | file: tandberg does, ask them for one |
| 16:33.23 | russellb | file: or rather, 2 |
| 16:33.26 | Qwell | file: I'll buy you a Tandberg, if you buy me a Selsius. |
| 16:33.28 | kpfleming | file: BFCP over UDP! |
| 16:33.44 | russellb | WTF over WTF! |
| 16:33.58 | file | kpfleming, blinky floating chicken pompoms over UDP! |
| 16:34.05 | Qwell | russellb: I once legitimately said "I'm on an ATM ATM, ATM." |
| 16:34.10 | kpfleming | file: yes |
| 16:37.03 | seanbright | otherwiseguy: ... WHERE key LIKE '%' || '/' || ? |
| 16:37.16 | seanbright | isn't "key LIKE '%'" a noop? |
| 16:37.40 | Qwell | actually, no |
| 16:37.41 | otherwiseguy | no because it is concatted. it means "LIKE %/<param>" |
| 16:37.51 | seanbright | ohhhhhh, fancy |
| 16:37.54 | otherwiseguy | You can't bind parameters in a string literal. |
| 16:37.57 | Qwell | seanbright: it would actually be a huge performance hit, if you were right. |
| 16:38.02 | otherwiseguy | so you have to use || |
| 16:38.19 | seanbright | is that ansi sql? |
| 16:38.23 | seanbright | i've never seen || for concat |
| 16:38.38 | seanbright | Qwell: if only i was right |
| 16:38.39 | Corydon76-home | otherwiseguy: if you create an in-memory SQLite database, it's much faster, right? |
| 16:38.57 | russellb | but astdb has to be persistant |
| 16:39.03 | otherwiseguy | Corydon76-home: Nope. Not if you are using transactions. Transactions actually make it in-memory until a commit. |
| 16:39.05 | Corydon76-home | I'm thinking of the problem where data might be up to a second out of sync |
| 16:39.31 | otherwiseguy | Corydon76-home: It isn't out of sync as far as querying against it goes, just whether it is written to disk. |
| 16:39.43 | Corydon76-home | Okay, so SQLite allows you by default to read uncommitted transactions? |
| 16:39.45 | otherwiseguy | tested that just to be sure |
| 16:39.48 | otherwiseguy | yep |
| 16:40.15 | otherwiseguy | from the same connection, anyway. we are only using one connection, so we're good. |
| 16:40.42 | russellb | otherwiseguy: you should document these things in code comments :-) |
| 16:41.24 | seanbright | huh... || is standard. go figure. |
| 16:41.36 | Corydon76-home | russellb: If in-memory was much faster, we could, at boot, create an in-memory copy of the SQLite database and flush writes to disk the way we already do |
| 16:42.03 | *** join/#asterisk-dev irroot (~irroot@197.106.195.34) |
| 16:43.21 | seanbright | otherwiseguy: why not throw an order by on the showkey_stmt? |
| 16:44.15 | otherwiseguy | seanbright: yep, checked about || as well before using it. :-) |
| 16:45.06 | otherwiseguy | Corydon76-home: it is essentially what we are doing with the looping transactions. I didn't see a way with sqlite3 to have it dump the in-memory to disk occasionally, but I'm not sure it would offer a benefit. |
| 16:47.01 | Corydon76-home | otherwiseguy: well, supposing you did each sql statement twice, once to an uncommitted transaction to disk, and once to in-memory |
| 16:47.42 | otherwiseguy | seanbright: basically because there wasn't anything specifically sorting on the bdb. The key field is the primary key of the table so I'm pretty sure that the results will be sorted by that anyway (which is what bdb would have done). |
| 16:47.45 | Corydon76-home | BTW, there's a way for SQLite to allow uncommitted reads on multiple connections, as long as all connections are within the same process: http://www.sqlite.org/sharedcache.html |
| 16:48.09 | otherwiseguy | Corydon76-home: why would we go to the trouble though? |
| 16:48.29 | seanbright | otherwiseguy: ah, good call. |
| 16:48.32 | Corydon76-home | otherwiseguy: the question of repeatable reads was the reason |
| 16:48.48 | Corydon76-home | That is, reading uncommitted data |
| 16:48.59 | otherwiseguy | Corydon76-home: but since you can read uncommitted data.... |
| 16:49.29 | Corydon76-home | otherwiseguy: I was simply countering Russell's assertion that it had to be on disk as an objection |
| 16:50.04 | Corydon76-home | otherwiseguy: but since we can read uncommitted data, it's probably not worth it |
| 16:50.10 | otherwiseguy | I've tested and there is no performance benefit to doing things like a connection per thread, etc. |
| 16:50.14 | otherwiseguy | Ok. |
| 16:50.42 | irroot | once SQLite is inplace could ODBC / SQLx be used ?? |
| 16:50.52 | otherwiseguy | I don't like that it is currently possible to lose the last second of data on a restart, though. |
| 16:51.04 | Corydon76-home | irroot: could already be used |
| 16:51.22 | Corydon76-home | otherwiseguy: you can register an atexit |
| 16:51.52 | Corydon76-home | otherwiseguy: see ast_register_atexit |
| 16:51.56 | otherwiseguy | Corydon76-home: will do, thanks. |
| 16:54.03 | Corydon76-home | Yep, just verified that it should run after module shutdown, if exiting cleanly |
| 16:54.20 | otherwiseguy | irroot: I will work on getting Olle's patch updated to allow realtime support for the astdb as well. |
| 16:55.07 | irroot | yeah that is a winner been using FUNC_ODBC in favor of DB for long time |
| 16:55.15 | Corydon76-home | otherwiseguy: not sure why. If SQLite is available, then using a native SQLite database is much, much better than trying to use the workarounds in Olle's astdb realtime patch |
| 16:55.35 | otherwiseguy | Corydon76-home: multi-machine shared dbs? |
| 16:55.56 | otherwiseguy | web frontends not located on the same machine? |
| 16:56.11 | otherwiseguy | only having to use one kind of database for your whole product, etc. |
| 16:56.26 | Corydon76-home | Oh, I'm thinking of the other direction... realtime in astdb |
| 16:56.32 | Corydon76-home | not astdb in realtime |
| 16:56.44 | Corydon76-home | Still, multi-machine astdb is a bad idea |
| 16:56.58 | otherwiseguy | Corydon76-home: depends on if the machines are doing the same things |
| 16:57.21 | Corydon76-home | otherwiseguy: well, okay, if they're doing different things, there's less of a problem |
| 16:57.27 | otherwiseguy | one *could* design it to be safe if they were just using a voicemail server, etc. |
| 16:57.34 | otherwiseguy | and wanted access to some other shared data. |
| 16:57.44 | otherwiseguy | not the way I would probably design things, but to each their own. :-) |
| 16:57.54 | otherwiseguy | We are in the giving people enough rope to hang themselves business. ;-) |
| 16:58.02 | Corydon76-home | otherwiseguy: but people would reasonably expect no harm to come from sharing astdb across machines doing similar things, which is why we should not. |
| 16:58.57 | Corydon76-home | otherwiseguy: the danger is that we are blamed for something they should not be doing, and that's bad press for us |
| 16:59.23 | Corydon76-home | So we should, at the very least, make it unpossible to do unless they modify their own source |
| 16:59.24 | otherwiseguy | We wouldn't be telling them that was the reason there was realtime support. Ostensibly it would be so that their web front-end could have easy access to the data or something. If people want to do something stupid just because it is technically possible, well... there are lots of ways they can do that already with Asterisk. |
| 17:00.01 | Corydon76-home | otherwiseguy: heh, add a hostname field to astdb-by-realtime |
| 17:00.28 | otherwiseguy | Corydon76-home: seems like an easy-enough solution. |
| 17:00.37 | Corydon76-home | That would make it very difficult to screw with, unless they did something really stupid, like setting all their hostnames to the same thing |
| 17:01.29 | Corydon76-home | I think I like that as the solution. They get all the benefits of sharing, very few of the risks |
| 17:01.35 | otherwiseguy | Corydon76-home: Although I'd still want to make it possible to query data from other machines. It would be an easy way of sharing data. |
| 17:01.36 | irroot | my table for RT via FUNC_ODBC is id,server,family,key,value |
| 17:01.53 | irroot | so im most the way there already |
| 17:02.27 | Corydon76-home | irroot: separating family and key is a problem, though, because it's sometimes not clear where the delineation is |
| 17:02.27 | irroot | astdb is used for internal bits only |
| 17:02.34 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:02.52 | irroot | indeed i kept it as close to the astdb way as possible |
| 17:03.30 | irroot | does allow things to be shared like call waiting setting / fwd settings .... |
| 17:03.30 | Corydon76-home | irroot: I'm saying separating those bits is probably better done with a query, not as separate fields |
| 17:04.12 | Corydon76-home | Yep, the pitfalls I'm primarily concerned with are the implicit bits embedded in the code |
| 17:04.31 | Corydon76-home | You can hang yourself with your own code, and it doesn't hurt the project any |
| 17:04.34 | irroot | id rather leave it in the deployers hands to do this and not have it "digium"ed |
| 17:04.41 | irroot | snap |
| 17:05.13 | Corydon76-home | func_odbc is a great tool to give to deployers |
| 17:05.28 | Corydon76-home | It's the implicit stuff that gets safeguards |
| 17:06.45 | *** join/#asterisk-dev michael-i (~anonymous@204.11.230.58.static.etheric.net) |
| 17:20.53 | *** part/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 17:20.54 | *** join/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 18:11.16 | *** join/#asterisk-dev Corydon76-home (one@c-69-137-80-31.hsd1.tn.comcast.net) |
| 18:11.16 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 18:18.49 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:18.49 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:23.49 | irroot | leifmadsen ASTERISK-17866 got new patch that respects subscribemwi |
| 18:23.50 | CaptainPants | [ASTERISK-17866] [Status: Open] [patch] MWI last-msgs-sent is mis-reported - https://issues.asterisk.org/jira/browse/ASTERISK-17866 |
| 18:24.01 | leifmadsen | awesome |
| 18:24.05 | leifmadsen | runs off to the bank |
| 18:25.32 | irroot | the problem with the last one is that it generated a notify with mwi all the time |
| 18:26.39 | irroot | now if subscribemwi is set notify with mwi will only be sent once subscribed |
| 18:40.34 | *** join/#asterisk-dev ManxPower (~ewieling@140.sub-75-253-217.myvzw.com) |
| 18:43.34 | ManxPower | https://issues.asterisk.org/view.php?id=16625 I do not see any indication this patch is in 1.8.4, even though the commit message message seems to indicated it is in there. Am I reading the changelog wrong, I see nothing in the changlog that indicates the commits listed in this issue are in 1.8.4 |
| 18:51.21 | tzafrir_laptop | Does reviewboard work for dahdi-tools? If so: what settings do I need to set? |
| 19:03.00 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-mzkuwjytmdzbjljh) |
| 19:06.08 | Qwell | ManxPower: The tag was made before that was committed. There's no indication on that issue that it's in 1.8.4. |
| 19:06.19 | irroot | http://eclipse.slooh.com <- what is happening outside but its too cold ... so watching the stream .... im off to see the moon turn red |
| 19:06.39 | Qwell | I see nothing in the commit message that claims such. |
| 19:10.38 | Corydon76-home | ManxPower: release tags are built from prior release candidates, not from the branch. It's an oft-repeated error to believe that release tags are made from the branch. |
| 19:10.59 | ManxPower | Corydon76-home, *nod* I guess I'll have to check out the 1.8 branch to get the fix? |
| 19:12.04 | ManxPower | Qwell, not sure what you mean about the issue not being in 1.8.4. There is a commit for that bug in 1.8.x. That to me indicates the issue exists in 1.8.x. Is that correct? |
| 19:12.13 | Corydon76-home | Correct. It may even be possible to merge a single fix onto a checkout of the release tag, but that configuration is not explicitly supported |
| 19:12.39 | Qwell | I didn't say the issue isn't in 1.8.4. |
| 19:14.00 | ManxPower | " no indication on that issue that it's in 1.8.4" did you mean FIX instead of "issue"? |
| 19:14.01 | Corydon76-home | He said there's no indication that the fix for the issue is in 1.8.4 |
| 19:14.12 | ManxPower | Cool. |
| 19:14.36 | ManxPower | I assume there is no ETA for 1.8.5? |
| 19:14.59 | Corydon76-home | ETA between releases is usually 4-6 weeks |
| 19:16.10 | Corydon76-home | but it's affected by testing of release candidates |
| 19:17.00 | ManxPower | I think we will hold off routing calls to Level3 from our Asterisk boxes until issue is resolved in an Asterisk release |
| 19:17.23 | ManxPower | Only a small percent of our calls are from Astrisk, so it is not a significant issue. |
| 19:17.28 | ManxPower | Thanks for the information everyone! |
| 19:19.17 | *** part/#asterisk-dev ManxPower (~ewieling@140.sub-75-253-217.myvzw.com) |
| 19:51.40 | *** join/#asterisk-dev philippel_mac (~p_lindhei@74-92-226-109-Washington.hfc.comcastbusiness.net) |
| 20:19.32 | *** join/#asterisk-dev otherwiseguy_ (~terry@68-70-72-166.static.kc.surewest.net) |
| 20:41.58 | *** join/#asterisk-dev tamiel (~tamiel@ip-28.net-81-220-88.toulouse.rev.numericable.fr) |
| 21:33.55 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 21:33.55 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:56.00 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:56.00 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:37.31 | *** join/#asterisk-dev datachomper (~Adium@207.98.189.248) |
| 23:31.58 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 23:37.28 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:37.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:46.06 | *** join/#asterisk-dev Mw3 (mw3@mw3.hu) |
| 23:53.30 | *** join/#asterisk-dev russellb_ (~russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:53.30 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 23:58.39 | *** join/#asterisk-dev n0tk (~n0tk@gateway/tor-sasl/n0tk) |