[test-results] [Bamboo] Asterisk - 1.8 > Mac OS X Snow Leopard (10.6) > #253 has FAILED. Change made by 9 authors.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - 1.8 > Mac OS X Snow Leopard (10.6) > #253 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST18-LUCID-650.
No failed tests found, a possible compilation error.

http://bamboo.asterisk.org/browse/AST18-SNOWLEOPARD-253/


--------------
Failing Jobs
--------------
  - x86_64 (Default Stage): No tests found.


--------------
Code Changes
--------------
kmoore (331038):

>In-queue MOH stops after a periodic announcement
>
>If the seek value is past the end of file when resuming G.722 MOH, MOH will
>cease to function for the duration of the MOH session through all starts and
>stops until saved state is cleared.  Adjusting the code to guarantee a single
>valid read (which is already assumed) fixes the bug.
>
>(closes issue ASTERISK-18077)
>Review: https://reviewboard.asterisk.org/r/1328/
>Tested-by: Jonathan Rose <jrose at digium.com>
>

rmudgett (331714):

>AMI actions DAHDIHangup and DAHDITransfer have no effect.
>
>The AMI actions DAHDIHangup and DAHDITransfer have no effect on a DAHDI
>channel.  These two AMI actions are highly specialized to analog channels
>and appear to make the channel behave like a jack port for headsets.
>
>* Made the faked DAHDI event get processed before a normal media stream
>read in dahdi_read() instead of trying to trigger an exception read by
>setting the AST_FLAG_EXCEPTION flag.  Apparently a change was made long
>ago that changed how AST_FLAG_EXCEPTION is processed in the core.
>Unfortunately, the faked DAHDI events no longer worked when that happened.
>
>* Updated the DAHDI AMI action documentation for the following actions:
>DAHDITransfer, DAHDIHangup, DAHDIDialOffhook, DAHDIDNDon, DAHDIDNDoff,
>DAHDIShowChannels, and DAHDIRestart.
>
>* Made use sscanf() instead of atoi() for better error checking of the
>DAHDIChannel header string.
>
>JIRA AST-620
>JIRA SWP-3616
>

rmudgett (331461):

>Output of queue log not started until logger reloaded.
>
>ASTERISK-15863 caused a regression with queue logging.  The output of the
>queue log is not started until the logger configuration is reloaded.
>
>* Queue log initialization is completely delayed until the first message
>is posted to the queue log system.  Including the initial opening of the
>queue log file.
>
>* Fixed rotate_file() ROTATE strategy to give the file just rotated out to
>the configured exec function after rotate.  Just like the other strategies.
>
>* Fixed logger reload to always post the queue reload entry instead of
>just if there is a queue log file.
>
>* Refactored some code to eliminate some redundancy and to reduce stack
>utilization.
>
>(closes issue ASTERISK-17036)
>JIRA SWP-2952
>Reported by: Juan Carlos Valero
>Patches:
>      jira_asterisk_17036_v1.8.patch (license #5621) patch uploaded by rmudgett
>Tested by: rmudgett
>
>(closes issue ASTERISK-18208)
>Reported by: Christian Pinedo
>
>Review: https://reviewboard.asterisk.org/r/1333/
>


--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20110815/ad150869/attachment-0001.htm>