When calling Mach, it was prefixed with the `srcdir`, even though the
`srcdir` was also the working directory of the invocation. This caused
the invocation to fail.
Differential Revision: https://phabricator.services.mozilla.com/D140400
Inconsistency confuses some of our tools. As part of this, I:
* Updated some docs to point to rust-minidump
* Added a fallback to mozcrash.py to try both versions
* Make mozcrash.py use --brief output when the local mdsw is used
* Remove the renaming hack from build-minidump-stackwalk.sh
This isn't as simple as a sed because we still have breakpad in tree
for minidump-analyzer. I did my best to replace the right strings.
Differential Revision: https://phabricator.services.mozilla.com/D138971
Python 3.10 prints a warning when it sees `distutils` used, so let's
avoid using `distutils` in the "common Mach code" that runs on every
Mach call.
Note that this change will also fix the `SetuptoolsDeprecationWarning`
that shipped on `setuptools>=58.3.0`, since our usage of `distutils` was
calling a `setup.py install` under the hood.
Differential Revision: https://phabricator.services.mozilla.com/D137499
The main difference between `OSXBootstrapperLight` and `OSXBootstrapper`
is that the "light" one doesn't install utilities via `brew`.
However, these utilities are all optional for builds (`watchman`,
`terminal-notifier`, etc).
Since arm macOS + Rosetta + brew installs are failing (because brew is
complaining that the "ARM prefix" is being used in a Rosetta context),
the solution provided by this patch is to avoid using `brew` in this
case.
Differential Revision: https://phabricator.services.mozilla.com/D137661
Currently, developers don't have a way to have the Mach virtualenv
re-attempt to install optional dependencies (such as `glean`).
As part of `./mach bootstrap` (the general catch-all "re-create my dev
environment" command), we should retry installing optional dependencies.
This also matches the "glean isn't installed" error message
recommendation.
Note: This doesn't address the case in which command virtualenvs
need their optional dependencies attempted to be reinstalled.
However, since we don't have any such cases yet, I'm satisfied with
deferring that work.
Differential Revision: https://phabricator.services.mozilla.com/D123242
What this function does can easily be a one-liner now that we're using
Pathlib, so both calls to it have been replaced by said one-liner.
Differential Revision: https://phabricator.services.mozilla.com/D135263
This uses the same trick as bug 1743832 under the hood. We could go the
other way around, extracting the configure code to a separate module,
but the longer term goal here is to have configure figure out which
things to bootstrap for the selected build type.
As a side effect, mach bootstrap will stop re-bootstrapping things that
are already up-to-date, at least for things using
install_toolchain_artifact, excluding those that don't follow the
convention wrt the extracted directory path.
Differential Revision: https://phabricator.services.mozilla.com/D134595
Also update the table of Firefox requirements. It's worth noting that I
actually upgraded to 1.57 earlier than I should have (too close to
freeze), but what is done is done.
Differential Revision: https://phabricator.services.mozilla.com/D134124
Without this change, on systems that use `dnf` (such as Fedora),
`mach bootstrap` will prompt for the sudo password to install packages and
groups that have already been installed. Making this change will help get
`mach bootstrap` to a point where it can be run without prompting for user
input when we can avoid doing that.
Differential Revision: https://phabricator.services.mozilla.com/D132816
Fedora 33 is now EOL. Fedora 34 and 35 now both use the package name
'python3-devel', not 'python-devel'. Although 'python-devel' is aliased to
'python3-devel' for `dnf install`, it is not aliased for other commands such as
`dnf info`. That defeats the purpose of fixing bug 1744277 unless we also fix
this issue.
Differential Revision: https://phabricator.services.mozilla.com/D132815
We already use the adoptopenjdk on some platforms, this allows us to have a
more predictable Java binary on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D130878
Build and run the Mach virtualenv from a `state_dir` that is
"specific-to-topsrcdir".
As part of this, move `get_state_dir()` to `mach` so that it's usable
before `sys.path` entries are fully set up.
Differential Revision: https://phabricator.services.mozilla.com/D130383
The modified script :
1. Guides the user after the first successful clone to opt for './mach bootstrap', if the user wants to re do the tooling bootstrapping.
2. Prompts the user an option to remove the standalone 'bootstrap.py' script as it isn't required anymore.
3. Guides the user to run './mach bootstrap' instead of 'python3 bootstrap.py', provided the repository is already cloned.
Differential Revision: https://phabricator.services.mozilla.com/D130246
Consolidate Mach virtualenv management to the front of the
Mach process. This obsoletes `./mach create-mach-environment`
and simplifies the `sh` portion of the top-level `./mach` script.
This helps ensure that the Mach virtualenv doesn't become
out-of-sync and simplifies the mental model of the Mach
virtualenv situation.
Differential Revision: https://phabricator.services.mozilla.com/D120401
Updated the path value in the instructions from "<drive>:/" to "/<drive>/" for
Windows so that it works as intended when added to the MSYS profile. Also
added a copyable link to the expected msys/etc dir based on the MOZILLABUILD
environment variable to direct the user to where to apply the change.
(If the MOZILLABUILD variable isn't defined, supply the expected default instead)
Differential Revision: https://phabricator.services.mozilla.com/D129480
The current inheritance-based separation between "general venv
details" (`VirtualenvHelper`) and moz site details
(`MozSiteManager`) has caused `MozSiteManager` to care
about too many details.
This patch splits things apart a little more:
* The term `VirtualenvHelper` isn't _super_ useful, rename it to
`PythonVenv` to show that it represents a Python virtualenv.
* Move on-disk virtualenv logic (`activate_path` location,
`site-packages` location, `pip install` behaviour) into a
contained `MozVirtualenv` class.
* Port the inheritance to a "composition" model instead.
Differential Revision: https://phabricator.services.mozilla.com/D129685
The existing terminology had two issues:
* `VirtualenvManager` wasn't always associated with an on-disk
`virtualenv`: for example, when running in automation, Mach
"activates" a `VirtualenvManager`, updating its import scope,
but without ever creating an on-disk `virtualenv`.
* An upcoming patch splits the `VirtualenvManager` class, pulling
"on-disk virtualenv-handling functions" from the project-wide
interface for managing Python's import scope.
After some good discussion with Ahal, I think we've struck
the terminology that handles this distinction well: we'll call
the "import scope"-handling part the "site", and we'll continue
to call on-disk virtualenvs (and their representative classes)
as, well, virtualenvs.
Differential Revision: https://phabricator.services.mozilla.com/D130391
Downloading, as well as resuming a partial download, of an SDK/NDK was
implemented. The progress bar was implemented via tqdm.
This is not a generic solution, but the same ideas could be used and improved
to replace 'dlmanager' in the future.
Differential Revision: https://phabricator.services.mozilla.com/D129063
ahochheiden
Mitchell Hentges
Alexis Beingessner
Tom Ritter
Jens Stutte
Mike Hommey
Agi Sferro
Emilio Cobos Álvarez
Noemi Erli
Jonathan Watt
Makoto Kato
surajeet310
Sylvestre Ledru
Mats Palmgren
Iulian Moraru
Csoregi Natalia