jiebi/CodeConvo huggingface dataset:
Code change:
let value = getAttrFromPath [ "services" "ddclient" "domain" ] config; in if value != "" then [ value ] else [])) (mkRemovedOptionModule [ "services" "ddclient" "homeDir" ] "") <ins> (mkRenamedOptionModule [ "services" "flatpak" "extraPortals" ] [ "xdg" "portal" "extraPortals" ]) </ins> (mkRenamedOptionModule [ "services" "i2pd" "extIp" ] [ "services" "i2pd" "address" ]) (mkRenamedOptionModule [ "services" "kubernetes" "apiserver" "admissionControl" ] [ "services" "kubernetes" "apiserver" "enableAdmissionPlugins" ]) (mkRenamedOptionModule [ "services" "kubernetes" "apiserver" "address" ] ["services" "kubernetes" "apiserver" "bindAddress"])

Related discussion:
text: It is possible to use Plasma’s native file dialogues in Firefox 64 to open or save a file. Currently this feature is not working in NixOS, and it seems to me some small changes would need to be made to derivation in order to enable it. I propose we include this option together with as a Firefox option in NixOS (see also: ). I followed the explanation on how to enable this feature as it was published on : Firefox (64 is current stable) from a terminal emulator But it produces the following error: system: host os: multi-user?: sandbox: version: channels(root): channels(hook): nixpkgs:
You'll probably have to do something like this to expose the dbus service:
Where? In:
It needs to go into a nixos module or your .
Code change:
<del> { lib, buildPythonPackage, fetchPypi, unrar }: </del> <ins> { lib, stdenv, buildPythonPackage, fetchPypi, unrar }: </ins> buildPythonPackage rec { pname = "unrardll";

Related discussion:
text: Steps to reproduce the behavior: Happens on intel darwin. Please run and paste the result.
The .so dependency should be fixed up:
Code change:
setuid = true; owner = "root"; group = "root"; <del> source = "/run/${dirName}/nix-helpers/qemu-bridge-helper"; </del> <ins> source = "${cfg.qemu.package}/libexec/qemu-bridge-helper"; </ins> }; systemd.packages = [ cfg.package ];

Related discussion:
text: When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.
Code change:
setuid = true; owner = "root"; group = "root"; <del> source = "/run/${dirName}/nix-helpers/qemu-bridge-helper"; </del> <ins> source = "${cfg.qemu.package}/libexec/qemu-bridge-helper"; </ins> }; systemd.packages = [ cfg.package ];

Related discussion:
text: I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?
Code change:
<ins> { lib, stdenv, fetchFromGitea, }: stdenv.mkDerivation rec { pname = "game-devices-udev-rules"; version = "0.21"; src = fetchFromGitea { domain = "codeberg.org"; owner = "fabiscafe"; repo = "game-devices-udev"; rev = version; hash = "sha256-Yy91yDF5BSDTTlr/Pj8e0UklPooEdzvRW8mkhdHtHVo="; }; installPhase = '' runHook preInstall install -Dm444 -t "$out/lib/udev/rules.d" *.rules runHook postInstall ''; meta = with lib; { description = "Udev rules to make supported controllers available with user-grade permissions"; homepage = "https://codeberg.org/fabiscafe/game-devices-udev"; license = licenses.mit; longDescription = '' These udev rules are intended to be used as a package under 'services.udev.packages'. They will not be activated if installed as 'environment.systemPackages' or 'users.user.<user>.packages'. Additionally, you may need to enable 'hardware.uinput'. ''; platforms = platforms.linux; maintainers = with maintainers; [keenanweaver]; }; } </ins>

Related discussion:
text: Project description udev rules to make supported controllers available with user-grade permissions Metadata homepage URL: source URL: license: mit platforms: linux
Code change:
${keyboard.config} ''; <ins> # Only the config file generated by this module is checked.  A # user-provided one is not checked because it may not be available # at build time.  I think this is a good balance between module # complexity and functionality. </ins> checkPhase = '' ${getExe cfg.package} --cfg "$target" --check --debug '';

Related discussion:
text: Currently it's only possible to configure kanata by specifying specific parts one at a time. It's not possible to read a configuration from a file and use that instead of the specific parts. I use HomeManager to manage the kanata configuration file and because it's also used for Windows this is the most platform neutral way for me without duplicating parts of the configuration. As a workaround I did it like this for now: But clearly that is not ideal. What I would want is to just keep the 'readFile' and uncomment the 'defcfg' part from the configuration file ()
I created to address this issue. Could you help test it?
Thanks a lot for the fast solution! I tested it with my config and it works without any issues.
Code change:
webdis = callPackage ../development/tools/database/webdis { }; <ins> xmake = callPackage ../development/tools/build-managers/xmake { lua = lua5_4; }; </ins> xc3sprog = callPackage ../development/embedded/xc3sprog { stdenv = gcc10StdenvCompat; }; xcb-imdkit = callPackage ../development/libraries/xcb-imdkit { };

Related discussion:
text: Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix
Code change:
maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

Related discussion:
text: I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.
Code change:
maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

Related discussion:
text: The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.
Code change:
maintainers = [ ]; platforms = stdenv.lib.platforms.all; <ins> priority = 10; </ins> }; }

Related discussion:
text: 0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.
Code change:
<ins> { lib , stdenv , fetchFromGitHub , emptyDirectory , writeText , makeBinaryWrapper , gradle , jdk22 , llvmPackages }: let gradleInit = writeText "init.gradle" '' logger.lifecycle 'Replacing Maven repositories with empty directory...' gradle.projectsLoaded { rootProject.allprojects { buildscript { repositories { clear() maven { url '${emptyDirectory}' } } } repositories { clear() maven { url '${emptyDirectory}' } } } } settingsEvaluated { settings -> settings.pluginManagement { repositories { maven { url '${emptyDirectory}' } } } } ''; in stdenv.mkDerivation { pname = "jextract"; version = "unstable-2024-03-13"; src = fetchFromGitHub { owner = "openjdk"; repo = "jextract"; rev = "b9ec8879cff052b463237fdd76382b3a5cd8ff2b"; hash = "sha256-+4AM8pzXPIO/CS3+Rd/jJf2xDvAo7K7FRyNE8rXvk5U="; }; nativeBuildInputs = [ gradle makeBinaryWrapper ]; env = { ORG_GRADLE_PROJECT_llvm_home = llvmPackages.libclang.lib; ORG_GRADLE_PROJECT_jdk22_home = jdk22; }; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --console plain --init-script "${gradleInit}" assemble runHook postBuild ''; doCheck = true; checkPhase = '' runHook preCheck gradle --console plain --init-script "${gradleInit}" verify runHook postCheck ''; installPhase = '' runHook preInstall mkdir -p $out/opt/ cp -r ./build/jextract $out/opt/jextract makeBinaryWrapper "$out/opt/jextract/bin/jextract" "$out/bin/jextract" runHook postInstall ''; meta = with lib; { description = "A tool which mechanically generates Java bindings from a native library headers"; mainProgram = "jextract"; homepage = "https://github.com/openjdk/jextract"; platforms = jdk22.meta.platforms; license = licenses.gpl2Only; maintainers = with maintainers; [ jlesquembre sharzy ]; }; } </ins>

Related discussion:
text: And now that Panama/FF&M is final, I'm hoping it will be possible to use jextract 22 to build headers for JDK 23+. Newer versions of jextract might offer improvements, but headers generated for JDK 22 should work wth JDK 23+ (I don't know what guarantees the JDK makes for that, but this seems a reasonable conclusion given a stable API.)
Nice to hear that, and thanks for your work! IMO, I think it's worth. The point is that JDK 21 is a LTS version, some downstreams prefer to use a LTS version of JDK to develop their projects. For them, if we don't keep JDK 21's , this will be unavailable to them unless they give up on choosing LTS and do some extra effort - porting their project to a newer version of JDK.
I agree. But I also strongly encourage new projects to start with JDK 22 and existing projects to migrate as quickly as possible. Having to make sure "preview mode" is set in the compiler and at runtime can cause various problems with tools and the output of the latest is significantly improved. In general, it's much better to be using a non-LTS JDK with a non-preview feature than and LTS JDK with a preview feature. I migrated my project recently and wish I had migrated to JDK 22 much earlier.
PR has been merged. I gave it a quick test on macOS/aarch64 and it seems to be working. (I used it to build which uses JDK 22 and Panama via Gradle's Java toolchains)
Code change:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Related discussion:
text: Invoking is producing the following error message: is part of the package so it's just failing to locate it. I'm running on NixOS Unstable.
I believe this issue has been fixed and can be closed:
Code change:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Related discussion:
text: Travis has been giving build failures because of this: commit seems to be at fault here.. The reason I didn't just fix this this bug and push upstream is because there are two different ways to approach this and I'm not sure which the best course of action is. a) jfsrec removal was intentional, remove all references to jfsrec b) restore jfsrec Here is a listing of all current things pointing to jfsrec:
The jfsrec commit has already been reverted.
thanks for the info
Code change:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Related discussion:
text: nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources
Code change:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Related discussion:
text: In its builder, there's a command saying "Need libgcc until the llvm compiler-rt library is complete". It's from in 2011, so I'm inclined to think it's out of date and that the dependency on gcc is spurious. Is that true?
For context from #llvm on oftc:
covers , covers , the only thing I'm not sure about is the C runtime files (e.g. ), none of those packages seem to come with them (but maybe clang does it another way)
Actually some of the files come from glibc, but these ones come with gcc: crtprec32.o crtendS.o crtbeginS.o crtfastmath.o crtprec64.o crtbeginT.o crtprec80.o crtbegin.o crtend.o
This story is quite old, is this still true?
Closing because no reaction.
Code change:
, pillow , toml , numpy <ins> , pyyaml </ins> , python , pytestCheckHook }: buildPythonPackage rec { pname = "clickgen"; <del> version = "2.1.3"; </del> <ins> version = "2.1.9"; </ins> format = "setuptools"; disabled = pythonOlder "3.8";

Related discussion:
text: Package name: clickgen Latest released version: 2.1.9 <!-- Search your package here: --- Current version on the unstable channel: 2.1.3 Current version on the stable/release channel: 2.1.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.
Code change:
monA.succeed( "ceph osd pool create multi-node-test 32 32", "ceph osd pool ls | grep 'multi-node-test'", <ins> # We need to enable an application on the pool, otherwise it will # stay unhealthy in state POOL_APP_NOT_ENABLED. # Creating a CephFS would do this automatically, but we haven't done that here. # See: https://docs.ceph.com/en/reef/rados/operations/pools/#associating-a-pool-with-an-application # We use the custom application name "nixos-test" for this. "ceph osd pool application enable multi-node-test nixos-test", </ins> "ceph osd pool rename multi-node-test multi-node-other-test", "ceph osd pool ls | grep 'multi-node-other-test'", )

Related discussion:
text: Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding &lt;!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the
Code change:
quickemu ''; <del> patches = [ # reduces windows vm ram requirements to 4G, to match microsoft recommendations # TODO: remove on next release (fetchpatch2 { name = "decrease-windows-ram-requirements.patch"; url = "https://github.com/quickemu-project/quickemu/commit/f51697593a4650c5486661292e2febe1d16f8c71.patch"; hash = "sha256-J5hIvQGtkufOcjk2FZN65iox/W2zkLlg+Veg9TF11Fs="; }) ]; </del> nativeBuildInputs = [ makeWrapper installShellFiles

Related discussion:
text: There is a bug in the latest release of quickemu (present in nixpkgs), that sends invalid flags to qemu and thus doesn't work for MacOS (maybe others too). The fix I was planning to PR was to simply move the src to point to the most current revision. I wasn't 100% sure if that was something that I should do however, given it would set the precedent that we follow revisions for this package instead of the version tag, which may add maintenance burden. Just wanted opinions before I made a PR, would it be acceptable to bump the revision temporarily to avoid this issue? It's niche but its real and could affect users of this package. Steps to reproduce the behavior: Pops open a Qemu window with the appropriate screens. Fails with a strange "macos-ventura/macos- file not found", but it is related to the bugged release. <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Don't know of any official policy on this. My opinion: If it's a single commit that fixes the issue, you can add a patch. If it's spread out over multiple commits, use current unstable, but that may introduce other unknown regressions and breaking changes. And in any case we'd go back to the release tag on the next release.
Patching sounds like a good idea, hopefully it is just one commit. Though honestly from personal testing the newest release worked perfectly fine (I tested via an override).