[test-results] [Bamboo] No agents to build plan Asterisk - 1.8 - Mac OS X Snow Leopard (10.6) - x86_64

[Bamboo]

-------------------------------------------------------------------------------
AST18-SNOWLEOPARD-X8664-194 has been queued, but there's no agent capable of building it.
-------------------------------------------------------------------------------

http://bamboo.asterisk.org/browse/AST18-SNOWLEOPARD-X8664/log

--------------
Code Changes
--------------
twilson (319529):

>Merged revisions 319528 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>
>................
>  r319528 | twilson | 2011-05-18 13:02:06 -0700 (Wed, 18 May 2011) | 17 lines
>  
>  Merged revisions 319527 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.4
>  
>  ........
>    r319527 | twilson | 2011-05-18 12:56:08 -0700 (Wed, 18 May 2011) | 10 lines
>    
>    Fix app_dial ring groups
>    
>    Revert part of r315643. We need to remove the datastore here as well.
>    The code in bridging code will catch anything that app_dial might miss.
>    
>    (closes issue #19311)
>    Reported by: mspuhler
>    Patches: 
>          issue_19311_no_answer.diff uploaded by elguero (license 37)
>  ........
>................
>

twilson (319552):

>Unbreak the storing of registrations for restart
>
>The fix for issue 18882 broke retrieving non-realtime peers from the ast_db
>on restart/reload. This patch tries to unbreak things while leaving the intent
>of the original fix intact.
>(closes issue #19318)
>Reported by: remiq
>Patches: 
>      diff.txt uploaded by twilson (license 396)
>Tested by: lmadsen, remiq
>

twilson (319654):

>Merged revisions 319653 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>
>................
>  r319653 | twilson | 2011-05-18 16:11:57 -0700 (Wed, 18 May 2011) | 15 lines
>  
>  Merged revisions 319652 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.4
>  
>  ........
>    r319652 | twilson | 2011-05-18 16:04:35 -0700 (Wed, 18 May 2011) | 8 lines
>    
>    Make sure everyone gets an unhold when a transfer succeeds
>    
>    Some phones, like the Snom phones, send a hold to the transfer target after
>    before sending the REFER. We need to make sure that we unhold the parties
>    that are being connected after the masquerade. If Local channels with the /nm
>    option are used when dialing the parties, hold music would still be playing on
>    the transfer target, even after being connected with the transferee.
>  ........
>................
>


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