| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | release-cuda: remove gimp3 | Morgan Helton | 2025-12-18 | 1 | -1/+0 |
| * | release-cuda: remove references to nix-community•••cuda work has moved out of nix-community and the jobset on the community hydra will be disabled
| zowoq | 2025-11-06 | 1 | -4/+1 |
| * | release-cuda: add freecad, krita, python3Packages.opencv4Full | Ulysses Zhan | 2025-11-02 | 1 | -0/+3 |
| * | firefox-devedition: build in cuda release | samfundev | 2025-09-19 | 1 | -0/+2 |
| * | firefox-beta: build in cuda release | wxt | 2025-08-30 | 1 | -0/+2 |
| * | thunderbird: add to release-cuda for nix-community caching | eymeric | 2025-08-28 | 1 | -0/+2 |
| * | firefox: add to release-cuda for nix-community caching | eymeric | 2025-08-28 | 1 | -0/+2 |
| * | jellyfin-ffmpeg: add to release-cuda•••This package overrides ffmpeg and thus can't rely on the ffmpeg build
| Adam C. Stephens | 2025-07-19 | 1 | -0/+1 |
| * | kdenlive and octave: add to release-cuda (#414778)•••Bypassing waiting for the `no PR failures` check which should have run successfully a while ago (since all of Check, Eval, and Lint succeeded -- this is not an attribute set exposed through Nixpkgs). The passthru tests aren't going to run, either. | Connor Baker | 2025-07-16 | 1 | -0/+2 |
| |\ |
|
| | * | octave: add to release-cuda | eymeric | 2025-06-11 | 1 | -0/+1 |
| | * | kdenlive: add to release-cuda | eymeric | 2025-06-11 | 1 | -0/+1 |
| * | | release-cuda: add flashinfer | hacker1024 | 2025-06-30 | 1 | -0/+1 |
| |/ |
|
| * | _cuda: missed fixups•••Signed-off-by: Connor Baker <ConnorBaker01@gmail.com>
| Connor Baker | 2025-05-27 | 1 | -1/+1 |
| * | _cuda: introduce to organize CUDA package set backbone•••Signed-off-by: Connor Baker <ConnorBaker01@gmail.com>
| Connor Baker | 2025-05-27 | 1 | -2/+2 |
| * | cudaPackages: switch to cudaLib•••Signed-off-by: Connor Baker <ConnorBaker01@gmail.com>
| Connor Baker | 2025-05-27 | 1 | -15/+2 |
| * | gimp3: add to release-cuda | eymeric | 2025-05-27 | 1 | -0/+1 |
| * | mistral-rs: fix cuda support (#343254) | Gaétan Lepage | 2025-04-13 | 1 | -0/+1 |
| |\ |
|
| | * | release-cuda: build mistral-rs on nix-community Hydra | Gaetan Lepage | 2025-04-13 | 1 | -0/+1 |
| * | | release-cuda: add sunshine | Morgan Helton | 2025-04-08 | 1 | -0/+1 |
| |/ |
|
| * | cusparselt: init at 0.7.1 (#270446) | Suwon Park | 2025-03-18 | 1 | -0/+1 |
| * | release-cuda: minor refactoring and comments | ruro | 2025-03-12 | 1 | -6/+15 |
| * | release-cuda: disable deprecated aliases•••Using primary/canonical names for packages makes it easier to keep track
of stuff. Additionally, this stops the recursion into cudaPackages* from
including fake "aliases" for old (unsupported) cuda versions.
| ruro | 2025-02-17 | 1 | -0/+3 |
| * | python3Packages.scikit-image: switch to primary alias in release-cuda•••Both `scikitimage` and `scikit-image` refer to the same package, but
only the second one is the canonical name.
| ruro | 2025-02-17 | 1 | -1/+1 |
| * | python3Packages.keras: switch to primary alias in release-cuda•••Both `Keras` and `keras` refer to the same package, but only the second
one is the canonical name.
| ruro | 2025-02-17 | 1 | -1/+1 |
| * | python3Packages.torch remove duplicate from release-cuda•••Both `pytorch` and `torch` refer to the same package, but only the
second one is the canonical name.
The canonical `torch` name is already mentioned once a bit lower in the
file.
| ruro | 2025-02-17 | 1 | -1/+0 |
| * | python3Packages.theano: remove from release-cuda•••The theano package itself was originally removed in #313148.
| ruro | 2025-02-17 | 1 | -1/+0 |
| * | release-cuda: fix job names•••Rename the jobs from cudaPackages*.cudaPackages*.blah to just
cudaPackages*.blah so that they match the nixpkgs attribute paths.
| ruro | 2025-02-17 | 1 | -2/+2 |
| * | python3Packages.boxx: remove•••This package was only used as a dependency of bpycv which was removed in
the previous commit.
| ruro | 2025-02-14 | 1 | -1/+0 |
| * | python3Packages.bpycv: remove•••The bpycv package is incompatible with blender version 4 or later. It
seems that neither upstream author nor the nixpkgs maintainer are
currently interested in updating/maintaining this package.
See:
- https://github.com/NixOS/nixpkgs/issues/379872
- https://github.com/DIYer22/bpycv/issues/51
- https://github.com/NixOS/nixpkgs/pull/380403
- https://github.com/NixOS/nixpkgs/pull/380443
| ruro | 2025-02-14 | 1 | -1/+0 |
| * | release-cuda: add vllm | Pavol Rusnak | 2025-02-07 | 1 | -0/+1 |
| * | deepin.image-editor: remove | rewine | 2025-01-17 | 1 | -1/+0 |
| * | python312Packages.chainer: remove•••chainer has been removed, as it is abandoned and broken
| natsukium | 2025-01-10 | 1 | -1/+0 |
| * | release: forbid use of `lib.fileset` in Nixpkgs•••Due to Nix bug <https://github.com/NixOS/nix/issues/11503>,
`builtins.filterSource` and chroot stores interact in a confusing
and broken way that breaks `lib.fileset`. This means that uses of
the API inside Nixpkgs keep breaking the NixOS installer, blocking
the channel. The resulting error messages are inscrutable (they look
like “the installer test is trying to download `curl`…?” and
eventually bottom out in a derivation that has the wrong `outPath`
because of the chroot store causing an incorrect `lib.fileset` result).
Whenever this happens, someone (well, in practice K900 or I)
has to bisect the change that introduced it and remove the use of
`lib.fileset`. This has happened at least three times in the past
four months (I believe I might actually be missing one here, but
these are the ones I remember and could easily dig up):
* <https://github.com/NixOS/nixpkgs/pull/340046>
* <https://github.com/NixOS/nixpkgs/pull/352491>
* <https://github.com/NixOS/nixpkgs/pull/369459>
The options I see here are:
1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is
fixed. This is the approach taken here. External users of Nixpkgs
can continue to use the API as normal, but using it from within
something that affects any release jobset `outPath`s will cause an
evaluation failure with a hopefully‐helpful error message.
2. Forbid `lib.fileset` and also all of the other library APIs that use
`builtins.filterSource`. I’m happy to do this, but so far none of
those have broken the installer, so I decided to start small and
worry about the others if they end up causing a problem in practice.
3. Forbid `builtins.filterSource` directly. This is hard and would
require more invasive `builtins.scopedImport` crimes to do at
evaluation time. I think this would realistically have to be done in
something like nixpkgs-vet instead and I didn’t have much luck
shoehorning a check like this into that codebase when I tried.
4. Fix the Nix bug. This would be great! But also it doesn’t seem to be
happening any time soon, it seems difficult to fix in a way that
doesn’t subtly break compatibility with the previous semantics, and
arguably the fix would need backporting all the way back to 2.3
given our minimum version policy.
5. Do nothing; have people continue to innocuously use `lib.fileset`
throughout Nixpkgs, breaking the installer whenever one of them
sneaks in to that closure, causing the channel to be blocked and
requiring expensive bisections to narrow down the inscrutable test
failure to the package using `lib.fileset`, which then needs moving
back off it. This sucks for the people who keep having to track it
down, holds back important channel bumps, and the criteria for when
it’s okay to use `lib.fileset` are not realistically possible to
teach to all contributors.
I'd be happy to work on (2) as an alternative; (3) would be difficult
and seems like overkill, (4) is not really something I trust myself
to do and wouldn’t address the immediate problem, and (5) isn’t
sustainable. I think that the current approach here is the best
trade‐off for now, as `lib.fileset` seems to be the only prominent
user of the `builtins.filterSource` API that works with full store
paths, exposing it to the Nix bug. It’s unfortunate to lose the
nice API, but since we can’t rely on it to produce correct results
and the channels keep getting blocked as a result, I don’t think
we really have an alternative right now.
| Emily | 2024-12-31 | 1 | -0/+2 |
| * | caffe: remove broken CUDA support•••It’s been marked as broken for over a year and requires CUDA
10. Even the non‐CUDA variant of the package refused to evaluate
without enabling broken packages due to `cudnn`, so I’m not sure
anyone is using this package at all…
| Emily | 2024-11-21 | 1 | -1/+0 |
| * | release-cuda: account for Hydra passing extra flags | Someone Serge | 2024-08-28 | 1 | -3/+4 |
| * | release-cuda: allow passing `system` to release-lib | SomeoneSerge | 2024-08-15 | 1 | -2/+5 |
| * | python312Packages.libgpuarray: drop•••The package has not been maintained aside from small bugfixes and
formatting fixes, and is not depended on by anything else, therefore it
should be good to drop now.
| Pyrox | 2024-08-03 | 1 | -1/+0 |
| * | treewide: remove openai-triton (alias) references•••The repository moved out of the openai org, so it doesn't make sense to
prefix the package with it.
(cherry picked from commit af13bb4513647eec3c3790c5272dbd4aa190d208)
| Dennis Wuitz | 2024-07-23 | 1 | -1/+1 |
| * | release-cuda: explicitly allow cuTENSOR, disallow generic unfreeRedistributable | Someone Serge | 2024-07-20 | 1 | -1/+1 |
| * | release-cuda: refine the allowUnfreePredicate | Someone Serge | 2024-07-04 | 1 | -1/+17 |
| * | release-cuda: import attributes from https://github.com/SomeoneSerge/nixpkgs-... | Someone Serge | 2024-07-04 | 1 | -41/+128 |
| * | Avoid `with lib;` at the top level in pkgs/top-level/release-cuda.nix | Philip Taron | 2024-03-08 | 1 | -3/+8 |
| * | python3Packages.torch{,-bin}: rename from pytorch{,-bin}•••The proper name for a python package is the one in the setuptools
setup() call, which can also be seen on pypi.
Correct: https://pypi.org/project/torch/
Wrong: https://pypi.org/project/pytorch/
Includes a treewide rename of the attribute and creates aliases for the
old name.
| Martin Weinelt | 2022-08-30 | 1 | -1/+1 |
| * | cudaPackages: overhaul of how we package cuda packages•••There are many different versions of the `cudatoolkit` and related
cuda packages, and it can be tricky to ensure they remain compatible.
- `cudaPackages` is now a package set with `cudatoolkit`, `cudnn`, `cutensor`, `nccl`, as well as `cudatoolkit` split into smaller packages ("redist");
- expressions should now use `cudaPackages` as parameter instead of the individual cuda packages;
- `makeScope` is now used, so it is possible to use `.overrideScope'` to set e.g. a different `cudnn` version;
- `release-cuda.nix` is introduced to easily evaluate cuda packages using hydra.
| Frederik Rietdijk | 2022-04-09 | 1 | -0/+55 |
