The example pertinent to `fccUnlockScripts` contains wrong (maybe old) key names possibly leading to trial/error while configuring the option. This issue can be avoided updating the example.
Reimplement the `ModulePath` generation logic by only adding the
`/lib/xorg/modules` subpath for each module, in the specified order.
In particular, hardware-specific drivers are listed *before*
`xorgserver`, which fixes https://github.com/NixOS/nixpkgs/issues/299684.
This also keeps the list reproducible, as wanted by https://github.com/NixOS/nixpkgs/pull/230186.
I have confirmed that X is able to find `.so` files recursively within
the `ModulePath`, so that there is no need to include subdirectories of
`/lib/xorg/modules`. Furthermore, I don't expect there to be a need to
include directories *outside* of `/lib/xorg/modules`, as the default
`ModulePath` on standard distributions is `/usr/lib/xorg/modules`.
(see https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml#heading4)
I am not able to take care of those for the time being, will readd
myself in the future once I have more time and energy.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
This fixes an issue where running the forgejo package standalone,
without the use of our nixos/forgejo module, would try to use a
directory named `@data@` for its `STATIC_ROOT_PATH` assets.
This went unnoticed until now, because most users use the nixos/forgejo
module in which we explicitly set this option/setting/path to
`cfg.package.data` by default (`pkgs.forgejo.data`).
Also, this commit hard-copies the patch in question from gitea to our
nixpkgs derivation directory.
We decided a long time ago to part ways, and forgejo inheriting the
patch from gitea's drv directory puts strain on gitea.
So we don't do that anymore and instead maintain that patch ourselves
from now on.
Unfortunately, `substituteInPlace --subst-var` does not error, when the
substitution fails.
This would have prevented this issue from going unnoticed.
it's no longer needed and if anything impedes further development of the
tooling by its sheer undecipherability of reasoning alone. users of the
docbook renderers can still pull nrd from 23.11 to get this support for
the foreseeable future, but with everything we can remember having moved
away from docbook-like toolchains already that seems unlikely to happen.
since we don't want to break links and changing the id generation scheme
would Very Break links this id generation function is unfortunately
somewhat part of the manual structure now, so we may as well put it there.
Upstream updates roon-server frequently, and client apps (iOS, Android,
etc) will stop working with older versions of the roon-server.
We can't always keep the roon-server up to date as fast as upstream
releases, so it is often necessary for users to use an overlay or
provide their own version.
In particular the use case of running NixOS stable channel, but wanting
to use the `pkgs.roon-server` from unstable is one that I want to
support with this simple change.
Add package for proton mail desktop app in the beta version.
Apply suggestions from code review
Apply batch of suggestions from CR by @dotlambda.
Co-authored-by: Robert Schütz <github@dotlambda.de>
The package could not be built because it was trying to write the DLL into
$src. One way to fix that is to build the DLL beforehand. Perhaps "make" could
be convinced to put its outputs elsewhere, then the build-with-compile-into-pwd
could be swapped for just build-asdf-system. It would have to create $out during
buildPhase.
Works after changing `git/default.nix` to use `gitRelease` instead of `officialRelease`
Wont update the version attr
```
, gitRelease ? {
version = "15.0.0";
rev = "a5640968f2f7485b2aa4919f5fa68fd8f23e2d1f";
rev-version = "unstable-2022-26-07";
sha256 = "1sh5xihdfdn2hp7ds3lkaq1bfrl4alj36gl1aidmhlw65p5rdvl7";
}
```
I removed the test as it currently fails on master and is removed
upstream in the as-yet-unreleased next version.
The test that fails looks like this:
```
Traceback (most recent call last):
File "/build/source/tests/test_cases/test_cocotb/test_deprecated.py", line 39, in test_unicode_handle_assignment_deprecated
dut.stream_in_string.value = "Bad idea"
^^^^^^^^^^^^^^^^^^^^
File "/nix/store/yvcizx3fwkm044jpw9sfpnb0kx0g2bfl-python3.11-cocotb-1.8.1/lib/python3.11/site-packages/cocotb/handle.py", line 370, in __getattr__
raise AttributeError(f"{self._name} contains no object named {name}")
AttributeError: sample_module contains no object named stream_in_string
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/build/source/tests/test_cases/test_cocotb/test_deprecated.py", line 38, in test_unicode_handle_assignment_deprecated
with pytest.warns(DeprecationWarning, match=".*bytes.*"):
File "/nix/store/5ipi1f14ji1nrvqnf8h8fqvr0zny183d-python3.11-pytest-8.0.2/lib/python3.11/site-packages/_pytest/recwarn.py", line 332, in __exit__
fail(
File "/nix/store/5ipi1f14ji1nrvqnf8h8fqvr0zny183d-python3.11-pytest-8.0.2/lib/python3.11/site-packages/_pytest/outcomes.py", line 188, in fail
raise Failed(msg=reason, pytrace=pytrace)
Failed: DID NOT WARN. No warnings of type (<class 'DeprecationWarning'>,) were emitted.
Emitted warnings: [].
```
We can now use standard nix-update-script but the renode-unstable still
requires the custom update script so we moved it to the specific .nix
file.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
This update enables support for newer hardware.
I am putting myself down as maintainer, and removing the prior
maintainer, @sebtm, at his specific suggestion.
This seeems reasonable to me as I do own the hardware and therefore
can do some actual testing.
When trying to insert an emoji, and error notification raises:
`Could not find any tool to handle insertion. Please install xdotool or wtype.`
This commit add those missing dependencies.
To control which of these tools should be installed (one is for x11 and the
other for wayland) 2 derivations arguments have been created: `x11Support` and
`waylandSupport` defaulting to `true`.
When using LLVM strip on the favicon.ico files in this package, their
size gets inflated from 31K to 772M, which results in an unreasonable
package size.
Related: #299427
These are the names of the binaries as they are distributed in some
places. Upstream systemd services even depend upon these names, it is
going to be helpful to keep this naming consistent, for bootstrapping
Ignore vendorSha256 when vendorHash is specified.
Throw when vendorHash isn't specified:
- "buildGoModule: Expect vendorHash instead of vendorSha256" when
vendorSha256 is specified.
- "buildGoModule: vendorHash is missing" otherwise.
`goModules.outputHashAlgo` is specified as null when vendorHash is not
empty, "sha256" otherwise.
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
It also has HIP, Metal, and SYCL support, but I do not have hardware to
test any of those actually work. Further, Blender 4.1.0 does not enable
GPU OIDN on AMD (HIP), but may in 4.2.0 it seems.
The current URL doesn't work anymore:
$ nix-build -A gnuradioPackages.osmosdr.src --check
checking outputs of '/nix/store/3jmqk57y5214iadfi6ivbgfd1rr9fyib-gr-osmosdr.drv'...
exporting git://git.osmocom.org/gr-osmosdr (rev v0.2.4) into /nix/store/m1qa9ipmdf4xrc6gl1r0zd0c5r0ns7bk-gr-osmosdr
Initialized empty Git repository in /nix/store/m1qa9ipmdf4xrc6gl1r0zd0c5r0ns7bk-gr-osmosdr/.git/
fatal: unable to connect to git.osmocom.org:
git.osmocom.org[0: 78.46.96.155]: errno=Connection refused
git.osmocom.org[1: 2a01:4f8:120:8470::2]: errno=Network is unreachable
Fixes https://github.com/NixOS/nixpkgs/issues/298876.
PR #256638 inadvertently introduced a bug in `nixos-generate-config` whereby it
would never put `bcache` into the `availableKernelModules` for the initrd.
This is because the `qr` operator in Perl returns a regex object, rather than
matching it; the regex object evaluates to true, making the filter expression
effectively `grep(!true, @bcacheDevices)`, which will always return an empty
list.
- Build virtualbox guest additions from source and fix paths
- Install VBoxDRMClient to support resizing
- Support resizing on wayland and x11
- Adding multiple new options
- clipboard
- seamless
- Removing x11 option
- Support linux 6.8
* use xcbuild.xcbuild, which is dep for @esfx/equatable; fix 'aligned_alloc' error
* frontend's offlineCache: don't allow platforms other than the one's mentioned in `meta.platforms`
Follow upstream to disable test_pyin_multi_center on darwin:
> Note: this test has issues on OSX with libopenblas 0.3.26, so we
disable it for now. We may re-enable it some time in the future.
Add a Nix `matchbox-server` package for the matchbox project
https://github.com/poseidon/matchbox. It provides a server for
PXE booting and provisioning machines into clusters and has been
maintained for many years
Note: A matchbox-window-manager is already using the Nix package name
matchbox, so name this new package matchbox-server
Adds newer patches upstreamed from Fedora into Sage; CRLF endings in the
`dietz` solver require `dos2unix` to apply the patches properly.
Frankly, I have no idea how this previously compiled on gcc.
The available policies for `InsertedDevicePolicy` and
`ImplicitPolicyTarget` differ from the defined policy enum. This change
is to prevent users from configuring incorrect policies for `usbguard`
Related `usbguard` documentation
https://usbguard.github.io/documentation/configuration.html
Signed-off-by: Ameya Shenoy <shenoy.ameya@gmail.com>
The NVIDIA X driver uses a UNIX domain socket to pass information to
other driver components. If unable to connect to this socket, some
driver features, such as G-Sync, may not work correctly. The socket will
be bound to a file with a name unique to the X server instance created
in the directory specified by this option. Note that on Linux, an
additional abstract socket (not associated with a file) will also be
created, with this pathname socket serving as a fallback if connecting
to the abstract socket fails.
The default, which was in effect prior to this change, was `/var/run`.
The effect of not setting this option was that GDM X sessions
(and other non-root sessions) would see this warning in the log files:
```
(WW) NVIDIA: Failed to bind sideband socket to
(WW) NVIDIA: '/var/run/nvidia-xdriver-b4f69129' Permission denied
```
I don't see any security implications of turning this on universally,
since there already was an abstract socket created according to the
docs.
Documentation:
1. [NVIDIA X Config Options](https://download.nvidia.com/XFree86/Linux-x86_64/440.82/README/xconfigoptions.html#SidebandSocketPath)
Diagnosis:
1. [Arch Linux BBS post](https://bbs.archlinux.org/viewtopic.php?pid=1909115#p1909115)
In `kdePackages`, `strictDeps` is set and `extra-cmake-modules` goes into
`buildInputs`. The hook should run against the `buildInputs`, so it should
have `hostOffset`. This fixes for example the loading of translations that
come from dependencies.
The correct way is to use goldwarden through the programs.goldwarden module
and the correct pinentry flavor based on programs.gnupg.agent.pinentryFlavor is now used.
When specifying a list of fonts to install, the google-fonts package
would previously only search for fonts with the formats `$font-*.ttf`
and `$font[*.ttf`. However, certain fonts in the Google fonts repository
do not follow this naming scheme (e.g., Nova Square;
ofl/novasquare/NovaSquare.ttf). I have added `$font.ttf` as a format.
I have also optimized the build script so it does not make multiple calls
to `find`.
@ -557,7 +557,7 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
```nix
foo {
foo {
arg = ...;
arg = <...>;
}
}
```
```
@ -566,14 +566,14 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
```nix
foo
foo
{
{
arg = ...;
arg = <...>;
}
}
```
```
Also fine is
Also fine is
```nix
```nix
foo { arg = ...; }
foo { arg = <...>; }
```
```
if it's a short call.
if it's a short call.
@ -581,41 +581,45 @@ Names of files and directories should be in lowercase, with dashes between words
- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
```nix
```nix
# A long list.
{
list = [
# A long list.
elem1
list = [
elem2
elem1
elem3
elem2
];
elem3
];
# A long attribute set.
# A long attribute set.
attrs = {
attrs = {
attr1 = short_expr;
attr1 = short_expr;
attr2 =
attr2 =
if true then big_expr else big_expr;
if true then big_expr else big_expr;
};
};
# Combined
# Combined
listOfAttrs = [
listOfAttrs = [
{
{
attr1 = 3;
attr1 = 3;
attr2 = "fff";
attr2 = "fff";
}
}
{
{
attr1 = 5;
attr1 = 5;
attr2 = "ggg";
attr2 = "ggg";
}
}
];
];
}
```
```
- Short lists or attribute sets can be written on one line:
- Short lists or attribute sets can be written on one line:
```nix
```nix
# A short list.
{
list = [ elem1 elem2 elem3 ];
# A short list.
list = [ elem1 elem2 elem3 ];
# A short set.
# A short set.
attrs = { x = 1280; y = 1024; };
attrs = { x = 1280; y = 1024; };
}
```
```
- Breaking in the middle of a function argument can give hard-to-read code, like
- Breaking in the middle of a function argument can give hard-to-read code, like
@ -649,7 +653,7 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
```nix
{ arg1, arg2 }:
{ arg1, arg2 }:
assert system == "i686-linux";
assert system == "i686-linux";
stdenv.mkDerivation { ...
stdenv.mkDerivation { /* ... */ }
```
```
not
not
@ -657,41 +661,41 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
```nix
{ arg1, arg2 }:
{ arg1, arg2 }:
assert system == "i686-linux";
assert system == "i686-linux";
stdenv.mkDerivation { ...
stdenv.mkDerivation { /* ... */ }
```
```
- Function formal arguments are written as:
- Function formal arguments are written as:
```nix
```nix
{ arg1, arg2, arg3 }:
{ arg1, arg2, arg3 }: { /* ... */ }
```
```
but if they don't fit on one line they're written as:
but if they don't fit on one line they're written as:
```nix
```nix
{ arg1, arg2, arg3
{ arg1, arg2, arg3
, arg4, ...
, arg4
, # Some comment...
# Some comment...
argN
, argN
}:
}: { }
```
```
- Functions should list their expected arguments as precisely as possible. That is, write
- Functions should list their expected arguments as precisely as possible. That is, write
```nix
```nix
{ stdenv, fetchurl, perl }: ...
{ stdenv, fetchurl, perl }: <...>
```
```
instead of
instead of
```nix
```nix
args: with args; ...
args: with args; <...>
```
```
or
or
```nix
```nix
{ stdenv, fetchurl, perl, ... }: ...
{ stdenv, fetchurl, perl, ... }: <...>
```
```
For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
@ -700,7 +704,7 @@ Names of files and directories should be in lowercase, with dashes between words
@ -710,32 +714,40 @@ Names of files and directories should be in lowercase, with dashes between words
args:
args:
args.stdenv.mkDerivation (args // {
args.stdenv.mkDerivation (args // {
... if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" ...
foo = if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "";
})
})
```
```
- Unnecessary string conversions should be avoided. Do
- Unnecessary string conversions should be avoided. Do
```nix
```nix
rev = version;
{
rev = version;
}
```
```
instead of
instead of
```nix
```nix
rev = "${version}";
{
rev = "${version}";
}
```
```
- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
```nix
```nix
buildInputs = lib.optional stdenv.isDarwin iconv;
{
buildInputs = lib.optional stdenv.isDarwin iconv;
}
```
```
instead of
instead of
```nix
```nix
buildInputs = if stdenv.isDarwin then [ iconv ] else null;
{
buildInputs = if stdenv.isDarwin then [ iconv ] else null;
}
```
```
As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
@ -270,7 +270,7 @@ It produces packages that cannot be built automatically.
`fetchtorrent` expects two arguments. `url` which can either be a Magnet URI (Magnet Link) such as `magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c` or an HTTP URL pointing to a `.torrent` file. It can also take a `config` argument which will craft a `settings.json` configuration file and give it to `transmission`, the underlying program that is performing the fetch. The available config options for `transmission` can be found [here](https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#options)
`fetchtorrent` expects two arguments. `url` which can either be a Magnet URI (Magnet Link) such as `magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c` or an HTTP URL pointing to a `.torrent` file. It can also take a `config` argument which will craft a `settings.json` configuration file and give it to `transmission`, the underlying program that is performing the fetch. The available config options for `transmission` can be found [here](https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#options)
`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
@ -35,7 +38,9 @@ Those filter functions accept the same arguments the `builtins.filterSource` fun
If you want to make your own filter from scratch, you may use
If you want to make your own filter from scratch, you may use
This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
```nix
```nix
nativeBuildInputs = [ breakpointHook ];
{
nativeBuildInputs = [ breakpointHook ];
}
```
```
When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
@ -7,19 +7,21 @@ The `installManPage` function takes one or more paths to manpages to install. Th
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
```nix
```nix
{
crystalBinaries.mint.src = "src/mint.cr";
crystalBinaries.mint.src = "src/mint.cr";
# ...
# ...
}
```
```
Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
@ -26,7 +26,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
Here is an example:
Here is an example:
```
```nix
pkgs.writeCueValidator
pkgs.writeCueValidator
(pkgs.writeText "schema.cue" ''
(pkgs.writeText "schema.cue" ''
#Def1: {
#Def1: {
@ -42,7 +42,7 @@ pkgs.writeCueValidator
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
Another example, given the following `validator.nix` :
Another example, given the following `validator.nix` :
@ -47,6 +47,7 @@ When an application uses icons, an icon theme should be available in `XDG_DATA_D
In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:
In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:
```nix
```nix
{
buildInputs = [
buildInputs = [
pantheon.elementary-icon-theme
pantheon.elementary-icon-theme
];
];
@ -56,6 +57,7 @@ In the rare case you need to use icons from dependencies (e.g. when an app force
--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS"
--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS"
)
)
'';
'';
}
```
```
To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
@ -85,17 +87,19 @@ If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Gri
Given the requirements above, the package expression would become messy quickly:
Given the requirements above, the package expression would become messy quickly:
```nix
```nix
preFixup = ''
{
for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
preFixup = ''
wrapProgram "$f" \
for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
@ -121,14 +125,16 @@ For convenience, it also adds `dconf.lib` for a GIO module implementing a GSetti
You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
description = "Simple command-line snippet manager, written in Go";
description = "Simple command-line snippet manager, written in Go";
homepage = "https://github.com/knqyf263/pet";
homepage = "https://github.com/knqyf263/pet";
license = lib.licenses.mit;
license = lib.licenses.mit;
maintainers = with lib.maintainers; [ kalbasit ];
maintainers = with lib.maintainers; [ kalbasit ];
};
};
};
}
}
```
```
@ -72,20 +74,22 @@ In the following is an example expression using `buildGoPackage`, the following
- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
@ -153,10 +157,12 @@ A string list of flags to pass to the Go linker tool via the `-ldflags` argument
The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:
The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:
```nix
```nix
{
ldflags = [
ldflags = [
"-X main.Version=${version}"
"-X main.Version=${version}"
"-X main.Commit=${version}"
"-X main.Commit=${version}"
];
];
}
```
```
### `tags` {#var-go-tags}
### `tags` {#var-go-tags}
@ -164,16 +170,20 @@ The most common use case for this argument is to make the resulting executable a
A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`. These constraints control whether Go files from the source should be included in the build. For example:
A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`. These constraints control whether Go files from the source should be included in the build. For example:
You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
@ -115,10 +117,12 @@ After you have identified the correct system, you need to override your package
For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.
This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.
maintainers = with lib.maintainers; [ sternenseemann ];
maintainers = with lib.maintainers; [ sternenseemann ];
};
};
}
```
```
Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
@ -34,23 +34,27 @@ Nixpkgs provides a function `buildPerlPackage`, a generic package builder functi
Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:
Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:
Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
```nix
```nix
foo = import ../path/to/foo.nix {
{
inherit stdenv fetchurl ...;
foo = import ../path/to/foo.nix {
inherit (perlPackages) ClassC3;
inherit stdenv fetchurl /* ... */;
};
inherit (perlPackages) ClassC3;
};
}
```
```
in `all-packages.nix`. You can test building a Perl package as follows:
in `all-packages.nix`. You can test building a Perl package as follows:
@ -91,17 +95,19 @@ buildPerlPackage rec {
Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
@ -109,20 +115,22 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb
This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
However, this is done in its own phase, and not dependent on whether [`doCheck = true;`](#var-stdenv-doCheck).
However, this is done in its own phase, and not dependent on whether [`doCheck = true;`](#var-stdenv-doCheck).
@ -1342,7 +1362,8 @@ pkg3>=1.0,<=2.0
we can do:
we can do:
```
```nix
{
nativeBuildInputs = [
nativeBuildInputs = [
pythonRelaxDepsHook
pythonRelaxDepsHook
];
];
@ -1353,6 +1374,7 @@ we can do:
pythonRemoveDeps = [
pythonRemoveDeps = [
"pkg2"
"pkg2"
];
];
}
```
```
which would result in the following `requirements.txt` file:
which would result in the following `requirements.txt` file:
@ -1365,9 +1387,11 @@ pkg3
Another option is to pass `true`, that will relax/remove all dependencies, for
Another option is to pass `true`, that will relax/remove all dependencies, for
example:
example:
```
```nix
{
nativeBuildInputs = [ pythonRelaxDepsHook ];
nativeBuildInputs = [ pythonRelaxDepsHook ];
pythonRelaxDeps = true;
pythonRelaxDeps = true;
}
```
```
which would result in the following `requirements.txt` file:
which would result in the following `requirements.txt` file:
@ -1392,7 +1416,8 @@ work with any of the [existing hooks](#setup-hooks).
`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:
`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:
```
```nix
{
nativeCheckInputs = [
nativeCheckInputs = [
unittestCheckHook
unittestCheckHook
];
];
@ -1400,6 +1425,7 @@ work with any of the [existing hooks](#setup-hooks).
unittestFlagsArray = [
unittestFlagsArray = [
"-s" "tests" "-v"
"-s" "tests" "-v"
];
];
}
```
```
#### Using sphinxHook {#using-sphinxhook}
#### Using sphinxHook {#using-sphinxhook}
@ -1409,7 +1435,8 @@ using the popular Sphinx documentation generator.
It is setup to automatically find common documentation source paths and
It is setup to automatically find common documentation source paths and
render them using the default `html` style.
render them using the default `html` style.
```
```nix
{
outputs = [
outputs = [
"out"
"out"
"doc"
"doc"
@ -1418,13 +1445,15 @@ render them using the default `html` style.
nativeBuildInputs = [
nativeBuildInputs = [
sphinxHook
sphinxHook
];
];
}
```
```
The hook will automatically build and install the artifact into the
The hook will automatically build and install the artifact into the
`doc` output, if it exists. It also provides an automatic diversion
`doc` output, if it exists. It also provides an automatic diversion
for the artifacts of the `man` builder into the `man` target.
for the artifacts of the `man` builder into the `man` target.
```
```nix
{
outputs = [
outputs = [
"out"
"out"
"doc"
"doc"
@ -1436,14 +1465,17 @@ for the artifacts of the `man` builder into the `man` target.
"singlehtml"
"singlehtml"
"man"
"man"
];
];
}
```
```
Overwrite `sphinxRoot` when the hook is unable to find your
Overwrite `sphinxRoot` when the hook is unable to find your
documentation source root.
documentation source root.
```
```nix
{
# Configure sphinxRoot for uncommon paths
# Configure sphinxRoot for uncommon paths
sphinxRoot = "weird/docs/path";
sphinxRoot = "weird/docs/path";
}
```
```
The hook is also available to packages outside the python ecosystem by
The hook is also available to packages outside the python ecosystem by
@ -1827,6 +1859,7 @@ folder and not downloaded again.
If you need to change a package's attribute(s) from `configuration.nix` you could do:
If you need to change a package's attribute(s) from `configuration.nix` you could do:
```nix
```nix
{
nixpkgs.config.packageOverrides = super: {
nixpkgs.config.packageOverrides = super: {
python3 = super.python3.override {
python3 = super.python3.override {
packageOverrides = python-self: python-super: {
packageOverrides = python-self: python-super: {
@ -1841,6 +1874,7 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
};
};
};
};
};
};
}
```
```
`python3Packages.twisted` is now globally overridden.
`python3Packages.twisted` is now globally overridden.
@ -1853,11 +1887,13 @@ To modify only a Python package set instead of a whole Python derivation, use
this snippet:
this snippet:
```nix
```nix
{
myPythonPackages = python3Packages.override {
myPythonPackages = python3Packages.override {
overrides = self: super: {
overrides = self: super: {
twisted = ...;
twisted = <...>;
};
};
}
};
}
```
```
### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}
### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}
Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
```nix
```nix
{
gems = bundlerEnv {
gems = bundlerEnv {
name = "gems-for-some-project";
name = "gems-for-some-project";
gemdir = ./.;
gemdir = ./.;
extraConfigPaths = [ "${./.}/.ruby-version" ];
extraConfigPaths = [ "${./.}/.ruby-version" ];
};
};
}
```
```
### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}
### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}
@ -219,9 +219,11 @@ After running the updater, if nvim-treesitter received an update, also run [`nvi
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
dependencies = with super; [ deoplete-nvim vim-fish ];
});
}
```
```
Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
@ -264,8 +266,10 @@ pwntester/octo.nvim,,
You can then reference the generated vim plugins via:
You can then reference the generated vim plugins via:
@ -13,11 +13,13 @@ Once an Eclipse variant is installed, it can be run using the `eclipse` command,
If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
```nix
```nix
packageOverrides = pkgs: {
{
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
packageOverrides = pkgs: {
eclipse = eclipse-platform;
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
jvmArgs = [ "-Xmx2048m" ];
eclipse = eclipse-platform;
plugins = [ plugins.color-theme ];
jvmArgs = [ "-Xmx2048m" ];
plugins = [ plugins.color-theme ];
};
};
};
}
}
```
```
@ -33,32 +35,34 @@ If there is a need to install plugins that are not available in Nixpkgs then it
Expanding the previous example with two plugins using the above functions, we have:
Expanding the previous example with two plugins using the above functions, we have:
```nix
```nix
packageOverrides = pkgs: {
{
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
packageOverrides = pkgs: {
eclipse = eclipse-platform;
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
@ -16,7 +16,7 @@ The Emacs package comes with some extra helpers to make it easier to configure.
projectile
projectile
use-package
use-package
]));
]));
}
};
}
}
```
```
@ -102,10 +102,12 @@ This provides a fairly full Emacs start file. It will load in addition to the us
Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to GNU-devel ELPA, and the highest for packages manually defined in `pkgs/applications/editors/emacs/elisp-packages/manual-packages`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope`.
Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to GNU-devel ELPA, and the highest for packages manually defined in `pkgs/applications/editors/emacs/elisp-packages/manual-packages`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope`.
WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:
WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:
@ -15,7 +15,9 @@ Nixpkgs follows the [conventions of GNU autoconf](https://gcc.gnu.org/onlinedocs
In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:
In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:
@ -127,7 +129,9 @@ Some frequently encountered problems when packaging for cross-compilation should
Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefix. For instance, instead of `cc`, use `${stdenv.cc.targetPrefix}cc`.
Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefix. For instance, instead of `cc`, use `${stdenv.cc.targetPrefix}cc`.
```nix
```nix
makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];
{
makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];
}
```
```
#### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}
#### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}
@ -142,7 +146,9 @@ $ nix-build '<nixpkgs>' -A pkgsCross.raspberryPi.hello
Add the following to your `mkDerivation` invocation.
Add the following to your `mkDerivation` invocation.
```nix
```nix
depsBuildBuild = [ buildPackages.stdenv.cc ];
{
depsBuildBuild = [ buildPackages.stdenv.cc ];
}
```
```
#### My package’s testsuite needs to run host platform code. {#cross-testsuite-runs-host-code}
#### My package’s testsuite needs to run host platform code. {#cross-testsuite-runs-host-code}
Nix packages can declare *meta-attributes* that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a `meta` declaration like this:
Nix packages can declare *meta-attributes* that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a `meta` declaration like this:
```nix
```nix
meta = {
{
description = "A program that produces a familiar, friendly greeting";
meta = {
longDescription = ''
description = "A program that produces a familiar, friendly greeting";
GNU Hello is a program that prints "Hello, world!" when you run it.
longDescription = ''
It is fully customizable.
GNU Hello is a program that prints "Hello, world!" when you run it.
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.
@ -45,6 +47,10 @@ Release branch. Used to specify that a package is not going to receive updates t
The package’s homepage. Example: `https://www.gnu.org/software/hello/manual/`
The package’s homepage. Example: `https://www.gnu.org/software/hello/manual/`
### `repository` {#var-meta-repository}
A webpage where the package's source code can be viewed. `https` links are preferred if available. Automatically set to a default value if the package uses a `fetchFrom*` fetcher for its `src`. Example: `https://github.com/forthy42/gforth`
### `downloadPage` {#var-meta-downloadPage}
### `downloadPage` {#var-meta-downloadPage}
The page where a link to the current version can be found. Example: `https://ftp.gnu.org/gnu/hello/`
The page where a link to the current version can be found. Example: `https://ftp.gnu.org/gnu/hello/`
@ -82,7 +88,9 @@ The *priority* of the package, used by `nix-env` to resolve file name conflicts
The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
```nix
```nix
meta.platforms = lib.platforms.linux;
{
meta.platforms = lib.platforms.linux;
}
```
```
Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.
Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.
@ -95,8 +103,10 @@ In general it is preferable to set `meta.platforms = lib.platforms.all` and then
For example, a package which requires dynamic linking and cannot be linked statically could use this:
For example, a package which requires dynamic linking and cannot be linked statically could use this:
The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.
The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.
@ -136,7 +146,7 @@ For more on how to write and run package tests, see [](#sec-package-tests).
The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
```nix
```nix
{ /* ... */, nixosTests }:
{ /* ... , */ nixosTests }:
{
{
# ...
# ...
passthru.tests = {
passthru.tests = {
@ -194,8 +204,10 @@ To be effective, it must be presented directly to an evaluation process that han
The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
```nix
```nix
meta.platforms = lib.platforms.linux;
{
meta.hydraPlatforms = [];
meta.platforms = lib.platforms.linux;
meta.hydraPlatforms = [];
}
```
```
### `broken` {#var-meta-broken}
### `broken` {#var-meta-broken}
@ -209,13 +221,17 @@ This means that `broken` can be used to express constraints, for example:
@ -30,7 +30,9 @@ Here you find how to write a derivation that produces multiple outputs.
In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in `<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>`; it’s relatively well-readable. The whole machinery is triggered by defining the `outputs` attribute to contain the list of desired output names (strings).
In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in `<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>`; it’s relatively well-readable. The whole machinery is triggered by defining the `outputs` attribute to contain the list of desired output names (strings).
```nix
```nix
outputs = [ "bin" "dev" "out" "doc" ];
{
outputs = [ "bin" "dev" "out" "doc" ];
}
```
```
Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere.
Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere.
@ -496,18 +504,22 @@ A script to be run by `maintainers/scripts/update.nix` when the package is match
- [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.
- [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.
```nix
```nix
passthru.updateScript = {
{
command = [ ../../update.sh pname ];
passthru.updateScript = {
attrPath = pname;
command = [ ../../update.sh pname ];
supportedFeatures = [ … ];
attrPath = pname;
};
supportedFeatures = [ /* ... */ ];
};
}
```
```
::: {.tip}
::: {.tip}
A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update):
A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update):
```nix
```nix
passthru.updateScript = nix-update-script { };
{
passthru.updateScript = nix-update-script { };
}
```
```
For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases).
For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases).
@ -846,7 +858,9 @@ The file name of the Makefile.
A list of strings passed as additional flags to `make`. These flags are also used by the default install and check phase. For setting make flags specific to the build phase, use `buildFlags` (see below).
A list of strings passed as additional flags to `make`. These flags are also used by the default install and check phase. For setting make flags specific to the build phase, use `buildFlags` (see below).
```nix
```nix
makeFlags = [ "PREFIX=$(out)" ];
{
makeFlags = [ "PREFIX=$(out)" ];
}
```
```
::: {.note}
::: {.note}
@ -858,9 +872,11 @@ The flags are quoted in bash, but environment variables can be specified by usin
A shell array containing additional arguments passed to `make`. You must use this instead of `makeFlags` if the arguments contain spaces, e.g.
A shell array containing additional arguments passed to `make`. You must use this instead of `makeFlags` if the arguments contain spaces, e.g.
Note that shell arrays cannot be passed through environment variables, so you cannot set `makeFlagsArray` in a derivation attribute (because those are passed through environment variables): you have to define them in shell code.
Note that shell arrays cannot be passed through environment variables, so you cannot set `makeFlagsArray` in a derivation attribute (because those are passed through environment variables): you have to define them in shell code.
@ -892,7 +908,9 @@ The check phase checks whether the package was built correctly by running its te
Controls whether the check phase is executed. By default it is skipped, but if `doCheck` is set to true, the check phase is usually executed. Thus you should set
Controls whether the check phase is executed. By default it is skipped, but if `doCheck` is set to true, the check phase is usually executed. Thus you should set
```nix
```nix
doCheck = true;
{
doCheck = true;
}
```
```
in the derivation to enable checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doCheck` is set, as the newly-built program won’t run on the platform used to build it.
in the derivation to enable checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doCheck` is set, as the newly-built program won’t run on the platform used to build it.
@ -945,7 +963,9 @@ See the [build phase](#var-stdenv-makeFlags) for details.
The make targets that perform the installation. Defaults to `install`. Example:
The make targets that perform the installation. Defaults to `install`. Example:
@ -1024,7 +1044,7 @@ This example prevents all `*.rlib` files from being stripped:
```nix
```nix
stdenv.mkDerivation {
stdenv.mkDerivation {
# ...
# ...
stripExclude = [ "*.rlib" ]
stripExclude = [ "*.rlib" ];
}
}
```
```
@ -1033,7 +1053,7 @@ This example prevents files within certain paths from being stripped:
```nix
```nix
stdenv.mkDerivation {
stdenv.mkDerivation {
# ...
# ...
stripExclude = [ "lib/modules/*/build/* ]
stripExclude = [ "lib/modules/*/build/*" ];
}
}
```
```
@ -1134,7 +1154,9 @@ It is often better to add tests that are not part of the source distribution to
Controls whether the installCheck phase is executed. By default it is skipped, but if `doInstallCheck` is set to true, the installCheck phase is usually executed. Thus you should set
Controls whether the installCheck phase is executed. By default it is skipped, but if `doInstallCheck` is set to true, the installCheck phase is usually executed. Thus you should set
```nix
```nix
doInstallCheck = true;
{
doInstallCheck = true;
}
```
```
in the derivation to enable install checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doInstallCheck` is set, as the newly-built program won’t run on the platform used to build it.
in the derivation to enable install checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doInstallCheck` is set, as the newly-built program won’t run on the platform used to build it.
@ -1244,9 +1266,11 @@ To use this, add `removeReferencesTo` to `nativeBuildInputs`.
As `remove-references-to` is an actual executable and not a shell function, it can be used with `find`.
As `remove-references-to` is an actual executable and not a shell function, it can be used with `find`.
Example removing all references to the compiler in the output:
Example removing all references to the compiler in the output:
```nix
```nix
postInstall = ''
{
find "$out" -type f -exec remove-references-to -t ${stdenv.cc} '{}' +
postInstall = ''
'';
find "$out" -type f -exec remove-references-to -t ${stdenv.cc} '{}' +
In the first example, `pkgs.foo` is the result of a function call with some default arguments, usually a derivation. Using `pkgs.foo.override` will call the same function with the given new arguments.
In the first example, `pkgs.foo` is the result of a function call with some default arguments, usually a derivation. Using `pkgs.foo.override` will call the same function with the given new arguments.
@ -45,9 +47,11 @@ The function `overrideAttrs` allows overriding the attribute set passed to a `st
In the above example, the `name`, `src`, and `patches` of the derivation will be overridden, while all other attributes will be retained from the original derivation.
In the above example, the `name`, `src`, and `patches` of the derivation will be overridden, while all other attributes will be retained from the original derivation.
@ -112,8 +120,10 @@ The function `lib.makeOverridable` is used to make the result of a function easi
Example usage:
Example usage:
```nix
```nix
f = { a, b }: { result = a+b; };
{
c = lib.makeOverridable f { a = 1; b = 2; };
f = { a, b }: { result = a+b; };
c = lib.makeOverridable f { a = 1; b = 2; };
}
```
```
The variable `c` is the value of the `f` function applied with some default arguments. Hence the value of `c.result` is `3`, in this example.
The variable `c` is the value of the `f` function applied with some default arguments. Hence the value of `c.result` is `3`, in this example.