Question: sha256 = "00cq03cy5dyghmibsdsq5sdqv3bzkzhshsng74bpnb5lasxp3ia5"; }; <del> pythonPath = with python3.pkgs; [ </del> <ins> nativeBuildInputs = with python3.pkgs; [ setuptools_scm docutils ]; propagatedBuildInputs = with python3.pkgs; [ </ins> musicbrainzngs mutagen pycdio pygobject3 <del> requests </del> ruamel_yaml <del> setuptools setuptools_scm </del> <ins> discid pillow </ins> ]; buildInputs = [ libsndfile ]; checkInputs = with python3.pkgs; [ twisted <del> ]; patches = [ (substituteAll { src = ./paths.patch; inherit cdparanoia; }) ]; </del> <ins> ] ++ bins; </ins> makeWrapperArgs = [ <del> "--prefix" "PATH" ":" (lib.makeBinPath [ accuraterip-checksum cdrdao util-linux flac sox ]) </del> <ins> "--prefix" "PATH" ":" (lib.makeBinPath bins) </ins> ]; preBuild = '' export SETUPTOOLS_SCM_PRETEND_VERSION="${version}" ''; <del> # some tests require internet access # https://github.com/JoeLametta/whipper/issues/291 doCheck = false; preCheck = '' HOME=$TMPDIR </del> <ins> checkPhase = '' runHook preCheck # disable tests that require internet access # https://github.com/JoeLametta/whipper/issues/291 substituteInPlace whipper/test/test_common_accurip.py  --replace "test_AccurateRipResponse" "dont_test_AccurateRipResponse" HOME=$TMPDIR ${python3.interpreter} -m unittest discover runHook postCheck </ins> ''; meta = with lib; {

Describe the bug throws an error when attempting to generate the musicbrainz disc id: Notify maintainers recently updated the package in listed as maintainer Maintainer information:


Question: <del> { stdenv, lib, fetchFromGitHub, fetchurl, pkg-config, makeWrapper, allegro5, libGL }: </del> <ins> { stdenv, lib, fetchFromGitHub, fetchurl, pkg-config, allegro5, libGL, wrapGAppsHook }: </ins> stdenv.mkDerivation rec { pname = "liberation-circuit"; <del> version = "unstable-2022-01-02"; </del> <ins> version = "1.3-unstable-2022-01-02"; </ins> src = fetchFromGitHub { owner = "linleyh"; <del> repo = pname; </del> <ins> repo = "liberation-circuit"; </ins> rev = "19e3363547793e931fd9419b61ebc2cd8e257714"; <del> sha256 = "zIwjh4CBSmKz7pF7GM5af+VslWho5jHOLsulbW4C8TY="; </del> <ins> hash = "sha256-zIwjh4CBSmKz7pF7GM5af+VslWho5jHOLsulbW4C8TY="; </ins> }; <del> nativeBuildInputs = [ pkg-config makeWrapper ]; </del> <ins> nativeBuildInputs = [ pkg-config wrapGAppsHook ]; </ins> buildInputs = [ allegro5 libGL ]; <ins> dontWrapGApps = true; </ins> installPhase = '' runHook preInstall mkdir -p $out/opt cp -r bin $out/opt/liberation-circuit chmod +x $out/opt/liberation-circuit/launcher.sh <del> makeWrapper $out/opt/liberation-circuit/launcher.sh $out/bin/liberation-circuit </del> install -D linux-packaging/liberation-circuit.desktop $out/share/applications/liberation-circuit.desktop install -D linux-packaging/liberation-circuit.appdata.xml $out/share/metainfo/liberation-circuit.appdata.xml

When trying to load a multi-binary, a GLib error occurs on the terminal, and liberation-circuit crashes. In fact, this appears when interacting with anything using files: Saving a code, loading a code, and saving a multi-binary. This causes the player to have no way to program his processes. Steps to reproduce the behavior: multi-binary A window should appear to select a file This is the error appearing in the terminal : Please run and paste the result.


Question: makeWrapper ${python3Packages.python.interpreter} $out/bin/onedrivegui  --prefix PATH : ${lib.makeBinPath [ onedrive ]}  <del> --prefix PYTHONPATH : ${python3Packages.makePythonPath (propagatedBuildInputs ++ [(placeholder "out")])}  </del> <ins> --prefix PYTHONPATH : ${ python3Packages.makePythonPath (propagatedBuildInputs ++ [ (placeholder "out") ]) }  </ins> --add-flags $out/${python3Packages.python.sitePackages}/OneDriveGUI.py '';

A recent update on unstable broke compatibility between OneDriveGui and OneDrive client. Steps to reproduce the behavior: unstable to current version ( ) a OneDrive profile configured in OneDriveGui OneDriveGui window OneDriveGui correctly recognizing the cli client ! After some investigation on their respective repos, it appears that OneDriveGui 1.0.3 is not compatible with OneDrive 2.5.x, now in rc (and in Nixos unstable) so this is going to stay broken until OneDriveGui releases their 1.1.0 version. There's an open issue on their repository... which points to an alpha release of the new gui... it might be of interest to package that one on unstable. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
FYI , v2.5.0 will GA 16th September 2024 AEST


Question: ] ++ lib.optionals stdenv.targetPlatform.isiOS [ autoreconfHook ]; <del> buildInputs = [ zlib ]; </del> <ins> buildInputs = [ zlib gettext ]; </ins> inherit noSysDirs;

I'm not really sure why this would happen or how to go about dealing with this. Any tips?
(triage) still a problem?
Unsure, I don't use nix on my mac anymore.
This was a coreutil, right? If so, it’s probably fixed by now.
Probably safe to assume so.
I'm actually hitting the same thing right now.


Question: <del> { lib, stdenv, fetchFromGitHub </del> <ins> { lib, stdenv, fetchFromGitHub, fetchpatch </ins> , doxygen, fontconfig, graphviz-nox, libxml2, pkg-config, which , systemd }: <del> let version = "2019-12-08"; in stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "openzwave"; <del> inherit version; </del> <ins> version = "1.6"; </ins> <del> # Use fork by Home Assistant because this package is mainly used for python.pkgs.homeassistant-pyozw. # See https://github.com/OpenZWave/open-zwave/compare/master...home-assistant:hass for the difference. </del> src = fetchFromGitHub { <del> owner = "home-assistant"; </del> <ins> owner = "OpenZWave"; </ins> repo = "open-zwave"; <del> rev = "2cd2137025c529835e4893a7b87c3d56605b2681"; sha256 = "04g8fb4f4ihakvvsmzcnncgfdd2ikmki7s22i9c6layzdwavbwf1"; </del> <ins> rev = "v${version}"; sha256 = "0xgs4mmr0480c269wx9xkk67ikjzxkh8xcssrdx0f5xcl1lyd333"; </ins> }; <ins> patches = [ (fetchpatch { name = "fix-strncat-build-failure.patch"; url = "https://github.com/OpenZWave/open-zwave/commit/601e5fb16232a7984885e67fdddaf5b9c9dd8105.patch"; sha256 = "1n1k5arwk1dyc12xz6xl4n8yw28vghzhv27j65z1nca4zqsxgza1"; }) (fetchpatch { name = "fix-text-uninitialized.patch"; url = "https://github.com/OpenZWave/open-zwave/commit/3b029a467e83bc7f0054e4dbba1e77e6eac7bc7f.patch"; sha256 = "183mrzjh1zx2b2wzkj4jisiw8br7g7bbs167afls4li0fm01d638"; }) ]; outputs = [ "out" "doc" ]; </ins> nativeBuildInputs = [ doxygen fontconfig graphviz-nox libxml2 pkg-config which ]; buildInputs = [ systemd ];

Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
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 .
We should replace the package with an official version and make use the fork.


Question: <del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

Describe the bug Trying to run mutagen results in an error: The mutagen- which is supposed to have binaries for different platforms is missing. To Reproduce mutagen a mutagen session Metadata system: host os: multi-user?: sandbox: version: channels(alex): channels(root): nixpkgs: Maintainer information:
Hey, author of Mutagen here, super excited to see a Nix package for it! I just thought I'd mention that the bundle currently needs to be placed in the same directory as the executable itself. This is something I've been meaning to improve for a while now (by allowing it to be put in a directory), but I haven't had a chance to implement it yet, mostly because it's a little tricky to get right with package managers like Homebrew that symlink binaries into a different target location. I'm not very familiar with Nix, but I'm sure that it would prefer to avoid having this tarball in the directory. So I'm happy to push ahead on trying to support the -based layout if that's helpful here (or perhaps something more general if NixOS prefers a different layout).
cc
A quick update: Mutagen v0.11.2 and later support looking for the bundle in a directory (assuming a Filesystem Hierarchy Standard layout), so a layout of the form: should now work (in addition to the option of installing the bundle directly alongside the executable). This also works in a -style setup where the binary is symlinked into a larger directory.
Thanks! Is the available for direct download?
The bundle ships as part of the official releases (e.g. in the ). It needs to be kept in sync with the version of the binary being installed, but it should work just fine with a binary built locally, so long as the versions are the same (to the patch level). The bundle can also be built locally, but doing so requires running a custom script inside the Mutagen source tree that performs the necessary cross-compilation (this bundle is a collection of cross-compiled binaries that get injected to remote systems to facilitate file synchronization and network forwarding). I'm not sure the best way of handling that in the context of the NixOS packaging system. Perhaps there are some custom hooks available?


Question: <del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

At the moment, this script doesn't have a flag for building just this bundle (it will only be built as part of a full set of release bundles for all platforms), though I suppose such a flag could be . One of the downsides of doing the cross-compilation locally on Linux (or any non-macOS system) is that the C FFI bindings needed for efficient filesystem watching on macOS won't be available, so file synchronization between NixOS systems and macOS systems will suffer. That might not be a huge loss, though. This is why the Homebrew packages just use the official pre-built release bundles as their "source code." It's a bit non-idiomatic, but it saves on local build times and allows for cross-compiled binaries with C FFI support. Of course, I totally understand if that doesn't work with the NixOS package philosophy, in which case just building the bundle locally is probably the best bet.
As a reference point, here's what the Mutagen Homebrew formula looks like:
I agree, setting up the cross-compilation would not be trivial so the nix derivation must download the prebuilt agents binaries from somewhere while still being able to build the agent on the platform it is running on. I see three possibilities: (No changes on the mutagen side). Nix derivation downloads the full mutagen release and extracts . the version number to the and add it to the downloads. The nix derivation would just download it. the individual downloads for the agents similarly to for all the platforms and have the nix derivation create the itself. That way it would be very easy to even parametrize it to only download the agents the user wants and the nix derivation would supply the binary for the platform it is running on.
All three options are reasonable ideas, though I would prefer to avoid (3) since it would significantly increase the number of assets attached to each GitHub release (which is probably already too high). The individual agent binaries for linux/amd64 that you mentioned are sort of a special case for some experimental container integration features, so I'd prefer to avoid expanding them to every platform.


Question: <del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

I also don't know if many users want to go through the trouble of filtering the remote platform support that they want, though if that's something users are interested in then I'm certainly willing to try to support that.<sup1</supOption (2) is possible without too much effort, though I don't think it adds much value over option (1). Additionally, if option (1) is already going to be used to download the release bundle, it might as well just pull the binary out of the release bundle as well and save the complexity of a local build. In any case, the current package should have the build of removed since it won't really be of any use. Let me know if option (1) will work and if there's anything I can do to help. <sup1</supI think a better long-term solution is to provide two download variants: a "full" agent bundle that includes all platforms and a "slim" agent bundle that just includes commonly used platforms. P.S. Thanks for helping to support this!
Given the usual problems with pre-compiled binaries, reading the discussion above I thought we might have another problem : nixos needing its own agent in mutagen- But to my surprise, the amd64 binaries work on nixos without the need to patch the ELF interpreter or anything else, it seems that everything is self-contained with no external dependencies. So why not make a binary installation directly?
I can open a brand new issue about this, but wanted to get a quick check from you about a problem I'm having with this. I'm getting the following when extracting an agent: The libexec path appears to be appended to the directory for some reason. I don't know if this is an issue w/ nixpkgs or mutagen but would be happy to help track it down and (maybe) fix it. So, it looks like the file is there, but the search path is treating the absolute path for as if it was relative to the path. I suspect it has to do with the liberal usage of symlinks in nix tripping something up. I'm just too new to golang and nix to have any idea how to fix this.
Hey I believe this is fixed in Mutagen (thanks to who reported it in mutagen-io/mutagen and fixed it in mutagen-io/mutagen).


Question: <del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

It looks like the corresponding NixOS package needs to be updated — we're currently at Mutagen v0.16.4. If you want to open a NixOS/nixpkgs PR for that, that's probably the way to go. Feel free to @ mention me in that PR, otherwise I'll see if I can find some time to open it during this week.
Thanks for the information. :) I spent some time yesterday trying to get my local system running on Mutagen 0.16.4. I got it working in terms of correctly locating the agents, but I noted in the PR that it isn't working for docker containers because Mutagen running as root does not seem to be able to find Docker installed via nix. I'm happy to move any additional discussion to .


Question: , libXScrnSaver, libXcomposite, libXcursor, libXdamage, libXext, libXfixes , libXi, libXrandr, libXrender, libXtst, libxcb, libxshmfence, mesa, nspr, nss , pango, systemd, libappindicator-gtk3, libdbusmenu, writeScript, python3, runCommand <ins> , libunity </ins> , wayland , branch , common-updater-scripts, withOpenASAR ? false }:

I never really noticed this until today, but apparently the discord task bar icon (if you have one, I am on KDE) is supposed to have a notification badge, I have included a screenshot. The discord task bar icon should include a badge for the number of unread notifications ! Today I was setting up a system for someone else who was new to Linux, I installed Discord via flatpak, and then they asked me about the badge (since it is present on Windows but not on the ). From a little searching, it seems that Discord needs to ba available in the system, so on Kubuntu this was fixed by doing . Since is already in , it might just be a matter of adding it to the ?
Huh. I don't think I ever knew one was supposed to be there either. I see an unread indicator (red circle in the top corner, no number), so that works fine, but I don't think I've ever seen a number. Assuming that would be all it would take, sounds like a pretty simple PR that would be a good addition.
I have made a clone of and it does seem that all that was need was to add the library to . I found it to be a bit ugly myself since I had over 1000 unread notifications, and it seems disabling it is only possible outside the application. On for example, you have to go to and tick off "Show notification badges". Running the current from afterwords does not remove the badges, it only freezes them in place, as in marking notifications as read will not update the number, so this is also cached somewhere outside , meaning this couldn't be a toggleable functionality via an .


Question: hackage = [ http://hackage.haskell.org/package/ http://hdiff.luite.com/packages/archive/package/ <ins> http://hackage.fpcomplete.com/package/ http://objects-us-east-1.dream.io/hackage-mirror/package/ </ins> ]; # Roy marples mirrors

During Hackage downtime, nix builds are needlessly broken. There are mirrors available; we should use them. See: Mirrors include: http://objects-us-east- I'm a third party reporting errors I've heard of, so I don't have precise repro steps. Do certain Haskell-related build stuff during Hackage downtime, I guess?
Mirror list is available at E. g. https://objects-us-east-


Question: substituteInPlace variety_lib/varietyconfig.py  --replace "__variety_data_directory__ = "../data""  "__variety_data_directory__ = "$out/share/variety"" <del> substituteInPlace data/scripts/set_wallpaper  --replace /bin/bash ${runtimeShell} substituteInPlace data/scripts/get_wallpaper  --replace /bin/bash ${runtimeShell} </del> <ins> substituteInPlace variety/VarietyWindow.py  --replace '[script,' '["${runtimeShell}", script,'  --replace 'check_output(script)' 'check_output(["${runtimeShell}", script])' </ins> ''; meta = with lib; {

Recently variety stops working on NixOS. Pictures are downloaded well but the wallpaper can't be changed and can only be set in system setting. That's because of the hardcoded shebang which is taken from on the first installation. So when the bash is updated the script can't find it. It should be set as something like . Not sure if this is a nixos bug. Steps to reproduce the behavior: variety bash It works after the bash update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
IIRC now we use . I am patching it now.


Question: type = types.attrsOf types.str; description = "Extra environment variables to pass to the Garage server."; default = { }; <del> example = { RUST_BACKTRACE = "yes"; }; </del> <ins> example = { RUST_BACKTRACE = "yes"; }; </ins> }; environmentFile = mkOption {

Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.


Question: hash = "sha256-nxNQde3GZs8rnKkd41xnA+KxdxwQp3B0FPtlbCilmzs="; }; <ins> patches = [ # Load modules from path in `NIX_GNOME_PANEL_MODULESDIR` environment variable # instead of gnome-panel’s libdir so that the NixOS module can make gnome-panel # load modules from other packages as well. ./modulesdir-env-var.patch ]; </ins> # make .desktop Exec absolute postPatch = '' patch -p0 <<END_PATCH

Panel applets are being picked up from environment variable in and a completely hardcoded path in . First, we will need to patch the latter manager to use an environment variable as well. Second, we will need to do something similar to what . Or better, create  derivation. Originally posted by 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 .
I'd like to tackle this, do you have any pointers? We need to get it to pick up at least right?


Question: buildInputs = [ dbus <ins> systemd </ins> dconf gdk-pixbuf gobject-introspection python3.pkgs.pygobject3 # for pygobject overrides gtk2 gtk3 <ins> gtk4 </ins> isocodes json-glib libnotify

Upstream ibus-1.5.24 (in nixpkgs) supports gtk4. It will be good if we enable gtk4 support in nixpkgs. I fail to enable it with the following patch.


Question: }; nativeBuildInputs = [ autoreconfHook pkgconfig pythonPackages.docutils ]; <del> buildInputs = stdenv.lib.optional stdenv.isDarwin libiconv; </del> <ins> buildInputs = [ jansson ] ++ stdenv.lib.optional stdenv.isDarwin libiconv; </ins> # to generate makefile.in autoreconfPhase = ''

universal-ctags is not built with jansson, which means that universal-ctags does not have support for outputting JSON files. Steps to reproduce the behavior: universal-ctags with error: Expected: Tags file created with json format. Additional context I think this can be resolved by simply adding to the , but I've never written a nix package before so I'm not certain. I did this locally and it seemed to work, but I don't know if there's a better way to do it. Metadata Maintainer information:
cc I took a whack at fixing this locally. If this looks good to you, let me know and I can create a PR. I'm really new to Nix so it's likely I did something wrong.
Welcome and thanks a lot for the wonderful bug description Open the PR of course! You can update the package to the last version or add yourself to maintainers too if you are agree Don't hesitate to ask if your find any troubles