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>
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.
Checks that the output from running a command contains the specified version string in it as a whole word.
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:
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.
- Catch dynamic linking errors and such and missing environment variables that should be added by wrapping.
It also provides some protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
- Probable 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:
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`.
it will check `meta.mainProgram` first, and fall back to `pname` or `name`.
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.
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;
projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
@@ -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
* `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`
* `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.
* `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:
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
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`
* `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)
* 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, ensure the correct file was written and the derivation can be built.
* 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}
## 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.
@@ -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
are also exposed at the top level, and there is nothing Haskell specific to
installing and using them.
installing and using them.
All of these packages are originally defined in the `haskellPackages` package set.
All of these packages are originally defined in the `haskellPackages` package
The same packages are re-exposed with a reduced dependency closure for convenience (see `justStaticExecutables` or `separateBinOutput` below).
set and are re-exposed with a reduced dependency closure for convenience.
(see `justStaticExecutables` or `separateBinOutput` below)
:::{.note}
The `haskellPackages` set includes at least one version of every package from
See [](#chap-language-support) for techniques to explore package sets.
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
The attribute names in `haskellPackages` always correspond with their name on
Hackage. Since Hackage allows names that are not valid Nix without escaping,
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
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
(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
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
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).
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).
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.
`haskellPackages` is built with our default compiler, but we also provide other
Available compilers are collected under `haskell.compiler`.
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.
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
@@ -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).
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:
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:
@@ -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).
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}
## 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` package and run the game with:
@@ -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}
## 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:
It is expected that each meta-attribute is one of the following:
### `description` {#var-meta-description}
### `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.
A short (one-line) description of the package.
This is displayed on [search.nixos.org](https://search.nixos.org/packages).
This is displayed on [search.nixos.org](https://search.nixos.org/packages).
The general requirements of a description are:
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.
- 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.
Wrong: `"libpng is a library that allows you to decode PNG images."`
Wrong: `"libpng is a library that allows you to decode PNG images."`
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.
When building `git`, a rudimentary test for successful compilation would be running `git --version`:
- 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.
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 -->
<!-- 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).
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.
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}
#### Variables controlling the check phase {#variables-controlling-the-check-phase}
##### `doCheck` {#var-stdenv-doCheck}
##### `doCheck` {#var-stdenv-doCheck}
@@ -1517,10 +1515,6 @@ This flag can break dynamic shared object loading. For instance, the module syst
intel_drv.so: undefined symbol: vgaHWFreeHWRec
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}
### 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.
The following flags are disabled by default and should be enabled with `hardeningEnable` for packages that take untrusted input like network services.
@@ -1534,22 +1528,16 @@ Adds the `-fPIE` compiler and `-pie` linker options. Position Independent Execut
Static libraries need to be compiled with `-fPIE` so that executables can link them in with the `-pie` linker option.
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`.
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}
#### `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.
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.
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-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-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.
[^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.
# 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.
# 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.
# 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
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
@@ -225,19 +225,6 @@ The pre-existing [services.ankisyncd](#opt-services.ankisyncd.enable) has been m
- `appimageTools.wrapAppImage` now creates the binary at `$out/bin/${pname}` rather than `$out/bin/${pname}-${version}`, which will break downstream workarounds.
- `appimageTools.wrapAppImage` now creates the binary at `$out/bin/${pname}` rather than `$out/bin/${pname}-${version}`, which will break downstream workarounds.
- `apptainer` and `singularity` now prioritize system-wide `PATH` over those constructed from dependent packages when searching for third-party utilities. The `PATH` to search for third-party utilities, known as `defaultPath` inside Apptainer/Singularity source code, is now constructed from the following sources, ordered by their precedence:
- `systemBinPaths`, a new argument introduced to specify system-wide `"/**/bin"` directories.
- The FHS `defaultPath` value set by Apptainer/Singularity developers, making Apptainer/Singularity work out of the box in FHS systems.
- `defaultPathInputs`, a list of packages to form the fall-back `PATH`.
This change is required to enable Sylabs SingularityCE (`singularity`) to run images, as it requires a `fusermount3` commant with the SUID bit set.
`newuidmapPath` and `newgidmapPath` arguments are deprecated in favour of `systemBinPaths`. Their support will be removed in future releases.
`programs.singularity.systemBinPaths` option is introduced to specify the `systemBinPaths` argument of the overridden package. It includes `"/run/wrappers/bin"` even if specified empty.
`programs.singularity.enableFakeroot` option is deprecated and has no effect. `--fakeroot` support is now always enabled as long as `programs.singularity.systemBinPaths` is not forcefully overridden.
- `azure-cli` now has extension support. For example, to install the `aks-preview` extension, use
- `azure-cli` now has extension support. For example, to install the `aks-preview` extension, use
- [AMDVLK](https://github.com/GPUOpen-Drivers/AMDVLK), AMD's open source Vulkan driver, is now available to be configured as `hardware.amdgpu.amdvlk` option.
- [AMDVLK](https://github.com/GPUOpen-Drivers/AMDVLK), AMD's open source Vulkan driver, is now available to be configured as `hardware.amdgpu.amdvlk` option.
This also allows configuring runtime settings of AMDVLK and enabling experimental features.
This also allows configuring runtime settings of AMDVLK and enabling experimental features.
- The `moonlight-qt` package ([Moonlight game streaming](https://moonlight-stream.org/)) now has HDR support on Linux systems.
## New Services {#sec-release-24.11-new-services}
## New Services {#sec-release-24.11-new-services}
@@ -20,26 +19,12 @@
- [Flood](https://flood.js.org/), a beautiful WebUI for various torrent clients. Available as [services.flood](options.html#opt-services.flood).
- [Flood](https://flood.js.org/), a beautiful WebUI for various torrent clients. Available as [services.flood](options.html#opt-services.flood).
- [Eintopf](https://eintopf.info), community event and calendar web application. Available as [services.eintopf](options.html#opt-services.eintopf).
- [Renovate](https://github.com/renovatebot/renovate), a dependency updating tool for various git forges and language ecosystems. Available as [services.renovate](#opt-services.renovate.enable).
- [Renovate](https://github.com/renovatebot/renovate), a dependency updating tool for various git forges and language ecosystems. Available as [services.renovate](#opt-services.renovate.enable).
- [wg-access-server](https://github.com/freifunkMUC/wg-access-server/), an all-in-one WireGuard VPN solution with a web ui for connecting devices. Available at [services.wg-access-server](#opt-services.wg-access-server.enable).
- [Envision](https://gitlab.com/gabmus/envision), a UI for building, configuring and running Monado, the open source OpenXR runtime. Available as [programs.envision](#opt-programs.envision.enable).
- [Playerctld](https://github.com/altdesktop/playerctl), a daemon to track media player activity. Available as [services.playerctld](option.html#opt-services.playerctld).
- `transmission` package has been aliased with a `trace` warning to `transmission_3`. Since [Transmission 4 has been released last year](https://github.com/transmission/transmission/releases/tag/4.0.0), and Transmission 3 will eventually go away, it was decided perform this warning alias to make people aware of the new version. The `services.transmission.package` defaults to `transmission_3` as well because the upgrade can cause data loss in certain specific usage patterns (examples: [#5153](https://github.com/transmission/transmission/issues/5153), [#6796](https://github.com/transmission/transmission/issues/6796)). Please make sure to back up to your data directory per your usage:
- `transmission-gtk`: `~/.config/transmission`
- `transmission-daemon` using NixOS module: `${config.services.transmission.home}/.config/transmission-daemon` (defaults to `/var/lib/transmission/.config/transmission-daemon`)
- `androidenv.androidPkgs_9_0` has been removed, and replaced with `androidenv.androidPkgs` for a more complete Android SDK including support for Android 9 and later.
- `androidenv.androidPkgs_9_0` has been removed, and replaced with `androidenv.androidPkgs` for a more complete Android SDK including support for Android 9 and later.
- `grafana` has been updated to version 11.1. This version doesn't support setting `http_addr` to a hostname anymore, an IP address is expected.
- `wstunnel` has had a major version upgrade that entailed rewriting the program in Rust.
- `wstunnel` has had a major version upgrade that entailed rewriting the program in Rust.
The module was updated to accommodate for breaking changes.
The module was updated to accommodate for breaking changes.
Breaking changes to the module API were minimised as much as possible,
Breaking changes to the module API were minimised as much as possible,
@@ -50,41 +35,15 @@
Also be aware that if you have set additional options in `services.wstunnel.{clients,servers}.<name>.extraArgs`,
Also be aware that if you have set additional options in `services.wstunnel.{clients,servers}.<name>.extraArgs`,
that those might have been removed or modified upstream.
that those might have been removed or modified upstream.
- `clang-tools_<version>` packages have been moved into `llvmPackages_<version>` (i.e. `clang-tools_18` is now `llvmPackages_18.clang-tools`).
- For convenience, the top-level `clang-tools` attribute remains and is now bound to `llvmPackages.clang-tools`.
- Top-level `clang_tools_<version>` attributes are now aliases; these will be removed in a future release.
- `buildbot` was updated to 4.0, the AngularJS frontend has been replaced by a React frontend, see the [upstream release notes](https://docs.buildbot.net/current/manual/upgrading/4.0-upgrade.html).
- `nginx` package no longer includes `gd` and `geoip` dependencies. For enabling it, override `nginx` package with the optionals `withImageFilter` and `withGeoIP`.
- `nginx` package no longer includes `gd` and `geoip` dependencies. For enabling it, override `nginx` package with the optionals `withImageFilter` and `withGeoIP`.
- `openssh` and `openssh_hpn` are now compiled without Kerberos 5 / GSSAPI support in an effort to reduce the attack surface of the components for the majority of users. Users needing this support can
- `openssh` and `openssh_hpn` are now compiled without Kerberos 5 / GSSAPI support in an effort to reduce the attack surface of the components for the majority of users. Users needing this support can
use the new `opensshWithKerberos` and `openssh_hpnWithKerberos` flavors (e.g. `programs.ssh.package = pkgs.openssh_gssapi`).
use the new `opensshWithKerberos` and `openssh_hpnWithKerberos` flavors (e.g. `programs.ssh.package = pkgs.openssh_gssapi`).
- `security.ipa.ipaHostname` now defaults to the value of `networking.fqdn` if
it is set, instead of the previous hardcoded default of
`${networking.hostName}.${security.ipa.domain}`.
- The fcgiwrap module now allows multiple instances running as distinct users.
The option `services.fgciwrap` now takes an attribute set of the
configuration of each individual instance.
This requires migrating any previous configuration keys from
`services.fcgiwrap.*` to `services.fcgiwrap.some-instance.*`.
The ownership and mode of the UNIX sockets created by this service are now
configurable and private by default.
Processes also now run as a dynamically allocated user by default instead of
root.
- `services.cgit` now runs as the cgit user by default instead of root.
This change requires granting access to the repositories to this user or
setting the appropriate one through `services.cgit.some-instance.user`.
- `nvimpager` was updated to version 0.13.0, which changes the order of user and
- `nvimpager` was updated to version 0.13.0, which changes the order of user and
nvimpager settings: user commands in `-c` and `--cmd` now override the
nvimpager settings: user commands in `-c` and `--cmd` now override the
respective default settings because they are executed later.
respective default settings because they are executed later.
- `pkgs.nextcloud27` has been removed since it's EOL.
- `services.forgejo.mailerPasswordFile` has been deprecated by the drop-in replacement `services.forgejo.secrets.mailer.PASSWD`,
- `services.forgejo.mailerPasswordFile` has been deprecated by the drop-in replacement `services.forgejo.secrets.mailer.PASSWD`,
which is part of the new free-form `services.forgejo.secrets` option.
which is part of the new free-form `services.forgejo.secrets` option.
`services.forgejo.secrets` is a small wrapper over systemd's `LoadCredential=`. It has the same structure (sections/keys) as
`services.forgejo.secrets` is a small wrapper over systemd's `LoadCredential=`. It has the same structure (sections/keys) as
@@ -92,10 +51,6 @@
- `services.ddclient.use` has been deprecated: `ddclient` now supports separate IPv4 and IPv6 configuration. Use `services.ddclient.usev4` and `services.ddclient.usev6` instead.
- `services.ddclient.use` has been deprecated: `ddclient` now supports separate IPv4 and IPv6 configuration. Use `services.ddclient.usev4` and `services.ddclient.usev6` instead.
- `teleport` has been upgraded from major version 15 to major version 16.
Refer to upstream [upgrade instructions](https://goteleport.com/docs/management/operations/upgrading/)
and [release notes for v16](https://goteleport.com/docs/changelog/#1600-061324).
- `vaultwarden` lost the capability to bind to privileged ports. If you rely on
- `vaultwarden` lost the capability to bind to privileged ports. If you rely on
this behavior, override the systemd unit to allow `CAP_NET_BIND_SERVICE` in
this behavior, override the systemd unit to allow `CAP_NET_BIND_SERVICE` in
your local configuration.
your local configuration.
@@ -108,14 +63,6 @@
before changing the package to `pkgs.stalwart-mail` in
before changing the package to `pkgs.stalwart-mail` in
and `nodePackages.vscode-json-languageserver-bin` were dropped due to an unmaintained upstream.
The `vscode-langservers-extracted` package is a maintained drop-in replacement.
- `haskell.lib.compose.justStaticExecutables` now disallows references to GHC in the
- `haskell.lib.compose.justStaticExecutables` now disallows references to GHC in the
output by default, to alert users to closure size issues caused by
output by default, to alert users to closure size issues caused by
[#164630](https://github.com/NixOS/nixpkgs/issues/164630). See ["Packaging
[#164630](https://github.com/NixOS/nixpkgs/issues/164630). See ["Packaging
@@ -124,37 +71,10 @@
for information on working around `output '...' is not allowed to refer to
for information on working around `output '...' is not allowed to refer to
the following paths` errors caused by this change.
the following paths` errors caused by this change.
- The `stalwart-mail` service now runs under the `stalwart-mail` system user
instead of a dynamically created one via `DynamicUser`, to avoid automatic
ownership changes on its large file store each time the service was started.
This change requires to manually move the state directory from
`/var/lib/private/stalwart-mail` to `/var/lib/stalwart-mail` and to
change the ownership of the directory and its content to `stalwart-mail`.
- The `stalwart-mail` module now uses RocksDB as the default storage backend
- The `stalwart-mail` module now uses RocksDB as the default storage backend
for `stateVersion` ≥ 24.11. (It was previously using SQLite for structured
for `stateVersion` ≥ 24.11. (It was previously using SQLite for structured
data and the filesystem for blobs).
data and the filesystem for blobs).
- The `shiori` service now requires an HTTP secret value `SHIORI_HTTP_SECRET_KEY` to be provided via environment variable. The nixos module therefore, now provides an environmentFile option:
```
# This is how a environment file can be generated:
- `libe57format` has been updated to `>= 3.0.0`, which contains some backward-incompatible API changes. See the [release note](https://github.com/asmaloney/libE57Format/releases/tag/v3.0.0) for more details.
- `gitlab` deprecated support for *runner registration tokens* in GitLab 16.0, disabled their support in GitLab 17.0 and will
ultimately remove it in GitLab 18.0, as outlined in the
After upgrading to GitLab >= 17.0, it is possible to re-enable support for registration tokens in the UI until GitLab 18.0.
Refer to the manual on [using registration tokens after GitLab 17.0](https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#using-registration-tokens-after-gitlab-170).
GitLab administrators should migrate to the [new runner registration workflow](https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#using-registration-tokens-after-gitlab-170)
with *runner authentication tokens* until the release of GitLab 18.0.
- `gitlab` has been updated from 16.x to 17.x and requires at least `postgresql` 14.9, as stated in the [documentation](https://docs.gitlab.com/17.1/ee/install/requirements.html#postgresql-requirements). Check the [upgrade guide](#module-services-postgres-upgrading) in the NixOS manual on how to upgrade your PostgreSQL installation.
- `zx` was updated to v8, which introduces several breaking changes.
- `zx` was updated to v8, which introduces several breaking changes.
See the [v8 changelog](https://github.com/google/zx/releases/tag/8.0.0) for more information.
See the [v8 changelog](https://github.com/google/zx/releases/tag/8.0.0) for more information.
- The default value of `services.kubernetes.kubelet.hostname` is now lowercased.
Explicitly set `kubelet.hostname` to `networking.fqdnOrHostName` to get back
the old default behavior.
- `keycloak` was updated to version 25, which introduces new hostname related options.
See [Upgrading Guide](https://www.keycloak.org/docs/25.0.1/upgrading/#migrating-to-25-0-0) for instructions.
- The `tracy` package no longer works on X11, since it's moved to Wayland
- The `tracy` package no longer works on X11, since it's moved to Wayland
support, which is the intended default behavior by Tracy maintainers.
support, which is the intended default behavior by Tracy maintainers.
X11 users have to switch to the new package `tracy-x11`.
X11 users have to switch to the new package `tracy-x11`.
- The `services.prometheus.exporters.minio` option has been removed, as it's upstream implementation was broken and unmaintained.
Minio now has built-in [Prometheus metrics exposure](https://min.io/docs/minio/linux/operations/monitoring/collect-minio-metrics-using-prometheus.html), which can be used instead.
- The `services.patroni.raft` option has been removed, as Raft has been [deprecated by upstream since 3.0.0](https://github.com/patroni/patroni/blob/master/docs/releases.rst#version-300)
- `services.roundcube.maxAttachmentSize` will multiply the value set with `1.37` to offset overhead introduced by the base64 encoding applied to attachments.
## Other Notable Changes {#sec-release-24.11-notable-changes}
## Other Notable Changes {#sec-release-24.11-notable-changes}
<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
- The `zerocallusedregs` hardening flag is enabled by default on compilers that support it.
- The `stackclashprotection` hardening flag has been added, though disabled by default.
- `hareHook` has been added as the language framework for Hare. From now on, it,
- `hareHook` has been added as the language framework for Hare. From now on, it,
not the `hare` package, should be added to `nativeBuildInputs` when building
not the `hare` package, should be added to `nativeBuildInputs` when building
Hare programs.
Hare programs.
- [`lib.options.mkPackageOptionMD`](https://nixos.org/manual/nixpkgs/unstable#function-library-lib.options.mkPackageOptionMD) is now obsolete; use the identical [`lib.options.mkPackageOption`](https://nixos.org/manual/nixpkgs/unstable#function-library-lib.options.mkPackageOption) instead.
- To facilitate dependency injection, the `imgui` package now builds a static archive using vcpkg' CMake rules.
- To facilitate dependency injection, the `imgui` package now builds a static archive using vcpkg' CMake rules.
The derivation now installs "impl" headers selectively instead of by a wildcard.
The derivation now installs "impl" headers selectively instead of by a wildcard.
Use `imgui.src` if you just want to access the unpacked sources.
Use `imgui.src` if you just want to access the unpacked sources.
- `security.pam.u2f` now follows RFC42.
All module options are now settable through the freeform `.settings`.
- Cinnamon has been updated to 6.2.
- Following Mint 22 defaults, the Cinnamon module no longer ships geary and hexchat by default.
- Nemo is now built with gtk-layer-shell support, note that for now it will be expected to see nemo-desktop
listed as a regular entry in Cinnamon Wayland session's window list applet.
- Support for *runner registration tokens* has been [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/380872)
in `gitlab-runner` 15.6 and is expected to be removed in `gitlab-runner` 18.0. Configuration of existing runners
should be changed to using *runner authentication tokens* by configuring
{option}`services.gitlab-runner.services.<name>.authenticationTokenConfigFile` instead of the former
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