jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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: haruna <!-- 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: 0.7.3 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: I tried to update it myself, but when trying to open the result I get either: or: Some dependencies could be moved to , since they are build time only. The project supports other than . Since uses the former, maybe switching could be considered. The homepage is outdated. It's now "". Please tag this issue in your PR.
Can you (re)produce after this update?
This is an issue requesting an update, not a pull request (edited the title to be more clear). Still, with the update I tried to do by myself I couldn't open Haruna in the first place.

Related discussion:
text: , cmake , extra-cmake-modules , ffmpeg-full <del> , kcodecs </del> , kconfig , kcoreaddons , kfilemetadata , ki18n , kiconthemes , kio <del> , kio-extras </del> , kirigami2 , kxmlgui <ins> , kdoctools </ins> , mpv , pkg-config <ins> , wrapQtAppsHook </ins> , qqc2-desktop-style , qtbase , qtquickcontrols2 <del> , qtwayland , youtube-dl </del> <ins> , yt-dlp </ins> }: mkDerivation rec { pname = "haruna"; <del> version = "0.7.3"; </del> <ins> version = "0.8.0"; </ins> src = fetchFromGitLab { owner = "multimedia"; repo = "haruna"; rev = "v${version}"; <del> sha256 = "sha256-pFrmTaRvsqxJw34VULzfjx2k56kJgkB96nJtai2D1wY="; </del> <ins> sha256 = "sha256-Lom9iQUKH3lQHrVK4dJzo+FG79xSCg0b4gY/KAevL6I="; </ins> domain = "invent.kde.org"; }; buildInputs = [ breeze-icons breeze-qt5 <ins> qqc2-desktop-style yt-dlp </ins> ffmpeg-full <del> kcodecs </del> kconfig kcoreaddons kfilemetadata ki18n kiconthemes kio <del> kio-extras </del> kirigami2 kxmlgui <ins> kdoctools </ins> mpv <del> qqc2-desktop-style </del> qtbase qtquickcontrols2 <del> qtwayland youtube-dl </del> ]; nativeBuildInputs = [ cmake extra-cmake-modules pkg-config <ins> wrapQtAppsHook </ins> ]; meta = with lib; { <del> homepage = "https://github.com/g-fb/haruna"; </del> <ins> homepage = "https://invent.kde.org/multimedia/haruna"; </ins> description = "Open source video player built with Qt/QML and libmpv"; <del> license = with licenses; [ bsd3 cc-by-40 gpl3Plus wtfpl ]; </del> <ins> license = with licenses; [ bsd3 cc-by-40 cc-by-sa-40 cc0 gpl2Plus gpl3Plus wtfpl ]; </ins> maintainers = with maintainers; [ jojosch ]; }; }
Code change:
Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.

Related discussion:
text: stdenv.mkDerivation rec { pname = "xow"; <del> version = "0.5"; </del> <ins> version = "unstable-2022-04-24"; </ins> src = fetchFromGitHub { owner = "medusalix"; repo = "xow"; <del> rev = "v${version}"; sha256 = "071r2kx44k1sc49cad3i607xg618mf34ki1ykr5lnfx9y6qyz075"; </del> <ins> rev = "d335d6024f8380f52767a7de67727d9b2f867871"; sha256 = "0q5nr21p4dlx2a99hiivwz6qj9anrqqsdhiz6xi375yqkxis4251"; </ins> }; firmware = fetchurl {
Code change:
Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.

Related discussion:
text: makeFlags = [ "BUILD=RELEASE" <del> "VERSION=${version}" </del> <ins> "VERSION=${version}-${src.rev}" </ins> "BINDIR=${placeholder "out"}/bin" "UDEVDIR=${placeholder "out"}/lib/udev/rules.d" "MODLDIR=${placeholder "out"}/lib/modules-load.d"
Code change:
<!-- 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: rtl-sdr <!-- 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: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.

Related discussion:
text: { lib , stdenv <del> , fetchgit </del> <ins> , fetchFromGitHub </ins> , cmake , pkg-config , libusb1
Code change:
<!-- 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: rtl-sdr <!-- 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: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.

Related discussion:
text: stdenv.mkDerivation rec { pname = "rtl-sdr"; <del> version = "0.6.0"; </del> <ins> version = "0.8.0"; </ins> <del> src = fetchgit { url = "git://git.osmocom.org/rtl-sdr.git"; rev = "refs/tags/${version}"; sha256 = "0lmvsnb4xw4hmz6zs0z5ilsah5hjz29g1s0050n59fllskqr3b8k"; </del> <ins> src = fetchFromGitHub { owner = "librtlsdr"; repo = "librtlsdr"; rev = "v${version}"; sha256 = "1fgxlkgmdchbrf0nn98ivjr6css5hak3608nr4xrf2qzf7xy2kdk"; </ins> }; postPatch = ''
Code change:
<!-- 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: rtl-sdr <!-- 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: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.

Related discussion:
text: buildInputs = [ libusb1 ]; <del> cmakeFlags = lib.optional stdenv.isLinux "-DINSTALL_UDEV_RULES=ON"; </del> <ins> cmakeFlags = lib.optional stdenv.isLinux [ "-DINSTALL_UDEV_RULES=ON" "-DWITH_RPC=ON" ]; </ins> meta = with lib; { description = "Turns your Realtek RTL2832 based DVB dongle into a SDR receiver";
Code change:
For example This test has always been failing: From the logs: /cc
Whoopsie! Maybe instead of keeping hard-coded URL to x86-64's Alpine we could build something dynamically? (this way the test would automatically work on all architectures) I'll try to take a look over the weekend, but feel free to take a shot at it, if you want
Hmm that is a cool idea. Though OTOH it is currently nice that when this test fails it is clear it is a problem with running the image, and not with creating it. Did you get that from somewhere or did you create it? Is it the 'mini root fs' from ?
Yeah, that's the one;

Related discussion:
text: # # I've chosen to import Alpine Linux, because its image is turbo-tiny and, # generally, sufficient for our tests. <del> alpine-meta = pkgs.fetchurl { </del> <ins> alpine-meta-x86 = pkgs.fetchurl { </ins> url = "https://tarballs.nixos.org/alpine/3.12/lxd.tar.xz"; hash = "sha256-1tcKaO9lOkvqfmG/7FMbfAEToAuFy2YMewS8ysBKuLA="; }; <ins> alpine-meta-for = arch: pkgs.stdenv.mkDerivation { name = "alpine-meta-${arch}"; version = "3.12"; unpackPhase = "true"; buildPhase = '' runHook preBuild </ins> <del> alpine-rootfs = pkgs.fetchurl { url = "https://tarballs.nixos.org/alpine/3.12/rootfs.tar.xz"; hash = "sha256-Tba9sSoaiMtQLY45u7p5DMqXTSDgs/763L/SQp0bkCA="; </del> <ins> tar xvf ${alpine-meta-x86} sed -i 's/architecture: .*/architecture: ${arch}/' metadata.yaml runHook postBuild ''; installPhase = '' runHook preInstall tar czRf $out * runHook postInstall ''; </ins> }; <ins> alpine-meta = { x86_64-linux = alpine-meta-x86; aarch64-linux = alpine-meta-for "aarch64"; }.${pkgs.system} or (throw "Unsupported system: ${pkgs.system}"); alpine-rootfs = { x86_64-linux = pkgs.fetchurl { url = "https://tarballs.nixos.org/alpine/3.12/rootfs.tar.xz"; hash = "sha256-Tba9sSoaiMtQLY45u7p5DMqXTSDgs/763L/SQp0bkCA="; }; aarch64-linux = pkgs.fetchurl { url = "https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/aarch64/alpine-minirootfs-3.15.4-aarch64.tar.gz"; hash = "sha256-9kBz8Jwmo8XepJhTMt5zilCaHHpflnUH7y9+0To39Us="; }; }.${pkgs.system} or (throw "Unsupported system: ${pkgs.system}"); </ins> lxd-config = pkgs.writeText "config.yaml" '' storage_pools: - name: default
Code change:
fails to build. Looking at hydra when it started to fail () it could be due to GCC 11 update. Just adding to the only leads to the next error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

Related discussion:
text: ]; configureFlags = [ <ins> "--disable-werror" </ins> "--enable-jtag_vpi" "--enable-usb_blaster_libftdi" (lib.enableFeature (! stdenv.isDarwin) "amtjtagaccel")
Code change:
On nixos-unstable it appears that was renamed to . However the config line for applying the option still references the obsolete option name: This means that enabling produces a warning like Relatedly, using this without defining also throws an error ' is used but not defined.confignullOr submodule` with no default value). Steps to reproduce the behavior: should not produce any warnings or errors. Uncommenting the line removes the error but leaves the warning. (though the flake output in question is for )
You used the wrong GitHub handles for some of the maintainers. cc
Oops. I copied the names out of the file as there's no GitHub team for it, but I forgot to indirect through . Is there any simple way to look up the github handles for a given module? I'm not even sure how to get at the module programmatically.
It works, but it isn't pretty.

Related discussion:
text: }; config = mkIf cfg.enable { <del> networking.firewall.allowedTCPPorts = mkIf cfg.openFirewall [ cfg.port ]; </del> <ins> assertions = [ { assertion = cfg.openFirewall -> !isNull cfg.config; message = "openFirewall can only be used with a declarative config"; } ]; networking.firewall.allowedTCPPorts = mkIf cfg.openFirewall [ cfg.config.http.server_port ]; </ins> systemd.services.home-assistant = { description = "Home Assistant";
Code change:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

Related discussion:
text: <del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchFromGitHub , cmake , qttools
Code change:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

Related discussion:
text: export LC_ALL="en_US.UTF-8" export QT_QPA_PLATFORM=offscreen export QT_PLUGIN_PATH="${qtbase.bin}/${qtbase.qtPluginPrefix}" <del> # testcli and testgui are flaky - skip them both make test ARGS+="-E 'testcli|testgui' --output-on-failure" </del> <ins> # testcli, testgui and testkdbx4 are flaky - skip them all # testautotype on darwin throws "QWidget: Cannot create a QWidget without QApplication" make test ARGS+="-E 'testcli|testgui${lib.optionalString stdenv.isDarwin "|testautotype|testkdbx4"}' --output-on-failure" </ins> runHook postCheck '';
Code change:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

Related discussion:
text: dontWrapGApps = true; preFixup = '' qtWrapperArgs+=("''${gappsWrapperArgs[@]}") <ins> '' + lib.optionalString stdenv.isDarwin '' wrapQtApp "$out/Applications/KeePassXC.app/Contents/MacOS/KeePassXC" </ins> ''; buildInputs = [
Code change:
See Hydra failure: I could not find anything directly keepassxc-related in the changes on hydra from last successful to first failing build. CC Also relevant: Version bump to 2.7: A fix for this issue might give a merge conflict there in the worst case, or alleviate the build problems there in the best case.
Does keepassxc depend on Qt? We're stuck on an older Qt because of the SDK version for x86_64-darwin. I think keepassxc may require a newer SDK.
mentions QT = 5.9.5.
Current version builds just fine. There's one test failure instead: I'll see if that's fixable...
Another issue though is that somehow became wrapped so can't be loaded anymore. Which may be related to the test failure... Either way, after trying to run the app, the gui just spins with 100% CPU. The cli part works just fine though.
I came across this issue because I was investigating something else, this is because of the wrap qt apps hook which wraps all the executable files, even if it's a dynamic library. This can be fixed by removing the executable flag from the library. You might be able to resolve it with something like: In the derivation. This should be fixed in the fixup script however

Related discussion:
text: license = licenses.gpl2Plus; maintainers = with maintainers; [ jonafato turion srapenne ]; platforms = platforms.linux ++ platforms.darwin; <del> broken = stdenv.isDarwin;  # see to https://github.com/NixOS/nixpkgs/issues/172165 </del> }; }
Code change:
nixpkgs-review stopped working on recent branches, I didn't update nixpkgs-review before it break so I assume something internal in nixpkgs has been broken. Steps to reproduce the behavior: or there is a build failure related to hydra <details<summaryLong output of the failure</summary</detailsit shouldn't fail
This is certainly related to , ping :)
Sorry about that, it's a bit annoying that aliases are allowed locally and not in nixpkgs-review :/.

Related discussion:
text: TermSizeAny TermReadKey Test2Harness <del> TestMore </del> TestPostgreSQL TextDiff TextTable
Code change:
, CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. Versions of vyper prior to 0.3.2 suffer from a potential buffer overrun. Importing a function from a JSON interface which returns generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Users are advised to upgrade. There are no known workarounds for this issue. Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In affected versions, the return of is not validated to fall within the bounds of . This issue can result in a misinterpretation of the integer value and lead to incorrect behavior. As of v0.3.0, is validated in simple expressions, but not complex expressions. Users are advised to upgrade. There is no known workaround for this issue. Scanned versions: nixos-unstable: . Cc
See also:

Related discussion:
text: , buildPythonPackage , fetchPypi , pythonOlder <del> , pythonAtLeast </del> , pythonRelaxDepsHook , writeText , asttokens
Code change:
, CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. Versions of vyper prior to 0.3.2 suffer from a potential buffer overrun. Importing a function from a JSON interface which returns generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Users are advised to upgrade. There are no known workarounds for this issue. Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In affected versions, the return of is not validated to fall within the bounds of . This issue can result in a misinterpretation of the integer value and lead to incorrect behavior. As of v0.3.0, is validated in simple expressions, but not complex expressions. Users are advised to upgrade. There is no known workaround for this issue. Scanned versions: nixos-unstable: . Cc
See also:

Related discussion:
text: , sphinx_rtd_theme , pytest-runner , setuptools-scm <ins> , git </ins> }: let
Code change:
, CVSSv3=9.8 (nixos-unstable) CVSSv3=9.8 (nixos-unstable) Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. Versions of vyper prior to 0.3.2 suffer from a potential buffer overrun. Importing a function from a JSON interface which returns generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Users are advised to upgrade. There are no known workarounds for this issue. Vyper is a pythonic Smart Contract Language for the ethereum virtual machine. In affected versions, the return of is not validated to fall within the bounds of . This issue can result in a misinterpretation of the integer value and lead to incorrect behavior. As of v0.3.0, is validated in simple expressions, but not complex expressions. Users are advised to upgrade. There is no known workaround for this issue. Scanned versions: nixos-unstable: . Cc
See also:

Related discussion:
text: in buildPythonPackage rec { pname = "vyper"; <del> version = "0.3.1"; </del> <ins> version = "0.3.3"; </ins> format = "setuptools"; <del> disabled = pythonOlder "3.7" || pythonAtLeast "3.10"; </del> <ins> disabled = pythonOlder "3.7"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "sha256-fXug5v3zstz19uexMWokHBVsfcl2ZCdIOIXKeLVyh/Q="; </del> <ins> sha256 = "sha256-BAnNj27B1HAb9VVDA69bFGbQjeOpl0g5EB2juajqBAw="; </ins> }; nativeBuildInputs = [ <ins> # Git is used in setup.py to compute version information during building # ever since https://github.com/vyperlang/vyper/pull/2816 git </ins> pythonRelaxDepsHook pytest-runner setuptools-scm