jiebi/CodeConvo huggingface dataset:
Change:
<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.

Discussion:
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]:
Change:
tree-sitter-nickel = lib.importJSON ./tree-sitter-nickel.json; tree-sitter-nix = lib.importJSON ./tree-sitter-nix.json; tree-sitter-norg = lib.importJSON ./tree-sitter-norg.json; <ins> tree-sitter-norg-meta = lib.importJSON ./tree-sitter-norg-meta.json; </ins> tree-sitter-nu = lib.importJSON ./tree-sitter-nu.json; tree-sitter-ocaml = lib.importJSON ./tree-sitter-ocaml.json; tree-sitter-org-nvim = lib.importJSON ./tree-sitter-org-nvim.json;

Discussion:
Project description <!-- Describe the project a little: --I've recently watched the videos on norg and found the plugin very code. At some point though I had an error because my system was missing this treesitter grammar: It doesn't seem packaged yet (I checked unstable). Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
, stdenv }: <del> let pythonRuntime = python3.withPackages(ps: [ ps.protobuf ]); in stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "nanopb"; <del> version = "0.4.1"; </del> <ins> version = "0.4.4"; </ins> src = fetchFromGitHub { owner = pname; repo = pname; rev = version; <del> sha256 = "16zxk42wzn519bpxf4578qn97k0h1cnbkvqqkqvka9sl0n3lz2dp"; </del> <ins> sha256 = "0nqfi1b0szjmm1z8wd3ks64h10jblv9ip01kfggxgz6qjjfwgvq7"; </ins> }; <del> nativeBuildInputs = [ cmake python3 ]; </del> <ins> nativeBuildInputs = [ cmake python3 python3.pkgs.wrapPython ]; pythonPath = with python3.pkgs; [ python3.pkgs.protobuf six ]; </ins> cmakeFlags = [ "-DBUILD_SHARED_LIBS=ON" # generate $out/lib/libprotobuf-nanopb.so{.0,}

Discussion:
, CVSSv3=7.5 (nixos-20.09) Scanned versions: nixos-20.09: . Cc
Change:
<del> { lib, stdenv, fetchurl, cups, busybox }: </del> <ins> { lib, stdenv, fetchurl, cups, rpm, cpio }: </ins> stdenv.mkDerivation rec { pname = "epson-inkjet-printer-escpr2"; <del> version = "1.1.49"; </del> <ins> version = "1.2.9"; </ins> src = fetchurl { # To find new versions, visit # http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX and search for # some printer like for instance "WF-7210" to get to the most recent # version. <del> url = "https://download3.ebz.epson.net/dsc/f/03/00/13/76/47/16f624dc1dfad10c3b4eb141c50c651a6360f69a/epson-inkjet-printer-escpr2-1.1.49-1lsb3.2.src.rpm"; sha256 = "sha256-WKDOpS7YL7J/IaNQcTjcoyXNXJGOuEexopdhYFubf50="; </del> <ins> url = "https://download3.ebz.epson.net/dsc/f/03/00/15/33/94/3bf10a30a1f8b5b91ddbafa4571c073878ec476b/epson-inkjet-printer-escpr2-1.2.9-1.src.rpm"; sha256 = "sha256-2smNBTMSqoKYsGUoBtIHS3Fwk9ODbiXaP7Dtq69FG9U="; </ins> }; unpackPhase = '' runHook preUnpack rpm2cpio $src | cpio -idmv <del> tar xvf ${pname}-${version}-1lsb3.2.tar.gz </del> <ins> tar xvf ${pname}-${version}-1.tar.gz </ins> cd ${pname}-${version} runHook postUnpack

Discussion:
When updating my NixOS I got the following error because of the printer driver: I expect the problem to be fixed so that I can continue to use my printer.
Change:
doCheck = true; <del> postInstall = '' install -D -t $out/lib/udev/rules.d 70-u2f.rules ''; </del> meta = with stdenv.lib; { homepage = "https://developers.yubico.com/libu2f-host"; description = "A C library and command-line tool that implements the host-side of the U2F protocol";

Discussion:
Describe the bug I recently noticed errors in logs around a missing group: To Reproduce Steps to reproduce the behavior: to on a NixOS system built from a recent commit logs with e.g Expected behavior No errors in logs. Additional context I'm not 100% sure what changed to trigger this error or how to best address it, but the config file does refer to a group, which commonly is present on other distros: The group is indeed not present on my NixOS system: The udev config seems to be fetched from the package. Metadata Maintainer information:
I see 2 ways of fixing this: a) just adding the group - this group is used in older Debian/Ubuntu distributions to indicate the device can be mounted using pmount b) removing from udev files as should be enough
A simple nixpkgs search shows there are more modules/packages using the group such as: and upstream packages tarballs used in: In we replace the the group with the group.
Since we don't include that group by default like Debian does, we should probably remove these references to plugdev. Users can always add their own custom udev rules if they want special group handling.
Looking at , seems to be the right way forward for most of these rules. We might just want to patch those to use it, and upstream these patches.
most of the affected udev files already have ; they just include the group for older Debian/Ubuntu distros. This is indeed obsolete method, so fix is indeed just a matter of removing this from the udev files.
According to removing breaks some non-systemd distros where nixpkgs maybe independently installed. What are your thoughts on removing the offending rule via ? Same approach can be taken with other . This would preserve backward compatibility with non NixOS systems.
If I'm not mistaken, this comment is not about nixpkgs on non-systemd distros, but other non-systemd distros in general. As written in , we probably can just ignore the warning for now, and remove the udev rule entirely once a systemd with has landed in nixpkgs.
This should be solved by , PTAL.
Change:
rr-unstable = rr; # Added 2022-09-17 rtl8723bs-firmware = throw "rtl8723bs-firmware was added in mainline kernel version 4.12"; # Added 2023-07-03 rtsp-simple-server = throw "rtsp-simple-server is rebranded as mediamtx, including default config path update"; # Added 2023-04-11 <ins> rtx = mise; # Added 2024-01-05 </ins> runCommandNoCC = runCommand; runCommandNoCCLocal = runCommandLocal; rxvt_unicode = rxvt-unicode-unwrapped; # Added 2020-02-02

Discussion:
(pronounced "meez") or "mise-en-place" is a development environment setup tool. The name refers to a French culinary phrase that roughly translates to "setup" or "put in place". The idea is that before one begins cooking, they should have all their utensils and ingredients ready to go in their place. Homepage URL: Source URL: License: MIT Platforms: Linux, Darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Inviting because I see you listed as maintainer for the current package :raised_hands:
Change:
avfs = callPackage ../tools/filesystems/avfs { }; <del> avldrums-lv2 = callPackage ../applications/audio/avldrums-lv2 { }; </del> aws-iam-authenticator = callPackage ../tools/security/aws-iam-authenticator {}; awscli = callPackage ../tools/admin/awscli { };

Discussion:
Recently a second version of avldrums got merged: We already had
cc
How many of these kind of plugins do we have? Does it make sense to put them in a package set?
What do you mean by these kind of plugins? LV2 in general? Might make sense. Not sure what the advantages and disadvantages are. avldrums? There is only one, but it's packaged twice. (just in case you missed that). :)
Yes, lv2 in general. We should do this
So by package set you mean just move them next to each other in all-packages? BTW, not all of the above are plugins: lv2: the library lv2bm: an lv2 benchmarker faust2lv2: a compiler to make lv2s with There are also more lv2 plugins in nixpkgs.
Unfortunately x42 stuff has two names, sometimes distantly related (x42-autotune is aka fat1.lv2). It seems that x42 names are better because they are more recognizable (as belonging to x42-), they are used in URLs (https://x42-) and as the names of packages (https://x42-). It would be useful to be able to find all packaged lv2 plugins at a glance. However, since some lv2 plugins come with a standalone application, sometimes it will be difficult to decide whether a package should be classified as a plugin or not. (I would classify x42-plugins as plugins despite their programs in bin/, but qmidiarp as a non-plugin despite its lib/lv2/.)
I propose the same approach as in Python. In case its plugins, put them in the plugin set. In case its only application, put them in top-level, if both, put them in plugins and offer a top-level reference.
I agree it would be useful to be able to find all packaged lv2 plugins at a glance.
OK. I would propose to name the package set audioPlugins and put the definitions in applications/audio/plugins/ . They should comprise DAW plugins (lv2, ladspa, dssi, vst), but not e.g. media player plugins (gst-plugins-good).

It does not seem useful to subdivide plugins further, because audio hosts support many types of plugins (Ardour and Carla support lv2, ladspa, vst) and some packages provide many types of plugins at once (zam-plugins has lv2, ladspa, vst; wolf-shaper has lv2, dssi, vst).
I'm not familiar with DAWs but that sounds reasonable! Maybe then so its clear its not about and such?
Change:
cd src/libXNVCtrl ''; <ins> makeFlags = [ "OUTPUTDIR=." # src/libXNVCtrl ]; </ins> installPhase = '' mkdir -p $out/lib mkdir -p $out/include/NVCtrl

Discussion:
With current unstable fails with the error messages: cc system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
cc
Change:
numpy ]; <ins> disabledTests = [ # Flaky -- socket collision "test_show_browser" ]; </ins> # remove scalene directory to prevent pytest import confusion preCheck = '' rm -rf scalene

Discussion:
Steps to reproduce the behavior: python312Packages.scalene Per , this failure is intentional due to some behaviour changes in setuptools. I'm not completely familiar with the change or setuptools overall, but the gist seems to be that setuptools now "prefers installed dependencies over vendored ones", whatever that means in this case. fails on () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
EDIT: Filed a PR to fix this in Scalene.
As soon as Emery has a fix on his end, we can bump the version number or apply the patch. Edit: Watch this PR
Updated in the original sources. We need Emery to cut a new release of Scalene as we're building from the published binary. (The scalene source build is complicated.)
FYI, I managed to make source builds work. That will make future bug responses quicker.
Change:
vdmfec = callPackage ../applications/backup/vdmfec {}; <ins> vk-bootstrap = callPackage ../development/libraries/vk-bootstrap { }; </ins> vk-cli = callPackage ../applications/networking/instant-messengers/vk-cli { }; vk-messenger = callPackage ../applications/networking/instant-messengers/vk-messenger {};

Discussion:
Project description A utility library that jump starts initialization of Vulkan. Helps writing simple boilerplate when dealing with Vulkan projects, helping beginners get into the ecosystem. Metadata homepage URL: (and possibly ) source URL: license: mit platforms: all (I think)
I didn't notice this but thank you so much for trying to package this for me ! Very much appreciated! :smile:
Change:
navidrome = callPackage ../servers/misc/navidrome {}; zettlr = callPackage ../applications/misc/zettlr { }; <ins> unifi-poller = callPackage ../servers/monitoring/unifi-poller {}; </ins> }

Discussion:
Project description Collect ALL UniFi Controller, Site, Device & Client Data Nixpkg currently has which is not developed anymore. Corresponding NixOS module may have to be updated. Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin
Change:
'' wrapPythonPrograms <del> # If a user installs a Python package, she probably also wants its # dependencies in the user environment (since Python modules don't # have something like an RPATH, so the only way to find the # dependencies is to have them in the PYTHONPATH variable). if test -e $out/nix-support/propagated-build-inputs; then ln -s $out/nix-support/propagated-build-inputs $out/nix-support/propagated-user-env-packages fi createBuildInputsPth build-inputs "$buildInputStrings" </del> <ins> # these should already be in $name.pth #createBuildInputsPth build-inputs "$buildInputStrings" </ins> for inputsfile in propagated-build-inputs propagated-build-native-inputs; do if test -e $out/nix-support/$inputsfile; then createBuildInputsPth $inputsfile "$(cat $out/nix-support/$inputsfile)"

Discussion:
We need to propagate the pth loader so packages using us process our pth files, but it makes no sense to have the pth loader itself in a pth file.
Change:
{ buildPythonPackage, fetchPypi, <ins> fetchpatch, </ins> cairosvg, pyphen, cffi,

Discussion:
Describe the bug Seems to be missing/incorrect fonts used during testing. To Reproduce Steps to reproduce the behavior: Expected behavior passed tests, successful build Additional context Attempted to add fonts via the FONTCONFIGFILE variable which did make a few of the font tests pass, but could not figure out how to make the rest pass. Looked at Cairo, but it seems 1.16.0 is exactly what is needed for weasyprint. Maintainer information:
could you please take a look at this?
In the meantime, does anyone have a workaround? I've tried the following, but the tests still run.
I think it's likely we're hitting this: Locally I tried using the branch with the Nix package and while it doesn't fully work yet it's past the point I was at before where it stopped during testing and just uses increasingly more memory.
Tried the linked patch instead and that seems to fix it. I'll get a PR going.
I was able to get it to build by commenting out the line (with a ).
The package builds on master, not sure what your comment is about.
Yeah, realized my comment was too late, now that it has been fixed.
Change:
in stdenv.mkDerivation rec { name = "flashplayer-${version}"; <del> version = "29.0.0.171"; </del> <ins> version = "30.0.0.113"; </ins> src = fetchurl { url = if debug then <del> "https://fpdownload.macromedia.com/pub/flashplayer/updaters/29/flash_player_npapi_linux_debug.${arch}.tar.gz" </del> <ins> "https://fpdownload.macromedia.com/pub/flashplayer/updaters/30/flash_player_npapi_linux_debug.${arch}.tar.gz" </ins> else "https://fpdownload.adobe.com/get/flashplayer/pdc/${version}/flash_player_npapi_linux.${arch}.tar.gz"; sha256 = if debug then if arch == "x86_64" then <del> "140galarr38lmfnd2chl2msvxizx96kdi000gbikir9xnd7bx1hc" </del> <ins> "1s4i9lmlydm8b373pi8jw5xf3fhcq75fgqyp7xd7aava8hay7x0j" </ins> else <del> "0wzmf12xrmyq8vqqyii932yx4nadrvkn2j9s86xcw67lb40xj5ig" </del> <ins> "1jhzvrn6f9zcynx3zq0vxidaps946aymm7l16c42p1f7q9s8msb4" </ins> else if arch == "x86_64" then <del> "17c57xgs0w71p4xsjw5an7dg484769wanq3kx86ppaqw8vqhnqc3" </del> <ins> "05dv4cn9i3zz5fmy16dxs9m1rpvlaih4gzsrf0q1zfjn46jbyw2l" </ins> else <del> "06pjbc9050fgi2njzf9vm6py7c22i6chw852rbm8flx3cmplw23b"; </del> <ins> "0pn159rzx6nb6lmkghccl0ynnc9ihfbr4rvfp14gm4n6jzbl6vg8"; </ins> }; nativeBuildInputs = [ unzip ];

Discussion:
Download of current version (29.0.0.171) fails with 404 NotFound.
Change:
''; }; <ins> bootstrapLlvmVersion = llvmPackages.llvm.version; </ins> bootstrapFiles = { sh      = "${build}/on-server/sh"; bzip2   = "${build}/on-server/bzip2";

Discussion:
is now failing, and blocking the unstable channel cc
Minimal reproducer: Bisected to Relevant snippet of cc
Oh I see, the stdenv setup logic is wrong when stdenv's cc version doesn't match the bootstrap tools because it tries to use a nonexistent include dir. The following patch should fix it but rebuilds the world, is there a clever way we can avoid rebuilds?
The bootstrap files contain some version of llvm, we could make this an explicit part of the tools. More generally, the test here is quite strict: it builds all the way to with new bootstrap tools but using current stdenv structure. When there are significant changes being made to the bootstrap tools that require stdenv changes this test makes it almost impossible. We've previously temporarily disabled this test to make such changes (). <details<summaryExplicit versions patch</summary</deatils
Yeah, the next bootstrap tools will depend on so it's somewhat expected that the stdenv test fails. I missed that build when testing.
Change:
<del> diff --git a/src/alpaca.in b/src/alpaca.in index cb883c8..a9822cc 100755 --- a/src/alpaca.in +++ b/src/alpaca.in @@ -35,7 +35,21 @@ locale.bindtextdomain('alpaca', localedir) locale.textdomain('alpaca') gettext.install('alpaca', localedir) +# Use the right XDG paths outside flatpak +def set_xdg_path(env, default): +    app_id = "com.jeffser.Alpaca" +    base = os.getenv(env) or os.path.expanduser(default) +    path = os.path.join(base, app_id) +    if not os.path.exists(path): +        os.makedirs(path) +    os.environ[env] = path +    return + if __name__ == '__main__': +    set_xdg_path("XDG_CONFIG_HOME", "~/.config") +    set_xdg_path("XDG_DATA_HOME", "~/.local/share") +    set_xdg_path("XDG_CACHE_HOME", "~/.cache") + import gi from gi.repository import Gio </del>

Discussion:
Alpaca does not use system theme configuration. (probably has something to do with flatpak) Affected: GTK4 theme GTK4 polarity Cursor theme Steps to reproduce the behavior: customized NixOS system, example: up and run nixpkgs#alpaca on nixos-unstable: App follows system theme settings: GTK4 Theme GTK4 Polarity Cursor theme ! <!-- 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]:
It works for me, with . Maybe there's something to do with your theme? (Is that some simple libadwaita stylesheets?) Also try setting .
didn't help, I will provide my gtk settings files. (they are symlinks to /nix/store btw) the theme is generated by stylix but under the hood it uses In any other situation I would assume it's a problem with my theme but this is the first time this happened to me on NixOS and I use a lot of gtk apps.
Yes, I've tried with , and it behaves the same. But there are probably other applications that behave similarly, because I set this environment variable a long time ago for similar reasons. I will try to read its source code later. (this may also be caused by me setting XDG paths)
Change:
<ins> #!/usr/bin/env nix-shell #! nix-shell -i bash -p nodePackages.node2nix set -euo pipefail node2nix  --input node-packages.json  --output node-packages.nix  --composition node-composition.nix  --node-env ../../development/node-packages/node-env.nix  ; </ins>

Discussion:
Project description Simple open-source self-hosted file sharing solution. Metadata homepage URL: source URL: license: bsd platforms: linux
I may have a go at this myself over the next few weeks but figured I'd start by posting it here.
I marked this as stale due to inactivity. &rarr;
Looks like you contributed this in :)
Change:
owner = "systemd"; repo = "systemd-stable"; rev = "v${version}"; <del> sha256 = "sha256-/vLu5aNW9qudZJhbisiq7Oteh5IP2hi71OEI2dZi0EA="; </del> <ins> sha256 = "sha256-46EM3sETMm5zAoLKtcGYCwmI7EYFeze/Pr4R/hwZL7Q="; </ins> }; # On major changes, or when otherwise required, you *must* reformat the patches,

Discussion:
A server crashed for unknown reason with the following message: Motherboard: Soldered CPU: Intel(R) Atom(TM) CPU C2550 @ 2.41GHz might be related. describes the issue in some detail and basically says that one needs to contact the hardware vendor. System: (NixOS: (Gorilla)
I'm not exactly sure why this on the nixpkgs issue-tracker. Do you think there is something in nixpkgs that needs fixing?

This site appears to be down, causing some latex package builds to fail.
Ah, I see there are already some todo comments about this. Is there anything I can do to help, or some workaround?
There is a workaround, at least, but let's not duplicate another thread:
Change:
{ stdenv, file, fetchurl, makeWrapper, autoPatchelfHook, jsoncpp, libpulseaudio }: let <del> versionMajor = "6.9"; versionMinor = "2"; </del> <ins> versionMajor = "6.10"; versionMinor = "12"; </ins> versionBuild_x86_64 = "1"; versionBuild_i686 = "1"; in stdenv.mkDerivation rec { pname = "nomachine-client"; version = "${versionMajor}.${versionMinor}"; src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://download.nomachine.com/download/${versionMajor}/Linux/nomachine_${version}_${versionBuild_x86_64}_x86_64.tar.gz"; <del> sha256 = "1z2pcfkzicjma4lxrj4qx43xyml993v7qyjd7k8xy8hw85fwnzii"; </del> <ins> sha256 = "17yb377ry7i7cmkb72xmhyqkfggv1ygqlz55ymvmrs7psbh7ql01"; </ins> } else if stdenv.hostPlatform.system == "i686-linux" then fetchurl { url = "https://download.nomachine.com/download/${versionMajor}/Linux/nomachine_${version}_${versionBuild_i686}_i686.tar.gz"; <del> sha256 = "03421s0k91c02ga9k6bdvixw71brlgi13q82cinnfayg3fhb0rb6"; </del> <ins> sha256 = "0k6dspmwdkm0zf0c2zqlqy0jya8qgsg90wwv9wa12fn4chp66gqg"; </ins> } else throw "NoMachine client is not supported on ${stdenv.hostPlatform.system}"; postUnpack = '' mv $(find . -type f -name nxclient.tar.gz) . mv $(find . -type f -name nxplayer.tar.gz) .

Discussion:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)