jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib , fetchFromGitLab , python3Packages , wrapGAppsHook4 , gst_all_1 , gobject-introspection , yt-dlp , libadwaita , libsoup_3 , glib-networking }: python3Packages.buildPythonApplication rec { pname = "monophony"; version = "2.3.1"; format = "other"; sourceRoot = "source/source"; src = fetchFromGitLab { owner = "zehkira"; repo = "monophony"; rev = "v${version}"; hash = "sha256-dpRTHsujaIwzgr+qY5LC9xtXz40g3akdpEiHuxiilZM="; }; pythonPath = with python3Packages; [ mpris-server pygobject3 ytmusicapi ]; nativeBuildInputs = [ python3Packages.nuitka gobject-introspection wrapGAppsHook4 ]; buildInputs = [ libadwaita # needed for gstreamer https libsoup_3 glib-networking ] ++ (with gst_all_1; [ gst-plugins-base gst-plugins-good gstreamer ]); installFlags = [ "prefix=$(out)" ]; preFixup = '' buildPythonPath "$pythonPath" gappsWrapperArgs+=( --prefix PYTHONPATH : "$program_PYTHONPATH" --prefix PATH : "${lib.makeBinPath [yt-dlp]}" # needed for gstreamer https --prefix LD_LIBRARY_PATH : "${libsoup_3.out}/lib" ) ''; meta = with lib; { homepage = "https://gitlab.com/zehkira/monophony"; description = "Linux app for streaming music from YouTube"; longDescription = "Monophony is a free and open source Linux app for streaming music from YouTube. It has no ads and does not require an account."; license = licenses.agpl3Plus; mainProgram = "monophony"; platforms = platforms.linux; maintainers = with maintainers; [ quadradical ]; }; } </ins>

Discussion:
Linux app for streaming music from YouTube. <!-- Monophony is a free and open source Linux app for streaming music from YouTube. It has no ads and does not require an account. --Metadata homepage URL: source URL: license: mit platforms: linux
I'd be interested in doing this if its not too hard, I'll look into it.
The package is almost done, had some complications including unpackaged dependencies, but it should be good to go within the next few days.
Just waiting for a merge now.
Change:
$out/lib/electron/electron  ${lib.optionalString (lib.versionAtLeast version "15.0.0") "$out/lib/electron/chrome_crashpad_handler" } <del> wrapProgram $out/lib/electron/electron  --prefix LD_PRELOAD : ${lib.makeLibraryPath [ libXScrnSaver ]}/libXss.so.1  "''${gappsWrapperArgs[@]}" </del> <ins> wrapProgram $out/lib/electron/electron "''${gappsWrapperArgs[@]}" </ins> ''; };

Discussion:
Obsidian is unable to run (non-nixpkgs) git commands, due to being prefixed with . Steps to reproduce the behavior: non-nixpkgs from nixpkgs in obsidian the command Git syncing properly <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Why don't you use git from nixpkgs (e.g. )?
That does work, although I'd prefer not to install git with on manjaro. I have other workaround that i use, i simply wanted to report how seem to break subcommands.
Just updated, and this also affects electron 16
We could consider prepending to in the derivation (the start script in the output).
can you guesstimate how many percent of obsidian users have obsidian-git plugin installed?
Of all obsidian users: few. Of obsidian&cap;nixpkgs users: maybe 20%?
Possibly related:
can you please check whether the fix in fixes this issue for you?
Seems to work!

I am currently working on electron support for dream2nix and have a question for the electron maintainers of nixpkgs. What is the reason that LDPRELOAD is used here? This leads to errors on my system (NixOS): The cause seems to be that my current systems glibc is 2.32 but I built the electron app with 2.33. Some part of the electron app defaults to using my systems glibc. If I try to fix that by addind glibc 2.33 via , another error occurs: If I instead just remove the from the wrapper, it everything works flawlessly. Therefore my question: Do we really need that LDPRELOAD in the wrapper? If yes, is there an alternative solution possible, like putting into instead. I tried that and this doesn't break stuff. I have seen the mentioned problem with multiple electron apps, so it is not a problem of a specific app. <!-- 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. Maintainer information:
can you please check whether the fix in fixes this issue for you?
Change:
# see https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; <del> preCheck = "export HOME=$PWD"; </del> meta = with lib; { homepage = "https://lutris.net"; description = "Open Source gaming platform for GNU/Linux";

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- 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! --- name: lutris-unwrapped <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.5.8.4 desired version: 0.5.9 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
cp -R FreeFileSync/Build/* $out mv $out/{Bin,bin} <ins> mkdir -p $out/share/pixmaps unzip -j $out/Resources/Icons.zip '*Sync.png' -d $out/share/pixmaps </ins> runHook postInstall ''; <ins> desktopItems = [ (makeDesktopItem rec { name = "FreeFileSync"; desktopName = name; genericName = "Folder Comparison and Synchronization"; icon = name; exec = name; categories = [ "Utility" "FileTools" ]; }) (makeDesktopItem rec { name = "RealTimeSync"; desktopName = name; genericName = "Automated Synchronization"; icon = name; exec = name; categories = [ "Utility" "FileTools" ]; }) ]; </ins> passthru.updateScript = gitUpdater { rev-prefix = "v"; };

Discussion:
For FreeFileSync, add a desktop file to $out/share/applications so that the application can be found in an app launcher. <!-- 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.
Change:
libhandy libsoup libunity <del> switchboard </del> <ins> switchboard-with-plugs </ins> wingpanel zeitgeist <del> ]; </del> <ins> ] ++ # applications-menu has a plugin to search switchboard plugins # see https://github.com/NixOS/nixpkgs/issues/100209 # wingpanel's wrapper will need to pick up the fact that # applications-menu needs a version of switchboard with all # its plugins for search. switchboard-with-plugs.buildInputs; </ins> mesonFlags = [ "--sysconfdir=${placeholder "out"}/etc"

Discussion:
Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
owner = "ofiwg"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-tXfAn8hkasA2UuA4/8dOE3EcORyJo/A33TtSNdzDXD8="; </del> <ins> sha256 = "sha256-uL3L9k9yqdZXQmR1zi8OEIGLAZ8cf7EBnlDhetaMA08="; </ins> }; nativeBuildInputs = [ pkg-config autoreconfHook ]; <del> buildInputs = lib.optionals enableOpx [ libuuid numactl ] ++ lib.optional enablePsm2 [ libpsm2 ]; </del> <ins> buildInputs = lib.optional enablePsm2 libpsm2; </ins> <del> configureFlags = [ (if enablePsm2 then "--enable-psm2=${libpsm2}" else "--disable-psm2") (if enableOpx then "--enable-opx" else "--disable-opx") ]; </del> <ins> configureFlags = [ (if enablePsm2 then "--enable-psm2=${libpsm2}" else "--disable-psm2") ]; </ins> meta = with lib; { homepage = "https://ofiwg.github.io/libfabric/";

Discussion:
fails the build, because running the tests terminates with a segfault on unstable. Complete build log: Build succeeds. N/A N/A <!-- 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. system: host os: multi-user?: sandbox: version: channels(henri): nixpkgs:
Bisected to
I just tried : it does not segfault, but it causes the test to hang.
It seems that there are at least two problems: the segfault in the test and the hanging test. I suggest reverting the upgrade back to version for now. Maybe has an idea or wants to report the issue upstream?
Well, there's a bunch of ways to start openmpi, with many many options and some combinations may lead to such segfault. I see that before the backtrace, there's an UCX error about the tcp interface not found. Then, the OFI BTL seems to be used. But OFI (open fabric interface) is meant to be used on computing nodes hosting a specific network interface. I suggest trying to force the mpi4py test to use the "VADER" or "SELF" interface: or You may also try or
That is true, but I think the default should just work and not segfault. You can make the tests in mpi4py pass by setting in its test phase, but I don't think this is a good solution. Rather should the auto-detect mechanism just work without crashing. EDIT: this could be an acceptable solution if the failure is specific to the builder's sandbox, but does not appear if used outside the sandbox.
Maybe let's start with adding to the test phase to get the ball rolling and improve further at a later time if necessary.
Isn't that just masking the problem? It then may just break at run time, which is could be super annoying for someone who does not know why this happens.
I see the libfabric update was just reverted although I wonder whether this will work out in the long run. An update will be necessary sooner or later.
I agree, that we should update libfabric at some point, but at least we have everything in a well working state right now. IMHO that should have higher priority than updating at any cost.

I would expect that we can either find a proper solution to fix the problem or that, ideally, libfabric is fixed upstream. Is someone willing to report this issue upstream?
I reported it here
Change:
{ lib , buildPythonPackage , fetchPypi <del> , simplejson </del> , pytestCheckHook , pythonOlder <ins> , setuptools </ins> }: buildPythonPackage rec { pname = "uritemplate"; version = "4.1.1"; <del> format = "setuptools"; </del> <ins> pyproject = true; </ins> disabled = pythonOlder "3.6";

Discussion:
A clear and concise description of what the bug is. The uritemplate python module install simplejson, but the lib doesn't depend on it. Looking for the history, in the past it had this dependency in v0.6, but it is almost 10 years old now. A clear and concise description of what you expected to happen. Do not install simplejson, it is an old compatibility layer and it slightly change behavior of some libs, like . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
stdenv.mkDerivation rec { pname = "gnunet"; <del> version = "0.20.0"; </del> <ins> version = "0.21.1"; </ins> src = fetchurl { <del> url = "mirror://gnu/gnunet/${pname}-${version}.tar.gz"; sha256 = "sha256-VgKeeKmcBNUrE1gJSuUHTkzY6puYz2hV9XrZryeslRg="; </del> <ins> url = "mirror://gnu/gnunet/gnunet-${version}.tar.gz"; hash = "sha256-k+aLPqynCHJz49doX+auOLLoBV5MnnANNg3UBVJJeFw="; </ins> }; enableParallelBuilding = true;

Discussion:
Package name: gnunet Latest released version: 0.21.0 Current version on the unstable channel: 0.20.0 Current version on the stable/release channel: 0.20.0 Notify maintainers Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
''; nativeBuildInputs = [ autoreconfHook ]; <del> buildInputs = [ fuse unrar ]; </del> <ins> buildInputs = [ fuse unrar_6 ]; </ins> configureFlags = [ <del> "--with-unrar=${unrar.src}/unrar" </del> <ins> "--with-unrar=${unrar_6.src}/unrar" </ins> "--disable-static-unrar" ];

Discussion:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.
Change:
url = mkURL "fa1349f1" "0002-gfxboot-menu-label.patch"; sha256 = "06ifgzbpjj4picpj17zgprsfi501zf4pp85qjjgn29i5rs291zni"; }) <del> (fetchurl { url = mkURL "477e56d2" "0005-gnu-efi-version-compatibility.patch"; sha256 = "041568b4abb79wynyps1n04lg4fr26rc3sbjncz99pp0mbz0ajlm"; </del> <ins> (fetchpatch { url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/0005-gnu-efi-version-compatibility.patch?h=packages/syslinux"; sha256 = "0fbqz56hj8az8ws26m39hyp3l5fvcbzvzdddqz3x6n56hzdpz1p6"; </ins> }) (fetchurl { # mbr.bin: too big (452 > 440)

Discussion:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.
Change:
# cfg.configFile contains secrets such as proxy servers' credential! # we dont want plaintext secrets in world-readable `/nix/store`. <del> { lib , config , pkgs , ... </del> <ins> { lib, config, pkgs, ... </ins> }: let cfg = config.services.mihomo;

Discussion:
A clear and concise description of what the bug is. raise Steps to reproduce the behavior: add ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. 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]:
Change:
<ins> # This file has been generated by node2nix 1.11.1. Do not edit! {pkgs ? import <nixpkgs> { inherit system; }, system ? builtins.currentSystem, nodejs ? pkgs."nodejs-16_x"}: let nodeEnv = import ../../../development/node-packages/node-env.nix { inherit (pkgs) stdenv lib python2 runCommand writeTextFile writeShellScript; inherit pkgs nodejs; libtool = if pkgs.stdenv.isDarwin then pkgs.darwin.cctools else null; }; in import ./node-packages.nix { inherit (pkgs) fetchurl nix-gitignore stdenv lib fetchgit; inherit nodeEnv; } </ins>

Discussion:
Project description Libre and modular OSC / MIDI controller Metadata homepage URL: source URL: license: GPLv3 platforms: electron
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still would be cool.
I marked this as stale due to inactivity. &rarr;
still relevant
I marked this as stale due to inactivity. &rarr;
Still relevant
I've opened a PR to add this package! See
Change:
<ins> diff --git a/Makefile.in b/Makefile.in index 877c54f..3e39ed1 100644 --- a/Makefile.in +++ b/Makefile.in @@ -209,6 +209,8 @@ $(NSS_VERSION).tar.gz: $(nss_static_libs): $(NSS_VERSION).tar.gz tar xf $(NSS_VERSION).tar.gz +	sed -i -e "1s@#!/usr/bin/env bash@#!$$(type -p bash)@" $(NSS_VERSION)/nss/build.sh +	sed -i -e "s@/usr/bin/env grep@$$(type -p grep)@" $(NSS_VERSION)/nss/coreconf/config.gypi ifeq ($(host),$(build)) # Native build, use NSS' build script. </ins>

Discussion:
Project description is like curl, but doesn't get you blocked by cloudflare and other WAPs that insist you have the TLS fingerprint of a web browser. Metadata homepage URL: source URL: license: MIT platforms: linux
the build process produces a separate 'Chrome' and 'Firefox' impersonation binary
I started packaging the firefox variant of curl-impersonate in , but it has unresolved issues, including: missing the curl-impersonate wrapper scripts; PATH conflicts with ; disabled tests; missing shell completions; possible issues with getting an HTTP response from some sites including But it does sort of work and may be useful as a starting point. (Note that I have not checked the TLS fingerprint.)
I've opened which should add a fully working build from source of curl-impersonate (with both firefox and chrome variants)
Change:
plasma-browser-integration konsole oxygen <ins> (lib.getBin qttools) # Expose qdbus in PATH </ins> ]; in requiredPackages

Discussion:
, an application that simulates user input to keep the screen awake when pressing gamepad buttons, relies on on Plasma Wayland to do this. However, isn't installed (or at least, it's not in ) with a default Plasma installation, making not work: (Among other errors) Steps to reproduce the behavior: Plasma (), without "installing" ; a Plasma Wayland session; ; 'll see the error message, and the program won't work. There is no error message and the program works (which is what happens by installing ). I don't know if the best solution is to add to Plasma or to . I'd vote for the former, since (if I'm not wrong), is already installed with Plasma, it's just not in PATH, and I don't see the harm in being there. Still, that's why I opened an issue. By the way, can't be installed "alone". NixOS says: <!-- 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.

KDE Plasma supports the power profiles feature , but , enabling doesn't activate the feature by default. Steps to reproduce the behavior: Plasma; on the battery icon; are no power profiles. You should see the power profiles.
Change:
{ stdenv, buildEnv, fetchurl, mono }: let <del> version = "1.8.0"; </del> <ins> version = "1.14.0"; </ins> drv = stdenv.mkDerivation { pname = "keepassrpc"; inherit version; src = fetchurl { url    = "https://github.com/kee-org/keepassrpc/releases/download/v${version}/KeePassRPC.plgx"; <del> sha256 = "1dclfpia559cqf78qw29zz235h1df5md4kgjv3bbi8y41wwmx7cd"; </del> <ins> sha256 = "1c410cc93c0252e7cfdb02507b8172c13e18d12c97f08630b721d897dc9b8b24"; </ins> }; meta = with stdenv.lib; {

Discussion:
, CVSSv3=9.1 (nixos-20.03, nixos-unstable) CVSSv3=9.1 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: .
NixOS 20.03 is EOL, so this issue isn't actionable anymore (but fixed in unstable and 20.09).
Change:
postStart = postStartScript dummyConfig; <del> preStop = '' pid="$(cat /run/containers/$INSTANCE.pid)" if [ -n "$pid" ]; then kill -RTMIN+4 "$pid" fi rm -f "/run/containers/$INSTANCE.pid" ''; </del> <ins> preStop = "machinectl poweroff $INSTANCE"; </ins> restartIfChanged = false;

Discussion:
Hi, I'm using declarative NixOS containers, and everytime I reboot, systemd waits 1min 30s with the following message: However if I run , it's instantaneous. I'm using the channel. Here's the minimal configuration to reproduce:
Yeah, I've noticed this as well...
Change:
inherit (config.system.nixos-generate-config) configuration; }; <del> nixos-option = makeProg { name = "nixos-option"; src = ./nixos-option.sh; }; </del> <ins> nixos-option = pkgs.callPackage ./nixos-option { }; </ins> nixos-version = makeProg { name = "nixos-version";

Discussion:
We can currently display a NixOS module option type using, for example: . It seems to me that, to maximize usability, should display this string. Also, the should display this information. Perhaps it should be toggleable, though, since options involving submodule types could be quite large. EDIT: Apparently the field is currently for any submodule type. It would be nice to either pretty-print the whole type or output some kind of structured data there. Run . There is no indication of the type of this option other than the default/example values. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc
This was fixed in .
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .