| 00:02.41 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 00:02.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 00:08.20 | jsmith | Anybody care to look at a backtrace from a segfault? |
| 00:08.42 | jsmith | Appears to be related to masquerading in the ParkAndAnnounce application |
| 00:12.22 | snuff-work | mm there was an issue about parkand announce |
| 00:12.30 | snuff-work | on the bugtracker |
| 00:12.48 | jsmith | Oh? |
| 00:12.54 | jsmith | Happen to have the number handy? |
| 00:13.00 | jsmith | I searched, but couldn't find anything relevant |
| 00:13.12 | snuff-work | mm 1 sec |
| 00:13.34 | snuff-work | give me a link to the bt.. |
| 00:13.42 | snuff-work | might have seen something similar.. |
| 00:13.59 | snuff-work | (though i suck at readin em.. i might have 'seen' similar before) |
| 00:14.17 | jsmith | http://pastebin.com/5GJ0CUnU |
| 00:15.19 | snuff-work | https://issues.asterisk.org/view.php?id=16804 |
| 00:16.21 | snuff-work | what about a 'bt full' |
| 00:24.27 | jsmith | snuff-work: That appears to be the problem... thanks for the link to that bug |
| 00:25.29 | snuff-work | np :) |
| 00:26.05 | snuff-work | i dont do much 'Marshalling' these days.. but i do watch occasional issues :) |
| 00:44.47 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 00:44.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:29.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:29.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:58.12 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:58.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 02:40.50 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 02:59.41 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 06:21.26 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 06:21.45 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 06:42.19 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 06:57.42 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 06:57.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:24.41 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 08:12.01 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:39.41 | wedhorn | mvanbaak: another skinny patch for you |
| 08:39.56 | wedhorn | I think that is the end of the easy transmit_* stuff |
| 08:40.17 | *** join/#asterisk-dev steliosk (~Stelios@athedsl-413323.home.otenet.gr) |
| 08:40.35 | wedhorn | Will probably start looking at substate handling when these are committed |
| 09:09.59 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:09.59 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:16.22 | *** join/#asterisk-dev steliosk (~Stelios@ipa107.2.tellas.gr) |
| 10:06.57 | mvanbaak | wedhorn: thanks. I think both are good to go in :) |
| 10:07.05 | mvanbaak | wedhorn: need to test them with my 7960 |
| 10:18.32 | wedhorn | mvanbaak: no probs |
| 10:25.51 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 10:57.56 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:57.56 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:02.07 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 11:04.36 | *** join/#asterisk-dev Gugge (~gugge@vlan2.dlxhosting.dk) |
| 11:15.49 | tzafrir | DAHDI-linux seems to have no problems with kernel 2.6.34-rc1 :-) |
| 11:41.31 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:41.31 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:15.51 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:40.16 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:40.16 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:12.43 | lbarth | tzafrir, System uptime: 1 day, 18 hours, 14 minutes, 52 seconds |
| 13:41.28 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 13:46.18 | *** join/#asterisk-dev Pazzo (~ugelt@reserved-225136.rol.raiffeisen.net) |
| 13:48.02 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 14:28.56 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 15:10.21 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:10.22 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:14.42 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 15:19.00 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 15:19.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:48.34 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:48.34 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:55.58 | *** join/#asterisk-dev moy (~chatzilla@74.12.129.100) |
| 15:59.37 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:59.45 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 16:02.55 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:02.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:05.22 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:05.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:17.35 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 16:18.28 | atis_work | cool, asterisk doesn't crash with glusterfs-booster like mc does :p |
| 16:20.35 | tzafrir | Do we really need debug level 1000? http://pastebin.ca/1830191 |
| 16:21.28 | atis_work | it's more important than 999 :D |
| 16:21.39 | atis_work | /s/more/less/ |
| 16:23.25 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 16:25.46 | *** join/#asterisk-dev vrban (~chatzilla@p50997436.dip0.t-ipconnect.de) |
| 16:26.41 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:41.42 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:41.42 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:59.21 | *** join/#asterisk-dev korihor (~korihor@190.205.251.97) |
| 17:59.11 | *** join/#asterisk-dev Corydon76-dig (peuce@c-69-137-80-31.hsd1.tn.comcast.net) |
| 17:59.11 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 18:10.42 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:10.42 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:16.40 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 18:59.11 | *** join/#asterisk-dev codefreeze-lap (~murf@mail.parsetree.com) |
| 18:59.12 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 18:59.55 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 18:59.55 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:01.07 | *** join/#asterisk-dev Madoc (~Madoc@bas8-toronto63-1177708113.dsl.bell.ca) |
| 19:01.22 | *** part/#asterisk-dev Madoc (~Madoc@bas8-toronto63-1177708113.dsl.bell.ca) |
| 19:01.33 | snuff-home | Corydon76-dig: ping? |
| 19:07.11 | wedhorn | snuff-home: someone on whirlpool is wanting someone to install queue callback, you know anyone? |
| 19:07.13 | wedhorn | http://forums.whirlpool.net.au/forum-replies.cfm?t=1400273 |
| 19:07.44 | wedhorn | oh yeah, morning, you're up early |
| 19:07.46 | *** join/#asterisk-dev ecrane (~ecrane@o1-69-19-166-10.static.o1.com) |
| 19:11.20 | Corydon76-dig | snuff-home: pong |
| 19:12.16 | snuff-home | your parsing in cdr_sqlite3_custom is broken |
| 19:12.44 | Corydon76-dig | Sweet, what's wrong? |
| 19:13.01 | snuff-home | you seperate on ', |
| 19:13.25 | snuff-home | so if you use a option of '{CDR(field,f)}' |
| 19:13.34 | snuff-home | oops.. add a $ |
| 19:14.37 | Corydon76-dig | What section is that in? |
| 19:15.16 | snuff-home | line 95 |
| 19:15.39 | snuff-home | oops 133 |
| 19:16.41 | snuff-home | gotta go for a while.. need to get ready for work |
| 19:16.45 | Corydon76-dig | Aha |
| 19:16.52 | Corydon76-dig | Have you filed an issue on this? |
| 19:16.57 | snuff-home | not yet.. |
| 19:17.06 | snuff-home | found it while testing hr_cdr |
| 19:17.07 | Corydon76-dig | Go ahead. I'll confirm it |
| 19:17.15 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:17.32 | snuff-home | k will have entry in about 3 hrs when i get to work |
| 19:17.45 | Corydon76-dig | Thank you |
| 19:38.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:38.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:44.05 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 19:44.05 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 19:44.26 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:07.25 | wedhorn | mvanbaak: i've been pondering you skinny rtp timeout, any reason you couldn't just use the rtp send to increment a counter and the rtp receive to reset the counter |
| 20:08.30 | wedhorn | it wouldn't be exact, but would get you within a few 10's of milliseconds, even without locks |
| 20:09.28 | wedhorn | most of the time anyway |
| 20:12.07 | wedhorn | or set the counter atomically or use a sub lock |
| 20:17.59 | wedhorn | mvanbaak: actually skinny_read and _write already use sub->lock, so should be fairly trivial. In skinny_write if sub->rtpcount++ > 500 kill sub, in skinny_read sub->rtpcount = 0 |
| 20:20.11 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 20:33.40 | tzafrir | can anybody please give a sanity check to https://issues.asterisk.org/view.php?id=14577#119173 ? (dahdi ring from FXO issue in 1.6.x) |
| 20:34.08 | tzafrir | If it's true, the code there has never done what it was supposed to do |
| 20:36.32 | alecdavis | leifmadsen: are you able to change the summary on 16981, to 'PRI support for CPE-CPE crossover' |
| 20:36.59 | alecdavis | the magic word. please |
| 20:37.02 | leifmadsen | alecdavis: yes sir |
| 20:37.06 | leifmadsen | M16981 |
| 20:37.08 | MuffinMan | [new] [LibPRI] NewFeature 0016981: [patch] PRI loopback support, when in CPE mode. reported by alecdavis https://issues.asterisk.org/view.php?id=16981 |
| 20:37.42 | leifmadsen | alecdavis: done |
| 20:39.16 | alecdavis | thanks, the description we wont worry about. That suggests loopback works, when infact it doesn't. |
| 20:39.27 | alecdavis | and never will. |
| 20:41.28 | tzafrir | alecdavis, does CPE-CPE make sense signalling-wise? |
| 20:42.21 | tzafrir | Doesn't this break things somewhere up the stack? |
| 20:42.39 | tzafrir | CAS/E&M is more symmetric |
| 20:43.28 | tzafrir | But even with it Asterisk keeps getting annoyed about an incoming call to a channel that is already busy (calling out) |
| 20:44.09 | tzafrir | I'm not sure what's the exact PRI equivalent, but I believe that there is |
| 20:46.36 | mvanbaak | wedhorn: I was using the _read and _write function to increment/decrement the counter |
| 20:47.05 | mvanbaak | wedhorn: but for the detection of a stale connection .... I was looking too hard at chan_sip I think |
| 20:52.14 | kpfleming | mvanbaak: wedhorn: the rtp stack already has its own facilities for detection of a dead connection |
| 20:52.50 | alecdavis | tzafrir: no where in the q.921 spec could I find that it shouldn't work, the only bit that differentiates between NETWORK/CPE is the C/R command/response, this inverts when its a NETWORK versus CPE. So the only bit that needs changing for a CPE-CPE crossover to be set up, is the function is_command(). |
| 20:52.55 | wedhorn | kpfleming: why would I look at that, it's not in chan_skinny.c ;) |
| 20:53.01 | kpfleming | of course |
| 20:53.33 | kpfleming | alecdavis: for basic calling that is probably true. for call features the CPE and NT sides are quite different. |
| 20:54.13 | tzafrir | alecdavis, what happens when you get an incoming call to a channel that is in state RING? |
| 21:06.20 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 21:12.12 | seanbright | commit asterisk 200000 |
| 21:12.14 | MuffinMan | [200000] Committed by seanbright on 2009-06-10T20:40:41.975868Z: Remove some trailing whitespace and steal revision 200000. |
| 21:12.14 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=200000 |
| 21:12.26 | seanbright | i was so awesome back then |
| 21:12.38 | alecdavis | tzafrir: channel glare. Happens already from the network. refer 16755 it captures basically the problem. |
| 21:12.51 | Qwell | seanbright: what happened? |
| 21:13.06 | Qwell | (I kid) |
| 21:13.06 | seanbright | Qwell: you're better than that |
| 21:13.15 | Qwell | you're right - too easy |
| 21:25.56 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 21:29.12 | tzafrir | alecdavis, so you want to allow both the outgoing and the incoming call to coexist on the same channel (time-slot) |
| 21:30.17 | tzafrir | which is kind of a wierd behaviour |
| 21:31.19 | kpfleming | tzafrir: i don't think that's true. even when the link is CPE-CPE, they will still attempt to negotiate an available B-channel for the call |
| 21:31.27 | alecdavis | tzafrir: I understood that can't happen, if it could then loopback would work. |
| 21:31.47 | alecdavis | I should read, before pressing enter. |
| 21:33.37 | tzafrir | kpfleming, but is there anything along the line to copy the data from the original timeslont to the negotiated timeslot? |
| 21:34.02 | alecdavis | fwiw, I setup a basic CPE-CPE, on an E1 lastnight, all 15 calls setup, and had a speechpath to the echo app. I understand now that at q.931 some non-basic calls are reliant on being Network and CPE. |
| 21:34.22 | kpfleming | tzafrir: copy what data? |
| 21:34.32 | tzafrir | the audio |
| 21:34.34 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 21:34.35 | tzafrir | the pcm |
| 21:34.41 | kpfleming | that's not necessary |
| 21:34.48 | kpfleming | there is only one timeslot with audio |
| 21:42.58 | tzafrir | which is why negotiating a different one is pointless |
| 21:43.25 | tzafrir | anyway, any thoughts on https://issues.asterisk.org/view.php?id=14577#119173 ? |
| 21:43.59 | alecdavis | correction, reads wrong, I should have said "I set up an E1 CPE-CPE link between 2 boxes"... and had audio. |
| 21:45.05 | kpfleming | tzafrir: what is 'pointless'? it's never pointless to negotiate a different timeslot, it happens all the time, and whether it is NET-CPE or CPE-CPE (or even NET-NET, if that works) doesn't really matter |
| 21:45.23 | kpfleming | at any given moment in time, both ends can have channels in intermediate states that the other end is not yet aware of |
| 21:47.19 | Kobaz | i dont think net-net works |
| 21:47.45 | Kobaz | and i dont think cpe-cpe works either |
| 21:48.39 | Kobaz | or at least from what i've seen |
| 21:48.46 | alecdavis | kabaz: your right, libpri complains. |
| 21:52.38 | Kobaz | almost time to go ski |
| 21:54.17 | Kobaz | remove the old asterisk modules from /usr/lib/asterisk/modules |
| 21:54.19 | Kobaz | er |
| 22:00.02 | tzafrir | kpfleming, it could have worked if you could have separated the tx and rx of both channels |
| 22:01.19 | tzafrir | but as this is loopback, the rx of the channel is the same a its tx |
| 22:01.39 | kpfleming | no, we're not talking about loopback |
| 22:01.46 | kpfleming | he's already confirmed loopback will not work |
| 22:02.03 | tzafrir | ah, ok |
| 22:02.31 | Corydon76-dig | Yeah, the best you can do for that situation is a loopback cable between two different ports |
| 22:03.16 | Kobaz | speaking of t1 |
| 22:03.38 | Kobaz | how would i get more info to debug this libpri crash |
| 22:03.41 | tzafrir | how can you test a loop? |
| 22:04.16 | tzafrir | apart from the fact that the immediate cries of "we're not CPE" indicate that the D-channel is properly passed |
| 22:04.17 | Corydon76-dig | Well, that's not really a loopback cable... it's a T1 crossover cable |
| 22:04.54 | Kobaz | there it is |
| 22:04.55 | Kobaz | https://issues.asterisk.org/view.php?id=16913 |
| 22:05.08 | alecdavis | tazfrir: http://www.patentstorm.us/patents/6657971/description.html |
| 22:05.14 | Kobaz | is there like... a more-intensive-debug |
| 22:05.18 | Kobaz | for pri? |
| 22:05.20 | Corydon76-dig | Kobaz: I think you're looking for pri intense debug |
| 22:05.29 | Kobaz | yeah i need something more than that |
| 22:05.36 | Corydon76-dig | though it got renamed in 1.6 |
| 22:05.51 | Kobaz | because it crashed and there was no debug output before the crash |
| 22:06.02 | Kobaz | other than some stuff from another call about 5 seconds prior |
| 22:06.11 | alecdavis | tzafrir: if your asking how to test for a loop, the method I just posted is already patented. |
| 22:06.34 | Corydon76-dig | Kobaz: pri set debug {<level>|on|off} span <span> |
| 22:06.46 | Kobaz | yeah but |
| 22:06.48 | Corydon76-dig | Level is only 0, 1, or 2. |
| 22:06.49 | tzafrir | alecdavis, no. to test that a line works properly, given that I have a loop |
| 22:06.50 | Kobaz | is there more than that? |
| 22:06.52 | Kobaz | oh |
| 22:06.55 | Corydon76-dig | No, that's it |
| 22:06.58 | Kobaz | hmm |
| 22:07.02 | Corydon76-dig | 2 gives you every single packet |
| 22:07.03 | Kobaz | what level is intense? |
| 22:07.07 | Kobaz | okay good |
| 22:07.12 | tzafrir | 2 |
| 22:07.31 | Kobaz | oh |
| 22:07.31 | Corydon76-dig | 0 is off, 1 is on, 2 is intense |
| 22:07.39 | Kobaz | so that's not more than what i have already |
| 22:08.01 | Corydon76-dig | No, sorry. If you want more, you'd need to alter libpri |
| 22:08.43 | alecdavis | tzafrir: after applying 16981, if the loopback is ok, you see the call setup and teardown, just won't have a speechpath. |
| 22:08.43 | Kobaz | ideally it should log every last little bit to a log file |
| 22:09.47 | Corydon76-dig | It only logs what it understands |
| 22:10.06 | Kobaz | actually |
| 22:10.08 | Kobaz | you know |
| 22:10.19 | Kobaz | this is a problem with sending something out in libpri |
| 22:10.25 | Kobaz | so incoming logging wouldn't help |
| 22:10.38 | Kobaz | it's crashing on sending an indication |
| 22:12.27 | tzafrir | If anybody is truly bored and wants to do something about it: |
| 22:13.13 | tzafrir | wireshark can help here. you need to reformat the raw data, though |
| 22:13.28 | Kobaz | i added more info to the ticket |
| 22:13.35 | Kobaz | i posted the bt full, and the code that crashed |
| 22:15.06 | Kobaz | the problem is, this is one of those 'it crashes at the worst time, and i can't get to crash on demand' type problem |
| 22:16.09 | Kobaz | maybe after closing time i'll run asterisk under valgrind, make some calls, and see if it's doing anything naughty |
| 22:16.23 | *** join/#asterisk-dev jsmith (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 22:16.23 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 22:17.00 | Kobaz | i'll post a bounty if you guys are interested |
| 22:17.20 | Corydon76-dig | only does naughty things during off hours |
| 22:17.41 | *** join/#asterisk-dev jsmith (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 22:17.41 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 22:25.32 | mvanbaak | kpfleming: hhmm, so the rtptimeout in chan_sip is useless nowedays ? |
| 22:27.23 | kpfleming | josh says maybe, maybe not |
| 22:27.34 | kpfleming | apparently it's not implemented as elegantly as it could be :-) |
| 22:27.37 | file | I say chan_sip is in charge of actually determining if it timed out |
| 22:27.49 | file | if it stopped |
| 22:28.29 | mvanbaak | ok, so we still need it in chan_skinny |
| 22:28.54 | mvanbaak | the problem is with the wifi skinny phones |
| 22:29.03 | mvanbaak | they sometimes get out of range |
| 22:29.16 | mvanbaak | and the reregister when they have link again causes trouble sometimes |
| 22:29.33 | mvanbaak | rtptimeout as chan_sip has will fix this |
| 22:41.31 | kpfleming | mvanbaak: so will session timers, which are not subject to reinvite issues, or lack of audio when put on hold |
| 22:53.24 | mvanbaak | uhhuh |
| 22:56.04 | mvanbaak | well, now that wedhorn fixed the transmit_* mess in chan_skinny, we are ready to move on and fix the sub handling |
| 22:56.23 | mvanbaak | which will make autoanswer possible as well |
| 22:56.49 | snuff-work | Corydon76-dig: bug made.. 17001 .. damn just missed 17000.. |
| 22:56.53 | mvanbaak | and who knows, maybe I get motivated to start working on the skinny realtime support again |
| 22:57.11 | Corydon76-dig | cracks the whip at mvanbaak |
| 22:57.28 | mvanbaak | wut???? what did I do this time ? |
| 22:57.42 | Corydon76-dig | Nothing. I'm motivating you. |
| 22:58.09 | mvanbaak | lol |
| 22:59.11 | mvanbaak | wow, someone from the Digium secret society is motivating someone from outside the society to work on skinny |
| 22:59.16 | mvanbaak | calls the press |
| 23:00.10 | mvanbaak | it's midnight !!!!!!!!!!!!!! |
| 23:00.22 | russellb | you know what that means! |
| 23:00.35 | putnopvut | It's two minutes too late to play that Iron Maiden song? |
| 23:01.32 | mvanbaak | it's time to get drunk |
| 23:01.52 | *** join/#asterisk-dev xpot-mobile (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 23:04.57 | mvanbaak | The_Boy_Wonder: I like it how you put your IRC name in your mail signature |
| 23:05.29 | russellb | ooh, he used the official digium email signature format, heh |
| 23:05.49 | mvanbaak | good boy |
| 23:05.50 | mvanbaak | lol |
| 23:06.05 | russellb | yup. |
| 23:06.18 | mvanbaak | russellb: I noticed two crashes of the bamboo agent already :( |
| 23:06.30 | russellb | that sucks ... |
| 23:06.41 | russellb | it's supposed to be running in some sort of wrapper that will restart it |
| 23:06.47 | The_Boy_Wonder | my emails look all official now! |
| 23:06.49 | mvanbaak | I'll write a safe_bamboo for it |
| 23:07.06 | russellb | well, try adding "start" as an argument to the end of the java command |
| 23:07.14 | russellb | by default it runs "console" (run in foreground) |
| 23:07.22 | mvanbaak | uhhuh |
| 23:07.23 | russellb | it's supposed to be running in some sort of container already |
| 23:07.25 | russellb | shrugs |
| 23:07.31 | russellb | safe_bamboo might be needed |
| 23:07.38 | russellb | shakes his fist as not having the source |
| 23:07.54 | mvanbaak | hhmm, I think I trust a small shellscript before a java watchdog thingie ;) |
| 23:08.01 | russellb | ha, k |
| 23:08.18 | mvanbaak | should have gone with cruisecontrol |
| 23:09.08 | mvanbaak | there you have the source, and looking at the featurelist they are very close in functionality |
| 23:09.13 | russellb | if it becomes a problem, we can always run the script on a linux box that just runs a build on the OpenBSD agent via ssh |
| 23:09.31 | kpfleming | or telnet! |
| 23:09.36 | mvanbaak | or rsh ! |
| 23:09.48 | russellb | or voice under IP! |
| 23:09.57 | russellb | "ONE ONE ZERO ONE ZERO ONE ONE!" |
| 23:10.04 | kpfleming | has anyone released plz-to-be-hacking-my-box-sh yet? |
| 23:10.24 | kpfleming | russellb: watch your language |
| 23:10.36 | russellb | ^_^ |
| 23:11.05 | russellb | gah, I didn't even get to say an entire byte before kpfleming got onto me ... |
| 23:11.15 | mvanbaak | it's sad |
| 23:11.24 | putnopvut | russellb: I just assumed that was a 7-bit byte. |
| 23:11.39 | kpfleming | six bits with a start bit |
| 23:11.54 | mvanbaak | and no parity |
| 23:11.54 | file | RAWR |
| 23:12.03 | putnopvut | At least russellb got in his 87.5 cents worth. |
| 23:12.08 | putnopvut | EVERYONE LAUGH AT MY PUN! |
| 23:12.21 | putnopvut | NOW, DAMMIT! |
| 23:12.30 | mvanbaak | erm, nope |
| 23:12.51 | mvanbaak | it's opensource, go fix it yourself ! |
| 23:12.54 | russellb | attempts running unit tests on this mac ... |
| 23:12.56 | russellb | will it work?!?! |
| 23:13.02 | file | it will catch on fire ;( |
| 23:13.08 | russellb | correct |
| 23:13.10 | mvanbaak | it's a mac, of course it wont work |
| 23:13.44 | russellb | it's all like, even though I have wget, I refuse to run until you install more crap! |
| 23:14.00 | mvanbaak | I say again: it's a mac |
| 23:14.18 | russellb | sexiest and easiest to use desktop around |
| 23:14.59 | mvanbaak | yeah, for watching youporn and typing a mail and using keynote. All other stuff is simply not working correctly on a mac |
| 23:15.50 | putnopvut | mvanbaak: you left out audio/video editing/mixing |
| 23:16.02 | mvanbaak | they fixed that on a mac ? |
| 23:16.44 | mvanbaak | last time I asked a guy who is actually into goatrance mixing and stuff, they were very unhappy with the mac |
| 23:16.53 | mvanbaak | and that was like 4 months ago |
| 23:17.14 | russellb | the 99.99% of the AV industry that uses mac disagrees |
| 23:17.23 | mvanbaak | they told me the amiga stuff was amazing in that area |
| 23:17.56 | mvanbaak | and for video they used sgi hardware |
| 23:18.26 | russellb | does he use the new amiga mouse? http://en.wikipedia.org/wiki/File:Amiga_Mouse.jpg |
| 23:19.11 | mvanbaak | lol |
| 23:20.10 | mvanbaak | no, they are using this mouse: http://www.geekologie.com/2010/02/11/vagina-mouse-2.jpg |
| 23:21.17 | mvanbaak | ok, I have 2 minutes battery time left in this laptop |
| 23:21.24 | mvanbaak | I think it's time to go to bed :) |
| 23:21.50 | mvanbaak | latero all |
| 23:22.49 | kpfleming | russellb: your unit tests better not require more than one thread |
| 23:23.07 | russellb | kpfleming: heh, indeed |
| 23:30.50 | snuff-work | leifmadsen: ping? |
| 23:34.51 | snuff-work | mm.. only thing that erks me about CR Fix XML documentation on non-Linux platforms.. is why the guy didn't try to use my code to begin with.. |
| 23:35.44 | Qwell | snuff-home: You had code attached? O.o |
| 23:36.02 | snuff-work | The_Boy_Wonder: your AoC stuff.. does that cover SS7 related parts? (aka toll free thing on bug tracker for ss7) |
| 23:36.04 | snuff-work | yer.. |
| 23:36.17 | Qwell | wonders if he's talking about the right issue |
| 23:36.25 | snuff-work | M15402 |
| 23:36.28 | MuffinMan | [ready for review] [Asterisk] Core/Portability 0015402: [patch] Cannot find XML documentation under non linux platforms reported by snuffy https://issues.asterisk.org/view.php?id=15402 |
| 23:36.31 | russellb | snuff-home: nothing AoC is included in the scope right now |
| 23:36.49 | Qwell | ...I wasn't aware of that issue |
| 23:38.15 | russellb | that's what we get with over 600 open mantis issues, i guess :-( |
| 23:38.15 | snuff-work | meh.. too late now ;) |
| 23:38.19 | kpfleming | AOC is not related to toll-free call marking |
| 23:38.38 | snuff-work | the guy was told in the bug there was already a patch around |
| 23:38.44 | russellb | i meant nothing SS7* is included in the scope |
| 23:38.49 | kpfleming | that too |
| 23:38.59 | russellb | because AoC is definitely included in the scope. |
| 23:39.37 | kpfleming | of the AoC project? |
| 23:39.49 | russellb | yes. |
