Mozilla overlay for Nixpkgs.
Перейти к файлу
Christian Albrecht db89c8707e overlays.rust: fix fromManifest postBuild realpath for rust-src build
When building rust-src like in
```
nix build --impure -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/refs/tags/23.05.tar.gz --argstr PWD $PWD --expr '{ PWD }:(import <nixpkgs> { overlays = (builtins.getFlake PWD).overlays.rust ];}).latest.rustChannels.stable.rust-src' -L --out-link rust-src-stable
```
after fixing the previous error the build failed since commit f6fe8508b0 with an error like
```
realpath: missing operand
```
because, bash shopt nullglob is enabled during build which leads to a
non-existing glob matching pattern to be a null string and therefore
the check with `ls $out/lib/librustc_driver-*.so` lists the whole
directory and succeeds.
```
bash -c 'shopt -s nullglob; if ls $PWD/rust-o*.nixxxxxxxxxxx &> /dev/null ; then echo yes ; else echo no ; fi'
yes
```

This commit changes the check to compare the null string resulting
from glob pattern match with nullglob enabled against another null
string.
2023-07-28 11:25:31 +02:00
lib remove url literals 2022-07-07 19:15:16 +02:00
pkgs remove url literals 2022-07-07 19:15:16 +02:00
.gitignore create a travis build and set gecko build to be built 2016-07-20 01:44:30 +02:00
.travis.yml typos in travis.yml 2016-08-07 02:47:31 +02:00
CODE_OF_CONDUCT.md Add Mozilla Code of Conduct file 2019-04-01 10:40:52 +02:00
LICENSE Change license to MIT, fixes #17 2017-03-28 01:25:41 +02:00
README.rst doc: fix typo 2023-06-26 11:24:36 +02:00
compilers-overlay.nix Gecko: Add clang13 target for running clang-format. 2021-11-16 09:46:48 -05:00
default.nix Allow usage as package set instead of overlay 2018-09-06 17:05:46 +02:00
deploy_rsa.enc adding ssh key to travis 2016-08-07 02:28:42 +02:00
firefox-overlay.nix Update gpg incantations to work with 2.4.1 2023-05-19 11:12:39 +02:00
flake.nix Remove rr overlay 2023-02-02 17:08:25 +01:00
git-cinnabar-overlay.nix Add git-cinnabar 0.5.0b3 2018-08-02 19:51:22 +02:00
lib-overlay.nix Convert nixpkgs-mozilla repository into a valid Nixpkgs overlay, which 2017-08-16 14:40:22 +02:00
overlays.nix Remove rr overlay 2023-02-02 17:08:25 +01:00
package-set.nix Allow usage as package set instead of overlay 2018-09-06 17:05:46 +02:00
phlay-overlay.nix Add derivation for phlay 2018-10-16 17:07:37 +02:00
pinned.nix remove servo: 2018-09-13 21:20:54 +02:00
release.nix Gecko: Add clang13 target for running clang-format. 2021-11-16 09:46:48 -05:00
rust-overlay-install.sh Fixes the overlay documentation 2017-03-16 15:25:29 +01:00
rust-overlay.nix overlays.rust: fix fromManifest postBuild realpath for rust-src build 2023-07-28 11:25:31 +02:00
rust-src-overlay.nix Replace deprecated stdenv.lib with lib 2021-07-29 11:57:09 +02:00
update.nix update.nix: Allow user to skip prompt with dont_prompt parameter 2017-07-17 14:43:35 +02:00

README.rst

nixpkgs-mozilla
===============

Gathering nix efforts in one repository.


Current packages
----------------

- gecko (https://github.com/mozilla/gecko-dev)
- firefox-bin variants including Nightly

firefox-bin variants
--------------------

Nixpkgs already has definitions for `firefox
<https://github.com/NixOS/nixpkgs/blob/246d2848ff657d56fcf2d8596709e8869ce8616a/pkgs/applications/networking/browsers/firefox/packages.nix>`_,
which is built from source, as well as `firefox-bin
<https://github.com/NixOS/nixpkgs/blob/ba2fe3c9a626a8fb845c786383b8b23ad8355951/pkgs/applications/networking/browsers/firefox-bin/default.nix>`_,
which is the binary Firefox version built by Mozilla.

The ``firefox-overlay.nix`` in this repository adds definitions for
some other firefox-bin variants that Mozilla ships:
``firefox-nightly-bin``, ``firefox-beta-bin``, and
``firefox-esr-bin``. All are exposed under a ``latest`` attribute,
e.g. ``latest.firefox-nightly-bin``.

Unfortunately, these variants do not auto-update, and you may see some
annoying pop-ups complaining about this.

Note that all the ``-bin`` packages are "unfree" (because of the
Firefox trademark, held by Mozilla), so you will need to set
``nixpkgs.config.allowUnfree`` in order to use them. More info `here
<https://nixos.wiki/wiki/FAQ#How_can_I_install_a_proprietary_or_unfree_package.3F>`_.

Rust overlay
------------

**NOTE:** Nix overlays only works on up-to-date versions of NixOS/nixpkgs, starting from 17.03.

A nixpkgs overlay is provided to contain all of the latest rust releases.

To use the rust overlay run the ``./rust-overlay-install.sh`` command. It will
link the current ``./rust-overlay.nix`` into your ``~/.config/nixpkgs/overlays`` folder.

Once this is done, use ``nix-env -iA nixpkgs.latest.rustChannels.nightly.rust`` for
example. Replace the ``nixpkgs.`` prefix with ``nixos.`` on NixOS.

Using in nix expressions
------------------------

Example of using in ```shell.nix```:

.. code:: nix

 let
   moz_overlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz);
   nixpkgs = import <nixpkgs> { overlays = [ moz_overlay ]; };
 in
   with nixpkgs;
   stdenv.mkDerivation {
     name = "moz_overlay_shell";
     buildInputs = [
       # to use the latest nightly:
       nixpkgs.latest.rustChannels.nightly.rust
       # to use a specific nighly:
       (nixpkgs.rustChannelOf { date = "2018-04-11"; channel = "nightly"; }).rust
       # to use the project's rust-toolchain file:
       (nixpkgs.rustChannelOf { rustToolchain = ./rust-toolchain; }).rust
     ];
   }

Flake usage
-----------
This repository contains a minimal flake interface for the various
overlays in this repository. To use it in your own flake, add it as
an input to your ``flake.nix``:

.. code:: nix
 {
   inputs.nixpkgs.url = github:NixOS/nixpkgs;
   inputs.nixpkgs-mozilla.url = github:mozilla/nixpkgs-mozilla;

   outputs = { self, nixpkgs, nixpkgs-mozilla }: {
     devShell."x86_64-linux" = let
       pkgs = import nixpkgs { system = "x86_64-linux"; overlays = [ nixpkgs-mozilla.overlay ]; };
     in pkgs.mkShell {
       buildInputs = [ pkgs.latest.rustChannels.nightly.rust ];
     };
   };
  }
The available overlays are ``nixpkgs-mozilla.overlay`` for the
default overlay containing everything, and
``nixpkgs-mozilla.overlays.{lib, rust, rr, firefox, git-cinnabar}``
respectively. Depending on your use case, you might need to set the
``--impure`` flag when invoking the ``nix`` command. This is because
this repository fetches resources from non-pinned URLs
non-reproducibly.

Firefox Development Environment
-------------------------------

This repository provides several tools to facilitate development on
Firefox. Firefox is built on an engine called Gecko, which lends its
name to some of the files and derivations in this repo.

Checking out Firefox
~~~~~~~~~~~~~~~~~~~~

To build Firefox from source, it is best to have a local checkout of
``mozilla-central``. ``mozilla-central`` is hosted in Mercurial, but
some people prefer to access it using ``git`` and
``git-cinnabar``. The tools in this repo support either using
mercurial or git.

This repository provides a ``git-cinnabar-overlay.nix`` which defines
a ``git-cinnabar`` derivation. This overlay can be used to install
``git-cinnabar``, either using ``nix-env`` or as part of a system-wide
``configuration.nix``.

Building Firefox
~~~~~~~~~~~~~~~~

The ``firefox-overlay.nix`` provides an environment to build Firefox
from its sources, once you have finished the checkout of
``mozilla-central``. You can use ``nix-shell`` to enter this
environment to launch ``mach`` commands to build Firefox and test your
build.

Some debugging tools are available in this environment as well, but
other development tools (such as those used to submit changes for
review) are outside the scope of this environment.

The ``nix-shell`` environment is available in the
``gecko.<arch>.<cc>`` attribute of the ``release.nix`` file provided
in this repository.

The ``<arch>`` attribute is either ``x86_64-linux`` or ``i686-linux``. The first
one would create a native toolchain for compiling on x64, while the second one
would give a native toolchain for compiling on x86. Note that due to the size of
the compilation units on x86, the compilation might not be able to complete, but
some sub part of Gecko, such as SpiderMonkey would compile fine.

The ``<cc>`` attribute is either ``gcc`` or ``clang``, or any specific version
of the compiler available in the ``compiler-overlay.nix`` file which is repeated
in ``release.nix``. This compiler would only be used for compiling Gecko, and
the rest of the toolchain is compiled against the default ``stdenv`` of the
architecture.

When first entering the ``nix-shell``, the toolchain will pull and build all
the dependencies necessary to build Gecko, this includes might take some time.
This work will not be necessary the second time, unless you use a different
toolchain or architecture.

.. code:: sh

  ~/$ cd mozilla-central
  ~/mozilla-central$ nix-shell ../nixpkgs-mozilla/release.nix -A gecko.x86_64-linux.gcc --pure
    ... pull the rust compiler
    ... compile the toolchain
  # First time only - initialize virtualenv
  [~/mozilla-central] python ./mach create-mach-environment
     ... create .mozbuild/_virtualenvs/mach
  [~/mozilla-central] python ./mach build
    ... build firefox desktop
  [~/mozilla-central] python ./mach run
    ... run firefox

When entering the ``nix-shell``, the ``MOZCONFIG`` environment variable is set
to a local file, named ``.mozconfig.nix-shell``, created each time you enter the
``nix-shell``. You can create your own ``.mozconfig`` file which extends the
default one, with your own options.

.. code:: sh

  ~/mozilla-central$ nix-shell ../nixpkgs-mozilla/release.nix -A gecko.x86_64-linux.gcc --pure
  [~/mozilla-central] cat .mozconfig
  # Import current nix-shell config.
  . .mozconfig.nix-shell

  ac_add_options --enable-js-shell
  ac_add_options --disable-tests
  [~/mozilla-central] export MOZCONFIG="$(pwd)/.mozconfig"
  [~/mozilla-central] python ./mach build

To avoid repeating yourself, you can also rely on the ``NIX_SHELL_HOOK``
environment variable, to reset the ``MOZCONFIG`` environment variable for you.

.. code:: sh

  ~/mozilla-central$ export NIX_SHELL_HOOK="export MOZCONFIG=$(pwd)/.mozconfig;"
  ~/mozilla-central$ nix-shell ../nixpkgs-mozilla/release.nix -A gecko.x86_64-linux.gcc --pure
  [~/mozilla-central] python ./mach build

Submitting Firefox patches
~~~~~~~~~~~~~~~~~~~~~~~~~~

Firefox development happens in `Mozilla Phabricator
<https://phabricator.services.mozilla.com/>`_. Mozilla Phabricator
docs are `here
<https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html>`_.

To get your commits into Phabricator, some options include:

- Arcanist, the upstream tool for interacting with
  Phabricator. Arcanist is packaged in nixpkgs already; you can find
  it in `nixos.arcanist`. Unfortunately, as of this writing, upstream
  Arcanist does not support ``git-cinnabar`` (according to `the
  "Setting up Arcanist"
  <https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#setting-up-arcanist>`_
  documentation). `Mozilla maintains a fork of Arcanist
  <https://github.com/mozilla-conduit/arcanist>`_ but it isn't yet
  packaged. (PRs welcome.)

- `moz-phab <https://github.com/mozilla-conduit/review>`_, an in-house
  CLI for Phabricator. It's available in nix packages (unstable channel).

- `phlay <https://github.com/mystor/phlay>`_, a small Python script
  that speaks to the Phabricator API directly. This repository ships a
  ``phlay-overlay.nix`` that you can use to make ``phlay`` available
  in a nix-shell or nix-env.

Note: although the ``nix-shell`` from the previous section may have
all the tools you would normally use to do Firefox development, it
isn't recommended that you use that shell for anything besides tasks
that involve running ``mach``. Other development tasks such as
committing code and submitting patches to code review are best handled
in a separate nix-shell.

TODO
----

- setup hydra to have binary channels

- make sure pinned revisions get updated automatically (if build passes we
  should update revisions in default.nix)

- pin to specific (working) nixpkgs revision (as we do for other sources)

- can we make this work on darwin as well?

- assign maintainers for our packages that will montior that it "always" builds

- hook it with vulnix report to monitor CVEs (once vulnix is ready, it must be
  ready soon :P)