[test-results] [Bamboo] Asterisk - Trunk > CentOS 5.5 > #26 > i386 has FAILED. Change made by rmudgett.

Bamboo bamboo at asterisk.org
Thu Nov 25 13:13:49 CST 2010


-------------- next part --------------
----------------------------------------------------------------------------
Asterisk - Trunk > CentOS 5.5 > #26 > i386 failed.
----------------------------------------------------------------------------
Code has been updated by rmudgett.
No failed tests found, a possible compilation error.

http://bamboo.asterisk.org/browse/ASTTRUNK-CENTOS55-I386-26/        


--------------
Code Changes
--------------
rmudgett (296168):

>Merged revisions 296167 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r296167 | rmudgett | 2010-11-24 16:49:48 -0600 (Wed, 24 Nov 2010) | 57 lines
>  
>  Merged revisions 296166 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r296166 | rmudgett | 2010-11-24 16:42:45 -0600 (Wed, 24 Nov 2010) | 50 lines
>    
>    Merged revisions 296165 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r296165 | rmudgett | 2010-11-24 16:41:07 -0600 (Wed, 24 Nov 2010) | 43 lines
>      
>      Oneway audio to SIP phone from FXS port after FXS port gets a CallWaiting pip.
>      
>      The FXS connected phone has to have CW/CID support to fail, as it will
>      send back a DTMF 'A' or 'D' when it's ready to receive CallerID.  A normal
>      phone with no CID never fails.  Also the SIP phone does not hear MOH when
>      the CW call is answered.
>      
>      The DTMF end frame is suppressed when the phone acknowledges the CW signal
>      for CID.  The problem is the DTMF begin frame needs to be suppressed as
>      well.  The DTMF begin frame is causing SIP to start sending the DTMF RTP
>      frames.  Since the DTMF end frame is suppressed, SIP will not stop sending
>      those DTMF RTP packets.
>      
>      * Suppress the DTMF begin and end frames when the channel driver is
>      looking for DTMF digits.
>      
>      * Fixed a couple issues caused by not cleaning up the CID spill if you
>      answer the CW call while it is sending the CID spill.
>      
>      * Fixed not sending CW/CID spill to the phone when the call is natively
>      bridged.  (Fixed by not using native bridge if CW/CID is possible.)
>      
>      * Suppress received audio when sending CW/CID spills.  The other parties
>      involved do not need to hear the CW/CID spills and may be confused if the
>      CW call is for them.
>      
>      (closes issue #18129)
>      Reported by: alecdavis
>      Patches:
>            issue_18129_v1.8_v3.patch uploaded by rmudgett (license 664)
>      Tested by: alecdavis, rmudgett
>      
>      
>      NOTE:
>      
>      * v1.4 does not have the main problem fixed by suppressing the DTMF start
>      frames.  The other three items fixed are relevant.
>      
>      * If you really must restore native bridging between analog ports, you
>      need to disable CW/CID either by configuring chan_dahdi.conf
>      callwaitingcallerid=no or dialing *70 before dialing the number to
>      temporarily disable CW.
>    ........
>  ................
>................
>


--------------
Error Summary
--------------
   Failed to execute the build 'ASTTRUNK-CENTOS55-I386-26'<br>
java.lang.InterruptedException<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.utils.FileVisitor.visitFilesThatMatch(FileVisitor.java:54)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.builder.AbstractBuilder.collateTestResults(AbstractBuilder.java:410)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.builder.AbstractBuilder.runBuild(AbstractBuilder.java:319)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.builder.AbstractBuilder.executeBuild(AbstractBuilder.java:272)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.build.pipeline.tasks.ExecuteBuildTask.call(ExecuteBuildTask.java:85)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent.build(DefaultBuildAgent.java:189)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.v2.build.agent.BuildAgentControllerImpl.waitAndPerformBuild(BuildAgentControllerImpl.java:90)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.v2.build.agent.DefaultBuildAgent$1.run(DefaultBuildAgent.java:102)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at com.atlassian.bamboo.build.pipeline.concurrent.NamedThreadFactory$2.run(NamedThreadFactory.java:50)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at java.lang.Thread.run(Thread.java:636)<br>

   Package gtk+-2.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gtk+-2.0.pc'
   to the PKG_CONFIG_PATH environment variable
   No package 'gtk+-2.0' found
   Package gtk+-2.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gtk+-2.0.pc'
   to the PKG_CONFIG_PATH environment variable
   No package 'gtk+-2.0' found
   gcc: -lcrypto: linker input file unused because linking not done
   gcc: -lcrypto: linker input file unused because linking not done
   Build was manually stopped.


--
This message is automatically generated by Atlassian Bamboo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/test-results/attachments/20101125/e3e8d69b/attachment.htm 


More information about the Test-results mailing list