jiebi/CodeConvo huggingface dataset:
Code change:
Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Related discussion:
text: sourceRoot = "source/src"; <del> # Workaround '-idirafter' ordering bug in staging-next: #   https://github.com/NixOS/nixpkgs/pull/210004 # where libc '-idirafter' gets added after user's idirafter and # breaks. # TODO(trofi): remove it in staging once fixed in cc-wrapper. preConfigure = '' export NIX_CFLAGS_COMPILE_BEFORE_${lib.replaceStrings ["-" "."] ["_" "_"] stdenv.hostPlatform.config}=$(< ${stdenv.cc}/nix-support/libc-cflags) ''; </del> buildInputs = [ libbfd zlib libiberty ]; makeFlags = [ "wimboot.x86_64.efi" ];
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: , cython , dill , fastavro <ins> , fasteners </ins> , fetchFromGitHub , fetchpatch , freezegun
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: , grpcio-tools , hdfs , httplib2 <ins> , hypothesis </ins> , lib , mock , mypy-protobuf , numpy <del> , oauth2client </del> <ins> , objsize </ins> , orjson , pandas , parameterized
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: , pydot , pyhamcrest , pymongo <ins> , pytest-xdist </ins> , pytestCheckHook , python , python-dateutil <del> , pythonAtLeast </del> , pythonRelaxDepsHook , pytz , pyyaml <ins> , regex </ins> , requests , requests-mock , scikit-learn <del> , setuptools </del> , sqlalchemy , tenacity , testcontainers , typing-extensions <ins> , zstandard </ins> }: buildPythonPackage rec { pname = "apache-beam"; <del> version = "2.43.0"; </del> <ins> version = "2.44.0"; </ins> src = fetchFromGitHub { owner = "apache"; repo = "beam"; rev = "refs/tags/v${version}"; <del> sha256 = "sha256-lqGXCC66eyBnHcK06k9knggX5C+2d0m6xBAI5sh0RHo="; </del> <ins> hash = "sha256-5fnZxv2ZkFlv8vGDIt/6EL41v9P1iKa1tEd1nezq+PU="; </ins> }; patches = [
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: hash = "sha256-iUmnzrItTFM98w3mpadzrmtI3t0fucpSujAg/6qxCGk="; stripLen = 2; }) <del> (fetchpatch { # https://github.com/apache/beam/pull/24573 name = "relax-httplib2-version.patch"; url = "https://github.com/apache/beam/commit/4045503575ae5ccef3de8d7b868c54e37fef658b.patch"; hash = "sha256-YqT+sHaa1R9vLQnEQN2K0lYoCdnGoPY9qduGBpXPaek="; stripLen = 2; }) </del> ]; pythonRelaxDeps = [ # See https://github.com/NixOS/nixpkgs/issues/156957 "dill" "numpy" <del> "pyarrow" </del> "pymongo" # See https://github.com/NixOS/nixpkgs/issues/193613 "protobuf" <ins> # As of apache-beam v2.44.0, the requirement is httplib2>=0.8,<0.21.0, but # the current (2023-02-08) nixpkgs's httplib2 version is 0.21.0. This can be # removed once beam is upgraded since the current requirement on master is # for httplib2>=0.8,<0.22.0. "httplib2" </ins> ]; sourceRoot = "source/sdks/python";
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: propagatedBuildInputs = [ cloudpickle crcmod <del> cython </del> dill fastavro <ins> fasteners </ins> grpcio hdfs httplib2 numpy <del> oauth2client </del> <ins> objsize </ins> orjson proto-plus protobuf
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: pymongo python-dateutil pytz <ins> regex </ins> requests <del> setuptools </del> typing-extensions <ins> zstandard </ins> ]; enableParallelBuilding = true;
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: "apache_beam" ]; <del> nativeCheckInputs = [ </del> <ins> checkInputs = [ </ins> freezegun <ins> hypothesis </ins> mock pandas parameterized psycopg2 pyhamcrest pytestCheckHook <ins> pytest-xdist </ins> pyyaml requests-mock scikit-learn
Code change:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

Related discussion:
text: # Fails starting from dill 0.3.6 because it tries to pickle pytest globals: # https://github.com/uqfoundation/dill/issues/482#issuecomment-1139017499. "apache_beam/transforms/window_test.py" <ins> # See https://github.com/apache/beam/issues/25390. "apache_beam/coders/slow_coders_test.py" "apache_beam/dataframe/pandas_doctests_test.py" "apache_beam/typehints/typed_pipeline_test.py" "apache_beam/coders/fast_coders_test.py" "apache_beam/dataframe/schemas_test.py" </ins> ]; disabledTests = [
Code change:
Currently, most functions work without problem. However, when I try to add new paths to search dictionaries, it crashes with the following error message: Steps to reproduce the behavior: goldendict Edit Dictionaries Source Add crashes A dialog should pop up to select the path. Reproduced using the latest master branch of this repo. Using startx and qtile as the window manager I've submitted a PR to fix this issue (see ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

Related discussion:
text: , libXtst, libvorbis, hunspell, lzo, xz, bzip2, libiconv , qtbase, qtsvg, qtwebkit, qtx11extras, qttools, qmake , wrapQtAppsHook <ins> , wrapGAppsHook </ins> , withCC ? true, opencc , withEpwing ? true, libeb , withExtraTiff ? true, libtiff
Code change:
Currently, most functions work without problem. However, when I try to add new paths to search dictionaries, it crashes with the following error message: Steps to reproduce the behavior: goldendict Edit Dictionaries Source Add crashes A dialog should pop up to select the path. Reproduced using the latest master branch of this repo. Using startx and qtile as the window manager I've submitted a PR to fix this issue (see ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

Related discussion:
text: --replace "opencc.2" "opencc" ''; <del> nativeBuildInputs = [ pkg-config qmake wrapQtAppsHook ]; </del> <ins> nativeBuildInputs = [ pkg-config qmake wrapQtAppsHook wrapGAppsHook ]; </ins> buildInputs = [ qtbase qtsvg qtwebkit qttools libvorbis hunspell xz lzo
Code change:
sakura terminal emulator terminates when trying to change color by context menu with following error: GLib-GIO-ERROR *: No GSettings schemas are installed on the system [1] 9932 trace trap sakura run sakura, right click to popup context menu : options -select colors -(click on color field to open color chooser) Here is a thread that discusses the issue. it seems that the color-chooser gui description is missing that is needed by sakura. should include gsettings as runtime dependency. actually it has gtk3 package as dependency which provides those schemata, however it obvious doesn't look in the right path. this kind of error got fixed for System: (17.03pre98008. (Gorilla)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: ("17.03pre98008.")

Related discussion:
text: <del> { stdenv, fetchurl, cmake, pkgconfig, gtk3, perl, vte, pcre, glib }: </del> <ins> { stdenv, fetchurl, cmake, pkgconfig, gtk3, perl, vte, pcre, glib , makeWrapper }: </ins> stdenv.mkDerivation rec { name = "sakura-${version}";
Code change:
sakura terminal emulator terminates when trying to change color by context menu with following error: GLib-GIO-ERROR *: No GSettings schemas are installed on the system [1] 9932 trace trap sakura run sakura, right click to popup context menu : options -select colors -(click on color field to open color chooser) Here is a thread that discusses the issue. it seems that the color-chooser gui description is missing that is needed by sakura. should include gsettings as runtime dependency. actually it has gtk3 package as dependency which provides those schemata, however it obvious doesn't look in the right path. this kind of error got fixed for System: (17.03pre98008. (Gorilla)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: ("17.03pre98008.")

Related discussion:
text: nativeBuildInputs = [ cmake perl pkgconfig ]; <del> buildInputs = [ gtk3 vte pcre glib ]; </del> <ins> buildInputs = [ makeWrapper gtk3 vte pcre glib ]; # Wrapper sets path to gsettings-schemata so sakura knows where to find colorchooser, fontchooser ... postInstall = "wrapProgram $out/bin/sakura --suffix XDG_DATA_DIRS : ${gtk3}/share/gsettings-schemas/${gtk3.name}/"; </ins> meta = with stdenv.lib; { description = "A terminal emulator based on GTK and VTE";
Code change:
sakura terminal emulator terminates when trying to change color by context menu with following error: GLib-GIO-ERROR *: No GSettings schemas are installed on the system [1] 9932 trace trap sakura run sakura, right click to popup context menu : options -select colors -(click on color field to open color chooser) Here is a thread that discusses the issue. it seems that the color-chooser gui description is missing that is needed by sakura. should include gsettings as runtime dependency. actually it has gtk3 package as dependency which provides those schemata, however it obvious doesn't look in the right path. this kind of error got fixed for System: (17.03pre98008. (Gorilla)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: ("17.03pre98008.")

Related discussion:
text: makeFlags = [ "-e" ]; makeFlagsArray="LIBS=-lgc"; <del> meta = { </del> <ins> meta = with stdenv.lib ; { </ins> description = "Follow a symlink and print out its target file"; longDescription = '' A commandline program that chases symbolic filesystems links to the original file ''; homepage = "https://qa.debian.org/developer.php?login=rotty%40debian.org"; <del> license = stdenv.lib.licenses.gpl2Plus; maintainers = [ stdenv.lib.maintainers.polyrod ]; platforms = stdenv.lib.platforms.all; </del> <ins> license = licenses.gpl2Plus; maintainers = [ maintainers.polyrod ]; platforms = platforms.all; </ins> }; }
Code change:
Steps to reproduce the behavior: package is marked as broken I marked this package as broken starting with linux 6.2 because enables by default. The binary blobs included with the nvidia driver are not compiled with support for IBT and nvidia hasn't been able to update their internal toolchain to support it at this point. Rather than leave it broken, we should probably check if the driver is built using the proprietary blobs and add the kernel parameter starting with linux 6.2. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.

Related discussion:
text: # If requested enable modesetting via kernel parameter. boot.kernelParams = optional (offloadCfg.enable || cfg.modesetting.enable) "nvidia-drm.modeset=1" ++ optional cfg.powerManagement.enable "nvidia.NVreg_PreserveVideoMemoryAllocations=1" <del> ++ optional cfg.open "nvidia.NVreg_OpenRmEnableUnsupportedGpus=1"; </del> <ins> ++ optional cfg.open "nvidia.NVreg_OpenRmEnableUnsupportedGpus=1" # proprietary driver is not compiled with support for X86_KERNEL_IBT ++ optional (!cfg.open && config.boot.kernelPackages.kernel.kernelAtLeast "6.2") "ibt=off"; </ins> services.udev.extraRules = ''
Code change:
Steps to reproduce the behavior: package is marked as broken I marked this package as broken starting with linux 6.2 because enables by default. The binary blobs included with the nvidia driver are not compiled with support for IBT and nvidia hasn't been able to update their internal toolchain to support it at this point. Rather than leave it broken, we should probably check if the driver is built using the proprietary blobs and add the kernel parameter starting with linux 6.2. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.

Related discussion:
text: platforms = [ "x86_64-linux" ] ++ optionals (!i686bundled) [ "i686-linux" ]; maintainers = with maintainers; [ jonringer ]; priority = 4; # resolves collision with xorg-server's "lib/xorg/modules/extensions/libglx.so" <del> # proprietary driver currently does not support X86_KERNEL_IBT, which is scheduled to be added in linux 6.2 broken = broken || (kernel != null && kernel.kernelAtLeast "6.2"); </del> <ins> inherit broken; </ins> }; };
Code change:
A ends with the following: commit -rebuild switch System: NixOS: Nix version:nix-env (Nix) 1.11.4 Nixpkgs version:
Do you have grub on an encrypted partition and have ?
no, I don't have that option specified anywhere at all. Also, the error has since disappeared after moving to a fresher .
GRUBENABLECRYPTODISK=y' in file That seemed to say that, no idea what the issue was then, so I'm closing this, please reopen if it occurs again.

Related discussion:
text: { stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };
Code change:
The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):

Related discussion:
text: case $o in init=*) IFS== read -r -a initParam <<< "$o" <del> closure="$(dirname "''${initParam[1]}")" </del> <ins> closure="''${initParam[1]}" </ins> ;; esac done
Code change:
The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):

Related discussion:
text: exit 1 fi <ins> # Resolve symlinks in the init parameter. We need this for some boot loaders # (e.g. boot.loader.generationsDir). closure="$(chroot /sysroot ${pkgs.coreutils}/bin/realpath "$closure")" # Assume the directory containing the init script is the closure. closure="$(dirname "$closure")" </ins> # If we are not booting a NixOS closure (e.g. init=/bin/sh), # we don't know what root to prepare so we don't do anything if ! [ -x "/sysroot$(readlink "/sysroot$closure/prepare-root" || echo "$closure/prepare-root")" ]; then
Code change:
Package name: wpgtk Latest released version: 6.5.7 <!-- Search your package here: --- Current version on the unstable channel: 6.5.5 Current version on the stable/release channel: 6.5.5 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: python3Packages.buildPythonApplication rec { pname = "wpgtk"; <del> version = "6.5.5"; </del> <ins> version = "6.5.7"; </ins> src = fetchFromGitHub { owner = "deviantfero"; repo = "wpgtk"; rev = version; <del> sha256 = "sha256-g3flxQNiNta+uL4t21Lhpij8b5yB78SJLGaFpTcm9fE="; </del> <ins> sha256 = "sha256-rHNni0nDghc5kI1sWHAb5ODr4buBz65eUEB1qWpbTTs="; </ins> }; nativeBuildInputs = [
Code change:
Changes introduced in forcing package (or whatever the option is set to) installation even if the set to . This is because the module is unconditionally adding the package to the : Steps to reproduce the behavior: both and to in order to avoid enabling the service or systemd overriding the package with . installed packages, for example using the command. An package is installed into the system: An package should not be installed into the system. I am on a quest to build a minimal NixOS system for usage in LXC containers and trying to trim things down to the minimum, without having to resort to forking, overriding, patching and maintaining individual modules. I am happy to open up a PR to move the package assignment to the block: but would like to check if anyone has any objections or reasons why I shouldn't be doing so. appreciate any insights ‍ Please run and paste the result.
As the author of that PR I have no objections to restoring the old behaviour.

Related discussion:
text: exit 1 '' else configText; <del> environment.systemPackages = [ cfg.package ]; </del> } (mkIf cfg.enable { networking.resolvconf.package = pkgs.openresolv; <ins> environment.systemPackages = [ cfg.package ]; </ins> systemd.services.resolvconf = { description = "resolvconf update";
Code change:
Steps to reproduce the behavior: (the current version in ) I was having the same issue that was fixed by until a few days ago and built and worked flawlessly. I am currently using the version it is supposedly trying to build. returns , so I do not understand why the build is needed in the first place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (because you made the last commit) Please run and paste the result.
I tried rebuilding today after the fix you committed (thank you for being so quick), I am still receiving the same error. Is there something in particular I need to do for the fix to propogate? I know that there is a little lag before a commit comes in from , but I thought 3 days later would be enough?
The fix is now on and , so if you are on either, I guess you just need to update the channel. Otherwise, the following command should work:
FWIW, is also a handy tool for checking the status of a PR's movement into the various channels.
that worked, thank you. this is also very useful, will put it in my bookmarks!

Related discussion:
text: hash = "sha256-4VC1fwQh9L3c5tgLUaC36p9QHL4dR2vkWc2XlNl0Xzw="; }; <del> # Disable version check </del> postPatch = '' <ins> # Drop broken version specifier sed -i '/python_requires/d' setup.py # Disable version check </ins> substituteInPlace raphodo/constants.py  --replace "disable_version_check = False" "disable_version_check = True" '';