Before, virtualenv.py may have attempted to use 3rd party
(untrusted) pip indices when installing wheels for pip,
setuptools, and wheel. These dependencies are vendored in
the tree for a reason. So don't let virtualenv contact the
outside world.
MozReview-Commit-ID: 6BCU0WegJO1
--HG--
extra : rebase_source : 6231235486e8cfa784e67e8b18004dd63d8aaf36
While we're addressing virtualenv foo, let's ensure we are running
the latest version. This also pulls in newer versions of pip (8.1.1),
setuptools (20.3), and wheel (0.29.0).
MozReview-Commit-ID: G5uSy66Kd6u
--HG--
extra : rebase_source : 804f230adcf77335c79a93537d9623ac3836d9bf
This makes "display: -webkit-box" & "display: -webkit-inline-box" into bona
fide "display" values (instead of just aliases), when webkit prefix support is
enabled, and allows us to actually exercise the code added in the earlier
patches on this bug. (Note that when webkit prefix support is *disabled*, our
CSS Unprefixing Service strategy will instead have an opportunity to take
effect, for whitelisted sites, and it'll continue to convert "-webkit-box" to
"flex".)
MozReview-Commit-ID: BV93xs4ddbK
These new enum values are added with same behavior as their modern flexbox
equivalents -- they're hooked up to NS_NewFlexContainerFrame, and they're
listed alongside the modern flexbox enums in 'switch' & 'if' statements.
There's one exception, which I call out with a comment at the end of the patch:
we don't treat -webkit-box the same as flexbox in IsFlexOrGridDisplayType(),
because that method is used to determine whether we should blockify
inline-level children of a flex/grid container, and we don't want to blockify
any children of a -webkit-box. (Instead, we want to wrap them in an anonymous
flex item. That happens in the next patch.)
MozReview-Commit-ID: 9BB4Ib2KpvE
This commit switches Windows builds from Visual Studio 2013
to Visual Studio 2015 Update 1.
Previously, Visual Studio was installed on the builders as part
of the base system image. Starting with this commit, we obtain
Visual Studio from a pre-generated, self-contained archive
containing the executables, Windows SDK, and other support
files. This means that new Windows toolchains can be installed
without having to modify configuration of machines in automation!
The mozconfigs for Visual Studio 2015 are a bit different from
existing mozconfigs.
Because it appears to be completely redundant and not necessary,
the LIBPATH variable has been dropped.
The order of paths in PATH, LIB, and INCLUDE has changed. The new
order more accurately reflects what would be defined by
vcvarsall.bat.
As part of switching to Visual Studio 2015, the Universal CRT is
now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR
to define the location to those files.
The switch to Visual Studio 2015 also involves the switch from
the Windows 8.1 SDK to the Windows 10 SDK. However, we still
target an old version of Windows, so this hopefully shouldn't
have any significant fallout.
It's worth noting that switching to Visual Studio 2015 makes
builds - especially PGO builds - significantly faster. Our
PGO build times in automation are ~1 hour faster. Our regular
builds appear to be a few minutes faster.
MozReview-Commit-ID: Pa5GW8V87Q
--HG--
extra : rebase_source : bff4fad17f781d8d21bdb941bdd500955d1e9f08
extra : amend_source : faa3038c290fdf5cdd3e24a45ba2a37490f68c17
extra : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
According to dbaron, the deleted block smells like a workaround for
a compiler bug which no longer reproduces in VS2015. This is the last
bug blocking the landing of VS2015. So remove the apparent workaround.
MozReview-Commit-ID: zsmfFjSOxN
--HG--
extra : rebase_source : e1be788c637b7b60a05e1827411cb5838bb68b35
extra : amend_source : f35410b864f8b23def2c2b4f7468738889a2a7d0
End state is Waldo's original patch, which so far has been the only
version that compiles on VS2015.
MozReview-Commit-ID: FCOaEvMqYB4
--HG--
extra : rebase_source : 2ee6e5ec7578b2dedb2f57a0f6df4ce50e191d98
As B2G has been moved to Tier 3, we are turning phone builds off. Only
nexus-5l-eng, aries-eng and aries-debug remain.
--HG--
extra : rebase_source : a8cb8d4d939d1163e9d681290116b59a1ec85e4d
Modify the congruentTo method of MDiv and MMod opcodes to take into
account signedness, which is necessary for correct code generation.
--HG--
extra : rebase_source : 73037989ae280384c9bb2fd21f5e58243f06da4f
Since the minidump path can be overridden programmatically in the chrome
process, using that path as the base for .extra files won't work since content
is unaware of it.
This patch changes everything to use the temp path when MOZ_CONTENT_SANDBOX is
not defined or when sandboxing is disabled via pref. It also moves the derivation
of the content temp path out of exception context on Windows and Mac, as I
found out that those functions touch the heap.
I also noticed that xpcshell is not sandbox-aware when utilized as a parent
process. I've filed bug 1257098 to take care of that, but this patch includes a
hack for the immediate term.
MozReview-Commit-ID: 3SIB5Nihqxh
--HG--
extra : rebase_source : f4f83c4474f12ececa34e9dda68fc19abc56a899
So far we've simply assumed that the first MPEG Layer 3 frame sync we find is automatically valid. However if the audio data has been improperly cut, parsing might start somewhere in mid-stream, so the first frame sync we hit upon might be a false positive. This naturally leads to problems if we try to check later frame syncs for consistency (same MPEG version, sample rate, etc.) with that first frame sync.
Therefore, this patch changes demuxer initialisation to only accept a frame sync if it is followed by a number of further frame syncs consistent with the initial frame.
