Question: Project description goread is an RSS/Atom feed reader for your terminal. It allows you to categorize and follow feeds and read articles right in the terminal. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> { lib, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "goread"; version = "1.6.5"; src = fetchFromGitHub { owner = "TypicalAM"; repo = "goread"; rev = "v${version}"; hash = "sha256-SRVXcdgtRpWqvO28CnUcx40nFJnG+Hd94Ezgaj5xK6A="; }; vendorHash = "sha256-/kxEnw8l9S7WNMcPh1x7xqiQ3L61DSn6DCIvJlyrip0="; env.TEST_OFFLINE_ONLY = 1; meta = { description = "Beautiful program to read your RSS/Atom feeds right in the terminal"; homepage = "https://github.com/TypicalAM/goread"; changelog = "https://github.com/TypicalAM/goread/releases/tag/v${version}"; license = lib.licenses.gpl3Plus; mainProgram = "goread"; maintainers = with lib.maintainers; [ schnow265 ]; }; } </ins>


Question:
Klee installation returns the following error: Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.

<del> { lib, stdenv, cmake, boost, bison, flex, fetchFromGitHub, perl , python3, python3Packages, zlib, minisat, cryptominisat }: </del> <ins> { lib , stdenv , cmake , boost , bison , flex , fetchFromGitHub , fetchpatch , perl , python3 , zlib , minisat , cryptominisat }: </ins> stdenv.mkDerivation rec { pname = "stp";


Question:
Klee installation returns the following error: Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.

src = fetchFromGitHub { owner = "stp"; repo = "stp"; <del> rev    = version; sha256 = "1yg2v4wmswh1sigk47drwsxyayr472mf4i47lqmlcgn9hhbx1q87"; </del> <ins> rev = version; hash = "sha256-B+HQF4TJPkYrpodE4qo4JHvlu+a5HTJf1AFyXTnZ4vk="; </ins> }; patches = [ # Fix missing type declaration # due to undeterminisitic compilation # of circularly dependent headers ./stdint.patch <ins> # Python 3.12+ compatibility for build: https://github.com/stp/stp/pull/450 (fetchpatch { url = "https://github.com/stp/stp/commit/fb185479e760b6ff163512cb6c30ac9561aadc0e.patch"; hash = "sha256-guFgeWOrxRrxkU7kMvd5+nmML0rwLYW196m1usE2qiA="; }) </ins> ]; postPatch = ''


Question:
Klee installation returns the following error: Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.

sed -e '1i #include <cstdint>' -i include/stp/AST/ASTNode.h ''; <del> buildInputs = [ boost zlib minisat cryptominisat python3 ]; </del> <ins> buildInputs = [ boost zlib minisat cryptominisat python3 ]; </ins> nativeBuildInputs = [ cmake bison flex perl ]; preConfigure = '' <del> python_install_dir=$out/${python3Packages.python.sitePackages} </del> <ins> python_install_dir=$out/${python3.sitePackages} </ins> mkdir -p $python_install_dir cmakeFlagsArray=( $cmakeFlagsArray


Question:
Klee installation returns the following error: Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.

meta = with lib; { description = "Simple Theorem Prover"; <del> maintainers = with maintainers; [ McSinyx ]; </del> <ins> maintainers = with maintainers; [ McSinyx numinit ]; </ins> platforms = platforms.linux; license = licenses.mit; };


Question:
Klee installation returns the following error: Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.

--replace "#include <assert.h>" "" substituteInPlace lib/builtins/cpu_model${lib.optionalString (lib.versionAtLeast version "18") "/x86"}.c  --replace "#include <assert.h>" "" <del> '')); </del> <ins> '')) + lib.optionalString (lib.versionAtLeast release_version "13" && lib.versionOlder release_version "14") '' # https://github.com/llvm/llvm-project/blob/llvmorg-14.0.6/libcxx/utils/merge_archives.py # Seems to only be used in v13 though it's present in v12 and v14, and dropped in v15. substituteInPlace ../libcxx/utils/merge_archives.py  --replace-fail "import distutils.spawn" "from shutil import which as find_executable"  --replace-fail "distutils.spawn." "" ''; </ins> # Hack around weird upsream RPATH bug postInstall = lib.optionalString (stdenv.hostPlatform.isDarwin) ''


Question:
fails: see: cc: n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
(Fixed the title, my bad)
The current () tailscale builds fine for me on , but I gave it a try to be more "correct" anyway. I attempted to change to the following as a fix: However I seem to get the following error: I also tried running itself in the just to see what happens, and got an exec format error, presumably that's the cause of not having a completion in the first place.

wrapProgram $out/bin/tailscaled  --prefix PATH : ${lib.makeBinPath [ iproute2 iptables getent shadow ]}  --suffix PATH : ${lib.makeBinPath [ procps ]} <ins> sed -i -e "s#/usr/sbin#$out/bin#" -e "/^EnvironmentFile/d" ./cmd/tailscaled/tailscaled.service install -D -m0444 -t $out/lib/systemd/system ./cmd/tailscaled/tailscaled.service '' + lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' </ins> local INSTALL="$out/bin/tailscale" installShellCompletion --cmd tailscale  --bash <($out/bin/tailscale completion bash)  --fish <($out/bin/tailscale completion fish)  --zsh <($out/bin/tailscale completion zsh) <del> sed -i -e "s#/usr/sbin#$out/bin#" -e "/^EnvironmentFile/d" ./cmd/tailscaled/tailscaled.service install -D -m0444 -t $out/lib/systemd/system ./cmd/tailscaled/tailscaled.service </del> ''; passthru.tests = {


Question: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<del> { lib, fetchFromGitHub, python3Packages }: </del> <ins> { lib, fetchFromGitHub, python3Packages, gobject-introspection, wrapGAppsNoGuiHook }: </ins> python3Packages.buildPythonPackage rec { pname = "open-fprintd";


Question: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

sha256 = "sha256-uVFuwtsmR/9epoqot3lJ/5v5OuJjuRjL7FJF7oXNDzU="; }; <ins> nativeBuildInputs = [ wrapGAppsNoGuiHook gobject-introspection ]; </ins> propagatedBuildInputs = with python3Packages; [ dbus-python pygobject3 ]; checkInputs = with python3Packages; [ dbus-python ];


Question: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

--replace /usr/lib/open-fprintd "$out/lib/open-fprintd" ''; <ins> dontWrapGApps = true; makeWrapperArgs = [ "${gappsWrapperArgs[@]}" ]; </ins> postFixup = '' wrapPythonProgramsIn "$out/lib/open-fprintd" "$out $pythonPath" '';


Question: Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<del> { lib , python3 , fetchFromGitHub }: python3.pkgs.buildPythonApplication rec { pname = "flexget"; version = "3.11.39"; pyproject = true; # Fetch from GitHub in order to use `requirements.in` src = fetchFromGitHub { owner = "Flexget"; repo = "Flexget"; rev = "refs/tags/v${version}"; hash = "sha256-saNxs+Xdf6OTRRcMTceU8/ITcYzwtP8VqRKxsWyas+o="; }; postPatch = '' # remove dependency constraints but keep environment constraints sed 's/[~<>=][^;]*//' -i requirements.txt ''; build-system = with python3.pkgs; [ setuptools wheel ]; dependencies = with python3.pkgs; [ # See https://github.com/Flexget/Flexget/blob/master/requirements.txt apscheduler beautifulsoup4 click colorama commonmark feedparser guessit html5lib jinja2 jsonschema loguru more-itertools packaging pendulum psutil pynzb pyrsistent pyrss2gen python-dateutil pyyaml rebulk requests rich rpyc sqlalchemy typing-extensions # WebUI requirements cherrypy flask-compress flask-cors flask-login flask-restful flask-restx flask pyparsing werkzeug zxcvbn # Plugins requirements transmission-rpc ]; pythonImportsCheck = [ "flexget" "flexget.plugins.clients.transmission" ]; # ~400 failures doCheck = false; meta = with lib; { homepage = "https://flexget.com/"; changelog = "https://github.com/Flexget/Flexget/releases/tag/v${version}"; description = "Multipurpose automation tool for all of your media"; license = licenses.mit; maintainers = with maintainers; [ pbsds ]; }; } </del>


Question: Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> { lib , python3 , python311 , fetchFromGitHub }: let python = if (builtins.tryEval python3.pkgs.nose.outPath).success then python3 else python311; in python.pkgs.buildPythonApplication rec { pname = "flexget"; version = "3.11.41"; pyproject = true; # Fetch from GitHub in order to use `requirements.in` src = fetchFromGitHub { owner = "Flexget"; repo = "Flexget"; rev = "refs/tags/v${version}"; hash = "sha256-ZSqkD53fdDnKulVPgM9NWXVFXDR0sZ94mRyV1iKS87o="; }; postPatch = '' # remove dependency constraints but keep environment constraints sed 's/[~<>=][^;]*//' -i requirements.txt ''; build-system = with python.pkgs; [ setuptools wheel ]; dependencies = with python.pkgs; [ # See https://github.com/Flexget/Flexget/blob/master/pyproject.toml apscheduler beautifulsoup4 colorama feedparser guessit html5lib jinja2 jsonschema loguru psutil pynzb pyrss2gen python-dateutil pyyaml rebulk requests rich rpyc sqlalchemy # WebUI requirements cherrypy flask-compress flask-cors flask-login flask-restx flask packaging pyparsing werkzeug zxcvbn pendulum # Plugins requirements transmission-rpc qbittorrent-api deluge-client cloudscraper python-telegram-bot ]; pythonImportsCheck = [ "flexget" "flexget.api.core.authentication" "flexget.api.core.database" "flexget.api.core.plugins" "flexget.api.core.schema" "flexget.api.core.server" "flexget.api.core.tasks" "flexget.api.core.user" "flexget.components.thetvdb.api" "flexget.components.tmdb.api" "flexget.components.trakt.api" "flexget.components.tvmaze.api" "flexget.plugins.clients.aria2" "flexget.plugins.clients.deluge" "flexget.plugins.clients.nzbget" "flexget.plugins.clients.pyload" "flexget.plugins.clients.qbittorrent" "flexget.plugins.clients.rtorrent" "flexget.plugins.clients.transmission" "flexget.plugins.services.kodi_library" "flexget.plugins.services.myepisodes" "flexget.plugins.services.pogcal_acquired" ]; # ~400 failures doCheck = false; meta = with lib; { homepage = "https://flexget.com/"; changelog = "https://github.com/Flexget/Flexget/releases/tag/v${version}"; description = "Multipurpose automation tool for all of your media"; license = licenses.mit; maintainers = with maintainers; [ pbsds ]; }; } </ins>


Question: Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

flamp = callPackage ../applications/radio/flamp { }; <del> flexget = callPackage ../applications/networking/flexget { }; </del> fldigi = callPackage ../applications/radio/fldigi { hamlib = hamlib_4; };


Question: Package name: vkquake Latest released version: 1.22.3 Current version on the unstable channel: 1.22.3 Current version on the stable/release channel: 1.22.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

githubId = 4201956; name = "pongo1231"; }; <ins> PopeRigby = { name = "PopeRigby"; github = "poperigby"; githubId = 20866468; }; </ins> poptart = { email = "poptart@hosakacorp.net"; github = "terrorbyte";


Question: Package name: vkquake Latest released version: 1.22.3 Current version on the unstable channel: 1.22.3 Current version on the stable/release channel: 1.22.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<del> { lib, stdenv, fetchFromGitHub, makeWrapper , SDL2, gzip, libvorbis, libmad, vulkan-headers, vulkan-loader, moltenvk </del> <ins> { lib, stdenv, fetchFromGitHub, meson, ninja, glslang, pkg-config, flac, libopus, opusfile, makeWrapper, SDL2, gzip, libvorbis, libmad, vulkan-loader, moltenvk, </ins> }: stdenv.mkDerivation rec { pname = "vkquake"; <del> version = "1.22.3"; </del> <ins> version = "1.31.0"; </ins> src = fetchFromGitHub { owner = "Novum"; repo = "vkQuake"; rev = version; <del> sha256 = "sha256-+8DU1QT3Lgqf1AIReVnXQ2Lq6R6eBb8VjdkJfAn/Rtc="; </del> <ins> sha256 = "sha256-3xWwqN0EcwDMEhVxfLa0bMMClM+zELEFWzO/EJvPNs0="; </ins> }; <del> sourceRoot = "${src.name}/Quake"; </del> nativeBuildInputs = [ makeWrapper <del> vulkan-headers </del> <ins> glslang meson ninja pkg-config </ins> ]; buildInputs = [ <del> gzip </del> SDL2 <del> libvorbis </del> <ins> flac gzip </ins> libmad <ins> libopus libvorbis opusfile </ins> vulkan-loader ] ++ lib.optional stdenv.isDarwin moltenvk; buildFlags = [ "DO_USERDIRS=1" ]; <del> preInstall = '' mkdir -p "$out/bin" ''; makeFlags = [ "prefix=$(out) bindir=$(out)/bin" ]; </del> env = lib.optionalAttrs stdenv.isDarwin { NIX_CFLAGS_COMPILE = "-Wno-error=unused-but-set-variable"; }; <del> postFixup = '' wrapProgram $out/bin/vkquake  --prefix LD_LIBRARY_PATH : ${vulkan-loader}/lib </del> <ins> installPhase = '' mkdir -p "$out/bin" cp vkquake "$out/bin" </ins> ''; <del> enableParallelBuilding = true; </del> <ins> postFixup = '' patchelf $out/bin/vkquake  --add-rpath ${lib.makeLibraryPath [ vulkan-loader ]} ''; </ins> meta = with lib; { description = "Vulkan Quake port based on QuakeSpasm"; <del> mainProgram = "vkquake"; </del> homepage = src.meta.homepage; longDescription = '' vkQuake is a Quake 1 port using Vulkan instead of OpenGL for rendering.


Question: Package name: vkquake Latest released version: 1.22.3 Current version on the unstable channel: 1.22.3 Current version on the stable/release channel: 1.22.3 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

''; platforms = with platforms; linux ++ darwin; <del> maintainers = with maintainers; [ ylh ]; </del> <ins> maintainers = with maintainers; [ PopeRigby ylh ]; mainProgram = "vkquake"; </ins> }; }


Question:
Steps to reproduce the behavior: with One test is failing: only the relevant part Add any other context about the problem here. (note, I've set the project to the geospatial team, which should be enough to have it in the radar maybe?) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm currently bisecting to confirm my intuition that it is a dependency version change that is triggering this failure.
The first bad commit could be any of: Probably an upstream issue?

buildPythonPackage rec { pname = "momepy"; <del> version = "0.7.0"; </del> <ins> version = "0.8.0"; </ins> pyproject = true; disabled = pythonOlder "3.10";


Question:
Steps to reproduce the behavior: with One test is failing: only the relevant part Add any other context about the problem here. (note, I've set the project to the geospatial team, which should be enough to have it in the radar maybe?) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm currently bisecting to confirm my intuition that it is a dependency version change that is triggering this failure.
The first bad commit could be any of: Probably an upstream issue?

owner = "pysal"; repo = "momepy"; rev = "v${version}"; <del> hash = "sha256-HVp2a0z+5fbfkNSxnTfZPCgG2SJMlKX/zso14M18mCk="; </del> <ins> hash = "sha256-r2iGzk54MsrkYB3Sp9/B1QGKnvqPGUj3MQhk6yqIoXE="; </ins> }; build-system = [ setuptools-scm ];


Question:
Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in . For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.

kpurpose kdeclarative wrapGAppsHook3 <del> glaxnimate </del> ]; # Both MLT and FFMpeg paths must be set or Kdenlive will complain that it


Question:
Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in . For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.

mlt shared-mime-info libv4l <del> glaxnimate </del> ]; qtWrapperArgs = [


Question:
Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.

haveLibcxx = stdenv.cc.libcxx != null; isDarwinStatic = stdenv.hostPlatform.isDarwin && stdenv.hostPlatform.isStatic && lib.versionAtLeast release_version "16"; inherit (stdenv.hostPlatform) isMusl isAarch64; <ins> noSanitizers = !haveLibc || bareMetal || isMusl || isDarwinStatic; </ins> baseName = "compiler-rt"; pname = baseName + lib.optionalString (haveLibc) "-libc";


Question:
Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.

"-DCOMPILER_RT_BUILD_LIBFUZZER=OFF" ] ++ lib.optionals (useLLVM && haveLibc) [ "-DCOMPILER_RT_BUILD_SANITIZERS=ON" <del> ] ++ lib.optionals (!haveLibc || bareMetal || isMusl || isDarwinStatic) [ </del> <ins> ] ++ lib.optionals (noSanitizers) [ </ins> "-DCOMPILER_RT_BUILD_SANITIZERS=OFF" ] ++ lib.optionals ((useLLVM && !haveLibcxx) || !haveLibc || bareMetal || isMusl || isDarwinStatic) [ "-DCOMPILER_RT_BUILD_XRAY=OFF"


Question:
Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.

"-DCOMPILER_RT_ENABLE_IOS=OFF" ]) ++ lib.optionals (lib.versionAtLeast version "19" && stdenv.isDarwin && lib.versionOlder stdenv.hostPlatform.darwinMinVersion "10.13") [ "-DSANITIZER_MIN_OSX_VERSION=10.10" <ins> ]  ++ lib.optionals (noSanitizers && lib.versionAtLeast release_version "19") [ "-DCOMPILER_RT_BUILD_CTX_PROFILE=OFF" </ins> ]; outputs = [ "out" "dev" ];


Question:
It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them. It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source. In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
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 .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. →
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p

} <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {


Question:
It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them. It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source. In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
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 .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. →
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p

push @kernelModules, "kvm-intel" if hasCPUFeature "vmx"; push @kernelModules, "kvm-amd" if hasCPUFeature "svm"; <ins> push @attrs, "hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "AuthenticAMD"; push @attrs, "hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "GenuineIntel"; </ins> # Look at the PCI devices and add necessary modules.  Note that most # modules are auto-detected so we don't need to list them here.


Question: Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

{ lib <ins> , gccStdenv </ins> , stdenv , fetchurl , fetchpatch


Question: Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

}) # Fix detection of NEON (and armv6 build) : ./fix-neon-detection.patch <del> ]; </del> <ins> ] # CMake files require a bit of patching to support CMAKE_ASM_COMPILER. # Made by @RossComputerGuy for x265 v3.5. # https://mailman.videolan.org/pipermail/x265-devel/2024-July/013734.html ++ lib.optional (stdenv.cc.isClang && !stdenv.targetPlatform.isDarwin) ./fix-clang-asm.patch; </ins> postPatch = '' substituteInPlace cmake/Version.cmake


Question: Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

(mkFlag ppaSupport "ENABLE_PPA") (mkFlag vtuneSupport "ENABLE_VTUNE") (mkFlag werrorSupport "WARNINGS_AS_ERRORS") <del> ]; </del> <ins> ] # Clang does not support the endfunc directive so use GCC. ++ lib.optional (stdenv.cc.isClang && !stdenv.targetPlatform.isDarwin) "-DCMAKE_ASM_COMPILER=${gccStdenv.cc}/bin/${gccStdenv.cc.targetPrefix}gcc"; </ins> cmakeStaticLibFlags = [ "-DHIGH_BIT_DEPTH=ON"


Question: Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> diff --git a/CMakeLists.txt b/CMakeLists.txt index a407271b4..593628e0f 100755 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -310,7 +310,7 @@ if(GCC) endif() check_cxx_compiler_flag(-mstackrealign CC_HAS_STACK_REALIGN) if (CC_HAS_STACK_REALIGN) -        add_definitions(-mstackrealign) +        add_compile_options($<$<COMPILE_LANGUAGE:CXX>:-mstackrealign>) endif() # Disable exceptions. Reduce executable size, increase compability. check_cxx_compiler_flag(-fno-exceptions CC_HAS_FNO_EXCEPTIONS_FLAG) @@ -545,7 +545,7 @@ if((MSVC_IDE OR XCODE OR GCC) AND ENABLE_ASSEMBLY) list(APPEND ASM_OBJS ${ASM}.${SUFFIX}) add_custom_command( OUTPUT ${ASM}.${SUFFIX} -                COMMAND ${CMAKE_CXX_COMPILER} +                COMMAND ${CMAKE_ASM_COMPILER} ARGS ${ARM_ARGS} -c ${ASM_SRC} -o ${ASM}.${SUFFIX} DEPENDS ${ASM_SRC}) endforeach() diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt index 12b643ad5..876f3543d 100644 --- a/common/CMakeLists.txt +++ b/common/CMakeLists.txt @@ -16,6 +16,7 @@ endif(EXTRA_LIB) if(ENABLE_ASSEMBLY) set_source_files_properties(threading.cpp primitives.cpp pixel.cpp PROPERTIES COMPILE_FLAGS -DENABLE_ASSEMBLY=1) list(APPEND VFLAGS "-DENABLE_ASSEMBLY=1") +    enable_language(ASM) endif(ENABLE_ASSEMBLY) if(ENABLE_ASSEMBLY AND X86) </ins>


Question:
Package name: nuclear Latest released version: 0.6.31 Current version on the unstable channel: 0.6.30 Current version on the stable/release channel: 0.6.30 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Made a PR, would appreciate it if you tested it - I don't use nuclear very often at the moment.

<del> { appimageTools , lib , fetchurl }: let pname = "nuclear"; version = "0.6.30"; src = fetchurl { url = "https://github.com/nukeop/nuclear/releases/download/v${version}/${pname}-v${version}.AppImage"; hash = "sha256-he1uGC1M/nFcKpMM9JKY4oeexJcnzV0ZRxhTjtJz6xw="; }; appimageContents = appimageTools.extract { inherit pname version src; }; in appimageTools.wrapType2 { inherit pname version src; extraInstallCommands = '' install -m 444 -D ${appimageContents}/${pname}.desktop -t $out/share/applications substituteInPlace $out/share/applications/${pname}.desktop  --replace 'Exec=AppRun' 'Exec=${pname}' cp -r ${appimageContents}/usr/share/icons $out/share ''; meta = with lib; { description = "Streaming music player that finds free music for you"; homepage = "https://nuclear.js.org/"; license = licenses.agpl3Plus; maintainers = [ maintainers.NotAShelf ]; platforms = [ "x86_64-linux" ]; mainProgram = "nuclear"; }; } </del>


Question:
Package name: nuclear Latest released version: 0.6.31 Current version on the unstable channel: 0.6.30 Current version on the stable/release channel: 0.6.30 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Made a PR, would appreciate it if you tested it - I don't use nuclear very often at the moment.

<ins> { appimageTools, lib, fetchurl, }: let pname = "nuclear"; version = "0.6.31"; src = fetchurl { # Nuclear currenntly only publishes AppImage releases for x86_64, which is hardcoded in # the package name. We also hardcode the host arch in the release name, but should upstream # provide more arches, we should use stdenv.hostPlatform to determine the arch and choose # source URL accordingly. url = "https://github.com/nukeop/nuclear/releases/download/v${version}/${pname}-v${version}-x86_64.AppImage"; hash = "sha256-ezho69fDP4OiLpC8KNKc8OIZ++TX4GUinFB6o8MLx3I="; }; appimageContents = appimageTools.extract { inherit pname version src; }; in appimageTools.wrapType2 { inherit pname version src; extraInstallCommands = '' install -m 444 -D ${appimageContents}/${pname}.desktop -t $out/share/applications substituteInPlace $out/share/applications/${pname}.desktop  --replace-fail 'Exec=AppRun' 'Exec=${pname}' cp -r ${appimageContents}/usr/share/icons $out/share ''; meta = { description = "Streaming music player that finds free music for you"; homepage = "https://nuclear.js.org/"; license = lib.licenses.agpl3Plus; maintainers = [ lib.maintainers.NotAShelf ]; platforms = [ "x86_64-linux" ]; mainProgram = "nuclear"; }; } </ins>


Question:
Package name: nuclear Latest released version: 0.6.31 Current version on the unstable channel: 0.6.30 Current version on the stable/release channel: 0.6.30 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Made a PR, would appreciate it if you tested it - I don't use nuclear very often at the moment.

''; }; <del> nuclear = callPackage ../applications/audio/nuclear { }; </del> nuclei = callPackage ../tools/security/nuclei { }; nullmailer = callPackage ../servers/mail/nullmailer {