jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { lib, rustPlatform, yabridge }: rustPlatform.buildRustPackage rec { pname = "yabridgectl"; version = yabridge.version; src = yabridge.src; sourceRoot = "source/tools/yabridgectl"; cargoSha256 = "1sjhani8h7ap42yqlnj05sx59jyz2h12qlm1ibv8ldxcpwps0bwy"; patches = [ ./libyabridge-from-nix-profiles.patch ]; patchFlags = [ "-p3" ]; meta = with lib; { description = "A small, optional utility to help set up and update yabridge for several directories at once"; homepage = "https://github.com/robbert-vdh/yabridge/tree/master/tools/yabridgectl"; license = licenses.gpl3Plus; maintainers = with maintainers; [ metadark ]; }; } </ins>

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:
<ins> { lib, rustPlatform, yabridge }: rustPlatform.buildRustPackage rec { pname = "yabridgectl"; version = yabridge.version; src = yabridge.src; sourceRoot = "source/tools/yabridgectl"; cargoSha256 = "1sjhani8h7ap42yqlnj05sx59jyz2h12qlm1ibv8ldxcpwps0bwy"; patches = [ ./libyabridge-from-nix-profiles.patch ]; patchFlags = [ "-p3" ]; meta = with lib; { description = "A small, optional utility to help set up and update yabridge for several directories at once"; homepage = "https://github.com/robbert-vdh/yabridge/tree/master/tools/yabridgectl"; license = licenses.gpl3Plus; maintainers = with maintainers; [ metadark ]; }; } </ins>

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:
<ins> #!/bin/sh -e xsltproc generate-sources.xsl repository-11.xml > sources.nix </ins>

Related discussion:
text: 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 .
Code change:
sha256 = "1044rj3wbfmgaif2jb0k28m2aczli6ai2n5yvn6pr7zjyw16kvd2"; }; buildInputs = [ pkgs.gtk2 Cairo ExtUtilsDepends ExtUtilsPkgConfig Glib Pango ]; <del> doCheck = !stdenv.isDarwin; </del> <ins> # https://rt.cpan.org/Public/Bug/Display.html?id=130742 # doCheck = !stdenv.isDarwin; doCheck = false; </ins> meta = { homepage = http://gtk2-perl.sourceforge.net/; description = "Perl interface to the 2.x series of the Gimp Toolkit library";

Related discussion:
text: 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 .
Code change:
patches = [ ./fix-application-path.patch ]; postPatch = '' <ins> # https://github.com/NixOS/nixpkgs/issues/119766 substituteInPlace lxqtbacklight/linux_backend/driver/libbacklight_backend.c  --replace "pkexec lxqt-backlight_backend" "pkexec $out/bin/lxqt-backlight_backend" </ins> sed -i "s|''${POLKITQT-1_POLICY_FILES_INSTALL_DIR}|''${out}/share/polkit-1/actions|" CMakeLists.txt '';

Related discussion:
text: 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 .
Code change:
patches = [ ./fix-application-path.patch ]; postPatch = '' <ins> # https://github.com/NixOS/nixpkgs/issues/119766 substituteInPlace lxqtbacklight/linux_backend/driver/libbacklight_backend.c  --replace "pkexec lxqt-backlight_backend" "pkexec $out/bin/lxqt-backlight_backend" </ins> sed -i "s|''${POLKITQT-1_POLICY_FILES_INSTALL_DIR}|''${out}/share/polkit-1/actions|" CMakeLists.txt '';

Related discussion:
text: Notify maintainers Hi there thanks for providing an update to 0.17 so quickly! Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(khumba): nixpkgs: Maintainer information:
Code change:
stdenv = gcc7Stdenv; })); <del> llvmPackages_latest = llvmPackages_11; </del> <ins> llvmPackages_latest = llvmPackages_12; </ins> llvmPackages_rocm = recurseIntoAttrs (callPackage ../development/compilers/llvm/rocm { });

Related discussion:
text: 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
Code change:
cpp-ipfs-api = callPackage ../development/libraries/cpp-ipfs-api { }; <del> cpp-netlib = callPackage ../development/libraries/cpp-netlib { openssl = openssl_1_0_2; }; </del> <ins> cpp-netlib = callPackage ../development/libraries/cpp-netlib {}; </ins> uri = callPackage ../development/libraries/uri { }; cppcms = callPackage ../development/libraries/cppcms { };

Related discussion:
text: 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:
Code change:
]; buildInputs = <del> [ cairo gdk-pixbuf gobject-introspection libsoup pango webkitgtk ]; </del> <ins> [ cairo gdk-pixbuf gobject-introspection libsoup openssl pango webkitgtk ]; env = { OPENSSL_NO_VENDOR = 1; }; </ins> postPatch = '' substituteInPlace ./tauri.conf.json  <del> --replace '"distDir": "../dist",' '"distDir": "${finalAttrs.ui}",'  --replace '"beforeBuildCommand": "pnpm build",' '"beforeBuildCommand": "",' </del> <ins> --replace-fail '"distDir": "../dist",' '"distDir": "${finalAttrs.ui}",'  --replace-fail '"beforeBuildCommand": "pnpm build",' '"beforeBuildCommand": "",' </ins> ''; postBuild = ''

Related discussion:
text: 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.
Code change:
, autoPatchelfHook , makeWrapper , buildNpmPackage <ins> , nixosTests </ins> , cmake , avahi , libevdev

Related discussion:
text: 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.
Code change:
options = { paths = mkOption { <del> type = with types; either path (nonEmptyListOf path); </del> <ins> type = with types; either path (listOf str); </ins> description = "Path(s) to back up."; example = "/home/user"; apply = x: if isList x then x else [ x ];

Related discussion:
text: 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!
Code change:
''; meta = with lib; { <del> description = "Powerful graphical SurrealDB query playground and database explorer for Browser and Desktop"; homepage = "https://surrealist.starlane.studio"; </del> <ins> description = "Surrealist is the ultimate way to visually manage your SurrealDB database"; homepage = "https://surrealdb.com/surrealist"; </ins> license = licenses.mit; mainProgram = "surrealist"; maintainers = with maintainers; [ frankp ]; platforms = platforms.linux; <del> # See comment about wasm32-unknown-unknown in rustc.nix. broken = lib.any (a: lib.hasAttr a stdenv.hostPlatform.gcc) [ "cpu" "float-abi" "fpu" ] || !stdenv.hostPlatform.gcc.thumb or true; </del> }; })

Related discussion:
text: 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.
Code change:
passthru.tests.version = testers.testVersion { package = podman-tui; <del> command = "podman-tui version"; </del> <ins> command = "HOME=$(mktemp -d) podman-tui version"; </ins> version = "v${version}"; };

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:
gnused # sed stdenv.cc # c++ ld etc. stdenv.cc.libc # ldd <del> ]}"  --prefix ${lib.optionalString stdenv.hostPlatform.isDarwin "DY"}LD_LIBRARY_PATH : "${lib.makeLibraryPath [ xrootd ]}" </del> <ins> ]}" </ins> # Patch thisroot.{sh,csh,fish}

Related discussion:
text: 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.
Code change:
owner = "spesmilo"; repo = "electrum"; rev = version; <del> sha256 = "sha256-lXMz0U7zgtCApBCGZcpOHvLcyOeGG0yJE/gr7Gv+yBQ="; </del> <ins> sha256 = "sha256-R5jFxqaKnqQ+WNp4l0u34wMFxlbIsQ+9qDQxiQEu6kM="; </ins> postFetch = '' mv $out ./all

Related discussion:
text: 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
Code change:
user = config.services.nginx.user; group = config.services.nginx.group; }; <del> systemd.targets."acme-finished-example.test" = {}; </del> <ins> systemd.targets."acme-finished-example.test" = { after = [ "acme-example.test.service" ]; wantedBy = [ "acme-example.test.service" ]; }; </ins> systemd.services."acme-example.test" = { <del> wants = [ "acme-finished-example.test.target" ]; before = [ "acme-finished-example.test.target" "nginx.service" ]; </del> <ins> before = [ "nginx.service" ]; </ins> wantedBy = [ "nginx.service" ]; }; services.nginx.virtualHosts."c.example.test" = {

Related discussion:
text: 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