| 00:05.17 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 00:28.49 | *** join/#asterisk-dev droemel (~droemel@p4FCAD27F.dip.t-dialin.net) |
| 01:08.11 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 01:40.11 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 01:40.11 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:05.00 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 05:08.37 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 05:08.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:45.31 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:45.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:51.57 | *** join/#asterisk-dev voxter (~hardcore@macpro.daytonhome.voxter.net) |
| 05:53.27 | voxter | I apologize in advance for asking in here, but i just don't think anyone in the #asterisk channel would have a clue (or be awake) - I've got a system (1.8.5.0) where when loading app_queue.so or chan_iax2.so, asterisk hangs, and an strace produces an endless amount of lseek() and read() of? who knows what. Any suggestions where I might start? |
| 05:53.44 | voxter | Weird thing is, the system worked like.. 6 hours ago.. I went to do a reload, then all of a sudden this happens. |
| 05:58.38 | voxter | Im sure it happens to other modules, but those are the only two I've been able to specifically recreate |
| 06:03.18 | sruffell | voxter: I don't know specifically what your problem isâ¦but if you have an strace, then you should be able to look up what the actual file is (Assuming it's still open) in /proc/<asterisk pid>/fd/<file descriptor from ftrace> Won't solve your problem but could give you another clue. |
| 06:03.44 | sruffell | could answer the "of who knows what" question anyway... |
| 06:12.27 | wdoekes2 | you could also fire up gdb. a backtrace will provide additional cues |
| 06:12.49 | voxter | i would gladly, alas i have never used gdb. |
| 06:12.57 | wdoekes2 | gdb -p <asteriskpid> |
| 06:13.14 | wdoekes2 | info threads |
| 06:13.20 | wdoekes2 | thread <threadno> |
| 06:13.28 | wdoekes2 | bt |
| 06:13.39 | wdoekes2 | bt full |
| 06:13.52 | wdoekes2 | that should help you along |
| 06:14.11 | voxter | holy crap I found it |
| 06:14.16 | voxter | an 830kb astdb file....!?! |
| 06:14.22 | voxter | presumably corrupted. |
| 06:14.37 | wdoekes2 | I've heard reports of corrupt astdbs causing havoc |
| 06:14.51 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 06:14.56 | wdoekes2 | look on the issue tracker |
| 06:23.44 | voxter | So weird, that has happened a couple times on this box.. Thanks for the help :) I was ready to jump. haha |
| 06:59.49 | oej | Morning folks |
| 07:05.41 | irroot | oej its officially spring day hello to you and all the others happy spring day |
| 07:05.48 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 07:06.03 | oej | thanks, irroot! |
| 07:06.25 | oej | Btw, I think you use my e-mail in your automerge on one branch. I got email about one of your branches that failed yesterday. |
| 07:07.34 | irroot | oej me ?? ill look at that odd odd odd |
| 07:11.37 | wdoekes2 | spring? it has been autumn here since july, with all the rain |
| 07:11.52 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:12.00 | irroot | hehe southern hemi |
| 07:14.31 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:14.31 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:19.49 | oej | we have had nice weather all summer. |
| 07:20.03 | wdoekes2 | yeah.. dalarna was nice.. :) |
| 07:20.38 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 07:36.51 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:511e:aa0b:e88:57ff) |
| 08:14.12 | *** join/#asterisk-dev Ulrar (~quassel@2a01:e0b:1:136:62eb:69ff:fe8f:18a0) |
| 08:32.20 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:32.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:42.56 | *** join/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 09:42.56 | *** join/#asterisk-dev JonathanRose (~jonathan@nat/digium/x-ewcwzpsjgwvajjgl) |
| 09:42.56 | *** join/#asterisk-dev jdoe (~jdoe@falseprophet.ca) |
| 09:42.56 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 09:42.56 | *** mode/#asterisk-dev [+oo russellb opticron] by zelazny.freenode.net |
| 09:52.22 | *** join/#asterisk-dev oej_ (~olle@ns.webway.se) |
| 09:52.22 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 09:53.59 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 09:54.13 | irroot | chan_misdn round robin routing is borked |
| 09:54.32 | oej_ | is chan_misdn still alive? I thought people had given up on that one. |
| 09:54.33 | irroot | it rotates ports the way it should but it does not rotate channels |
| 09:54.43 | irroot | hehe i still use it in production :P |
| 09:55.17 | irroot | need to catch up sometime but not today |
| 09:55.47 | irroot | lots of customers with USB mISDN |
| 10:02.03 | mvanbaak | meh, my asterisk wont stop ... |
| 10:02.16 | mvanbaak | even if I try with 'kill -9' or 'kill -11' |
| 10:04.12 | mvanbaak | in ps it's marked as a 'Stopped process' |
| 10:04.22 | mvanbaak | how do I get rid of it ? |
| 10:09.04 | irroot | power switch :P |
| 10:09.25 | mvanbaak | yeah, thinking about that :( |
| 10:09.36 | irroot | any indication of what it is doing ?? |
| 10:09.45 | irroot | can gdb attach to the pid |
| 10:10.21 | mvanbaak | let me try |
| 10:11.16 | mvanbaak | doesn't look like it |
| 10:11.49 | mvanbaak | nope, nothing happens |
| 10:12.17 | mvanbaak | dont get the (gdb) prompt |
| 10:15.14 | mvanbaak | meh, I tried all signals |
| 10:15.17 | mvanbaak | nothing works |
| 10:16.51 | mvanbaak | be right back, trying a reboot |
| 10:22.37 | *** join/#asterisk-dev mickecarlsson (~Micke@h10n3c1o1101.bredband.skanova.com) |
| 10:23.21 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:23.22 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 10:24.20 | mvanbaak | that worked |
| 10:24.25 | mvanbaak | :( |
| 10:26.13 | wedhorn | mvanbaak: you expected the process to survive a reboot ... |
| 10:26.31 | mvanbaak | no, I expected the reboot not to happen |
| 10:26.39 | mvanbaak | 'Waiting for processes ...' |
| 10:26.40 | wedhorn | ah |
| 10:26.53 | mvanbaak | happened to me before on linux |
| 10:26.59 | wedhorn | yep |
| 10:27.12 | mvanbaak | but this is not linux (thank god) |
| 10:27.19 | mvanbaak | so it actually worked ;) |
| 10:27.38 | wedhorn | luckily they still have switches on the wall (or removable power cords if all else fails) |
| 10:27.46 | wedhorn | for linux |
| 10:28.12 | mvanbaak | I have an APC powerbar |
| 10:28.20 | mvanbaak | I can cycle the ports using snmp ;) |
| 10:28.27 | wedhorn | nifty |
| 10:28.55 | mvanbaak | yeah :) |
| 10:29.04 | mvanbaak | I can also read the powerusage per port |
| 10:29.19 | mvanbaak | I really should move one of my servers to the datacenter |
| 10:29.30 | mvanbaak | there I get power for free (coworker contract) |
| 10:29.38 | mvanbaak | the machine is using 1.2 Amps |
| 10:29.43 | wedhorn | ouch |
| 10:30.16 | wedhorn | I'm trying to reduce my power bill, but it's sort of limited to going via/atom |
| 10:30.17 | mvanbaak | ibm X345 dual xeon with 8GB ram and 6 15k rpm scsi disks |
| 10:30.40 | wedhorn | I assume the 1.2amps is at 240v |
| 10:30.48 | mvanbaak | 230 |
| 10:30.50 | mvanbaak | yeah |
| 10:32.18 | mvanbaak | there, I finally have my skinny phones back in 'production' |
| 10:32.21 | wedhorn | that works out at about $400 AUD a year here. |
| 10:32.25 | wedhorn | woohoo |
| 10:32.56 | mvanbaak | 7905 and 7960 |
| 10:33.21 | mvanbaak | 7905 in my livingroom, 7960 in my home office |
| 10:33.33 | wedhorn | using the latest version |
| 10:33.52 | wedhorn | ? |
| 10:34.14 | mvanbaak | [Sep 1 12:34:08] Connected to Asterisk SVN-trunk-r328502 currently running on ifrid (pid = 1832) |
| 10:34.31 | mvanbaak | and I have no idea what firmware the phones are ... |
| 10:35.10 | mvanbaak | 7960: Version 8.0(9.0) |
| 10:35.31 | wedhorn | who cares about firmware, the more I've been playing, the less I think it really matters (except for some of the latest functionality which is not implemented in chan_skinny anyway) |
| 10:35.32 | mvanbaak | 7905: Software Version 8.0.3(070409A) |
| 10:36.02 | mvanbaak | yeah, agreed |
| 10:36.14 | wedhorn | my 7960 is 7.2 |
| 10:36.17 | mvanbaak | I should read up on chan_skinny again |
| 10:36.29 | wedhorn | any crashes? |
| 10:36.44 | mvanbaak | not yet |
| 10:36.55 | wedhorn | a lot as changed, but should be easier to follow |
| 10:37.15 | mvanbaak | yeah. I see your 'refactor' patches got in |
| 10:37.46 | wedhorn | russell pretty much let me just edit and commit |
| 10:37.56 | wedhorn | shortened the process significantly |
| 10:38.21 | wedhorn | hey, and I got SLA in there as well |
| 10:39.35 | mvanbaak | cool |
| 10:39.39 | mvanbaak | I need to look into that |
| 10:40.10 | wedhorn | yeah, it'd be nice to get some else to have a look at it |
| 10:40.35 | wedhorn | I managed to get it in version 10, but I think there's still some testing needed |
| 10:40.57 | mvanbaak | my svn cert is renewed |
| 10:41.01 | mvanbaak | so I can help again :) |
| 10:41.20 | mvanbaak | and now that my marriage is over, I have some more time for it ;) |
| 10:41.40 | wedhorn | so that is what was taking up all your time ... |
| 10:41.55 | mvanbaak | breaking up yeah :( |
| 10:42.01 | wedhorn | oh ... |
| 10:42.17 | mvanbaak | taking all my time and money :/ |
| 10:42.49 | irroot | Marrige vs Hooker is like diff between contract and pay as you go .... |
| 10:42.52 | mvanbaak | but I'm getting back on track |
| 10:42.59 | mvanbaak | lol |
| 10:43.48 | wedhorn | yep. Like the old saying, if it flies, floats or f...., rent it, don't buy it. |
| 10:43.59 | wedhorn | I've failed all 3 |
| 10:44.53 | mvanbaak | meh |
| 10:45.03 | mvanbaak | I failed the last two. but got rid of the last item |
| 11:05.13 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 11:44.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:44.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:30.08 | oej_ | God morning, kpfleming! |
| 12:32.20 | kpfleming | oej: you too |
| 12:32.42 | oej | You're too late. Getting ready to board an evening flight :-) |
| 12:47.02 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 12:56.10 | *** join/#asterisk-dev Fritz09 (~Adium@pop1-1207.catv.wtnet.de) |
| 12:57.00 | *** join/#asterisk-dev Fritz09 (~Adium@pop1-1207.catv.wtnet.de) |
| 13:02.24 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zrxegxpalcpycmes) |
| 13:05.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mqefqykdngoejcun) |
| 13:05.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:17.40 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 13:22.22 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:01.57 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:01.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:10.51 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 14:23.50 | JunK-Y | lo guys |
| 14:26.15 | irroot | lo |
| 14:27.05 | kpfleming | JunK-Y: is the young boy writing code yet? |
| 14:28.06 | JunK-Y | kpfleming: https://www.facebook.com/photo.php?fbid=10150340437685792&set=a.10150240520240792.372375.746200791&type=1&theater |
| 14:29.14 | irroot | got a bug in chan_misdn round robin im not to bothered by it should i throw it up on jira any way ??\ |
| 14:30.48 | pabelanger | irroot: yes |
| 14:31.19 | JunK-Y | kpfleming: its a real qwerty kb, but it plays sounds, but no one knows it :) |
| 14:32.14 | irroot | cool will do add patch with the hack i used to get arround it |
| 14:34.28 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-bzvevhamysmldkqj) |
| 14:45.34 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:45.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:46.22 | leifmadsen | jsmith: ping |
| 14:46.29 | jsmith | leifmadsen: pong! |
| 14:46.45 | leifmadsen | jsmith: hey, just curious if you were planning on adding more debug info to ASTERISK-18406 |
| 14:46.54 | leifmadsen | I'm not sure I can move that issue forward as-is |
| 14:47.05 | jsmith | leifmadsen: Aye... I'm uploading logs and packet traces now :-) |
| 14:47.05 | leifmadsen | unless there is a related issue or something I should be linking to? |
| 14:47.12 | leifmadsen | ok cool, that's why I wanted to ask |
| 14:47.16 | jsmith | leifmadsen: You just have to forgive my slow internet connection |
| 14:47.26 | leifmadsen | not a problem, I just didn't want to move it to feedback if you were still working on it |
| 14:47.28 | jsmith | leifmadsen: mnicholson is already aware of the issue :-) |
| 14:47.35 | leifmadsen | awesome, carry on! |
| 14:48.52 | Corydon76-home | mickecarlsson: ping |
| 15:21.46 | *** join/#asterisk-dev Gugge (~gugge@46.30.120.1) |
| 15:40.28 | *** join/#asterisk-dev Gugge (~gugge@46.30.120.1) |
| 15:51.40 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:51.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:19.07 | *** join/#asterisk-dev irroot (~irroot@197.174.36.133) |
| 16:25.39 | mickecarlsson | Corydon76-home pong |
| 16:26.35 | Corydon76-home | mickecarlsson: Ref ASTERISK-18399, does that patch fix the problem for you? |
| 16:26.54 | mickecarlsson | Just got home, I will check asap. |
| 16:38.29 | mickecarlsson | Corydon76-home just patched the server, no more error in log when modules.conf just contains autoload=yes. So that fixed it |
| 16:38.41 | Corydon76-home | Excellent |
| 16:41.56 | mickecarlsson | I just reverted it to make sure that it popped up again, and it did. So the fix is OK. |
| 16:54.35 | pabelanger | leifmadsen: btw: http://bamboo.asterisk.org/browse/TESTING-AST18-6 |
| 16:54.47 | pabelanger | that is a success build for asterisk 1.8.6.0 release |
| 16:54.56 | pabelanger | all tests we tested with passed |
| 16:57.43 | leifmadsen | pabelanger: awesome :) |
| 16:57.54 | leifmadsen | pabelanger: next time we'll test it before we do a release :) |
| 16:59.11 | leifmadsen | pabelanger: can we do a test as soon as I create a tag? |
| 17:00.45 | pabelanger | leifmadsen: Yes, however the next version of the build script will not be using subversion but rather download the actual 1.8.7.0-rc.tar.gz tarball |
| 17:01.20 | leifmadsen | hmmmm :S |
| 17:01.23 | pabelanger | that way we are using the same files the asterisk user would be using |
| 17:01.29 | leifmadsen | ya I guess that makes sense |
| 17:01.38 | leifmadsen | it'll need to have access to pending/ |
| 17:01.56 | leifmadsen | Qwell: that brings up another point -- you around? |
| 17:02.20 | Qwell | nope |
| 17:02.37 | pabelanger | leifmadsen: well, by the time you do release a tarball (eg: 1.8.7.0) we will have already run bamboo on each rcX in the release process |
| 17:03.47 | leifmadsen | pabelanger: right, but that's what I mean -- I'm thinking about 1.8.7.0-rc1 now |
| 17:06.50 | pabelanger | yes, so after you create the 1.8.7.0-rc1.tar.gz, and release it to downloads.asterisk.org we'll have bamboo test with it |
| 17:08.48 | leifmadsen | I don't want that to be the order |
| 17:08.54 | leifmadsen | I want to test it before it is released |
| 17:10.59 | leifmadsen | when it is ready to be signed, it would be awesome if bamboo would sign the tarball when/if all tests were passed (or something else to indicate that the tarball passed all the tests) |
| 17:11.13 | Qwell | that would be pretty cool |
| 17:12.08 | pabelanger | the problem with that is, what if there IS a problem with the 1.8.7.0-rc1.tar.gz that bamboo finds? Are you going to recreate the _same_ tarball with the same version or bump it? |
| 17:13.20 | pabelanger | If we want to test before we release, then we need an alpha or beta tag or something |
| 17:13.45 | Qwell | Why not test the rc from svn? |
| 17:13.53 | Qwell | before the tarball actually gets made |
| 17:14.52 | leifmadsen | that's what I was hoping for ideally because then bamboo could modify the ChangeLog and/or add a file with the results of the tests. |
| 17:15.36 | pabelanger | Qwell: when do we test the tarball? |
| 17:15.59 | leifmadsen | why test the tarball? |
| 17:16.11 | *** join/#asterisk-dev irroot (~irroot@197.171.161.170) |
| 17:16.11 | pabelanger | because that is the final product people use? |
| 17:16.15 | leifmadsen | tarball creation is already automated and uses exactly what is in the svn tag |
| 17:16.33 | leifmadsen | pabelanger: not necessarily, the tarball *has* to be exactly the same as the subversion tag |
| 17:16.36 | leifmadsen | or something is REALLY wrong |
| 17:17.03 | leifmadsen | if you're going to test the tarball, then you have to test both the tarball and the subversion tag |
| 17:17.07 | pabelanger | Right, but my point is... if we are not testing using the _same_ media Asterisk users are, we are missing the point |
| 17:17.11 | leifmadsen | because you're implying they could be different |
| 17:17.26 | pabelanger | Correct |
| 17:17.27 | leifmadsen | pabelanger: the media I'm using is the checkout from the tag on my servers |
| 17:17.50 | pabelanger | because there is still a process in the release cycle that needs to be accomplished, the create of a tag |
| 17:17.54 | pabelanger | sorry, tarball |
| 17:18.08 | leifmadsen | so we need to test both then, which means we should test the subversion tag first, have bamboo write something to the tag saying it passes, then create the tarball, then test it again, and have bamboo sign the tarball to signify it still passes |
| 17:18.20 | leifmadsen | the tag happens first, then the tarball |
| 17:18.40 | leifmadsen | if you're testing after you're created the tarball, you've missed an entire opportunity to test before you get to the finished point |
| 17:18.55 | leifmadsen | then that entire release is useless and we have to bump |
| 17:18.57 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:19.09 | pabelanger | Also, once a tarball is signed and released, we have a guarantee nothing is going to change with that tarball. In subversion, we don't have the option. A tag could be created, but something _could_ be merged into it at a later point in time |
| 17:19.19 | leifmadsen | imagine if that happened after 1.8.x.0 was released... what, we create 1.8.x.1 ? |
| 17:19.36 | pabelanger | yes? |
| 17:19.40 | pabelanger | why not? |
| 17:19.51 | leifmadsen | because we could totally catch the issue before the tarball was created |
| 17:20.14 | leifmadsen | pabelanger: because it's terribly confusing to users to release 1.8.x.3 and say, "well, we didn't release .0, .1, and .2 because they failed testing" |
| 17:20.43 | leifmadsen | we should create the tag, test it, make sure it passes, if not, fix it, test again, when it passes, then create the tarball, test again, release |
| 17:21.04 | leifmadsen | you can make changes right up to the point you create the tarball, but not after |
| 17:21.39 | Qwell | I think the tarball testing should be nothing more than: Does it unpack? Do X, Y, and Z files exist, with the correct values? Does it build/install? |
| 17:21.58 | Qwell | maybe not even the latter |
| 17:22.24 | Qwell | basically, test that the mkrelease script did what we say it's supposed to do. |
| 17:22.25 | pabelanger | But I don't understand, if we created 1.8.7.0-rc3 (the last RC), then created 1.8.7.0 tags and tarball, why do you think there is a failure? |
| 17:22.35 | leifmadsen | pabelanger: that's not what I'm discussing |
| 17:22.43 | leifmadsen | I'm discussing the release of 1.8.7.0-rc1 to start |
| 17:23.27 | Qwell | pabelanger: as an aside, whatever you're using to commit to sites/ needs to be changed to ignore certain files (like svn-commit.tmp) |
| 17:24.00 | pabelanger | leifmadsen: Right, after you tag and release the tarball, we would run bamboo |
| 17:24.11 | leifmadsen | I disagree with that order |
| 17:24.16 | leifmadsen | you're saying, "release, then test" |
| 17:24.23 | leifmadsen | I'm saying, "test, then release" |
| 17:24.27 | file | I also disagree (for what it's not worth) |
| 17:26.47 | file | leifmadsen, +1 |
| 17:27.15 | file | Qwell, I also +1 your comments |
| 17:27.29 | leifmadsen | if we create 1.8.x.0-rc1, then test it, and it fails, we still have the opportunity to resolve those issues before we release. If we just test the tarball we don't have that opportunity and we just need to create a new tag entirely |
| 17:27.49 | Qwell | tag > test > create tarball > test tarball (I assert that we don't need full testing here) > sign > release |
| 17:28.24 | file | yes, and because there is a contract with this that the tarball IS what the tag is in SVN then that's fine - if that contract is broken you have bigger problems |
| 17:29.19 | leifmadsen | it may(?) be possible to change permissions to read-only in subversion after the tarball is created too? |
| 17:29.35 | Qwell | leifmadsen: we could svn lock the files, but meh |
| 17:29.41 | Qwell | or do you mean the tag? |
| 17:29.45 | leifmadsen | the tag |
| 17:29.50 | Qwell | let's not |
| 17:29.55 | leifmadsen | so we can be sure the tag == tarball |
| 17:30.04 | leifmadsen | there is probably some hash check we could do.... |
| 17:30.08 | leifmadsen | if we cared |
| 17:30.13 | file | there should be no reason to need to do that, everyone is full aware that tags are read only once created unless deleted - I'd only worry about automated things potentially touching it |
| 17:30.22 | pabelanger | leifmadsen: right, so how to do guarantee everybody on the testing team is using the _same_ point in the revision to test with? We we create a tag, start testing, find a problem, are you going to merge fixes into the same tag or bump it? |
| 17:30.35 | Qwell | same tag |
| 17:30.40 | pabelanger | that is a problem |
| 17:30.47 | leifmadsen | why? |
| 17:30.52 | leifmadsen | we haven't released yet |
| 17:30.58 | leifmadsen | things are still up for changes |
| 17:31.10 | leifmadsen | it's the same thing when I cp rc1 -> rc2 and make a change |
| 17:31.29 | file | call it a pending release |
| 17:31.56 | pabelanger | and my point about using a tarball, once created, it will not change. Creating a tag, does not guarantee somebody else could merge something into it, changing a tag, mid testing, invalidates all testing before that |
| 17:32.02 | leifmadsen | (that was my point of having it in a separate, perhaps private or team branch prior to moving to the tag dir) |
| 17:32.18 | leifmadsen | pabelanger: not if you tested the tarball after again |
| 17:32.34 | pabelanger | but then we are duplicating testing |
| 17:32.39 | leifmadsen | ok... |
| 17:32.43 | leifmadsen | so? |
| 17:33.03 | pabelanger | not all of the testing is automated, some is manual |
| 17:33.12 | leifmadsen | if we test the tarball, and it is broken, it is useless and we have to bump the version which is very confusing to people and a lot more effort on the part of the release manager |
| 17:33.44 | Qwell | We aren't going to be doing manual testing on an RC before it is released. |
| 17:33.49 | leifmadsen | it's pretty clear that only the release manager should be merging changes into a tag anyways |
| 17:34.05 | file | you essentially want a tag before the actual tag |
| 17:34.07 | leifmadsen | who is going to be the same person triggering the automated testing |
| 17:34.31 | leifmadsen | file: yep -- your idea for pending, or my suggestion of having it not in the 'tag' directory is what I was suggesting earlier |
| 17:34.38 | file | leifmadsen, aye |
| 17:34.47 | pabelanger | leifmadsen: right, but the other people who care about the version bump are testers |
| 17:34.52 | leifmadsen | I really don't like the idea of testing the tarball after it is released |
| 17:35.36 | leifmadsen | I'm going to defer this until our meeting this afternoon and bring it up then |
| 17:35.44 | leifmadsen | because we're going in circles now |
| 17:35.51 | pabelanger | Yes |
| 17:35.51 | kpfleming | leifmadsen: *only* after it is released |
| 17:36.03 | leifmadsen | kpfleming: I don't understand your statement |
| 17:36.08 | kpfleming | obviously testing after it is released is fine, if that's not the only testing |
| 17:36.40 | leifmadsen | I don't understand why we would execute automated testing after we released something just to find out it is broken |
| 17:36.46 | kpfleming | agreed |
| 17:36.59 | leifmadsen | ok, so I'm confused still :) |
| 17:37.20 | leifmadsen | <kpfleming> leifmadsen: *only* after it is released <-- I don't get this |
| 17:38.25 | irroot | we need to define release is it when its tagged or when its published on the website/ml |
| 17:38.29 | Qwell | leifmadsen: "if the only testing is after it is released" |
| 17:38.36 | kpfleming | you said you objected to testing the tarball after it is released. i was making the point that if someone wants to test after it is released, that was not what you were objecting to... you were objecting to not testing *before* it is released. |
| 17:38.44 | kpfleming | Qwell: right |
| 17:38.51 | leifmadsen | kpfleming: ah yes, that is true |
| 17:39.17 | leifmadsen | I'm fine with running the automated testing twice |
| 17:39.21 | leifmadsen | or as many times as it takes |
| 17:39.22 | Qwell | (pasted from earlier. I assert this to be the order.) tag > test > create tarball > test tarball (I assert that we don't need full testing here) > sign > release |
| 17:39.34 | Qwell | lots of assertions on that line. |
| 17:39.42 | leifmadsen | I assert your assertions |
| 17:39.46 | Qwell | (please don't cause me to exit by failing the assertions) |
| 17:39.53 | pabelanger | Qwell: test tarball stage, what if there is a problem and something fails? |
| 17:40.10 | Corydon76-home | ast_assert doesn't exit when failing the assertions. :-P |
| 17:40.14 | leifmadsen | pabelanger: then we have to create a new release, but that should be infinitely rare |
| 17:40.17 | kpfleming | then you respin the tarball with the same versio number |
| 17:40.24 | leifmadsen | or that I guess |
| 17:40.29 | Qwell | The only change would be packaging. |
| 17:40.34 | kpfleming | correct |
| 17:40.52 | Qwell | pabelanger: think of it like a -2 release for an rpm/deb |
| 17:41.04 | pabelanger | kpfleming: how do you tell the differences between the original (broken tarball) and the new (fixed tarball) if they are the same version and unsigned? |
| 17:41.06 | Qwell | (except that there's nothing to actually signify that, except svn logs) |
| 17:41.13 | pabelanger | it makes it hard from something in the testing team to track |
| 17:41.20 | kpfleming | if the tarball was made and did not pass testing, it should not have been publicized yet |
| 17:41.37 | kpfleming | if you are going to test the tarball, you have do it while it's still in pending |
| 17:41.52 | Corydon76-home | Can bamboo be made to track the pending directory? |
| 17:41.57 | pabelanger | but then we exclude the asterisk community from testing |
| 17:41.58 | Qwell | Corydon76-home: sure |
| 17:42.02 | pabelanger | since they cannot access pending |
| 17:42.06 | irroot | kpfleming indeed put the it in proposed folder ?? and consider a release only when published by the gods |
| 17:42.11 | Qwell | pabelanger: That's the *point* of the rc. |
| 17:42.44 | kpfleming | right. the community does not need to test whether the tarball was produced properly. |
| 17:42.50 | Qwell | We aren't going to say "Dear community, please test this unreleased release." |
| 17:43.01 | Corydon76-home | Is there a good reason to hide pending from the community? |
| 17:43.11 | kpfleming | yes, and this is the reason |
| 17:43.22 | kpfleming | if we want to respin a tarball, we want to be sure that the previous iteration did not get out |
| 17:43.34 | file | or confusion occurs |
| 17:43.54 | Corydon76-home | I was thinking about for signing purposes, but that's enabled by having access to svn |
| 17:44.14 | kpfleming | no, the pending dir is only visible to a subset of people with origsvn access |
| 17:44.15 | Corydon76-home | That repo, anyway |
| 17:45.40 | pabelanger | right, and this is the same point I am trying to raise with the testing team, confusion with occur. I don't like the fact that at different stages of the asterisk release cycle, everybody is testing the same version of asterisk at different points of the release process. When we create a release, we release, then everybody is at the same point to test with and the expected results will be the same |
| 17:46.11 | Qwell | Nobody should be testing between tarball creation and release. That is going to be only automated testing. |
| 17:46.20 | kpfleming | right |
| 17:46.32 | kpfleming | the 'testing team' should only be testing tags, or tarballs produced from those tags |
| 17:46.43 | kpfleming | but really, just tags |
| 17:46.44 | Qwell | released* tarballs produced from those tags |
| 17:46.51 | kpfleming | yeah |
| 17:47.01 | pabelanger | in my else, the testing team should be testing using the same media as the end user |
| 17:47.04 | pabelanger | not developer |
| 17:47.11 | Qwell | That's fine - and they can do that after release |
| 17:47.22 | kpfleming | only if you are concerned about the packaging process itself causing problems, which is very rare |
| 17:47.44 | kpfleming | and the only problems it is going to cause will be found at build/install time, not during functional testing |
| 17:48.36 | kpfleming | does the testing team then turn around and test the RPMs and DEBs we produce as well? it's certainly possible for that second level of packaging to cause problems too. |
| 17:48.59 | pabelanger | do we officially support them? |
| 17:49.11 | kpfleming | that depends on your definition :-) |
| 17:49.30 | kpfleming | the RPMs are produced for AsteriskNOW users, so that means there is some level of support, yes |
| 17:49.41 | pabelanger | Well, if yes, then we should be testing them. The reality is, we don't :) |
| 17:52.52 | kpfleming | i have to head down to the meeting room to prepare for our upcoming meeting... we can continue this discussion there, or here after the meeting is done |
| 18:02.45 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 18:07.13 | *** join/#asterisk-dev otherwiseguy (~terry@rrcs-173-197-10-151.west.biz.rr.com) |
| 18:45.41 | *** join/#asterisk-dev bbryant (~brett@c-174-56-132-225.hsd1.sc.comcast.net) |
| 18:45.41 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:05.39 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 19:15.07 | mickecarlsson | Can someone please explain the INCOMPLETE logic for HANGUPCASUE 28 that was introduced in 1.6.2? |
| 19:15.15 | mickecarlsson | https://issues.asterisk.org/jira/browse/ASTERISK-17288 |
| 19:15.52 | mickecarlsson | Up to 1.6.0 it was going to next exten in dialplan when receiving hangupcause 28 |
| 19:16.35 | mickecarlsson | Then in 1.6.2 an incomplete logic was intrduced that instead of going to next exten it was sent to 't' exten |
| 19:16.48 | mickecarlsson | is clueless |
| 19:17.48 | Corydon76-home | mickecarlsson: the cause code means that the number, as dialed, is short of a full number. Think 9 digits, when a complete phone number is 10 digits long |
| 19:18.00 | mickecarlsson | Well, is US that is fine |
| 19:18.19 | mickecarlsson | In Sweden we have from 8 digits to 13 |
| 19:18.27 | mickecarlsson | Totally variaböe |
| 19:18.31 | mickecarlsson | variable |
| 19:18.33 | Corydon76-home | Well, anywhere, the phone company can decide if a number is incomplete as dialled |
| 19:18.45 | mickecarlsson | Yes, that is fine |
| 19:18.49 | Corydon76-home | 9/10 is just an example |
| 19:19.02 | mickecarlsson | and it was working as it should up to 1.6.0 |
| 19:19.29 | mickecarlsson | But when I dial to the provider an he returns SIP 484, and hangup the call |
| 19:19.45 | mickecarlsson | then how can this be sent to the phone asking for more digits? |
| 19:20.32 | mickecarlsson | I am very confused how this actually work |
| 19:20.54 | mickecarlsson | I have not seen any examples of it in any documentation or examples |
| 19:21.07 | mickecarlsson | Just some text in the reviewboard |
| 19:21.14 | mickecarlsson | It does not make sense |
| 19:22.03 | mickecarlsson | Well, I will await the feedback from my feedback |
| 19:22.17 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 19:24.34 | Corydon76-home | Does it go immediately to the 't' extension, or only after the responsetimeout interval? |
| 19:24.36 | mickecarlsson | Only information I can detect is this: https://issues.asterisk.org/jira/browse/12351 |
| 19:24.45 | mickecarlsson | Checking... |
| 19:25.16 | leifmadsen | mjordan: weren't you looking at this same type of thing earlier? |
| 19:25.21 | Corydon76-home | That issue is not the same thing |
| 19:25.41 | mickecarlsson | First I receive Spawn extension (macro-dialout-trunk, s, 20) exited non-zero on 'SIP/2476-0000000e' in macro 'dialout-trunk' |
| 19:25.50 | mickecarlsson | Next: Spawn extension (from-internal, 04552, 6) exited INCOMPLETE on 'SIP/2476-0000000e' |
| 19:25.58 | mickecarlsson | Then there is a timeout |
| 19:26.07 | mickecarlsson | Then this: -- Timeout on SIP/2476-0000000e |
| 19:26.25 | mickecarlsson | Then it goes to 't': Executing [t@from-internal:1] NoOp("SIP/2476-0000000e", "Timeout from HC 28") in new stack |
| 19:26.37 | mickecarlsson | But on another context from where I was |
| 19:26.45 | Corydon76-home | Ah, you're using a Macro to dial, which doesn't support waiting for additional DTMF |
| 19:26.57 | mickecarlsson | Checking... |
| 19:27.05 | mickecarlsson | Yes, I am in a mcro |
| 19:27.08 | mickecarlsson | macro that is |
| 19:27.38 | mickecarlsson | So, my suggestion in the ticket, make the Incomplete function configurabeö |
| 19:27.42 | mjordan | leifmadsen: yes |
| 19:27.44 | mickecarlsson | configurable |
| 19:27.58 | Corydon76-home | You'd need to pastebin the relevant parts of the dialplan, because it's likely a configuration issue |
| 19:28.08 | mickecarlsson | Sorry, no it is not |
| 19:28.23 | mickecarlsson | It is a working (1.4, 1.6 install) |
| 19:28.47 | Corydon76-home | It's a new feature (new as of 1.6.2, I suspect) |
| 19:28.48 | mickecarlsson | I can't update to 1.8 due to this isse |
| 19:28.57 | mickecarlsson | 1.6.2 feature |
| 19:29.03 | mickecarlsson | https://issues.asterisk.org/jira/browse/12351 |
| 19:30.27 | mickecarlsson | To make you all go ballistic, this is FreePBX |
| 19:30.45 | mickecarlsson | I am one of the developers on FreePBX |
| 19:30.52 | Corydon76-home | I wasn't aware that freepbx supported 1.8 |
| 19:30.57 | mickecarlsson | Oh, it does |
| 19:31.03 | mickecarlsson | Even 10 |
| 19:31.26 | Corydon76-home | By using deprecated applications? |
| 19:31.36 | mickecarlsson | Hmm, what application |
| 19:31.43 | Corydon76-home | Macro |
| 19:32.01 | mickecarlsson | Is that a deprecated application? |
| 19:32.08 | mickecarlsson | is checking asterisk code |
| 19:32.18 | Corydon76-home | Yes |
| 19:32.28 | mickecarlsson | Since when? |
| 19:33.02 | Corydon76-home | <support_level>deprecated</support_level><replacement>app_stack (GoSub) |
| 19:33.35 | Corydon76-home | 1.8 |
| 19:33.36 | kpfleming | but switching to Gosub would not affect his current issue, so that's unrelated |
| 19:33.50 | pabelanger | Corydon76-home: I think that was reverts, since app_dial depends on app_macro |
| 19:33.53 | mickecarlsson | Ok, I will create a ticket for that in our tracker so we keep an eye on that |
| 19:34.04 | pabelanger | reversed* |
| 19:34.04 | Corydon76-home | I'm not sure that's true. Macro deals with DTMF in weird ways |
| 19:34.26 | kpfleming | s/DTMF/extension digit entry/ |
| 19:34.34 | Corydon76-home | pabelanger: not as of SVN from 10 minutes ago, it hasn't |
| 19:34.40 | Marquis42 | mickecarlsson: For the record, Macro has been deprecated since 1.6.0 as far as I remember. |
| 19:35.17 | mickecarlsson | Ouch, I am pretty good at keeping an eye on changelog for asterisk, that has slipped by |
| 19:35.38 | Corydon76-home | Marquis42: unofficially, yes |
| 19:36.04 | Marquis42 | Well, officially insofar as UPGRADE-1.6.txt in the root of the source tree is concerned. |
| 19:36.06 | mickecarlsson | So, going back to the issue with HC 28 |
| 19:36.30 | mickecarlsson | Is is possible to do Imcomplete configurable in a config file? |
| 19:36.46 | mickecarlsson | It is built in pbx.c I think |
| 19:36.46 | pabelanger | Corydon76-home: Sorry, I was talking about the menuselect changes (supported, extended, etc). My mistake |
| 19:37.49 | mjordan | mickecarlsson: Incomplete only supports a single option, whether or not to answer the channel first. For a SIP channel that ends up in an Incomplete status due to a 484, there are no configuration options. |
| 19:38.05 | Corydon76-home | mickecarlsson: possible, sure. Is it likely? I don't think so |
| 19:38.22 | mickecarlsson | That is BAD (IMHO) |
| 19:39.16 | kpfleming | i don't think you guys are talking about the same thing... configuration options in a config file != dialplan application arguments |
| 19:39.57 | mickecarlsson | Correct |
| 19:40.01 | Corydon76-home | mickecarlsson: you're essentially talking about altering the meaning of a cause code traveling through the core, and that's... problematic |
| 19:40.04 | kpfleming | mickecarlsson: what do you *want* to happen? do you want the macro to exit back to the context that called it, or do you want the timeout to occur immediately and send a 484 back to the calling device? |
| 19:40.34 | kpfleming | Corydon76-home: the pbx core already handles INCOMPLETE specially... mjordan is working on a related issue right now |
| 19:40.41 | mickecarlsson | What I really want is that it should go to next exten as it did in 1.6.0, that was I really want |
| 19:40.55 | kpfleming | next priority, you mean |
| 19:41.00 | mickecarlsson | Yes |
| 19:41.31 | kpfleming | i wasn't following the first part of this... when did the behavior change? |
| 19:41.40 | mickecarlsson | Hang on, checking |
| 19:41.51 | Corydon76-home | Best as I can tell, 1.6.1 or 1.6.2 |
| 19:42.09 | mickecarlsson | Up to Asterisk 1.6.0.28 the SIP 484 is working as it should. |
| 19:42.32 | mickecarlsson | In Asterisk 1.6.2.14 it would go to 't' |
| 19:42.50 | mickecarlsson | With Asterisk 1.6.2.15-r it would return hangupcause 111 |
| 19:43.12 | mickecarlsson | It took me a whole day to find out where and on what version it broke |
| 19:43.41 | mjordan | mickecarlsson: ironically, that was my yesterday as well. |
| 19:44.11 | kpfleming | well, behavior changes like that within a release branch are unacceptable, in my opinion |
| 19:44.17 | kpfleming | we need to stop doing that |
| 19:44.43 | Corydon76-home | Yeah, I don't think the 111 change was correct |
| 19:44.57 | sruffell | oron_laptop: dohâ¦that channel "hole" I forgot about that. |
| 19:45.10 | mickecarlsson | Read the ticket, I think I have covered every detail about it |
| 19:45.55 | mjordan | Corydon76-home: ASTERISK-17288 covers the 111 change |
| 19:46.33 | kpfleming | it's unfortunate that we've caused this breakage, and we're not going to make new releases of 1.6.x to correct it |
| 19:46.56 | kpfleming | however, we can fix 1.8 and later so that the useful behaviors are available, even if there have to be app_dial options to select what is desired |
| 19:47.27 | mickecarlsson | Now we are talking |
| 19:47.35 | mickecarlsson | I am all ears |
| 19:48.40 | kpfleming | so we have "return to dialplan with DIALSTATUS == <xxx>" as one option, right? |
| 19:48.56 | mickecarlsson | Yes |
| 19:49.15 | mickecarlsson | Old behavior |
| 19:49.27 | mickecarlsson | And then the new one, going to 't' |
| 19:49.36 | kpfleming | and as a second option, if there is no 'next priority' in the dialplan and autofallthrough is enabled, the automatic behavior should attempt to indicate 'incomplete' to the calling device |
| 19:49.52 | Corydon76-home | Well, it doesn't go directly to 't'. It returns to the dialplan and waits for the extension to be completed |
| 19:49.56 | kpfleming | right |
| 19:50.04 | mickecarlsson | got it |
| 19:50.34 | kpfleming | but that behavior doesn't make a lot of sense for channel types do normally do en-bloc dialing |
| 19:50.58 | mjordan | kpfleming: sounds like the pbx Incomplete logic should be the option, not the default |
| 19:50.59 | kpfleming | so it definitely needs to be optional, not the default |
| 19:51.12 | kpfleming | mjordan: jinx |
| 19:51.30 | mjordan | yeah :-) I'll update 17288 to reflect this, since we're already working it |
| 19:52.01 | kpfleming | and further... running Incomplete *could* indicate to the channel driver that the dialing is incomplete... that way if the channel driver knows that it isn't going to be supplying any more digits for the extension, it can go ahead and indicate 'incomplete' to the calling device |
| 19:52.53 | kpfleming | which means that the dialplan writer can just directly call Incomplete if that's what they want to do, and no app_dial option is necessary at all |
| 19:53.13 | kpfleming | 'implicit behavior is bad' - kpfleming |
| 19:55.37 | kpfleming | thoughts, comments? |
| 19:56.16 | mickecarlsson | I agree on the optional for Imcomplete |
| 19:57.14 | mjordan | works for me - btw, thanks for testing the first patch mickecarlsson, even if it made the bad behavior into an even worse "correct" behavior :-) |
| 19:57.43 | mickecarlsson | Well, thanks for take a stab at it |
| 19:57.49 | mickecarlsson | And thanks for the chat here |
| 19:58.04 | mickecarlsson | I am still on 1.4 due tothis |
| 19:58.18 | Corydon76-home | kpfleming: yep, I'm in agreement |
| 19:58.22 | kpfleming | yay |
| 19:58.34 | mickecarlsson | My first Asterisk was a BE license, still have it |
| 19:58.49 | kpfleming | so that would require a new control frame, to allow the channel driver to be told that the pbx is about to enter 'incomplete' mode |
| 20:00.56 | Corydon76-home | I wonder if Polycom SIP phones have a message attuned to this purpose |
| 20:01.24 | Corydon76-home | Or if 484 just does that automatically |
| 20:06.19 | oron_laptop | returned... |
| 20:06.51 | oron_laptop | sruffell: If you apply the sysfs channel representation patch, there's no more hole... |
| 20:07.09 | jsmith | Corydon76-home: Sorry, wasn't paying attention... attuned for which purpose? |
| 20:07.31 | Corydon76-home | jsmith: for informing the user operator that the number is incomplete and needs additional digits |
| 20:08.17 | sruffell | hmm... |
| 20:08.41 | Corydon76-home | preferably with an interface with a cursor, inviting the user operator to type more digits at the end, instead of just ending the call |
| 20:09.14 | oron_laptop | sruffell: the dahdi-sysfs-chan.c allocate device files for channels from clean ranges (dynamic major numbers) |
| 20:10.04 | oron_laptop | sruffell: (oops, that obviously does not apply to access via /dev/channel) |
| 20:10.05 | sruffell | oron_laptop: How risky is it to queue it for 2.6? |
| 20:10.31 | sruffell | currently, it just skips those minors right? |
| 20:10.50 | jsmith | Corydon76-home: That's the 484 message :-) |
| 20:10.58 | oron_laptop | thinking... |
| 20:10.58 | sruffell | I could just add those as reserved in the function that see's if the channo can fit in a range.. |
| 20:17.27 | oron_laptop | sruffell: Just looked at the code: the device file created do not have holes, but everybody that use /dev/channel |
| 20:17.47 | oron_laptop | sruffell: still have this problem. |
| 20:19.00 | sruffell | so in the current trunk channo 250 will have a minor of something other than something like 256? |
| 20:19.07 | sruffell | scratch that. |
| 20:19.32 | sruffell | so in the current trunk the 250th channel will have /dev/dahdi/256 device created? or /dev/dhadi/250 will have a minor of 256? |
| 20:20.27 | oron_laptop | sruffell: the dial_byname have strict mapping: minor==chan_number |
| 20:20.28 | sruffell | I'm not keen on changing those minors right nowâ¦so that 2.6 will be completely backward compatible by default with all existing userspace scripts. In case someone is precreating those files. |
| 20:21.06 | sruffell | thinks some more. |
| 20:21.29 | oron_laptop | sruffell: we should not change them now (compat), but with pinned spans it should be easier to skip those numbers (need to code this...) |
| 20:21.59 | sruffell | I agreeâ¦my current thought is that we should just code n 250-255 as reserved channos. |
| 20:22.31 | sruffell | will that break any of your scripts? Do you currently have anything that requires those be available for assignment as channels? |
| 20:23.04 | oron_laptop | sruffell: Agreed, but let's make it n 250-255 AND MAJOR==DAHDI_MAJOR, so in the future we could lift this (via dial_byname) |
| 20:23.13 | sruffell | ahh..good point. |
| 20:23.20 | sruffell | okâ¦and you're gone until next Wed? |
| 20:23.40 | oron_laptop | sruffell: The scripts are trivial, and trivial to change. The only assumption is minor==chan_number. |
| 20:23.58 | oron_laptop | sruffell: Yes, out of Xorcom until Wed. |
| 20:24.38 | oron_laptop | sruffell: (though I read my mail every night, but I don't have available hardware to test, code, etc.) |
| 20:25.24 | sruffell | ok. I should be able to have the candidate series to you before then. |
| 20:25.37 | oron_laptop | sruffell: thnks. |
| 20:26.08 | oron_laptop | sruffell: Do you think you would be able to verify the assignment bug I mailed about? |
| 20:26.16 | sruffell | yesâ¦I'll chase that down. |
| 20:26.21 | sruffell | thanks for the email, btw. |
| 20:26.39 | sruffell | I scanned the email and it rang some old bells... |
| 20:27.12 | oron_laptop | sruffell: lucky me that I wasn't using this code when those bells rang ;-) |
| 20:27.31 | sruffell | heh |
| 20:40.35 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:42.26 | alecdavis | sruffell: re echo on TDM800p FXS ports. I had echocan=yes configured on the FXS ports, perhaps shouldn't have. |
| 20:43.01 | sruffell | that still shouldn't have really affected what you heard on the handset connected to the FXS portâ¦. |
| 20:43.26 | alecdavis | sruffell: but the echo only happens when you have a caller id capable phone plugged in, it didn't manifest itself when I only had a 'dumb' phone plugged in. |
| 20:43.30 | sruffell | unless there was a bit of acoustic echo in your handset that was making it back to the FXO port... |
| 20:44.03 | sruffell | and you are the only one who hears itâ¦not the person on the other end? |
| 20:44.39 | alecdavis | forgot to say, for the tests night before last, I rang voicemailmain on the same box. |
| 20:45.15 | alecdavis | so FXS port dial 2000 which is voicemailmain. |
| 20:45.37 | sruffell | and you hear an echo of the recorded prompts..or an echo of your own voice? |
| 20:46.09 | sruffell | still doesn't quite understand how a cid capable handset would affect this |
| 20:46.18 | alecdavis | echo of you own voice, but you don't hear it before a cw pip has come in. |
| 20:46.48 | alecdavis | cid phones send cas tones to signal that it can received callerid |
| 20:51.34 | alecdavis | <PROTECTED> |
| 20:52.38 | alecdavis | that's chan_dahdi tones sent to the FXS port, the phone respnds with another tone if it supports CW. |
| 20:54.00 | alecdavis | but: then I updated to dahdi trunk, which has later firmware, and I cannot get it anymore. |
| 20:57.59 | alecdavis | so the sequence is. |
| 20:57.59 | alecdavis | dial voicemail main from an FXS port. |
| 20:57.59 | alecdavis | don't enter any DTMF, talk over the prompts and listen for echo, there is none - or very samll. |
| 20:57.59 | alecdavis | from a sip phone ring the FXS port. |
| 20:57.59 | alecdavis | FXS will hear CW pip. Hangup SIP call to FXS port. |
| 20:58.00 | alecdavis | At FXS phone keep talking, and listen for echo, it's there. |
| 20:59.27 | alecdavis | totally non scientific test, I know. But thats what the users experience. |
| 21:04.53 | mvanbaak | wedhorn: you here ? |
| 21:09.02 | mvanbaak | wedhorn: 'skinny reload' crashed my asterisk ;) |
| 21:09.35 | anonymouz666 | mvanbaak: that's why safe_asterisk exists :-) |
| 21:09.56 | mvanbaak | nah, I hate that hack |
| 21:09.57 | anonymouz666 | j/k |
| 21:12.48 | mvanbaak | nah, if it annoys me enough I will fix it ;) |
| 21:13.12 | mvanbaak | for now I'm just recreating my home office setup |
| 21:13.53 | sruffell | alecdavis: ahh..ok, I understand. I didn't know cid phones send a response. What does "but: then I updated to dahdi trunk, which has later firmware, and I cannot get it anymore" mean? You don't get the echo, or the tone, or..? |
| 21:14.16 | wedhorn | mvanbaak: yeah, lots of changes, and I didn't test that .... |
| 21:15.50 | mvanbaak | wedhorn: I altered my config (added some speeddials to my 7960) and typed: skinny reload |
| 21:15.54 | mvanbaak | *BOOM* |
| 21:16.35 | wedhorn | yeah. When coding and testing, you need to stop, recompile/reconfigure, start, so reload gets overlooked |
| 21:17.01 | mvanbaak | I know |
| 21:17.10 | mvanbaak | reload has been broken before a couple of times |
| 21:17.17 | mvanbaak | I'll look into it later |
| 21:17.38 | alecdavis | sruffell: that's correct, I can't get the echo any more. |
| 21:17.41 | wedhorn | sounds good, suppose you can have a look at realtime at some stage |
| 21:18.16 | wedhorn | oh yeah, one of the mods I did should help for your rtp timeout stuff (that was you wasn't it?) |
| 21:18.55 | alecdavis | sruffell: the SAS and CAS signalling is toward the handset, then the handset returns a DTMF 'A' or DTMF' D' if it supports CID. |
| 21:19.30 | sruffell | I'm guessing your 'old' version was before 2.4.0? |
| 21:20.21 | mvanbaak | wedhorn: yeah, that was me |
| 21:21.10 | mvanbaak | wedhorn: with the removal of the do_housekeeping the rtptimeout stuff became a bit more complicated ;) |
| 21:21.36 | wedhorn | mvanbaak: in revision 322381, I removed do_monitor and set up the scheduling properly, it should be fairly easy to add a schedule for rtp |
| 21:21.40 | wedhorn | no easier |
| 21:21.44 | wedhorn | hang on |
| 21:21.52 | sruffell | alecdavis: is memory serves, I saw 1.25 (from http://svnview.digium.com/svn/dahdi?view=revision&revision=8983 released in 2.4.0) that could actually introduce echo on the line. Come to think of itâ¦I think it was with you that I was chasing that down. |
| 21:22.56 | mvanbaak | wedhorn: cool |
| 21:25.10 | wedhorn | mvanbaak: there's two functions, skinny_sched_del and skinny_sched_add, should be fairly trivial to write a skinny_sched_modify |
| 21:25.29 | mvanbaak | yeah, I'm reading the code |
| 21:25.34 | wedhorn | then hook in in the packet skinny_read/write |
| 21:25.35 | mvanbaak | shouldn't be that hard |
| 21:27.00 | wedhorn | and you can actually sched down to approaching zero seconds (under the housekeeping, you had to wait for timeout) |
| 21:27.15 | mvanbaak | yeah |
| 21:27.17 | mvanbaak | nice |
| 21:27.28 | mvanbaak | that will make my rtptimeout work really easy |
| 21:28.41 | alecdavis | sruffell: it would be really nice if the dahdi version number was logged to the kernel like the debug messages. Then I could tell which version I was running before I upgraded. |
| 21:28.59 | sruffell | it isâ¦. |
| 21:29.00 | mvanbaak | I need to get my stuff up-to-date |
| 21:29.04 | mvanbaak | so it can be included |
| 21:30.50 | sruffell | alecdavis: https://github.com/sruffell/dahdi-linux/blob/master/drivers/dahdi/dahdi-sysfs.c#L184 |
| 21:30.52 | mvanbaak | but not now |
| 21:30.56 | mvanbaak | it's midnight here ;) |
| 21:31.54 | alecdavis | sruffell: it was SVN-trunk-r9912M |
| 21:32.32 | mvanbaak | let me first get my asterisk up-to-date with trunk |
| 21:33.19 | korch | howcome asterisk doesn't use timerfd for all of the various timing logic & checks? |
| 21:33.30 | mvanbaak | meh, where did I put the source .... |
| 21:33.57 | korch | you can use timerfd + epoll to really clean up nasty blocking & timing logic to make the code look more like evented or reactor pattern |
| 21:35.22 | korch | according to my rough approx, ~30% of all the source in asterisk is uncommented, undocumented, non-DRY juggling and comparing of timing ms junk |
| 21:36.07 | mvanbaak | really ? |
| 21:36.09 | korch | in my zeromq app C module which is now working i have been able to ditch all the crap and just use epoll + timerfd and audio in/out works great :P |
| 21:36.20 | alecdavis | sruffell: if you don't restart dahdi for a long time, the log then will dissappear. how about on close, we also log the closing version. |
| 21:36.36 | Qwell | korch: timerfd didn't exist 10 years ago when Asterisk was first created. |
| 21:36.43 | korch | it felt kinda cool to not even need to use any of the 10 different polling functions in channel.c and instead use my own that is like 50 LoC :) |
| 21:37.05 | Qwell | (and obviously neither was epoll) |
| 21:37.09 | korch | Qwell: heh ok, legacy technical debt, point taken |
| 21:37.37 | Qwell | patches welcome. |
| 21:38.08 | korch | no doubt in the next couple of weeks i'm gonna submit some patches |
| 21:38.14 | mvanbaak | cool |
| 21:39.20 | wedhorn | mvanbaak: some scheduling stuff (auto answer) |
| 21:39.22 | wedhorn | http://svnview.digium.com/svn/asterisk/trunk/channels/chan_skinny.c?r1=322544&r2=322543&pathrev=322544 |
| 21:39.33 | wedhorn | when you get some time |
| 21:42.13 | sruffell | alecdavis: Oddâ¦there have been no functional changes to the hwec related code between that commit and the current trunk. |
| 21:44.06 | sruffell | alecdavis: andâ¦.I'm not really excited about logging the version on start *and* stop. You could always run "cat /sys/module/dahdi/version" to check the version just before unloading? |
| 21:44.37 | mvanbaak | wedhorn: hhmm, looks ok to me |
| 21:46.41 | alecdavis | sruffell: I did do a 'dahdi show version', recorded it in notepad, but didn't save it. Louckily my logs go back to april, so I could find the version. |
| 21:47.21 | sruffell | nods |
| 21:47.44 | alecdavis | sruffell: thus, I can now recompile and retest with 9912. |
| 21:48.03 | sruffell | ok |
| 21:49.44 | alecdavis | I still like the idea though, of logging the closing version. wouldn't it go in dahdi_cleanup() |
| 21:50.14 | alecdavis | or dahdi_sysfs_exit(). |
| 21:50.50 | sruffell | I'm for reducing the amount of information in the kernel logs that can be obtained elsewhereâ¦.but perhaps it's just me... |
| 21:51.54 | korch | curious, how many full-time developers are actively working on asterisk at any time? i'd include both engineers at Digium as well at outsiders from 3rd parties and open source devs |
| 21:51.55 | alecdavis | If it was there, then when the question is asked, what did you change, it's there, in todays log. |
| 21:53.03 | mvanbaak | korch: we cannot estimate how many of the 3rd parties and open source devs work full-time on asterisk |
| 21:53.10 | alecdavis | assuming 'today' is the day you restarted dahdi, and something has changed. |
| 21:53.12 | Corydon76-home | korch: I think only Digium has full-time developers. The rest of us are all part timers |
| 21:53.15 | mvanbaak | korch: and besides that: what is full-time for an opensource dev ? |
| 21:53.38 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 21:53.56 | kpfleming | man... this channel has been unusually busy today |
| 21:54.11 | mvanbaak | ut-oh, |
| 21:54.18 | mvanbaak | everyone: be quiet ;) |
| 21:55.11 | kpfleming | no, this is a good thing |
| 21:55.15 | kpfleming | reminds me of 3-4 years ago |
| 21:55.19 | kpfleming | it's nice to see |
| 21:55.58 | Corydon76-home | Reminds me that I'm glad this is a silent medium. All that talking could otherwise lead to a cold-induced headache |
| 21:58.46 | mvanbaak | kpfleming: I agree :) |
| 21:59.32 | kpfleming | yay... ASTERISK-18394 resolved |
| 21:59.51 | mvanbaak | hurray |
| 21:59.57 | mvanbaak | which reminds me .... |
| 22:00.01 | mvanbaak | jira .... |
| 22:00.20 | mvanbaak | haven't even logged in to it yet ;) |
| 22:00.59 | mvanbaak | ah, now I know |
| 22:01.04 | mvanbaak | I cannot login |
| 22:01.15 | mvanbaak | does not work with safari |
| 22:01.24 | kpfleming | we fixed that problem |
| 22:01.29 | kpfleming | at least, the one that lots of users had |
| 22:01.53 | mvanbaak | not working here |
| 22:02.20 | kpfleming | what is the symptom? |
| 22:02.59 | mvanbaak | the server issues.asterisk.org did not accept the certificate |
| 22:03.14 | kpfleming | you shouldn't be sending a client certificate |
| 22:05.46 | mvanbaak | as far as I know I'm not doing that |
| 22:06.09 | file | SVN cert? |
| 22:06.17 | kpfleming | well, if that's what the error message was, you are sending a cert |
| 22:07.01 | kpfleming | time to head home... be back online tomorrow if you're still having this problem |
| 22:08.44 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mqefqykdngoejcun) |
| 22:20.56 | *** join/#asterisk-dev otherwiseguy_ (~terry@69.76.217.40) |
| 22:23.25 | mvanbaak | ok, jira confuses me ;) |
| 22:23.41 | wedhorn | mvanbaak: me too ... |
| 22:23.54 | mvanbaak | I'm lost |
| 22:26.39 | mvanbaak | I have to type all kinds of funky stuff before I get what I want |
| 22:26.57 | mvanbaak | "This query is too complex to display in Simple mode" |
| 22:28.06 | mvanbaak | ok, how to get all tickets about chan_skinny ? |
| 22:30.50 | wedhorn | mvanbaak: https://issues.asterisk.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+ASTERISK+AND+component+in+%28%22Channels%2Fchan_skinny%22%2C+%22Channels%2Fchan_skinny%2FNewFeature%22%29+AND+status+%3D+Open+ORDER+BY+updated+DESC%2C+priority+DESC |
| 22:30.53 | wedhorn | maybe |
| 22:31.21 | mvanbaak | I just did a 'quick search' for skinny |
| 22:31.22 | mvanbaak | ;) |
| 22:31.45 | wedhorn | okay, thought you were calling it a night, and I'm off to work |
| 22:31.58 | mvanbaak | lol |
| 22:32.02 | mvanbaak | cant help it |
| 22:32.14 | mvanbaak | I'm getting hooked to chan_skinny again |
| 22:32.16 | mvanbaak | https://issues.asterisk.org/jira/browse/ASTERISK-16610 |
| 22:32.29 | mvanbaak | meh |
| 22:32.37 | mvanbaak | I'll look into the reload stuff later |
| 22:32.43 | mvanbaak | have fun at work wedhorn |
| 22:34.27 | alecdavis | bring back mantis:) jira requires me to get a new monitor, 1920x1080 should do, then can watch full HD in spare time:) |
| 22:38.58 | mvanbaak | amen |
| 22:53.11 | mvanbaak | meh, latest trunk segfaults on me |
| 22:56.56 | mvanbaak | [Sep 2 00:56:24] res_ael_share.so => (share-able code for AEL) |
| 22:56.56 | mvanbaak | Program received signal SIGSEGV, Segmentation fault. |
| 22:56.56 | mvanbaak | [Switching to Thread 801a041c0 (LWP 100386)] |
| 22:56.56 | mvanbaak | 0x0000000800c372d2 in getframeaddr () from /usr/local/lib/libexecinfo.so.1 |
| 23:50.33 | pabelanger | mvanbaak: what OS? |
| 23:52.32 | mvanbaak | FreeBSD |
| 23:54.25 | pabelanger | version? |
| 23:55.13 | pabelanger | we test with FreeBSD, and it is successful: http://bamboo.asterisk.org/browse/ASTTRUNK-FREEBSD81 |
| 23:55.31 | pabelanger | Always curious when asterisk crashes on startup and bamboo does not catch it |
| 23:55.59 | snuff-work | my trunk crashes on shutdown with chan skinny i think.. not that i care |
| 23:56.30 | alecdavis | only last week, on debian linux, trunk crashes on startup if you try to make a sip call too early. |
| 23:57.23 | alecdavis | too early being, within the first 20 seconds. |
| 23:57.56 | alecdavis | or so. haven't measured it. |
| 23:58.04 | mvanbaak | FreeBSD ifrid.vanbaak.info 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 |
| 23:58.06 | pabelanger | alecdavis: possible, we only start testing once we get: self.cli_exec("core waitfullybooted") return |
| 23:58.47 | pabelanger | mvanbaak: ya, we'd need to at a FreeBSD 8.2 build agent |
| 23:58.53 | pabelanger | s/at/add |