jiebi/CodeConvo huggingface dataset:
Code change:
]; buildInputs = [ <del> rocm-thunk rocm-smi hsa-amd-aqlprofile-bin </del> numactl libpciaccess libxml2 elfutils mpi <ins> systemd </ins> gtest ]; <ins> propagatedBuildInputs = [ rocmtoolkit-merged ]; </ins> cmakeFlags = [ "-DCMAKE_MODULE_PATH=${clr}/lib/cmake/hip" <del> "-DPROF_API_HEADER_PATH=${roctracer.src}/inc/ext" </del> "-DHIP_ROOT_DIR=${clr}" "-DGPU_TARGETS=${lib.concatStringsSep ";" gpuTargets}" # Manually define CMAKE_INSTALL_<DIR>

Related discussion:
text: When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- 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.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see
Code change:
services.hardware.bolt.enable = mkDefault true; services.xserver.libinput.enable = mkDefault true; # for controlling touchpad settings via gnome control center systemd.packages = [ pkgs.gnome3.vino ]; <del> services.flatpak.extraPortals = [ pkgs.xdg-desktop-portal-gtk ]; </del> <ins> xdg.portal.extraPortals = [ pkgs.xdg-desktop-portal-gtk ]; </ins> # If gnome3 is installed, build vim for gtk3 too. nixpkgs.config.vim.gui = "gtk3";

Related discussion:
text: It is possible to use Plasma’s native file dialogues in Firefox 64 to open or save a file. Currently this feature is not working in NixOS, and it seems to me some small changes would need to be made to derivation in order to enable it. I propose we include this option together with as a Firefox option in NixOS (see also: ). I followed the explanation on how to enable this feature as it was published on : Firefox (64 is current stable) from a terminal emulator But it produces the following error: system: host os: multi-user?: sandbox: version: channels(root): channels(hook): nixpkgs:
You'll probably have to do something like this to expose the dbus service:
Where? In:
It needs to go into a nixos module or your .
Code change:
binDir = if enableSeparateBinOutput then "$bin/bin" else "$out/bin"; <del> newCabalFileUrl = "http://hackage.haskell.org/package/${pname}-${version}/revision/${revision}.cabal"; </del> <ins> newCabalFileUrl = "mirror://hackage/${pname}-${version}/revision/${revision}.cabal"; </ins> newCabalFile = fetchurl { url = newCabalFileUrl; sha256 = editedCabalFile;

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:
''; }; <ins> prompt = { enable = mkEnableOption "automatically sourcing git-prompt.sh. This does not change $PS1; it simply provides relevant utility functions"; }; </ins> lfs = { enable = mkEnableOption (lib.mdDoc "git-lfs");

Related discussion:
text: git package includes which defines functions for shell prompt customization like . Even though the file is included it's not sourced by default and doesn't make the functions available. Steps to reproduce the behavior: package system-wide. one of the functions provided: the file manually: function becomes available: shell function being available out of the box when package installed. Making the prompt functions available when bash completions are enabled seem to have been the original intention of . However one might also argue that the functions should not be sourced by default if someone doesn't use git prompt customisations provided. It could be placed behind an option but I'm not sure it's worth the hassle. cc
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I'm not a maintainer or expert, but I read your linked Discourse thread and your ticket because it sounded interesting. Great analysis and writeup. My interpretation is that was never intended to be sourced automatically when completions are enabled, for two reasons. First, inside of : which is an instruction to source it explicitly. Second, the for says: which leads me to believe that was created so that it can be used independently from bash completion. Prior to its creation, it might have been available automatically as a consequence of completion scripts being loaded eagerly, but that was accidental.
Thanks for digging deeper into this, Theodore! I agree with your conclusion: it does look like the prompt script wasn't intended to be sourced automatically. I think the best way to approach this in NixOS would be to have a option that would enable sourcing of the file.
I think something like this sounds reasonable. I'm sorry I can't help with it right now, because I haven't set up NixOS yet. (I'm just using nix on my Mac right now.)
No worries, thanks for your help so far :) I might eventually give it a shot myself.
Code change:
buildInputs = [ cmake python3 xlibsWrapper libxcb libXrandr libXext wayland ]; enableParallelBuilding = true; <ins> preConfigure = '' substituteInPlace loader/vulkan.pc.in --replace 'includedir=''${prefix}/include' 'includedir=${vulkan-headers}/include' ''; </ins> cmakeFlags = [ "-DSYSCONFDIR=${addOpenGLRunpath.driverLink}/share" "-DVULKAN_HEADERS_INSTALL_DIR=${vulkan-headers}"

Related discussion:
text: This is the content of on my system: It has set to , which does not exist. This path should point to the include directory of vulkan-headers package. Also, the package contain headers that include headers from vulkan-headers package. Should the pc file for glfw3 add vulkan-headers to the include path? Metadata system: host os: multi-user?: sandbox: version: channels(saga): nixpkgs:
Ping (Vulkan maintainer), I'm seeing when building anything depending on vulkan-loader using pkgconfig.
Thanks for the ping! Drafted Please confirm that this solves the problem.
Code change:
./config/fonts/fontdir.nix ./config/fonts/ghostscript.nix ./config/fonts/packages.nix <del> ./config/gnu.nix </del> ./config/gtk/gtk-icon-cache.nix ./config/i18n.nix ./config/iproute2.nix

Related discussion:
text: When I set in , the rebuild fails as is no longer a valid option. Steps to reproduce the behavior: thrown: The option definition /nix/store/bfg7xzgvbhxhs7vnl7lynaxmjhmvc4j0-' no longer has any effect; please remove it. See the 16.09 release notes for more information. should not fail. - - Please run and paste the result.
Having had a look at that module (), IMO it should just be removed. ? really?
The module in general looks outdated and incomplete. I share the opinion of either dropping it or actually correcting and finishing it.
Other question is when you look at the history they removed lsh 7 years ago because it was unmaintained, but then the commit got reverted later?
This module doesn't make sense at all. GNU stuff and non-GNU ones usually can't fully replace each other, and it's up to the users to decide which one to use.
Code change:
stdenv.mkDerivation rec { pname = "xreader"; <del> version = "3.4.3"; </del> <ins> version = "3.4.4"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "sha256-GkJo/wc5StyeQv0pv5XK0Qy3o8EGpfPYY8gOMq0Afgs="; </del> <ins> sha256 = "sha256-uYnQE1GjkUxYlvXSJNmvr6q4OdvAWgv8HqTXk0KkRQM="; </ins> }; nativeBuildInputs = [

Related discussion:
text: I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. 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.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.
Code change:
stdenv.mkDerivation rec { pname = "xreader"; <del> version = "3.4.3"; </del> <ins> version = "3.4.4"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "sha256-GkJo/wc5StyeQv0pv5XK0Qy3o8EGpfPYY8gOMq0Afgs="; </del> <ins> sha256 = "sha256-uYnQE1GjkUxYlvXSJNmvr6q4OdvAWgv8HqTXk0KkRQM="; </ins> }; nativeBuildInputs = [

Related discussion:
text: I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:
Code change:
install_name_tool -change libblas.dylib ${blas}/lib/libblas.dylib $out/lib/libarpack.dylib ''; <ins> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </ins> meta = { homepage = "https://github.com/opencollab/arpack-ng"; description = ''

Related discussion:
text: Reported via email by a Nix user without a GitHub account. Build fines. In the attempt to build GNU octave for aarch64 darwin. Maintainer information:
I would suggest opening an issue but I guess that's not an option.
Perhaps, but it seems peculiar that the user "is not able to compile a simple test program" - as if there's a bug in our compiler . Related issues: Perhaps the user should try this edit to Nixpkgs: So even on Darwin the compiler that will be used will be gcc, to play nicely with gfortran.
The suggestion to use is good; I think couldn't possibly work otherwise. Beyond that, I have no idea.
But doesn't it work on x86_64 Darwin?
perhaps you could help us - does arpack and/or octave build currently on x8664 Darwin?
Any news here? This also affects other derivations (e.g. openspecfun). arpack does build on x86_64-darwin.
This issue should be renamed "gfortran broken on aarch64-darwin", as it is not specific to arpack:
See – but we should really fix this in gfortran, rather than requiring every derivation to copy/paste the line.
cc To summarize, we should set: In stdenv somehow.. Perhaps this should go here:
We probably don't want to globally disable stack protector support, though; this only affects gfortran. Seems like we'd want to have the cc-wrapper for gfortran (on aarch64-darwin) to never inject the options, either through a option, or in the cc- script itself. Actually fixing whatever goes wrong in the toolchain would be preferable, of course.
Here's a proposal:
Code change:
<del> { lib, stdenv, fetchFromGitHub, boost-build, lua, boost }: </del> <ins> { lib, stdenv, fetchFromGitHub, lua, boost, cmake }: </ins> stdenv.mkDerivation rec { pname = "luabind"; version = "0.9.1"; src = fetchFromGitHub { <del> owner = "luabind"; </del> <ins> owner = "Oberon00"; </ins> repo = "luabind"; <del> rev = "v${version}"; sha256 = "sha256-sK1ca2Oj9yXdmxyXeDO3k8YZ1g+HxIXLhvdTWdPDdag="; </del> <ins> rev = "49814f6b47ed99e273edc5198a6ebd7fa19e813a"; sha256 = "sha256-JcOsoQHRvdzF2rsZBW6egOwIy7+7C4wy0LiYmbV590Q"; </ins> }; <del> patches = [ ./0.9.1_modern_boost_fix.patch ./0.9.1_boost_1.57_fix.patch ./0.9.1_discover_luajit.patch ]; </del> <ins> nativeBuildInputs = [ cmake ]; </ins> <del> buildInputs = [ boost-build lua boost ]; </del> <ins> buildInputs = [ boost ]; </ins> propagatedBuildInputs = [ lua ]; <del> buildPhase = "LUA_PATH=${lua} bjam release"; installPhase = "LUA_PATH=${lua} bjam --prefix=$out release install"; </del> passthru = { inherit lua; };

Related discussion:
text: Steps to reproduce the behavior: FWIW: my fix is here, - but it is using a fork of . If somebody has the time to create a minimal patch on top of the current source, please feel free to. Please run and paste the result.
Looks like you are on a good path. Unfortunately I have no access to Apple hardware at all, but would be happy to merge a PR.
Yes, is working on it. There is a more active fork of luabind here: - how about we switch to using it? It'll obviate a bunch of patches as well.
I agree, sounds sensible.
Code change:
<ins> { lib , stdenv , fetchFromGitHub , rustPlatform , pkg-config , meson , ninja , rustc , cargo , wrapGAppsHook4 , python3 , libadwaita , graphene , gst_all_1 , glib-networking , darwin , libsoup_3 }: stdenv.mkDerivation rec { pname = "glide-media-player"; version = "0.6.1"; src = fetchFromGitHub { owner = "philn"; repo = "glide"; rev = version; hash = "sha256-dIXuWaoTeyVBhzr6VWxYBsn+CnUYG/KzhzNJtLLdRuI="; }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; hash = "sha256-azvxW40fuKuF/N0qwzofFk1bZiNxyTN6YBFU5qHQkCA="; }; postPatch = '' substituteInPlace scripts/meson_post_install.py  --replace "gtk-update-icon-cache" "gtk4-update-icon-cache" patchShebangs --build scripts/meson_post_install.py '' + lib.optionalString stdenv.isDarwin '' sed -i "/wayland,x11egl,x11glx/d" meson.build ''; nativeBuildInputs = [ pkg-config meson ninja rustPlatform.cargoSetupHook rustc cargo wrapGAppsHook4 python3 ]; buildInputs = [ libadwaita graphene gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-bad gst_all_1.gst-plugins-good glib-networking ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk_11_0.frameworks.IOKit ]; # FIXME: gst-plugins-good missing libsoup breaks streaming # (https://github.com/nixos/nixpkgs/issues/271960) preFixup = '' gappsWrapperArgs+=(--prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ libsoup_3 ]}") ''; meta = with lib; { description = "Linux/macOS media player based on GStreamer and GTK"; homepage = "https://philn.github.io/glide"; license = licenses.mit; maintainers = with maintainers; [ aleksana ]; mainProgram = "glide"; platforms = platforms.unix; # error: could not find system library 'gstreamer-gl-1.0' required by the 'gstreamer-gl-sys' crate broken = stdenv.isDarwin && stdenv.isx86_64; }; } </ins>

Related discussion:
text: Project description "Linux/macOS media player based on GStreamer and GTK" gstreamer rust Metadata homepage URL: source URL: license: MIT platforms: linux
I tried to package glide and it's building successfully but the timestamps and the progress bar at the bottom aren't working. My progress is at if someone else is willing to look into it but I'm not sure how to debug this.
Nice, thanks Sadly, I think you made it further than me: heh
I couldn't really find anything about
I pulled your branch but it doesn't launch for me. Just the .
Stuck here I think maybe updating the registry would help, but I'd better waiting for the next release if possible...
Code change:
ssh-askpass-fullscreen = callPackage ../tools/networking/ssh-askpass-fullscreen { }; <ins> sshed = callPackage ../tools/networking/sshed { }; </ins> sshguard = callPackage ../tools/security/sshguard { }; sshping = callPackage ../tools/networking/sshping { };

Related discussion:
text: Project description So basically it is a simple ssh config manager. Metadata homepage URL: source URL: license: Apache-2.0 platforms:
Code change:
python3.pkgs.buildPythonApplication rec { pname = "sticky"; <del> version = "1.11"; </del> <ins> version = "1.12"; </ins> format = "other"; src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-PXJpNKzF9goQvfh3lUUfOaZFessFNrWtg8nMDxPxRMo="; </del> <ins> hash = "sha256-kAO8Qz4bTn3+YeIXAvPZ1SpKgn+g+rBgi9+TaqL1vOY="; </ins> }; postPatch = ''

Related discussion:
text: I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. 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.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.
Code change:
python3.pkgs.buildPythonApplication rec { pname = "sticky"; <del> version = "1.11"; </del> <ins> version = "1.12"; </ins> format = "other"; src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-PXJpNKzF9goQvfh3lUUfOaZFessFNrWtg8nMDxPxRMo="; </del> <ins> hash = "sha256-kAO8Qz4bTn3+YeIXAvPZ1SpKgn+g+rBgi9+TaqL1vOY="; </ins> }; postPatch = ''

Related discussion:
text: I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:
Code change:
}; systemd.services.libvirtd = { <ins> wantedBy = [ "multi-user.target" ]; </ins> requires = [ "libvirtd-config.service" ]; after = [ "libvirtd-config.service" ] ++ optional vswitch.enable "ovs-vswitchd.service";

Related discussion:
text: the following configuration: guests are started to confirm VM should have automatically started guests marked to start on boot start Guests marked to boot on startup should start doesn't seem to do what it says
Not stale
The problem is that libvirtd is socket-activated on NixOS which it isn't out of the box.
Code change:
gmic_stdlib = fetchurl { name = "gmic_stdlib.h"; url = "http://gmic.eu/gmic_stdlib${lib.replaceStrings ["."] [""] version}.h"; <del> sha256 = "adObp8s+2TWaS+X/bQSphWRK6o85h+DGwlIDol6XN/4="; </del> <ins> hash = "sha256-kWHzA1Dk7F4IROq/gk+RJllry3BABMbssJxhkQ6Cp2M="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Steps to reproduce the behavior: gmic in a nix shell using the unstable channel Add any other context about the problem here.
Will be fixed by
Thanks! Note that it makes darktable fail to build.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
use = builtins.trace "Obsolete option `${showOption from}' is used. It was renamed to `${showOption to}'."; }; <ins> mkRenamedOptionModuleWith = { /* Old option path as list of strings. */ from, /* New option path as list of strings. */ to, /* Release number of the first release that contains the rename, ignoring backports. Set it to the upcoming release, matching the nixpkgs/.version file. */ sinceRelease, }: doRename { inherit from to; visible = false; warn = lib.isInOldestRelease sinceRelease; use = lib.warnIf (lib.isInOldestRelease sinceRelease) "Obsolete option `${showOption from}' is used. It was renamed to `${showOption to}'."; }; </ins> /* Return a module that causes a warning to be shown if any of the "from" option is defined; the defined values can be used in the "mergeFn" to set the "to" value.

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors