jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib , python3 , xorg , argyllcms , wrapGAppsHook , gtk3 , librsvg }: python3.pkgs.buildPythonApplication rec { pname = "displaycal"; version = "3.9.10"; format = "setuptools"; src = python3.pkgs.fetchPypi { pname = "DisplayCAL"; inherit version; hash = "sha256-oDHDVb0zuAC49yPfmNe7xuFKaA1BRZGr75XwsLqugHs="; }; nativeBuildInputs = [ wrapGAppsHook gtk3 ]; propagatedBuildInputs = with python3.pkgs; [ build certifi wxPython_4_2 dbus-python distro PyChromecast send2trash ]; buildInputs = [ gtk3 librsvg ] ++ (with xorg; [ libX11 libXxf86vm libXext libXinerama libXrandr ]); doCheck = false; # Tests try to access an X11 session and dbus in weird locations. pythonImportsCheck = [ "DisplayCAL" ]; dontWrapGApps = true; preFixup = '' makeWrapperArgs+=( ''${gappsWrapperArgs[@]} --prefix PATH : ${lib.makeBinPath [ argyllcms ]} --prefix PYTHONPATH : $PYTHONPATH ) ''; meta = with lib; { description = "Display calibration and characterization powered by Argyll CMS (Migrated to Python 3)"; homepage = "https://github.com/eoyilmaz/displaycal-py3"; license = licenses.gpl3Plus; platforms = platforms.linux; maintainers = with maintainers; [ toastal ]; }; } </ins>

Discussion:
Project description . A few months back the project was removed because Python 2 was removed, and the Pillow lib was insecure too. This project is a revival of the project but under Python 3. In fact they have stated: "Everything should be working now". DisplayCAL is a tool for many color-related tasks; from the docs: Calibration + Characterization (Profiling). Installing the created ICC profile both locally and system-wide (requires root permissions). Profile Info window is now fully working (on some systems we still have an issue related to default values ). Measurement report creation. Creating, displaying and uploading Colorimeter Corrections. Measuring and reporting display uniformity. Creating charts with Test Chart Editor and creating diagnostic 3d data. Creating 3D LUTs. Creating synthetic ICC profiles. Metadata homepage URL: source URL: license: GPL 3.0 platforms: unsure, but at least Linux
Change:
{ stdenv, lib, fetchFromGitHub, cmake, pkg-config, makeWrapper, freetype, SDL2 , glib, pcre2, openal, rtmidi, fluidsynth, jack2, alsa-lib, qt5, libvncserver <del> , discord-gamesdk, libpcap </del> <ins> , discord-gamesdk, libpcap, libslirp </ins> , enableDynarec ? with stdenv.hostPlatform; isx86 || isAarch , enableNewDynarec ? enableDynarec && stdenv.hostPlatform.isAarch

Discussion:
Package name: _86Box Latest released version: 4.0 <!-- Search your package here: --- Current version on the unstable channel: 3.11 Current version on the stable/release channel: 3.11 <!-- 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.
I'm a bit busy but I'll try to get back to this on the weekend. I want to check the build system and deps to make sure there's nothing I should be updating there beyond swapping the version numbers, it looks like a decently large changelog.
Change:
simplenote = callPackage ../applications/misc/simplenote { }; <del> hy = callPackage ../development/interpreters/hy {}; </del> <ins> hy = python3Packages.hy.withPackages (python-packages: [ ]); </ins> wmic-bin = callPackage ../servers/monitoring/plugins/wmic-bin.nix { };

Discussion:
The one in is more up-to-date (1.0a3 vs 1.0a1, current version is 1.0a4 though), . The second one is the oldest though. Not sure what is the best solution here. It doesn't seem to make much sense to have Hy being considered a interpreter instead of a Python package (it even has attribute that AFAIK isn't any different from simply from using with and other dependencies as ). But I don't have sufficient context here. We probably need to merge one in another and delete the other derivation. Steps to reproduce the behavior: We should only have one Hy package. N/A N/A <!-- 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.
Created a PR removing and keeping , while also making has the same parameter for backwards compatibility:
Change:
buildGoModule rec { pname = "pulumi"; <del> version = "3.99.0"; </del> <ins> version = "3.122.0"; </ins> src = fetchFromGitHub { owner = pname;

Discussion:
Pulumi does some path comparison to ensure that its language plugin binaries 'match' its main cli -- essentially that they're installed in the same place. The package packages the languages separately and thus, the path comparison fails and pulumi spits out warnings: Pulumi bug with some extra discussion: I'm a n00b on nix packaging, but would be be possible to have a single package with options to enable the plugins of your choosing? Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same question here. I've been sort of sitting on this particular problem as a good possible gateway into killing a lot of time to understand nix on a lower level. I tried all of the low hanging fruit ideas like and a handful of other things, most of them worked but the warning never went away. If nobody chimes in, maybe we can figure it out in the long term between us.. It's sort of a noob thing that most people won't have the time to educate on, which is fair enough.
I don't think there should be anything to do on Nixpkgs side. The only "fix" I can think of is to put all the binaries into a single nixpkgs package (like what package is). I don't like this approach though, as nixpkgs is designed around separation, and most of the time a user only needs binary with a single language engine binary. I'd argue that requiring all the binaries to be in the same directory is a bad packaging decision. The warning is rather harmless, in my opinion, so can we all just ignore it? The linked issue also suggests that upstream is fine with a compromise on their end and is open to a community PR.
includes a binary, which seems to make the warnings go away when I test it. If we get the plugins packaged separately in the future, we'll have this problem again, but in the meantime it seems like there's a solution by just using the in instead of . EDIT: No, actually, for some reason that doesn't work when I try to preview a stack: I am not sure what the difference is.
Change:
buildDotnetModule rec { pname = "ryujinx"; <del> version = "1.1.733"; # Based off of the official github actions builds: https://github.com/Ryujinx/Ryujinx/actions/workflows/release.yml </del> <ins> version = "1.1.819"; # Based off of the official github actions builds: https://github.com/Ryujinx/Ryujinx/actions/workflows/release.yml </ins> src = fetchFromGitHub { owner = "Ryujinx"; repo = "Ryujinx"; <del> rev = "9f12e50a546b15533778ed0d8290202af91c10a2"; sha256 = "1d1hg2sv0h56a56xnarcfp73df3rbw3iax85g258l6w2kxhkc42a"; </del> <ins> rev = "4ca78eded52f21089400cc28351b9353279b8171"; sha256 = "13g5sgql14rr7qmsiavm6kkjkv9sqqq7cmwpy9iiahbfzc9w1wc1"; </ins> }; dotnet-sdk = dotnetCorePackages.sdk_7_0;

Discussion:
Package name: ryujinx Latest released version: 1.1.747 <!-- Search your package here: --- Current version on the unstable channel: 1.1.743 Current version on the stable/release channel: 1.1.327 Notify maintainers Note for maintainers: Please tag this issue in your PR. Finally, for anyone who stumbles upon this issues, and wants an overlay to get them to 1.1.747 without waiting for the package to be updated:
An update to this package will require updating using the script (a process I'm unfamiliar with) and changing the testProjectFile attribute because all of the source was moved into the src/ directory. Other than that and updating the source, no other changes to the derivation should be necessary
Updating a package with an update script (if it's written correctly) should be as simple as: Thanks for detailing the testProjectFile change, that's super helpful. I'm in the process of updating now.
Change:
}; declarativeContents."dc=example" = dbContents; }; <ins> users.ldap = ldapClientConfig; </ins> }; }) { inherit pkgs system; };

Discussion:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.
Change:
peaqevcore = callPackage ../development/python-modules/peaqevcore { }; <ins> pegen = callPackage ../development/python-modules/pegen { }; </ins> pebble = callPackage ../development/python-modules/pebble { }; pecan = callPackage ../development/python-modules/pecan { };

Discussion:
Steps to reproduce the behavior: `nix-build '<nixpkgs' -A Fails since /cc
Change:
libwebp libheif python <del> pygtk </del> libexif xorg.libXpm glib-networking

Discussion:
Describe the bug GIMP uses Python and GTK+ for e.g. plugins. But GIMP in the NixOS-GIMP-package cannot find the Python-gtk-module: GIMP itself starts, but e.g. some plugins cannot be used, e.g. . When selecting this plugin, nothing happens, and the following error is shown in the console (again): To Reproduce Steps to reproduce the behavior: GIMP. GIMP. at the error-messages. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can confirm this still doesn't work. Of note is that installing will allow when used from the REPL, but GIMP will still not recognize it. Tagging since they are tagged as the maintainer.

I see the following warnings when running gimp: Not sure if they are critical or not. I do have problems with one Python plugin, not sure if this could be related. Run gimp from the terminal. I'm running it from i3+none desktop environment, if that matters. Please run and paste the results.
I can see the warning too. This is what the file looks like on Arch: nothing special compared to ours: The file exists and is executable Not really sure what is wrong. Also the Python scripts seem to work, at least does.
For me, resynthesizer runs but it doesn't produce correct results:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me. This is the current console output:
I have found this issue can be fixed by installing the python package by yourself (which is weird: it looks like GIMP may be trying to use the command from your ). I have it in my systemPackages and I got past that stage. However, is still blocking the usage of some plugins.
Spent some time in and it looks like the extension mapping from file only searches in path, not in the mapping described on previous lines and registered in : : The extension is so some other mechanism than extension matching must be involved – perhaps shebangs are applied. We will still want to hardcode the path to ensure purity.
Change:
cargo-wasi = callPackage ../development/tools/rust/cargo-wasi { inherit (darwin.apple_sdk.frameworks) Security; }; <del> cargo-watch = darwin.apple_sdk_11_0.callPackage ../development/tools/rust/cargo-watch { inherit (darwin.apple_sdk_11_0.frameworks) Cocoa CoreServices Foundation; </del> <ins> cargo-watch = callPackage ../development/tools/rust/cargo-watch { inherit (darwin.apple_sdk.frameworks) Foundation Cocoa; </ins> }; cargo-wipe = callPackage ../development/tools/rust/cargo-wipe { }; cargo-workspaces = callPackage ../development/tools/rust/cargo-workspaces { };

Discussion:
Steps to reproduce the behavior: cargo-watch on x86-64-darwin Sounds similar to this issue: Though I have a hard time seeing any dependency that would be built with a different version of the framework in its closure. <!-- 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. My system is showing as "aarch64-darwin", but I'm building with Rosetta. Hydra reports the same issue: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ config = mkIf (any (fs: fs == "exfat") config.boot.supportedFilesystems) { <del> system.fsPackages = [ pkgs.exfat ]; </del> <ins> system.fsPackages = if config.boot.kernelPackages.kernelOlder "5.7" then [ pkgs.exfat # FUSE ] else [ pkgs.exfatprogs # non-FUSE ]; </ins> }; }

Discussion:
Describe the bug On kernels newer than 5.8 exfat is natively supported by the kernel. However, if is used, nix will pull in exfat package and will use the fuse driver. This can be bypassed by not using the type and mounting by hand (there is no link for , but works still). To Reproduce Steps to reproduce the behavior: an exfat volume it to the attribute, e.g. that filesystem type is using . Expected behavior Using native kernel module for mounting exfat filesystems when kernel version is newer than 5.8. Additional context A check alike this already exists for the package () It seems that the check in could be responsible for this. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
should be for proper userspace to go with the new in kernel driver
Just got bitten by this on . Both FUSE and native can coexist, but if (from the package) is in the path, the utility will prefer it unless called with the flag (even with ). As there's no way to disable the utility from being built from current exfat, I suggest we switch to (I can submit a PR to package this) for applicable kernels.
Can confirm this behavior, having exfatprogs with newer kernels is definitely recommended.
Change:
addEnvHooks "$targetOffset" gatherLibraries isExecutable() { <del> [ "$(file -b -N --mime-type "$1")" = application/x-executable ] } findElfs() { find "$1" -type f -exec "$SHELL" -c ' while [ -n "$1" ]; do mimeType="$(file -b -N --mime-type "$1")" if [ "$mimeType" = application/x-executable  -o "$mimeType" = application/x-pie-executable  -o "$mimeType" = application/x-sharedlib ]; then echo "$1" fi shift done ' -- {} + </del> <ins> # For dynamically linked ELF files it would be enough to check just for the # INTERP section. However, we won't catch statically linked executables as # they only have an ELF type of EXEC but no INTERP. # # So what we do here is just check whether *either* the ELF type is EXEC # *or* there is an INTERP section. This also catches position-independent # executables, as they typically have an INTERP section but their ELF type # is DYN. LANG=C readelf -h -l "$1" 2> /dev/null  | grep -q '^ *Type: *EXEC>|^ *INTERP>' </ins> } # We cache dependencies so that we don't need to search through all of them on

Discussion:
determines which executables it should patch via: However, PIEs have a type of , as in: Questions: Should also patch PIEs? An alternative is to just call manually, but I'm having trouble finding out how to run it in the correct phase. Is there even a reliable way to distinguish between shared libraries and PIEs? I know in general, shared libs don't have an section, but is this a reliable enough assumption? cc
Actually, executables can also be shared libraries at the same time (eg. and I'm doing exactly that in my as well), so the only thing that distinguishes them is an section (except if statically linked of course). So I guess it's a better idea to just look for in instead of what we currently do. At least if I don't miss something, this should be the most reliable way, after all what we want to do with executables is to patch the section. If nobody else sends a PR in the meantime, I'm going to fix this next week. As for it's a bit more difficult, because it needs to be run after the normal hook, so it might be necessary to add .
Change:
rm scipy/linalg/tests/test_lapack.py ''; <del> doCheck = true; </del> <ins> doCheck = !(stdenv.isx86_64 && stdenv.isDarwin); </ins> preConfigure = '' sed -i '0,/from numpy.distutils.core/s//import setuptools;from numpy.distutils.core/' setup.py

Discussion:
scipy doesn't build on Darwin right now (trunk). Hydra: The error in Hydra seems to be some builder failure and not actually related to the issue. It however fails as well when I try to build on my Mac. We should get rid of both issues. Steps to reproduce the behavior: to build It builds I don't need this Python module myself but a lot of other packages depend on it. This is currently the package with the most dependants (322) that fails so it'd be nice to have this cleaned up before ZHF starts. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The too many open files sounds like it could be related to the very low default limit on open files on macOS. For me it defaults to 256, I think more recent versions have increased the limit but it's still lower than for Linux and the tests were probably written with that in mind.
scipy builds for me on both x86_64-darwin and aarch64-darwin. $ nix-info -m system: host os: multi-user?: sandbox: version: channels(reckenrode): channels(root): nixpkgs:
what does report for you?
Ok, then my hypothesis is debunked.
Could this be due to the file descriptor leak bug in nix ? This would explain why it fails to build for some users but not for others. I believe the bug was fixed in nix 2.8.
scipy seems to be build for me on , can anyone else confirm? Looks like it's still failing on .
can we just disable the tests on for now? as a note (or whatever) can bump the open file limit but you might then run into memory limits like I've experienced in
I'm going to disable tests on so we can work on other issues for ZHF. If anyone wants to debug specific failures in scipy please reply to this issue. It currently causes hundreds of other packages to transitively fail.
Wonder if reducing parallelism would help.
Change:
xterm = handleTest ./xterm.nix {}; xxh = handleTest ./xxh.nix {}; yabar = handleTest ./yabar.nix {}; <ins> ydotool = handleTest ./ydotool.nix {}; </ins> yggdrasil = handleTest ./yggdrasil.nix {}; zammad = handleTest ./zammad.nix {}; zeronet-conservancy = handleTest ./zeronet-conservancy.nix {};

Discussion:
requires to be running in order to be used otherwise it aborts and crashes (see ). It would make sense to have a NixOS configuration option in order to automatically configure to run. Some NixOS module option (perhaps ) that automatically configures and runs as a systemd service in the background.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
tut = callPackage ../applications/misc/tut { }; <ins> tuxclocker = libsForQt5.callPackage ../applications/misc/tuxclocker { tuxclocker-plugins = tuxclocker-plugins-with-unfree; }; tuxclocker-without-unfree = libsForQt5.callPackage ../applications/misc/tuxclocker { }; </ins> tuxedo-rs = callPackage ../os-specific/linux/tuxedo-rs { }; tuxguitar = callPackage ../applications/editors/music/tuxguitar {

Discussion:
Project description TuxClocker is a hardware controlling and monitoring program. TuxClocker consists of a DBus daemon and a Qt GUI that uses the daemon. It allows you to e.g. set a custom fan curve and overclock your CPU and GPU. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Change:
path=${prefetch[1]} echo "vivaldi: $vivaldi_version_old -> $vivaldi_version" <ins> echo "$path" </ins> (cd "$root" && update-source-version vivaldi "$vivaldi_version" "$hash") # Check vivaldi-ffmpeg-codecs version. chromium_version_old=$(version vivaldi-ffmpeg-codecs) <del> chromium_version=$(bsdtar xOf "$path" data.tar.xz | bsdtar xOf - ./opt/vivaldi/vivaldi-bin | strings | grep -A2 -i '^chrome/' | grep '^[0-9]+.[0-9]+.[1-9][0-9]+.[0-9]+') </del> <ins> chromium_version=$(bsdtar xOf "$path" data.tar.xz | bsdtar xOf - ./opt/vivaldi/vivaldi-bin | strings | grep '^[0-9]{2,}.[0-9]+.[0-9]{4,}+.[0-9]+$') </ins> if [[ "$chromium_version" != "$chromium_version_old" ]]; then echo "vivaldi-ffmpeg-codecs: $chromium_version_old -> $chromium_version"

Discussion:
I try to install vivaldi-ffmpeg-codecs, it tries to build it — Just try to install vivaldi-ffmpeg-codecs. there was the same thing in previous 18.03.
I found that was removed in . Here it is in the : And the helpful thread:
I tried bluntly update the chromium source where codecs stored. But it failed:
That patch is marked .
Let's call submitter:
I tried bluntly update the chromium source where codecs stored. This is the right approach, but you'll also have to remove the old patches and check whether you need any newer . The patches used by the are usually a good starting point.
So unless I'm mistaken, shouldn't we just build chromium & provide a vivaldi output? The chromium build is huge & we don't want Hydra to have to do it multiple times. What's the intended use of ffmpeg-vivaldi-codecs? I think we can disable libcxx building with in args, though.
As i can see, there are some license issues (?) with something like h264. So we build in on "client" side from sources (probably it's x264)... I don't know exactly...
Providing a Vivaldi output from chromium (as suggests) is difficult because chromium moves at a different speed than Vivaldi, so the resulting library may not fit properly. I don't know how often this happens, but it looks like upstream ffmpeg changes their ABI fairly often. The build actually isn't that much of an issue. The only difficulty is having to download and extract the full chromium tarball, the compile times are short as we only need . What's the intended use of ffmpeg-vivaldi-codecs? Vivaldi (the company) cannot distribute certain codecs in ffmpeg in their packages, so we have to compile that separately.