Bug 1553584 was filed and shows a race condition in the test harness that could make fixing bugs difficult. Bumping these back to tier-3 until that can be fixed.
Differential Revision: https://phabricator.services.mozilla.com/D32240
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Changes:
- edited `linux32-tests` to include only web-platform-tests
- removed references to other `linux32` platforms from `test-platforms.yml` other than `linux32-shippable/opt`
Differential Revision: https://phabricator.services.mozilla.com/D29792
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
This will match the compiler version Tor would like. We backport several
llvm-objcopy patches that landed right after the 8 branch though. We
also grab some upstream changes from mingw-clang in the build script
Differential Revision: https://phabricator.services.mozilla.com/D31347
--HG--
extra : moz-landing-system : lando
This patch runs wpt against opt and debug builds of geckoview as tier-2 jobs on mozilla-central and try.
Differential Revision: https://phabricator.services.mozilla.com/D31581
--HG--
extra : moz-landing-system : lando
This adds a new set of update tasks and channels for testing updates from the
previous ESR release, before we make the new release generally available as an
update.
Differential Revision: https://phabricator.services.mozilla.com/D31654
--HG--
extra : moz-landing-system : lando
ESR 68.2 is going to be the watershed for bz2 updates, so generate them for the
moment.
Differential Revision: https://phabricator.services.mozilla.com/D31652
--HG--
extra : moz-landing-system : lando
When the logic was switched to be by release-type, rc's were accidentally
excluded.
Differential Revision: https://phabricator.services.mozilla.com/D31587
--HG--
extra : moz-landing-system : lando
Stub installers aren't generated on esr branches; the repackage task includes
metadata indicating this. Use this information to filter out upstream artifacts
when use declarative artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D31586
--HG--
extra : moz-landing-system : lando
When snaps started being packaged on archive.mozilla.org, the `build_platform`
of the snap repackge task changed, causing the beetmover dependencies to be
dropped. Switch the platform back so that the dependencies are restored.
Differential Revision: https://phabricator.services.mozilla.com/D31585
--HG--
extra : moz-landing-system : lando
we're looking to reduce costs on infra. as parallel gcp builds have served their purpose of demonstrating they are possible and valid, we'd now like to disable them until a later date.
Differential Revision: https://phabricator.services.mozilla.com/D31655
--HG--
extra : moz-landing-system : lando
These chunks are quite out of balance: Probably there are some very long running
tests in xpcshell-7 with 8 chunks. Even so, I think the easiest way to avoid timeouts
is to return to 12 chunks.
Differential Revision: https://phabricator.services.mozilla.com/D31685
--HG--
extra : moz-landing-system : lando
We need this to auto-generate the copy-constructor for TransformOperation,
without which the patch wouldn't build.
Differential Revision: https://phabricator.services.mozilla.com/D30799
--HG--
extra : moz-landing-system : lando
a17faa0e5bf8f1680c750e81a5424715a7825387 switchted to pulling the channel from
the update-verify-config task, and missed removing the setting for
secondary-update-verify.
Differential Revision: https://phabricator.services.mozilla.com/D31512
--HG--
extra : moz-landing-system : lando
