jiebi/CodeConvo huggingface dataset:
Change:
binaryheap,,,,,vcunat bit32,,,,lua5_1,lblasc busted,,,,, <del> cassowary,,,,,marsam </del> <ins> cassowary,,,,,marsam alerque </ins> cjson,lua-cjson,,,, compat53,,,,,vcunat cosmo,,,,,marsam

Discussion:
I tried adding to , then running and noticed in the diff this still uses , and non-string URLs. To Reproduce Steps to reproduce the behavior: Expected behavior The diff shouldn't contain non-string URLs, and not use via . Notify maintainers
luarocks-nix needs to be updated. Its current state is messy (not clear which branch to use), I will update it.
Change:
<del> diff --git a/TOOLS/osxbundle.py b/TOOLS/osxbundle.py index 98699e478b..d02ecf610e 100755 --- a/TOOLS/osxbundle.py +++ b/TOOLS/osxbundle.py @@ -39,7 +39,7 @@ def apply_plist_template(plist_file, version): print(line.rstrip().replace('${VERSION}', version)) def sign_bundle(binary_name): -    sh('codesign --force --deep -s - ' + bundle_path(binary_name)) +    sh('rcodesign sign ' + bundle_path(binary_name)) def bundle_version(): if os.path.exists('VERSION'): </del>

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yeeessaah!
Change:
<ins> export NIX_CXXSTDLIB_COMPILE+="-isystem $(echo -n @gcc@/include/c++/*) -isystem $(echo -n @gcc@/include/c++/*)/$(@gcc@/bin/gcc -dumpmachine)" export NIX_CXXSTDLIB_LINK=" -stdlib=libstdc++" </ins>

Discussion:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error.

(I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.
Change:
, openssl , expat , libxcrypt-legacy <ins> , fontconfig </ins> , vmopts ? null }:

Discussion:
A clear and concise description of what the bug is. JetBrains editors run with which result in project built under the editors (i.e. in 's terminal) always picks up from . Even if the project is using for example . This result in ABI conflict when the build executable runs, because other components - which built using , outside clion - use from Steps to reproduce the behavior: well, this might be tricky to prepare a small project needed to support itself, should not leak into projects it edits  I suspect and in are problematic too introduced in
it seems that the fix should be to use command line switch instead of environment variable
And (or ), because JNA is looking for .so files there, so should be on one of them instead of
This is still a problem
Can confirm, this is an issue when using per-project environments which are on a different channel than my systems'. Shouldn't the "internals" be patched using e.g. instead?
For anyone else running into this: the workaround is to clear the environment variable in the IDE settings for the commands you want to run. Cumbersome, but it works.
The above workaround doesn't completely work. For instance, there is no way to remove when setting the project interpreter in PyCharm.
The following seems to work: I'll try to prepare a PR in the coming days. EDIT: It even discovered some missing dependencies and .
Has there been an update on this? I am trying to use prettier in Webstorm and all other tools to have needed the to be reset, if I want to run them. But this is not possible for prettier. I suspect that it would work with unset.
Just had this come up again trying to build a program with gcc 13 in CLion. Simply removing from in fixes the issue and doesn't appear to break clion, idea, or rider.
Change:
pnpm = nodeEnv.buildNodePackage { name = "pnpm"; packageName = "pnpm"; <del> version = "7.19.0"; </del> <ins> version = "7.24.3"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/pnpm/-/pnpm-7.19.0.tgz"; sha512 = "0ZPqlBY9M5fqKI9Ya0kEB7PQj7Pg7bYEjXbRbg4pNnJIObzXeO+PaK/8FBd8KMgJe5QpLb6rn2nVFHNSNoz+kw=="; </del> <ins> url = "https://registry.npmjs.org/pnpm/-/pnpm-7.24.3.tgz"; sha512 = "0fpP1l16xOY8YwsATSLodNNBa7bitV1cNY475fioVLR7Thx5tkCtdp3xIlvZYX8ZoPtedLhGn3fICC409HQSNQ=="; </ins> }; buildInputs = globalBuildInputs; meta = {

Discussion:
explanation pnpm version is a little bit old. May I ask for update in unstable channel to v7.24.3? Project description Fast, disk space efficient package manager: Fast. Up to 2x faster than the alternatives (see ). Efficient. Files inside node_modules are linked from a single content-addressable storage. . Strict. A package can access only dependencies that are specified in its Deterministic. Has a lockfile called pnpm- Works as a version manager. See . Works everywhere. Supports Windows, Linux, and macOS. Battle-tested. Used in production by teams of since 2016. . Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
Change:
, python3 , spice-protocol , usbredir <del> , usbutils </del> , vala <ins> , wayland-protocols </ins> , zlib , withPolkit ? true }:

Discussion:
A regular update fails because apparently won't find the module: (edit: line-wrapped for clarity) Please run and paste the result.
now I see that this is fixed by . I did my search before, but I haven't seen that one.
This PR is already on nixos-unstable, but I still cannot compile :
I had the same problem and can still reproduce on master building with the flake:
We need this upstream patch: freedesktop/spice-common
fixed , not . , like , pulls in as a Git submodule.
I just tried bumping spice-gtk to version 0.40 locally (like suggested by ) and it indeed passes that "check for dependencies" phase of the build. It fails later on though for reasons that I'm not familiar enough with the build process to understand. With this patch: I get the following build log:
the issue is still persisting after 4 days :(
Not directly, it's fixed on master (and stable branches I guess, it builds on nixos-21.11 for example), but nixos-unstable can't catch up right now because of another completely unrelated issue, see .
Change:
}: let <del> old-openfst = openfst.overrideAttrs (self: { </del> <ins> old-openfst = openfst.overrideAttrs (prev: { version = "kag-unstable-2022-05-06"; </ins> src = fetchFromGitHub { owner = "kkm000"; repo = "openfst"; <ins> # required by https://github.com/daanzu/kaldi-fork-active-grammar/blob/e9c7d0ffca401cf312779d25f2c05a34b41ff696/cmake/third_party/openfst.cmake#L7 </ins> rev = "0bca6e76d24647427356dc242b0adbf3b5f1a8d9"; sha256 = "1802rr14a03zl1wa5a0x1fa412kcvbgprgkadfj5s6s3agnn11rx"; }; buildInputs = [ zlib ]; <del> }); in </del> <ins> }); in </ins> assert blas.implementation == "openblas" && lapack.implementation == "openblas";

Discussion:
I'm trying to run the example script , but I get the following error: Steps to reproduce the behavior: into this flake: (Adapt paths in script) I'm trying out the software for the first time, so I didn't know what to expect, but I guess I didn't expect this error. I tried nixpkgs master first, but there, wouldn't build.
Change:
python3Packages.buildPythonApplication rec { pname = "alpaca"; <del> version = "1.0.1"; </del> <ins> version = "1.0.5"; </ins> pyproject = false; # Built with meson src = fetchFromGitHub { owner = "Jeffser"; repo = "Alpaca"; rev = version; <del> hash = "sha256-GxnYPnrjaJ47/i+pigw+on2dmbHwQSX+STasvqnAtuQ="; </del> <ins> hash = "sha256-xNQLaMvZaJq7Bmz+c8OQhta3IdFXpVB2bSNwXCRj6rY="; </ins> }; patches = [ # Change the way XDG paths are handled so it makes sense outside of flatpak <del> ./fix_xdg_path_flatpak.patch </del> <ins> # https://github.com/Jeffser/Alpaca/pull/187 ./flatpak_path_fixes.patch </ins> ]; <del> postPatch = '' substituteInPlace src/local_instance.py  --replace-fail '/app/bin/ollama' 'ollama' substituteInPlace src/window.py  --replace-fail '/app/share' "$out/share" ''; </del> nativeBuildInputs = [ appstream meson

Discussion:
Alpaca does not use system theme configuration. (probably has something to do with flatpak) Affected: GTK4 theme GTK4 polarity Cursor theme Steps to reproduce the behavior: customized NixOS system, example: up and run nixpkgs#alpaca on nixos-unstable: App follows system theme settings: GTK4 Theme GTK4 Polarity Cursor theme ! <!-- 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]:
It works for me, with . Maybe there's something to do with your theme? (Is that some simple libadwaita stylesheets?) Also try setting .
didn't help, I will provide my gtk settings files. (they are symlinks to /nix/store btw) the theme is generated by stylix but under the hood it uses In any other situation I would assume it's a problem with my theme but this is the first time this happened to me on NixOS and I use a lot of gtk apps.
Yes, I've tried with , and it behaves the same. But there are probably other applications that behave similarly, because I set this environment variable a long time ago for similar reasons. I will try to read its source code later. (this may also be caused by me setting XDG paths)
Change:
doInstallCheck = true; <ins> # socket path becomes too long otherwise preInstallCheck = lib.optional stdenv.isDarwin "export TMPDIR=/tmp"; </ins> separateDebugInfo = stdenv.isLinux; crossAttrs = {

Discussion:
Building on macOS fails in the test phase, since the path to the nix-daemon's socket is longer than the maximum 108 characters. This is a combination of macOS (long TMPDIR set to the build directory). I'm not really sure whether this is more of a nixpkgs or a nix issue. The problem can be worked around by setting TMPDIR=/tmp manually, but it seems to me that that should not be required... Compare nix commit , which removed a workaround for this limitation. System: Darwin 16.6.0 Nix version: 1.11.11 (building nix-1.12pre5413_b4b1f452) Nixpkgs version: master as of 2017-07-04 Sandboxing enabled: no
Change:
terminalType = mkOption { type = types.str; default = "xterm-256color"; <del> description = lib.mdDoc "Terminal type to report."; </del> <ins> description = "Terminal type to report."; </ins> }; checkOrigin = mkOption { type = types.bool; default = false; <del> description = lib.mdDoc "Whether to allow a websocket connection from a different origin."; </del> <ins> description = "Whether to allow a websocket connection from a different origin."; </ins> }; maxClients = mkOption { type = types.int; default = 0; <del> description = lib.mdDoc "Maximum clients to support (0, no limit)"; </del> <ins> description = "Maximum clients to support (0, no limit)"; </ins> }; indexFile = mkOption { type = types.nullOr types.path; default = null; <del> description = lib.mdDoc "Custom index.html path"; </del> <ins> description = "Custom index.html path"; </ins> }; enableIPv6 = mkOption { type = types.bool; default = false; <del> description = lib.mdDoc "Whether or not to enable IPv6 support."; </del> <ins> description = "Whether or not to enable IPv6 support."; </ins> }; enableSSL = mkOption { type = types.bool; default = false; <del> description = lib.mdDoc "Whether or not to enable SSL (https) support."; </del> <ins> description = "Whether or not to enable SSL (https) support."; </ins> }; certFile = mkOption { type = types.nullOr types.path; default = null; <del> description = lib.mdDoc "SSL certificate file path."; </del> <ins> description = "SSL certificate file path."; </ins> }; keyFile = mkOption { type = types.nullOr types.path; default = null; apply = value: if value == null then null else toString value; <del> description = lib.mdDoc '' </del> <ins> description = '' </ins> SSL key file path. For insecurely putting the keyFile in the globally readable store use `pkgs.writeText "ttydKeyFile" "SSLKEY"`.

Discussion:
After a recent upgrade ( followed by ) the browser-based terminal in my setup, served with ttyd, no longer accepts user input (i.e. where the user can type and enter commands through the browser). Normally you are greeted with a terminal login screen and can enter username/password and log in, but it is now no longer possible to type or submit either. After researching, there is a breaking change in ttyd version =1.7.4, where the terminal is now readonly by default, users must pass or to get an interactive terminal. Note that the release notes appear to incorrectly indicate a lower-case flag, upper-case is needed. Consulting both the listed and the nixpkgs , there is no currently no way to pass this option. I am unsure who if anyone is the maintainer of this service, although I see that maintains the ttyd package. I will attempt to fix and submit a PR.
Change:
''; in { <del> # https://github.com/lightbend/config/blob/main/HOCON.md </del> format = { generator ? hocon-generator , validator ? hocon-validator <del> # `include classpath("")` is not implemented in pyhocon. # In the case that you need this functionality, # you will have to disable pyhocon validation. </del> , doCheck ? true }: let hoconLib = {

Discussion:
In , was . In the review I forgot to mention that documentation should be . Add documentation to , where the other are also documented. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
stdenv.mkDerivation rec { pname = "vapoursynth"; <del> version = "R48"; </del> <ins> version = "R49"; </ins> src = fetchFromGitHub { owner  = "vapoursynth"; repo   = "vapoursynth"; rev    = version; <del> sha256 = "1i6163bidlp0p9zcnxpsphr44ayfzd51fig4ri7vbrbl9lw9jaih"; </del> <ins> sha256 = "1d298mlb24nlc2x7pixfbkd0qbpv4c706c32idsgpi96z1spkhvl"; </ins> }; <del> nativeBuildInputs = [ pkgconfig autoreconfHook nasm makeWrapper ]; </del> <ins> nativeBuildInputs = [ pkgconfig autoreconfHook makeWrapper ]; </ins> buildInputs = [ zimg libass (python3.withPackages (ps: with ps; [ sphinx cython ]))

Discussion:
Vapoursynth in nixpkgs is still version R47 which is affected by serious (crashes on some CPUs, artifacts) bugs that were fixed in R49 (Audio support was also merged since then). Moreover R47 is the first vapoursynth version to not require nasm anymore (all asm was removed in favor of intrinsics). For details, the last few articles on the are a good read. It'd be nice to have an upgraded package for it. It's my first issue so I'm not sure I did this correctly.
Tested and backported to 20.03 in .
Change:
fetchMavenArtifact = callPackage ../build-support/fetchmavenartifact { }; <ins> fetchpijul = callPackage ../build-support/fetchpijul { }; </ins> inherit (callPackage ../build-support/node/fetch-yarn-deps { }) prefetch-yarn-deps fetchYarnDeps;

Discussion:
It would be nice to add pijul () to the list of source controls that nix supports.
What are some motivating examples of software distributed via Pijul that you would like to see available through Nix/Nixpkgs?
Sort of a chicken and egg problem. My use case is for libraries. I want to start using pijul exclusively for source control for projects I control, therefore pulling source via say niv would require a fetchpijul to exist somewhere and nixpkgs seemed like the most likely place. It feels like a common theme that folks would be keen to use it over git if there were less friction and more integration options.
Concrete use case:
Is there a good high level outline on what needs to happen for the fetching process? I might be open to taking a stab at this, but just reading through the fetchgit source unassisted was a tad intimidating, I thought. Does there also need to be some work done in nix itself to support something like using Pijul for tracking what is included in a flake?
fetchFossil sounds like a better starting point…
Change:
</varlistentry> <varlistentry> <term> <ins> <literal>types.optionType</literal> </term> <listitem> <para> The type of an option’s type. Its merging operation ensures that nested options have the correct file location annotated, and that if possible, multiple option definitions are correctly merged together. The main use case is as the type of the <literal>_module.freeformType</literal> option. </para> </listitem> </varlistentry> <varlistentry> <term> </ins> <literal>types.attrs</literal> </term> <listitem>

Discussion:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!
Change:
doCheck = false; meta = with lib; { <del> homepage = "https://git.goral.net.pl/mgoral/i3a"; </del> <ins> changelog = "https://git.goral.net.pl/i3a.git/log/"; </ins> description = "A set of scripts used for automation of i3 and sway window manager layouts"; <ins> homepage = "https://git.goral.net.pl/i3a.git/about"; </ins> license = licenses.gpl3Plus; maintainers = with maintainers; [ moni ]; };

Discussion:
Hello, I'm the author of i3a. Thanks for packaging it for nix. I noticed that nix package contains outdated metadata. It would be great for nix users if you could update it. Current homepage for i3a is and source code link is The latest version is 2.1.1: Thanks, mg
Change:
, django-paintstore , django-q , django_compressor <del> , django_extensions </del> <ins> , django-extensions </ins> , djangorestframework , flufl_lock , mistune_2_0

Discussion:
python38Packages.djangoextensions and python39Packages.djangoextensions Fails to build. I discovered it as it was a dependency of Archivebox that also doesnt build now. Simple way to reproduce is: a file : I expected the package to build and not fail with errors. It appears it is the test's that fail and not the actual build. ! I have much larger file that I choose not to include as it is the same error i got in the minimal version and all the other clutter likely is not responsible. No maintainers for either of the packages :( Please run and paste the result. this path will be fetched (0.06 MiB download, 0.30 MiB unpacked):
Change:
tar -xzf ${icons} -C $sourceRoot/src ''; <del> patch_version = "2.18.2612.102.1"; </del> <ins> patch_version = "${version}.1"; </ins> patches = [ (fetchpatch rec { name   = "fcitx-mozc-${patch_version}.patch"; url    = "https://download.fcitx-im.org/fcitx-mozc/${name}"; <del> sha256 = "1f9m4310kz09v5qvnv75ka2vq63m7by023qrkpddgq4dv7gxx3ca"; </del> <ins> sha256 = "0a8q3vzcbai1ccdrl6qdb81gvbw8aby4lqkl6qs9hg68p6zg42hg"; </ins> }) # https://github.com/google/mozc/pull/444 - fix for gcc8 STL (fetchpatch { url = "https://github.com/google/mozc/commit/82d38f929882a9c62289b179c6fe41efed249987.patch"; sha256 = "07cja1b7qfsd3i76nscf1zwiav74h7d6h2g9g2w4bs3h1mc9jwla"; }) <ins> # Support dates after 2019 (fetchpatch { url = "https://salsa.debian.org/debian/mozc/-/raw/master/debian/patches/add_support_new_japanese_era.patch"; sha256 = "1dsiiglrmm8i8shn2hv0j2b8pv6miysjrimj4569h606j4lwmcw2"; }) </ins> ]; postPatch = ''

Discussion:
Describe the bug I was trying to upgrade my system to latest unstable when I encountered this error: error: --- Error
--------------------- nix-build builder for '/nix/store/4akxpw50h059071m68rm96qi3jmdv7zi-ibus-mozc-' failed with exit code 1; last 10 log lines: File "", line 854, in BuildMain BuildWithNinja(options, targets) File "", line 828, in BuildWithNinja RunOrDie([ninja, '-C', buildarg] + ninjatargets) File "", line 99, in RunOrDie '=========='])) ERROR: ninja -C outlinux/Release ibusmozc mozcemacshelper mozcserver mozctool mozc_renderer
cc: because of .
likewsie fcitx-mozc stopped working. Seems like there is this fork of google-mozc with more recent commits but changing upstream would require more changes:
Change:
runHook postInstall ''; <del> env.NIX_CFLAGS_COMPILE = with python3.pkgs; "-I${pygame-sdl2}/include/${python.libPrefix}"; </del> <ins> env.NIX_CFLAGS_COMPILE = with python311.pkgs; "-I${pygame-sdl2}/include/${python.libPrefix}"; </ins> meta = { description = "Visual Novel Engine";

Discussion:
Package name: renpy Latest released version: 8.3.2 <!-- Search your package here: --- Current version on the unstable channel: 8.2.1. Current version on the stable/release channel: 8.2.1. <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: