The OSX linker apparently decides on its own to link against system
frameworks. We end up with libxul linked to 6 frameworks that were never
given on the command line, and we do use symbols from those.
Interestingly, for those frameworks that don't appear on the command
line, there is no determinism in how stubs for lazy bindings (equivalent
to Linux's PLT, AIUI) are laid out in the binary. But for those that do
appear on the command line, the layout is deterministic.
So add those frameworks to the command line.
With this change, the remaining difference between two builds of the
same changeset on try is due to symbol tables for profiling. Stripping
those (like we do on beta/release) produces no differences.
--HG--
extra : rebase_source : 151342f3c0067c16c26e111247f6da58f4b639be
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
We only had this "for flexibility with other platforms", but given that
we set it to the same thing for all platforms, and nobody has tried to
change that, this flexibility isn't actually needed.
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : f7582d7089f0f4582a02aeaef090dc0701df994d
It's no longer used, and won't be able to work with the removal of speech synth direct audio support.
MozReview-Commit-ID: BMdeRJHes0R
--HG--
extra : rebase_source : 9f45b360d27f8013ef229eba79e9d9921d0fdb26
It's no longer used, and won't be able to work with the removal of speech synth direct audio support.
MozReview-Commit-ID: BMdeRJHes0R
--HG--
extra : rebase_source : 9f45b360d27f8013ef229eba79e9d9921d0fdb26
This work around is required when using icecream distributed compilers. Icecream doesn't pass the original filename that would allow the remote clang to automatically determine the language type.
MozReview-Commit-ID: LMs022jDkPt
--HG--
extra : rebase_source : d3d43c29f0e2cf91a29677a1e827463f9e0a9f1d
Preserving the MOZ_MACBUNDLE_ID will avoid issue related to bundle identifier
MozReview-Commit-ID: IDIZGl6usXA
--HG--
extra : rebase_source : b01934cdf8a42d805ae467cc08b5beafb02c0732
We currently turn off the C++14 sized-deallocation facility on MSVC, and
we'd like to ensure we do the same thing for clang and gcc. To do so,
we add new functionality to moz.configure for checking and adding
compilation flags, similar to the facility for checking and adding
warning flags. The newly added facility is then used to add
-fno-sized-deallocation to the compilation flags, when the option is
supported.
Once we do this, we can't define the sized deallocation functions in
mozalloc.h; the compiler will complain that we are using
-fno-sized-deallocation, yet defining these special functions that we'll
never use. These functions were added for MinGW, where we needed to
compile with C++14 ahead of other platforms to be compatible with MSVC
headers. But they're no longer necessary, though they would be if we
removed -fno-sized-deallocation; the compiler will complain if we do
that and we'll add them back at that point.
C5038 is a new warning in VS2017, similar to gcc and clang's -Wreorder, which is enabled by -Wall. We should enable C5038 so Windows developers can see these warnings locally instead of when gcc and clang fail with warnings-as-errors on Try.
https://blogs.msdn.microsoft.com/vcblog/2017/07/21/diagnostic-improvements-in-vs2017-15-3-0/
We need to suppress C5038 warnings from Windows Runtime Library header files (wrl.h) included in ANGLE and widget/windows:
z:\build\build\src\vs2017_15.4.2\SDK\Include\10.0.15063.0\winrt\wrl\wrappers\corewrappers.h(515): error C5038: data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::sync_' will be initialized after data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::status_'
...
And suppress C5038 warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/video_capture/windows/BaseFilter.cpp(176): error C5038: data member 'mozilla::media::BaseFilter::mClsId' will be initialized after data member 'mozilla::media::BaseFilter::mState'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(169): error C5038: data member 'mozilla::media::BasePin::mFilter' will be initialized after data member 'mozilla::media::BasePin::mLock'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(170): error C5038: data member 'mozilla::media::BasePin::mLock' will be initialized after data member 'mozilla::media::BasePin::mName'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(172): error C5038: data member 'mozilla::media::BasePin::mDirection' will be initialized after data member 'mozilla::media::BasePin::mQualitySink'
MozReview-Commit-ID: BMDVkvQXNoq
--HG--
extra : rebase_source : 0d5ede9530d0d0750b8fffdc1cdfdc646ec8f22a
Environment variables for configure don't get automatically propagated
down to js/src on Windows because mingw. So we have to take extra steps.
--HG--
extra : amend_source : fc123e7439ebbf97884eeb56af8409c7b3294b21
This change ensures that folks who configure --with-system-FOO for
various values of FOO can build Stylo, since bindgen will know where to
find the flags for said FOO packages.
Add an intermediate step in old-configure.in for setting up
BINDGEN_CFLAGS (renamed to BINDGEN_SYSTEM_FLAGS), so we can add whatever
flags we like (e.g. for system libaries with their includes in
non-standard places) at a later point.
This class isn't being used right now, and MozURL is a much better alternative if interaction with rust URLs is required.
MozReview-Commit-ID: ADdYRrrTnr6
--HG--
extra : rebase_source : b36aa26c20e7daaadab1f3360bab0ed4681eb7f8
The system ffmpeg will be used instead or libvpx if not found.
MozReview-Commit-ID: GX5WWPOhPq9
--HG--
extra : rebase_source : 3eec2ee1bc3b66d88653b913d6d1b3ad1a5d5acd
Backed out changeset f019d4ffff53 (bug 1414735)for failing Gtest TransportTest.TestCipherMismatch and Xpcshell dom/presentation/tests/xpcshell/test_tcp_control_channel.js tests on a CLOSED TREE r=backout UPGRADE_NSS_RELEASE
Remove the VP8 and VP9 decoder and the subsequently unused functions.
This drops the size to libmozavcodec to around 1MB down from 4MB.
MozReview-Commit-ID: Ge57fauG35L
--HG--
extra : rebase_source : 3f667d7bf89036e9b059727d846af2504ce488b3
For now this is a C decoder only and FFmpeg isn't optimised to only decode flac (both vp8 and vp9 C decoders code is included, however they aren't enabled).
MozReview-Commit-ID: 7ulwvJDJqVg
--HG--
extra : rebase_source : 7090eee32ba394224ef8c3c1c31abf1543b69975
This also introduces C{XX}_LDFLAGS variables which contain cflags that
are meant to be passed to the linker, and adds them to various linker
command lines in place of CFLAGS.
MozReview-Commit-ID: GyKlD9nMqrt
This commit establishes a separate variable to add PROFILE_GEN and PROFILE_USE
CFLAGS to compile and link command lines. Currently the make backend
orchestrates the pgo build steps and is the only thing aware of whether
we're in the profile generate or profile use stage. The flags are separated
here to allow other flags to be moved to mozbuild, but this will not yet
sufficient to perform a PGO build independent of the make backend.
MozReview-Commit-ID: IX30l2MvvNc
When we move to a shell aware split for AC_SUBST_LIST it will become an error
to emit an unquoted make variable reference. Currently this happens to only
occur during artifact builds when setting cflags related variables that aren't
needed there anyway, so here we skip settting those variables when a compile
environment isn't present.
MozReview-Commit-ID: EnHu48yyZ1C
The Rust optimization logic is tied to --enable-optimize/MOZ_OPTIMIZE
and --enable-debug/MOZ_DEBUG. In order to more easily implement more
customization, let's move --enable-optimize/MOZ_OPTIMIZE to
moz.configure so its value can be consulted there.
The logic here is a bit wonky. The option behaves like a boolean
or a string. If a string, MOZ_OPTIMIZE is set to 2. Otherwise it
is 1 or unset depending on the boolean value.
The custom compiler flags string is passed to old-configure, where it
overwrites whatever old-configure derived as the default value.
We stop short of moving all references to MOZ_OPTIMIZE_FLAGS to
moz.configure because there are a handful of them and I don't want
to scope bloat.
MozReview-Commit-ID: 6iNDu2HwLGr
--HG--
extra : rebase_source : a64f1236012d13913f21253df1b9b5ff0ae8ea6e
It is now closer in the file to where other default values are computed.
MozReview-Commit-ID: BffCEb6FAUP
--HG--
extra : rebase_source : 81b17131f9330d89818a36ffff625b672c19c01e
Bug 1365460 introduced code paths behind MOZ_DEBUG #ifdefs, but
MOZ_DEBUG is never defined, while it is available in CONFIG in
moz.builds. This is kind of a confusing situation, but the fact that
we've been able to avoid those problems for so long would tend to
put the blame on mozjemalloc, and fixes should go there.
Except that bug 1261161 explains that the only existing alternative
(the DEBUG #define), as used in MFBT, is not working for spidermonkey,
so it actually makes sense to converge to MOZ_DEBUG rather than DEBUG.
So start defining MOZ_DEBUG globally, fixing the mozjemalloc issues of
not having the debug code enabled. Bug 1261161 can then take care of
changing the DEBUG #ifdefs.
--HG--
extra : rebase_source : 37e3d03ac8350c62c8059d4ca01d1ecfdf5f421a
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : 00715beb5fbd2c11311dec43809bd1febab56a11
extra : intermediate-source : 0f2b1b75b83737378d882a3c3e0d8dfb4efecd1f
extra : source : a8032ae9cb2ad1c4574c6ac6f5c2778863cd71e0
This adds a section in both old-configure.in's for hardening flags.
In old-configure.in we add $HARDENING_CFLAGS (which are turned on by
--enable-hardening) and are defined in toolchain.configure (and
which does compiler detection there.) We then add non-optional
hardening flags, performing compiler detection here.
In js/src/old-configure.in we follow the same pattern, but omit
$HARDENING_CFLAGS because we don't apply the current lone flag
to js (doing so is Bug 1359905).
MozReview-Commit-ID: EFE0Pc7yZHa
--HG--
extra : rebase_source : f793e665cabe3d33bdc73fc8a68208d69b55137a
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c
Nothing in js/ uses TARGET_XPCOM_ABI, so the code in js's configure is
dead. Since TARGET_XPCOM_ABI is a Gecko-only thing, the reasonable
place for it is toolkit/moz.configure.
TARGET_XPCOM depends on TARGET_COMPILER_ABI, and the value of
TARGET_COMPILER_ABI is easily derivable from the current target and
compiler. The only notable change we make in the conversion to
moz.configure is that the ARM old-ABI is no longer supported by any of
our current targets: Android and Linux for ARM targets are both
exclusively EABI nowadays, so we have one less case to worry about.
TARGET_COMPILER_ABI's sole purpose was to provide information for
TARGET_XPCOM_ABI, and since we are deriving TARGET_XPCOM_ABI exclusively
inside moz.configure, we can remove TARGET_COMPILER_ABI.
Use of this define was removed in bug 866988, but is still listed in
non_global_defines.
MozReview-Commit-ID: BIiwlxL6i7i
--HG--
extra : rebase_source : 76488041e4144eccc63854a9267bd42adf3b4a85
Some gaia-related code was also found and removed as part of the
cleanup.
MozReview-Commit-ID: DEjVSljzzu1
--HG--
extra : rebase_source : 58c4c34df44a258d90029853f29ea01338bd142b
This option was added ~decade ago; AFAICT from bug archaeology, the
option was added to prevent our servers from being overwhelmed.
Somewhere over the years, however, we obtained more capable servers and
the option disappeared from mozconfigs. It seems moderately unlikely
that we'll have a need for this option again, and we could reintroduce
this patch very easily in any event. Let's go ahead and remove it.
This is primarily for local builds that use the latest Android SDK.
MozReview-Commit-ID: 5uIjC6EhCho
--HG--
extra : rebase_source : 338caa12cf72a711cf3dbc2fd67df0afef1ef373
This patch does two things:
- add a Gradle-only ANDROID_COMPILE_SDK_VERSION substitution;
- uses it while uniformizing all of the Gradle Android SDK version
configurations.
The approach is fairly standard (and we were using it already); see,
for example
https://medium.com/@ali.muzaffar/gradle-configure-variables-for-all-android-project-modules-in-one-place-5a6e56cd384e
This will make bumping the Gradle configuration versions forward
easier.
MozReview-Commit-ID: 1j5siCvR5qt
--HG--
extra : rebase_source : 07afb00de0e4a72af4026eb19ff4f2530c119336
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
Add the dependency between "MOZ_ENABLE_SKIA_PDF" and "MOZ_TREE_FREETYPE" on Windows:
- let |tree_freetype| returns true if |skia_pdf| returns true on Windows, and
- avoid defining "MOZ_ENABLE_CAIRO_FT" on Windows ("cairo-ft-font.c" includes <dlfcn.h>, which only exists on posix platforms)
MozReview-Commit-ID: 6CWVwzIHL1Q
The linker uses zlib. The linker is in mozglue, zlib is in libxul by
default. As a consequence, we made --with-system-zlib a requirement for
builds enabling the linker.
In the meanwhile, we added an option that makes zlib built in mozglue
for different needs, which, in fact, also allows to do that when the
linker is enabled.
So, allow to build without system zlib when the linker is enabled.
--HG--
extra : rebase_source : 873a87b17b306fc392018049e01cf794b63a6206
For parts of configuring Stylo, we need information about the library
extensions on all of our platforms, and this change is a reasonable way
to get at that information without duplicating it in two places. Plus
moving more things to moz.configure is more better.
Before, MSVS was set in old-configure and could only be unset or
"2015." We move the definition of the variable to moz.configure
and support defining its value as "2017" when VS2017 is being used.
As part of this, I discovered that GYP barfs with a "2017" value.
This is likely a limitation of the legacy version of GYP we have
vendored. Rather than go down the rabbit hole of upgrading GYP,
I added code to convert the value to "2015." This preserves existing
behavior and unblocks us from setting MSVS_VERSION properly. A
warning is emitted to remind us to remove this hack once GYP is
upgraded.
After this commit, we now generate native VS2017 solutions and
projects when building with VS2017.
MozReview-Commit-ID: BvNJX3F8qCn
--HG--
extra : rebase_source : 13a495856a83d9ca7afbb4770ebab1cc7f651cae
The test in old-configure.in for MOZ_REPLACE_MALLOC_LINKAGE runs
dyldinfo, which is a native tool on OSX. We have it in the cross
toolchain as well, but as x86_64-apple-darwin11-dyldinfo. We should use
the TOOLCHAIN_PREFIX here to make sure we get the same result as native
builds.
MozReview-Commit-ID: 3jyzpaM8ZGy
--HG--
extra : rebase_source : fa0d2c1470f8d61b3f31c9a46609d8911ae2ff91
js/src/builtin/Intl.js will spew three C4819 warnings every time non-Western
developers build the tree locally on Windows because of non-ASCII characters
in the file. Usually we have compilers use UTF-8 to prevent this, but it did
not work for Intl.js because embedjs.py did not pass around $CPPFLAGS.
--enable-warnings-as-errors did not catch this because embedjs.py did not
pass around warnings-as-errors flags either.
This patch will fix both issues.
MozReview-Commit-ID: 5D1TCGnIX1T
--HG--
extra : rebase_source : 9f353d46d0a5320f9a0b9be2aea11fb66d6a88b4
-Os generates smaller code, at the expense of performance. On desktop,
this tradeoff is not necessarily the best, especially when considering
the vast performance difference. Most downstream redistributors also
don't do PGO and don't override defaults, so they would tend to ship
slower builds as a consequence.
We however keep -Os as default for debug builds for now, because -O2
triggers -Werror=strict-overflow failures somehow.
--HG--
extra : rebase_source : ad2f4fedb7934b6b23b84412c86b30d29a8fb5f8
-Os generates smaller code, at the expense of performance. On desktop,
this tradeoff is not necessarily the best, especially when considering
the vast performance difference. Most downstream redistributors also
don't do PGO and don't override defaults, so they would tend to ship
slower builds as a consequence.
--HG--
extra : rebase_source : 7d66393d03b9424fdcc46874a09239ffe46cfb33
This intentionally allows to set MOZ_INSTALL_TRACKING without
reference to the milestone being release or beta. That is, we
separate the default value (which depends on release or beta) from the
value specified, making life easier for developers.
MozReview-Commit-ID: 3vPF7KO7fEX
--HG--
extra : rebase_source : 8d5764104b5322a32e4a048bfd3222f62fed73bb
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
The first attempt at this patch in Bug 1314979 turned off the entire
ANGLE section for MINGW builds on Linux for Windows. This was
incorrect, as it also turned off includes of very important files
like d3d11.h
This changes it so we go through the ANGLE section, but if we don't find
a Windows SDK we only consider that an error when we're compiling with
MinGW for Windows _on_ Windows. If the Host and Target OSes don't match
(meaning we're compiling on Linux for Windows) we ignore the lack of a
Windows SDK.
MozReview-Commit-ID: KyggI6yJCEM
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
This flag enables the stack-cookie exploit mitigation for all functions which
manipulate stack-based buffers, providing better protections than
-fstack-protector, at considerably lower performance overhead than
-fstack-protector-all.
r=froydnj
MozReview-Commit-ID: 7ZNAHHAf376
--HG--
extra : rebase_source : 6d5ccbb9537372912c3f5a73fe0fdc65bb68ac08
MINGW builds do not need any of the checks that are performed in the
windows.configure file. Nor do they the D3D compiler DLL that is
needed for ANGLE, so we can skip that entire section in
old-configure.in.
MozReview-Commit-ID: DqufbgGoGy4
--HG--
extra : rebase_source : d5f1ed371f79a8a16f888ccc5d058ac72a69f34f
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : fe3c9480cee468aa2a24fd34e569b58e4f2c9c9a
It looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
Android/x86 runs xpcshell and a limited of mochitest. These tests are already passed on m-c.
MozReview-Commit-ID: 7Qkqi0dYh95
--HG--
extra : rebase_source : 4cc064aea022a8ba17d9a78a1f36a612ab877898
Now that we don't support XP it's reasonable for us to drop support for GDI
fonts and rely solely on DirectWrite. We should start this process by removing
support for building without DirectWrite.
Until we have the ability to properly make these flags conditional in
moz.configure, do not perform these checks.
MozReview-Commit-ID: CexvgiadIw0
--HG--
extra : rebase_source : 3944a7c98a6570bf0f30dc01a9d895cc07cc0ff1
Mike Hommey
Sylvestre Ledru
Andreea Pavel
David Major
Nathan Froyd
Nathan Froyd
Tom Prince
Dorel Luca
Gurzau Raul
Ryan VanderMeulen
Cosmin Sabou
Tom Ritter
Henri Sivonen
Jean-Yves Avenard
arthur.iakab
Sebastian Hengst
Bogdan Tara
Petr Sumbera
Gabriele Svelto
Noemi Erli
Chris Peterson
Chris Manchester
Franziskus Kiefer
Valentin Gosu
Masatoshi Kimura
Martin Thomson
Csoregi Natalia
Daniel Holbert
Nick Alexander
Gregory Szorc
Ted Mielczarek
Jan Henning
Glenn Randers-Pehrson
Mike Shal
Ting-Yu Lin
Kai Engert
Liang Wei
Wes Kocher
Jon Coppeard
Nevin Chen
Eric Rahm
Carsten "Tomcat" Book
mozilla@mozilla-23773
Zibi Braniecki
Sebastian Kaspari
Marco Castelluccio
Makoto Kato
Bruce Sun
Mike Taylor
Stephen A Pohl
Ben Hearsum
Paolo Amadini
Jan Beich
Ralph Giles
Alex Gaynor
Iris Hsiao
Andrzej Hunt
Dão Gottwald
Jeff Muizelaar
David Anderson