[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