jiebi/CodeConvo huggingface dataset:
Code change:
metapixel = callPackage ../tools/graphics/metapixel { }; <ins> yabridge = callPackage ../tools/audio/yabridge { wine = wineWowPackages.minimal; }; yabridgectl = callPackage ../tools/audio/yabridgectl { }; </ins> ### APPLICATIONS/TERMINAL-EMULATORS alacritty = callPackage ../applications/terminal-emulators/alacritty {

Related discussion:
text: 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.
Code change:
metapixel = callPackage ../tools/graphics/metapixel { }; <ins> yabridge = callPackage ../tools/audio/yabridge { wine = wineWowPackages.minimal; }; yabridgectl = callPackage ../tools/audio/yabridgectl { }; </ins> ### APPLICATIONS/TERMINAL-EMULATORS alacritty = callPackage ../applications/terminal-emulators/alacritty {

Related discussion:
text: 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.
Code change:
metapixel = callPackage ../tools/graphics/metapixel { }; <ins> yabridge = callPackage ../tools/audio/yabridge { wine = wineWowPackages.minimal; }; yabridgectl = callPackage ../tools/audio/yabridgectl { }; </ins> ### APPLICATIONS/TERMINAL-EMULATORS alacritty = callPackage ../applications/terminal-emulators/alacritty {

Related discussion:
text: REAPER was just loading the old 2.2.1 yabridge- :woman_facepalming: I just finished rebuilding my home environment with a new nixpkgs commit, and it's working now :smile: .
Code change:
stdenv.mkDerivation rec { name = "gnome-desktop-${version}"; <del> version = "3.30.2.1"; </del> <ins> version = "3.30.2.2"; </ins> outputs = [ "out" "dev" "devdoc" ]; src = fetchurl { url = "mirror://gnome/sources/gnome-desktop/${stdenv.lib.versions.majorMinor version}/${name}.tar.xz"; <del> sha256 = "07s95fpfl3kjq51yxbrx6q87w812pq6bl0xdn0zzyi6qvg33m00v"; </del> <ins> sha256 = "02ksmq2h4jjvjalp5x6d6v36qnp1h66qxwv2gl7kbx7dxqcp6ys3"; </ins> }; enableParallelBuilding = true;

Related discussion:
text: , (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.
Code change:
"--with-unsigned-addon-scopes=app,system" ]; <ins> extraPostPatch = '' # Fix .desktop files for PWAs generated by Floorp; they hardcode /usr/bin # https://github.com/NixOS/nixpkgs/issues/314115 substituteInPlace floorp/browser/base/content/modules/ssb/LinuxSupport.mjs  --replace-fail /usr/bin/floorp floorp ''; </ins> updateScript = ./update.sh; meta = {

Related discussion:
text: Steps to reproduce the behavior: floorp Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, Please elaborate - there does not seem to be any actual build failure here. What's the actual error? Are you sure your build machine has enough resources? A browser build is pretty demanding and can take even multiple hours on low-to-mid-end machines. Can you please also post the complete derivation log, as obtained using ?
I have the same problem (with floorp and floorp-unwrapped). Here’s the error: ! That feature was removed in February, so either update the qcms crate to 0.3 or downgrade the rust compiler version (1.76 could work).
is the log in the link not enough ?
Oh, I see, Github just truncated the file in the UI. That's what you get from hosting projects on crappy, proprietary software .. Pointing out the exact error too from the get-go would have been helpful in any case. Anyway - seems it broke with a recent rustc upgrade in nixpkgs. This is already fixed with 11.14.1, as it updates the firefox base source. See .
Okay, I will host my opengist instance for the next time ;) Thanks for your prompt response, waiting for your pr to be merged.
Any ETA on the PR merge?
Floorp is now in version 11.14.1 on unstable.
Code change:
"--with-unsigned-addon-scopes=app,system" ]; <ins> extraPostPatch = '' # Fix .desktop files for PWAs generated by Floorp; they hardcode /usr/bin # https://github.com/NixOS/nixpkgs/issues/314115 substituteInPlace floorp/browser/base/content/modules/ssb/LinuxSupport.mjs  --replace-fail /usr/bin/floorp floorp ''; </ins> updateScript = ./update.sh; meta = {

Related discussion:
text: When installing a PWA using the Floorp browser (experimental toggle in settings), the installed desktop file uses /usr/bin/floorp as the path for the browser to run said PWA. Steps to reproduce the behavior: Floorp experimental PWAs in settings a PWA, e.g. Github or Excalidraw the newly spawned PWA window to launch the same PWA from your DE's application launcher The PWA opens. ! , using flakes, installed via <!-- 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]:
Thanks for reporting! As well as the upstream report! I can look into it what we can do as I get time. But as I'm the only maintainer for Floorp and currently pretty much out of time due to university and $dayjob, I cannot promise any timeline unfortunately. But happy to review patches, of course, if you'd like to fix it yourself. Can you provide such a generated file for further investigation?
sure, one such generated desktop file with the example of excalidraw can be found (github doesn't allow for drag and drop of .desktop files)
Hello! I don't have experience maintaining and modifying large packages like Firefox (floorp), and I currently don't have much free time. However, I've discovered how floorp generates the .desktop file for PWA applications: Maybe it will be helpful to you.
Thanks, that is indeed helpful! Should be relatively easy patchable by us then, from the looks of it.
upstream has and now it will use the path it was in at the time of creating the PWA. It may not be too big of an issue if what they say about fixing it in the next version is true but now the patching will probably fail.
Code change:
${attrsToSection def.bondConfig} ''} <ins> ${optionalString (def.wireguardConfig != { }) '' [WireGuard] ${attrsToSection def.wireguardConfig} ''} ${flip concatMapStrings def.wireguardPeers (x: '' [WireGuardPeer] ${attrsToSection x.wireguardPeerConfig} '')} </ins> ${def.extraConfig} ''; };

Related discussion:
text: This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.
Code change:
GITOLITE_RC_DEFAULT = "${rcDir}/gitolite.rc.default"; }; <del> serviceConfig = { Type = "oneshot"; User = cfg.user; Group = cfg.group; WorkingDirectory = "~"; RemainAfterExit = true; }; </del> <ins> serviceConfig = mkMerge [ (mkIf (cfg.dataDir == "/var/lib/gitolite") { StateDirectory = "gitolite gitolite/.gitolite gitolite/.gitolite/logs"; StateDirectoryMode = "0750"; }) { Type = "oneshot"; User = cfg.user; Group = cfg.group; WorkingDirectory = "~"; RemainAfterExit = true; } ]; </ins> path = [ pkgs.gitolite pkgs.git pkgs.perl pkgs.bash pkgs.diffutils config.programs.ssh.package ]; script =

Related discussion:
text: Describe the bug My server uses an encrypted filesystem /data that I have to mount manually after reboot. Gitolite is configured to use /data/gitolite. I have configured gitolite-init to only run once /data is mounted. Mounting of /data always fails, as gitolite uses to generate directories and thus the mountpoint is not empty. Manual cleanup is required every time. Expected behavior Gitolite should create its directories in gitolite-init.service. Additional context systemd-tmpfiles-setup.service runs before the system is fully initialized, so I cannot delay that service. 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:
I'll try to address this in the next few days.
Code change:
"-DENABLE_SYSTEM_GMIC:BOOL=ON" ]; <del> patches = [ # NOTE: this should be removed when a new version is released. (fetchpatch { name = "fix_filter_translation_scripts.patch"; url = "https://github.com/c-koi/gmic-qt/commit/ccb9f29eda239d0c80663593cd90a6548c935b39.patch"; sha256 = "sha256-OzuJ6yGuDJweQ+1uin/pmJqZV79bN9E1Zuo+0iciwzg="; }) ]; </del> postPatch = '' patchShebangs  translations/filters/csv2ts.sh 

Related discussion:
text: Steps to reproduce the behavior: gmic in a nix shell using the unstable channel Add any other context about the problem here.
Will be fixed by
Thanks! Note that it makes darktable fail to build.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
stdenv.mkDerivation rec { pname = "vulkan-loader"; <del> version = "1.2.189.1"; </del> <ins> version = "1.2.198.0"; </ins> src = (assert version == vulkan-headers.version; fetchFromGitHub { owner = "KhronosGroup"; repo = "Vulkan-Loader"; rev = "sdk-${version}"; <del> sha256 = "1745fdzi0n5qj2s41q6z1y52cq8pwswvh1a32d3n7kl6bhksagp6"; </del> <ins> sha256 = "sha256-k3eCdZqCjFxpKa0pZ0K4XcORxdSOlr1dFa7C3Qzi04Y="; </ins> }); nativeBuildInputs = [ cmake pkg-config ];

Related discussion:
text: name: All packages in current version: 1.2.189.1 desired version: 1.2.200 maintainers: Please tag this issue in your PR.
Code change:
<del> source 'https://rubygems.org' gem 'chef-dk', '4.13.3' gem 'pry' gem 'test-kitchen' gem 'inspec' gem 'kitchen-inspec' gem 'kitchen-vagrant' gem 'berkshelf' gem 'chef-vault' gem 'foodcritic' gem 'ohai' gem 'rubocop' gem 'knife-spork' gem 'fauxhai-ng' gem 'chefspec' gem 'chef-provisioning' </del>

Related discussion:
text: ChefDK is deprecated and no longer maintained by Chef. This package is currently maintained by and I believe ChefDK should be dropped and replaced by Chef Workstation (see issue ). This has been deprecated since 2021.
Code change:
free = true; }; <ins> fairsource09 = { fullName = "Fair Source License, version 0.9"; url = "https://fair.io/v0.9.txt"; free = false; redistributable = true; }; </ins> issl = { fullName = "Intel Simplified Software License"; url = "https://software.intel.com/en-us/license/intel-simplified-software-license";

Related discussion:
text: Project description <!-- Describe the project a little: --Metadata homepage URL: source URL: license: platforms: darwin
Code change:
sha256 = "sha256-Ha0bIh3SYMhA28YXQ//Loaz9J1lTJAzjTx8eK3AqUjM="; }; <del> patches = [ ./option-debugging.patch ]; </del> <ins> patches = [ ./option-debugging.patch # ffmpeg 6 fix https://github.com/cmus/cmus/pull/1254/ (fetchpatch { url = "https://github.com/cmus/cmus/commit/07b368ff1500e1d2957cad61ced982fa10243fbc.patch"; hash = "sha256-5gsz3q8R9FPobHoLj8BQPsa9s4ULEA9w2VQR+gmpmgA="; }) ]; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ ncurses ]

Related discussion:
text: Steps to reproduce the behavior: cmus on current (). Full logs: I haven't updated in a while, so I'm not sure where this failure starts. Nothing has changed in the cmus package; it must be a change in dependencies. system: host os: multi-user?: sandbox: version: channels(root): channels(jamesw): nixpkgs:
cmus started failing somewhere between (good) and (bad). I don't have the hundreds of gigabytes of RAM that would allow me to do a bisection between those, so I'll leave that to someone else.
Manually going through it suggests as a possible culprit. I have no idea what that commit does, though, yet.
the issue is bump of ffmpeg to 6, i am about to push a fix
Code change:
octoprint = callPackage ../applications/misc/octoprint { }; <ins> oculante = callPackage ../applications/graphics/oculante { }; </ins> ocr-a = callPackage ../data/fonts/ocr-a {}; ocrad = callPackage ../applications/graphics/ocrad { };

Related discussion:
text: Project description Oculante's vision is to be a fast, unobtrusive, portable image viewer with wide image format support, offering image analysis and basic editing tools. Metadata homepage URL: source URL: license: MIT platforms: cross
Code change:
stdenv.mkDerivation rec { pname = "cardinal"; <del> version = "23.09"; </del> <ins> version = "23.10"; </ins> src = fetchurl { url = "https://github.com/DISTRHO/Cardinal/releases/download/${version}/cardinal+deps-${version}.tar.xz"; <del> hash = "sha256-q42ry47y4tTkUbejv6iN5jXcadXSSTPQ3omhMUevfqU="; </del> <ins> hash = "sha256-6Wt2sC7vdrz2Fkl08bNLfnGu+pAV7b5lZUmsx1wtJRE="; </ins> }; prePatch = ''

Related discussion:
text: Package name: cardinal Latest released version: 23.10 Current version on the unstable channel: 23.09 Current version on the stable/release channel: 22.12 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Code change:
inherit cc shell libc_bin libc_dev libc_lib binutils_bin coreutils_bin; gnugrep_bin = if nativeTools then "" else gnugrep; <ins> binPrefix = prefix; </ins> passthru = { inherit libc nativeTools nativeLibc nativePrefix isGNU isClang default_cxx_stdlib_compile

Related discussion:
text: Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.
Code change:
inherit cc shell libc_bin libc_dev libc_lib binutils_bin coreutils_bin; gnugrep_bin = if nativeTools then "" else gnugrep; <ins> binPrefix = prefix; </ins> passthru = { inherit libc nativeTools nativeLibc nativePrefix isGNU isClang default_cxx_stdlib_compile

Related discussion:
text: gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc
Code change:
${cfg.sleep.extraConfig} ''; <del> "systemd/system-generators" = { source = hooks "generators" cfg.generators; }; "systemd/system-shutdown" = { source = hooks "shutdown" cfg.shutdown; }; </del> <ins> "systemd/user-generators" = { source = hooks "user-generators" cfg.user.generators; }; "systemd/system-generators" = { source = hooks "system-generators" cfg.generators; }; "systemd/system-shutdown" = { source = hooks "system-shutdown" cfg.shutdown; }; </ins> }); services.dbus.enable = true;

Related discussion:
text: Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.
Code change:
buildGoModule rec { pname = "podman-tui"; <del> version = "0.18.0"; </del> <ins> version = "1.0.0"; </ins> src = fetchFromGitHub { owner = "containers"; repo = "podman-tui"; rev = "v${version}"; <del> hash = "sha256-T2hiCRoZqdbcB36Tpy597j7Hc1yeR2MijQbuheENfuA="; </del> <ins> hash = "sha256-sJaiZJeT0oUAnSg9Kv8uMp1XoumumC3LB77lelmwSgw="; </ins> }; vendorHash = null;

Related discussion:
text: 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]:
Code change:
description = ".NET C# and Visual Basic compiler"; homepage = "https://github.com/dotnet/roslyn"; mainProgram = "csc"; <del> platforms = platforms.linux; </del> license = licenses.mit; maintainers = with maintainers; [ corngood ]; };

Related discussion:
text: Steps to reproduce the behavior: msbuild Trying to build msbuild on a mac fails. <!-- 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.