According to https://code.google.com/p/webrtc/issues/detail?id=2907#c2
r5505 was committed to resolve exactly these flakes.
Let's revert the disabling and see.
BUG=2907
TBR=mallinath@webrtc.org
> Disable failing libjingle_p2p_unittest test on Linux
>
> I realize this diables 84 test cases and for all platforms, which
> I'm not really comfortable with. I tried finding a better way but
> couldn't without doing significant changes to the file.
> I think the tests either needs to be fixed or otherwise refactored
> in order to make more fine-grained disabling possible.
>
> Another (too) large disabling was done by holmer@ in
> https://webrtc-codereview.appspot.com/2227004 where he should only have
> disabled them on Windows, if the failures in webrtc:2383 was all that
> caused those flakes.
>
> BUG=2907
> TEST=Verified this ran 0 tests:
> out/Release/libjingle_p2p_unittest --gtest_filter=P2PTransportChannelTest.TestNAT_ADDR_RESTRICTEDToNAT_PORT_RESTRICTEDAsGiceBothSharedUfragWithMinimumStepDelay
> TBR=wu@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/8309004TBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8329004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5511 4adac7df-926f-26a2-2b94-8c16560cd09d
I realize this diables 84 test cases and for all platforms, which
I'm not really comfortable with. I tried finding a better way but
couldn't without doing significant changes to the file.
I think the tests either needs to be fixed or otherwise refactored
in order to make more fine-grained disabling possible.
Another (too) large disabling was done by holmer@ in
https://webrtc-codereview.appspot.com/2227004 where he should only have
disabled them on Windows, if the failures in webrtc:2383 was all that
caused those flakes.
BUG=2907
TEST=Verified this ran 0 tests:
out/Release/libjingle_p2p_unittest --gtest_filter=P2PTransportChannelTest.TestNAT_ADDR_RESTRICTEDToNAT_PORT_RESTRICTEDAsGiceBothSharedUfragWithMinimumStepDelay
TBR=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8309004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5510 4adac7df-926f-26a2-2b94-8c16560cd09d
New errors arrived when rolling libjingle in r5502.
These suppressions are needed to green up the Memcheck and
TSan bots.
BUG=1976,2080
TEST=local runs on Linux:
tools/valgrind-webrtc/webrtc_tests.sh --tool=tsan -b out/Release -t libjingle_unittest
tools/valgrind-webrtc/webrtc_tests.sh --tool=memcheck -b out/Release -t libjingle_unittest
and trybot:
git try --bot=linux_memcheck,linux_tsan -t libjingle_unittest
TBR=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5509 4adac7df-926f-26a2-2b94-8c16560cd09d
Because chromium is compiled with a different version of logging macros
defined in logging.h that header cannot be used in headers that can
also included from chromium code. Removed LOG_F(LS_WARNING) from
callback.h . That issue would block this code from being rolled in
chromium.
R=mallinath@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8279004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5507 4adac7df-926f-26a2-2b94-8c16560cd09d
Chromium has decided to drop Coverity so
we don't have any reason for maintaining this code.
Personally, I think that from a quality perspective other tools,
like all the new compiler warnings that are constantly being added
to the Clang compiler is a better way to address dangers in the code.
The maintenance cost and overhead of such advanced tools like Coverity
is simply too high.
BUG=
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7669007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5500 4adac7df-926f-26a2-2b94-8c16560cd09d
The reason for this is that http://crrev.com/245412
introduces a dependency of Chrome's src/build/gyp_chromium
to src/tools/find_depot_tools.py, which we don't have
synced in WebRTC (src/tools is very big).
Offline discussions shows that we cannot rely on syncing
individual subdirectories from Chrome in the future, but
maintaining our own gyp_webrtc file will at least buy us
some time for now, so we can roll past that chromium_revision
in WebRTC DEPS.
Overview of differences between gyp_webrtc and gyp_chromium
(and how we previously used gyp_chromium):
* No .gyp file needs to be passed (defaults to all.gyp)
* CHROMIUM_GYP_FILE is ignored (i.e. cannot be used to
specify an alternate .gyp file to process)
* Ninja is used by default on all platforms unless GYP_GENERATORS
is set.
* Gyp syntax check is always on
* Gyp circular dependency check is always on
* No support for automatic toolchain detection on Windows.
* --depth argument is no longer needed since calculated by
the script.
* Support for a webrtc.gyp_env file sitting next to the
.gclient file in the top dir of checkout, which can be
used to override Gyp variables similar to chromium.gyp_env.
* SKIP_WEBRTC_GYP_ENV can be set to skip reading webrtc.gyp_env.
BUG=2863
TEST=Ran and verified behavior on Linux with:
gclient runhooks
webrtc/build/gyp_webrtc
webrtc/build/gyp_webrtc -Dextra_gyp_flag=0
. build/android/envsetup.sh && gclient runhooks
SKIP_WEBRTC_GYP_ENV=1 webrtc/build/gyp_webrtc
GYP_GENERATORS=make webrtc/build/gyp_webrtc
The patch also passes runhooks and compile step on all trybots.
R=andrew@webrtc.org, fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7759004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5467 4adac7df-926f-26a2-2b94-8c16560cd09d
This will allow an embedder to use it directly.
Adding inertia/hangover time between updates of the reported detection status to the algorithm, controlled by a parameter. That is usually desired and this way a consumer of
the class don't have to implement that. (VoiceEngine will let it be 1, which results in the same behavior as before, and keep controlling the hangover itself.)
R=andrew@webrtc.org, niklas.enbom@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6219004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5462 4adac7df-926f-26a2-2b94-8c16560cd09d
