[test-results] [Bamboo] No agents to build plan Asterisk - Trunk - Ubuntu Hardy (8.04) - amd64

Bamboo bamboo at asterisk.org
Mon May 23 09:30:16 CDT 2011


-------------------------------------------------------------------------------
ASTTRUNK-HARDY-AMD64-7 has been queued, but there's no agent capable of building it.
-------------------------------------------------------------------------------

http://bamboo.asterisk.org/browse/ASTTRUNK-HARDY-AMD64/log

--------------
Code Changes
--------------
jrose (320178):

>Merged revisions 320162 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r320162 | jrose | 2011-05-20 13:12:21 -0500 (Fri, 20 May 2011) | 15 lines
>  
>  Fixes an imapfolder related crash
>  
>  imapfolders being set in the general section of voicemail would cause the inbox folder name to
>  change.  Since sound file names are made based on the names of the folders, this would cause
>  the audio related to that folder name to change and if Asterisk attempted to play it, the
>  channel would instantly hang up when the audio file couldn't be found.  This patch searches for
>  the name of the folder first to leave existing behavior in tact and if that fails, it uses
>  the normal inbox name to get the sound file instead.
>  
>  
>  (closes issue #16104)
>  Reported by: blkline
>  
>  Review: https://reviewboard.asterisk.org/r/1215/
>........
>

mnicholson (320181):

>Merged revisions 320180 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r320180 | mnicholson | 2011-05-20 13:48:46 -0500 (Fri, 20 May 2011) | 16 lines
>  
>  This commit modifies the way polling is done on TLS sockets.
>  
>  Because of the buffering the TLS layer does, polling is unreliable. If poll is
>  called while there is data waiting to be read in the TLS layer but not at the
>  network layer, the messaging processing engine will not proceed until something
>  else writes data to the socket, which may not occur. This change modifies the
>  logic around TLS sockets to only poll after a failed read on a non-blocking
>  socket. This way we know that there is no data waiting to be read from the
>  buffering layer.
>  
>  (closes issue #19182)
>  Reported by: st
>  Patches:
>        ssl-poll-fix3.diff uploaded by mnicholson (license 96)
>  Tested by: mnicholson
>........
>


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


More information about the Test-results mailing list