| 01:03.25 | usrbinfoobar | hey guys |
| 03:56.30 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 03:56.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:11.15 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 04:39.24 | *** join/#asterisk-dev irroot (~irroot@197.174.69.7) |
| 05:34.36 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 18:09.01 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 18:09.01 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://xkcd.com/303/ |
| 18:09.06 | sruffell | looks |
| 18:09.17 | seanbright | this is a fairly old version of dahdi trunk, however - r9073 |
| 18:09.49 | seanbright | that message is spamming the hell out of my messages file |
| 18:09.57 | seanbright | which i assume is a bad thing |
| 18:10.14 | sruffell | yesâ¦and you're probably not getting any new transcoder channels up? |
| 18:10.21 | seanbright | seems that way |
| 18:10.29 | seanbright | well, it's sporadic |
| 18:10.29 | sruffell | that warning isn't in the trunkâ¦.hmmâ¦.checking diffs... |
| 18:10.50 | seanbright | i see errors in the asterisk CLI for some time, and then i don't for some time |
| 18:10.53 | seanbright | rinse and repeat |
| 18:19.12 | sruffell | I don't see any changes since then on the wctc4xxp that would account for that.... |
| 18:19.31 | sruffell | https://gist.github.com/1147352 |
| 18:19.56 | sruffell | ^^^ how I get the summary of changes that touched that file between the versions. |
| 18:21.14 | seanbright | so will unloading and reloading dahdi fix it or do i need a full reboot? |
| 18:21.53 | sruffell | If you update the the latest version of DAHDI you'll get a better error message. |
| 18:22.06 | sruffell | reloading DAHDI will reset the firmware on the transcoder. |
| 18:23.01 | sruffell | https://gist.github.com/sruffell/dahdi-linux/blob/master/drivers/dahdi/wctc4xxp/base.c#L1112 <â contains the error code from the firmware now. |
| 18:23.20 | seanbright | 2.4.1.2 far enough or would you recommend 2.5.0? |
| 18:24.57 | sruffell | 2.4.1.2 should be far enough, but I always appreciate it when people run the latest. |
| 18:25.03 | sruffell | :0 |
| 18:25.20 | sruffell | https://gist.github.com/sruffell/dahdi-linux/blob/ba5a68f6885e3fa80b3eba603311d8b797879dc9/drivers/dahdi/wctc4xxp/base.c#L1132 <â same function in the version that you're running. You're hitting that WARN_ON |
| 18:25.42 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 18:25.42 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 18:26.38 | seanbright | gotcha |
| 18:27.03 | seanbright | but if i am reading you correctly, upgrading will not fix this issue, it will just make tracking down the actual problem easier |
| 18:27.15 | sruffell | That is my best guess...yes. |
| 18:27.39 | seanbright | ok, great |
| 18:27.41 | seanbright | thank you sir |
| 18:27.48 | sruffell | no, thank you. |
| 18:27.54 | seanbright | heh |
| 18:55.05 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 19:05.00 | pabelanger | Hmm, I think I maybe did something wrong with my commit message this morning |
| 19:05.04 | pabelanger | ASTERISK-18270 is still not closed |
| 19:29.23 | JunK-Y | Kobaz: nice, link? |
| 19:35.08 | kpfleming | pabelanger: maybe not... we've been discussing this for a couple of weeks now. if ASTERISK-18270 is linked to an internal time-tracking issue, it can't be closed until the time-tracking issue is closed... and that's a catch-22, because it can't be closed until the commits are completed |
| 19:35.22 | kpfleming | so for now... just be patient, and help us redesign the workflows to not have deadlocks in them |
| 19:37.01 | pabelanger | kpfleming: ya, I was aware of that issue, however this specific issue does not have a dependency on a clone; I should have said that. For now, I assume it is safe to manually close it? |
| 19:37.33 | kpfleming | yes |
| 19:42.17 | kpfleming | pabelanger: i don't see any obvious reason why that issue didn't get closed... the commit message appears to be formatted properly |
| 19:44.21 | *** join/#asterisk-dev oej (~olle@195.41.130.3) |
| 19:44.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:53.21 | JonathanRose | Hey, I've got a questino on ASTERISK-18067. In Asterisk 1.4, sip peers with mailbox set to multiple boxes receive an mwi with a combined count of all voicemails from all mailboxes they are assigned. In 1.8, they only receive a full count from the mailbox that they have the most recent message from. Which of these is the correct behavior? |
| 19:54.21 | sruffell | tzafrir: https://github.com/sruffell/dahdi-linux/commit/9b40c7b65da90c spams "bad sigtype" when running genconf.... |
| 19:54.37 | sruffell | â¦need to fix those drivers so that the "probing" isn't necessray.... |
| 19:57.30 | tzafrir | sruffell, demote that notice to a debug message for now? |
| 19:57.44 | sruffell | cool..that's what I was thinkingâ¦I'll make that change. |
| 19:58.59 | kpfleming | JonathanRose: that's a regression... the SIP NOTIFY should summarize the message counts for all subscribed mailboxes |
| 19:59.17 | JonathanRose | Yay, regression within regression. |
| 20:00.19 | kpfleming | it's actually possible for the NOTIFY to include message counts for each mailbox individually, but that would be a new feature :-) |
| 20:04.36 | JonathanRose | Well, as it is, ASTERISK-18067 is a blocker and while this new thing is a regression, it's almost trivial due to the way it regressively behaves. Should I go ahead and just tackle this one as is and fix the MWI being wrong later? |
| 20:05.16 | JonathanRose | In fact, it's teetering on "That's not a bug, that's a feature!" territory. |
| 20:07.23 | kpfleming | JonathanRose: i'm confused. what is 'this new thing'? |
| 20:08.03 | JonathanRose | Well, not new as much as newly discovered. |
| 20:08.14 | JonathanRose | The simple fact that it's giving the wrong mwi. |
| 20:08.44 | kpfleming | so now you are talking about ASTERISK-15479 |
| 20:09.01 | JonathanRose | I'm not aware of ASTERISK-15479 |
| 20:09.11 | kpfleming | it's the issue linked to from ASTERISK-18067 |
| 20:09.20 | kpfleming | and appears to be describing the identical problem |
| 20:09.34 | kpfleming | well... a closely related problem |
| 20:11.23 | JonathanRose | I'll go ahead and checkout the patch in there. |
| 20:12.34 | kpfleming | so yes... for both of those, the proper behavior is for the phone to be notified of the message counts for all subscribed mailboxes as if they were a combined mailbox |
| 20:14.59 | kpfleming | i'm quite disturbed that ASTERISK-15479 has been open for more than a year, when it was very clearly a regression and had a patch attached. that's a serious breakdown of our issue handling right there. |
| 20:19.39 | mjordan | anyone know how to link two different diffs from two different branches into one review on ReviewBoard? |
| 20:19.57 | mjordan | in this case, its testsuite + 1.8 |
| 20:20.10 | kpfleming | i don't believe you can |
| 20:20.19 | kpfleming | the 'base' for a diff in ReviewBoard can only point to one place |
| 20:20.30 | kpfleming | Crucible can do that, though :-) |
| 20:21.18 | kpfleming | unfortunately the 'asterisk' repo isn't available in crucible right now, i started it reindexing on friday and it's not done (or really even close to done) |
| 20:21.50 | mjordan | well, +1 to Crucible then |
| 20:22.47 | kpfleming | yes... we've been using that feature heavily for asterisk scf, because reviews frequently contain content from multiple repos |
| 20:23.06 | kpfleming | for now, though, you can just use ReviewBoard and setup two reviws |
| 20:23.10 | kpfleming | s/reviws/reviews/ |
| 20:24.33 | sruffell | kpfleming: speaking of crucible, do you know how to just drop all files from a review? I had a little trouble this weekend when trying to set up the review for the wctdm24xxp. I wanted to select all the revisions on the branch, and started with the tip. When I clicked the parent (working my way back to trunk) it said those changes were already in the review. Then when I clicked the x to remove the revision from the review, it did, |
| 20:24.43 | sruffell | looking at https://code.asterisk.org/code/cru/CR-DAHDI-2 |
| 20:24.50 | sruffell | (I don't know if you can see that since it's a draft) |
| 20:25.03 | kpfleming | yes, i saw it this morning |
| 20:25.19 | kpfleming | i don't know of any 'en masse' way to remove content... it may be easier to just abandon the review. |
| 20:25.25 | sruffell | :( ok |
| 20:25.53 | sruffell | so..note to selfâ¦I'm guessing you need to start with the change that is closest to trunk and move your way out to the tip of a branch? |
| 20:25.53 | kpfleming | otherwise you'd have to click a lot of red Xs |
| 20:26.05 | kpfleming | you don't have to, but it does make things easier |
| 20:26.23 | kpfleming | if you want, when you're ready to try again, let me know and i'll come over |
| 20:26.52 | sruffell | ok |
| 20:38.44 | *** join/#asterisk-dev oej (~olle@195.41.130.3) |
| 20:38.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:51.58 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 20:52.04 | jmls | evening all |
| 20:52.22 | jsmith | Hey jmls -- how are things on the far side of the pond? |
| 20:52.38 | jmls | not so bad. We're busy jailing all the yobs |
| 20:54.10 | jmls | what's the pros and cons of reloading a module , forcing a realtime static read of a .conf file vs. realtime ? |
| 20:54.58 | jmls | IOW, for example, should I use realtime voicemail, or reload the module when I add / remove voicemail boxes from the system ? |
| 21:01.05 | kpfleming | rescanning the conf file doesn't tend to be particularly expensive vs. having to constantly poll the database for config info |
| 21:05.21 | jmls | kpfleming: thanks. I was wondering about the impact on a running system if the modules are being reloaded - is there any downside to a module reload ? |
| 21:06.26 | kpfleming | sure.. the module usually can't process any new requests during the conf parsing process |
| 21:06.58 | kpfleming | also, there's a difference between a real module reload (where the module is removed from the process and brought back in) and a 'reload' which just tells the module to reload its config |
| 21:08.36 | jmls | bugger. just thought of a flaw in my thought process. Is there any way of getting an indication that a pin has changed ? |
| 21:09.34 | kpfleming | umm... that question is too vague for me to answer |
| 21:22.52 | jmls | when changing your pin number on voicemail, the new password is written back to voicemail.conf (or sent to the db for update in realtime) |
| 21:23.42 | kpfleming | you can have a script run when that happens |
| 21:23.58 | jmls | ah, excellent. |
| 21:24.12 | kpfleming | because someone thought of that already :-) |
| 21:24.43 | jmls | there are some smart boys over the pond, then ? ;) |
| 21:25.05 | kpfleming | could have been someone on your side.. or down under. it's been there for a long time. |
| 21:25.13 | jmls | heh |
| 21:25.41 | jmls | runs off to stop the dog eating one of the children |
| 21:28.26 | kpfleming | that's right... children should be eaten in pairs. |
| 21:29.10 | jmls | yeah ... saved one leg. Irish wife thought that it would be a good idea to get an Irish wolfhound as a pet ... |
| 21:29.12 | jsmith | kpfleming: That's the funniest thing I've heard all day :-) |
| 21:29.22 | kpfleming | jsmith: slow day then. |
| 21:29.28 | jsmith | kpfleming: Must be a Monday... |
| 21:29.46 | kpfleming | jmls: i like Irish wolfhounds. wouldn't have one here though, it's way too hot for them. |
| 21:58.58 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hqoccdooyhrtolof) |
| 22:21.20 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 22:21.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:14.09 | *** part/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |