jiebi/CodeConvo huggingface dataset:
Code change:
sha256 = "sha256-uhVRO9aiYJbUmwDp1+LIYF3wNBbVduVpTtVzaS0oUMU="; }; <ins> patches = [ # Fix Exec= path in runtime-generated # ~/.config/autostart/syncthingtray.desktop file - this is required because # we are wrapping the executable. We can't use `substituteAll` because we # can't use `${placeholder "out"}` because that will produce the $out of # the patch derivation itself, and not of syncthing's "out" placeholder. # Hence we use a C definition with NIX_CFLAGS_COMPILE ./use-nix-path-in-autostart.patch ]; NIX_CFLAGS_COMPILE = "-DEXEC_NIX_PATH="${placeholder "out"}/bin/syncthingtray""; </ins> buildInputs = [ qtbase cpp-utilities

Related discussion:
text: The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.
Code change:
sha256 = "sha256-uhVRO9aiYJbUmwDp1+LIYF3wNBbVduVpTtVzaS0oUMU="; }; <ins> patches = [ # Fix Exec= path in runtime-generated # ~/.config/autostart/syncthingtray.desktop file - this is required because # we are wrapping the executable. We can't use `substituteAll` because we # can't use `${placeholder "out"}` because that will produce the $out of # the patch derivation itself, and not of syncthing's "out" placeholder. # Hence we use a C definition with NIX_CFLAGS_COMPILE ./use-nix-path-in-autostart.patch ]; NIX_CFLAGS_COMPILE = "-DEXEC_NIX_PATH="${placeholder "out"}/bin/syncthingtray""; </ins> buildInputs = [ qtbase cpp-utilities

Related discussion:
text: Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?
Code change:
sha256 = "sha256-uhVRO9aiYJbUmwDp1+LIYF3wNBbVduVpTtVzaS0oUMU="; }; <ins> patches = [ # Fix Exec= path in runtime-generated # ~/.config/autostart/syncthingtray.desktop file - this is required because # we are wrapping the executable. We can't use `substituteAll` because we # can't use `${placeholder "out"}` because that will produce the $out of # the patch derivation itself, and not of syncthing's "out" placeholder. # Hence we use a C definition with NIX_CFLAGS_COMPILE ./use-nix-path-in-autostart.patch ]; NIX_CFLAGS_COMPILE = "-DEXEC_NIX_PATH="${placeholder "out"}/bin/syncthingtray""; </ins> buildInputs = [ qtbase cpp-utilities

Related discussion:
text: I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.
Code change:
, gmp , libGL , libGLU <ins> , libSM </ins> , mpfr , proj , python3

Related discussion:
text: Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.
Code change:
nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

Related discussion:
text: After setting up faster-whisper for my Home Assistant instance, I learned that my CPU (i5-6500) isn't quite as fast as I'd like for this, so I am now trying to test a GPU (NVIDIA Quadro M2000). My configuration for it is the following: I expected it to then run on my GPU using CUDA, but unless my GPU and CPU are continually equally performant, it is not working. (Also, no processes are shown in ) Steps to reproduce the behavior: NVIDIA GPU, and then configure it accordingly in , add , , , and to faster-whisper in configuration, configure it to work with device = "cuda" for STT to be faster, instead same speed I'm not totally sure what to expect because this is my first time using this, but I expected a Python3 process to appear in and for my STT to be quicker. My config is the following: The following (seemingly) NVIDIA related items are at /dev/ ! ! works, but I am not totally sure that my CUDA is configured correctly, for all I know possibly CUDA isn't configured properly, but I think I have everything correct.
I eyeballed CUDA support, but have no hardware to test or reproduce. I appreciate help in fixing the module to make it work with CUDA.
I am not overly proficient in Nix or anything like this, but I would be willing to help if you have ideas.
Well, for one we're not passing in . Can you try setting ?
Ok, I that and now when looking at the logs, I get this: It then exits.
That looks actionable. We did indeed not build ctranslate2 with CUDA support. I can try to set that up, but it won't be the default, because that would make the package unfree. We possibly need multiple ctranslate2 attributes.
Is it possible to have the package be free unless an option is passed that enables CUDA and then makes it unfree, or would two different packages be needed. There could be a package, I think that could work.
Yeah, that would also work.
If you want to try and build it with CUDA support, I can test it out and report back.
fixes the module, so it passes as expected. It also adds CUDA support to .
Code change:
nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

Related discussion:
text: Check the description of the PR on how to opt into CUDA support in nixpkgs.
Hi Just to clarify, you only need in your (or in your 's ) if you're setting up a development environment to write cuda programs. If you only want to use packages with cuda support enabled, you just use them directly (e.g. ), no need to add anywhere manually. If you want to enable cuda in every package that supports it, you can set in your (nb: this triggers a massive rebuild). Instead of adding , you want to use (this way if you switch e.g. -, you'd be still using for the correct kernel), but also instead of you can take (keeps working if you switch e.g. -) Sorry we didn't get this documented yet
Wow, thank you! I assume I still need in my , right? About enabling , I've already enabled that and let it go through that whole process, so I think I'll just leave it enabled. About changing the , how is that to be done exactly? Do I just swap for in the exact same spot?
Also, is there an easy way for me to test out this updated package before it gets merged?
Depends on how you deploy your machine and what nixos version you are on.
I'm on Unstable and use Flakes.
You could replace your nixpkgs input with a fork of nixos-unstable and pick the commits from that PR on top. I'm sure there is a better solution, but I'm not well versed in flakes.
No, is the old version of , and you don't need it in Yes, except it's just , without at the end. This refers to "whatever graphics driver is in use". But also you can just remove this if you use and (both options are badly named, they're not really specific to neither of opengl or x11)
I have , but I don't have xserver enabled because this is a headless server. Do I even need nvidia_x11 if it's headless with no DE?
is where comes from; I don't recall now if it's ok to use on a headless machine, but if you like to just be explicit, you can keep P.S.
Code change:
nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

Related discussion:
text: Discourse and NixOS matrix channels provide venues for Q&A discussions
With the changes made to ctranslate2, and the fixes to th , I fully expect this could work. If not, please get back to me with some error messages, e.g. the hardening of the systemd unit might cause problems.
No problem. I attempted to use just the new packages, but it became a little difficult because my old nixpkgs didn't think that ctranslate2 could have CUDA enabled, so I'll just wait for master to get pushed to NixOS-Unstable (Hopefully soon!)
The package now fails with . My system may not be correctly configured for CUDA support, or the SystemD Service is not passing through the NVIDIA device correctly. Just a reminder, the following devices are available at : (I'm not sure if is an NVIDIA thing, but it exists if that's of importance.)
Then we're at least missing . What's the content of ? nix DeviceAllow = if [ "cuda" "auto" ] then [ # "/dev/nvidia1" "/dev/nvidia2" "/dev/nvidia3" "/dev/nvidia4" "/dev/nvidia-caps/nvidia-cap1" "/dev/nvidia-caps/nvidia-cap2" "/dev/nvidiactl" "/dev/nvidia-modeset" "/dev/nvidia-uvm" "/dev/nvidia-uvm-tools" ] else "";
I modified the SystemD service to include , and it didn't help at all. The contents of are . Also, I just discovered something new. When running I get So possibly updating this system now broke NVIDIA support and it just so happened to be at the same time I tried to get Whisper working.
Did you also check which is in ? There are two things you need to maintain: 1) your driver should be newer than the cuda libraries used to build your program, 2) your should come from the same (version of) package as the kernel modules (in other words, currently you have to reboot if you update your nixos and get a newer - the new kernel module is only loaded on the next boot)
shows the following for Also, I just rebooted and is working.
from what I listed is accessible from , should my system have functional CUDA support? I tried using some testing parts from , but it seems to be out of date.
Code change:
nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

Related discussion:
text: PS: Should this conversation be continued somewhere else, or is it fine to continue it here because it is somewhat pertinent to the issue?
Yes please, e.g. in or , or on You can just post the final update here once you get things to work, for discoverability purposes. Thanks!
Code change:
batctl = callPackage ../os-specific/linux/batman-adv/batctl.nix { }; <ins> beefi = callPackage ../os-specific/linux/beefi { }; </ins> blktrace = callPackage ../os-specific/linux/blktrace { }; bluez5 = callPackage ../os-specific/linux/bluez { };

Related discussion:
text: Project description Converts Linux images and kernels into UEFI images. Metadata homepage URL: source URL: license: GPL3 platforms: Linux
Code change:
hash = "sha256-g5OqdnPtGGV4wBwPRAjH3lweguwlfVcgpNLlq54OHKA="; }; <del> postPatch = '' substituteInPlace pyproject.toml  --replace "attrs~=21.4" "attrs>=21.4" ''; </del> nativeBuildInputs = with python3.pkgs; [ flit-core <ins> pythonRelaxDepsHook </ins> ]; <ins> pythonRelaxDeps = true; </ins> propagatedBuildInputs = with python3.pkgs; [ attrs <del> ipython </del> jinja2 lxml pypubsub pyyaml <ins> termcolor </ins> ]; # Project has no tests

Related discussion:
text: Steps to reproduce the behavior: trueseeing dependency check fails due to missing termcolor. Full logs : <summary<details<preSourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing pypa-build-hook Using pypaBuildPhase Sourcing python-runtime-deps-check-hook Using pythonRuntimeDepsCheckHook Sourcing pypa-install-hook Using pypaInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook Sourcing python-catch-conflicts- { "action": "setPhase", "phase": "unpackPhase" } Running phase: unpackPhase unpacking source archive /nix/store/p05bg72wb6ihkj9jjmdgzsnjifd0m0ar-source source root is source setting SOURCEDATEEPOCH to timestamp of file { "action": "setPhase", "phase": "patchPhase" } Running phase: patchPhase { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" } Running phase: updateAutotoolsGnuConfigScriptsPhase { "action": "setPhase", "phase": "configurePhase" } Running phase: configurePhase no configure script, doing nothing { "action": "setPhase", "phase": "buildPhase" } Running phase: buildPhase Executing pypaBuildPhase Creating a wheel... Getting build dependencies for wheel... Building wheel... Successfully built trueseeing-2.1.9-py3-none- Finished creating a wheel... Finished executing pypaBuildPhase { "action": "setPhase", "phase": "pythonRuntimeDepsCheckHook" } Running phase: pythonRuntimeDepsCheckHook Executing pythonRuntimeDepsCheck Checking runtime dependencies for trueseeing-2.1.9-py3-none- termcolor not installed </pre</details</summaryAdd any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: I believe trueseeing is missing the termcolor dependency hence the failure happening during the build.
Code change:
hash = "sha256-g5OqdnPtGGV4wBwPRAjH3lweguwlfVcgpNLlq54OHKA="; }; <del> postPatch = '' substituteInPlace pyproject.toml  --replace "attrs~=21.4" "attrs>=21.4" ''; </del> nativeBuildInputs = with python3.pkgs; [ flit-core <ins> pythonRelaxDepsHook </ins> ]; <ins> pythonRelaxDeps = true; </ins> propagatedBuildInputs = with python3.pkgs; [ attrs <del> ipython </del> jinja2 lxml pypubsub pyyaml <ins> termcolor </ins> ]; # Project has no tests

Related discussion:
text: I can try and PR a fix but I did not try and reproduce the bug under NixOS. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems a lot of other packages have broken in similar ways, mitmproxy, ioccheck, theharvester but they all fail due to missing runtime dependencies or version of modules that are not meeting constraints.
I had the same issue with mitmproxy and found this issue because you've mentioned it here. ~git bisect for mitmproxy pointed to this commit for me: ~ Edit: apologies, I used git bisect wrongly. The first bad commit seems to be .
This seems relevant:
That shouldn't change whether or not a package builds.
Yeah, my nightly session of bisecting for pointed to , which is from . I guess affected packages do have to be fixed one-by-one manually.
Code change:
hy3 = { fetchFromGitHub, cmake, hyprland }: mkHyprlandPlugin rec { pluginName = "hy3"; <del> version = "0.35.0"; </del> <ins> version = "unstable-2024-02-23"; </ins> src = fetchFromGitHub { owner = "outfoxxed"; repo = "hy3"; <del> rev = "hl${version}"; hash = "sha256-lFe7Lf0K5ePTh4gflnvBohOGH4ayGDtNkbg/XtoNqRo="; </del> <ins> rev = "029a2001361d2a4cbbe7447968dee5d1b1880298"; hash = "sha256-8LKCXwNU6wA8o6O7s9T2sLWbYNHaI1tYU4YMjHkNLZQ="; </ins> }; nativeBuildInputs = [ cmake ];

Related discussion:
text: Package name: hyprland Latest released version: 0.36.0 <!-- Search your package here: --- Current version on the unstable channel: 0.35.0 Current version on the stable/release channel: 0.32.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: The 035.0 has a bug that makes my system crash very often (nullptr when monitor is disconnected) the issue is supposed to be fixed in 0.36.0.
Code change:
hash = "sha256-iUmnzrItTFM98w3mpadzrmtI3t0fucpSujAg/6qxCGk="; stripLen = 2; }) <ins> (fetchpatch { # https://github.com/apache/beam/pull/24573 name = "relax-httplib2-version.patch"; url = "https://github.com/apache/beam/commit/4045503575ae5ccef3de8d7b868c54e37fef658b.patch"; hash = "sha256-YqT+sHaa1R9vLQnEQN2K0lYoCdnGoPY9qduGBpXPaek="; stripLen = 2; }) </ins> ]; pythonRelaxDeps = [

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -
Code change:
buildGoModule rec { pname = "shadowsocks-v2ray-plugin"; <del> version = "1.3.2"; </del> <ins> version = "1.3.1"; </ins> src = fetchFromGitHub { owner = "shadowsocks"; repo = "v2ray-plugin"; rev = "v${version}"; <del> sha256 = "sha256-sGsGdJp20mXvJ6Ov1QjztbJxNpDaDEERcRAAyGgenVk="; </del> <ins> sha256 = "0aq445gnqk9dxs1hkw7rvk86wg0iyiy0h740lvyh6d9zsqhf61wb"; </ins> }; <del> vendorHash = "sha256-vW8790Z4BacbdqANWO41l5bH5ac/TSZIdVNvOFVTsZ8="; </del> <ins> vendorSha256 = "0vzd9v33p4a32f5ic9ir4g5ckis06wpdf07a649h9qalimxnvzfz"; </ins> meta = with lib; { description = "Yet another SIP003 plugin for shadowsocks, based on v2ray";

Related discussion:
text: shadowsocks-v2ray-plugin doesn't work anymore in nixos-unstable. Try to use it with shadowsocks-rust. Here what I have in logs: It works. If applicable, add screenshots to help explain your problem. Add any other context about the problem here.
Version from works.
Looks like it got updated again: :)
cc
Just a note - it seems v2ray plugin is not maintained, but maybe can be used instead.
Code change:
<del> --- a/Build.PL +++ b/Build.PL @@ -88,7 +88,7 @@ if ( $^O =~ /mswin32/i ) { } } else { -    if ( $Config{archname} =~ /^x86_64|^ppc64|^s390x|^aarch64|^riscv64/ ) { +    if ( $Config{archname} =~ /^x86_64|^ppc64|^s390x|^riscv64/ ) { $libdir =~ s/bbinb/lib64/; if ( !-d $libdir ) { my $test = $libdir; </del>

Related discussion:
text: Steps to reproduce the behavior: Confirmed locally against recent master () system: host os: multi-user?: sandbox: version: nixpkgs:
There's already a PR fixing this build failure:
looks like this is being addressed in
Can confirm, fixes build-issues on unstable :)
Fix has been merged. Feel free to reopen if the issue persists after the next channel bump
Code change:
<del> { lib, stdenv, fetchurl, makeWrapper, jre8, which, gawk }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, which, gawk }: </ins> with lib;

Related discussion:
text: Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information: