jiebi/CodeConvo huggingface dataset:
Change:
application. </para></listitem> </varlistentry> <ins> <varlistentry> <term><literal>kde</literal></term> <listitem><para>Use Qt settings from Plasma.</para></listitem> </varlistentry> </ins> </variablelist> ''; };

Discussion:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.
Change:
ninka = callPackage ../development/tools/misc/ninka { }; <del> nixnote2 = libsForQt514.callPackage ../applications/misc/nixnote2 { }; </del> <ins> nixnote2 = libsForQt5.callPackage ../applications/misc/nixnote2 { }; </ins> nodenv = callPackage ../development/tools/nodenv { };

Discussion:
libsForQt514.qt5.qtwebengine currently fails to build locally and on . The interessting line seems to be: The last successful build on hydra was linked to . After that it seems to fail (starting with ) Bisecting takes forever. I would hazard a guess that it has to do with and PR which broke some other packages as well. EDIT: EDIT2: The error seems to stem from the c++ upgrade. The error message is referenced e.g. here Steps to reproduce the behavior: nixpkgs master -build -A libsForQt514.qt5.qtwebengine . Build should succeed. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result.
It's most likely due to mixing gcc versions, as that's not 100% compatible in C++. qt514 (and qt512) get overridden to gcc10, whereas the default is gcc11. (For x86_64-linux; some others have other combinations.)
Closing since libsForQt514 was removed from master.
Change:
mate.mate-settings-daemon ]; <ins> patches = [ # look up keyboard shortcuts in system data dirs ./mate-control-center.keybindings-dir.patch ]; </ins> configureFlags = [ "--disable-update-mimedb" ]; <ins> preFixup = '' gappsWrapperArgs+=( # WM keyboard shortcuts --prefix XDG_DATA_DIRS : "${mate.marco}/share" ) ''; enableParallelBuilding = true; </ins> meta = with stdenv.lib; { description = "Utilities to configure the MATE desktop"; homepage = https://github.com/mate-desktop/mate-control-center;

Discussion:
The mate keybinding properties does not include window management actions, provided by the marco (the mate window manager) package. ! system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
<ins> { lib , stdenv , fetchFromGitHub , fetchpatch , cmake , pkg-config , wrapGAppsHook , gst_all_1 , libnotify , libayatana-appindicator }: stdenv.mkDerivation rec { pname = "alarm-clock-applet"; version = "0.4.1"; src = fetchFromGitHub { owner = pname; repo = "alarm-clock"; rev = version; hash = "sha256-10hkWWEsAUJnGeu35bR5d0RFKd9CKDZI7WGMzmEM3rI="; }; patches = [ (fetchpatch { url = "https://github.com/alarm-clock-applet/alarm-clock/commit/6a11003099660dfae0e3d5800f49880d3a26f5ec.patch"; hash = "sha256-NP1PlEw5AFWZgywvppIs2e+5EfMSPbU4Pq2tIfwODrQ="; }) (fetchpatch { url = "https://github.com/alarm-clock-applet/alarm-clock/commit/cbcf22fac5b45ab251ade2e7e993f422f33f926e.patch"; hash = "sha256-xKaaNfXsv9Ckwy73r1n93kOWIZ01fU5GDqYSQCch1Kc="; }) ]; nativeBuildInputs = [ cmake pkg-config wrapGAppsHook ]; buildInputs = [ gst_all_1.gstreamer libnotify libayatana-appindicator ]; cmakeFlags = [ # gconf is already deprecated "-DENABLE_GCONF_MIGRATION=OFF" ]; meta = with lib; { description = "A fully-featured alarm clock with an indicator"; homepage = "https://alarm-clock-applet.github.io"; license = licenses.gpl2Plus; maintainers = with maintainers; [ aleksana ]; platforms = platforms.linux; }; } </ins>

Discussion:
the package alarm clock applet has been removed via for reasons of being unmaintained and using components of the deprecated gnome2 stack. however the package has a new maintainer a of january 2023. and it has been ported to Gtk 3 this information and the code can be found on https://alarm-clock- the source-distribution goes under the name now. it is to be discussed wheter the new nix derivation should match that new name or keep the old name <!-- Describe the project a little: --Metadata homepage URL: https://alarm-clock- source URL: license: gpl2+ platforms: unix, linux, darwin, ...
Change:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Discussion:
Invoking is producing the following error message: is part of the package so it's just failing to locate it. I'm running on NixOS Unstable.
I believe this issue has been fixed and can be closed:

Travis has been giving build failures because of this: commit seems to be at fault here.. The reason I didn't just fix this this bug and push upstream is because there are two different ways to approach this and I'm not sure which the best course of action is. a) jfsrec removal was intentional, remove all references to jfsrec b) restore jfsrec Here is a listing of all current things pointing to jfsrec:
The jfsrec commit has already been reverted.
thanks for the info

nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources

In its builder, there's a command saying "Need libgcc until the llvm compiler-rt library is complete". It's from in 2011, so I'm inclined to think it's out of date and that the dependency on gcc is spurious. Is that true?
For context from #llvm on oftc:
covers , covers , the only thing I'm not sure about is the C runtime files (e.g. ), none of those packages seem to come with them (but maybe clang does it another way)
Actually some of the files come from glibc, but these ones come with gcc: crtprec32.o crtendS.o crtbeginS.o crtfastmath.o crtprec64.o crtbeginT.o crtprec80.o crtbegin.o crtend.o
This story is quite old, is this still true?
Closing because no reaction.
Change:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

Discussion:
Invoking is producing the following error message: is part of the package so it's just failing to locate it. I'm running on NixOS Unstable.
I believe this issue has been fixed and can be closed:

Travis has been giving build failures because of this: commit seems to be at fault here.. The reason I didn't just fix this this bug and push upstream is because there are two different ways to approach this and I'm not sure which the best course of action is. a) jfsrec removal was intentional, remove all references to jfsrec b) restore jfsrec Here is a listing of all current things pointing to jfsrec:
The jfsrec commit has already been reverted.
thanks for the info

nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources
Change:
# `contents = {object = ...; symlink = /init;}' is a typical # argument. <del> { stdenv, perl, cpio, contents, compressor, prepend, ubootTools </del> <ins> { stdenv, perl, cpio, contents, ubootTools , name ? "initrd" , compressor ? "gzip -9n" , prepend ? [] </ins> }: stdenv.mkDerivation rec { <del> name = "initrd"; </del> <ins> inherit name; </ins> builder = ./make-initrd.sh; makeUInitrd = stdenv.hostPlatform.platform.kernelTarget == "uImage";

Discussion:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.
Change:
let pname = "osu-lazer-bin"; <del> version = "2023.1130.0"; </del> <ins> version = "2023.1218.1"; </ins> src = { aarch64-darwin = fetchzip { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Apple.Silicon.zip"; <del> hash = "sha256-7lQVc517QEtQDdSF5FxR+kgw1TVpr8H3whzURelABIY="; </del> <ins> hash = "sha256-FSxXPvbHjLVKU2rlTY2iqIUZSjOPoTES8Bl8j/Ln+6w="; </ins> stripRoot = false; }; x86_64-darwin = fetchzip { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Intel.zip"; <del> hash = "sha256-BOpW8QP4TLKzdTDnjjT/t4k+3Q2w2MWA0IDnXH+/mBU="; </del> <ins> hash = "sha256-d6jumDva2LAmiixxD9RFiKdiuSv1yPVeX8OgNB7DYpM="; </ins> stripRoot = false; }; x86_64-linux = fetchurl { url = "https://github.com/ppy/osu/releases/download/${version}/osu.AppImage"; <del> hash = "sha256-dQuyKjCZaIl3uaI81qRMt5NzBxfmyROVbJrVAqzuZxg="; </del> <ins> hash = "sha256-xxWNLP5m/nxGutt/ogcDYcVaiFaesEvZpDdU/ndVRMs="; </ins> }; }.${stdenv.system} or (throw "${pname}-${version}: ${stdenv.system} is unsupported.");

Discussion:
Package name: osu-lazer Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023.815.0 Current version on the stable/release channel: 2023.511.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 Note for maintainers: Please tag this issue in your PR.
Change:
stdenv.mkDerivation rec { pname = "pjsip"; <del> version = "2.12"; </del> <ins> version = "2.12.1"; </ins> src = fetchFromGitHub { owner = pname; repo = "pjproject"; rev = version; <del> sha256 = "sha256-snp9+PlffU9Ay8o42PM8SqyP60hu9nozp457HM+0bM8="; </del> <ins> sha256 = "sha256-HIDL4xzzTu3irzrIOf8qSNCAvHGOMpi8EDeqZb8mMnc="; </ins> }; patches = [ ./fix-aarch64.patch <del> (fetchpatch { name = "CVE-2022-24764.patch"; url = "https://github.com/pjsip/pjproject/commit/560a1346f87aabe126509bb24930106dea292b00.patch"; sha256 = "1fy78v3clm0gby7qcq3ny6f7d7f4qnn01lkqq67bf2s85k2phisg"; }) </del> ]; buildInputs = [ openssl libsamplerate ]

Discussion:
, CVSSv3=9.8 (nixos-21.11, nixos-unstable) CVSSv3=7.5 (nixos-21.11, nixos-unstable) PJSIP is a free and open source multimedia communication library written in C language. In versions prior to and including 2.12 PJSIP there is a stack-buffer overflow vulnerability which only impacts PJSIP users who accept hashed digest credentials (credentials with datatype ). This issue has been patched in the master branch of the PJSIP repository and will be included with the next release. Users unable to upgrade need to check that the hashed digest data length must be equal to before passing to PJSIP. PJSIP is a free and open source multimedia communication library written in C. Versions 2.12 and prior contain a stack buffer overflow vulnerability that affects PJSUA2 users or users that call the API . Applications that do not use PJSUA2 and do not directly call or should not be affected. A patch is available on the branch of the GitHub repository. There are currently no known workarounds. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
Change:
(if stdenv.isLinux then '' find . -type f -perm -0100  -exec patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  <del> --set-rpath "${libedit}/lib:${ncurses.out}/lib:${gmp.out}/lib" {} ; </del> <ins> --set-rpath "${libedit}/lib:${ncurses5.out}/lib:${gmp.out}/lib" {} ; </ins> for prog in ld ar gcc strip ranlib; do find . -name "setup-config" -exec sed -i "s@/usr/bin/$prog@$(type -p $prog)@g" {} ; done

Discussion:
Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.
Change:
factorio = 241; emby = 242; sniproxy = 244; <ins> nzbget = 245; </ins> # When adding a gid, make sure it doesn't match an existing # uid. Users and groups with the same name should have equal

Discussion:
nzbget can not load shared library Use unstable channel Output: System: 16.09 Flounder Nix version: nix-env (Nix) 1.11.2
Have you tried to add zlib twice? when you use ldd, you will see that there is zlib twice.
Most certainly fixed upstream with - but not included in current stable.. 17.0 is still testing :clap:
Change:
buildInputs = with self; [nose] ++ optionals isPy27 [mock]; <del> propagatedBuildInputs = with self; [decorator pickleshare simplegeneric traitlets requests pexpect sqlite3]; </del> <ins> propagatedBuildInputs = with self; [decorator pickleshare simplegeneric traitlets readline requests pexpect sqlite3]; </ins> meta = { description = "IPython: Productive Interactive Computing";

Discussion:
I'm guessing this happened during 4.0 / jupyter upgrade. Running (from ) gives: Tab completion / readline doesn't work, and the prompt has no colours any more (I don't know whether this is due to missing or a separate issue). /cc
Thanks for your report. readline is indeed missing, causing both tab completion not to work and not showing any colors. I'll add the dependency.
Change:
configureFlags = [ ''--with-qt=${if enableGUI then "${qtbase}/lib" else "no"}'' ]; <ins> # workaround https://github.com/NixOS/nixpkgs/issues/155458 preBuild = lib.optionalString stdenv.cc.isClang '' rm version ''; </ins> enableParallelBuilding = true; dontWrapQtApps = true;

Discussion:
ttfautohint throws lots of c++ errors when building on macos This is on a 2021 M1 Max Macbook Pro Steps to reproduce the behavior: this nix-shell ++ errors will occur: It should not error Please run and paste the result.
Coincidentally, I've just filed
This does seem to fix it thankfully. Unfortunately until it is merged this means I'll have to build iosevka from source, which seems to take an age even on a powerful computer.
It looks like hasn't built for a while on darwin Hydra: because the build is too quiet. Perhaps, would work for you?
Change:
substituteInPlace src/reshade_effect_manager.cpp --replace "@out@" "$out" # Patching shebangs in the main `libdisplay-info` build patchShebangs subprojects/libdisplay-info/tool/gen-search-table.py <ins> # Replace gamescopereeaper with absolute path substituteInPlace src/Utils/Process.cpp --subst-var-by "gamescopereaper" "$out/bin/gamescopereaper" </ins> ''; mesonFlags = [

Discussion:
gamescope 3.14.23 seems to be packaged incorrectly, looks like this automatic upgrade missed some new runtime dependency, as the command now fails when run. Steps to reproduce the behavior: A window is displayed ! I am running on KDE Plasma 6.1, but this issue seems to happen on a standalone session as well. I'm also running Nvidia hardware, RTX 4090, on driver 555.58.02 Written logs: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Did a quick test to tryout the previous gamescope version, 3.14.22: Seems like the issue was definitely introduced in 3.14.23. !
Are you running it from nix-shell or something? should be in the package and thus on your PATH.
No, it's part of my system configuration flake. Sharing the relevant host file for context, is the only part of my configuration that is related to gamescope (): My configuration lives here: Some changes I haven't pushed yet. You can see by my that 'unstable' referes to nixos-unstable channel, and stable to the latest stable release, 24.05.
At the very least you can't mix unstable gamescope and stable WSI.
Thank you for pointing that out, I changed it to both be on "unstable" but the issue persists.
It looks to me like "gamescoperreaper" is a new binary that Valve recently with 3.14.23 that gamescope calls at some point. I was looking into their releases . Not a CPP developer so I am making a some assumptions about the nature of gamescopereaper and the layout of their project. Perhaps gamescopereaper needs to be packaged as part of the gamescope derivation? It doesn't look like it does that currently.
The binary is there in our gamescope package, though?
Agh, seems like adding though the was not enough to add into the path. I solved the issue by adding the package explicitly inside of .
I think the issue is with the module -- looks like it doesn't actually add the gamescope package into , but instead a wrapper.
I can confirm that adding the package through the gamescope module makes gamescope not work.

Adding it through other means such as does work.
Ok, so possible solutions: 1 - simple but less optimal: add a symlink below this line: 2 - complex but more Nix-friendly: find the exec portion in C code and patch it to find the executable in $out/bin/ 3 - alternative similar to (1): add $out/bin to wrapper's PATH (using makeWrapper argument) Good opportunity to open a PR with any of these solutions, tag the module and package's maintainers, and make the requested changes (which might be even a change of which strategy). Don't worry, the worst thing that could happen is your PR being closed to favorite a committer's PR, it's still seen as a good contribution (and good opportunity to learn).
Opened to attempt to resolve.
Change:
stdenv.mkDerivation rec { pname = "digimend"; <del> version = "10"; </del> <ins> version = "unstable-2023-05-03"; </ins> src = fetchFromGitHub { owner = "digimend"; repo = "digimend-kernel-drivers"; <del> rev = "v${version}"; sha256 = "0lifd6cx6aa6hcms4zn4hlla3alra08r0svj5x1l8nlsv0ydnl6i"; </del> <ins> rev = "eca6e1b701bffb80a293234a485ebf6b4bc85562"; hash = "sha256-0mjIUgHvbNcVQVzU3xzaloe5R41a4eknDhdhruJH+6c="; </ins> }; postPatch = ''

Discussion:
This looks similar: according to which the solution is getting the kernel built with or . Edit: just noticed that while the error looks similar, it's for kernel 5.15 so probably a different issue.
I also had this problem when updating from 22.11 to 23.05.
Thank you for fixing this,
Change:
<del> { lib , stdenv , fetchFromGitHub , cmake , gtest , openssl , zlib }: stdenv.mkDerivation rec { pname = "jesec-libtorrent"; version = "0.13.8-r3"; src = fetchFromGitHub { owner = "jesec"; repo = "libtorrent"; rev = "v${version}"; hash = "sha256-S3DOKzXkvU+ZJxfrxwLXCVBnepzmiZ+3iiQqz084BEk="; }; nativeBuildInputs = [ cmake ]; buildInputs = [ openssl zlib ]; doCheck = true; preCheck = '' export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}$PWD ''; checkInputs = [ gtest ]; meta = with lib; { homepage = "https://github.com/jesec/libtorrent"; description = "A BitTorrent library written in C++ for *nix, with focus on high performance and good code (jesec's fork)"; license = licenses.gpl2Plus; maintainers = with maintainers; [ winter AndersonTorres ]; platforms = platforms.linux; }; } </del>

Discussion:
jesec-libtorrent tests fail, making the build fail. Steps to reproduce the behavior: jesec-libtorrent fails, failing the build I expect it to build succesfully ! ! I'm building the package with the help of morph to deploy on a server, though this shouldn't really have an impact.
This happened between and . I'll bisect later, thanks for the heads up!
The test is expecting to be returned by , but is instead getting . I'm... really not sure how to move forward with this, short of disabling the test.
Next time copy-paste the error message.
Perhaps triggered by upgrading glibc from 2.33 to 2.34? (some change in getaddrinfo() behavior)
I ruled that out initially since I didn't see anything mentioned in the changelog about getaddrinfo. I'll give it a try, though.
This has been fixed by .
Change:
<del> --- a/12-feature-linux-systray-example.patch +++ b/12-feature-linux-systray-example.patch @@ -8,18 +8,15 @@ diff --git a/third_party/appindicator/Makefile b/third_party/appindicator/Makefi new file mode 100644 --- /dev/null +++ b/third_party/appindicator/Makefile -@@ -0,0 +1,34 @@ +@@ -0,0 +1,31 @@ +# Code from https://github.com/AyatanaIndicators/libayatana-appindicator +# and related repositories. +# See https://github.com/AyatanaIndicators/libayatana-appindicator/issues/46 for build instructions. +# You need: sudo aptitude install libdbusmenu-gtk3-dev + -+CFLAGS=`pkg-config --cflags gtk+-3.0 glib-2.0`  -+  -I/usr/include/libdbusmenu-glib-0.4/  -+  -I/usr/include/libdbusmenu-gtk3-0.4/  -+  -I/usr/include/glib-2.0 ++CFLAGS=`pkg-config --cflags gtk+-3.0 glib-2.0 dbusmenu-gtk3-0.4`  + -+LDFLAGS=`pkg-config --libs gtk+-3.0 glib-2.0` -ldbusmenu-glib -ldbusmenu-gtk3 ++LDFLAGS=`pkg-config --libs dbusmenu-gtk3-0.4` + +OBJECTS=betterbird-systray-icon.o  +  app-indicator.o  --- a/1790619-send-progress-width.patch +++ b/1790619-send-progress-width.patch @@ -31,6 +21,7 @@ scrolling="false"> <head> <title>&sendDialog.title;</title> +   <link rel="localization" href="branding/brand.ftl" /> +  <script defer="defer" src="chrome://messenger/content/dialogShadowDom.js"></script> <script defer="defer" src="chrome://messenger/content/messengercompose/sendProgress.js"></script> -  <script defer="defer" src="chrome://messenger/content/dialogShadowDom.js"></script> --- a/1777788-fix-dialog-size.patch +++ b/1777788-fix-dialog-size.patch @@ -22,6 +22,7 @@ diff --git a/mailnews/compose/content/sendProgress.xhtml b/mailnews/compose/cont scrolling="false"> <head> <title>&sendDialog.title;</title> +   <link rel="localization" href="branding/brand.ftl" /> <script defer="defer" src="chrome://messenger/content/dialogShadowDom.js"></script> <script defer="defer" src="chrome://messenger/content/messengercompose/sendProgress.js"></script> </head> </del>

Discussion:
Package name: betterbird Latest released version: 102.12.0-bb37 Current version on the unstable channel: 102.8.0-bb30 Current version on the stable/release channel: 102.8.0-bb30 Notify maintainers The package is outdated since a while. I hope it can be updated in the near feature. Thank you :) Note for maintainers: Please tag this issue in your PR.
see
Change:
jdk = jdk21; }; <del> clojure-lsp = callPackage ../development/tools/misc/clojure-lsp { }; </del> clooj = callPackage ../development/interpreters/clojure/clooj.nix { }; dhall = haskell.lib.compose.justStaticExecutables haskellPackages.dhall;

Discussion:
Hi folks, I saw that clojure-lsp was out of date I tried to build the new version (2024.04.22-11.50.26) Unfortunately after bumping the version and fixing the hashes, we have a build error. Specifically the version check that was recently is failing. Steps to reproduce the behavior: clojure-lsp with version (see ) Full build log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: