jiebi/CodeConvo huggingface dataset:
Change:
}; nativeBuildInputs = [ pkg-config ]; <del> buildInputs = [ SDL2 libpng ] ++ lib.optionals stdenv.isDarwin [ libiconv ]; </del> <ins> buildInputs = [ SDL2 libpng ] ++ lib.optionals stdenv.isDarwin [ libiconv libobjc ]; </ins> configureFlags = [ "--with-tests"

Discussion:
As the title says, the package is including wayland despite the system being Darwin. Steps to reproduce the behavior: on Darwin Nix should evaluate and not fail.
Change:
tclx = callPackage ../development/libraries/tclx { }; <del> ntdb = callPackage ../development/libraries/ntdb { python = python2; }; </del> <ins> ntdb = callPackage ../development/libraries/ntdb { }; </ins> tdb = callPackage ../development/libraries/tdb {};

Discussion:
Describe the bug build of failed. To Reproduce Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(gtgteq): nixpkgs: Maintainer information:
Looks like regression in . We need to build talloc with Python 3 too.
It might also need
Change:
<ins> { stdenv , lib , fetchFromGitLab , pkg-config , meson , ninja , wayland , wayland-protocols , cairo , dbus , pango , libxkbcommon }: stdenv.mkDerivation rec { pname = "libdecor"; version = "0.1.0"; src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "jadahl"; repo = "libdecor"; rev = "${version}"; hash = "sha256:0qdg3r7k086wzszr969s0ljlqdvfqm31zpl8p5h397bw076zr6p2"; }; nativeBuildInputs = [ meson ninja pkg-config ]; buildInputs = [ wayland wayland-protocols cairo dbus pango libxkbcommon ]; meta = with lib; { homepage = "https://gitlab.gnome.org/jadahl/libdecor"; description = "Client-side decorations library for Wayland clients"; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ artturin ]; }; } </ins>

Discussion:
Project description Used for client-side decorations on Wayland. Needed for adding libdecor support in . Metadata source URL: license: mit platforms: linux
I have this packaged in my user repository
Change:
, galliumDrivers ? ["auto"] , vulkanDrivers ? ["auto"] , eglPlatforms ? [ "x11" ] ++ lib.optionals stdenv.isLinux [ "wayland" ] <ins> , vulkanLayers ? [ "device-select" "overlay" ] </ins> , OpenGL, Xplugin , withValgrind ? lib.meta.availableOn stdenv.hostPlatform valgrind-light && !valgrind-light.meta.broken, valgrind-light , enableGalliumNine ? stdenv.isLinux

Discussion:
Our mesa build is missing the device-select and overlay layers so that functionality doesn't work. Add to mesonFlags and to postInstall to get device-select working. This doesn't get the overlay working, probably needs a similar change. Other distros eg arch do include these layers: The functionality these layers enable is described .
Ah, got the overlay working too, needs that replace in explicit_layer.d too. !
Change:
"-DTDESKTOP_API_TEST=ON" "-DDESKTOP_APP_USE_PACKAGED_RLOTTIE=OFF" "-DDESKTOP_APP_USE_PACKAGED_VARIANT=OFF" <ins> "-DDESKTOP_APP_USE_PACKAGED_GSL=OFF" </ins> "-DTDESKTOP_DISABLE_REGISTER_CUSTOM_SCHEME=ON" "-DTDESKTOP_USE_PACKAGED_TGVOIP=OFF" #"-DDESKTOP_APP_SPECIAL_TARGET=""" # TODO: Error when set to "": Bad special target '""'

Discussion:
, CVSSv3=7.8 (nixos-20.03) Scanned versions: nixos-20.03: . Cc Cc
Change:
<ins> { stdenv, lib, fetchFromGitHub, kernel }: let modDestDir = "$out/lib/modules/${kernel.modDirVersion}/kernel/drivers/net/wireless/realtek/rtw89"; in stdenv.mkDerivation { pname = "rtw89"; version = "unstable-2021-07-03"; src = fetchFromGitHub { owner = "lwfinger"; repo = "rtw89"; rev = "cebafc6dc839e66c725b92c0fabf131bc908f607"; sha256 = "1vw67a423gajpzd5d51bxnja1qpppx9x5ii2vcfkj6cbnqwr83af"; }; makeFlags = [ "KSRC=${kernel.dev}/lib/modules/${kernel.modDirVersion}/build" ]; enableParallelBuilding = true; installPhase = '' runHook preInstall mkdir -p ${modDestDir} find . -name '*.ko' -exec cp --parents {} ${modDestDir} ; find ${modDestDir} -name '*.ko' -exec xz -f {} ; runHook postInstall ''; meta = with lib; { description = " Driver for Realtek 8852AE, an 802.11ax device"; homepage = "https://github.com/lwfinger/rtw89"; license = with licenses; [ gpl2Only ]; maintainers = with maintainers; [ tvorog ]; platforms = platforms.linux; broken = kernel.kernelOlder "5.4"; priority = -1; }; } </ins>

Discussion:
Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux
Change:
cdpr = callPackage ../tools/networking/cdpr { }; <del> cdrdao = callPackage ../tools/cd-dvd/cdrdao { }; </del> <ins> cdrdao = callPackage ../tools/cd-dvd/cdrdao { inherit (darwin.apple_sdk.frameworks) CoreServices IOKit; }; </ins> cdrkit = callPackage ../tools/cd-dvd/cdrkit { };

Discussion:
Ripped CD The original issue: The fix linked in the issue: So the fix seems to be either downgrade to 1.2.4 or apply the patch listed in the arch repo. Please run and paste the result.
It's hard to imagine how this specific error could be related to an encoding issue... both of your links point to the same place, do you have a link to the fix you're talking about?
Ah, I found the one used in the Arch package. I'm not presently able to test the fix myself, however; if I give you an amended Nixpkgs branch and instructions to try it, would you be able to see if it works correctly?
I applied the downgrade and it works. If you can give me the patch I can test it as well.
Thanks; please try (patch: ). Sadly it seems like neither cdrdao nor whipper get very much upstream maintainer attention these days...
Gave it a try with the following in my home-manager config: I was able to successfully rip a CD so the patch seems to be effective. :partying_face:
Thanks for testing; opened
Change:
lobster-two = google-fonts; # Added 2021-07-22 luxcorerender = throw "'luxcorerender' has been removed as it's unmaintained and broken in nixpkgs since a while ago"; # Added 2023-06-07 <ins> lv_img_conv = throw "'lv_img_conv' has been removed from nixpkgs as it is broken"; # Added 2024-06-18 </ins> lxd = lib.warn "lxd has been renamed to lxd-lts" lxd-lts; # Added 2024-04-01 lxd-unwrapped = lib.warn "lxd-unwrapped has been renamed to lxd-unwrapped-lts" lxd-unwrapped-lts; # Added 2024-04-01 lzma = xz; # moved from top-level 2021-03-14

Discussion:
Steps to reproduce the behavior: w/ channel check hydra: 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. -- ping :) Please run and paste the result.
Do you need this package? The original reason I it was to support building . Recently, that project has deprecated and instead uses their own tooling ( , "Replace the tool that convert the images (lvimgconv) by a custom re-implementation in Python"), so my use-case for this package has disappeared. I don't know what is causing this issue, I tried rebuilding the package with the most recent changes from its repo, but no success. I propose to mark this package as broken or remove it.
fascinating, you're right. I was using it to build infinitime too and have that working now by adding to my devShell's python environemnt. might just want to mark it as broken and move along then. cheers
Change:
mesonFlags = [ "--cross-file" "cross-wine.conf" <ins> "-Dwith-bitbridge=true" </ins> # Requires CMake and is unnecessary "-Dtomlplusplus:GENERATE_CMAKE_CONFIG=disabled"

Discussion:
The current version of doesn't build support for the bitbridge that allows for running 32 bit VST plugins. Information on building that is on the . Basically, what's necessary is to make sure that the 32 bit versions of and are installed, and adding a meson flag. It didn't end up being that simple when I tried adding it myself by just adding the 32 bit dependencies to buildInputs and the meson flag; I got a vague error about meson being unable to find boost_filesystem. paging the maintainer of the package:
Attached are my modifications to the current yabridge definition. It is very hacky, but it seems to build... all up until it gets to the part where it links stuff. There, ld fails (see attached error log).
I spent a lot of time trying to get this to work, but I couldn't find any way to specify both the 32bit and 64bit version of boost in a build because of There probably is a hacky way to work around it, but I couldn't find how. I decided to give up on it until is fixed, but I would be happy to accept a workaround if you find one.
It looks like that linking error is the same problem I was running into. The build would only ever pick up either the 32bit boost or the 64bit one, but not both. I couldn't find a way to specify the right one per-architecture. I also thought of trying to combine the 32bit & 64bit builds after building them separately, but the project fails to compile as 32bit, because it makes the assumption that the default build will be 64bit.
Hmm. An idea i haven't tried yet is trying to patch one of the release binaries. Might be a little easier than trying to wrangle meson, at least until that issue gets fixed.
Complete crackpot idea; since the 32 bit stuff that gets built are just binaries that yabridgectl looks for in $PATH (i think), maybe it's possible to just take them from the prebuilt binaries and patch them? I'll try this when i get the chance.

EDIT: this idea was as terrible as it sounds, and the prebuilt binaries only worked through steam-run (presumably because they were compiled with hardcoded FHS paths)
Sorry to leave so many comments in a row, but I got it working and pretty much no ugly hacks too. I'll just paste my definition verbatim. Pretty much all i did was replace with (unsure if necessary, probably is), add the bitbridge flag, and replace all references to with (this was the reason for the linking issues at the end). Then i just a wildcard to the installPhase to get the 32 bit stuff in $out/bin. There are a few lines where I don't know if they're actually necessary; once it worked i stopped testing. I'm also unsure of how to handle referring to pkgsi686Linux, or if there's even a better/more specific way rather than just including pkgsi686Linux as an input. EDIT: I can also open a PR tomorrow if these changes look fine.
Change:
rardiol = "Ricardo Ardissone <ricardo.ardissone@gmail.com>"; rasendubi = "Alexey Shmalko <rasen.dubi@gmail.com>"; raskin = "Michael Raskin <7c6f434c@mail.ru>"; <ins> rbasso = "Rafael Basso <rbasso@sharpgeeks.net>"; </ins> redbaron = "Maxim Ivanov <ivanov.maxim@gmail.com>"; redvers = "Redvers Davies <red@infect.me>"; refnil = "Martin Lavoie <broemartino@gmail.com>";

Discussion:
Hello, I wanted to install exercism and thought that I should first look if there is not a Nix package for it. I did not find it with nor with but I found traces that there existed such a package (first as a binary, then as a goPackage) by searching this repository. Was support for this package dropped? If so, was it dropped voluntarily? I did not find any trace of a discussion on dropping it but maybe it happened somewhere anyway. If the package is still there, somehow, what should I have done to find it? Thanks! PS: tagging since he was listed as maintainer of the original binary package.
I think, it go removed by this pull request: You can restore this package, if you want.
Indeed! For some reason it did not appear in and thus was forgotten from this pull request. Not being a Go developer myself, I'm not sure how I could restore it properly.
cc
It looks like it wasn't exposed to before and that's why it was removed. I can get it back and expose it as top level package if you want.
FWIW, I used to refer to lots of (just like I do with and so on; would you delete most of those too?) so exposing at the top level doesn't really feel like the right criterion.
The distinction between this particular package and most or is that this is providing an executable and not a library. It is a final-user package, not a development package. It was probably a mistake from the beginning not to expose it in . Now, it is true that lots of packages providing executable utilities for developers (and not libraries) are hidden inside such attribute sets as well. Drawing an example from what I know, is in such case. as well, but at least if I type the response tells me what its location is. Whereas, if I type the response is unhelpful. But at least I can find it with Whereas in the case of the Emacs mode Proof-General, I don't even find it there or with . I do not understand these distinctions. But I know that I have digressed.

Coming back to the original problem, if you restore the package, note that the latest version is now v2.3:
I'm not a Go programmer and I'm still trying to understand Nix and Nixpkgs, but I would like to pack because it is too boring to compile and install it manually. I would love some directions here... seems to work, but I don't know if this is the proper way to do it. Is it right? Suggestions? way it is, the package name comes out as instead of . Is this name structure also used for executables or just for libraries? install it, I have to type . Is it possible to make it work with ?
's ok, add some meta to it like (+ 3) There's no difference for libs/exec in now and I think that it could be a good move to change it to like that won't prefix app name.
Change:
keycloakConfig = lib.generators.toKeyValue { mkKeyValue = lib.flip lib.generators.mkKeyValueDefault "=" { <del> mkValueString = v: with builtins; </del> <ins> mkValueString = v: </ins> if isInt v then toString v else if isString v then v else if true == v then "true"

Discussion:
Keycloak offers the option to configure either the or configuration setting. The current keycloak module doesn't support the option due to the way the config file is generated. Steps to reproduce the behavior: a keycloak service with only and not . a system with this service and get Be able to configure either or as a setting. (maintainer of keycloak module: ) Please run and paste the result.
should resolve this. Please try it out.
Thank you for the quick handling of the issue I'll try to do it at work the day after tomorrow
Has been tested and works.
Change:
<ins> { fetchFromGitLab , hyprland , wlroots , xwayland , fetchpatch , lib , libdisplay-info , libliftoff , hwdata , hidpiXWayland ? true , enableXWayland ? true , nvidiaPatches ? false }: let libdisplay-info-new = libdisplay-info.overrideAttrs (old: { version = "0.1.1+date=2023-03-02"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "emersion"; repo = old.pname; rev = "147d6611a64a6ab04611b923e30efacaca6fc678"; sha256 = "sha256-/q79o13Zvu7x02SBGu0W5yQznQ+p7ltZ9L6cMW5t/o4="; }; }); libliftoff-new = libliftoff.overrideAttrs (old: { version = "0.5.0-dev"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "emersion"; repo = old.pname; rev = "d98ae243280074b0ba44bff92215ae8d785658c0"; sha256 = "sha256-DjwlS8rXE7srs7A8+tHqXyUsFGtucYSeq6X0T/pVOc8="; }; NIX_CFLAGS_COMPILE = toString [ "-Wno-error=sign-conversion" ]; }); in assert (lib.assertMsg (hidpiXWayland -> enableXWayland) '' wlroots-hyprland: cannot have hidpiXWayland when enableXWayland is false. ''); (wlroots.overrideAttrs (old: { version = "0.17.0-dev"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "wlroots"; repo = "wlroots"; rev = "5ae17de23f5fd9bb252a698f3771c840280e2c05"; hash = "sha256-dWrk+Q3bLdtFe5rkyaAKWCQJCeE/KFNllcu1DvBC38c="; }; pname = old.pname + "-hyprland" + ( if hidpiXWayland then "-hidpi" else "" ) + ( if nvidiaPatches then "-nvidia" else "" ); patches = (old.patches or [ ]) ++ (lib.optionals (enableXWayland && hidpiXWayland) [ "${hyprland.src}/nix/wlroots-hidpi.patch" (fetchpatch { url = "https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/18595000f3a21502fd60bf213122859cc348f9af.diff"; sha256 = "sha256-jvfkAMh3gzkfuoRhB4E9T5X1Hu62wgUjj4tZkJm0mrI="; revert = true; }) ]) ++ (lib.optionals nvidiaPatches [ (fetchpatch { url = "https://aur.archlinux.org/cgit/aur.git/plain/nvidia.patch?h=hyprland-nvidia-git&id=757614af7729352fda534abe9eb1a88fe77dfe04"; sha256 = "A9f1p5EW++mGCaNq8w7ZJfeWmvTfUm4iO+1KDcnqYX8="; }) ]); postPatch = (old.postPatch or "") + ( if nvidiaPatches then '' substituteInPlace render/gles2/renderer.c --replace "glFlush();" "glFinish();" '' else "" ); buildInputs = old.buildInputs ++ [ hwdata libdisplay-info-new libliftoff-new ]; })).override { xwayland = xwayland.overrideAttrs (old: { patches = (old.patches or [ ]) ++ (lib.optionals hidpiXWayland [ "${hyprland.src}/nix/xwayland-vsync.patch" "${hyprland.src}/nix/xwayland-hidpi.patch" ]); }); } </ins>

Discussion:
Project description A wlroots-compatible Wayland color picker that does not suck. Metadata homepage URL: source URL: license: platforms: linux Just because you made available on NixOS, I wanted to point you on hyprpicker, too - if you're interested to have a look into this(?)
I'll take a look into packaging this.
Change:
src = ./fix-rpath.patch; inherit (builtins) storeDir; }) <ins> # Fix detecting incorrect compiler in the store path hash. # https://github.com/NixOS/nixpkgs/issues/73417#issuecomment-554077964 # https://github.com/mesonbuild/meson/pull/6185 (fetchpatch { url = "https://github.com/mesonbuild/meson/commit/972ede1d14fdf17fe5bb8fb99be220f9395c2392.patch"; sha256 = "19bfsylhpy0b2xv3ks8ac9x3q6vvvyj1wjcy971v9d5f1455xhbb"; }) </ins> ] ++ lib.optionals stdenv.isDarwin [ # We use custom Clang, which makes Meson think *not Apple*, while still # relying on system linker. When it detects standard Clang, Meson will

Discussion:
Describe the bug The channel is currently blocked on the i686-linux minimal ISO not building. It's both failing at and Both of these packages use the meson build system and produce a similar output on failure cc It's another topic entirely if i686-linux should be able to block channels. In my opinion, it's not at the same tier of support to be able to have a channel blocking job like this.
Re channel dependency:
Git bisect said this was at fault ??
I got , damn the merge commits. Neither seems particularly suspect. Edit: I was using wrong bad tag, now I get the same.
That is just weird. On () I see the following in logs: Comparing the two does not show anything suspicious: /nix/store/d915ffl08q1yckm2laqwvjj55ykjq6vd-gcc-wrapper-8.3.0/bin/cc /nix/store/38rh09iclvs97fisbgy8fg6wxr33ijr1-gcc-wrapper-8.3.0/bin/cc
Applying the following to Meson revealed The error pointed me to  method and the empty argument to: The hash contains so it matches some obscure compiler!
Ewwwww :rofl: This is actually rather funny. I can assume what the folllow-up PR to this will be doing to meson...
Change:
}); passthru = rec { <ins> spirv-llvm-translator = llvmPkgs.spirv-llvm-translator; llvm = addPatches "llvm" llvmPkgs.llvm; </ins> libclang = addPatches "clang" llvmPkgs.libclang; clang-unwrapped = libclang.out;

Discussion:
, current version: 20.34. desired version: 21.42. maintainers: The packages version is quite old and doesn't work properly on 11th gen cpus. There are also other PR which are interwoven with this such as: And also an issue that might be related To update this properly I think we need to update at least the following packages: , , and .
Change:
inotify-tools = callPackage ../development/tools/misc/inotify-tools { }; <ins> inherit (callPackage ../applications/misc/inochi2d { }) inochi-creator inochi-session; </ins> intel-gpu-tools = callPackage ../development/tools/misc/intel-gpu-tools { }; insomnia = callPackage ../development/web/insomnia { };

Discussion:
Project description Open Source Real-time 2D Animation inochi-creator, inochi-session should be packaged as separated packages. There was some debate about Inochi2D in initiated by its author. If you want to package it, read the mentioned issue first. It seems that the debate was settled: the author agrees that nixpkgs can package Inoshi2D under complying their demands. However, no PR packaging Inochi2D was opened after that, so I am opening this issue. Metadata homepage URL: source URL: , license: bsd 2-clause (not including proprietary assets) platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
}; environment.systemPackages = [ nvidia_x11.bin ]; <del> hardware.nvidia.open = lib.mkDefault (lib.versionAtLeast nvidia_x11.version "560"); </del> <ins> hardware.nvidia.open = lib.mkIf (lib.versionOlder nvidia_x11.version "560") (lib.mkDefault false); hardware.nvidia.gsp.enable = lib.mkDefault (cfg.open || lib.versionAtLeast nvidia_x11.version "555"); </ins> }) # X11

Discussion:
The RPATH of , as installed by the standard nvidia package () in nixos 23.11, has no entry for , causing it to fail if anyone actually used that particular interface. Steps to reproduce the behavior: The nvidia package should set proper RPATHs on the installed libraries. I ran into this because I was trying to clean up the steam package of issues, and steam's does a lot of sanity checking of its environment and reported the issue from inside the FHS environment. <!-- 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]:
That library is an internal compatibility layer for openssl1.1. Since we link openssl3 into the nvidia driver it never gets used and is meant to fail to load. Since NixOS makes sure that openssl3 is always available this library is functionally useless. We could probably just remove that file (like we do with ) to regain some disk space and satisfy the checks you mentioned.
Sounds good. Better to not ship it than ship it broken, especially if nobody needs it.
Change:
<del> { lib , pkgs , callPackage }: rec { libtorrent = callPackage ./libtorrent.nix { }; rtorrent = callPackage ./rtorrent.nix { }; } </del>

Discussion:
jesec-libtorrent tests fail, making the build fail. Steps to reproduce the behavior: jesec-libtorrent fails, failing the build I expect it to build succesfully ! ! I'm building the package with the help of morph to deploy on a server, though this shouldn't really have an impact.
This happened between and . I'll bisect later, thanks for the heads up!
The test is expecting to be returned by , but is instead getting . I'm... really not sure how to move forward with this, short of disabling the test.
Next time copy-paste the error message.
Perhaps triggered by upgrading glibc from 2.33 to 2.34? (some change in getaddrinfo() behavior)
I ruled that out initially since I didn't see anything mentioned in the changelog about getaddrinfo. I'll give it a try, though.
This has been fixed by .