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

Bamboo bamboo at asterisk.org
Fri May 13 00:19:47 CDT 2011


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

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

--------------
Code Changes
--------------
twilson (315670):

>Merged revisions 315644 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r315644 | twilson | 2011-04-26 14:39:01 -0700 (Tue, 26 Apr 2011) | 32 lines
>  
>  Merged revisions 315643 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines
>    
>    Merged revisions 315596 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines
>      
>      Allow transfer loops without allowing forwarding loops
>      
>      We try to avoid the situation where two phones may be forwarded to each other
>      causing an infinite loop by storing each dialed interface in a channel
>      datastore and checking the list before dialing out. This works, but currently
>      breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
>      transfers C to B. Since human interaction is happening here and not an
>      automated forwarding loop, it should be allowed.
>      
>      This patch removes the dialed_interfaces datastore when a call is bridged (a
>      suggestion from the brilliant mmichelson). If a call is being bridged, it
>      should be safe to assume that we aren't stuck in a loop.
>      
>      Since we are now handling this is the bridge code, the previous attempts at
>      handling it in app_dial and app_queue are removed.
>      
>      Review: https://reviewboard.asterisk.org/r/1195/
>    ........
>  ................
>................
>

twilson (315674):

>Make sure to create the caps structure for autocreated peers
>
>Because crashing is bad.
>

twilson (315675):

>Merged revisions 315673 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r315673 | twilson | 2011-04-26 15:56:19 -0700 (Tue, 26 Apr 2011) | 25 lines
>  
>  Merged revisions 315672 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r315672 | twilson | 2011-04-26 15:52:25 -0700 (Tue, 26 Apr 2011) | 18 lines
>    
>    Merged revisions 315671 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r315671 | twilson | 2011-04-26 15:47:56 -0700 (Tue, 26 Apr 2011) | 11 lines
>      
>      Make sure unregistering a peer unlinks it from the peer container
>      
>      Instead of mostly copying the code from expire_register, just use the function
>      that "does the right thing".
>      
>      (closes issue #16033)
>      Reported by: kkm
>      Patches: 
>            016033-tilgman-fixed-refcount.diff uploaded by kkm (license 888)
>      Tested by: kkm, tilghman, twilson
>    ........
>  ................
>................
>


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


More information about the Test-results mailing list