This change adds a prompt to enable build system telemetry as part of
bootstrap. The prompt will only be shown if the build.telemetry config value
is not present, so users will not be prompted again if they have already
opted-in. However, if a user answers 'no' we don't save that value to
the config file because the default is to not send telemetry, so unless
they manually add `telemetry = false` to their config file they will be
prompted again the next time they run bootstrap.
The config value is always written to `~/.mozbuild/machrc` where we store
other Firefox build-related state. A standalone function is used to write
the config file so that we can do so even when running from bootstrap.py
outside of the context of a mach command.
As part of this change a `prompt_yesno` method is added to `BaseBootstrapper`.
Differential Revision: https://phabricator.services.mozilla.com/D9781
--HG--
extra : moz-landing-system : lando
In bug 1481425 I added an argument to `configure_git` for
the root directory of the current Firefox checkout, so
we could check for and remove the MozReview commit message
hook. I overlooked one other call to that function in
`bootstrap.py`, which is now failing due to too few
arguments. This commit adds the missing parameter.
Differential Revision: https://phabricator.services.mozilla.com/D10556
--HG--
extra : moz-landing-system : lando
This change adds a prompt to enable build system telemetry as part of
bootstrap. The prompt will only be shown if the build.telemetry config value
is not present, so users will not be prompted again if they have already
opted-in. However, if a user answers 'no' we don't save that value to
the config file because the default is to not send telemetry, so unless
they manually add `telemetry = false` to their config file they will be
prompted again the next time they run bootstrap.
The config value is always written to `~/.mozbuild/machrc` where we store
other Firefox build-related state. A standalone function is used to write
the config file so that we can do so even when running from bootstrap.py
outside of the context of a mach command.
As part of this change a `prompt_yesno` method is added to `BaseBootstrapper`.
Differential Revision: https://phabricator.services.mozilla.com/D9781
--HG--
extra : moz-landing-system : lando
During the MozReview days, users of git-cinnabar would install a
commit message hook to include `MozReview-Commit-Id` in their
commit messages. MozReview has seen been retired, yet there
are still a few users with the hook in their configs who now
have both a MozReview commit ID and a Phabricator Differential
link in their commits. This commit makes `mach vcs-setup` (and
`mach bootstrap`, since the former is called during the latter)
remove the commit hook on git checkouts of a Firefox repo. We
check the `commit-msg` hook file for "mozreview" anywhere in
the hook and remove if it is found.
Differential Revision: https://phabricator.services.mozilla.com/D10229
--HG--
extra : moz-landing-system : lando
cargo build is no longer called, so bootstrap will be faster.
All dependencies (including cbindgen) are usually up-to-date on BSDs
because there's no fallback to Mozilla binaries.
This patch makes the bootstrap code "ask" Gentoo's package manager for
human-readable information on how to get the latest JDK, then parses it and
locates the tarball URL on its own. The whole procedure is now fully automatic
(until the package output or Oracle web pages change).
Differential Revision: https://phabricator.services.mozilla.com/D5544
--HG--
extra : moz-landing-system : lando
moz.configure looks for rustc/cargo on PATH and in ~/.cargo/bin.
Bootstrap only looks on PATH and not in ~/.cargo/bin, though it is smart
enough to complain if rustc/cargo can't be found on PATH and you have
them in ~/.cargo/bin. Bootstrap should look in both places by default,
and be content if it finds them wherever they are, so long as
moz.configure can find them.
The state directory is in $HOME by default, so should be fine to just create it
if we get --no-interactive I think.
Differential Revision: https://phabricator.services.mozilla.com/D3838
This excludes directories, and returns true only if it's an executable file.
Differential Revision: https://phabricator.services.mozilla.com/D3366
--HG--
extra : moz-landing-system : lando
And require it for taskcluster build already, because it doesn't harm and lets
me put all the yml changes in the same commit.
I gave up cross-compiling for OSX after a few tries and after realizing it
wasn't enough with cctools and such, but that I also needed the Mac SDK, for
which I don't have permission...
Differential Revision: https://phabricator.services.mozilla.com/D2664
--HG--
extra : moz-landing-system : lando
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
A frequent question when mentoring new contributors is what "your
mozconfig file" is. By suggesting to create the file if it does
not exist, we can hopefully alleviate some new contributor frustration.
This change does unfortunately not take into account that the
mozconfig file can be named .mozconfig or even be in a designated
location defined by the MOZCONFIG environment variable, but it
seems reasonable to assume that developers who already know about
those alternatives will know which file to edit, and that what we
should optimise for during the bootstrapping process is to get new
contributors up and running quickly.
The argument --package_file was removed in the latest sdkmanager by Google's Android. But the docs for it say
packages can also be sent by putting them in quotes and calling the sdk manager with them as individual args.
So now instead of sending the file directly with the --package_file argument, the package names are read from
the file and the sdk manager is called with them as individual args.
Historically this has been thought of as a bug that happens with the wrong version of the JDK, but this can be
reproduced with just java 1.8.0_181 and the most up to date version of sdkmanager currently 26.1.1
Important note, the mach bootstrap command downloads an older version of the sdk and this bug is not present in
the older version.
Since the way of updating packages I'm proposiing to use is backwards compatible, there shouldn't be any problem
in any version of the sdkamanger.
This is a simpler fix than trying the --package_file argument, particularly because it would involve capturing
output (to detect this particular bug) that's also supposed to be shown to the user because this also happens
when the user is supposed to be interacting with the install.
MozReview-Commit-ID: L7VhCVKJNIf
***
Formatting changes to satisfy the linter.
--HG--
extra : rebase_source : f67d2cb85a4136eb8ad5c3053f5436a8870ab528