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

Bamboo bamboo at asterisk.org
Tue Apr 26 22:44:31 CDT 2011


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

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

--------------
Code Changes
--------------
twilson (315644):

>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/
>  ........
>................
>

rmudgett (315645):

>The 'e' special extension fails to trigger in at least two cases.
>
>The 'e' extension is a fall back for the 'i', 't', or 'T' extensions if
>any of them do not exist.  Many of the places the 'e' extension was
>supposed to be invoked fail because the priority was set wrong.  There
>were two places where the 'e' extension was not even checked for fall
>back.
>
>* Made invoke the 'e' extension similarly to the previous 'i', 't', or 'T'
>extension check and added the 'e' extension as a fall back to the two
>missing locations.
>
>* Prioritized and optimized some hangup tests associated with the 'e'
>extension.
>
>(closes issue #19136)
>Reported by: kshumard
>Tested by: rmudgett
>
>Review: https://reviewboard.asterisk.org/r/1196/
>

twilson (315673):

>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/20110426/6983b318/attachment-0001.htm>


More information about the Test-results mailing list