jiebi/CodeConvo huggingface dataset:
Change:
Project description Pueue is a command line queue management tool for sequential and parallel execution of long running tasks.  Installation Vector This package is conventionally installed through or , so it should be packaged like other Python programs. Metadata homepage URL: source URL: license: MIT platforms: Unix
Hey. Maintainer from pueue here. Pueue has been rewritten in Rust. It can now easily be deployed via binary or clean installed via cargo.
Hi great to hear from you! And it's nice to hear that Pueue has been rewritten in Rust. It would be easier to package if it had an upstream file. Would you be willing to provide one?
Hey Sorry for the delay, I wanted to release a new version that fixes some things before pinging you. is .
Wow, thanks much appreciated. Here's the expression I'm using: When I build it I get a build failure in the dependency of all things: It looks like CI is red for this build too, but for a different reason: Is this error familiar to you? If not it might be something about how works in Nix. My main hunch is that I'm implicitly using a that does not meet the Rust=1.39 constraint of .
Travis' pipeline failed on the old python version :D Totally forgot this still existed. The Github Actions pipeline is working for both rust stable and nightly (just a badge to the Readme) I just looked at the Nixpkg rust section and it looks like there is an option to set the Rust version: Also looked at the error you got there. It's indeed another feature that got stablilized in Rust v1.39. Thanks for packaging this for NixOs. I'm kind of honored :)
Aha, I just used so that I got the channel instead of NixOS 19.09. This works!

Discussion:
<ins> { lib, rustPlatform, fetchFromGitHub, installShellFiles }: rustPlatform.buildRustPackage rec { pname = "pueue"; version = "0.1.5"; src = fetchFromGitHub { owner = "Nukesor"; repo = pname; rev = "v${version}"; sha256 = "03aj4vw8kvwqk1i1a4kah5b574ahs930ij7xmqsvdy7f8c2g6pbq"; }; nativeBuildInputs = [ installShellFiles ]; cargoSha256 = "1y33n0dmrssv35l0apfq1mchyh92cfbzjarh0m8zb2nxwhvk7paw"; postInstall = '' installShellCompletion utils/completions/pueue.{bash,fish} --zsh utils/completions/_pueue ''; meta = with lib; { description = "A daemon for managing long running shell commands"; homepage = "https://github.com/Nukesor/pueue"; license = licenses.mit; maintainers = [ maintainers.marsam ]; }; } </ins>

parallel-rust = callPackage ../tools/misc/parallel-rust { }; <ins> pueue = callPackage ../applications/misc/pueue { }; </ins> pyCA = python3Packages.callPackage ../applications/video/pyca {}; pyznap = python3Packages.callPackage ../tools/backup/pyznap {};
Change:
Describe the bug the sshguard module includes a post-start script that adds firewall rules to match the that sshguard creates on startup. This script races with sshguard actually creating the s, and when it loses, the entire unit fails to start with: This leads sshguard to crashloop a non-deterministic number of times before starting correctly. If especially unlucky, it crashloops enough times that systemd gives up trying to start it, and sshguard doesn't come up at all until an admin fixes it. To Reproduce to . and , observe crashloop. It may take a few attempts to trigger depending on your machine and luck. Expected behavior sshguard should start cleanly without relying on winning races. Additional context This is a secondary effect of fixing with . In the old world, sshguard didn't create the ipset so nixos's post-start script did both the ipset creation and firewall config. Now, sshguard creates the ipset itself, but we still rely on a post-start script to create firewall rules that depend on the ipsets existing. I believe a correct fix would be to go back to creating the ipset from outside sshguard, and putting both ipset creation and firewall configuration in pre-start, rather than post-start. This way, the system state would already be satisfactory to sshguard, and it would not need to do anything itself. Metadata Maintainer information:
I am experiencing the same issue on several servers running 19.03.
will this be backported to 19.03?

Discussion:
path = with pkgs; [ iptables ipset iproute systemd ]; <del> postStart = '' </del> <ins> # The sshguard ipsets must exist before we invoke # iptables. sshguard creates the ipsets after startup if # necessary, but if we let sshguard do it, we can't reliably add # the iptables rules because postStart races with the creation # of the ipsets. So instead, we create both the ipsets and # firewall rules before sshguard starts. preStart = '' ${pkgs.ipset}/bin/ipset -quiet create -exist sshguard4 hash:net family inet ${pkgs.ipset}/bin/ipset -quiet create -exist sshguard6 hash:net family inet6 </ins> ${pkgs.iptables}/bin/iptables  -I INPUT -m set --match-set sshguard4 src -j DROP ${pkgs.iptables}/bin/ip6tables -I INPUT -m set --match-set sshguard6 src -j DROP ''; <del> preStop = '' </del> <ins> postStop = '' </ins> ${pkgs.iptables}/bin/iptables  -D INPUT -m set --match-set sshguard4 src -j DROP ${pkgs.iptables}/bin/ip6tables -D INPUT -m set --match-set sshguard6 src -j DROP <ins> ${pkgs.ipset}/bin/ipset -quiet destroy sshguard4 ${pkgs.ipset}/bin/ipset -quiet destroy sshguard6 </ins> ''; unitConfig.Documentation = "man:sshguard(8)";
Change:
Describe the bug I’m trying to build the ghc package (currently at version 8.6.5) on Darwin but building fails with the error (warning: almost 2 MB) To Reproduce (this is the exact revision I’m using; it’s the Nixpkgs as of this writing) Metadata system: host os: multi-user?: sandbox: version: channels(besham): nixpkgs: Maintainer information:
This is most likely from

Discussion:
export CC="${targetCC}/bin/${targetCC.targetPrefix}cc" export CXX="${targetCC}/bin/${targetCC.targetPrefix}cxx" # Use gold to work around https://sourceware.org/bugzilla/show_bug.cgi?id=16177 <del> export LD="${targetCC.bintools}/bin/${targetCC.bintools.targetPrefix}ld.gold" </del> <ins> export LD="${targetCC.bintools}/bin/${targetCC.bintools.targetPrefix}ld${stdenv.lib.optionalString targetPlatform.isLinux ".gold"}" </ins> export AS="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}as" export AR="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}ar" export NM="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}nm"

export CXX="${targetCC}/bin/${targetCC.targetPrefix}cxx" # Use gold to work around https://sourceware.org/bugzilla/show_bug.cgi?id=16177 # and more generally have a faster linker. <del> export LD="${targetCC.bintools}/bin/${targetCC.bintools.targetPrefix}ld.gold" </del> <ins> export LD="${targetCC.bintools}/bin/${targetCC.bintools.targetPrefix}ld${stdenv.lib.optionalString targetPlatform.isLinux ".gold"}" </ins> export AS="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}as" export AR="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}ar" export NM="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}nm"
Change:
Describe the bug To Reproduce Steps to reproduce the behavior: -env -i wasm-pack Expected behavior Should install wasm-pack Additional context After add and to buildInputs works well Metadata

Discussion:
, rustPlatform , pkgconfig , openssl <ins> , curl , Security </ins> }: rustPlatform.buildRustPackage rec {

nativeBuildInputs = [ pkgconfig ]; <del> buildInputs = [ openssl ]; </del> <ins> buildInputs = [ openssl ] ++ stdenv.lib.optionals stdenv.isDarwin [ curl Security ]; </ins> # Tests fetch external resources and build artifacts. # Disabled to work with sandboxing

vttest = callPackage ../tools/misc/vttest { }; <del> wasm-pack = callPackage ../development/tools/wasm-pack { }; </del> <ins> wasm-pack = callPackage ../development/tools/wasm-pack { inherit (darwin.apple_sdk.frameworks) Security; }; </ins> wavegain = callPackage ../applications/audio/wavegain { };
Change:
(triage) solved?
If it's the same issue I'm having, it seems unrelated to unetbootin. When I run memtest (either from usb or from grub), it starts giving errors once it arrives at 53%. I tested on 3 different PC,s with 5 different ram sticks. When I run memtest86+ 5.01 (same version as nixos) from an arch install usb, all is fine.
IIRC my experience was that it didn't even start.
Could you give it a try again?

Discussion:
<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.15.2"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.15/${name}.tar.xz"; sha256 = "0g71zq6dpqrw2f40wfzdf18fdw41ymr17laqniy2kr622hkxdi8w"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>

<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.16.1"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.16/${name}.tar.xz"; sha256 = "1n708n9ixyy9qrzyv1wf4ybvcclx43ib9ki028wwpvkz6kv8zqlb"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>

{stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { <del> name = "vala-0.14.2"; </del> <ins> version = "0.17.2"; name = "vala-${version}"; </ins> src = fetchurl { <del> url = mirror://gnome/sources/vala/0.14/vala-0.14.2.tar.xz; sha256 = "1l5kllw9vpwv24lzv9fp64l3sad46wpxgvsgryrwlrjg91w6jzl0"; </del> <ins> url = "mirror://gnome/sources/vala/0.17/${name}.tar.xz"; sha256 = "09i2s0dwmrk147ind2dx7nq845g12fp6fsjqrphhrr0dbi0zzgh3"; </ins> }; buildNativeInputs = [ yacc flex pkgconfig xz ];

meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; <ins> license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; </ins> }; }

urweb = callPackage ../development/compilers/urweb { }; <del> vala = callPackage ../development/compilers/vala { }; </del> <ins> vala = vala17; vala15 = callPackage ../development/compilers/vala/15.2.nix { }; vala16 = callPackage ../development/compilers/vala/16.1.nix { }; vala17 = callPackage ../development/compilers/vala/default.nix { }; </ins> visualcpp = callPackage ../development/compilers/visual-c++ { };
Change:
Describe the bug Running qbittorrent causes the following error To Reproduce Install qbittorrent and run Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Another example of: Metadata Please run and paste the result. Maintainer information:

Discussion:
<del> { stdenv, fetchFromGitHub, pkgconfig </del> <ins> { mkDerivation, lib, fetchFromGitHub, pkgconfig </ins> , boost, libtorrentRasterbar, qtbase, qttools, qtsvg , debugSupport ? false # Debugging , guiSupport ? true, dbus ? null # GUI (disable to run headless)

}: assert guiSupport -> (dbus != null); <del> with stdenv.lib; </del> <ins> with lib; </ins> <del> stdenv.mkDerivation rec { </del> <ins> mkDerivation rec { </ins> name = "qbittorrent-${version}"; version = "4.1.7";
Change:
Describe the bug Not really a "bug", but pyprof2calltree is hard-coded to and fails for Python 3 profile results with This can be fixed by changing the expression to . Not sure what to do here, move the program to since Python 2 will be EOL anyway?
Pinging the maintainer,
As can also be used as a library it would make sense to move it into and let the default attribute be Python 3.
My PR has been merged, does this solve the issue for you?

Discussion:
<ins> { lib, buildPythonPackage, fetchFromGitHub }: buildPythonPackage rec { pname = "pyprof2calltree"; version = "1.4.4"; # Fetch from GitHub because the PyPi packaged version does not # include all test files. src = fetchFromGitHub { owner = "pwaller"; repo = "pyprof2calltree"; rev = "v" + version; sha256 = "1vrip41ib7nmkwa8rjny1na1wyp7nvvgvm0h9bd21i262kbm4nqx"; }; meta = with lib; { description = "Help visualize profiling data from cProfile with kcachegrind and qcachegrind"; homepage = https://pypi.python.org/pypi/pyprof2calltree/; license = licenses.mit; maintainers = with maintainers; [ sfrijters ]; }; } </ins>

<del> { lib, buildPythonApplication, fetchFromGitHub }: buildPythonApplication rec { pname = "pyprof2calltree"; version = "1.4.4"; # Fetch from GitHub because the PyPi packaged version does not # include all test files. src = fetchFromGitHub { owner = "pwaller"; repo = "pyprof2calltree"; rev = "v" + version; sha256 = "1vrip41ib7nmkwa8rjny1na1wyp7nvvgvm0h9bd21i262kbm4nqx"; }; meta = with lib; { description = "Help visualize profiling data from cProfile with kcachegrind and qcachegrind"; homepage = https://pypi.python.org/pypi/pyprof2calltree/; license = licenses.mit; maintainers = with maintainers; [ sfrijters ]; }; } </del>

pprof = callPackage ../development/tools/profiling/pprof { }; <del> pyprof2calltree = pythonPackages.callPackage ../development/tools/profiling/pyprof2calltree { }; </del> <ins> pyprof2calltree = with python3Packages; toPythonApplication pyprof2calltree; </ins> prelink = callPackage ../development/tools/misc/prelink { };

wget = callPackage ../development/python-modules/wget { }; runway-python = callPackage ../development/python-modules/runway-python { }; <ins> pyprof2calltree = callPackage ../development/python-modules/pyprof2calltree { }; </ins> }); in fix' (extends overrides packages)
Change:
To Reproduce Steps to reproduce the behavior: install the irony emacs package with allowBroken Expected behavior The package builds and works Additional context It has been introduced by Metadata Maintainer information: I tried to debug this but couldn't figure it out :(
Seeing this too. Not sure what is happening though /cc
It doesn't work because of what seems to be an upstream bug in tar-mode. Here's how to reproduce outside of nix: open the tar file from with emacs You'll get: According to my experimentations, it only happens when the length of the package description file name length is 32 characters (so when the version is 13 characters long). An horrific fix is to patch the version so that it's always not 13 characters long. I spent quite a bit of time trying to debug this, but it turned out being way too intense as a first common lisp experience. what do you think ?
It looks like irony- is missing from that .tar file, which is causing the error. But it does show up when I extract it with gnutar!

Discussion:
inherit (import ./libgenerated.nix lib self) melpaDerivation; super = lib.listToAttrs (map (melpaDerivation variant) (lib.importJSON archiveJson)); <del> generic = import ./melpa-generic.nix; </del> overrides = rec { shared = { # Expects bash to be at /bin/bash

# upstream issue: missing file header initsplit = markBroken super.initsplit; <del> irony = super.irony.overrideAttrs(old: { </del> <ins> irony = super.irony.overrideAttrs (old: { cmakeFlags = old.cmakeFlags or [] ++ [ "-DCMAKE_INSTALL_BINDIR=bin" ]; </ins> preConfigure = '' cd server ''; preBuild = '' make <ins> install -D bin/irony-server $out/bin/irony-server cd .. </ins> ''; <del> postInstall = '' mkdir -p $out mv $out/share/emacs/site-lisp/elpa/*/server/bin $out rm -rf $out/share/emacs/site-lisp/elpa/*/server ''; preCheck = '' </del> <ins> checkPhase = '' </ins> cd source/server <ins> make check cd ../.. </ins> ''; dontUseCmakeBuildDir = true; doCheck = true;

# Expects bash to be at /bin/bash helm-rtags = markBroken super.helm-rtags; <del> # Fails with "package does not untar cleanly into ..." irony = shared.irony.overrideAttrs(old: { meta = old.meta // { broken = true; }; }); </del> orgit = (super.orgit.overrideAttrs (attrs: { # searches for Git at build time
Change:
Describe the bug The current version of fails to build on macOS. From the error message it sounds like it believes the current macOS version is 10.10. The error message in question, from the configure phase: I suspect this was caused by which bumped our to 10.12. I have no idea why Erlang thinks the current macOS version is 10.10 (I'm running macOS 10.14). To Reproduce Steps to reproduce the behavior: macOS, run , or from a nixpkgs checkout run Expected behavior It should build. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(lily): nixpkgs: Maintainer information:
This is explicitly a problem with . I found the following in , , , and So at least it isn't a larger issue with Darwin. We should probably fix this to use . I'll work on a patch.

Discussion:
]; prePatch = '' <del> substituteInPlace configure.in --replace '`sw_vers -productVersion`' '10.10' </del> <ins> substituteInPlace configure.in --replace '`sw_vers -productVersion`' "''${MACOSX_DEPLOYMENT_TARGET:-10.12}" </ins> ''; }

sha256 = "0v2iiyzss8hiih98wvj0gi2qzdmmhh7bvc9p025wlfm4k7r1109a"; prePatch = '' <del> substituteInPlace configure.in --replace '`sw_vers -productVersion`' '10.10' </del> <ins> substituteInPlace configure.in --replace '`sw_vers -productVersion`' "''${MACOSX_DEPLOYMENT_TARGET:-10.12}" </ins> ''; }

sha256 = "1szybirrcpqsl2nmlmpbkxjqnm6i7l7bma87m5cpwi0kpvlxwmcw"; prePatch = '' <del> substituteInPlace configure.in --replace '`sw_vers -productVersion`' '10.10' </del> <ins> substituteInPlace configure.in --replace '`sw_vers -productVersion`' "''${MACOSX_DEPLOYMENT_TARGET:-10.12}" </ins> ''; }

sha256 = "1aqkhd6nwdn4xp5yz02zbymd4x8ij8fjw9ji8kh860n1a513k9ai"; prePatch = '' <del> substituteInPlace make/configure.in --replace '`sw_vers -productVersion`' '10.10' </del> <ins> substituteInPlace make/configure.in --replace '`sw_vers -productVersion`' "''${MACOSX_DEPLOYMENT_TARGET:-10.12}" </ins> substituteInPlace erts/configure.in --replace '-Wl,-no_weak_imports' "" ''; }
Change:
Describe the bug Getting the error when trying to generate a signed URL: It is more than possible that I am doing something wrong because I can see as a dependency in , and in the output when installing the package: To Reproduce Try generating a signed URL. Expected behavior It should generate a signed URL (as described at ) Metadata Thank you for looking into this!
The same issue still exists in google-cloud-sdk-255.0.0
I'm still getting this error message when running on NixOS unstable.
I guess it's probably caused by , which replaced with in . There's a comment about this change in the PR:
can confirm the error with recent pkgs: Couldn't find it in commit history nor github discussion thread. What was the comment? Knowing the reason for this change will be helpful to open a new issue.
fixes it for but gsutil is still broken due to GoogleCloudPlatform/gsutil

Discussion:
, pretend , flaky , glibcLocales <ins> , six </ins> }: with stdenv.lib;

doCheck = !stdenv.isDarwin; nativeBuildInputs = [ openssl ]; <del> propagatedBuildInputs = [ cryptography pyasn1 idna ]; </del> <ins> propagatedBuildInputs = [ cryptography pyasn1 idna six ]; </ins> checkInputs = [ pytest pretend flaky glibcLocales ]; }

#   3) used by `google-cloud-sdk` only on GCE guests # <del> { stdenv, lib, fetchurl, makeWrapper, python, cffi, cryptography, pyopenssl, crcmod, google-compute-engine, with-gce ? false }: </del> <ins> { stdenv, lib, fetchurl, makeWrapper, python, with-gce ? false }: </ins> let <del> pythonInputs = [ cffi cryptography pyopenssl crcmod ] ++ lib.optional (with-gce) google-compute-engine; pythonPath = lib.makeSearchPath python.sitePackages pythonInputs; </del> <ins> pythonEnv = python.withPackages (p: with p; [ cffi cryptography pyopenssl crcmod ] ++ lib.optional (with-gce) google-compute-engine); </ins> baseUrl = "https://dl.google.com/dl/cloudsdk/channels/rapid/downloads"; sources = name: system: {

programPath="$out/google-cloud-sdk/bin/$program" binaryPath="$out/bin/$program" wrapProgram "$programPath"  <del> --set CLOUDSDK_PYTHON "${python}/bin/python"  --prefix PYTHONPATH : "${pythonPath}" </del> <ins> --set CLOUDSDK_PYTHON "${pythonEnv}/bin/python"  --prefix PYTHONPATH : "${pythonEnv}/${python.sitePackages}" </ins> mkdir -p $out/bin ln -s $programPath $binaryPath

google-authenticator = callPackage ../os-specific/linux/google-authenticator { }; <del> google-cloud-sdk = python2.pkgs.google-cloud-sdk; google-cloud-sdk-gce = python2.pkgs.google-cloud-sdk-gce; </del> <ins> google-cloud-sdk = callPackage ../tools/admin/google-cloud-sdk { }; google-cloud-sdk-gce = google-cloud-sdk.override { with-gce = true; }; </ins> google-fonts = callPackage ../data/fonts/google-fonts { };

python-gitlab = callPackage ../development/python-modules/python-gitlab { }; <del> google-cloud-sdk = callPackage ../tools/admin/google-cloud-sdk { }; google-cloud-sdk-gce = callPackage ../tools/admin/google-cloud-sdk { with-gce=true; }; </del> google-compute-engine = callPackage ../tools/virtualization/google-compute-engine { }; google-music = callPackage ../development/python-modules/google-music { };
Change:
Describe the bug When installing viber, the download step won't complete because the package has an incorrect sha256. My nixos version is 19.03.. (Koi) To Reproduce Steps to reproduce the behavior: Ensure that you can install non-free packages: a) For you can set { = true; } in to override this. b) For , , or any other Nix command you can add { allowUnfree = true; } to then: Expected behavior Viber should install Screenshots Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
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 .
This is still reproducible. Is there an archive of Viber versions anywhere so we can pin Viber versions or do we have to constantly play catch-up with them?
I have the same issue, but in my case the SHA got is different:
I marked this as stale due to inactivity. &rarr;

Discussion:
version = "13.3.1.22"; src = fetchurl { <del> url = "https://download.cdn.viber.com/cdn/desktop/Linux/viber.deb"; </del> <ins> # Official link: https://download.cdn.viber.com/cdn/desktop/Linux/viber.deb url = "http://web.archive.org/web/20210602004133/https://download.cdn.viber.com/cdn/desktop/Linux/viber.deb"; </ins> sha256 = "0rs26x0lycavybn6k1hbb5kzms0zzcmxlrmi4g8k7vyafj6s8dqh"; };
Change:
, (nixos-unstable) (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.

Discussion:
name = "CVE-2019-1010319.patch"; sha256 = "011sqdgpykilaj2c4ns298z7aad03yprpva0dqr39nx88ji6jnrb"; }) <ins> (fetchpatch { url = "https://github.com/dbry/WavPack/commit/36a24c7881427d2e1e4dc1cef58f19eee0d13aec.patch"; name = "CVE-2018-7253.patch"; sha256 = "130kvmlpaj6x1pm6qzdzrmf4xzhp0pj29qrardb76zcfinx5pk2n"; }) (fetchpatch { url = "https://github.com/dbry/WavPack/commit/8e3fe45a7bac31d9a3b558ae0079e2d92a04799e.patch"; name = "CVE-2018-7254.patch"; sha256 = "06fdzw2cbdj8ajf171z1g53cl6bf1cdh2czswqldrqqvv3jkzk77"; }) </ins> ]; meta = with stdenv.lib; {