text:
rr fails to build in unstable

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Checkout nixos-unstable (or use unstable channel)
Build rr ( nix-shell -p rr fails as does nix-build -A pkgs.rr)

Expected behavior
rr package is built successfully.
Screenshots
[100%] Built target x87env
[100%] Built target user_ignore_sig
[100%] Built target fcntl_rw_hints
[100%] Built target thread_open_race
[100%] Built target search
[100%] Built target nscd
[100%] Built target watchpoint_no_progress
[100%] Built target watchpoint_size_change
[100%] Built target constructor
[100%] Built target threaded_syscall_spam
[100%] Linking CXX executable bin/rr
/nix/store/wcz8lsibkw2nikdb0bjl22p75lfwahzr-binutils-2.35.1/bin/ld.bfd: /build/rr.rBJ93I.ltrans0.ltrans.o: in function `rr::AddressSpace::AddressSpace(rr::Task*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)':
/build/source/src/AddressSpace.cc:1632: undefined reference to `rr_syscall_addr'
/nix/store/wcz8lsibkw2nikdb0bjl22p75lfwahzr-binutils-2.35.1/bin/ld.bfd: bin/rr: hidden symbol `rr_syscall_addr' isn't defined
/nix/store/wcz8lsibkw2nikdb0bjl22p75lfwahzr-binutils-2.35.1/bin/ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/rr.dir/build.make:1228: bin/rr] Error 1
make[1]: *** [CMakeFiles/Makefile2:5597: CMakeFiles/rr.dir/all] Error 2
make: *** [Makefile:182: all] Error 2
builder for '/nix/store/d406ixnsmw1b1qr10incwnhx3qwjjnym-rr-5.4.0.drv' failed with exit code 2
error: build of '/nix/store/d406ixnsmw1b1qr10incwnhx3qwjjnym-rr-5.4.0.drv' on 'ssh://bob@m5' failed: builder for '/nix/store/d406ixnsmw1b1qr10incwnhx3qwjjnym-rr-5.4.0.drv' failed with exit code 2
builder for '/nix/store/d406ixnsmw1b1qr10incwnhx3qwjjnym-rr-5.4.0.drv' failed with exit code 1
error: build of '/nix/store/d406ixnsmw1b1qr10incwnhx3qwjjnym-rr-5.4.0.drv' failed

Additional context
I think it broke over the holidays... I'll try to get a more exact time/commit range.
Notify maintainers

@thoughtpolice @nbp
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.4.89, NixOS, 21.03.git.4a2481f0c70 (Okapi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.10
channels(root): "nixos-20.03pre208171.2e8fc97dbfa"
nixpkgs: /etc/nixos/aij/unstable

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
  - rr
# a list of nixos modules affected by the problem
module:

cc @FRidh since I suspect this is gcc10 related. Build worked right before af802654b91e150fdaa8e32c29a0eefbdf953597 though dependencies failed to build at that sha so I'm not sure when the current failure started.
Here's my bisect log so far:
ivan@tobati:~/nixops/aij/unstable$ git bisect log
# bad: [187af93c1972b7c1930bc48a91c42a22ecba86ec] Merge pull request #78430 from puckipedia/fix-initrd-silent
# good: [ed4d6a8eff74b3b6e372778b64d9a90e6c8c93aa] linux-hardened: Switch to 5.10
# good: [2d9193f9f032c52594d90eb64b8c4ffa8c615354] Merge staging-next into staging
git bisect start '187af93c1972b7c1930bc48a91c42a22ecba86ec' 'ed4d6a8eff74b3b6e372778b64d9a90e6c8c93aa' 'gcc10^'
# bad: [c92a996c8f82467bcdd8566981d0c71b42c74833] Merge pull request #108602 from mweinelt/home-assistant
git bisect bad c92a996c8f82467bcdd8566981d0c71b42c74833
# bad: [d9dba88d08a9cdf483c3d45f0d7220cf97a4ce64] Merge pull request #106742 from freezeboy/migrate-qt515
git bisect bad d9dba88d08a9cdf483c3d45f0d7220cf97a4ce64
# bad: [a7ac72d80d6735d0203fb57b6708b09052b72de7] Merge pull request #108326 from thiagokokada/bump-denonavr
git bisect bad a7ac72d80d6735d0203fb57b6708b09052b72de7
# bad: [279110cd86e9c969f8f2942675f7c73cfe4059d3] Merge master into staging-next
git bisect bad 279110cd86e9c969f8f2942675f7c73cfe4059d3
# bad: [f19b7b03a03b7f1d5beb44471eb9298de4b9e186] Merge branch 'master' into staging-next
git bisect bad f19b7b03a03b7f1d5beb44471eb9298de4b9e186
# bad: [ff873c7c213c0ab112a60b151a12261bbb40a585] Merge master into staging-next
git bisect bad ff873c7c213c0ab112a60b151a12261bbb40a585
# bad: [1c89832fd5cb1c3be4a5bb9b483e219b06db0f25] refind: fix build on gcc10
git bisect bad 1c89832fd5cb1c3be4a5bb9b483e219b06db0f25

cc @FRidh since I suspect this is gcc10 related. Build worked right before af802654b91e150fdaa8e32c29a0eefbdf953597 though dependencies failed to build at that sha so I'm not sure when the current failure started.
Here's my bisect log so far:
ivan@tobati:~/nixops/aij/unstable$ git bisect log
# bad: [187af93c1972b7c1930bc48a91c42a22ecba86ec] Merge pull request #78430 from puckipedia/fix-initrd-silent
# good: [ed4d6a8eff74b3b6e372778b64d9a90e6c8c93aa] linux-hardened: Switch to 5.10
# good: [2d9193f9f032c52594d90eb64b8c4ffa8c615354] Merge staging-next into staging
git bisect start '187af93c1972b7c1930bc48a91c42a22ecba86ec' 'ed4d6a8eff74b3b6e372778b64d9a90e6c8c93aa' 'gcc10^'
# bad: [c92a996c8f82467bcdd8566981d0c71b42c74833] Merge pull request #108602 from mweinelt/home-assistant
git bisect bad c92a996c8f82467bcdd8566981d0c71b42c74833
# bad: [d9dba88d08a9cdf483c3d45f0d7220cf97a4ce64] Merge pull request #106742 from freezeboy/migrate-qt515
git bisect bad d9dba88d08a9cdf483c3d45f0d7220cf97a4ce64
# bad: [a7ac72d80d6735d0203fb57b6708b09052b72de7] Merge pull request #108326 from thiagokokada/bump-denonavr
git bisect bad a7ac72d80d6735d0203fb57b6708b09052b72de7
# bad: [279110cd86e9c969f8f2942675f7c73cfe4059d3] Merge master into staging-next
git bisect bad 279110cd86e9c969f8f2942675f7c73cfe4059d3
# bad: [f19b7b03a03b7f1d5beb44471eb9298de4b9e186] Merge branch 'master' into staging-next
git bisect bad f19b7b03a03b7f1d5beb44471eb9298de4b9e186
# bad: [ff873c7c213c0ab112a60b151a12261bbb40a585] Merge master into staging-next
git bisect bad ff873c7c213c0ab112a60b151a12261bbb40a585
# bad: [1c89832fd5cb1c3be4a5bb9b483e219b06db0f25] refind: fix build on gcc10
git bisect bad 1c89832fd5cb1c3be4a5bb9b483e219b06db0f25

So, for now this?
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -12583 +12583,3 @@ in
-  rr = callPackage ../development/tools/analysis/rr { };
+  rr = callPackage ../development/tools/analysis/rr {
+    stdenv = gcc9Stdenv; # hidden symbol `rr_syscall_addr' isn't defined
+  };

and also clean up the unstable variant not to override other parameters from plain rr
--- a/pkgs/development/tools/analysis/rr/unstable.nix
+++ b/pkgs/development/tools/analysis/rr/unstable.nix
@@ -8,6 +8 @@
-{ callPackage, fetchFromGitHub }:
-
-let
-  rr = callPackage ./. {};
-in
-
+{ rr, fetchFromGitHub }:

So, for now this?
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -12583 +12583,3 @@ in
-  rr = callPackage ../development/tools/analysis/rr { };
+  rr = callPackage ../development/tools/analysis/rr {
+    stdenv = gcc9Stdenv; # hidden symbol `rr_syscall_addr' isn't defined
+  };

and also clean up the unstable variant not to override other parameters from plain rr
--- a/pkgs/development/tools/analysis/rr/unstable.nix
+++ b/pkgs/development/tools/analysis/rr/unstable.nix
@@ -8,6 +8 @@
-{ callPackage, fetchFromGitHub }:
-
-let
-  rr = callPackage ./. {};
-in
-
+{ rr, fetchFromGitHub }:

authors: aij vcunat


text:
unstable channel hasn't updated for 14+ days

https://github.com/nixos/nixpkgs-channels has been stuck at 7ae05edcdd14f6ace83ead9bf0d114e97c89a83a for two weeks. According to https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents, kde4 tests fail, but there might be other reasons why the channel is blocked.

Yes, there's a build error in kgamma:

Unknown CMake command "check_include_files".

Maybe some cmake update on staging or something...

Sounds like exactly the same problem that @aszlig fixed in conky: 880eba6481d112b934325f1e60033ffd3c6c3f53

Yes, that sounds exactly like that problem. However I have no idea how to fix it properly.
@ttuegel You do most of the kde stuff, do you have a idea?

For kgamma, check for a patch upstream. CMake doesn't keep backwards compatibility between versions, so you can't just upgrade it globally. You will need an upstream patch for kgamma to fix it properly. If there is no upstream patch, I guess your options are to use an older CMake for kgamma or drop kgamma as unmaintained upstream.

Fixed a channel blocker in 48409bd3. No other failures are visible ATM http://hydra.nixos.org/build/28002207#tabs-constituents

So, kde4 test succeed for me now on x86_64-linux. I decided to switch to cmake-2.8 for all kde4 components, as that seemed easiest with kde4 stuff not really maintained upstream anymore.

@lethalman: what is your estimate about status of gnome-3.18 in nixpkgs? When switch the default?
Now I see that gnome-maps-3.16 also has problems with newer glib and there are no more 3.16 releases of that one. Maybe 3.16 will become nontrivial to keep alive.

gnome3.gnome-maps has been removed by @lethalman , but main hydra machine still fails to run tests because of:
mv: error writing '/nix/store/sdsnyczpgyrf801z33g043igch461gk3-xsession': No space left on device
<3>note: build failure may have been caused by lack of free disk space
<3>builder for ‘/nix/store/n24r2qi5h74c1j8h2cilx23zaz1phbpp-xsession.drv’ failed with exit code 1

cc @rbvermaa @edolstra

Currently hydra doesn't pickup nixos tests, so they're in queue for a few days.

It appears that https://hydra.nixos.org/build/28408697 succeeded. Now all we need is a channel update!

here it is \o/

source: gharchive/issue

authors: domenkozar pSub peti ttuegel vcunat wizeman

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
unstable/unstable-small boot tests blocked due to alsa-firmware failing nix verify

Describe the bug
nix verify fails in the boot tests, like so:
machine # path '/nix/store/7d37hb96a4m0z7kx0crh7vqyi24r1iwz-alsa-firmware-1.2.1' was modified! expected hash 'sha256:04051aw1fpag65s5nrvaj8bf55x8nzckq6610lz0vfxy7sh9cp7n', got 'sha256:154zsxs2d2zxqgr0mia3yj26m5szwygab3z122ws9ydzq9ilglkw'
machine: output:
error:
Traceback (most recent call last):
  File "/nix/store/mb9lhv3n6h20ybbpr2j8xdhbv5jgijwb-nixos-test-driver/bin/.nixos-test-driver-wrapped", line 943, in run_tests
    exec(tests, globals())
  File "<string>", line 1, in <module>
  File "<string>", line 10, in <module>
  File "/nix/store/mb9lhv3n6h20ybbpr2j8xdhbv5jgijwb-nixos-test-driver/bin/.nixos-test-driver-wrapped", line 483, in succeed
    raise Exception(
Exception: command `nix verify -r --no-trust /run/current-system` failed (exit code 1)
cleaning up
(0.00 seconds)

See e.g. the history here: https://hydra.nixos.org/job/nixos/unstable-small/nixos.tests.boot.biosCdrom.x86_64-linux/all
Steps To Reproduce
On master, nix-build nixos/release.nix -A tests.boot.biosCdrom.x86_64-linux. This failed for me on the first try:
machine # path '/nix/store/fyx0rpdshfb9np7sb2dqr50rm72xzwkh-alsa-firmware-1.2.1' was modified! expected hash 'sha256:04051aw1fpag65s5nrvaj8bf55x8nzckq6610lz0vfxy7sh9cp7n', got 'sha256:154zsxs2d2zxqgr0mia3yj26m5szwygab3z122ws9ydzq9ilglkw'

Interestingly, that path is fine on my host machine:
$ nix verify -r --no-trust /nix/store/fyx0rpdshfb9np7sb2dqr50rm72xzwkh-alsa-firmware-1.2.1
$ echo $?
0
$

Expected behavior
The boot tests succeed, and channels are unblocked.
Notify maintainers
Unclear who to ping here, since I'm not sure if this is a nix daemon bug, a corruption issue on cache.nixos.org, or an alsa-firmware problem...
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute: alsa-firmware
# a list of nixos modules affected by the problem
module:

@roberth I think you referred to a related Nix issue earlier when I asked, but I can't recall what it was.

It was this PR: https://github.com/NixOS/nixpkgs/pull/123943  (but not in the sense that it fixes this issue)

It would be nice to understand why the modification happens.
I tried just dumb bisection.  The problem seems reliably reproducible on my machine, and I arrived at c5114b3d3ef. (retried multiple times on the commit and its parent)  But it doesn't really make sense, and reverting that merge on master does not fix it for me anyway.

I grabbed the nar out of a running test VM with nix-store --dump /nix/store/fyx0rpdshfb9np7sb2dqr50rm72xzwkh-alsa-firmware-1.2.1.
Here's the diff-of-xxds:
vimdiff <(xxd fyx0rpdshfb9np7sb2dqr50rm72xzwkh-alsa-firmware-1.2.1.nar-from-vm) <(curl https://cache.nixos.org/nar/1qsqiayqgg7y3pvzrsg1mkxbq2y33mbbwv6wc315b434l9vh002i.nar.xz | unxz - | xxd)

Checking edolstra's PHD thesis to find out what this actually means :)

Maybe it would be easier to "unpack" it into a directory and compare those.

It's the sizes of the files /nix/store/fyx0rpdshfb9np7sb2dqr50rm72xzwkh-alsa-firmware-1.2.1/share/alsa/firmware/usx2yloader/us224.prepad and /nix/store/fyx0rpdshfb9np7sb2dqr50rm72xzwkh-alsa-firmware-1.2.1/share/alsa/firmware/usx2yloader/us428.prepad.
In the cache version, they're 70 and 72 bytes each, in the vm version, they're 71 each.

If I'm understand correctly, this is a simple non-reproducable build, and due to some messy nix behavior, that is manifesting as a failed verify, since the narinfos come from two places with two different ideas of what the final output hash should be?
I don't believe enforcing true reproducibility as a channel blocker is the intention of this test, right?

I had checked that first: on my machine the nix-build -QA alsa-firmware --check always succeeds (i.e. reproduces the hash from cache.nixos.org).  Of course, in the VM it might be different, but so far I suspect the problem is somewhere else.

Ah of course, the VM isn't actually doing the build it's presumably getting it from the same place as the host. Which means something spookier is going on...

Maybe it's some bug related to those files containing just zero bytes.

Ah yeah, looking at the alsa-firmware sources these files do seem to just be static files, so the build being truely reproducable seems unlikely. The correct sizes are:
.rw-r--r-- 71 jamie 14 Nov  2019 us122.prepad
.rw-r--r-- 70 jamie 14 Nov  2019 us224.prepad
.rw-r--r-- 72 jamie 14 Nov  2019 us428.prepad

So cache.nix.org is correct and the VM is incorrect. I assume the VM is getting it from the iso file it's booting? Will check that next.
Cosmic rays? :3

Yep, I have mounted the squashfs from the ISO and it is indeed wrong:
-r--r--r-- 1 root root 71 Jan  1  1970 share/alsa/firmware/usx2yloader/us122.prepad
-r--r--r-- 1 root root 71 Jan  1  1970 share/alsa/firmware/usx2yloader/us224.prepad
-r--r--r-- 1 root root 71 Jan  1  1970 share/alsa/firmware/usx2yloader/us428.prepad

I suspect https://github.com/plougher/squashfs-tools/commit/19b161c1cd3e31f7a396ea92dea4390ad43f27b9  I'll verify.

That commit doesn't seem to be part of squashfs-tools 4.5 though.

No, the bug was introduced in 4.5, and is not yet part of a release, see the top of the readme:
NEWS
----

2021-07-25 Important bug found in release.

A new point release will be forthcomming in the
next couple of days.  Sooner if no other release
bugs are reported.

Ah, thanks

Yes, that patch fixed the bug.  At least for me.
I assume it was elusive because sparsity of files isn't perfectly reproducible (especially when you have /nix/store on a different FS).

authors: FRidh JJJollyjim ncfavier vcunat


text:
Vulnerability roundup 106: grilo-0.3.13: 1 advisory [5.9]

search, files

[ ] CVE-2021-39365 CVSSv3=5.9 (nixos-21.05, nixos-unstable)

CVE details
CVE-2021-39365
In GNOME grilo though 0.3.13, grl-net-wc.c does not enable TLS certificate verification on the SoupSessionAsync objects it creates, leaving users vulnerable to network MITM attacks. NOTE: this is similar to CVE-2016-20011.

Scanned versions: nixos-21.05: 6120ac5cd20; nixos-unstable: bc9b956714e.
Cc @dasj19
Cc @hedning
Cc @jtojnar
Cc @maxeaubrey

See https://github.com/NixOS/nixpkgs/issues/138668#issuecomment-923874558


text:
Our MultiMC build doesn't have keys to log into a Microsoft Account

Describe the bug
Our build of MultiMC cannot log in to any Microsoft (migrated) account due to lack of API keys from Azure. AFAIK we cannot provide the keys in our build safely since they are secrets and therefore will have to be public in Nix store.
Steps To Reproduce
Steps to reproduce the behavior:

Launch MultiMC
Try to log in
Observe the "Add Microsoft [account]" button grayed out

Expected behavior
MultiMC from Nixpkgs can log in to Microsoft accounts.
Additional context
We can package the official build of MultiMC which does contain API keys, by either patchelf-ing it or wrapping it in an FHS environment.
Notify maintainers
@cleverca22 @starcraft66

You need to provide your own.
See:

https://nixos.wiki/wiki/MultiMC
https://github.com/NixOS/nixpkgs/pull/137147


text:
google-chrome-stable has an invalid sha256 hash

Issue description
While running nixos-rebuild switch --upgrade:
[...]
curl: (22) The requested URL returned error: 404 Not Found

trying http://mirror.pcbeta.com/google/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_49.0.2623.87-1_amd64.deb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found

trying http://repo.fdzh.org/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_49.0.2623.87-1_amd64.deb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   185  100   185    0     0    261      0 --:--:-- --:--:-- --:--:--   262
100   161  100   161    0     0     76      0  0:00:02  0:00:02 --:--:--   133
100 5880k  100 5880k    0     0   887k      0  0:00:06  0:00:06 --:--:-- 1570k
output path ‘/nix/store/w21wkbwp951xjfs4bhc8lx0kszhrq6ks-google-chrome-stable_49.0.2623.87-1_amd64.deb’ should have sha256 hash ‘1k6nhccdqzzzicwi07nldqfsdlic65i2xfyb7dbasbbg9zl3s9yw’, instead has ‘1hhrxx0qgmircanmnpwsqpwl7y04qz98nj7h3bsk1ib5jrwx9w1m’
building path(s) ‘/nix/store/04kp3dg9qh38im6q8ygdkygsp02q42j8-chfn.pam’

Is this a malicious or broken mirror? Should it be removed?

Just got the same thing and I think with the same mirror.

Something is amiss, the download is way smaller than it ought to be. Upstream .deb is ~50MB

That mirror is regularly excruciatingly slow for me. I used to have it patched out.

/cc maintainer @msteen.

The the source of Google Chrome is defined by the Chromium package, which was already using it to extract its plugins from. So as far as I know, the source of this issues lies with the deb mirrors as defined in update.nix of the Chromium package.

So, /cc @aszlig as well, I guess.

It is unfortunate that Google does not keep the two previous versions around, but instead drops the previous version as soon as a new version arises. I tried to find other mirrors, but so far I have only found one that does not keep the same directory structure as the rest:
http://www.ubuntuupdates.org/pm/google-chrome-stable

Hi, I am facing the same issue. Is there any workaround?

This should be long resolved / outdated.

authors: colemickens joachifm msteen nkaretnikov puffnfresh vcunat yamafaktory


text:
nodePackages.prisma-language-server

Project description
A language server for prisma files
Metadata

homepage URL: https://www.npmjs.com/package/@prisma/language-server
source URL: https://www.npmjs.com/package/@prisma/language-server
license: apache 2.0
platforms: all

This is already packaged: https://github.com/NixOS/nixpkgs/blob/e8c05fe2e1a31a92731b92b6f78c2ff997d25e61/pkgs/development/node-packages/node-packages.json#L264

authors: Alexnortung jupblb


text:
report

Describe the bug
A clear and concise description of what the bug is.
Steps To Reproduce
Steps to reproduce the behavior:

...
...
...

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

Looks like accidental opening from template.


text:
networking.networkmanager.ensureProfiles.profiles..ipv4.ignore-auto-dns option does not work

Describe the bug
The setting networking.networkmanager.ensureProfiles.profiles.<name>.ipv4.ignore-auto-dns does not work.
Steps To Reproduce
Steps to reproduce the behavior:

Create a NetworkManager wifi configuration in a config file such as:

  networking.networkmanager.ensureProfiles.profiles = {
    my-cool-wifi = {
      connection = {
        id = "some-wifi-id";
        type = "wifi";
        interface = "$NETWORK_IFACE";
        permissions = "";
      };
      ipv4 = {
        method = "auto";
        ignore-auto-dns = "true";
        dns = "$DNS";
        dns-search = "";
      };

      wifi = {
        mode = "infrastructure";
        ssid = "$SSID";
      };

      wifi-security = {
        auth-alg = "open";
        key-mgmt = "wpa-psk";
        psk = "$PASSWORD";
      };
    };
  };

Apply the configuration
Check the configuration is applied at /run/NetworkManager/system-connections/my-cool-wifi.connection
Restart networkmanager with "ssystemctl restart NetworkManager"
Wait a few seconds and cat /etc/resolv.conf
An entry is created that starts with "domain x.y.z" where x.y.z is pushed from the dns server.

Expected behavior
According to https://people.freedesktop.org/~lkundrak/nm-docs/nm-settings.html, setting ignore-auto-dns to "true" should ignore automatically configured nameservers and search domains
There should be no line in /etc/resolv.conf configuring a domain ; that is there should be no line starting with "domain x.y.z".
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.78, NixOS, 24.05 (Uakari), 24.05.20240221.0e74ca9`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/store/gzf4zwcakda1nykn6h0avh45xhjhvsz4-source`

Add a :+1: reaction to issues you find important.

CC: @NixOS/freedesktop

CC: @Janik-Haag @flokli @jtojnar @kevincox

Can you share the content of /run/NetworkManager/system-connections/my-cool-wifi ?

Thanks for the quick feedback!
Here:
[connection]
id=my-cool-wifi
interface=$INTERFACE
permissions=
type=wifi

[ipv4]
dns=$IP_OF_DNS
dns-search=
ignore-auto-dns=true
method=auto

[wifi]
mode=infrastructure
ssid=$SSID

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=$PASSWD

All the $VAR things are for anonymity/security of the concerned network.
One of my colleague tried with Debian on the same network and ignore-auto-dns=true DID work for them, no domain x.y.z was pushed in /etc/resolv.conf.

I'll be at dayjob for the next few hours but can take a look later.

Okay so I would say this isn't a NixOS bug, or at least isn't one related to networking.networkmanager.ensureProfiles.profiles since it gets rendered correctly. Did you try diffing you and your colleague's  nmconnection file?
You can also try reading through the nm reference manual
Where it lists some conditions:

When "method" is set to "auto" and this property to TRUE, automatically configured name servers and search domains are ignored and only name servers and search domains specified in the "dns" and "dns-search" properties, if any, are used.

We basically had the same configuration but I will ask a second time.

When "method" is set to "auto" and this property to TRUE, automatically configured name servers and search domains are ignored and only name servers and search domains specified in the "dns" and "dns-search" properties, if any, are used.

Exactly. In the configuration method=auto and the property is set to true BUT the name servers domains are not ignored.

at least isn't one related to networking.networkmanager.ensureProfiles.profiles

Yes, maybe there is something happening beyond that. The first call to cat showed the nameserver but only the second call (after 1 or 2 seconds) would show the added domain x.y.z line.

Here the config from my colleague:
[connection]
id=my-cool-wifi
uuid=$SOMEUID
type=wifi
interface-name=$INTERFACE

[wifi]
mode=infrastructure
ssid=$SSID

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=$THE_SECRET_PASSWORD

[ipv4]
method=auto
ignore-auto-dns=true
dns=$DNS_IP

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

Honestly no idea what's wrong with it. I started writing VM-tests for Network-Manager yesterday and will try to finish them this weekend. Then checking for your problem will be a lot easier.

Thank you so much!!
A workaround is to have a dispatchScript, like so:
networking.networkmanager.dispatcherScripts = [
    {
     source = pkgs.writeText "upHook" ''
              if [ "$2" != "up" ]; then
                logger "exit: event $2 != up"
                exit
              fi

              sleep 2s
              sed -i 's/domain x.y.z.*//' /etc/resolv.conf

              # coreutils and iproute are in PATH too
              logger "Device $DEVICE_IFACE coming up"
            '';
     type = "basic";
   }
  ];

Feel free to take a look at #292472 it has some very basic NM vm-tests I'll add a test case for your problem this weekend or so.

Okay so as you can see with https://github.com/NixOS/nixpkgs/pull/292472/files#diff-3649918b52093521f5b02110302572d734ccc01a0778c65089b556e1db448ee3R94-R124 the issue you are describing is not network-manager related. You probably have something else installed trying to update /etc/resolv.conf based on dhcp packets, maybe networkd?
If you want to test locally I suggest you do something like:
nix run github:janik-haag/nixpkgs/networkmanager-tests#nixosTests.networking.networkmanager.dns.driverInteractive

or
env -i nix-shell -I nixpkgs=https://github.com/Janik-Haag/nixpkgs/archive/refs/heads/networkmanager-tests.tar.gz '<nixpkgs>' -p nixosTests.networki
ng.networkmanager.dns.driverInteractive --run nixos-test-driver

and then just type:
# starts the vms
start_all()
# wait ~10-60 seconds depending on your hardware
static.shell_interact()
# or depending on which machine you want to look at
dynamic.shell_interact()

then you get a shell inside the vm and do things like: cat /etc/resolv.conf
So I think we can close this issue?

Thanks for taking to develop these tests. Does your test simulate the dhcp server pushing a domain for resolution?
I don't think I have networkd ?
sudo systemctl list-units | grep network
[sudo] password for user:
  network-addresses-enp0s31f6.service                                                    loaded active exited    Address configuration of enp0s31f6
  network-addresses-wlp9s0.service                                                       loaded active exited    Address configuration of wlp9s0
  network-addresses-wwan0.service                                                        loaded active exited    Address configuration of wwan0
  network-local-commands.service                                                         loaded active exited    Extra networking commands.
  network-setup.service                                                                  loaded active exited    Networking Setup
  network-online.target                                                                  loaded active active    Network is Online
  network-pre.target                                                                     loaded active active    Preparation for Network
  network.target                                                                         loaded active active    Network

Does your test simulate the dhcp server pushing a domain for resolution

nope only pushing a dns server.

Is there a way to test that? To test that domain x.y.z gets written in /etc/resolv.con despite ignore-auto-dns.
Thank you again for the tests, it's really nice work!

Here another manual test at home. I have
[ipv4]
dns-search=
method=auto
# debugging https://github.com/NixOS/nixpkgs/issues/291868
ignore-auto-dns=yes

in my private configuration (this time directly edited in the file). I restart NetworkManager with systemctl restart NetworkManager.
Then:
resolvconf -l | head -3
# resolv.conf from NetworkManager
# Generated by NetworkManager
search fritz.box

Here I would expect search fritz.box to not be there. What do you think?

Rest of the file has also this:
# resolv.conf from wlp9s0.dhcp
# Generated by dhcpcd from wlp9s0.dhcp
domain fritz.box
search fritz.box
nameserver 192.168.178.1

Do you know how NetworkManager and dhcpcd interact ?

Do you know how NetworkManager and dhcpcd interact ?

Looking at the documentation on resolvconf it seems not relevant since the NetworkManager section printed by resolvconf -l should already not have search. What does resolvconf -l shows on your system? and if you add ignore-auto-dns=yes to your config?

Did you try setting https://search.nixos.org/options?channel=unstable&show=networking.interfaces.<name>.useDHCP&from=0&size=200&sort=relevance&type=packages&query=useDhcp to false?

It does not affect the output from resolvconf -l:
# resolv.conf from NetworkManager
# Generated by NetworkManager
nameserver $IP_OF_DNS

# resolv.conf from wlp9s0.dhcp
# Generated by dhcpcd from wlp9s0.dhcp
domain x.y.z
search x.y.z
nameserver $IP_OF_DNS

Maybe because the second entry is the one from the internal dhcp of NetworkManager.

Ok it seems the right setting is networking.dhcpcd.enable = false;. It works on my work network, I will try at home also.
I'm not sure why dhcpd is activated by default in Nix since the default configuration encourages to use NetworkManager anyway and it works without dhcpd?!
Do you think this is something that could be documented? We could add "Note that a domain can still ends up in /etc/resolv.conf when using resolvconf and other dhcp client such as the dhcpd which is enabled by default." to the setting.

Do you think this is something that could be documented? We could add "Note that a domain can still ends up in /etc/resolv.conf when using resolvconf and other dhcp client such as the dhcpd which is enabled by default." to the setting.

Sure, feel free to do a pr adding it to networking.useDHCP/networking.interfaces.<name>.useDHCP

More like in the documentation of networking.networkmanager.ensureProfiles.profiles.<name>.ipv4, right?

More like in the documentation of networking.networkmanager.ensureProfiles.profiles..ipv4, right?

networking.networkmanager.ensureProfiles.profiles.<name>.ipv4 doesn't have any explicit documentation since it's not really defined, networking.networkmanager.ensureProfiles.profiles just expects a attr-set of ini.type.
But I think we can close this issue for now since your problem is resolved?

I think so. Sorry for the confusion and many thanks for the help.

authors: Janik-Haag pallix


text:
Build failure: teck-programmer

Steps To Reproduce
Steps to reproduce the behavior:

build teck-programmer

Build log
@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
Running phase: configurePhase
no configure script, doing nothing
@nix { "action": "setPhase", "phase": "buildPhase" }
Running phase: buildPhase
@nix { "action": "setPhase", "phase": "installPhase" }
Running phase: installPhase
unpacking source archive /nix/store/c5pwfvci9ag1cy9alz6fmal8vsg82ch2-teck-programmer-1.1.1.tgz
unpacking source archive /nix/store/m05h86qxlfbg73xn40m8w8b8xjlprx0x-node-addon-api-4.3.0.tgz
unpacking source archive /nix/store/jw7b8b413skkb5jib0dl1z2ff1ga4bh7-node-gyp-build-4.8.0.tgz
unpacking source archive /nix/store/nbsqm17x64h6x92gxrbl4p4a1zjwkqv2-q-1.5.1.tgz
unpacking source archive /nix/store/bl3mdlpl5i8zz2r1ks4xfb8kxls2bqq2-usb-1.9.2.tgz
pinpointing versions of dependencies...
patching script interpreter paths in .
./teck-programmer/cli.js: interpreter directive changed from "#!/usr/bin/env node" to "/nix/store/vz13mi0w75q96sfjxz2y>
./teck-programmer/node_modules/node-addon-api/tools/conversion.js: interpreter directive changed from "#! /usr/bin/env>
./teck-programmer/node_modules/usb/libusb/bootstrap.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/>
./teck-programmer/node_modules/usb/libusb/autogen.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/08>
./teck-programmer/node_modules/usb/libusb/travis-autogen.sh: interpreter directive changed from "#!/bin/bash" to "/nix>
./teck-programmer/node_modules/usb/libusb/.private/pre-commit.sh: interpreter directive changed from "#!/bin/sh" to "/>
./teck-programmer/node_modules/usb/libusb/.private/post-rewrite.sh: interpreter directive changed from "#!/bin/sh" to >
./teck-programmer/node_modules/node-gyp-build/bin.js: interpreter directive changed from "#!/usr/bin/env node" to "/ni>
./teck-programmer/node_modules/node-gyp-build/build-test.js: interpreter directive changed from "#!/usr/bin/env node" >
./teck-programmer/node_modules/node-gyp-build/optional.js: interpreter directive changed from "#!/usr/bin/env node" to>
No package-lock.json file found, reconstructing...
Adding metadata fields to: node_modules/node-addon-api/package.json
Adding metadata fields to: node_modules/node-gyp-build/package.json
Adding metadata fields to: node_modules/q/package.json
Adding metadata fields to: node_modules/usb/package.json
npm WARN config production Use `--omit=dev` instead.
npm ERR! code 1
npm ERR! path /nix/store/whxlgj4369slg3xx5w9z7rzd8ryiamrv-teck-programmer-1.1.1/lib/node_modules/teck-programmer/node_>
npm ERR! command failed
npm ERR! command sh -c node-gyp-build
npm ERR! make: Entering directory '/nix/store/whxlgj4369slg3xx5w9z7rzd8ryiamrv-teck-programmer-1.1.1/lib/node_modules/>
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/core.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/descriptor.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/hotplug.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/io.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/strerror.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/sync.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/os/poll_posix.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/os/threads_posix.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/os/linux_usbfs.o
npm ERR!   CC(target) Release/obj.target/libusb/libusb/libusb/os/linux_udev.o
npm ERR! rm -f Release/obj.target/usb.a Release/obj.target/usb.a.ar-file-list; mkdir -p `dirname Release/obj.target/us>
npm ERR! ar crs Release/obj.target/usb.a @Release/obj.target/usb.a.ar-file-list
npm ERR!   COPY Release/usb.a
npm ERR!   CXX(target) Release/obj.target/usb_bindings/src/node_usb.o
npm ERR! make: Leaving directory '/nix/store/whxlgj4369slg3xx5w9z7rzd8ryiamrv-teck-programmer-1.1.1/lib/node_modules/t>
npm ERR! gyp info it worked if it ends with ok
npm ERR! gyp info using node-gyp@10.0.1
npm ERR! gyp info using node@20.11.1 | linux | x64
npm ERR! gyp info find Python using Python version 3.11.8 found at "/nix/store/sxr2igfkwhxbagri49b8krmcqz168sim-python>
npm ERR! gyp WARN read config.gypi ENOENT: no such file or directory, open '/nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50c>
npm ERR! gyp info spawn /nix/store/sxr2igfkwhxbagri49b8krmcqz168sim-python3-3.11.8/bin/python3
npm ERR! gyp info spawn args [
npm ERR! gyp info spawn args '/nix/store/vz13mi0w75q96sfjxz2ylnv8812hvf34-nodejs-20.11.1/lib/node_modules/npm/node_mod>
npm ERR! gyp info spawn args 'binding.gyp',
npm ERR! gyp info spawn args '-f',
npm ERR! gyp info spawn args 'make',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args '/nix/store/whxlgj4369slg3xx5w9z7rzd8ryiamrv-teck-programmer-1.1.1/lib/node_modules/teck->
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args '/nix/store/vz13mi0w75q96sfjxz2ylnv8812hvf34-nodejs-20.11.1/lib/node_modules/npm/node_mod>
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args '/nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/common.gypi',
npm ERR! gyp info spawn args '-Dlibrary=shared_library',
npm ERR! gyp info spawn args '-Dvisibility=default',
npm ERR! gyp info spawn args '-Dnode_root_dir=/nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources',
npm ERR! gyp info spawn args '-Dnode_gyp_dir=/nix/store/vz13mi0w75q96sfjxz2ylnv8812hvf34-nodejs-20.11.1/lib/node_modul>
npm ERR! gyp info spawn args '-Dnode_lib_file=/nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/$(Configuration>
npm ERR! gyp info spawn args '-Dmodule_root_dir=/nix/store/whxlgj4369slg3xx5w9z7rzd8ryiamrv-teck-programmer-1.1.1/lib/>
npm ERR! gyp info spawn args '-Dnode_engine=v8',
npm ERR! gyp info spawn args '--depth=.',
npm ERR! gyp info spawn args '--no-parallel',
npm ERR! gyp info spawn args '--generator-output',
npm ERR! gyp info spawn args 'build',
npm ERR! gyp info spawn args '-Goutput_dir=.'
npm ERR! gyp info spawn args ]
npm ERR! gyp info spawn make
npm ERR! gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
npm ERR! In file included from /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-object.h:9,
npm ERR!                  from /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-array-buffe>
npm ERR!                  from /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8.h:24,
npm ERR!                  from /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/src/node.h:73,
npm ERR!                  from /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/src/node_buffer.h:25,
npm ERR!                  from ../src/node_usb.h:14,
npm ERR!                  from ../src/node_usb.cc:1:
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:106:45: error: 'is_lvalue>
npm ERR!   106 |   template <class U, std::enable_if_t<!std::is_lvalue_reference_v<U>>*>
npm ERR!       |                                             ^~~~~~~~~~~~~~~~~~~~~
npm ERR!       |                                             is_lvalue_reference
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:106:66: warning: logical >
npm ERR!   106 |   template <class U, std::enable_if_t<!std::is_lvalue_reference_v<U>>*>
npm ERR!       |                                                                  ^
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:106:67: error: template a>
npm ERR!   106 |   template <class U, std::enable_if_t<!std::is_lvalue_reference_v<U>>*>
npm ERR!       |                                                                   ^
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:106:71: error: expected u>
npm ERR!   106 |   template <class U, std::enable_if_t<!std::is_lvalue_reference_v<U>>*>
npm ERR!       |                                                                       ^
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:123:43: error: 'is_lvalue>
npm ERR!   123 | template <class T, std::enable_if_t<!std::is_lvalue_reference_v<T>>* = nullptr>
npm ERR!       |                                           ^~~~~~~~~~~~~~~~~~~~~
npm ERR!       |                                           is_lvalue_reference
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:123:64: warning: logical >
npm ERR!   123 | template <class T, std::enable_if_t<!std::is_lvalue_reference_v<T>>* = nullptr>
npm ERR!       |                                                                ^
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:123:65: error: template a>
npm ERR!   123 | template <class T, std::enable_if_t<!std::is_lvalue_reference_v<T>>* = nullptr>
npm ERR!       |                                                                 ^
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/deps/v8/include/v8-maybe.h:123:70: error: expected u>
npm ERR!   123 | template <class T, std::enable_if_t<!std::is_lvalue_reference_v<T>>* = nullptr>
npm ERR!       |                                                                      ^
npm ERR! /nix/store/86r9krkcjgrcrvvrcc8mamg5il4d50cc-node-sources/src/node.h:711:28: error: 'std::string_view' has not>
npm ERR!   711 |     Environment* env, std::string_view main_script_source_utf8);
npm ERR!       |                            ^~~~~~~~~~~
npm ERR! ../src/node_usb.cc: In function 'Napi::Value SetDebugLevel(const Napi::CallbackInfo&)':
npm ERR! ../src/node_usb.cc:118:25: warning: 'void libusb_set_debug(libusb_context*, int)' is deprecated: Use libusb_s>
npm ERR!   118 |         libusb_set_debug(usb_context, info[0].As<Napi::Number>().Int32Value());
npm ERR!       |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
npm ERR! In file included from ../src/node_usb.h:11:
npm ERR! ../libusb/libusb/libusb.h:1325:18: note: declared here
npm ERR!  1325 | void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
npm ERR!       |                  ^~~~~~~~~~~~~~~~
npm ERR! make: *** [usb_bindings.target.mk:115: Release/obj.target/usb_bindings/src/node_usb.o] Error 1
npm ERR! gyp ERR! build error
npm ERR! gyp ERR! stack Error: `make` failed with exit code: 2
npm ERR! gyp ERR! stack at ChildProcess.<anonymous> (/nix/store/vz13mi0w75q96sfjxz2ylnv8812hvf34-nodejs-20.11.1/lib/no>
npm ERR! gyp ERR! System Linux 6.1.78
npm ERR! gyp ERR! command "/nix/store/vz13mi0w75q96sfjxz2ylnv8812hvf34-nodejs-20.11.1/bin/node" "/nix/store/vz13mi0w75>
npm ERR! gyp ERR! cwd /nix/store/whxlgj4369slg3xx5w9z7rzd8ryiamrv-teck-programmer-1.1.1/lib/node_modules/teck-programm>
npm ERR! gyp ERR! node -v v20.11.1
npm ERR! gyp ERR! node-gyp -v v10.0.1
npm ERR! gyp ERR! not ok

npm ERR! A complete log of this run can be found in: /build/.npm/_logs/2024-03-01T10_43_48_416Z-debug-0.log

Additional context
Since c4b3cc031e051233d7dfa6f124db215d0fb31224, nodejs 20. Might be an upstream incompatibility I don't know nodejs internals too well.
Notify maintainers
@bbjubjub2494
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.78, NixOS, 23.11 (Tapir), 23.11.20240220.526d051`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/etc/nix/channels/nixos`

Add a :+1: reaction to issues you find important.

That's fair.


text:
nvidia-container-runtime fails to run containers with the -it flag

Describe the bug
When passing --runtime nvidia to docker and the -it flag is passed, the following error is output:
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: /nix/store/va74ykggqzmamwh2aj39fxlwzf8csw6s-nvidia-docker/bin/nvidia-container-runtime did not terminate successfully: exit status 125: unknown flag: --root
See 'docker --help'.
...

Steps To Reproduce
Steps to reproduce the behavior:

Run:

docker run --runtime nvidia --rm --gpus all -ti docker.io/nvidia/vulkan:1.3-470 vulkaninfo

Expected behavior
The container runs properly.
Notify maintainers
@averelld (author of commit that added the virtualisation.docker.enableNvidia option)
@cpcloud (nvidia-docker maintainer)
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.32, NixOS, 24.05 (Uakari), 24.05.675.805a384895c6`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - channels(root): `"nixos-24.05, nixos-21.11-21.11, nixos-23.05-23.05, nixos-23.11-23.11, nixos-24.05-24.05, nixos-unstable, nixpkgs"`
 - channels(raskolnikov): `"nixpkgs"`
 - nixpkgs: `/home/raskolnikov/.nix-defexpr/channels/nixpkgs`

Add a :+1: reaction to issues you find important.

Tried podman as workaround, got a different error:
podman run --runtime nvidia --rm --gpus all docker.io/nvidia/vulkan:1.3-470 vulkaninfo
WARN[0000] Using cgroups-v1 which is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version. Set environment variable `PODMAN_IGNORE_CGROUPSV1_WARNING` to hide this warning.
Error: nvidia: time="2024-06-25T14:32:14+02:00" level=error msg="runc create failed: unable to start container process: error during container init: error mounting \"/nix/store/2vh0agm3gq8nqp9ql2wsg2kbj7nsihp7-nvidia-x11-470.239.06-6.6.32-bin/bin/nvidia-powerd\" to rootfs at \"/usr/bin/nvidia-powerd\": stat /nix/store/2vh0agm3gq8nqp9ql2wsg2kbj7nsihp7-nvidia-x11-470.239.06-6.6.32-bin/bin/nvidia-powerd: no such file or directory": OCI runtime attempted to invoke a command that was not found

Also for completenes::
  virtualisation.docker.enable = true;
  virtualisation.docker.enableNvidia = true;
  virtualisation.podman.enable = true;
  virtualisation.podman.enableNvidia = true;
  systemd.enableUnifiedCgroupHierarchy = false;
  hardware.nvidia-container-toolkit.enable = true;

Fixed the last error with: https://github.com/NixOS/nixpkgs/issues/319201
  hardware.nvidia-container-toolkit.mount-nvidia-executables = false;

Now I get:
sudo podman run --runtime nvidia --rm --gpus all docker.io/nvidia/vulkan:1.3-470 vulkaninfo
WARN[0000] Using cgroups-v1 which is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version. Set environment variable `PODMAN_IGNORE_CGROUPSV1_WARNING` to hide this warning.
Trying to pull docker.io/nvidia/vulkan:1.3-470...
Getting image source signatures
Copying blob ebf96a6776b2 done   |
Copying blob ea362f368469 done   |
Copying blob 33ad2f6e0261 done   |
Copying blob 9b499af792c6 done   |
Copying blob 91ce2d96e937 done   |
Copying blob c04906891ebc done   |
Copying blob dfd3c8943767 done   |
Copying blob 49eaa5311171 done   |
Copying config 4a99e30b38 done   |
Writing manifest to image destination
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
ERROR at /vulkan-sdk/1.3.204.1/source/Vulkan-Tools/vulkaninfo/vulkaninfo.h:649:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER

Strange as:
nvidia-smi
Tue Jun 25 14:35:30 2024
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.239.06   Driver Version: 470.239.06   CUDA Version: 11.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:2D:00.0  On |                  N/A |
|  0%   49C    P5    32W / 270W |    558MiB /  7979MiB |      3%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      1944      G   ...xorg-server-21.1.13/bin/X      371MiB |
|    0   N/A  N/A      4823      G   ...26.0/bin/.firefox-wrapped      184MiB |
+-----------------------------------------------------------------------------+

Ok, managed to get it to work with podman. The problem persists with docker.

CDI support, included in Docker 25, and in Podman since a long time ago, should be the way to go to expose GPU's to containers.
You can set hardware.nvidia-container-toolkit.enable and virtualisation.docker.package  to pkgs.docker_25 at least (until https://github.com/NixOS/nixpkgs/pull/330130 merges).
With CDI you can run docker run --rm --device=nvidia.com/gpu=all ubuntu:latest nvidia-smi or podman run --rm --device=nvidia.com/gpu=all ubuntu:latest nvidia-smi.

The following 3 settings are somehow broken, or the error/warning messages are broken, I get the following:
 - trace: warning: The option
   `virtualisation.containers.cdi.dynamic.nvidia.enable' defined in
   `/nix/store/05mr6xlxl0zxpvpbryjz4vi5m241njd0-source/newnixsetup/machines/hq/configuration.nix'
   has been renamed to `hardware.nvidia-container-toolkit.enable'.
 - trace: warning: You have set virtualisation.docker.enableNvidia. This option is
   deprecated, please set virtualisation.containers.cdi.dynamic.nvidia.enable
   instead.

These two errors come together which means only setting
hardware.nvidia-container-toolkit.enable should solve everything,
but it does not so we need to keep using deprecated settings but now we get warnings.
something seems broken.

Hello @geekodur!
virtualisation.containers.cdi.dynamic.nvidia.enable, same as virtualisation.docker.enableNvidia are both deprecated.
The right setting is hardware.nvidia-container-toolkit.enable.

If I just set hardware.nvidia-container-toolkit.enable, I get could not select device driver "" with capabilities: [[gpu]].: https://github.com/NVIDIA/nvidia-docker/issues/1034 which points to 	nvidia-container-toolkit not installing the toolkit correctly plus I cannot access nvidia-ctk on my PATH.

This problem points to having an old Docker version. The default docker version as of now in nixpkgs in 24.05 is Docker 24, which does not have support for CDI. This default is being bumped in https://github.com/NixOS/nixpkgs/pull/330109.
Until https://github.com/NixOS/nixpkgs/pull/330109 merges, you need to set virtualisation.docker.package to pkgs.docker_25.
However, I agree that virtualisation.docker.enableNvidia suggesting virtualisation.containers.cdi.dynamic.nvidia.enable is an overlook on our side, and it should suggest hardware.nvidia-container-toolkit.enable instead. I have created https://github.com/NixOS/nixpkgs/pull/330617 to fix this issue.

Until https://github.com/NixOS/nixpkgs/pull/330109 merges, you need to set virtualisation.docker.package to pkgs.docker_25.

Do we not have assertions = [ ... ] for that?
We could also change the default when CDI is enabled

Do we not have assertions = [ ... ] for that?

I'll add one later today.

We could also change the default when CDI is enabled

I'd say it's safer to put an assertion, instead of bumping Docker without the user noticing to a different default.

This problem points to having an old Docker version. The default docker version as of now in nixpkgs in 24.05 is Docker 24

I am using  pkgs.docker_25; I even tried bumping it upto 27. no dice.
But I was wondering why after enabling hardware.nvidia-container-toolkit.enable there's no nvidia-ckt in the path and only the latter of the following 2 work:
# workes when  cdi disabled but stops working when cdi enabled
docker run --rm --gpus all nvidia/cuda:12.0.0-base-ubuntu20.04 nvidia-smi

# works when using cdi enabled, but nvidia-ctk will be missing in path
docker run --rm --device=nvidia.com/gpu=all nvidia/cuda:12.0.0-base-ubuntu20.04 nvidia-smi

Thanks a lot for quick reply @ereslibre ! I am trying use nixos+nomad+docker+nvidia: mentioned in details here: https://github.com/hashicorp/nomad-device-nvidia/issues/48 and I am a bit unclear if CDI is forward compatible with these orchestration tools(nomad/k8s) or we still need to keep supporting non-cdi ways, which as mentioned above gets broken when using cdi.
Apologies for dumping in a lot of questions in a separate issue, just got confused!

λ docker info|grep -i runtime
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc

After setting daemon settings:
  hardware.nvidia-container-toolkit.enable = true; # TODO: this is the newer one
  virtualisation.docker = {
    # enableNvidia = true; # deprecated usage (but sets runtime and executables correctly in the host)
    package = pkgs.docker_25;
    daemon.settings = {
        default-runtime = "nvidia";
        runtimes.nvidia.path = "${pkgs.nvidia-docker}/bin/nvidia-container-runtime";
        exec-opts = ["native.cgroupdriver=cgroupfs"];
    };
  };

λ docker info|grep -i runtime
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: nvidia

Is ardware.nvidia-container-toolkit.enable supposed to update the daemon settings that I had to set manually here?^

But I was wondering why after enabling hardware.nvidia-container-toolkit.enable there's no nvidia-ckt in the path and only the latter of the following 2 work:

Enabling hardware.nvidia-container-toolkit.enable does not put nvidia-ctk in the PATH. It creates a systemd unit (nvidia-container-toolkit-cdi-generator.service that calls to nvidia-ctk cdi generate and puts the result (after massagging the JSON) into /var/run/cdi/nvidia-container-toolkit.json.
With CDI, you don't specify the GPU's as you do with the runtime wrappers. So the second option with CDI is the correct one (--device=nvidia.com/gpu=all), not the first one (--gpus all).
With CDI also, there's no need for wrappers, so this:
    daemon.settings = {
        default-runtime = "nvidia";
        runtimes.nvidia.path = "${pkgs.nvidia-docker}/bin/nvidia-container-runtime";
        exec-opts = ["native.cgroupdriver=cgroupfs"];
    };

can go away entirely. CDI completely removes the need for runtime wrappers. However, I don't know about nomad. I would be willing to help in whatever is needed though.

Thanks a lot @ereslibre for the detailed explanation, super helpful!
I finally got this to work with nomad with a very hacky combination: https://github.com/hashicorp/nomad-device-nvidia/issues/48#issuecomment-2254576364 (described here) but this combination uses enableNvidia so I think even if we show the deprecation warning, I think we should not remove enableNvidia totally in the next release etc until this gets fixed if that's being planned.
Let me know what do you think of this!

@geekodour maybe it's worth opening a specific issue about nomad + NixOS + Nvidia. However, and without having worked with nomad at all, I see we have:

services.nomad.enableDocker: this sets virtualisation.docker.enable.

From what I understand, you can configure Nomad to use the Docker socket, like so:
plugin "docker" {
  config {
    endpoint = "unix:///var/run/docker.sock"
    ...
  }
  ...
}

You can configure NixOS, so that Docker is able to use the nvidia-container-toolkit to generate the CDI spec, and configure Docker to use the CDI experimental feature:
hardware.nvidia-container-toolkit.enable = true;
virtualisation.docker.package = pkgs.docker_25;
...

With the previous settings, the docker daemon will be correctly configured to use CDI, and since Nomad is using the Docker socket, so that it should be capable of using GPU's. Now, the only remaining part is how Nomad tells the Docker socket "--device=nvidia.com/gpu=all" when it creates a container using the socket API. Looking at https://github.com/docker/cli/pull/4084/files#diff-e546b85d27f9dbea4fd41e83a58e36bb540bcda3e304355d56c92a119cd5aa2aR568-R575, I assume Nomad needs to pass the deviceRequests with something like the following:
[]container.DeviceRequest{
  {
    Driver:    "cdi",
    DeviceIDs: []string{"nvidia.com/gpu=all"},
  },
},

I guess this needs to be adapted on the Docker driver for Nomad.

@ereslibre sorry, but I'm trying to setup linuxserver.io/jellyfin with support for nvidia but until now I got no success whatsoever.
According to the linuxserver documentation, one has to use --runtime=nvidia. Also according to the official jellyfin docs, it's necessary to add a deploy section, though I'm not entirely sure if it's needed for the linuxserver.io image.
I'm using a docker compose so I have the following:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - JELLYFIN_PublishedServerUrl=${JELLYFIN_URL} # optional
      - NVIDIA_VISIBLE_DEVICES=all
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: ["gpu"]

I followed the nixos docs to enable nvidia driver
	hardware = {
		graphics.enable = true;
		nvidia-container-toolkit.enable = true;
		nvidia = {
			# Modesetting is required.
			modesetting.enable = true;
			powerManagement = {
				enable = false;
				finegrained = false;
			};
			open = false;
			nvidiaSettings = true;
			nvidiaPersistenced = true;
			package = config.boot.kernelPackages.nvidiaPackages.stable;
		};
	};

	services = {
		xserver = {
			enable = false;  # this is a headless machine
			videoDrivers = ["nvidia"];
		};
	};

        virtualisation.docker.package = pkgs.docker_25;

I'm running unstable 24.11.20240804.cb9a96f (Vicuna).
systemctl status nvidia-container-toolkit-cdi-generator.service gives:
● nvidia-container-toolkit-cdi-generator.service - Container Device Interface (CDI) for Nvidia generator
     Loaded: loaded (/etc/systemd/system/nvidia-container-toolkit-cdi-generator.service; enabled; preset: enabled)
     Active: active (exited) since Fri 2024-08-09 17:26:18 -03; 37min ago
 Invocation: 3e560b7cf4444eff9b5fc1cac7e67136
   Main PID: 963 (code=exited, status=0/SUCCESS)
   Mem peak: 41.9M
        CPU: 138ms

Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=info msg="Selecting /nix/store/6ysl62ncf5gifwvdky69pzzkgxckhrcm-firmware/lib/firmware/nvidia/555>
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia-smi: pattern nvidia-smi not found"
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia-debugdump: pattern nvidia-debugdump not found"
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia-persistenced: pattern nvidia-persistenced not found"
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia-cuda-mps-control: pattern nvidia-cuda-mps-control not found"
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia-cuda-mps-server: pattern nvidia-cuda-mps-server not found"
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia/xorg/nvidia_drv.so: pattern nvidia/xorg/nvidia_drv.so not f>
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=warning msg="Could not locate nvidia/xorg/libglxserver_nvidia.so.555.58.02: pattern nvidia/xorg/>
Aug 09 17:26:17 coolermaster nvidia-cdi-generator[977]: time="2024-08-09T17:26:17-03:00" level=info msg="Generated CDI spec with version 0.5.0"
Aug 09 17:26:18 coolermaster systemd[1]: Finished Container Device Interface (CDI) for Nvidia generator.

If I run docker run --rm --device=nvidia.com/gpu=all lscr.io/linuxserver/jellyfin nvidia-smi, I do in fact get a running container with the nvidia-smi output correct. But each time I run docker compose up jellyfin I get Error response from daemon: unknown or invalid runtime name: nvidia. What am I missing here? How can I run docker compose and get the container with nvidia support?

@leoperegrino it seems like you've hit similar issues like mine: https://github.com/NixOS/nixpkgs/issues/322400#issuecomment-2254576903 I think the issue has to be fixed upstream in the package you're using similar to how some change would be needed in nomad in my case( I am yet to make that PR to nomad)
But I'd suggest, try the workaround that I suggested in my comment. It requires a downgrade but worked for me. But the longterm fix will be what @ereslibre mentioned in this(https://github.com/NixOS/nixpkgs/issues/322400#issuecomment-2255477537) comment.

@geekodour Thank you for the reply. The only way I managed to run with docker compose was with the following options:
virtualisation.docker.enableNvidia = true;
hardware.graphics.enable32Bits = true;

and removing runtime: nvidia from the docker-compose.yaml snippet I posted in my last comment.
Though I could use the non-deprecated option hardware.nvidia-container-toolkit.enable and run it with a docker run script like this:
# insert your other cli options as needed
exec docker run \
    --detach \
    --device=nvidia.com/gpu=all \
    --name jellyfin \
    --restart unless-stopped \
    --env NVIDIA_VISIBLE_DEVICES=all \
    lscr.io/linuxserver/jellyfin

it is not very ideal to have it outside of the compose project I manage with lots of other integrated services.
Until nvidia-container-toolkit is not able to support this use case of docker compose, I'll unfortunately keep the deprecated enableNvidia option.

Bit unfortunate this changed mid 24.05. Isn't this supposed to be a stable release?

Bit unfortunate this changed mid 24.05. Isn't this supposed to be a stable release?

this was due to security vulnerability in docker v24
if you switch to hardware.nvidia-container-toolkit.enable docker nvidia will work again, just need to use new args to pass GPU
eg
 --device=nvidia.com/gpu=0

To use cdi with docker-compose one is supposed to do:
    deploy:
      resources:
        reservations:
          devices:
           - driver: cdi
             device_ids:
                - nvidia.com/gpu=all

From what I found after bouncing around in github.

Just to add to https://github.com/NixOS/nixpkgs/issues/322400#issuecomment-2336724982, you can choose specific devices to be exposed by their ID. Had you say, 5 GPU's, if you wanted to expose 1, 3 and 5 only you can do:
    deploy:
      resources:
        reservations:
          devices:
           - driver: cdi
             device_ids:
                - nvidia.com/gpu=1
                - nvidia.com/gpu=3
                - nvidia.com/gpu=5

@ereslibre @leiserfg
thank you for the hint! I was able to reproduce with hardware.graphics and hardware.nvidia-container-toolkit enabled using nixos unstable (24.11.20240906.574d1ea (Vicuna)).
Using 24.05 (24.05.20240817.c42fcfb (Uakari)) I had no success. I went through a bunch of different errors including:

nvidia-container-toolkit-cdi-generator.service giving level=error msg="failed to generate CDI spec: failed to create device CDI specs: failed to initialize NVML: ERROR_LIBRARY_NOT_FOUND"
docker compose giving Error response from daemon: CDI device injection failed: unresolvable CDI devices nvidia.com/gpu=all

Didn't exactly tracked what was causing what but finally got it working in unstable and with driver: cdi.

Hello @leoperegrino!

nvidia-container-toolkit-cdi-generator.service giving level=error msg="failed to generate CDI spec: failed to create device CDI specs: failed to initialize NVML: ERROR_LIBRARY_NOT_FOUND"

Maybe you forgot to add nvidia to services.xserver.videoDrivers = ["nvidia"];? I think we should probably do this automatically when you enable hardware.nvidia-container-toolkit.

Error response from daemon: CDI device injection failed: unresolvable CDI devices nvidia.com/gpu=all

This was probably related to the previous error. If the nvidia-container-toolkit cdi generate command fails, the file /var/run/cdi/nvidia-container-toolkit.json will be empty, so that when you do docker|podman run --device nvidia.com/gpu=all, this is not found and causes this "unresolvable CDI devices" error.

@ereslibre
I did put the video driver configuration so I don't think that was the issue. But your comment made me realize one thing that could be the cause. Since I'm deploying this flake in a headless machine, which I access only through ssh, I had services.xserver.enabled = false;. I assumed that xserver would only be needed if had GUI/DEs.
Looking at nixpkgs I see that the drivers are only inserted if xserver is enabled, which should result in missing drivers.
Should one enable xserver in this case even without GUI applications? If the xserver is only needed to insert the drivers, I guess hardware.nvidia-container-toolkit should insert by itself.
I'm not sure why using unstable with hardware.graphics worked, though.

I did put the video driver configuration so I don't think that was the issue. But your comment made me realize one thing that could be the cause. Since I'm deploying this flake in a headless machine, which I access only through ssh, I had services.xserver.enabled = false;. I assumed that xserver would only be needed if had GUI/DEs.

This is the same for me, my machine is headless and I access through SSH. However I still have to set services.xserver.videoDrivers = ["nvidia"];. I also have services.xserver.enable unset (so the default is false).
What's important is that when you alter services.xserver.videoDrivers and run the activation, you need to restart the machine for that to take effect.
Could it be that you had the nvidia value in the services.xserver.videoDrivers, and that it didn't work until you restarted the machine?

I did restarted but kept getting those error still. Eventually if I find anything new, I'll get back here. Thanks!

Can confirm I had to enable xserver with nvidia and reboot to get this going.
The compose CDI driver snippet was immensely helpful. Thank you for sharing that.

Hello @ironicbadger!

Can confirm I had to enable xserver with nvidia and reboot to get this going.

With this, you mean you had to do services.xserver.enable = true; as in the config you show? It shouldn't be necessary to do that if it's a headless machine. Can you confirm?
Besides that, in your config, some comments:

The settings you have hardware.nvidia.* are also optional, no need to specify them.
virtualisation.docker.enableNvidia can be removed.
virtualisation.docker.package can be removed if you are on unstable greater than https://github.com/NixOS/nixpkgs/pull/330109/commits/b381163c0b6e97395d9750d7abc591d9f745112f, given this commit sets Docker 27 as the new default.

So, in principle, the minimum viable config in your case should be:
  virtualisation.docker.enable = true;
  hardware.nvidia-container-toolkit.enable = true;
  services.xserver.videoDrivers = [ "nvidia" ];

For a headless machine, and:
  virtualisation.docker.enable = true;
  hardware.nvidia-container-toolkit.enable = true;
  services.xserver = {
    enable = true;
    videoDrivers = [ "nvidia" ];
  };

For a non-headless machine. I am trying to confirm all this because I'm working on the documentation of this feature, and I'd like to double check that I'm not missing anything. Please, if you have the time it would be amazing if you could confirm that the minimum configuration I did show works for you too. Thank you!

By the way, @ereslibre I see that nvidia-container-toolkit and libnvidia-container are outdated (the last one is two years old already).

By the way, @ereslibre I see that nvidia-container-toolkit and libnvidia-container are outdated (the last one is two years old already).

I'm not super interested in bumping libnvidia-container myself. It's used by the nvidia-container-runtime, but I prefer the CDI approach myself.
That said, feel free to bump libnvidia-container and nvidia-container-toolkit, I don't see any PR's open bumping them.

Is there a possibility of a race condition on computer boot for setting up the cdi configuration? Everytime the computer restarts the docker daemon is unable to start those with driver: cdi. sytemctl logs:
msg="failed to start container" container=c20614b2a2f6965fa6364584df66d6094b6a44aef0b406a96c0b794db280510d error="could not select device driver \"cdi\" with capabilities: [[]]"
running docker compose up after boot does work though.

How are they being executed @leoperegrino? Please open a new issue as we are mixing a ton of different and potentially unrelated things here.
If it was a race condition due to the CDI spec not being available, the error would read "unresolvable CDI devices":
❯ docker run -it --rm --device=this-vendor.com/does-not-exist-at=all ubuntu:latest
docker: Error response from daemon: CDI device injection failed: unresolvable CDI devices this-vendor.com/does-not-exist-exist-at=all.

@ereslibre yeah, sorry for belabouring. I used with the following snippet and docker daemon should start all containers according to the restart specification.

To use cdi with docker-compose one is supposed to do:
    deploy:
      resources:
        reservations:
          devices:
           - driver: cdi
             device_ids:
                - nvidia.com/gpu=all

From what I found after bouncing around in github.

@leoperegrino Please, open a new issue and we can follow up there. Thanks :)

@ereslibre Hi, sorry for bumping again this thread but now I've got some insights related to our previous discussion. I managed to run in stable using the previously corrected deploy:

   deploy:
      resources:
        reservations:
          devices:
           - driver: cdi
             device_ids:
                - nvidia.com/gpu=all

I was not being able to run this way in stable before because hardware.graphics option does not exist right now. I found out that the option was renamed in this commit from hardware.opengl, which we didn't mention in our debugging.
I noticed that without that option my /var/run/cdi/nvidia-container-toolkit.json was empty despite enabling hardware.nvidia-container-toolkit, which caused errors such as CDI device injection failed: unresolvable CDI devices nvidia.com/gpu=all.
In summary, in nixos stable (24.05.20240817.c42fcfb), I'm running these options:
  hardware = {
    opengl.enable = true;
    nvidia-container-toolkit.enable = true;
    nvidia = {
       ...
    };
  };

  services = {
    xserver = {
      enable = false;
      videoDrivers = [ "nvidia" ];
    };
  };

I hope that this discussion was helpful for you as it was for me, since you said that you are the one documenting this. Might be helpful to have in mind the different options for different branches.
Thanks!

Thank you for the followup @leoperegrino

Hi @leoperegrino. Sorry to necropost but can you send your final jellyfin & hardware configurations? I'm running into the exact same issue but I'm not sure what I'm missing

@jackheuberger my final configuration is the one in my last comment even though with that I didn't manage to solve the lack of restart. Right now I'm not using that machine so I can't help much besides the comments written here. Pay attention to your nixos version and which option should you use.

authors: SomeoneSerge arximboldi ereslibre geekodour ironicbadger jackheuberger kirillrdy leiserfg leoperegrino


text:
Build failure: quickgui

Steps To Reproduce
Steps to reproduce the behavior:

build quickgui

Build log
https://gist.github.com/LuNeder/271b9a730e039e8e12a3296ddea6936a
Additional context
Failed obtaining PRETTY_NAME for Linux: PathNotFoundException: Cannot open file, path = '/usr/lib/os-release' (OS Error: No such file or directory
, errno = 2)
[...]
 /nix/store/4wj8q7c8fjk9j7xw6iiz7r4qrpg6gc6y-flutter-sdk-flutter/lib/src/material/color_scheme.dart:1915:39: Error: Method not found: 'SchemeRainbo
w'.
[        ] [   +1 ms]       DynamicSchemeVariant.rainbow => SchemeRainbow(sourceColorHct: sourceColor, isDark: isDark, contrastLevel: contrastLevel),
[        ] [        ]                                       ^^^^^^^^^^^^^
[        ] [        ] /nix/store/4wj8q7c8fjk9j7xw6iiz7r4qrpg6gc6y-flutter-sdk-flutter/lib/src/material/color_scheme.dart:1916:42: Error: Method not found: 'SchemeFruitS
alad'.

Notify maintainers

@flexiondotorg  @heyimnova
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 ✘ luana@Luana-X670E  ~  nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.10.6, NixOS, 24.11 (Vicuna), 24.11.20240821.c374d94`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - nixpkgs: `/nix/store/j8pbrsb3nybdap3hhg9kw0ffqd4rlbx6-source`

Add a :+1: reaction to issues you find important.

Can confirm, just swapped to 24.11 and encountered this.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/i-cant-rebuild-my-system/56978/2

authors: LuNeder llakala nixos-discourse


text:
VirtualBox: Can't find help file

Describe the bug
I was tweaking VM settings and clicked on the "Help" button. An error says can't be found.
Steps To Reproduce
Steps to reproduce the behavior:

Expected behavior
Help works.
Screenshots
See STR
Notify maintainers

@svanderburg @FriedrichAltheide @blitz
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.54, NixOS, 24.05 (Uakari), 24.05.20241007.1bfbbbe`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.24.8`
 - nixpkgs: `/nix/store/a2gnsay8asfn2kqghz12nhw196cnmf8h-source`

Add a :+1: reaction to issues you find important.

@yajo please create a PR with a fix :)

I don't know how to fix that... Do you have any clues?

As virtualbox can not find a specific file (cf. the error message), you should check if the docs are already build/available. If not, ensure that they are build. If they are already build/available, you would likely have to copy / symlink the files (https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/virtualization/virtualbox/default.nix) so that they are reachable / usable once the build finished.

authors: FriedrichAltheide yajo


text:
initrd-find-system-closure fails passing --symbolic to busybox ln

Describe the bug
The system where I have boot.initrd.systemd.enable = true; has recently stopped booting, failing in the initrd-find-system-closure.service step. The journal has busybox ln complaining that it is passed --symbolic.
Steps To Reproduce
Steps to reproduce the behavior:

Set boot.initrd.systemd.enable to true, set the system closure to bootable
reboot
See "Find NixOS Closure" fail

Expected behavior
System should boot
Screenshots

Additional context
Seems the line that fails is https://github.com/NixOS/nixpkgs/blame/109f05c89daecd824dd1d367dd3dce744d706933/nixos/modules/system/boot/systemd/initrd.nix#L554; I suspect it might be necessary to add coreutils to the PATH above...
Metadata

(sorry, impossible to do on this unbootable system right now. I'll try and recover from a USB key)
Notify maintainers
@r-vdp and I think @ElvishJerricco?

Note for maintainers: Please tag this issue in your PR.

Add a :+1: reaction to issues you find important.

Update: busybox happens to be providing ln because my configuration also sets
      boot.initrd.systemd.initrdBin = [
          (pkgs.busybox.overrideAttrs (o: {meta.priority = 0;}))
          # among other things
      ];

for ssh-ability, which up until something called ln with args bb doesn't understand worked well.
I think the initrd-find-system-closure.service script probably should still pull in coreutils-full using the PATH trick above to be resilient to users hitting themselves.


text:
R example fails with ld: library not found for -liconv

Issue description
I am trying to run a Jupyter notebook using the example here: https://nixos.wiki/wiki/R#Jupyter_Notebook
Steps to reproduce
nix-shell shellR.nix -I nixpkgs=https://github.com/nixos/nixpkgs-channels/archive/nixos-unstable-small.tar.gz

ld: library not found for -liconv
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/nix/store/k3v4j8g34hznydwss2vdzlzin67yms3d-R-3.5.0/lib/R/share/make/shlib.mk:6: xts.so] Error 1
ERROR: compilation failed for package 'xts'
* removing '/nix/store/hincd8sigckq2clnha6pqh0ynv75acl1-r-xts-0.10-2/library/xts'
builder for ‘/nix/store/bhi6vdpvkv55xfm3jlwn9wkgn1sgipch-r-xts-0.10-2.drv’ failed with exit code 1
cannot build derivation ‘/nix/store/xyhb17jznly6shb5amhhbzrxlmsf6a11-R-3.5.0-wrapper.drv’: 1 dependencies couldn't be built
error: build of ‘/nix/store/xyhb17jznly6shb5amhhbzrxlmsf6a11-R-3.5.0-wrapper.drv’ failed
/nix/var/nix/profiles/default/bin/nix-shell: failed to build all dependencies

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
 - system: `"x86_64-darwin"`
 - host os: `Darwin 17.3.0, macOS 10.13.2`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 1.11.15`
 - channels(root): `"nixpkgs-18.03pre122117.14df60d0db9"`
 - channels(dom): `"nixpkgs-18.09pre142380.23f2dfd9f5a"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

I am not getting the iconv issue on master.

Tentatively closing this since bauer said he didn't see it on master, and there hasn't been any more activity.
Feel free to squeak if this is still a problem--I'll happily reopen it.

Tentatively closing this since bauer said he didn't see it on master, and there hasn't been any more activity.
Feel free to squeak if this is still a problem--I'll happily reopen it.

I've been getting this using master for the past week or so and always failing on compiling procs v0.11.4 with rust. What's funny is I have the exact same Nix setup on my work computer (Macbook Pro from 2018 with latest macOS), but the error is on my personal Macbook Pro from 2013 running Catalina 10.15.7.
This exact error seems to be happening with any rust-based nix package.

Expand this to see the error

   Compiling toml v0.5.8
   Compiling hyper v0.13.10
   Compiling hyperlocal v0.7.0
   Compiling dockworker v0.0.22
   Compiling procs v0.11.4 (/private/tmp/nix-build-procs-0.11.4.drv-0/source)
error: linking with `/nix/store/kdb6mr4whml4dlyxbwhsv4zy90qbmbk4-clang-wrapper-7.1.0/bin/cc` failed: exit code: 1
  |
  = note: "/nix/store/kdb6mr4whml4dlyxbwhsv4zy90qbmbk4-clang-wrapper-7.1.0/bin/cc" "-m64" "-arch" "x86_64" "-L" "/nix/store/dkd2mzd27flf75g9nprg0civx9hwgchh-rustc-1.50.0/lib/rustlib/x86_64-apple-darwin/lib" "/private/tmp/nix-build-procs-0.11.4.drv-0/source/target/x86_64-apple-darwin/release/deps/procs.procs.hv73vwnx-cgu.0.rcgu.o" "-o" "/private/tmp/nix-build-procs-0.11.4.drv-0/source/target/x86_64-apple-darwin/release/deps/procs" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/private/tmp/nix-build-procs-0.11.4.drv-0/source/target/x86_64-apple-darwin/release/deps" "-L" "/private/tmp/nix-build-procs-0.11.4.drv-0/source/target/release/deps" "-L" "/private/tmp/nix-build-procs-0.11.4.drv-0/source/target/x86_64-apple-darwin/release/build/backtrace-sys-51a7809984259ee0/out" "-L" "/nix/store/dkd2mzd27flf75g9nprg0civx9hwgchh-rustc-1.50.0/lib/rustlib/x86_64-apple-darwin/lib" "/nix/store/dkd2mzd27flf75g9nprg0civx9hwgchh-rustc-1.50.0/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-36c5611c149fc184.rlib" "-lc" "-lproc" "-lproc" "-lproc" "-lproc" "-liconv" "-lSystem" "-lresolv" "-lc" "-lm"
  = note: ld: library not found for -liconv
          clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to previous error
error: could not compile procs

Here are my system details:
 - system: `"x86_64-darwin"`
 - host os: `Darwin 19.6.0, macOS 10.15.7`
 - multi-user?: `no`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.4pre20210317_8a5203d`
 - channels(rpearce): `"home-manager, nixpkgs-21.05pre277683.4e0d3868c67"`
 - nixpkgs: `/Users/rpearce/.nix-defexpr/channels/nixpkgs`

@rpearce I'm not specifically familiar, but I get the impression from reading other issues that missing libiconv is a common/general macOS package issue. How recently did you pull master? It looks like your specific case might be fixed in #117559. (There may also be a new issue in master--it is fairly common :)
If there's a persistent difference between the two systems at the same nixpkgs commit, it's probably worth a new issue.

@abathur That looks like it'll definitely fix it. I pull master almost daily, and I didn't have the time to look into it for a week or so. Thanks for that link! I'll leave this thread alone

authors: abathur idontgetoutmuch matthewbauer rpearce


text:
blockhash: doesn't build on darwin

Issue description
haskellPackages.blockhash fails to build on darwin.
Steps to reproduce
nix-env -iA nixos.haskellPackages.blockhash

yields:

Configuring blockhash-0.1.0.0...
Setup: Encountered missing dependencies:
optparse-applicative ==0.12., vector ==0.11.
builder for ‘/nix/store/4al8n274lx860a7jzx4aq8f2w3j2lfd4-blockhash-0.1.0.0.drv’ failed with exit code 1

nix-env -iA nixpkgs.haskellPackages.blockhash

yields:

Configuring blockhash-0.1.0.0...
CallStack (from HasCallStack):
die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:958:20 in Cabal-2.2.0.1:Distribution.Simple.Configure
configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:462:12 in Cabal-2.2.0.1:Distribution.Simple.Configure
configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:596:20 in Cabal-2.2.0.1:Distribution.Simple
confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.2.0.1:Distribution.Simple.UserHooks
configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:178:19 in Cabal-2.2.0.1:Distribution.Simple
defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:115:27 in Cabal-2.2.0.1:Distribution.Simple
defaultMain, called at Setup.hs:2:8 in main:Main
Setup: Encountered missing dependencies:
optparse-applicative ==0.12., vector ==0.11.

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

system: "x86_64-darwin"
host os: Darwin 16.7.0, macOS 10.12.6
multi-user?: yes
sandbox: no
version: nix-env (Nix) 1.11.16
channels(andersriutta): "nixos-17.09.3263.9e1d8b74706, nixpkgs-18.09pre146471.d7d31fea7e7"
channels(root): "nixpkgs-18.03pre122585.b212125b541"
nixpkgs: /Users/andersriutta/.nix-defexpr/channels/nixpkgs

This should probably be opened as an issue in the blockhash repo.

authors: ariutta matthewbauer


text:
Vulnerability roundup 71: soundtouch-2.0.0: 3 advisories

search, files

[x] CVE-2018-1000223 (nixos-unstable)
[x] CVE-2018-14044 (nixos-unstable)
[x] CVE-2018-14045 (nixos-unstable)

Scanned versions: nixos-unstable: 73392e79aa6. May contain false positives.

See also #64662


text:
pyxdg: AttributeError: 'MenuEntry' object has no attribute 'Type' on KDE plasma

Describe the bug
A clear and concise description of what the bug is.
This came up while debugging xpra on KDE. This issue has been reported upstream, but it seems to uniquely affect KDE on nix. We communicated with the xpra author who added a mitigation for this, but it does not address the underlying issue in pyxdg. It seems the issue is due to the envvar XDG_DATA_DIRS only when it contains both ${plasma-workspace}/share and current-system/sw/share. Those are the only two directories that seem to matter. I'm wondering if this is because some entries from plasma-workspace/share are a subset of what is symlinked into current-system/sw/share?
To Reproduce
Steps to reproduce the behavior:

nix-shell -p "python3.withPackages (ps: with ps; [ pyxdg ])" --command "python -c 'from xdg.Menu import parse;parse()'" -> Error occurs

For the following you'll need the /share directory for the installed KDE. You can get this by echo $XDG_DATA_DIRS > out.txt and searching for plasma-workspace, or on nix repl
❯ sudo nix repl
[sudo] password for mjlbach:
Welcome to Nix version 2.3.4. Type :? for help.

nix-repl> :l <nixpkgs>
Added 11495 variables.

nix-repl> "${plasma-workspace}"
"/nix/store/2gc5fsahhfxvffdrfz2vmr4g2askadia-plasma-workspace-5.17.5"

nix-shell -p "python3.withPackages (ps: with ps; [ pyxdg ])" --command "XDG_DATA_DIRS=/run/current-system/sw/share:/nix/store/2gc5fsahhfxvffdrfz2vmr4g2askadia-plasma-workspace-5.17.5/share python -c 'from xdg.Menu import parse;parse()'" -> Error occurs (change the path to point to your plasma workspace)

nix-shell -p "python3.withPackages (ps: with ps; [ pyxdg ])" --command "XDG_DATA_DIRS=/run/current-system/sw/share python -c 'from xdg.Menu import parse;parse()'" -> Error doesn't occur

nix-shell -p "python3.withPackages (ps: with ps; [ pyxdg ])" --command "XDG_DATA_DIRS=/nix/store/2gc5fsahhfxvffdrfz2vmr4g2askadia-plasma-workspace-5.17.5/share python -c 'from xdg.Menu import parse;parse()'" -> Error doesn't occur

A clear and concise description of what you expected to happen.
pyxdg loads cleanly
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Nixpkgs snippet to make an executable script that tests the issue
writers.writePython3 "pyxdg-test" { libraries = [ python3Packages.pyxdg ]; } ''
from xdg.Menu import parse
parse()
''

authors: lourkeur mjlbach


text:
qbittorent trayicon doesn't show correctly on sway

Describe the bug
I'm using swaywm and when I have qbittorent opened I get a default looking trayicon instead of what it supposed to be.
To Reproduce
Steps to reproduce the behavior:

Start qbittorent.

Expected behavior
Qbittorent icon appears.
Screenshots
Pic here. The right icon belongs to qbittorent.
Notify maintainers
@Anton-Latukha
Metadata
> nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.7.17, NixOS, 20.03.2849.feff2fa6659 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.6`
 - channels(root): `"nixos-20.03.2849.feff2fa6659, nixos-unstable-20.09pre239318.c59ea8b8a0e"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

setting QT_QPA_PLATFORMTHEME to qt5ct and setting a icon theme in qt5ct is atleast a workaround

Indeed it works as a workaround. Although, it messed up icons in the gui.

Here comes a weird thingy. When I use magnet link to open qbittorent the correct trayicon loads.

updated my system, and I cannot reproduce anymore

authors: Artturin Kazimazi


text:
lollypop: 1.3.2 -> 1.4.5

Motivation for this change
lollypop has a new release.
Full changelog
This change depends on libhandy updates, so it targets staging-next.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Why did you target staging_next? There are not that many rebuilds.

Project name: lollypop
Project version: 1.4.5
Host machine cpu family: x86_64
Host machine cpu: x86_64

meson.build:5:0: ERROR: Could not execute command "/build/lollypop/bin/revision.sh".

A full log can be found at /build/lollypop/build/meson-logs/meson-log.txt

This update depends on the libhandy upgrade made in #98316. For some reason I only saw that in staging-next, but I see that it's in staging as well; should this change target staging instead?
Not sure why there was a build failure, it built locally for me. I'm rebuilding against staging now to double check.

It builds and runs for me locally on latest staging as well.

Thanks :+1:

source: gharchive/pull-request

authors: SuperSandro2000 jonafato worldofpeace


text:
chrysalis: init at 0.7.9

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 103207 run on x86_64-linux 1

1 package built:

chrysalis

LGTM

authors: SuperSandro2000 herrwiese spacefrogg


text:
pijul: 1.0.0-alpha.11 -> 1.0.0-alpha.17

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 105978 1

1 package built:

pijul

Result of nixpkgs-review pr 105978 run on x86_64-linux 1

1 package built:

pijul


text:
pythonPackages.progressbar2: fix build

build failed because tests depend on pytest-pep8 which is unmaintained
and therefore not worth packaging. it's probably better to wait for
upstream to resolve the linked issue.

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 107414 run on x86_64-linux 1

1 package marked as broken and skipped:

python37Packages.baselines

3 packages failed to build:

python37Packages.paperspace
python38Packages.paperspace
python39Packages.paperspace

5 packages built:

portmod
python37Packages.progressbar2
python38Packages.progressbar2
python39Packages.progressbar2
truvari

paperspace fails because our hyperopt is too new…

Result of nixpkgs-review pr 107414 run on x86_64-darwin 1

3 packages failed to build:

python37Packages.paperspace
python38Packages.paperspace
python39Packages.paperspace

3 packages built:

python37Packages.progressbar2
python38Packages.progressbar2
python39Packages.progressbar2


text:
haskellPackages.Agda: Fix build for ghc 8.10.2 → 8.10.3 upgrade

Motivation for this change
Commit 1998b95adc6b5a9aef336e45955a01575bd898f1 “haskellPackages: update default compiler from ghc 8.10.2 to version 8.10.3” broke Agda because Agda.cabal incorrectly declares a transformers dependency only for ghc < 8.10.3:
if impl(ghc >= 8.6.4) && impl(ghc < 8.10.3)
  build-depends: transformers == 0.5.6.2

if impl(ghc >= 8.4) && impl(ghc < 8.6.4)
  build-depends: transformers == 0.5.5.0

if impl(ghc < 8.4)
  build-depends: transformers == 0.5.2.0

leading to this error:
src/full/Agda/Utils/Maybe.hs:13:1: error:
Could not load module ‘Control.Monad.Trans.Maybe’
It is a member of the hidden package ‘transformers-0.5.6.2’.
Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
13 | import Control.Monad.Trans.Maybe
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Just wanted to say thanks to the two of you, @andersk and @cdepillabout, for the quick pull request and merge! For keeping the Agdapad up to date, this was exactly what I needed. Now I'm just waiting for unstable to pick that up. Thank you!

@iblech You may already be aware, but this should get into master when https://github.com/NixOS/nixpkgs/pull/107593 is merged, and then that should make its way to the unstable channel a day or two after that.

authors: andersk cdepillabout iblech


text:
kodi.packages.jellyfin: init at 0.7.1, a few fixups

Motivation for this change

add the jellyfin package to kodi.packages.*, as well as dependencies
fixup kodi.packages.netflix

This PR is based on top of #116806
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Very nice find! I'm quite interested in this add-on, I just wish I knew about it sooner. Tested it with my Jellyfin server, and it seems to work fine. Here's the build I tested it with:
nix build --impure --expr "with import ./nixpkgs {}; (kodi-wayland.withPackages (p: with p; [ jellyfin ]))"

Result of nix-review pr 117034 1

25 package were built:

kodiPackages.certifi
kodiPackages.chardet
kodiPackages.dateutil
kodiPackages.idna
kodiPackages.inputstream-adaptive
kodiPackages.inputstreamhelper
kodiPackages.jellyfin
kodiPackages.joystick
kodiPackages.kodi-six
kodiPackages.myconnpy
kodiPackages.netflix
kodiPackages.osmc-skin
kodiPackages.pdfreader
kodiPackages.pvr-hdhomerun
kodiPackages.pvr-hts
kodiPackages.pvr-iptvsimple
kodiPackages.requests
kodiPackages.signals
kodiPackages.six
kodiPackages.steam-controller
kodiPackages.steam-launcher
kodiPackages.svtplay
kodiPackages.urllib3
kodiPackages.vfs-libarchive
kodiPackages.vfs-sftp

It seems the Jellyfin add-on has an optional dependency on "Kodi Sync Queue" for automatic library updates, it might be desirable to install it automatically.

Thanks for the testing! And yet, this add-on is awesome! Totally replaced my mysql setup for managing multiple kodi machines.

authors: aanderse minijackson