jiebi/CodeConvo huggingface dataset:
Code change:
libDeps = platform: stdenv.lib.optional enableTerminfo [ ncurses ] ++ [libffi] ++ stdenv.lib.optional (!enableIntegerSimple) gmp <del> ++ stdenv.lib.optional (platform.libc != "glibc" && !targetPlatform.isWindows) libiconv ++ stdenv.lib.optional enableDwarf elfutils; </del> <ins> ++ stdenv.lib.optional (platform.libc != "glibc" && !targetPlatform.isWindows) libiconv; </ins> toolsForTarget = [ pkgsBuildTarget.targetPackages.stdenv.cc

Related discussion:
text: Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.
Code change:
-e 's^addCVars^addCVars${_infixSalt}^g'  -e 's^[ -z "$crossConfig" ]^[[ "${builtins.toString (targetPlatform != hostPlatform)}" || -z "$crossConfig" ]]^g' <del> '' + stdenv.lib.optionalString (textFile == ./setup-hook.sh) '' cat << 'EOF' >> $out for CMD in ar as nm objcopy ranlib strip strings size ld windres do # which is not part of stdenv, but compgen will do for now if PATH=$_PATH type -p ${prefix}$CMD > /dev/null then export ''$(echo "$CMD" | tr "[:lower:]" "[:upper:]")=${prefix}''${CMD}; fi done EOF sed -i $out -e 's_envHooks_crossEnvHooks_g' '' + '' </del> # NIX_ things which we don't both use and define, we revert them #asymmetric=$( #  for pre in "" "$"

Related discussion:
text: Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.
Code change:
-e 's^addCVars^addCVars${_infixSalt}^g'  -e 's^[ -z "$crossConfig" ]^[[ "${builtins.toString (targetPlatform != hostPlatform)}" || -z "$crossConfig" ]]^g' <del> '' + stdenv.lib.optionalString (textFile == ./setup-hook.sh) '' cat << 'EOF' >> $out for CMD in ar as nm objcopy ranlib strip strings size ld windres do # which is not part of stdenv, but compgen will do for now if PATH=$_PATH type -p ${prefix}$CMD > /dev/null then export ''$(echo "$CMD" | tr "[:lower:]" "[:upper:]")=${prefix}''${CMD}; fi done EOF sed -i $out -e 's_envHooks_crossEnvHooks_g' '' + '' </del> # NIX_ things which we don't both use and define, we revert them #asymmetric=$( #  for pre in "" "$"

Related discussion:
text: gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc
Code change:
rustPlatform.buildRustPackage rec { pname = "edgedb"; <del> version = "3.3.0"; </del> <ins> version = "3.4.0"; </ins> src = fetchFromGitHub { owner = "edgedb"; repo = "edgedb-cli"; rev =  "v${version}"; <del> sha256 = "sha256-6uhwuAGZ/XU+eENNo0H7hOdrDDx0fWvPVZAEOm5mdcY="; </del> <ins> sha256 = "sha256-w6YpjSmh517yat45l4gGdV6qWD4O3aCx/6LL5wea+RA="; </ins> fetchSubmodules = true; };

Related discussion:
text: Package name: edgedb Latest released version: 3.2.0 Current version on the unstable channel: 2.3.1 Current version on the stable/release channel: 2.3.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Code change:
homepage = "https://github.com/luabind/luabind"; description = "A library that helps you create bindings between C++ and Lua"; license = lib.licenses.mit; <del> platforms = lib.platforms.linux; </del> <ins> platforms = lib.platforms.unix; </ins> }; }

Related discussion:
text: Steps to reproduce the behavior: FWIW: my fix is here, - but it is using a fork of . If somebody has the time to create a minimal patch on top of the current source, please feel free to. Please run and paste the result.
Looks like you are on a good path. Unfortunately I have no access to Apple hardware at all, but would be happy to merge a PR.
Yes, is working on it. There is a more active fork of luabind here: - how about we switch to using it? It'll obviate a bunch of patches as well.
I agree, sounds sensible.
Code change:
requests_oauth2 = buildPythonPackage rec { name = "requests-oauth2-0.1.1"; <ins> # python3 does not support relative imports disabled = isPy3k; </ins> src = pkgs.fetchurl { url = https://github.com/maraujop/requests-oauth2/archive/0.1.1.tar.gz; sha256 = "1aij66qg9j5j4vzyh64nbg72y7pcafgjddxsi865racsay43xfqg"; }; <del> propagatedBuildInputs = with self; [ requests_oauthlib ]; </del> <ins> propagatedBuildInputs = with self; [ requests2 ]; # no tests in tarball doCheck = false; </ins> meta = { description = "Python's Requests OAuth2 (Open Authentication) plugin";

Related discussion:
text: I get the error: It seems that this problem is related to There is no problem for System: 17.03pre94121. (Gorilla) and on master Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre94121.
it seems the tests depend on a package like
Code change:
hash = "sha256-FIlnJsNgofGo4HETEEpW28wpC3U9z5AZprwFR5AgFfA="; }; <del> version = "0.38.0"; </del> <ins> # "main.c" from master after (https://github.com/falcosecurity/libs/pull/1884) # Remove when an upstream release includes the driver update driverKernel610MainC = fetchurl { url = "https://raw.githubusercontent.com/falcosecurity/libs/fa26daf65bb4117ecfe099fcad48ea75fe86d8bb/driver/main.c"; hash = "sha256-VI/tOSXs5OcEDehSqICF3apmSnwe4QCmbkHz+DGH4uM="; }; version = "0.38.1"; </ins> in stdenv.mkDerivation { pname = "sysdig";

Related discussion:
text: Steps to reproduce the behavior: sysdig Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on master () and the error isn't in the log output, can you provide additional info?
Hey, thanks for the response - checking again - it only happens if for me if I enable the sysdig-option in my config not building the sysdig-package - maybe this helps to reproduce and depends on the used kernel-version? I've uploaded the full build log:
Thanks, seems this is the error:
I guess this is already fixed upstream in the drivers () but needs to be to nixpkgs to fix 6.10-kernel builds.
fixes it for me
~Ah 0.38.1 - got released somehow oversaw it should check first if that includes the fix~ 38.1 does not include a driver-bump
Code change:
# Unpack the wheel file. wheel unpack --dest unpacked ./*.whl <del> # Tensorflow has a hard dependency on gast==0.2.2, but we relax it to # gast==0.3.2. substituteInPlace ./unpacked/tensorflow*/tensorflow_core/tools/pip_package/setup.py --replace "gast == 0.2.2" "gast == 0.3.2" substituteInPlace ./unpacked/tensorflow*/tensorflow_*.dist-info/METADATA --replace "gast (==0.2.2)" "gast (==0.3.2)" </del> <ins> # Tensorflow wheels tightly constrain the versions of gast, tensorflow-estimator and scipy. # This code relaxes these requirements: substituteInPlace ./unpacked/tensorflow*/tensorflow_core/tools/pip_package/setup.py  --replace "tensorflow_estimator >= 2.1.0rc0, < 2.2.0" "tensorflow_estimator"  --replace "tensorboard >= 2.1.0, < 2.2.0" "tensorboard"  --replace "gast == 0.2.2" "gast"   --replace "scipy == 1.2.2" "scipy" substituteInPlace ./unpacked/tensorflow*/tensorflow*.dist-info/METADATA   --replace "gast (==0.2.2)" "gast"  --replace "tensorflow-estimator (<2.2.0,>=2.1.0rc0)" "tensorflow_estimator"  --replace "tensorboard (<2.2.0,>=2.1.0)" "tensorboard"  --replace "scipy (==1.4.1)" "scipy" </ins> # Pack the wheel file back up. wheel pack ./unpacked/tensorflow*

Related discussion:
text: Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:
Code change:
# Unpack the wheel file. wheel unpack --dest unpacked ./*.whl <del> # Tensorflow has a hard dependency on gast==0.2.2, but we relax it to # gast==0.3.2. substituteInPlace ./unpacked/tensorflow*/tensorflow_core/tools/pip_package/setup.py --replace "gast == 0.2.2" "gast == 0.3.2" substituteInPlace ./unpacked/tensorflow*/tensorflow_*.dist-info/METADATA --replace "gast (==0.2.2)" "gast (==0.3.2)" </del> <ins> # Tensorflow wheels tightly constrain the versions of gast, tensorflow-estimator and scipy. # This code relaxes these requirements: substituteInPlace ./unpacked/tensorflow*/tensorflow_core/tools/pip_package/setup.py  --replace "tensorflow_estimator >= 2.1.0rc0, < 2.2.0" "tensorflow_estimator"  --replace "tensorboard >= 2.1.0, < 2.2.0" "tensorboard"  --replace "gast == 0.2.2" "gast"   --replace "scipy == 1.2.2" "scipy" substituteInPlace ./unpacked/tensorflow*/tensorflow*.dist-info/METADATA   --replace "gast (==0.2.2)" "gast"  --replace "tensorflow-estimator (<2.2.0,>=2.1.0rc0)" "tensorflow_estimator"  --replace "tensorboard (<2.2.0,>=2.1.0)" "tensorboard"  --replace "scipy (==1.4.1)" "scipy" </ins> # Pack the wheel file back up. wheel pack ./unpacked/tensorflow*

Related discussion:
text: Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.
Code change:
# THIS IS A GENERATED FILE.  DO NOT EDIT! xorgserver = callPackage ({ stdenv, pkg-config, fetchurl, xorgproto, openssl, libX11, libXau, libxcb, xcbutil, xcbutilwm, xcbutilimage, xcbutilkeysyms, xcbutilrenderutil, libXdmcp, libXfixes, libxkbfile, testers }: stdenv.mkDerivation (finalAttrs: { pname = "xorg-server"; <del> version = "21.1.12"; </del> <ins> version = "21.1.13"; </ins> builder = ./builder.sh; src = fetchurl { <del> url = "mirror://xorg/individual/xserver/xorg-server-21.1.12.tar.xz"; sha256 = "03x954bygi6sdynk5yy3yvsfhg6i9gjhisn3x9jxvk5mw4mnw08y"; </del> <ins> url = "mirror://xorg/individual/xserver/xorg-server-21.1.13.tar.xz"; sha256 = "033lvjihidc68v08izrr63va8jhkfmzcjg0d6rm26wizjkah4nml"; </ins> }; hardeningDisable = [ "bindnow" "relro" ]; strictDeps = true;

Related discussion:
text: XOrg crashes when certain applications are launched. More details here: Steps to reproduce the behavior: any of the IntelliJ IDEs. You may have to set anti aliasing to greyscale. Xorg will crash. Xorg doesn't crash. This is the bug: It looks like a security fix caused this regression. Ubuntu has already applied patches that fix this for Xorg and Xwayland: see this message from the above Ubuntu thread: NixOS should use the same patches until this is fixed upstream in XOrg. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Sounds like this will be addressed by this update:
xwayland too: looks like updating xorg and xwayland to their latest versions will do the trick then
xwayland was bumped to the latest version in PR
Code change:
./services/networking/strongswan.nix ./services/networking/stubby.nix ./services/networking/stunnel.nix <ins> ./services/networking/sunshine.nix </ins> ./services/networking/supplicant.nix ./services/networking/supybot.nix ./services/networking/syncplay.nix

Related discussion:
text: Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.
Code change:
postFixup = '' wrapProgram $out/bin/glimpse-${lib.versions.majorMinor version}  <del> --set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE" </del> <ins> --set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE"  --prefix PATH ":" ${ lib.makeBinPath [ graphviz ] } </ins> ''; passthru = rec {

Related discussion:
text: Installing results in a broken application that exits on startup with the message "GEGL operation missing! Glimpse requires the GEGL operation "gegl:introspect". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for Glimpse." Steps to reproduce the behavior: to Glimpse Glimpse should work! works fine for me. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Thanks for the report, Unfortunately I cannot reproduce your issue. Neither on as you reported nor on current . Could you elaborate on your setup a bit? Which window manager/desktop environment are you using? Is it possible that you modified glimpse in an overlay? I'm running Sway (Wayland) and deleted and before testing to make sure I didn't have any leftover state in my home directory.
I'm using i3wm (with no separate desktop manager); I installed Glimpse by adding it to environment.systemPackages in , I don't think there's any chance I did anything special with overlays there. I can't think of anything else I've done that might have affected this – I only installed NixOS a few days ago. I do have Home Manager installed, so I guess is it possible that something I've installed via that is causing a problem? (I don't have that much stuff installed, though, I don't think.) on my system is a tmpfs, so if something put a file outside of /nix or /home on install and is expecting it to still be there then it'll be unhappy, but I think I tried running Glimpse immediately after installing it with and it didn't work even then, so it shouldn't be anything related to that. Deleting changes the icon in the popup, which is weird, it looks like this if that directory isn't present at statup: ! and like this if I leave the directory there: ! but nothing else seems to change. (I noticed there's a directory in and , but removing it doesn't seem to do anything.)
aha, I found the problem: works just fine, and adding graphviz to environment.systemPackages fixes it permanently. see e.g.
Code change:
postFixup = '' wrapProgram $out/bin/glimpse-${lib.versions.majorMinor version}  <del> --set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE" </del> <ins> --set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE"  --prefix PATH ":" ${ lib.makeBinPath [ graphviz ] } </ins> ''; passthru = rec {

Related discussion:
text: Ooh nice, didn't think about using a pure nix-shell to circumvent already installed packages clouding the issue. Now I'm able to reproduce the issue. Will add graphviz as runtime dependency then.
Looks like Gimp is not affected, as they got it . Glimpse didn't receive that fix, and it won't in the foreseeable future as the project .
Code change:
]; preCheck = '' <del> # Scale default timeouts by a factor of 4 to avoid flaky builds # https://github.com/microsoft/debugpy/pull/1286 if merged would # allow us to disable the timeouts altogether export DEBUGPY_PROCESS_SPAWN_TIMEOUT=60 export DEBUGPY_PROCESS_EXIT_TIMEOUT=20 </del> <ins> export DEBUGPY_PROCESS_SPAWN_TIMEOUT=0 export DEBUGPY_PROCESS_EXIT_TIMEOUT=0 </ins> '' + lib.optionalString (stdenv.isDarwin && stdenv.isAarch64) '' # https://github.com/python/cpython/issues/74570#issuecomment-1093748531 export no_proxy='*';

Related discussion:
text: Steps to reproduce the behavior: (warning: veeery long) Seems caused by Also previously reported (if I'm reading the many thousands of lines of output right) to be another instance of Breaks: .
This appears to have been fixed somewhere between and
I have no idea how you tested, but after a (pulling branch), I fail to build this same package. Now with the newer hash: I vote for this issue to be marked as "prematurely-closed", and thus re-opened.
debugpy was blocking my nixos rebuilds through . Updating to resolved it for me. That's about all the testing I did at the time, and figured it was good. Sorry about that.
Yep! Looks like this is related to flaky process test timeouts (which are more likely to fail on less powerful / overworked devices). should fix this!
You can checkout to see when the fix will be applied to the channel you're using.
Code change:
buildPythonPackage rec { pname = "dm-tree"; <del> # As of 2021-12-29, the latest stable version still builds with Bazel. version = "unstable-2021-12-20"; </del> <ins> version = "0.1.7"; </ins> src = fetchFromGitHub { owner = "deepmind"; repo = "tree"; <del> rev = "b452e5c2743e7489b4ba7f16ecd51c516d7cd8e3"; sha256 = "1r187xwpvnnj98lyasngcv3lbxz0ziihpl5dbnjbfbjr0kh6z0j9"; </del> <ins> rev = version; hash = "sha256-rg6dcGcbTGfK3h4WAyhwCjgM3o64Jj2SImxNsZXJHHM="; </ins> }; patches = [

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
Code change:
enableParallelBuilding = true; depsBuildBuild = [ buildPackages.stdenv.cc ]; <del> nativeBuildInputs = [ perl bc nettools openssl rsync gmp libmpc mpfr ] </del> <ins> nativeBuildInputs = [ perl bc nettools openssl rsync gmp libmpc mpfr gawk zstd ] </ins> ++ optional  (stdenv.hostPlatform.platform.kernelTarget == "uImage") buildPackages.ubootTools ++ optional  (stdenv.lib.versionAtLeast version "4.14" && stdenv.lib.versionOlder version "5.8") libelf # Removed util-linuxMinimal since it should not be a dependency.

Related discussion:
text: The latest major version 5.9 of the Linux kernel . Apparently, zstd compressed things decompress much faster and can cut boot times substantially, hence it seems worthwhile for us to support this scheme. Currently we are using bzip2. Unfortunately, I probably won't find time to work on this myself, but thought to open this issue to track progress.
I've [probably] been using it through a xanmod patch, not recently since the 5.9 release though. What I have in my files are and adding to of the kernel derivation
For the initrd image: For me (which might differ from the stock kernel NixOS provides): is already enabled, so set This enables ZSTD compression for initrd. However, which will need to as mentioned above.
I was wondering if zstd should be made a part of stdenv. are all available in stdenv on linux and with slowly becoming more common by being available in the kernel and used by various distribution's packaging it should make sense to include it.
Can this be closed? Did cover it all?
Yes, it did! Closing this issue. Thank you for pointing that out, didn't notice before.
Code change:
<ins> { lib , stdenv , fetchurl , installShellFiles , python3 }: stdenv.mkDerivation rec { pname = "flawfinder"; version = "2.0.15"; src = fetchurl { url = "https://dwheeler.com/flawfinder/flawfinder-${version}.tar.gz"; sha256 = "01j4szy8gwvikrfzfayfayjnc1za0jxsnxp5fsa6d06kn69wyr8a"; }; nativeBuildInputs = [ installShellFiles ]; buildInputs = [ python3 ]; installPhase = '' runHook preInstall mkdir -p $out/bin cp ${pname} $out/bin installManPage flawfinder.1 runHook postInstall ''; meta = with lib; { description = "Tool to examines C/C++ source code for security flaws"; homepage = "https://dwheeler.com/flawfinder/"; license = with licenses; [ gpl2Only ]; maintainers = with maintainers; [ fab ]; }; } </ins>

Related discussion:
text: Project description Flawfinder is a simple program that scans C/C++ source code and reports potential security flaws. It can be a useful tool for examining software for vulnerabilities, and it can also serve as a simple introduction to static source code analysis tools more generally. It is designed to be easy to install and use. Flawfinder supports the Common Weakness Enumeration (CWE) and is officially CWE-Compatible. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
could you please test Thanks
Works for me on NixOS. I wrote a simple c program that it found the vuln in: where it gave: