Work around missing redhat-hardened-cc1 when building psutil_linux
on Fedora by installing the redhat-rpm-config package.
This fixed build warnings with several mach commands, and errors
with others like `./mach mochitest` and `./mach install` for fennec
builds.
MozReview-Commit-ID: G9jn4abUEtp
--HG--
extra : rebase_source : 98337b820fff52e2efd2368e89f7ff488b36f1ff
Should be pretty safe as Java compa is usually very good.
This will fix the issue on Debian testing not having openjdk-7-jdk and
current Debian stable having it.
(same with Ubuntu)
MozReview-Commit-ID: Alxg4K4PwQ4
--HG--
extra : rebase_source : 920cdb1618ba587a4776e33ef7857415a59c53b9
On windows, python generally returns windows-style paths,
with drive letters and backslash for a separator. However,
when we offer advice for updating the PATH variable, we're
talking about the msys environment which uses unix-style
paths. Convert to avoid confusion.
This is intended to turn c:\Users\mozilla\ into /c/Users/mozilla/.
MozReview-Commit-ID: FdB8FvjeCV1
--HG--
extra : rebase_source : 6d9e87b460417254bbe2eb5af3813e22f2126fb1
This provides build-completion notification from mach.
We already do this on debian-based distros.
MozReview-Commit-ID: Jl3OWa9MpZ6
--HG--
extra : rebase_source : e97c02d2924f888b33593ad5209cedaccceba633
Update the version number and checksums of the rustup
installer we download to 1.0.0. This had a first stable
release alongside rust 1.15.
This is the result of running `python mozboot/rust.py --update`
and applying the resulting output.
MozReview-Commit-ID: 1gzMLHZuhNx
--HG--
extra : rebase_source : b9d0f95f17e76a32e17e82d05505cf07a21c5e66
It seems older Python (e.g. 2.7 from Ubuntu 14.04) doesn't
support SNI, so we get a TLS error with the canonical
https://static.rust-lang.org/ url even when using the
`requests` module.
Fall back to the no-CNAME host instead which is ugly but works.
Thanks to Simon Sapin for the suggestion.
MozReview-Commit-ID: I6V5ASijuKi
--HG--
extra : rebase_source : 2e2a449fbb3011b51207f1c6baa3d288d0dc774c
On Windows, the rustup installer doesn't create ~/.cargo/env
but instead pokes .cargo/bin into the path in the Windows
registry. This doesn't necessarily propagate to the msys
evironment however, so some PATH manipulation may still
be necessary.
Split our path advice to be clear in both the new install
and unconfigured path cases, and amend our path update
advice to not mention .cargo/env if it isn't present.
MozReview-Commit-ID: 9IHhS6UYCqq
--HG--
extra : rebase_source : 898615106078882f335385ac0b50eff1612377f0
Always report if we found an out-of-date rustc.
This is better when an older rustc is installed, but not rustup,
and it's shadowing the version we install in $CARGO_HOME.
MozReview-Commit-ID: 43io6uISMNI
--HG--
extra : rebase_source : f02e36e0c0c0e5380b3f511852b29a77622165c5
This is needed on Fedora as well as CentOS, at least on Fedora 25
where it's evidently not part of the "GNOME Software Development"
group.
MozReview-Commit-ID: KMW8FUsvJcv
--HG--
extra : rebase_source : 07acb80148409cc1d2918900a56e5d0210c157e1
We were checking for success installing rust with the same code
we checked for upgrade success, but in the case of a clean install
this will likely fail because the binaries installed by rustup
won't be in path. Instead, print the help message about adding
them after installation completes.
MozReview-Commit-ID: xa5PKIDKzZ
WindowsBootstrapper overrides BaseBootstrapper.which() to append
the Windows 'exe' filename extension, so which() finds rustc.exe
and rustup.exe properly. However, our other code which constructs
the program name in _parse_version or looks for the files in
CARGO_HOME didn't take this into account, making the script think
it couldn't find rust.
Don't use os.path.join to construct urls, since on windows this
inserts the backslash '\' path separator instead of the normal
forward slash.
MozReview-Commit-ID: HWJjwCDHuNK
--HG--
extra : rebase_source : c9a295a22c06dcbfa60637ff6d56d6f1ca269e83
Python urllib2 doesn't validate https origins in all versions.
During actual bootstrap the static hash values act as an out-of-bound
validatation channel.
However, that doesn't help when doing the initial download and hash
generation when invoked as `python rust.py [--update]`. Fortunately
we don't expect to be called this way in standalone mode, so we can
use the in-tree requests module to fetch things properly.
MozReview-Commit-ID: KZTtIXDfWTB
--HG--
extra : rebase_source : 14c505797a74de16a7e9bec1f791c0b4659d2932
Reopen sys.stdout in unbuffered mode so we can correctly print
'Checking foo... Result' in two parts without calling sys.stdout.flush()
everywhere.
Although we import print_function from the future, the python 2 version
does not support the python 3 flush=True argument.
MozReview-Commit-ID: SjliWeoSa3
--HG--
extra : rebase_source : e16905ac4045e80060d6f248cae0ec731dd0d1c5
Make the mozboot.rust module invokable as a utility. E.g.
python rust.py --update
When called with the --update option it downloads and generates
checksums for the latest version of the installer on supported
platforms, suitable for updating the values coded in the script.
When invoked without the --update option, it verifies the
current version and checksums against the server.
MozReview-Commit-ID: 2NVFf0ptvbM
--HG--
extra : rebase_source : 5e8b650a9b3c6e1d2b8bfdc90d02faa194f1aa04
Download and run a known-good rustup-init installer for the host
system. Once installed, use it to upgrade the latest toolchain.
NB: I expect the MozillaBuildBootstrapper to run its installer
first, but this will take care of Mac, Linux, and FreeBSD.
MozReview-Commit-ID: BKDm1UcLxQS
--HG--
extra : rebase_source : 4e4489d55ad658166a7e4b20c53185532c041204
Add a check to `mach bootstrap` that a compatible version of
the rust toolchain is installed and in path. Note that we use
a separate minimum version from the one checked at configure
time, defined in build/moz.configure/rust.configure, because
this script may be running stand-alone.
If we don't find `rustc` in PATH, we check for it in CARGO_HOME
and suggest adding that to PATH.
If we don't find `rustc` but find a `rustup`, we call it with
the --version switch and report if that fails. This will detect
the older `rustup.rs` script.
MozReview-Commit-ID: EPfQhLz4Dvo
--HG--
extra : rebase_source : 2ea4acdfbfdc2a436f386eae7bc3cbcbc485aa1b
Also use the abstracted helper method for reading the current
mercurial version too. This changes the regex from what was in
use before, but should work for normal version numbers.
MozReview-Commit-ID: IZfC65Jg6T8
--HG--
extra : rebase_source : d61a73b7b1b438d8c846523e5e1f639950fe5473
Move version parsing to a helper method so it can be used
for more than one executable.
MozReview-Commit-ID: 4gOgdgYFbFx
--HG--
extra : rebase_source : 944f562c0d5a6a105a0c27af6f4d7dfc214f3c01
Previously if an Arch Linux user had a different package extension configured
in `/etc/makepkg.conf` building AUR packages during bootstrap would fail.
Forcing the extension by providing it as an environment variable makes sure
building doesn't fail regarding of a user's configuration.
MozReview-Commit-ID: 4aryYS0XVr7
--HG--
extra : rebase_source : 4c466e49f729de625e814a92325c6d38e6d1e0b4
This patch solves 3 problems on Fedora when trying to bootstrap Firefox for Android:
1) Installs java
2) Adds a call to android.ensure_android_packages()
3) Uses build-tools-23.0.1 which seems to be the latest on Fedora
I'm not sure why the Android specific packages are only being installed on Fedora
and not CentOS, but as I don't have CentOS distribution to play around with figured
it was best to leave that for another bug.
MozReview-Commit-ID: 19sD6tYj4V
--HG--
extra : rebase_source : eaf17bc05d606d3010b11927f27a482680266992
Versions of mercurial older than 3.0 don't support the -T shorthand for
the --template option. While most people should be using something
newer, it can still happen that some run an older version, and it's
still trivial to support them by using the long option.
--HG--
extra : rebase_source : 1507aea436779495045df48b044a58f4af1382be
Also, is a ConEmu preferences file which automatically points a newly installed ConEmu to the newly installed MSYS2.
MozReview-Commit-ID: FBeMat4SYjK
--HG--
extra : rebase_source : 83d8f03a6cc011215fe58745c93afdf90162dc58
Contains a few sentences copied from MDN.
MozReview-Commit-ID: 2wgcCNiWkWw
--HG--
extra : transplant_source : %7B%A2%10%88%83k%AC%AE%D3%A4H/pL%E6%B9%BE-9%5E
This matches the implementation from mach_bootstrap.py.
MozReview-Commit-ID: 8kZCKuIsAMQ
--HG--
extra : rebase_source : 59b1f3d595e1663603363bb712da9cb74c3ba0e0
extra : amend_source : e95774ade1c7d28ba1d880b6b9ef1d64eaa618a8
We'll be consolidating code from mach_bootstrap.py and mozboot.
We don't want mach_bootstrap.py to import bootstrap.py because it
imports nearly every module under mozboot. So establish a standalone
module with minimal dependencies to hold utility code. Move
get_state_dir() there.
MozReview-Commit-ID: Hw5VB5OZGCi
--HG--
extra : rebase_source : e083f9a5d2fabea308b7b884e9830f800758ae17
extra : amend_source : 0a7b5f42a937430170fdc16909c559f720085668
https://hg.mozilla.org/firefox now exists. It is a unified Firefox
repository containing the heads of all the major Firefox repos
(mozilla-central, inbound, aurora, beta, release, esrs, etc).
Having 1 unified repository is more useful and incurs less overhead
than N separate repos. We want to encourage the use of the unified
repository. So, we start cloning from it.
The unified repo on the server is configured in such a way that
manifest delta chains can become very long - over 30,000 deltas. This
can make manifest reading very slow and slow down many Mercurial
operations. The server compensates for this by setting
format.maxchainlen=10000 to limit the delta chains to 10,000.
Unfortunately, this setting is not preserved when clients do a
traditional clone: the changegroup consists of a single delta chain
and the client will use its own settings (often the default) to
break the chain. This will result in the client re-creating very long
delta chains. So, as part of initializing the new repo we configure
format.maxchainlen in its .hg/hgrc so it doesn't suffer from this
performance issue.
We could achieve the same result by passing the --config option to
`hg clone`. However, the option won't be preserved in the repo's
.hg/hgrc and subsequent `hg pull` operations could result in the
creation of very long delta chains. So we need to write the config
option in the .hg/hgrc. `hg clone` is equivalent to `hg init` +
`hg pull` anyway, so we just separate out the steps and insert a
write to .hg/hgrc in between.
We also set the "default" path (like `hg clone` would do).
DONTBUILD (NPOTB)
MozReview-Commit-ID: Fs4cz9YvdCv
--HG--
extra : rebase_source : 99e8239415f74d078c9a1a903355175cb54a8184
extra : amend_source : ee4bc9ef2b89fabdae6f14d0ab10ca12dc08b15d
I've always been bothered that the one-line bootstrap configures your system
then leaves you on the hook to clone source code and configure the build
system. I'd like the bootstrap wizard to guide you through end-to-end.
This commit addresses part of the disconnect by offering to clone the
Mercurial source repository at the end of bootstrap.
We only offer to clone if we aren't running from a Firefox source checkout
(likely the one-line bootstrap invocation) and if we are in interactive
mode.
I'd like to eventually offer Git support here. Mercurial is the canonical
repo, so it makes sense to start with that.
MozReview-Commit-ID: 6TSZwxB3702
--HG--
extra : rebase_source : 5c35408a4f0e59d681ca28e5b23359c54927b513
extra : amend_source : f980b972e35a17e733e704e47efdd773b3633e45
Without this, we attempt to execute "hg" as a native Win32 program
and get the dreaded "%1 is not a valid Win32 application" error because
"hg" has a shebang and only executes inside a UNIX-like shell.
MozReview-Commit-ID: 5sUrxh1IxFC
--HG--
extra : rebase_source : b01d9b2f8ffc60da320f51a1b7e8a398781c373a
The wizard has been ported to the version-control-tools repository
and in-tree consumers have been switched to consume it from there. This
code is now dead. Kill it.
References to the now-defunct code have been removed/updated.
MozReview-Commit-ID: 5fpCXdNIp8L
--HG--
extra : rebase_source : 6c1e2363793fe2cd3a506ce5d962788657871203
extra : histedit_source : c40d2203aaa54bbd48e4e2b46178e277dcdc2e3f
The Mercurial setup wizard has now been ported to the version-control-tools
repository, where it has testing and integrates better with Mercurial
configs.
The bootstrapper has been taught how to invoke the new version of the
Mercurial setup wizard.
This commit switched `mach mercurial-setup` to call the bootstrapper
code for invoking the Mercurial setup wizard from version-control-tools.
As of this commit, the Mercurial setup wizard in tools/mercurial is
unused.
MozReview-Commit-ID: 3xzgOYZWTZn
--HG--
extra : rebase_source : 56697d504ff41ad02d77ddd1241cebafe610751a
extra : histedit_source : feb7450130c447dc74e059173f5b54544c020929
If a state directory is available and we're running in interactive mode
(or have been told otherwise), we now configure Mercurial during
bootstrap.
This consists of cloning version-control-tools to the state directory
(mimicking code in `mach mercurial-setup` today) and running the
config wizard from version-control-tools.
Code for cloning/updating repositories has been stolen from
tools/mercurial/hgsetup.
As the inline TODO notes, I'd like to eventually support
configuring Git during bootstrap. Since Mercurial is the canonical VCS
for Firefox and since we already have a Mercurial setup wizard (and
don't have a Git one yet), I don't think we should block on implementing
Git support.
MozReview-Commit-ID: 1FZyWIlHZNy
--HG--
extra : rebase_source : c727017bbdc703399fa67e1d831280441026614b
extra : histedit_source : fdb124447b4e80277cfd70fb65a24e0947c89c60
Currently, on first run of `mach` it prompts you to create a state
directory. The hand-off between bootstrap and `mach` has always
bothered me because bootstrap is supposed to get your system in a good
state.
In this commit, we teach the bootstrap tool to create the state
directory when not present. This duplicates functionality from `mach`.
The justification for the duplication is explained by inline comment.
In future commits, we'll build on this work to have the bootstrapper
run the Mercurial config wizard, which needs this state directory.
MozReview-Commit-ID: CPKVuRJ3peM
--HG--
extra : rebase_source : 085b67183ec4fda8a23ead3328130c962c95617d
extra : histedit_source : 3ba31232521f624bcf9d0cc5a99033083c1f3657
This begins the consolidation of `mach mercurial-setup` into
`mach bootstrap`. The first step is to move the content of the
mach_commands.py file into the bootstrapper's.
I'm not crazy about adding the sys.path entry for tools/mercurial.
I intend to clean this up later.
MozReview-Commit-ID: Cq56wPG8sO1
--HG--
extra : rebase_source : 48d6d2631760c9333bf99285673430948085630e
extra : histedit_source : e062f6fbc0ae9678347801b4a1f1c9b6912afd52
The correct version of Python will get installed from the install_python method instead of with the system packages.
This is more in-line with how a bootstrapper *should* extend from the base bootstrapper.
MozReview-Commit-ID: JIMGF7XKL02
--HG--
extra : rebase_source : dc70bdf555afe0a0dfb253e01381b5e6fa52eee3
Overrode BaseBootstrapper.which to append '.exe' to any which checks since (hopefully) anything the bootstrapper looks for, must be a windows executable.
Changed base bootstrapper class to use str instead of unicode to avoid a bug in the MinGW version of Python where subprocces.Popen will not accept environment variables that are in unicode instead of str.
MozReview-Commit-ID: 4m8xNifawYS
--HG--
extra : rebase_source : 455b518b099fdba347626ab93b85ddbd44f1f977
dinartejesus
Ralph Giles
Sylvestre Ledru
Jonathan Watt
Chris Manchester
Leo Schwarz
Andrew Halberstadt
Mike Hommey
Nathan Hakkakzadeh
Timothy Guan-tin Chien
Sambuddha Basu
Jan Beich
Paul Adenot
Gregory Szorc