jiebi/CodeConvo huggingface dataset:
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.0 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: ,
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=5.9 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.3 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09) CVSSv3=5.9 (nixos-19.09) CVSSv3=5.5 (nixos-19.09) CVSSv3=5.3 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:
30.1 is also the default version in 20.03 ATM.
Code change:
rustPlatform.buildRustPackage rec { pname = "eww"; <del> version = "0.6.0"; </del> <ins> version = "0.6.0-unstable-2024-04-26"; </ins> src = fetchFromGitHub { owner = "elkowar"; repo = "eww"; <del> rev = "refs/tags/v${version}"; hash = "sha256-rzDnplFJNiHe+XbxbhZMEhPJMiJsmdVqtZxlxhzzpTk="; </del> <ins> # FIXME: change to a release tag once a new release is available # https://github.com/elkowar/eww/pull/1084 # using the revision to fix string truncation issue in eww config rev = "2c8811512460ce6cc75e021d8d081813647699dc"; hash = "sha256-eDOg5Ink3iWT/B1WpD9po5/UxS4DEaVO4NPIRyjSheM="; </ins> }; <del> cargoHash = "sha256-n9nd5E/VO+0BgkhrfQpeihlIkoVQRf6CMiPCK5opvvw="; </del> <ins> cargoHash = "sha256-ClnIW7HxbQcC85OyoMhBLFjVtdEUCOARuimfS4uRi+E="; </ins> <del> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </del> <ins> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </ins> buildInputs = [ gtk3

Related discussion:
text: After upgrading to eww 0.6.0 from unstable I've got problems showing some strings in some of my widgets, one that shows the hour and another the minutes using two digits each one, i.e. : "09 : 10". When using eww 0.6.0 the string shown is like this: "... : ..." In eww's github repo I can see that there is a commit after version 0.6.0: And cloning eww repo with that commit, compiling it and using a local eww executable the problem explained before disappears for me. There's also another problem, asking eww-0.6.0 for version number shows it's 0.5.0: unstable eww 0.6.0 some string truncation (I think this is the problem) see "..." where a two char string with the hour should appear. eww should work as expected. Cloning eww repo with latest commit after v0.6.0 was published solves the problem for me.
~The current package for eww is . How did you install 0.6.0 from nixpkgs?~ ~As for the outdated 0.5.0 version in nixpkgs, there are three maintainers for eww in nixpkgs so it probably will be updated shortly, perhaps fetching a commit with the solution to the string truncation problem you describe.~ EDIT: i was wrong, see comment below.
I got it installed today from unstable when upgrading my system: But, as you say, if I look for it into unstable () it shows version 0.5.0...I can't understand very well this...I'm relatively new to nixos. Ok, I'll wait then. Thanks for your interest in this.
Oh sorry, you're right! There is eww 0.6.0 in master, although it didn't make it into unstable yet. I built the package and, indeed, truncation is broken the version is incorrectly reported So the truncation was fixed, as you mention, after the release, and the reported version . That . If you can't wait, for it, i'd recommend you use the package output from the eww flake.
Code change:
rustPlatform.buildRustPackage rec { pname = "eww"; <del> version = "0.6.0"; </del> <ins> version = "0.6.0-unstable-2024-04-26"; </ins> src = fetchFromGitHub { owner = "elkowar"; repo = "eww"; <del> rev = "refs/tags/v${version}"; hash = "sha256-rzDnplFJNiHe+XbxbhZMEhPJMiJsmdVqtZxlxhzzpTk="; </del> <ins> # FIXME: change to a release tag once a new release is available # https://github.com/elkowar/eww/pull/1084 # using the revision to fix string truncation issue in eww config rev = "2c8811512460ce6cc75e021d8d081813647699dc"; hash = "sha256-eDOg5Ink3iWT/B1WpD9po5/UxS4DEaVO4NPIRyjSheM="; </ins> }; <del> cargoHash = "sha256-n9nd5E/VO+0BgkhrfQpeihlIkoVQRf6CMiPCK5opvvw="; </del> <ins> cargoHash = "sha256-ClnIW7HxbQcC85OyoMhBLFjVtdEUCOARuimfS4uRi+E="; </ins> <del> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </del> <ins> nativeBuildInputs = [ pkg-config wrapGAppsHook3 ]; </ins> buildInputs = [ gtk3

Related discussion:
text: I personally have been using it for a while and it works correctly (let me know if you need help, i'm on the matrix server with the same username). For now, I guess this issue can be closed because both are upstream bugs and the fixes will make it into a future release.
I think I we can backport the changes using patches. I'll send a PR.
Still I don't know how this 0.6.0 version was pulled from unstable into my system...I'm in my way learning nixos. Flakes! my never ending story :). I'll try to use it and if I have problems I'll try to ping you on the matrix server. Thx!
Since 0.6.0 reached unstable, of course, and you updated your channels/inputs. BTW the search can be out-of-date, so don't expect 100% accuracy from it.
Yep, that makes sense to me and seems to be the missing piece that confused me: how could it be possible that in the search appeared version 0.5 and I had installed v 0.6. thanks for clarifying it for me and for your work in Nixos.
Code change:
--replace '"/usr/local/bin/espanso"' '"${placeholder "out"}/bin/espanso"' ''; <ins> env = lib.optionalAttrs stdenv.cc.isClang { # Work around https://github.com/NixOS/nixpkgs/issues/166205. NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}"; }; </ins> # Some tests require networking doCheck = false;

Related discussion:
text: was looking to resume my work on espanso's (which has been somewhat impeded by ), and now I find that espanso no longer builds at all. As those issues haven't gotten much attention thought I'd reach out to to see if anyone can at least confirm (as my understanding is that the reproducibility on darwin can't be quite as good as NixOS -- especially when one ). Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you so much for the quick fix! I keep running into these issues on darwin, I really want / need to learn more so I can contribute back! Unfortunately I'm still getting a build error, which looks to be a sandbox issue: This seems to fix the issue: Could you take a look and if appropriate merge? Many thanks!
Code change:
kpurpose kdeclarative wrapGAppsHook3 <del> glaxnimate </del> ]; # Both MLT and FFMpeg paths must be set or Kdenlive will complain that it

Related discussion:
text: 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 .
Code change:
kpurpose kdeclarative wrapGAppsHook3 <del> glaxnimate </del> ]; # Both MLT and FFMpeg paths must be set or Kdenlive will complain that it

Related discussion:
text: 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.
Code change:
{ path = "/boot"; inherit (cfg) devices; inherit (efi) efiSysMountPoint; } ]; <ins> boot.loader.supportsInitrdSecrets = true; </ins> system.build.installBootLoader = let install-grub-pl = pkgs.substituteAll {

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
dotnetfx40 = callPackage ../development/libraries/dotnetfx40 { }; <del> dolphinEmu = callPackage ../misc/emulators/dolphin-emu { }; dolphinEmuMaster = qt5.callPackage ../misc/emulators/dolphin-emu/master.nix { </del> <ins> dolphin-emu = callPackage ../misc/emulators/dolphin-emu { }; dolphin-emu-beta = qt5.callPackage ../misc/emulators/dolphin-emu/master.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreBluetooth ForceFeedback IOKit OpenGL; };

Related discussion:
text: The derivation of creates a different .desktop file from the "official" one that has a different name. This is probably done in order to differentiate the two versions of in case someone installs both of them, but the problem is that while it creates a new one, it doesn't delete the "official" one. Also, the new .desktop file should also set , otherwise games don't launch in Wayland. (Though maybe it should be a wrapper instead) (And, unrelated, but why and not ?) The same also applies to PATH: there are both and (which is a link made by the derivation to in the folder). For consistency, there should be made a , otherwise if both dolphins are installed, one overwrites the other in PATH. Steps to reproduce the behavior: dolphinEmuMaster; an app launcher; are both the original "Dolphin Emulator" and the new "Dolphin Emulator (master)" that open the same app (the master one doesn't set `QTQPAPLATFORM=xcb). PATH there are both and (which is a link). There should only be the "Dolphin Emulator (master)" desktop file, and in PATH there should be only (and instead of ). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Code change:
generic = { version, sha256, eol ? false, extraVulnerabilities ? [] <del> }: stdenv.mkDerivation rec { </del> <ins> }: let major = lib.versions.major version; in stdenv.mkDerivation rec { </ins> pname = "nextcloud"; inherit version;

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 25.0.1 desired version: 25.0.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package -- maintainers: Please tag this issue in your PR.
Code change:
in stdenv.mkDerivation rec { pname = "cups-filters"; <del> version = "1.25.0"; </del> <ins> version = "1.25.6"; </ins> src = fetchurl { url = "https://openprinting.org/download/cups-filters/${pname}-${version}.tar.xz"; <del> sha256 = "1laiscq8yvynw862calkgbz9irrdkmd5l821q6a6wik1ifd186c1"; </del> <ins> sha256 = "1pgjk7j2p8m17pwynqd86hxgvz9lyb09ivx18lv6inmygij0pm4j"; </ins> }; nativeBuildInputs = [ pkgconfig makeWrapper ];

Related discussion:
text: Describe the bug fails to build on current master To Reproduce Steps to reproduce the behavior: a checkout of the current nixpkgs master Expected behavior Build succeeds Screenshots <details<summaryNot a screenshot, but build output </summary<p</p</detailsAdditional context The kind of error (not including a needed header) seems to be an upstream bug for me. Metadata Please run and paste the result. Maintainer information:
Fixed by upstream in See my PR
Code change:
fullName = "European Union Public License 1.1"; }; <ins> eupl12 = spdx { spdxId = "EUPL-1.2"; fullName = "European Union Public License 1.2"; }; </ins> fdl12 = spdx { spdxId = "GFDL-1.2-only"; fullName = "GNU Free Documentation License v1.2 only";

Related discussion:
text: Project description Client for authenticating to services using a German ID Metadata homepage URL: source URL: license: EUPL platforms: unix, linux, darwin, win32
Code change:
# Update this when adding the newest kernel major version! # And update linux_latest_for_hardened below if the patches are already available <del> linuxPackages_latest = linuxPackages_5_8; </del> <ins> linuxPackages_latest = linuxPackages_5_7; </ins> linux_latest = linuxPackages_latest.kernel; # Build the kernel modules for the some of the kernels.

Related discussion:
text: Describe the bug The is failing. I bisected this problem to “linux: Init 5.8”. The error message matches , which points to both a workaround of recompiling systemd against Linux 5.8 headers, and an upstream systemd patch (systemd/systemd) that’s in systemd 246 () and was backported in 245.7 as systemd/systemd-stable To Reproduce Steps to reproduce the behavior: Notify maintainers Cc Metadata Please run and paste the result. Maintainer information:
My PR wasn't merged, Linux 5.8 ended up being by someone else.
Linking for visibility: that PR was
The PR bumping systemd to 245.7 is at
Is it really helpful to send systemd 245.7 to given that will be unable to advance without it? Or are you thinking we also want to revert the bump in for now?
Maybe we should revert in master, and re-revert it in staging again. I let and decide about this, they've been doing the staging rounds.
Hey all, question: How do you spot which tests block the channels? I always track and every few days I notice nixos-unstable doesn't progress. When it don't I see an issue with the "channel blocker" label and I always wonder..
Click on the “Hydra job for tests” link and go to the “Constituents” tab.
Code change:
, libtiff, librsvg, gconf, libxml2, imagemagick, gnutls, libselinux , alsaLib, cairo, acl, gpm, AppKit, GSS, ImageIO, m17n_lib, libotf , jansson, harfbuzz <del> , libgccjit, targetPlatform, makeWrapper # native-comp params </del> <ins> , libgccjit, targetPlatform, makeWrapper, nukeReferences # native-comp params </ins> , systemd ? null , withX ? !stdenv.isDarwin , withNS ? stdenv.isDarwin

Related discussion:
text: Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
<ins> { stdenv, fetchFromGitHub }: let rev = "77686b3dfa20a34270cc52377c8e37c3a461e484"; version = stdenv.lib.strings.substring 0 7 rev; in stdenv.mkDerivation { name = "sbt-extras-${version}"; inherit version; src = fetchFromGitHub { owner = "paulp"; repo = "sbt-extras"; inherit rev; sha256 = "1bhqigm0clv3i1gvn4gsllywcnwfsa73xvqp8m7pbvn8g7i2ws6x"; }; dontBuild = true; installPhase = '' mkdir -p $out/bin install bin/sbt $out/bin ''; meta = { description = "A more featureful runner for sbt, the simple/scala/standard build tool"; homepage = https://github.com/paulp/sbt-extras; license = stdenv.lib.licenses.bsd3; maintainers = with stdenv.lib.maintainers; [ puffnfresh ]; platforms = stdenv.lib.platforms.unix; }; } </ins>

Related discussion:
text: I'm told a lot of people favor Paul Phillips' SBT wrapper over vanilla SBT. We probably ought to have a package for it.
Minus the parts where it auto-downloads sbt for you, I expect
Mmm, I don't know. Isn't it kind of important to be able to auto-download the appropriate version of sbt for each project?
Maybe? Seems hard to keep it Nix-flavored though, given that it wants to retrieve unhashed versions from the outside. I guess we could either patch it to call out to nix to download scala and sbt, or we could leave it alone and users can decide whether they care about Nix-like behavior here.
Code change:
maintainers = with lib.maintainers; [ dotlambda foo-dogsquared ]; platforms = lib.platforms.all; mainProgram = "warp"; <ins> broken = stdenv.isDarwin; </ins> }; }

Related discussion:
text: On an apple silicon: $ nix-env -iA I thought was supposed to add support for macos. <!-- 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.
Why don't you ping
I don't own a mac currently and I don't use the package, can't help you unfortunately.
Code change:
gmp libGL libGLU <ins> libSM </ins> mpfr proj python

Related discussion:
text: Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.