jiebi/CodeConvo huggingface dataset:
Change:
sha256 = "1x3i9wmzw33fpkis203alygfnrkcmq9w1aydcm887jh6frfqm6cw"; }; <ins> patches = [ ./skip-asyncore-python-3.12.patch ]; </ins> # No tests distributed doCheck = false; <ins> pythonImportsCheck = [ "pyinotify" ]; </ins> meta = with lib; { homepage = "https://github.com/seb-m/pyinotify/wiki"; description = "Monitor filesystems events on Linux platforms with inotify";

Discussion:
auto-cpufreq has runtime error. Steps to reproduce the behavior: in terminal give command not found error or help message error: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --I mentioned sarcasticadmin because Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Closing upon digging into this deeper: it looks like this error is due to the removal of asyncore from python 3.12 which is effecting pyinotify. See: and This probably means anything running on python 3.12 with pyinotify is also broken. Ill make the fix there.
Change:
openssl, Security, msgpack, <ins> fetchpatch, </ins> }: buildPythonPackage rec { pname = "etebase"; <del> version = "0.31.6"; </del> <ins> version = "0.31.7"; </ins> src = fetchFromGitHub { owner = "etesync"; repo = "etebase-py"; rev = "v${version}"; <del> hash = "sha256-T61nPW3wjBRjmJ81w59T1b/Kxrwwqvyj3gILE9OF/5Q="; </del> <ins> hash = "sha256-ZNUUp/0fGJxL/Rt8sAZ864rg8uCcNybIYSk4POt0vqg="; </ins> }; <ins> # https://github.com/etesync/etebase-py/pull/54 patches = [ # fix python 3.12 build (fetchpatch { url = "https://github.com/etesync/etebase-py/commit/898eb3aca1d4eb30d4aeae15e35d0bc45dd7b3c8.patch"; hash = "sha256-0BDUTztiC4MiwwNEDFtfc5ruc69Qk+svepQZRixNJgA="; }) # replace flapigen git dependency in Cargo.lock (fetchpatch { url = "https://github.com/etesync/etebase-py/commit/7e9e4244a144dd46383d8be950d3df79e28eb069.patch"; hash = "sha256-8EH8Sc3UnmuCrSwDf3+as218HiG2Ed3r+FCMrUi5YrI="; }) ]; </ins> cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-wrMNtcaLAsWBVeJbYbYo+Xmobl01lnUbR9NUqqUzUgU="; </del> <ins> hash = "sha256-We19laZd6b2fLSPNLegyNp0eQSeCvUJeTIXqvG7o08c="; inherit patches; </ins> }; format = "pyproject";

Discussion:
Steps to reproduce the behavior: or build
Looked through upstream and there is an issue about it: It mentioned that support for python312 in (that is used in ) is unlikely. But 3 week ago PR was merged that supposedly fixed python312 support (also has something related to from this error): Tag with fix: So there may be an upstream fix, if somebody who understands it all can pass it through and .
Change:
stdenv.mkDerivation rec { pname = "ocenaudio"; <del> version = "3.10.2"; </del> <ins> version = "3.10.6"; </ins> src = fetchurl { url = "https://www.ocenaudio.com/downloads/index.php/ocenaudio_debian9_64.deb?version=${version}"; <del> sha256 = "sha256-mmo6/zc/3R8ptXfY01RKUOLgmDhWTHiYBMlGqpdMTAo="; </del> <ins> sha256 = "0fgvm1xw2kgrqj3w6slpfxbb3pw9k8i0dz16q9d5d8gyyvr2mh8g"; </ins> }; nativeBuildInputs = [ autoPatchelfHook qt5.qtbase <ins> qt5.wrapQtAppsHook </ins> libjack2 libpulseaudio bzip2

Discussion:
Describe the bug same with previous versions nixpkgs at nixpkgs at nixpkgs at their download url seems not stable. i got the same file (hash) every time the latest version is 3.10.5. an update should fix it. but stable url would still be good To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
{ lib , stdenv <del> , fetchurl </del> <ins> , fetchFromSourcehut </ins> , pkg-config , scdoc , wayland

Discussion:
Describe the bug Sources from archives from fail to download with hash mismatches. To Reproduce Expected behavior The hash should match and the source should download. Additional context It sounds like , causing changes to all generated archives (to come in-line with GNU gzip). I've determined some packages which this affects (listed in "Maintainer information") by . I'm happy to have a go making a PR for all of these packages with the following process: archive from cache (by with subsituters) archive from both and confirm tar files are identical hash according to newly retrieved archive But if there's a better process, please let me know :) Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Sounds good
I think it is preferable to switch all affected derivations to fetchzip. This should prevent this from happening again, if the actual content of the tarball is the same. Even better, you could add a fetchFromSourceHut function which uses fetchzip under the hood, like fetchFromGitHub and fetchFromGitLab. This would encourage people not to use fetchurl to fetch procedurally generated tarballs from sourcehut.
From a quick look at the ticket, this is supposed to be a one-time change to make the hash the same as in other forges though
I think getting the new hashes with e.g. should be enough (fetches securely via HTTPS and we should be able to trust that the contents remain unchanged). +1, that seems like the best (long-term) solution. Edit: And IMO we should keep using archives (e.g. because it's consistent with the GitHub and GitLab fetchers) and should indeed be fine now:
the point is: with fetchzip, we don't have to trust this pinky promise (I mean, I'm sure that they intend to keep it, but it could break unwillingly). That's exactly why fetchzip exists in the first place. So on fixes keeping fetchurl.
oh, my bad, I didn't read your comment carefully enough :o I thought you've meant vs. (which didn't make much sense) but realized now that it was vs. . :+1: for that then :)
Hah, same. too then
is merged now so you could submit a PR to switch the affected attributes/packages to the new (s. ). I can also take care of it if you want.
Change:
<ins> diff --git i/app/proc_globdata.pas w/app/proc_globdata.pas index d161b09c7..0fcfbdc09 100644 --- i/app/proc_globdata.pas +++ w/app/proc_globdata.pas @@ -1342,6 +1342,7 @@ begin {$ifdef unix} for Dir in [ +              '@python3@/lib', '/usr/lib64', '/usr/lib', '/usr/lib/x86_64-linux-gnu' @@ -1364,7 +1365,7 @@ var function GetDirPrecopy: string; begin {$ifdef linux} -  exit('/usr/share/cudatext'); +  exit('@out@/share/cudatext'); {$endif} {$ifdef darwin} @@ -2056,7 +2057,7 @@ begin FindWrapAtEdge_Delay:= 350; FindWrapAtEdge_ThemeItem:= ''; //'EdMarkedRangeBg'; -    AllowProgramUpdates:= true; +    AllowProgramUpdates:= false; EscapeClose:= false; EscapeCloseConsole:= true; EscapeCloseFinder:= true; </ins>

Discussion:
Cudatext does not have access to , hence multiple feature are not working (opening folders, installing plugins). Steps to reproduce the behavior: Cudatext Cudatext the warning in the Console that no Python 3 engine was found. On install, cudatext should have access to since that seems to be the intention according to the initial pull request . I looked at the packages definition, and it seems that the replace is not working anymore. The file upstream has changed since the initial pr and now does not contain "" anymore. I guess that that is the cause of this. Please run and paste the result.
Change:
pname = "aerc"; version = "0.5.2"; <del> src = fetchurl { url = "https://git.sr.ht/~sircmpwn/aerc/archive/${version}.tar.gz"; sha256 = "h7kiRA5TuZ8mDSMymWU33stFLIOMd06TQLYzKW+faO4="; </del> <ins> src = fetchFromSourcehut { owner = "~sircmpwn"; repo = pname; rev = version; sha256 = "1ja639qry8h2d6y7qshf62ypkzs2rzady59p81scqh8nx0g9bils"; </ins> }; runVend = true;

Discussion:
Describe the bug Sources from archives from fail to download with hash mismatches. To Reproduce Expected behavior The hash should match and the source should download. Additional context It sounds like , causing changes to all generated archives (to come in-line with GNU gzip). I've determined some packages which this affects (listed in "Maintainer information") by . I'm happy to have a go making a PR for all of these packages with the following process: archive from cache (by with subsituters) archive from both and confirm tar files are identical hash according to newly retrieved archive But if there's a better process, please let me know :) Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Sounds good
I think it is preferable to switch all affected derivations to fetchzip. This should prevent this from happening again, if the actual content of the tarball is the same. Even better, you could add a fetchFromSourceHut function which uses fetchzip under the hood, like fetchFromGitHub and fetchFromGitLab. This would encourage people not to use fetchurl to fetch procedurally generated tarballs from sourcehut.
From a quick look at the ticket, this is supposed to be a one-time change to make the hash the same as in other forges though
I think getting the new hashes with e.g. should be enough (fetches securely via HTTPS and we should be able to trust that the contents remain unchanged). +1, that seems like the best (long-term) solution. Edit: And IMO we should keep using archives (e.g. because it's consistent with the GitHub and GitLab fetchers) and should indeed be fine now:
the point is: with fetchzip, we don't have to trust this pinky promise (I mean, I'm sure that they intend to keep it, but it could break unwillingly). That's exactly why fetchzip exists in the first place. So on fixes keeping fetchurl.
oh, my bad, I didn't read your comment carefully enough :o I thought you've meant vs. (which didn't make much sense) but realized now that it was vs. . :+1: for that then :)
Hah, same. too then
is merged now so you could submit a PR to switch the affected attributes/packages to the new (s. ). I can also take care of it if you want.
Change:
- The latest version of `clonehero` now stores custom content in `~/.clonehero`. See the [migration instructions](https://clonehero.net/2022/11/29/v23-to-v1-migration-instructions.html). Typically, these content files would exist along side the binary, but the previous build used a wrapper script that would store them in `~/.config/unity3d/srylain Inc_/Clone Hero`. <ins> - `python3.pkgs.fetchPypi` (and `python3Packages.fetchPypi`) has been deprecated in favor of top-level `fetchPypi`. </ins> - `etcd` has been updated to 3.5, you will want to read the [3.3 to 3.4](https://etcd.io/docs/v3.5/upgrades/upgrade_3_4/) and [3.4 to 3.5](https://etcd.io/docs/v3.5/upgrades/upgrade_3_5/) upgrade guides ## Other Notable Changes {#sec-release-23.11-notable-changes}

Discussion:
Since , was moved to top level, and and are aliases of from the top level To find the usages of these aliases, you can search for in the repository Note that there are false positives (e.g. when used in overlays) and this also might not include all usages (let inherit)
Change:
) machine = create_machine({"startCommand": start_command}) <del> '' + script; </del> <ins> try: '' + indentLines script + '' finally: machine.shutdown() ''; </ins> inherit meta; };

Discussion:
takes an argument that copies source paths into the resulting VM image. It seems to work fine when the sources are files or , but when copying directories, they end up nested inside the target directory named with a nix-store-like path. This is not what I expected, it is hard to use, and I do not think it is the intended behavior. these files: (and additional , see attached ). the VM image with . the VM image, e.g. with . in with credentials literal . that contains a subdirectory with a Nix-store-like path, e.g. instead of . I expected that the source would end up at the target, as happens with contents objects that are files. ! I will have a PR with a test and fix up soon. When changing the behavior of a function that is already widely used, even fixing a bug can cause problems for people. I checked, but I did not find any existing usages of with directories in . And given how broken the directory support seems, I suspect that it is not actually used in the wild, so I think it is okay to fix this behavior. Please run and paste the result.
Change:
, precis-i18n , pygobject3 , pyopenssl <ins> , setuptools </ins> , pytestCheckHook }: buildPythonPackage rec { pname = "nbxmpp"; <del> version = "4.0.1"; </del> <ins> version = "4.2.2"; </ins> disabled = pythonOlder "3.10";

Discussion:
Package name: gajim Latest released version: 1.7.3 <!-- Search your package here: --- Current version on the unstable channel: 1.5.4 Current version on the stable/release channel: 1.6.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 Note for maintainers: Please tag this issue in your PR.
New sha256 hash, but it doesn’t just work with a version bump because they changed something with the build setup.
Change:
{ lib <ins> , atom </ins> , buildPythonPackage <ins> , bytecode , cppy </ins> , fetchFromGitHub <del> , setuptools-scm , atom , ply </del> , kiwisolver <ins> , pegen , ply </ins> , qtpy <ins> , setuptools , setuptools-scm , pythonOlder </ins> , sip_4 <del> , cppy , bytecode </del> }: buildPythonPackage rec { pname = "enaml"; version = "0.16.0"; <ins> format = "pyproject"; disabled = pythonOlder "3.8"; </ins> src = fetchFromGitHub { owner = "nucleic";

Discussion:
Steps to reproduce the behavior: `nix-build '<nixpkgs' -A Fails since /cc
Change:
patchShebangs meson_post_install.py ''; <del> postInstall = '' rm $out/share/applications/mimeinfo.cache ''; </del> meta = { homepage = https://fontmanager.github.io/; description = "Simple font management for GTK+ desktop environments";

Discussion:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .
Change:
haproxy = handleTest ./haproxy.nix {}; hardened = handleTest ./hardened.nix {}; healthchecks = handleTest ./web-apps/healthchecks.nix {}; <del> hbase1 = handleTest ./hbase.nix { package=pkgs.hbase1; }; </del> hbase2 = handleTest ./hbase.nix { package=pkgs.hbase2; }; <ins> hbase_2_4 = handleTest ./hbase.nix { package=pkgs.hbase_2_4; }; </ins> hbase3 = handleTest ./hbase.nix { package=pkgs.hbase3; }; hedgedoc = handleTest ./hedgedoc.nix {}; herbstluftwm = handleTest ./herbstluftwm.nix {};

Discussion:
Apache HBase 1.7 EOL was in 2022/08, can we remove it? via
Hey. Thanks for reminding me. I have a WIP PR for this: I'm not sure why I left it as a draft... I'll go over it again and open it if it's ready.
Change:
makeFlags = [ "PREFIX=${placeholder "out"}" <ins> "ETCDIR=${placeholder "out"}/etc" "SHAREDDIR=${placeholder "out"}/share" </ins> ]; env.NIX_CFLAGS_COMPILE = "-DLSP_NO_EXPERIMENTAL";

Discussion:
Every time there's a version bump it breaks scripts and other things, a versionless lib would go a long way in making it easy to maintain references, especially for "ad-hoc" software like DAWs, that load plugins outside of nix's control. currently I only have in my environment, and pipewire breaks, because I have to have a reference to the file name inside it's config. I would much prefer if all I had to do was specify , and version management can be delegated to Nix(OS), by passing the package to the service & systemPackages.
This seems like an upstream issue to me, not a NixOS one, as we are just using the upstream pkg as is. Feel free to correct me if I'm wrong!
Change:
}; wantedBy = [ "multi-user.target" ]; <del> path = with pkgs; [ iptables bash iproute2 ]; # required by v2rayA TProxy functionality </del> <ins> path = with pkgs; [ iptables bash iproute2 ] ++ lib.optionals nftablesEnabled [ nftables ]; # required by v2rayA TProxy functionality </ins> }; };

Discussion:
On Arch Linux and NixOS, both with nftables installed, enabling the v2rayA systemd service with tproxy enabled will produce different nft rulesets. On Arch Linux, v2rayA creates a dedicated table for it, as shown by : table inet v2raya { set whitelist { type ipv4addr flags interval auto-merge elements = { 0.0.0.0, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, ... On NixOS, however, if v2rayA is started by , the table is not present, and the rules with the TPROXY target are found in the table instead: table ip mangle { ... chain TPPRE { ... ip protocol tcp meta mark & 0x000000c0 == 0x00000040 counter packets 196 bytes xt target "TPROXY" ip protocol udp meta mark & 0x000000c0 == 0x00000040 counter packets 72 bytes 5690 xt target "TPROXY" } ... This is because, currently, only adds to the service : However, v2rayA only consider nftables as supported if it finds the command: So I guess it just falls back to some legacy method of setting the forwarding rules. In fact, v2rayA creates the same ruleset on NixOS after enabling if is started directly from the command line instead of being started as a systemd service. Steps to reproduce the behavior: and v2rayA's panel, enable transparent proxy with tproxy the the rule sets: There should be a table called under . I suggest modifying this line in : <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --CC Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
is the maintainer now.
I've had the same problem before, thank for your feedback. After testing, your suggestions work fine. So I have opened a pull request in
Change:
meta = with stdenv.lib; { description = "A pure python implementation of OTR"; <del> homepage = https://github.com/AGProjects/otr; </del> <ins> homepage = "https://github.com/AGProjects/python-otr"; </ins> license = licenses.lgpl21Plus; platforms = platforms.linux; maintainers = with maintainers; [ edwtjo ]; <ins> # The package itself does not support python3, and its transitive # dependencies rely on namespace package support that does not work in # Nix's python2 infra. See #74619 for details. broken = true; </ins> }; }

Discussion:
This impacts any fixed-output derivation using that is not already in the binary cache. Packages relying on should be inspected to make sure that the canonical source location still actually uses in the first place; many of them have migrated to GitHub or similar places over the years.
It appears that is now fixed.
Change:
buildPhase = '' make world <del> make -i install </del> make bootstrap make opt.opt <ins> make -i install </ins> make installopt mkdir -p $out/include ln -sv $out/lib/ocaml/caml $out/include/caml

Discussion:
Describe the bug All modules are not bundled in ber_metaocaml package. To Reproduce Steps to reproduce the behavior: Expected behavior
Change:
''; }; <ins> borgmatic = { exporterConfig = { enable = true; user = "root"; }; metricProvider = { services.borgmatic.enable = true; services.borgmatic.settings.source_directories = [ "/home" ]; services.borgmatic.settings.repositories = [ { label = "local"; path = "/var/backup"; } ]; services.borgmatic.settings.keep_daily = 10; }; exporterTest = '' succeed("borgmatic rcreate -e none") succeed("borgmatic") wait_for_unit("prometheus-borgmatic-exporter.service") wait_for_open_port(9996) succeed("curl -sSf localhost:9996/metrics | grep 'borg_total_backups{repository="/var/backup"} 1'") ''; }; </ins> collectd = { exporterConfig = { enable = true;

Discussion:
Project description <!-- Describe the project a little: --Prometheus exporter for Borgmatic Written in python, depends on unpackaged python packages and . Metadata homepage URL: source URL: license: mit platforms: any Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
stdenv.mkDerivation { pname = "libraw"; <del> version = "unstable-2021-12-03"; </del> <ins> version = "0.20.2.p2"; </ins> src = fetchFromGitHub { owner = "LibRaw"; repo = "LibRaw"; <del> rev = "52b2fc52e93a566e7e05eaa44cada58e3360b6ad"; sha256 = "kW0R4iPuqnFuWYDrl46ok3kaPcGgY2MqZT7mqVX+BDQ="; </del> <ins> rev = "fedad11e87daad7b7d389a3ef84ccf10b5e84710"; # current 0.20-stable branch sha256 = "1mklf8lzybzyg75ja34822xlv6h9nw93griyrjjna7darl1dyvja"; </ins> }; outputs = [ "out" "lib" "dev" "doc" ];

Discussion:
Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.
Change:
subPackages = [ "cmd/main.go" ]; ldflags = [ <del> "-s" "-w" </del> <ins> "-s" "-w" </ins> "-X github.com/danielfoehrkn/kubeswitch/cmd/switcher.version=${version}" "-X github.com/danielfoehrkn/kubeswitch/cmd/switcher.buildDate=1970-01-01" ]; <del> passthru.tests.version = testers.testVersion { package = kubeswitch; }; </del> <ins> nativeBuildInputs = [ installShellFiles ]; </ins> postInstall = '' <del> mv $out/bin/main $out/bin/switch </del> <ins> mv $out/bin/main $out/bin/switcher for shell in bash zsh fish; do $out/bin/switcher --cmd switcher completion $shell > switcher.$shell installShellCompletion --$shell switcher.$shell done </ins> ''; <del> meta = with lib; { description = "The kubectx for operators"; license = licenses.asl20; </del> <ins> passthru.tests.version = testers.testVersion { package = kubeswitch; }; meta = { changelog = "https://github.com/danielfoehrKn/kubeswitch/releases/tag/${version}"; description = "The kubectx for operators, a drop-in replacement for kubectx"; license = lib.licenses.asl20; </ins> homepage = "https://github.com/danielfoehrKn/kubeswitch"; <del> maintainers = with maintainers; [ bryanasdev000 ]; mainProgram = "switch"; </del> <ins> maintainers = with lib.maintainers; [ bryanasdev000 ]; mainProgram = "switcher"; </ins> }; }

Discussion:
Kubeswitch requires both the binary and a script Steps to reproduce the behavior: kubeswitch to use Kubeconfig is set as intended only adds the binary, not the script itself. On the other hand, I'm not using nix directly but via fleek.
Hey happy first issue! About the kubeswitch, indeed, I did make this mistake as I am using it on my work machine which is not NixOS and I had done the standard installation in the past, so I got the binary from Nix, but not the script. Honestly, I need time and a little bit of searching on how to handle scripts, as I have only messed with Go or Python packages (which have a nice interface, BTW).
This will help fix it.
I did not test, but thanks. are you willing to do fix it?
Hi, sorry I want to but do not have much time recently.