jiebi/CodeConvo huggingface dataset:
Change:
fplll_20160331 = callPackage ../development/libraries/fplll/20160331.nix {}; freeimage = callPackage ../development/libraries/freeimage { <ins> inherit (darwin) autoSignDarwinBinariesHook; </ins> libraw = libraw_unstable; };

Discussion:
The package is not supported on Apple M1. It gives the following error message Steps to reproduce the behavior: on an Apple M1 Macbook. We should be able to build the package successfully. Add any other context about the problem here. Maintainer information:
Please run and report whether [ ] it builds without error [ ] produces a working binary Then we can simply add M1 to the list of supported platforms.
No. It does not build. It hits error when building . The outputs are
Change:
EOF ''; <del> buildPhase = with python3.pkgs; '' </del> <ins> buildPhase = with python311.pkgs; '' </ins> runHook preBuild ${python.pythonOnBuildForHost.interpreter} module/setup.py build --parallel=$NIX_BUILD_CORES runHook postBuild ''; <del> installPhase = with python3.pkgs; '' </del> <ins> installPhase = with python311.pkgs; '' </ins> runHook preInstall ${python.pythonOnBuildForHost.interpreter} module/setup.py install_lib -d $out/${python.sitePackages}

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]:
Change:
<ins> diff -ur compiler-rt-6.0.1.src/cmake/builtin-config-ix.cmake compiler-rt-6.0.1.src-patched/cmake/builtin-config-ix.cmake --- compiler-rt-6.0.1.src/cmake/builtin-config-ix.cmake	2017-12-01 06:04:11.000000000 +0900 +++ compiler-rt-6.0.1.src-patched/cmake/builtin-config-ix.cmake	2020-05-10 03:30:01.939694303 +0900 @@ -24,7 +24,7 @@ set(ARM64 aarch64) -set(ARM32 arm armhf armv6m armv7m armv7em armv7 armv7s armv7k) +set(ARM32 arm armhf armv6m armv7m armv7em armv7 armv7s armv7k armv7l) set(X86 i386) set(X86_64 x86_64) set(MIPS32 mips mipsel) diff -ur compiler-rt-6.0.1.src/lib/builtins/CMakeLists.txt compiler-rt-6.0.1.src-patched/lib/builtins/CMakeLists.txt --- compiler-rt-6.0.1.src/lib/builtins/CMakeLists.txt	2017-12-25 06:11:32.000000000 +0900 +++ compiler-rt-6.0.1.src-patched/lib/builtins/CMakeLists.txt	2020-05-10 03:30:44.814964156 +0900 @@ -452,6 +452,7 @@ set(armv7_SOURCES ${arm_SOURCES}) set(armv7s_SOURCES ${arm_SOURCES}) set(armv7k_SOURCES ${arm_SOURCES}) +set(armv7l_SOURCES ${arm_SOURCES}) set(arm64_SOURCES ${aarch64_SOURCES}) # macho_embedded archs @@ -521,7 +522,7 @@ set(_arch ${arch}) if("${arch}" STREQUAL "armv6m") set(_arch "arm|armv6m") -      elseif("${arch}" MATCHES "^(armhf|armv7|armv7s|armv7k|armv7m|armv7em)$") +      elseif("${arch}" MATCHES "^(armhf|armv7|armv7s|armv7k|armv7l|armv7m|armv7em)$") set(_arch "arm") endif() </ins>

Discussion:
Describe the bug A clear and concise description of what the bug is. Same issue as or , but on armv7l Additional context Add any other context about the problem here. On hydra, the clang build first started failing with this error after going from to . I diffed the range and found to be the most likely culprit. It enabled some cmakeFlags globally which used to only be enabled on darwin and useLLVM systems. I don't know what exactly these do but, I was able to build on my rpi2 by disabling them on aarch32: Since I have no idea why this works and what would be affected, I'd rather have someone look over this. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
we probably need to add armv7l here:
I tried but it fails with this error now: I guess it can't find a default target for armv7l somehow? Not really familiar with cmake unfortunately
I made some progress, it seems to be taking the target arch from the triplet given to , even if you override the target arch with a flag. Printf debugging showed me that it does this halfway through the configure phase, it's armhf in the beginning if I set the flag. Setting the compiler target to instead of makes it find its target and compile successfully. Does have any importance outside the build process?
I don't think it does. It's possible it sets in compiler calls, but that is considered equivalent to .
Change:
<del> { lib, stdenv, fetchFromGitHub, cmake, pkg-config , libpng, libtiff, lcms2, jpylyzer , mj2Support ? true # MJ2 executables , jpwlLibSupport ? true # JPWL library & executables , jpipLibSupport ? false # JPIP library & executables , jpipServerSupport ? false, curl ? null, fcgi ? null # JPIP Server #, opjViewerSupport ? false, wxGTK ? null # OPJViewer executable , openjpegJarSupport ? false # Openjpeg jar (Java) , jp3dSupport ? true # # JP3D comp , thirdPartySupport ? false # Third party libraries - OFF: only build when found, ON: always build , testsSupport ? true , jdk ? null # Inherit generics , branch, version, revision, sha256, patches ? [], extraFlags ? [], ... }: assert jpipServerSupport -> jpipLibSupport && curl != null && fcgi != null; #assert opjViewerSupport -> (wxGTK != null); assert (openjpegJarSupport || jpipLibSupport) -> jdk != null; let inherit (lib) optional optionals; mkFlag = optSet: flag: "-D${flag}=${if optSet then "ON" else "OFF"}"; in stdenv.mkDerivation { pname = "openjpeg"; inherit version; src = fetchFromGitHub { owner = "uclouvain"; repo = "openjpeg"; rev = revision; inherit sha256; }; inherit patches; outputs = [ "out" "dev" ]; cmakeFlags = [ "-DCMAKE_INSTALL_NAME_DIR=${CMAKE_INSTALL_PREFIX}/lib" "-DBUILD_SHARED_LIBS=ON" "-DBUILD_CODEC=ON" (mkFlag mj2Support "BUILD_MJ2") (mkFlag jpwlLibSupport "BUILD_JPWL") (mkFlag jpipLibSupport "BUILD_JPIP") (mkFlag jpipServerSupport "BUILD_JPIP_SERVER") #(mkFlag opjViewerSupport "BUILD_VIEWER") "-DBUILD_VIEWER=OFF" (mkFlag openjpegJarSupport "BUILD_JAVA") (mkFlag jp3dSupport "BUILD_JP3D") (mkFlag thirdPartySupport "BUILD_THIRDPARTY") (mkFlag testsSupport "BUILD_TESTING") ] ++ extraFlags; nativeBuildInputs = [ cmake pkg-config ]; buildInputs = [ ] ++ optionals jpipServerSupport [ curl fcgi ] #++ optional opjViewerSupport wxGTK ++ optional (openjpegJarSupport || jpipLibSupport) jdk; propagatedBuildInputs = [ libpng libtiff lcms2 ]; doCheck = (testsSupport && !stdenv.isAarch64); # tests fail on aarch64-linux checkPhase = '' substituteInPlace ../tools/ctest_scripts/travis-ci.cmake  --replace "JPYLYZER_EXECUTABLE=" "JPYLYZER_EXECUTABLE="${jpylyzer}/bin/jpylyzer" # " OPJ_SOURCE_DIR=.. ctest -S ../tools/ctest_scripts/travis-ci.cmake ''; passthru = { incDir = "openjpeg-${branch}"; }; meta = with lib; { description = "Open-source JPEG 2000 codec written in C language"; homepage = "https://www.openjpeg.org/"; license = licenses.bsd2; maintainers = with maintainers; [ codyopel ]; platforms = platforms.all; }; } </del>

Discussion:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also: ,
Change:
# https://docs.gradle.org/current/userguide/compatibility.html gradle_7 = gen { <del> version = "7.3.3"; nativeVersion = "0.22-milestone-21"; sha256 = "00h3z0vxc4hv31sc71gb88r8yabyqgz304wpr0bxhbx2d14f11mm"; </del> <ins> version = "7.4"; nativeVersion = "0.22-milestone-23"; sha256 = "0d56bgd2m64pzmycjk29hwdlhbpn1kkm7fjik1sibn6vslw71hlc"; </ins> defaultJava = jdk17; };

Discussion:
Gradle 7.4 is out, see (I am one of the maintainers, this is a TODO.)
Change:
evalModules) and the less declarative the module set is. */ evalModules = { modules , prefix ? [] <ins> , # This should only be used for special arguments that need to be evaluated # when resolving module structure (like in imports). For everything else, # there's _module.args. specialArgs ? {} </ins> , # This would be remove in the future, Prefer _module.args option instead. args ? {} , # This would be remove in the future, Prefer _module.check option instead.

Discussion:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by
Change:
symlinkJoin rec { pname = "fira"; <del> inherit (fira-mono) version; </del> <ins> inherit (fira-sans) version; </ins> name = "${pname}-${version}"; paths = [

Discussion:
Currently the fira, fira-sans e fira-mono packages use the source available in the . According to , this repository is not up to date: The latest versions of the fonts are available at <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
license = stdenv.lib.licenses.bsd3; platforms = stdenv.lib.platforms.unix; maintainers = with stdenv.lib.maintainers; [ fuuzetsu ]; <ins> broken = true;  # largely replaced by HoTT-Agda </ins> }; })

Discussion:
As of Agda 2.5.1 (which comes on the latest nixos-unstable release), both nixpkgs' agda-stdlib (from git nominally at version 2.4.2.3) and an updated version (v0.12, the most recent release) fail to build. Some modules are checked successfully, but it gets stuck at (the first builtin module it finds). For this module only, it tries to write to . Output: System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
has the same issue, meaning that there has probably been some change in Agda. The problem seems to be that writes a file for each file it checks, and some files it's checking are in the Nix store (specifically, in ). I think it's to do with . Maybe it would work if these were checked when building .
Current status: .
Fixed by .
Let's keep this open until the fix lands in master.
Change:
weather-icons = callPackage ../data/fonts/weather-icons { }; <ins> whitesur-cursors = callPackage ../data/icons/whitesur-cursors { }; </ins> whitesur-gtk-theme = callPackage ../data/themes/whitesur { inherit (gnome) gnome-shell; };

Discussion:
Project description WhiteSur cursors theme for linux desktops, to go with . Metadata homepage URL: source URL: license: platforms: linux
Change:
sha256 = "0px0xdv6kyzkkpmvryrdfavv1qy2xrqdxkpmhvx1gj649xcabv32"; }; <ins> postPatch = '' substituteInPlace inkcut/device/transports/printer/plugin.py  --replace ", 'lpr', " ", '${cups}/bin/lpr', " ''; </ins> nativeBuildInputs = [ wrapQtAppsHook ]; propagatedBuildInputs = [

Discussion:
Describe the bug Inkcut is unable to print to a cups printer. To Reproduce Steps to reproduce the behavior: to your config to and add a printer that points to a local vinyl cutter or printer device via its USB device name, for example the printer driver for this device to Inkcut, go to and make a profile for your printer that points to this new printer to "Send to device" (Ctrl + P) in Inkcut that nothing happens, no new print job is started Expected behavior Inkcut would start a print job in cups Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(matthew): nixpkgs: Maintainer information:
Note that as a workaround you can likely use the USB-to-serial device directly as a serial interface without going through CUPS - I'm pretty sure that's the setup in / . We should still fix it so it also works via CUPS, of course :)
In my case, your workaround is not as nice as using cups, since Inkcut improperly handles the lp0 (parallel) and serial is not an option for my cutter. Cups handles the jobs properly, if the vinyl cutter is powered off half-way through a job it will not continue to send and buffer the job, it will halt the job and consider it done. So it's just a better method than to give Inkcut direct access to lp0.
I tried this, and under 'Setup' I do see my CUPS printers, so it looks like at least something works. However, indeed when I send the job to the device, indeed I see nothing show up in the print queue. Looking at the inkcut logs, however, all looks fine: Showing the 'completed jobs' in CUPS doesn't show this one, though - not as 'cancelled' either. Adding some more diagnostic logging () revealed that twisted is trying to run /usr/bin/lpr, which is of course not where that tool is located in NixOS. Making that an absolute path into the nix store seemed to help (at least things showed up in my CUPS queue, haven't tested with an actual plotter).
Well, that should be it.

I always assumed was ran automatically in most cases to fix the issue of hardcoded references, Is this not the case here?
That should indeed run automatically, but only covers the line of executable scripts. In this case was just passed as a parameter to somewhere inside the python plugin, so that's hard to detect automatically ;)
Change:
thc-hydra = callPackage ../tools/security/thc-hydra { }; <del> thefuck = callPackage ../tools/misc/thefuck { }; </del> <ins> thefuck = python3Packages.callPackage ../tools/misc/thefuck { }; </ins> thin-provisioning-tools = callPackage ../tools/misc/thin-provisioning-tools {  };

Discussion:
has failing tests. Specifically, the tests seem to be failing because is no longer available. I traced back the issue to an update of , using : output: system: host os: multi-user?: sandbox: version: channels(root): channels(synthetica): nixpkgs:
Change:
githubId = 24193; name = "Dan Callahan"; }; <ins> callumio = { email = "git@cleslie.uk"; github = "callumio"; githubId = 16057677; name = "Callum Leslie"; keys = [ { fingerprint = "BC82 4BB5 1656 D144 285E  A0EC D382 C4AF EECE AA90"; } ]; }; </ins> calvertvl = { email = "calvertvl@gmail.com"; github = "calvertvl";

Discussion:
Project description A virtual file system that behaves like . I use it to discard unwanted files writing to my SSDs, that do not need to be read, such as caches and temp files. You can also set a mount option to prevent a file being discarded which is placed in RAM. Refer to . <!-- Describe the project a little: --It can handle regular file operations like mkdir/rmdir/ln but writing to files does NOT store any data. The file size is however saved, reading from the files behaves like reading from . Writing and reading is basically an NOOP, so it can be used for performance testing with applications that require directory structures. Implemented as kernel module, instead of using FUSE, there is absolutely no overhead for copying application data from user to kernel space while performing write or read operations. Metadata homepage URL: source URL: license: GPL-3.0 platforms: unix, linux, darwin (not sure) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
buildGoModule rec { pname = "oh-my-posh"; <del> version = "14.22.0"; </del> <ins> version = "14.27.0"; </ins> src = fetchFromGitHub { owner = "jandedobbeleer"; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-kyASLWzjTFc10XWDLbc66+kaXjBaYmlgBc0Y8fF23Jk="; </del> <ins> hash = "sha256-aOUhKETwrPJWPvxkuLdpmSbD38RxMeQywmKq6j617Dk="; </ins> }; vendorHash = "sha256-MM6WwEs2BMkfpTsDFIqwpIROMs8zbbT5OsP6FXwRvy8=";

Discussion:
Package name: oh-my-posh Latest released version: 14.27.0 <!-- Search your package here: --- Current version on the unstable channel: 14.22.0 Current version on the stable/release channel: 12.16.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.
Change:
src = fetchFromGitHub { owner = "torproject"; repo = "stem"; <del> rev = "refs/tags/${version}"; hash = "sha256-9BXeE/sVa13jr8G060aWjc49zgDVBhjaR6nt4lSxc0g="; </del> <ins> rev = "9f1fa4ac53cf83a4cdd7155cc487212bf8bc08af"; hash = "sha256-AMyF4ir9Utb91dp1Swheyw1zQH6ZvgyW9kFp1g9JoQQ="; </ins> }; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: python3.11-stem While updating to current nixos-unstable, qutebrowser didn't build as this seems to be a dependency. <!-- 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]:
see
The patch has been merged upstream and we are waiting for a bugfix release. On the other hand, it seems to me that: stem is , and qutebrowser only depends on stem through a userscript: If stem breaks again we can simply remove it along with that userscript.
Change:
''; }); <ins> tesseract = old.tesseract.overrideAttrs (_: { preConfigure = '' substituteInPlace configure  --replace 'PKG_CONFIG_NAME="tesseract"' 'PKG_CONFIG_NAME="tesseract lept"' ''; }); </ins> ijtiff = old.ijtiff.overrideAttrs (_: { preConfigure = '' patchShebangs configure

Discussion:
Steps to reproduce the behavior: Looks like rPackages.tesseract is failing to build. Tested on x86_64-linux
This seems to be a bug with pkg-config not including leptonica's cflags. I initially thought it was a problem with tesseract, but it doesn't seem to be as contains
Thanks for taking a look at this one! works for me.
Change:
mkdir "$out/bin" cp build/vm/*.so* "$out/lib/" cp build/vm/pharo "$out/bin/pharo" <del> patchelf --allowed-rpath-prefixes /nix/store --shrink-rpath "$out/bin/pharo" </del> <ins> patchelf --allowed-rpath-prefixes "$NIX_STORE" --shrink-rpath "$out/bin/pharo" </ins> wrapProgram "$out/bin/pharo" --set LD_LIBRARY_PATH "${library_path}" runHook postInstall

Discussion:
Steps to reproduce the behavior: on nixos-unstable I believe this is related to <!-- 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.
It'll need a similar fix like the ones in Wasn't caught in staging because it's marked insecure
Change:
, fetchurl , cmake , dbus <ins> , fftwFloat </ins> , file , freetype , jansson

Discussion:
Package name: cardinal Latest released version: Current version on the unstable channel: v22.12 Current version on the stable/release channel: v22.10 <!-- 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.
Change:
<ins> { lib , python3 , fetchFromGitHub }: let python = python3.override { packageOverrides = self: super: { lark = super.lark.overridePythonAttrs (old: rec { # gdtoolkit needs exactly this lark version version = "1.1.9"; src = fetchFromGitHub { owner = "lark-parser"; repo = "lark"; rev = version; hash = "sha256-vDu+VPAXONY8J+A6oS7EiMeOMgzGms0nWpE+DKI1MVU="; fetchSubmodules = true; }; patches = [ ]; }); }; }; in python.pkgs.buildPythonApplication rec { pname = "gdtoolkit"; version = "4.2.2"; src = fetchFromGitHub { owner = "Scony"; repo = "godot-gdscript-toolkit"; rev = version; hash = "sha256-SvEKKuDnfxV+5AArg5ssrQzgIwRITdek4KYEs3d0n4Y="; }; disabled = python.pythonOlder "3.7"; propagatedBuildInputs = with python.pkgs; [ docopt lark pyyaml setuptools ]; doCheck = true; nativeCheckInputs = with python.pkgs; [ pytestCheckHook hypothesis ]; preCheck = '' # The tests want to run the installed executables export PATH=$out/bin:$PATH # gdtoolkit tries to write cache variables to $HOME/.cache export HOME=$TMP ''; # The tests are not working on NixOS disabledTestPaths = [ "tests/generated/test_expression_parsing.py" "tests/gdradon/test_executable.py" ]; pythonImportsCheck = [ "gdtoolkit" "gdtoolkit.formatter" "gdtoolkit.linter" "gdtoolkit.parser" ]; meta = with lib; { description = "Independent set of tools for working with Godot's GDScript - parser, linter and formatter"; homepage = "https://github.com/Scony/godot-gdscript-toolkit"; license = licenses.mit; maintainers = with maintainers; [ squarepear ]; }; } </ins>

Discussion:
Package name: gdtoolkit Latest released version: 4.1.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.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 It's a bit of an odd situation because both Godot 3 and 4 are in use, so maybe this one should be renamed to gdtoolkit3 or the opposite for the time being. Haven't had any success yet trying to override the package on my own. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.