jiebi/CodeConvo huggingface dataset:
Code change:
XDG_CONFIG_HOME=''${XDG_CONFIG_HOME:-$HOME/.config} ''; <del> startplasma = '' ${set_XDG_CONFIG_HOME} mkdir -p "''${XDG_CONFIG_HOME}" '' + optionalString config.hardware.pulseaudio.enable '' # Load PulseAudio module for routing support. # See also: http://colin.guthr.ie/2009/10/so-how-does-the-kde-pulseaudio-support-work-anyway/ ${getBin config.hardware.pulseaudio.package}/bin/pactl load-module module-device-manager "do_routing=1" '' + '' ${activationScript} # Create default configurations if Plasma has never been started. kdeglobals="''${XDG_CONFIG_HOME}/kdeglobals" if ! [ -f "$kdeglobals" ]; then kcminputrc="''${XDG_CONFIG_HOME}/kcminputrc" if ! [ -f "$kcminputrc" ]; then cat ${kcminputrc} >"$kcminputrc" fi gtkrc2="$HOME/.gtkrc-2.0" if ! [ -f "$gtkrc2" ]; then cat ${gtkrc2} >"$gtkrc2" fi gtk3_settings="''${XDG_CONFIG_HOME}/gtk-3.0/settings.ini" if ! [ -f "$gtk3_settings" ]; then mkdir -p "$(dirname "$gtk3_settings")" cat ${gtk3_settings} >"$gtk3_settings" fi fi ''; </del> in {

Related discussion:
text: On a fresh install, lightdm is writing several files to / These should probably be either in /root or in some other runtime .cache and .gtkrc-2.0 Steps to reproduce the behavior: NixOS with X enabled, using the default lightdm display manager. soon as the display manager starts, files are written to / That my / will stay clean. If I stop display-manager.service, delete the files, then restart it, the files return. Looking in my /etc/passwd, shows that lightdm does have a home directory set at /var/lib/lightdm. But for some reason these files are not being written there as they should be. Please run and paste the result.
I just realized after I posted this that I used an old iso from 21.11 to install. So I reinstalled with 22.05, and this still happens
Are you using KDE Plasma? Can you reproduce the issue with SDDM?
I am using KDE. The issue also happens with SDDM. I went ahead and tested GDM as well (while still using plasma,) and it does not happen.
I can reproduce. For my case, in I saw one single file with prefix, after some search it is likely cache for kbuildsycoca5 (). I have no idea what that package does so far though.
All the files in my / are exactly the files being generated in
I can reproduce this with Plasma 5/SDDM on nixpkgs-unstable.
I also observed these files, tracked down the problem and prepared a pull-request that -- hopefully -- fixes the issue: . I came to the conclusion that it is best to entirely remove the code that creates those file. However, I feel a bit unconfident about my solution, so it would be good to have it tested by more users. If you can spare the time, please have a look at my draft pull request, maybe try my solution, and feel free to report back or even drop a review. Thanks a lot!
Code change:
description = "Open the GitHub page or website for a repository in your browser"; license = licenses.mit; platforms = platforms.all; <del> maintainers = with maintainers; [ jlesquembre SuperSandro2000 ]; </del> <ins> maintainers = with maintainers; [ SuperSandro2000 ]; </ins> }; }

Related discussion:
text: Package name: git-open Latest released version: 3.0.0 <!-- Search your package here: --- Current version on the unstable channel: 2.1.0 Current version on the stable/release channel: 2.1.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package.-- Note for maintainers: Please tag this issue in your PR.
The latest version of listed on the project's is (Dec 3, 2018), however was released on the project's (Jul 18, 2022).
Code change:
go-junit-report = callPackage ../development/tools/go-junit-report { }; <ins> gobang = callPackage ../development/tools/database/gobang { }; </ins> gogetdoc = callPackage ../development/tools/gogetdoc { }; gox = callPackage ../development/tools/gox { };

Related discussion:
text: Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix
Code change:
# Load extensions from NEMO_EXTENSION_DIR environment variable # https://github.com/NixOS/nixpkgs/issues/78327 ./load-extensions-from-env.patch <ins> # Don't tie the interactive search box with the window's lifetime # https://github.com/linuxmint/nemo/issues/3423 (fetchpatch { url = "https://github.com/linuxmint/nemo/commit/055b47af0e1a830e556989372f3689bbd36b639d.patch"; hash = "sha256-cMtBz1uLGCV4nnrBITzXAV/SffI0nNcEdeujrHxAzQc="; }) </ins> ]; outputs = [ "out" "dev" ];

Related discussion:
text: Several windows of nemo closing together when sending killactive (note that this is not real kill) and a coredump can be found in systemd journal. Steps to reproduce the behavior: several instances of nemo from a wlroots based compositor e.g. sway or hyprland. hotkeys attached to killactive on one window. systemd-coredump message from journal (I use gnome-logs for convenience). The nemo window should exits one per time, not closing together, and not coredump as well. windows do share one process id, but this seems to be not the case as . (however, this may be misleading as someone mentioned that steam also exits its background process when using killactive) issue didn't exist on Arch Linux. Just to mention that there may be something we should patch. is the content of coredump: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Reported from Fedora with nemo 5.6.2, also hyprland, works fine.
More related behavior (I'll call nemo windows in time order as nemo1 nemo2 etc): I launch nemo1 and nemo2 in a short interval, they won't close together when I close one. I launch nemo1 and wait for about 10 seconds, then launch nemo2, then close nemo1, they are possible to crash. However, closing nemo2 immediately won't, if wait for another 10 seconds, both crashes when closing nemo1 or nemo2. I launch nemo1, nemo2 and nemo3 in a short interval, then close nemo1, they all will crash. Again, nemo windows share one pid. So the crash will close all windows. This was , but I'm afraid they can't reproduce the bug anymore. Also since other distros can't reproduce this bug, I'd rather believe it's specific to nixos, and maybe because of the wrapper.
Code change:
# Load extensions from NEMO_EXTENSION_DIR environment variable # https://github.com/NixOS/nixpkgs/issues/78327 ./load-extensions-from-env.patch <ins> # Don't tie the interactive search box with the window's lifetime # https://github.com/linuxmint/nemo/issues/3423 (fetchpatch { url = "https://github.com/linuxmint/nemo/commit/055b47af0e1a830e556989372f3689bbd36b639d.patch"; hash = "sha256-cMtBz1uLGCV4nnrBITzXAV/SffI0nNcEdeujrHxAzQc="; }) </ins> ]; outputs = [ "out" "dev" ];

Related discussion:
text: I was not able to properly test this right now (sorry :bowingwoman:), but here are some random things you can try: See if you can reproduce this with nautilus, thunar, also some old version of nemo, some old nixpkgs checkouts, ... If you find it previously working, a bisect point will be appreciated. Install debug symbols and reproduce the crash, not tested but should be something like: Then get list of crashes with , run and enter . Based on the above step, try to patch away (remove) some of the lines in  according to your stack trace and try reproduce the issue, you can also e.g. try swapping the order they distroy widgets to see if it matters. Sorry I have no idea how killactive "closes" a window, is that the only way to trigger the crash? Did you spot the crash when closing nemo normally, i.e. clicking (File) - (Close All Windows) and/or (File) - (Close)?
Sorry I haven't got time to debug it, but I've tested with "close all windows" or "close" several times, they didn't crash and "close" works correctly. Thunar don't (since it doesn't share the same pid across windows?), and nautilus refuses to open a second window when one exists.
Okay here is the coredump:
Weird, did you trigger the crash after rebuilding nemo? :thinking:
Yes, by the same killactive sended by hyprland
in my nixos configuration, and installed with home manager (home manager as a module of nixos). This rebuilds nemo (I saw it) when applying config.
Can you try adding to () instead?
Okay it seem to work, and now I get this:
Pretty fun though, it happens even without triggering the 'search window'. I just open and close the nemo, and do nothing else.
Make sense to me! If I hit the search button to trigger the search widget, then close it, it won't crash (tested 10 times). So the problem is trying to destroy a widget that doesn't exist.
Code change:
# Load extensions from NEMO_EXTENSION_DIR environment variable # https://github.com/NixOS/nixpkgs/issues/78327 ./load-extensions-from-env.patch <ins> # Don't tie the interactive search box with the window's lifetime # https://github.com/linuxmint/nemo/issues/3423 (fetchpatch { url = "https://github.com/linuxmint/nemo/commit/055b47af0e1a830e556989372f3689bbd36b639d.patch"; hash = "sha256-cMtBz1uLGCV4nnrBITzXAV/SffI0nNcEdeujrHxAzQc="; }) </ins> ]; outputs = [ "out" "dev" ];

Related discussion:
text: However, there is another question: fedora and archlinux with the exact nemo 5.6.3, hyprland latest, xdg-desktop-portal-hyprland, doesn't, and the code makes sense. So what is happening to nixos?
Unsure of memory leaks, but anyway it works. This seems like a upstream bug and caused by gtk or glib version compatibility. Will close it for now.
Hmmm, please consider reporting this to linuxmint. I checked nautilus and they after so we are on our own. I actually wonder whether a check is needed But it is unclear to me why the null check is not enough :upsidedown_face:
Tested, this is not enough however.
Did this ever get fixed? I seem to be having this same issue still with version 6.0.2
I totally forgot that. I'm using my patches for more than one year. This is also useful for Would be better to report it upstream, though.
Thanks for the info. This does in fact fix it. It's worth noting for anyone who might travel this path in the future - the patch has to be applied to , even if using . Totally didn't spend 45 minutes trying to figure out why it wasn't working just to figure that out
Please try .
seems to work?
Code change:
, systemd , zlib , pcre <ins> , libb64 , libutp , miniupnpc , dht , libnatpmp </ins> # Build options , enableGTK3 ? false , gtk3

Related discussion:
text: Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:
Code change:
preCheck = lib.optionalString stdenv.isDarwin '' substituteInPlace kitty_tests/file_transmission.py  --replace test_file_get dont_test_file_get  <del> --replace test_path_mapping_receive dont_test_path_mapping_receive </del> <ins> --replace test_path_mapping_receive dont_test_path_mapping_receive  --replace test_transfer_send dont_test_transfer_send </ins> substituteInPlace kitty_tests/shell_integration.py  --replace test_fish_integration dont_test_fish_integration substituteInPlace kitty_tests/shell_integration.py 

Related discussion:
text: Package name: kitty Latest released version: 0.29.2 <!-- Search your package here: --- Current version on the unstable channel: 0.29.2 Current version on the stable/release channel: 0.28.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Code change:
<ins> { lib, appimageTools, fetchurl, }: let pname = "clickup"; version = "3.3.79"; src = fetchurl { # Using archive.org because the website doesn't store older versions of the software. url = "https://web.archive.org/web/20240601173958/https%3A%2F%2Fdesktop.clickup.com%2Flinux"; hash = "sha256-jAOYDX9j+ZTqWsSg0rEckKZnErgsIV6+CtUv3M3wNqM="; }; appimageContents = appimageTools.extractType2 { inherit pname version src; }; in appimageTools.wrapType2 { inherit pname version src; extraPkgs = pkgs: [ pkgs.xorg.libxkbfile ]; extraInstallCommands = '' install -m 444 -D ${appimageContents}/desktop.desktop $out/share/applications/clickup.desktop substituteInPlace $out/share/applications/clickup.desktop  --replace-fail 'Exec=AppRun --no-sandbox %U' 'Exec=clickup'  --replace-fail 'Icon=desktop' 'Icon=clickup' for size in 16 32 64 128 256 512 1024; do install -Dm444 ${appimageContents}/usr/share/icons/hicolor/''${size}x''${size}/apps/desktop.png  -t $out/share/icons/hicolor/''${size}x''${size}/apps/clickup.png done ''; meta = { description = "All in one project management solution"; homepage = "https://clickup.com"; license = lib.licenses.unfree; mainProgram = "clickup"; maintainers = with lib.maintainers; [ heisfer ]; platforms = [ "x86_64-linux" ]; }; } </ins>

Related discussion:
text: Project description ClickUp is a project management solution, similar to Trello Metadata homepage URL: source URL: N/A license: unfree platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like it's needs to be archived with (currently it's down). Download URL is:
I also found this PR, but it has been a year
Yeah I did give packaging it a shot but I could not find a reliable way to get it downloaded because there doesn't seem to be an exposed way to get a specific version?
Yeah, I also checked PR URL, and it doesn't seem to give reliable version package. Even AUR has some problems. That's why I suggested
Code change:
Explicitly set `kubelet.hostname` to `networking.fqdnOrHostName` to get back the old default behavior. <ins> - Docker now defaults to 27.x, because version 24.x stopped receiving security updates and bug fixes after [February 1, 2024](https://github.com/moby/moby/pull/46772#discussion_r1686464084). </ins> - `keycloak` was updated to version 25, which introduces new hostname related options. See [Upgrading Guide](https://www.keycloak.org/docs/25.0.1/upgrading/#migrating-to-25-0-0) for instructions.

Related discussion:
text: Today one of my containers wouldn't start after I updated the docker-compose file and it was due to the docker engine being too old to support a certain feature. Easy enough to fix in config but is there a specific reason the attribute points at rather than ? Last time the attr was touched was
The reason is basically this: Quoting a recent comment in that PR:
Code change:
hash = "sha256-mi8btxI6de5iQ8HzNpvuFdJHjzi03zZJT65dsWEiDHA="; }; }; <ins> distributionIni = writeText "distribution.ini" (lib.generators.toINI {} { # Some light branding indicating this build uses our distro preferences Global = { id = "nixos"; version = "1.0"; about = "Tor Browser for NixOS"; }; }); policiesJson = writeText "policies.json" (builtins.toJSON { policies.DisableAppUpdate = true; }); </ins> in stdenv.mkDerivation rec { pname = "tor-browser-bundle-bin";

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:
hash = "sha256-mi8btxI6de5iQ8HzNpvuFdJHjzi03zZJT65dsWEiDHA="; }; }; <ins> distributionIni = writeText "distribution.ini" (lib.generators.toINI {} { # Some light branding indicating this build uses our distro preferences Global = { id = "nixos"; version = "1.0"; about = "Tor Browser for NixOS"; }; }); policiesJson = writeText "policies.json" (builtins.toJSON { policies.DisableAppUpdate = true; }); </ins> in stdenv.mkDerivation rec { pname = "tor-browser-bundle-bin";

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:
, fetchFromGitHub , python3Packages , dnsmasq <ins> , gawk </ins> , getent , kmod , lxc

Related discussion:
text: <!-- 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 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: <!-- The current version can be found easily with the same process as 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: 1.3.0 desired version: 1.3.3 <!-- 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.
Code change:
bpycv = callPackage ../development/python-modules/bpycv {}; <ins> bpylist2 = callPackage ../development/python-modules/bpylist2 { }; </ins> bpython = callPackage ../development/python-modules/bpython { }; bqplot = callPackage ../development/python-modules/bqplot { };

Related discussion:
text: Project description Python app to work with pictures and associated metadata from Apple Photos on macOS. Also includes a package to provide programmatic access to the Photos library, pictures, and metadata. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This was the most complex package i ever tried to write :sweat_smile:
Code change:
<ins> source 'https://rubygems.org' gem 'ipaddr' gem 'addressable' gem 'json' gem 'mongo' gem 'rchardet' </ins>

Related discussion:
text: Project description A scanner informing the technologies and headers a website uses. Metadata homepage URL: source URL: license: GPL-2.0 platforms: Agnostic (Darwin, Linux, Windows) See also:
I was able to build it, check it here
Thanks!