jiebi/CodeConvo huggingface dataset:
Code change:
''; cmakeFlags = [ <del> (lib.cmakeBool "USE_DLIB_USE_CUDA" cudaSupport) </del> (lib.cmakeBool "USE_SSE4_INSTRUCTIONS" sse4Support) (lib.cmakeBool "USE_AVX_INSTRUCTIONS" avxSupport) <ins> (lib.cmakeBool "DLIB_USE_CUDA" cudaSupport) ] ++ lib.optionals cudaSupport [ (lib.cmakeFeature "DLIB_USE_CUDA_COMPUTE_CAPABILITIES" (builtins.concatStringsSep "," (with cudaPackages.flags; map dropDot cudaCapabilities))) </ins> ]; <del> nativeBuildInputs = [ cmake pkg-config ]; </del> <ins> nativeBuildInputs = [ cmake pkg-config ] ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_nvcc ]); </ins> buildInputs = [ <del> fftw </del> libpng libjpeg libwebp <del> openblas ] ++ lib.optional guiSupport libX11; </del> <ins> blas lapack ] ++ lib.optionals guiSupport [ libX11 ] ++ lib.optionals config.cudaSupport (with cudaPackages; [ cuda_cudart.dev cuda_cudart.lib cuda_cudart.static cuda_nvcc.dev libcublas.dev libcublas.lib libcublas.static libcurand.dev libcurand.lib libcurand.static libcusolver.dev libcusolver.lib libcusolver.static cudnn.dev cudnn.lib cudnn.static cuda_cccl.dev ]); passthru = { inherit cudaSupport cudaPackages sse4Support avxSupport; }; </ins> meta = with lib; { description = "A general purpose cross-platform C++ machine learning library";

Related discussion:
text: When you set , although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of instead of when building the cuda related packages. The correct usage can be seen in the package. It also tries to build with CUDA by default which is wrong. Dlib hasn't supported fftw since however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed. As mentioned in this it makes more sense to have as an input into rather that so that people can override it with other BLAS implementations e.g more easily if they want to. The package was also missing lapack which should be . Steps to reproduce the behavior: Build the package, it tries to build with CUDA by default. I made an example with a fairly simple nix flake that let's you switch between my patch and the original package. I have created a which fixes these issues. For it to build with CUDA. How CMAKE fails ! For this simple c switching from my fix to the original bugged package on 23.11 before openblas was . ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Thanks!
Code change:
<ins> { lib , buildPythonPackage , python , pythonOlder , fetchFromGitLab , substituteAll , bubblewrap , exiftool , ffmpeg , mime-types , wrapGAppsHook , gdk-pixbuf , gobject-introspection , librsvg , poppler_gi , mutagen , pygobject3 , pycairo , dolphinIntegration ? false, plasma5Packages }: buildPythonPackage rec { pname = "mat2"; version = "0.12.0"; disabled = pythonOlder "3.5"; src = fetchFromGitLab { domain = "0xacab.org"; owner = "jvoisin"; repo = "mat2"; rev = version; sha256 = "0amxwwmcf47dakfm6zvsksv6ja7rz7dpmd1z2rsspy8yds6zgxs7"; }; patches = [ # hardcode paths to some binaries (substituteAll ({ src = ./paths.patch; bwrap = "${bubblewrap}/bin/bwrap"; exiftool = "${exiftool}/bin/exiftool"; ffmpeg = "${ffmpeg}/bin/ffmpeg"; # remove once faf0f8a8a4134edbeec0a73de7f938453444186d is in master mimetypes = "${mime-types}/etc/mime.types"; } // lib.optionalAttrs dolphinIntegration { kdialog = "${plasma5Packages.kdialog}/bin/kdialog"; })) # the executable shouldn't be called .mat2-wrapped ./executable-name.patch # hardcode path to mat2 executable ./tests.patch ]; postPatch = '' substituteInPlace dolphin/mat2.desktop  --replace "@mat2@" "$out/bin/mat2"  --replace "@mat2svg@" "$out/share/icons/hicolor/scalable/apps/mat2.svg" ''; nativeBuildInputs = [ wrapGAppsHook ]; buildInputs = [ gdk-pixbuf gobject-introspection librsvg poppler_gi ]; propagatedBuildInputs = [ mutagen pygobject3 pycairo ]; postInstall = '' install -Dm 444 data/mat2.svg -t "$out/share/icons/hicolor/scalable/apps" install -Dm 444 doc/mat2.1 -t "$out/share/man/man1" install -Dm 444 nautilus/mat2.py -t "$out/share/nautilus-python/extensions" buildPythonPath "$out $pythonPath" patchPythonScript "$out/share/nautilus-python/extensions/mat2.py" '' + lib.optionalString dolphinIntegration '' install -Dm 444 dolphin/mat2.desktop -t "$out/share/kservices5/ServiceMenus" ''; checkPhase = '' ${python.interpreter} -m unittest discover -v ''; meta = with lib; { description = "A handy tool to trash your metadata"; homepage = "https://0xacab.org/jvoisin/mat2"; changelog = "https://0xacab.org/jvoisin/mat2/-/blob/${version}/CHANGELOG.md"; license = licenses.lgpl3Plus; maintainers = with maintainers; [ dotlambda ]; }; } </ins>

Related discussion:
text: Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection
Code change:
''; }; <ins> jshint = nodePackages.jshint.override { buildInputs = [ pkgs.phantomjs2 ]; }; </ins> dat = nodePackages.dat.override { buildInputs = [ nodePackages.node-gyp-build ]; };

Related discussion:
text: Reproducing is pretty simple: . The error is: system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:
Code change:
--> <para> <del> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </del> <ins> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </ins> <programlisting> <xref linkend="opt-services.postgresql.dataDir"/> = "/data/postgresql"; </programlisting>

Related discussion:
text: to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.
Code change:
--> <para> <del> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </del> <ins> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </ins> <programlisting> <xref linkend="opt-services.postgresql.dataDir"/> = "/data/postgresql"; </programlisting>

Related discussion:
text: I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)
Code change:
<ins> { lib , pkgs , alsa-lib , plugins ? [ pkgs.alsa-plugins ] , lndir , symlinkJoin , runCommand }: let merged = symlinkJoin { name = "alsa-plugins-merged"; paths = plugins; }; in runCommand "${alsa-lib.pname}-${alsa-lib.version}" { meta = with lib; { description = "wrapper to ease access to ALSA plugins"; platforms = platforms.linux; maintainers = with maintainers; [ gm6k ]; }; outputs = alsa-lib.outputs; } ( ( lib.concatMapStringsSep "n" ( output: '' mkdir ${builtins.placeholder output} ${lndir}/bin/lndir ${lib.attrByPath [output] null alsa-lib}  ${builtins.placeholder output} '' ) alsa-lib.outputs ) + '' cp -r ${merged}/lib/alsa-lib $out/lib ( echo $out | wc -c echo ${alsa-lib} | wc -c ) | xargs echo | grep -q "^(.*) 1$" || ( echo cannot binary patch exit 1 ) rm $out/lib/libasound.la rm $out/lib/libasound.so.?.?.? rm $dev/lib/pkgconfig/alsa.pc rm $dev/nix-support/propagated-build-inputs cp ${alsa-lib}/lib/libasound.la $out/lib cp ${alsa-lib}/lib/libasound.so.?.?.? $out/lib cp ${alsa-lib.dev}/lib/pkgconfig/alsa.pc $dev/lib/pkgconfig cp ${alsa-lib.dev}/nix-support/propagated-build-inputs $dev/nix-support sed -i  $out/lib/libasound.la  $out/lib/libasound.so.?.?.?  $dev/lib/pkgconfig/alsa.pc  $dev/nix-support/propagated-build-inputs  -e "s@${alsa-lib}@$out@g" '' ) </ins>

Related discussion:
text: One nice effect is that we don't have to patch alsa-libs any more. Thoughts on how to best take advantage of the new feature?
Without writing an updated patch for multiple plugin directory support, the upstream's can probably be put to use immediately by pointing to symlink farm of plugins. Haven't tried this, but I suspect it (or something similar) would do the trick. The linked GUIX thread included review of a patch for multiple plugin directory support. It looked promising but its growing stale with outstanding feedback. They've not responded to news of upstream ; I do wonder if they'd consider contributing their multi-directory patch or not - especially given that there's now some kind of upstream support.
Guix's property will automatically create a create a symlink union of the relevant plugins for single-entry search paths. It's how Chromium extensions and plugins are discovered, for example. It's just because we haven't gotten around to update alsa-lib yet, as it missed the latest 'staging' cycle.
Hi, I'm the author of that patch from Guix, although it grew out my reading of the old unused nixpkgs patch. I ran out of energy for keeping track of all the "C issues" one has to think about... if alsa-lib's new ALSAPLUGINDIR meets our needs then I'll be glad to leave the patch behind. Feel free to use the patch in any way you like — it does work fine and, as a part of Guix, the license is GPL3+. Or, as a part of alsa-lib, maybe it's LGPL2.1+? Anyways, feel free...
I marked this as stale due to inactivity. &rarr;
I implemented the aggregate package approach () and appreciate your thoughts on it.
Code change:
{ lib , buildPythonPackage , fetchPypi <del> , mock , nose </del> <ins> , pytestCheckHook , pythonOlder </ins> , requests <del> , yanc </del> }: buildPythonPackage rec { pname = "ovh"; <del> version = "1.0.0"; </del> <ins> version = "1.1.0"; </ins> format = "setuptools"; <ins> disabled = pythonOlder "3.7"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-IQzwu0gwfPNPOLQLCO99KL5Hu2094Y+acQBFXVGzHhU="; </del> <ins> hash = "sha256-EI+bWjtHEZPOSkWJx3gvS8y//gugMWl3TrBHKsKO9nk="; </ins> }; propagatedBuildInputs = [ requests ]; <del> preCheck = '' export HOME=$(mktemp -d) ''; </del> nativeCheckInputs = [ <del> mock nose yanc </del> <ins> pytestCheckHook </ins> ]; <del> # requires network checkPhase = '' nosetests .  -e test_config_get_conf  -e test_config_get_custom_conf  -e test_endpoints  -e test_init_from_custom_config ''; </del> <ins> pythonImportsCheck = [ "ovh" ]; disabledTests = [ # Tests require network access "test_config_from_files" "test_config_from_given_config_file" "test_config_from_invalid_ini_file" "test_config_from_only_one_file" "test_endpoints" ]; </ins> <del> meta = { </del> <ins> meta = with lib; { </ins> description = "Thin wrapper around OVH's APIs"; homepage = "https://github.com/ovh/python-ovh"; <del> license = lib.licenses.bsd2; maintainers = [ lib.maintainers.makefu ]; </del> <ins> changelog = "https://github.com/ovh/python-ovh/blob/v${version}/CHANGELOG.md"; license = licenses.bsd2; maintainers = with maintainers; [ makefu ]; </ins> }; }

Related discussion:
text: Package name: Latest released version: 1.1.0 <!-- Search your package here: --- Current version on the unstable channel: 1.0.0 Current version on the stable/release channel: 1.0.0 <!-- 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 Note for maintainers: Please tag this issue in your PR.
Code change:
srt systemd taglib <del> wayland wayland-protocols </del> zlib ] ++ (with xorg; [

Related discussion:
text: Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file
Code change:
}; }; } <ins> { settings.bind_interface = "eth0"; port = bindTestPort; } </ins> ]; }; };

Related discussion:
text: lists a listener option called that can be used to listen for incoming network connections only on the specified interface. Unfortunately does not accept this option. Steps to reproduce the behavior: This should evaluate cleanly. Incidentally, that assertion message drops the component in the attribute path, it might be nice to fix that.
Code change:
buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

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:
buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

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:
buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

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:
buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

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!