jiebi/CodeConvo huggingface dataset:
Code change:
I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...

Related discussion:
text: uudeview = callPackage ../tools/misc/uudeview { }; <ins> uutils-coreutils = callPackage ../tools/misc/uutils-coreutils { inherit (pythonPackages) sphinx; }; </ins> zabbix-cli = callPackage ../tools/misc/zabbix-cli { }; ### DEVELOPMENT / EMSCRIPTEN
Code change:
Steps to reproduce the behavior: curaengine This was on an update yesterday to . Please run and paste the result.
I opened a PR yesterday:

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, cmake, libarcus, stb, protobuf }: </del> <ins> { lib, stdenv, fetchFromGitHub, cmake, libarcus, stb, protobuf, fetchpatch }: </ins> stdenv.mkDerivation rec { pname = "curaengine";
Code change:
Steps to reproduce the behavior: curaengine This was on an update yesterday to . Please run and paste the result.
I opened a PR yesterday:

Related discussion:
text: cmakeFlags = [ "-DCURA_ENGINE_VERSION=${version}" ]; <ins> # TODO already fixed in master, remove in next release patches = [ (fetchpatch { url = "https://github.com/Ultimaker/CuraEngine/commit/de60e86a6ea11cb7d121471b5dd192e5deac0f3d.patch"; hash = "sha256-/gT9yErIDDYAXvZ6vX5TGlwljy31K563+sqkm1UGljQ="; includes = [ "src/utils/math.h" ]; }) ]; </ins> meta = with lib; { description = "A powerful, fast and robust engine for processing 3D models into 3D printing instruction"; homepage = "https://github.com/Ultimaker/CuraEngine";
Code change:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: <del> { lib , stdenv , callPackage , fetchFromGitHub , testers , enableE57 ? lib.meta.availableOn stdenv.hostPlatform libe57format , cmake , curl , gdal , hdf5-cpp , LASzip , libe57format , libgeotiff , libtiff , libxml2 , openscenegraph , pkg-config , postgresql , tiledb , xercesc , zlib , zstd }: stdenv.mkDerivation (finalAttrs: { pname = "pdal"; version = "2.5.6"; src = fetchFromGitHub { owner = "PDAL"; repo = "PDAL"; rev = finalAttrs.version; sha256 = "sha256-JKwa89c05EfZ/FxOkj8lYmw0o2EgSqafRDIV2mTpZ5E="; }; nativeBuildInputs = [ cmake pkg-config ]; buildInputs = [ curl gdal hdf5-cpp LASzip libgeotiff libtiff libxml2 openscenegraph postgresql tiledb xercesc zlib zstd ] ++ lib.optionals enableE57 [ libe57format ]; cmakeFlags = [ "-DBUILD_PLUGIN_E57=${if enableE57 then "ON" else "OFF"}" "-DBUILD_PLUGIN_HDF=ON" "-DBUILD_PLUGIN_PGPOINTCLOUD=ON" "-DBUILD_PLUGIN_TILEDB=ON" "-DWITH_TESTS=ON" "-DBUILD_PGPOINTCLOUD_TESTS=OFF" # Plugins can probably not be made work easily: "-DBUILD_PLUGIN_CPD=OFF" "-DBUILD_PLUGIN_FBX=OFF" # Autodesk FBX SDK is gratis+proprietary; not packaged in nixpkgs "-DBUILD_PLUGIN_GEOWAVE=OFF" "-DBUILD_PLUGIN_I3S=OFF" "-DBUILD_PLUGIN_ICEBRIDGE=OFF" "-DBUILD_PLUGIN_MATLAB=OFF" "-DBUILD_PLUGIN_MBIO=OFF" "-DBUILD_PLUGIN_MRSID=OFF" "-DBUILD_PLUGIN_NITF=OFF" "-DBUILD_PLUGIN_OCI=OFF" "-DBUILD_PLUGIN_RDBLIB=OFF" # Riegl rdblib is proprietary; not packaged in nixpkgs "-DBUILD_PLUGIN_RIVLIB=OFF" ]; doCheck = true; disabledTests = [ # Tests failing due to TileDB library implementation, disabled also # by upstream CI. # See: https://github.com/PDAL/PDAL/blob/bc46bc77f595add4a6d568a1ff923d7fe20f7e74/.github/workflows/linux.yml#L81 "pdal_io_tiledb_writer_test" "pdal_io_tiledb_reader_test" "pdal_io_tiledb_time_writer_test" "pdal_io_tiledb_time_reader_test" "pdal_io_tiledb_bit_fields_test" "pdal_io_e57_read_test" "pdal_io_e57_write_test" "pdal_io_stac_reader_test" # Segfault "pdal_io_hdf_reader_test" # Failure "pdal_app_plugin_test" ]; checkPhase = '' runHook preCheck # tests are flaky and they seem to fail less often when they don't run in # parallel ctest -j 1 --output-on-failure -E '^${lib.concatStringsSep "|" finalAttrs.disabledTests}$' runHook postCheck ''; passthru.tests = { version = testers.testVersion { package = finalAttrs.finalPackage; command = "pdal --version"; version = "pdal ${finalAttrs.finalPackage.version}"; }; pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage; }; meta = with lib; { description = "PDAL is Point Data Abstraction Library. GDAL for point cloud data"; homepage = "https://pdal.io"; license = licenses.bsd3; maintainers = teams.geospatial.members; platforms = platforms.all; pkgConfigModules = [ "pdal" ]; }; }) </del>
Code change:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: }: let <del> # replace with global pdal version once # https://github.com/qgis/QGIS/pull/54940 is backported pdal = callPackage ./pdal-2_5.nix { }; </del> py = python3.override { packageOverrides = self: super: { pyqt5 = super.pyqt5.override {
Code change:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: qtserialport qtxmlpatterns qt3d <del> pdal </del> <ins> # pdal </ins> zstd ] ++ lib.optional withGrass grass ++ lib.optional withWebKit qtwebkit
Code change:
Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: }) ]; <ins> # PDAL is disabled until https://github.com/qgis/QGIS/pull/54940 # is backported. </ins> cmakeFlags = [ "-DWITH_3D=True" <del> "-DWITH_PDAL=TRUE" </del> <ins> "-DWITH_PDAL=False"  # TODO: re-enable PDAL </ins> "-DENABLE_TESTS=False" ] ++ lib.optional (!withWebKit) "-DWITH_QTWEBKIT=OFF" ++ lib.optional withGrass (let
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: ''; }; <del> package = mkPackageOption pkgs [ "findutils" "locate" ] { </del> <ins> package = lib.mkPackageOption pkgs [ "findutils" "locate" ] { </ins> example = "mlocate"; }; <del> interval = mkOption { type = str; </del> <ins> interval = lib.mkOption { type = lib.types.str; </ins> default = "02:15"; example = "hourly"; description = ''
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: ''; }; <del> extraFlags = mkOption { type = listOf str; </del> <ins> extraFlags = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = [ ]; description = '' Extra flags to pass to {command}`updatedb`. ''; }; <del> output = mkOption { type = path; </del> <ins> output = lib.mkOption { type = lib.types.path; </ins> default = "/var/cache/locatedb"; description = '' The database file to build. ''; }; <del> localuser = mkOption { type = nullOr str; </del> <ins> localuser = lib.mkOption { type = lib.types.nullOr lib.types.str; </ins> default = "nobody"; description = '' The user to search non-network directories as, using
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: ''; }; <del> pruneFS = mkOption { type = listOf str; </del> <ins> pruneFS = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = [ "afs" "anon_inodefs"
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: ''; }; <del> prunePaths = mkOption { type = listOf path; </del> <ins> prunePaths = lib.mkOption { type = lib.types.listOf lib.types.path; </ins> default = [ "/tmp" "/var/tmp"
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: ''; }; <del> pruneNames = mkOption { type = listOf str; </del> <ins> pruneNames = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = lib.optionals (!isFindutils) [ ".bzr" ".cache" ".git" ".hg" ".svn" ]; <del> defaultText = literalMD '' </del> <ins> defaultText = lib.literalMD '' </ins> `[ ".bzr" ".cache" ".git" ".hg" ".svn" ]`, if supported by the locate implementation (i.e. mlocate or plocate). '';
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: ''; }; <del> pruneBindMounts = mkOption { type = bool; </del> <ins> pruneBindMounts = lib.mkOption { type = lib.types.bool; </ins> default = false; description = '' Whether not to index bind mounts
Code change:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.

Related discussion:
text: }; <del> config = mkIf cfg.enable { users.groups = mkMerge [ (mkIf isMLocate { mlocate = { }; }) (mkIf isPLocate { plocate = { }; }) </del> <ins> config = lib.mkIf cfg.enable { users.groups = lib.mkMerge [ (lib.mkIf isMLocate { mlocate = { }; }) (lib.mkIf isPLocate { plocate = { }; }) </ins> ]; security.wrappers =