jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { lib, fetchFromGitHub, rustPlatform, installShellFiles }: rustPlatform.buildRustPackage rec { pname = "httm"; version = "0.9.0"; src = fetchFromGitHub { owner = "kimono-koans"; repo = pname; rev = version; sha256 = "sha256-uqzwS7+OQsPdMv3+fWdn3yVFJwtFZNd8kVWw//mQZj8="; }; cargoSha256 = "sha256-EC3E5NawsDe+CU5WEu0G3FWVLuqW5nXOoUURN0iDPK0="; nativeBuildInputs = [ installShellFiles ]; postInstall = '' installManPage httm.1 installShellCompletion --cmd httm  --zsh scripts/httm-key-bindings.zsh ''; meta = with lib; { description = "Interactive, file-level ZFS Time Machine-like tool"; homepage = "https://github.com/kimono-koans/httm"; license = licenses.mpl20; platforms = platforms.unix; maintainers = with maintainers; [ wyndon ]; }; } </ins>

Related discussion:
text: Project description httm prints the size, date and corresponding locations of available unique versions (deduplicated by modify time and size) of files residing on ZFS snapshots, but can also be used interactively to view and restore such files. httm might change the way you use ZFS snapshots (because ZFS isn't designed for finding for unique file versions) or the Time Machine concept (because httm is very fast!). Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: unix, linux, darwin
Oh great thanks! Searched first but missed this.
Code change:
buildGoModule rec { pname = "ko"; <del> version = "0.15.2"; </del> <ins> version = "0.15.3"; </ins> src = fetchFromGitHub { owner = "ko-build"; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-/1s335bXbBKlzKT4AevuHltLdU2qj6pJFngOrJCLtUw="; </del> <ins> hash = "sha256-H/S2TNzUIAjHDCrfQ3pkHC3yVf1k1DYkR5eBme8Cuq4="; </ins> }; <del> vendorHash = null; </del> <ins> vendorHash = "sha256-RrcJJzjmihjR/E19Pqgl//+yweRsaqWZ0yPcd1AvOc0="; </ins> nativeBuildInputs = [ installShellFiles ];

Related discussion:
text: Package name: ko Latest released version: 0.15.3 <!-- Search your package here: --- Current version on the unstable channel: 0.15.2 Current version on the stable/release channel: 0.15.1 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
support = import ../development/python-modules/numpy-scipy-support.nix { inherit python; openblas = pkgs.openblasCompat; <del> pkgName = "numpy"; </del> <ins> pkgName = "scipy"; </ins> }; in buildPythonPackage rec { name = "scipy-${version}";

Related discussion:
text: As noted by scipy uses the wrong tests. Instead of running its own test-suite, it runs that of numpy. This is because accidentally pkgName was set to in
Most errors are which are harmless according to
The 12 errors that are encountered are in fact 11 deprecation warnings, and one syntax error in a test when setting PYTHONPATH.
Code change:
omxplayer = callPackage ../applications/video/omxplayer { }; <del> inherit (python3Packages.callPackage ../applications/networking/onionshare { }) onionshare onionshare-gui; </del> <ins> inherit (callPackage ../applications/networking/onionshare { }) onionshare onionshare-gui; </ins> openambit = qt5.callPackage ../applications/misc/openambit { };

Related discussion:
text: Steps to reproduce the behavior: onionshare <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:
Code change:
<ins> { lib, ... }: let mainPort = "8080"; in { name = "open-webui"; meta = with lib.maintainers; { maintainers = [ shivaraj-bh ]; }; nodes = { machine = { ... }: { services.open-webui = { enable = true; environment = { # Requires network connection RAG_EMBEDDING_MODEL = ""; }; }; }; }; testScript = '' machine.start() machine.wait_for_unit("open-webui.service") machine.wait_for_open_port(${mainPort}) machine.succeed("curl http://127.0.0.1:${mainPort}") ''; } </ins>

Related discussion:
text: Project description WebUI service for Large Language Models Video demonstration by : .. basically self-hostable ChatGPT-like service Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Additional info Follow-up on for open-webui nixos module. There seems to be an ongoing work on the subject by and on Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant Merge Request:
Just for reference / workaround here's another nix package:
Thanks for that reference. That pdm tool workaround looks a lot more maintainable for the Python backend. Maybe i'll have time to try another PR in the next weeks. In the meantime and as a much simpler UI i packaged as part of PR It would be great if someone could review it.
I would like to mention that in the latest release switched to , I am not sure of any straightforward way to do this while packaging it for .
I just tested your flake, it's impressive, especially the nice UI at the end showing all the processes ! Regarding open-webui, it would be so nice to have that in !!!
Thank you, planning to have more UIs and devShell integration (for CLI tools that interact with ollama). I would love that too! Although there are a few challenges (like the one I pointed above regarding ), I am willing to contribute here. Also, maintainers are quick to respond, in case we need any upstream contributions to make it happen.
Code change:
src = lib.cleanSource ./.; <del> makeFlags = [ "PANDOC_LUA_FILTERS_DIR=${pkgs.pandoc-lua-filters}/share/pandoc/filters" ]; </del> postPatch = '' ln -s ${doc-support} ./doc-support/result '';

Related discussion:
text: Describe the bug To contribute to the nixpkgs documentation I followed the instructions in the nixpkgs manual "Chapter 21. Contributing to this documentation" and I followed the code snippet Firstly I was greeted with some warnings: But moving on to I saw a large number of errors. It looks like is set up inside the nix-shell but it's not picked up by ? Running the command does work. To Reproduce Expected behavior No warnings, no errors. Metadata Please run and paste the result. Maintainer information:
nix-shell has a specific setup to allow running stdenv phases such as
That also gives me a bunch of errors as well, but different ones: For a bunch of files. I managed to write some updates to the docs and validated them just using the command, but it's a bit unfortunate that just following the instructions literally doesn't work.
Sorry about that. should fix it.
Thanks, that fixes it for me (tested by setting the env variable manually). Great to see these steps towards making it easier to contribute to the docs.
Code change:
meta.homepage = "https://github.com/blazkowolf/gruber-darker.nvim/"; }; <ins> grug-far-nvim = buildVimPlugin { pname = "grug-far.nvim"; version = "2024-07-22"; src = fetchFromGitHub { owner = "MagicDuck"; repo = "grug-far.nvim"; rev = "f9a8592b037b761fac6a327bc314e9e3eb47401e"; sha256 = "13aa8s9lxdjiyifj9vmbph6hl9px0spfm36my1j2h41biq5nsx5q"; }; meta.homepage = "https://github.com/MagicDuck/grug-far.nvim/"; }; </ins> gruvbox = buildVimPlugin { pname = "gruvbox"; version = "2023-08-14";

Related discussion:
text: Project description <!-- Describe the project a little: --An UI for search and replace on neovim It has replaced for me Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
'' + optionalString isDarwin '' sed -i '/qemucapabilitiestest/d' tests/meson.build sed -i '/vircryptotest/d' tests/meson.build <ins> sed -i '/domaincapstest/d' tests/meson.build sed -i '/qemufirmwaretest/d' tests/meson.build sed -i '/qemuvhostusertest/d' tests/meson.build </ins> '' + optionalString (isDarwin && isx86_64) '' sed -i '/qemucaps2xmltest/d' tests/meson.build sed -i '/qemuhotplugtest/d' tests/meson.build

Related discussion:
text: On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?
Code change:
, wayland-protocols , wlroots_0_17 , xwayland <del> , zig_0_12 </del> <ins> , zig_0_13 </ins> , withManpages ? true , xwaylandSupport ? true }: stdenv.mkDerivation (finalAttrs: { pname = "river"; <del> version = "0.3.2"; </del> <ins> version = "0.3.3"; </ins> outputs = [ "out" ] ++ lib.optionals withManpages [ "man" ];

Related discussion:
text: Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.
Code change:
<del> diff --git a/Cargo.lock b/Cargo.lock index bc9a0f8..45a74ad 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -2165,7 +2165,7 @@ dependencies = [ [[package]] name = "lapce" -version = "0.0.9" +version = "0.0.10" dependencies = [ "lapce-core", "lapce-proxy", @@ -2173,7 +2173,7 @@ dependencies = [ [[package]] name = "lapce-core" -version = "0.0.9" +version = "0.0.10" dependencies = [ "Inflector", "alacritty_terminal 0.15.0", @@ -2233,7 +2233,7 @@ dependencies = [ [[package]] name = "lapce-proxy" -version = "0.0.9" +version = "0.0.10" dependencies = [ "alacritty_terminal 0.16.0-rc2", "anyhow", </del>

Related discussion:
text: <!-- 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 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: lapce <!-- The current version can be found easily with the same process as 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: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine
Code change:
<xi:include href="nginx.section.xml" /> <xi:include href="opengl.section.xml" /> <xi:include href="shell-helpers.section.xml" /> <del> <xi:include href="steam.xml" /> </del> <ins> <xi:include href="steam.section.xml" /> </ins> <xi:include href="cataclysm-dda.section.xml" /> <xi:include href="urxvt.section.xml" /> <xi:include href="weechat.section.xml" />

Related discussion:
text: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I will also work on this
Code change:
makeWrapper $out/dbeaver/dbeaver $out/bin/dbeaver  --prefix PATH : ${jdk}/bin  <del> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath ([ glib gtk3 libXtst ])}  </del> <ins> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath ([ glib gtk3 libXtst webkitgtk glib-networking ])}  --prefix GIO_EXTRA_MODULES : "${glib-networking}/lib/gio/modules"  </ins> --prefix XDG_DATA_DIRS : "$GSETTINGS_SCHEMAS_PATH" mkdir -p $out/share/pixmaps

Related discussion:
text: DBeaver has support to show spatial data on a map when the database is capable (e.g. postgres + postgis) but opening "spatial" tab gives this error: Steps to reproduce the behavior: dbeaver to a table that has a geometry, show data "Spatial" on the left A map should be shown This happens on master and 21.05-release, didn't test on 21.11 but I suppose it's the same Maintainer information:
I was able to reproduce the error and have fixed it. This is how the map now looks with a sample polygon taken from !
Wow that was quick! Thank you a lot!
Code change:
<del> { fetchurl, lib, stdenv, squashfsTools, xorg, alsa-lib, makeWrapper, openssl, freetype </del> <ins> { fetchurl, lib, stdenv, squashfsTools, xorg, alsa-lib, makeWrapper, wrapGAppsHook, openssl, freetype </ins> , glib, pango, cairo, atk, gdk-pixbuf, gtk3, cups, nspr, nss, libpng, libnotify , libgcrypt, systemd, fontconfig, dbus, expat, ffmpeg, curl, zlib, gnome , at-spi2-atk, at-spi2-core, libpulseaudio, libdrm, mesa, libxkbcommon

Related discussion:
text: Describe the bug When adding a local directory to spotify client, it always fails due to missing gtk schema(s) To Reproduce Steps to reproduce the behavior: on button Expected behavior Open a file chooser to select which directory to be . Screenshots If applicable, add screenshots to help explain your problem. Additional context Running spotify with flag from console gives me Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
I think that this issue is not NixOS specific:
Still seems to be an issue. I'm using flakes so above is not applicable I'm on.
Tail end of strace.
Yep I can confirm that. However, as IvanMalison commented above, the bug might be not by nixos but by upstream.
I'm getting the same issue as OP when clicking the button I also tried this on EndeavourOS with the same version of spotify and there it works flawlessly. So I think this is actually a nixpkgs problem and not something upstream related. Maybe the issue can be reopened?
Code change:
rm -r $out/share ''; <ins> postFixup = '' # CMake incorrectly calculates library path from dev prefix substituteInPlace $dev/lib/cmake/shogun/ShogunTargets-release.cmake  --replace "''${_IMPORT_PREFIX}/lib/" "$out/lib/" ''; </ins> meta = with lib; { description = "A toolbox which offers a wide range of efficient and unified machine learning methods"; homepage = "http://shogun-toolbox.org/";

Related discussion:
text: Using Shogun as a for another CMake-based project fails because the dependent project cannot properly find the shogun library (via its installed cmake files). Steps to reproduce the behavior: to build a derivation based on shogun files are wrong Everything builds correctly I am trying to build the following derivation However I get an error at the build generation step: This indicates that shogun CMake files are not in the right place and/or are pointing towards the wrong paths.
I fixed the issue with shogun. When installing the configuration files, CMake calculates the prefix to the installed library based on the output directory, instead of the default , and I missed it when I split the derivation into multiple outputs. I wonder why it's not a more widespread issue, only a few derivations patch it. But that derivation still doesn't build: This is in macOS, though. Maybe it works on Linux.
Thanks, is the fix committed yet? The other error is unrelated and I can fix it.
I'm working on the PR.
Code change:
docbook_xml_dtd_45 != null && docbook5_xsl != null && docbook_xsl != null && <del> fop != null && </del> <ins> (fop != null || !enableJava) && </ins> # TODO: Package this: #  epubcheck != null && gnused != null &&

Related discussion:
text: Since is provided by the non-free on aarch64, I'm not able to install asciidoc-full or any software that requires it to create e.g. the man pages. Can we make an option different from ? /cc
Making new granular options is fine, but I think enableStandardFeatures should still include java. (Or else the option is dishonest.) Alternatively, can we switch to openjdk (assuming that works on aarch64)?
It was just recently changed to in I'm fine with granular options, even though it will be quite some work to make packages not use anymore.
Oh, so this problem is due to licensing, not wanting to use non-free software? I didn't pick up on that earlier. How about adding a disableJava option, that has priority over enableStandardFeatures? Hm, this feels like a local solution to a global problem.
is a good idea! What do you think should be the default?
If enableStandardFeatures is true, you should get java. Setting disableJava then enables standard features except those requiring java. I'm not sure if doing this (per package) is a good idea though. Isn't this the start of a new whack-a-mole game?
Yes, it's certainly not a perfect solution, but I can then use an overlay which sets for . Alternatively, we could enable Java for x86 only by default.
Perhaps it would be less confusing to have so the additive condition is positive.
Code change:
if os.path.exists(settings_path): with settings_path.open(encoding="utf-8") as settings_file: <del> settings = json.load(settings_file) </del> <ins> try: settings = json.load(settings_file) except json.JSONDecodeError: print("[Nix] settings.json is malformed, letting Discord fix itself") sys.exit(0) </ins> else: settings = {}

Related discussion:
text: Discord's package has a script which disables breaking updates, by looking and modifying the file. This script breaks if said exists but is empty (fails to load the JSON object) For some reason all values in this file cleared to me and I encountered this issue. (tested on NixOS 22.11 but the script hasn't changed in master) Steps to reproduce the behavior: discord discord should not launch at all (silently, unless launched from a terminal) should handle the exception which arises from this issue. N/A Some logs of when this happens: <!-- 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.
Hmm, interesting that Discord doesn't launch at all. This is a pretty simple fix though, Or something like that (Now that I think about it, if the doesn't exist yet, the script could create it)
Tangentally related: I installed discord on a new machine, and the disable breaking updates script didn't appear to have any effect until I created an empty containing just . There were other files in , but not . Creating that would be nice. Also, the only real indication that it was missing is that when I ran from a terminal, the first line of the output was . This is quite easy to miss because it's at the top of the output, so maybe it would be good to show these errors in a dialog or something similar.
I'm surprised this is even in tree - I don't think we should be changing program behavior - especially when you're calling it . I doubt the majority of the users even knew this was happening outside of those involved in PRs for nixpkgs. This is a matter of convenience like stated in the script that has a trade off causing a degradation in the security of the application - causing users to not update - relying on maintainers to do it. Please create a separate package for this at the same time when fixing this - call it whatever - just not . Or enclose it in an arg that is disabled by default.
I hit this same issue and adding an with contents got it running for me as well.
Thanks for opening an issue and describing the fix. This broke for me too and it took me a while to figure out why ...
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
patches = [ ./fix-path.patch <del> ./0001-Adjust-get_data_path-for-NixOS.patch </del> ./fix-extensions.patch ];

Related discussion:
text: Describe the bug I'm unsure what the error is, but it seems to relate to ulauncher being unable to find the project path, whatever that may be. To Reproduce Steps to reproduce the behavior: Expected behavior For Ulauncher to start normally Additional context This is the error message I get: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(miyuki): nixpkgs: Maintainer information:
See the PR linked above. The issue is that the ulauncher package must be installed via , , , or something similar. Using does not work (for reasons explained in the patch). The PR both updates ulauncher and adds a note to explain what's going on to Nix users trying out the package. I think it would be a good idea to create a NixOS module for Ulauncher. I might be able to do this after I finish exams in a couple weeks.
Alright guys, the real solution here is to just use rofi. With a little work you can make it look pretty good and with a little extra work one could easily make it look similar to ulauncher. Here is my config I tried to fix this issue up but it seemed to work for maintainers thus it was the end of that story
Hello ulauncher package maintainer here. This definitely shouldn't be the end of the story. I do want to get these issues fixed. The problem is that ulauncher wants to store paths to its assets in a config file within . Typically we'd just let it use paths for everything, but that would cause ulauncher to break if we update the derivation then garbage-collect the old paths in . I also use Rofi right now, and it works. But I really want the plugin ecosystem of Ulauncher, so I'm motivated to fix this situation. Perhaps we could modify the current package to allow decoratively specifying the file contents (like ), which would allow the package to be used without messing with system state? Maybe we could even create something like and a NixOS module?
Perhaps this is a good fit for a home-manager module?
Code change:
patches = [ ./fix-path.patch <del> ./0001-Adjust-get_data_path-for-NixOS.patch </del> ./fix-extensions.patch ];

Related discussion:
text: In any case, this issue can probably be closed once is merged. Maybe a new issue should be opened to track the addition of an unlauncher module?
I marked this as stale due to inactivity. &rarr;
bad bot
I installed (rev ) through . Unfortunately, I get this error message on launch anyway.
same issue here