jiebi/CodeConvo huggingface dataset:
Change:
rev = "33402b7c545c5a92b7042369867e7eb75ef32a59"; hash = "sha256-duSEpd2GBBskoKNFos5X9wFtsjRct1918VhZd1T2rvU="; }; <ins> buildInputs = [ glib gsettings-desktop-schemas ]; nativeBuildInputs = [ wrapGAppsHook ]; </ins> propagatedBuildInputs = with python3.pkgs; [ future pyserial

Discussion:
Using the file manager in chirp (specifically the version used in nixpkgs-unstable) causes the program to crash Console errors: Similar issues seem to have been fixed with wrapGAppsHook, but I can't seem to figure it out. Steps to reproduce the behavior: from nixpkgs-unstable to open a file via the file-open dialogue, or try to save a file. The program does not crash, allows file saving and loading. None listed so pinging last few contributors: Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I can't reproduce the issue on both GNOME 44 and Xfce 4.18, so I'm not sure what the solution is. But maybe adding both and to would help?
Using i3wm myself. Adding to the package (with the appropriate argument lines at the top) results in the same error
Oh! Adding wrapGAppshook to nativebuildInputs as well as the above change seems to fix it.
Change:
}; nativeBuildInputs = [ qmake qttools flex bison ]; <del> buildInputs = [ qtbase libsForQt5.poppler ]; </del> <ins> buildInputs = [ qtbase poppler ]; </ins> # src/data/tikzlexer.l:29:10: fatal error: tikzparser.parser.hpp: No such file or directory enableParallelBuilding = false;

Discussion:
Describe the bug The binary fails to launch in . Output: To Reproduce Steps to reproduce the behavior: to vis CLI Expected behavior The Seafile Applet starts without issues. Additional context This could be related to a missing , however looks like it does include an alternative way of the hook. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
Can you try to see if adding helps?
Fixing this now.
That's a fast response, thank you both! Just wondering: Why didn't this occur earlier?
It was large issue that a lot of qt apps in nixpkgs weren't packaged correctly Hopefully people will read the qt section of the manual now, since it's always been to do
Oh, I'm well aware of the Qt Apps problem in general. What I'm wondering is why I did not run into this issue before 20.03. I'm using seafile since 17.03, and I'm not using a Qt DE that circumvents the problem, so I'm wondering why this problem ocured first in 20.03.
Me trying to run it from nixos-unstable results in That is indeed strange.
I figured out the timeline and why you just now experienced this issue
Change:
<ins> { lib , buildPythonPackage , pythonOlder , fetchPypi , ptpython , ipython , setuptools , setuptools-scm , setuptools-generate }: let pname = "repl-python-wakatime"; version = "0.0.6"; in buildPythonPackage { inherit pname version; format = "pyproject"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; hash = "sha256-s2UelniMn4+wWILbVIIKidRCFaOvo/nNNofA7yf2+9c="; }; nativeBuildInputs = [ setuptools setuptools-scm setuptools-generate ]; propagatedBuildInputs = [ ptpython ipython ]; pythonImportsCheck = [ "repl_python_wakatime" ]; meta = with lib; { description = "Python REPL plugin for automatic time tracking and metrics generated from your programming activity"; homepage = "https://github.com/wakatime/repl-python-wakatime"; license = licenses.gpl3Only; maintainers = with maintainers; [ jfvillablanca ]; }; } </ins>

Discussion:
Project description Python REPL plugin for automatic time tracking and metrics generated from your programming activity. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, ...
Change:
outline = handleTest ./outline.nix {}; image-contents = handleTest ./image-contents.nix {}; openvscode-server = handleTest ./openvscode-server.nix {}; <ins> open-webui = runTest ./open-webui.nix; </ins> orangefs = handleTest ./orangefs.nix {}; os-prober = handleTestOn ["x86_64-linux"] ./os-prober.nix {}; osquery = handleTestOn ["x86_64-linux"] ./osquery.nix {};

Discussion:
Ollama is a big project and I think having a nice UI in the stable repos would make nix even better. I can help with the PR but I am new to nix and don't really understand the git workflow and all Pinging the package maintainer: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Current master is broken for (see ). However, I don’t think that should be a problem while backporting to , as .
Backport PR for 0.2.4:
To track the progress of backporting to latest , see:
I love this, thanks!!
Change:
### N ### ncdu_2 = ncdu; # Added 2022-07-22 <ins> neocities-cli = neocities; # Added 2024-07-31 </ins> nestopia = throw "nestopia was forked; use nestopia-ue instead"; # Added 2024-01-24 net_snmp = throw "'net_snmp' has been renamed to/replaced by 'net-snmp'"; # Converted to throw 2023-09-10 netbox_3_3 = throw "netbox 3.3 series has been removed as it was EOL"; # Added 2023-09-02

Discussion:
I'm not really sure how it happened, however we have 2 copies of the Neocities CLI: One from , and another from . After formatting the nix files in each, the only differences are: Description Maintainers Platforms ( lists ) Gemfile lock platform/bundled-with version ( is bundled-with , has as a platform and is bundled-with ) is older, while is newer and slightly more complete, as it seems. One should be removed, with the other aliased to it. CC as the maintainer of the other Neocities package.
this happened before, i wonder if there are more cases like this rn
I'll take care of this -- it seems like is out of date so might as well take care of that, too.
Change:
stdenv.mkDerivation rec { name = "calf-${version}"; <del> version = "0.90.0"; </del> <ins> version = "0.90.2"; </ins> src = fetchurl { url = "https://calf-studio-gear.org/files/${name}.tar.gz"; <del> sha256 = "0dijv2j7vlp76l10s4v8gbav26ibaqk8s24ci74vrc398xy00cib"; </del> <ins> sha256 = "0bn4j1klw2yfxz8clbmasaydifq25rdfsv0n6iisxrzcj1lx7sgh"; </ins> }; <del> patches = [ # Fix memory leak in limiter # https://github.com/flathub/com.github.wwmm.pulseeffects/issues/12 (fetchpatch { url = https://github.com/calf-studio-gear/calf/commit/7afdefc0d0489a6227fd10f15843d81dc82afd62.patch; sha256 = "056662iw6hp4ykwk4jyrzg5yarcn17ni97yc060y5kcnzy29ddg6"; }) ]; </del> <ins> enableParallelBuilding = true; </ins> buildInputs = [ cairo expat fftwSinglePrec fluidsynth glib gtk2 libjack2 ladspaH

Discussion:
I'm using the latest from and it works fine, mostly. I notice the following errors during start-up, though: Looking at the build it seems like all recommended dependencies are there so it doesn't seem likely that those plugins weren't built, no? But why are they missing at run-time? And why are others (like the equalizer) not missing?
After some bisecting I found to be the cause of this, reverting it fixes it. I'm not entirely sure why that is though, investigating..
Was fixed in calf with , which is in the latest version, I have opened a PR to update calf
Change:
description = "The official implementation library for the hypr config language"; license = licenses.gpl3Plus; platforms = platforms.linux; <ins> maintainers = with maintainers; [ iogamaster fufexan ]; </ins> }; })

Discussion:
Project description Hyprland's idle daemon Metadata homepage URL: source URL: license: BSD 3 clause platforms: Linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
There is an issue with hypridle currently <details<summaryBuild Log</summary<pThis </p</detailsOnce this is fixed I can make the pr for hyprlang and hypridle
Okay, fixed by using the unstable hyprlang lib. hypridle builds, but segfaults upon execution
Issue made:
Should be good, waiting for fufexan's review.
Change:
"--enable-dap" "--enable-shared" "--disable-dap-remote-tests" <ins> "--with-plugin-dir=${placeholder "out"}/lib/hdf5-plugins" </ins> ] ++ (lib.optionals mpiSupport [ "--enable-parallel-tests" "CC=${mpi}/bin/mpicc" ]); <ins> enableParallelBuilding = true; </ins> disallowedReferences = [ stdenv.cc ]; postFixup = ''

Discussion:
While rebuilding on this system that requires the package a failure while building has been occurring since NixOS 22.11. One of the tests fails.
I am not the maintainer of this package. Maybe can help? also have a look at:
Silly me for not checking and just the current release, disabling tests is a hell of a workaround but definitely works!
I'm also not a maintainer of the package, but I'm happy to fix it nonetheless :) There's an issue in that we don't have a good way of setting HDF5PLUGINPATH appropriately. Maybe I'll come back and fix this at some point, but for now this will do...
Change:
diff -ru a/Makefile b/Makefile <del> --- a/Makefile	1970-01-01 01:00:01.000000000 +0100 +++ b/Makefile	1970-01-01 01:00:01.000000000 +0100 @@ -21,8 +21,8 @@ build/dep/osdialog/osdialog_gtk2.c.o: FLAGS += $(shell pkg-config --cflags gtk+-2.0) </del> <ins> --- a/Makefile 1970-01-01 01:00:01.000000000 +0100 +++ b/Makefile 1970-01-01 01:00:01.000000000 +0100 @@ -36,7 +36,7 @@ build/dep/osdialog/osdialog_gtk3.c.o: FLAGS += $(shell pkg-config --cflags gtk+- </ins> <del> LDFLAGS += -rdynamic  -		dep/lib/libGLEW.a dep/lib/libglfw3.a dep/lib/libjansson.a dep/lib/libcurl.a dep/lib/libssl.a dep/lib/libcrypto.a dep/lib/libzip.a dep/lib/libz.a dep/lib/libspeexdsp.a dep/lib/libsamplerate.a dep/lib/librtmidi.a dep/lib/librtaudio.a  +		-lGLEW -lglfw -ljansson -lcurl -lssl -lcrypto -lzip -lz -lspeexdsp -lsamplerate -lrtmidi -lrtaudio  -lpthread -lGL -ldl -lX11 -lasound -ljack  $(shell pkg-config --libs gtk+-2.0) TARGET := Rack endif </del> <ins> LDFLAGS += -Wl,--whole-archive LDFLAGS += -static-libstdc++ -static-libgcc -	LDFLAGS += dep/lib/libGLEW.a dep/lib/libglfw3.a dep/lib/libjansson.a dep/lib/libcurl.a dep/lib/libssl.a dep/lib/libcrypto.a dep/lib/libarchive.a dep/lib/libzstd.a dep/lib/libspeexdsp.a dep/lib/libsamplerate.a dep/lib/librtmidi.a dep/lib/librtaudio.a +	LDFLAGS += -lGLEW -lglfw -ljansson -lcurl -lssl -lcrypto -larchive -lz -lspeexdsp -lsamplerate -lrtmidi -lrtaudio LDFLAGS += -Wl,--no-whole-archive LDFLAGS += -lpthread -lGL -ldl -lX11 -lasound -ljack -lpulse -lpulse-simple LDFLAGS += $(shell pkg-config --libs gtk+-3.0) </ins>

Discussion:
Project description The 2.0 series of VCVRack has been released. I tried to simply update the git revision, but it seems some details of the build process has changed. Pinging Metadata homepage URL: source URL: license: GPL3 platforms: unix, linux, darwin
Looks like it was updated to a later 2.0.x release in:
Change:
{ lib, mkDerivation, fetchFromGitHub, fetchpatch, which, qtbase, qtwebkit, qtscript , libpulseaudio, fftwSinglePrec , lame, zlib, libGLU, libGL, alsa-lib, freetype , perl, pkg-config , libsamplerate, libbluray, lzo, libX11, libXv, libXrandr, libXvMC, libXinerama, libXxf86vm <del> , libXmu , yasm, libuuid, taglib, libtool, autoconf, automake, file, exiv2, linuxHeaders, soundtouch, libzip </del> <ins> , libXmu , yasm, libuuid, taglib, libtool, autoconf, automake, file, exiv2, linuxHeaders , soundtouch, libzip, libhdhomerun </ins> , withWebKit ? false }:

Discussion:
MythTV was not compiled with HDHOMERUN support. To reproduce, start the server configured for an hdhomerun tuner. See this error in the systemd journal: This issue just requires adding to the . I have recompiled and tested with the libhdhomerun library, and it fixes the issue. I'll create a PR with the change, hopefully someone can pull it, is listed as the maintainer.
fyi... You'll most likely need to add the workaround from to actually get your tuner to detect:
Change:
nativeBuildInputs = [ perl xz.bin autoreconfHook ] # autoreconfHook is due to patch, normally only needed for cygwin ++ optionals stdenv.hostPlatform.isCygwin [ texinfo ];  # due to patch <del> configureFlags = [ "--with-packager=https://NixOS.org" ] </del> <ins> configureFlags = [ "--with-packager=https://nixos.org" ] </ins> ++ optional (singleBinary != false) ("--enable-single-binary" + optionalString (isString singleBinary) "=${singleBinary}") ++ optional withOpenssl "--with-openssl"

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: coreutils <!-- 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: 9.0 desired version: 9.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
I'm already on it :) might take some while before I do the pr because I want to build stdenv first
Change:
format = pkgs.formats.yaml {}; nameToId = netName: "nebula-${netName}"; <ins> resolveFinalPort = netCfg: if netCfg.listen.port == null then if (netCfg.isLighthouse || netCfg.isRelay) then 4242 else 0 else netCfg.listen.port; </ins> in { # Interface

Discussion:
When a "lighthouse" and a regular "roaming" node are on the same network and the default value for () is used, nodes occasionally enter a consistent failure state while trying to connect. I suspect this occurs when Nebula tries to NAT-punch with the local router and always tries to connect to the lighthouse instead of the roaming node. Steps to reproduce the behavior: up a lighthouse node and roaming node -forward port 4242 for the lighthouse node to set a value for in the Nebula config intermittent failures The value of should be required, with a link to Nebula docs: I'm not entirely sure, but logs from the issue indicate the lighthouse-node handshakes are both sending packets to "192.168.1.1:4242", which is port-forwarded to the lighthouse (I'm in a dual-NAT setup unfortunately; this is the IP of the outer NAT). Explicitly setting the port to (to automatically select an ephemeral port) on the roaming nodes immediately fixes the issue. (wrote the initial module with the port default) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on those docs, I think we can solve this without requiring the user to specify the port. Since we know whether a node is a lighthouse via , we could implement a behavior where defaults to for lighthouses and for non-lighthouses: I'm not sure how to get the for this, though. Maybe if the options were , then we could just refer to ? We'd probably also want to include . Thoughts?
My thought is that a change should meet the following requirements: Per set and to something like:Set the actual value appropriately in the module with an expression like the above if the input is null. If (isLighthouse or isRelay) and the final port evaluates to 0, we should warn, since this config will probably result in connectivity issues. There should be a test for this. I am split on whether to backport this. While this is a bug, people may have relied on the default port to NAT port forward from routers to a Nebula node that is not a lighthouse or a relay.

As such the new default may impede connectivity on restrictive NATs, so this is also a breaking change.
Also, good job diagnosing this. I think I've run into this before but didn't know what was causing it.
Per (captured in + ) Given this, it is probably a good idea to both fix and backport this.
Change:
<ins> ---   a/src/gnome-desktop/gnome-desktop-thumbnail-script.c +++   a/src/gnome-desktop/gnome-desktop-thumbnail-script.c @@ -514,14 +514,10 @@ add_bwrap (GPtrArray   *array, g_return_val_if_fail (script->s_infile != NULL, FALSE); add_args (array, -	    "bwrap", -	    "--ro-bind", "/usr", "/usr", -	    "--ro-bind", "/lib", "/lib", -	    "--ro-bind", "/lib64", "/lib64", +      "@bubblewrap_bin@", +      "--ro-bind", "@storeDir@", "@storeDir@", "--proc", "/proc", "--dev", "/dev", -	    "--symlink", "usr/bin", "/bin", -	    "--symlink", "usr/sbin", "/sbin", "--chdir", "/", "--setenv", "GIO_USE_VFS", "local", "--unshare-all", </ins>

Discussion:
Thumbnails do not get generated for files. Instead, a 1x1 png file gets written to Here's the relevant terminal output: I'm guessing this is caused by and . Open nautilus in a folder containing images. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Fixed in
I think the fix wasn't sufficient on 3.30 :/ I'm able to reproduce on master at least. IIRC I only checked the fix worked with 3.28.
It seems that patch may need to be applied directly to Nautilus too as it now seems to bundle that code? -
Change:
pytestCheckHook syrupy time-machine <del> ]; </del> <ins> ] ++ passthru.optional-dependencies.syntax; </ins> disabledTestPaths = [ # snapshot tests require syrupy<4

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.37.1 Current version on the stable/release channel: 0.24.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.
Change:
{ stdenv, lib, fetchFromGitHub, makeWrapper <del> , bridge-utils, iproute2, lxc, openvswitch, docker, busybox, dhcpcd, dhcp </del> <ins> , bridge-utils, iproute2, lxc, openvswitch, docker, busybox, dhcpcd </ins> }: stdenv.mkDerivation {

Discussion:
Was announced multiple times, now it is EOL with release 4.2.3 We should remove it before branching 22.05.
Change:
rev = "0c28b6451d77774912e52949c1e57fa726edf113"; sha256 = "sha256-KpCMceTV/BRaoJe1qeXhKYQNQqdGaM6Q9nklpJKzHFY="; }; <del> in stdenv.mkDerivation rec { </del> <ins> in stdenv.mkDerivation rec { </ins> pname = "shaderc"; version = "2021.0";

Discussion:
glslc binary in shaderc has invalid signature Steps to reproduce the behavior: to compile shader on aarch64-darwin to SPIR-V should not be killed
Change:
(mkIf cfgZfs.enabled { assertions = [ { <ins> assertion = cfgZED.enableMail -> cfgZfs.package.enableMail; message = '' To allow ZED to send emails, ZFS needs to be configured to enable this. To do so, one must override the `zfs` package and set `enableMail` to true. ''; } { </ins> assertion = config.networking.hostId != null; message = "ZFS requires networking.hostId to be set"; }

Discussion:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in
Change:
in buildGoModule rec { pname = "forgejo"; <del> version = "1.21.6-0"; </del> <ins> version = "1.21.7-0"; </ins> src = fetchFromGitea { domain = "codeberg.org"; owner = "forgejo"; repo = "forgejo"; rev = "v${version}"; <del> hash = "sha256-YvLdqNo/zGutPnRVkcxCTcX7Xua0FXUs3veQ2NBgaAA="; </del> <ins> hash = "sha256-wYwQnZRIJSbwI+kOPedxnIdfhQ/wWxXpOpdfcFono6k="; </ins> }; <del> vendorHash = "sha256-5BznZiPZCwFEl74JVf7ujFtzsTyG6AcKvQG0LdaMKe4="; </del> <ins> vendorHash = "sha256-Mptfd1WoUXNQkw7sa/GxIO7s5V5/9VmVBtvPCjMsa/4="; </ins> subPackages = [ "." ];

Discussion:
Package name: forgejo Latest released version: 1.21.7-0 <!-- Search your package here: --- Current version on the unstable channel: 1.21.6-0 Current version on the stable/release channel: 1.20.6-1-unstable-2024-02-22 <!-- 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]:
I've opened a PR. FYI Forgejo (and many other packages) has an update script which can simplify this process, and contributions are welcome!
I will try that next time. :)