jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug fails. To Reproduce It will not fail immediately, but it will eventually, and it should not take long at all (see e.g for a ). Additional context Couldn't find an interesting commit in the git log since the last successful test: Notify maintainers ?
Works for me locally (1/1 attempt). I restarted the job.
BTW, the big channels are now mainly blocked by
Hmmm... Didn't work for me in the first attempt among 3.
Maybe it's still worth looking into reliability of the test but occasional restarts don't seem such a huge burden, as someone has to watch for breakages anyway.
The test is blocking nixos-unstable again. Edit: wrong link.
It was just a single attempt on Hydra and the second one succeeded. Locally it succeeded 1/1 again; perhaps it's more prone to fail on a loaded system. Well, my last comment still holds.
When I run the test locally, it fails (or rather gets stuck) once in five tries or so: It will fail eventually, as said.
Seems like this is caused by two different interfaces getting the same IP via DHCP. From the : Both and have IP , so fails. looks like this: Here, has IP as it is supposed to.
It failed again: Could somebody please look at ?
We should probably either make the test reliable or delete the test.
It passed. We should probably open a new issue if it fails again, with a focus on trying to stabilize the test .
I believe fixes it. Not sure why nobody wants to merge it. Am I shadowbanned? :)

Discussion:
extraConfig = flip concatMapStrings vlanIfs (n: '' subnet 192.168.${toString n}.0 netmask 255.255.255.0 { option routers 192.168.${toString n}.1; <del> range 192.168.${toString n}.2 192.168.${toString n}.254; </del> <ins> range 192.168.${toString n}.3 192.168.${toString n}.254; </ins> } '') ;
Change:
Describe the bug For some reason neither of nix-env, nix-build or nix-shell compile Lean standard library, i.e. there are no .olean files. This results in abysmal performance even on trivial code, because every time it needs to recompile entire library in memory. Also, there is no leanstatic.a installed. To Reproduce Steps to reproduce the behavior: Expected behavior There should be compiled .olean files. Additional context Building Lean manually using compiles standard_library by default without issues. Also, there was no such issue on older NixOS. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Turned out that compiling standard_lib was included in tests. Adding should fix the issue.
Except that 39 tests have failed :disappointed:
This patch fixes all remaining issues, which proves that in NixOS 20.09 expression for Lean is broken:

Discussion:
buildInputs = [ gmp ]; enableParallelBuilding = true; <del> preConfigure = '' cd src ''; </del> <ins> cmakeDir = "../src"; # Running the tests is required to build the *.olean files for the core # library. doCheck = true; postPatch = "patchShebangs ."; </ins> postInstall = stdenv.lib.optionalString stdenv.isDarwin '' substituteInPlace $out/bin/leanpkg
Change:
Project description ! Metadata homepage URL: source URL: license: gpl3 platforms: linux
FTR: This requires an update of .
I marked this as stale due to inactivity. &rarr;

Discussion:
<ins> { lib , stdenv , fetchFromGitHub , meson , ninja , pkg-config , wrapGAppsHook , desktop-file-utils , appstream-glib , python3Packages , glib , gtk3 , libhandy , gobject-introspection , gst_all_1 }: python3Packages.buildPythonApplication rec { pname = "blanket"; version = "0.5.0"; src = fetchFromGitHub { owner = "rafaelmardojai"; repo = "blanket"; rev = version; sha256 = "00i821zqfbigxmc709322r16z75qsw4rg23yhv35gza9sl65bzkg"; }; nativeBuildInputs = [ meson ninja pkg-config wrapGAppsHook desktop-file-utils appstream-glib ]; buildInputs = [ glib gtk3 libhandy gobject-introspection gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good gst_all_1.gst-plugins-bad ]; propagatedBuildInputs = with python3Packages; [ pygobject3 ]; # Broken with gobject-introspection setup hook # https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; format = "other"; postPatch = '' patchShebangs build-aux/meson/postinstall.py ''; meta = with lib; { homepage = "https://github.com/rafaelmardojai/blanket"; description = "Listen to different sounds"; maintainers = with maintainers; [ onny ]; license = licenses.gpl3Plus; platforms = platforms.linux; }; } </ins>

bitwise = callPackage ../tools/misc/bitwise { }; <ins> blanket = callPackage ../applications/audio/blanket { }; </ins> brakeman = callPackage ../development/tools/analysis/brakeman { }; brewtarget = libsForQt514.callPackage ../applications/misc/brewtarget { } ;
Change:
Project description Racket on Chez Scheme (Racket CS) may become the default Racket implementation in the next release [1] [1] Metadata homepage URL: https://racket- source URL: license: MIT or Apache 2.0 platforms: unix
Released:
Just a note. Reading stumbled upon the following (emphasis mine): This probably needs to be worked-around...
I thought I'd have a stab at a pull request for bumping to 8.0. It's still compiling, but right now it's looking good. I just had to bump the version number, correct the checksum and fix some hardcoded paths and their like. I'll report back when I know more! Update: There were no further problems. Upstream took care of everything :-) I confirm that I got a working drracket 8.0. Test for yourself here:

Discussion:
, libGL , libGLU , libjpeg <ins> , ncurses </ins> , libpng, libtool, mpfr, openssl, pango, poppler , readline, sqlite , disableDocs ? false

stdenv.mkDerivation rec { pname = "racket"; <del> version = "7.9"; # always change at once with ./minimal.nix </del> <ins> version = "8.0"; # always change at once with ./minimal.nix </ins> src = (lib.makeOverridable ({ name, sha256 }: fetchurl {

} )) { name = "${pname}-${version}"; <del> sha256 = "0gmp2ahmfd97nn9bwpfx9lznjmjkd042slnrrbdmyh59cqh98y2m"; </del> <ins> sha256 = "0lqqpa88v0br93qw7450a4blyi3pwn7sq2k04h0ikbsqrdnfj7lj"; </ins> }; FONTCONFIG_FILE = fontsConf;

nativeBuildInputs = [ cacert wrapGAppsHook ]; buildInputs = [ fontconfig libffi libtool sqlite gsettings-desktop-schemas gtk3 ] <del> ++ lib.optionals stdenv.isDarwin [ libiconv CoreFoundation ]; </del> <ins> ++ lib.optionals stdenv.isDarwin [ libiconv CoreFoundation ncurses ]; </ins> preConfigure = '' unset AR <del> for f in src/lt/configure src/cs/c/configure src/bc/src/string.c; do substituteInPlace "$f" --replace /usr/bin/uname ${coreutils}/bin/uname </del> <ins> for f in src/lt/configure src/cs/c/configure src/bc/src/string.c src/ChezScheme/workarea; do substituteInPlace "$f"  --replace /usr/bin/uname ${coreutils}/bin/uname  --replace /bin/cp ${coreutils}/bin/cp  --replace /bin/ln ${coreutils}/bin/ln  --replace /bin/rm ${coreutils}/bin/rm  --replace /bin/true ${coreutils}/bin/true </ins> done mkdir src/build cd src/build

name = "racket-minimal-${oldAttrs.version}"; src = oldAttrs.src.override { inherit name; <del> sha256 = "0yc5zkpq1bavj64h67pllw6mfjhmdp65fgdpyqcaan3syy6b5cia"; </del> <ins> sha256 = "0qvfi6rg9cwzh716q5j7m30rqq9xysi6zsalqlpdqrzhnx8y54k0"; </ins> }; meta = oldAttrs.meta // {
Change:
Trying to install nix-ops on macOS I get the following error (I'm using nixpkgs-unstable) Looking at old issues there were a couple on build being broken on darwin. Is it supposed to work? Using verbose, it seems to be an issue related to libvirt indeed looking at the package definition libvirt59_0 is the package broken on darwin. Perhaps it's impossible to upgrade libvirt in python2 ? I'm not an expert on python, so not sure how to move forward with this one. I'm open to testing ideas for a fix. issue open in nixops as well Metadata Please run and paste the result. Maintainer information:

Discussion:
nativeBuildInputs = [ makeWrapper pkgconfig rpcsvc-proto ]; buildInputs = [ libxml2 gnutls perl python2 readline gettext libtasn1 libgcrypt yajl <del> libxslt xhtml1 perlPackages.XMLXPath curl libpcap glib libtirpc </del> <ins> libxslt xhtml1 perlPackages.XMLXPath curl libpcap glib </ins> ] ++ optionals (!buildFromTarball) [ libtool autoconf automake ] ++ optionals stdenv.isLinux [ libpciaccess lvm2 utillinux systemd libnl numad zfs <del> libapparmor libcap_ng numactl attr parted </del> <ins> libapparmor libcap_ng numactl attr parted libtirpc </ins> ] ++ optionals (enableXen && stdenv.isLinux && stdenv.isx86_64) [ xen ] ++ optionals enableIscsi [

<del> { callPackage, fetchurl }: </del> <ins> { callPackage, fetchurl, fetchpatch }: </ins> callPackage ./generic.nix (rec { version = "1.7";

url = "https://nixos.org/releases/nixops/nixops-${version}/nixops-${version}.tar.bz2"; sha256 = "091c0b5bca57d4aa20be20e826ec161efe3aec9c788fbbcf3806a734a517f0f3"; }; <ins> patches = [ # follow redirect in nixos-infect. Remove with the next release. (fetchpatch { url = "https://github.com/NixOS/nixops/commit/fb6d4665e8efd858a215bbaaf079ec3f5ebc49b8.patch"; sha256 = "1hbhykl811zsqlaj3y5m9d8lfsal6ps6n5p16ah6lqy2s18ap9d0"; }) ]; </ins> })

# version args , src, version , meta ? {} <ins> , patches ? null </ins> }: python2Packages.buildPythonApplication { name = "nixops-${version}"; <del> inherit version src; </del> <ins> inherit version src patches; </ins> buildInputs = [ libxslt ];
Change:
Describe the bug rspamd for aarch64 can't find luajit and fails to build. To Reproduce At the moment of writing, the latest unstable seems to be . Expected behavior Build succeeds Screenshots n/a Additional context Hydra build log: Notify maintainers Metadata Maintainer information:
I managed to pinpoint the issue to the commit , where rspamd was updated from 2.5 to 2.6. Build log: It looks like rspamd is trying to find LuaJIT, but it's only available in builds. Probable fix would be disabling LuaJIT support in CMake flags.
Sorry, looks like I broke it in PR . I didn't notice the failure, probably because it showed as a grey dot instead of a red cross :x:: I'm not sure why that is, perhaps because it has both a build failure in the output (same one as you see), AND an evaluation failure

Discussion:
"-DLOGDIR=/var/log/rspamd" "-DLOCAL_CONFDIR=/etc/rspamd" "-DENABLE_JEMALLOC=ON" <del> ] ++ lib.optional withHyperscan "-DENABLE_HYPERSCAN=ON"; </del> <ins> ] ++ lib.optional withHyperscan "-DENABLE_HYPERSCAN=ON" ++ lib.optional (!withLuaJIT) "-DENABLE_LUAJIT=OFF"; </ins> passthru.tests.rspamd = nixosTests.rspamd;
Change:
Describe the bug The example given for does not seem work as expected. To Reproduce Steps to reproduce the behavior: the following to nixos-rebuild switch Expected behavior Creation of a proper ceph client configuration. Additional context I am trying to build a NixOS configuration with a minimal ceph client configuration. Metadata Maintainer information:

Discussion:
client = { enable = mkEnableOption "Ceph client configuration"; extraConfig = mkOption { <del> type = with types; attrsOf str; </del> <ins> type = with types; attrsOf (attrsOf str); </ins> default = {}; example = '' {
Change:
, CVSSv3=7.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc

Discussion:
"--enable-add-ons" "--sysconfdir=/etc" "--localedir=/var/run/current-system/sw/lib/locale" <ins> "libc_cv_ssp=no" </ins> (if kernelHeaders != null then "--with-headers=${kernelHeaders}/include" else "--without-headers")
Change:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: .

Discussion:
stdenv.mkDerivation rec { pname = "jetty"; <del> version = "9.4.35.v20201120"; </del> <ins> version = "9.4.36.v20210114"; </ins> src = fetchurl { url = "https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/${version}/jetty-distribution-${version}.tar.gz"; <del> name = "jetty-distribution-${version}.tar.gz"; sha256 = "1cpdrqz6wi7fd228lh4ijs82jq51qr5aym6vff464w3y2sd0jbav"; </del> <ins> sha256 = "1bsqxzjcdgdg2qdgc64pvrimkn9j2di2s3prlgdpbwi566744q54"; </ins> }; <del> phases = [ "unpackPhase" "installPhase" ]; </del> <ins> dontBuild = true; </ins> installPhase = '' mkdir -p $out
Change:
, CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . Cc Cc
Fixed by

Discussion:
<del> { stdenv, fetchFromGitHub, autoreconfHook, pkgconfig </del> <ins> { stdenv, fetchFromGitHub, fetchpatch, autoreconfHook, pkgconfig </ins> , ffmpeg, libjpeg, libmicrohttpd }: stdenv.mkDerivation rec {

sha256 = "08mm7ajgs0qnrydywxxyzcll09z80crjnjkjnckdi6ljsj6s96j8"; }; <ins> patches = [ (fetchpatch { name = "CVE-2020-26566.patch"; url = "https://github.com/Motion-Project/motion/commit/5c9b907ddd4d096f0485831869a29dc0fbfbb800.diff"; sha256 = "0q4yl5k5w37kgxsipxaw20mx238s50lmvhlqrsyh8w31qr3dwgx4"; excludes = [ ".travis.yml" ]; }) ]; </ins> nativeBuildInputs = [ autoreconfHook pkgconfig ]; buildInputs = [ ffmpeg libjpeg libmicrohttpd ];
Change:
, CVSSv3=7.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc
Upstream is working on fixes: and Let's mark tcpreplay as insecure if they don't land soon.

Discussion:
license = with licenses; [ bsd3 gpl3 ]; maintainers = with maintainers; [ eleanor ]; platforms = platforms.unix; <ins> knownVulnerabilities = [ "CVE-2020-24265" # https://github.com/appneta/tcpreplay/issues/616 "CVE-2020-24266" # https://github.com/appneta/tcpreplay/issues/617 ]; </ins> }; }
Change:
, CVSSv3=9.8 (nixos-20.09, nixos-unstable) CVSSv3=9.8 (nixos-20.09, nixos-unstable) CVSSv3=9.8 (nixos-20.09, nixos-unstable) CVSSv3=9.8 (nixos-20.09, nixos-unstable) CVSSv3=9.1 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=6.1 (nixos-20.09, nixos-unstable) CVSSv3=6.1 (nixos-20.09, nixos-unstable) CVSSv3=4.3 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
2 is all that is needed, but 5.5.3 doesn't work with new installations (see WP changelog)
The changelog says that 5.5.2 doesn't work. See

Discussion:
stdenv.mkDerivation rec { pname = "wordpress"; <del> version = "5.5.1"; </del> <ins> version = "5.5.3"; </ins> src = fetchurl { url = "https://wordpress.org/${pname}-${version}.tar.gz"; <del> sha256 = "15cjp48q23fw8ryy39mlxi4rd3rha2yqyrnk5mhx0h72ygawx8k6"; </del> <ins> sha256 = "sTkmdr9Mulw7XwNEMJBU81rwNV/agNpBjCznGuObrtQ="; </ins> }; installPhase = ''
Change:
Describe the bug The static build of is broken. To Reproduce Steps to reproduce the behavior: Expected behavior It builds. Screenshots See log output. Additional context In the version was bumped but the patch was not adjusted. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (+ author of ?) Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

Discussion:
nativeBuildInputs = [ cmake ]; patches = stdenv.lib.optional staticOnly (fetchpatch { <del> # from https://github.com/google/brotli/pull/655 url = "https://github.com/google/brotli/commit/7289e5a378ba13801996a84d89d8fe95c3fc4c11.patch"; sha256 = "1bghbdvj24jrvb0sqfdif9vwg7wx6pn8dvl6flkrcjkhpj0gi0jg"; </del> <ins> # context from https://github.com/google/brotli/pull/655 # updated patch from https://github.com/google/brotli/pull/655 url = "https://github.com/google/brotli/commit/47a554804ceabb899ae924aaee54df806053d0d1.patch"; sha256 = "sOeXNVsCaBSD9i82GRUDrkyreGeQ7qaJWjjy/uLL0/0="; </ins> }); cmakeFlags = []
Change:
It would be great to be able to obtain a version of postgres including debug symbols. (For people actually getting segfaults to properly report a backtrace for example. I know it doesn't seem like there are many bugs in postgres, but I'm actually running into on on version 13) It's a matter of passing the flags when building from source. so It seems that it should be another configure flag to add here However I'm not sure what's the best way to go about it, since each version should have a dbgsym version associated. perhaps just like version is inherited for every single package, add a attribute that would be defined in each package and add a new dbgsym version of each package? So far it seems to be what makes the most sense to me. I'm curious to have your opinion when you have a moment. Let me know if I'm missing anything. homepage URL: PS: completely unrelated, but it seems there is a typo here postgreql -postgresql

Discussion:
enableParallelBuilding = !stdenv.isDarwin; <ins> separateDebugInfo = true; </ins> buildFlags = [ "world" ]; NIX_CFLAGS_COMPILE = "-I${libxml2.dev}/include/libxml2";

"--sysconfdir=/etc" "--libdir=$(lib)/lib" "--with-system-tzdata=${tzdata}/share/zoneinfo" <ins> "--enable-debug" </ins> (lib.optionalString enableSystemd "--with-systemd") (if stdenv.isDarwin then "--with-uuid=e2fs" else "--with-ossp-uuid") ] ++ lib.optionals icuEnabled [ "--with-icu" ];

]; buildInputs = [ makeWrapper ]; # We include /bin to ensure the $out/bin directory is created, which is # needed because we'll be removing the files from that directory in postBuild # below. See #22653
Change:
At the moment this seems to be the neatest way: Sadly this doesn't work:
This is a bit better, neat enough for me to close the issue :)
Better yet: This doesn't generate the exact same derivation, but it's functionally the same:

Discussion:
# a cabal flag with '--flag=myflag'. developPackage = { root <del> , name ? builtins.baseNameOf root </del> <ins> , name ? if builtins.typeOf root == "path" then builtins.baseNameOf root else "" </ins> , source-overrides ? {} , overrides ? self: super: {} , modifier ? drv: drv
Change:
Describe the bug yq fails to install with the latest nixpkgs and/or version. To Reproduce Steps to reproduce the behavior: -channel --update; nix-env -iA -env -i yq Expected behavior Installs without error. Additional context I had previously happily installed yq with an older nixpkgs-unstable. Upgrading myPackages failed with yq included. So I excluded it to proceed. Attempting to re-install it individually fails with an illegal arg. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:

Discussion:
, flake8 , jq , pytest <del> , unixtools </del> , toml }:

sha256 = "1q4rky0a6n4izmq7slb91a54g8swry1xrbfqxwc8lkd3hhvlxxkl"; }; <ins> postPatch = '' substituteInPlace test/test.py --replace "expect_exit_codes={0} if sys.stdin.isatty() else {2}" "expect_exit_codes={0}" ''; </ins> propagatedBuildInputs = [ pyyaml xmltodict

doCheck = true; checkInputs = [ <del> unixtools.script </del> pytest coverage flake8

toml ]; <del> # tests fails if stdin is not a tty checkPhase = "echo | script -c 'pytest ./test/test.py'"; </del> <ins> checkPhase = "pytest ./test/test.py"; </ins> pythonImportsCheck = [ "yq" ];
Change:
Describe the bug While the configuration contains no settings related to LVM, is launched during boot, and so on, and the "lvm2-activation-generator: lvmconfig failed" message is logged in the journal. Expected behavior At least, does not produce error messages. It might be better if the service is not activated if the system does not use LVM at all. Additional context may or may not be relevant. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cc
I'll try to find some time to look into this, as I might be responsible for this.
I got this error when running in the console. It just froze, didn't reboot. Hitting enter put me back into the shell. Doing shutdown -h now worked. Very strange ..
I strongly suspect that your freeze was not caused by this warning message.
Yeah, so this was most likely caused by , which combined with the rest of leads to systemd being aware of lvm2 things. lvm2 was already in and for anything that's not a container, before this, but now it's also in . As for why this happens, it looks like it's , which fails when does not return what it expects. Since we do not install the default lvm config, it fails like so: The easiest solution to this is probably to install the default config file to . There is a problem with that though. If we use , we cannot use anymore to append any settings. We also cannot "copy" the defaults into e.g. with , because that would be import from derivation. So the remaining option is to simply set some default settings, which also kind of sucks, because then we need to track upstream on those, but it's probably our best option. If you have any other/better ideas, I'd gladly go for those, but if nobody does, I'll go with specifying some defaults, in a few days.
+1 to importing upstream defaults as it seems the safest option if it tracks upstream properly, even though it will certainly increase the maintenance cost.
I also would just create a default configuration if it is not possible to disable lvm2-activation-generator somehow if lvm is not used.
Detecting if lvm is used sadly isn't trivial. For filesystems (in ) we can just look at the and enable the respective kernel modules and tools, but how would that be done for lvm?
Maybe it would be possible to fix/patch(&upstream) the generator?
lvm seems to have its default hard coded so we don't need to copy over the whole file. To fix the loading error I just an almost empty configuration to make the warning go away:

Discussion:
}; config = mkMerge [ <ins> ({ # minimal configuration file to make lvmconfig/lvm2-activation-generator happy environment.etc."lvm/lvm.conf".text = "config {}"; }) </ins> (mkIf (!config.boot.isContainer) { systemd.tmpfiles.packages = [ cfg.package.out ]; environment.systemPackages = [ cfg.package ];
Change:
Describe the bug Notify maintainers
Had a play with this. Looks like at the moment it's trying to link against , passing causes it to try to link against libstdc++.a from the wrong directory
is present in libtool's lib search paths, , and . Albeit after the directory containing and . I'm not sure if the order is important.
yikes, has , no wonder things are trying to link against
Indeed, if I change 's to point to it all works fine,
This looks like the same error I'm getting in , is this the best solution for this at this point? Unfortunately what I'm trying to build is based on cmake rather than make, so I don't know if this will be directly applicable.
Yeah. The fix for this one here is probably not directly applicable to a cmake project. Weird that someone got into that mess using cmake.
My bad - even though protobuf includes cmake files, the build actually seems to be based on automake(?). However I attempted a similar patch using sed, but the protobuf *.la files don't appear to exist yet by the preBuild hook.

Discussion:
# fix build with gcc9 NIX_CFLAGS_LINK = lib.optional (stdenv.system == "i686-linux") "-lgcc"; <ins> # Even when statically linking, libstdc++.la is put in dependency_libs here, # and hence libstdc++.so passed to the linker, just pass -lstdc++ and let the # compiler do what it does best.  (libaudiofile.la is a generated file, so we # have to run `make` that far first). # # Without this, the executables in this package (sfcommands and examples) # fail to build: https://github.com/NixOS/nixpkgs/issues/103215 # # There might be a more sensible way to do this with autotools, but I am not # smart enough to discover it. preBuild = lib.optionalString stdenv.targetPlatform.isStatic '' make -C libaudiofile $makeFlags sed -i "s/dependency_libs=.*/dependency_libs=' -lstdc++'/" libaudiofile/libaudiofile.la ''; </ins> patches = [ ./gcc-6.patch ./CVE-2015-7747.patch