| 15:59.51 | *** join/#asterisk-bugs infobot (i=ibot@rikers.org) |
| 15:59.51 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://issues.asterisk.org/ -=- http://asterisk.org/developers/bug-guidelines - Discussions not related to reported issues should be in #asterisk -=- Test bugs marked Ready For Testing! -=- http://xkcd.org/583/ |
| 16:16.25 | *** join/#asterisk-bugs zeroHalo (n=zeroHalo@173.13.92.17) |
| 17:07.24 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 17:19.45 | *** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 17:28.42 | *** join/#asterisk-bugs philippel (n=p_lindhe@pool-98-111-69-201.sttlwa.fios.verizon.net) |
| 17:29.01 | philippel | leifmadsen ping |
| 17:29.20 | philippel | or someone else ping |
| 17:29.27 | philippel | m15168 |
| 17:29.32 | MuffinMan | [assigned] [Asterisk] Applications/app_queue 0015168: [patch] Add ability to use extension state as well as device state when adding queue memebers reported by p_lindheimer (Karma: +4.25) https://issues.asterisk.org/view.php?id=15168 |
| 17:29.39 | philippel | question on that |
| 17:29.42 | philippel | I noticed: |
| 17:29.57 | philippel | lmadsen Target Version => 1.6.x Version Tracker |
| 17:30.04 | philippel | I am wondering if it is working its way in |
| 17:30.15 | philippel | I have changed to FreePBX to take advantage of that if it is |
| 17:30.38 | philippel | mainly, I need to know if my proposed format of HINTnnn in my patch will be adopted or something else |
| 17:31.10 | philippel | since - if htis is going to get in in some form, I would like to role my chanes into FreePBX to take advantage of it at the right * version level |
| 17:41.19 | leifmadsen | philippel: that means it is marked as a feature for some future version of 1.6.x, but has not been assigned to a specific version |
| 17:41.24 | leifmadsen | i.e. priority is fairly low |
| 17:41.40 | leifmadsen | however, people testing and reporting back could help move it along |
| 17:42.13 | leifmadsen | typically open issues with the most community involvement get moved along faster than those that simply have to wait for Digium developers -- bugs are more important than features in most cases |
| 17:46.05 | philippel | leifmadsen ok - and of course I don't know how much help the 1.4 patch will have on that |
| 17:46.25 | philippel | leifmadsen can you tell me - from what I have in the ticket, would you forsee the format changing when it does get implemented? |
| 17:47.01 | philippel | the details of implementation are not that important but if I put it into FreePBX since the 1.4 patch is at least there it will bring awareness |
| 17:47.12 | leifmadsen | I haven't looked at that issue closely yet -- give me a little bit to get to it |
| 17:47.13 | philippel | so I wouldn't want it to turn aroudn and change |
| 17:47.15 | leifmadsen | places issue into queue |
| 17:47.16 | Corydon76-lap | If any of us could foresee that, we'd be stock market millionaires... |
| 17:47.27 | leifmadsen | Corydon76-lap: speak for yourself! |
| 17:47.29 | leifmadsen | :) |
| 17:47.38 | philippel | member => Local/3000@default,0,John Smith,HINT:3000@default |
| 17:47.41 | philippel | simply that |
| 17:47.47 | leifmadsen | bascially Corydon76-lap is saying anything is possible until it isn't |
| 17:47.47 | philippel | e.g. HINT:nnnn |
| 17:47.56 | philippel | is then treated as a hint instead of a device |
| 17:48.12 | philippel | similar in the call to AddQueueMembers |
| 17:48.23 | Corydon76-lap | Is there a good reason for it to be all uppercase? |
| 17:48.36 | Corydon76-lap | That's one change I could see making |
| 17:48.36 | philippel | Corydon76-lap no - I just did it that way |
| 17:48.57 | philippel | I suspect I probably use case insensitve comaprison in my patch |
| 17:49.00 | philippel | I would have to check |
| 17:49.16 | Corydon76-lap | That would make good sense |
| 17:49.32 | philippel | let's just say if I don't, it could be implemented that way |
| 17:49.41 | philippel | and from that perspecitve, no harm if I generate it in all upper case |
| 17:50.02 | philippel | as long as the final implementation doesn't end up implementing it in lower case only :) |
| 17:50.07 | philippel | or something different |
| 17:50.30 | Corydon76-lap | I suspect whether a ':' or a '/' occurs first in the string determines which type it is... |
| 17:50.35 | philippel | + } else if (!strncasecmp(interface,"HINT:",5)) { |
| 17:50.55 | philippel | I did the : to mimic the custom device type scenario |
| 17:51.01 | philippel | to differentiate it from a real device |
| 17:51.04 | Corydon76-lap | Well, other than spacing guidelines. |
| 17:51.09 | philippel | above - that is case insensitve right ? |
| 17:51.15 | Corydon76-lap | Yes |
| 17:51.28 | philippel | has done very little C coding in years, just occaisional * patches |
| 17:51.44 | Corydon76-lap | Yeah, "hint" is fine |
| 17:52.30 | philippel | ok - well I'll go and implement it in FreePBX then, with a config flag for now and then when we see what version of 1.6 it ends up in, I can make it automatic when that version is installed |
| 17:52.31 | Corydon76-lap | since I think we already have meetme:confroom |
| 17:53.50 | philippel | Corydon76-dig yeah, similarly, any custom device state, parking state, etc is in that format |
| 17:54.52 | Corydon76-lap | philippel: is it implemented in a similar way to those custom device states or as a hack? |
| 17:55.06 | philippel | I did it in 1.4 |
| 17:55.10 | philippel | and it is not the same |
| 17:55.17 | philippel | since it is a hint, it is a bit more complex |
| 17:55.34 | Corydon76-lap | It probably should be implemented in a similar way, so that it can be used in other places |
| 17:55.39 | philippel | it required special case code to handle it as a hint |
| 17:55.48 | philippel | I don't think it can |
| 17:55.53 | philippel | at least not in 1.4 |
| 17:56.05 | philippel | the custom devices are just treated as a device as they act like a device |
| 17:56.07 | Corydon76-lap | Well, it's not a candidate patch for 1.4, anyway |
| 17:56.15 | philippel | where as a hint is a collection of devices, so to speak |
| 17:56.28 | philippel | I know it is not for 1.4, it's just the only place I implemented it |
| 17:56.38 | Corydon76-lap | A hint is an extra level of indirection, just like the Local channel |
| 17:56.43 | philippel | there was talk that the event system in 1.6 might lend itself to a different implementation |
| 17:56.53 | philippel | but I recall there wre some potential issues there also in some discussions |
| 17:57.00 | philippel | Corydon76-lap exactly |
| 17:57.06 | philippel | on the extra level of indirection |
| 17:57.16 | Corydon76-lap | can haz meeting, kthx |
| 17:57.28 | philippel | where as the custom device states are already 'transparently' handled like other devices |
| 17:57.31 | philippel | ok - thanks |
| 17:57.46 | philippel | I'll assume for now that format and hope it stays that way :) |
| 18:21.28 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 18:24.38 | *** join/#asterisk-bugs bbryant (n=brett@68.208.65.50) |
| 18:24.38 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 19:27.32 | *** join/#asterisk-bugs Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 19:36.57 | *** part/#asterisk-bugs zeroHalo (n=zeroHalo@173.13.92.17) |
| 19:46.17 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:46.17 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 20:03.43 | *** join/#asterisk-bugs mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 20:03.57 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 20:03.57 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 20:11.09 | lasko | Is the AJAM interface known to ber usable on 1.6? When I attempt to use the instructions found on voip-info I receive a segmentation fault while using a url to login to the manager. |
| 20:11.55 | Qwell | lasko: can you give an example? |
| 20:12.12 | lasko | example: http://localhost:8088/asterisk/rawman?action=status |
| 20:12.23 | lasko | which producesL: *CLI> Segmentation fault |
| 20:12.29 | Qwell | that crashes it? nothing before it? |
| 20:12.33 | lasko | *nod* |
| 20:12.37 | Qwell | what version of Asterisk specifically? |
| 20:12.52 | lasko | this is currently on trunk |
| 20:12.57 | Qwell | sec |
| 20:12.57 | lasko | will be testing on 1.6.1 soon |
| 20:13.24 | Qwell | lemme see if I can reproduce. If I can, that's err...kinda a problem. :) |
| 20:13.34 | lasko | hehe yup |
| 20:14.36 | lasko | The only command I've been able to be successful with is: http://localhost:8088/asterisk/static/ajamdemo.html (This however does produce a segmentation fault, but the page loads) The console produces several hundred lines of "[Aug 24 13:13:59] WARNING[32122]: http.c:415 ast_http_send: fwrite() failed: Success" |
| 20:14.55 | Qwell | k |
| 20:15.19 | putnopvut | oh gotta love those failed: Success messages... |
| 20:16.18 | Corydon76-lap | leifmadsen: ping |
| 20:20.54 | Qwell | sure enough... |
| 20:21.04 | Qwell | lasko: please open a bug on issues.asterisk.org |
| 20:21.38 | lasko | will do |
| 20:21.38 | lasko | thanks |
| 20:25.19 | lasko | Qwell: What category would this issue be best suited for when reporting it? |
| 20:25.55 | Qwell | manager |
| 20:26.00 | lasko | *nod* |
| 20:26.26 | putnopvut | was about to say Core/HTTP... |
| 20:26.36 | putnopvut | But manager works, too :) |
| 20:26.38 | Qwell | I suspect it's not just http causing it |
| 20:27.16 | Qwell | we can test that theory, actually |
| 20:28.52 | seanbright | if (fwrite(buf, len, 1, ser->f) != len) { |
| 20:28.55 | seanbright | shouldn't that be: |
| 20:28.58 | seanbright | if (fwrite(buf, len, 1, ser->f) != 1) { |
| 20:29.00 | seanbright | ? |
| 20:30.51 | seanbright | yes, i am right. as usual. |
| 20:31.07 | lasko | lol |
| 20:31.25 | putnopvut | ha, that's a silly coding mistake. |
| 20:32.07 | Corydon76-lap | or just swap 1 and len in the arguments |
| 20:33.38 | seanbright | true |
| 20:35.09 | Corydon76-lap | If you do change it to ... != 1, please add a comment which says "1 obj of len size" |
| 20:35.45 | putnopvut | It's little inconsistencies like this difference between write and fwrite that annoy me sometimes. |
| 20:36.38 | Corydon76-lap | Clearly, we need ast_read and ast_write... oops, we have them already. |
| 20:36.59 | putnopvut | we don't have ast_fwrite though :) |
| 20:37.12 | Corydon76-lap | ast_fh_write, perhaps |
| 20:37.27 | putnopvut | fh == file handle? |
| 20:37.48 | Corydon76-lap | Yep |
| 20:39.11 | lasko | Qwell: Submitted bug id #0015774 |
| 20:41.11 | *** join/#asterisk-bugs bbryant (n=brett@68.208.65.50) |
| 20:41.11 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 20:42.56 | Qwell | looks like it's only an issue in trunk, at least |
| 20:43.54 | Corydon76-lap | adds karma to seanbright for finding that |
| 20:44.07 | seanbright | that wasn't the crash i don't think |
| 20:44.14 | seanbright | that was just a typo |
| 20:44.21 | Corydon76-lap | but it was annoying |
| 20:44.59 | seanbright | indeed. |
| 20:45.57 | Qwell | his problem is from the new security event stuffs |
| 20:46.18 | Qwell | tcptls_session is NULL and being dereferenced |
| 20:46.20 | putnopvut | orly |
| 20:46.31 | Qwell | (I assume mansession_get_transport would cause the same crash) |
| 20:47.23 | Qwell | however... root cause my be elsewhere, since I can't make it happen with a 5038 manager connection |
| 21:15.03 | leifmadsen | Corydon76-lap: pong |
| 21:15.29 | Corydon76-lap | leifmadsen: If you have time for testing, AST-228 needs some |
| 21:16.33 | Corydon76-lap | If not, I'll run some testing tomorrow, when I'm back in my office/lab |
| 21:19.11 | leifmadsen | Corydon76-lap: ok sounds good -- I'm currently rebuilding my development cluster, so if I get it done in a reasonable period of time I'll get on that! |
| 21:46.27 | *** join/#asterisk-bugs itamarjp (n=itamar@189-015-69-079.xd-dynamic.ctbcnetsuper.com.br) |