jiebi/CodeConvo huggingface dataset:
Change:
buildPythonPackage rec { pname = "pyqt5"; <del> version = "5.15.9"; </del> <ins> version = "5.15.10"; </ins> format = "pyproject"; disabled = isPy27;

Discussion:
Steps to reproduce the behavior: picard <!-- 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]:
Also happens for . Probably related:
Hey, was "fixed" by switching to Python 3.11 at . Hopefully I'll remember to switch back to Python 3.12 when the picard's maintainers will publish a new release and will be merged to by then.

Steps to reproduce the behavior: git-cola <!-- 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]:
I'm not at a laptop for the coming weeks, so I'm not able to look into it. A segfault inside pytest doesn't sound like something git-cola specific, but not sure. If someone else wants to take a look in the meantime, that would be much appreciated
I've also run into this and have opened builds and runs with the updated PyQt5 version.
I link a few related issues:
I was able to workaround this problem by overriding the python version to be 3.11 instead of 3.12: The proper patch () is already in staging-next (), so it shouldn't be too long before it lands on master and nixpkgs-unstable.
In about a week, probably.
Change:
rev = "v${version}"; sha256 = "sha256-wyzpx0WjQLA8UKx4S6QOETMehf51Af5napZsxMXttmM="; }; <ins> nativeBuildInputs = [ cmake ]; </ins> buildInputs = [ zlib openssl libre ]; <ins> cmakeFlags = [ "-DRE_INCLUDE_DIR=${libre}/include/re" ]; </ins> makeFlags = [ "LIBRE_MK=${libre}/share/re/re.mk" <del> "LIBRE_INC=${libre}/include/re" </del> "PREFIX=$(out)" ] ++ lib.optional (stdenv.cc.cc != null) "SYSROOT_ALT=${lib.getDev stdenv.cc.cc}" ++ lib.optional (stdenv.cc.libc != null) "SYSROOT=${lib.getDev stdenv.cc.libc}" ; <ins> enableParallelBuilding = true; </ins> meta = { description = "A library for real-time audio and video processing"; homepage = "https://github.com/baresip/rem";

Discussion:
Baresip fails to build after because the baresip no longer finds librem through pkg-config. Building baresip with Cmake resolves this, but then there is a new build failure: Steps to reproduce the behavior: baresip
Sorry! I think fixes this. I developed and tested them together but wanted to take more time to be sure baresip was finding all of its dependencies. I didn't realize that merging one without the other would break things. We can either merge or else revert and
Waiting for is fine by me.
Change:
# Desktop file mkdir -p "$out/share/applications" cp "${desktopItem}/share/applications/"* "$out/share/applications" <ins> runHook postInstall </ins> ''; runtimeDependencies = [ (lib.getLib udev) ];

Discussion:
Describe the bug cannot be installed because the requested URL returned error 403. To Reproduce Steps to reproduce the behavior: Expected behavior should be installed. Screenshots Relevant logs are as below: Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Change:
mv $out/usr/share $out/share rm -rf $out/usr substituteInPlace $out/share/applications/ocenaudio.desktop  <del> --replace "/opt/ocenaudio/bin/ocenaudio" "ocenaudio" </del> <ins> --replace-fail "/opt/ocenaudio/bin/ocenaudio" "ocenaudio" </ins> mkdir -p $out/share/licenses/ocenaudio mv $out/bin/ocenaudio_license.txt $out/share/licenses/ocenaudio/LICENSE

Discussion:
Getting the following error when trying to install =! I'm using the latest NixOS 11.23 and Gnome.
Change:
path = with pkgs; [ iptables ipset iproute systemd ]; <del> postStart = '' </del> <ins> # The sshguard ipsets must exist before we invoke # iptables. sshguard creates the ipsets after startup if # necessary, but if we let sshguard do it, we can't reliably add # the iptables rules because postStart races with the creation # of the ipsets. So instead, we create both the ipsets and # firewall rules before sshguard starts. preStart = '' ${pkgs.ipset}/bin/ipset -quiet create -exist sshguard4 hash:net family inet ${pkgs.ipset}/bin/ipset -quiet create -exist sshguard6 hash:net family inet6 </ins> ${pkgs.iptables}/bin/iptables  -I INPUT -m set --match-set sshguard4 src -j DROP ${pkgs.iptables}/bin/ip6tables -I INPUT -m set --match-set sshguard6 src -j DROP ''; <del> preStop = '' </del> <ins> postStop = '' </ins> ${pkgs.iptables}/bin/iptables  -D INPUT -m set --match-set sshguard4 src -j DROP ${pkgs.iptables}/bin/ip6tables -D INPUT -m set --match-set sshguard6 src -j DROP <ins> ${pkgs.ipset}/bin/ipset -quiet destroy sshguard4 ${pkgs.ipset}/bin/ipset -quiet destroy sshguard6 </ins> ''; unitConfig.Documentation = "man:sshguard(8)";

Discussion:
Describe the bug the sshguard module includes a post-start script that adds firewall rules to match the that sshguard creates on startup. This script races with sshguard actually creating the s, and when it loses, the entire unit fails to start with: This leads sshguard to crashloop a non-deterministic number of times before starting correctly. If especially unlucky, it crashloops enough times that systemd gives up trying to start it, and sshguard doesn't come up at all until an admin fixes it. To Reproduce to . and , observe crashloop. It may take a few attempts to trigger depending on your machine and luck. Expected behavior sshguard should start cleanly without relying on winning races. Additional context This is a secondary effect of fixing with . In the old world, sshguard didn't create the ipset so nixos's post-start script did both the ipset creation and firewall config. Now, sshguard creates the ipset itself, but we still rely on a post-start script to create firewall rules that depend on the ipsets existing. I believe a correct fix would be to go back to creating the ipset from outside sshguard, and putting both ipset creation and firewall configuration in pre-start, rather than post-start. This way, the system state would already be satisfactory to sshguard, and it would not need to do anything itself. Metadata Maintainer information:
I am experiencing the same issue on several servers running 19.03.
will this be backported to 19.03?
Change:
"test_example" "test_example_info" "test_load_resample" <ins> # does not converge "test_nnls_vector" </ins> ]; meta = with lib; {

Discussion:
Steps to reproduce the behavior: in nixos-unstable chanale 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi thanks for the report but I'm not using the package anymore, I have attempted to fix it in the past. I'll be removing myself as maintainer with a PR. I will try to take a look in details at the logs if I can find the time and see if I can leave helpful comment for anyone willing to investigate more further
Not using it as well, but I can give it a quick look
I could get it to nix build with the following test on master IMO we can just ignore that test. I'll make a PR. In the meantime, you can make an overlay to fix it for you.
Change:
"test_check_link_response_only" # fails on hydra https://hydra.nixos.org/build/242624087/nixlog/1 ]; }); <ins> python-dateutil = prev.python-dateutil.overridePythonAttrs (prev: { version = "2.8.2"; pyproject = null; src = prev.src.override { version = "2.8.2"; hash = "sha256-ASPKzBYnrhnd88J6XeW9Z+5FhvvdZEDZdI+Ku0g9PoY="; }; patches = [ # https://github.com/dateutil/dateutil/pull/1285 (fetchpatch { url = "https://github.com/dateutil/dateutil/commit/f2293200747fb03d56c6c5997bfebeabe703576f.patch"; relative = "src"; hash = "sha256-BVEFGV/WGUz9H/8q+l62jnyN9VDnoSR71DdL+LIkb0o="; }) ]; postPatch = null; }); </ins> ruamel-yaml = prev.ruamel-yaml.overridePythonAttrs (prev: { src = prev.src.override { version = "0.17.21";

Discussion:
Steps to reproduce the behavior: awscli2 New to NixOS, I ran and . Removing and reinstalling the package did not fix the issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello Thank you for reporting the issue. Indeed, I have a PR to upgrade awscli2 to 2.15.29 whose the build is failing now after rebasing it with master: Looks like the issue could be caused by this python-updates PR merged into staging branch: (and then merged into master yesterday: ) Looks like could be the cause. I will take a look.
Indeed, used to check if the installed dependencies meets constraints does only supports simple version numbers (X.Y.Z). And version does not parse and the script fails ( is also not semver compliant, and using ).
I am also experiencing the same issue
Looks like upstream may be trying to avoid this version too for now, they made recently pinning it to . Overriding the package to use (and adding a substitution for 's version string and some test weirdness) seems to let it build -- maybe just worth doing that in your upgrade PR?
Thanks for your help. Indeed, looks like pinning python-dateutil to 2.8.2 is a resolution: Yes, I the fix in my upgrade PR.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The build has just passed on Hydra:
Its arrived in . I think this can be closed now
Yes we can close now :)
Awesome, thank you for your help !
Change:
, pango , pipewire , udev <ins> , wayland </ins> , xorg , zlib , xdg-utils

Discussion:
I am running Brave with with ozone/wayland (see for how to achieve that). Brave 1.26.77 was fine, while 1.27.111 crashes with Steps to reproduce the behavior: Brave with Wayland () 1.27.111 to run Should start as Wayland client (I always check with ) I checked the underlying .deb package we are using. The only change in dependencies I could find was . Replacing our with did not fix it. Here is the output where I observed that: Please run and paste the result.
r-ryantm is a bot. Ping the real maintainers
Thanks for the notice. pinging
I can reproduce this on 1.30.89:
Still happens:
with applied fails with
I can confirm that fixes this.
Change:
darwin.apple_sdk_11_0.frameworks.OpenAL ]; <ins> appendRunpaths = [ (lib.makeLibraryPath [ vulkan-loader ]) ]; </ins> enableParallelBuilding = true; makeFlags = lib.optionals stdenv.isLinux [

Discussion:
The package for the Ares emulator doesn't seem to include Vulkan packages so it will return if you try to run a Nintendo 64 game. Other cores that don't use Vulkan are unaffected Steps to reproduce the behavior: Ares N64 game error in console glitched or black screen The game works ! see similar issue: Ares issue before I realized it was likely NixOS: GPU: RX 6800 Driver install setup: <!-- 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]:
Change:
then "DYLD_LIBRARY_PATH" else "LD_LIBRARY_PATH"; <del> generic = { version, sha256, patches ? [] }: stdenv.mkDerivation rec { </del> <ins> generic = { version, hash, patches ? [] }: stdenv.mkDerivation rec { </ins> pname = "libressl"; inherit version; src = fetchurl { url = "mirror://openbsd/LibreSSL/${pname}-${version}.tar.gz"; <del> inherit sha256; </del> <ins> inherit hash; </ins> }; nativeBuildInputs = [ cmake ];

Discussion:
LibreSSL 3.4 version will go EOL in October of this year, so we'll need to switch to 3.5
Change:
sha256 = "1cfnzamr4mvgpf6yhm28lh9cafy9z6842s8jpbqnfizfxybg8ylj"; }; <ins> patches = [ # CVE-2019-12448 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/gvfs/commit/464bbc7e4e7fdfc3cb426557562038408b6108c5.patch"; sha256 = "03fwlpj1vbi80661bbhzv8ddx3czkzv9i1q4h3gqyxi5f1i0xfz4"; }) # CVE-2019-12447 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/gvfs/commit/cf2f9c4020bbdd895485244b70e9442a80062cbe.patch"; sha256 = "1p7c48nsx1lkv2qpkyrsm9qfa77xwd28gczwcpv2kbji3ws5qgj5"; }) (fetchpatch { url = "https://gitlab.gnome.org/GNOME/gvfs/commit/64156459a366d64ab19187455016929b1026189a.patch"; sha256 = "0zxbhmgqxxw987ag8fh6yjzjn9jl55fqbn814jh9kwrk7x4prx9x"; }) # CVE-2019-12449 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/gvfs/commit/ec939a01c278d1aaa47153f51b5c5f0887738dd9.patch"; sha256 = "0hfybfaz2gfx3yyw5ymx6q0pqwkx2r1i7gzprfp80bplwslq0d4h"; }) # CVE-2019-12795 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/gvfs/commit/d8c9138bf240975848b1c54db648ec4cd516a48f.patch"; sha256 = "1lx6yxykx24mnq5izijqk744zj6rgww6ba76z0qjal4y0z3gsdqp"; }) ]; </ins> postPatch = '' # patchShebangs requires executable file chmod +x meson_post_install.py

Discussion:
, (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.
See also
Change:
libsForQt512 = recurseIntoAttrs (lib.makeScope qt512.newScope mkLibsForQt5); <del> qt5 = qt512; libsForQt5 = libsForQt512; </del> <ins> # TODO bump to 5.12 on darwin once it's not broken qt5 = if stdenv.isDarwin then qt511 else qt512; libsForQt5 = if stdenv.isDarwin then libsForQt511 else libsForQt512; </ins> qt5ct = libsForQt5.callPackage ../tools/misc/qt5ct { };

Discussion:
is broken on darwin, it requires an updated patch: Full log: Failure intrudoced in Blocks trunk through : cc
Change:
outputs = [ "out" "doc" ] ++ lib.optional (builtins.elem "documentation" features_) "man"; <ins> CXXFLAGS = lib.optionals stdenv.isDarwin [ "-D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0" ]; </ins> mesonFlags = [ "-Dtest=true" "-Dmanpages=true"

Discussion:
mpd is failing to build both for me locally and on hydra: i have an old version of mpd installed, and im running . i see similar output about locally as appears in the hydra build
Change:
mv gwt-$gwtVer $GWT_LIB_DIR/gwt/$gwtVer mkdir dependencies/common/dictionaries <del> for dict in $hunspellDicts; do </del> <ins> for dict in $hunspellDictionaries; do </ins> for i in "$dict/share/hunspell/"* do ln -sv $i dependencies/common/dictionaries/ done

Discussion:
No file is provided by Rstudio so system menus in KDE (and presumably any DE) don't show it. System: Nix version: (run ) Nixpkgs version: (run )
Change:
<del> { lib, bundlerApp, bundlerUpdateScript, makeWrapper, gnugrep, libinput }: bundlerApp { pname = "fusuma"; gemdir = ./.; exes = [ "fusuma" ]; nativeBuildInputs = [ makeWrapper ]; postBuild = '' wrapProgram "$out/bin/fusuma"  --prefix PATH : ${lib.makeBinPath [ gnugrep libinput ]} ''; passthru.updateScript = bundlerUpdateScript "fusuma"; meta = with lib; { description = "Multitouch gestures with libinput driver on X11, Linux"; homepage = "https://github.com/iberianpig/fusuma"; license = licenses.mit; maintainers = with maintainers; [ nicknovitski Br1ght0ne ]; platforms = platforms.linux; }; } </del>

Discussion:
Package name: fusuma Latest released version: 3.5.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 <!-- 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]. By the way, fusuma now use yml file instead of yaml file as config file. now when I use HM , it will generate a yaml file in .config, please update it to change it to a yml file. and when I use = true; it wont be installed. [reaction]: [issues you find important]:
I guess that this should be addressed at home-manager repository as nixpkgs does not offer a fusuma service, as far as I rembember
you are right
Already fixed in home-manager:
sorry, I don't understand. if it has been fixed, why I still have the same issue? I just installed yesterday.
Are you perhaps not on ?
ah, right. I use stable nixos and HM, install some new software with pkgs-unstable. But this is a service, how do I change the package to unstable version? I tried = pkgs- But the result is still same.
It's fixed on master branch of Home Manager and not have been backported to release-23.11. Home manager master always follows the NixOS unstable branch, so I won't suggest switching to master branch of HM unless you upgrade your system to nixos-unstable.
Change:
rec { # binlore = callPackage ./binlore.nix { }; <del> oil = callPackage ./oildev.nix { inherit python27; }; </del> <ins> oil = callPackage ./oildev.nix { inherit python27; inherit six; inherit typing; }; configargparse = python27.pkgs.buildPythonPackage rec { pname = "configargparse"; version = "1.5.3"; src = fetchFromGitHub { owner = "bw2"; repo = "ConfigArgParse"; rev = "v${version}"; sha256 = "1dsai4bilkp2biy9swfdx2z0k4akw4lpvx12flmk00r80hzgbglz"; }; doCheck = false; pythonImportsCheck = [ "configargparse" ]; meta = with lib; { description = "A drop-in replacement for argparse"; homepage = "https://github.com/bw2/ConfigArgParse"; license = licenses.mit; }; }; six = python27.pkgs.buildPythonPackage rec { pname = "six"; version = "1.16.0"; src = python27.pkgs.fetchPypi { inherit pname version; sha256 = "1e61c37477a1626458e36f7b1d82aa5c9b094fa4802892072e49de9c60c4c926"; }; doCheck = false; meta = { description = "A Python 2 and 3 compatibility library"; homepage = "https://pypi.python.org/pypi/six/"; license = lib.licenses.mit; }; }; typing = python27.pkgs.buildPythonPackage rec { pname = "typing"; version = "3.10.0.0"; src = python27.pkgs.fetchPypi { inherit pname version; sha256 = "13b4ad211f54ddbf93e5901a9967b1e07720c1d1b78d596ac6a439641aa1b130"; }; doCheck = false; meta = with lib; { description = "Backport of typing module to Python versions older than 3.5"; homepage = "https://docs.python.org/3/library/typing.html"; license = licenses.psfl; }; }; </ins> }

Discussion:
fails with the error message: Steps to reproduce the behavior: install bats <details<summarynix profile install nixpkgs#bats --show-trace</summary</detailsupgrading bats fails with the same error (assuming one had installed it before) n.a. Please run and paste the result.
This will be fixed by
Change:
postPatch = '' substituteInPlace ./tauri.conf.json  <del> --replace-fail '"distDir": "../dist",' '"distDir": "${finalAttrs.ui}",'  --replace-fail '"beforeBuildCommand": "pnpm build",' '"beforeBuildCommand": "",' </del> <ins> --replace-fail '"frontendDist": "../dist",' '"frontendDist": "${finalAttrs.ui}",'  --replace-fail '"beforeBuildCommand": "pnpm build:desktop",' '"beforeBuildCommand": "",' </ins> ''; postBuild = ''

Discussion:
Steps to reproduce the behavior: Attempt to build surrealist version 2.0.6 on NixOS 24.11. The build fails during the build phase. I reported a similar issue here: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
another failure
Change:
if channel_name in channels: continue <ins> # We only look for channels that are listed in our version pin file. if channel_name not in last_channels: continue </ins> # If we're back at the last release we used, we don't need to # keep going -- there's no new version available, and we can # just reuse the info from last time.

Discussion:
Package name: google-chrome Latest released version: 116.0.5845.187 Current version on the unstable channel: 116.0.5845.179 Current version on the stable/release channel: 116.0.5845.179 Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Please note a new version of Chrome is now available to address an exploited-in-the-wild zero-day vulnerability in the WebP image parsing code in the Chrome browser. This vulnerability could allow arbitrary code execution when a specially crafted image is viewed. Please update as soon as possible. For more information on the vulnerability, tracked as CVE-2023-4863, refer to this disclosure from Google: Note for maintainers: Please tag this issue in your PR.
I'm seeing on both 23.05 and unstable. Per chromium/google-chrome was one of the first things that was patched.
Those versions are released on both channels but on stable updates for google-chrome-dev and google-chrome-beta are missing
Change:
sed -i "s,/usr/share/pdf.js,${pdfjs},g" qutebrowser/browser/pdfjs.py ''; <del> postBuild = '' a2x -f manpage doc/qutebrowser.1.asciidoc ''; </del> postInstall = '' install -Dm644 doc/qutebrowser.1 "$out/share/man/man1/qutebrowser.1" install -Dm644 misc/org.qutebrowser.qutebrowser.desktop 

Discussion:
This error occurs when trying to open the help page. ! Steps to reproduce the behavior: Launch qutebrowser-qt6 Run :help Loads help page (since qt6 build, although not a maintainer) Note this doesn't happen for the qt5 build.
I probably should have myself as a maintainer. Seems it is not all urls since I can still load , the help is gone. Perhaps it needs to be explicitly built like the man page.
Change:
pipewire = callPackage ../development/libraries/pipewire {}; pipewire_0_2 = callPackage ../development/libraries/pipewire/0.2.nix {}; <del> pyradio = callPackage ../applications/radio/pyradio {}; </del> <ins> pyradio = callPackage ../applications/audio/pyradio {}; </ins> pyrex = pyrex095;

Discussion:
The contains both radio communication software (for signal processing / software radio, e.g ) and internet music radio-players (e.g. . These belong to separate domains (hobbyist vs. end-user) and should therefore be separated. I believe it would make sense to put all the music radio players into the audio folder, as it already contains a few radio-players (e.g. , which --confusingly-- is also the name of a commonly used radio communication frequency) I would be willing to sift through the section and find all misplaced packages, but I don't know how to work with github and create pull requests.. :innocent:
Thank you! That looks like a good explanatory guide. I guess that leaves me with no choice to get my hands dirty then. (Might take me a while to get started, so only ping me if you didn't hear from in a week.) As for why I couldn't search for this guide myself?.. I guess there simply is a difference between being lost and having to find guidance yourself and getting a peer-reviewed recommendation.
Hey I created a pull request -- would you be willing to take a look?
Change:
pyomo = callPackage ../development/python-modules/pyomo { }; <del> pyp = callPackage ../development/python-modules/pyp { inherit (pkgs) jq; }; </del> pypng = callPackage ../development/python-modules/pypng { }; phonemizer = callPackage ../development/python-modules/phonemizer { };

Discussion:
Steps to reproduce the behavior: or 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
this is about to hit 23.11 as well with PR it's probably triggered by patch-level updates to python3 all platforms are affected: