jiebi/CodeConvo huggingface dataset:
Code change:
dontWrapQtApps = true; <ins> postInstall = '' ln -s ${vgmstream.override { buildAudaciousPlugin = true; }}/lib/audacious/Input/* $out/lib/audacious/Input ''; </ins> meta = audacious.meta // { description = "Plugins for Audacious music player"; };

Related discussion:
text: The audacious package imports audacious-plugins to build most of the common plugins and then link them into the audacious lib path. However, this makes it hard to add more audacious plugins, like vgmstream. The vgmstream package currently has its , because importing the audacious package causes an infinite recursion error. Steps to reproduce the behavior: vgmstream to audacious-plugins buildInputs audacious to vgmstream's buildInputs and comment out the disable configure flag -shell -p audacious-plugins I expected that adding vgmstream to audacious-plugins would enable the plugin. Instead, the build crashes with an infinite recursion. How is it currently working for audacious to import audacious-plugins and audacious-plugins to import audacious? Can this same magic be extended to other plugins? This about how fcitx is packaged shows that fcitx-addons imports fcitx with no reverse import, should the audacious package be refactored to be similar? Should the audacious package gain an extra parameter to take extra plugin derivations, which can be created outside of the audacious-plugins derivation? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Instead of adding , did you try to add instead? is without as input, and it is used to break the loop.
Thank you for the quick response! That would be elegant, but I don't see any result in my grep of nixpkgs or in the .
Sorry, it is here: Basically you need to do and this should do the trick. Considering that we are going to use this in more than one place it probably makes sense to introduce it as a , but the result is the same regardless.
Oh that's a neat trick! I'll try that approach out next. Thank you so much! I tried out the extra-plugins approach here, seems to work but is not ergonomic:
I , and it's a lot easier to use as a user! If it looks good as an approach, please provide some review feedback and I'll squash it down for a PR :)
Shall I send a PR for a final review?
Code change:
default = true; description = "Enable the XFWM (default) window manager."; }; <ins> screenLock = mkOption { type = types.enum [ "xscreensaver" "xlockmore" "slock" ]; default = "xlockmore"; description = "Application used by XFCE to lock the screen."; }; </ins> }; };

Related discussion:
text: It's not possible to lock screen in xfce unless "xlockmore" is installed. in in XFCE and try to lock without success and then retry to lock System: NixOS Emu Nix version: 1.11.2 Nixpkgs version: "16.03.973."
I think that's because there is no blessed lock screen for XFCE. tries XScreenSaver, GNOME Screensaver, XLock and SLock -- in that order.
Has a situation like this (multiple optional but at least one required dependency on an executable) already been handled in NixOS?
I think this is generally resolved by some kind of switch, but we have to add one. Something like of ...
I kept as-is: see
I think the issue may be resolved. At least with (as of 2023-09-17) lock screen is possible without having installed.
Code change:
stdenv.mkDerivation (finalAttrs: { pname = "juce"; <del> version = "7.0.9"; </del> <ins> version = "7.0.10"; </ins> src = fetchFromGitHub { owner = "juce-framework"; repo = "juce"; rev = finalAttrs.version; <del> hash = "sha256-k8cNTPH9OgOav4dsSLqrd5PlJ1rqO0PLt6Lwmumc2Gg="; </del> <ins> hash = "sha256-CAHhHPTUvIyDOh2CdvNmw26HfoWWtbqRRiR+3Ky4GYA="; </ins> }; patches = [

Related discussion:
text: Package name: juce Latest released version: 7.0.10 Current version on the unstable channel: 7.0.9 Current version on the stable/release channel: 7.0.7 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<ins> { config, pkgs, lib, ... }: with lib; let pkg = [ pkgs.switcheroo-control ]; cfg = config.services.switcherooControl; in { options.services.switcherooControl = { enable = mkEnableOption "switcheroo-control, a D-Bus service to check the availability of dual-GPU"; }; config = mkIf cfg.enable { services.dbus.packages = pkg; environment.systemPackages = pkg; systemd.packages = pkg; systemd.targets.multi-user.wants = [ "switcheroo-control.service" ]; }; } </ins>

Related discussion:
text: Project description A dbus api to start programs on a different GPU Metadata homepage URL: source license: gpl3 platforms: linux
Duplicate
Code change:
typing-extensions ]; <del> pytestFlagsArray = [ # Pass -c /dev/null so that pytest does not use the bundled pytest.ini, which adds # options to run additional integration tests that are overkill for our purposes. "-c" "/dev/null" ]; </del> <ins> # Remove the bundled pytest.ini, which adds options to run additional integration # tests that are overkill for our purposes. preCheck = '' rm pytest.ini ''; </ins> pythonImportsCheck = [ "bidict" ];

Related discussion:
text: Steps to reproduce the behavior: hydra build: build logs: Add any other context about the problem here. <!-- 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]:
Not sure why this suddenly started failing after it worked fine for the last 11 days. Reproduced this and submitted a patch in that fixed it for me locally.
Thanks, I can confirm that the patch does work.
In my observation, it only breaks on , the works just fine. That's extremely weird.
I logged the test phase on the latest commit and the one before that, here’s what’s changed: Looks like it is to do with the
Nice work, It looks like is the commit that upgraded to pytest 8, but that was two weeks ago. So I'm not sure how this passed for 4 days ago.
The build that passed 4 days ago used as and the also wasn’t pointing to , here’s a snippet from the logs: The log file: But the latest build which failed, had set to and set to .
Code change:
"pillow" "httpx" "packaging" <ins> "typer" </ins> ]; propagatedBuildInputs = with python3Packages; [

Related discussion:
text: Steps to reproduce the behavior: oterm 0.2.7 unstable (I'm doing via home-manager on rev ) Fails finding a typer version Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I will check on my NixOS host later in the day to see if I can replicate.
There's a quick way to fix it:
Also, a PR in upstream:
Code change:
hash = "sha256-bHEBzl0aBXsHOhSWJUz428pG5M6L0s/Q6acKO+2oMXo="; }; <ins> patches = [ (substituteAll { src = ./fix-paths.patch; zenity = gnome.zenity; }) # compositor: Fix crash when restarting Cinnamon # https://github.com/linuxmint/muffin/pull/655 (fetchpatch { url = "https://github.com/linuxmint/muffin/commit/1a941ec603a1565dbd2f943f7da6e877d1541bcb.patch"; sha256 = "sha256-6x64rWQ20ZjM9z79Pg6QMDPeFN5VNdDHBueRvy2kA6c="; }) ]; </ins> nativeBuildInputs = [ desktop-file-utils mesa # needed for gbm

Related discussion:
text: Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...
Code change:
}; # grab the plugin sdk for the desktop icon <del> pluginsdk = fetchurl { url = "http://dl.4players.de/ts/client/pluginsdk/pluginsdk_3.1.1.1.zip"; sha256 = "1bywmdj54glzd0kffvr27r84n4dsd0pskkbmh59mllbxvj0qwy7f"; </del> <ins> pluginsdk = fetchzip { url = "https://files.teamspeak-services.com/releases/sdk/3.3.1/ts_sdk_3.3.1.zip"; hash = "sha256-wx4pBZHpFPoNvEe4xYE80KnXGVda9XcX35ho4R8QxrQ="; </ins> }; nativeBuildInputs = [ makeWrapper which <del> unzip </del> perl # Installer script needs `shasum` ];

Related discussion:
text: Steps to reproduce the behavior: try to install/build the package using nix-shell or nixos the Domain is no longer configured. Teamspeak Download Pages redirects to this place: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You might want to check out
Not merged yet
As a workaround, until this is fixed in nixpkgs: The file is still available at the Internet Archive. You can fetch it from there and write it into the store, with something like this:
Code change:
}; }; in <del> python.pkgs.buildPythonApplication { </del> <ins> python.pkgs.buildPythonApplication rec { </ins> pname = "immich-machine-learning"; inherit (immich) version; src = "${immich.src}/machine-learning";

Related discussion:
text: Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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]:
After bisecting, first bad commit is (
Code change:
daphne = callPackage ../development/python-modules/daphne { }; <ins> daqp = callPackage ../development/python-modules/daqp { }; </ins> dasbus = callPackage ../development/python-modules/dasbus { }; dash = callPackage ../development/python-modules/dash { };

Related discussion:
text: Project description qpsolvers is python library for solving quadratic programming problems. It contains wrappers for multiple solvers like osqp, cvxopt, quadprog and much more. Metadata homepage URL: source URL: license: LGPLv3 platforms: platform independent (python3.10)
This package wants new version of and new package - . I will try add PR today, but now you can use my NUR repo if you want:
Code change:
appimageContents = appimageTools.extractType2 { inherit name src; }; <del> in appimageTools.wrapType2 rec { </del> <ins> # Hotplug events from udevd are fired into the kernel, which then re-broadcasts them over a # special socket, to every libudev client listening for hotplug when the kernel does that. It will # try to preserve the uid of the sender but a non-root namespace (like the fhs-env) cant map root # to a uid, for security reasons, so the uid of the sender becomes nobody and libudev actively # rejects such messages. This patch disables that bit of security in libudev. # See: https://github.com/NixOS/nixpkgs/issues/116361 systemdPatched = systemd.overrideAttrs ({ patches ? [ ], ... }: { patches = patches ++ [ ./systemd.patch ]; }); in appimageTools.wrapType2 rec { </ins> inherit name src; <ins> extraPkgs = pkgs: [ systemdPatched ]; </ins> extraInstallCommands = '' mv $out/bin/${name} $out/bin/${pname} install -m 444 -D ${appimageContents}/ledger-live-desktop.desktop $out/share/applications/ledger-live-desktop.desktop

Related discussion:
text: Describe the bug From IRC: ; Looks like we currently just use their appimage: and our appimage tooling uses buildUserFHSEnv: It seems like we can either: using (build from source, maybe?) similar to how iohk patches Daedalus.
I tried packaging it with yarn2nix, but stumbled upon , unfortunately.
I don't know much about the appimage architecture. Why exactly can we not run appimages natively without FhsUserEnv? Is it just because binaries linking against fhs paths? In this case we probably could run autoPatchelfHook on the contents of the appimage and produce a new image that links against nix libs. EDIT: I just tried this. Extracted the appimage contents, patched all binaries, but then when executing ledger-live-desktop, I'm getting: Currently I'm running ledger live via qemu + usb device passthru via . That works fine.
how difficult would it be to lift Daedalus's patch and use it for the libudev inside the fhs? I've never worked with FHS before, but also don't want to build ledger live from source...
I tried to build ledger live from source and it didn't work because of the issue that mentioned. Patching libudev worked though.
can you link to the patch? It would be great to be able to use my more-trusted nixos machines for these types of activities.
I already created a PR for it and it's referenced above. This one:
Feel free to comment in the PR whether it actually works for you :)
The patch had to be re-done in Should this problem probably be communicated to upstream, so we can think about how to fix this long-term in a more sustainable fashion?
Code change:
# cross-compiling. ./always-search-rpath.patch <del> ] ++ lib.optionals (!stdenv.targetPlatform.isVc4) [ # https://sourceware.org/bugzilla/show_bug.cgi?id=22868 ./gold-symbol-visibility.patch # https://sourceware.org/bugzilla/show_bug.cgi?id=23428 # un-break features so linking against musl doesn't produce crash-only binaries ./0001-x86-Add-a-GNU_PROPERTY_X86_ISA_1_USED-note-if-needed.patch ./0001-x86-Properly-merge-GNU_PROPERTY_X86_ISA_1_USED.patch ./0001-x86-Properly-add-X86_ISA_1_NEEDED-property.patch </del> ] ++ lib.optional stdenv.targetPlatform.isiOS ./support-ios.patch; outputs = [ "out" "info" "man" ];

Related discussion:
text: Describe the bug is currently in nixpkgs master. It was released in July 2018. was released in October 2019. It contains a few improvements and may also contains fix for some vulnerabilities: Is there a reason to keep the old version in nixpkgs, other than a lack of manpower? I'd be happy to do this work, but I just want to be sure that I was not starting a long, difficult and redundant work. I already tried a "naive" bump of the and but it does not work, mostly because most of the patchs are not valid anymore.
This was solved by cc.
Thank you for continuing this work!
Code change:
# code here, we'll cause an infinite recursion. Since a set with # clang as its default compiler always means libc++, we can infer this # decision statically. <del> then buildPackages.llvmPackages.libcxxClang </del> <ins> then buildPackages.pkgsBuildTarget.llvmPackages.libcxxClang </ins> else buildPackages.gcc else # This will blow up if anything uses it, but that's OK. The `if

Related discussion:
text: Steps to reproduce the behavior: something which uses (easily ) Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --No maintainers, blame says last made a modification. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
No maintainers, blame says last made a modification. Hm, I can’t recall changing anything remotely related to LLVM and/or wrapper stuff recently. Which file(s) are you referring to?
Code change:
- The `hardware.pulseaudio` module now sets permission of pulse user home directory to 755 when running in "systemWide" mode. It fixes [issue 114399](https://github.com/NixOS/nixpkgs/issues/114399). <ins> - The `services.networkmanager.extraConfig` was renamed to `services.networkmanager.settings` and was changed to use the ini type instead of using a multiline string. </ins> - The module `services.github-runner` has been removed. To configure a single GitHub Actions Runner refer to `services.github-runners.*`. Note that this will trigger a new runner registration. - The `services.slskd` has been refactored to include more configuation options in

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
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 .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions
Code change:
<ins> diff --git a/src/builder-context.c b/src/builder-context.c index dde12790..3a379297 100644 </ins> --- a/src/builder-context.c +++ b/src/builder-context.c <ins> @@ -256,7 +256,7 @@ builder_context_init (BuilderContext *self) g_autofree char *path = NULL; self->rofiles_file_lock = init; -  path = g_find_program_in_path ("rofiles-fuse"); +  path = g_find_program_in_path ("@rofilesfuse@"); self->have_rofiles = path != NULL; } </ins> @@ -800,7 +800,7 @@ builder_context_enable_rofiles (BuilderContext *self, g_autoptr(GFile) rofiles_base = NULL; g_autoptr(GFile) rofiles_dir = NULL;

Related discussion:
text: Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
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 .
should fix that issue.
Code change:
<ins> --- a/Build.PL +++ b/Build.PL @@ -88,7 +88,7 @@ if ( $^O =~ /mswin32/i ) { } } else { -    if ( $Config{archname} =~ /^x86_64|^ppc64|^s390x|^aarch64|^riscv64/ ) { +    if ( 0 ) { $libdir =~ s/bbinb/lib64/; if ( !-d $libdir ) { my $test = $libdir; </ins>

Related discussion:
text: Steps to reproduce the behavior: Confirmed locally against recent master () system: host os: multi-user?: sandbox: version: nixpkgs:
There's already a PR fixing this build failure:
looks like this is being addressed in
Can confirm, fixes build-issues on unstable :)
Fix has been merged. Feel free to reopen if the issue persists after the next channel bump
Code change:
<ins> diff --git a/thirdparty/CMakeLists.txt b/thirdparty/CMakeLists.txt index f33b3bf3f..1214f179c 100644 --- a/thirdparty/CMakeLists.txt +++ b/thirdparty/CMakeLists.txt @@ -16,6 +16,5 @@ if(NOT "${SRB2_CONFIG_SYSTEM_LIBRARIES}") include("cpm-png.cmake") include("cpm-curl.cmake") include("cpm-openmpt.cmake") +	include("cpm-libgme.cmake") endif() - -include("cpm-libgme.cmake") </ins>

Related discussion:
text: use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1:
Code change:
url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/qtbug-77037-workaround.patch?h=packages/qt5-webengine&id=fc77d6b3d5ec74e421b58f199efceb2593cbf951"; sha256 = "1gv733qfdn9746nbqqxzyjx4ijjqkkb7zb71nxax49nna5bri3am"; }) <ins> # Fix build with bison-3.7: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?id=1a53f599 (fetchpatch { name = "qtwebengine-bison-3.7-build.patch"; url = "https://code.qt.io/cgit/qt/qtwebengine-chromium.git/patch/?id=1a53f599"; sha256 = "1nqpyn5fq37q7i9nasag6i14lnz0d7sld5ikqhlm8qwq9d7gbmjy"; stripLen = 1; extraPrefix = "src/3rdparty/"; }) </ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-darwin-fix-failed-static-assertion.patch

Related discussion:
text: Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.
Code change:
springLobby = callPackage ../games/spring/springlobby.nix { }; <del> srb2 = callPackage ../games/srb2 { }; </del> ssl-cert-check = callPackage ../tools/admin/ssl-cert-check { }; stardust = callPackage ../games/stardust { };

Related discussion:
text: use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1: