jiebi/CodeConvo huggingface dataset:
Change:
"myst-parser" ]; <del> pythonImportsCheck = [ "myst_nb" ]; </del> <ins> pythonImportsCheck = [ "myst_nb" "myst_nb.sphinx_ext" ]; </ins> meta = with lib; { description = "A Jupyter Notebook Sphinx reader built on top of the MyST markdown parser";

Discussion:
The package, in , does not work in practice. The command throws a Python runtime exception. Steps to reproduce the behavior: a default book: on that directory Expect this error: The book builds.
Change:
gnome-menus gnome.gnome-bluetooth_1_0 gnome.gnome-settings-daemon <ins> gnome.mutter </ins> gnome.zenity graphene gtk3

Discussion:
Budgie desktop stopped working a few months ago on because gsettings schema supplied by Budgie is missing settings which was recently to . This causes to crash during startup making Budgie DE setup unusable. budgie-desktop from . .
Are you using Budgie alongside another desktop? Otherwise LightDM is the preferred choice for Budgie, but I will still look into this.
Oh, I didn't know that. When I switched from gnome to budgie, I kept and everything worked, so I kept it. I can confirm that if I use , everything works.
Change:
diff --git a/configure.ac b/configure.ac <del> index c909878..60c540e 100644 </del> <ins> index 88ccd91..0857782 100644 </ins> --- a/configure.ac +++ b/configure.ac @@ -59,7 +59,7 @@ AS_CASE([$host_os],

Discussion:
cc system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
Thanks!

Not sure how difficult it'd be to fix this, but thought I'd note it somewhere. We recently bumped to 0.8.5 but I don't see any reason that would make the patch apply again (although I can't confirm this myself :)). If it can't be resolved reasonably perhaps the patch should be dropped and "darwin" removed from ? EDIT: Looks like libbsd has a separate "port" for OSX: which I've filed an issue on (like was done previously, apparently): Try to build libbsd on Darwin; look at Hydra/Travis build failures. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
Yeah, I have just been manually updating the patch since v0.8.3. The "correct" thing to do would be to get the patch applied upstream in libbsd. Perhaps freedesktop doesn't want it though. /cc
Change:
-    """ - -    # detect if running on a SNAP <del> -    if os.getenv('PKG_MARKER') == "SNAP": </del> <ins> -    if os.getenv("PKG_MARKER") == "SNAP": </ins> -        pass -    else: -        # deploy cpufreqctl.auto-cpufreq script -        if os.path.isfile("/usr/bin/cpufreqctl"): <del> -            shutil.copy(SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq") </del> <ins> -            shutil.copy( -                SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq" -            ) </ins> -        else: <del> -            shutil.copy(SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq") </del> <ins> -            shutil.copy( -                SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq" -            ) </ins> +    # scripts are already in the correct place +    pass

Discussion:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it
Change:
let <del> common = { version, sha256, extraBuildInputs ? [ ] }: stdenv.mkDerivation (rec { </del> <ins> common = { version, sha256, extraBuildInputs ? [ ], knownVulnerabilities ? [ ] }: stdenv.mkDerivation (rec { </ins> inherit version; pname = "subversion";

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
See also:
This effectively needs a patch for the package in as far as I can see. It would be nice to have a label or something like that :)
Without knowing the internals of the subversion source well, I don't think it's going to be particularly easy to patch. The location to add the nullptr check is easy enough to find, but it's unclear what the right action to take is when the null is detected. The 1.10.x patch in that case calls a function that doesn't exist in 1.9. Without learning more about the subversion internals I'd be afraid of turning a null pointer dereference into something much worse. Or throwing an error that basically just terminates the process anyway, which wouldn't make the situation a whole lot better.
In that case it might make sense to mark it as known vulnerable?
Probably.
This doesn't affect nixos-unstable since has been removed there. Why did you scan a commit from March 19 for nixos-unstable?
Change:
}; config = mkIf (cfg.provider != "libc") { <del> boot.kernel.sysctl."vm.max_map_count" = mkIf (cfg.provider == "graphene-hardened") (mkDefault 1048576); </del> environment.etc."ld-nix.so.preload".text = '' ${providerLibPath} '';

Discussion:
Applications are starting to allocate more times than allowed by the default value of vm.maxmapcount, . For instance, this situation arises in applications such as Ryujinx () and newer Windows games like Hogwarts Legacy (). SteamOS has already addressed this matter by augmenting the aforementioned value, while Fedora intends to implement the same modification in Fedora 39 (, ).
Please feel free to send PRs, it's hard to track those issues as you don't mention any owner.
The line to add is: The questions are: How big should n be? ? ? In which file should I add it? At the bottom of
You mentioned other distros were thinking about bumping it, let's follow Fedora lead In the relevant file, a quick grep shows indeed that sysctl is one of the best candidate. :)
For the policy discussion: I'm all in favor of doing this soon(m). It is not really dangerous and as people have explained to me the previous default has been there for historical reasons and 32 bit systems.
Change:
sourceRoot = "${finalAttrs.src.name}/gpt4all-chat"; <del> postPatch = '' substituteInPlace CMakeLists.txt  --replace-fail 'set(CMAKE_INSTALL_PREFIX ''${CMAKE_BINARY_DIR}/install)' "" ''; </del> nativeBuildInputs = [ cmake qt6.wrapQtAppsHook

Discussion:
Package name: gpt4all Latest released version: 2.7.4 <!-- Search your package here: --- Current version on the unstable channel: 2.7.3 Current version on the stable/release channel: N/A <!-- 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]:
Change:
<del> { symlinkJoin, makeWrapper, stdenv }: idris: { path, lib }: </del> <ins> { lib, symlinkJoin, makeWrapper, idris-no-deps, gcc, gmp }: </ins> symlinkJoin { <del> name = idris.name; src = idris.src; paths = [ idris ]; </del> <ins> inherit (idris-no-deps) name src meta; paths = [ idris-no-deps ]; </ins> buildInputs = [ makeWrapper ]; <del> meta.platforms = idris.meta.platforms; </del> postBuild = '' wrapProgram $out/bin/idris  <del> --suffix PATH : ${ stdenv.lib.makeBinPath path }  --suffix LIBRARY_PATH : ${stdenv.lib.makeLibraryPath lib} ''; } </del> <ins> --run 'export IDRIS_CC=''${IDRIS_CC:-${lib.getBin gcc}/bin/gcc}'  --suffix LIBRARY_PATH : ${lib.makeLibraryPath [ gmp ]} ''; } </ins>

Discussion:
Idris requires a C compiler to function. To find a C compiler, it first checks IDRISCC, as implemented here: and then searches PATH. The current wrapper for the "idris" compiler binary appends /nix/store/...-gcc-wrapper/bin to the PATH. This unfortunately makes idris quite fragile: When my PATH has some bad program named "cc" on it, such as some ancient compiler that I've installed for whatever reason, idris will break. It's also a fairly unnecessary impurity. We should set IDRISCC in the wrapper instead, when it is not already set. This allows the user to still override the C compiler that is used if they want to, while significantly lowering the chance that things will be unexpectedly broken.
Change:
inherit (haskellPackages) ghcWithPackages; }; <del> hexen = callPackage ../games/hexen { }; </del> holdingnuts = callPackage ../games/holdingnuts { }; hyperrogue = callPackage ../games/hyperrogue { };

Discussion:
Package: hexen Error: Makefile:157: recipe for target 'mmisc.o' failed Platform: openSUSE 13.1, x8664, XFCE Version: nix-env (Nix) 1.9
It builds fine for 32bit x86 architectures. I’ve no idea if it runs however. I don’t know if this program has been ever meant to be built on x86_64.
Hmm, that's a good point. If it isn't meant to run on x86_64, would there be some way to indicate as such in the file, eg. using an ?
Setting the attribute to should be enough.
The i686 version builds for me but doesn't run.
(triage) status?
Still doesn't build on x64.
(triage) and now?
Still fails on on NixOS 18.03.
Then I suggest we remove it. Can you prepare a patch?
Change:
# With the open driver, nvidia-uvm does not automatically load as # a softdep of the nvidia module, so we explicitly load it for now. # See https://github.com/NixOS/nixpkgs/issues/334180 <del> ++ lib.optionals (config.services.xserver.enable && cfg.open) [ "nvidia_uvm" ]; </del> <ins> ++ lib.optionals (config.services.xserver.enable && useOpenModules) [ "nvidia_uvm" ]; </ins> # If requested enable modesetting via kernel parameters. kernelParams = lib.optional (offloadCfg.enable || cfg.modesetting.enable) "nvidia-drm.modeset=1" ++ lib.optional ((offloadCfg.enable || cfg.modesetting.enable) && lib.versionAtLeast nvidia_x11.version "545") "nvidia-drm.fbdev=1" ++ lib.optional cfg.powerManagement.enable "nvidia.NVreg_PreserveVideoMemoryAllocations=1" <del> ++ lib.optional cfg.open "nvidia.NVreg_OpenRmEnableUnsupportedGpus=1" </del> <ins> ++ lib.optional useOpenModules "nvidia.NVreg_OpenRmEnableUnsupportedGpus=1" </ins> ++ lib.optional (config.boot.kernelPackages.kernel.kernelAtLeast "6.2" && !ibtSupport) "ibt=off"; # enable finegrained power management

Discussion:
Steps to reproduce the behavior: after update Add 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. But I am using flakes and following unstable. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It was an intentional breaking change
TY.
To sum up, is non-optional and must be set now: When , use open source NVIDIA kernel module, this is now recommended by NVIDIA, but it doesn't work with older drivers. When , use proprietary kernel module. This is needed for people with older NVIDIA cards. More information:
Change:
novacomd = handleTestOn ["x86_64-linux"] ./novacomd.nix {}; nsd = handleTest ./nsd.nix {}; nzbget = handleTest ./nzbget.nix {}; <ins> nzbhydra2 = handleTest ./nzbhydra2.nix {}; </ins> oh-my-zsh = handleTest ./oh-my-zsh.nix {}; openarena = handleTest ./openarena.nix {}; openldap = handleTest ./openldap.nix {};

Discussion:
Project description From GitHub: Metadata homepage URL: source URL: license: apache 2.0 platforms: All (Java project)
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This is still important to me.
I marked this as stale due to inactivity. &rarr;
This issue is not stale. There is a PR in progress.
Change:
hardeningDisable = [ "format" ]; <ins> postInstall = '' mkdir -p $out/lib/udev/rules.d $out/lib/libgphoto2/print-camera-list udev-rules version 175 group camera >$out/lib/udev/rules.d/40-gphoto2.rules ''; </ins> meta = { homepage = http://www.gphoto.org/proj/libgphoto2/; description = "A library for accessing digital cameras";

Discussion:
I could not access my USB digital camera as a non-root user, due to insufficient permissions. The file in popped up with user and group set to . I'm new to NixOS and I'm not sure of the best way to solve something like this. Below I'll document a workaround that I used in my that solved the problem, in case that's helpful to others. But if a NixOS option along with some facility in the package could solve it, that would be ideal. Plug camera into USB Ensure it shows up in Run At first it died with "unknown error", but if you do you see the "insufficient permissions" message. System: 16.09.1357. (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 16.09.1357. I these to my : where I copied the file .
Tagging the gphoto2 maintainer thanks.
you can graft a module, which does exactly the steps above to fix this in long term. I did something similar for adb:
I see, thanks. So there's to define the option, and it references which contains the rules, maintained separately from the packages in . I'll aim to put together something similar for gphoto2.
Change:
]; license = licenses.unfree; platforms = platforms.linux; <del> inherit broken; </del> mainProgram = pname; maintainers = [ maintainers.pwoelfel ]; };

Discussion:
The package had been silently marked as broken. From what I can see, the developers now only provide a deb file for the latest version, see The deb link is I guess we should update the link instead of marking the package broken.
Change:
<del> diff --git a/setup_dxvk.sh b/setup_dxvk.sh index 3e63ecf0..87c04f23 100755 --- a/setup_dxvk.sh +++ b/setup_dxvk.sh @@ -133,6 +133,8 @@ rm -v "${dstfile}" fi $file_cmd "${srcfile}" "${dstfile}" +    elif [ "${4}" = "--force" ]; then +      $file_cmd "${srcfile}" "${dstfile}" else echo "${dstfile}: File not found in wine prefix" >&2 return 1 @@ -170,12 +172,12 @@ } install() { -  installFile "$win64_sys_path" "$dxvk_lib64" "$1" +  installFile "$win64_sys_path" "$dxvk_lib64" "$1" "${2-}" inst64_ret="$?" inst32_ret=-1 if $wow64; then -    installFile "$win32_sys_path" "$dxvk_lib32" "$1" +    installFile "$win32_sys_path" "$dxvk_lib32" "$1" "${2-}" inst32_ret="$?" fi @@ -214,3 +216,5 @@ $action d3d10core $action d3d11 + +basedir="" dxvk_lib32=@mcfgthreads32@/bin dxvk_lib64=@mcfgthreads64@/bin $action mcfgthread-12 --force </del>

Discussion:
In future releases of dxvk the setup script won't be included anymore so this issue is just to notify so something can be figured out for how the nix package should handle it beforehand. (Hope such an issue is okay) See
CC
Thanks for the heads up. The DLLs are already available via a output, but this will break anyone’s set up that relies on . A short term solution would be to vendor the script. Longer term, it would be ideal if there were a way to declaratively create and manage a Wine prefix.
1 has been released with the script removed
I saw that. It can also build natively on Linux, which is interesting. I need to think about how I want to do things and maybe see what other distributions that package it are doing.
God speed
There is a nix-gaming repository that contains such derivation: It also handles vkd3d-proton:
One approach I’m considering is splitting dxvk into dxvk110 (for Darwin and hardware no longer supported by 2.0) and dxvk2x (or just dxvk_2, not sure). The plain DXVK derivation could continue to provide the script (most likely copied from before upstream removed it) while the versioned ones would be built for the native platform only (Linux and Windows). Well, I guess if it builds on Darwin, I can set the platform to then mark it broken on Darwin. I doubt DXVK 2.0 will work on Darwin any time soon. There are a number of extensions DXVK needs that aren’t implemented yet in MoltenVK, and since DXVK is always adding and using new ones, it’s a moving target.
I created to add the script and bump DXVK. It also exposes native builds on Linux.
Change:
buildGoModule rec { pname = "ets"; <del> version = "0.2.1"; </del> <ins> version = "0.3.0"; </ins> src = fetchFromGitHub { <del> owner = "zmwangx"; repo = pname; </del> <ins> owner = "gdubicki"; repo = "ets"; </ins> rev = "v${version}"; <del> sha256 = "sha256-XWIDo5msTMTLr60x1R9cwsiZIDG6G+uHWx8idt4F2iA="; </del> <ins> hash = "sha256-PowJ3ig8TfGx9P/PJPVBL8GsMh+gGZVt9l4Rf7Mqk00="; </ins> }; <del> # https://github.com/zmwangx/ets/pull/18/ patches = [ (fetchpatch { url = "https://github.com/zmwangx/ets/commit/600ec17a9c86ca63cd022d00439cdc4978e2afa9.patch"; sha256 = "sha256-SGCISHkWNFubgKkQYx8Vf5/fknNDfPNYkSuw1mMhZaE="; }) ]; vendorHash = "sha256-+8dXfqOu8XTw2uEx3GAynQSHtzifejZtddr1CdxrupA="; </del> <ins> vendorHash = "sha256-XHgdiXdp9aNEAc/Apvb64ExnpywjddWOw1scNKy+ico="; </ins> ldflags = [ "-s" "-w" "-X main.version=v${version}-nixpkgs" ];

Discussion:
Package name: ets Latest released version: 0.3.0 Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I am not seeing a 0.3.0 release on their , where are you getting this from?
0 comes from , a fork of the original ets.
Nice, I knew this wasn't actively maintained anymore but wasn't aware of this fork. I'll take a look and submit a PR if it looks good and no one else has by the time I get to it.
Change:
eschalot = callPackage ../tools/security/eschalot { }; <del> espanso = callPackage ../applications/office/espanso { }; </del> <ins> espanso = callPackage ../applications/office/espanso { inherit (darwin.apple_sdk.frameworks) AppKit Cocoa Foundation; }; </ins> esphome = callPackage ../tools/misc/esphome { };

Discussion:
Trying to install espanso on osX, there are missing libraries, even after trying to install and Steps to reproduce the behavior: tries to compile fails with The build should work on osX n/a latest osX with nixpkgs 21.15 and nix-darwin Please run and paste the result.
You cannot install libraries (), they need to be to the package definition.
I tried adding them as dependencies, but the build still fails with the same error
I marked this as stale due to inactivity. &rarr;
Change:
, gdk-pixbuf, wrapGAppsHook }: <ins> let why3_1_5 = why3; in let why3 = why3_1_5.overrideAttrs (o: rec { version = "1.4.1"; src = fetchurl { url = "https://why3.gitlabpages.inria.fr/releases/${o.pname}-${version}.tar.gz"; sha256 = "sha256:1rqyypzlvagrn43ykl0c5wxyvnry5fl1ykn3xcvlzgghk96yq3jq"; }; }); in </ins> let mkocamlpath = p: "${p}/lib/ocaml/${ocamlPackages.ocaml.version}/site-lib"; runtimeDeps = with ocamlPackages; [

Discussion:
When using I'd expect to show Z3 and Alt-Ergo. Steps to reproduce the behavior: (make sure is merged or check out my branch) I'd expect and to be listed. The derivation does : It should do instead to overwrite the config completely. Please run and paste the result.
Thanks for the report. Would you like to open a PR with the proposed change?
Change:
couchdb = handleTest ./couchdb.nix {}; cri-o = handleTestOn ["aarch64-linux" "x86_64-linux"] ./cri-o.nix {}; cups-pdf = handleTest ./cups-pdf.nix {}; <ins> curl-impersonate = handleTest ./curl-impersonate.nix {}; </ins> custom-ca = handleTest ./custom-ca.nix {}; croc = handleTest ./croc.nix {}; deluge = handleTest ./deluge.nix {};

Discussion:
Project description is like curl, but doesn't get you blocked by cloudflare and other WAPs that insist you have the TLS fingerprint of a web browser. Metadata homepage URL: source URL: license: MIT platforms: linux
the build process produces a separate 'Chrome' and 'Firefox' impersonation binary
I started packaging the firefox variant of curl-impersonate in , but it has unresolved issues, including: missing the curl-impersonate wrapper scripts; PATH conflicts with ; disabled tests; missing shell completions; possible issues with getting an HTTP response from some sites including But it does sort of work and may be useful as a starting point. (Note that I have not checked the TLS fingerprint.)
I've opened which should add a fully working build from source of curl-impersonate (with both firefox and chrome variants)
Change:
freezegun gevent greenlet <del> html2text </del> idna jinja2 libsass

Discussion:
I was trying to build a NixOS derivation containing odoo using The flake output I built is a nixosConfiguration for the aarch64-linxu system, since I am running locally nix on darwin I am remote building to an aarch64-linux host. For odoo For werkzeug Please run and paste the result.
This is not a problem of werkzeug but odoo.
I changed the title, thank you for your help (ping for the update)
Change:
<del> --- pyside-setup-everywhere-src-5.12.3/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp~	2019-06-15 10:31:04.712949189 +0200 +++ pyside-setup-everywhere-src-5.12.3/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp	2019-06-15 11:52:52.894987343 +0200 @@ -317,15 +317,15 @@ </del> <ins> --- pyside-setup-everywhere-src-5.12.6/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp~	2020-07-08 14:37:13.022476435 -0700 +++ pyside-setup-everywhere-src-5.12.6/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp	2020-07-08 14:37:18.271484269 -0700 @@ -330,17 +330,15 @@ </ins> } #endif // NEED_CLANG_BUILTIN_INCLUDES

Discussion:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,
Change:
}; fileSystems."/nix/store" = <del> { fsType = "unionfs-fuse"; device = "unionfs"; options = [ "allow_other" "cow" "nonempty" "chroot=/mnt-root" "max_files=32768" "hide_meta_files" "dirs=/nix/.rw-store=rw:/nix/.ro-store=ro" ]; </del> <ins> { fsType = "overlay"; device = "overlay"; options = [ "lowerdir=/nix/.ro-store" "upperdir=/nix/.rw-store/store" "workdir=/nix/.rw-store/work" ]; </ins> }; <del> boot.initrd.availableKernelModules = [ "squashfs" "iso9660" "uas" ]; </del> <ins> boot.initrd.availableKernelModules = [ "squashfs" "iso9660" "uas" "overlay" ]; </ins> <del> boot.initrd.kernelModules = [ "loop" ]; </del> <ins> boot.initrd.kernelModules = [ "loop" "overlay" ]; </ins> # Closures to be copied to the Nix store on the CD, namely the init # script and the top-level system configuration directory.

Discussion:
got it working with this for the AArch64 community box: Presumably the hackiness could be lowered by doing a thing like we already do for unionfs-fuse: