We are replicating one mechanism behind `-Z build-std`.
There isn't yet crate2nix support for this, but one can (and I do) add
the missing stdlib deps (for this feature to pick up) with overrides.
(cherry picked from commit cc29693a09)
(cherry picked from commit 5aef865cef)
It is possible to both be bare metal and have a libc (newlib).
This libc doesn't provide very much --- not enough for CMake to think
the C toolchain works. We therefore adjust our logic so we hit the "bare
metal" case with or without libc.
The "use LLVM" bootstrap is intentionally not affected.
(cherry picked from commit bf39e32272)
(cherry picked from commit c820cd8cee)
This test reproducibly triggers the max open files limit on our
aarch64 hydra builders. Disable it for now to make tests work again but
this can't be the final solution.
https://hydra.nixos.org/build/179001754
(cherry picked from commit 3fcf9f18dd)
For non-time metrics it doesn't matter,
and those seem more important anyway.
So better this than nothing, for now.
(cherry picked from commit 3ea36f0f74)
Previously, all configuration and state data was accessible to all
users on the system running jellyfin. This included user passwords in
the Jellyfin database, as well as credentials for LDAP if configured.
The exact set of accessible data depends on system configuration.
Thanks to Sofie Finnes Øvrelid for reporting this issue.
Fixes: CVE-2022-32198
Co-Authored-By: Martin Weinelt <hexa@darmstadt.ccc.de>
(cherry picked from commit 7eab23d517)
LLVM 14 doesn't support those build flags yet
(-no-opaque-pointers is the argument for -Xclang):
error: unknown argument: '-no-opaque-pointers'
Those build flags were added in the following commit:
003067c130
(cherry picked from commit 7f684c2ba0)
This fixes the following error:
configuring
ERROR at //infra/orchestrator/BUILD.gn:38:17: Could not read file.
pydeps_file = "//third_party/blink/tools/merge_web_test_results.pydeps"
^--------------------------------------------------------
I resolved this to "/build/chromium-102.0.5005.27/third_party/blink/tools/merge_web_test_results.pydeps".
See //infra/orchestrator/BUILD.gn:37:1: whence it was called.
python_library("blink_merge_web_test_results_py") {
^--------------------------------------------------
See //BUILD.gn:89:5: which caused the file to be included.
"//infra/orchestrator:orchestrator_all",
^--------------------------------------
It's a known upstream issue when building from the generated tarballs:
- https://bugs.chromium.org/p/chromium/issues/detail?id=1313361
- https://chromium-review.googlesource.com/c/chromium/src/+/3457503
(cherry picked from commit 73e094bf3c)
This fixes the following error during patchShebangs:
./third_party/dawn/third_party/webgpu-cts/tools/run_deno: unsupported interpreter directive "#!/usr/bin/env -S deno run --unstable --allow-read --allow-write --allow-env --allow-net=deno.land --no-check" (set dontPatchShebangs=1 and handle shebang patching yourself)
(cherry picked from commit 3e8d4d6237)
Commit 49d0a5afd mistakenly inverted when to apply the patch.
Maybe it's not needed anymore, as pkgsMusl.e2fsprogs succeeded for me
even without it, but it looks harmless and better not have it inversed.
This way we also don't cause a mass rebuild :-)
(cherry picked from commit f008987704)
We're still using 8.4.x on 21.11 because 8.5 contained a few breaking
changes[1]. The patch for 8.5[2] was almost compatible with 8.4, but had
to be modified a bit because `New` in `http_client_provider` had a
slightly different signature:
func New(cfg *setting.Cfg, tracer tracing.Tracer, features featuremgmt.FeatureToggles) *sdkhttpclient.Provider
on 8.4.7 vs
func New(cfg *setting.Cfg, tracer tracing.Tracer) *sdkhttpclient.Provider
on 8.5.2.
I only had to adjust the signature in the test (because `PluginRequestValidator`
was added), but nothing else because these calls are automatically
resolved via `wire`.
[1] https://github.com/grafana/grafana/releases/tag/v8.5.0
[2] 2f75684500
Added Nextcloud 23 and set it as the default Nextcloud version for the
NixOS module. Added PHP 8.1 as an option for phpPackage and default for
Nextcloud ≥ 24.
(cherry picked from commit ecd8d42397)
Backport #171736 to release-21.11. We have multiple attributes for
different majors, so this is technically a new package that can be
backported.
The defaults aren't changed, so nextcloud22 is still the default for
NixOS 21.11. We have also removed php81 references, as that has not been
backported to 21.11.
Remove the -Werror=format-security compiler option when using Clang, because
recutils does not build with it enabled.
(cherry picked from commit 3ece875b60)
See also #169928 for a PR that would fix this vulnerability; after a
brief discussion with @Ma27 we came to the conclusion that breaking
backwards compatibility silently is more of a pain than breaking
evaluation loudly. We consider the severity of this vulnerability as
relatively low, because prometheus exporters should usually not be
publicly accessible anyway, and believe that this is the best approach
to allowing people who run the exporter the choice of running the
compatible version.
Closes#169928.
Backporting #166389
This includes changes from 3.1.0 and 3.1.1.
This is fully backwards-compatible. There is one new subcommand (list-stacks) added to the CLI, all other changes are to internals, testing, and documentation.
The hiljusti/sigi#19
is complete, so testing now happens with no skips at all.
hiljusti/sigi@v3.0.3...v3.1.1
Fixes#166833.
The build creates a symlink for this assuming it's present,
so be sure it's there when filtering the source for clang.
Alternatively we could use LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR.
(cherry picked from commit 075c5eb8d3)
The test would previously error out like this:
> synapse_homeserver[1155]: synapse.config._base.ConfigError: You have
> enabled open registration without any verification. This is a known
> vector for spam and abuse. If you would like to allow public
> registration, please consider adding email, captcha, or token-based
> verification. Otherwise this check can be removed by setting the
> `enable_registration_without_verification` config option to `true`.
(cherry picked from commit 1d2a0b801a)
- The c_rehash script allows command injection (CVE-2022-1292)
- OCSP_basic_verify may incorrectly verify the response signing
certificate (CVE-2022-1343)
- Incorrect MAC key used in the RC4-MD5 ciphersuite (CVE-2022-1434)
- Resource leakage when decoding certificates and keys (CVE-2022-1473)
https://mta.openssl.org/pipermail/openssl-announce/2022-May/000224.html
Fixes: CVE-2022-1292, CVE-2022-1343, CVE-2022-1434, CVE-2022-1473
(cherry picked from commit c62eceb91e)
These features are internal-only, have special characters that bash
doesn't support in variable names, and aren't normally given
environment variables by cargo as far as I can tell.
(cherry picked from commit ede639a8d6)
This fixes build errors like this:
error: Could not read profile ../../chrome/build/pgo_profiles/chrome-linux-4951-1649181099-528ef6669805f2d3db6f3ad7429cfa57a6078271.profdata: unsupported instrumentation profile format version
We already package the most recent stable LLVM version for Chromium but Google
relies on unreleased (Git) versions (thanks...). This isn't ideal but I
don't have the time to package yet another LLVM version so it'll have to
cut it for now.
See build/config/compiler/pgo/pgo.gni:
- 0 : Means that PGO is turned off.
- 1 : Used during the PGI (instrumentation) phase.
- 2 : Used during the PGO (optimization) phase.
With is_official_build the default is chrome_pgo_phase = 2.
(cherry picked from commit 15623bcb65)
GConf has been deprecated for ages and support for it removed from Chromium a while ago:
- Removal of `use_gconf` gn build system flag:
a28f4d062f
(cherry picked from commit e3e625ffe4)
Commit 6df37c9aab bumped the version of
evtest but failed to update the hash. As a result, hosts which
already have evtest-1.33 source present will build the old version but
label it as evtest-1.34. Hosts which lack the older source code will
fail their builds. This commit corrects the issue.
We should think about a way to get Hydra to catch issues like this.
Maybe require that if two FODs have different hashes then they must
have different `${pname}-${version}`s? Only for FODs, of course.
(cherry picked from commit 9a0fd1e35e)
The latest version of nixpkgs.firecracker (1.0.0) is incompatible
with version 0.1.0 of firectl. Must use latest HEAD in upstream
to pick up breaking changes in the API. See:
https://github.com/firecracker-microvm/firectl/issues/82
(cherry picked from commit 6c87c725e2)
- format with nixpkgs-fmt
- use more conventional attribute ordering
- remove non-existent file from patchShebang args
- remove unnecessary if from sphinx-build binding (Nix is lazy so we do not need to null it when not used)
(cherry picked from commit 2144f37d36)
"The websites yt-dlp deals with are a very moving target. That means that
downloads break constantly. Because of that, updates should always be backported
to the latest stable release."
(cherry picked from commit 7833517adc)
This fixes a buffer overflow in NeoMutt, to quote the original
report[1]:
> Hello, In mutt_decode_uuencoded(), the line length is read from the
> untrusted uuencoded part without validation. This could result in
> including private memory in message parts, for example fragments of
> other messages, passphrases or keys in replys.
Security advistory for the corresponding CVE-2022-1328 is on GitHub[2].
Applying the entire release 20220415 is IMHO too risky because too much
has changed, but applying the patch only works fine as well here.
In NeoMutt 20220415 / Mutt 2.2.3 there's also a fix for an integer
overflow[3] of a `strlen()` for very large messages which is however not
exploitable for NeoMutt according to the upstream maintainers[4], so I
won't backport this patch as well.
Related to https://github.com/NixOS/nixpkgs/pull/168800.
[1] https://gitlab.com/muttmua/mutt/-/issues/404
[2] https://github.com/advisories/GHSA-qfrq-pp74-gpff
[3] https://gitlab.com/muttmua/mutt/-/issues/405
[4] 2bedc9762e:
No-op release: https://github.com/grafana/grafana/releases/tag/v8.4.6
Yes, this is actually not really needed since we only provide the OSS
version of Grafana and the CVE in question is only exploitable on
Grafana enterprise, but I decided to perform this update to test the
update script I previously implemented in 7708fccf01.
(cherry picked from commit e633d42747)
users.users.*.createHome makes home only owner-readable.
This breaks nginx reading static assets from nextcloud's home,
after a nixos-rebuild that did not restart nextcloud-setup.
Closes#112639
(cherry picked from commit 956dab36a3)
The test was fine for a day and started failing again yesterday, so we
disable it this time until upstream makes a new release with more
confidence.
(cherry picked from commit ef7564a0ac)
Twisted versions before 22.1 would leak cookie and authorization headers
when following cross-origin redirects in
`twisted.web.client.RedirectAgent` and
`twisted.web.client.BrowserLikeRedirectAgent`.
Fixes: #CVE-2022-21712
Fixes race conditions like this:
> systemd[1]: Started prometheus-kea-exporter.service.
> kea-exporter[927]: Listening on http://0.0.0.0:9547
> kea-exporter[927]: Socket at /run/kea/dhcp4.sock does not exist. Is Kea running?
> systemd[1]: prometheus-kea-exporter.service: Main process exited, code=exited, status=1/FAILURE
(cherry picked from commit 8b7ca8bdcb)
This commit exposes that support for compilation without systemd,
controlled by the global systemdSupport argument. This argument is
understood by many other nixpkgs expressions and can be set globally
in ~/.config/nixpkgs/config.nix.
(cherry picked from commit 5f9ce130b2)
This ensures that our build flags for ungoogled-chromium will remain
up-to-date with upstream's defaults (also important for avoiding build
errors).
Co-authored-by: Michael Weiss <dev.primeos@gmail.com>
(cherry picked from commit 1122130c6f)
Most of these just need JAVA_HOME, but a few assume that java is in PATH
(cherry picked from commit 1449c4e28d)
Co-authored-by: Benjamin Staffin <benley@gmail.com>
With Firefox 98.0 the remoting name now depends on the update channel
(mozbz#1752418), which resulted in a weird app_id/wmclass of
`firefox-default`, which broke window association in GNOME and likely
other desktops.
Fixes: #165107
(cherry picked from commit 3ec7f8d487)
The new repo has the same maintainer and is the continuation of the repo
used prior to this commit.
Closes#147053
(cherry picked from commit 31077c9148)
The patch that was previously fetched from GitHub is now part of the
4.5.1 release, and is no longer needed. Furthermore, 4.5.1 introduces
some new scripts to build manpages, and some new build inputs are
required to make that work.
This also rebases the Darwin patch. I don't have a Mac so I can't test
this personally. There was one conflict:
diff --cc squashfs-tools/read_xattrs.c
index 2067f80,b28c3a0..0000000
--- a/squashfs-tools/read_xattrs.c
+++ b/squashfs-tools/read_xattrs.c
@@@ -36,9 -38,7 +38,7 @@@
#include "xattr.h"
#include "error.h"
- #include <stdlib.h>
-
-extern int read_fs_bytes(int, long long, int, void *);
+extern int read_fs_bytes(int, long long, long long, void *);
extern int read_block(int, long long, long long *, int, void *);
static struct hash_entry {
Resolved by updating the signature from int to long long.
(cherry picked from commit ed81545df5)
- Add adfs and keycloak-oidc providrs
- Sort the list alphabetically
(cherry picked from commit eef56691e3)
Co-authored-by: Benjamin Staffin <benley@gmail.com>
The argument to addNodePath previously wasn't being quoted, leading to
problems when the argument contains characters interpreted specially by
bash
(cherry picked from commit e975c56501)
https://downloads.apache.org/httpd/CHANGES_2.4.53
Migrating to pcre2 was recommended in the release notes, since pcre 8.x
is over 20 years old and has now reached its end of life.
Fixes: CVE-2022-23943, CVE-2022-22721, CVE-2022-22720, CVE-2022-22719
(cherry picked from commit 6bf3336975)
Without this fix, evaluating a NixOS configuration with Tomcat enabled and the
default settings results in the following evaluation error:
Failed assertions:
- users.users.tomcat.group is unset. This used to default to
nogroup, but this is unsafe. For example you can create a group
for this user with:
users.users.tomcat.group = "tomcat";
users.groups.tomcat = {};
(cherry picked from commit d12186a601)
I was actively maintaining the package but stopped using it since the
Ozone/Wayland support broke (e06082eda0 - and I was already migrating
away from Signal anyway).
Mic92 kindly offered to take over and equirosa also offered to become
active again. So it should be in good hands :)
And thank you ixmatus for packaging Signal-Desktop in Nixpkgs.
(cherry picked from commit 52cbeeda30)
Follow-up on https://github.com/NixOS/nixpkgs/pull/161426.
Explain why having legacy iptables rules installed can lead to confusing
firewall behaviour, and provide some guidance on how to fix this.
(cherry picked from commit 788abdba4b)
a little ugly, but minidlna now checks requests Host: header and
only accepts requests using an IPv4 address to avoid DNS-rebinding
attacks.
(cherry picked from commit 97572a798c)
As `nix-daemon.service` does not make use of `ExecStop`, we prefer
to keep the socket up and available. This is important for machines
that run Nix-based services, such as automated build, test, and deploy
services, that expect the daemon socket to be available at all times.
See committed inline comment for further explanation.
(cherry picked from commit b550b4b6f8)
This fixes the following issues with the database provisioning script
included in the services.keycloak module:
- It lacked permission to access the DB password file specified in the
module option 'services.keycloak.database.passwordFile'.
- It prevented Keycloak from starting after the second time if the user
chose MySQL for the database.
(cherry picked from commit dc5bd4b375)
Upstream no longers signs the tarball directly; instead they sign the
sha256sum file[1]. Also, the signing keys have changed, and the
latest release is signed with a key we didn't have before.
[1]: dd17604bb3
(cherry picked from commit 9307a4d328)
these may not be reliable enough to enable by default, but enabling
them as a passthru may allow us to get a feel for which platforms
have trouble with them
(cherry picked from commit 5adc3817a0)
Fixed a use-after-free issue where logged_in_context is used in update_style().
There are several reports for this but upstream has no action for this so far during the 6.x cycle.
See the provided link for more details.
(cherry picked from commit f29955df81)
Note: the above is the original commit message, the patch has been accepted on upstream.
This "fixes" the following error:
gen/shim_headers/opus_shim/third_party/opus/src/include/opus.h:5:10: error: 'opus.h' file not found with <angled> include; use "quotes" instead
^~~~~~~~
"opus.h"
Our system library isn't discovered anymore so I'm switching to the bundled
Opus library for now since I don't have time to look into it.
(cherry picked from commit 1bdf7862e3)
This fixes the following build error:
[24751/48400] ACTION //components/url_formatter/spoof_checks/top_domains:generate_top_domain_list_variables_file(//build/toolchain/linux/unbundle:default)d_tmp/browser_command.mojom-webui.js.mojom-webui.jsui.js
FAILED: gen/components/url_formatter/spoof_checks/top_domains/top500-domains-inc.cc
python3 ../../build/gn_run_binary.py make_top_domain_list_variables ../../components/url_formatter/spoof_checks/top_domains/domains.list top500_domains gen/components/url_formatter/spoof_checks/top_domains/top500-domains-inc.cc
make_top_domain_list_variables failed with exit code -4
The "make_top_domain_list_variables" program fails due to a SIGILL error
(illegal instruction). See:
- https://bugs.chromium.org/p/chromium/issues/detail?id=1273966
- https://reviews.llvm.org/D115015
- https://bugs.chromium.org/p/chromium/issues/detail?id=1269407
(cherry picked from commit c0952b6478)
This is important so that users can choose to use other implementations
(e.g., self-written Bash scripts).
We only provide xdg-utils as a fallback in case the system isn't
properly configured.
(cherry picked from commit 37a19c55df)
Chromium appears to require bin/java at build-time. This patch causes
the chromium derivation to use jre8_headless instead of jre8, in order
to avoid dragging in all of gnome.
(cherry picked from commit 02ae3defed)
This fixes a CI warning [0]:
Run cat "$HOME/changed_files" | xargs -r editorconfig-checker -disable-indent-size
pkgs/development/compilers/llvm/14/lld/default.nix:
28: Wrong indent style found (tabs instead of spaces)
29: Wrong indent style found (tabs instead of spaces)
30: Wrong indent style found (tabs instead of spaces)
[0]: https://github.com/NixOS/nixpkgs/runs/5351700772
(cherry picked from commit 45cd41de23)
This is a temporary hack until I have time to update the patches for
14.0.0-rc1. We need llvmPackages_14 *NOW* for Chromium M99.
(cherry picked from commit d61e45b686)
This change probably wasn't documented sufficiently in the release
notes, neither the fact systemd stopped using iptables on its own in
case of nf_tables support.
Fixes#156041.
(cherry picked from commit 753a43caf0)
64b4af5296 ("kmod-blacklist-ubuntu: 22-1.1ubuntu1 -> 28-1ubuntu4")
doubled the size of the default initramfs. This happened because the
upgrade introduced this configuration:
remove iwlwifi \
(/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs /sbin/rmmod) \
&& /sbin/modprobe -r mac80211
This meant that the grep and xargs substitutions, which had been
inactive for years, suddenly became active again and became part of
kmod-blacklist-ubuntu's closure.
Since we're already using /run/booted-system for the kmod binaries,
I think it's okay to use it for grep and xargs as well. Both are
required NixOS packages, so they're guaranteed to be there.
Large increases in initramfs size are problematic, because it's often
not possible for users to do anything about them. It's not always
possible to increase the size of /boot, because some filesystems like
ZFS don't support being shrunk to make way for a bigger /boot.
(cherry picked from commit 0100a75801)
According to https://reviews.llvm.org/D96164, aarch64-darwin executables
require at least an ad hoc signature.
The build tool from the racket repo tries to sign $out/bin/racket but
errors out, because that binary already has a signature.
It is not clear yet at which stage the signature was introduced. This
patch removes the existing signature always before calling
add-ad-hoc-signature to circumvent that error.
(cherry picked from commit 152b59855d)
PRUNE_BIND_MOUNTSFR seems to be a typo.
The man page only mentions it in a header and further in the paragraph
it is PRUNE_BIND_MOUNTS.
Also breaks plocate which complains about the unknown option.
The command in example is expected to be run from nixpkgs checkout, but
there's no explanation of this. Let's just use system nixpkgs: most
users will have it just working and those who use git checkouts will
figure it out.
(cherry picked from commit bd7a47e27b)
This was EOL by the time it was introduced into nixpkgs and should have
never gotten merged in the first place.
Browsers are complex beasts, and those that haven't seen an update in
two years simply cannot be secure.
...into release-21.11
This time really with excluding the update of `firefox` attribute.
(Sigh, once again I got caught by refs/remotes/pr/$num on GitHub
being updated slower than anticipated.)
I'm deploying my own Hydra via flakes for a while now and while this
package actually needs more love and a few updates, I don't have the
capacity to take care of this.
(cherry picked from commit a215ce7fa5)
It turns out it's actually possible to fall back to WPA2 in case the
authentication fails with WPA3. This was suggested to me in the hostapd
mailing list: add another network block with only WPA2 and lower
priority, for each network with WPA3. For clients with missing/broken
WPA3, wpa_supplicant will:
1. try the network block with higher priority first
2. fail and temporarily disable the network block
3. try the fallback network block and connect
This takes a little more time (still <5s) because wpa_supplicant
retries a couple times before disabling the network block, but it allows
old client to gracefully fall back to WPA2 on mixed WPA2/WPA3 networks.
To avoid downgrade attacks, clients with proper WPA3 should disable
this; in the future we may want to disable this option by default.
(cherry picked from commit 2eed89bbe1)
Alternative solution to PR #152443.
This fixes authentication failures to WPA3 networks (issue #151729)
by enabling protected management frames.
Note: old client without 802.11w support will still fail.
(cherry picked from commit 2f5ced6d7c)
Change comment type so than nixdoc picks them up into Nixpkgs manual.
Also improve phrasing a bit and move stuff around so that it is formatted better.
(cherry picked from commit 1e1396aafc)
We're pulling from a random fork, so switch to the actual upstream.
Also change to use buildGoModule instead of buildGoPackage.
(cherry picked from commit b8f6ce151a)
Co-authored-by: Zane van Iperen <zane@zanevaniperen.com>
Co-Authored-By: Martin <stackshadow@evilbrain.de>
Flake users that use a command like `nix build nixpkgs#hello` on a
broken/insecure package will not be able to use an environment variable
to override that behavior, unless they pass `--impure` to the command.
Co-authored-by: pkharvey <kayharvey@protonmail.com>
(cherry picked from commit 36f2aa12e6)
fixes#157920.
nuking the references in `magick_config.h` also nuked the references to
the package's own `delegates.mgk`, needed for determining which external
tools to use for handling of e.g. pdf files.
(cherry picked from commit 2eb5c569a8)
This fixes:
--------------------------------------------------------------------------------
configuring
ERROR at //ui/gtk/BUILD.gn:17:1: Assertion failed.
assert(use_gio, "GIO is required for building with GTK")
^-----
GIO is required for building with GTK
See //content/shell/BUILD.gn:308:15: which caused the file to be included.
deps += [ "//ui/gtk" ]
^---------
--------------------------------------------------------------------------------
But there's still another build issue(s) left:
--------------------------------------------------------------------------------
[25491/48383] ACTION //components/url_formatter/spoof_checks/top_domains:generate_top_domain_list_variables_file(//build/toolchain/linux/unbundle:default)d_tmp/browser_command.mojom-webui.jsab_page_third_party.mojom-webui.js
FAILED: gen/components/url_formatter/spoof_checks/top_domains/top500-domains-inc.cc
python3 ../../build/gn_run_binary.py make_top_domain_list_variables ../../components/url_formatter/spoof_checks/top_domains/domains.list top500_domains gen/components/url_formatter/spoof_checks/top_domains/top500-domains-inc.cc
make_top_domain_list_variables failed with exit code -4
ninja: build stopped: subcommand failed.
--------------------------------------------------------------------------------
(cherry picked from commit e8b241cdba)
NixOS stores ICDs at /run/opengl-driver/share/vulkan/icd.d/. Because
Chrome ships its own vulkan-loader and doesn't use the NixOS system
vulkan-loader, Chrome won't search the /run/opengl-driver directory
withou either adding it to the path or patching Chrome's libvulkan.so.1.
This change adds "${addOpenGLRunpath.driverLink}/share" unconditionally
to the path. addOpenGLRunpath is the same module that NixOS system
vulkan-loader uses as the path.
Tested by running `VK_LOADER_DEBUG=all google-chrome-unstable
--enable-features=Vulkan` and verifying Vulkan is enabled with
chrome://gpu.
(cherry picked from commit 007af34263)
This will be required to prevent crashes on Wayland compositors that
support version 4 of the wl_output protocol (available since Wayland
1.20.0). This should affect any compositor that is based on wlroots
0.15.0 and soon more. Upstream will hopefully backport those patches
soon (if not we could also apply them to M97 - only two trivial
changes are necessary to apply the first patch).
More information:
- Chromium bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1279574
- wlroots bug report: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3344
(cherry picked from commit 843508dad4)
* make slurmd depend on network target to ensure basic networking
is available on startup. This fixes behaviour
where slurmd fails with "error: get_addr_info: getaddrinfo() failed".
* Use tmpfiles.d to ensure spool directory exists on start up.
(cherry picked from commit 270da0a115)
When no devices are given the exporter tries to autodiscover available
disks. The previous DevicePolicy was however preventing the exporter
from accessing any device at all, since only explicitly mentioned ones
were allowed.
This commit adds an allow rule for several device classes that I could
find on my machines, that gets set when no devices are explicitly
configured.
There is an existing problem with nvme devices, that expose a character
device at `/dev/nvme0`, and a (namespaced) block device at
`/dev/nvme0n1`. The character device does not come with permissions that
we could give to the exporter without further impacting the hardening.
crw------- 1 root root 247, 0 27. Jan 03:10 /dev/nvme0
brw-rw---- 1 root disk 259, 0 27. Jan 03:10 /dev/nvme0n1
The autodiscovery only finds the character device, which the exporter
unfortunately does not have access to.
However a simple udev rule can be used to resolve this:
services.udev.extraRules = ''
SUBSYSTEM=="nvme", KERNEL=="nvme[0-9]*", GROUP="disk"
'';
Unfortunately I'm not fully aware of the security implications this
change carries and we should question upstream (systemd) why they did
not include such a rule.
The disk group has no members on any of my machines.
❯ getent group disk
disk:x:6:
(cherry picked from commit 12c26aca1f)
* fix MTP support on KDE Plasma and Dolphin
(cherry picked from commit c1e4f4d661)
* Update pkgs/applications/kde/kio-extras.nix
Co-authored-by: ElXreno <elxreno@gmail.com>
(cherry picked from commit a2415efca6)
Co-authored-by: Oleg Kapitonov <kapitonov1987@gmail.com>
Co-authored-by: Peter Hoeg <peter@hoeg.com>
The current doc is wildly out of touch with reality. A regex search shows
the following stats.
```
Style example Frequency Regex used
nix-2-5: 8 [a-zA-Z]-[0-9]+(-[0-9]+)+ =
nix-2_5: 17 [a-zA-Z]-[0-9]+(_[0-9]+)+ =
nix_2_5: 689 [a-zA-Z]_[0-9]+(_[0-9]+)+ =
nix_2-5: 1 [a-zA-Z]_[0-9]+(-[0-9]+)+ =
```
(cherry picked from commit daca830722)
Our support for Xen lacks maintenance and since Xen has monthly security
advisories it is reasonable to assume our version is affected by a
multitude of security problems that are fixed upstream.
How many advisories? Browsing oss-security shows the following number of
advisories in each of the following years:
2022: 3
2021: 53
2020: 54
2019: 46 <-- we are *here*
https://xenbits.xen.org/docs/unstable/support-matrix.html
(cherry picked from commit 39341ed38b)
Empty parantheses are not supported in regular expressions on
Darwin/macOS. The old regular expression produces an error during
evaluation. This commit fixes that.
Nix‘s `builtins.match` works with extend POSIX regular expressions. The
specification for these regular expression states[^1] that the result
for a left paranthesis immediately followed by a right paranthesis
outside of a bracket expression is undefined.
[^1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_03
(cherry picked from commit 6a96992fe0)
> We discovered a Local Privilege Escalation (from any user to root) in
> polkit's pkexec, a SUID-root program that is installed by default on
> every major Linux distribution
https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
Fixes: CVE-2021-4034
(cherry picked from commit 9e01b06585)
Otherwise you end up with a derivation that refers to the original
path (which is not in the Nix store and not accessible to
builders). This caused the derivation paths for the docbookrx package
(removed on master) to depend on the location of the nixpkgs source
tree.
(cherry picked from commit 55ae086747)
Originally, some TBB files in the user's $HOME are always deleted on
startup, and as a result, addons are not loaded automatically at
startup. For example, NoScript is disabled by default and needs a manual
reload cycle (dis-/enable by hand).
This change preserves the files with the addon information as long as
the contained store path is the same, i.e. TBB was not modified. When
TBB is updated, the files are removed as before, so that they don't
contain paths to the store location of the (now outdated) previous TBB.
A manual reload addon cycle is necessary once.
(cherry picked from commit 8985aca004)
The value of builtins.nixVersion should never be used except to bail
out if it's too old. It causes the evaluation result to depend on the
version of Nix, so e.g. the binary cache doesn't work.
(cherry picked from commit 5762b8c8a5)
Lets you specify the default listen address if none are listed in the vhost configuration.
Useful for hosts with more than one ip
(cherry picked from commit ab7e6995ac)
Backport of the commits
* 4713109cae (mautrix-telegram: 0.10.2 -> 0.11.0)
* 0630d5c381 (mautrix-telegram: remove alembic passthru)
* 2d42d654aa (mautrix-telegram: 0.11.0 -> 0.11.1)
Also added an override for `mautrix` since we cannot backport these
updates as it'd break at least `mautrix-signal`.
While this is technically a breaking change, we don't really have a
choice since Telegram expects all kinds of consuming software to also
display & support "Promotions", otherwise these apps will be
deactivated. To quote the message I got from Telegram in December:
> We ask that you make sure that these sponsored messages are supported and
> properly displayed in your app by January 1, 2022. Unfortunately, Telegram
> cannot financially sustain apps that support Telegram Channels but do not
> display official sponsored messages – such apps will have to be disconnected.
Version 5.27.1 is the last version with working Ozone/Wayland support
but we'll have to update to a more recent version soon.
See [0] for more details.
[0]: https://github.com/NixOS/nixpkgs/pull/154003
(cherry picked from commit 1f7d88bba2)
Allow a \n character at the end of the string and remove it during the
merge function.
An option of this type will resolve to the value "foo" whether it is set
to "foo" or "foo\n".
This is useful when using 'builtins.readFile' or ''-strings, which might
add an unintended newline (for example, bash trim the final newline from
a subshell).
(cherry picked from commit 4baf8548fb)
Add a new type, inheriting 'types.str' but checking whether the value
doesn't contain any newline characters.
The motivation comes from a problem with the
'users.users.${u}.openssh.authorizedKeys' option.
It is easy to unintentionally insert a newline character at the end of a
string, or even in the middle, for example:
restricted_ssh_keys = command: keys:
let
prefix = ''
command="${command}",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding
'';
in map (key: "${prefix} ${key}") keys;
The 'prefix' string ends with a newline, which ends up in the middle of
a key entry after a few manipulations.
This is problematic because the key file is built by concatenating all
the keys with 'concatStringsSep "\n"', with result in two entries for
the faulty key:
''
command="...",options...
MY_KEY
''
This is hard to debug and might be dangerous. This is now caught at
build time.
(cherry picked from commit df590070b0)
Instead of referencing all library functions through `lib.` and
builtins through `builtins.` at every invocation, inherit them into
the appropriate scope.
Use systemd's LoadCredential mechanism to make the secret files
available to the service.
This gets rid of the privileged part of the ExecPreStart script which
only served to copy these files and assign the correct
permissions. There's been issues with this approach when used in
combination with DynamicUser, where sometimes the user isn't created
before the ExecPreStart script runs, causing the error
install: invalid user ‘keycloak’
This should fix that issue.
Unfortunately, all of the ExecPreStart script had to be moved to
ExecStart, since credentials aren't provided to ExecPreStart. See
https://github.com/systemd/systemd/issues/19604.
Also set up updateScript since there haven't been any particularly
dramatic changes requiring modifications to the expression in a while.
(cherry picked from commit 1f42b69c67)
It seems as if it's a problem if `/etc/resolv.conf` is a symlink to
`/run/systemd/resolve/stub-resolv.conf` which is the case when using
`systemd-resolved.service`:
bwrap: Can't bind mount /oldroot/etc/resolv.conf on /newroot/etc/resolv.conf: Unable to mount source on destination: No such file or directory
I confirmed that by following the symlink of `/etc/resolv.conf`
(pointing to `/run/systemd/resolve/stub-resolv.conf`) with `readlink -f`
the issues are all gone.
(cherry picked from commit f3f82d8330)
network.target is reached earlier, but with much fewer services
available. DNS is likely to be not functional before
network-online.target, so waiting for that seems better for that reason
alone. the existing backends for network-online.target all seem to do
reasonable things (wait until all links are in *some* stable state), so
we shouldn't lose anything from waiting.
(cherry picked from commit dc101d9fef)
When cross building, we need to disable building tests or cmake will
complain about the missing gtest.
Also switching from targetPlatform to buildPlatform caused doCheck to be
properly set to false
(cherry picked from commit 9049874ff1)
We emit a few jobs conditionally on supportDarwin which only checked for
x86_64-darwin in the past. This change makes it more modular by
transforming it into an attribute set which holds the two darwin
arches. Jobs needing aarch64-darwin or x86_64-darwin are now only
emitted if their respective platform is actually in supportedSystems.
This issue was discovered because the staging-next-21.11 jobset had
commented out x86_64-darwin (presumably due to a build load issue).
(cherry picked from commit 533eb9866c)
This together with extraConfig:
{
"subsystem=undertow"."server=default-server"."http-listener=default"."proxy-address-forwarding" = true;
"subsystem=undertow"."server=default-server"."https-listener=https"."proxy-address-forwarding" = true;
}
Allows to run Keycloak behind a reverse proxy that provides
X-Forwarded-* headers.
(cherry picked from commit 97a0cf62f0)
Keycloak 16.1.0 uses different way to configure HTTPS.
This requires us to order commands correctly, otherwise linked
objects will fail.
(cherry picked from commit 827267a27f)
Allow update commands in the script to be ordered using `mkOrder`.
If we encounter ordered sub-objects we sort them by priority.
To implement this we now explicitly pass current node in `recurse`,
which also allows us to clean up edge case for top-level node.
Also refactor `recurse` to avoid passing result text argument; we
weren't tail recursive before anyway.
(cherry picked from commit 3c7e78cc6a)
A new symlink is required to fix the following error:
[3744707:0100/000000.911609:ERROR:egl_util.cc(74)] Failed to load GLES library: libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory
zsh: segmentation fault (core dumped) signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland
The GPU acceleration still fails (not sure if it worked before) but at least
"signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland"
launches again (without "--disable-gpu"):
[40492:0115/184719.611780:ERROR:gpu_process_host.cc(968)] GPU process exited unexpectedly: exit_code=139
[40492:0115/184720.256775:ERROR:gpu_process_host.cc(968)] GPU process exited unexpectedly: exit_code=139
[40492:0115/184720.892093:ERROR:gpu_process_host.cc(968)] GPU process exited unexpectedly: exit_code=139
[40620:0115/184721.033949:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process.
[40620:0115/184721.069600:ERROR:gl_utils.cc(318)] [.RendererMainThread-0x227200113f00]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[40620:0115/184721.133265:ERROR:gl_utils.cc(318)] [.RendererMainThread-0x227200113f00]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[40620:0115/184721.158341:ERROR:gl_utils.cc(318)] [.RendererMainThread-0x227200113f00]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
(After three GPU process crashes Chromium should automatically fall back
to software rendering.)
Fix#155050 (it only fixes the crashes though, not the underlying
issue, but that's likely all we can do for the moment as other Linux
distributions are affected as well; Ozone/Wayland is just not stable yet)
(cherry picked from commit 892a9971b0)
4369bebd9a removed the prosody-mysql
test. We forgot to remove the associated passthru test entry in the
prosody derivation.
(cherry picked from commit 3469429c39)
Blightmud is a terminal client for connecting to Multi User Dungeon
(MUD) games. It is written in Rust and supports TLS, GMCP, MSDP, MCCP2,
tab completion, text searching and a split view for scrolling. Blightmud
can be customized with Lua scripting for aliases, triggers, timers,
customized status bars, and more. Blightmud supports several
accessibility features including an optional built-in text-to-speech
engine and a screen reader friendly mode.
For nixpkgs it is largely a standard derivation for a rust project using
`rustPlatform.buildRustPackage`. There is some customization required
for the optional text-to-speech (TTS) engine support. In this case the
derivation must also set the `LIBCLANG_PATH` and customize
`BINDGEN_EXTRA_CLANG_ARGS` in order for a required crate to be able to
`rust-bindgen` the `libspeechd` dependency it wraps. Lastly the
derivation has to skip some integration-style tests that don't play
nicely with the nixpkgs build environment - the majority of unit tests
work so they are left running in the check phase.
Since the TTS support brings in heavy dependencies, but is a useful
accessibility feature, the Blightmud derivation is added to
`all-packages.nix` twice:
1. the `blightmud` attribute builds a configuration without TTS support.
2. the `blightmud-tts` attribute builds a configuration _with_ TTS
support.
The new Blightmud derivation is placed in `pkgs/games/blightmud/`
following the precedent set by another packaged GUI-based MUD client,
`mudlet` with `pkgs/games/mudlet/`.
(cherry picked from commit ae1bee344a)
nss-cacert has updated a few certificates, including Google's which
breaks the test suite of ca-certs expecting the old version.
(cherry picked from commit d1cc3df792)
IBM publishes their IBM Spectrum Protect client
for Linux in two flavors:
* "Linux x86_64 client"
* "Linux x86_64 Ubuntu client"
Up to this commit, nixpkgs used the Ubuntu
flavor to build its `tsm-client` derivation.
However, the history of published archive files in
* https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/client/v8r1/Linux/
* https://public.dhe.ibm.com/storage/tivoli-storage-management/patches/client/v8r1/Linux/
suggests that updates in the fourth level of
the version numbers (e.g. 8.1.13.0 -> 8.1.13.1)
do not get published as Ubuntu flavor.
It order to be able to always use the latest release,
this commit switches to the non-Ubuntu flavor.
The non-Ubuntu archive contains rpm files,
so this commit switches from `ar` to `rpmextract`.
Instead of unpacking all deb files,
the build recipe now unpacks all _but one_ rpm file:
The file `TIVsm-WEBGUI.x86_64.rpm` apparently
contains a plugin that is not included
in the Ubuntu version (see note below).
Comparing the old and the new derivation's output indicates
that this choice minimizes the difference between the results:
The output of the old (Ubuntu flavor) derivation contains:
* `commons-codec-1.6.jar`
* `share/` with changelog and copyright information
for the packages `gskssl64` and `gskcrypt64`
The output of the new (non-Ubuntu flavor) derivation contains:
* `lib64`, symlink to `lib`
* `commons-codec-1.14.jar`
* `opt/tivoli/tsm/license/{api,baclient}/sm/`
with license agreement files in many languages
Besides these differences, the outputs' file names are equal.
Note: I don't know what functionality
`TIVsm-WEBGUI.x86_64.rpm` actually provides.
Unpacking it with the other rpm files makes patchelf complain
about missing X11 libraries, so in order to include it here,
one would likely need to add those to `buildInputs`.
However, as the old (Ubuntu flavor) `tsm-client` package
did not contain this functionality and as I cannot test
or use it in any way, I opted to not include it now.
If we want to include this with a later commit,
we should add another package build option (like `enableGui`)
so that the default `tsm-client` package does not pull in
X11 libraries and its closure size therefore stays small.
cherry-picked/adapted from https://github.com/NixOS/nixpkgs/pull/138386
IBM has changed the URL structures of their support web pages.
The commit at hand updates most URLs and
in particular the package update instructions
so they follow the new structure.
It also calculates the source download URL from the
version number, so package updates no longer have to
update the URL in addition to the version string.
cherry-picked from https://github.com/NixOS/nixpkgs/pull/138386
The test has been broken for some time and the test errors are
non-obvious. None of the current maintainers know how to fix it so it is
better to get rid of it then to keep a continously failing test.
(cherry picked from commit 4369bebd9a)
When building glib statically, a Meson check would fail, because the
check would interpret any warning as failure, and it would see the
warning that the musl sys/cdefs.h emits about the file being
deprecated.
(cherry picked from commit 2b9c5958a1)
In pkgsStatic, /all/ build inputs are propagated. This means that
netbsd.compat was propagated, along with its setup hook, which broke
static glib builds because glib defines a function with the same name
as one in nbtool_config.h, and nbtool_config.h was being automatically
included in every C file processed by the compiler, in any transitive
dependent of netbsd.compat's setup hook.
To fix this, rather than forcing nbtool_config.h to be included for
_every_ C file in a derivation that depends on netbsd.compat, modify
the NetBSD-specific mkDerivation to detect files that need the header,
and patch it in there where appropriate. That way, only files that
are part of NetBSD will be affected, not all transitive dependents.
(cherry picked from commit 7be5fbf70f)
DPDK defaults to reading machine info from /sys unless specific platform
info is provided at configure time. Tell it to build a generic version
instead of trying to optimize based on the build host.
I was confused why I couldn't find a mention of udev.log_priority in
systemd-udevd.service(8). It turns out that it was renamed[1] to
udev.log_level. The old name is still accepted, but it'll avoid
further confusion if we use the new name in our documentation.
[1]: 64a3494c3d
(cherry picked from commit 6a1ea53c13)
This option makes the complete netdata configuration directory available for
modification. The default configuration is merged with changes
defined in the configDir option.
Co-authored-by: Michael Raitza <spacefrogg-github@meterriblecrew.net>
(cherry picked from commit 9e6145c73b)
Before this fix, if the listenAddress is set to something else than 127.0.0.1,
the service fails to detect that Elasticsearch has properly started and stop.
(cherry picked from commit 40fb59cfc3)
Before that, base stdenv passed non-makeOverridable version of itself
inside. This cause it to be lost on package-name.stdenv.
(cherry picked from commit 523c701c0b)
We don't need to check versions any more, because we no longer package
any kernels older than 4.4, so this is broken for all kernel versions
in Nixpkgs.
(cherry picked from commit 2424687448)
The guest additions currently don't build, either before or after this
change, but upgrading is still good because it gets us Linux 5.16
compatibility for the kernel module.
(cherry picked from commit dcabc91904)
During working on #150837 I discovered that `google-oslogin` test
started failing, and so did some of my development machines. Turns out
it was because nscd doesn't start by default; rather it's wanted by
NSS lookup targets, which are not always fired up.
To quote from section on systemd.special(7) on `nss-user-lookup.target`:
> All services which provide parts of the user/group database should be
> ordered before this target, and pull it in.
Following this advice and comparing our unit to official `sssd.service`
unit (which is a similar service), we now pull NSS lookup targets from
the service, while starting it with `multi-user.target`.
(cherry picked from commit b451eca621)
sa-update.service starts by making an HTTP GET request to
http://spamassassin.apache.org/updates/MIRRORED.BY, which now
redirects to HTTPS. Since we didn't have the appropriate library
available to handle HTTPS, rule updates would fail:
Jan 03 12:35:03 atuin systemd[1]: Starting sa-update.service...
Jan 03 12:35:10 atuin sa-update-start[1250]: Update available for channel updates.spamassassin.org: 1895535 -> 1896618
Jan 03 12:35:10 atuin sa-update-start[1250]: http: (lwp) hotpatching IO::Socket::INET by module IO::Socket::IP
Jan 03 12:35:11 atuin sa-update-start[1250]: http: (lwp) GET http://spamassassin.apache.org/updates/MIRRORED.BY, 501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)
Jan 03 12:35:11 atuin sa-update-start[1250]: error: unable to refresh mirrors file for channel updates.spamassassin.org, using old file
Jan 03 12:35:11 atuin sa-update-start[1250]: error: no mirror data available for channel updates.spamassassin.org
Jan 03 12:35:11 atuin sa-update-start[1250]: channel 'updates.spamassassin.org': MIRRORED.BY file contents were missing, channel failed
Jan 03 12:35:11 atuin sa-update-start[1250]: Update failed, exiting with code 4
Jan 03 12:35:11 atuin systemd[1]: sa-update.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 03 12:35:11 atuin systemd[1]: sa-update.service: Failed with result 'exit-code'.
Jan 03 12:35:11 atuin systemd[1]: Failed to start sa-update.service.
(cherry picked from commit 7169ada492)
The systemd syntax is suprising to me, but I suppose it's worth being
compatible as people might be sharing it with other modules.
Our regexp is lenient on IPv6 address part, so this is actually
backwards compatible (i.e. you can put the scope at either place).
(cherry picked from commit 180213a0ac)
Instead of setting the environment variable using Nix, use `preBuild`
hook to inject the value `DTLV_LIB_EXTRACT_DIR` on directly to
`nativeImageBuildArgs`. This will allow us to use a dynamically value
generated with `mktemp -d`.
Fix issue #153765.
(cherry picked from commit e1c79ccfe4)
Update pkgs/applications/version-management/commit-formatter/default.nix
Co-authored-by: Bobby Rong <rjl931189261@126.com>
Update pkgs/applications/version-management/commit-formatter/default.nix
Co-authored-by: Fabian Affolter <mail@fabian-affolter.ch>
Update pkgs/applications/version-management/commit-formatter/default.nix
Co-authored-by: Bobby Rong <rjl931189261@126.com>
(cherry picked from commit 1ed1e00d2b)
libcxxClang still depends on cc wrapper's gccForLibs for libgcc which is
not available when useLLVM is set. In such cases we need to switch to
clangUseLLVM and (try) to use compiler-rt instead.
Resolves#153759: pkgsLLVM.llvmPackages.stdenv now correctly
clangUseLLVM as cc, allowing compilation to work as expected.
(cherry picked from commit e238f456b8)
llvmPackages_*.clang should check the default compiler for the package
set it is targeting (targetPackages.stdenv.cc) instead of the compiler
that has been used to build it (stdenv.cc) in order to get some sense of
whether to use libc++ or libstdc++.
Since we are now inspecting targetPackages in the llvmPackages.clang
attribute, we need to avoid using it in the cross stdenv — which just
forces us to explicitly request libcxxClang for darwin instead of
relying on the clang attribute to pick it for us.
We also need to do something similar for targetPackages.stdenv.cc: Here
the llvmPackages.clang logic would work as we want (inspect
targetPackages.stdenv.cc and if it doesn't exist, make the choice based
on stdenv.cc), but it gets locked in a cycle with the previous package.
We can easily break this, however: We know that the previous set had
clang and the next one doesn't exist, so we'd choose libcxxClang any day
of the week.
(cherry picked from commit 766f5ffb76)
wrapCCWith shipped its own, but imperfect duplication of the logic we
use to choose the bintools for the *next* stage by inspecting
targetPlatform.
This change should ensure that C compilers relying on the default
behavior of wrapCCWith should end up with the same bintools als
theirStage.bintools. In particular, this makes
pkgsLLVM.llvmPackages.stdenv correctly use the LLVM bintools instead of
GNU binutils.
(cherry picked from commit 17c5a15c89)
The removed lines converted the flake path passed by the command line
from `/some/path` to `git+file:///some/path`.
This technically shouldn't cause any issues, however running
`nixos-rebuild switch` inside a directory `/nix/store` will cause the
switch to fail and leave a partially construct generation (see issue #144811
for details).
By itself this shouldn't be too much of an issue, however thanks to
another issue in `systemd-boot-builder.py` this can leave the system
in a broken state for those using `boot.loader.systemd-boot` (AFAIK the
default), where future `nixos-rebuild switch` will fail
(see issue #93694 for details).
The issue can be fixed by running
`nix-env -p /nix/var/nix/profiles/system --delete-generations old`,
however this makes newbies very confused and it is showing in our
support threads in Matrix and Discourse (see
https://discourse.nixos.org/t/need-help-on-failure-of-building-my-configuration/16842).
Keep in mind this is a workaround. The actual issue seems to be in nix
itself (see: https://github.com/NixOS/nix/issues/5510).
See also #150065 for an alternative fix that caused other issues.
Kudos for @figsoda for figuring out this fix.
(cherry picked from commit c274d045ac)
macOS's dyld can be rather picky as to what dylib it accepts. This
even changes across macOS versions. Therefore we now build a fat
dylib with all three architectures (x86_64, arm64, arm64e). This
should then be compatible with pretty much any macOS's dyld.
(cherry picked from commit a655bc02a7)
LLVM's build system creates NATIVE/bin/llvm-config by reexecuting cmake
with entirely new flags. Problematically, the `CMAKE_INSTALL_*` flags
are not inherited, causing llvm-config-native to return wrong
installation paths, e. g. CMAKE_INSTALL_LIBDIR would default to `lib64`
on x86_64-linux. Previously this was masked by outputs.patch which
replaced ActiveLibDir with a string passed in from Nix, however
`--cmakedir` for example would turn out to be wrong always, breaking
cross-compilation of e. g. lld.
Additionally LLVM_ENABLE_RTTI needs to be repassed, as it is used to
determine if RTTI is available. Passing LLVM_LINK_LLVM_DYLIB is crucial
if we are building LLVM non-statically: It influences the --shared-mode
flag (which should indicate that -lLLVM is enough to link all
components) and makes --link-shared work in the first place,
i. e. llvm-config-native believes the built shared libs don't exist
unless we repass this flag.
Passing LLVM_LINK_LLVM_DYLIB=ON, however, makes the native build produce
a full libLLVM.so which is something we don't want, so we introduce a
patch which forces llvm-config to link statically against the LLVM
components it needs.
(cherry picked from commit e10edcc278)
Due to gnu-install-dirs.patch llvm-config will return correct results
for --link-shared as well as --link-static even without this patch.
(cherry picked from commit 677a94fd9e)
Starting with LLVM 8, clang does no longer use llvm-config to detect the
LLVM installation: https://github.com/llvm/llvm-project/commit/e4faa5c7986b7
Consequently, there is no point passing LLVM_CONFIG_PATH (in fact the
variable is unused currently).
(cherry picked from commit c58517aeed)
this is the recommanded default, as glibc cause memory leaks:
"We ran into a problem with glibc's malloc on Linux where it seemed
like it failed to ever give memory back to the OS, causing the system
to swap. We have now switched to jemalloc which appears not to have
this problem." (from varnish-cache/doc/changes.rst)
(cherry picked from commit 24ce179bac)
LLVM 12 added the memory profiling runtime and LLVM 13 the ORC
runtime. Both need a libc in order to build (or at least headers not
present in clang's resource root), so we'll disable them for any sort of
baremetal-ish build. memprof likely doesn't work in a baremetal
situation at all, orc is unknown. Whether both would compile with musl
is to be checked.
(cherry picked from commit b591a98be4)
`test` directory actually also contains various libraries and broken
tests. Test failure happens when `test/lib/gajim_mocks.py` is attempted
to run as a test.
Upstream only runs no_gui tests:
e0f58cfc78/.gajim-ci.yml (L18)
We now explicitly run only tests from `no_gui` and `unit`.
(cherry picked from commit c138c66dcb)
This commit changes how we deal with the current token, i.e., the token
which may exist from a previous runner registration, and the configured
token, i.e., the path set for the respective NixOS configuration option.
Until now, we copied the configured and the current token (if any) to
the runtime directory to compare them. The path of the current token may
reference a file which is only accessible to specific users (even only
root). Therefore, we ran the copying of credentials with elevated
privileges by prefixing the `ExecStartPre=` script with a `+` (see
systemd.service(5)). In this script, we also changed the owner of the
files to the service user. Apparently, however, the user/group pair
sometimes did not exist because we use `DynamicUser=`.
To address this issue, we no longer change the owner of the file.
Instead, we change the file permissions to 0666 to allow the runner
configuration script (runs with full sandboxing) to read-write the file.
Due to the current permissions of the runtime directory (0755), this
would expose the token. Therefore, we process the tokens in the state
directory, which is only accessible to the service user.
If a new token file exists in the state directory, the configuration
script should trigger a new runner registration. Afterward, it deletes
the new token file. The token is still available using the path of the
current token which is inaccessible within the service's sandbox.
(cherry picked from commit 3cf9508c72)
So far we've ignored response files in arguments, and did not
check linkType against expanded parameters. This means if
we have `-static` in a @reponse-file, linkType will not be
set to `-static` as we never check against the expanded arguments
from response files.
(cherry picked from commit 14996789a1)
The build was failing due to mismatched libstdc++ between
stdenv.cc and cudatoolkit.cc. This can be fixed by bumping
the build-time cudatoolkit to 11, which is able to use the
same cc as stdenv.
(cherry picked from commit e263bdd82b)
New upstream release.
Also dropped the `web.archive.org`-usage: when I took over maintainership
over the package I continued to update that, but actually it's not
strictly needed because `copy-tarballs.pl` already takes care of copying
the src to `tarballs.nixos.org` (since it's redistributable).
(cherry picked from commit 87ee865bd6)
This will make it easier to trace through the test execution without
having to scroll through the entire kernel output.
(cherry picked from commit af765f3abd)
When displaying the amount of time some step took, with no other
context, it becomes nigh impossible (especially in longer tests) to see
when specific steps finished.
(cherry picked from commit c6ee63259a)
A build script in glusterfs uses /bin/bash interpreter and fails to get
the version from the VERSION file at build time:
sh: build-aux/pkg-version: /bin/bash: bad interpreter: No such file or directory
sh: build-aux/pkg-version: /bin/bash: bad interpreter: No such file or directory
sh: build-aux/pkg-version: /bin/bash: bad interpreter: No such file or directory
[...]
The result is that `gluster --version` doesn't include a version number.
Fixup the shebang to get the version info.
(cherry picked from commit 7e399b7078)
Update pkgs/applications/misc/inherd-quake/default.nix
Co-authored-by: Bobby Rong <rjl931189261@126.com>
Update pkgs/applications/misc/inherd-quake/default.nix
Co-authored-by: Bobby Rong <rjl931189261@126.com>
Update pkgs/applications/misc/inherd-quake/default.nix
Co-authored-by: Bobby Rong <rjl931189261@126.com>
Update pkgs/applications/misc/inherd-quake/default.nix
Co-authored-by: Bobby Rong <rjl931189261@126.com>
(cherry picked from commit 4a578ce659)
The system attribute is otherwise deduced from the system the
evaluation runs on, which could be incorrect if using remote
builders.
(cherry picked from commit ae77e2fb78)
...in the update script and remove it from the Gemfile.lock. Having
it there causes a failure with the error message:
Could not find libv8-node-16.10.0.0-aarch64-linux in any of the
sources (Bundler::GemNotFound)
And since we're not using the prebuilt binary packages anyway, we
don't need it there in the first place.
(cherry picked from commit 1138af5637)
Fix a typo in the kea-dhcp-ddns-server unit definition, and add a
KEA_LOCKFILE_DIR environment variable without which kea daemons try to
access a lockfile under /var/run/kea path, which is prevented by
systemd's ProtectSystem (or one of the other Protect*) mechanism.
kea-dhcp-ddns-server doesn't react to updates from dhcp4 server at all
without it.
(cherry picked from commit 6faa7ad3fc)
Since both static and shared libs are installed to the same `lib`
output, we override the ActiveLibDir unconditionally.
Fixes `llvm-config-native --link-static --libs`
(cherry picked from commit 544707d6a4)
When accessing the Audit log, I get an HTTP 502 when the frontend
requests `/audit` and I get the following error in my `nginx`-log:
Dec 20 22:12:48 ldap nginx[336]: 2021/12/20 22:12:48 [error] 336#336: *8421 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.237.0.1, server: _, request: "GET /audit/?action=**&action_detail=**&administrator=**&client=**&date=**&duration=**&info=**&page=1&page_size=10&policies=**&privacyidea_server=**&realm=**&resolver=**&serial=**&sortorder=desc&startdate=**&success=**&tokentype=**&user=** HTTP/1.1", upstream: "uwsgi://unix:/run/privacyidea/socket:", host: "ldap.ist.nicht-so.sexy", referrer: "https://ldap.ist.nicht-so.sexy/"
This is because of an "invalid request block size"-error according to
`journalctl -u privacyidea.service`:
Dec 20 22:12:48 ldap uwsgi[10721]: invalid request block size: 4245 (max 4096)...skip
Increasing the buffer to 8192 fixes the problem for me.
(cherry picked from commit 8f9f754271)
tar's -z flag only works for gzip-compressed tarballs. When passed a tarball
compressed with a different compressor (like xz), tar will fail to extract it.
Since tar can auto-detect a compressed tarball and use the appropriate
decompressor itself since forever, this is unecessary now.
(cherry picked from commit a6f973b534)
Before this change the `ghcjs` build fails with:
```
checking host system type... Invalid configuration `js-ghcjs': machine `js-unknown' not recognized
configure: error: …/bin/bash …/configured-ghcjs-src/lib/boot/pkg/unix/config.sub js-ghcjs failed
```
This fails because the `updateAutotoolsGnuConfigScriptsHook` overrides the
`config.sub` in the `unix` boot package to use the newer upstream
version of `config.sub`, but the newer version is incompatible with the
`js-ghcjs` host string used to configure the `unix` package. The
fix is to undo the override, because the `config.sub` vendored within
`ghc` supports the host string correctly.
(cherry picked from commit 69125bc160)
I unfortunately still depend on some python2 packages. It appears
that these two packages fail to evaluate, in a way that `tryEval`
doesn't catch. This changes them to be explicitly disabled there.
(cherry picked from commit deaec9f289)
This also includes disabling tensorflow-bin_2 which has been removed
from master.
ChangeLog: https://github.com/grafana/grafana/releases/tag/v8.3.3
Note: I had to copy `defaults.ini` from the Git repo rather than from
`srcStatic`. This is because the `srcStatic`-variant missed some config
changes[1] which caused the test to fail like this:
postgresql # [ 24.754735] grafana-start[900]: Failed to start grafana. error: section "tracing.opentelemetry.jaeger" does not exist
postgresql # [ 24.756013] grafana-start[900]: section "tracing.opentelemetry.jaeger" does not exist
postgresql # [ 24.762057] systemd[1]: grafana.service: Main process exited, code=exited, status=1/FAILURE
postgresql # [ 24.765443] systemd[1]: grafana.service: Failed with result 'exit-code'.
postgresql # [ 24.767419] systemd[1]: grafana.service: Consumed 1.598s CPU time, no IP traffic.
[1] d993b12415 (diff-0c326c4f02797b088fc566e64fbfe2162390f52f2fec1483ec3a413a7f11c910)
(cherry picked from commit 8af12f8ebd)
While we haven't encountered any problems related to this in MELPA
it's just a matter of time (this just happened for an ELPA package
(phps-mode)).
(cherry picked from commit 4192dce538)
This applies a patch from upstream[1] that replaces the previously used
method of using the SQLITE_DBPAGE virtual table extension.
This fixes audacity hanging when closing it, which leads to it having to
be killed. That results in incompletely saved project files which
triggers the file recovery dialogue on every start.
Fixes#130347.
[1] https://github.com/audacity/audacity/pull/1802
(cherry picked from commit fed4002ba3)
This is required since KWin relies on absolute paths in `Exec=` to find a process'
corresponding desktop file and check if it's allowed to take screenshot.
(cherry picked from commit fda144875f)
Snapserver expects the arguments `--tcp.bind_to_address` and
`--http.bind_to_address` instead of the `--tcp.address` (and http
equivalent) versions.
This caused the process to listen on `0.0.0.0` (for TCP and HTTP
sockets) regardless of the configuration value. It also never listend on
the IPv6 address `::` as our module system made the user believe.
This commit fixes the above issue and ensures that (at least for the TCP
socket) that our default `::` does indeed allow connections via IPv6
(to localhost aka ::1).
(cherry picked from commit c9c93b0add)
This seems to break
`boot.kernelPackages = config.boot.zfs.package.latestCompatibleLinuxPackages`
causing it to use `linuxPackages`.
(cherry picked from commit e6ca3fc976)
While it is a fact of life that aarch64-darwin is built on Hydra, it has
never formally been elevated from the Tier 7 state it was originally
assigned in RFC 0046. Since platform Tier status is not only
descriptive, but also normative, a consensus to commit to supporting
aarch64-darwin would need to be reached.
(cherry picked from commit 2d04319d0c)
Filebeat is an open source file harvester, mostly used to fetch logs
files and feed them into logstash.
This module can be used instead of journalbeat if used with
`filebeat7` and configured with the `journald` input.
(cherry picked from commit 6c9c2b4734)
- Use comparisons in jq instead of grepping
- Match for `.hits.total.value` if version >= 7, otherwise it always
passes
- Make curl fail if requests fails
(cherry picked from commit 9647a429ed)
This backport a patch made to add NixOS as a supported Operating System
fixing the wrong rendering issues I faced during test.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
(cherry picked from commit 4516cecba0)
(cherry picked from commit 702dfffa06)
Reason: adds compatibility w/ GNOME 41 (default in 21.11)
and lessens the reliance on globally installed packages.
use a much stronger binding to our specific freeimage that
works reliably on linux. previously it didn't and the tests
covering freeimage support were just being skipped as they
assumed it to be disabled.
once the binding works it reveals slight breakage in the tests
themselves, mostly fixed with an upstream patch (skipping
one remaining breakage). these breakages were already
revealing themselves on darwin as the freeimage binding was
"working" there.
(cherry picked from c81cf6a242 with
modifications)
This commit mitigates a remote code execution vulnerability in the log4j
library.
(cherry picked from commit 4925948fa1)
Co-authored-by: Lara <lara@uwu.is>
by default a ps/2 keyboard input is used which seems to cause issues
on aarch64-linux when the machine is used high load, causing the keymap
qwertz test to always fail and azerty to sometimes fail
See https://github.com/NixOS/nixpkgs/issues/147294
(cherry picked from commit 39c5525cb1)
The mentioned bugs have merged linked pull requests a long time ago:
* b9dea87ff1
in Ceph v15.1.0
* f701ed8b26
in Ceph v16.1.0
(cherry picked from commit c6cb7badab)
There is no real harm having them there; but it means these units really
only become active if there is a service providing the underlying
functionality.
nss-lookup.target should not be pulled in unconditionally. It should be
pulled in by providers of DNS lookups. E.g. systemd-resolved.service has
a Wants=nss-lookup.target, Before=nss-lookup.target. So once
systemd-resolved.service has finished starting up; other units that rely
on DNS can be started; but if systemd-resolved is not enabled; those
units can start up immediately.
Same story goes for nss-user-lookup.target and daemons like sssd.
From https://systemd.io/UIDS-GIDS/:
Note that nss-user-lookup.target is a passive unit: in order to
minimize synchronization points on systems that don’t need it the unit
is pulled into the initial transaction only if there’s at least one
service that really needs it, and that means only if there’s a service
providing the local user database somehow through IPC or suchlike.
(cherry picked from commit 3efbd53c1b)
It was originally moved because of nixops autoLuks feature which
has been unsupported for a while.
See:
* https://github.com/NixOS/nixpkgs/issues/62211
* https://github.com/NixOS/nixops/pull/1156#issuecomment-605339705
systemd-tmpfiles-setup-dev.service needs to run very early (even before
udev runs) because udev rules assume static device nodes already exist
even before udev is started. If these static device nodes do not exist;
systemd might have trouble mounting filesystems that require static
device nodes (like loopfs and btrfs).
(cherry picked from commit d4e4d27dff)
by default all cores are used
hoping this will fix the hydra i686 squashfs build issues as all the
failures were using 64 cores
Parallel mksquashfs: Using 64 processors
Creating 4.0 filesystem on ..., block size 1048576.
FATAL ERROR: mangle2:: xz compress failed with error code 5
(cherry picked from commit eea6baad50)
Instead of patching the path to /public in Discourse's sources, make
the nginx configuration refer to the symlink in the discourse
package which points to the real path.
When there is a mismatch between the path nginx serves and the path
Discourse thinks it serves, we can run into issues like files not
being served - at least when sendfile requests from the ruby app are
processed by nginx. The issue I ran into most recently is that backup
downloads don't work.
Since Discourse refers to the public directory relative to the Rails
root in many places, it's much easier to just sync this path to the
nginx configuration than trying to patch all occurrences in the
sources. This should hopefully mean less potential for breakage in
future Discourse releases, too.
(cherry picked from commit 125bb7dac1)
Add a DiscourseVersion class which handles Discourse's version
numbering properly when sorting - beta versions are sorted lower than
their respective release versions. It can also return both its version
number and equivalent git tag, removing the need for `rev2version` and
manually adding `v` to the front.
Using DiscourseVersion instead of LooseVersion, we can list all
current version number tags from the `discourse` repo and sort them
correctly, giving us the latest one, regardless of type; i.e. we don't
have to filter for only release versions or beta versions anymore.
This also implements the plugin pinning algorithm laid out here:
https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971
to make sure we don't upgrade plugins further than what's compatible
with our currently packaged Discourse version. While it likely won't
matter much most of the time if we continue packaging the beta
versions, it could be helpful if we decide to go back to packaging
release versions or if we run into issues with future upgrades. In
that case, the plugins could still be updated safely even though we're
not on the latest version of Discourse.
(cherry picked from commit 4fb343c87e)
Also, add support for updating plugins which keep gem versions in
files at the root of the repo (discourse-prometheus) and replace the
`up-plugin.sh` script with a README file pointing to the plugin
packaging documentation.
(cherry picked from commit ab042d6452)
Since building nodejs also builds v8, one way to get a static v8
library is to manually assemble it from the leftover object
files. This seems like an easier way to get an up-to-date v8 library
than trying to keep the v8 package updated.
(cherry picked from commit 679398b160)
This reverts commit 6af3d13bec.
Reported by @arcnmx
(https://github.com/NixOS/nixpkgs/pull/148179#issuecomment-987197656):
Does this not completely break the service? It doesn't change the
owner to the same as the ddclient server (which is somewhat difficult
due to it being a DynamicUser), so this now makes the service
completely unusable because the config is only readable by its owner,
root:
ddclient[871397]: WARNING: file /run/ddclient/ddclient.conf: Cannot open file '/run/ddclient/ddclient.conf'. (Permission denied)
Given that the RuntimeDirectory was only readable by the ddclient
service, the warning this PR fixes was spurious and not indicative of
an actual information leak. I'm not sure of what a quick fix would be
due to DynamicUser, but would at least request a revert of this so the
service can work again?
(cherry picked from commit 6a6a40d2ae)
This is horrible if you want to debug failures that happened during
system switches but your 30-ish acme clients spam the log with the same
messages over and over again.
(cherry picked from commit e37aab2130)
CC, CXX, LD, AR, …, LLC, OPT and CLANG will be invoked by GHC's build
system at build time in the build->target role. However, since we are
passing absolute paths, they will get saved in GHC's settings file and
later invoked at runtime, when they should be host->target. This means
that the build->target and host->target tools need to be the same for
our built GHC to work properly which is what we guard using these new
asserts.
Being able to drop these asserts would be a step towards cross-compiling
GHC (as opposed to building a GHC cross-compiler which still works).
(cherry picked from commit c23e14e33f)
Since 4c75874560 it is possible to
introspect if ld.gold is contained in the used bintools, so we can also
check if it is available before deciding to use it as done in the other
GHC derivations in 0908812372.
(cherry picked from commit b2e4708105)
When running ddclient with the current configuration we receive this warning:
```
WARNING: file /run/ddclient/ddclient.conf: file /run/ddclient/ddclient.conf must be accessible only by its owner.
```
This change should adjust the permissions for the ddclient.conf file to be -r-------- (read only by owner)
(cherry picked from commit f5582528aa)
While upgrading my NixOS system I was greeted by this error:
error:
Failed assertions:
- users.users.collectd.group is unset. This used to default to
nogroup, but this is unsafe. For example you can create a group
for this user with:
users.users.collectd.group = "collectd";
users.groups.collectd = {};
Let's fix it.
(cherry picked from commit 05bc708a7f)
autorandr includes functional zsh completions upstream they just lack
a make target to install the relevant file. For some consistency use the
direct file for both zsh and bash rather than just zsh. Note this
changes the resulting bash completion filename from just 'autorandr' to
'autorandr.bash'
See https://github.com/phillipberndt/autorandr/issues/197
(cherry picked from commit bdda2cca74)
Previously we were unable to override individual attributes within the
coreboot-toolchain packageset. By using callPackage on each of the
attributes individually we retain the ability to call the override
function to inject custom dependencies into the build.
(cherry picked from commit 3cd5413447)
The sub-packages of coreboot-toolchain don't build currently. Fix that
by using recurseIntoAttrs.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
(cherry picked from commit 39a3cf5367)
Starts the exporter, checks it answers via HTTP, checks that it can't
detect the device type of the virtual disk.
(cherry picked from commit 02316a4565)
Backport #148301 to release-21.11. We have multiple attributes for
different majors, so this is technically a new package that can be
backported.
The defaults aren't changed, so `nextcloud22` is still the default for
NixOS 21.11.
Co-authored-by: Ilan Joselevich <personal@ilanjoselevich.com>
Otherwise, `postfix_up{path="/var/lib/postfix/queue/public/showq"}` will
always be `0` indicating an postfix outage because this is a unix domain
socket that cannot be connected to:
2021/12/03 14:50:46 Failed to scrape showq socket: dial unix /var/lib/postfix/queue/public/showq: socket: address family not supported by protocol
(cherry picked from commit 8e6d403e65)
Remove PrivateDevices to silence warning about SnapRAID being
unable to access disk UUIDs.
Add CAP_FOWNER when touch is enabled so file time stamps can be
set.
(cherry picked from commit 6073b099d0)
These targets also have NCG support, but they are tested less (in fact
SPARC seems to be untested atm) and may have issues. In such cases being
able to fallback to -fllvm without rebuilding the compiler could be
useful. OTOH GHC will default to -fasm and the backends probably work
well enough in most cases.
(cherry picked from commit 8f1a52ac33)
Since we inherit the platform list from the bootstrap GHC, we get
differing lists depending on which platform we evaluate the platform
list on (depending on whether 8.10.2 or 8.6.5 is used). This leads to
Hydra thinking aarch64-linux is not supported as it evaluates on
x86_64-linux usually.
(cherry picked from commit 55b8d8c1bf)
Since LLVM itself doesn't depend on target at all, this doesn't change
anything *in effect* (i. e. rebuild count should be zero), but it is
more clear about the intention and what LLVM is used for here (i. e. in
depsBuildTarget).
(cherry picked from commit 156d8d619c)
This means we only have to update the llvmPackages attribute in one
place now and should prevent situations like with 8.6.5 where different
versions would be used in the package set compared to the compiler
build.
Drop comments in the configuration-ghc-X.Y.x.nix files as well, since
LLVM version isn't tied to the compiler minor version at
all (e. g. 8.10.2 and 8.10.7 have different support ranges).
(cherry picked from commit d7ff8061be)
useLLVM is what we are using in the GHC derivations already -- for
better or for worse -- so we should rename the argument here for
consistency which we are free to do as this is purely internal at the
moment (with overriding being impossible).
(cherry picked from commit c32095b400)
This check was wrong and caused by a bit of confusion on my part.
GHC >= 8.10.5 && < 9 supports aarch64-darwin via LLVM and GHC >= 9.2.1
introduces the NCG backend for aarch64-darwin.
(cherry picked from commit 2f98c1824c)
Based on https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms, although
it sadly doesn't list when the backends were introduced.
* PowerPC, x86 (and x86_64) and Sparc have been supported for longer.
* aarch64-darwin is new in 9.2.1 and backported to 8.10.5, 8.10.6 and
8.10.7 (check is dumb here since we'll grep for 8.10.7 anyways when
upgrading)
Fixes ghcWithPackages failing to evaluate on aarch64-darwin because of
missing support for the platform in LLVM 9's compiler-rt.
(cherry picked from commit 571f3e504b)
The availability of native codegen (which allows us to disable the LLVM
backend by default) hinges on the target platform of the compiler (that
is GHC), not on the platform it runs on (the host platform).
(cherry picked from commit cfdc073da4)
This was originally made to throw because pkgsHostHost was unimplemented.
Now that we have the full range of pkgs*, we can add this normally.
(cherry picked from commit c47f991435)
This is already done for previous versions of clang which use
a release tarball, but must be done differently for the more
recent versions which use fetchFromGitHub.
Fixes clang-tools clangd wrapper
(cherry picked from commit dd8ad828de)
The postInstall step for this package copies an icon to the hicolor icon
theme under the name mcomix3.png (${pname}). The applications
mcomix.desktop references the icon by Icon=mcomix. The means the copied
icon ends up with the "wrong" filename making lookup following the xdg
standard break. This change updates the icon reference in the .desktop
file to match what is currently being installed.
(cherry picked from commit f524d70519)
Install the desktop items so users can launch Mathematica from their desktop environment, notebooks are associated with Mathematica, etc.
(cherry picked from commit 97da277f17)
https://github.com/NixOS/nixpkgs/pull/145602 introduced versions of
aiohttp and async_timeout that are incompatible with Home Assistant and
many of its dependencies. Since reverting that PR would be a mass
rebuild we only switch back to the old versions for Home Assistant.
Update done by running the `nss` and `cacert` update scripts, then
running nixpkgs-check to validate things look good enough to be thrown
at hydra
(cherry picked from commit bb64e52399)
Co-authored-by: Léo Gaspard <leo@gaspard.io>
... by not avoiding openssl dependency in .lib.
dnstap part of code ran into issues with this during checkPhase.
The benefit of withSlimLib is mainly for `unbound`;
for the fuller builds it doesn't seem important.
(cherry picked from commit 9a0723cc3f)
The flag -cpu max leaves QEMU 6.1.0 stuck on some systems,
for example when /dev/kvm is not read-writable.
This does not happen with -cpu qemu64.
Getting stuck like that is a regression in 6.1.0 not yet present in 6.0.0
and should be fixed with 6.2.0 according to early testing with rc1.
We should consider reverting this change when we merge QEMU 6.2.0.
See #146526.
fixes#141596
(cherry picked from commit abbe8cbc48)
This fixes the qemu-kvm wrapper we add for convenience
silently not using KVM, when the system would support it
by at least leaving an indication in the log that the build ran
slower because it ran without KVM.
(cherry picked from commit 5718276542)
KVM should only be considered abailable if /dev/kvm exists and
is read-writable by the user that is trying to launch it.
The previous check for existance only had the consequence that
on some Linux distributions running VMs with Nix's QEMU only worked
if KVM was NOT installed.
fixes#124371
(cherry picked from commit 046392279c)
Updating the engine required updating the data. Otherwise a crash would
happen at the 2nd level (out of the main house).
(cherry picked from commit f30f9c8aa8)
It doesn't seems worth keeping it alive. Broken by commit 0649fcdf2.
(I hope I did this right without regenerating.)
(cherry picked from commit 0c0f340c22)
These tests were timing out, they pass locally but can overrun the timeout threshold depending on system load and speed.
System load shouldn't cause hydra failures, so disabling.
(cherry picked from commit c5b6e8a0fd)
ClosesNixOS/nixpkgs#147348
I was able to reproduce this intermittently in the
test suite during the tests for HTTPd. Adding
StartLimitIntervalSec=0 to disable rate limiting
for these services works fine. I added it anywhere
there was a ConditionPathExists.
(cherry picked from commit be952aba1c)
Enable for Coq 8.14
Use default version of OCaml (instead of 4.05)
VST is not ready for CompCert 3.10, so it still uses 3.9
(cherry picked from commit fa22c7cda3)
In e6548105b7 rnix-lsp switched back to
using the default nix because it was moved to 2.4. However, in
e3b7448f23 the default nix moved back to 2.3.16.
As rnix-lsp requires at least nix 2.4 for tests to succeed, the tests
started failing
At least on NixOS, it fails to evaluate as follows:
$ nix-env -qaPs -f .
error: attribute '__propagatedImpureHostDeps' missing
(cherry picked from commit b8c07facaa)
pulseaudio-dlna shells out to pactl to configure sinks and sources.
As pactl might not be in $PATH, add --suffix it (so pactl configured by the
user get priority)
(cherry picked from commit f567ff4440)
add ConditionVirtualization
and remove unneeded before and wants which are not in the upstream
package, the wantedBy should be enough
(cherry picked from commit 21585dc683)
This reverts commit 57961d2b83, reversing
changes made to b04f913afc.
(I.e. this reverts PR #141192.)
While well-intended, this change does unfortunately introduce very
serious regressions that are especially disruptive/noticeable on desktop
systems (e.g. users of Sway will loose their graphical session when
running "nixos-rebuild switch").
Therefore, this change has to be reverted ASAP instead of trying to fix
it in "production".
Note: An updated version should be extensively discussed, reviewed, and
tested before re-landing this change as an earlier version also had to
be reverted for the exact same issues [0].
Fix: #146727
[0]: https://github.com/NixOS/nixpkgs/pull/73871#issuecomment-559783752
(cherry picked from commit 1cfecb636b)
Commit 3a92a1a replaced the nix.daemonNiceLevel and nix.daemonIONiceLevel
options. This commit adds appropriate mk(Rename|Removed)OptionModule.
(cherry picked from commit 257e92258e)
For now it only takes care of the single Jar <-> single Executable case.
This will take care of the majority (all?) use cases we have in nixpkgs
currently.
(cherry picked from commit 1415e30830)
Reducing the priority makes the system build prefer the Nix-provided
completions, for e.g. the new `nix` commands.
(cherry picked from commit 8608d393e8)
It is broken and their is no usage in current nixpkgs.
Also the notice about its necessity is from 2014:
08131bd5d5
(cherry picked from commit 1d2c379e3b)
Guitone isn't used in Nixpkgs anywhere. It hasn't seen a release in 11 years
(6a09974e0f) and is unmaintained in
Nixpkgs. Also it's the sole remaining user of graphviz_2_32, which
should be removed as well.
(cherry picked from commit 86b2661837)
It's better to fail to build if our version of Meson isn't compatible
with QEMU's, so we'll know something is wrong. Otherwise, we'll get
subtle breakages that only manifest at runtime, which I think might be
what happened in 9e403b19a1 ("qemu: 5.1.0 -> 5.2.0") to necessitate
autoPatchelfHook.
(cherry picked from commit aa58876daf)
This also unbreaks the build, as for some reason the bin directory is
empty when doCheck = true and then the postFixup fails.
(cherry picked from commit a6c95f2706)
This will allow users to package their own core derivations if they want
without necessary submitting to nixpkgs.
(cherry picked from commit 702c8f29fb)
Sadly the original repository (stenzek/duckstation) is missing the
necessary files to build a libretro core, so we need to use the fork
instead.
(cherry picked from commit 994719881a)
Previously, `pkgs.libreoffice` had a total closure-size of 2.4GB where
`pkgs.openjdk` was a significant part:
$ nix path-info ./result -Sh
/nix/store/7xyfklmiz2azcnrfa8n9cz12dyyqc85r-libreoffice-7.1.7.2 2.4G
$ nix path-info ./result -shr | grep openjdk
/nix/store/qcn7ihaak9g8ayyj4995ila2z0pkm37i-openjdk-17.0.1+12 643.6M
However we need exactly two components:
* a `javac` from `pkgs.openjdk`
* a minimal runtime (i.e. a JRE) for `libofficebean.so` where
`libjawt.so` is also available.
I moved `jdk` to the `nativeBuildInputs` to ensure that `javac` is still
available in the build-environment and created a minimal JRE that seems
sufficient.
Now, the total closure-size is reduced by ~29.1% (basically the 600M
from `pkgs.openjdk`):
$ nix path-info ./result -Sh
/nix/store/zv34xijv64k7sz7rv50g3v6y59qg7p8k-libreoffice-7.1.7.2 1.7G
(cherry picked from commit 2f9426ad83)
Follow up to 2b84c77b3e (python3Packages.m3u8: fix build on Hydra
(x86_64-darwin), 2021-11-19), now with upstream patch.
(cherry picked from commit 40c3bc3b08)
Co-authored-by: Sebastián Mancilla <smancill@smancill.dev>
pmdk is only available on x86_64-linux, yet included in other platforms.
Things tested:
- build on x86_64-linux is the same (substituted from binary cache)
- build on aarch64-linux doesn't crash now with an "unsupported system"
(cherry picked from commit ccb2baa615)
- Clone the sources and leave the .git directory, and add Git to
checkInputs to fix several failing tests (they use Git commands and
expect to be inside a Git repository).
- Exclude a test failing on darwin.
(cherry picked from commit 29185d80e9)
use the same locale settings used by upstream's CI:
2bc4360474/.github/workflows/build.yaml (L33)
this has the effect of skipping some otherwise-failing tests on
darwin. seems slightly counterproductive but who am i to judge?
(cherry picked from commit 62b8957343)
Document that the all-packages.nix needs to be updated too (this was forgotten
in the GNOME 41 update). Also fixed typos.
(cherry picked from commit e41a7715a2)
The reduced reduncancy should help us avoid making some copy-paste errors,
as happened previously. Also, increased ergonomics.
(cherry picked from commit bc1f025afb)
It's quite ridiculous that we currently require manual intervention just
to have devman indexed if dev.enable == true.
(cherry picked from commit 2d59c66ea7)
<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
@@ -22,20 +28,9 @@ For new packages please briefly describe the package or provide a link to its ho
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."
Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
Check that all providers build with:
```
@ofborg build terraform-full
```
branch:terraform-providers-update
delete-branch:false
labels:"2.status: work-in-progress"
title:${{ steps.setup.outputs.title }}
token:${{ secrets.GITHUB_TOKEN }}
- name:comment on failure
uses:peter-evans/create-or-update-comment@v2
if:${{ failure() }}
with:
issue-number:153416
body:|
Automatic update of terraform providers [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).
@@ -11,16 +11,12 @@ under the terms of [COPYING](COPYING), which is an MIT-like license.
## Submitting changes
Read the ["Submitting changes"](https://nixos.org/nixpkgs/manual/#chap-submitting-changes) section of the nixpkgs manual. It explains how to write, test, and iterate on your change, and which branch to base your pull request against.
Below is a short excerpt of some points in there:
* Format the commit messages in the following way:
```
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
(Motivation for change. Link to release notes. Additional information.)
(Motivation for change. Additional information.)
```
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
@@ -29,7 +25,6 @@ Below is a short excerpt of some points in there:
@@ -45,7 +40,7 @@ Below is a short excerpt of some points in there:
* If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`.
* `meta.maintainers` must be set.
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes).
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes) and on how to [submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
## Writing good commit messages
@@ -53,61 +48,15 @@ In addition to writing properly formatted commit messages, it's important to inc
For package version upgrades and such a one-line commit message is usually sufficient.
## Rebasing between branches (i.e. from master to staging)
From time to time, changes between branches must be rebased, for example, if the
number of new rebuilds they would cause is too large for the target branch. When
rebasing, care must be taken to include only the intended changes, otherwise
many CODEOWNERS will be inadvertently requested for review. To achieve this,
rebasing should not be performed directly on the target branch, but on the merge
base between the current and target branch.
In the following example, we see a rebase from `master` onto the merge base
between `master` and `staging`, so that a change can eventually be retargeted to
`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
while the `origin` remote is used for the remote you are pushing to.
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
You can add a label such as `backport release-22.05` to a PR, so that merging it will
automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
This also works for PR's that have already been merged, and might take a couple of minutes to trigger.
You can also create the backport manually:
1. Take note of the commits in which the change was introduced into `master` branch.
2. Check out the target _release branch_, e.g. `release-22.05`. Do not use a _channel branch_ like `nixos-22.05` or `nixpkgs-22.05-darwin`.
2. Check out the target _release branch_, e.g. `release-20.09`. Do not use a _channel branch_ like `nixos-20.09` or `nixpkgs-20.09`.
3. Create a branch for your change, e.g. `git checkout -b backport`.
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.05`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.05]`.
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-20.09`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[20.09]`.
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
## Criteria for Backporting changes
@@ -119,15 +68,17 @@ Anything that does not cause user or downstream dependency regressions can be ba
- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
- Security critical applications (E.g. `firefox`)
## Generating 22.11 Release Notes
## Generating 21.11 Release Notes
(This section also applies to backporting 21.05 release notes: substitute "rl-2111" for "rl-2105".)
Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
Steps for updating 22.11 Release notes:
Steps for updating 21.11 Release notes:
1. Edit `nixos/doc/manual/release-notes/rl-2211.section.md` with the desired changes
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2211.section.xml`
3. Include changes to `rl-2211.section.md` and `rl-2211.section.xml` in the same commit.
1. Edit `nixos/doc/manual/release-notes/rl-2111.section.md` with the desired changes
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2111.section.xml`
3. Include changes to `rl-2111.section.md` and `rl-2111.section.xml` in the same commit.
@@ -6,11 +6,11 @@ When using Nix, you will frequently need to download source code and other files
Because fixed output derivations are _identified_ by their hash, a common mistake is to update a fetcher's URL or a version parameter, without updating the hash. **This will cause the old contents to be used.** So remember to always invalidate the hash argument.
For those who develop and maintain fetchers, a similar problem arises with changes to the implementation of a fetcher. These may cause a fixed output derivation to fail, but won't normally be caught by tests because the supposed output is already in the store or cache. For the purpose of testing, you can use a trick that is embodied by the [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function. It uses the derivation `name` to create a unique output path per fetcher implementation, defeating the caching precisely where it would be harmful.
For those who develop and maintain fetchers, a similar problem arises with changes to the implementation of a fetcher. These may cause a fixed output derivation to fail, but won't normally be caught by tests because the supposed output is already in the store or cache. For the purpose of testing, you can use a trick that is embodied by the [`invalidateFetcherByDrvHash`](#sec-pkgs-invalidateFetcherByDrvHash) function. It uses the derivation `name` to create a unique output path per fetcher implementation, defeating the caching precisely where it would be harmful.
## `fetchurl` and `fetchzip` {#fetchurl}
Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below.
```nix
{stdenv,fetchurl}:
@@ -24,9 +24,9 @@ stdenv.mkDerivation {
}
```
The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand, will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example, it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
Most other fetchers return a directory rather than a single file.
@@ -38,25 +38,7 @@ Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha25
Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
Additionally, the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.
If only parts of the repository are needed, `sparseCheckout` can be used. This will prevent git from fetching unnecessary blobs from server, see [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) and [git clone --filter](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---filterltfilter-specgt) for more information:
Additionally the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.
## `fetchfossil` {#fetchfossil}
@@ -72,23 +54,19 @@ Used with Mercurial. Expects `url`, `rev`, and `sha256`.
A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
## `fetchFromGitea` {#fetchfromgitea}
`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
## `fetchFromGitHub` {#fetchfromgithub}
`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `sha256` is currently preferred.
`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
`fetchFromGitHub` uses `fetchzip` to download the source archive generated by GitHub for the specified revision. If `leaveDotGit`, `deepClone` or `fetchSubmodules` are set to `true`, `fetchFromGitHub` will use `fetchgit` instead. Refer to its section for documentation of these options.
## `fetchFromGitLab` {#fetchfromgitlab}
This is used with GitLab repositories. The arguments expected are very similar to `fetchFromGitHub` above.
This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above.
## `fetchFromGitiles` {#fetchfromgitiles}
This is used with Gitiles repositories. The arguments expected are similar to `fetchgit`.
This is used with Gitiles repositories. The arguments expected are similar to fetchgit.
## `fetchFromBitbucket` {#fetchfrombitbucket}
@@ -96,19 +74,12 @@ This is used with BitBucket repositories. The arguments expected are very simila
## `fetchFromSavannah` {#fetchfromsavannah}
This is used with Savannah repositories. The arguments expected are very similar to `fetchFromGitHub` above.
This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub above.
## `fetchFromRepoOrCz` {#fetchfromrepoorcz}
This is used with repo.or.cz repositories. The arguments expected are very similar to `fetchFromGitHub` above.
This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub above.
## `fetchFromSourcehut` {#fetchfromsourcehut}
This is used with sourcehut repositories. Similar to `fetchFromGitHub` above,
it expects `owner`, `repo`, `rev` and `sha256`, but don't forget the tilde (~)
in front of the username! Expected arguments also include `vc` ("git" (default)
or "hg"), `domain` and `fetchSubmodules`.
If `fetchSubmodules` is `true`, `fetchFromSourcehut` uses `fetchgit`
or `fetchhg` with `fetchSubmodules` or `fetchSubrepos` set to `true`,
respectively. Otherwise, the fetcher uses `fetchzip`.
This is used with sourcehut repositories. The arguments expected are very similar to fetchFromGitHub above. Don't forget the tilde (~) in front of the user name!
@@ -58,7 +58,7 @@ After the new layer has been created, its closure (to which `contents`, `config`
At the end of the process, only one new single layer will be produced and added to the resulting image.
The resulting repository will only list the single image `image/tag`. In the case of [the `buildImage` example](#ex-dockerTools-buildImage), it would be `redis/latest`.
The resulting repository will only list the single image `image/tag`. In the case of [the `buildImage` example](#ex-dockerTools-buildImage) it would be `redis/latest`.
It is possible to inspect the arguments with which an image was built using its `buildArgs` attribute.
@@ -87,7 +87,7 @@ pkgs.dockerTools.buildImage {
}
```
Now the Docker CLI will display a reasonable date and sort the images as expected:
and now the Docker CLI will display a reasonable date and sort the images as expected:
```ShellSession
$ docker images
@@ -95,7 +95,7 @@ REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest de2bf4786de6 About a minute ago 25.2MB
```
However, the produced images will not be binary reproducible.
however, the produced images will not be binary reproducible.
@@ -119,13 +119,13 @@ Create a Docker image with many of the store paths being on their own layer to i
`contents`_optional_
: Top-level paths in the container. Either a single derivation, or a list of derivations.
: Toplevel paths in the container. Either a single derivation, or a list of derivations.
*Default:*`[]`
`config`_optional_
: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
*Default:*`{}`
@@ -151,12 +151,6 @@ Create a Docker image with many of the store paths being on their own layer to i
: Shell commands to run while creating the archive for the final layer in a fakeroot environment. Unlike `extraCommands`, you can run `chown` to change the owners of the files in the archive, changing fakeroot's state instead of the real filesystem. The latter would require privileges that the build user does not have. Static binaries do not interact with the fakeroot environment. By default all files in the archive will be owned by root.
`enableFakechroot`_optional_
: Whether to run in `fakeRootCommands` in `fakechroot`, making programs behave as though `/` is the root of the image being created, while files in the Nix store are available as usual. This allows scripts that perform installation in `/` to work as expected. Considering that `fakechroot` is implemented via the same mechanism as `fakeroot`, the same caveats apply.
*Default:*`false`
### Behavior of `contents` in the final image {#dockerTools-buildLayeredImage-arg-contents}
Each path directly listed in `contents` will have a symlink in the root of the image.
Increasing the `maxLayers` increases the number of layers which have a chance to be shared between different images.
Modern Docker installations support up to 128 layers, but older versions support as few as 42.
Modern Docker installations support up to 128 layers, however older versions support as few as 42.
If the produced image will not be extended by other Docker builds, it is safe to set `maxLayers` to `128`. However, it will be impossible to extend the image further.
If the produced image will not be extended by other Docker builds, it is safe to set `maxLayers` to `128`. However it will be impossible to extend the image further.
The first (`maxLayers-2`) most "popular" paths will have their own individual layers, then layer \#`maxLayers-1` will contain all the remaining "unpopular" paths, and finally layer \#`maxLayers` will contain the Image configuration.
@@ -213,7 +207,7 @@ The image produced by running the output script can be piped directly into `dock
$(nix-build) | docker load
```
Alternatively, the image be piped via `gzip` into `skopeo`, e.g., to copy it into a registry:
Alternatively, the image be piped via `gzip` into `skopeo`, e.g. to copy it into a registry:
`pkgs.ociTools` is a set of functions for creating containers according to the [OCI container specification v1.0.0](https://github.com/opencontainers/runtime-spec). Beyond that, it makes no assumptions about the container runner you choose to use to run the created container.
`pkgs.ociTools` is a set of functions for creating containers according to the [OCI container specification v1.0.0](https://github.com/opencontainers/runtime-spec). Beyond that it makes no assumptions about the container runner you choose to use to run the created container.
This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a `config.json` and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command.
This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a `config.json` and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command.
The parameters of `buildContainer` with an example value are described below:
@@ -30,7 +30,7 @@ buildContainer {
}
```
-`args` specifies a set of arguments to run inside the container. This is the only required argument for `buildContainer`. All referenced packages inside the derivation will be made available inside the container.
-`args` specifies a set of arguments to run inside the container. This is the only required argument for `buildContainer`. All referenced packages inside the derivation will be made available inside the container
-`mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox}
Graphical programs require many more integrations with the host. This example uses Firefox as an example because it is one of the most complicated programs we could package.
Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package.
@@ -4,13 +4,13 @@ The [Citrix Workspace App](https://www.citrix.com/products/workspace-app/) is a
## Basic usage {#sec-citrix-base}
The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.
The tarball archive needs to be downloaded manually as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store the package can be built and installed with Nix.
## Citrix Self-service {#sec-citrix-selfservice}
## Citrix Selfservice {#sec-citrix-selfservice}
The [self-service](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions.
The [selfservice](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions.
In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that you can configure the `selfservice` like this:
```ShellSession
$ storebrowse -C ~/Downloads/receiverconfig.cr
@@ -19,7 +19,7 @@ $ selfservice
## Custom certificates {#sec-citrix-custom-certs}
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative packaging these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
@@ -8,9 +8,9 @@ Nixpkgs provides a number of packages that will install Eclipse in its various f
$ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
```
Once an Eclipse variant is installed, it can be run using the `eclipse` command, as expected. From within Eclipse, it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
Once an Eclipse variant is installed it can be run using the `eclipse` command, as expected. From within Eclipse it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
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
packageOverrides=pkgs:{
@@ -22,15 +22,15 @@ packageOverrides = pkgs: {
}
```
to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running:
to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running
```ShellSession
$ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
```
If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the `buildEclipseUpdateSite` and `buildEclipsePlugin` functions found in the `nixpkgs.eclipses.plugins` attribute set. Use the `buildEclipseUpdateSite` function to install a plugin distributed as an Eclipse update site. This function takes `{ name, src }` as argument, where `src` indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available, then the `buildEclipsePlugin` function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument `{ name, srcFeature, srcPlugin }` where `srcFeature` and `srcPlugin` are the feature and plugin JARs, respectively.
If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the `buildEclipseUpdateSite` and `buildEclipsePlugin` functions found in the `nixpkgs.eclipses.plugins` attribute set. Use the `buildEclipseUpdateSite` function to install a plugin distributed as an Eclipse update site. This function takes `{ name, src }` as argument where `src` indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available then the `buildEclipsePlugin` function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument `{ name, srcFeature, srcPlugin }` where `srcFeature` and `srcPlugin` are the feature and plugin JARs, respectively.
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
@@ -20,7 +20,7 @@ The Emacs package comes with some extra helpers to make it easier to configure.
}
```
You can install it like any other packages via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
You can install it like any other packages via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provide a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
```nix
{
@@ -101,9 +101,9 @@ You can install it like any other packages via `nix-env -iA myEmacs`. However, t
}
```
This provides a fairly full Emacs start file. It will load in addition to the user's personal config. You can always disable it by passing `-q` to the Emacs command.
This provides a fairly full Emacs start file. It will load in addition to the user's presonal config. You can always disable it by passing `-q` to the Emacs command.
Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in `pkgs/top-level/emacs-packages.nix`). 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 Melpa Unstable, and the highest for packages manually defined in `pkgs/top-level/emacs-packages.nix`). But you can't control this priorities when some package is installed as a dependency. You can override it on 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'`.
Certain calls in glibc require access to runtime files found in `/etc` such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function.
Certain calls in glibc require access to runtime files found in /etc such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function.
On non-NixOS distributions these files are typically provided by packages (i.e., [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
On non-NixOS distributions these files are typically provided by packages (i.e. [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your `buildInputs`, then it will set the environment variables `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a setuphook.
If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your _buildInputs_ then it will set the environment varaibles `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a _setup-hook_.
Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variables are *not* set, then it will attempt to find the files at the default location within `/etc`.
Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variable are *not set*, then it will attempt to find the files at the default location within _/etc_.
## Build wrapped Firefox with extensions and policies {#build-wrapped-firefox-with-extensions-and-policies}
The `wrapFirefox` function allows to pass policies, preferences and extensions that are available to Firefox. With the help of `fetchFirefoxAddon` this allows to build a Firefox version that already comes with add-ons pre-installed:
The `wrapFirefox` function allows to pass policies, preferences and extension that are available to Firefox. With the help of `fetchFirefoxAddon` this allows build a Firefox version that already comes with addons pre-installed:
```nix
{
@@ -40,12 +40,13 @@ The `wrapFirefox` function allows to pass policies, preferences and extensions t
}
```
If `nixExtensions != null`, then all manually installed add-ons will be uninstalled from your browser profile.
To view available enterprise policies, visit [enterprise policies](https://github.com/mozilla/policy-templates#enterprisepoliciesenabled)
or type into the Firefox URL bar: `about:policies#documentation`.
Nix installed add-ons do not have a valid signature, which is why signature verification is disabled. This does not compromise security because downloaded add-ons are checksummed and manual add-ons can't be installed. Also, make sure that the `name` field of `fetchFirefoxAddon` is unique. If you remove an add-on from the `nixExtensions` array, rebuild and start Firefox: the removed add-on will be completely removed with all of its settings.
If `nixExtensions != null` then all manually installed addons will be uninstalled from your browser profile.
To view available enterprise policies visit [enterprise policies](https://github.com/mozilla/policy-templates#enterprisepoliciesenabled)
or type into the Firefox url bar: `about:policies#documentation`.
Nix installed addons do not have a valid signature, which is why signature verification is disabled. This does not compromise security because downloaded addons are checksumed and manual addons can't be installed. Also make sure that the `name` field of fetchFirefoxAddon is unique. If you remove an addon from the nixExtensions array, rebuild and start Firefox the removed addon will be completly removed with all of its settings.
## Troubleshooting {#sec-firefox-troubleshooting}
If add-ons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for add-ons thus nix add-ons get disabled by the normal Firefox binary.
If addons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for addons thus nix addons get disabled by the normal Firefox binary.
If addons do not appear installed although they have been defined in your nix configuration file reset the local addon state of your Firefox profile by clicking `help -> restart with addons disabled -> restart -> refresh firefox`. This can happen if you switch from manual addon mode to nix addon mode and then back to manual mode and then again to nix addon mode.
If add-ons do not appear installed despite being defined in your nix configuration file, reset the local add-on state of your Firefox profile by clicking `Help -> More Troubleshooting Information -> Refresh Firefox`. This can happen if you switch from manual add-on mode to nix add-on mode and then back to manual mode and then again to nix add-on mode.
@@ -6,7 +6,7 @@ This package is an ibus-based completion method to speed up typing.
IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/documentation.html).
On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
On NixOS you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
```nix
{pkgs,...}:{
@@ -19,7 +19,7 @@ On NixOS, you need to explicitly enable `ibus` with given engines before customi
## Using custom hunspell dictionaries {#sec-ibus-typing-booster-customize-hunspell}
The IBus engine is based on `hunspell` to support completion in many languages. By default, the dictionaries `de-de`, `en-us`, `fr-moderne``es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:
The IBus engine is based on `hunspell` to support completion in many languages. By default the dictionaries `de-de`, `en-us`, `fr-moderne``es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:
@@ -31,7 +31,7 @@ _Note: each language passed to `langs` must be an attribute name in `pkgs.hunspe
The `ibus-engines.typing-booster` package contains a program named `emoji-picker`. To display all emojis correctly, a special font such as `noto-fonts-emoji` is needed:
On NixOS, it can be installed using the following expression:
On NixOS it can be installed using the following expression:
@@ -4,7 +4,7 @@ The Nix expressions to build the Linux kernel are in [`pkgs/os-specific/linux/ke
The function that builds the kernel has an argument `kernelPatches` which should be a list of `{name, patch, extraConfig}` attribute sets, where `name` is the name of the patch (which is included in the kernel’s `meta.description` attribute), `patch` is the patch itself (possibly compressed), and `extraConfig` (optional) is a string specifying extra options to be concatenated to the kernel configuration file (`.config`).
The kernel derivation exports an attribute `features` specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the `iwlwifi` feature (i.e., has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external `iwlwifi` package:
The kernel derivation exports an attribute `features` specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the `iwlwifi` feature (i.e. has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external `iwlwifi` package:
```nix
modulesTree=[kernel]
@@ -14,19 +14,19 @@ modulesTree = [kernel]
How to add a new (major) version of the Linux kernel to Nixpkgs:
1. Copy the old Nix expression (e.g.,`linux-2.6.21.nix`) to the new one (e.g.,`linux-2.6.22.nix`) and update it.
1. Copy the old Nix expression (e.g. `linux-2.6.21.nix`) to the new one (e.g. `linux-2.6.22.nix`) and update it.
2. Add the new kernel to the `kernels` attribute set in `linux-kernels.nix` (e.g., create an attribute `kernel_2_6_22`).
3. Now we’re going to update the kernel configuration. First unpack the kernel. Then for each supported platform (`i686`, `x86_64`, `uml`) do the following:
1. Make a copy from the old config (e.g.,`config-2.6.21-i686-smp`) to the new one (e.g.,`config-2.6.22-i686-smp`).
1. Make an copy from the old config (e.g. `config-2.6.21-i686-smp`) to the new one (e.g. `config-2.6.22-i686-smp`).
2. Copy the config file for this platform (e.g.,`config-2.6.22-i686-smp`) to `.config` in the kernel source tree.
2. Copy the config file for this platform (e.g. `config-2.6.22-i686-smp`) to `.config` in the kernel source tree.
3. Run `make oldconfig ARCH={i386,x86_64,um}` and answer all questions. (For the uml configuration, also add `SHELL=bash`.) Make sure to keep the configuration consistent between platforms (i.e., don’t enable some feature on `i686` and disable it on `x86_64`).
3. Run `make oldconfig ARCH={i386,x86_64,um}` and answer all questions. (For the uml configuration, also add `SHELL=bash`.) Make sure to keep the configuration consistent between platforms (i.e. don’t enable some feature on `i686` and disable it on `x86_64`).
4. If needed, you can also run `make menuconfig`:
4. If needed you can also run `make menuconfig`:
```ShellSession
$ nix-env -f "<nixpkgs>" -iA ncurses
@@ -34,7 +34,7 @@ How to add a new (major) version of the Linux kernel to Nixpkgs:
$ make menuconfig ARCH=arch
```
5. Copy `.config` over the new config file (e.g., `config-2.6.22-i686-smp`).
5. Copy `.config` over the new config file (e.g. `config-2.6.22-i686-smp`).
4. Test building the kernel: `nix-build -A linuxKernel.kernels.kernel_2_6_22`. If it compiles, ship it! For extra credit, try booting NixOS with it.
To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats, Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
On non-NixOS distributions, this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.
On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.
## ETags on static files served from the Nix store {#sec-nginx-etag}
HTTP has a couple of different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the [`Last-Modified`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the `Last-Modified` header. This doesn't give the desired behavior when the file is in the Nix store because all file timestamps are set to 0 (for reasons related to build reproducibility).
HTTP has a couple different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the [`Last-Modified`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the `Last-Modified` header. This doesn't give the desired behavior when the file is in the Nix store, because all file timestamps are set to 0 (for reasons related to build reproducibility).
Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) response header. The value of the `ETag` header specifies some identifier for the particular content that the server is sending (e.g., a hash). When a client makes a second request for the same resource, it sends that value back in an `If-None-Match` header. If the ETag value is unchanged, then the server does not need to resend the content.
Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) response header. The value of the `ETag` header specifies some identifier for the particular content that the server is sending (e.g. a hash). When a client makes a second request for the same resource, it sends that value back in an `If-None-Match` header. If the ETag value is unchanged, then the server does not need to resend the content.
As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of `/nix/store`, the hash in the store path is used as the `ETag` header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.
@@ -12,4 +12,4 @@ The NixOS desktop or other non-headless configurations are the primary target fo
If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of `libglvnd` and `mesa.drivers` in `LD_LIBRARY_PATH`. For Mesa drivers, the Linux kernel version doesn't have to match nixpkgs.
For proprietary video drivers, you might have luck with also adding the corresponding video driver package.
For proprietary video drivers you might have luck with also adding the corresponding video driver package.
Steam is distributed as a `.deb` file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called `steam` that in Ubuntu (their target distro) would go to `/usr/bin`. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in `$HOME`.
Steam is distributed as a `.deb` file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called `steam` that in Ubuntu (their target distro) would go to `/usr/bin`. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in \$HOME.
Nix problems and constraints:
- We don't have `/bin/bash` and many scripts point there. Same thing for `/usr/bin/python`.
- We don't have `/bin/bash` and many scripts point there. Similarly for `/usr/bin/python`.
- We don't have the dynamic loader in `/lib`.
- The `steam.sh` script in `$HOME` cannot be patched, as it is checked and rewritten by steam.
- The `steam.sh` script in \$HOME cannot be patched, as it is checked and rewritten by steam.
- The steam binary cannot be patched, it's also checked.
The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented [here](http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html). This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
## How to play {#sec-steam-play}
Use `programs.steam.enable = true;` if you want to add steam to `systemPackages` and also enable a few workarounds aswell as Steam controller support or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pro Controller.
Use `programs.steam.enable = true;` if you want to add steam to systemPackages and also enable a few workarrounds aswell as Steam controller support or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pr.
## Troubleshooting {#sec-steam-troub}
@@ -32,7 +32,7 @@ Use `programs.steam.enable = true;` if you want to add steam to `systemPackages`
- **Using the FOSS Radeon or nouveau (nvidia) drivers**
- The `newStdcpp` parameter was removed since NixOS 17.09 and should not be needed anymore.
- Steam ships statically linked with a version of `libcrypto` that conflicts with the one dynamically loaded by radeonsi_dri.so. If you get the error:
- Steam ships statically linked with a version of libcrypto that conflics with the one dynamically loaded by radeonsi_dri.so. If you get the error
```
steam.sh: line 713: 7842 Segmentation fault (core dumped)
@@ -42,13 +42,13 @@ Use `programs.steam.enable = true;` if you want to add steam to `systemPackages`
- **Java**
1. There is no java in steam chrootenv by default. If you get a message like:
1. There is no java in steam chrootenv by default. If you get a message like
```
/home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found
```
you need to add:
you need to add
```nix
steam.override { withJava = true; };
@@ -56,7 +56,7 @@ Use `programs.steam.enable = true;` if you want to add steam to `systemPackages`
## steam-run {#sec-steam-run}
The FHS-compatible chroot used for Steam can also be used to run other Linux games that expect a FHS environment. To use it, install the `steam-run` package and run the game with:
The FHS-compatible chroot used for Steam can also be used to run other Linux games that expect a FHS environment. To use it, install the `steam-run-native` package and run the game with
@@ -4,7 +4,7 @@ Urxvt, also known as rxvt-unicode, is a highly customizable terminal emulator.
## Configuring urxvt {#sec-urxvt-conf}
In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It 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, use an overlay or directly install an expression that overrides its configuration, such as:
In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It 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, use an overlay or directly install an expression that overrides its configuration, such as
```nix
rxvt-unicode.override{
@@ -58,14 +58,14 @@ rxvt-unicode.override {
## Packaging urxvt plugins {#sec-urxvt-pkg}
Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin, create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
A plugin can be any kind of derivation, the only requirement is that it should always install perl scripts in `$out/lib/urxvt/perl`. Look for existing plugins for examples.
If the plugin is itself a Perl package that needs to be imported from other plugins or scripts, add the following passthrough:
If the plugin is itself a perl package that needs to be imported from other plugins or scripts, add the following passthrough:
```nix
passthru.perlPackages=["self"];
```
This will make the urxvt wrapper pick up the dependency and set up the Perl path accordingly.
This will make the urxvt wrapper pick up the dependency and set up the perl path accordingly.
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
@@ -13,7 +13,7 @@ If the `configure` function returns an attrset without the `plugins` attribute,
The plugins currently available are `python`, `perl`, `ruby`, `guile`, `tcl` and `lua`.
The Python and Perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
The python and perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
Further values can be added to the list of commands when running `weechat --run-command "your-commands"`.
Additionally, it's possible to specify scripts to be loaded when starting `weechat`. These will be loaded before the commands from `init`:
Additionally it's possible to specify scripts to be loaded when starting `weechat`. These will be loaded before the commands from `init`:
```nix
weechat.override{
@@ -64,7 +64,7 @@ weechat.override {
}
```
In `nixpkgs` there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a `passthru.scripts` attribute, which contains a list of all scripts inside the store path. Furthermore, all scripts have to live in `$out/share`. An exemplary derivation looks like this:
In `nixpkgs` there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a `passthru.scripts` attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in `$out/share`. An exemplary derivation looks like this:
@@ -45,5 +45,3 @@ One can create a simple environment using a `shell.nix` like that:
```
Running `nix-shell` would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change `runScript` to the application path, e.g. `./bin/start.sh` -- relative paths are supported.
Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.
Run a NixOS VM network test using this evaluation of Nixpkgs.
NOTE: This function is primarily for external use. NixOS itself uses `make-test-python.nix` directly. Packages defined in Nixpkgs [reuse NixOS tests via `nixosTests`, plural](#ssec-nixos-tests-linking).
It is mostly equivalent to the function `import ./make-test-python.nix` from the
Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network round-trip and can speed up a build.
Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network roundrip and can speed up a build.
::: {.note}
This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g., just copying some files to a different location or adding symlinks) because there the `system` is usually the same as `builtins.currentSystem`.
This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g. just copying some files to a different location or adding symlinks), because there the `system` is usually the same as `builtins.currentSystem`.
@@ -47,88 +47,6 @@ These functions write `text` to the Nix store. This is useful for creating scrip
Many more commands wrap `writeTextFile` including `writeText`, `writeTextDir`, `writeScript`, and `writeScriptBin`. These are convenience functions over `writeTextFile`.
Here are a few examples:
```nix
# Writes my-file to /nix/store/<store path>
writeTextFile{
name="my-file";
text=''
ContentsofFile
'';
}
# See also the `writeText` helper function below.
# Writes executable my-file to /nix/store/<store path>/bin/my-file
writeTextFile{
name="my-file";
text=''
ContentsofFile
'';
executable=true;
destination="/bin/my-file";
}
# Writes contents of file to /nix/store/<store path>
writeText"my-file"
''
ContentsofFile
'';
# Writes contents of file to /nix/store/<store path>/share/my-file
writeTextDir"share/my-file"
''
ContentsofFile
'';
# Writes my-file to /nix/store/<store path> and makes executable
writeScript"my-file"
''
ContentsofFile
'';
# Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
writeScriptBin"my-file"
''
ContentsofFile
'';
# Writes my-file to /nix/store/<store path> and makes executable.
writeShellScript"my-file"
''
ContentsofFile
'';
# Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
These functions concatenate `files` to the Nix store in a single file. This is useful for configuration files structured in lines of text. `concatTextFile` takes an attribute set and expects two arguments, `name` and `files`. `name` corresponds to the name used in the Nix store path. `files` will be the files to be concatenated. You can also set `executable` to true to make this file have the executable bit set.
`concatText` and`concatScript` are simple wrappers over `concatTextFile`.
Here are a few examples:
```nix
# Writes my-file to /nix/store/<store path>
concatTextFile{
name="my-file";
files=[drv1"${drv2}/path/to/file"];
}
# See also the `concatText` helper function below.
# Writes executable my-file to /nix/store/<store path>/bin/my-file
concatTextFile{
name="my-file";
files=[drv1"${drv2}/path/to/file"];
executable=true;
destination="/bin/my-file";
}
# Writes contents of files to /nix/store/<store path>
concatText"my-file"[file1file2]
# Writes contents of files to /nix/store/<store path>
This can be used to easily produce a shell script that has some dependencies (`runtimeInputs`). It automatically sets the `PATH` of the script to contain all of the listed inputs, sets some sanity shellopts (`errexit`, `nounset`, `pipefail`), and checks the resulting script with [`shellcheck`](https://github.com/koalaman/shellcheck).
@@ -154,26 +72,6 @@ validation.
## `symlinkJoin` {#trivial-builder-symlinkJoin}
This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, `name`, and `paths`. `name` is the name used in the Nix store path for the created derivation. `paths` is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
Here is an example:
```nix
# adds symlinks of hello and stack to current build and prints "links added"
@@ -214,15 +214,15 @@ Most of the time, these are the same. For instance, the package `e2fsprogs` has
There are a few naming guidelines:
- The `pname` attribute _should_ be identical to the upstream package name.
- The `name` attribute _should_ be identical to the upstream package name.
- The `pname` and the `version` attribute _must not_ contain uppercase letters — e.g., `"mplayer" instead of `"MPlayer"`.
- The `name` attribute _must not_ contain uppercase letters — e.g., `"mplayer-1.0rc2"` instead of `"MPlayer-1.0rc2"`.
- The `version` attribute _must_ start with a digit e.g`"0.3.1rc2".
- The version part of the `name` attribute _must_ start with a digit (following a dash) — e.g., `"hello-0.3.1rc2"`.
- If a package is not a release but a commit from a repository, then the `version` attribute _must_ be the date of that (fetched) commit. The date _must_ be in `"unstable-YYYY-MM-DD"` format.
- If a package is not a release but a commit from a repository, then the version part of the name _must_ be the date of that (fetched) commit. The date _must_ be in `"YYYY-MM-DD"` format. Also append `"unstable"` to the name - e.g., `"pkgname-unstable-2014-09-23"`.
- Dashes in the package `pname`_should_ be preserved in new variable names, rather than converted to underscores or camel cased — e.g., `http-parser` instead of `http_parser` or `httpParser`. The hyphenated style is preferred in all three package names.
- Dashes in the package name _should_ be preserved in new variable names, rather than converted to underscores or camel cased — e.g., `http-parser` instead of `http_parser` or `httpParser`. The hyphenated style is preferred in all three package names.
- If there are multiple versions of a package, this _should_ be reflected in the variable names in `all-packages.nix`, e.g. `json-c_0_9` and `json-c_0_11`. If there is an obvious “default” version, make an attribute like `json-c = json-c_0_9;`. See also [](#sec-versioning)
@@ -540,11 +540,10 @@ If you do need to do create this sort of patch file, one way to do so is with gi
If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`:
- `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it.
- `stripLen`: Remove the first `stripLen` components of pathnames in the patch.
- `extraPrefix`: Prefix pathnames by this string.
- `excludes`: Exclude files matching these patterns (applies after the above arguments).
- `includes`: Include only files matching these patterns (applies after the above arguments).
- `excludes`: Exclude files matching this pattern.
- `includes`: Include only files matching this pattern.
- `revert`: Revert the patch.
Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well.
@@ -55,7 +55,7 @@ Additionally, the following syntax extensions are currently used:
- []{#ssec-contributing-markup-inline-roles}
If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`.
The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/unix-man-urls.lua`.
This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
@@ -103,8 +103,7 @@ Sample template for a new package review is provided below.
- [ ] `meta.maintainers` is set
- [ ] build time only dependencies are declared in `nativeBuildInputs`
- [ ] source is fetched using the appropriate function
- [ ] the list of `phases` is not overridden
- [ ] when a phase (like `installPhase`) is overridden it starts with `runHook preInstall` and ends with `runHook postInstall`.
- [ ] phases are respected
- [ ] patches that are remotely available are fetched with `fetchpatch`
##### Possible improvements
@@ -122,10 +121,10 @@ Reviewing process:
- [CODEOWNERS](https://help.github.com/articles/about-codeowners/) will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
- Ensure that the module tests, if any, are succeeding.
- Ensure that the introduced options are correct.
- Type should be appropriate (string related types differs in their merging capabilities, `loaOf` and `string` types are deprecated).
- Type should be appropriate (string related types differs in their merging capabilities, `optionSet` and `string` types are deprecated).
- Description, default and example should be provided.
- Ensure that option changes are backward compatible.
- `mkRenamedOptionModuleWith` provides a way to make option changes backward compatible.
- `mkRenamedOptionModule` and `mkAliasOptionModule` functions provide way to make option changes backward compatible.
- Ensure that removed options are declared with `mkRemovedOptionModule`
- Ensure that changes that are not backward compatible are mentioned in release notes.
- Ensure that documentations affected by the change is updated.
@@ -157,7 +156,7 @@ Reviewing process:
- Ensure that the module tests, if any, are succeeding.
- Ensure that the introduced options are correct.
- Type should be appropriate (string related types differs in their merging capabilities, `loaOf` and `string` types are deprecated).
- Type should be appropriate (string related types differs in their merging capabilities, `optionSet` and `string` types are deprecated).
- Description, default and example should be provided.
- Ensure that module `meta` field is present
- Maintainers should be declared in `meta.maintainers`.
@@ -96,9 +96,9 @@ We use jbidwatcher as an example for a discontinued project here.
1. Have Nixpkgs checked out locally and up to date.
1. Create a new branch for your change, e.g. `git checkout -b jbidwatcher`
1. Remove the actual package including its directory, e.g. `git rm -rf pkgs/applications/misc/jbidwatcher`
1. Remove the actual package including its directory, e.g. `rm -rf pkgs/applications/misc/jbidwatcher`
1. Remove the package from the list of all packages (`pkgs/top-level/all-packages.nix`).
1. Add an alias for the package name in `pkgs/top-level/aliases.nix` (There is also `pkgs/applications/editors/vim/plugins/aliases.nix`. Package sets typically do not have aliases, so we can't add them there.)
1. Add an alias for the package name in `pkgs/top-level/aliases.nix` (There is also `pkgs/misc/vim-plugins/aliases.nix`. Package sets typically do not have aliases, so we can't add them there.)
For example in this case:
@@ -227,7 +227,7 @@ digraph {
}
```
[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours; these are the blue arrows in the diagram above. The purple arrows in the diagram above are done manually and much less frequently. You can get an idea of how often these merges occur by looking at the git history.
[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours.
The `staging` branch is a development branch where mass-rebuilds go. Mass rebuilds are commits that cause rebuilds for many packages, like more than 500 (or perhaps, if it's 'light' packages, 1000). It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
The `staging` branch is a development branch where mass-rebuilds go. It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
The same staging workflow applies to stable release branches, but the main branch is called `release-*` instead of `master`.
For cherry-picking a commit to a stable release branch (“backporting”), use `git cherry-pick -x <original commit>` so that the original commit id is included in the commit.
Example branch names: `release-21.11`, `staging-21.11`, `staging-next-21.11`.
Add a reason for the backport by using `git cherry-pick -xe <original commit>` instead when it is not obvious from the original commit message. It is not needed when it's a minor version update that includes security and bug fixes but don't add new features or when the commit fixes an otherwise broken package.
Most changes added to the stable release branches are cherry-picked (“backported”) from the `master` and staging branches.
#### Automatically backporting a Pull Request {#submitting-changes-stable-release-branches-automatic-backports}
Assign label `backport <branch>` (e.g. `backport release-21.11`) to the PR and a backport PR is automatically created after the PR is merged.
Cherry-pick changes via `git cherry-pick -x <original commit>` so that the original commit id is included in the commit message.
Add a reason for the backport when it is not obvious from the original commit message. You can do this by cherry picking with `git cherry-pick -xe <original commit>`, which allows editing the commit message. This is not needed for minor version updates that include security and bug fixes but don't add new features or when the commit fixes an otherwise broken package.
For backporting Pull Requests to stable branches, assign label `backport <branch>` to the original Pull Requests and automation should take care of the rest once the Pull Requests is merged.
Here is an example of a cherry-picked commit message with good reason description:
This hook starts a PostgreSQL server during the `checkPhase`. Example:
```nix
{stdenv,postgresql,postgresqlTestHook}:
stdenv.mkDerivation{
# ...
checkInputs=[
postgresql
postgresqlTestHook
];
}
```
If you use a custom `checkPhase`, remember to add the `runHook` calls:
```nix
checkPhase''
runHookpreCheck
#...yourtests
runHookpostCheck
''
```
## Variables {#sec-postgresqlTestHook-variables}
The hook logic will read a number of variables and set them to a default value if unset or empty.
Exported variables:
-`PGDATA`: location of server files.
-`PGHOST`: location of UNIX domain socket directory; the default `host` in a connection string.
-`PGUSER`: user to create / log in with, default: `test_user`.
-`PGDATABASE`: database name, default: `test_db`.
Bash-only variables:
-`postgresqlTestUserOptions`: SQL options to use when creating the `$PGUSER` role, default: `LOGIN`.
-`postgresqlTestSetupSQL`: SQL commands to run as database administrator after startup, default: statements that create `$PGUSER` and `$PGDATABASE`.
-`postgresqlTestSetupCommands`: bash commands to run after database start, defaults to running `$postgresqlTestSetupSQL` as database administrator.
-`postgresqlEnableTCP`: set to `1` to enable TCP listening. Flaky; not recommended.
-`postgresqlStartCommands`: defaults to `pg_ctl start`.
## TCP and the Nix sandbox {#sec-postgresqlTestHook-tcp}
`postgresqlEnableTCP` relies on network sandboxing, which is not available on macOS and some custom Nix installations, resulting in flaky tests.
For this reason, it is disabled by default.
The preferred solution is to make the test suite use a UNIX domain socket connection. This is the default behavior when no `host` connection parameter is provided.
Some test suites hardcode a value for `host` though, so a patch may be required. If you can upstream the patch, you can make `host` default to the `PGHOST` environment variable when set. Otherwise, you can patch it locally to omit the `host` connection string parameter altogether.
::: {.note}
The error `libpq: failed (could not receive data from server: Connection refused` is generally an indication that the test suite is trying to connect through TCP.
For phoenix projects, inside of nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
for phoenix projects, inside of nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
@@ -82,13 +82,13 @@ There are 2 ways to package backend dependencies. With mix2nix and with a fixed-
###### mix2nix {#mix2nix}
`mix2nix` is a cli tool available in nixpkgs. it will generate a nix expression from a mix.lock file. It is quite standard in the 2nix tool series.
mix2nix is a cli tool available in nixpkgs. it will generate a nix expression from a mix.lock file. It is quite standard in the 2nix tool series.
Note that currently mix2nix can't handle git dependencies inside the mix.lock file. If you have git dependencies, you can either add them manually (see [example](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/pleroma/default.nix#L20)) or use the FOD method.
The advantage of using mix2nix is that nix will know your whole dependency graph. On a dependency update, this won't trigger a full rebuild and download of all the dependencies, where FOD will do so.
Practical steps:
practical steps:
- run `mix2nix > mix_deps.nix` in the upstream repo.
- pass `mixNixDeps = with pkgs; import ./mix_deps.nix { inherit lib beamPackages; };` as an argument to mixRelease.
@@ -280,30 +280,6 @@ mkShell {
}
```
### Using an overlay
If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `sha256`) and then use this overlay in your development environment:
@@ -29,8 +29,7 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
*`releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
*`displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
*`namePrefix` (optional, defaults to `[ "coq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
*`extraNativeBuildInputs` (optional), by default `nativeBuildInputs` just contains `coq`, this allows to add more native build inputs,`nativeBuildInputs` are executables and `buildInputs` are libraries and dependencies,
*`extraBuildInputs` (optional), this allows to add more build inputs,
*`extraBuildInputs` (optional), by default `buildInputs` just contains `coq`, this allows to add more build inputs,
*`mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `coq.ocamlPackages` attribute can be used in `extraBuildInputs` to depend on the same package set Coq was built against.
*`useDune2ifVersion` (optional, default to `(x: false)` uses Dune2 to build the package if the provided predicate evaluates to true on the version, e.g. `useDune2if = versions.isGe "1.1"` will use dune if the version of the package is greater or equal to `"1.1"`,
*`useDune2` (optional, defaults to `false`) uses Dune2 to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.
@@ -72,51 +72,33 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given
To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
*`projectFile` has to be used for specifying the dotnet project file relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be an array of multiple projects as well.
*`nugetDeps` has to be used to specify the NuGet dependency file. Unfortunately, these cannot be deterministically fetched without a lockfile. A script to fetch these is available as `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs.
*`packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`.
*`projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
For example, your project has a local dependency:
```xml
<ProjectReference Include="../foo/bar.fsproj" />
```
To enable discovery through `projectReferences` you would need to add:
* `executables` is used to specify which executables get wrapped to `$out/bin`, relative to `$out/lib/$pname`. If this is unset, all executables generated will get installed. If you do not want to install any, set this to `[]`. This gets done in the `preFixup` phase.
*`nugetDeps` has to be used to specify the NuGet dependency file. Unfortunately, these cannot be deterministically fetched without a lockfile. This file should be generated using `nuget-to-nix` tool, which is available in nixpkgs.
*`executables` is used to specify which executables get wrapped to `$out/bin`, relative to `$out/lib/$pname`. If this is unset, all executables generated will get installed. If you do not want to install any, set this to `[]`.
*`runtimeDeps` is used to wrap libraries into `LD_LIBRARY_PATH`. This is how dotnet usually handles runtime dependencies.
*`buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
*`dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used.
*`dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
*`dotnet-test-sdk` is useful in cases where unit tests expect a different dotnet SDK. By default, this is set to the `dotnet-sdk` attribute.
* `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this.
*`testProjectFile` is useful in cases where the regular project file does not contain the unit tests. By default, this is set to the `projectFile` attribute.
*`disabledTests` is used to disable running specific unit tests. This gets passed as: `dotnet test --filter "FullyQualifiedName!={}"`, to ensure compatibility with all unit test frameworks.
*`dotnetRestoreFlags` can be used to pass flags to `dotnet restore`.
*`dotnetBuildFlags` can be used to pass flags to `dotnet build`.
* `dotnetTestFlags` can be used to pass flags to `dotnet test`. Used only if `doCheck` is set to `true`.
*`dotnetTestFlags` can be used to pass flags to `dotnet test`.
*`dotnetInstallFlags` can be used to pass flags to `dotnet install`.
* `dotnetPackFlags` can be used to pass flags to `dotnet pack`. Used only if `packNupkg` is set to `true`.
*`dotnetFlags` can be used to pass flags to all of the above phases.
When packaging a new application, you need to fetch it's dependencies. You can set `nugetDeps` to an empty string to make the derivation temporarily evaluate, and then run `nix-build -A package.passthru.fetch-deps` to generate it's dependency fetching script. After running the script, you should have the location of the generated lockfile printed to the console. This can be copied to a stable directory. Note that if either `projectFile` or `nugetDeps` are unset, this script cannot be generated!
Here is an example `default.nix`, using some of the previously discussed arguments:
@@ -42,21 +42,7 @@ Unlike other libraries mentioned in this section, GdkPixbuf only supports a sing
### Icons {#ssec-gnome-icons}
When an application uses icons, an icon theme should be available in `XDG_DATA_DIRS` during runtime. The package for the default, icon-less [hicolor-icon-theme](https://www.freedesktop.org/wiki/Software/icon-theme/) (should be propagated by every icon theme) contains [a setup hook](#ssec-gnome-hooks-hicolor-icon-theme) that will pick up icon themes from `buildInputs` and add their datadirs to `XDG_ICON_DIRS` environment variable (this is Nixpkgs specific, not actually a XDG standard variable). Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
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
buildInputs=[
pantheon.elementary-icon-theme
];
preFixup=''
gappsWrapperArgs+=(
#Theiconthemeishardcoded.
--prefixXDG_DATA_DIRS:"$XDG_ICON_DIRS"
)
'';
```
When an application uses icons, an icon theme should be available in `XDG_DATA_DIRS` during runtime. The package for the default, icon-less [hicolor-icon-theme](https://www.freedesktop.org/wiki/Software/icon-theme/) (should be propagated by every icon theme) contains [a setup hook](#ssec-gnome-hooks-hicolor-icon-theme) that will pick up icon themes from `buildInputs` and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
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.
@@ -106,13 +92,13 @@ For convenience, it also adds `dconf.lib` for a GIO module implementing a GSetti
- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](#ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGAppsHook` copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGAppsHook` copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
- []{#ssec-gnome-hooks-gtk-drop-icon-theme-cache} One of `gtk3`’s setup hooks will remove `icon-theme.cache` files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with `dontDropIconThemeCache = true;`.
- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGAppsHook`, which then also adds it to the `GIO_EXTRA_MODULES` variable.
- []{#ssec-gnome-hooks-hicolor-icon-theme} `hicolor-icon-theme`’s setup hook will add icon themes to `XDG_ICON_DIRS`.
- []{#ssec-gnome-hooks-hicolor-icon-theme} `hicolor-icon-theme`’s setup hook will add icon themes to `XDG_ICON_DIRS` which is prepended to `XDG_DATA_DIRS` by `wrapGAppsHook`.
- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGAppsHook`. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGAppsHook`.
@@ -12,7 +12,8 @@ The function `buildGoModule` builds Go programs managed with Go modules. It buil
In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
-`vendorSha256`: is the hash of the output of the intermediate fetcher derivation. `vendorSha256` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorSha256 = null;`
-`proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorSha256` checksums.
-`runVend`: runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
-`proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if any dependency has case-insensitive conflicts which will produce platform dependant `vendorSha256` checksums.
@@ -142,8 +146,4 @@ Removes the pre-existing vendor directory. This should only be used if the depen
### `subPackages` {#var-go-subPackages}
Specified as a string or list of strings. Limits the builder from building child packages that have not been listed. If `subPackages` is not specified, all child packages will be built.
### `excludedPackages` {#var-go-excludedPackages}
Specified as a string or list of strings. Causes the builder to skip building child packages that match any of the provided values. If `excludedPackages` is not specified, all child packages will be built.
Limits the builder from building child packages that have not been listed. If `subPackages` is not specified, all child packages will be built.
@@ -8,16 +8,19 @@ The various tools available will be listed in the [tools-overview](#javascript-t
## Getting unstuck / finding code examples
If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
If you find you are lacking inspiration for packing javascript applications, the links below might prove useful.
Searching online for prior art can be helpful if you are running into solved problems.
### Github
- Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>
- Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>
### Gitlab
- Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>
- Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>
## Tools overview {#javascript-tools-overview}
@@ -32,128 +35,107 @@ It is often not documented which node version is used upstream, but if it is, tr
This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node. Some cryptic errors regarding V8 may appear.
An exception to this:
### Try to respect the package manager originally used by upstream (and use the upstream lock file) {#javascript-upstream-package-manager}
A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of node_modules for each tool.
Guidelines of package managers, recommend to commit those lock files to the repos. If a particular lock file is present, it is a strong indication of which package manager is used upstream.
It's better to try to use a Nix tool that understand the lock file. Using a different tool might give you hard to understand error because different packages have been installed. An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629). Upstream use NPM, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
It's better to try to use a nix tool that understand the lock file. Using a different tool might give you hard to understand error because different packages have been installed. An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629). Upstream uses npm, but this is an attempt to package it with yarn2nix (that uses yarn.lock)
Using a different tool forces to commit a lock file to the repository. Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
Exceptions to this rule are:
-When you encounter one of the bugs from a Nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general `yarn2nix` has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed.
- Some lock files contain particular version of a package that has been pulled off NPM for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
- The only tool that supports workspaces (a feature of NPM that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
-when you encounter one of the bugs from a nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general yarn2nix has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed
- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
- The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is yarn2nix. If upstream has workspaces you should try yarn2nix.
### Try to use upstream package.json {#javascript-upstream-package-json}
Exceptions to this rule are:
Exceptions to this rule are
- Sometimes the upstream repo assumes some dependencies be installed globally. In that case you can add them manually to the upstream package.json (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for CLI tools. (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
- Sometimes there is a version conflict between some dependency requirements. In that case you can fix a version by removing the `^`.
- Sometimes the script defined in the package.json does not work as is. Some scripts for example use CLI tools that might not be available, or cd in directory with a different package.json (for workspaces notably). In that case, it's perfectly fine to look at what the particular script is doing and break this down in the phases. In the build script you can see `build:*` calling in turns several other build scripts like `build:ui` or `build:server`. If one of those fails, you can try to separate those into,
- Sometimes the upstream repo assumes some dependencies be installed globally. In that case you can add them manually to the upstream package.json (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for cli tools. (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
- Sometimes there is a version conflict between some dependency requirements. In that case you can fix a version (by removing the `^`).
- Sometimes the script defined in the package.json does not work as is. Some scripts for example use cli tools that might not be available, or cd in directory with a different package.json (for workspaces notably). In that case, it's perfectly fine to look at what the particular script is doing and break this down in the phases. In the build script you can see `build:*` calling in turns several other build scripts like `build:ui` or `build:server`. If one of those fails, you can try to separate those into:
```sh
yarn build:ui
yarn build:server
# OR
npm run build:ui
npm run build:server
```
```Shell
yarn build:ui
yarn build:server
# OR
npm run build:ui
npm run build:server
```
when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:
when you need to override a package.json. It's nice to use the one from the upstream src and do some explicit override. Here is an 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.
### Using node_modules directly {#javascript-using-node_modules}
Each tool has an abstraction to just build the node_modules (dependencies) directory. You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command). The node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory.
each tool has an abstraction to just build the node_modules (dependencies) directory. you can always use the stdenv.mkDerivation with the node_modules to build the package (symlink the node_modules directory and then use the package build command). the node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. mkYarnModules to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory
The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [NPM packages](https://npmjs.com/) that can be installed with the Nix package manager.
The `pkgs/development/node-packages` folder contains a generated collection of
[NPM packages](https://npmjs.com/) that can be installed with the Nix package
manager.
As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities. Libraries should only be added to the package set if there is a non-NPM package that requires it.
As a rule of thumb, the package set should only provide _end user_ software
packages, such as command-line utilities. Libraries should only be added to the
package set if there is a non-NPM package that requires it.
When it is desired to use NPM libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
When it is desired to use NPM libraries in a development project, use the
`node2nix` generator directly on the `package.json` configuration file of the
project.
The package set provides support for the official stable Node.js versions. The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
The package set provides support for the official stable Node.js versions.
The latest stable LTS release in `nodePackages`, as well as the latest stable
Current release in `nodePackages_latest`.
If your package uses native addons, you need to examine what kind of native build system it uses. Here are some examples:
If your package uses native addons, you need to examine what kind of native
build system it uses. Here are some examples:
-`node-gyp`
-`node-gyp-builder`
-`node-pre-gyp`
After you have identified the correct system, you need to override your package expression while adding in build system as a build input. 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):
After you have identified the correct system, you need to override your package
expression while adding in build system as a build input. For example, `dat`
requires `node-gyp-build`, so [we override](https://github.com/NixOS/nixpkgs/blob/32f5e5da4a1b3f0595527f5195ac3a91451e9b56/pkgs/development/node-packages/default.nix#L37-L40) its expression in [`default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/default.nix):
### Adding and Updating Javascript packages in nixpkgs
To add a package from NPM to nixpkgs:
1. Modify [pkgs/development/node-packages/node-packages.json](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/node-packages.json) to add, update or remove package entries to have it included in `nodePackages` and `nodePackages_latest`.
2. Run the script:
```sh
./pkgs/development/node-packages/generate.sh
```
1. Modify `pkgs/development/node-packages/node-packages.json` to add, update
or remove package entries to have it included in `nodePackages` and
`nodePackages_latest`.
2. Run the script: `cd pkgs/development/node-packages && ./generate.sh`.
3. Build your new package to test your changes:
`cd /path/to/nixpkgs && nix-build -A nodePackages.<new-or-updated-package>`.
To build against the latest stable Current Node.js version (e.g. 14.x):
`nix-build -A nodePackages_latest.<new-or-updated-package>`
4. Add and commit all modified and generated files.
```sh
nix-build -A nodePackages.<new-or-updated-package>
```
To build against the latest stable Current Node.js version (e.g. 18.x):
```sh
nix-build -A nodePackages_latest.<new-or-updated-package>
```
If the package doesn't build, you may need to add an override as explained above.
4. If the package's name doesn't match any of the executables it provides, add an entry in [pkgs/development/node-packages/main-programs.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/main-programs.nix). This will be the case for all scoped packages, e.g., `@angular/cli`.
5. Add and commit all modified and generated files.
For more information about the generation process, consult the [README.md](https://github.com/svanderburg/node2nix) file of the `node2nix` tool.
To update NPM packages in nixpkgs, run the same `generate.sh` script:
```sh
./pkgs/development/node-packages/generate.sh
```
#### Git protocol error
Some packages may have Git dependencies from GitHub specified with `git://`.
GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
```
The unauthenticated git protocol on port 9418 is no longer supported
```
Use the following Git configuration to resolve the issue:
You will need to generate a Nix expression for the dependencies. Don't forget the `-l package-lock.json` if there is a lock file. Most probably you will need the `--development` to include the `devDependencies`
you will need to generate a nix expression for the dependencies
So the command will most likely be:
```sh
node2nix --development -l package-lock.json
```
- don't forget the `-l package-lock.json` if there is a lock file
- Most probably you will need the `--development` to include the `devDependencies`
See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
so the command will most likely be
`node2nix --development -l package-lock.json`
[link to the doc in the repo](https://github.com/svanderburg/node2nix)
#### Pitfalls {#javascript-node2nix-pitfalls}
- If upstream package.json does not have a "version" attribute, `node2nix` will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json).
- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs-16_x`.
- `node2nix` does not like missing packages from NPM. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of NPM.
- if upstream package.json does not have a "version" attribute, node2nix will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json)
-node2nix has some [bugs](https://github.com/svanderburg/node2nix/issues/238). related to working with lock files from npm distributed with nodejs-16_x
-node2nix does not like missing packages from npm. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of npm.
This will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), you will need to explicitly override the build step with your instructions. It's important to use the `--offline` flag. For example if you script is `"build": "something"` in package.json use:
this will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), you will need to explicitly override the build step with your instructions. It's important to use the `--offline` flag. For example if you script is `"build": "something"` in package.json use
```nix
buildPhase=''
@@ -195,13 +178,14 @@ buildPhase = ''
'';
```
The dist phase is also trying to build a binary, the only way to override it is with:
The dist phase is also trying to build a binary, the only way to override it is with
```nix
distPhase="true";
```
The configure phase can sometimes fail because it tries to be too clever. One common override is:
the configure phase can sometimes fail because it tries to be too clever.
This will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
this will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
#### Overriding dependency behavior
In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.
For instance, say your package is throwing errors when trying to invoke node-sass:
```
ENOENT: no such file or directory, scandir '/build/source/node_modules/node-sass/vendor'
```
For instance, say your package is throwing errors when trying to invoke node-sass:`ENOENT: no such file or directory, scandir '/build/source/node_modules/node-sass/vendor'`
To fix this we will specify different versions of build inputs to use, as well as some post install steps to get the software built the way we want:
@@ -239,8 +219,9 @@ mkYarnPackage rec {
#### Pitfalls {#javascript-yarn2nix-pitfalls}
- If version is missing from upstream package.json, yarn will silently install nothing. In that case, you will need to override package.json as shown in the [package.json section](#javascript-upstream-package-json)
- Having trouble with `node-gyp`? Try adding these lines to the `yarnPreBuild` steps:
- if version is missing from upstream package.json, yarn will silently install nothing. In that case, you will need to override package.json as shown in the [package.json section](#javascript-upstream-package-json)
- having trouble with node-gyp? Try adding these lines to the `yarnPreBuild` steps:
```nix
yarnPreBuild = ''
@@ -256,20 +237,20 @@ mkYarnPackage rec {
## Outside of nixpkgs {#javascript-outside-nixpkgs}
There are some other options available that can't be used inside nixpkgs. Those other options are written in Nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in Hydra at present. If you are packaging something outside nixpkgs, those can be considered
There are some other options available that can't be used inside nixpkgs. Those other options are written in nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in hydra at present. If you are packaging something outside nixpkgs, those can be considered
### npmlock2nix {#javascript-npmlock2nix}
[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might be subject to change.
[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the api might be subject to change.
#### Pitfalls {#javascript-npmlock2nix-pitfalls}
There are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issues/45).
- there are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issues/45).
[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might change. It supports both package-lock.json and yarn.lock.
[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the api might change. It supports both package-lock.json and yarn.lock.
@@ -6,7 +6,7 @@ Since release 15.09 there is a new TeX Live packaging that lives entirely under
- For basic usage just pull `texlive.combined.scheme-basic` for an environment with basic LaTeX support.
- It typically won't work to use separately installed packages together. Instead, you can build a custom set of packages like this. Most CTAN packages should be available:
- It typically won't work to use separately installed packages together. Instead, you can build a custom set of packages like this:
## Adding new plugins to nixpkgs {#adding-new-plugins-to-nixpkgs}
Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plugins](https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/editors/vim/plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py). This creates a [generated.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]@[gitref]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
Nix expressions for Vim plugins are stored in [pkgs/misc/vim-plugins](/pkgs/misc/vim-plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](/pkgs/misc/vim-plugins/update.py). This creates a [generated.nix](/pkgs/misc/vim-plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](/pkgs/misc/vim-plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]@[gitref]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
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](/pkgs/misc/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:
@@ -333,13 +330,13 @@ Finally, there are some plugins that are also packaged in nodePackages because t
Run the update script with a GitHub API token that has at least `public_repo` access. Running the script without the token is likely to result in rate-limiting (429 errors). For steps on creating an API token, please refer to [GitHub's token documentation](https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token).
@@ -78,46 +78,21 @@ If both the dependency and depending packages aren't compilers or other machine-
Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit time". This is for compilers that (regrettably) insist on being built together with their source languages' standard libraries. Assuming build != host != target, a run-time dependency of the standard library cannot be run at the compiler's build time or run time, but only at the run time of code emitted by the compiler.
Putting this all together, that means that we have dependency types of the form "X→ E", which means that the dependency executes on X and emits code for E; each of X and E can be `build`, `host`, or `target`, and E can be `*` to indicate that the dependency is not a compiler-like package.
Dependency types describe the relationships that a package has with each of its transitive dependencies. You could think of attaching one or more dependency types to each of the formal parameters at the top of a package's `.nix` file, as well as to all of *their* formal parameters, and so on. Triples like `(foo, bar, baz)`, on the other hand, are a property of an instantiated derivation -- you could would attach a triple `(mips-linux, mips-linux, sparc-solaris)` to a `.drv` file in `/nix/store`.
Only nine dependency types matter in practice:
Putting this all together, that means we have dependencies in the form "host → target", in at most the following six combinations:
#### Possible dependency types {#possible-dependency-types}
Let's use `g++` as an example to make this table clearer. `g++` is a C++ compiler written in C. Suppose we are building `g++` with a `(build, host, target)` platform triple of `(foo, bar, baz)`. This means we are using a `foo`-machine to build a copy of `g++` which will run on a `bar`-machine and emit binaries for the `baz`-machine.
*`g++` links against the host platform's `glibc` C library, which is a "host→ *" dependency with a triple of `(bar, bar, *)`. Since it is a library, not a compiler, it has no "target".
* Since `g++` is written in C, the `gcc` compiler used to compile it is a "build→ host" dependency of `g++` with a triple of `(foo, foo, bar)`. This compiler runs on the build platform and emits code for the host platform.
*`gcc` links against the build platform's `glibc` C library, which is a "build→ *" dependency with a triple of `(foo, foo, *)`. Since it is a library, not a compiler, it has no "target".
* This `gcc` is itself compiled by an *earlier* copy of `gcc`. This earlier copy of `gcc` is a "build→ build" dependency of `g++` with a triple of `(foo, foo, foo)`. This "early `gcc`" runs on the build platform and emits code for the build platform.
*`g++` is bundled with `libgcc`, which includes a collection of target-machine routines for exception handling and
software floating point emulation. `libgcc` would be a "target→ *" dependency with triple `(foo, baz, *)`, because it consists of machine code which gets linked against the output of the compiler that we are building. It is a library, not a compiler, so it has no target of its own.
* `libgcc` is written in C and compiled with `gcc`. The `gcc` that compiles it will be a "build→ target" dependency with triple `(foo, foo, baz)`. It gets compiled *and run* at `g++`-build-time (on platform `foo`), but must emit code for the `baz`-platform.
* `g++` allows inline assembler code, so it depends on access to a copy of the `gas` assembler. This would be a "host→ target" dependency with triple `(foo, bar, baz)`.
* `g++` (and `gcc`) include a library `libgccjit.so`, which wrap the compiler in a library to create a just-in-time compiler. In nixpkgs, this library is in the `libgccjit` package; if C++ required that programs have access to a JIT, `g++` would need to add a "target→ target" dependency for `libgccjit` with triple `(foo, baz, baz)`. This would ensure that the compiler ships with a copy of `libgccjit` which both executes on and generates code for the `baz`-platform.
* If `g++` itself linked against `libgccjit.so` (for example, to allow compile-time-evaluated C++ expressions), then the `libgccjit` package used to provide this functionality would be a "host→ host" dependency of `g++`: it is code which runs on the `host` and emits code for execution on the `host`.
Some examples will make this table clearer. Suppose there's some package that is being built with a `(build, host, target)` platform triple of `(foo, bar, baz)`. If it has a build-time library dependency, that would be a "host→ build" dependency with a triple of `(foo, foo, *)` (the target platform is irrelevant). If it needs a compiler to be built, that would be a "build → host" dependency with a triple of `(foo, foo, *)` (the target platform is irrelevant). That compiler, would be built with another compiler, also "build → host" dependency, with a triple of `(foo, foo, foo)`.
@@ -175,40 +175,6 @@ The NixOS tests are available as `nixosTests` in parameters of derivations. For
NixOS tests run in a VM, so they are slower than regular package tests. For more information see [NixOS module tests](https://nixos.org/manual/nixos/stable/#sec-nixos-tests).
Alternatively, you can specify other derivations as tests. You can make use of
the optional parameter to inject the correct package without
relying on non-local definitions, even in the presence of `overrideAttrs`.
Here that's `finalAttrs.finalPackage`, but you could choose a different name if
`finalAttrs` already exists in your scope.
`(mypkg.overrideAttrs f).passthru.tests` will be as expected, as long as the
definition of `tests` does not rely on the original `mypkg` or overrides it in
A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
@@ -226,6 +192,10 @@ meta.hydraPlatforms = [];
If set to `true`, the package is marked as "broken", meaning that it won’t show up in `nix-env -qa`, and cannot be built or installed. Such packages should be removed from Nixpkgs eventually unless they are fixed.
### `updateWalker` {#var-meta-updateWalker}
If set to `true`, the package is tested to be updated correctly by the `update-walker.sh` script without additional settings. Such packages have `meta.version` set and their homepage (or the page specified by `meta.downloadPage`) contains a direct link to the package tarball.
## Licenses {#sec-meta-license}
The `meta.license` attribute should preferably contain a value from `lib.licenses` defined in [`nixpkgs/lib/licenses.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix), or in-place license description of the same format if the license is unlikely to be useful in another expression.
@@ -77,7 +77,7 @@ There is a special handling of the `debug` output, described at [](#stdenv-separ
A commonly adopted convention in `nixpkgs` is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the `perl` package contains a `perl` executable it can be referenced as `${pkgs.perl}/bin/perl` within a Nix derivation that needs to execute a Perl script.
The `glibc` package is a deliberate single exception to the “binaries first” convention. The `glibc` has `libs` as its first output allowing the libraries provided by `glibc` to be referenced directly (e.g. `${glibc}/lib/ld-linux-x86-64.so.2`). The executables provided by `glibc` can be accessed via its `bin` attribute (e.g. `${lib.getBin stdenv.cc.libc}/bin/ldd`).
The `glibc` package is a deliberate single exception to the “binaries first” convention. The `glibc` has `libs` as its first output allowing the libraries provided by `glibc` to be referenced directly (e.g. `${stdenv.glibc}/lib/ld-linux-x86-64.so.2`). The executables provided by `glibc` can be accessed via its `bin` attribute (e.g. `${stdenv.glibc.bin}/bin/ldd`).
The reason for why `glibc` deviates from the convention is because referencing a library provided by `glibc` is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of `glibc` libraries from Nix packages (please see the documentation on [patchelf](https://github.com/NixOS/patchelf) for more details).
@@ -125,7 +125,7 @@ The extension of `PATH` with dependencies, alluded to above, proceeds according
A dependency is said to be **propagated** when some of its other-transitive (non-immediate) downstream dependencies also need it as an immediate dependency.
[^footnote-stdenv-propagated-dependencies]
It is important to note that dependencies are not necessarily propagated as the same sort of dependency that they were before, but rather as the corresponding sort so that the platform rules still line up. To determine the exact rules for dependency propagation, we start by assigning to each dependency a couple of ternary numbers (`-1` for `build`, `0` for `host`, and `1` for `target`) representing its [dependency type](#possible-dependency-types), which captures how its host and target platforms are each "offset" from the depending derivation’s host and target platforms. The following table summarize the different combinations that can be obtained:
It is important to note that dependencies are not necessarily propagated as the same sort of dependency that they were before, but rather as the corresponding sort so that the platform rules still line up. To determine the exact rules for dependency propagation, we start by assigning to each dependency a couple of ternary numbers (`-1` for `build`, `0` for `host`, and `1` for `target`), representing how respectively its host and target platforms are "offset" from the depending derivation’s platforms. The following table summarize the different combinations that can be obtained:
@@ -317,72 +317,12 @@ The script will be usually run from the root of the Nixpkgs repository but you s
For information about how to run the updates, execute `nix-shell maintainers/scripts/update.nix`.
### Recursive attributes in `mkDerivation`
If you pass a function to `mkDerivation`, it will receive as its argument the final arguments, including the overrides when reinvoked via `overrideAttrs`. For example:
# `(pkg.overrideAttrs(x)).finalAttrs` etc in the text below.
passthru.finalAttrs=finalAttrs;
passthru.original=pkg;
});
inpkg
```
Unlike the `pkg` binding in the above example, the `finalAttrs` parameter always references the final attributes. For instance `(pkg.overrideAttrs(x)).finalAttrs.finalPackage` is identical to `pkg.overrideAttrs(x)`, whereas `(pkg.overrideAttrs(x)).original` is the same as the original `pkg`.
See also the section about [`passthru.tests`](#var-meta-tests).
## Phases {#sec-stdenv-phases}
`stdenv.mkDerivation` sets the Nix [derivation](https://nixos.org/manual/nix/stable/expressions/derivations.html#derivations)'s builder to a script that loads the stdenv `setup.sh` bash library and calls `genericBuild`. Most packaging functions rely on this default builder.
This generic command invokes a number of *phases*. Package builds are split into phases to make it easier to override specific parts of the build (e.g., unpacking the sources or installing the binaries).
The generic builder has a number of *phases*. Package builds are split into phases to make it easier to override specific parts of the build (e.g., unpacking the sources or installing the binaries). Furthermore, it allows a nicer presentation of build logs in the Nix build farm.
Each phase can be overridden in its entirety either by setting the environment variable `namePhase` to a string containing some shell commands to be executed, or by redefining the shell function `namePhase`. The former is convenient to override a phase from the derivation, while the latter is convenient from a build script. However, typically one only wants to *add* some commands to a phase, e.g. by defining `postInstall` or `preFixup`, as skipping some of the default actions may have unexpected consequences. The default script for each phase is defined in the file `pkgs/stdenv/generic/setup.sh`.
When overriding a phase, for example `installPhase`, it is important to start with `runHook preInstall` and end it with `runHook postInstall`, otherwise `preInstall` and `postInstall` will not be run. Even if you don't use them directly, it is good practice to do so anyways for downstream users who would want to add a `postInstall` by overriding your derivation.
While inside an interactive `nix-shell`, if you wanted to run all phases in the order they would be run in an actual build, you can invoke `genericBuild` yourself.
### Controlling phases {#ssec-controlling-phases}
There are a number of variables that control what phases are executed and in what order:
@@ -393,8 +333,7 @@ There are a number of variables that control what phases are executed and in wha
Specifies the phases. You can change the order in which phases are executed, or add new phases, by setting this variable. If it’s not set, the default value is used, which is `$prePhases unpackPhase patchPhase $preConfigurePhases configurePhase $preBuildPhases buildPhase checkPhase $preInstallPhases installPhase fixupPhase installCheckPhase $preDistPhases distPhase $postPhases`.
It is discouraged to set this variable, as it is easy to miss some important functionality hidden in some of the less obviously needed phases (like `fixupPhase` which patches the shebang of scripts).
Usually, if you just want to add a few phases, it’s more convenient to set one of the variables below (such as `preInstallPhases`).
Usually, if you just want to add a few phases, it’s more convenient to set one of the variables below (such as `preInstallPhases`), as you then don’t specify all the normal phases.
##### `prePhases` {#var-stdenv-prePhases}
@@ -851,13 +790,13 @@ Hook executed at the start of the distribution phase.
Hook executed at the end of the distribution phase.
## Shell functions and utilities {#ssec-stdenv-functions}
## Shell functions {#ssec-stdenv-functions}
The standard environment provides a number of useful functions.
Constructs a wrapper for a program with various possible arguments. It is defined as part of 2 setup-hooks named `makeWrapper` and `makeBinaryWrapper` that implement the same bash functions. Hence, to use it you have to add `makeWrapper` to your `nativeBuildInputs`. Here's an example usage:
Constructs a wrapper for a program with various possible arguments. For example:
```bash
# adds `FOOBAR=baz` to `$out/bin/foo`’s environment
There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh` for the `makeWrapper` implementation and in `nixpkgs/pkgs/build-support/setup-hooks/make-binary-wrapper/make-binary-wrapper.sh` for the `makeBinaryWrapper` implementation.
There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh`.
`wrapProgram` is a convenience function you probably want to use most of the time, implemented by both `makeWrapper` and `makeBinaryWrapper`.
Using the `makeBinaryWrapper` implementation is usually preferred, as it creates a tiny _compiled_ wrapper executable, that can be used as a shebang interpreter. This is needed mostly on Darwin, where shebangs cannot point to scripts, [due to a limitation with the `execve`-syscall](https://stackoverflow.com/questions/67100831/macos-shebang-with-absolute-path-not-working). Compiled wrappers generated by `makeBinaryWrapper` can be inspected with `less <path-to-wrapper>` - by scrolling past the binary data you should be able to see the shell command that generated the executable and there see the environment variables that were injected into the wrapper.
Removes the references of the specified files to the specified store files. This is done without changing the size of the file by replacing the hash by `eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee`, and should work on compiled executables. This is meant to be used to remove the dependency of the output on inputs that are known to be unnecessary at runtime. Of course, reckless usage will break the patched programs.
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`.
Example removing all references to the compiler in the output:
Convenience function for `makeWrapper` that replaces `<\executable\>` with a wrapper that executes the original program. It takes all the same arguments as `makeWrapper`, except for `--inherit-argv0` (used by the `makeBinaryWrapper` implementation) and `--argv0` (used by both `makeWrapper` and `makeBinaryWrapper` wrapper implementations).
Convenience function for `makeWrapper` that automatically creates a sane wrapper file. It takes all the same arguments as `makeWrapper`, except for `--argv0`.
If you will apply it multiple times, it will overwrite the wrapper file and you will end up with double wrapping, which should be avoided.
It cannot be applied multiple times, since it will overwrite the wrapper file.
## Package setup hooks {#ssec-setup-hooks}
@@ -1097,7 +1021,7 @@ You can also specify a `runtimeDependencies` variable which lists dependencies t
In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.
By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value.`autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.
By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value.
The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.
## Modify packages via `packageOverrides` {#sec-modify-via-packageOverrides}
You can define a function called `packageOverrides` in your local `~/.config/nixpkgs/config.nix` to override Nix packages. It must be a function that takes pkgs as an argument and returns a modified set of packages.
@@ -77,7 +77,7 @@ In Nixpkgs, we have multiple implementations of the BLAS/LAPACK numerical linear
The Nixpkgs attribute is `openblas` for ILP64 (integer width = 64 bits) and `openblasCompat` for LP64 (integer width = 32 bits). `openblasCompat` is the default.
- [LAPACK reference](http://www.netlib.org/lapack/) (also provides BLAS and CBLAS)
@@ -117,23 +117,7 @@ $ LD_LIBRARY_PATH=$(nix-build -A mkl)/lib${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH n
Intel MKL requires an `openmp` implementation when running with multiple processors. By default, `mkl` will use Intel's `iomp` implementation if no other is specified, but this is a runtime-only dependency and binary compatible with the LLVM implementation. To use that one instead, Intel recommends users set it with `LD_PRELOAD`. Note that `mkl` is only available on `x86_64-linux` and `x86_64-darwin`. Moreover, Hydra is not building and distributing pre-compiled binaries using it.
To override`blas`and`lapack` with its reference implementations (i.e. for development purposes), one can use the following overlay:
```nix
self:super:
{
blas=super.blas.override{
blasProvider=self.lapack-reference;
};
lapack=super.lapack.override{
lapackProvider=self.lapack-reference;
};
}
```
For BLAS/LAPACK switching to work correctly, all packages must depend on `blas` or `lapack`. This ensures that only one BLAS/LAPACK library is used at one time. There are two versions of BLAS/LAPACK currently in the wild, `LP64` (integer size = 32 bits) and `ILP64` (integer size = 64 bits). The attributes `blas` and `lapack` are `LP64` by default. Their `ILP64` version are provided through the attributes `blas-ilp64` and `lapack-ilp64`. Some software needs special flags or patches to work with `ILP64`. You can check if `ILP64` is used in Nixpkgs with `blas.isILP64` and `lapack.isILP64`. Some software does NOT work with `ILP64`, and derivations need to specify an assertion to prevent this. You can prevent `ILP64` from being used with the following:
For BLAS/LAPACK switching to work correctly, all packages must depend on`blas`or`lapack`. This ensures that only one BLAS/LAPACK library is used at one time. There are two versions of BLAS/LAPACK currently in the wild, `LP64` (integer size = 32 bits) and `ILP64` (integer size = 64 bits). Some software needs special flags or patches to work with `ILP64`. You can check if `ILP64` is used in Nixpkgs with `blas.isILP64` and `lapack.isILP64`. Some software does NOT work with `ILP64`, and derivations need to specify an assertion to prevent this. You can prevent `ILP64` from being used with the following:
In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`, while all other attributes will be retained from the original `hello` package.
The argument `previousAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
The argument `finalAttrs` refers to the final attributes passed to `mkDerivation`, plus the `finalPackage` attribute which is equal to the result of `mkDerivation` or subsequent `overrideAttrs` calls.
If only a one-argument function is written, the argument has the meaning of `previousAttrs`.
The argument `oldAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
::: {.note}
Note that `separateDebugInfo` is processed only by the `stdenv.mkDerivation` function, not the generated, raw Nix derivation. Thus, using `overrideDerivation` will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that `overrideAttrs` should be preferred in (almost) all cases to `overrideDerivation`, i.e. to allow using `stdenv.mkDerivation` to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. `buildInputs` vs `nativeBuildInputs`), and it involves less typing).
# Other platforms with sufficient support in stdenv which is not formally
# mandated by their platform tier.
"aarch64-darwin"
"armv5tel-linux"
"powerpc64le-linux"
"riscv64-linux"
# "x86_64-freebsd" is excluded because it is mostly broken
]
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
