[test-results] [Bamboo] Asterisk - Trunk > Mac OS X Snow Leopard (10.6) > #157 has FAILED. Change made by qwell, Russell Bryant and Matthew Nicholson.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - Trunk > Mac OS X Snow Leopard (10.6) > #157 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of ASTTRUNK-LUCID-248.
No failed tests found, a possible compilation error.

http://bamboo.asterisk.org/browse/ASTTRUNK-SNOWLEOPARD-157/


--------------
Failing Jobs
--------------
  - x86_64 (Default Stage): No tests found.


--------------
Code Changes
--------------
Matthew Nicholson (303509):

>According to section 19.1.2 of RFC 3261:
>
>  For each component, the set of valid BNF expansions defines exactly
>  which characters may appear unescaped.  All other characters MUST be
>  escaped.
>
>This patch modifies ast_uri_encode() to encode strings in line with this recommendation.  This patch also adds an ast_escape_quoted() function which escapes '"' and '\' characters in quoted strings in accordance with section 25.1 of RFC 3261.  The ast_uri_encode() function has also been modified to take an ast_flags struct describing the set of rules it should use when escaping characters to allow for it to escape SIP URIs in addition to HTTP URIs and other types of URIs or variations of those two URI types in the future.
>
>The ast_uri_decode() function has also been modified to accept an ast_flags struct describing the set of rules to use when decoding to enable decoding '+' as ' ' in legacy http URLs.
>
>The unit tests for these functions have also been updated.
>
>ABE-2705
>
>Review: https://reviewboard.asterisk.org/r/1081/
>

qwell (303468):

>Merged revisions 303467 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r303467 | qwell | 2011-01-24 11:20:03 -0600 (Mon, 24 Jan 2011) | 22 lines
>  
>  Merged revisions 303285 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r303285 | qwell | 2011-01-21 15:48:09 -0600 (Fri, 21 Jan 2011) | 15 lines
>    
>    Merged revisions 303284 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r303284 | qwell | 2011-01-21 15:45:34 -0600 (Fri, 21 Jan 2011) | 8 lines
>      
>      Reset configuration before parsing users.conf.
>      
>      Some values configured in chan_dahdi.conf were able to leak in to users.conf
>      configuration.  This was surprising users, and potentially setting non-sane
>      "defaults".
>      
>      ASTNOW-125
>    ........
>  ................
>................
>

Russell Bryant (303551):

>Merged revisions 303549 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r303549 | russell | 2011-01-24 14:51:37 -0600 (Mon, 24 Jan 2011) | 45 lines
>  
>  Merged revisions 303548 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
>    
>    Merged revisions 303546 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
>      
>      Fix channel redirect out of MeetMe() and other issues with channel softhangup.
>      
>      Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
>      working properly.  This issue includes a patch that resolves the issue by
>      removing a call to ast_check_hangup() from app_meetme.c.  I left that in my
>      patch, as it doesn't need to be there.  However, the rest of the patch fixes
>      this problem with or without the change to app_meetme.
>      
>      The key difference between what happens before and after this patch is the
>      effect of the END_OF_Q control frame.  After END_OF_Q is hit in ast_read(),
>      ast_read() will return NULL.  With the ast_check_hangup() removed, app_meetme
>      sees this which causes it to exit as intended.  Checking ast_check_hangup()
>      caused app_meetme to exit earlier in the process, and the target of the
>      redirect saw the condition where ast_read() returned NULL.
>      
>      Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
>      solve the issue if another application did the same thing.  There are also
>      other edge cases where if an application finishes at the same time that a
>      redirect happens, the target of the redirect will think that the channel hung
>      up.  So, I made some changes in pbx.c to resolve it at a deeper level.  There
>      are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
>      abort the hangup process.  My patch extends this to remove the END_OF_Q frame
>      from the channel's read queue, making the "abort hangup" more complete.  This
>      same technique was used in every place where a softhangup flag was cleared.
>      
>      (closes issue #18585)
>      Reported by: oej
>      Tested by: oej, wedhorn, russell
>      
>      Review: https://reviewboard.asterisk.org/r/1082/
>    ........
>  ................
>................
>


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