jiebi/CodeConvo huggingface dataset:
Change:
path = mkOptionType { name = "path"; <del> # Hacky: there is no ‘isPath’ primop. check = x: builtins.substring 0 1 (toString x) == "/"; </del> <ins> check = x: isCoercibleToString x && builtins.substring 0 1 (toString x) == "/"; </ins> merge = mergeEqualOption; };

Discussion:
Describe the bug it adds source paths to the store it is partial To Reproduce Steps to reproduce the behavior: Partiality: Adding sources to store: a module with a option the module use that path by further filtering the source it source will be in the store (nb can be huge) Expected behavior No side effects, so also no exceptions. Additional context will need to understand when string coercion is possible to avoid both exceptions and adding sources to the store. toString implementation: string coercion: Metadata Maintainer information:
Change:
patches = [ ./gcloud-path.patch <ins> ./gsutil-disable-updates.patch </ins> ]; installPhase = ''

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: Expected behavior Works. Metadata Maintainer information:
cc
I am getting same error
/cc . Maybe the closure size got reduced a bit too much
Hmm, this only seems to come up in . I think we plausibly just want to remove that function.
Change:
# optionally takes a GITHUB_TOKEN to overcome api rate limiting. if [ -n "$GITHUB_TOKEN" ]; then curl_args+=( --header "authorization: Bearer ${GITHUB_TOKEN}" ); fi <del> # get last master ref curl_args+=( --url https://api.github.com/repos/adi1090x/files/commits/master ) last_ref=$(curl "${curl_args[@]}" | jq -r '.sha' ) unset curl_args[-1] curl_args+=( https://api.github.com/repos/adi1090x/files/git/trees/$last_ref?recursive=1 ) theme_archives=$(curl "${curl_args[@]}"  | jq '.tree | map(select(.path| test("^plymouth-themes/themes/pack_.*tar.gz$"))| .path)') </del> <ins> # get latest release assets curl_args+=( --url https://api.github.com/repos/adi1090x/plymouth-themes/releases/latest ) theme_archives=$(curl "${curl_args[@]}" | jq -r '.assets' ) </ins> dirname="$(dirname "$0")" printf '{n' > "$dirname/shas.nix" <del> repo_url="https://github.com/adi1090x/files/raw/$last_ref" </del> while read -r file_path do <del> name=$(basename $file_path) printf '  "%s" = {n    url = "%s";n    sha = "%s";n  };n' "${name%%.*}" "$repo_url/$file_path" "$(nix-prefetch-url "$repo_url/$file_path")" >>"$dirname/shas.nix" done < <(jq -r '.[]' <<<"$theme_archives") </del> <ins> name="$(basename $file_path)" name="${name/.tar.gz/}" printf '  "%s" = {n    url = "%s";n    sha = "%s";n  };n' "${name}" "$file_path" "$(nix-prefetch-url "$file_path")" >>"$dirname/shas.nix" done < <(jq -r '.[].browser_download_url' <<<"$theme_archives") </ins> printf '}n' >> "$dirname/shas.nix"

Discussion:
Package name: adi1090x-plymouth-themes Latest released version: v1.0 (yay) <!-- Search your package here: --- Current version on the unstable channel: 2020-12-28 Current version on the stable/release channel: 2020-12-28 <!-- 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! --- There's been a few fixes recently and the release is fairly fresh but I thought I'd create this Notify maintainers Note for maintainers: Please tag this issue in your PR.
Tried to prep an update for this in
LGTM, thanks :smile:
Change:
<ins> { stdenv , pkgs , fetchFromGitHub , pkg-config , cmake , cpp-utilities , qtutilities , mp4v2 , libid3tag , qtbase , qttools , qtwebengine , qtx11extras , tagparser , wrapQtAppsHook }: stdenv.mkDerivation rec { pname = "tageditor"; version = "3.3.10"; src = fetchFromGitHub { owner = "martchus"; repo = "tageditor"; rev = "v${version}"; sha256 = "16cmq7dyalcwc8gx1y9acngw5imjh8ydp4prxy7qpzk4fj3kpsak"; }; nativeBuildInputs = [ pkg-config cmake wrapQtAppsHook ]; buildInputs = [ mp4v2 libid3tag pkg-config qtbase qttools qtx11extras qtwebengine cpp-utilities qtutilities tagparser ]; enableParallelBuilding = true; meta = with pkgs.lib; { homepage = "https://github.com/Martchus/tageditor"; description = "A tag editor with Qt GUI and command-line interface supporting MP4/M4A/AAC (iTunes), ID3, Vorbis, Opus, FLAC and Matroska"; license = licenses.gpl2; maintainers = [ maintainers.matthiasbeyer ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description A tag editor with Qt GUI and command-line interface. Supports MP4 (iTunes), ID3, Vorbis, Opus, FLAC and Matroska. Metadata homepage URL: source URL: license: mit, GPLv2.0 platforms: linux
I am working on it. Progress:
Change:
{ stdenv, fetchurl, lib, patchelf, cdrkit, kernel, which, makeWrapper <del> , zlib, xorg, dbus, virtualbox }: </del> <ins> , zlib, xorg, dbus, virtualbox, dos2unix }: </ins> let version = virtualbox.version;

Discussion:
Describe the bug I am no longer able to build VirtualBox with guest additions when switching over to the lastest linux kernel: . The error complains that headers are missing/not found. This bug occurs consistently across all 3 of my machines. I am still able to build VirtualBox without guest additions. To Reproduce Here is the relevant snippet of my Additional context Here is the relevant errors from using Metadata Nix Info: Maintainer information:
Just hit the same thing myself too, very inconvenient to say the least.
Me too, is there any workaround?
No I never found a fix. In the end I had to remove VBox Guest.
It seems the only way to work around this is not to use boot.kernelPackages = pkgs.linuxPackages_latest;
Can you check whether this is still the case on the branch? I was able to build that with the same configuration as above:
I take that back - it's now failing at a later stage: This looks like we're missing a patch similar to the one in
agreed, that looks to be the exact same file that was patched in the host version of a VirtualBox. I did a quick search for an upstream bug for vboxguest but couldn't find anything. Perhaps it gets copied from the same source in the build process. I could try applying the same patch to vboxguest and alter the paths to see what happens. I won't have the opportunity to try that out until tonight (North America, west cost). So if you or someone else want to try it out sooner let me know.
Fix in , please test :-)
Change:
maintainers = with maintainers; [ travisbhartwell manveru prusnak ]; platforms = [ "x86_64-darwin" "x86_64-linux" "i686-linux" "armv7l-linux" "aarch64-linux" ] ++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ]; <del> knownVulnerabilities = optional (versionOlder version "6.0.0") "Electron version ${version} is EOL"; </del> <ins> knownVulnerabilities = optional (versionOlder version "12.0.0") "Electron version ${version} is EOL"; </ins> }; fetcher = vers: tag: hash: fetchurl {

Discussion:
, CVSSv3=8.6 (nixos-21.05, nixos-unstable) Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. A vulnerability in versions prior to 11.5.0, 12.1.0, and 13.3.0 allows a sandboxed renderer to request a "thumbnail" image of an arbitrary file on the user's system. The thumbnail can potentially include significant parts of the original file, including textual data in many cases. Versions 15.0.0-alpha.10, 14.0.0, 13.3.0, 12.1.0, and 11.5.0 all contain a fix for the vulnerability. Two workarounds aside from upgrading are available. One may make the vulnerability significantly more difficult for an attacker to exploit by enabling in one's app. One may also disable the functionality of the API if one does not need it. Scanned versions: nixos-21.05: ; nixos-unstable: . Cc Cc Cc
Fix in
Change:
--replace '${"$"}{LIBDIR}/opencollada'  '${opencollada}'  --replace '${"$"}{PYTHON_LIBPATH}/site-packages/numpy'  <del> '${python39Packages.numpy}/${python.sitePackages}/numpy' </del> <ins> '${python310Packages.numpy}/${python.sitePackages}/numpy' </ins> '' else '' substituteInPlace extern/clew/src/clew.c --replace '"libOpenCL.so"' '"${ocl-icd}/lib/libOpenCL.so"' '');

Discussion:
<!-- 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: blender <!-- 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: 2.93.5 desired version: 3.1 <!-- 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.
Change:
configureFlags = [ "--localstatedir=/var" "--without-lmdb" <ins> "--with-libidn2" </ins> ] ++ lib.optional enableGSSAPI "--with-gssapi=${libkrb5.dev}/bin/krb5-config" <del> ++ lib.optional (stdenv.hostPlatform != stdenv.buildPlatform) "BUILD_CC=$(CC_FOR_BUILD)"; </del> <ins> ++ lib.optional (stdenv.hostPlatform != stdenv.buildPlatform) "BUILD_CC=$(CC_FOR_BUILD)"; </ins> postInstall = '' moveToOutput bin/bind9-config $dev

Discussion:
outputs something like "187183230175148230" instead of Chinese when it should output Chinese. Steps to reproduce the behavior: of the terminal use a command similar to the following Can output Chinese normally <img width="803" alt="image" src=""The terminal is the one that comes with the gnome desktop. <img width="803" alt="image" src=""<!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<del> { stdenv, lib, fetchFromGitHub, cmake, copyDesktopItems, makeDesktopItem, pkg-config, wrapGAppsHook , boost, cereal, cgal_5, curl, dbus, eigen, expat, glew, glib, gmp, gtest, gtk3, hicolor-icon-theme , ilmbase, libpng, mpfr, nlopt, openvdb, pcre, qhull, systemd, tbb, wxGTK31-gtk3, xorg, fetchpatch }: stdenv.mkDerivation rec { </del> <ins> { stdenv, lib, fetchFromGitHub, cmake, copyDesktopItems, makeDesktopItem , pkg-config, wrapGAppsHook, boost, cereal, cgal_5, curl, dbus, eigen, expat , glew, glib, gmp, gtest, gtk3, hicolor-icon-theme, ilmbase, libpng, mpfr, nlopt , openvdb, pcre, qhull, systemd, tbb, wxGTK31-gtk3, xorg, fetchpatch , wxGTK31-gtk3-override ? null }: let wxGTK31-gtk3-prusa = wxGTK31-gtk3.overrideAttrs (old: rec { pname = "wxwidgets-prusa3d-patched"; version = "3.1.4"; src = fetchFromGitHub { owner = "prusa3d"; repo = "wxWidgets"; rev = "489f6118256853cf5b299d595868641938566cdb"; hash = "sha256-xGL5I2+bPjmZGSTYe1L7VAmvLHbwd934o/cxg9baEvQ="; fetchSubmodules = true; }; }); wxGTK31-gtk3-override' = if wxGTK31-gtk3-override == null then wxGTK31-gtk3-prusa else wxGTK31-gtk3-override; in stdenv.mkDerivation rec { </ins> pname = "prusa-slicer"; version = "2.4.2";

Discussion:
prusa-slicer crashes, maybe related to our wxWidgets version. See for now. cc
Maybe caused by Maybe backport that change, or use the prusa-slicer wxWidget fork.
I can reproduce it with nixpkgs rev Using the wxWidgets fork from prusa3d fixes the issue. Will try to write a PR soon.
Change:
stdenv.mkDerivation (finalAttrs: { pname = "gnome-control-center"; <del> version = "46.1"; </del> <ins> version = "46.2"; </ins> src = fetchurl { url = "mirror://gnome/sources/gnome-control-center/${lib.versions.major finalAttrs.version}/gnome-control-center-${finalAttrs.version}.tar.xz"; <del> hash = "sha256-gXkkIwGd7aHSoHTB7Pan5u8xcsCcvm9NeZWktd6igxI="; </del> <ins> hash = "sha256-YzXGy4Fk5XTbUh//Yc+j36pV8dtmrjvKAnUKGT4cTz0="; </ins> }; patches = [

Discussion:
Package name: Latest released version: 46.0 <!-- Search your package here: --- Current version on the unstable channel: 46.0 Current version on the stable/release channel: 46.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- 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]: Fixes very annoying bug for users with nvidia dGPU notebooks on gnome using external displays. Reports of the Bug:
Change:
<ins> { lib , buildGoModule , fetchFromSourcehut , libxkbcommon , pkg-config }: buildGoModule rec { pname = "dotool"; version = "1.3"; src = fetchFromSourcehut { owner = "~geb"; repo = "dotool"; rev = version; hash = "sha256-z0fQ+qenHjtoriYSD2sOjEvfLVtZcMJbvnjKZFRSsMA="; }; vendorHash = "sha256-v0uoG9mNaemzhQAiG85RequGjkSllPd4UK2SrLjfm7A="; # uses nix store path for the dotool binary # also replaces /bin/echo with echo patches = [ ./fix-paths.patch ]; postPatch = '' substituteInPlace ./dotoold --replace "@dotool@" "$out/bin/dotool" ''; buildInputs = [ libxkbcommon ]; nativeBuildInputs = [ pkg-config ]; ldflags = [ "-s" "-w" "-X main.Version=${version}" ]; postInstall = '' mkdir -p $out/bin cp ./dotoold ./dotoolc $out/bin ''; meta = with lib; { description = "Command to simulate input anywhere"; homepage = "https://git.sr.ht/~geb/dotool"; changelog = "https://git.sr.ht/~geb/dotool/tree/${version}/item/CHANGELOG.md"; license = licenses.gpl3Only; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Discussion:
Project description Perhaps it would also require a module to set the correct permission for /dev/uinput? dotool reads commands from stdin and simulates keyboard and pointer events. It works everywhere on Linux, including in X11, Wayland and TTYs. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: GPLv3 platforms: unix, linux dotool requires permission to to create the virtual input devices, and a udev rule grants this to users in group input. You could try: echo type hello | dotool and if need be, you can run: sudo groupadd -f input sudo usermod -a -G input $USER and re-login and trigger the udev rule or just reboot. See , but this greets the world: echo 'type Sup, Lads!' | dotool and this screams for three seconds: { echo keydown A; sleep 3; echo key H shift+1; } | dotool There is an initial delay registering the virtual devices, but you can keep writing commands to the same instance or use the daemon and client, and . dotoold & echo type super | dotoolc echo type speedy | dotoolc dotool will produce gobbledygook if your environment has assigned it a different keyboard layout than it's simulating keycodes for. You can match them up with the environment variables and . echo type azerty | DOTOOLXKBLAYOUT=fr dotool dotool was written for , which has a you're welcome to join. You can also send questions, thoughts or patches by composing an email to .
Change:
assertion = !(nvidiaEnabled && cfg.datacenter.enable); message = "You cannot configure both X11 and Data Center drivers at the same time."; } <ins> { assertion = cfg.open != null; message = '' You must configure `hardware.nvidia.open` on NVIDIA driver versions >= 560. It is suggested to use the open source kernel modules on Turing or later GPUs (RTX series, GTX 16xx), and the closed source modules otherwise. ''; } </ins> ]; boot = { blacklistedKernelModules = [

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:
rustPlatform.buildRustPackage rec { pname = "rust-analyzer-unwrapped"; <del> version = "2022-10-31"; cargoSha256 = "sha256-yehukhYwNhFqHUYmIe0P/LPgRHvyj1/DFCl2yzBkB8Q="; </del> <ins> version = "2022-12-05"; cargoSha256 = "sha256-lD52qI6LX5ORBWknCC4gAWQG8FPlNhOj6xQo1eXpO30="; </ins> src = fetchFromGitHub { owner = "rust-lang"; repo = "rust-analyzer"; rev = version; <del> sha256 = "sha256-D0YwkSqwtD08twtCtN5q0a8S0Y26kgDWg1ruRNEQEOw="; </del> <ins> sha256 = "sha256-2Syd2jVpY0UIfsYlmzvWICZTDVRG4UchcbRlNhuJSpM="; </ins> }; cargoBuildFlags = [ "--bin" "rust-analyzer" "--bin" "rust-analyzer-proc-macro-srv" ];

Discussion:
<!-- 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: rust-analyzer-unwrapped <!-- 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: 2022-10-31 desired version: 2022-11-14 <!-- 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.
rust-analyzer requires rust 1.65, so we need to update it in staging-next or wait until it gets into master:
Change:
<ins> { stdenv, buildPythonPackage, fetchFromGitHub , pytest, pytestcov, mock }: buildPythonPackage rec { pname = "vdf"; version = "3.1"; src = fetchFromGitHub { owner = "ValvePython"; repo = pname; rev = "v${version}"; sha256 = "19xqjq2159w2l9vaxlkickvy3zksp9ssdkvbfcfggxz31miwp1zr"; }; checkInputs = [ pytest pytestcov mock ]; checkPhase = "make test"; meta = with stdenv.lib; { description = "Library for working with Valve's VDF text format"; homepage = https://github.com/ValvePython/vdf; license = licenses.mit; maintainers = with maintainers; [ metadark ]; }; } </ins>

Discussion:
A simple wrapper that does winetricks things for Proton enabled games, requires Winetricks.
Change:
<ins> From acab088fd6af0b2ef2df1396aeb93bfc2e020fa5 Mon Sep 17 00:00:00 2001 From: "Yukihiro "Matz" Matsumoto" <matz@ruby.or.jp> Date: Mon, 27 Apr 2020 18:52:43 +0900 Subject: [PATCH 1/2] Updating `parse.y for recent `bison` (retry). --- mrbgems/mruby-compiler/core/parse.y | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mrbgems/mruby-compiler/core/parse.y b/mrbgems/mruby-compiler/core/parse.y index 6a1faf4e..2a4f740e 100644 --- a/mrbgems/mruby-compiler/core/parse.y +++ b/mrbgems/mruby-compiler/core/parse.y @@ -1323,7 +1323,7 @@ heredoc_end(parser_state *p) %} -%pure-parser +%define api.pure %parse-param {parser_state *p} %lex-param {parser_state *p} -- 2.27.0 From 3cc682d943b29e84928a847a23f411ddbace74b7 Mon Sep 17 00:00:00 2001 From: "Yukihiro "Matz" Matsumoto" <matz@ruby.or.jp> Date: Fri, 15 May 2020 12:30:13 +0900 Subject: [PATCH 2/2] Remove `YYERROR_VERBOSE` which no longer supported since `bison 3.6`. Instead we added `%define parse.error verbose`. --- mrbgems/mruby-compiler/core/parse.y | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mrbgems/mruby-compiler/core/parse.y b/mrbgems/mruby-compiler/core/parse.y index 2a4f740e..eee6a5e5 100644 --- a/mrbgems/mruby-compiler/core/parse.y +++ b/mrbgems/mruby-compiler/core/parse.y @@ -9,7 +9,6 @@ #ifdef PARSER_DEBUG # define YYDEBUG 1 #endif -#define YYERROR_VERBOSE 1 #define YYSTACK_USE_ALLOCA 1 #include <ctype.h> @@ -1323,6 +1322,7 @@ heredoc_end(parser_state *p) %} +%define parse.error verbose %define api.pure %parse-param {parser_state *p} %lex-param {parser_state *p} -- 2.27.0 </ins>

Discussion:
Describe the bug cannot be built from current master due to failing tests. To Reproduce Additional context Relevant logs: Notify maintainers Metadata Please run and paste the result. Maintainer information:
Change:
contents = crossPkgs.hello; }; <ins> # layered image where a store path is itself a symlink layeredStoreSymlink = let target = pkgs.writeTextDir "dir/target" "Content doesn't matter."; symlink = pkgs.runCommandNoCC "symlink" {} "ln -s ${target} $out"; in pkgs.dockerTools.buildLayeredImage { name = "layeredstoresymlink"; tag = "latest"; contents = [ pkgs.bash symlink ]; } // { passthru = { inherit symlink; }; }; </ins> }

Discussion:
Describe the bug Please see for a more thorough investigation than this. ~I'm not sure I'd really classify this as a bug, but it is a least surprising behaviour on some docker storage backends, so I'd like to document this. I'm not sure whether docker really has any formal semantics with respect to the loading process.~ The TL;DR: Some s may be usable on some storage backends but not on others when symlinked paths are involved. To Reproduce Consider: This image fails to load on an ext4/overlayfs setup: But succeeds on a zfs-backed docker setup: I imagine this is because of the storage backend's behaviour wrt. earlier layers' files. Expected behavior Image loads the same on all backends. Additional context This was discovered because our docker images became unpullable on some hosts (overlay) but not others (zfs) after crate2nix started using symlinks for tested builds: might find this interesting. :smile_cat:
docker.. sounds like an upstream issue, no? What happens if you do the equivalent in a Dockerfile?
Yes, I tend to agree, both backends should behave the same, but I'm afraid "overlay" is the de facto standard, so the functioning version is probably the buggy one. I may report this upstream, but it's at least surprising that can produce unpullable images (never happened to me before!) :grinning: Uh, that would require a working memory on how to make Dockerfiles... Stand by. :stuckouttongue:
I can't seem to reproduce this with Dockerfiles. I suspect it does some logic to avoid having symlink breakage across layers, but I haven't checked the source. Maybe we should do the same.
Scratch the above, my assumptions were wrong. Here's what I now think is going on, seen only from the perspective of an overlayfs setup (forget about zfs, I've no idea what process the clone/snapshot mechanism uses to make this magically "work" and to what extent it actually "works") Given the snippet: We get an image which has a layer containing: This, I think, is the main culprit.

If we go to the prior commit (the commented nixpkgs revision) the problem does not exist, and the corresponding layer looks like this: Which looks much more correct and doesn't have more than one entry for with one being a symlink (correct) and the other (implicitly) a directory. In other words, I believe this is a bug and was introduced in specifically in and relates to how disparate entries are somehow created because of some wonky symlink traversal. :smile_cat: cc