| 00:05.52 | leifmadsen | russellb: ping? |
| 00:08.15 | leifmadsen | question: putnopvut mentioned I should block my 1.4 change in 1.6.2, but I'm not entirely sure how to go about that. I made my change to 1.4, 1.6.0, 1.6.1 for the non astxml stuff, then made the xml changes to docs in trunk then merged back to 1.6.2. Just wanted to make sure I got all the steps. |
| 00:11.41 | eliel | leifmadsen: i think the "natural" order is 1.4 -> trunk -> 1.6.2 -> 1.6.1 -> 1.6.0 |
| 00:14.19 | eliel | what i did once (maybe i was wrong) was: 1.4 -> trunk (resolved the conflicts) and then merge back to 1.6.x... and resolving the conflicts was using xml instead of the old static docs... maybe i did wrong... |
| 00:15.34 | leifmadsen | hmmmm.... |
| 00:15.59 | eliel | i think going from old static docs to xml is a conflict and it is not needed to do a new patch... |
| 00:15.59 | leifmadsen | I think we need to make sure we document the best way of updating the old and new docs going forward so we do it the right way |
| 00:16.48 | leifmadsen | I had asked a couple of times earlier, and each time I got the recommendation to do the trunk -> 1.6.2 route, then do a separate patch for 1.4, 1.6.0, and 1.6.1 |
| 00:16.58 | leifmadsen | although I'm sure there is still something wrong I'm doing |
| 00:18.05 | *** join/#asterisk-bugs bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 00:18.05 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 00:19.51 | eliel | you already block4trunk the commit in 1.4? |
| 00:21.11 | leifmadsen | block4trunk in trunk |
| 00:21.42 | eliel | yes, that, ok |
| 00:58.11 | *** join/#asterisk-bugs Deeewayne (n=dwayne@76.29.245.9) |
| 00:58.11 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 01:07.26 | *** join/#asterisk-bugs leif[mobile] (n=leifmads@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:07.26 | *** mode/#asterisk-bugs [+o leif[mobile]] by ChanServ |
| 03:17.59 | *** join/#asterisk-bugs bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 03:17.59 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 03:22.06 | seanbright | i really feel like 15189 is a blocker |
| 03:22.11 | seanbright | ... for another 1.4 release |
| 03:22.55 | seanbright | i am working on an ugly (but hopefully working) solution |
| 03:24.35 | leifmadsen | seanbright: oh really... |
| 03:24.37 | leifmadsen | M15189 |
| 03:24.40 | MuffinMan | [new] [Asterisk] Core/PBX 0015189: #exec script can't access manager on first asterisk load reported by p_lindheimer (Karma: +2.25) https://issues.asterisk.org/view.php?id=15189 |
| 03:25.25 | leifmadsen | seanbright: updated to reflect that |
| 03:25.30 | leifmadsen | blocker for 1.4.27 |
| 03:25.36 | seanbright | oh |
| 03:25.38 | leifmadsen | there are too many issues assigned for 1.6.1.1 |
| 03:25.40 | seanbright | 1.4.26 is already out? |
| 03:25.54 | leifmadsen | seanbright: 1.4.26-rc1 is currently pending |
| 03:26.04 | leifmadsen | it could potentially go into -rc2 I suppose |
| 03:26.12 | seanbright | it affects freepbx |
| 03:26.23 | leifmadsen | I'm not going to wait a week for it :) |
| 03:26.25 | seanbright | which is a good number of people i would imagine |
| 03:26.29 | leifmadsen | right |
| 03:26.31 | seanbright | i'm working on it right now |
| 03:26.33 | seanbright | :) |
| 03:26.38 | seanbright | will get a review tomorrow |
| 03:26.39 | leifmadsen | no problem, it will probably get in then |
| 03:26.52 | leifmadsen | I'm not in tomorrow, and I haven't gotten what I need for 1.4.26-rc1 anyways |
| 03:26.55 | leifmadsen | so I think you'll be fine |
| 03:26.59 | seanbright | cool |
| 03:27.04 | leifmadsen | I'll update this to be a blocker for 1.4.26 |
| 03:27.25 | seanbright | thank you, sir. |
| 03:31.06 | leifmadsen | I'm currently going through issues and marking them as blockers or not for 1.6.1.x.... yay! |
| 03:33.18 | seanbright | nice. |
| 03:33.30 | seanbright | so i am wondering if this is a good solution... |
| 03:33.37 | seanbright | pbx_config loads extensions.conf |
| 03:33.41 | seanbright | manager loads |
| 03:33.48 | seanbright | pbx_config is notified and does a reload |
| 03:33.59 | seanbright | that would seem to solve the problem there. |
| 03:34.04 | leifmadsen | is there any way to force another module to load before another? |
| 03:34.19 | seanbright | well that's the problem |
| 03:34.25 | leifmadsen | ya, the load order |
| 03:34.37 | seanbright | manager is now loaded last to resolve a deadlock |
| 03:34.41 | leifmadsen | ah |
| 03:34.48 | seanbright | so going on the assumption that it *has* to be loaded last |
| 03:34.53 | leifmadsen | seems like a yucky way to solve it :) |
| 03:34.56 | seanbright | agreed. |
| 03:35.43 | seanbright | i guess instead of doing that, i could load pbx_config but defer loading extensions.conf until the manager is loaded. |
| 03:36.42 | seanbright | well, one thing at a time. |
| 04:13.49 | seanbright | ok, test patch uploaded. |
| 04:21.01 | *** join/#asterisk-bugs ZX81 (n=matt@121-72-133-248.dsl.telstraclear.net) |
| 04:21.36 | ZX81 | hi all, about to submit an issue but wondered if anyone had seen it etc (been through about 60 queue related issues and can't see it). |
| 04:22.11 | ZX81 | Basically if you have no music on hold in a queue (i.e. r option) then you don't get played the holdtime announcement |
| 04:22.33 | ZX81 | if no one has seen it before I'll set up a xen enviro with a stock install and report it |
| 04:22.38 | ZX81 | 1.4svn |
| 04:27.59 | ZX81 | hmmm - just confirmed on clean box - will submit issue |
| 05:51.13 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 07:18.19 | mvanbaak | ZX81: that is correct. the r option will stop the announcements |
| 07:18.37 | mvanbaak | ZX81: it's been that way since I started using asterisk (1.0.8 I think) |
| 08:07.03 | *** join/#asterisk-bugs oej (n=olle@213.136.49.145) |
| 08:18.38 | Entomologist | *** CLOSED (15219) [Applications/General] recent commit on SVN 1.4 branch fails to compile |
| 08:18.38 | Entomologist | Reported by: loloski Karma: 4.5 |
| 08:18.38 | Entomologist | https://issues.asterisk.org/view.php?id=15219 |
| 08:18.38 | Entomologist | ********************************************************* |
| 11:15.22 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:39.16 | *** join/#asterisk-bugs eliel (n=eliels@200.61.172.61) |
| 12:57.32 | *** join/#asterisk-bugs leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:57.32 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 13:08.52 | *** join/#asterisk-bugs putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:08.52 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 14:04.07 | philippel | M15189 |
| 14:04.09 | MuffinMan | [acknowledged] [Asterisk] Core/PBX 0015189: [patch] #exec script can't access manager on first asterisk load reported by p_lindheimer (Karma: +2.25) https://issues.asterisk.org/view.php?id=15189 |
| 14:04.57 | philippel | just tested, looks good as far as #exec connecting to manager on a "restart now" where it was failing before until a subsequent "reload" |
| 14:08.51 | jsmith | philippel: I'll bet the config file is being read before the rest of the modules have loaded |
| 14:09.52 | philippel | jsmith they had moved the initial load of the manager to the end cause of another bug which caused the issue. seanbright provided a patch to address that last night which I just tested |
| 14:10.36 | philippel | jsmith btw, seems like putnopvut is real busy, do you think I should fire out something to the dev mailing list wrt to the queue extensions state changes (fixes) I did? |
| 14:10.43 | philippel | M15168 |
| 14:10.46 | 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: +2.25) https://issues.asterisk.org/view.php?id=15168 |
| 14:17.21 | seanbright | philippel: was just a quick and dirty hack to see if i could get it to work. i am going to try to code up something based on Corydon76-dig's suggestion. |
| 14:17.29 | seanbright | that seems cleaner. |
| 14:19.04 | philippel | seanbright I thought so too from the sound of it, as long as the manager is able to return an error return code if the reload fails from the timeout |
| 14:22.59 | jsmith | philippel: Wouldn't hurt to fire something to the -dev list |
| 14:23.00 | *** join/#asterisk-bugs Deeewayne (n=dwayne@75.76.254.162) |
| 14:23.00 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 14:23.06 | jsmith | philippel: All the digium devs are slammed |
| 14:24.18 | seanbright | well his suggestions was more aimed at resolving 13778 in a less break-other-things way |
| 14:24.49 | seanbright | the idea being to sit on a reload request until the pbx is completely up and running |
| 14:24.52 | philippel | I assume as much - I still think though that the 'solution' currenlty provided using devicestate information is not a complete solution (thus the reason I was motivated to write this patch) which means, once reviewed and if accepted, the next challenge is how to connvince that it should be backported to 1.4 on the premis that the devicestate solution already backported is not adequate for all |
| 14:24.54 | seanbright | unless i misunderstood |
| 14:25.14 | philippel | seanbright maybe I mis-understood, let me read again |
| 14:25.33 | seanbright | basically... move manager initialization back to where it was |
| 14:25.50 | philippel | This means that a reload might fail, but that's preferable to the alternatives (either a deadlock or a module load failing). |
| 14:26.07 | seanbright | then throw a timedlock in ast_module_reload so that an AMI reload command would block until we were actually done loading in the first place |
| 14:26.10 | philippel | I assumed his suggestion was to wait and possibly timeout and fail worse case (in the manager) |
| 14:26.47 | philippel | I guess the only queustion on that one, are there other instances of blocking manager calls that could block for a significant amount of time? |
| 14:27.26 | philippel | if there are not, I could see something blocking for a while being problematic for someone's manager application out there - but on the other hand |
| 14:27.36 | seanbright | it's only blocking on startup |
| 14:27.49 | seanbright | and when a reload is issued during startup |
| 14:27.52 | philippel | if reload already blocks until the reload is finished (which would be a nice option if not) then there is no issue since some reloads can be long |
| 14:28.15 | seanbright | well, i'll need to look more closely at it. |
| 14:28.56 | seanbright | i just want to get it resolved since it affects freepbx |
| 14:29.04 | seanbright | i don't consider 15168 a blocker |
| 14:29.05 | philippel | in any event, it is only at startup and fact of the matter is, if they are expecting a reload to be successful, they probably can't do anything else anyhow... |
| 14:29.10 | seanbright | since it's effectively a new feature. |
| 14:29.16 | philippel | M15168 |
| 14:29.19 | 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: +2.25) https://issues.asterisk.org/view.php?id=15168 |
| 14:29.31 | philippel | seanbright oh, agreed completely at this point |
| 14:30.17 | philippel | seanbright I'll eventually want to get into the discussino when that is reviewed and addressed whether it is a new feature, or another grey area that once put in 1.6, it is brought back to 1.4 just like the other related changes were |
| 14:31.27 | philippel | the issue being, it is actually very related to this #exec bug, in many FreePBX installations, it won't be adequate to associate a single devicestate with a queue member, you need to associate a hint given the way hints can be multi part and dynamic |
| 14:32.37 | philippel | but - it isn't worth discussing yet until my concept and patch gets reviewed (and probably properly re-written though hopefully it will result in some additional Karma points:) ) - and as it is now, it's written for 1.4 and me or someone else needs to probably first port it to trunk... |
| 14:34.31 | philippel | seanbright btw, not that it is a really high priority but it has been showing as new for quite some time and probably should get assigned as I think it is an easy fix: |
| 14:34.35 | philippel | M15056 |
| 14:34.38 | MuffinMan | [new] [Asterisk] Applications/app_dial 0015056: Blank FORWARD_CONTEXT is not ignored reported by p_lindheimer (Karma: +2.25) https://issues.asterisk.org/view.php?id=15056 |
| 14:40.32 | *** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:53.37 | seanbright | M15056 |
| 14:53.39 | MuffinMan | [ready for testing] [Asterisk] Applications/app_dial 0015056: [patch] Blank FORWARD_CONTEXT is not ignored reported by p_lindheimer (Karma: +2.25) https://issues.asterisk.org/view.php?id=15056 |
| 14:53.41 | seanbright | philippel: ^^^ |
| 14:56.20 | philippel | seanbright I'll have a look at testing that this morning, thanks - btw, has there ever been thought to adding the ability of unsetting a channel variable from the dialplan? (unless I have somehow missed that ability)? |
| 14:59.56 | leifmadsen | philippel: heh... see #asterisk-dev :) |
| 15:09.15 | seanbright | philippel: when 'unsetting' FORWARD_CONTEXT (Set(FORWARD_CONTEXT=)) you expect it will use whatever the default context is, correct? |
| 15:11.36 | philippel | seanbright if I were to 'unset' it, I would expect it to operate as if it had never been set, iirc isn't that the 'current' context? |
| 15:12.11 | seanbright | correct |
| 15:12.25 | philippel | yeah - that is my expected behavior |
| 15:12.28 | seanbright | excellent. |
| 15:12.37 | seanbright | that patch should fix you up, then. |
| 15:13.48 | philippel | so I'll test and see if that works, today I set it to a context that would hangup the call on a ringgroup if they have an option set that says to not honor CF (to handle client side CF devices), but if it continues without anyone answering, I want to unset it. To get around that I set it to "from-internal" which is our default internal context |
| 15:14.20 | philippel | however - if someone were doing something custom or strange, it would be nice to just unset it which is what you patch looks like ti will do and all will be good |
| 15:17.21 | seanbright | well, before the patch, if the variable didn't exist on the channel, it would use the current context |
| 15:17.27 | seanbright | if it was blank it tried to use a blank context |
| 15:17.37 | seanbright | now if it's empty it just treats it as if it wasn't there at all |
| 15:18.35 | philippel | yeah - I think I recall it looked like it was trying to use the current context whe I tested it and then filed the bug, since the current context is not the correct context to use (as it is not the same as if it was not there) |
| 15:57.26 | *** join/#asterisk-bugs JackEStorm (n=no@ip24-252-118-155.no.no.cox.net) |
| 16:20.49 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 17:50.36 | Entomologist | *** CLOSED (15124) [Addons/chan_mobile] Segmentation fault with incoming calls |
| 17:50.36 | Entomologist | Assigned to: mnicholson |
| 17:50.37 | Entomologist | Reported by: Fishticky Karma: 0 |
| 17:50.37 | Entomologist | https://issues.asterisk.org/view.php?id=15124 |
| 17:50.37 | Entomologist | ********************************************************* |
| 18:14.14 | Entomologist | *** CLOSED (15225) [General] make config on slackware |
| 18:14.14 | Entomologist | Reported by: pdavis Karma: 0 |
| 18:14.14 | Entomologist | https://issues.asterisk.org/view.php?id=15225 |
| 18:14.14 | Entomologist | ********************************************************* |
| 18:15.24 | *** join/#asterisk-bugs codefreeze-lap (n=murf@72.21.67.40) |
| 18:15.30 | *** join/#asterisk-bugs ghenry (n=ghenry@pdpc/supporter/monthlybyte/ghenry) |
| 18:18.57 | *** join/#asterisk-bugs JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 18:18.57 | *** mode/#asterisk-bugs [+o JunK-Y] by ChanServ |
| 18:37.05 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 18:53.06 | Entomologist | *** CLOSED (12946) [CDR/General] [patch] ResetCDR does not work on non-answered channel |
| 18:53.06 | Entomologist | Reported by: meral Karma: 0 |
| 18:53.06 | Entomologist | https://issues.asterisk.org/view.php?id=12946 |
| 18:53.06 | Entomologist | ********************************************************* |
| 18:53.07 | Entomologist | *** CLOSED (15122) [Applications/app_queue] Abandoned queue calls won't show on CDR |
| 18:53.07 | Entomologist | Assigned to: mnicholson |
| 18:53.08 | Entomologist | Reported by: sum Karma: 1 |
| 18:53.10 | Entomologist | https://issues.asterisk.org/view.php?id=15122 |
| 18:53.12 | Entomologist | ********************************************************* |
| 19:46.08 | Entomologist | *** CLOSED (15226) [General] [patch] Simplify main/Makefile removing the list of objects to compile |
| 19:46.09 | Entomologist | Reported by: eliel Karma: 184.5 |
| 19:46.09 | Entomologist | https://issues.asterisk.org/view.php?id=15226 |
| 19:46.09 | Entomologist | ********************************************************* |
| 20:07.04 | Entomologist | *** CLOSED (14412) [Resources/General] [patch] 1.6.1 Choppy sound in Dual Xeon 2.8 GHz |
| 20:07.04 | Entomologist | Assigned to: russell |
| 20:07.05 | Entomologist | Reported by: dome Karma: 3 |
| 20:07.05 | Entomologist | https://issues.asterisk.org/view.php?id=14412 |
| 20:07.05 | Entomologist | ********************************************************* |
| 20:07.30 | *** join/#asterisk-bugs pmhaddad-work (n=pmhaddad@141.219.87.43) |
| 20:08.09 | pmhaddad-work | M15227 |
| 20:08.11 | MuffinMan | [new] [Asterisk] Applications/app_chanisavail 0015227: ChanIsAvail() always returns 0 (Unknown) reported by pmhaddad (Karma: neutral) https://issues.asterisk.org/view.php?id=15227 |
| 20:08.19 | pmhaddad-work | ^^ have fun with that one... |
| 20:09.34 | russellb | bah, nobody should use that application, anyway :-) |
| 20:09.38 | russellb | it's evil |
| 20:10.03 | leifmadsen | way |
| 20:10.43 | leifmadsen | major => minor |
| 20:12.04 | pmhaddad-work | sorry :S |
| 20:12.15 | pmhaddad-work | russellb, what should i be using to determine is on/off hook? |
| 20:13.10 | russellb | ${DEVICE_STATE(DAHDI/1)} I suppose :-) |
| 20:13.40 | pmhaddad-work | yeah, that always returns 0 though |
| 20:13.52 | russellb | I don't believe you! |
| 20:13.54 | pmhaddad-work | er |
| 20:13.55 | pmhaddad-work | sorry |
| 20:13.57 | leifmadsen | heh |
| 20:13.58 | russellb | because it returns a string, not a number |
| 20:13.59 | pmhaddad-work | it returns unknown |
| 20:14.02 | pmhaddad-work | yeah |
| 20:14.02 | russellb | Ah. |
| 20:14.06 | pmhaddad-work | sorru |
| 20:14.09 | russellb | nods |
| 20:14.10 | pmhaddad-work | i got mixed up lol |
| 20:14.10 | russellb | well then. |
| 20:14.18 | russellb | shrugs some more |
| 20:14.23 | pmhaddad-work | and i was thinking it was a ChanIsAvail() problem |
| 20:15.38 | pmhaddad-work | its stumped me for a while and I need to get it working now(ish) |
| 20:33.21 | *** join/#asterisk-bugs bbryant1 (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 20:33.21 | *** mode/#asterisk-bugs [+o bbryant1] by ChanServ |
| 20:47.43 | *** join/#asterisk-bugs codefreeze-lap (n=murf@72.21.67.40) |
| 22:03.28 | *** join/#asterisk-bugs xpot (n=james@70.91.210.233) |
| 22:03.28 | *** join/#asterisk-bugs Entomologist (n=nobody@76.164.171.226) [NETSPLIT VICTIM] |
| 22:35.40 | philippel | seanbright oops, want' that silly, but I forgot to do a restart now:) |
| 22:37.50 | Qwell | philippel: *thwap* |