jiebi/CodeConvo huggingface dataset:
Project description Yet Another way to use Windows VST plugins on Linux. Yabridge seamlessly supports using both 32-bit and 64-bit Windows VST2 and VST3 plugins in a 64-bit Linux VST host as if they were native VST2 and VST3 plugins, with optional support for plugin groups to enable inter-plugin communication for VST2 plugins and quick startup times. Its modern concurrent architecture and focus on transparency allows yabridge to be both fast and highly compatible, while also staying easy to debug and maintain. If I understand correctly, this provides similar functionality to the airwave package. I think the big plus to this package though is that it emulates as if they were native which means the build process doesn't need to require the user to go to the steinberg site and download the VST SDK (as airwave currently does). I used this on Arch with Reaper and it was extremely easy to get going. I had a much easier time using yabridge than trying to get carla set up and running. There are multiple AUR packages for installing from source or just pulling in the binaries. I've tried to package this myself but it's just a bit beyond my means. I think that if someone is more familiar with packaging wine related binaries or compiling with meson from source this would be a quick win. homepage URL: source URL: license: GPL 3.0 platforms: linux
I probably won't have time today, but I can take a look at this later. I'm pretty familiar with the nixpkgs wine build, and I've worked with the ZynAddSubFx build to add support for the Zyn-Fusion ui.
Amazing. I was able to take your PR and get Upright Piano working with Reaper as well. Thank you so much for the quick turn around, I really appreciate it.
Hi! I don't use NixOS myself, but if it helps, there's one person in the yabridge Discord currently using yabridge's master branch with NixOS. And I've also ran into another Nix build definition on GitHub in the past (but that one's pretty outdated by now).
I've just released with a lot of important new features, fixes and improvements including the first ever Linux <-Windows VST3 plugin bridge.
I saw that the package created by for yabridge 2.2.1 has not been merged yet, but please let me know if you want to update the yabridge and yabridgectl packages for yabridge 3.0.0 and need any help! One additional dependency is now a patched version of the VST3 SDK which is patched to compile under winegcc and with support for Meson. I'm not quite sure how Nix packaging handles those things.
Thanks, I have it building right now. I'm just testing out vst3 plugins right now :smile:
:cry: For some reason neither the vst2 or vst3 plugins are working, even though they get synced. I think it might be an issue with my system installed wine. I'll submit my changes anyway so other people can test it out.
So they are found but yabridge fails to load them? Which Wine are your derivations using?
You can try running manually to see if that is the issue. A plain call should print: And should print:
I'm able to sync them with yabridgectl, but they fail to load in Reaper. I'm using (currently version 6.0) to build yabridge, but I have a custom build of wine staging 6.0 currently installed. seems to be working fine:
That indeed seems to work as expected, that's great news! If you start REAPER with and then take a look at after trying to scan/load a plugin then you'll probably be able to figure out what's wrong very quickly.
Hmm, apparently the path to the VST host is too long :stuckouttongue:
Huh I can't think of from the top of my head what would be throwing such an exception. That message printed after comes from a try-catch around the entire plugin startup that catches and prints any . Windows (and thus Wine, because it has to be compatible haha) has a path name limit of 255 characters, but none of those paths sound like they should come close to that.
Yeah, sorry. It was just a problem with my home environment. I was trying to test it without installing because I lost the nixpkgs commit I used to generate my home-manager environment.
Currently, our Android SDK derivations contain only binary files. This is unfortunate during development, when one wants to jump to a definition of a particular symbol in the SDK and it is not found. For comparison, ArchLinux is doing this in their packages, e.g. System: 16.09pre-git (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09beta335." /cc
Created PR .
Describe the bug Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs: Maintainer information:
I've also encountered this. I bisected it to . says there's a newer version (1.) whose release notes say "Fix two test failures on newer versions of gtk+/gnome-shell/mutter". However, updating to it does not fix this test failure. :( With 1., the exact failure I'm getting is:
When updating to GNOME 3.34 I did indeed notice this and tried the exact things did. We probably need to report it so it can be fixed, I just didn't have the time to do this. Guess the testsuite could be disabled.
Disabling tests got it to build for me. I'll try to find some time to open a PR for that, and to report it upstream.
Reported upstream:
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 .
Describe the bug Keyboard backlight keys don't work out of the box on LXQT. Pressing one brings up a polkit dialog for authorization to run as superuser. Of course, changing the backlight brightness should not require authorization. liblxqt provides an function in which I believe is the problematic code path. This function calls a helper utility as follows: FILE lxqtbacklightbackendgetwritestream() { FILE stream = popen("pkexec lxqt-backlightbackend --stdin", "w"); return stream; } There is a polkit rule for this: $ cat <?xml version="1.0" encoding="UTF-8"?<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" ""<policyconfig<action id=""<messageAuthentication is required to Change Brightness</message<iconnamebattery</iconname<defaults<allowanyno</allowany<allowinactiveno</allowinactive<allowactiveyes</allowactive</defaults<annotate key=""${CMAKEINSTALLPREFIX}/bin/lxqt-backlightbackend</annotate</action</policyconfigHowever, this rule ends up expanding to e.g.: <annotate key=""/nix/store/k1w634ib02dxqh046icm2i7ml28iycq5-liblxqt-0.17.0/bin/lxqt-backlightbackend</annotateand polkit is presumably just finding the binary in . It appears that pkexec doesn't resolve symlinks, as if I run on the path, I get the prompt, whereas if I run on the resolved path, I don't get prompted, and I can adjust the brightness from the command line. I'm not sure what the proper solution is here. I don't know enough about polkit to have an opinion on its symlink handling. Maybe we can provide another polkit rule for the path? To Reproduce Steps to reproduce the behavior: LXQT and boot into it. a display brightness key on your keyboard. polkit dialog appear. Expected behavior Display brightness should be adjustable without entering your password. Screenshots If applicable, add screenshots to help explain your problem. Additional context I'm running NixOS 20.09, and have hit this bug both with the shipped LXQT, as well as when I backported 0.17.0 from .
LLVM 12 (not yet released, currently at RC3) will be required for building Chromium M90+ (currently in the beta channel; stable release planned for 2021-04-13; s. ). cc I couldn't find a draft PR for LLVM 12 yet. Are you already working on it or currently busy? LLVM Release Schedule: 12.0.0: Jan 26: release/12.x branch, 12.0.0-rc1 Feb 23: 12.0.0-rc2 Mar 2: 12.0.0-final
I have't started yet. But I think I have a few minutes now!
Just a heads-up, we have Should that transition to ?
I have to hand this over to you, Borg says the unit tests fail (on both platforms, consistently). Maybe the testing framework needs a bump?
Actually, LLVM is not enough I tested with and the key commit seems not included into You have to either wait for compile LLVM now cherry-pick to or related
The match is a bit out of context: We have so everything should be fine. ok, thanks for that information! If I understand that correctly you've tried compiling or with and it requires cherry-picking as well (which would be unfortunate because that commit might not be part of the final release; they don't seem to have a dedicated branch for the LLVM 12 release and I don't know where/how/if they track and provide that information - Edit: Oh, they have a branch (the GitHub UI doesn't seem show all branches that a commit is part of) but wasn't cherry-picked so far).
I built (from llvm master, simple replacing with fetchFromGitHub and removing some lines in ) and it builds Chromium 91
RC3 in
Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:
Package name: surrealist Latest released version: 2.0.1 <!-- Search your package here: --- Current version on the unstable channel: 1.11.7 Current version on the stable/release channel: - <!-- 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 Surrealist has now officially moved to the SurrealDB Github org, see Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Nvm the nix package is actually built from source, just Tauri builds a deb in that process
Working on it. I'm currently stuck at an issue with the frontend build. There is a transitive dependency to that does not get installed by pnpm.
Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.
c.f. If using --patterns-from, all of the paths to back up are (or can be) read from the pattern file, and specifying paths on the command line is optional. But the nixos configuration won't let you omit the paths, and since they aren't stored in a variable you can't even do something awkward with preHook or preCreate to unset them.
While investigating this, I found the related issue that since it requires "paths" rather than "strings" it also only works for absolute paths; if you want to back up relative paths (using preHook to make sure they're relative to the right directory) this is impossible. Not sure if that's worth opening a separate issue for.
I changed it to .
Thank you!
Package name: podman-tui Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.18.0 Current version on the stable/release channel: 0.12.0 <!-- 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. --I attempted to update this package myself and create a PR, however, there appears to be a major changes to how this package is built that are outside my ability to address. Attempting to build the package after a , both with and without the changes in , results in the following build log: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
XRootD failed to access the files following the URL, complaining that isn't found and the authentication handler couldn't be loaded. However, does present in the output directory. Steps to reproduce the behavior: Enter the top directory of Nixpkgs See Run See the detailed output A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Terminal output during execution: Short: Long: is packaged by myself, but I haven't found the solution. Suggestions and helps are more than welcom. Please run and paste the result.
This is probably because has the wrong . How to fix that though? No idea.
Package name: electrum Latest released version: 4.4.4 <!-- Search your package here: --- Current version on the unstable channel: 4.4.0 Current version on the stable/release channel: 4.4.0 <!-- 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. Reporters Note: Tried the update locally and got the error Looking at the diff on the electrum github I see the substituteInPlace pattern will no longer match: In:
PR in
Project description Unity is changing the way they deliver the editor via the UnityHub. They have shifted away from the appimage and have started Debian and RHEL repositories. They are not producing the appimage anymore. Would it be possible to add the new UnityHub to NixOS? The new download instructions are here:
Extracting the binary from the .deb is fairly simple and has been done in similar situations in nixpkgs before.
Is there any quick fix to use unity right now?
Not that I have found. You could use an old version of the appimage if you still have one. The flatpak is available but is a really old version.
I am currently building a derivation locally to extract the binary from the .deb package and make it run. Lets see how long it takes
have you had any success? I have but it yells about and crashes when I try to use it
I thought that unityhub is an electron app. My current attempt results in a f mismatch from electron. Here is my . I build it via .
Yeah it is electron but I'm just trying to package the prepackaged electron binary instead of using system electron
Yes you are right. When trying to use the included electron binary it will result in the same error. Hm when I have some time I will investigate with . Or maybe you had any luck?
Unfortunately not, I've seen one other mention of the same error with electron with no solution, and I'm not sure how to do deeper debugging personally.
I've managed to do something: by adding to LDLIBRARYPATH, I can get it to not , but now instead it just hangs... I'll keep trying but I'm not sure what it is this time.
I've made a tad more progress, I forgot to enable gnome-keychain so that was causing the hang, but now it's segfaulting :sweat: I do see it looking for but I'm not sure what that even is
Finally, got it working. It boots up and I can install everything properly. The remaining issue is that hub-installed versions of Unity aren't patched so the hub fails to launch them. It seems that since the previous version used appimages, the library paths were passed to the editor as well as the hub, but I'm not sure how to do it with this. Do I need ?
I'll try that but I'm not sure if there's a more optimal solution.
Looking at the code seems to be the way. !
<details open<summaryWeird error I'm getting when I'm trying to open say Preferences or the Package Manager in the unity editor.... I have no idea what this is from, am I missing gtk stuff?</summary<br</details
Hopefully the final bit of the saga, it turns out the GTK issue I had isn't unique to NixOS, it occurs on other distros too, see the . In that case, it seems my derivation for the updated Unity Hub is working properly in all other regards, and can be found . All the need to be cleaned up, I may have a few unnecessary ones, and there's a lot of leftover testing with the QML paths :sweat_smile:. If it looks good, perhaps we can update Unity Hub in nixpkgs too? I've also made a describing how to use Rider with Unity on NixOS as well, might help someone out.
Thanks for that looking forward to seeing that on master!
Hehe thanks for the reminder, forgot to make a PR for updating the package!
I just copied your derivation meanwhile and was the only thing it make unity work (installing the 2021.3.4), thanks!
Hello I use Unity and just tried out file. It works great! However, I cannot find your PR. Would you be able to point me in the right direction? I would love to see this in nixpkgs soon!
I've been kinda busy recently with other prs and such, but I'm definitely planning to make a PR in nixpkgs, if not later today, definitely by this weekend. Thanks for the support :)
I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week
When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- 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.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see
Steps to reproduce the behavior: odin If you run the resulting binary through you'll see this strange backtrace: I think it has to do with the version of the C++ standard library that is getting linked. Adding and to the and updating the file to explicitly link allows it to run without segfaulting. (But thats just a workaround I'm using). EDIT: During more testing with the built binary, it also doesn't use the correct linker, which can cause problems if you are linking with Objective-C code/frameworks (not sure if this is a problem with how Odin is packaged with nix, or if its a problem that the Odin devs need to solve). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Note: Was fixed by
macOS Odin support is kinda scuffed anyway with any deviation from what's expected. do you have the code for your workaround somewhere? then i can see if i can patch it in
I'm using for my project. It doesn't have any switching based on OS, and my override probably isn't necessary either. Honestly, the is probably the only thing needed to stop the seg faulting.
updating to llvm17 is not a bad idea either
When using an option with , the type description references the nested type's name instead of its description. This can lead to type descriptions like "function that evaluates to a(n) functionTo". Nix expression to reproduce: Reproduction in NixOS: The Nix expr should print something like "function that evaluates to a(n) function that evaluates to a(n) string". The command should print a type description like "function that evaluates to a(n) list of packages".