jiebi/CodeConvo huggingface dataset:
Code change:
Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…

Related discussion:
text: + optionalString isClang '' # Escape twice: once for this script, once for the one it gets substituted into. export march=${escapeShellArg <del> (optionalString (targetPlatform ? gcc.arch && !disableMarch) </del> <ins> (optionalString (targetPlatform ? gcc.arch) </ins> (escapeShellArg "-march=${targetPlatform.gcc.arch}"))} export defaultTarget=${targetPlatform.config} substituteAll ${./add-clang-cc-cflags-before.sh} $out/nix-support/add-local-cc-cflags-before.sh
Code change:
Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…

Related discussion:
text: # # The following selects the correct Clang version, matching the version # used in Swift, and applies the same libc overrides as `apple_sdk.stdenv`. <del> clang = let # https://github.com/NixOS/nixpkgs/issues/295322 clangNoMarch = swiftLlvmPackages.clang.override { disableMarch = true; }; in if pkgs.stdenv.isDarwin </del> <ins> clang = if pkgs.stdenv.isDarwin </ins> then <del> clangNoMarch.override rec { </del> <ins> swiftLlvmPackages.clang.override rec { </ins> libc = apple_sdk.Libsystem; bintools = pkgs.bintools.override { inherit libc; }; # Ensure that Swift’s internal clang uses the same libc++ and libc++abi as the
Code change:
Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…

Related discussion:
text: inherit (llvmPackages) libcxx; } else <del> clangNoMarch; </del> <ins> swiftLlvmPackages.clang; </ins> # Overrides that create a useful environment for swift packages, allowing # packaging with `swiftPackages.callPackage`. These are similar to
Code change:
Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…

Related discussion:
text: source $cc_wrapper/nix-support/add-local-cc-cflags-before.sh fi <del> # May need to transform the triple injected by the above. for ((i = 1; i < ${#extraBefore[@]}; i++)); do if [[ "${extraBefore[i]}" = -target ]]; then </del> <ins> for ((i=0; i < ${#extraBefore[@]}; i++));do case "${extraBefore[i]}" in -target) </ins> i=$((i + 1)) # On Darwin only, need to change 'aarch64' to 'arm64'. extraBefore[i]="${extraBefore[i]/aarch64-apple-/arm64-apple-}" # On Darwin, Swift requires the triple to be annotated with a version. # TODO: Assumes macOS. extraBefore[i]="${extraBefore[i]/-apple-darwin/-apple-macosx${MACOSX_DEPLOYMENT_TARGET:-11.0}}" <del> break fi </del> <ins> ;; -march=*) [[ i -gt 0 && ${extraBefore[i-1]} == -Xcc ]] && continue extraBefore=( "${extraBefore[@]:0:i}" -Xcc "${extraBefore[@]:i:${#extraBefore[@]}}" ) i=$((i + 1)) ;; esac </ins> done # As a very special hack, if the arguments are just `-v', then don't
Code change:
Project description A simple GTK4 based video player for mobile phones Metadata homepage URL: source URL: license: GPL3 platforms: Linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi. Is this a package you're working on? If not, I packaged it but I'm not sure if it's correct. I can send a PR for it as starter. [It's the first time I built anything on NixOS].
Not currently working on this, but can help test.
I a PR for this. It would be great if you could check it out. Though running it gives this warning but can play videos. Also I couldn't play x265 videos with it. Is this normal?

Related discussion:
text: fingerprint = "E90C BA34 55B3 6236 740C  038F 0D94 8CE1 9CF4 9C5F"; }]; }; <ins> mksafavi = { name = "MK Safavi"; email = "mksafavi@gmail.com"; github = "mksafavi"; githubId = 50653293; }; </ins> mktip = { email = "mo.issa.ok+nix@gmail.com"; github = "mktip";
Code change:
Project description A simple GTK4 based video player for mobile phones Metadata homepage URL: source URL: license: GPL3 platforms: Linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi. Is this a package you're working on? If not, I packaged it but I'm not sure if it's correct. I can send a PR for it as starter. [It's the first time I built anything on NixOS].
Not currently working on this, but can help test.
I a PR for this. It would be great if you could check it out. Though running it gives this warning but can play videos. Also I couldn't play x265 videos with it. Is this normal?

Related discussion:
text: <ins> { lib , stdenv , fetchFromGitLab , meson , ninja , pkg-config , gst_all_1 , wrapGAppsHook4 , appstream-glib , gtk4 , libadwaita , desktop-file-utils , libGL }: stdenv.mkDerivation rec { pname = "livi"; version = "0.0.6"; src = fetchFromGitLab { owner = "guidog"; repo = "livi"; domain = "gitlab.gnome.org"; rev = "v${version}"; sha256 = "sha256-DaIbBCJT4Da5noW6Q5z1yzTZ256HNqrvdXgwSY7p/D8="; }; nativeBuildInputs = [ meson ninja pkg-config wrapGAppsHook4 appstream-glib desktop-file-utils ]; buildInputs = [ gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good gst_all_1.gst-plugins-bad gtk4 libadwaita libGL ]; strictDeps = true; meta = with lib; { homepage = "https://gitlab.gnome.org/guidog/livi"; description = "A small video player targeting mobile devices (also named μPlayer)"; license = licenses.gpl3Plus; platforms = platforms.linux; mainProgram = "livi"; maintainers = with maintainers; [ mksafavi ]; }; } </ins>
Code change:
When changing an SVP option during playback or the played file in mpv, starting from mpv 0.37.0, due to , it spams: and SVP no longer reports any connected player at the bottom of its window after that. top left logo, "Open file via mpv", pick a video the video is playing, switch back and forth between one of the buttons under "Do frame rate conversion" like "To screen" and "Movie x2" In mpv 0.36 and earlier, it says: and SVP keeps working normally. SVP has no source code available and new versions haven't been released on Linux since 2021, while mpv 0.37 came out in November 2023, making it unlikely to be fixed upstream any time soon. I've made a dirty workaround by to re-add the option, and overriding the source of the mpv package in my flake + home-manager setup. Handling both the external mpv package and the one within SVP's (the mpv that gets used by SVP's in-GUI "Open file") gets complicated - here are the relevant parts: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for your investigation! Indeed it looks like modifying mpv to add the option back is the best way. Based on the diff on your fork, the change seems small enough for us to maintain. On the other hand, patching SVP is impossible due to its tamper protection.
A couple questions: the mpv package gets updated, it might break building SVP with the patch. Do github checks catch these cases, or will the SVP package just be broken until someone else notices? I give you push access to the forked repo, to rebase and regenerate the patch as needed? I rarely update my system, so the repo will likely be left randomly outdated until I have to take care of it. you make the SVP package take and overridable parameters, so that it isn't so hard to e.g. add scripts to the internal mpv? to make a standard external mpv connect to SVP will fail since it won't be patched, is there a good way to indicate to users that they should install in their environment? The parameters mentioned above should probably also be made known.
package in nixpkgs will be broken. However I also have this SVP package on my NUR, and have daily CI runs to rebuild packages, so once it breaks I will notice and make a fix. isn't necessary. I can rebase the patch on mainline mpv as needed. will add them. can't think of any good way for now.

Related discussion:
text: <del> { lib , mpv-unwrapped , ocl-icd , ... </del> <ins> { lib, mpv-unwrapped, ocl-icd, </ins> }: mpv-unwrapped.wrapper {
Code change:
When changing an SVP option during playback or the played file in mpv, starting from mpv 0.37.0, due to , it spams: and SVP no longer reports any connected player at the bottom of its window after that. top left logo, "Open file via mpv", pick a video the video is playing, switch back and forth between one of the buttons under "Do frame rate conversion" like "To screen" and "Movie x2" In mpv 0.36 and earlier, it says: and SVP keeps working normally. SVP has no source code available and new versions haven't been released on Linux since 2021, while mpv 0.37 came out in November 2023, making it unlikely to be fixed upstream any time soon. I've made a dirty workaround by to re-add the option, and overriding the source of the mpv package in my flake + home-manager setup. Handling both the external mpv package and the one within SVP's (the mpv that gets used by SVP's in-GUI "Open file") gets complicated - here are the relevant parts: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for your investigation! Indeed it looks like modifying mpv to add the option back is the best way. Based on the diff on your fork, the change seems small enough for us to maintain. On the other hand, patching SVP is impossible due to its tamper protection.
A couple questions: the mpv package gets updated, it might break building SVP with the patch. Do github checks catch these cases, or will the SVP package just be broken until someone else notices? I give you push access to the forked repo, to rebase and regenerate the patch as needed? I rarely update my system, so the repo will likely be left randomly outdated until I have to take care of it. you make the SVP package take and overridable parameters, so that it isn't so hard to e.g. add scripts to the internal mpv? to make a standard external mpv connect to SVP will fail since it won't be patched, is there a good way to indicate to users that they should install in their environment? The parameters mentioned above should probably also be made known.
package in nixpkgs will be broken. However I also have this SVP package on my NUR, and have daily CI runs to rebuild packages, so once it breaks I will notice and make a fix. isn't necessary. I can rebase the patch on mainline mpv as needed. will add them. can't think of any good way for now.

Related discussion:
text: <del> { stdenv , buildFHSEnv , writeShellScriptBin , fetchurl , callPackage , makeDesktopItem , copyDesktopItems , ffmpeg , glibc , jq , lib , libmediainfo , libsForQt5 , libusb1 , ocl-icd , p7zip , patchelf , socat , vapoursynth , xdg-utils , xorg , zenity </del> <ins> { stdenv, buildFHSEnv, writeShellScriptBin, fetchurl, callPackage, makeDesktopItem, copyDesktopItems, ffmpeg, glibc, jq, lib, libmediainfo, libsForQt5, libusb1, ocl-icd, p7zip, patchelf, socat, vapoursynth, xdg-utils, xorg, zenity, </ins> }: let mpvForSVP = callPackage ./mpv.nix { };
Code change:
When changing an SVP option during playback or the played file in mpv, starting from mpv 0.37.0, due to , it spams: and SVP no longer reports any connected player at the bottom of its window after that. top left logo, "Open file via mpv", pick a video the video is playing, switch back and forth between one of the buttons under "Do frame rate conversion" like "To screen" and "Movie x2" In mpv 0.36 and earlier, it says: and SVP keeps working normally. SVP has no source code available and new versions haven't been released on Linux since 2021, while mpv 0.37 came out in November 2023, making it unlikely to be fixed upstream any time soon. I've made a dirty workaround by to re-add the option, and overriding the source of the mpv package in my flake + home-manager setup. Handling both the external mpv package and the one within SVP's (the mpv that gets used by SVP's in-GUI "Open file") gets complicated - here are the relevant parts: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for your investigation! Indeed it looks like modifying mpv to add the option back is the best way. Based on the diff on your fork, the change seems small enough for us to maintain. On the other hand, patching SVP is impossible due to its tamper protection.
A couple questions: the mpv package gets updated, it might break building SVP with the patch. Do github checks catch these cases, or will the SVP package just be broken until someone else notices? I give you push access to the forked repo, to rebase and regenerate the patch as needed? I rarely update my system, so the repo will likely be left randomly outdated until I have to take care of it. you make the SVP package take and overridable parameters, so that it isn't so hard to e.g. add scripts to the internal mpv? to make a standard external mpv connect to SVP will fail since it won't be patched, is there a good way to indicate to users that they should install in their environment? The parameters mentioned above should probably also be made known.
package in nixpkgs will be broken. However I also have this SVP package on my NUR, and have daily CI runs to rebuild packages, so once it breaks I will notice and make a fix. isn't necessary. I can rebase the patch on mainline mpv as needed. will add them. can't think of any good way for now.

Related discussion:
text: svp-dist = stdenv.mkDerivation rec { pname = "svp-dist"; <del> version = "4.5.210-2"; </del> <ins> version = "4.6.263"; </ins> src = fetchurl { url = "https://www.svp-team.com/files/svp4-linux.${version}.tar.bz2"; <del> hash = "sha256-dY9uQ9jzTHiN2XSnOrXtHD11IIJW6t9BUzGGQFfZ+yg="; </del> <ins> sha256 = "sha256-HyRDVFHVmTan/Si3QjGQpC3za30way10d0Hk79oXG98="; </ins> }; <del> nativeBuildInputs = [ p7zip patchelf ]; </del> <ins> nativeBuildInputs = [ p7zip patchelf ]; </ins> dontFixup = true; unpackPhase = ''
Code change:
When changing an SVP option during playback or the played file in mpv, starting from mpv 0.37.0, due to , it spams: and SVP no longer reports any connected player at the bottom of its window after that. top left logo, "Open file via mpv", pick a video the video is playing, switch back and forth between one of the buttons under "Do frame rate conversion" like "To screen" and "Movie x2" In mpv 0.36 and earlier, it says: and SVP keeps working normally. SVP has no source code available and new versions haven't been released on Linux since 2021, while mpv 0.37 came out in November 2023, making it unlikely to be fixed upstream any time soon. I've made a dirty workaround by to re-add the option, and overriding the source of the mpv package in my flake + home-manager setup. Handling both the external mpv package and the one within SVP's (the mpv that gets used by SVP's in-GUI "Open file") gets complicated - here are the relevant parts: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for your investigation! Indeed it looks like modifying mpv to add the option back is the best way. Based on the diff on your fork, the change seems small enough for us to maintain. On the other hand, patching SVP is impossible due to its tamper protection.
A couple questions: the mpv package gets updated, it might break building SVP with the patch. Do github checks catch these cases, or will the SVP package just be broken until someone else notices? I give you push access to the forked repo, to rebase and regenerate the patch as needed? I rarely update my system, so the repo will likely be left randomly outdated until I have to take care of it. you make the SVP package take and overridable parameters, so that it isn't so hard to e.g. add scripts to the internal mpv? to make a standard external mpv connect to SVP will fail since it won't be patched, is there a good way to indicate to users that they should install in their environment? The parameters mentioned above should probably also be made known.
package in nixpkgs will be broken. However I also have this SVP package on my NUR, and have daily CI runs to rebuild packages, so once it breaks I will notice and make a fix. isn't necessary. I can rebase the patch on mainline mpv as needed. will add them. can't think of any good way for now.

Related discussion:
text: desktopName = "SVP 4 Linux"; genericName = "Real time frame interpolation"; icon = "svp-manager4"; <del> categories = [ "AudioVideo" "Player" "Video" ]; mimeTypes = [ "video/x-msvideo" "video/x-matroska" "video/webm" "video/mpeg" "video/mp4" ]; </del> <ins> categories = [ "AudioVideo" "Player" "Video" ]; mimeTypes = [ "video/x-msvideo" "video/x-matroska" "video/webm" "video/mpeg" "video/mp4" ]; </ins> terminal = false; startupNotify = true; }) ]; meta = with lib; { <ins> mainProgram = "SVPManager"; </ins> description = "SmoothVideo Project 4 (SVP4) converts any video to 60 fps (and even higher) and performs this in real time right in your favorite video player"; homepage = "https://www.svp-team.com/wiki/SVP:Linux"; platforms = [ "x86_64-linux" ];
Code change:
Steps to reproduce the behavior: stig If I try to install it from my config, I get . If I try to run it by nix-shell: is the nixpkgs commit I'm currently using to get a working version of this program. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The different experience you get with vs is a problem in your Nix environment - probably an old version of nixpkgs you use for vs how you build "your config". However the test failing mark this package is now completely broken. See also discussion with upstream at: . I opened that marks stig as broken, and it will close this issue when merged.
stig works for me with this overlay: I think since addresses
It'd be great if you'd share this in a PR.
Opened at !

Related discussion:
text: description = "TUI and CLI for the BitTorrent client Transmission"; homepage = "https://github.com/rndusr/stig"; license = licenses.gpl3Plus; <del> maintainers = with maintainers; [ doronbehar ]; </del> <ins> # Too many broken tests, and it fails to launch broken = true; maintainers = with maintainers; [  ]; </ins> }; }
Code change:
Steps to reproduce the behavior: stig If I try to install it from my config, I get . If I try to run it by nix-shell: is the nixpkgs commit I'm currently using to get a working version of this program. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The different experience you get with vs is a problem in your Nix environment - probably an old version of nixpkgs you use for vs how you build "your config". However the test failing mark this package is now completely broken. See also discussion with upstream at: . I opened that marks stig as broken, and it will close this issue when merged.
stig works for me with this overlay: I think since addresses
It'd be great if you'd share this in a PR.
Opened at !

Related discussion:
text: { lib <del> , stdenv </del> , fetchFromGitHub , python310Packages , testers
Code change:
Steps to reproduce the behavior: stig If I try to install it from my config, I get . If I try to run it by nix-shell: is the nixpkgs commit I'm currently using to get a working version of this program. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The different experience you get with vs is a problem in your Nix environment - probably an old version of nixpkgs you use for vs how you build "your config". However the test failing mark this package is now completely broken. See also discussion with upstream at: . I opened that marks stig as broken, and it will close this issue when merged.
stig works for me with this overlay: I think since addresses
It'd be great if you'd share this in a PR.
Opened at !

Related discussion:
text: pname = "stig"; # This project has a different concept for pre release / alpha, # Read the project's README for details: https://github.com/rndusr/stig#stig <del> version = "0.12.8a0"; </del> <ins> version = "0.12.10a0"; </ins> src = fetchFromGitHub { owner = "rndusr"; repo = "stig"; rev = "v${version}"; <del> sha256 = "sha256-vfmuA6DqWvAygcS6N+qX1h+Ag+P4eOwm41DhAFZR3r8="; </del> <ins> sha256 = "sha256-lSFI4/DxWl17KFgLXZ7c5nW/e5IUGN7s8Gm6wTM5ZWg="; </ins> }; propagatedBuildInputs = with python310Packages; [