| 00:04.35 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE004010100002-CM00159a090f12.cpe.net.cable.rogers.com) |
| 00:55.46 | *** join/#asterisk-dev wdbl (~not@ool-44c0668f.dyn.optonline.net) |
| 01:00.34 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:00.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:10.37 | *** join/#asterisk-dev wdbl (~not@ool-44c0668f.dyn.optonline.net) |
| 02:06.32 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE004010100002-CM00159a090f12.cpe.net.cable.rogers.com) |
| 02:16.13 | russellb | pabelanger_: you're welcome to have team branch access. email jpeeler@digium.com, requesting a certificate for team branch access. He'll work with you on the details. |
| 02:30.15 | paravoid | what's the expected release date for 1.8? |
| 02:30.23 | kpfleming | 2010 |
| 02:30.27 | Kobaz | foorrrreeeevvverrr |
| 02:33.37 | russellb | it's at least Q3 at this point |
| 02:35.04 | paravoid | ok, thanks! |
| 02:40.58 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE004010100002-CM00159a090f12.cpe.net.cable.rogers.com) |
| 03:12.20 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 03:12.20 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:53.26 | *** join/#asterisk-dev jameswf (~james@unaffiliated/jameswf-home) |
| 07:43.59 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:16.13 | *** join/#asterisk-dev pentanol (~pentanol@77.35.49.164) |
| 08:39.56 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 10:00.10 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 10:01.17 | pentanol | anybody alive here? |
| 10:16.58 | *** join/#asterisk-dev sgimeno (~chatzilla@83.46.36.105) |
| 11:07.08 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:07.08 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:26.35 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 11:50.14 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:50.14 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:58.06 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:03.23 | *** join/#asterisk-dev sgimeno (~chatzilla@83.46.36.105) |
| 12:45.06 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 12:45.06 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:45.23 | eliel | morning |
| 12:51.03 | eliel | russellb: i will be here if you want to discuss some details about my gsoc application |
| 12:55.15 | pabelanger | eliel: morning! |
| 12:55.31 | kpfleming | eliel: russell is leaving for paris some time today... he may not be online much |
| 12:55.31 | eliel | pabelanger: good morning! |
| 12:55.48 | snuff-home | paris?? busy guy ;) |
| 12:56.35 | eliel | kpfleming: oooh, thanks |
| 13:25.00 | *** join/#asterisk-dev hluesea (~hluesea@88.247.127.66) |
| 13:25.40 | hluesea | hello, anyone is here now how can i active channel number via web ? |
| 13:26.32 | hluesea | i used this but it has been unsucces :( http://pastebin.com/LAXEzRaF |
| 13:28.24 | eliel | hluesea: i think you will get more help in #asterisk (but try modifying "show channels" -> "core show channels"). |
| 13:28.51 | hluesea | thanks eliel |
| 13:30.48 | eliel | yw |
| 13:41.26 | seanbright | so what is the root cause of a "Dropping incompatible voice frame on Local/..." message? |
| 13:50.11 | *** join/#asterisk-dev Corydon76-dig (eleven@c-69-137-80-31.hsd1.tn.comcast.net) |
| 13:50.11 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 13:53.05 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:53.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:03.00 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 14:12.19 | *** join/#asterisk-dev diegomad (~mad@190.146.200.120) |
| 14:23.38 | *** join/#asterisk-dev moy (~chatzilla@74.12.133.16) |
| 14:23.49 | *** join/#asterisk-dev Dovid (~annon@213.8.118.62) |
| 14:24.30 | *** join/#asterisk-dev sgimeno (~chatzilla@83.46.36.105) |
| 14:26.44 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:45.48 | *** join/#asterisk-dev adamsweet (~adamsweet@brooke.credativ.ltd.uk) |
| 14:47.51 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.24.176.229) |
| 14:49.22 | *** join/#asterisk-dev chazzam (~chazz@173-24-238-25.client.mchsi.com) |
| 14:54.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:54.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:56.16 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:56.16 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:56.57 | *** part/#asterisk-dev adamsweet (~adamsweet@brooke.credativ.ltd.uk) |
| 15:00.02 | seanbright | pabelanger: i don't get the (.*$\) part of the regexs |
| 15:00.48 | seanbright | ^;astetcdir.*$ should be sufficient |
| 15:00.55 | seanbright | and you can drop the 'g' flag as well |
| 15:01.31 | pabelanger | me neither ;) My sed skills are week. |
| 15:01.38 | pabelanger | will do. |
| 15:04.24 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:04.25 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:18.25 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 15:30.42 | *** join/#asterisk-dev Corydon76-lap (~Corydon76@nat/digium/x-lqnfokcutiarwvbs) |
| 15:30.42 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:31.50 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:39.17 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 15:45.57 | *** join/#asterisk-dev |Rain| (rain@ev.il.net) |
| 15:46.42 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:47.25 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 15:47.25 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:48.27 | *** join/#asterisk-dev jetsnoc (~brian@kickback-66.eth242.twf.pmt.org) |
| 15:49.19 | |Rain| | does pbx_exec() expect the channel to be (un)locked? I'm having some trouble calling Gosub from within app_queue's is_our_turn() |
| 16:03.42 | Corydon76-lap | Yes, it does |
| 16:04.06 | Corydon76-lap | It needs the channel to be unlocked to ensure that proper locking order is maintained |
| 16:04.32 | seanbright | pabelanger: that backslash before the | is necessary? |
| 16:08.32 | leifmadsen | Would anyone be opposed to me just removing line 12659 in app_voicemail.c (revision 256823) of trunk? |
| 16:08.44 | leifmadsen | Line in question being: ast_debug(1000, "This message is too urgent!\n"); |
| 16:09.09 | Corydon76-lap | leifmadsen: Um, almost nobody should ever see that message |
| 16:09.14 | leifmadsen | exactly |
| 16:09.16 | seanbright | i think that's the point |
| 16:09.22 | seanbright | but i say "meh" |
| 16:09.25 | leifmadsen | and it doesn't add anything of value |
| 16:09.45 | Corydon76-lap | leifmadsen: That's true of most debugging messages |
| 16:11.05 | leifmadsen | OK, this stems from a discussion about trying to get our verbose and debug levels into something more reasonable (something like between 0 and 10) instead of them being all over the place |
| 16:11.09 | seanbright | leifmadsen: i am not opposed. fwiw. |
| 16:11.38 | leifmadsen | FYI: https://issues.asterisk.org/view.php?id=17159#120245 |
| 16:11.49 | Corydon76-lap | leifmadsen: for verbose, I have no issue, but for debug, I think that's an uphill battle |
| 16:12.01 | leifmadsen | why? |
| 16:12.20 | leifmadsen | everything already lands between 0 and 10 except for that one message |
| 16:12.51 | leifmadsen | at least from the version tzafrir was looking at |
| 16:12.59 | Corydon76-lap | leifmadsen: because debugging is by definition only for the developer |
| 16:13.16 | leifmadsen | I don't understand where you're going with this |
| 16:13.59 | Corydon76-lap | leifmadsen: why standardize on something that should almost never be seen? |
| 16:14.33 | leifmadsen | because then when we tell a user to do "core set debug 10" we know we're getting all the information we need when the user reports it to the developer |
| 16:14.54 | Corydon76-lap | More to the point: why bug someone about debug levels that don't conform to some arbitrary standard, before the code is committed? |
| 16:15.19 | seanbright | leifmadsen: sure, remove it. |
| 16:15.21 | seanbright | NOW |
| 16:15.24 | seanbright | GO GO GO |
| 16:15.24 | russellb | remove it! |
| 16:15.26 | leifmadsen | done |
| 16:15.30 | seanbright | awesome |
| 16:15.39 | russellb | also, standardization is a good thing. |
| 16:15.42 | russellb | that is all. |
| 16:15.44 | Corydon76-lap | That assumes that the debugging information is at all useful outside of debugging the particular code when it was written |
| 16:15.46 | seanbright | points to his bike shed |
| 16:15.51 | seanbright | it's puce |
| 16:15.59 | russellb | if it's not useful, it shouldn't be there |
| 16:16.01 | Qwell | If it's not useful outside of when the code was written, why is it there? |
| 16:16.08 | russellb | Qwell: i win |
| 16:16.19 | Corydon76-lap | Qwell: because the code needed to be debugged originally |
| 16:16.24 | Qwell | russellb: I won't comment about comment length. |
| 16:16.33 | Qwell | I'll just...refrain. ;p |
| 16:16.34 | seanbright | whoa whoa whoa |
| 16:16.37 | seanbright | this is a family channel |
| 16:16.49 | Corydon76-lap | Just because code is debugged doesn't mean the debugging information is at all useful after the fact |
| 16:17.09 | pabelanger | seanbright: Yes, I had to leave it in, otherwise sed would complain. |
| 16:17.11 | Qwell | but if it's not useful, it can be removed before being committed, no? |
| 16:17.15 | seanbright | pabelanger: strange. |
| 16:17.54 | Corydon76-lap | Qwell: I'm saying that we shouldn't spend ANY time on arbitrary standards for debug levels, because it's not worth the discussion time to even make up those standards |
| 16:18.18 | seanbright | pabelanger: i'm pretty sure it's because you're passing -r, which is non-standard. |
| 16:18.38 | seanbright | sed -e 's|^;astetcdir.*$|;astetcdir => $(ASTETCDIR)|' /etc/asterisk/asterisk.conf |
| 16:18.42 | seanbright | that works fine for me with GNU sed |
| 16:18.55 | seanbright | and probably openbsd sed (which i haven't tested yet) |
| 16:19.29 | seanbright | (the single quotes are important to stop variable interopolation in the shell) |
| 16:19.41 | tzafrir_laptop | Corydon76-dig, how do I enable "all debug messages"? |
| 16:19.55 | seanbright | core set debug 118983721897312 |
| 16:20.04 | leifmadsen | seanbright: the square root of pi |
| 16:20.11 | Corydon76-lap | tzafrir_laptop: why do you need to? |
| 16:20.17 | seanbright | core set debug 3i |
| 16:20.19 | Qwell | pi square r cake |
| 16:20.31 | pabelanger | seanbright: To be honest, I don |
| 16:20.33 | pabelanger | doh! |
| 16:21.05 | Qwell | Corydon76-dig: why? to debug a problem |
| 16:21.14 | tzafrir_laptop | Corydon76-dig, https://issues.asterisk.org/view.php?id=17159 |
| 16:21.34 | Corydon76-lap | Qwell: how do you know that any of the debug messages are at all relevant to your problem? |
| 16:21.36 | pabelanger | seanbright: To be honest, I was looking at another script with contrib/script (live_ast) and used it for my sed template. I can remove -r option and convert to single ' too. |
| 16:21.51 | Qwell | because I can read the code and see where the debug message is in the flow |
| 16:21.56 | tzafrir_laptop | Corydon76-dig, because I don't know that they are not |
| 16:22.13 | Corydon76-lap | Qwell: AH-HA!!! You read the code. Thank you, end of argument. |
| 16:22.23 | Qwell | I read the code *after seeing the message*. |
| 16:22.32 | tzafrir_laptop | Or should any message that is useful for tracing be 'verbose' ? |
| 16:22.48 | Qwell | if that's the case, why do we have ast_debug at all? Let's just remove it. |
| 16:23.10 | seanbright | pabelanger: i use gnu tools for everything, so it doesn't bother me. but there are others it would annoy. |
| 16:23.16 | Corydon76-lap | Qwell: it's there for the programmer, not for the general user |
| 16:23.20 | seanbright | and might as well get it right the first time |
| 16:23.44 | Corydon76-lap | Qwell: if we wrote perfect code, there would be no reason for debug statements at all |
| 16:24.05 | Qwell | then there shouldn't be any debug messages in the code when we commit |
| 16:24.27 | Corydon76-lap | leifmadsen: are you following us here? |
| 16:24.44 | leifmadsen | I left the discussion a while ago because it got silly |
| 16:24.50 | seanbright | ditto |
| 16:24.51 | seanbright | :-) |
| 16:24.55 | russellb | ditto! |
| 16:24.56 | Qwell | this is rather silly. it's trivial to say what a max debug level should be |
| 16:25.00 | leifmadsen | I went back to working on bugs |
| 16:25.12 | seanbright | ohhhh |
| 16:25.13 | Corydon76-lap | Qwell: Right, maximum level should be 2.1 billion |
| 16:25.15 | seanbright | bazinga! |
| 16:25.15 | leifmadsen | I picked 10 because other than 1 message, 10 was the highest level |
| 16:25.18 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 16:25.18 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 16:25.39 | Corydon76-lap | same as the amount of accuracy in a signed integer |
| 16:25.49 | Corydon76-lap | and LEAVE IT BE |
| 16:25.56 | russellb | facepalms |
| 16:25.58 | Qwell | so we should tell users to set debug to MAX_INT when we need to see it? |
| 16:26.05 | Corydon76-lap | YES! |
| 16:26.15 | Corydon76-lap | INT_MAX, but yes |
| 16:26.25 | kpfleming | UINT_MAX |
| 16:26.43 | russellb | let's play a game called everyone go do something useful |
| 16:26.45 | seanbright | Zzzzzzzz... |
| 16:26.46 | Corydon76-lap | Nope, it's currently signed, and we should LEAVE IT BE |
| 16:27.15 | eliel | is going to play the game... |
| 16:27.23 | Corydon76-lap | russellb: that is PRECISELY my argument. Go do something useful |
| 16:28.14 | russellb | kthx |
| 16:28.36 | Corydon76-lap | russellb: speaking of which, have you assigned a random mentor to each student for which we want a slot, so that Carol's slot assignment algorithm gives us initial slot allocations? |
| 16:29.17 | pabelanger | seanbright: "sed: -e expression #1, char 47: unterminated `s' command" if I drop the -r and \ on my shell. |
| 16:29.29 | seanbright | pastebin the full example |
| 16:29.34 | seanbright | that is failing for you |
| 16:29.43 | Corydon76-lap | russellb: or did you miss that request in the middle of a random thread, since you were on vacation? |
| 16:29.48 | seanbright | of just paste if it's a one-linger |
| 16:29.51 | seanbright | liner* |
| 16:29.54 | pabelanger | 1 sec |
| 16:32.02 | pabelanger | http://asterisk.pastebin.com/bwEakvLf |
| 16:32.17 | pabelanger | If I run it from make, it fails. If I pass it via CLI, no issues. |
| 16:32.55 | russellb | Corydon76-lap: missed it, *grumbles* |
| 16:33.13 | russellb | the process is sucking a freaking mess |
| 16:33.48 | *** join/#asterisk-dev jetsnoc (~brian@kickback-66.eth242.twf.pmt.org) |
| 16:35.56 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:35.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:36.23 | seanbright | pabelanger: ah. make is replacing '$/' |
| 16:36.30 | seanbright | err |
| 16:36.31 | seanbright | $| |
| 16:36.36 | leifmadsen | lunch! |
| 16:37.37 | pabelanger | Damn make |
| 16:38.01 | seanbright | pabelanger: double the $s |
| 16:38.26 | seanbright | -e 's/^;astetcdir.*$$/;astetcdir => $(ASTETCDIR)/' \ |
| 16:38.53 | Qwell | don't use / :D |
| 16:38.58 | seanbright | it happens with | too |
| 16:39.51 | seanbright | tests with openbsd |
| 16:41.35 | seanbright | keep using the |s too. i just switched to / to test. |
| 16:44.36 | pabelanger | -e 's|^;astetcdir.*$$|;astetcdir => $(ASTETCDIR)|' \ |
| 16:44.42 | pabelanger | works fine here. |
| 16:45.19 | pabelanger | seanbright: are you ok with that? |
| 16:48.39 | seanbright | looks good to me |
| 16:49.21 | pabelanger | :) Thanks for your help. |
| 16:49.28 | seanbright | no sweat |
| 16:57.43 | russellb | pabelanger: did you see my answer earlier about team branch access? |
| 16:59.44 | |Rain| | VmData: 869240 kB |
| 16:59.50 | |Rain| | so uh, any advice on tracking down memory leaks? |
| 17:02.41 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.155) |
| 17:04.09 | pabelanger | russellb: yar! I sent an email to jpeeler this morning. |
| 17:04.11 | pabelanger | thanks |
| 17:04.24 | russellb | cool, he's out today, he'll probably get back to you tomorrow |
| 17:04.36 | pabelanger | ok, thanks for the heads up. |
| 17:17.35 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 17:25.23 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 18:01.08 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 18:04.49 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 18:18.01 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 18:19.26 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:19.26 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:41.29 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 18:41.29 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 18:41.59 | *** join/#asterisk-dev sgimeno (~chatzilla@83.46.36.105) |
| 18:56.40 | *** join/#asterisk-dev niekvlessert (~niek@92.70.112.34) |
| 18:57.10 | niekvlessert | hello! how can I make asterisk unresponsive to test my fix-unresponsiveness-script? |
| 18:57.26 | russellb | define unresponsive |
| 18:57.36 | niekvlessert | and I don't mean segfault manually by using kill -11 or something |
| 18:57.38 | russellb | it's heavily multithreaded ... |
| 18:57.46 | niekvlessert | well, so that the process is still running |
| 18:57.49 | niekvlessert | but it doesn't work |
| 18:58.00 | russellb | how do you detect that it doesn't work? |
| 18:58.03 | niekvlessert | ok, so you mean parts will remain working, others won't? |
| 18:58.03 | Qwell | suspend it |
| 18:58.30 | niekvlessert | right now: asterisk -rx "core show uptime" |
| 18:58.40 | niekvlessert | if that doesn't respond in 30 seconds, bam, restart |
| 18:58.53 | niekvlessert | qwell: how would i suspend it? |
| 18:58.53 | russellb | there are many things that could go wrong that won't be detected that way |
| 18:58.55 | Qwell | start Asterisk with -c, hit ctrl-Z |
| 18:58.59 | russellb | it's a non-trivial problem to solve |
| 18:59.08 | niekvlessert | russellb: thanks |
| 18:59.09 | niekvlessert | problem is |
| 18:59.14 | niekvlessert | we're running with a lot of users |
| 18:59.20 | niekvlessert | and today we had a segfault |
| 18:59.28 | niekvlessert | and safe_asterisk didn't work |
| 18:59.36 | niekvlessert | because the asterisk process wat still there |
| 18:59.44 | russellb | then it didn't seg fault :-) |
| 18:59.44 | Qwell | then it wasn't a segfault |
| 18:59.45 | niekvlessert | and asterisk -r didn't respond |
| 19:00.05 | niekvlessert | ok 2 at the same time, clearly i'm wrong :) |
| 19:00.10 | russellb | Qwell: stop being my echo today |
| 19:00.12 | niekvlessert | so what could that be then? |
| 19:00.17 | russellb | that sounds like a deadlock. |
| 19:00.29 | niekvlessert | argl.... i hate that word |
| 19:00.29 | Qwell | russellb: I was first this time ;p |
| 19:00.30 | leifmadsen | sounds like a deadlock |
| 19:00.31 | leifmadsen | damnit! |
| 19:00.35 | leifmadsen | late to the party |
| 19:00.43 | niekvlessert | ok |
| 19:00.49 | niekvlessert | so i know those are hard to fix |
| 19:00.52 | russellb | leaves this one to Qwell and leifmadsen |
| 19:01.01 | russellb | usually easier to fix than seg faults, actually |
| 19:01.17 | niekvlessert | but what would i have my script check to make sure it will get detected and gets things restarted? |
| 19:02.08 | russellb | CLI commands aren't a bad place to start, but you should probably go with "core show channels" if you're going to pick a single CLI command |
| 19:02.27 | russellb | that's going to hang on the vast majority of asterisk deadlock issues |
| 19:02.39 | Corydon76-lap | russellb: what's the use case for checking doing two SRV queries for the same record before the cache times out? Wouldn't a caching DNS server (as we recommend) negate the possibility of the record changing? |
| 19:02.43 | leifmadsen | niekvlessert: file an issue, and provide the following info: "core show locks" when it's in the state you described. Something like: asterisk -rx "core show locks" | tee /tmp/core-show-lock.txt. Then get the backtrace (make sure asterisk is compiled with DEBUG_THREADS to get the 'core show locks' output and DONT_OPTIMIZE for a good backtrace). Something like: gdb -se "asterisk" <pid of asterisk process> | tee / |
| 19:02.43 | leifmadsen | tmp/backtrace.txt. Run: bt, bt full, thread apply all bt |
| 19:03.03 | russellb | Corydon76-dig: the sort order will come back different if weights/priorities are the same |
| 19:03.20 | niekvlessert | leifmadsen: ok will do. we're running bristuff, those patches might cause it |
| 19:03.28 | niekvlessert | are those known to cause those issues? |
| 19:03.30 | russellb | yes. |
| 19:03.36 | niekvlessert | ok |
| 19:03.38 | russellb | and please don't report bugs to us with those patches in use ... |
| 19:03.43 | Corydon76-lap | russellb: but that behavior is a constant source of consternation. People would like the record to be consistent more often, not exploit its indeterminability |
| 19:03.53 | niekvlessert | then we'll use clean 1.4.26.2 |
| 19:04.03 | niekvlessert | with external audiocodes for pstn |
| 19:04.04 | russellb | that's how SRV works, they get randomized for load balancing purposes |
| 19:05.17 | Corydon76-lap | russellb: at the same time, people want the ordering to be consistent for an entire call, to ensure that a call that fails does not get retried on the same server |
| 19:05.49 | Corydon76-lap | s/want/expect/ |
| 19:06.03 | russellb | so then they wouldn't do the lookup twice then? |
| 19:06.13 | Corydon76-lap | I don't think they would |
| 19:06.27 | russellb | i don't see why allowing it is any kind of problem |
| 19:06.36 | russellb | and that makes it just like the other 2 nearly identical interfaces |
| 19:06.39 | Corydon76-lap | They'd only do the lookup twice if the query results weren't cached from the first query |
| 19:06.56 | Corydon76-lap | and in that case, get possibly inconsistent results, which is not what they expect |
| 19:07.02 | russellb | it's more functionality given the same interfaces |
| 19:07.18 | russellb | it _is_ expected, it's how SRV is defined to work if you do a lookup again |
| 19:07.20 | Corydon76-lap | Perhaps, but useless |
| 19:07.21 | kpfleming | who will answer the first bug report from a user who has a valid reason to do the lookup twice and the interface doesn't support it? |
| 19:07.46 | Corydon76-lap | kpfleming: I'm asking what is a valid reason for it? |
| 19:08.00 | kpfleming | because someone might want it, and it's not painful or harmful to provide it |
| 19:08.05 | russellb | yes. |
| 19:08.46 | Corydon76-lap | kpfleming: I'm looking at it from the perspective of, why make this more complicated than it needs to be? Why call two functions, when one will do? |
| 19:08.52 | russellb | it's an arbitrary and unnecessary limitation to take it away, and doesn't simplify the interface at all |
| 19:08.56 | kpfleming | because the other functions arelady work that way |
| 19:09.04 | kpfleming | and people will ask why not make the other ones work that way |
| 19:09.08 | kpfleming | since they have the same situation |
| 19:09.12 | russellb | and the 2 function approach is very explicit in how it works |
| 19:09.23 | russellb | there is no implicit lookup being done "sometimes" |
| 19:09.27 | Corydon76-lap | kpfleming: I was proposing making the other functions also more simple |
| 19:09.40 | kpfleming | that's a lot of work for no visible gain |
| 19:09.52 | russellb | and removing functionality (multiple lookups on a channel) |
| 19:10.04 | Corydon76-lap | It's not a lot of work, and simplifying it for new users is a gain |
| 19:10.04 | kpfleming | i've never heard anyone complain about having to have another line in their dialplan to do the lookup |
| 19:10.27 | kpfleming | put it on the list then, if it gets high enough in priority it could get done |
| 19:10.32 | russellb | and it won't |
| 19:10.37 | Corydon76-lap | Heh |
| 19:10.44 | kpfleming | in the meantime, new interfaces that logically provide a similar mechanism should work the same way |
| 19:10.46 | Corydon76-lap | Unless I do it in my spare time |
| 19:10.57 | leifmadsen | the review will never pass! |
| 19:10.58 | leifmadsen | :) |
| 19:11.03 | russellb | pretty much :-p |
| 19:11.04 | Corydon76-lap | leifmadsen: :-P |
| 19:11.26 | Corydon76-lap | leifmadsen: Watch me. I already have a method of coding around Russell's objection. |
| 19:12.35 | russellb | you really just want to piss me off, don't you |
| 19:12.47 | Corydon76-lap | Nope, I want to make the dialplan easier to use |
| 19:13.04 | Corydon76-lap | Pissing you off does not enter into my calculations |
| 19:13.07 | kpfleming | so if this easier, why isn't it done this way in every other programming language? |
| 19:14.04 | Corydon76-lap | kpfleming: Actually, it usually is, with the difference that you choose the name for your resultset, instead of it being tagged with an arbitrary identifier |
| 19:14.06 | kpfleming | honestly, i don't even see how this could be easier, but since there is a high risk of being completely annoyed by the entire proposal, i'll just go back to my cave and work on other stuff |
| 19:14.19 | seanbright | heh |
| 19:14.51 | russellb | cartwheels away to finish packing |
| 19:14.54 | Corydon76-lap | Right, I think you'll be fine with the result, once I have it encoded next weekend |
| 19:15.23 | Corydon76-lap | Be complicated or simple, as you wish, and everybody wins |
| 19:16.36 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:21.58 | *** join/#asterisk-dev dsfr (~dsfr@pdpc/sponsor/digium/dsfr) |
| 19:25.39 | niekvlessert | one more question |
| 19:25.51 | niekvlessert | when there's a deadlock and i use core show channels, what will happen? |
| 19:25.58 | niekvlessert | will core show channels be unresponsive? |
| 19:26.01 | leifmadsen | output will happen on the screen |
| 19:26.11 | niekvlessert | what kind of output |
| 19:26.13 | Corydon76-lap | depends upon where the deadlock has occurred |
| 19:26.21 | leifmadsen | if the system is not deadlocked to the point that console output is not possible |
| 19:26.30 | Corydon76-lap | There's no one master lock in Asterisk through which all output passes |
| 19:26.32 | leifmadsen | niekvlessert: a list of held locks I believe |
| 19:26.47 | russellb | most deadlocks involve a channel, though, and if that happens, the command will hang |
| 19:26.53 | Corydon76-lap | leifmadsen: he said 'core show channels' not 'core show locks' |
| 19:27.05 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 19:27.05 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 19:27.10 | leifmadsen | ah, my brain read 'locks' |
| 19:27.26 | niekvlessert | russellb: thanks, that's what i meant :) |
| 19:27.33 | Corydon76-lap | leifmadsen: I figured that out. :-) |
| 19:27.34 | niekvlessert | so i can test my script using time out |
| 19:28.58 | niekvlessert | ok thanks! |
| 19:29.10 | niekvlessert | will implement those scripts and will start using non-bristuff asterisk |
| 19:29.12 | niekvlessert | see you!! |
| 19:46.59 | *** join/#asterisk-dev FlaPer87 (~FlaPer87@unaffiliated/flaper87) |
| 19:47.15 | FlaPer87 | erm guys, https://issues.asterisk.org/ is giving me some mysql connection problems |
| 19:47.25 | kpfleming | yes, it was very slow for a few minutes |
| 19:47.28 | kpfleming | should be better now |
| 19:48.00 | kpfleming | or not... will investigate |
| 19:48.57 | kpfleming | it's back |
| 19:54.49 | FlaPer87 | russellb: https://issues.asterisk.org/view.php?id=17170 as promised ;) |
| 19:57.42 | russellb | it'll have to be attached as a patch so it is associated with a contributor license agreement |
| 19:57.50 | russellb | also, make sure it's compatible with svn trunk |
| 19:57.56 | russellb | and thanks for the contribution :-) |
| 19:59.05 | FlaPer87 | russellb: ok, I'll attach it as a patch and I'll test it with svn trunk =D |
| 19:59.22 | FlaPer87 | russellb: and np, It's be a pleasure, I hope to do more ;) |
| 20:04.58 | FlaPer87 | russellb: ok, I attached it as patch now svn test |
| 20:05.01 | FlaPer87 | =) |
| 20:20.41 | *** join/#asterisk-dev michaely (~michaely@CPE-124-190-32-229.sdcz1.lon.bigpond.net.au) |
| 20:20.46 | seanbright | tzafrir_laptop: aren't [\d.] and . equivalent? |
| 20:23.27 | tzafrir_laptop | seanbright, no. a '.' is not special inside [] |
| 20:24.37 | *** part/#asterisk-dev michaely (~michaely@CPE-124-190-32-229.sdcz1.lon.bigpond.net.au) |
| 20:24.44 | seanbright | ahh |
| 20:24.54 | seanbright | makes sense |
| 20:59.24 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 20:59.24 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 22:25.22 | Qwell | Would it be expected that Asterisk could load without any config files whatsoever? |
| 22:26.08 | Qwell | I wouldn't have expected so, but apparently as of at least 1.6.0, that was the case. |
| 22:26.24 | Deeewayne | I think I've loaded asterisk w/o any config files and it was 1.6.0 |
| 22:26.38 | Qwell | Deeewayne: yeah, it worked on 1.6.0 |
| 22:27.01 | Qwell | haven't tested 1.6.1, but 1.6.2 does not work. It requires indications.conf to exist |
| 22:27.36 | Qwell | which really screws with the FreePBX installation. It installs the Asterisk config files, but it requires that Asterisk be running. |
| 23:49.57 | russellb | Qwell: but it would break most modules |
| 23:49.59 | russellb | Qwell: I guess we could make indications not required, but spit out a huge ERROR (as long as a reload can load them later) |
| 23:49.59 | russellb | and also make sure we log an ERROR when code tries to play an indication and indications aren't loaded |