[test-results] [Bamboo] No agents to build plan Asterisk - Trunk - FreeBSD 8.1 - i386

[Bamboo]

-------------------------------------------------------------------------------
ASTTRUNK-FREEBSD81-I386-370 has been queued, but there's no agent capable of building it.
-------------------------------------------------------------------------------

http://bamboo.asterisk.org/browse/ASTTRUNK-FREEBSD81-I386/log

--------------
Code Changes
--------------
rmudgett (339721):

>Merged revisions 339720 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/10
>
>................
>  r339720 | rmudgett | 2011-10-06 17:58:40 -0500 (Thu, 06 Oct 2011) | 27 lines
>  
>  Merged revisions 339719 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.8
>  
>  ........
>    r339719 | rmudgett | 2011-10-06 17:47:50 -0500 (Thu, 06 Oct 2011) | 20 lines
>    
>    Fix regression in configure script for libpri capability checks.
>    
>    JIRA AST-598 added the PRI_L2_PERSISTENCE option to fix BRI PTMP TE layer
>    2 persistence issues with some telcos.  ASTERISK-18535 attempted to fix
>    the unexpected requirement that libpri *must* have that feature to work
>    with Asterisk.  The AST_EXT_LIB_SETUP_DEPENDENT lines made the PRI
>    optional features required.  Unfortunately, I thought
>    AST_EXT_LIB_SETUP_DEPENDENT didn't do anything useful for libpri and
>    deleted those lines for libpri.  The result was the HAVE_PRI_xxx defines
>    that control the ability to use optional libpri features were also
>    deleted.
>    
>    * Created AST_EXT_LIB_SETUP_OPTIONAL configuration macro to allow optional
>    features in a library that the source code could take advantage of if the
>    code supports the feature.
>    
>    (closes issue ASTERISK-18687)
>    Reported by: Norbert
>    Tested by: rmudgett
>  ........
>................
>

rmudgett (339723):

>Recorded merge of revisions 339681 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/10
>
>........
>  r339681 | wedhorn | 2011-10-06 15:47:08 -0500 (Thu, 06 Oct 2011) | 10 lines
>  
>  Fixed segfault on core stop gracefully.
>  
>  There was an issue that the cap and confcap pointers for each line and device
>  were being memcpy'd so they all pointed to the same ast_format_cap. On
>  destroying, a segfault occured on the second call to the same struct.
>  
>  skinny reload now works again as well.
>  
>  Tested by snuff (in trunk) and myself. 
>........
>


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