jiebi/CodeConvo huggingface dataset:
Change:
I am getting following error after a channel update: How can I help debug this issue? FWIW:
That package is trying to use which only became available with nix-1.10, so you need to upgrade it to evaluate it.
See
Thanks for the quick tip, it works now :+1:
This went to release-15.09: Should really nixpkgs 15.09 require nix 1.10? Wasn't this intended for master alone?
I've reverted it on the 15.09 branch, turns out it wasn't actually needed.

Discussion:
{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Change:
Maybe would be nice to automatically remove all those /usr/share/icons/*/icon- files during build process? In other case always will be packages when someones forgot to remove it. What do you think?
We do that, but you need to depend on the hicolor icon theme. I'll fix these packages.
oh ok, I see. If I find any of those I'll fix as well, thanks for quick response and fix.
Thanks for reporting these :-)

Discussion:
{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Change:
I've hit the same bug as described in The root of the problem seems to be missing configuration file which should be placed somewhere and made accessible by . It is used by, for example, in Emacs. cc
cc
I'm just getting this warning: Otherwise the output seems normal to me, but I've never really used the utility.
Oh, I see, is still a problem, as it used to be in Debian.
Actually, that config file is provided by package, so if I include it in , it works fine even with . Still, it's a bit confusing that the core provides binary but doesn't fully support it.
I currently can't see a simple way how to improve that.
I am not able to use on because it does not accept the option . In the command line I get: Is it related to this issue, or should I report a new issue?
cc When explicitly adding to there are checksum errors. The following patch fixes it for me: With that, does not give the error anymore.
Oh, no, they're updating files in-place on the only mirror. Many of them won't download anymore :angry:
Better discuss the mirroring stuff at this thread:
triage: this might have been fixed in the meantime, is that so?
it's still necessary to explicitly add the package, otherwise the problem persists.
Could anyone, please, provide steps to reproduce?
The "chktex -v" works for me, I have installed with .
works in but not .
This issue still persists as of today under the tetex scheme. the addition of the chktex package is mandatory to not get this error. I was getting this error in emacs: chktex: WARNING -- Could not find global resource file. chktex: ERROR -- Illegal verbosity level. I didn't thought that this was a NixOS related issue so this thread was quite hard to stumble upon.
I can't reproduce:
I guess I forgot . If I include that then it just gives "chktex: command not found". So how do I trigger the issue?

Discussion:
configureFlags = common.configureFlags ++ [ "--without-x" ] # disable xdvik and xpdfopen ++ map (what: "--disable-${what}") ([ <ins> "chktex" </ins> "dvisvgm" "dvipng" # ghostscript dependency "luatex" "luajittex" "mp" "pmp" "upmp" "mf" # cairo would bring in X and more "xetex" "bibtexu" "bibtex8" "bibtex-x" "upmendex" # ICU isn't small

}; <ins> chktex = stdenv.mkDerivation { pname = "texlive-chktex.bin"; inherit version; inherit (common) src; nativeBuildInputs = [ pkgconfig ]; buildInputs = [ core/*kpathsea*/ ]; preConfigure = "cd texk/chktex"; configureFlags = common.configureFlags ++ [ "--with-system-kpathsea" ]; enableParallelBuilding = true; }; </ins> dvisvgm = stdenv.mkDerivation { pname = "texlive-dvisvgm.bin"; inherit version;
Change:
This is fixed by . Can this be merged to release-15.09 as well? As it stands, cannot be used.
Pushed as .

Discussion:
{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Change:
Describe the bug The nix install of clojure causes issues with certain workflows. For example Expected behavior I would expect clj new to complete successfully, as per the brew equivalent: Additional context I noticed that symlinked from to seemed to fix the issue; so I suspect something problematic around here: (maybe) Notify maintainers Metadata Please run and paste the result. Maintainer information:
Seems like (or as it was previously named) was never in the right location. Thanks for the spot and the fix!
Ah no problem. Thank you for the speedy response!

Discussion:
makeWrapper ]; <ins> # See https://github.com/clojure/brew-install/blob/1.10.1/src/main/resources/clojure/install/linux-install.sh </ins> installPhase = let binPath = stdenv.lib.makeBinPath [ rlwrap jdk ]; in '' <del> mkdir -p $out/libexec cp clojure-tools-${version}.jar $out/libexec cp example-deps.edn $out cp deps.edn $out cp exec.jar $out </del> <ins> clojure_lib_dir=$out bin_dir=$out/bin echo "Installing libs into $clojure_lib_dir" install -Dm644 deps.edn "$clojure_lib_dir/deps.edn" install -Dm644 example-deps.edn "$clojure_lib_dir/example-deps.edn" install -Dm644 exec.jar "$clojure_lib_dir/libexec/exec.jar" install -Dm644 clojure-tools-${version}.jar "$clojure_lib_dir/libexec/clojure-tools-${version}.jar" echo "Installing clojure and clj into $bin_dir" </ins> substituteInPlace clojure --replace PREFIX $out <ins> install -Dm755 clojure "$bin_dir/clojure" install -Dm755 clj "$bin_dir/clj" </ins> <del> install -Dt $out/bin clj clojure wrapProgram $out/bin/clj --prefix PATH : $out/bin:${binPath} wrapProgram $out/bin/clojure --prefix PATH : $out/bin:${binPath} </del> <ins> wrapProgram $bin_dir/clojure --prefix PATH : $out/bin:${binPath} wrapProgram $bin_dir/clj --prefix PATH : $out/bin:${binPath} </ins> installManPage clj.1 clojure.1 '';
Change:
Describe the bug A clear and concise description of what the bug is. Tracking issue for srcs that can no longer be built with . Having these around isn't critical but it creates dependence on and it is not certain that it will keep around all srcs it once fetched.
While reviewing I found a few:
Thanks for the heads-up I found a fix for x32-edit and m32-edit and I'll do a PR for them asap. (ie when I have a clean git state in my $NIXPKGS dir) For hybridreverb2 I did not find the exact cause of problem though. ` complains: When I look into the , there is a pointer to , but I don't understand why nix-env tries to download a non-existing reference. I looked in various places for the 78ae... string, but didn't find it: nixpkgs, hybridreverb2, JUCE. Any pointers on why it tries to download this specific version of JUCE? PS: At first I thought it was an upstream problem, that had occured before, so I commented on a, what I thought to be relevant, , but a regular git clone works just fine:
The broken hash comes from HybridReverb2 repo: Looks like they use their own JUCE fork and force pushed so the commit used by HR 2.1.1 has been garbage collected on GitHub.
Thanks, I've passed the info upstream, hoping they will fix the issue.
I marked this as stale due to inactivity. &rarr;

Discussion:
<del> { stdenv, fetchurl, lib, libX11, libXext, alsaLib, freetype, brand, type, version, homepage, sha256, ... }: </del> <ins> { stdenv, fetchurl, lib, libX11, libXext, alsaLib, freetype, brand, type, version, homepage, url, sha256, ... }: </ins> stdenv.mkDerivation rec { inherit type; baseName = "${type}-Edit"; name = "${lib.toLower baseName}-${version}"; src = fetchurl { <del> url = "http://downloads.music-group.com/software/behringer/${type}/${type}-Edit_LINUX_64bit_${version}.tar.gz"; </del> <ins> inherit url; </ins> inherit sha256; };

{ callPackage, ... } @ args: <del> callPackage ./generic.nix (args // { </del> <ins> callPackage ./generic.nix (args // rec { </ins> brand = "Midas"; type = "M32"; <del> version = "3.2"; sha256 = "1cds6qinz37086l6pmmgrzrxadygjr2z96sjjyznnai2wz4z2nrd"; homepage = "http://www.musictri.be/Categories/Midas/Mixers/Digital/M32/p/P0B3I/downloads"; </del> <ins> version = "4.1"; url = "https://mediadl.musictribe.com/download/software/midas_${type}/${type}-Edit_LINUX_64-Bit_${version}.tar.gz"; sha256 = "0aqhdrxqa49liyvbbw5x32kwk0h1spzvmizmdxklrfs64vvr9bvh"; homepage = "https://midasconsoles.com/midas/product?modelCode=P0B3I"; </ins> })

{ callPackage, ... } @ args: <del> callPackage ./generic.nix (args // { </del> <ins> callPackage ./generic.nix (args // rec { </ins> brand = "Behringer"; type = "X32"; <del> version = "3.2"; sha256 = "1lzmhd0sqnlzc0khpwm82sfi48qhv7rg153a57qjih7hhhy41mzk"; homepage = "http://www.musictri.be/Categories/Behringer/Mixers/Digital/X32/p/P0ASF/downloads"; </del> <ins> version = "4.1"; url = "https://mediadl.musictribe.com/download/software/behringer/${type}/${type}-Edit_LINUX_64-Bit_${version}.tar.gz"; sha256 = "0zsw7qfmcci87skkpq8vx5zxk35phn8y4byispvki9ascifnnb33"; homepage = "https://www.behringer.com/behringer/product?modelCode=P0ASF"; </ins> })
Change:
Describe the bug Building gst-plugins-bad-1.18.0 errors out on Darwin with: To Reproduce On master: Expected behavior should compile Additional context Version bump from 1.16.2 -1.18.0 in includes new dependencies libmicrodns and libva that might be incompatible for macOS Notify maintainers Metadata
has tags on the right so chances are that isn't true and that it works on Darwin. Could you try in there?
leads to continuing down this rabbit hole leads to libpciaccess is pulled in by libdrm, which is pulled in by libva, which is pulled in by gst-plugins-bad as mentioned above. Since the cited attribute is in I don't suppose it is feasible for Darwin.
Thanks, I hadn't found that override, that's what I needed to know. This might fix it, give it a try: PR
build continues as expected, yet leads to
gist of meson-
Probably needs in on Darwin, looking at:
so disabling v4l2codecs solved the problem. Complete diff:
just noticed your comment. Yes, indeed, that was the last piece. Thx.

Discussion:
soundtouch srtp fluidsynth <del> libva </del> libvdpau libwebp xvidcore

faac ] ++ optionals stdenv.isLinux [ bluez <ins> libva # vaapi requires libva -> libdrm -> libpciaccess, which is Linux-only in nixpkgs </ins> wayland wayland-protocols ] ++ optionals (!stdenv.isDarwin) [

"-Dwpe=disabled" # required `wpe-webkit` library not packaged in nixpkgs as of writing "-Dzxing=disabled" # required `zxing-cpp` library not packaged in nixpkgs as of writing ] <ins> ++ optionals (!stdenv.isLinux) [ "-Dva=disabled" # see comment on `libva` in `buildInputs` ] </ins> ++ optionals stdenv.isDarwin [ "-Dbluez=disabled" "-Dchromaprint=disabled"

"-Ddvb=disabled" "-Dfbdev=disabled" "-Duvch264=disabled" # requires gudev <ins> "-Dv4l2codecs=disabled" # requires gudev </ins> "-Dladspa=disabled" # requires lrdf "-Dwebrtc=disabled" # requires libnice, which as of writing doesn't work on Darwin in nixpkgs "-Dwildmidi=disabled" # see dependencies above
Change:
In found that the upgrade from gstreamer 0.16 to 0.18 broke : I think is a RaspberryPi specific file and pulled in via . I don't know though whether this could be build on general , and if yes, how to get , so some help is needed.
can be found in and , which appear to be identical packages.
And can/should that be as a general gstreamer dependency on aarch64?
I feel like it should be an optional dependency. I'll file a PR real quick

Discussion:
, mpg123 , twolame , gtkSupport ? false, gtk3 ? null <ins> , raspiCameraSupport ? false, libraspberrypi ? null </ins> , enableJack ? true, libjack2 , libXdamage , libXext

}: assert gtkSupport -> gtk3 != null; <ins> assert raspiCameraSupport -> ((libraspberrypi != null) && stdenv.isLinux && stdenv.isAarch64); </ins> let inherit (stdenv.lib) optionals;

xorg.libXfixes xorg.libXdamage wavpack <ins> ] ++ optionals raspiCameraSupport [ libraspberrypi </ins> ] ++ optionals gtkSupport [ # for gtksink gtk3

"-Dv4l2=disabled" # Linux-only "-Dximagesrc=disabled" # Linux-only "-Dpulse=disabled" # TODO check if we can keep this enabled <del> ] ++ optionals (!(stdenv.isLinux && stdenv.hostPlatform.isAarch64)) [ "-Drpicamsrc=disabled" # only works on Linux aarch64, see https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/428c9b60532917c0ac49c9d48b15bdcd00a1370b/sys/rpicamsrc/meson.build#L10 </del> <ins> ] ++ optionals (!raspiCameraSupport) [ "-Drpicamsrc=disabled" </ins> ]; postPatch = ''
Change:
nixos 16.03 nix-env -i amarok :( (I'm not using kde, I'm using xfce+gtk)
(triage) still missing?
Still the case on 18.09pre140958.
ping maintainer
Amarok for Qt4/KDE4 was dropped some time ago (despite there being a recent release) so are you seeing this with the qt4 or the qt5 version?
(triage) still an issue at
Missing from where exactly? It's working here.
This is how amarok looks for me: ! I believe there should be some icons there. The icon in the system tray is also missing. (Tested with awesome wm.)
That's not right. On KDE however, it's fine. I will take a look at this but I cannot promise you when.
Still an issue at any chance for you to look into this?
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 .
I haven't been using amarok in ages - is this still a problem for you on 20.03 ?
Never used Amarok myself. One from nixpkgs unstable seems to grow a couple of icons but most are still missing. I don't use KDE, so that might be the reason. !
So it's expecting to find the icons in the global environment - it's basically an impurity. I'm realistically not going to be working on this but it's very much a legit issue.
I marked this as stale due to inactivity. &rarr;
Please revisit this again. !
Still no icons on non-KDE (this time EXWM). what DE/WM do you use? !
Apologies. I didn't see part. I'm on KDE right now. Looking through stale issues.
thank you for reviewing stale issues! I can confirm issue still exists. It's little better on latest unstable, there are some icons like on screenshot.
Installing the package fixed this for me on unstable.
I marked this as stale due to inactivity. &rarr;

Discussion:
, extra-cmake-modules, kdoctools , qca-qt5, qjson, qtquickcontrols2, qtscript, qtwebengine , karchive, kcmutils, kconfig, kdnssd, kguiaddons, kinit, kirigami2, knewstuff, knotifyconfig, ktexteditor, kwindowsystem <del> , fftw, phonon, plasma-framework, threadweaver </del> <ins> , fftw, phonon, plasma-framework, threadweaver, breeze-icons </ins> , curl, ffmpeg, gdk-pixbuf, libaio, liblastfm, libmtp, loudmouth, lzo, lz4, mysql57, pcre, snappy, taglib, taglib_extras }:

karchive kcmutils kconfig kdnssd kguiaddons kinit kirigami2 knewstuff knotifyconfig ktexteditor kwindowsystem phonon plasma-framework threadweaver curl fftw ffmpeg gdk-pixbuf libaio liblastfm libmtp loudmouth lz4 lzo mysql57.server mysql57.server.static <del> pcre snappy taglib taglib_extras </del> <ins> pcre snappy taglib taglib_extras breeze-icons </ins> ]; enableParallelBuilding = true;
Change:
Describe the bug Fixed upstream in . Running results in the following output from Bash: This problem prevents from copying keys to the remote system. To Reproduce Ensure you've got an SSH keypair, then attempt to copy it to a remote system with : Expected behavior I would expect to exit with status and without issuing any error output. Notify maintainers Ping -- happy to submit a PR for this, though I'm not sure about the best approach. It looks like hasn't landed in an OpenSSH release yet; the Arch Linux folks and have . Metadata
Closing as this appears to have been fixed with and backported to 20.09 in , please comment if something is still missing.

Discussion:
./dont_create_privsep_path.patch ./ssh-keysign.patch <ins> # See https://github.com/openssh/openssh-portable/pull/206 ./ssh-copy-id-fix-eof.patch </ins> ] ++ optional withGssapiPatches (assert withKerberos; gssapiPatch);

<ins> diff --git a/contrib/ssh-copy-id b/contrib/ssh-copy-id index 392f64f..a769077 100644 --- a/contrib/ssh-copy-id +++ b/contrib/ssh-copy-id @@ -247,7 +247,7 @@ installkeys_sh() { #    the -z `tail ...` checks for a trailing newline. The echo adds one if was missing #    the cat adds the keys we're getting via STDIN #    and if available restorecon is used to restore the SELinux context -  INSTALLKEYS_SH=$(tr 'tn' ' ' <<-EOF) +  INSTALLKEYS_SH=$(tr 'tn' ' ' <<-EOF cd; umask 077; mkdir -p $(dirname "${AUTH_KEY_FILE}") && @@ -258,6 +258,7 @@ installkeys_sh() { restorecon -F .ssh ${AUTH_KEY_FILE}; fi EOF +  ) # to defend against quirky remote shells: use 'exec sh -c' to get POSIX; printf "exec sh -c '%s'" "${INSTALLKEYS_SH}" </ins>
Change:
Describe the bug From This currently breaks at least mercurial and haskell-language-server. Notify maintainers
Title says , Hydra says , me trying to reproduce it says . FYI it works on .
Sorry for the wrong link. I blame hydra ui. But it is broken on master. This is the same build from : It is broken there and will be broken on nixos-unstable as soon as the channel gets bumped far enough, I guess. I can reproduce the issue locally on the master branch.
This problem will be solved by .
well, it doesn't fix the underlying problem. Just removes it. I tried building dulwich from source, but it doesn't seem to fix the issue. At the beginning of the tests, it mentions "there may be some abi incompatibility" then proceeds to segfault. But I couldn't even locate where the module was coming from.
Uh, yeah, right. That's what I meant of course.
did git bisect to find offending commit:
I still run into this problem on . Was the "fix" reverted again?

Discussion:
buildPythonPackage rec { pname = "greenlet"; <del> version = "0.4.17"; </del> <ins> version = "0.4.16"; </ins> disabled = isPyPy;  # builtin for pypy src = fetchPypi { inherit pname version; <del> sha256 = "41d8835c69a78de718e466dd0e6bfd4b46125f21a67c3ff6d76d8d8059868d6b"; </del> <ins> sha256 = "6e06eac722676797e8fce4adb8ad3dc57a1bb3adfb0dd3fdf8306c055a38456c"; </ins> }; propagatedBuildInputs = [ six ];
Change:
Describe the bug There appears to be a bug in the latest microcode from Intel that causes the XPS 13 9310 (and possibly other Tiger Lake machines) to freeze right after initrd with heavy graphical glitching presented on the screen. You can find the main bug report here The last comment appears to be an administrator: Perhaps this is taken to mean that Intel advise rolling back to the previous version until a new patched version is released? Perhaps it's worth reverting this commit temporarily? If not, perhaps someone can offer some advice on how NixOS users on XPS 9310 can patch their file to switch back to the previous version? I'm still getting my head around Nix and it's not obvious to me what the best way to achieve this would be. To Reproduce Run on the unstable nixos channel on a Dell XPS 13 9310 and run . Reboot into a glitchy screen. To get back to a usable state, reboot once more but select the previously working generation from the nixos generation menu. Expected behavior Boot into NixOS smoothly on Dell XPS 13 9310. Additional context I'm on a mission to get the XPS 13 9310 working nicely with NixOS, and land the necessary patches in nixos/nixos-hardware. You can follow along This bug was an unexpected regression that caught me off guard a few days ago while attempting to update my system while trying out new kernel patches to get wi-fi working. Notify maintainers cc as you are listed in the package cc as you made the aforementioned commit updating the version.
It looks like this is the commit the administrator is referring to that removes the update here
Rather than revert, I'll submit a PR that updates the package to point to the aforementioned Intel commit that supposedly removes the culprit microcode.
Thanks for the report. Can you testdrive ?

Discussion:
stdenv.mkDerivation rec { pname = "microcode-intel"; <del> version = "20201112"; </del> <ins> version = "20201118"; </ins> src = fetchFromGitHub { owner = "intel"; repo = "Intel-Linux-Processor-Microcode-Data-Files"; rev = "microcode-${version}"; <del> sha256 = "104l3py5z6405wpa2fscqpc5r9dgrf1ckaf27hrswivi32gvp7f2"; </del> <ins> sha256 = "1xs3f2rbfqnpz9qs7a1kl363qdyb8fybmmyd37v573clqf7l4lgg"; </ins> }; nativeBuildInputs = [ iucode-tool libarchive ];
Change:
Describe the bug The KDE Wacom configuration module is not working, showing "The shared library was not found": To Reproduce Steps to reproduce the behavior: KDE KDE system settings Expected behavior The configuration module should work Screenshots ! Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
can confirm ! system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: (was not mentioned before)
not sure if this is related to
This is still be a problem on 20.09
According to strace, the missing library file is either or . The latter is provided by , so it somehow needs to be made discoverable in the environment of kcmshell5.
Running into same problem now on 20.09.
Just to clarify, does just need backporting to 20.09, or are people still experiencing issues on master after was merged?
I think it just needs backporting, but I'm not yet familiar enough with NixOS to say for sure. I just upgraded my system to unstable and is working as expected (which I'm assuming is because of ). !
I marked this as stale due to inactivity. &rarr;
There was a PR to backport it to 20.09, but nobody reviewed it and it was closed when 20.09 went end-of-life, so I'm assuming everybody using kcm-wacomtablet is now happily running 21.05 or unstable and we can close this.
Yes, I can confirm it is working again in 21.05.

Discussion:
<del> { lib, mkDerivation, fetchurl, extra-cmake-modules, qtx11extras, </del> <ins> { lib, mkDerivation, fetchurl, fetchpatch, extra-cmake-modules, qtx11extras, </ins> plasma-workspace, libwacom, xf86_input_wacom }:

url = "mirror://kde/stable/${pname}/${version}/${pname}-${version}.tar.xz"; sha256 = "197pwpl87gqlnza36bp68jvw8ww25znk08acmi8bpz7n84xfc368"; }; <ins> patches = [ (fetchpatch { url = "https://invent.kde.org/system/wacomtablet/commit/4f73ff02b3efd5e8728b18fcf1067eca166704ee.patch"; sha256 = "0185gbh1vywfz8a3wnvncmzdk0dd189my4bzimkbh85rlrqq2nf8"; }) ]; </ins> nativeBuildInputs = [ extra-cmake-modules ]; buildInputs = [

This module implements a GUI for the Wacom Linux Drivers and extends it with profile support to handle different button / pen layouts per profile. ''; <del> homepage = "https://cgit.kde.org/wacomtablet.git/about/"; </del> <ins> homepage = "https://invent.kde.org/system/wacomtablet"; </ins> license = lib.licenses.gpl2; maintainers = [ lib.maintainers.Thra11 ]; platforms = lib.platforms.linux;

vttest = callPackage ../tools/misc/vttest { }; <del> wacomtablet = libsForQt514.callPackage ../tools/misc/wacomtablet { }; </del> <ins> wacomtablet = libsForQt5.callPackage ../tools/misc/wacomtablet { }; </ins> wasmer = callPackage ../development/interpreters/wasmer { };