| 00:02.26 | Corydon76-dig | Qwell: so now you've got massive upper body strength? |
| 00:24.49 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:24.49 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 01:25.33 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:25.33 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 01:57.05 | *** join/#asterisk-bugs nybble (n=nybble@about/apple/performa/nybble) |
| 04:02.39 | *** join/#asterisk-bugs xxxbuntu (n=ben@c-76-110-237-202.hsd1.fl.comcast.net) |
| 05:24.15 | *** join/#asterisk-bugs implicit_ (i=implicit@gateway/tor/x-8bbf9666b408eb1c) |
| 09:20.41 | *** join/#asterisk-bugs mbranca (i=daemon@mi-gw1.voismart.net) |
| 10:08.33 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 11:06.12 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:15.36 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 11:15.36 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 11:18.51 | *** join/#asterisk-bugs Victor_Yure (n=aaa@postfix.tradein.com.br) |
| 12:08.24 | *** join/#asterisk-bugs mbranca (i=daemon@mi-gw1.voismart.net) |
| 13:17.14 | *** join/#asterisk-bugs jsmith (n=jsmith@68-247-236-122.area3.spcsdns.net) |
| 13:17.14 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 14:06.49 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:06.49 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 14:12.17 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 14:32.34 | *** join/#asterisk-bugs mbranca (i=daemon@mi-gw1.voismart.net) |
| 15:04.33 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:29.09 | *** join/#asterisk-bugs jsmith (n=jsmith@68-247-236-122.area3.spcsdns.net) |
| 15:29.09 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 15:36.08 | *** join/#asterisk-bugs Laureano (n=chatzill@200.59.172.38) |
| 15:55.53 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:55.53 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 16:02.41 | *** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-c531125a13e2735c) |
| 16:02.42 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:11.14 | putnopvut | M11636 |
| 16:11.15 | MuffinMan | [closed] [Asterisk] Channels/General 0011636: many retries to lock channels when using attended transfer reported by liorm http://bugs.digium.com/view.php?id=11636 |
| 16:11.49 | putnopvut | russellb: I'm not sure if you noticed, but the reporter did mention a "big delay" so there actually was a problem there. |
| 16:13.40 | russellb | yeah, and spewing output to logs on every attempt to lock a mutex causes a delay :) |
| 16:14.35 | putnopvut | heh. |
| 16:14.43 | putnopvut | good point. |
| 16:35.35 | *** join/#asterisk-bugs eliel (n=chatzill@200.59.172.38) |
| 16:54.47 | file | congrats to those who have gotten the bug count down this low |
| 16:54.53 | file | mad props |
| 16:55.50 | *** topic/#asterisk-bugs by russellb -> Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Overall issue count: < 360 -=- Monitor new reports in #asterisk-commits |
| 16:56.54 | *** join/#asterisk-bugs nybble (n=nybble@about/apple/performa/nybble) |
| 17:33.20 | file | few more and we will be under 350 |
| 18:07.34 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 18:08.57 | Corydon76-dig | We're at 300 Asterisk bugs |
| 18:09.29 | Corydon76-dig | which is the only pool I'm working on |
| 18:11.53 | lmadsen | some might call you a cheater |
| 18:11.56 | lmadsen | :) |
| 18:14.33 | Corydon76-dig | lmadsen: what, work? |
| 18:15.14 | lmadsen | Corydon76-dig: I do un-working very well :D |
| 18:26.51 | *** join/#asterisk-bugs Victor_Yure (n=aaa@postfix.tradein.com.br) |
| 18:45.52 | *** join/#asterisk-bugs implicit (i=implicit@gateway/tor/x-7ceb94ec4ff6936c) |
| 18:45.52 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 19:59.39 | putnopvut | M11535 |
| 19:59.40 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0011535: [patch] chan_sip can cause 100% CPU usage on illegal listening IP reported by one47 http://bugs.digium.com/view.php?id=11535 |
| 20:00.03 | putnopvut | file: I reproduced this and have confirmed that the patch fixes the problem. Do you know of any way this could cause any unforeseen problems? |
| 20:00.12 | putnopvut | Otherwise, I'll just go ahead and get this committed as is. |
| 20:00.43 | file | let's see here... |
| 20:01.51 | file | there is one thought I have |
| 20:02.36 | putnopvut | Is your thought difficult to place into words? |
| 20:02.41 | file | I don't know how the I/O context stuff will perform if you have no file descriptors in it |
| 20:03.09 | russellb | heh, poll nothing and return immediately probably |
| 20:05.05 | file | well... there is a trick you can use on some platforms |
| 20:05.16 | file | which might accidentally get used in that scenario, but it's bad |
| 20:06.07 | file | putnopvut, that is the only thing I worry of with that |
| 20:06.47 | putnopvut | Just the case of having no fd's? |
| 20:07.05 | putnopvut | What are the consequences of that? |
| 20:07.21 | file | ast_io_wait doing a poll on ... nothing ... which is bad |
| 20:07.36 | file | and on certain platforms could still cause 100% CPU usage |
| 20:07.54 | putnopvut | Why is doing a poll on nothing bad? |
| 20:08.17 | putnopvut | I guess I should man poll to see what happens if no fd's are set. |
| 20:08.44 | file | on Linux it's fine to do it, it basically waits for a signal... sort of a mehish way of doing a pthread condition |
| 20:08.54 | file | on OSX at least you can't do it, poll won't let you and it returns immediately |
| 20:09.21 | putnopvut | So should a condition be added to ast_io_wait to not poll if there are no fd's to actually poll? |
| 20:10.11 | file | then the monitor thread will go into a loop again |
| 20:11.44 | *** join/#asterisk-bugs kratzers (n=kratzers@martha.pa.net) |
| 20:12.00 | *** part/#asterisk-bugs kratzers (n=kratzers@martha.pa.net) |
| 20:52.51 | *** join/#asterisk-bugs matsk (n=mk@83.233.97.210) |
| 21:09.33 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 21:50.30 | russellb | 351 ... |
| 21:52.00 | putnopvut | M11520 |
| 21:52.01 | MuffinMan | [new] [Asterisk] Resources/res_features 0011520: [patch] Re-enable one-touch parking on timeout park recall reported by pliew http://bugs.digium.com/view.php?id=11520 |
| 21:52.29 | putnopvut | I kind of feel like just committing that patch as is, but a part of me says to be more thorough and only do that if one-touch parking was enabled prior to parking. |
| 21:53.13 | file | there is a way to do that... |
| 21:53.41 | file | well, not a way... the capability to make it happen is there now that I think about it |
| 21:53.45 | putnopvut | Check the bridge_config? |
| 21:54.02 | file | doesn't work like that. |
| 21:54.14 | file | you don't have access to 'dat info... |
| 21:54.24 | putnopvut | Dag, yo! |
| 21:54.33 | putnopvut | So what info do I hax axxess tu? |
| 21:55.03 | file | WELL |
| 21:55.21 | file | you could theoretically use a datastore to store the info... |
| 21:55.54 | putnopvut | I guess a question would be how critical is it to know if one-touch parking was enabled before? |
| 21:56.04 | russellb | very critical |
| 21:56.11 | file | not just in the scope of parking |
| 21:56.12 | russellb | if you enable something that wasn't enabled before, people get very pissed |
| 21:56.14 | file | but transfers as well |
| 21:56.19 | file | yes |
| 21:56.19 | russellb | and consider it a security issue ... |
| 21:56.28 | file | and then you try to disable it... |
| 21:56.32 | file | and the people who used it get pissed |
| 21:56.34 | russellb | moreso in the case of transfers than parking, but still |
| 21:56.54 | russellb | it is an issue that really needs to get solved, not just for one touch parking, but for all call feature settings |
| 21:57.08 | file | yeah, and I think the datastore idea could solve it |
| 21:57.17 | russellb | sounds like it could work ... |
| 21:57.22 | russellb | but we're talking pretty high level, heh |
| 21:57.27 | russellb | i haven't looked at it in a while |
| 21:57.45 | putnopvut | So what all features need to be considered for reenabling? |
| 21:57.55 | file | WELL |
| 21:58.10 | file | the generally premise that people have is anything they enable in the Dial() line still works when it's picked up |
| 21:58.14 | file | generally? general |
| 21:59.36 | putnopvut | So in other words the datastore in question needs to store options defined in Dial() (or Queue() potentially). |
| 22:03.14 | russellb | yeah, any bridge features that get stored in the bridge config struct, i think |
| 22:03.51 | putnopvut | What about other dialling options? I don't think all of them are stored in the bridge config struct. |
| 22:04.17 | putnopvut | Or are those irrelevant once the call has progressed to this stage? |
| 22:04.19 | russellb | the other ones are relevant |
| 22:04.23 | russellb | aren't |
| 22:04.30 | putnopvut | Gotcha. |
| 22:05.03 | putnopvut | So it's a matter of creating the datastore for the channel and storing the bridge_config structure there. |
| 22:05.22 | russellb | maybe :) |
| 22:05.31 | putnopvut | Got a different idea? |
| 22:05.47 | russellb | no |
| 22:05.53 | russellb | i just haven't looked ... |
| 22:05.57 | file | he just can't give an accurate yes or no |
| 22:05.59 | putnopvut | heh, I thought you had something up your sleeve :) |
| 22:06.01 | russellb | i know the features are caller vs. callee ... |
| 22:06.09 | russellb | you might need to know which set of features apply to your channel ... |
| 22:06.15 | russellb | just details like that that i'm not sure about |
| 22:06.17 | russellb | i have no tricks. |
| 22:06.32 | file | do you have muffins? |
| 22:06.40 | putnopvut | I have only trick muffins. |
| 22:06.41 | russellb | not currently |
| 22:06.53 | putnopvut | They explode when you look at them. |
| 22:07.00 | file | that's dangerous |
| 22:07.02 | file | have you been sued yet? |
| 22:07.10 | putnopvut | Yeah, just be sure to blindfold yourself before eating them. |
| 22:07.22 | putnopvut | I haven't been sued because I have never distributed them. |
| 22:07.25 | russellb | i am disappearing for now |
| 22:08.57 | lmadsen | I'm going off to play a video game for a bit, then family visiting |
| 22:09.25 | jsmith | lmadsen: Sure, just wander off while I'm still stuck at 80% brainpower... |
| 22:09.38 | lmadsen | jsmith: I told you to go back to 100% a while ago :) |
| 22:09.45 | lmadsen | guess you missed it as you were at 80% |
| 22:09.48 | jsmith | lmadsen: Yeah, but you didn't *mean* it ;-) |
| 22:09.54 | lmadsen | sure I did! :) |
| 22:10.00 | lmadsen | I mean everything, except for the things I don't |
| 22:10.07 | lmadsen | oh -- looks like you got your gps back? |
| 22:10.39 | jsmith | Uh, yeah... didn't you get my message? |
| 22:17.55 | lmadsen | got an email a couple days ago that confirmed the delivery -- got no email from you |
| 22:20.49 | jsmith | I sent you either a text message to your cell phone or an email... I can't remember which |
| 22:20.57 | jsmith | It got here last Saturday |
| 22:21.08 | jsmith | And the delivery person was *very* friendly |
| 22:22.35 | file | really, or was that sarcasm? |
| 22:22.41 | file | I can't tell with you. |
| 22:23.26 | jsmith | That's for me to know and for you to find out |
| 22:23.33 | jsmith | But in this case, I'm being serious |
| 22:23.48 | file | who delivered it? O.o |
| 22:23.52 | jsmith | I figured the delivery person would be grumpy with the holidays and all... |
| 22:23.53 | jsmith | DHL |
| 22:24.03 | file | ah yes |
| 22:58.02 | lmadsen | jsmith: he was probably drinking :) |
| 23:00.59 | putnopvut | Drinking egg nog is appropriate around Christmas time. |
| 23:01.07 | putnopvut | Even for a DHL driver. |