jiebi/CodeConvo huggingface dataset:
Would be a very useful package to have for ML Enthusiasts Project description Machine Learning Catboost Library Metadata CatBoost is a high-performance open source library for gradient boosting on decision trees homepage URL: source URL: license: Apache License 2.0 platforms: Linux installation instructions: Please let me know if I should stop tagging you in random issues and it bothers you (sorry, i'll stop), but I thought this might be of interest to you since you are very involved in tensorflow.
taggining maintainers of xgboost and lightgbm. Wondering if you could look into compiling catboost too?
I use tensorflow at work, which is why I care :). But I'm not a data-scientist
understood, thank you. GPU support for catboost would also be very welcome.
Looks like they have a non standard install script. But definitely doable. Sadly I don't think I have time in the near future but would be happy to point you in the right direction to get stared with a PR
both eyes wide open - i'll try to start this w/e, any pointers very welcome, thank you.
Currently failing to build on nix, although the file clearly exists.
- maybe it's easier if you create a work-in-progress pull request so other people can check? Two things that stand out are: looks like something is being downloaded during the build process. This won't work with sandboxing because there won't be a working network. builds should be isolated, i.e. access to should be rewritten to the local build directory, not (probably hardcoded somewhere in the build scripts). Packaging for nix can be quite fiddly - I think might be a good example for fetching complex dependencies + build script patches.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Clang's wrapper does not set as an include path. Compiling files with since <cxxabi.hrequires is present in the aforementioned path I created the environment using this minimal mkShell expression Adding to
Proposed solution seems reasonable to me. See also started by
Please can you also include the nixpkgs commit hash in the repro (sorry if it's there and I missed it).
Oh thank you, that makes so much sense, I was also looking at how the monorepo handles things as well as their tests on finding the system include headers and what you said is probably the correct reason. Ah, it was the nixpkgs-unstable revision updated just then. Sorry I do not have that, but you can reproduce it with the current master as well.
Package name: tracker-miners Latest released version: 3.7.3 <!-- Search your package here: --- Current version on the unstable channel: 3.7.2 Current version on the stable/release channel: 3.6.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. -- Tracker was updated in , however tracker-miners wasn't. It currently suffers from this bug: (and generates a lot of failures on a running gnome system). It was fixed in 3.7.3. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
PRs are welcomed.
Which version does it attempt to build? See for explanation.
9
Hmm, are you sure procps(-ng) can work on darwin? I found just
The only reason I wanted it was for the utility, which does work on Darwin. Homebrew has a separate installation target for , so maybe we can do that too.
I see, I noticed that. I'll leave it open then.
Since there is now a specific watch expression, this is no longer a bug.
Package name: atuin Latest released version: 18.0.1 Current version on the unstable channel: 18.0.1 Current version on the stable/release channel: 17.0.1 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you are planning to open a PR anyway, you don't need to open an issue.
Cool, thanks. I was unsure of the policy around that
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.
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]:
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.
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 ?
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.
<!-- 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
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!
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?
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.
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.
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:
Project description forwards dns over https queries to normal dns servers and vice versa. Metadata homepage URL: source URL: license: apache 2.0 platforms: unix, linux, darwin, ... ubuntu package url:
Upstream has system services. Is there a need to include these modules (services) within this package? I would prefer not to include them if there is no need, because is not actively developed and has not released a single stable version yet.
I personally don't need them, because I prefer creating systemd services via nix configuration anyways.
Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in
Describe the bug Blender segfaults when an OpenCL render is attempted. To Reproduce Steps to reproduce the behavior: Properties (right panel) Select Cycles, change device to GPU Compute Expected behavior It should render. Additional context May be related to and 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 system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: Blender gdb backtrace: I'm using a Radeon VII with: gives me:
cc
This seems like an upstream issue. The question is which upstream? Does the crash also occur with e.g. the Intel OpenCL runtime?
FWIW, I also see the segfault on an rx580 following the repro instructions. It does like others have Blender working with ROCm OpenCL, so the crash may well be due to our packaging. did such a nice job cleaning up our LLVM derivations that there's much less room for funny business now than with previous releases. I see that we have a option we could give LLVM which might reveal a bit more information?
I can also reproduce the problem on a RX580. Here somebody has the same issue, with a plausible explanation: The conclusion there is that it occurs when two different LLVM versions are used in a process. Which would be the case here, since Blender uses OpenGL. Currently our Mesa is still on LLVM 9, whereas ROCm uses LLVM 11.
Yep, this is probably the issue. If I compile the derivation with a built against , I don't get the segfault. I am not sure yet what the solution is, since we cannot always update the LLVM version that Mesa uses to that of ROCm. I wonder how this is dealt with with ROCm on other distributions. Do they override the system Mesa?
I guess I should have turned up that link first given my prior involvement! Could we substitute a at runtime instead? Perhaps via ICD, or , or even ?
There is , which we could use to override system package. I guess if it works, we could add a module along the lines of the support, which would use as the OpenGL package and could even add the ICD definition to .
But we should probably first test how well building mesa against the LLVM fork works. At least it builds ;). I might have some time to look at this after work.
If you have a chance, could you elaborate on how you did this in nixos?: I understand that it's not the permanent fix, but I'm quite curious to try it.
I modified nixpkgs in-place, but you could do something like: And then: A more proper solution would be to switch to a -built Mesa for . I do have a branch for this: or the two commits: But I ran into another issue in Blender, and I didn't have time to investigate. The system (including GNOME, etc.) worked fine with Mesa built with llvmPackages_rocm.
Sorry. I misremember. I may have rebuilt my system with Which should be equivalent to having an overlay But I am a bit nervous about switching Mesa to a vendor-forked (IIRC prerelease) of LLVM. We should just document this incompatibility for 20.09 and then perhaps land something like the proposed branch/module in master/21.03. But that definitely requires more testing.
i tried your amdgpu-rocm thing but now blender crashes with this error when opening user preferences: is this the error you mentioned you didn't have time to debug?
That's the one. I am afraid though that I can't help with any further debugging. I had to replace the RX580 in the machine I was testing on by an NVIDIA card, because there were too many issues with training machine learning models on the RX580 :confused: .
this seems very similar to and replies there would seem to indicate that it's still some LLVM incompatibility, but i'm not sure what is incompatible here... is it blender itself?
I think the core problem is that both OpenGL and OpenCL (through winding paths) each load their own instances of LLVM into the process, and those instances of LLVM somehow end up sharing some global data, with usually disastrous results.
It seems that upstream now explicitly states that ROCm is only for headless deployments: Given the risks of compiling Mesa against a vendor fork (we get to fix any bugs), I think that we should just document this in the AMD -OpenCL section of the manual and leave it at that. Do you agree ?
Given this and the lack of RDNA support, I guess the future of OpenCL for GUI apps is with Mesa's Clover.
I do agree, yes. An AMD employee has been trying to walk things back, but who knows. It doesn’t make sense that they just switched their consumer driver to use ROCm for OpenCL if they don’t have a vision of getting in sync with Mesa, but that’s clearly their row to hoe.
I'm amazed AMD has any foot left to shoot at.
I marked this as stale due to inactivity. &rarr;
Still important, though only in general (OpenCL in GUI apps with AMD GPUs), because .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think I finally figured out a workaround! Disabling for seems to work. I did it with the following patch to nixpkgs, but it should be possible to do it with an overlay too: After a lot of building, Blender seems happy again :) !
If this works, it is incredible. How would I do it as an overlay?
I think this should do it. It's ugly and there might be a better way but it should at least make it easy to test if it works for you. I'm still trying to figure out if there's a simpler fix (for example, overriding just ), but haven't been able to figure it out yet.
It works for me. I suggest you make a PR with this change to Nixpkgs. It may seem a bit ad-hoc, but otherwise it is not possible for a process to have both OpenGL and ROCm OpenCL loaded simultaneously, which seems like a pretty common use case.
Now that I know it works for other people I'll try to make a PR in the next day or two, yeah :)
On NixOS 22.05, getting financial quotes in gnucash no longer works because the helper scripts are now binary wrappers, but gnucash calls so this fails. Commit suggests that should avoid this, but for some reason the scripts still get wrapped with binaries. NixOS 22.05..
I can reproduce this on my machine from nixpkgs/master, so it's not a 22.05 problem. Interestingly, when I backport GnuCash's derivation from nixpkgs/master back to a known-good commit (), things appear ok. I'll continue digging.
... I see you yourself as a maintainer. Any interest in taking a stab at this? Per I think we're being broken by a change somewhere related to .
... I see you yourself as a maintainer. Any interest in taking a stab at this? still getting my head together after a bad bout of covid, not sure I'll be able to work on anything serious any time soon
I worked around this on my nixos config by adding a patch () to execute the helpers directly without calling out to perl. It seems to work for me. Will this break anything? If desired, I can submit a PR with this patch. Also, the perl helpers seem to be getting wrapped explicitly () is this not the reason the perl helpers are getting wrapped with binary executables?