00:37.15 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
00:37.15 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
01:43.10 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
01:43.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
02:31.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
02:31.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
03:22.04 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
03:22.05 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
03:54.52 | *** join/#asterisk-dev atcmmi (~atcmmi@119.123.222.160) |
05:32.56 | *** join/#asterisk-dev suneye (~atcmmi@119.123.222.160) |
06:21.54 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
06:21.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
07:32.26 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
07:32.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
07:38.22 | oej | Morning folks |
07:42.11 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
07:42.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
07:58.00 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
08:06.53 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a90a:b5d2:62ff:fe32) |
09:11.32 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
09:48.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
09:48.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
12:30.01 | *** join/#asterisk-dev suneye (~xxxxyz@183.17.209.27) |
12:45.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
12:45.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
12:54.36 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-lzkhnwwwvnvyrmpc) |
12:54.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
12:55.41 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nfkwkcgmwjsuzhdp) |
13:50.07 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
13:50.07 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
14:10.24 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-bhzyprxrkaeckkrv) |
14:12.50 | *** join/#asterisk-dev RadJackson (~RadJackso@cpe-et000092.cust.jaguar-network.net) |
14:12.51 | RadJackson | Hello , i make some automatic phonecalls , by placing ".call" files into /var/spool/asterisk/outgoing folder, every minute asterisk launch one file, only 30% of the calls works, the other 70% displays an error message saying pbx_spool.c: Call failed to go through, reason (3) Remote end Ringing / devicestate.c: No provider found, checking channel drivers for SIP- XXX |
14:12.53 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
14:13.15 | Qwell | RadJackson: Your question would be better answered in #asterisk. |
14:13.30 | RadJackson | Ok thank you. |
14:21.34 | mjordan | leedm777: opticron: I think our decision to make all channels suffixed is going to have a lot of annoying event changes |
14:22.02 | leedm777 | mjordan: example? |
14:24.03 | mjordan | ChanSpyStart/Stop, DialBegin/End, Transfer events, Pickup |
14:24.38 | mjordan | as it turns out, I'm not sure that the channel will ever be suffixed. Originally, the suffix occurred during Bridge events, but those have been superceded by BridgeEnter/BridgeLeave, which only list a single channel |
14:24.56 | mjordan | Now, I'm not sure when we'll have multiple channels in an event that is not role based |
14:25.01 | mjordan | and all of the role based events use a prefix |
14:25.15 | mjordan | this feels like a bad specification decision that was admittedly written by me |
14:25.55 | leedm777 | shame on you |
14:26.18 | mjordan | I know |
14:26.32 | mjordan | I'm writing up the ChangeLog and "ChannelSpyer" looks okay, but "ChannelUniqueidSpyer" is annoying |
14:26.43 | mjordan | SpyerChannel, SpyerChannelUniqueid, etc. |
14:26.56 | mjordan | of course, suffix might be easier to parse as opposed to read... blech |
14:27.25 | leedm777 | nah, the name wouldn't matter to parsing. |
14:27.43 | mjordan | true, endswith is just as easy as beginswith |
14:28.00 | mjordan | it feels like a pointless syntax change |
14:28.13 | leedm777 | and I do hate pointless changes... |
14:28.14 | mjordan | and I'd have a hard time defending it at this point |
14:29.05 | mjordan | I can picture it now. "Pipes to commas we understand. But why'd you switch all the names around???" |
14:29.07 | mjordan | uhmmmm..... |
14:29.18 | file | cause it's Friday |
14:29.23 | Qwell | and there are bagels |
14:29.28 | leedm777 | I know we have some events that suffix channel and uniqueid... |
14:29.39 | leedm777 | but I think they all suffix with integers (channel1, channel2) |
14:30.09 | mjordan | leedm777, which ones? |
14:30.15 | leedm777 | trying to remember |
14:30.47 | mjordan | It was Bridge in 11 |
14:30.49 | leedm777 | Yes. |
14:30.52 | mjordan | but that's now gone the way of the DoDo |
14:30.52 | leedm777 | and Park in 11 |
14:30.56 | mjordan | (poor silly bird) |
14:31.10 | opticron | s/silly/delicious/ |
14:31.28 | leedm777 | At the time, those were the events we were looking at |
14:31.53 | leedm777 | and we were like "all these events are suffixed with numbers, let's suffix events with role names instead" |
14:31.55 | mjordan | Bridge isn't a problem. Park usually has roles |
14:32.09 | mjordan | I remember, I think I was wrong :-P |
14:32.18 | leedm777 | oh, you're right |
14:32.20 | mjordan | the numbered events have gone away, and now we're changing more than we're keeping |
14:32.27 | leedm777 | I'm looking at the park actions |
14:32.51 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
14:32.51 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
14:33.12 | leedm777 | anywho |
14:33.20 | mjordan | It's trivial to switch to prefix... but I figure we may as well make the decision now, as I want to go update the spec today |
14:33.36 | leedm777 | I'm fine with changing 12 to prefix if that makes for less churn. |
14:33.40 | mjordan | I think it will |
14:33.53 | leedm777 | then DO IT! |
14:33.54 | mjordan | checks to see if we have a quorum |
14:34.01 | mjordan | seconds the motion |
14:34.23 | leedm777 | I see what you did there. |
15:27.57 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
16:00.46 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
16:00.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
16:01.13 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:100b) |
16:01.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
16:06.09 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:100b) |
16:06.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
16:21.04 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
16:45.52 | mjordan | protip: when running tests, make sure you don't already have Asterisk running. |
17:35.43 | opticron | very important |
17:36.28 | opticron | the most annoying one for me was when valgrind had gone off into the weeds and wasn't attached to any terminal, but still had asterisk running in the background somewhere |
17:37.46 | seanbright | is there a minimum version of gcc that we require to build asterisk? |
17:37.50 | seanbright | trunk, specifically |
17:38.58 | seanbright | the README says 3.0 |
17:39.26 | mjordan | eek. That's older than I think we test with |
17:39.46 | mjordan | 4.2.4 is probably the oldest we test with |
17:39.58 | seanbright | 3.0 was released on june 18, 2001 |
17:40.00 | seanbright | heh |
17:40.12 | seanbright | just needed to get past the 2.95 hump |
17:40.13 | mjordan | 12 years isn't exactly new :-) |
17:42.04 | file | uses bleeding edge |
17:42.32 | file | Richard hangs on to the old for dear life, I surge ahead! |
17:42.48 | seanbright | looks like the cleanup attribute wasn't added until at least 3.3 |
17:43.01 | seanbright | (RAII_VAR) |
17:44.03 | Qwell | mjordan: 4.1.2 |
17:44.06 | Qwell | CentOS5 |
17:44.39 | Corydon76-work | I wish we could get rid of support for 4.1. There's a rather nasty bug in that version as it relates to alias support |
17:45.02 | Qwell | Corydon76-work: el5 goes EOL in like a year |
17:45.27 | Corydon76-work | Good riddance |
17:45.36 | blitzrage | +1 |
17:46.14 | Qwell | heh, nevermind |
17:46.18 | Qwell | 2017-03-31 (End of Production 3 / End of Regular Life Cycle) |
17:46.21 | Corydon76-work | There's quite a bit of cleanup in the alias support that will be possible once we lose that version |
17:46.24 | Qwell | Q1 2014 (End of Production 2) |
17:47.36 | Corydon76-work | Alternatively, we compile and release RPMs for that version that use a later compiler... and when people complain about official support, we point them to the official rpms |
17:48.32 | Corydon76-work | optional_api was delayed for a full release, specifically due to that issue |
17:51.54 | mjordan | I don't think we'll drop RAII_VAR at any point. That cat is *way* out of the bag. |
17:53.32 | Corydon76-work | If Apple would add constructor priorities in their version of gcc, that would solve a longstanding bug. |
17:53.41 | *** join/#asterisk-dev saghul__ (~saghul@ip3e830637.speed.planet.nl) |
17:54.03 | Corydon76-work | A bug that manifests on BSD-derived operating systems, only |
17:55.18 | Corydon76-work | I'm back-and-forth about whether we want to support OS X officially or not |
17:56.02 | mjordan | At this point, if we add an OS to the 'official support list', there needs to be someone who's willing to step up to the plate and fix compatibility bugs |
17:56.39 | mjordan | BSD, anything Solaris based, and sometimes OS X suffer from a lack of a throat to throttle when things break |
17:56.51 | Corydon76-work | I would love to have support for it, but Apple doesn't make it easy, doing things like deprecating POSIX interfaces. |
17:56.51 | Qwell | mjordan: Corydon76-work said he'd support cygwin. |
17:57.11 | mjordan | Qwell: owch man. Owch. |
17:57.53 | Corydon76-work | Qwell: I'll support it with a tower of ice cubes at the equator |
17:58.04 | mjordan | MOAR ICE |
17:58.55 | Corydon76-work | New rule, though... whenever we drop support for an architecture, we have to yell, "Jenga!" |
18:17.05 | seanbright | support for the cleanup attribute was added in gcc 3.4.0 |
18:17.42 | seanbright | /maybe/ 3.3.1, but i doubt it |
18:20.13 | seanbright | sure enough, i am wrong |
18:20.47 | seanbright | i'm as surprised as the rest of you |
18:21.21 | Corydon76-work | I'm never surprised when you're wrong. |
18:21.22 | seanbright | 3.3.1 - that is our minimum version |
18:21.23 | mjordan | seanbright: sorry :-\ |
18:21.58 | mjordan | once you start using RAII_VAR, you'll never go back to your old compiler :-) |
18:22.13 | seanbright | i'm on a fairly new compiler |
18:22.29 | seanbright | just thinking about adding something that will use a newer feature of gcc (ifunc attribute) |
18:22.55 | Corydon76-work | mjordan: what if my old compiler is a 16-bit compiler that runs on an Apple IIgs? |
18:23.20 | mjordan | uhm. hm. I'm sure gcc accepts patches |
18:23.35 | seanbright | and it looks like 4.0.0 may be the minimum version that supports ifunc |
18:23.38 | seanbright | oh well |
18:23.47 | Corydon76-work | I doubt Mike Westerfield is still accepting patches for ORCA/C. |
18:24.33 | seanbright | annd it's ELF only anyway. fails all around. |
18:26.46 | leedm777 | mentions clang, just because |
18:26.59 | seanbright | egcs |
19:00.29 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
19:04.53 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
19:45.09 | wedhorn | mjordan: ping |
19:50.39 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-frhyxhhwzyuihwrc) |
20:03.09 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
20:03.09 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
20:05.31 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
20:13.30 | JunK-Y | mooo! |
20:20.37 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
21:44.44 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
21:50.50 | mjordan | wedhorn: pong (sorry for the late reply) |
21:51.25 | mjordan | also: leedm777: currently the CDR/CEL manager backends directly access AMI. I'm pondering whether pushing that over Stasis-Core is worthwhile, since CDR/CEL engines will already be generating their information over Stasis-Core |
21:51.37 | mjordan | it feels round-about-ish to re-generate it into Stasis-Core at that point |
21:52.03 | wedhorn | mjordan: no worries |
21:52.19 | wedhorn | r2393 seems to have turned into a philosophical debate about the direction asterisk is heading in terms of running stuff through the dialplan |
21:52.35 | wedhorn | any chance of some guidance |
21:52.58 | mjordan | I haven't really looked at it yet - I can over the weekend if that's okay |
21:53.31 | wedhorn | that'd be great, been going around for a while now anyway |
21:58.07 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-fjgxfpueazkzaeaq) |
21:59.30 | leedm777 | mjordan: I agree. Having something that's feeding off stasis event to generate more stasis events just for the purpose of converting those to AMI events. ew. |
22:26.34 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-fjgxfpueazkzaeaq) |
22:59.47 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-lzkhnwwwvnvyrmpc) |