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
Before this change linting python/mozbuild brought about many errors. Some of this errors could be fixed using |mach lint --fix|. The remaining errors where fixed in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D20138
--HG--
extra : rebase_source : 8bd3d622d2221b981f08b8a080c1198b002cdc49
extra : amend_source : 3f6a70c1b7104a7c2d83e11fe911942771e331ea
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
The underlying backends only support directories in LOCAL_INCLUDES
(since these ultimately translate to -I arguments to the compiler). We
should disallow filenames here, in case a developer accidentally
specifies a header file instead of a directory.
Differential Revision: https://phabricator.services.mozilla.com/D21698
--HG--
extra : moz-landing-system : lando
After landing bug 1515004, it is unnecessary to use `--with-android-sdk` when
developer uses default path of Android SDK by `./mach bootstrap`.
So let's remove `--with-android-sdk` from mozconfig example using
`./mach bootstrap`.
Differential Revision: https://phabricator.services.mozilla.com/D20601
--HG--
extra : moz-landing-system : lando
In cases like those in the added unit test, explicit options on the
command line could end up being silently ignored. So instead of that happening,
error out. Unfortunately, the error message is not entirely accurate,
but it's better than nothing. It's rare anyways (I only stumbled upon it
because I was trying to do something fishy), and correlation between the
error message and the corresponding changes should make it clear what's
going on.
Depends on D20822
Differential Revision: https://phabricator.services.mozilla.com/D20823
--HG--
extra : moz-landing-system : lando
Currently, when a dependency loop involve imply_option, it is possible
to end up with an error message saying the implied option is unknown,
when it fact it is. So instead of bailing out with a weird error
message, try to make things work (if the implied value is not different
from what's known), or bail with a more accurate message.
Differential Revision: https://phabricator.services.mozilla.com/D20822
--HG--
extra : moz-landing-system : lando
Optimizing jars without preloading/reordering data only moves the
jar central directory to the beginning of the file, which, without
preloading information, is not very useful. Let's just stop doing it if
there's not going to be preloading/reordering information at all.
Differential Revision: https://phabricator.services.mozilla.com/D21170
--HG--
extra : moz-landing-system : lando
On Android we apparently try to include the cpufeatures.c file from the
NDK as part of the generated-sources tarball. While this works, it makes
tar drop the bogus entry for safety reasons when unpacking the archive.
It also makes tar return an error, which is undesirable for searchfox.
It's better to just skip the entry when building the tarball.
Differential Revision: https://phabricator.services.mozilla.com/D20942
--HG--
extra : moz-landing-system : lando
For mach commands that have 'pass_context=True', we should implicitly add the
handler instance to the context. This will give mach command implementations an
easy way to access things like the command/subcommand names, the parser, argv
list, etc.
Differential Revision: https://phabricator.services.mozilla.com/D20521
--HG--
extra : moz-landing-system : lando
This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.
We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D18138
--HG--
extra : moz-landing-system : lando
The motivations for this are:
1) Apply global excludes. This merges the exclusion rules defined in
tools/lint/mach_commands.py with the ones in .flake8.
2) Improve performance. Switching to a blacklist will result in a much longer
runtime for linting the entire tree and flake8 handles exclusions incredibly
slowly. Without this patch (and the blacklist change applied), I gave up
waiting after 30 minutes. With this patch, it takes 30 seconds.
Depends on D20495
Differential Revision: https://phabricator.services.mozilla.com/D20496
--HG--
rename : tools/lint/test/files/flake8/bad.py => tools/lint/test/files/flake8/subdir/exclude/bad.py
extra : moz-landing-system : lando
This will be re-used by the flake8 linter, so moving it into mozlint for
re-useability.
Depends on D20493
Differential Revision: https://phabricator.services.mozilla.com/D20494
--HG--
extra : moz-landing-system : lando
Instead of having cache misses for all variables that may vary when
getting job details. While the currently used variables are mostly
constants, we're going to introduce some flexibility in an subsequent
change.
Depends on D20443
Differential Revision: https://phabricator.services.mozilla.com/D20444
--HG--
extra : moz-landing-system : lando
Once all tests regexp are gone, we come to realize that all the package
regexp are the same for each ArtifactJob subclass, some we move the
definitions to the subclasses.
Depends on D20442
Differential Revision: https://phabricator.services.mozilla.com/D20443
--HG--
extra : moz-landing-system : lando
Once the firefox-* and fennec-* regexp are gone, we come to realize
that all jobs have the same regexp for tests, so we can just
use that across the board and remove the definition from JOB_DETAILS.
Depends on D20441
Differential Revision: https://phabricator.services.mozilla.com/D20442
--HG--
extra : moz-landing-system : lando
The filters were added back when buildbot was still used, and some
artifacts were still using file names beginning with "firefox" or
"fennec".
That is not true now that all builds are on taskcluster, and for all of
them, they are now target.$ext.
Differential Revision: https://phabricator.services.mozilla.com/D20441
--HG--
extra : moz-landing-system : lando
Translating most string from pageInfo.properties and making pageInfo.js and security.js use Fluent
Differential Revision: https://phabricator.services.mozilla.com/D16931
--HG--
extra : moz-landing-system : lando
On CI, Windows builds start from different directories on every build,
except when sccache is enabled. This affects many build types, such as
l10n repacks, and the preprocessor likes to put full paths in its
output, which means it includes those different directories, making the
builds non reproducible.
This changes the preprocessor to replace the source and object
directories with generic strings.
Differential Revision: https://phabricator.services.mozilla.com/D20421
--HG--
extra : moz-landing-system : lando
This will avoid trying to generate them during artifact builds.
Depends on D20587
Differential Revision: https://phabricator.services.mozilla.com/D20436
--HG--
extra : moz-landing-system : lando
In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.
It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.
Differential Revision: https://phabricator.services.mozilla.com/D19937
Since bug 1522788, mach invokes a part of configure as part of getting
mozconfig and target information for its own purpose. The problem is
that the sandboxed code may sys.exit(), which then makes mach silently
exit.
So when the sandboxed configure code does sys.exit(), instead of
silently failing, we catch the exit call, and print out what we
captured.
Differential Revision: https://phabricator.services.mozilla.com/D19936
Currently, artifact builds pull from some task they determine from the
job type, and finding a pushhead.
Sometimes that latter fails, most notably on automation. But automation
can already know the right task to use without guesswork.
This change allows artifact builds to pull from a specific taskid given
through an environment variable, and make tasks from the artifact-build
kind (not the --artifact builds from try) use that.
Remove the workaround from bug 1382982 because it's now dead code.
Differential Revision: https://phabricator.services.mozilla.com/D19881
Translating most string from pageInfo.properties and making pageInfo.js and security.js use Fluent
Differential Revision: https://phabricator.services.mozilla.com/D16931
--HG--
extra : moz-landing-system : lando
Turns out hg diff works differently, and when Miko tried to use this
option last week he realized it didn't work quite as expected.
Differential Revision: https://phabricator.services.mozilla.com/D20102
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
lib32-libstdc++5 moved from multilib to AUR, but it seems like we don't
need this anymore anyway.
Differential Revision: https://phabricator.services.mozilla.com/D19276
--HG--
extra : moz-landing-system : lando
There are cases that can be easily detected where an undefined variable
is used, and such mistakes seem to happen more often than they should,
as all the errors fixed in the previous patches (that this new lint
caught).
Depends on D19112
Differential Revision: https://phabricator.services.mozilla.com/D19113
--HG--
extra : moz-landing-system : lando
Currently, running the configure lint will raise errors with little
context, if any, which can make finding the cause of the errors tedious.
So instead of raising exceptions directly, we use a hack to make the
exception appear as if they had been thrown at the code location an
issue is reported for, which makes the test harness print more useful
context.
With more context, printed out, some exception messages can be made
lighter.
The added _raise_from method does more than is necessary here, but will
be fully used in a new check shortly.
Depends on D19111
Differential Revision: https://phabricator.services.mozilla.com/D19112
--HG--
extra : moz-landing-system : lando
Using the `assert` keyword actually generates bytecode that uses the
`AssertionError` class under the hood. Ideally, we should probably not
use asserts in python configure, but there are currently so many that
it's easier to allow it, until a better strategy is decided upon.
Depends on D19110
Differential Revision: https://phabricator.services.mozilla.com/D19111
--HG--
extra : moz-landing-system : lando
In upcoming changes, we're going to use the normal compiler flags for
bindgen instead of having a separate logic for essentially the same
flags (and there's not much reason not to use the same flags after all).
One hiccup, though is that for some reason, --target=i686-linux-gnu
doesn't work with bindgen while it works with clang in the same setup.
But -m32 does.
Considering -m32 and -m64 are standard flags and that we're using them
in many cases, it doesn't hurt to use them instead of --target with
clang.
While we're doing that, we might as well refactor a little to avoid the
multiple branches handling the use of -m32/-m64, and fix the theoretical
compile-x86_64-with-x86-clang-cl case, as well as the weird check for
aarch64.
And because only two cases actually require -Xclang, only one of which
requires a condition, and the control flow is not too complex to avoid
flag duplication, we just remove the append_flag function; it was too
confusing, with all the cases we skipped it when -Xclang was not wanted.
Differential Revision: https://phabricator.services.mozilla.com/D18316
--HG--
extra : moz-landing-system : lando
Convert resetProfile.dtd to resetProfile.ftl. Modify dependencies for resetProfile.xul, safeMode.xul, aboutSupport.xhtml.
Differential Revision: https://phabricator.services.mozilla.com/D17416
--HG--
extra : moz-landing-system : lando
Sometimes we want to store state that only applies to a particular srcdir, but
there isn't a standard directory where this lives. Let's add an argument to
'get_state_dir()' to provide an "official" place.
The new API to get the local state dir is 'get_state_dir(srcdir=True)'. Like
the global state dir, this directory is not guaranteed to exist. A reference to
this value can also be obtained via 'self._mach_context.local_state_dir' from
within a mach command (in this case it will be created automatically if it
doesn't exist).
Note: we should probably just make sure both exist at mach startup, but it felt
outside the scope of this change.
Differential Revision: https://phabricator.services.mozilla.com/D15724
--HG--
extra : moz-landing-system : lando
mozboot.util.get_state_dir() returns a tuple of (<path>, <bool). The bool
denotes whether or not the state dir came from an environment variable.
But this value is only used in a single place, and is very easy to test for
anyway. It's not worth the added complexity it imposes on all other consumers
of this function. Let's just make this function return the path.
Differential Revision: https://phabricator.services.mozilla.com/D15723
--HG--
extra : moz-landing-system : lando
Also use armv7a as the default when no target is given at all.
Also change bootstrap to create a simpler mozconfig. The downside is
that the resulting mozconfig would not work when building older
revisions.
Add unit tests for this as well as the simplications added in bug
1523341.
Differential Revision: https://phabricator.services.mozilla.com/D17906
--HG--
extra : moz-landing-system : lando
Chris Manchester
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
David Walsh
Axel Hecht
kerlyn
Mike Shal
Sebastian Hengst
Cosmin Sabou
Daniel Varga
Makoto Kato
Kartikaya Gupta
Panos Astithas
Ted Mielczarek
Oana Pop Rus
Marco Castelluccio
Csoregi Natalia
Emilio Cobos Álvarez
Dorel Luca
Jeff Gilbert
arthur.iakab
Kris Maglione
Kai Engert
Nabil Lamrabet
Razvan Maries
Paolo Amadini
Nathan Froyd
Justin Wood
Brian
Tom Prince
Tom Ritter
Avery Berninger