jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by

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 Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by

Related discussion:
text: , lib , buildPythonPackage , fetchPypi <ins> , fetchpatch </ins> , gfortran, glibcLocales , numpy, scipy, pytest, pillow , cython
Code change:
Describe the bug Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by

Related discussion:
text: ]; checkInputs = [ pytest ]; <ins> patches = [ # Fixes tests by changing threshold of a test-case that broke # with numpy versions >= 1.17. This should be removed for versions > 0.21.2. ( fetchpatch { url = "https://github.com/scikit-learn/scikit-learn/commit/b730befc821caec5b984d9ff3aa7bc4bd7f4d9bb.patch"; sha256 = "0z36m05mv6d494qwq0688rgwa7c4bbnm5s2rcjlrp29fwn3fy1bv"; }) ]; </ins> LC_ALL="en_US.UTF-8"; doCheck = !stdenv.isAarch64;
Code change:
, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.

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:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

Related discussion:
text: { fetchFromGitHub, stdenv, cmake, openssl, zlib, libuv }: <del> stdenv.mkDerivation rec { pname = "libwebsockets"; version = "3.2.0"; src = fetchFromGitHub { owner = "warmcat"; repo = "libwebsockets"; rev = "v${version}"; sha256 = "0ac5755h3w1pl6cznqbvg63dwkqy544fqlhvqyp7s11hgs7jx6l8"; </del> <ins> let generic = { version, sha256 }: stdenv.mkDerivation rec { pname = "libwebsockets"; inherit version; src = fetchFromGitHub { owner = "warmcat"; repo = "libwebsockets"; rev = "v${version}"; inherit sha256; }; buildInputs = [ openssl zlib libuv ]; nativeBuildInputs = [ cmake ]; cmakeFlags = [ "-DLWS_WITH_PLUGINS=ON" ]; meta = with stdenv.lib; { description = "Light, portable C library for websockets"; longDescription = '' Libwebsockets is a lightweight pure C library built to use minimal CPU and memory resources, and provide fast throughput in both directions. ''; homepage = "https://libwebsockets.org/"; license = licenses.lgpl21; platforms = platforms.all; }; </ins> }; <del> buildInputs = [ cmake openssl zlib libuv ]; cmakeFlags = [ "-DLWS_WITH_PLUGINS=ON" ]; meta = { description = "Light, portable C library for websockets"; longDescription = '' Libwebsockets is a lightweight pure C library built to use minimal CPU and memory resources, and provide fast throughput in both directions. ''; homepage = https://github.com/warmcat/libwebsockets; license = stdenv.lib.licenses.lgpl21; platforms = stdenv.lib.platforms.all; </del> <ins> in rec { libwebsockets_3_1 = generic { sha256 = "1w1wz6snf3cmcpa3f4dci2nz9za2f5rrylxl109id7bcb36xhbdl"; version = "3.1.0"; </ins> }; <ins> libwebsockets_3_2 = generic { version = "3.2.0"; sha256 = "0ac5755h3w1pl6cznqbvg63dwkqy544fqlhvqyp7s11hgs7jx6l8"; }; libwebsockets = libwebsockets_3_2; </ins> }
Code change:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

Related discussion:
text: { stdenv, lib, fetchFromGitHub, cmake, docbook_xsl, libxslt <del> , openssl, libuuid, libwebsockets, c-ares, libuv </del> <ins> , openssl, libuuid, libwebsockets_3_1, c-ares, libuv </ins> , systemd ? null, withSystemd ? stdenv.isLinux }: stdenv.mkDerivation rec { pname = "mosquitto"; <del> version = "1.6.4"; </del> <ins> version = "1.6.5"; </ins> src = fetchFromGitHub { owner  = "eclipse"; repo   = "mosquitto"; rev    = "v${version}"; <del> sha256 = "1kr1dgc4nzhyg3rzymbv4rka3rpb30rwsy6binb7apnw3n3ff58l"; </del> <ins> sha256 = "0scgsi3rvs9s8vxv4r7d5d9ixbsfg4dwnjcy6zxwdz9dfn8qnngj"; </ins> }; postPatch = ''
Code change:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

Related discussion:
text: ''; buildInputs = [ <del> openssl libuuid libwebsockets c-ares libuv </del> <ins> openssl libuuid libwebsockets_3_1 c-ares libuv </ins> ] ++ lib.optional withSystemd systemd; nativeBuildInputs = [ cmake docbook_xsl libxslt ];
Code change:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

Related discussion:
text: meta = with stdenv.lib; { description = "An open source MQTT v3.1/3.1.1 broker"; <del> homepage = http://mosquitto.org/; </del> <ins> homepage = "https://mosquitto.org/"; </ins> license = licenses.epl10; maintainers = with maintainers; [ peterhoeg ]; platforms = platforms.unix;
Code change:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!

Related discussion:
text: librest = callPackage ../development/libraries/librest { }; <del> libwebsockets = callPackage ../development/libraries/libwebsockets { }; </del> <ins> inherit (callPackages ../development/libraries/libwebsockets { }) libwebsockets_3_1 libwebsockets_3_2 libwebsockets; </ins> lidarr = callPackage ../servers/lidarr { };
Code change:
Describe the bug On opening Anki, I get this error My guess is the fix would be similar to (add ).
Intermediate fix: I put this in my in :

Related discussion:
text: propagatedBuildInputs = [ pyqtwebengine sqlalchemy beautifulsoup4 send2trash pyaudio requests decorator <del> markdown jsonschema </del> <ins> markdown jsonschema setuptools </ins> ] ++ lib.optional plotsSupport matplotlib ++ lib.optional stdenv.isDarwin [ CoreAudio ]
Code change:
I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
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 . 3. Ask on the on .
It would be nice to hear about the recent progress.

Related discussion:
text: , xkeyboard_config , udisks2 <ins> , waylandSupport ? false, wayland-protocols, xwayland </ins> , bluetoothSupport ? true, bluez5 , pulseSupport ? !stdenv.isDarwin, libpulseaudio }:
Code change:
I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
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 . 3. Ask on the on .
It would be nice to hear about the recent progress.

Related discussion:
text: ] ++ lib.optional bluetoothSupport bluez5 # for bluetooth configuration and control ++ lib.optional pulseSupport libpulseaudio # for proper audio device control and redirection <ins> ++ lib.optionals waylandSupport [ wayland-protocols xwayland ] </ins> ; patches = [
Code change:
I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
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 . 3. Ask on the on .
It would be nice to hear about the recent progress.

Related discussion:
text: mesonFlags = [ "-D systemdunitdir=lib/systemd/user" <del> ]; </del> <ins> ] ++ lib.optional waylandSupport "-Dwl=true"; </ins> passthru.providedSessions = [ "enlightenment" ];
Code change:
I am by no means an expert on database systems, so this may be a stupid question ... but I can't help wondering why does not refer to PostgreSQL version 11 on current versions of ? Is there a reason we haven't updated yet?
Maybe or can answer this... :thinking:
Good question. In my case I'm no longer using PostgreSQL 9 by myself and switched to 10 and 11 a long time ago, but I also wasn't aware of this because I'm not using the module from NixOS in my deployments.
Made a PR for that... If you think it's too rush to include it to 19.09, then I can delay it to 20.03 As for , it really shouldn't be used. It should be split to , and , and / may be continuosly updated, but should be used only with explicit version. But this server/client split is not straightforward, so it was not yet done.

Related discussion:
text: postgresql_10 postgresql_11 ; <del> postgresql = postgresql_9_6.override { this = postgresql; }; </del> <ins> postgresql = postgresql_11.override { this = postgresql; }; </ins> postgresqlPackages = recurseIntoAttrs postgresql.pkgs; <del> postgresql11Packages = recurseIntoAttrs postgresql_11.pkgs; </del> <ins> postgresql11Packages = pkgs.postgresqlPackages; </ins> postgresql_jdbc = callPackage ../development/java-modules/postgresql_jdbc { };
Code change:
Describe the bug to the find call. This prevents things in the that are symlinks from being wrapped. Noticed this during office-hours when wasn't wrapped anymore. We should add some code like there is in or revert the . To Reproduce Steps to reproduce the behavior: a binary into or the thing and notice the binary isn't wrapped.

Related discussion:
text: do [ -d "$targetDir" ] || continue <del> find "$targetDir" -type f -executable -print0 | while IFS= read -r -d '' file </del> <ins> find "$targetDir" ! -type d -executable -print0 | while IFS= read -r -d '' file </ins> do patchelf --print-interpreter "$file" >/dev/null 2>&1 || continue
Code change:
Describe the bug In , if you enable both xserver.services.desktopManager.plasma5 and , assertion fails. Failed assertions: cmt and libinput are incompatible, you cannot enable both (in services.xserver). To Reproduce Steps to reproduce the behavior: both and Expected behavior Failed assertion should happen Additional context Build with works fine. Metadata Maintainer information: kcalvinalvin a list of nixpkgs attributes affected by the problem a list of nixos modules affected by the problem
Found the culprit. Can we disable by default so that users can choose? The default generated has the option by default so I don't see the reason why it needs to also be defaulted in

Related discussion:
text: assertions = [ { assertion = !config.services.xserver.libinput.enable; <del> message = "cmt and libinput are incompatible, you cannot enable both (in services.xserver)."; </del> <ins> message = '' cmt and libinput are incompatible, meaning you cannot enable them both. To use cmt you need to disable libinput with `services.xserver.libinput.enable = false` If you haven't enabled it in configuration.nix, it's enabled by default on a different xserver module. ''; </ins> } ]; };
Code change:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!

Related discussion:
text: <ins> diff --git a/configure.py b/configure.py index 25ca951ac..454140420 100755 --- a/configure.py +++ b/configure.py @@ -36,13 +36,16 @@ tempfile.tempdir = "./build/tmp" configure_args = str.join(' ', [shlex.quote(x) for x in sys.argv[1:]]) -for line in open('/etc/os-release'): -    key, _, value = line.partition('=') -    value = value.strip().strip('"') -    if key == 'ID': -        os_ids = [value] -    if key == 'ID_LIKE': -        os_ids += value.split(' ') +try: +    for line in open('/etc/os-release'): +        key, _, value = line.partition('=') +        value = value.strip().strip('"') +        if key == 'ID': +            os_ids = [value] +        if key == 'ID_LIKE': +            os_ids += value.split(' ') +except FileNotFoundError: +    os_ids = ["linux"] # distribution "internationalization", converting package names. </ins>
Code change:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!

Related discussion:
text: fetchSubmodules = true; }; <del> patches = [ ./seastar-configure-script-paths.patch ]; </del> <ins> patches = [ ./seastar-configure-script-paths.patch ./configure-etc-osrelease.patch ]; </ins> nativeBuildInputs = [ pkgconfig
Code change:
seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!

Related discussion:
text: postPatch = '' patchShebangs ./configure.py <ins> patchShebangs seastar/json/json2code.py </ins> ''; configurePhase = '' ./configure.py --mode=release ''; installPhase = '' mkdir $out cp -r * $out/ ''; meta = with stdenv.lib; { description = "NoSQL data store using the seastar framework, compatible with Apache Cassandra"; homepage = "https://scylladb.com";
Code change:
Describe the bug is broken on Darwin. git bisect shows (part of ) as the first failing commit To Reproduce Try to build on Darwin at <details<summarynix-build -A gobject-introspection </summary</detailsExpected behavior Able to build on Darwin Additional context <!-- There is a 10 years old bug report with the same error message --Metadata Maintainer information: cc:
Looks like this upstream issue: . It's fixed on master so we should probably pick the patches.
Our jobset needs to be building on the darwin platform if we don't want things breaking like this.

Related discussion:
text: , doCheck ? config.doCheckByDefault or false , coreutils, dbus, libxml2, tzdata , desktop-file-utils, shared-mime-info <del> , darwin </del> <ins> , darwin, fetchpatch </ins> }: with stdenv.lib;