[test-results] [Bamboo] Asterisk > Asterisk Unit Tests > #927 has FAILED (2 tests failed, no failures were new). Change made by Matt Jordan and file.
Bamboo
noreply at bamboo.asterisk.org
Sat Mar 14 10:42:28 CDT 2015
-----------------------------------------------------------------------
Asterisk > Asterisk Unit Tests > #927 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST-ATRUNKFULLBUILD-959.
2/2 jobs failed, with 2 failing tests, no failures were new.
https://bamboo.asterisk.org/bamboo/browse/AST-ATRUNKUNIT-927/
---------------------
Currently Responsible
---------------------
Matt Jordan (Automatically assigned)
--------------
Failing Jobs
--------------
- CentOS 6 32-Bit Unit Testing (Unit Testing): 1 of 466 tests failed.
- CentOS 6 64-Bit Unit Testing (Unit Testing): 1 of 466 tests failed.
--------------
Code Changes
--------------
Matt Jordan (432947):
>apps/app_sms: Add an option to prevent SMS content from being logged
>
>In some countries, privacy laws specify that SMS content cannot be saved by a
>provider. This patch adds a new option to the SMS application, 'n', which
>prevents the SMS content from being written to the SMS log.
>
>ASTERISK-22591 #close
>Reported by: Jan Juergens
>patches:
> DisableSmsContentLoggingByParam.patch uploaded by Jan Juergens (License 6538)
>
Matt Jordan (432972):
>main/frame: Don't report empty disallow values as an error
>
>In realtime, it is normal to have a database with both 'allow' and 'disallow'
>columns in the schema. It is perfectly valid to have an 'allow' value of
>'!all,g722,ulaw,alaw' and no 'disallow' value. Unlike in static conf files,
>you can't *not* provide the disallow value. Thus, the empty disallow value
>causes a spurious WARNING message, which is kind of annoying.
>
>This patch makes it so that a 'disallow' value with no ... value ... is
>ignored. Granted, you can still screw this up as well, as technically
>specifying 'disallow=all,!ulaw' allows only ulaw, and then you would have no
>'allow' value in your database. But really, why would you do that? WHY?
>
>ASTERISK-16779 #close
>Reported by: Atis Lezdins
>........
>
>Merged revisions 432970 from http://svn.asterisk.org/svn/asterisk/branches/11
>........
>
>Merged revisions 432971 from http://svn.asterisk.org/svn/asterisk/branches/13
>
file (432950):
>func_curl: Don't hold exclusive lock when performing HTTP request.
>
>This code originally kept a lock held when performing the HTTP
>request to ensure that the options provided to curl remain valid.
>This doesn't seem to be necessary these days and holding the lock
>caused requests to happen sequentially instead of in parallel.
>
>ASTERISK-18708 #close
>Reported by: Dave Cabot
>........
>
>Merged revisions 432948 from http://svn.asterisk.org/svn/asterisk/branches/11
>........
>
>Merged revisions 432949 from http://svn.asterisk.org/svn/asterisk/branches/13
>
--------------
Tests
--------------
Existing Test Failures (2)
- AsteriskUnitTests: /funcs/func env/func file
- AsteriskUnitTests: /funcs/func env/func file
--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20150314/59c2dbb4/attachment-0001.html>
More information about the Test-results
mailing list