jiebi/CodeConvo huggingface dataset:
Change:
in # A wrapper around sage that makes sure sage finds its docs (if they were build). callPackage ./sage.nix { <del> inherit sage-tests sage-with-env sagedoc; </del> <ins> inherit sage-tests sage-with-env sagedoc jupyter-kernel-definition; </ins> inherit withDoc; }

Discussion:
When I run , I have the jupyter website that opens, however when I open a sage notebook, the sage kernel fails to start, and I've an error Install sage, tested on both latest nixos-unstable (that took ages to compile), and using the one provided here: Then run and try to open a sage notebook. You should see on the top right a red error "Kernel error", and the console should display the above errors Please run and paste the results.
/cc maintainer
Thanks for the report :) The immediate cause for the error is that contains while it should be . I have never used jupyter so I'm not sure if that is all. Integrating with would probably be good / maybe be necessary. I don't know when/if I'll get to debugging this since I don't currently use it myself, but I'll happily help you do it if you want to try. Note that the regular sage cli does work.
I also experience this issue. I thought I was installing Jupyter incorrectly. Lol, I should have checked for a bug report, I asked for help at
This is now fixed in master.
Change:
<ins> { stdenv, fetchFromGitHub }: stdenv.mkDerivation rec { version = "0.1"; pname = "snore"; src = fetchFromGitHub { owner = "clamiax"; repo = pname; rev = version; sha256 = "1ic1qy6ybnjlkz5rb1hpvq6dcdmxw5xcx34qcadrsfdjizxcv8pp"; }; makeFlags = [ "PREFIX=${placeholder "out"}" ]; meta = with stdenv.lib; { description = "sleep with feedback"; homepage = "https://github.com/clamiax/snore"; license = licenses.mit; maintainers = [ maintainers.marsam ]; platforms = platforms.unix; }; } </ins>

Discussion:
Project description snore is sleep with feedback Metadata source URL: license: mit platforms: linux
I'm confused by your name... lol
Change:
<ins> { lib , stdenv , fetchFromGitHub , pkg-config , meson , ninja , vala , wrapGAppsHook , desktop-file-utils , libgee , pantheon , libxml2 , libhandy }: stdenv.mkDerivation rec { pname = "annotator"; version = "1.2.1"; src = fetchFromGitHub { owner = "phase1geo"; repo = "annotator"; rev = version; hash = "sha256-VHvznkGvrE8o9qq+ijrIStSavq46dS8BqclWEWZ8mG8="; }; nativeBuildInputs = [ pkg-config meson ninja vala wrapGAppsHook desktop-file-utils ]; buildInputs = [ libgee pantheon.granite libxml2 libhandy ]; meta = with lib; { description = "Image annotation for Elementary OS"; homepage = "https://github.com/phase1geo/Annotator"; license = licenses.gpl3Plus; mainProgram = "com.github.phase1geo.annotator"; maintainers = with maintainers; [ aleksana ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Image crop and annotation tool built using Gtk and Vala. I think it is compatible with GNOME environment. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Change:
<ins> { lib , buildPythonPackage , fetchFromGitHub , pytestCheckHook , pythonOlder , setuptools , setuptools-scm }: buildPythonPackage rec { pname = "pegen"; version = "0.2.0"; format = "pyproject"; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "we-like-parsers"; repo = pname; rev = "refs/tags/v${version}"; hash = "sha256-5nxOMgkDAkHtVFSNXf0SPoag6/E7b97eVnFoAqyJE3g="; }; SETUPTOOLS_SCM_PRETEND_VERSION = version; nativeBuildInputs = [ setuptools setuptools-scm ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "pegen" ]; meta = with lib; { description = "Library to generate PEG parsers"; homepage = "https://github.com/we-like-parsers/pegen"; changelog = "https://github.com/we-like-parsers/pegen/releases/tag/v${version}"; license = licenses.mit; maintainers = with maintainers; [ fab ]; }; } </ins>

Discussion:
Steps to reproduce the behavior: `nix-build '<nixpkgs' -A Fails since /cc
Change:
owner = "drone"; repo = "drone"; rev = "v${version}"; <del> sha256 = "sha256-12Jac+mXWdUX8gWvmpdO9ROv7Bi0YzvyqnNDVNJOr34="; </del> <ins> sha256 = "sha256-BxwCJf3uY34rqegZJ6H/zb63orELhq41trOgzGXQe80="; </ins> }; preBuild = ''

Discussion:
Drone 2.0 has been released: <!-- Note that these are hard requirements --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.10.0 desired version: 2.0.0 Please tag this issue in your PR.
Change:
<ins> { stdenv, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "stripe-cli"; version = "1.5.3"; src = fetchFromGitHub { owner = "stripe"; repo = pname; rev = "v${version}"; sha256 = "0anrn7dkxgbzilh45gyqrp2930bkg3g3diarb50qp0rlim302sgy"; }; vendorSha256 = "05cyn9cgmijj6dl075slwm5qc6fj6m5sm414wqm50xz2fjs0400r"; subPackages = [ "cmd/stripe" ]; meta = with stdenv.lib; { homepage = "https://stripe.com/docs/stripe-cli"; description = "A command-line tool for Stripe"; license = with licenses; [ asl20 ]; maintainers = with maintainers; [ RaghavSood ]; }; } </ins>

Discussion:
Project description The Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal. Metadata homepage URL: source URL: license: Apache platforms: unix, linux, darwin I already made this, and it seemed to be good enough for my purposes:
Danm, that is amazing. Thank you!
Change:
self: super: { octoprint-pisupport = self.buildPythonPackage rec { pname = "OctoPrint-PiSupport"; <del> version = "2021.10.28"; </del> <ins> version = "2022.3.28"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "OctoPrint"; repo = "OctoPrint-PiSupport"; rev = version; <del> sha256 = "01bpvv1sn3113fdpw6b90c2rj8lqay118x609yy64z9ccm93khl9"; </del> <ins> sha256 = "yzE/jz604nX/CHcW3aa7goH1ey8qZ7rLw31SMfNKJZM="; </ins> }; # requires octoprint itself during tests

Discussion:
Due to the update in which includes octoprint fails to build in current unstable release. Octoprint needs a version <8, whereas black now demands a version of = 8. Steps to reproduce the behavior: octoprint should build. <!-- 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. One could add an additional overwrite for black at this point. On the other hand, octoprint just released its rc2 which drops python2 support and makes a lot of the overwrites unnecessary.
Please just remove black from the test pipeline. There is no reason to run it.
AFAIK black isn't used in the test pipeline. At least neither click, nor octoprint have black as a build input. Still, some package version of derivation seems to require black. I submitted a PR, which pins the version of black to the last working version.
Black is almost never a runtime dependency. Most of the time it can be safely removed from any requires which safes us the hassle of pinning it or fixing issues.
Hi as I said it is a runtime dependency. In this case . In any case, I would rather see move forward, which would remove most of the overrides.
We should probably wait for a stable release of octoprint first
Change:
configureFlags = "--disable-scrollkeeper"; <ins> passthru = { # Consumers are expected to copy the m4 files to their source tree, let them reuse the patch respect_xml_catalog_files_var_patch = ./respect-xml-catalog-files-var.patch; }; </ins> meta = with stdenv.lib; { homepage = https://www.gtk.org/gtk-doc; description = "Tools to extract documentation embedded in GTK+ and GNOME source code";

Discussion:
Once you take a video with cheese (as webm), a few strange things happen: No thumbnails for images or videos will load. Cheese will refuse to close without a 'kill/killall .cheese-wrapped' Errors: video in cheese. cheese via 'Quit' button OR by closing the window Check (cheese will still be running) and taking up quite a bit of CPU. Normal behavior is returned once webm file is moved or deleted. Cheese doesn't understand webm yet tries to record as webm. Then every attempt at loading the webm in the preview pane causes an error. Maybe a dependency issue and we should depend on some webm support library? Or an upstream issue with Cheese itself? System: 16.09.1445. (Flounder); 16.03.885. (Emu) Nix version: nix-env (Nix) 1.11.4; nix-env (Nix) 1.11.2 Nixpkgs version: 16.09.1445.; 16.03.885. Cheese version: 3.20.2; 3.18.1
Updated. Still an issue in 16.09.
I can reproduce the problems with thumbnails and webm-related issues on 17.03 and master. It doesn't seem to crash on exit in my testing. Playing with gets problems with missing to disappear, adding gstreamer bits (like is done in totem or sushi) doesn't seem to be sufficient (I'm no expert here). Related: (?).
I opened an upstream issue:
Running cheese with environment variable revealed missing path to bubblewrap. After patching , user still needs to have thumbnailers ( and ) installed, for now I have them as dependencies like I did in . The infinite loop is still an upstream bug but with thumbnailers, it at least should not appear.
Change:
]; patches = [ <ins> # Drop inheritable cap_sys_nice, to prevent the ambient set from leaking # from mutter/gnome-shell, see https://github.com/NixOS/nixpkgs/issues/71381 ./drop-inheritable.patch </ins> # TODO: submit upstream ./0001-build-use-get_pkgconfig_variable-for-sysprof-dbusdir.patch (substituteAll {

Discussion:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):
Change:
requests mypy-extensions django_3' <del> django_extensions </del> <ins> django-extensions </ins> dateparser youtube-dl python-crontab

Discussion:
python38Packages.djangoextensions and python39Packages.djangoextensions Fails to build. I discovered it as it was a dependency of Archivebox that also doesnt build now. Simple way to reproduce is: a file : I expected the package to build and not fail with errors. It appears it is the test's that fail and not the actual build. ! I have much larger file that I choose not to include as it is the same error i got in the minimal version and all the other clutter likely is not responsible. No maintainers for either of the packages :( Please run and paste the result. this path will be fetched (0.06 MiB download, 0.30 MiB unpacked):
Change:
"--docs" "--freedesktop" "--no-phone-home" <del> "--optimize" </del> "--ptformat" "--run-tests" "--test" <del> ]; </del> <ins> ] ++ lib.optional optimize "--optimize"; </ins> # removed because it fixes https://tracker.ardour.org/view.php?id=8161 and https://tracker.ardour.org/view.php?id=8437 # "--use-external-libs"

Discussion:
is adding ardour 7.0 to the repository. As noted by 7.0 still experiences crashes. Thus we've opted to keep version 6.9 around for a little while for people to optionally use as a more stable base for their projects. Once ardour 7.x (package name ) is deemed stable, ardour 6.x (package name ) should be removed from nixpkgs.
updated to in preparation for 8.0, so this issue should be either closed or updated. Fwiw, maintaining the package of the last stable release of the previous major version seems like a good tradition for Ardour.
Thanks for pointing that out. I agree that keeping (at least) the last version around is helpful for some people who can't update for one reason or another. If someone objects, they can create a new issue.
Change:
'' echo "${cidr}" >> $state echo -n "adding address ${cidr}... " <del> if out=$(ip addr add "${cidr}" dev "${i.name}" 2>&1); then </del> <ins> if out=$(ip addr replace "${cidr}" dev "${i.name}" 2>&1); then </ins> echo "done" <del> elif ! echo "$out" | grep "File exists" >/dev/null 2>&1; then echo "'ip addr add "${cidr}" dev "${i.name}"' failed: $out" </del> <ins> else echo "'ip addr replace "${cidr}" dev "${i.name}"' failed: $out" </ins> exit 1 fi ''

Discussion:
Service fails if an address is already assigned to an interface. an IP address to an interface the same IP address to the nixos configuration to the new configuration and start the service The service should skip addresses that are already assigned and finish with success. There is a check in the script run by the service (generated ): It checks presence of File exists in the output. This likely matches the message , that was there sometimes earlier. Now the error generated by is different: I got this error message both on 20.09 and nixos-unstable. If I replace File exists with address already assigned in the script, it works as expected. Note: If IP addresses are managed only by nixos, it works correctly. They are deleted when service is stopped. The problem is only present when there is an address that was manually or by non-nixos script. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ah, great detective work! Perhaps it would be better to run and then . Relying on the error message literal text is not a good idea. What do you think?
I also don't like relying on the error message. There is , that looks better than add+del. No info in man page, better description is on . I see one downside - if there is additional configuration associated with IP address, it will likely remove it. More complex solution is to pre-check if address is already assigned, something like I'm not sure if there are some corner cases with this check, so I would probably stick with less complex .
Nice, it says it doesn't fail if the address already exists, so it would dispense the error checking part. Yeah, it could mess with SIIT tunnels and services already bound to that address. The only advantage of del+add is that it would reset the lifetime and the flags (mngtmpaddr, nodad, etc.), so the final state is always consistent. However, I just checked and replace does this as well, so it seems perfect for our use case. Can you make a PR?
Has this regressed in some way in 24.05? I have extra addresses configured on and it now fails due this issue because 127.0.0.1 seems to be configured before runs.

But it did work before I updated to 24.05.
I'm also experiencing this after updating to 24.05. On some of my systems I'm setting kernel options to setup an interface initially (for remote unlocking of zfs datasets) and since updating to 24.05 the interface service fails to start because this address is already there.
Does fix the issue for you?
I've monkey-patched the change from into my configuration and that fixes it, yes.
You can track the progress here for and .
Change:
sha256 = "sha256-lqFhLCOLiuSQWhbcZUEj2xFRlZ+x1ZTVc8IJw7tJjhE="; }; <del> buildInputs = lib.optional stdenv.isDarwin libiconv; </del> cargoHash = "sha256-3hrpg2cMvIuFy6mH1/1igIpU4nbzFQLCAhiIRZbTuaI="; <del> checkFlags = [ # failure: path::tests::test_relative_to_parent "--skip=path::tests::test_relative_to_parent" ]; </del> <ins> # fixes `thread 'main' panicked at 'cannot find strip'` on x86_64-darwin env = lib.optionalAttrs (stdenv.isx86_64 && stdenv.isDarwin) { TARGET_STRIP = "${stdenv.cc.targetPrefix}strip"; }; # error: linker `aarch64-linux-gnu-gcc` not found postPatch = '' rm .cargo/config ''; </ins> meta = with lib; { description = "A hackable, minimal, fast TUI file explorer"; homepage = "https://xplr.dev"; <ins> changelog = "https://github.com/sayanarijit/xplr/releases/tag/${src.rev}"; </ins> license = licenses.mit; <del> maintainers = with maintainers; [ sayanarijit suryasr007 thehedgeh0g mimame ]; </del> <ins> maintainers = with maintainers; [ sayanarijit suryasr007 thehedgeh0g mimame figsoda ]; </ins> }; }

Discussion:
Steps to reproduce the behavior: xplr v0.21.3 Running inside QEMU (UTM) on Apple M1 Pro <!-- --Please run and paste the result.
Change:
} // lib.optionalAttrs config.allowAliases { #### ALIASES <ins> xinitrc = xfce4-session.xinitrc; # added 2019-11-04 thunar-bare = thunar.override { thunarPlugins = []; };  # added 2019-11-04 }) // lib.optionalAttrs config.allowAliases { #### Legacy aliases. They need to be outside the scope or they will shadow the attributes from parent scope. </ins> terminal = throw "xfce.terminal has been removed, use xfce.xfce4-terminal instead"; # added 2022-05-24 thunar-build = throw "xfce.thunar-build has been removed, use xfce.thunar-bare instead"; # added 2022-05-24 thunarx-2-dev = throw "xfce.thunarx-2-dev has been removed, use xfce.thunar-bare instead"; # added 2022-05-24

Discussion:
Trying to rebuild my system with current master () fails with the error: `error: has been removed, use dconf instead" This stems from PR from Obviously I don't use anywhere in my config. Running my deployment with yields: Looking at the source of just shows the correct usage of as far as I can tell. Steps to reproduce the behavior: nixpkgs locally to the given commit -rebuild with local nixpkgs Rebuild without issues. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result.
I guess it is due to the removal of because on another machine I have the same issue with
A simpler way to test it to checkout current master and try to build which fails with the above error
Change:
<del> { lib, rustPlatform, fetchFromGitHub, installShellFiles }: </del> <ins> { stdenv, lib, rustPlatform, fetchFromGitHub, installShellFiles, SystemConfiguration, libiconv }: </ins> rustPlatform.buildRustPackage rec { pname = "pueue"; <del> version = "0.12.0"; </del> <ins> version = "0.12.1"; </ins> src = fetchFromGitHub { owner = "Nukesor"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-yOUVDq/wRY35ZQjQVwTLYHKukkKpoggN51wBDdZnhI4="; </del> <ins> sha256 = "sha256-wcOF34GzlB6YKISkjDgYgsaN1NmWBMIntfT23A6byx8="; </ins> }; <del> cargoSha256 = "sha256-56jJ8IjxWTBlaDd1CVit4RP659Mgw2j2wMWcSDYVihM="; </del> <ins> cargoSha256 = "sha256-7SJjtHNSabE/VqdiSwKZ/yNzk6GSMNsQLaSx/MjN5NA="; </ins> nativeBuildInputs = [ installShellFiles ]; <ins> buildInputs = lib.optionals stdenv.isDarwin [ SystemConfiguration libiconv ]; </ins> checkFlags = [ "--skip=test_single_huge_payload" "--skip=test_create_unix_socket" ]; postInstall = ''

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- 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! --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. Also my motivation for this issue is not so much for bumping up new version but it's more about build not working on my mac (for both Catalina and Big Sur). I believe 's derivation is here, When I try to install this package, for example via , It doesn't use a cached one (I assume it was never cached for macOS for some reason), I get a long error that ends with: Anyhow, after trying to fix this issue, I began to realize maybe I can compare this one with other Rust package that works, for example, , which I believe the derivation is here, The notable difference I can see is this kind of line below exist in but not in . So I have a feeling that something similar must be done to make it work for macOS. And in , I can see: and: Therefore I believe it should also be something like this: Unfortunately I don't have much knowledges of how these things all work in a clear level nor the experience of building them, so I avoid creating premature PR and instead leaving this issue for now hoping it can be picked and I can also learn by watching. If anything what I said is not clear, feel free to let me know!
Change:
self: super: { octoprint = self.buildPythonPackage rec { pname = "OctoPrint"; <del> version = "1.7.3"; </del> <ins> version = "1.8.0rc5"; </ins> src = fetchFromGitHub { owner = "OctoPrint"; repo = "OctoPrint"; rev = version; <del> sha256 = "sha256-U6g7WysHHOlZ4p5BM4tw3GGAxQmxv6ltYgAp1rO/eCg="; </del> <ins> sha256 = "sha256-FeT45w6VXaFV4BsuOMk58nxxiu9jhCNnA2F7Uh/3sB0="; </ins> }; propagatedBuildInputs = with super; [

Discussion:
Due to the update in which includes octoprint fails to build in current unstable release. Octoprint needs a version <8, whereas black now demands a version of = 8. Steps to reproduce the behavior: octoprint should build. <!-- 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. One could add an additional overwrite for black at this point. On the other hand, octoprint just released its rc2 which drops python2 support and makes a lot of the overwrites unnecessary.
Please just remove black from the test pipeline. There is no reason to run it.
AFAIK black isn't used in the test pipeline. At least neither click, nor octoprint have black as a build input. Still, some package version of derivation seems to require black. I submitted a PR, which pins the version of black to the last working version.
Black is almost never a runtime dependency. Most of the time it can be safely removed from any requires which safes us the hassle of pinning it or fixing issues.
Hi as I said it is a runtime dependency. In this case . In any case, I would rather see move forward, which would remove most of the overrides.
We should probably wait for a stable release of octoprint first
Change:
}; "build/macosx/avrdude-6.3.0-arduino9-i386-apple-darwin11.tar.bz2" = fetchurl { url = "https://downloads.arduino.cc/tools/avrdude-6.3.0-arduino9-i386-apple-darwin11.tar.bz2"; <del> sha256 = "0rc4x8mcsva4v6j7ssfj8rdyg14l2pd9ivgdm39m5wnz8b06p85z11703f0r82aq3mmkiy7vwa4jfjhs9826qpp724hbng9dx74kk86r"; </del> <ins> sha256 = "0rc4x8mcsva4v6j7ssfj8rdyg14l2pd9ivgdm39m5wnz8b06p85z"; </ins> }; "build/macosx/appbundler/appbundler-1.0ea-arduino4.jar.zip" = fetchurl { url = "https://downloads.arduino.cc/appbundler-1.0ea-arduino4.jar.zip";

Discussion:
Describe the bug When I'm trying to install he arduino or ino package on MacOS I get the error message has wrong length for hash type 'sha256'. , one of the MacOS entries has a hash that is longer than all the other hashes. To Reproduce Steps to reproduce the behavior: Run: Expected behavior Arduino is installed in a nix shell. Screenshots ! Metadata Please run and paste the result. Maintainer information:
In the pull request mentioned above I have corrected the obvious error in the hash. I don't have Nix on Darwin to try it on, can you?