jiebi/CodeConvo huggingface dataset:
Discourse and NixOS matrix channels provide venues for Q&A discussions
With the changes made to ctranslate2, and the fixes to th , I fully expect this could work. If not, please get back to me with some error messages, e.g. the hardening of the systemd unit might cause problems.
No problem. I attempted to use just the new packages, but it became a little difficult because my old nixpkgs didn't think that ctranslate2 could have CUDA enabled, so I'll just wait for master to get pushed to NixOS-Unstable (Hopefully soon!)
The package now fails with . My system may not be correctly configured for CUDA support, or the SystemD Service is not passing through the NVIDIA device correctly. Just a reminder, the following devices are available at : (I'm not sure if is an NVIDIA thing, but it exists if that's of importance.)
Then we're at least missing . What's the content of ? nix DeviceAllow = if [ "cuda" "auto" ] then [ # "/dev/nvidia1" "/dev/nvidia2" "/dev/nvidia3" "/dev/nvidia4" "/dev/nvidia-caps/nvidia-cap1" "/dev/nvidia-caps/nvidia-cap2" "/dev/nvidiactl" "/dev/nvidia-modeset" "/dev/nvidia-uvm" "/dev/nvidia-uvm-tools" ] else "";
I modified the SystemD service to include , and it didn't help at all. The contents of are . Also, I just discovered something new. When running I get So possibly updating this system now broke NVIDIA support and it just so happened to be at the same time I tried to get Whisper working.
Did you also check which is in ? There are two things you need to maintain: 1) your driver should be newer than the cuda libraries used to build your program, 2) your should come from the same (version of) package as the kernel modules (in other words, currently you have to reboot if you update your nixos and get a newer - the new kernel module is only loaded on the next boot)
shows the following for Also, I just rebooted and is working.
from what I listed is accessible from , should my system have functional CUDA support? I tried using some testing parts from , but it seems to be out of date.
Can't build xorriso due to source archive hash mismatch. Steps to reproduce the behavior: the substituter -shell -p xorriso nixpkgs 23.11.5408.
Probably it comes from a moving target... Let's go!
How exactly it happened? Here is the url: Is web archive failing?? P.S.: since Xorriso is just another name for libisoburn, I will remove xorriso and link-alias it to libisoburn.
Project description vcpkg is a package manager for C++ and many large and very small libraries are packaged there. Many of my projects use it for CMake configuration and for its toolchain file that automatically download and build libraries. I want to setup dev environment with nix and this is one of the packages I'm looking for that I've been building manually (since the brew packaged vcpkg is not well configured for manifest files support) Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows
I'll try something now.
Reading the , it looks like a case for a module, not merely a package.
I'm not sure what's the difference between a package and a module... but if it allows me to download a prebuilt binary of vcpkg that I can simply install, that's fine for me. Know that this package manager is made (partly) in C++ and need compiling. The build script is the you see there.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Maybe I am over-engineering here. Reading the AUR script, vcpkg uses systemd scripts/services. Therefore I think it requires more integration with the operating system. Modules are, roughly speaking, designed to "patch" and configure NixOS (the operating system).
Would be nice to have!
Work is ongoing here:
Python module, corresponding to the package and exposing its functionality in Python programs, fails to import, despite being included in . module is imported successfully. n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- (as maintainer) (as the one who exposed the Python bindings) Please run and paste the result.
Note: it seems like the module doesn't work even on commits that introduced it properly... To verify, run in a Nixpkgs checkout:
Yeah, I screwed up testing this. btrfs-progs doesn't propagate python, so I was using my system (non-NixOS) Python installation without noticing. should fix it.
The gitlab  script depends on , which was removed by in . Steps to reproduce the behavior: The update scripts succeeds. (myself) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Also looks like nix-update could be used here.
Ok. looks like switching to nix-update would require some other major refactoring because the writes out some json file out. But here is a simpler approach:
Package name: nexus Latest released version: 3.69.0 <!-- Search your package here: --- Current version on the unstable channel: 3.68.1-02 Current version on the stable/release channel: 3.68.1-02 <!-- 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]:
Package name: gpt4all Latest released version: 3.2.1 <!-- Search your package here: --- Current version on the unstable channel: 2.8.0 Current version on the stable/release channel: 2.7.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, I don't maintain GPT4All any longer, I switched to some other technologies (Open-WebUI).
haha, maybe i'll give that one a try then :) ty for all your hard work
It would be great to have option to fetch nnn plugins with nxpkgs or with additional package instead of manually fetching it like developer advise. And second is it possible to implement some option to include icons support from nerdfont to nnn binary file instead of recompiling it? Thanks.
I think this issue was closed preemptively by the line in the PR, there doesn't seem to be any way to include plugins as of now
nnn seems to expect plugins in . This might work better as a home-manager module, maybe with the plugins themselves as an output of nixpkgs. I might take a look at this next week.
I marked this as stale due to inactivity. &rarr;
I've recompiled nnn with icons, by using unstable branch and overriding nnn-package:
I marked this as stale due to inactivity. &rarr;
Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.
Chromium coredumps on wayland/sway when trying to share a screen. Steps to reproduce the behavior: sway/wayland "" on "share screen" anywhere -Dump A selector for the screen to share should appear According chromium setting: According nixos configuration: Console output when the error occurs: Also this works fine with firefox-wayland and used to work with chromium. <!-- 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.
Could be related to as it also states
Did screen sharing work before / is that crash (segmentation fault) new? And do you know since which version it stopped working? So far screen sharing did never work reliably and there have been frequent regressions: (I've fixed it twice on my test setup but I've given up since then). We might want to close this issue in favor of to keep the discussion in one place.
For me, screenshare works on Chromium v99, and stopped working after update to v100
For me it also worked in the past without issues. This is new and this is chrome core-dumping. This is a different issue. If screen sharing did not work in the past, it just did not work. It did not cause an out of bounds read or crash of the browser. Please don't close this issue.
Sure, we can leave it open. We should mention it in the other issue though (I just did that) for better visibility. Now we need someone with time and motivation to handle this issue (analyzing the issue, searching for upstream issues, etc. and eventually someone needs to submit a fix).
Since this is NixOS and we have the boon of input-reproducibility and a binary cache, could you post: the nixpkgs commit you are on the nix store path of your chromium binary This will make it even easier for others to reproduce. You may also be able to get the stack trace with GDB using , use , make the segfault happen, and use in GDB.
nixpkgs: /nix/store/07346c7jv5wnwg30r5dvmlgqbk52hinz-chromium-100.0.4896.60/bin/chromium
Regarding gdb: ` How do I get gdb on the actual executable but keep the env vars of the shell script wrapper?
Now edit , replacing like this: Then terminate all chromium instances (to avoid joining existing instances), and run .
Thank you for the detailed instructions!
Looks like it should be fixed in m101
I tried to build chromiumDev(102) or chrimiumBeta (101) - but both failed with errors related to:
This patch may be useful: https://webrtc-
I'm a week old to nix, but trying to figure out a way to patch it. It seems it needs a special flag due to it's location:
building chrome is an undertaking not to be embarked on lightly. you can install the chrome dev or beta channel package. On my up-to-date, flakes-enabled nixos-unstable: The issue seems fixed there. There are builds of chromium upstream here: (under other), but I'm not sure if there is a nix derivation for them.
I've opened for a quick and dirty fix - the code isn't pretty but should do the job (I wish would support Base64 patches or even better: Gerrit and gitiles would support fetching patches using a sane format like basically any other web VCS frontend does...). Anyway, I'll check if the VM test passes (although that patch is so trivial that it should be unnecessary) and can merge the fix tomorrow.
I love the name and thanks a lot for your time & effort!
Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…
uses two actions and do get necessary authorization via . but these actions are not properly registed, leading to error: (It can be verified that these actions don't exist by using ) This breaks and . I tried both pcsclite 1.9.5 and 2.0.1 ending up with the same error. Steps to reproduce the behavior: and in , configure your smartcard (yubikey) to use yubikey error There actions are registered correctly and usable. Please run and paste the result. I'm using flakes (no channels). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
correct description of your effect, i am not able to use my yubikey with gpg.
This can be solved by
this works, thanks! but this is really unintuitive, given that is already adding the package to : I am leaving this open as I believe a proper fix should be provided in the module itself.
Same issue here. It was working approx. last Dec. I don't have a specific commit hash. Adding to works for me.
Looks like a regression in () - is implying to me that polkit actions get included in the output, however: isn't included, which explains why adding to fixes the issue. Solution ideas: Add to . Not sure about this one? seems to also contain some libraries that probably don't need to be installed. Install polkit actions to instead of . IMO this one makes the most sense, especially as it seems to have been the previous behaviour before this change.
I was bitten by this when attempting to update over the weekend as well. In my case it prevented login because I use smartcards for user login which made debugging difficult due to the number of reboots required. I tend to agree with that going back to having the polkit actions file in the output instead of makes the most sense. That will mean that of the pcsc module will again result in the polkit action file being to the system configuration.
Cc: ()
I also think the location should be fine, the files are also there.
I ran into this issue when I couldn't access my yubikey anymore via pcsc for commits. The above solution worked for me.
I'm going to add some comments for SEO so this is easier to find
I think you have found the right culprit that caused the issue, but I suppose the issue has more to do with the itself, where it only includes if . This has been rectified in from what it seems. For now the proper solution seems to enabling polkit with .
I think that makes more sense based on the existing file structure but maybe we just switch bin to out, so it is the default and move the libs to lib instead of being in out.
I've created to make the outputs a lot more expected by moving the udev file and the systemd service to the out output and the libraries to the lib output: I didn't test it yet, so it is still in draft. If someone could verify that it doesn't break security keys again, that would be great and then please undraft it, otherwise I do it in the evening.
I do not think I can fully test this due to the amount of rebuilds, so please chime in for reviews and find the one mistake I might have done (which I hope I didn't)
Tried to build but it fails on my machine:
I've xdist to dulwich here . Let me see if we can just disable some tests as a speed up from 66s to 9s is quite good.
This should be a lot better with . I did a lot of rebuilds locally on a low and high core machine and didn't encounter any failures anymore.
This was fixed in , works fine for me.
When executing switch-to-configuration in a pure environment it fails: I am calling switch-to-configuration via systemd-run to active a new profile using the Hail update tool. The actual executed script is as follows: Actual output: <preactivating the configuration... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up /etc... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up tmpfiles Too few arguments. sh: systemctl: command not found </preThe script works if I pass on the PATH and LOCALE_ARCHIVE environment variables: System: (NixOS: 17.09pre-git (Hummingbird)) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: nixos-unstable (Commit ) Sandboxing enabled: no (Related Hail issue: )
Steps to reproduce the behavior: on old thinkpad Device: Thinkpad X220 <!-- 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.
greetings ! are you able to test ? an other workaround is to stick to < 6.4 kernel
for now I can't test your commit since I'm newbie and asking you to teach me would take a lot of your time Gonna stick to < 6.4 kernel and try to test commit in free time
appreciate your concerns! from looking at your setup you seem to know fair bit already, and I dont mind spending some time for as long we all learn something useful you should be able to test that PR by changing in your flake to edit: also no rush to test this
Well that was actually easy to test! PR works! I thought I need to use overlays to test it and I have zero experience with them for now.
The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.
Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
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 . on the on .
Still important to me, many qt apps are broken on darwin due to this one.
Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).
If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.