jiebi/CodeConvo huggingface dataset:
Code change:
, darwin # Accelerate , llvmPackages # openmp , withMkl ? false, mkl <ins> , withCUDA ? false , withCuDNN ? false , cudaPackages </ins> # Enabling both withOneDNN and withOpenblas is broken # https://github.com/OpenNMT/CTranslate2/issues/1294 , withOneDNN ? false, oneDNN

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:
, darwin # Accelerate , llvmPackages # openmp , withMkl ? false, mkl <ins> , withCUDA ? false , withCuDNN ? false , cudaPackages </ins> # Enabling both withOneDNN and withOpenblas is broken # https://github.com/OpenNMT/CTranslate2/issues/1294 , withOneDNN ? false, oneDNN

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:
<!-- FIXME: render nicely --> <!-- FIXME: source can be added automatically --> <para> <del> <emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename> </del> <ins> <emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename> </ins> </para> <para> <del> <emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/> </del> <ins> <emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/> </ins> </para> <!-- FIXME: more stuff, like maintainer? --> <para>

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:
<!-- FIXME: render nicely --> <!-- FIXME: source can be added automatically --> <para> <del> <emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename> </del> <ins> <emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename> </ins> </para> <para> <del> <emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/> </del> <ins> <emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/> </ins> </para> <!-- FIXME: more stuff, like maintainer? --> <para>

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:
# Replace version inside sd-boot with something older. See magic[] string in systemd src/boot/efi/boot.c machine.succeed( """ <del> find /boot -iname '*.efi' -print0 |  </del> <ins> find /boot -iname '*boot*.efi' -print0 |  </ins> xargs -0 -I '{}' sed -i 's/#### LoaderInfo: systemd-boot .* ####/#### LoaderInfo: systemd-boot 000.0-1-notnixos ####/' '{}' """ ) output = machine.succeed("/run/current-system/bin/switch-to-configuration boot") <del> assert "updating systemd-boot from (000.0-1-notnixos) to " in output </del> <ins> assert "updating systemd-boot from 000.0-1-notnixos to " in output </ins> ''; };

Related discussion:
text: During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- 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. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in
Code change:
++ optional langD ../libphobos.patch ++ optional langFortran ../gfortran-driving.patch ++ optional (targetPlatform.libc == "musl" && targetPlatform.isPower) ../ppc-musl.patch <del> ++ optional (!crossStageStatic && targetPlatform.isMinGW) (fetchpatch { url = "https://raw.githubusercontent.com/lhmouse/MINGW-packages/${import ../common/mfcgthreads-patches-repo.nix}/mingw-w64-gcc-git/9000-gcc-${majorVersion}-branch-Added-mcf-thread-model-support-from-mcfgthread.patch"; sha256 = "1in5kvcknlpi9z1vvjw6jfmwy8k12zvbqlqfnq84qpm99r0rh00a"; }); </del> <ins> # Obtain latest patch with ../update-mcfgthread-patches.sh ++ optional (!crossStageStatic && targetPlatform.isMinGW) ./Added-mcf-thread-model-support-from-mcfgthread.patch; </ins> /* Cross-gcc settings (build == host != target) */ crossMingw = targetPlatform != hostPlatform && targetPlatform.libc == "msvcrt";

Related discussion:
text: Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Code change:
<del> diff --git a/llm/llama.go b/llm/llama.go index 0b460e9..b79e04a 100644 --- a/llm/llama.go +++ b/llm/llama.go @@ -299,10 +299,6 @@ func newLlama(model string, adapters []string, runners []ModelRunner, numLayers params = append(params, "--n-gpu-layers", fmt.Sprintf("%d", numGPU)) } -	if opts.NumGQA > 0 { -		params = append(params, "--gqa", fmt.Sprintf("%d", opts.NumGQA)) -	} - if len(adapters) > 0 { // TODO: applying multiple adapters is not supported by the llama.cpp server yet params = append(params, "--lora", adapters[0]) </del>

Related discussion:
text: Package name: ollama Latest released version: 0.1.20 <!-- Search your package here: --- Current version on the unstable channel: 0.1.17 Current version on the stable/release channel: 0.1.7 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
20 was released.[^1] :tada: Had a quick look into the source changes. Seems that patching is required because of the integration of ROCm. [^1]:
I modified the title :-)
21 is going to be released very soon.
I opened
update: 0.1.22 is the latest version.
Seems update can be problematic. I've tried manually download and executing new ollama and encountered a lot of issues connected with ROCM libraries. After adding I've got it to state where it crushes: But before adding it seems also miss new version of because it was asking for but current unstable version have CPU works fine without mentioned ROCM packages.
This appears to have been resolved by . Reopen if it's not.
Code change:
RestrictSUIDSGID = true; UMask = "0066"; ProtectProc = "invisible"; <del> ProcSubset = "pid"; </del> SystemCallFilter = [ <del> "~@debug" "~@mount" "~@privileged" </del> <ins> "~@capset" "~@clock" </ins> "~@cpu-emulation" <ins> "~@module" "~@mount" </ins> "~@obsolete" <ins> "~@raw-io" "~@reboot" "~setdomainname" "~sethostname" </ins> ]; RestrictAddressFamilies = [ "AF_INET" "AF_INET6" "AF_UNIX" "AF_NETLINK" ];

Related discussion:
text: introduced systemd syscall filtering which seems overly restrictive for common use cases. We use for coverage reports of our Rust projects which makes use of the ptrace(2) system call (denied by ). Android projects commonly rely on which uses chown(2) (denied by ). In my opinion, those use cases are too common and should work out of the box. Also, workflow failures are difficult to debug if syscall filtering (or any hardening) steps in. I'd suggest to revise the syscall filtering: Also, it might help with debugging or employing a custom hardening configuration if we add a module option which defaults to . Please run and paste the result.
I agree that if the hardening make github-runner not to work as expected or as "standard" installation, we should remove them or make them optional with new option Do you want it to default to ? Maybe better with so it work as expected out of box?
also noted problems with makefile workflows in that I have been able to reproduce. I am sorry I did not catch this when making the changes originally. My usecase was running binaries on uncommon targets (e.g. ) connected over USB; and I only had light testing for other usecases. I have since a makefile test to the runner I use for testing package/module updates and will add a coverage workflow now too. I am ok with removing the harderning entirely, or making it more permissive. I only this because at the time I thought it would be a sane default for majority of applications. I would prefer we keep some hardening. Most people probably do not want a CI process to change the clock, hostname, or reboot the system entirely. I have been working on this in the background since reported issues; this is what I have come up with so far, I have not tested it with yet (will do that later this weekend); but it does allow and debug related tools such as to function. In addition to changes should also be changed to so that nix does not emit warnings when running.
:+1: :+1: Yes, all this hardening is already available and entirely optional! Every user is free to add anything to that they want.
Code change:
RestrictSUIDSGID = true; UMask = "0066"; ProtectProc = "invisible"; <del> ProcSubset = "pid"; </del> SystemCallFilter = [ <del> "~@debug" "~@mount" "~@privileged" </del> <ins> "~@capset" "~@clock" </ins> "~@cpu-emulation" <ins> "~@module" "~@mount" </ins> "~@obsolete" <ins> "~@raw-io" "~@reboot" "~setdomainname" "~sethostname" </ins> ]; RestrictAddressFamilies = [ "AF_INET" "AF_INET6" "AF_UNIX" "AF_NETLINK" ];

Related discussion:
text: I understand that NixOS developers are super keen on hardening, which is generally good, but for certain applications I just don't think it makes sense to go over the top... or even provide "curated" selections behind 'enableHardening' type flags. CI software is so broad I think we're providing more trouble and confusion than value here. My personal recommendation for this specific module is to follow what suggested as a reasonable default and let users decide any hardening they want for themselves. But I'm not the maintainer of this module in NixOS, just a user, so I defer to those who are volunteering their time to maintain this module :bowing_man:
PR to fix is here: Mentions do not generate notifications, just making a comment so that anyone subscribed to this issue gets a notification.
Code change:
depsBuildBuild = [ buildPackages.stdenv.cc ]; nativeBuildInputs = [ bison <ins> perl texinfo </ins> ] ++ (lib.optionals stdenv.targetPlatform.isiOS [ autoreconfHook <del> ]) ++ lib.optionals stdenv.targetPlatform.isVc4 [ texinfo flex ]; </del> <ins> ]) ++ lib.optionals stdenv.targetPlatform.isVc4 [ flex ]; </ins> buildInputs = [ zlib gettext ]; inherit noSysDirs;

Related discussion:
text: Describe the bug is currently in nixpkgs master. It was released in July 2018. was released in October 2019. It contains a few improvements and may also contains fix for some vulnerabilities: Is there a reason to keep the old version in nixpkgs, other than a lack of manpower? I'd be happy to do this work, but I just want to be sure that I was not starting a long, difficult and redundant work. I already tried a "naive" bump of the and but it does not work, mostly because most of the patchs are not valid anymore.
This was solved by cc.
Thank you for continuing this work!
Code change:
# We use try_first_pass the second time to avoid prompting password twice (optionalString (cfg.unixAuth && (config.security.pam.enableEcryptfs <ins> || config.security.pam.enableFscrypt </ins> || cfg.pamMount || cfg.enableKwallet || cfg.enableGnomeKeyring

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
buildInputs = [ qtbase <ins> qtwayland </ins> qtsvg qtimageformats qt5compat

Related discussion:
text: low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.
Code change:
<del> { stdenv, buildGoPackage, fetchFromGitHub }: buildGoPackage rec { name = "kbfs-${version}"; version = "2.11.0"; goPackagePath = "github.com/keybase/kbfs"; subPackages = [ "kbfsfuse" "kbfsgit/git-remote-keybase" ]; dontRenameImports = true; src = fetchFromGitHub { owner = "keybase"; repo = "kbfs"; rev = "v${version}"; sha256 = "1qlns7vpyj3ivm7d3vvlmx3iksl7hpcg87yh30f3n64c8jk0xc83"; }; buildFlags = [ "-tags production" ]; meta = with stdenv.lib; { homepage = https://www.keybase.io; description = "The Keybase FS FUSE driver"; platforms = platforms.unix; maintainers = with maintainers; [ rvolosatovs bennofs np ]; license = licenses.bsd3; }; } </del>

Related discussion:
text: Hi, I'm a Keybase developer and some of our users reported that the Nix packages were out of date. Keybase 4.1.0 was released a while ago, so I believe these need to be updated: Additionally, the KBFS nix should point to the new remote, with , and be on the same version as the other packages (4.1.0). Please let me know if you have any questions, happy to answer! Thanks. N/A N/A
if the users are using the stable branch, then the update will need to be backported. Otherwise if they are unstable then it should be just a few short moments ;)
KBFS has not been updated as directed here.
Code change:
<del> { lib, stdenv, fetchFromGitHub, autoreconfHook, flex, libtool }: </del> <ins> { lib, fetchFromGitHub, buildGoModule }: </ins> <del> stdenv.mkDerivation rec { </del> <ins> buildGoModule rec { </ins> pname = "miller"; <del> version = "5.10.3"; </del> <ins> version = "6.2.0"; </ins> src = fetchFromGitHub { owner = "johnkerl"; repo = "miller"; <del> rev = "v${version}"; sha256 = "sha256-Mag7bIfZNdp+sM54yKp8HdH3kWjwWRfyPBGthej2jd8="; </del> <ins> # NOTE: The tag v6.2.0 has still old version number, as reported by #       `mlr --version`. This is the current head of the 6.2.0 branch, with #       the correct version number. # #       For future releases please check if we can use #       `rev = "v${version}"` again. rev = "a6dc231eefc209eb66b50b0773542c2e63501bba"; sha256 = "sha256-hMWcf43o1wiVjHsgH+ZDBny5vlZQkKyoJN5np4gUy4w="; </ins> }; <del> nativeBuildInputs = [ autoreconfHook flex libtool ]; </del> <ins> vendorSha256 = "sha256-2tl/twzkvWB1lnvi3fIptM77zi0lmAn7Pzoe0/lW6o4="; subPackages = [ "cmd/mlr" ]; </ins> meta = with lib; { <del> description = "Like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON"; homepage    = "http://johnkerl.org/miller/"; </del> <ins> description = "Like awk, sed, cut, join, and sort for data formats such as CSV, TSV, JSON, JSON Lines, and positionally-indexed"; homepage    = "https://github.com/johnkerl/miller"; </ins> license     = licenses.bsd2; maintainers = with maintainers; [ mstarzyk ]; platforms   = platforms.all;

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: miller <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 5.10.3 desired version: 6.1.0 miller is now written in Go; there's still a configure script and a makefile, but I don't know if it's now more complicated to package because of fetching dependencies in a reproducible way or whatever. <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.