jiebi/CodeConvo huggingface dataset:
Code change:
Project description ssh-tpm-agent is a ssh-agent compatible agent that allows keys to be created by the Trusted Platform Module (TPM) for authentication towards ssh servers. Metadata homepage URL: source URL: license: MIT platforms: unix (at least) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
ah, thanks i promise i did search but somehow didn't get any relevant results. probably PEBKAC.

Related discussion:
text: <ins> { lib , buildGo122Module , fetchFromGitHub , openssl }: buildGo122Module rec { pname = "ssh-tpm-agent"; version = "0.3.1"; src = fetchFromGitHub { owner = "Foxboron"; repo = "ssh-tpm-agent"; rev = "v${version}"; hash = "sha256-8CGSiCOcns4cWkYWqibs6hAFRipYabKPCpkhxF4OE8w="; }; proxyVendor = true; vendorHash = "sha256-zUAIesBeuh1zlxXcjKSNmMawZGgUr9z3NzT0XKn/YCQ="; buildInputs = [ openssl ]; meta = with lib; { description = "SSH agent with support for TPM sealed keys for public key authentication"; homepage = "https://github.com/Foxboron/ssh-agent-tpm"; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ sgo ]; mainProgram = "ssh-tpm-agent"; }; } </ins>
Code change:
Steps to reproduce the behavior: for n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --built from nixpkgs master () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: libxcrypt lttng-ust_2_12 musl <ins> ]++ lib.optionals (stdenv.isLinux && stdenv.isAarch64) [ expat libxml2 xz </ins> ]; }).overrideAttrs (attrs: { postInstall = (attrs.postInstall or "") + lib.optionalString (stdenv.isLinux) '' (
Code change:
Ffmpeg 6.1 supports vulkan video, but it is not enabled in the default version of ffmpeg, it is only enabled in ffmpeg-full. The default version of ffmpeg should support vulkan video so that applications like mpv can use it. Arch enables vulkan by . Vulkan video already works with amd GPUs using ffmpeg-full with this command: <!-- 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]:
This seems reasonable. I'm in favor.
EDIT: Error on my end, skip reading this. Hm, your command doesn't work for me on Mesa 23.3.3: Another aspect to consider is closure size.
If you haven't tried already, can you try with something in h264? Vulkan video currently only supports h264, h265 and av1(experminental), and only if you gpu supports them.
Indeed it's h.265, let me try h.264. This looks like a generic VK issue though.
As suspected, this happens on h.264 too.
Do you have multiple GPUs in your system except the amd one perhaps? This chooses the first one arbitrarily.
Same error for all.
Then I am not sure about what's causing it, that's the exact same error I receive when using ffmpeg 6.1 instead of ffmpeg-full 6.1.
Uhhh about that... So and that commit didn't seem to have been pulled into this brain thingy of mine... It works as expected with ffmpeg-full.

Related discussion:
text: , withVoAmrwbenc ? withFullDeps # AMR-WB encoder , withVorbis ? withHeadlessDeps # Vorbis de/encoding, native encoder exists , withVpx ? withHeadlessDeps && stdenv.buildPlatform == stdenv.hostPlatform # VP8 & VP9 de/encoding <del> , withVulkan ? withFullDeps && !stdenv.isDarwin </del> <ins> , withVulkan ? withSmallDeps && !stdenv.isDarwin </ins> , withWebp ? withFullDeps # WebP encoder , withX264 ? withHeadlessDeps # H.264/AVC encoder , withX265 ? withHeadlessDeps # H.265/HEVC encoder
Code change:
Ffmpeg 6.1 supports vulkan video, but it is not enabled in the default version of ffmpeg, it is only enabled in ffmpeg-full. The default version of ffmpeg should support vulkan video so that applications like mpv can use it. Arch enables vulkan by . Vulkan video already works with amd GPUs using ffmpeg-full with this command: <!-- 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]:
This seems reasonable. I'm in favor.
EDIT: Error on my end, skip reading this. Hm, your command doesn't work for me on Mesa 23.3.3: Another aspect to consider is closure size.
If you haven't tried already, can you try with something in h264? Vulkan video currently only supports h264, h265 and av1(experminental), and only if you gpu supports them.
Indeed it's h.265, let me try h.264. This looks like a generic VK issue though.
As suspected, this happens on h.264 too.
Do you have multiple GPUs in your system except the amd one perhaps? This chooses the first one arbitrarily.
Same error for all.
Then I am not sure about what's causing it, that's the exact same error I receive when using ffmpeg 6.1 instead of ffmpeg-full 6.1.
Uhhh about that... So and that commit didn't seem to have been pulled into this brain thingy of mine... It works as expected with ffmpeg-full.

Related discussion:
text: postFixup = optionalString (stdenv.isLinux && withLib) '' addOpenGLRunpath ${placeholder "lib"}/lib/libavcodec.so addOpenGLRunpath ${placeholder "lib"}/lib/libavutil.so <ins> '' # https://trac.ffmpeg.org/ticket/10809 + optionalString (versionAtLeast version "5.0" && withVulkan) '' patchelf $lib/lib/libavcodec.so --add-needed libvulkan.so --add-rpath ${lib.makeLibraryPath [ vulkan-loader ]} </ins> ''; enableParallelBuilding = true;
Code change:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error. (I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.

Related discussion:
text: <ins> export NIX_CXXSTDLIB_COMPILE+="-isystem $(echo -n @gcc@/include/c++/*) -isystem $(echo -n @gcc@/include/c++/*)/$(@gcc@/bin/gcc -dumpmachine)" export NIX_CXXSTDLIB_LINK=" -stdlib=libstdc++" </ins>
Code change:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error. (I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.

Related discussion:
text: <del> { lowPrio, newScope, stdenv, cmake, libxml2, python2, isl, fetchurl, overrideCC, wrapCC, darwin, ccWrapperFun }: </del> <ins> { lowPrio, newScope, stdenv, targetPlatform, cmake, libstdcxxHook , libxml2, python2, isl, fetchurl, overrideCC, wrapCC, ccWrapperFun , darwin }: </ins> let callPackage = newScope (self // { inherit stdenv cmake libxml2 python2 isl release_version version fetch; });
Code change:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error. (I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.

Related discussion:
text: extraPackages = [ self.libcxx self.libcxxabi ]; }; <del> stdenv = overrideCC stdenv self.clang; </del> <ins> stdenv = stdenv.override (drv: { allowedRequisites = null; cc = self.clang; # Use the gcc libstdc++ when targeting linux. extraBuildInputs = if stdenv.cc.isGNU then [ libstdcxxHook ] else drv.extraBuildInputs; }); </ins> libcxxStdenv = overrideCC stdenv self.libcxxClang;
Code change:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error. (I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.

Related discussion:
text: libcxxabi = callPackage ./libc++abi.nix {}; }; in self
Code change:
The clang stdenv (e.g., ) on recent unstable channel no longer seems able to find the C++ headers when used as the stdenv for a build. yields Curiously the libcxxStdenv does work: and just for sanity, it does work on 17.03 and usually works otherwise O:) System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc and since they were tracking down a similar problem in the Darwin clang stdenv recently.
This only happens on linux, it looks like the -isystem flags from gcc used to leak into the clang stdenv somehow.
This works, we could fix the clang stdenv to include those by default. Unless there's a reason to use the gcc headers, but using libcxx makes more sense I would think.
cc
Is this significantly different than using ? IMO it's an important use case, using clang w/gcc's libstdc++, it's the most "compatible" with Linux things and is the default way to use clang (for now, anyway).
This have something to do with ?
From the name I wouldn't expect to still use the gcc libstc++, but the use case makes sense. The condition for  looks good, not sure why it's not working.
noticed that the logic would only apply if that variable was undefined, not empty. But now ensures that it is defined (and empty if not otherwise defined). The best solution would be to handle the default in so there's no empty fallback at any point.
I'll do this for 17.09
appears to be a victim of this issue as well
seems to be defined before. I currently test the following patch: this is not a good fix though, but if this the root cause, I can come up with a better patch.
That would break or make it behave incorrectly.
i know
Is this supposed to work now? At least I am having the same problem on unstable(18.03); g++ works but clang fails and does not find the headers. I might have missed something though, rather new to nix.
Maybe you need instead of ? Edit: nevermind, I can also reproduce your issue
After some testing, I found that using without will cause the c++ header not found error. (I guess this is not a bug?) To successfully compile a simple file, I need
See
Indeed it works in nix-shell, thanks.
There's probably a bigger issue here of people wanting our tools to work normally outside of Nix builds and shells, but that's a much bigger endeavor.
Yeah we'd need like a , which would easiest to accomplish if we did less dependency stuff in bash.

Related discussion:
text: gccApple = throw "gccApple is no longer supported"; <ins> libstdcxxHook = makeSetupHook { substitutions = { gcc = gcc-unwrapped; }; } ../development/compilers/gcc/libstdc++-hook.sh; </ins> # Can't just overrideCC, because then the stdenv-cross mkDerivation will be # thrown away. TODO: find a better solution for this. crossLibcStdenv = buildPackages.makeStdenvCross {
Code change:
Package name: digikam Latest released version: 8.2.0 Current version on the unstable channel: 8.1.0 Current version on the stable/release channel: 8.1.0 Notify maintainers Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: <del> { mkDerivation, config, lib, fetchpatch, fetchurl, cmake, doxygen, extra-cmake-modules, wrapGAppsHook # For `digitaglinktree` , perl, sqlite , qtbase , qtxmlpatterns , qtsvg , qtwebengine , qtnetworkauth , akonadi-contacts , kcalendarcore , kconfigwidgets , kcoreaddons , kdoctools , kfilemetadata , knotifications , knotifyconfig , ktextwidgets , kwidgetsaddons , kxmlgui , bison , boost , eigen , exiv2 , ffmpeg_4 , flex , graphviz , imagemagick , lcms2 , lensfun , libgphoto2 , libkipi , libksane , liblqr1 , libqtav , libusb1 , marble , libGL , libGLU , opencv , pcre , threadweaver , x265 , jasper # For panorama and focus stacking , enblend-enfuse , hugin , gnumake , breeze-icons , oxygen , cudaSupport ? config.cudaSupport , cudaPackages ? {} }: mkDerivation rec { pname   = "digikam"; version = "8.1.0"; src = fetchurl { url = "mirror://kde/stable/${pname}/${version}/digiKam-${version}.tar.xz"; hash = "sha256-BQPANORF/0JPGKZxXAp6eb5KXgyCs+vEYaIc7DdFpbM="; }; # Fix build against exiv2 0.28.1 patches = [ (fetchpatch { url = "https://invent.kde.org/graphics/digikam/-/commit/f5ea91a7f6c1926815ec68f3e0176d6c15b83051.patch"; hash = "sha256-5g2NaKKNKVfgW3dTO/IP/H/nZ0YAIOmdPAumy3NEaNg="; }) ]; nativeBuildInputs = [ cmake doxygen extra-cmake-modules kdoctools wrapGAppsHook ] ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_nvcc ]); buildInputs = [ bison boost eigen exiv2 ffmpeg_4 flex graphviz imagemagick lcms2 lensfun libgphoto2 libkipi libksane liblqr1 libqtav libusb1 libGL libGLU opencv pcre x265 jasper qtbase qtxmlpatterns qtsvg qtwebengine qtnetworkauth akonadi-contacts kcalendarcore kconfigwidgets kcoreaddons kfilemetadata knotifications knotifyconfig ktextwidgets kwidgetsaddons kxmlgui breeze-icons marble oxygen threadweaver ] ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_cudart ]); cmakeFlags = [ "-DENABLE_MYSQLSUPPORT=1" "-DENABLE_INTERNALMYSQL=1" "-DENABLE_MEDIAPLAYER=1" "-DENABLE_QWEBENGINE=on" "-DENABLE_APPSTYLES=on" "-DCMAKE_CXX_FLAGS=-I${libksane}/include/KF5" # fix `#include <ksane_version.h>` ]; dontWrapGApps = true; preFixup = '' qtWrapperArgs+=("''${gappsWrapperArgs[@]}") qtWrapperArgs+=(--prefix PATH : ${lib.makeBinPath [ gnumake hugin enblend-enfuse ]}) qtWrapperArgs+=(--suffix DK_PLUGIN_PATH : ${placeholder "out"}/${qtbase.qtPluginPrefix}/${pname}) substituteInPlace $out/bin/digitaglinktree  --replace "/usr/bin/perl" "${perl}/bin/perl"  --replace "/usr/bin/sqlite3" "${sqlite}/bin/sqlite3" ''; meta = with lib; { description = "Photo Management Program"; license = licenses.gpl2; homepage = "https://www.digikam.org"; maintainers = with maintainers; [ spacefault ]; platforms = platforms.linux; mainProgram = "digikam"; }; } </del>