Will be replaced with a -bin build, which becomes necessary due to
upstream becoming unfeasible to build from source starting with the 12.x
release line.
An appropriate `throw` is also added, to advise users to upgrade to the
new -bin variant.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
This affects haskelPackages.mkDerivation, ghcWithPackages and
hoogleWithPackages which means that it is not possible to re-introduce
a ghcjs derivation downstream and create a ghcjs package set with an up
to date Nixpkgs.
This package depends on a 14-year-old version of http-parser, which has
numerous security issues. The upstream also hasn't been updated in
several years, so this is a security issue to keep around.
This reduces the filtering and renaming of airgap images archives to
make the update script and builder more resilient to upstream changes.
Additionally, it reduces the code of the k3s builder.
Bluetooth support is now built into the default build. The X11 support is
realized outside the Python interpreter by including the tkinter module
from the package set.
It has been EOL for several years now, and the last dependant(couchdb3)
no longer requires it as of #436932.
I've also removed all conditionals in the common.nix build file that
were for versions older than 115, since we no longer ship any versions
older than that. I would like to remove 115 and 128 soon as well, since
as of commit, they reach end of life in 3 weeks(in fact, 115 is EOL for
all platforms we support afaik)
ROCm packages are a runtime only dep for triton. triton-llvm always supports AMD GPU targets,
so we can reduce how many different builds of triton are needed by teaching triton to better search
for libamdhip64.so and ld.lld.
This is the latest major version of ffmpeg, codenamed "Huffman".
The feature flags added are one for Whisper filter support via
whisper-cpp, and APV encoding support via OpenAPV(which needed to be
packaged)
Further, the withPostproc feature flag is restricted to before version
8.0, as it was removed.
Currently, nasm is the only supported assembler on 8.0+, so we use that.
in order to not cause a mass rebuild, we don't change the assembler for
older builds, even though nasm has been supported since 3.4.
Explicitly provide a default value for the argument `enabledTestPaths`
as the current working directory (`enabledTestPaths = [ "." ]`)
to simplify overriding (making `enabledTestPaths` always specified as a
non-empty list) while preserving `pytest`'s default behaviour of
discovering tests in the current working directory.
Assert the specified `enabledTestPaths` value to be a non-empty list.
The kernel image is not functionally required at runtime in the same
output where the kernel modules are, and we can save space by removing
it.
Co-authored-by: Emily <vcs@emily.moe>
This has been marked insecure a while ago, as some CVEs have not been
backported. Even if *some* CVEs are fixed, we'd need **all** of them to
be, to get it back into the cache.
Not having it in the cache means, we can not test it in CI. This means
we can't make sure to actually support this version to evaluate Nixpkgs.
Currently, the output from fetchtorrent will be different depending on
whether the default "transmission" backend or the "rqbit" backend is
used, because "rqbit" changed its behaviour in v6.0.0 to create
subdirectories.
Restore the old behaviour for the rqbit backend of flattening the
directory structure, but add a "flatten" argument to allow users to
explicitly request the behaviour without this change.
Because fetchtorrent produces fixed-output derivations, it's possible
that people won't notice the changes in behaviour here, so add a warning
that the behaviour might be unexpected (in either direction!) if the
flatten argument isn't specified for the rqbit backend, and -- to avoid
needing to support it indefinitely -- a warning that `flatten = false`
will be deprecated in future.
Update the fetchtorrent tests to check all the relevant combinations,
and to mark all tests as now working.
Update the release notes to advertise this breaking change.
Fixes#432001.
With this argument fetchgit will make a subdirectory of the Git
repository a root of the resulting store path. This is helpful for
dealing with monorepos where many projects are in separate directories
and don't need a new source hash every time the monorepo is updated.
Commit hash is removed from the name of the derivation to prevent it
from changing the store path when nothing in the subdirectory changes.
GHC 9.10.2 seems to be unaffected by the i686 issue, so we can use 9.10
almost everywhere, c.f. https://gitlab.haskell.org/ghc/ghc/-/issues/25904.
haskellPackages: stackage LTS 23.27 -> LTS 24.2
all-cabal-hashes: 2025-07-07T21:33:55Z -> 2025-07-28T06:22:26Z
Make sure to retain Cabal and Cabal-syntax == 3.14.* which is currently
used by cabal2nix-unstable.
According to emilazy these were the only usages of sha1 in nixpkgs:
```
pkgs/servers/mx-puppet-discord/node-packages.nix
111: sha1 = "532e01241dbcb0f2769f1b9a7cde313d30101173";
120: sha1 = "68018cab4f59834b3fef2e59fbfd52938403e001";
129: sha1 = "52b0e8bb808a1202602899af67939b049dd42402";
138: sha1 = "0a37a3f9430ff7c29512d29882e25ae738a31283";
```
Anyone motivated to maintain it can feel free to restore this, it's just
not maintained at the moment, and the sha1 hashes need to go.
This was found after Ericson proposed implementing something like
https://github.com/NixOS/nix/issues/13544 in Lix, which led to the
question "who is using sha1 anyway?" and the realization we could just
*remove* support for it outside of .. the known chromium crimes.
Also:
- Updates the update script to use stable versions going forward
- Make pkgs.nixfmt the -rfc-style version and remove the warning
- Create a (delayed) warning for the -rfc-style version to encourage
switching to pkgs.nixfmt in a couple releases
- Add a release note for the above
The makeNeovimConfig function now preserves luaRcContent when passed as
an attribute, with a deprecation warning. This fixes the breaking change
from commit 24df1ab44a where luaRcContent would be overwritten by the
new customLuaRC parameter.
This will allow unlocking to take place *after* all of the devices have
been probed, as indicated by the x-systemd.wants and x-systemd.requires
options. This allows for multi-device bcachefs volumes to be reliably
unlocked.
A debuginfod support must be able to map a build-id to
- debug symbols
- the original elf file for which the debug symbols where separated
- the corresponding source files
Currently, hydra provides an index from build-id to the nar of the debug
output containing the debug symbols.
Add symlinks in these outputs so that we can recover the store path of
the source and original elf file. We can then fetch them by the normal
binary cache protocol.
About source files: to minimize storage demands, in the ideal case,
software would be built from the source store path $src and the
debuginfod server would just have to serve source files from this store
path. In practice, source files are sometimes patched as part of the
build. This commit stores the modified files in the debug output is a so
called source overlay so that the debuginfod serve can serve the patched
content of the file.
The checksum was chosen as follows (where big is 4GB of zeros):
$ hyperfine -L s sysv,bsd,crc,sha1,sha224,sha256,sha384,sha512,blake2b,sm3 'cksum -a {s} big'
Benchmark 1: cksum -a sysv big
Time (mean ± σ): 854.5 ms ± 270.5 ms [User: 245.3 ms, System: 601.8 ms]
Range (min … max): 760.5 ms … 1623.8 ms 10 runs
Warning: The first benchmarking run for this command was significantly slower than the rest (1.624 s). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.
Benchmark 2: cksum -a bsd big
Time (mean ± σ): 5.838 s ± 0.045 s [User: 5.118 s, System: 0.693 s]
Range (min … max): 5.767 s … 5.897 s 10 runs
Benchmark 3: cksum -a crc big
Time (mean ± σ): 829.9 ms ± 28.6 ms [User: 274.5 ms, System: 551.0 ms]
Range (min … max): 803.2 ms … 904.8 ms 10 runs
Benchmark 4: cksum -a sha1 big
Time (mean ± σ): 2.553 s ± 0.010 s [User: 1.912 s, System: 0.631 s]
Range (min … max): 2.543 s … 2.575 s 10 runs
Benchmark 5: cksum -a sha224 big
Time (mean ± σ): 2.716 s ± 0.018 s [User: 2.054 s, System: 0.645 s]
Range (min … max): 2.695 s … 2.743 s 10 runs
Benchmark 6: cksum -a sha256 big
Time (mean ± σ): 2.751 s ± 0.029 s [User: 2.057 s, System: 0.674 s]
Range (min … max): 2.712 s … 2.812 s 10 runs
Benchmark 7: cksum -a sha384 big
Time (mean ± σ): 5.600 s ± 0.049 s [User: 4.820 s, System: 0.753 s]
Range (min … max): 5.515 s … 5.683 s 10 runs
Benchmark 8: cksum -a sha512 big
Time (mean ± σ): 5.543 s ± 0.021 s [User: 4.751 s, System: 0.768 s]
Range (min … max): 5.523 s … 5.579 s 10 runs
Benchmark 9: cksum -a blake2b big
Time (mean ± σ): 5.091 s ± 0.025 s [User: 4.306 s, System: 0.764 s]
Range (min … max): 5.048 s … 5.125 s 10 runs
Benchmark 10: cksum -a sm3 big
Time (mean ± σ): 14.220 s ± 0.120 s [User: 13.376 s, System: 0.783 s]
Range (min … max): 14.077 s … 14.497 s 10 runs
Summary
cksum -a crc big ran
1.03 ± 0.33 times faster than cksum -a sysv big
3.08 ± 0.11 times faster than cksum -a sha1 big
3.27 ± 0.11 times faster than cksum -a sha224 big
3.31 ± 0.12 times faster than cksum -a sha256 big
6.13 ± 0.21 times faster than cksum -a blake2b big
6.68 ± 0.23 times faster than cksum -a sha512 big
6.75 ± 0.24 times faster than cksum -a sha384 big
7.03 ± 0.25 times faster than cksum -a bsd big
17.13 ± 0.61 times faster than cksum -a sm3 big
unfortunately, crc (and sysv) are not supported by --check, so they are
disqualified. sha1 sha224 and sha256 are sensibly as fast as one
another, so let's use a non broken one, even though cryptographic
qualities are not needed here.
vmalert only supports a single datasource for querying metrics and
managing alerts. Because of that, we need two instances to manage alerts
for both VictoriaLogs and VictoriaMetrics.
This is strongly inspired by the change made to Redis, i.e. a new
`instances` option was introduced with each option inside it.
With `mkRenamedOptionModule` it's ensured that existing configurations
still evaluate to the same result.
We removed additional guest agents from the main `lima` package.
These agents were moved to the `lima-additional-guestagents` package
in the previous commit.
This change reduces the size of the `lima` package, similar to how
upstream distributes these agents. Upstream has extracted guest agents
since version v1.1.0, except for the host's architecture.
This allows on-the-fly rewriting of URLs before they are passed from
fetchurl (or fetchurlBoot) to curl.
The intended use is to allow inserting company-internal mirrors, or
working around company firewalls and similar network restrictions,
without having to extensively patch across all of nixpkgs. Instead,
users can pass a function in their nixpkgs that performs the necessary
URL rewrites.
Co-authored-by: Alexander Bantyev <balsoft@balsoft.ru>
