Last time we updated the requirements was in bug 1278456, after we
switched to GTK+3.
While it might be worth checking what would be a reasonable requirement,
the immediate problem is that updating ANGLE hits a snag with a
libstdc++ 4.7 symbol, and the only main distro release that bumping to
that version would make us not support anymore is Ubuntu 12.04 LTS,
EOLed 2 years ago (April 2017).
Bumping to some even newer version would need more consideration.
Desupporting Ubuntu 12.04 LTS at this point is almost a no-brainer.
Differential Revision: https://phabricator.services.mozilla.com/D23979
--HG--
extra : moz-landing-system : lando
Newer versions of rust come with a specialized arm target that matches
more closely our armv7 targets (with neon and thumb2), so use that when
possible.
Depends on D24324
Differential Revision: https://phabricator.services.mozilla.com/D24325
--HG--
extra : moz-landing-system : lando
Changed the following:
- Use (Yn) instead of [Y/n] to align with mercurial-setup that is using
mercurial's ui class
- Use (Yn) prompt instead of int prompt where the options are Yes/No
- Remove empty lines around options to align with the first question
about Firefox {Desktop,Mobile} {,non-}Artifact
- Move the question `Would you like to enable build system telemetry?`
to the last line
- Use `Your choice:` propmt for int prompt to align with the first question
Differential Revision: https://phabricator.services.mozilla.com/D23457
--HG--
extra : moz-landing-system : lando
- Do not use `ERROR` when user enters possibly parent-directory when
choosing the directory to clone mozilla-unified
- Show the path of pre-existing mozilla-unified path on error
Differential Revision: https://phabricator.services.mozilla.com/D23456
--HG--
extra : moz-landing-system : lando
Sometimes tools install pypi at runtime via mach (e.g self.install_pip_package
/ self.install_pip_requirements). It's difficult to test these modules with
pytest because we usually won't be going through mach.
This gives tests the ability to depend on external pypi packages the same way
they might get installed when running via mach.
Note, I only added support for requirements.txt here because
python/mozbuild/mozbuild/virtualenv.py's 'install_pip_package' function is
completely busted with modern pip. And the pip used with |mach python-test| is
more modern than the one used with the regular build venv due to pipenv. We'll
need to fix this eventually, but that's another bug for another day.
Differential Revision: https://phabricator.services.mozilla.com/D22784
--HG--
extra : moz-landing-system : lando
Bug 1528123 added a way to specify a task id to influence mach
artifact. In the case of upcoming EME-enabled win64-aarch64 builds, we
need to be able to specify two different task ids, which a single
environment variable doesn't really allow.
So extend the scheme to check environment variables with the build
type included in the variable name.
Differential Revision: https://phabricator.services.mozilla.com/D23101
--HG--
extra : moz-landing-system : lando
Instead of over-estimating the number of items in a batch, do the opposite:
slightly under-estimate the number of items, then dispatch outstanding items
(by just adding one item to each batch).
Differential Revision: https://phabricator.services.mozilla.com/D23141
--HG--
extra : moz-landing-system : lando
Parts of this patch were taken from the original work of :bbouvier in Bug 1521772.
We needed to revert Bug 1521772 since it broken Windows compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D23100
--HG--
extra : moz-landing-system : lando
Flake8 ignores the 'exclude' section of the .flake8.yml if you pass in a direct
path to a file. To get around this we have some custom logic to handle these
exclusions for us, but this custom logic didn't account for globs.
Differential Revision: https://phabricator.services.mozilla.com/D23145
--HG--
extra : moz-landing-system : lando
It's occasionally useful to know what versions are being discovered for
these variables. It's also convenient for logs from automation to
contain all the relevant information, rather than setting up a loaner
and running all the commands yourself.
Differential Revision: https://phabricator.services.mozilla.com/D22385
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
Andi-Bogdan Postelnicu
Geoff Brown
Mike Hommey
Bastien Abadie
Ciure Andrei
Tooru Fujisawa
Nicholas Cowles
Jason Kratzer
Francesco Lodolo (:flod)
Christian Frey
Thomas Daede
Sylvestre Ledru
shindli
Yuan Cheng
Coroiu Cristina
Alvaro Serero
Dustin J. Mitchell
Andrew Halberstadt
Gurzau Raul
Benjamin Bouvier
Aki Sasaki
Nathan Froyd
Jason Laster
Brindusan Cristian