disable checks for werkzeug where one test started to fail recently.
An update of werkzeug inside octoprint isn't possible (yet), so disable
the tests.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Due to the removal of tools like `tiff2pdf` from `libtiff`
many tests fail or cause a timeout.
This commit fixes the dependency to `libtiff_4_5`.
Also it includes two upstream patches, which haven't been merged
and re-adds a previously removed test.
fixes#268406
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
since the new release of 7.0, the `generated` directory isn't included
in the tarball anymore. This commit will build the frontend so
pgadmin can function again.
Fixes https://github.com/NixOS/nixpkgs/pull/226675#issuecomment-1529033940
Also this commit will switch to the Github source and will not
need the package.json and yarn.{lock,nix} files anymore, since the
mkYarnModules part has been removed.
Also, since we don't depend on those files anymore and we switched
to Github, the `update.sh` script has been superseeded and isn't
needed anymore.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Existing postPatch/postInstall phases bring reference to "openssl" if gpgme or
smime are enabled, regardless of "enableSSL" configuration option.
To avoid unnecessary illusion we refuse to evaluate "+gpgme -ssl" configuration
instead of building output that does not match requested configuration.
Previously, the Python path selection logic was patched in the CMake
files. This patch no longer applies.
Fortunately there is a new way to directly specify the path without
patches. Use that instead on all platforms to fix the CMake logic being
broken on Darwin which results in this module not being detected and
the main application failing to start.
Implements a few usability changes for dracut framework by suffixing
rather than prefixing `DRACUT_PATH` (so that downstream consumers can
more easily override it) and reduce closure size by bundling fewer
default utilities in `DRACUT_PATH`.
Done per comments at https://github.com/NixOS/nixpkgs/pull/210075#discussion_r1088822274.
The build for the sapling package happens in three steps:
1. build sapling-isl
2. build sapling-main, copying files from sapling-isl
3. build sapling, copying files from sapling-main
I don't see a reason for splitting sapling-main and sapling. The problem
with splitting is that it makes it hard to use a package override to
patch sapling-main.
Merge sapling-main and sapling so I can easily apply patches with my
nixpkgs/config.nix.
The tests fail to build on 32-bit platforms, due to an upstream bug which will
be fixed in 3.22. Previously, this was holding back the default protobuf version
on 32-bit platforms to 3.20, which in turn broke packages such as mypy-protobuf
which require 3.21
This commit disables building the tests on 32-bit platforms, allowing 3.21 to
build. Note that we don't ever run the tests on any platform, but they are
normally still built.
Now that 3.21 builds on 32-bit, this commit also unpins 3.20 as the default
version.
Fixes `paraview` module import error in pvpython/pvbatch (#215144) by
building with Python 3.9. Also implements `mkDerivation` recommendations
from #180841.
`ghc ? hadrian` can be used to check if a GHC was built using hadrian.
This is often relevant since hadrian changed the ghc libdir location, so
we need to install libs to a different location as well.
The current workaround for the regression is propagating the
runtime dependency closure (technically only Requires.private in the
pkg-config files). This can easily be done automatically by mimicking
how e.g. pkgsStatic converts buildInputs to propagatedBuildInputs.
This is extracted into a helper function,
__CabalEagerPkgConfigWorkaround, which can be applied to any package
easily.
The Haskell Hydra report generator
(`maintainers/scripts/haskell/hydra-report.hs`) uses this
`maintainer-handles.nix` script for generating a mapping of email
addresses to GitHub handles.
This `maintainer-handles.nix` script is necessary because the Haskell
Hydra report generator gets Hydra job status info as input, but needs to
ping users on GitHub. Hydra job status info only contains user emails (not
GitHub handles). So the `maintainer-handles.nix` script is necessary
for looking up GitHub handles from email addresses.
This commit fixes the `maintainers-handles.nix` code to ignore
maintainers that don't have email addresses. The code was originally
assuming that all maintainers have email addresses, but there was
recently a maintainer added without an email address.
Issue: after installing, running `yubikey-agent -setup` produces the
following error:
```
nixOS: Failed to connect to the YubiKey: connecting to pscs: the Smart
card resource manager is not running
```
More on this issue: https://github.com/FiloSottile/yubikey-agent/issues/137
testing pyembed configuration : Could not build a python embedded interpreter
tevent-aarch64-unknown-linux-gnu> In file included from ../../pytevent.c:26:
tevent-aarch64-unknown-linux-gnu> ../../lib/replace/replace.h:885:10: fatal error: crypt.h: No such file or directory
tevent-aarch64-unknown-linux-gnu> 885 | #include <crypt.h>
tevent-aarch64-unknown-linux-gnu> | ^~~~~~~~~
tevent-aarch64-unknown-linux-gnu> compilation terminated.
It's possible that setting wpa=2 disables TKIP anyway, but on my machine
I could not get 802.11n to work without setting rsn_pairwise=CCMP.
N.B. rsn_pairwise takes its default from wpa_pairwise.
As documented by lib.composeManyExtensions, overrides intended to be applied later should come last in the list. This commit switches the order to make sure that custom overrides are in fact evaluated after the default ones. Also, since the previous version was basically a reimplementation of composeManyExtensions anyway, switching to that makes it a bit cleaner.
Adds support for armv6l-linux and armv7l-linux. These are officially
supported by the AdGuard team (they provide binaries for these
architectures).
See assets on their github releases:
https://github.com/AdguardTeam/AdGuardHome/releases
This fixes loading the shared library used for interacting with Nvidia
hardware. A similar package, nvidia-ml-py, already provides a patch for
the same thing. This commit adds a similar patch for pynvml. We could
not reuse the existing patch for the other package because the files
being patched have different names despite the patch itself being nearly
the same.
Fixes https://github.com/NixOS/nixpkgs/issues/209416
Multi-output `includedir` magic for `pkg-config` was not working, as not
only `libdir` was affected by `postPatch` script. And absolute path to
include directory is not compatibe with this magic either. So the
pkg-config file contained a path to non-existing directory (`include`,
but in the main `out` output).
The only package to use this library is openscad, but it's currently
not picking it - will fix it in a separate PR.
gcc lto-wrapper uses the make jobserver to speed up linking, and it
doesn't support the new fifo:/path style of jobserver-auth yet. it'll
still work but use only one thread, so we should stick to the old style
for now.
lib.optionalString creates an empty string when the condition is false
And the circt test framework interprets this as disabling all tests
failing the build with `error: filter did not match any tests`
By default, the desktop file of the Slack desktop client will output its
verbose logs to the system logs. To fix this, the '-s' flag which will
reduce the log level.
render all manual chapters to docbook from scratch every time the manual
is built. nixos-render-docs is quick enough at this to not worry about
the cost (needing only about a second), and it means we can remove
md-to-db.sh in the next commit.
no changes to the rendered html manual except for replacements and smartquotes.
we'll soon add another docbook converter that does not emit a section as
a collection of chapters, but sections or chapters on their own. this
should clarify naming a bit before there can be any confusion.
this is currently only supported by the docbook exporter, and even the
docbook exporter doesn't do much with them. we mirror the conversion
pandoc did for consistency with the previous manual chapter conversion,
which is to add just an anchor with the given id. future exporters that
go directly to html might want to do more.
this is a subset of pandoc's fenced divs. currently we only use this for
admonitions (which get a new name to differentiate them from other kinds
of blocks), but more users will appear soon.
this is used by release notes (and we don't want to break links to
those), and is also technically allowed anyway. we will *not* extend the
regex to allow more characters just yet due to a mozilla recommendation
against it (cf https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id)
this should've been a core rule from the beginning. not being a core
rule made it always run after smartquotes and replacements, which
could've wrecked the id.
this lets us parse the `[F12]{.keycap}` syntax we recently introduced to
the nixos manual markdown sources. the docbook renderer emits the keycap
element for this class, the manpage renderer will reject it because it's
not entirely clear what to do with it: while html has <kbd> mandoc has
nothing of the sort, and with no current occurences in options doc we
don't have to settle on a (potentially bad) way to render these.
this is pretty much what pandoc calls bracketed spans. since we only
want to support ids and classes it doesn't seem fair to copy the name,
so we'll call them "attributed span" for now. renderers are expected to
know about *all* classes they could encounter and act appropriately, and
since there are currently no classes with any defined behavior the most
appropriate thing to do for now is to reject all classes.
since support for kbd elements was added with explicit intent in #175128
it seems like a good idea to support this in nixos-render-docs instead
of just dropping it in favor of `*F12*` etc. since it's a very rare
thing in the manual and purely presentational it makes sense to use
bracketed spans instead of a new myst role.
the html-elements.lua plugin is now somewhat misnamed, but it'll go away
very soon so we don't want to bother renaming it.
this is a lot easier than adding footnote support for just the one
instance. if a use case for footnotes appears in the future (e.g. if we
wanted to render the nixpkgs manual with nixos-render-docs as well) this
decision should be reevaluated.
nixos-render-docs supports inline anchors, but not ids for blocks. it
seems wise to reserve blocks for special cases that don't have other
syntax already, like admonitions.
pandoc drops .title classes when rendering to docbook, so these are
effectively just paragraphs anyway. without support for including them
in a table of contents the complexity of parsing them in
nixos-render-docs won't be warranted.
the examples for mkPackageOption weren't terminated, leading to pretty
odd nesting of docbook (and thus html) elements. close them properly.
also turn the (likewise unclosed) fenced div containing just an anchor
id and a class that will be silently dropped to an inline anchor while
we're here. we'd have to convert it anyway later.
markdown-it parses deflists slitghtly differently than pandoc does. in
these two cases pandoc would find a deflist item while markdown-it would
not, instead it'd find a lone colon and the rest of the text.
pandoc renders these to multiple docbook paragraphs in a single
definition for the term, not multiple *actual* definitions for the same
term. this is most likely not what is intended here, so let's use
multiple paragraphs instead.
this should be placed before the appendices, not between them. might
even have a good place in the development part, but that's a decision
for another day.
Without the change `:help` command failed to find the help as:
$ rm -rfv ~/.config/vifm/ ~/.vifm
$ vifm
<in vifm>:help
Error detected while processing command line:
E149: Sorry, no help for vifm-app.txt
This happened because `tags` in `doc` directory was empty:
$(top_srcdir)/data/vim/doc/plugin/tags: \
$(top_srcdir)/data/vim/doc/plugin/vifm-plugin.txt
$(AM_V_GEN)mkdir -p ../data/vim/doc/plugin/; \
if [ -n "$(PERL)" ]; then \
$(srcdir)/helpztags "$(top_srcdir)/data/vim/doc/plugin"; \
elif [ -n "$(VIM)" ]; then \
vim -e -s -c 'helptags $(top_srcdir)/data/vim/doc/plugin|q'; \
else \
touch $@; \
fi
The change pulls in `perl` into build depends to get tags working.
Netdata package has been updated several times in the meantime, but this
(somewhat crucial) dependency was left forgotten and unloved. So this is
quite huge jump in versions, but it is needed as many of the collectors
were added there (the one I have noticed that is missing is PostgreSQL
collector, but I bet that there is more).
It also adds missing Bash `buildInput` as I noticed that it is needed by
some shell collectors (cgroups I believe).
compared output and the build log and python2 is not required
both build
'pkgsCross.aarch64-android.linuxHeaders'
'pkgsCross.aarch64-android.bionic.linuxHeaders'
linux-headers> LEX scripts/kconfig/lexer.lex.c
linux-headers> sh: line 1: flex: command not found
linux-headers> YACC scripts/kconfig/parser.tab.[ch]
linux-headers> sh: line 1: bison: command not found
linux-headers> INSTALL ./usr/include
linux-headers> sh: line 1: rsync: command not found
Co-authored-by: exarkun <exarkun@twistedmatrix.com>
Makes samba use the nix vendored `talloc` instead of compiling its own,
bundleded version. This fixes an issue where the library may be initialized
with different magic numbers, resulting in segfaults. See in
https://github.com/NixOS/nixpkgs/issues/205859 for further detail.
the (vc4 redox) flex conditional was missing in all other gcc version
because gcc6 was the default at the time it was added
that is one of the problems common/dependencies.nix fixes
By default, pgadmin4 uses SERVER_MODE = True. This requires
access to system directories (e.g. /var/lib/pgadmin). There is
no easy way to change this mode during runtime. One has to change
or add config files withing pgadmin's directory structure to change it
or add a system-wide config file under `/etc/pgadmin`[1].
This isn't always easy to achive or may not be possible at all. For
those usecases this implements a switch in the pgadmin4 derivation and
adds a new top-level package `pgadmin4-desktopmode`. This builds in
DESKTOP MODE and allows the usage of pgadmin4 without the nixOS module
and without access to system-wide directories.
pgadmin4 module saves the configuration to /etc/pgadmin/config_system.py
pgadmin4-desktopmode tries to read that as well. This normally fails with
a PermissionError, as the config file is owned by the user of the pgadmin module.
With the check-system-config-dir.patch this will just throw a warning
but will continue and not read the file.
If we run pgadmin4-desktopmode as root
(something one really shouldn't do), it can read the config file and fail,
because of the wrong config for desktopmode.
[1]https://www.pgadmin.org/docs/pgadmin4/latest/config_py.html
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
We test pgadmin in nixosTests, because it needs a running postgresql instance.
This is now unnecessary since we can do so in the package itself.
This reduces the complexity of pgadmin and removes the need for the extra
nixosTests.
Also setting SERVER_MODE in `pkg/pip/setup_pip.py` does not have any effect
on the final package, so we remove it.
In NixOS, we use the module, which expects SERVER_MODE to be true (which it defaults to).
In non-NixOS installations, we will need the directory /var/lib/pgadmin and /var/log/pgadmin
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
The nixos module uses `caddy fmt` to *format* the generated Caddyfile.
v2.6.3 slightly altered `caddy fmt`'s behavior.
Excerpt from https://github.com/caddyserver/caddy/releases/tag/v2.6.3
> cmd: caddy fmt return code is 1 if not formatted
> cmd: fmt exit successfully after overwriting config file
Which is why the internal `Caddyfile-formatted` now uses `cp` and `caddy fmt --overwrite` instead
This patch provides input arguments `newuidmapPath` and `newgidmapPath`
for apptainer and singularity to specify the path to the SUID-ed executables
newuidmap and newgidmap where they are not available from the FHS PATH.
As NixOS places those suided executables in a non-FHS position
(/run/wrapper/bin), this patch provides
programs.singularity.enableFakeroot option and implement with the above
input parameters.
Upstream changes:
singularity 3.8.7 (the legacy) -> apptainer 1.1.3 (the renamed) / singularity 3.10.4 (Sylabs's fork)
Build process:
* Share between different sources
* Fix the sed regexp to make defaultPath patch work
* allowGoReference is now true
* Provied input parameter removeCompat (default to false)
that removes the compatible "*singularity*" symbolic links
and related autocompletion files when projectName != "singularity"
* Change localstatedir to /var/lib
* Format with nixpkgs-fmt
* Fix the defaultPath patching
and use it instead of the `<executable> path` config directive
deprecated in Apptainer
* Provide dependencies for new functionalities such as
squashfuse (unprivileged squashfs mount)
* Provide an attribute `defaultPathInputs` to override
prefix of container runtime default PATH
NixOS module programs.singularity:
* Allow users to specify packages
* Place related directories to /var/lib
* Format with nixpkgs-fmt
singularity-tools:
* Allow users to specify packages
* Place related directories to /var/lib when building images in VM
now that the renderer produces the output we want to keep for the future
we can add a test that checks all of its features. this test notably
does not include markdown headings since we don't want to have those in
manpages (at least right now), but tests for other converters may add
headings for themselves.
for the longest time we completely dropped link targets in
configuration.nix.5. let's stop doing this now and instead provide a
footnote for each link in a given option, numbered locally per option.
we will currently duplicate the link for <labelless-links> because it
makes it easier to get the collection of all links in a given option.
this may not be useful enough, so over time we might decide to drop the
footnotes for such links.
indent the entire list by 4, just like each definition is already
indented by 4. this matches rendering in html, which indents terms once
and indents definitions twice.
other output types already have markings for inline code, manpages do
not. this can be somewhat confusing, so we'll do the least intrusive
thing: surrounding inline code blocks in ‘’. doing so separates inline
code from the rest of the text and is unlikely to collide with the
quoted contents. it's also what mdoc does with its Ql macro.
no reason to differentiate between links by source of their label. this
feature seems to be mostly used to change labels of links to other
options, but this should ultimately be done by auto-linking from
{option}`...`. at some point we may want to introduce a warning when
this pattern is encountered, but there's a lot to work out still before
we can do that.
most of the lists in option docs are actually compact, but docbook to
manpage processing always rendered them as non-compact. compactifying
these lists improves readability somewhat since most lists and their
contents are pretty short.
mdoc is just too slow to render on groff, and semantic markup doesn't
help us any for generated pages.
this produces a lot of changes to configuration.nix.5, but only few
rendering changes. most of those seem to be place losing a space where
docbook emitted roff code that did not faithfully represent the input
text, though a few places also gained space where docbook dropped them.
notably we also don't need the compatibility code docbook-xsl emitted
because that problem was fixed over a decade ago.
this will handle block quotes, which the docbook stylesheets turned into
a mess of roff requests that ended up showing up in the output instead
of being processed.
Token.attr is a dict[str, str | int | float], meta has no restriction on
the value type. attrs is ostensibly meant for html attributes, meta for
any information whatsoever.
these work together with render and renderInline to produce an output
from either of the two. rendering manpages will need both: to join
blocks with newlines, and to run some postprocessing and the rendered inlines.
pulling mypy into the build closure is unfortunately not reasonable, the
closure for mypy is rather large and takes a long time to build. if we
have the type checks hooked into CI we'll get most of the benefit though.
Since this feature's inception, we've compiled a binary that uses OpenSSL
to perform PBKDF-SHA512 during the extra-utils build. In addition to this
being inefficient, it broke as of 6ea1a2a1be,
which switched the extra-utils derivation to use stdenvNoCC.
For now, I think the path of least resistence is to move the pbkdf-sha512
build to its own derivation, to fix the breakage, as well as improving
the efficiency of the extra-utils build.
(I do believe that at some point, we should revisit this binary -- perhaps
rewriting it -- as Clang even just on its default settings emits more
warnings than you'd want to see in a security-related codebase when
compiling it.)
Nixpkgs convention is to only add attributes for deprecation throws
when config.allowAliases hasn't been explicitly disabled. This is
useful as it makes it easy to test building all non-deprecated
packages:
nix-build --arg config '{ allowAliases = false; }' -A sourcehut
Precedent for this convention in Nixpkgs is easy to find by grepping
for "config.allowAliases".
fixes this warning:
cdrecord <= 2.01.01a05 will be run with root privileges on kernel >= 2.6.8
Since Linux kernel 2.6.8 cdrecord <= 2.01.01a05 will not work when run suid root for security reasons anymore.
The upstream repo has regular releases and elementaryOS-specific releases.
We only want the regular releases, so filter out the elementaryOS ones in a
custom updateScript.
When aarch64 support was added, the x86_64 appears to have been
accidentally replaced with the one for eclipse-platform.
Fixes: 2c3e53a6cd ("eclipses.*: Enable on aarch64-linux")
While I was in here, I ported this code to use `pytestCheckHook`.
This fixes https://github.com/NixOS/nixpkgs/issues/211415 (maybe this is
more of a workaround?).
This build was failing due to a broken test upstream. I've instructed
nix to skip that test for now.
I also changed the `py.test` to plain `pytest`. I'm not familiar with
the difference, but according to [this SO
answer](https://stackoverflow.com/a/41893170/1739415), it sounds like
`pytest` is the new hotness and should be used wherever possible.
Running `make -C doc` to build the manual locally leaves .xml artifacts
in the tree. These are ignored by git, but they still get included in
the build when not using flakes, which causes the corresponding chapters
not to be built.
The output of a command is not guaranteed to be valid UTF-8, so the
decoding can fail raising UnicodeDecodeError. If this happens during a
`succeeds` the check will be erroneously marked failed.
This changes the error handling to the "replace" mode, where invalid
codepoints are replaced with � (REPLACEMENT CHARACTER U+FFFD) and the
decoding can go on.
This change (dynamically linking against libffi from Nixpkgs) is
required since we switched to third_party/wayland instead of linking
against Wayland from Nixpkgs (26aadca7c6). See also f9d9864cb6 and
d932886d6e for more details.
We could alternatively provide libffi_pic.a for static linking but due
to our immutable dependency model / pure builds the dynamic linking
shouldn't cause any issues.
This fixes the build error shown in [0].
[0]: https://github.com/NixOS/nixpkgs/issues/213862#issuecomment-1412519998
The cups-pdf vm test previously waited for the
activation of `cups.service` before testing anything.
This method fails since
https://github.com/NixOS/nixpkgs/commit/47d9e7d3d7d8ad19e29be1445171726bf7d602b6
as cups auto-stops if it is not used,
causing the test framework to complain
that `cups.service` will never start.
The commit at hand alters the test so it
simply waits for `multi-user.target`.
We could also switch to `cups.socket`,
but `multi-user.target` seems to be more robust
concerning future changes in the cups mechanisms.
The previous changes for the 3.8 update are ready, but staging got
merged into master, so there are a few more challenges to tackle:
* Use python 3.10 now since it's actually supported and less effort to
build (3.9 isn't recursed into anymore).
* sphinx doesn't build with these overrides, so patch it out entirely
(i.e. drop `sphinxHook` where it's causing problems).
* backport a few jinja2 fixes for python 3.10 that were fixed in later
versions, but break because this env is stuck to 2.11.
See docs.
Follow-up work:
- Existing packages should be converted
- `defaultPkgConfigPackages` should assert on `meta.pkgConfigModules`
and let `tests.pkg-config` alone test the build results.
CC @sternenseemann
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
AMC will look for its libraries on the nix store path if and only iff
its default modules directory doesn't exist. The value for this
variable was /lib/, which exists on some systems. This commit changes
it to /nonexistent, the "canonical non-existent home directory" per
Debian policy, which probably won't exist anywhere.
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
Upstream bakes their API tokens for external services
(like Strava) in its source. When users want to connect
golden-cheetah to the external services, they fail and there
is no option to add own API keys during runtime.
So either the user modifies the derivation to add their own API
keys during build, or we add the pre-build AppImage to NixOS.
This has the developers API keys built-in, so the connection to
external services work as expected.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
add wrapGAppsHook (back) to include gsettings.
Without, calibre dumps core because of missing
gsettings.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
- Use the cupswrapper file to have access to the printer settings with
CUPS
- Fix permission on the temporary settings file
The brother lpdwrapper uses a temporary file to convey the printer settings.
The original settings file will be copied with "400" permissions and the "brprintconflsr3"
binary cannot alter the temporary file later on. This fixes the permissions so the can be modified.
Since this is all in briefly in the temporary directory of systemd-cups and not accessible by others,
it shouldn't be a security concern.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Currently the only way to set the description for a submodule type is to
use `freeformType`. This is not ideal as it requires setting a
freeform type, and evaluates the submodule config unnecessarily.
Instead, add a `description` argument to `submoduleWith`.
Workaround build failure on -fno-common toolchains like upstream
gcc-10 or llvm-11. Otherwise build fails as:
duplicate symbol '_apple_platform' in:ui_cocoa.o cocoa_common.o
Main change is the fix for -fno-common toolchains.
Without the update build fails on upstream gcc-10 as:
ld: jack.o:src/jack.h:26: multiple definition of `driver_jack';
main.o:src/jack.h:26: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: vm/vm.a(cogit.o):spur64src/vm/cogitX64SysV.c:2552: multiple definition of
`traceStores'; vm/vm.a(gcc3x-cointerp.o):spur64src/vm/cogit.h:140: first defined here
* polychromatic: init at unstable-2020-03-10
use dev-1.0.0 branch
* polychromatic: use webkitgtk instead of webkit (package-list-no-aliases)
* polychromatic: use python3Packages.callPackage instead of callPackage
* polychromatic: add meta
* polychromatic: add usbutils to propagatedBuildInputs
polychromatic-tray-applet needs to be wrapped with lsusub from usbutils
* polychromatic: use pkgs.meson, not python3Packages.meson
* bump to 0.7.0
* rebase on master (python3.7 -> python3.9)
* ensure expression compiles at a minimum
* polychromatic: bump to 0.7.2; fix build
* 0.7.0 -> 0.7.2
* add `qtWrapperArgs` to `makeWrapperArgs`
* format with `nixpkgs-fmt`
* call `scripts/build-styles.sh` during `postPatch`
* patch `sassc` and `sass` references to point directly to binary from
`sassc` input
* polychromatic: remove `pkgconfig` from imports
* polychromatic: remove trailing whitespace
* polychromatic: 0.7.2 -> 0.7.3
* Apply various suggestions
* `xorg.libxcb` -> `libxcb`: `libxcb` can now be referenced directly
* Move various script patching functions from `postPatch` to
`preConfigure`
* `nativePropagatedBuildInputs` -> `propagatedNativeBuildInputs`
* Ensure expression is not modified by `nixpkgs-fmt`
* Apply recommended changes
* Move `nativeBuildInputs` before `propagatedNativeBuildInputs`
* Move all scripts but `scripts/build-styles.sh` back to `postPatch` phase
* Remove explicit `meson`, `wrapGAppsHook` imports from top-level
package attribute
Without the change build fails on upstream gcc-10 as:
ld: prefs.o:src/alarm-applet.h:49: multiple definition of
`app_command_map'; alarm-applet.o:src/alarm-applet.h:49: first defined here
the substituteInPlace didn't work for some reason, thus the deduced version became a negative one , i.e., -3.31 . Pulumi worked but then pulumi_aws was complaining that pulumi bounds were not respected.
I use sed as is done in pulumi/pulumi@d6a112c/sdk/python/Makefile#L31 to fix the issue. Now python3Packages.pulumi-aws accepts the version of pulumi and builds.
Between 4.1.1 and 4.2.0, the autconf-archive scripts
ax_prog_{cc,cxx}_for_build.m4 were updated to a newer version. This broke the
build (even native) on at least aarch64 and powerpc64le (but curiously not x86).
Adding this dependency allows the package to build again on these platforms.
In 5643714dea, I changed pkgs/stdenv/linux/make-bootstrap-tools.nix
to take a package set instead of system and localSystem arguments, but
I forgot to update make-bootstrap-tools-cross.nix.
Fixes: 5643714dea ("stdenvBootstrapTools: inherit {cross,local}System")
This has been deprecated for a long time, and it's doubtful it had any
users to start with. And having an undisablable warning when
enumarating platforms is not good.
Without the change build fails on upstream gcc-10 as:
ld: save-pass.o:src/qth-data.h:36: multiple definition of
`qth_data_type'; gtk-azel-plot.o:src/qth-data.h:36: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: plugin.o:(.bss+0x0): multiple definition of `stam'; panel.o:(.bss+0x20): first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ./libgclp.a(user_match.o):(.bss+0x18): multiple definition of
`tf'; ./libpre_gcl.a(main.o):(.bss+0x326d90): first defined here
and check for all required imports as per requirements.txt
While debugging missing metadata in the cloud-init boot local phase
in a NixOS VM on SmartOS, the following error was observed:
SystemError: Unable to open /dev/ttyS1
Adding the missing pyserial dependency fixes the above error and
cloud-init metadata detection now works in NixOS VMs on SmartOS
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ...-libprom-0.1.1/include/prom_collector_registry.h:37: multiple definition of
`PROM_COLLECTOR_REGISTRY_DEFAULT'; ...-libprom-0.1.1/include/prom_collector_registry.h:37: first defined here
Worked with the upstream project to get the test updated for modern
macOS and emulated/virtualized hardware.
Bring in unit test fixes in two patches from upstream trunk and
re-enable tests on Darwin.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: textdlg.o:(.bss+0x0): multiple definition of `someString';
configsettings.o:(.bss+0x0): first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: build/linux.release/alan3/Location.o:(.bss+0x0): multiple definition of
`logFile'; build/linux.release/alan3/act.o:(.bss+0x0): first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: libvars.a(vars-freeze-lex.o):src/libvars/vars-freeze-lex.l:23:
multiple definition of `line_number'; ifm-main.o:src/ifm-main.c:46: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: raima/startup.o:/build/cde-2.3.2/lib/DtSearch/raima/dbtype.h:408: multiple definition of
`__SK__'; raima/alloc.o:/build/cde-2.3.2/lib/DtSearch/raima/dbtype.h:408: first defined here
Without the change build fails on upstream gcc-10 as:
ld: stabs-trans.32.o:libedfmt/stabs-trans.c:28: multiple definition of
`buf'; dwarf2-trans.32.o:libedfmt/dwarf2-trans.c:22: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: dnd.o:src/main.h:136: multiple definition of
`MENU_EXT'; main.o:src/main.h:136: first defined here
Without the change builds fails on upstream -gcc-10 as:
ld: tools/usb/usbip/libsrc/vhci_driver.c:18: multiple definition of
`udev_context'; tools/usb/usbip/libsrc/usbip_host_common.c:38: first defined here
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: libpacklib.a(kedit.o):kuip/klink1.h:11: multiple definition of `klnkaddr';
libzftplib.a(zftpcdf.o):zftp/zftpcdf.c:155: first defined here
libgnome-keyring has been deprecated for a long time.
It has been superseded by libsecret, which allows access to not only
GNOME Keyring secret manager but any other service implementing
the Secret Service D-Bus API.
And libsecret is already in the dependencies so presumably it is supported.
This is unfortunately more complex than a simple version bump because
upstream has not released a dist tarball for this release. This commit
switches to using the github source and running autoreconf ourselves.
Along the way, stop randomly patching sources and Makefiles and instead
switch to upstreamable alternatives. The two (small) build system
patches have been sent upstream, see tuxera/ntfs-3g#39.
- New release fixing a nil dereference
- Remove patches that are already part of the new rel
- Rollback ldflags change from #175973
The -s flag implies -w on every platform but Darwin.
this commit passes the build dependencies to the
pgadmin nixos test for package and regression testing.
Also added changelog and some clarifying comments.
Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
@@ -379,12 +379,10 @@ See [this section][branch] to know when to use the release branches.
[staging]: #staging
The staging workflow exists to batch Hydra builds of many packages together.
It is coordinated in the [Staging room](https://matrix.to/#/#staging:nixos.org) on Matrix.
It works by directing commits that cause [mass rebuilds][mass-rebuild] to a separate `staging` branch that isn't directly built by Hydra.
Regularly, the `staging` branch is _manually_ merged into a `staging-next` branch to be built by Hydra using the [`nixpkgs:staging-next` jobset](https://hydra.nixos.org/jobset/nixpkgs/staging-next).
The `staging-next` branch should then only receive changes that fix Hydra builds;
**for anything else, ask the [Staging room](https://matrix.to/#/#staging:nixos.org) first**.
The `staging-next` branch should then only receive direct commits in order to fix Hydra builds.
Once it is verified that there are no major regressions, it is merged into `master` using [a pull request](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
This is done manually in order to ensure it's a good use of Hydra's computing resources.
By keeping the `staging-next` branch separate from `staging`, this batching does not block developers from merging changes into `staging`.
@@ -557,11 +555,138 @@ Names of files and directories should be in lowercase, with dashes between words
### Syntax
- Set up [editorconfig](https://editorconfig.org/) for your editor, such that [the settings](./.editorconfig) are automatically applied.
- Use 2 spaces of indentation per indentation level in Nix expressions, 4 spaces in shell scripts.
- Do not use tab characters, i.e. configure your editor to use soft tabs. For instance, use `(setq-default indent-tabs-mode nil)` in Emacs. Everybody has different tab settings so it’s asking for trouble.
- Use `lowerCamelCase` for variable names, not `UpperCamelCase`. Note, this rule does not apply to package attribute names, which instead follow the rules in [package naming](./pkgs/README.md#package-naming).
- New files must be formatted by entering the `nix-shell` from the repository root and running `nixfmt`.
- Function calls with attribute set arguments are written as
```nix
foo {
arg = <...>;
}
```
not
```nix
foo
{
arg = <...>;
}
```
Also fine is
```nix
foo { arg = <...>; }
```
if it's a short call.
- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
```nix
{
# A long list.
list = [
elem1
elem2
elem3
];
# A long attribute set.
attrs = {
attr1 = short_expr;
attr2 =
if true then big_expr else big_expr;
};
# Combined
listOfAttrs = [
{
attr1 = 3;
attr2 = "fff";
}
{
attr1 = 5;
attr2 = "ggg";
}
];
}
```
- Short lists or attribute sets can be written on one line:
```nix
{
# A short list.
list = [ elem1 elem2 elem3 ];
# A short set.
attrs = { x = 1280; y = 1024; };
}
```
- Breaking in the middle of a function argument can give hard-to-read code, like
```nix
someFunction { x = 1280;
y = 1024; } otherArg
yetAnotherArg
```
(especially if the argument is very large, spanning multiple lines).
Better:
```nix
someFunction
{ x = 1280; y = 1024; }
otherArg
yetAnotherArg
```
or
```nix
let res = { x = 1280; y = 1024; };
in someFunction res otherArg yetAnotherArg
```
- The bodies of functions, asserts, and withs are not indented to prevent a lot of superfluous indentation levels, i.e.
```nix
{ arg1, arg2 }:
assert system == "i686-linux";
stdenv.mkDerivation { /* ... */ }
```
not
```nix
{ arg1, arg2 }:
assert system == "i686-linux";
stdenv.mkDerivation { /* ... */ }
```
- Function formal arguments are written as:
```nix
{ arg1, arg2, arg3 }: { /* ... */ }
```
but if they don't fit on one line they're written as:
```nix
{ arg1, arg2, arg3
, arg4
# Some comment...
, argN
}: { }
```
- Functions should list their expected arguments as precisely as possible. That is, write
This directory contains files to support CI, such as [GitHub Actions](https://github.com/NixOS/nixpkgs/tree/master/.github/workflows) and [Ofborg](https://github.com/nixos/ofborg).
This is in contrast with [`maintainers/scripts`](`../maintainers/scripts`) which is for human use instead.
## Pinned Nixpkgs
CI may need certain packages from Nixpkgs.
In order to ensure that the needed packages are generally available without building,
[`pinned-nixpkgs.json`](./pinned-nixpkgs.json) contains a pinned Nixpkgs version tested by Hydra.
Run [`update-pinned-nixpkgs.sh`](./update-pinned-nixpkgs.sh) to update it.
@@ -185,19 +185,6 @@ Similarly, if you encounter errors similar to `Error_Protocol ("certificate has
_Default value:_`"gz"`.\
_Possible values:_`"none"`, `"gz"`, `"zstd"`.
`includeNixDB` (Boolean; _optional_)
: Populate the nix database in the image with the dependencies of `copyToRoot`.
The main purpose is to be able to use nix commands in the container.
:::{.caution}
Be careful since this doesn't work well in combination with `fromImage`. In particular, in a multi-layered image, only the Nix paths from the lower image will be in the database.
This also neglects to register the store paths that are pulled into the image as a dependency of one of the other values, but aren't a dependency of `copyToRoot`.
:::
_Default value:_`false`.
`contents`**DEPRECATED**
: This attribute is deprecated, and users are encouraged to use `copyToRoot` instead.
@@ -587,19 +574,6 @@ This allows the function to produce reproducible images.
_Default value:_`true`
`includeNixDB` (Boolean; _optional_)
: Populate the nix database in the image with the dependencies of `copyToRoot`.
The main purpose is to be able to use nix commands in the container.
:::{.caution}
Be careful since this doesn't work well in combination with `fromImage`. In particular, in a multi-layered image, only the Nix paths from the lower image will be in the database.
This also neglects to register the store paths that are pulled into the image as a dependency of one of the other values, but aren't a dependency of `copyToRoot`.
:::
_Default value:_`false`.
`passthru` (Attribute Set; _optional_)
: Use this to pass any attributes as [`passthru`](#chap-passthru) for the resulting derivation.
Runs files through `shellcheck`, a static analysis tool for shell scripts.
:::{.example #ex-shellcheck}
# Run `testers.shellcheck`
A single script
```nix
testers.shellcheck {
name = "shellcheck";
src = ./script.sh;
}
```
Multiple files
```nix
let
inherit (lib) fileset;
in
testers.shellcheck {
name = "shellcheck";
src = fileset.toSource {
root = ./.;
fileset = fileset.unions [
./lib.sh
./nixbsd-activate
];
};
}
```
:::
### Inputs {#tester-shellcheck-inputs}
[`src` (path or string)]{#tester-shellcheck-param-src}
: The path to the shell script(s) to check.
This can be a single file or a directory containing shell files.
All files in `src` will be checked, so you may want to provide `fileset`-based source instead of a whole directory.
### Return value {#tester-shellcheck-return}
A derivation that runs `shellcheck` on the given script(s).
The build will fail if `shellcheck` finds any issues.
## `testVersion` {#tester-testVersion}
Checks that the output from running a command contains the specified version string in it as a whole word.
NOTE: In most cases, [`versionCheckHook`](#versioncheckhook) should be preferred, but this function is provided and documented here anyway. The motivation for adding either tests would be:
- Catch dynamic linking errors and such and missing environment variables that should be added by wrapping.
- Probable protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
Although simplistic, this test assures that the main program can run.
While there's no substitute for a real test case, it does catch dynamic linking errors and such.
It also provides some protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
By default, the command to be run will be inferred from the given `package` attribute:
it will check `meta.mainProgram` first, and fall back to `pname` or `name`.
@@ -241,7 +241,7 @@ Write a text file to the Nix store.
`allowSubstitutes` (Bool, _optional_)
: Whether to allow substituting from a binary cache.
Passed through to [`allowSubstitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
Passed through to [`allowSubsitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
It defaults to `false`, as running the derivation's simple `builder` executable locally is assumed to be faster than network operations.
Set it to true if the `checkPhase` step is expensive.
@@ -4,7 +4,7 @@ This hook helps with installing manpages and shell completion files. It exposes
The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct `share/man/man<section>/` directory, in [`outputMan`](#outputman).
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh).
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
```nix
{
@@ -17,18 +17,6 @@ The `installShellCompletion` function takes one or more paths to shell completio
The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided (see below).
If the destination shell completion file is not actually present or consists of zero bytes after calling `installShellCompletion` this is treated as a build failure. In particular, if completion files are not vendored but are generated by running an executable, this is likely to fail in cross compilation scenarios. The result will be a zero byte completion file and hence a build failure. To prevent this, guard the completion commands against this, e.g.
This hook adds a `versionCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase) that runs the main program of the derivation with a `--help` or `--version` argument, and checks that the `${version}` string is found in that output. You use it like this:
```nix
{
lib,
stdenv,
versionCheckHook,
# ...
}:
stdenv.mkDerivation(finalAttrs:{
# ...
nativeInstallCheckInputs=[
versionCheckHook
];
doInstallCheck=true;
# ...
})
```
Note that for [`buildPythonPackage`](#buildpythonpackage-function) and [`buildPythonApplication`](#buildpythonapplication-function), `doInstallCheck` is enabled by default.
It does so in a clean environment (using `env --ignore-environment`), and it checks for the `${version}` string in both the `stdout` and the `stderr` of the command. It will report to you in the build log the output it received and it will fail the build if it failed to find `${version}`.
The variables that this phase control are:
-`dontVersionCheck`: Disable adding this hook to the [`preDistPhases`](#var-stdenv-preDist). Useful if you do want to load the bash functions of the hook, but run them differently.
-`versionCheckProgram`: The full path to the program that should print the `${version}` string. Defaults roughly to `${placeholder "out"}/bin/${pname}`. Using `$out` in the value of this variable won't work, as environment variables from this variable are not expanded by the hook. Hence using `placeholder` is unavoidable.
-`versionCheckProgramArg`: The argument that needs to be passed to `versionCheckProgram`. If undefined the hook tries first `--help` and then `--version`. Examples: `version`, `-V`, `-v`.
-`preVersionCheck`: A hook to run before the check is done.
-`postVersionCheck`: A hook to run after the check is done.
[OWASP](https://owasp.org/) [CycloneDX](https://cyclonedx.org/) is a Software [Bill of Materials](https://en.wikipedia.org/wiki/Bill_of_materials) (SBOM) standard.
The standards described here are for including Nix specific information within SBOMs in a way that is interoperable with external SBOM tooling.
The following tables describe namespaces for [properties](https://cyclonedx.org/docs/1.6/json/#components_items_properties) that may be attached to components within SBOMs.
Component properties are lists of name-value-pairs where values must be strings.
Properties with the same name may appear more than once.
Names and values are case-sensitive.
| Property | Description |
|------------------|-------------|
| `nix:store_path` | A Nix store path for the given component. This property should be contextualized by additional properties that describe the production of the store path, such as those from the `nix:narinfo:` and `nix:fod` namespaces. |
| Namespace | Description |
|---------------|-------------|
| [`nix:narinfo`](#sec-interop.cylonedx-narinfo) | Namespace for properties that are specific to how a component is stored as a [Nix archive](https://nixos.org/manual/nix/stable/glossary#gloss-nar) (NAR) in a [binary cache](https://nixos.org/manual/nix/stable/glossary#gloss-binary-cache). |
| [`nix:fod`](#sec-interop.cylonedx-fod) | Namespace for properties that describe a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation). |
### `nix:narinfo` {#sec-interop.cylonedx-narinfo}
Narinfo properties describe component archives that may be available from binary caches.
The `nix:narinfo` properties should be accompanied by a `nix:store_path` property within the same property list.
| Property | Description |
|---------------------------|-------------|
| `nix:narinfo:store_path` | Store path for the given store component. |
| `nix:narinfo:url` | URL path component. |
| `nix:narinfo:nar_hash` | Hash of the file system object part of the component when serialized as a Nix Archive. |
| `nix:narinfo:nar_size` | Size of the component when serialized as a Nix Archive. |
| `nix:narinfo:compression` | The compression format that component archive is in. |
| `nix:narinfo:file_hash` | A digest for the compressed component archive itself, as opposed to the data contained within. |
| `nix:narinfo:file_size` | The size of the compressed component archive itself. |
| `nix:narinfo:deriver` | The path to the derivation from which this component is produced. |
| `nix:narinfo:system` | The hardware and software platform on which this component is produced. |
| `nix:narinfo:sig` | Signatures claiming that this component is what it claims to be. |
| `nix:narinfo:ca` | Content address of this store object's file system object, used to compute its store path. |
| `nix:narinfo:references` | A whitespace separated array of store paths that this component references. |
### `nix:fod` {#sec-interop.cylonedx-fod}
FOD properties describe a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation).
The `nix:fod:method` property is required and must be accompanied by a `nix:store_path` property within the same property list.
All other properties in this namespace are method-specific.
To reproduce the build of a component the `nix:fod:method` value is resolved to an [appropriate function](#chap-pkgs-fetchers) within Nixpkgs whose arguments intersect with the given properties.
When generating `nix:fod` properties the method selected should be a stable function with a minimal number arguments.
For example, the `fetchFromGitHub` is commonly used within Nixpkgs but should be reduced to a call to the function by which it is implemented, `fetchzip`.
| Property | Description |
|------------------|-------------|
| `nix:fod:method` | Nixpkg function that produces this FOD. Required. Examples: `"fetchzip"`, `"fetchgit"` |
| `nix:fod:name` | Derivation name, present when method is `"fetchzip"` |
| `nix:fod:ref` | [Git ref](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefrefaref), present when method is `"fetchgit"` |
| `nix:fod:rev` | [Git rev](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefrevisionarevision), present when method is `"fetchgit"` |
| `nix:fod:sha256` | FOD hash |
| `nix:fod:url` | URL to fetch |
`nix:fod` properties may be extracted and evaluated to a derivation using code similar to the following, assuming a fictitious function `filterPropertiesToAttrs`:
@@ -98,13 +98,13 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
For more detail about managing the `deps.nix` file, see [Generating and updating NuGet dependencies](#generating-and-updating-nuget-dependencies)
:::
*`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 `buildInputs`.
*`buildInputs` 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 `buildInputs`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
*`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 `buildInputs` you would need to add:
To enable discovery through `projectReferences` you would need to add:
nugetDeps = ./deps.nix; # see "Generating and updating NuGet dependencies" section for details
# File generated with `nix-build -A package.passthru.fetch-deps`.
# To run fetch-deps when this file does not yet exist, set nugetDeps to null
nugetDeps = ./deps.nix;
buildInputs = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
dotnet-sdk = dotnetCorePackages.sdk_6_0;
dotnet-runtime = dotnetCorePackages.runtime_6_0;
@@ -194,7 +196,7 @@ This helper has the same arguments as `buildDotnetModule`, with a few difference
* `pname` and `version` are required, and will be used to find the NuGet package of the tool
* `nugetName` can be used to override the NuGet package name that will be downloaded, if it's different from `pname`
* `nugetHash` is the hash of the fetched NuGet package. `nugetSha256` is also supported, but not recommended. Set this to `lib.fakeHash` for the first build, and it will error out, giving you the proper hash. Also remember to update it during version updates (it will not error out if you just change the version while having a fetched package in `/nix/store`)
* `nugetSha256` is the hash of the fetched NuGet package. Set this to `lib.fakeHash256` for the first build, and it will error out, giving you the proper hash. Also remember to update it during version updates (it will not error out if you just change the version while having a fetched package in `/nix/store`)
* `dotnet-runtime` is set to `dotnet-sdk` by default. When changing this, remember that .NET tools fetched from NuGet require an SDK.
Here is an example of packaging `pbm`, an unfree binary without source available:
@@ -258,5 +254,6 @@ Finally, you move the `deps.nix` file to the appropriate location to be used by
If you ever need to update the dependencies of a package, you instead do
* `nix-build -A package.fetch-deps` to generate the update script for `package`
* Run `./result` to regenerate the lockfile to the path passed for `nugetDeps` (keep in mind if it can't be resolved to a local path, the script will write to `$1` or a temporary path instead)
* Finally, ensure the correct file was written and the derivation can be built.
* Run `./result deps.nix` to regenerate the lockfile to `deps.nix`, keep in mind if a location isn't provided, it will write to a temporary path instead
* Finally, move the file where needed and look at its contents to confirm it has updated the dependencies.
@@ -143,7 +143,7 @@ You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs`
## Updating GNOME packages {#ssec-gnome-updating}
Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is therefore possible to update to latest source tarball by running `nix-shell maintainers/scripts/update.nix --argstr package nautilus` or even en masse with `nix-shell maintainers/scripts/update.nix --argstr path gnome`. Read the package’s `NEWS` file to see what changed.
Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is therefore possible to update to latest source tarball by running `nix-shell maintainers/scripts/update.nix --argstr package gnome.nautilus` or even en masse with `nix-shell maintainers/scripts/update.nix --argstr path gnome`. Read the package’s `NEWS` file to see what changed.
@@ -66,25 +66,6 @@ The following is an example expression using `buildGoModule`:
The function `buildGoPackage` builds legacy Go programs, not supporting Go modules.
::: {.warning}
`buildGoPackage` is deprecated and will be removed for the 25.05 release.
:::
### Migrating from `buildGoPackage` to `buildGoModule` {#buildGoPackage-migration}
Go modules, released 6y ago, are now widely adopted in the ecosystem.
Most upstream projects are using Go modules, and the tooling previously used for dependency management in Go is mostly deprecated, archived or at least unmaintained at this point.
In case a project doesn't have external dependencies or dependencies are vendored in a way understood by `go mod init`, migration can be done with a few changes in the package.
- Switch the builder from `buildGoPackage` to `buildGoModule`
- Remove `goPackagePath` and other attributes specific to `buildGoPackage`
- Set `vendorHash = null;`
- Run `go mod init <module name>` in `postPatch`
In case the package has external dependencies that aren't vendored or the build setup is more complex the upstream source might need to be patched.
Examples for the migration can be found in the [issue tracking migration withing nixpkgs](https://github.com/NixOS/nixpkgs/issues/318069).
### Example for `buildGoPackage` {#example-for-buildgopackage}
In the following is an example expression using `buildGoPackage`, the following arguments are of special significance to the function:
@@ -21,14 +21,25 @@ Many “normal” user facing packages written in Haskell, like `niv` or `cachix
are also exposed at the top level, and there is nothing Haskell specific to
installing and using them.
All of these packages are originally defined in the `haskellPackages` package set.
The same packages are re-exposed with a reduced dependency closure for convenience (see `justStaticExecutables` or `separateBinOutput` below).
All of these packages are originally defined in the `haskellPackages` package
set and are re-exposed with a reduced dependency closure for convenience.
(see `justStaticExecutables` or `separateBinOutput` below)
:::{.note}
See [](#chap-language-support) for techniques to explore package sets.
:::
The `haskellPackages` set includes at least one version of every package from
Hackage as well as some manually injected packages. This amounts to a lot of
packages, so it is hidden from `nix-env -qa` by default for performance reasons.
You can still list all packages in the set like this:
The `haskellPackages` set includes at least one version of every package from [Hackage](https://hackage.haskell.org/) as well as some manually injected packages.
```console
$ nix-env -f '<nixpkgs>' -qaP -A haskellPackages
haskellPackages.a50 a50-0.5
haskellPackages.AAI AAI-0.2.0.1
haskellPackages.aasam aasam-0.2.0.0
haskellPackages.abacate abacate-0.0.0.0
haskellPackages.abc-puzzle abc-puzzle-0.2.1
…
```
Also, the `haskellPackages` set is included on [search.nixos.org].
The attribute names in `haskellPackages` always correspond with their name on
Hackage. Since Hackage allows names that are not valid Nix without escaping,
@@ -38,7 +49,8 @@ For packages that are part of [Stackage] (a curated set of known to be
compatible packages), we use the version prescribed by a Stackage snapshot
(usually the current LTS one) as the default version. For all other packages we
use the latest version from [Hackage](https://hackage.org) (the repository of
basically all open source Haskell packages). See [below](#haskell-available-versions) for a few more details on this.
basically all open source Haskell packages). See [below](#haskell-available-
versions) for a few more details on this.
Roughly half of the 16K packages contained in `haskellPackages` don’t actually
build and are [marked as broken semi-automatically](https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/configuration-hackage2nix/broken.yaml).
@@ -51,15 +63,68 @@ How you can help with that is
described in [Fixing a broken package](#haskell-fixing-a-broken-package).
-->
`haskellPackages` is built with our default compiler, but we also provide other releases of GHC and package sets built with them.
Available compilers are collected under `haskell.compiler`.
`haskellPackages` is built with our default compiler, but we also provide other
releases of GHC and package sets built with them. You can list all available
compilers like this:
Each of those compiler versions has a corresponding attribute set `packages` built with
The above uses the default value of `withSource = false` for the `idris2Api` but could be modified to include that library's source by passing `(idris2Api { withSource = true; })` to `idrisLibraries` instead. `idris2Api` in the above derivation comes built in with `idris2Packages`. This library exposes many of the otherwise internal APIs of the Idris2 compiler.
The above uses the default value of `withSource = false` for both of the two required Idris libraries that the `idris2-lsp` executable depends on. `idris2Api` in the above derivation comes built in with `idris2Packages`. This library exposes many of the otherwise internal APIs of the Idris2 compiler.
The [standard build environment](#chap-stdenv) makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of `stdenv`. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
Each supported language or software ecosystem has its own package set named `<language or ecosystem>Packages`, which can be explored in various ways:
- Search on [search.nixos.org](https://search.nixos.org/packages)
For example, search for [`haskellPackages`](https://search.nixos.org/packages?query=haskellPackages) or [`rubyPackages`](https://search.nixos.org/packages?query=rubyPackages).
- Navigate attribute sets with [`nix repl`](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-repl).
This technique is generally useful to inspect Nix language data structures.
:::{.example #example-navigte-nix-repl}
# Navigate Java compiler variants in `javaPackages` with `nix repl`
- List all derivations on the command line with [`nix-env --query`](https://nixos.org/manual/nix/stable/command-ref/nix-env/query).
`nix-env` is the only convenient way to do that, as it will skip attributes that fail [assertions](https://nixos.org/manual/nix/stable/language/constructs#assertions), such as when a package is [marked as broken](#var-meta-broken), rather than failing the entire evaluation.
:::{.example #example-list-haskellPackages}
# List all Python packages in Nixpkgs
The following command lists all [derivations names](https://nixos.org/manual/nix/stable/language/derivations#attr-name) with their attribute path from the latest Nixpkgs rolling release (`nixpkgs-unstable`).
```shell-session
$ nix-env -qaP -f '<nixpkgs>' -A pythonPackages -I nixpkgs=channel:nixpkgs-unstable
description = "Modern web UI for various torrent clients with a Node.js backend and React frontend";
description = "A modern web UI for various torrent clients with a Node.js backend and React frontend";
homepage = "https://flood.js.org";
license = lib.licenses.gpl3Only;
maintainers = with lib.maintainers; [ winter ];
@@ -233,7 +233,7 @@ If these are not defined, `npm pack` may miss some files, and no binaries will b
* `npmPruneFlags`: Flags to pass to `npm prune`. Defaults to the value of `npmInstallFlags`.
* `makeWrapperArgs`: Flags to pass to `makeWrapper`, added to executable calling the generated `.js` with `node` as an interpreter. These scripts are defined in `package.json`.
* `nodejs`: The `nodejs` package to build against, using the corresponding `npm` shipped with that version of `node`. Defaults to `pkgs.nodejs`.
* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace dependencies.
* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace depedencies.
@@ -375,74 +375,8 @@ Assuming the following directory structure, we can define `sourceRoot` and `pnpm
pnpmRoot = "frontend";
```
### Yarn {#javascript-yarn}
Yarn based projects use a `yarn.lock` file instead of a `package-lock.json` to pin dependencies. Nixpkgs provides the Nix function `fetchYarnDeps` which fetches an offline cache suitable for running `yarn install` before building the project. In addition, Nixpkgs provides the hooks:
- `yarnConfigHook`: Fetches the dependencies from the offline cache and installs them into `node_modules`.
- `yarnBuildHook`: Runs `yarn build` or a specified `yarn` command that builds the project.
Note that there is no setup hook for installing yarn based packages - `npmHooks.npmInstallHook` should fit most cases, but sometimes you may need to override the `installPhase` completely.
By default, `yarnConfigHook` relies upon the attribute `${yarnOfflineCache}` (or `${offlineCache}` if the former is not set) to find the location of the offline cache produced by `fetchYarnDeps`. To disable this phase, you can set `dontYarnInstallDeps = true` or override the `configurePhase`.
This script by default runs `yarn --offline build`, and it relies upon the project's dependencies installed at `node_modules`. Below is a list of additional `mkDerivation` arguments read by this hook:
- `yarnBuildScript`: Sets a different `yarn --offline` subcommand (defaults to `build`).
- `yarnBuildFlags`: Single string list of additional flags to pass the above command, or a Nix list of such additional flags.
### yarn2nix {#javascript-yarn2nix}
WARNING: The `yarn2nix` functions have been deprecated in favor of the new `yarnConfigHook` and `yarnBuildHook`. Documentation for them still appears here for the sake of the packages that still use them. See also a tracking issue [#324246](https://github.com/NixOS/nixpkgs/issues/324246).
@@ -88,7 +88,7 @@ For example, to propagate a dependency on SDL2 for lockfiles that select the Nim
}
```
The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlaid on the package being built.
The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlayed on the package being built.
- lockAttrs: the attrset for this library from within a lockfile. This can be used to implement library version constraints, such as marking libraries as broken or insecure.
- prevAttrs: the attrset produced by initial arguments to `buildNimPackage` and any preceding lockfile overlays.
@@ -214,7 +214,7 @@ Note: this is not possible anymore for Neovim.
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 [`nix-shell -p vimPluginsUpdater --run vim-plugins-updater`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/updater.nix). 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).
When the vim updater detects an nvim-treesitter update, it also runs [`nvim-treesitter/update.py $(nix-build -A vimPlugins.nvim-treesitter)`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py) to update the tree sitter grammars for `nvim-treesitter`.
After running the updater, if nvim-treesitter received an update, also run [`nvim-treesitter/update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py) to update the tree sitter grammars for `nvim-treesitter`.
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:
@@ -226,18 +226,18 @@ Some plugins require overrides in order to function properly. Overrides are plac
}
```
Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `nix-shell -p vimPluginsUpdater --run vim-plugins-updater` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
To add a new plugin, run `nix-shell -p vimPluginsUpdater --run 'vim-plugins-updater add "[owner]/[name]"'`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
To add a new plugin, run `./update.py add "[owner]/[name]"`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `vimPluginsUpdater` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of the Language Server Protocol integration with Vim/Neovim.
Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of the Language Server Protocol integration with Vim/Neovim.
## Updating plugins in nixpkgs {#updating-plugins-in-nixpkgs}
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).
```sh
nix-shell -p vimPluginsUpdater --run 'vim-plugins-updater --github-token=mytoken' # or set GITHUB_API_TOKEN environment variable
@@ -40,6 +40,20 @@ Use `programs.steam.enable = true;` if you want to add steam to `systemPackages`
have a look at [this pull request](https://github.com/NixOS/nixpkgs/pull/20269).
- **Java**
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:
```nix
steam.override { withJava = true; }
```
## 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 `vcpkg-tool` package has a wrapper around the `vcpkg` executable to avoid writing to the nix store.
The wrapper will also be present in `vcpkg`, unless you specify `vcpkg.override { vcpkg-tool = vcpkg-tool-unwrapped; }`
The wrapper has been made in a way so that it will provide default cli arguments, but tries not to interfere if the user provides the same arguments.
The arguments also have corresponding environment variables that can be used as an alternative way of overriding these paths.
Run the wrapper with the environment variable `NIX_VCPKG_DEBUG_PRINT_ENVVARS=true` to get a full list of corresponding environment variables.
## Nix specific environment variables {#sec-vcpkg-nix-envvars}
The wrapper also provides some new nix-specific environment variables that lets you control some of the wrapper functionality.
- `NIX_VCPKG_WRITABLE_PATH = <path>`
Set this environment variable to specify the path where `vcpkg` will store buildtime artifacts.
This will become the base path for all of the other paths.
- `NIX_VCPKG_DEBUG_PRINT_ENVVARS = true | false`
Set this to `true` for the wrapper to print the corresponding environment variables for the arguments that will be provided to the unwrapped executable.
The list of variables will be printed right before invoking `vcpkg`.
This can be useful if you suspect that the wrapper for some reason was unable to prioritize user-provided cli args over its default ones, or for fixing other issues like typos or unexpanded environment variables.
@@ -5,7 +5,7 @@ Nix packages can declare *meta-attributes* that contain information about a pack
```nix
{
meta = {
description = "Program that produces a familiar, friendly greeting";
description = "A program that produces a familiar, friendly greeting";
longDescription = ''
GNU Hello is a program that prints "Hello, world!" when you run it.
It is fully customizable.
@@ -22,10 +22,6 @@ Meta-attributes are not passed to the builder of the package. Thus, a change to
## Standard meta-attributes {#sec-standard-meta-attributes}
If the package is to be submitted to Nixpkgs, please check out the
[requirements for meta attributes](https://github.com/NixOS/nixpkgs/tree/master/pkgs#meta-attributes)
in the contributing documentation.
It is expected that each meta-attribute is one of the following:
### `description` {#var-meta-description}
@@ -33,21 +29,11 @@ It is expected that each meta-attribute is one of the following:
A short (one-line) description of the package.
This is displayed on [search.nixos.org](https://search.nixos.org/packages).
The general requirements of a description are:
- Be short, just one sentence.
- Be capitalized.
- Not start with definite ("The") or indefinite ("A"/"An") article.
- Not start with the package name.
- More generally, it should not refer to the package name.
- Not end with a period (or any punctuation for that matter).
- Provide factual information.
- Avoid subjective language.
Don’t include a period at the end. Don’t include newline characters. Capitalise the first character. For brevity, don’t repeat the name of package --- just describe what it does.
Wrong: `"libpng is a library that allows you to decode PNG images."`
Right: `"Library for decoding PNG images"`
Right: `"A library for decoding PNG images"`
### `longDescription` {#var-meta-longDescription}
@@ -81,12 +67,6 @@ The license, or licenses, for the package. One from the attribute set defined in
A list containing the type or types of source inputs from which the package is built, e.g. original source code, pre-built binaries, etc.
For details, see [Source provenance](#sec-meta-sourceProvenance).
### `maintainers` {#var-meta-maintainers}
A list of the maintainers of this Nix expression. Maintainers are defined in [`nixpkgs/maintainers/maintainer-list.nix`](https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix). There is no restriction to becoming a maintainer, just add yourself to that list in a separate commit titled “maintainers: add alice” in the same pull request, and reference maintainers with `maintainers = with lib.maintainers; [ alice bob ]`.
Besides tests provided by upstream, that you run in the [`checkPhase`](#ssec-check-phase), you may want to define tests derivations in the `passthru.tests` attribute, which won't change the build. `passthru.tests` have several advantages over running tests during any of the [standard phases](#sec-stdenv-phases):
Tests that are part of the source package, if they run quickly, are typically executed in the [`installCheckPhase`](#var-stdenv-phases).
This phase is also suitable for performing a `--version` test for packages that support such flag.
Most programs distributed by Nixpkgs support such a `--version` flag, and successfully calling the program with that flag indicates that the package at least got compiled properly.
- They access the package as consumers would, independently from the environment in which it was built
- They can be run and debugged without rebuilding the package, which is useful if that takes a long time
- They don't add overhead to each build, as opposed checks added to the [`distPhase`](#ssec-distribution-phase), such as [`versionCheckHook`](#versioncheckhook).
It is also possible to use `passthru.tests` to test the version with [`testVersion`](#tester-testVersion), but since that is pretty trivial and recommended thing to do, we recommend using [`versionCheckHook`](#versioncheckhook) for that, which has the following advantages over `passthru.tests`:
## Checking builds with `installCheckPhase`
- If the `versionCheckPhase` (the phase defined by [`versionCheckHook`](#versioncheckhook)) fails, it triggers a failure which can't be ignored if you use the package, or if you find out about it in a [`nixpkgs-review`](https://github.com/Mic92/nixpkgs-review) report.
- Sometimes packages become silently broken - meaning they fail to launch but their build passes because they don't perform any tests in the `checkPhase`. If you use this tool infrequently, such a silent breakage may rot in your system / profile configuration, and you will not notice the failure until you will want to use this package. Testing such basic functionality ensures you have to deal with the failure when you update your system / profile.
- When you open a PR, [ofborg](https://github.com/NixOS/ofborg)'s CI _will_ run `passthru.tests` of [packages that are directly changed by your PR (according to your commits' messages)](https://github.com/NixOS/ofborg?tab=readme-ov-file#automatic-building), but if you'd want to use the [`@ofborg build`](https://github.com/NixOS/ofborg?tab=readme-ov-file#build) command for dependent packages, you won't have to specify in addition the `.tests` attribute of the packages you want to build, and no body will be able to avoid these tests.
When building `git`, a rudimentary test for successful compilation would be running `git --version`:
```nix
stdenv.mkDerivation (finalAttrs: {
pname = "git";
version = "1.2.3";
# ...
doInstallCheck = true;
installCheckPhase = ''
runHook preInstallCheck
echo checking if 'git --version' mentions ${finalAttrs.version}
However, tests that are non-trivial will better fit into `passthru.tests` because they:
- Access the package as consumers would, independently from the environment in which it was built
- Can be run and debugged without rebuilding the package, which is useful if that takes a long time
- Don't add overhad to each build, as opposed to `installCheckPhase`
It is also possible to use `passthru.tests` to test the version with [`testVersion`](#tester-testVersion).
<!-- NOTE(@fricklerhandwerk): one may argue whether that testing guide should rather be in the user's manual -->
For more on how to write and run package tests for Nixpkgs, see the [testing section in the package contributor guide](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests).
@@ -762,8 +762,6 @@ Before and after running `make`, the hooks `preBuild` and `postBuild` are called
The check phase checks whether the package was built correctly by running its test suite. The default `checkPhase` calls `make $checkTarget`, but only if the [`doCheck` variable](#var-stdenv-doCheck) is enabled.
It is highly recommended, for packages' sources that are not distributed with any tests, to at least use [`versionCheckHook`](#versioncheckhook) to test that the resulting executable is basically functional.
#### Variables controlling the check phase {#variables-controlling-the-check-phase}
##### `doCheck` {#var-stdenv-doCheck}
@@ -1517,43 +1515,29 @@ This flag can break dynamic shared object loading. For instance, the module syst
intel_drv.so: undefined symbol: vgaHWFreeHWRec
```
#### `zerocallusedregs` {#zerocallusedregs}
Adds the `-fzero-call-used-regs=used-gpr` compiler option. This causes the general-purpose registers that an architecture's calling convention considers "call-used" to be zeroed on return from the function. This can make it harder for attackers to construct useful ROP gadgets and also reduces the chance of data leakage from a function call.
### Hardening flags disabled by default {#sec-hardening-flags-disabled-by-default}
The following flags are disabled by default and should be enabled with `hardeningEnable` for packages that take untrusted input like network services.
#### `pie` {#pie}
This flag is disabled by default for normal `glibc` based NixOS package builds, but enabled by default for
- `musl`-based package builds, except on Aarch64 and Aarch32, where there are issues.
- Statically-linked for OpenBSD builds, where it appears to be required to get a working binary.
This flag is disabled by default for normal `glibc` based NixOS package builds, but enabled by default for`musl` based package builds.
Adds the `-fPIE` compiler and `-pie` linker options. Position Independent Executables are needed to take advantage of Address Space Layout Randomization, supported by modern kernel versions. While ASLR can already be enforced for data areas in the stack and heap (brk and mmap), the code areas must be compiled as position-independent. Shared libraries already do this with the `pic` flag, so they gain ASLR automatically, but binary .text regions need to be build with `pie` to gain ASLR. When this happens, ROP attacks are much harder since there are no static locations to bounce off of during a memory corruption attack.
Static libraries need to be compiled with `-fPIE` so that executables can link them in with the `-pie` linker option.
If the libraries lack `-fPIE`, you will get the error `recompile with -fPIE`.
#### `zerocallusedregs` {#zerocallusedregs}
Adds the `-fzero-call-used-regs=used-gpr` compiler option. This causes the general-purpose registers that an architecture's calling convention considers "call-used" to be zeroed on return from the function. This can make it harder for attackers to construct useful ROP gadgets and also reduces the chance of data leakage from a function call.
#### `trivialautovarinit` {#trivialautovarinit}
Adds the `-ftrivial-auto-var-init=pattern` compiler option. This causes "trivially-initializable" uninitialized stack variables to be forcibly initialized with a nonzero value that is likely to cause a crash (and therefore be noticed). Uninitialized variables generally take on their values based on fragments of previous program state, and attackers can carefully manipulate that state to craft malicious initial values for these variables.
Use of this flag is controversial as it can prevent tools that detect uninitialized variable use (such as valgrind) from operating correctly.
This should be turned off or fixed for build errors such as:
```
sorry, unimplemented: __builtin_clear_padding not supported for variable length aggregates
This flag adds the `-fstack-clash-protection` compiler option, which causes growth of a program's stack to access each successive page in order. This should force the guard page to be accessed and cause an attempt to "jump over" this guard page to crash.
[^footnote-stdenv-ignored-build-platform]: The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency: As a general programming principle, dependencies are always *specified* as interfaces, not concrete implementation.
[^footnote-stdenv-native-dependencies-in-path]: Currently, this means for native builds all dependencies are put on the `PATH`. But in the future that may not be the case for sake of matching cross: the platforms would be assumed to be unique for native and cross builds alike, so only the `depsBuild*` and `nativeBuildInputs` would be added to the `PATH`.
[^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like [setup hooks](#ssec-setup-hooks) also are run as if it were a propagated dependency.
@@ -236,7 +236,7 @@ File sets cannot add single files to the store, they can only import files under
Arguments:
- (+) There's no point in using this library for a single file, since you can't do anything other than add it to the store or not.
And it would be unclear how the library should behave if the one file wouldn't be added to the store:
`toSource { root = ./file.nix; fileset = <empty>; }` has no reasonable result because returning an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean.
`toSource { root = ./file.nix; fileset = <empty>; }` has no reasonable result because returing an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean.
# Extended explanation: That's because a finalized configuration is more than just a set of modules. For instance, it has its own `specialArgs` that, by the nature of `specialArgs` can't be loaded through `imports` or the the `modules` argument. So instead, we have to ask you to extract the relevant modules and use those instead. This way, we keep the module system comparatively simple, and hopefully avoid a bad surprise down the line.
# We currently throw this error already in `config`, but throwing in `config.wrong1` would be acceptable.
checkConfigError 'It seems as if you.re trying to declare an option by placing it into .config. rather than .options.' config.wrong1 ./error-mkOption-in-config.nix
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.
gador
kilianar