jiebi/CodeConvo huggingface dataset:
Code change:
<del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

Related discussion:
text: 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?
Code change:
<del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

Related discussion:
text: 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.
Code change:
<del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

Related discussion:
text: 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).
Code change:
<del> { lib, buildGoModule, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchzip }: </ins> buildGoModule rec { pname = "mutagen";

Related discussion:
text: 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 .
Code change:
, 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 }:

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

Related discussion:
text: 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-
Code change:
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; {

Related discussion:
text: 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.
Code change:
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 {

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

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

Related discussion:
text: 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.
Code change:
}; 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 = ''

Related discussion:
text: 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
Code change:
def get_current_plugins(editor: Editor) -> List[Plugin]: with CleanEnvironment(): <del> cmd = ["nix", "eval", "--impure", "--json", "--expr", editor.get_plugins] </del> <ins> cmd = ["nix", "eval", "--extra-experimental-features", "nix-command", "--impure", "--json", "--expr", editor.get_plugins] </ins> log.debug("Running command %s", cmd) out = subprocess.check_output(cmd) data = json.loads(out)

Related discussion:
text: When attempting to add a Vim plugin, fails. It updates without error. I believe previous developers have this feature enabled in their system/user Nix configuration.
Code change:
<command>nixos-rebuild switch</command>. </para> <ins> <note> <para> Some packages require additional global configuration such as D-Bus or systemd service registration so adding them to <xref linkend="opt-environment.systemPackages"/> might not be sufficient. You are advised to check the <link xlink:href="#ch-options">list of options</link> whether a NixOS module for the package does not exist. </para> </note> </ins> <para> You can get a list of the available packages as follows: <screen>

Related discussion:
text: We should mention in nixos manual Chapter 6 that options can be dicovered with and It will help newbs learn how to discover packages more easily. As a new user, I was sticking everything I wanted inside of the array, and I didn't not realize that is a better route to take because it configures many things automatically. For example, results in also being installed as well as features enabled, while writing does not. This will be helpful to new users.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
<ins> { lib , fetchFromGitHub , buildPythonPackage # propagates , numpy , torch , tqdm , more-itertools , transformers , ffmpeg-python # tests , pytestCheckHook }: buildPythonPackage rec { pname = "whisper"; version = "unstable-2022-09-23"; format = "setuptools"; src = fetchFromGitHub { owner = "openai"; repo = pname; rev = "8cf36f3508c9acd341a45eb2364239a3d81458b9"; hash = "sha256-2RH8eM/SezqFJltelv5AjQEGpqXm980u57vrlkTEUvQ="; }; postPatch = '' # Rely on the ffmpeg path already patched into the ffmpeg-python library substituteInPlace whisper/audio.py  --replace 'run(cmd="ffmpeg",' 'run(' ''; propagatedBuildInputs = [ numpy torch tqdm more-itertools transformers ffmpeg-python ]; preCheck = '' export HOME=$TMPDIR ''; checkInputs = [ pytestCheckHook ]; disabledTests = [ # requires network access to download models "test_transcribe" ]; meta = with lib; { description = "General-purpose speech recognition model"; homepage = "https://github.com/openai/whisper"; license = licenses.mit; maintainers = with maintainers; [ hexa ]; }; } </ins>

Related discussion:
text: Project description Whisper is a general-purpose speech recognition model. It is trained on a large dataset of diverse audio and is also a multi-task model that can perform multilingual speech recognition as well as speech translation and language identification. Metadata homepage URL: source URL: license: mit platforms: all
PTAL.
Code change:
echo "user_pref("extensions.torlauncher.toronionauthdir_path", "$HOME/TorBrowser/Data/Tor/onion-auth");" echo "user_pref("extensions.torlauncher.torrc_path", "$HOME/TorBrowser/Data/Tor/torrc");" echo "user_pref("extensions.torlauncher.tordatadir_path", "$HOME/TorBrowser/Data/Tor");" <ins> echo "user_pref("network.proxy.socks", "file://$XDG_RUNTIME_DIR/Tor/socks.socket");" </ins> } >> "$HOME/TorBrowser/Data/Browser/profile.default/prefs.js" # Lift-off

Related discussion:
text: When you try to connect to the Tor network using the Tor browser you get the error message ! When you try to visit a website after being shown the big red error message your get the error message ! This problem appeared between one and two weeks ago. ; can't find an existing Nixpkgs issue. Steps to reproduce the behavior: the Tor browser from Nixpkgs the Tor browser on error message to go to a website When clicking on the browser should connect to the Tor network and be able to browse. The . browsers says that it can detect my internet connection. ! Tor logs doesn't seem to indicate any problems (from what I can interpret) I live in Sweden and this issue has appeared both when I've connected to the internet using my home connection (Sunet) and when I've connected over a VPN. I.e. no fuckery by an oppressive government. The timeline match up-ish with when would have become available in the binary caches. Unsure if the error appeared before or after updating around that time. After checking the original PR I see that this problem was noticed, but a workaround was applied. Doesn't seem to work for me :-/ The value is for me. I'm using root on tmpfs, and nothing under is persistently saved between boots. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- and because you seem to have actually researched the problem. The system is fully up-to-date as of 2023-03-05 22:15 CEST.
The red error message indicates that Tor cannot find the tor socket. Everything else is bound to not work unless it goes over the normal internet. Please see and for the underlying problem and please check if the firefox setting points to the right socket file.
I tested to set to , but that didn't help.
Setting to also doesn't work.
Just to avoid ambiguities, did you set to (with file name part)? TBB is still working fine for me with the workaround. Likewise for me, is a tmpfs. Have you modified (and forgotten about it) your torrc, e.g. to use a different control port/mechanism? What is your XDGSESSIONTYPE?
Code change:
echo "user_pref("extensions.torlauncher.toronionauthdir_path", "$HOME/TorBrowser/Data/Tor/onion-auth");" echo "user_pref("extensions.torlauncher.torrc_path", "$HOME/TorBrowser/Data/Tor/torrc");" echo "user_pref("extensions.torlauncher.tordatadir_path", "$HOME/TorBrowser/Data/Tor");" <ins> echo "user_pref("network.proxy.socks", "file://$XDG_RUNTIME_DIR/Tor/socks.socket");" </ins> } >> "$HOME/TorBrowser/Data/Browser/profile.default/prefs.js" # Lift-off

Related discussion:
text: The person on uses wayland (with sway). I currently still use x11 (with i3) and haven't tested it with wayland.
That did it! I missed that you should specify the file in the path. I'm using AwesomeWM.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The person on had the same problem and the same solution :-)
Why did you close this issue You can't seriously think that this temporary workaround is an acceptable permanent solution to this problem? While we still don't have a permanent solution, it should be as easy as possible for users to find information about this workaround. By closing this issue we signal to people that this problem has been solved. And people currently experiencing this problem on a fully up-to-date system will probably not think about looking into closed issues, because the issue is still there.
I am also experiencing this issue. The fix worked for me.
Confirmed. The issue is still present. Default installed value of is 127.0.0.1. Changing it to resolves the problem.
This issue only started happening on my machine after deleting today.
Still an issue. I'm using TBB with firejail and I have to apply the workaround at every restart. TBB creates the folder but not a profile inside (this wouldn't be a problem for me if connection works out of the box). about:config - = tor-browser-bundle-bin 12.0.5 firejail-0.9.72 nixos-unstable
By default, the service runs on port 9050 and the control port on 9051. This is configured in the torrc file: Your firewall may be blocking some of these ports bound by default to localhost which normally point to 127.0.0.1
The PR for Tor Browser 13 removes the current workaround again, because it seems the issue was fixed upstream: I would be grateful if some of you could give this a try and report if it's still working (or working again).
Code change:
<ins> diff --git a/configure.ac b/configure.ac index a3cdb2da..cade9466 100644 </ins> --- a/configure.ac +++ b/configure.ac <del> @@ -429,11 +429,11 @@ </del> <ins> @@ -469,11 +469,11 @@ PKG_CHECK_EXISTS([pygobject-3.0 >= $PYGOBJECT_REQUIRED], </ins> if test "x$enable_pygobject" = "xyes"; then PKG_CHECK_MODULES(PYTHON, [pygobject-3.0 >= $PYGOBJECT_REQUIRED])

Related discussion:
text: 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.
Code change:
, gnupg , darwin, xcbuild , procps, icu <ins> , installShellFiles </ins> }: { enableNpm ? true, version, sha256, patches ? [] } @args:

Related discussion:
text: The package (and the related ones) don't offer completions, only Npm's. At least for bash Node offers it through . I'd like this bash completion to be . Install Node, see that there is no completion in the completions dir (I'm using home-manager, so that'd be ).
Fixed by