jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug Neovim crashes when resizing windows under some circumstances. To Reproduce There are many different ways to repro, these are some reliable steps to reproduce the behavior: to create a split to open a terminal to go to other window to maximize window Expected behavior Windows should resize and there should be no crash. Additional context Originally filed at but it seems to only be affecting NixOS. The crashes only started since I upgraded from NixOS 19.03 to 19.09. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: cc
If you have a known-good nixos revision and a known-bad nixos revision you could try the issue.
The earliest local generation on which this happens is from . The latest known-good generation is from . I'm not sure these are accurate though, I'd have expected this to have happened later.
narrowed it down to which was part of
That looks helpful. Maybe you can report upstream that the libvterm update is responsible, and ask if someone on non-nixos can reproduce it with that version of libvterm (or report which version they use).
Thanks for guiding me in the right path I opened a PR with a fix. :point_up:
Thanks for fixing this :)

Related discussion:
text: stdenv.mkDerivation { pname = "libvterm-neovim"; <del> version = "2019-08-28"; </del> <ins> version = "2019-10-08"; </ins> src = fetchFromGitHub { owner = "neovim"; repo = "libvterm"; <del> rev = "1aa95e24d8f07a396aa80b7cd52f93e2b5bcca79"; sha256 = "0vjd397lqrfv4kc79i5izva4bynbymx3gllkg281fnk0b15vxfif"; </del> <ins> rev = "7c72294d84ce20da4c27362dbd7fa4b08cfc91da"; sha256 = "111qyxq33x74dwdnqcnzlv9j0n8hxyribd6ppwcsxmyrniyw9qrk"; </ins> }; buildInputs = [ perl ];
Code change:
Project description A cross-platform SSH client with cloud data sync and more. Metadata homepage URL: source URL: license: unfree platforms: linux
It would be really cool, I need it too!

Related discussion:
text: <ins> { atomEnv , autoPatchelfHook , dpkg , fetchurl , makeDesktopItem , makeWrapper , stdenv , udev , wrapGAppsHook }: stdenv.mkDerivation rec { pname = "termius"; version = "5.10.1"; src = fetchurl { url = "https://deb.termius.com/pool/main/t/termius-app/termius-app_${version}_amd64.deb"; sha256 = "04zh0zzyp906lf6mz3xzxybn2a55rv3vvrj0m12gnrb8kjb3pk5s"; }; desktopItem = makeDesktopItem { categories = "Network;"; comment = "The SSH client that works on Desktop and Mobile"; desktopName = "Termius"; exec = "termius-app"; genericName = "Cross-platform SSH client"; icon = "termius-app"; name = "termius-app"; }; dontBuild = true; dontConfigure = true; dontPatchELF = true; dontWrapGApps = true; nativeBuildInputs = [ autoPatchelfHook dpkg makeWrapper wrapGAppsHook ]; buildInputs = atomEnv.packages; unpackPhase = "dpkg-deb -x $src ."; installPhase = '' mkdir -p "$out/bin" cp -R "opt" "$out" cp -R "usr/share" "$out/share" chmod -R g-w "$out" # Desktop file mkdir -p "$out/share/applications" cp "${desktopItem}/share/applications/"* "$out/share/applications" ''; runtimeDependencies = [ udev.lib ]; postFixup = '' makeWrapper $out/opt/Termius/termius-app $out/bin/termius-app  "''${gappsWrapperArgs[@]}" ''; meta = with stdenv.lib; { description = "A cross-platform SSH client with cloud data sync and more"; homepage = "https://termius.com/"; downloadPage = "https://termius.com/linux/"; license = licenses.unfree; maintainers = with maintainers; [ filalex77 ]; platforms = [ "x86_64-linux" ]; }; } </ins>
Code change:
Project description A cross-platform SSH client with cloud data sync and more. Metadata homepage URL: source URL: license: unfree platforms: linux
It would be really cool, I need it too!

Related discussion:
text: pythonPackages = python3Packages; }; <ins> termius = callPackage ../applications/networking/termius { }; </ins> termplay = callPackage ../tools/misc/termplay { }; tewisay = callPackage ../tools/misc/tewisay { };
Code change:
I was getting errors with the version of dvisvgm bundled with texlive 2019 so I created a separate, texlive-independent version which works well. (If you're curious about the issue I was seeing it was related to compatibility between ghostscript and dvisvgm. I can be more specific if anyone wants, but reporting that issue is not the main purpose of this). Here's the build expression I'm using ( is ): How would people feel about a PR with a dvisvgm package uncoupled from the texlive version in addition to the one currently there? I could name it or or something like that. Note that I'm currently using this as a separate build expression but for a PR I'd put it in the texlive bin nix file. Note also that this package can be used identically to any other texlive package. The only difference to the end user is to get an option of a newer version.
What is the issue, though?
it's been reported . The issue is apparently fixed in dvisvgm 2.7.2 (ours is 2.6.3). Here's an additional MWE to test. The same example with v2.8.1 (in the build expression above) works fine.
So what you say, is that our dvisvgm is broken because of the incompatible ghostscript version. Then, I think, we should be fixing dvisvgm for all of our users, not just those who opt into using the separate package you propose. I would prefer to just patch the version from texlive, but, unfortunately, doesn't apply cleanly, so we would have to craft our own patch or pin to 2.8.1 (in this case, need to leave a TODO comment to remind to unpin for texlive 2020).
To clarify, the idea is to generate a patch from a newer texlive version of dvisvgm and apply that to the existing derivation (along with the code comment about this being a temporary fix until 2020)?
Does fix the issue for you?

Related discussion:
text: inherit (common) src; <ins> patches = [ # Fix for ghostscript>=9.27 # Backport of # https://github.com/mgieseki/dvisvgm/commit/bc51951bc90b700c28ea018993bdb058e5271e9b ./dvisvgm-fix.patch # Needed for ghostscript>=9.50 (fetchpatch { url = "https://github.com/mgieseki/dvisvgm/commit/7b93a9197b69305429183affd24fa40ee04a663a.patch"; sha256 = "1gmj76ja9xng39wxckhs9q140abixgb8rkrcfv2cdgq786wm3vag"; stripLen = 1; extraPrefix = "texk/dvisvgm/dvisvgm-src/"; }) ]; </ins> nativeBuildInputs = [ pkgconfig ]; # TODO: dvisvgm still uses vendored dependencies <del> buildInputs = [ core/*kpathsea*/ ghostscript zlib freetype potrace xxHash ]; </del> <ins> buildInputs = [ core/*kpathsea*/ ghostscript zlib freetype /*potrace xxHash*/ ]; </ins> preConfigure = "cd texk/dvisvgm";
Code change:
I was getting errors with the version of dvisvgm bundled with texlive 2019 so I created a separate, texlive-independent version which works well. (If you're curious about the issue I was seeing it was related to compatibility between ghostscript and dvisvgm. I can be more specific if anyone wants, but reporting that issue is not the main purpose of this). Here's the build expression I'm using ( is ): How would people feel about a PR with a dvisvgm package uncoupled from the texlive version in addition to the one currently there? I could name it or or something like that. Note that I'm currently using this as a separate build expression but for a PR I'd put it in the texlive bin nix file. Note also that this package can be used identically to any other texlive package. The only difference to the end user is to get an option of a newer version.
What is the issue, though?
it's been reported . The issue is apparently fixed in dvisvgm 2.7.2 (ours is 2.6.3). Here's an additional MWE to test. The same example with v2.8.1 (in the build expression above) works fine.
So what you say, is that our dvisvgm is broken because of the incompatible ghostscript version. Then, I think, we should be fixing dvisvgm for all of our users, not just those who opt into using the separate package you propose. I would prefer to just patch the version from texlive, but, unfortunately, doesn't apply cleanly, so we would have to craft our own patch or pin to 2.8.1 (in this case, need to leave a TODO comment to remind to unpin for texlive 2020).
To clarify, the idea is to generate a patch from a newer texlive version of dvisvgm and apply that to the existing derivation (along with the code comment about this being a temporary fix until 2020)?
Does fix the issue for you?

Related discussion:
text: <ins> diff a/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp b/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp --- a/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp +++ b/texk/dvisvgm/dvisvgm-src/src/psdefs.cpp @@ -107,8 +107,7 @@ const char *PSInterpreter::PSDEFS = "dmode sysexec<</Normal 0/Compatible 0/Multiply 1/Screen 2/Overlay 3/SoftLight " "4/HardLight 5/ColorDodge 6/ColorBurn 7/Darken 8/Lighten 9/Difference 10/Exclus" "ion 11/Hue 12/Saturation 13/Color 14/Luminosity 15/CompatibleOverprint 16>>exc" -"h get 1(setblendmode)prcmd}def/@pdfpagecount{GS_PDF_ProcSet begin pdfdict begi" -"n(r)file pdfopen begin pdfpagecount currentdict pdfclose end end end}def/@pdfp" -"agebox{GS_PDF_ProcSet begin pdfdict begin(r)file pdfopen begin dup dup 1 lt ex" -"ch pdfpagecount gt or{pop}{pdfgetpage/MediaBox pget pop aload pop}ifelse curre" -"ntdict pdfclose end end end}def DELAYBIND{.bindnow}if "; +"h get 1(setblendmode)prcmd}def/@pdfpagecount{(r)file runpdfbegin pdfpagecount " +"runpdfend}def/@pdfpagebox{(r)file runpdfbegin dup dup 1 lt exch pdfpagecount g" +"t or{pop}{pdfgetpage/MediaBox pget pop aload pop}ifelse runpdfend}def DELAYBIN" +"D{.bindnow}if "; </ins>
Code change:
, CVSSv3=9.8 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
Unstable/master: PR ; 19.09: (staging ATM, but should get into channel within days).

Related discussion:
text: # Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Code change:
Describe the bug Fails to build with some not-supported instructions: <details</detailsTo Reproduce Steps to reproduce the behavior: (on an aarch64 machine) Expected behavior Kernel builds Maintainer information: May be caused by
Fixed already by bumping to 5.4.x, 19.09 channel just hasn't caught up yet.
Never mind, I'm not very good at interpreting bisects.
I had the same issue (I think?) when trying to install NixOS 19.09 on Raspberry Pi 3B+
Fixed in .

Related discussion:
text: # Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Code change:
Describe the bug NixOS manual combined fails to build since commit . This was introduced by the changes to the package awstats. This is the output: To Reproduce Steps to reproduce the behavior: Expected behavior It should be possible to build the nixos-manual-combined without errors. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(terje): nixpkgs:
this issue was resolved in there is one more issue with docs - a warning What should it be? You can test manual builds with
this was my mistake :disappointed: I had the entry to the manual. Unfortunately I confused myself by checking the manual on another PR, and then thinking I had checked the manual for the PR. The issue was compounded by me being rather occupied on Christmas day (mostly with only cell phone but no computer), which I supposed in hindsight was a reason I shouldn't have merged the change on Christmas eve after the kids were in bed. I apologize for all the hassle. It looks like the option lost its during this PR... another thing I would have noticed if I had checked the manual... When is back they can create a PR to add a description along the lines of , unless this pressing enough you want me to file a PR today. Thanks again to all who helped out on this!
no pressure!
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: "ValidHTTPCodes" = "404"; } ''; <ins> description = "Extra configuration to be appendend to awstats.${name}.conf."; </ins> }; webService = {
Code change:
Project description A tiny IRC client Metadata homepage URL: source URL: license: mit platforms: linux

Related discussion:
text: <ins> { stdenv , lib , rustPlatform , fetchpatch , fetchFromGitHub , pkg-config , dbus , openssl }: rustPlatform.buildRustPackage rec { pname = "tiny"; version = "0.5.1"; src = fetchFromGitHub { owner = "osa1"; repo = pname; rev = "v${version}"; sha256 = "1m57xsrc7lzkrm8k1wh3yx3in5bhd0qjzygxdwr8lvigpsiy5caa"; }; cargoSha256 = "1vj6whnx8gd5r66zric9163ddlqc4al4azj0dvhv5sq0r33871kv"; RUSTC_BOOTSTRAP = 1; nativeBuildInputs = lib.optional stdenv.isLinux pkg-config; buildInputs = lib.optionals stdenv.isLinux [ dbus openssl ]; meta = with lib; { description = "A console IRC client"; homepage = "https://github.com/osa1/tiny"; license = licenses.mit; maintainers = with maintainers; [ filalex77 ]; }; } </ins>
Code change:
Project description A tiny IRC client Metadata homepage URL: source URL: license: mit platforms: linux

Related discussion:
text: tint2 = callPackage ../applications/misc/tint2 { }; <ins> tiny = callPackage ../applications/networking/irc/tiny { }; </ins> tixati = callPackage ../applications/networking/p2p/tixati { }; tkcvs = callPackage ../applications/version-management/tkcvs { };
Code change:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

Related discussion:
text: , lib , buildGoPackage , fetchFromGitHub <del> , openssl_1_0_2 </del> <ins> , openssl </ins> , pkgconfig , libpcap }:
Code change:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

Related discussion:
text: }; nativeBuildInputs = [ pkgconfig ]; <del> buildInputs = [ openssl_1_0_2 libpcap ]; </del> <ins> buildInputs = [ openssl libpcap ]; </ins> # Mongodb incorrectly names all of their binaries main # Let's work around this with our own installer
Code change:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

Related discussion:
text: <del> { stdenv, fetchFromGitHub, cmake, boost, openssl, asio }: </del> <ins> { stdenv, fetchFromGitHub, cmake, boost, openssl }: </ins> stdenv.mkDerivation rec { pname = "cpp-netlib";
Code change:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

Related discussion:
text: buildInputs = [ cmake boost openssl ]; <del> # This can be removed when updating to 0.13, see https://github.com/cpp-netlib/cpp-netlib/issues/629 propagatedBuildInputs = [ asio ]; </del> cmakeFlags = [ "-DCPP-NETLIB_BUILD_SHARED_LIBS=ON" ]; enableParallelBuilding = true; <ins> # The test driver binary lacks an RPath to the library's libs preCheck = '' export LD_LIBRARY_PATH=$PWD/libs/network/src ''; # Most tests make network GET requests to various websites doCheck = false; </ins> meta = with stdenv.lib; { <del> description = "Collection of open-source libraries for high level network programming"; </del> <ins> description = "Collection of open-source libraries for high level network programming"; </ins> homepage    = https://cpp-netlib.org; license     = licenses.boost; platforms   = platforms.all;
Code change:
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:

Related discussion:
text: cpp-ipfs-api = callPackage ../development/libraries/cpp-ipfs-api { }; <del> cpp-netlib = callPackage ../development/libraries/cpp-netlib { openssl = openssl_1_0_2; }; </del> <ins> cpp-netlib = callPackage ../development/libraries/cpp-netlib {}; </ins> uri = callPackage ../development/libraries/uri { }; cppcms = callPackage ../development/libraries/cppcms { };
Code change:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you

Related discussion:
text: , python , mkDerivation , stdenv <del> , isPy3k </del> }: let compyte = import ./compyte.nix {
Code change:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you

Related discussion:
text: sha256 = "ada56ce98a41f9f95fe18809f38afbae473a5c62d346cfa126a2d5477f24cc8a"; }; <del> preConfigure = '' </del> <ins> preConfigure = with stdenv.lib.versions; '' </ins> ${python.interpreter} configure.py --boost-inc-dir=${boost.dev}/include  --boost-lib-dir=${boost}/lib  --no-use-shipped-boost  <del> --boost-python-libname=boost_python${stdenv.lib.optionalString isPy3k "3"} </del> <ins> --boost-python-libname=boost_python${major python.version}${minor python.version}  --cuda-root=${cudatoolkit} </ins> ''; postInstall = ''
Code change:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you

Related discussion:
text: pycares = callPackage ../development/python-modules/pycares { }; pycuda = callPackage ../development/python-modules/pycuda { <del> cudatoolkit = pkgs.cudatoolkit_7_5; </del> <ins> cudatoolkit = pkgs.cudatoolkit; </ins> inherit (pkgs.stdenv) mkDerivation; };