Android headers can have a <sys/quota.h> header but with its functions
ifdef'ed out. Check for that by checking for the presence of quotactl().
MozReview-Commit-ID: 26ILnbP7flO
--HG--
extra : rebase_source : fe78c114189a362cdad3d79ce67868b045328392
NDK headers are grouped into a "sysroot" directory, which doesn't
contain architecture-specific bits, and a "system" directory, which
contains only the architecture-specific bits. Previously, both
directories are the same, under platforms/android-*/arch-*/. However,
with unified headers in NDK r16, the two are different, so we need to
support that in the Android build scripts.
Unified headers also rely on the build system defining the
__ANDROID_API__ macro, so we add support for that as well.
MozReview-Commit-ID: 9zBNQC3BRFl
--HG--
extra : rebase_source : 9ded282343df64d9cc4abcf7d7c6b03ac3423ff0
In this patch, we remove 3 tests:
1. test for blocked domain
2. test for blocked sub-domain
3. test for non-blocked domain
Two nsIDOMWindowUtils APIs were added for adding/removing a mock domain to the
existing blocklist. They are only used in the Stylo blocklist tests, so we
remove them as well.
MozReview-Commit-ID: A0ETWlqwbpN
Such a shame that the functionDecl() matcher doesn't handle them. I didn't find
a cleaner way to handle them, but I'm a 100% noob with AST matchers, so there
may be a more elegant way to do this.
MozReview-Commit-ID: 3HJQdFpN4hy
--HG--
extra : rebase_source : 27e48e6fb264499fd99e75eb54a22276758ab3e4
Android headers can have a <sys/quota.h> header but with its functions
ifdef'ed out. Check for that by checking for the presence of quotactl().
MozReview-Commit-ID: 26ILnbP7flO
--HG--
extra : rebase_source : 147e4be9eb98326fd4946b7b3695c573c7108347
NDK headers are grouped into a "sysroot" directory, which doesn't
contain architecture-specific bits, and a "system" directory, which
contains only the architecture-specific bits. Previously, both
directories are the same, under platforms/android-*/arch-*/. However,
with unified headers in NDK r16, the two are different, so we need to
support that in the Android build scripts.
Unified headers also rely on the build system defining the
__ANDROID_API__ macro, so we add support for that as well.
MozReview-Commit-ID: 9zBNQC3BRFl
--HG--
extra : rebase_source : 36c9d4d5625fecbbe2485668811f85f9d94372d5
The first two are variants of existing ones, with a slightly different
signature, and tha last one is well known and found in glib-related
suppression files like https://github.com/flatpak/flatpak/blob/master/tests/glib.supp
--HG--
extra : rebase_source : 2a209cc5987405e7ff638bbf69e1b74202b0357e
The MACHTYPE bash variable is an odd thing that returns e.g.
x86_64-redhat-linux-gnu on a CentOS system, but x86_64-pc-linux-gnu
on a Debian system, and possibly something different on other distros.
mach valgrind-test is the only place actually relying on MACHTYPE.
Others rely on information from python modules. Uniformize that, and use
the more generic 'pc' rather than 'redhat'.
--HG--
rename : build/valgrind/i386-redhat-linux-gnu.sup => build/valgrind/i386-pc-linux-gnu.sup
rename : build/valgrind/x86_64-redhat-linux-gnu.sup => build/valgrind/x86_64-pc-linux-gnu.sup
extra : rebase_source : ad94ce69e8094d2b9ddae97a3d261945886c0a61
They were added in bug 1427344 to reduce the differences between builds
on CentOS docker images and builds on Debian docker images. We're now
entirely on Debian docker images, so we can back this out.
--HG--
extra : rebase_source : 672e389cb8d6dbf7860a989024690de18e5c320e
As of bug 1430036 it was only set when building on CentOS, and as of bug
1432398, we don't have CentOS-based docker images anymore.
--HG--
extra : rebase_source : 5ade9bee773bca3283cfdb9d69209033fe82253f
It's been more than two weeks since the 1.23 stable release, and
we're making official builds with that toolchain release, so begin
requiring that version so new language features can be used in
development.
MozReview-Commit-ID: E6WuP41ceTn
--HG--
extra : rebase_source : 75850dd9edbf8e3f9beab394e4af7fad76ce3b17
We add a wrapper for llvm-dsymutil for macosx CI builds such that when
it crashes, we attempt to get a reduced test case and upload it as a
build artifact. This will allow to more easily report such crashes
upstream.
--HG--
extra : rebase_source : be208e6a46b60659a4e51acbe2bd7c4081189d1c
By default, wget prints dots every 1k bytes. This can render a
lot of output for large files. We switch to the "mega" style, which
makes each dot represent 64k, thus reducing output by up to 64x.
We also force the use of dot display. By default, it uses "bar"
which attempts to use terminal formatting if possible. Since most
of this code executes in CI and terminal control characters can
interfere with logged output, we force the use of "dot." (Although
wget appears to automatically switch to dot in TC today. But
consistency is good.)
MozReview-Commit-ID: IpTWJdcauTV
--HG--
extra : rebase_source : 5c9aa1bbdcd78eaa0b31347ad026a2c1beaedc03
There were a few constraints in the choice of the version of dpkg to
backport:
- 1.17.20 is the first version that supports the debian source format
for that xz-utils package.
- versions >= 1.17.10 and <= 1.17.22 fail to build on wheezy.
- versions >= 1.17.21 depend on a version of patch not available on
wheezy.
All in all, the simpler choice was to go with version 1.17.20 with a
backport of the build failure fix.
That version of dpkg breaks the version of devscripts in wheezy, so the
version from wheezy-backports would be better to use, but we can't
unconditionally use it on all builds, because it happens that
mk-build-deps from that version is broken with the dpkg in wheezy.
In the end, it's simpler to build that backport and rely on package task
dependencies rather than selectively install the package from
wheezy-backports, so we do that. Except we can't use version
2.14.11~bpo70+1 because of bug 1419577.
--HG--
extra : rebase_source : 19ad1a44b770229fbc7e15bbcf01d3cb101315a8
In many cases, building docker images starts on machines that don't have
a cached checkout, and it often takes forever to get a full clone. It
used to be worsened when 3 jobs could run at the same time because the
worker would start up clean, and 3 jobs would be doing a mercurial clone
at the same time, thrashing I/O, but that part is fortunately fixed.
It is still, however, appreciable not to waste time in the mercurial
clone part of image creation.
--HG--
extra : rebase_source : 8c76bc91e1d5102f68c43e1050d61971fef32e9f
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : 5547e2c8fbf4e2e87182b8720d8352c131e4ec65
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
In many cases, building docker images starts on machines that don't have
a cached checkout, and it often takes forever to get a full clone. It
used to be worsened when 3 jobs could run at the same time because the
worker would start up clean, and 3 jobs would be doing a mercurial clone
at the same time, thrashing I/O, but that part is fortunately fixed.
It is still, however, appreciable not to waste time in the mercurial
clone part of image creation.
--HG--
extra : rebase_source : bbe8b001849e59bb655bb0e9766a6071ad38a52c
The one available in Debian wheezy is 3.81, but we're explicitly using
4.0 on CentOS, most notably because of its --output-sync option which
helps make logs better in some ways.
This takes the package from Debian jessie and builds it for Debian
wheezy.
--HG--
extra : rebase_source : 20bb550703fec41ed0175ef7f78c5b9a394160f3
Switching to Debian build images will force a version bump from
pulseaudio 0.9.something to pulseaudio 2.0. Practically speaking, as
long as bug 1427150 is fixed (which it is), this is strictly better,
because this enables all the PA_CHECK_VERSION(2,0,0) code in libcubeb,
which handles port availability (whether output is plugged or not), and
with bug 1427150, it does so in a backward compatible manner.
Now, since this is a behavior change from what we're currently shipping,
this has the potential of triggering unexpected test failures, or break
sound for users. The likelyhood of the latter happening is rather low,
though, because Linux distros have been building with pulseaudio >= 2.0
for a long time and we haven't heard about port availability breaking
sound for them. But it's still better to decouple this change from the
switch to Debian.
We abuse the build-gtk3.sh script which installs gtk3 in the CentOS
build image to install pulseaudio as well.
--HG--
extra : rebase_source : eb4e4033c50d59117b5199d1653d85f871503b2f
Jim Chen
Emilio Cobos Álvarez
Jeremy Chen
Cosmin Sabou
Mike Hommey
Chris Manchester
Sylvestre Ledru
Ralph Giles
Margareta Eliza Balazs
Andreea Pavel
Dorel Luca
Andi-Bogdan Postelnicu
Ryan VanderMeulen
Gregory Szorc
Tom Ritter
Xidorn Quan
Tiberius Oros
Noemi Erli
Dustin J. Mitchell
shindli
Nick Alexander
Kartikaya Gupta
Chris Peterson