Creates a migration for browser.tfl to unify strings in browser.dtd and broser.properties
that are used in main-popupset.inc.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D122538
The sysroot setup on macOS is different from Linux, and pkg-config
files, if there are, would be coming from e.g. homebrew rather than
the macOS SDK.
Differential Revision: https://phabricator.services.mozilla.com/D122793
libdav1d only has relative paths. Like ../../third_party/foo/bar.c
libjpeg-xl has absolute paths like /third_party/bar/foo.c
This handles the second case by not doing our relative path
correction logic if we don't need to.
It will find all of the types of ways a file is included in a
moz.build file* and iterate over them, trying the slightly
different logic. This is okay, because the failure scenario
for trying an incorrect mode is just that we don't get a match.
By trying all the modes we can increase our chances of finding a
match.
* For SOURCES/UNIFIED_SOURCES there aren't actually any situations
where we have mixed-modes in a moz.build file. But a future patch
will add support for editing EXPORTS and they do have mixed-modes.
Depends on D120477
Differential Revision: https://phabricator.services.mozilla.com/D120478
When relanding Bug 1709697, all of the icons ended up as 0-byte files.
I can't explain this; it's hard to achieve this with a rebase. We
regenerate `Resources.pri` following the instructions in the
documentation.
This commit also moves to represent the package as "Mozilla Firefox",
which is consistent with how unpackaged versions appear in the Windows
UI. In the start menu, the application continues to be represented as
"Firefox" (no "Mozilla" vendor).
Finally, this commit also differentiates "Firefox Beta" from "Firefox"
in a few select places (while not changing branding and iconography).
Differential Revision: https://phabricator.services.mozilla.com/D122411
While some custom builds of GCC work successfully, system GCC builds
usually don't, because of several factors:
- they don't use the C++ headers or libstdc++.so from the sysroot
- they don't necessarily know to use the multiarch directories in the
sysroot
Differential Revision: https://phabricator.services.mozilla.com/D121946
We're currently using -isysroot as a preprocessor flag and
-Wl,--syslibroot/-Wl,--sysroot as a linker flag, but --sysroot is
generalization of both, so we can use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D121943
They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
This patch has a few minor improvements to `./mach ide vscode` to make
it nicer to use in various situations. Specifically:
* Tries to locate the `code` using `shutil.which` in addition to the
existing methods so that the binary is found when being run from
within a vscode remote shell.
* If locating the code binary fails, only prompts to ask whether or not
to continue, rather than requiring entering the complete path. The
only use of the vscode command is to start an instance connected to the
correct path, so if no binary was found, a message is logged instead.
(bug 1699943)
* When changes need to be made to the settings.json file, a full diff is
shown between the old and new files, rather than just showing the
computed state before and after.
* If parsing the existing settings.json file fails (e.g. because there
were c-style comments in it - see bug 1670997), the diff is shown and
an additional warning is emitted to ask if the change should be made.
Differential Revision: https://phabricator.services.mozilla.com/D121157
This commit does three things:
1. It makes thes MSIX test publisher subject "CN=..., OU=...". This
is more like the actual Firefox signing certificates".
2. It moves to use `universal_newlines=True` rather than decoding manually.
3. It fixes an oversight where a particular Powershell invocation
would fail when a certificate was missing.
Differential Revision: https://phabricator.services.mozilla.com/D121902
Installing the Nightly MSIX packages, signed with Mozilla's Nightly
key, yields an error: "Error in parsing the app package." Unpacking
with `makeappx.exe` yields:
```
MakeAppx : error: Error info: error 8007000B: The app manifest publisher name (CN=Mozilla Corporation) must match the subject name of the signing certificate (CN=Mozilla Corporation, OU=Firefox Engineering Operations, O=Mozilla Corporation, L=Mountain View, S=California, C=US).
```
Previously, we allowed just the `CN` to vary; in this patch we make
the publisher be the entire publisher subject, and we update the
publisher details in the task definitions.
Differential Revision: https://phabricator.services.mozilla.com/D121896
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
`_install_pip_package()` may be run from `populate()`, which
is invoked from a child Python process that doesn't
have in-tree Python modules in its sys.path.
An alternate solution would be to add in-tree modules
to the sys.path, but that seemed more costly than
simply using `tempfile` and `shutil`.
Differential Revision: https://phabricator.services.mozilla.com/D119834
Now that the upstream Python bug has been resolved since Python 3.4 (at
the latest), we can safely remove the environment variable workaround.
Differential Revision: https://phabricator.services.mozilla.com/D119687
It's possible for a virtualenv to have an incorrect list of directories
to add to the sys.path, such as the following cases:
* Its creation got cancelled halfway through
* The list of pths changed in a new revision
* It got modified by an external tool
By validating the list of provided pths against the list of required
pths, we can ensure that the virtualenv is more dependably up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D119686
This simplifies consumer logic, since they get the parsed list of pypi
and pth requirements, as well as the list of input files that were
parsed.
One benefit of this simplification is that we no longer
recursively create VirtualenvManagers.
Note that mach_bootstrap cannot (yet) take advantage
of `ParseMachEnvRequirements` because of a dependency cycle:
* `mach_bootstrap` must set up the `sys.path` to import
`ParseMachEnvRequirements`.
* `mach_bootstrap` would want `ParseMachEnvRequirements` to
determine which paths to add to the `sys.path`.
Differential Revision: https://phabricator.services.mozilla.com/D119685
This is strictly a convenience for local developer testing. In
automation, we'll use the regular signing process via `autograph`,
etc.
Differential Revision: https://phabricator.services.mozilla.com/D116181
This is strictly a convenience for local developer testing. In
automation, we'll use the regular signing process via `autograph`,
etc.
Differential Revision: https://phabricator.services.mozilla.com/D116181
Csoregi Natalia
Niklas Baumgardner
Erik Nordin
Mike Hommey
Tom Ritter
Mitchell Hentges
Nick Alexander
Molly Howell
Marian-Vasile Laza
Butkovits Atila
Alex Lopez
Nika Layzell
Brindusan Cristian
Alexandru Michis
Narcis Beleuzu
Iulian Moraru