How do I change package download link? Or fix broken packagen via local file?

So I’ve been trying to install graphics tablet proprietary drivers on my Nixos setup, but unfortunately the package download link is broken and whenever I try to intall the package libsForQt5.xp-pen-deco-01-v2-driver (I’m going with a standard pkg install method throug configuration.nix) I get a download error that reads:

error: cannot download xp-pen-deco-01-v2-driver- from any mirror
error: builder for ‘/nix/store/4mvsah70qr3m3cw6xp2cqn6say7ghx15-xp-pen-deco-01-v2-driver-’ failed with exit code 1

At the same time, an archive with drivers can be downloaded directly from the manufacturer’s website. It seems that they’ve only changed the download link address to:, which causes the error upon installation.

So how do I override nixpackage download link? Is there a command that I can use? Or maybe I could download an archive from a website and then point Nix package manager to install it from a local file? How do I fix the broken download link? Sorry if this a newbie question, I’ve been trying to make these particular drivers work for quite a while.

So I’ve tried running this command after downloading an archive on my own:
sudo nix-store --add-fixed sha256 XPPenLinux3.4.9-231023.tar.gz

But It seems I’m doing something wrong, as it won’t work…

I’d try

libsForQt5.xp-pen-deco-01-v2-driver.overrideAttrs (prev: {
  src = prev.src.override {
    url = "";
    # hash should be the same!

Though honestly, it’d be best if you simply contributed the URL change to upstream Nixpkgs.

The derivation might use fetchzip which unpacks the tarball automatically.

If you manually unpack it into a directory and add the directory instead, does that work?

1 Like

I’ve tried copying your example with .overrideAttrs function and I’m getting the following error:

… while calling the ‘head’ builtin

     at /nix/store/yjngzf087j9il2f4cqnr3ivjz2kagdxh-nixos-23.11/nixos/lib/attrsets.nix:922:11:

      921|         || pred here (elemAt values 1) (head values) then
      922|           head values
         |           ^
      923|         else

   … while evaluating the attribute 'value'

     at /nix/store/yjngzf087j9il2f4cqnr3ivjz2kagdxh-nixos-23.11/nixos/lib/modules.nix:807:9:

      806|     in warnDeprecation opt //
      807|       { value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
         |         ^
      808|         inherit (res.defsFinal') highestPrio;

   (stack trace truncated; use '--show-trace' to show the full trace)

   error: A definition for option `environment.systemPackages."[definition 3-entry 2]"' is not of type `package'. Definition values:
   - In `/etc/nixos/configuration.nix': <function>

I wish I knew how to contribute, also I’ve seen some commits from other users on github addressing the broken package issue in november 2023, but It seems that the changes were not committed yet, but I’m not sure.

Ultimately I think the most helpful thing would be to try to review #277176 since you have the hardware to actually put it to use. To make the unified xp-pentablet available you can try an overlay like this:

_: pkgs:

  pr-277176 = import (builtins.fetchTarball { url = ""; }) { inherit (pkgs) config; overlays = [ ]; };
rec {
  inherit (libsForQt5) xp-pentablet;

  libsForQt5 = pkgs.libsForQt5.overrideScope (_: _: {
    inherit (pr-277176.libsForQt5) xp-pentablet;

In the interim if you’d like to just have #267753 early you can use an overlay like:

_: pkgs:

  pr-267753 = import (builtins.fetchTarball { url = ""; }) { inherit (pkgs) config; overlays = [ ]; };
  libsForQt5 = pkgs.libsForQt5.overrideScope (_: _: {
    inherit (pr-267753.libsForQt5) xp-pen-deco-01-v2-driver;

If you wish to change the attributes of a package then you could use overrideAttrs just like this.

  dataDir = "var/lib/xppend1v2";

    (libsForQt5.xp-pen-deco-01-v2-driver.overrideAttrs {
      src = fetchzip {
        url = "";
        sha256 = "sha256-A/dv6DpelH0NHjlGj32tKv37S+9q3F8cYByiYlMuqLg=";

      installPhase = ''
        runHook preInstall

        mkdir -p $out/{opt,bin}
        cp -r App/usr/lib/pentablet/{PenTablet,resource.rcc,conf} $out/opt
        chmod +x $out/opt/PenTablet
        cp -r App/lib $out/lib
        sed -i 's#usr/lib/pentablet#${dataDir}#g' $out/opt/PenTablet

        runHook postInstall

      postFixup = ''
         makeWrapper $out/opt/PenTablet $out/bin/xp-pen-deco-01-v2-driver \
          "''${qtWrapperArgs[@]}" \
          --run 'if [ "$EUID" -ne 0 ]; then echo "Please run as root."; exit 1; fi' \
          --run 'if [ ! -d /${dataDir} ]; then mkdir -p /${dataDir}; cp -r '$out'/opt/conf /${dataDir}; chmod u+w -R /${dataDir}; fi'


You need to add the entire (libsForQt5.xp-pen-deco-01-v2-driver.overrideAttrs) code to system packages or home packages (whichever you use) and it should work. Or you could use open tablet drivers instead. This works fine for my xp pen deco 01 v2 tablet.

1 Like

Thank you for your solutions! I will try using this method, buy I’m still clueless when it comes to using overlays to be honest and all I get is errors that I fail to understand when building. I haven’t used homemanager either. I’ve tried open tablet drivers, while it provides support to pen pressure, it doesn’t support pen tilt function of that specific tablet, also it glitches out sometimes and stops working, especially when you save settings, it’s specifically glitchy when it comes to remapping buttons on a pen to different buttons, like middle mouse button on a button 2 and right click mouse button on button 3.

This error message hints at the (likely) actual issue at hand: You probably forgot to add parenthesis around the snippet.


  function { arg = "foo"; }

evaluates to a list with two elements: One function and one attrset. The function is never applied.

To get a list with one element where the function is applied to the argument, you must add parens:

  (function { arg = "foo"; })

As @_Andrew mentioned, reviewing the upstream PR is the best course of action. Not only do you get a working system once it’s merged, everyone coming after you will have it working out of the box too.

If you are using the unstable channel already, a simple way of testing the PR is to run

nixos-rebuild test -I nixpkgs=

(May require you to log out and back in again to take effect.)

Please share whether it works for you in the PR. Doing so would greatly help us committers who are not familiar with the package and/or do not have access to the required hardware know whether the PR is good to merge or not.

1 Like

I tried to run the above mentioned rebuild commands to test if PR is working and all I’m getting is a sudden black screen during the build process and system completely freezing and becoming unresponsive until I hard reset it… Tried running this command four times already and all the time my system just blacked out.

I think I’m doing it correctly, I’ve commented out all the rest of the packages and left out only firefox in environment.systemPackages = with pkgs; [ ]

Are you on the stable or unstable channel? If you’re on stable, trying this would likely not succeed on a running system as this will effectively upgrade you to a future NixOS release (24.05). You usually have to do boot rather than test and then reboot in such cases.

Going back is trivial from the NixOS side (simply roll back or boot a generation from the regular channel) but, because the newer NixOS release includes software that is newer, some of it might migrate its on-disk state in a manner that is not incompatible with the previous release’s software versions. There isn’t a lot of software which does this and is not guarded behind stateVersion but it could happen. Unless you’re running a lot of services, this is highly unlikely to happen though.

If you are indeed on stable, a better course of action would be to backport the fix using git cherry-pick but unless you already have a local Nixpkgs clone and know how to do that, this would be a learning project of its own.

1 Like

I have connected nixos to stable channel and nixpkgs to unstable channel (I have no idea if that is okay). And, yeah I do run a quite a lot of packages. I can try to switch to 24.05 and run a test build later on this day.

Theoretically, this could work and would be a super cool way to show Nix’ superpowers. However, unfortunately this doesn’t work for graphical applications because they rely on an impurity: The graphics driver.

This is still an unsolved problem.

Packages aren’t the issue per se. It’s whether those packages have any precarious on-disk state that may be modified in a backwards-incompatible manner without your active input. As long as the program never runs, that cannot happen. Services do run by default though which is why I explicitly called those out.

Note that you don’t have to change anything about your channels.

It’s just that running the rebuild command with the tarball above will, in effect, upgrade you to NixOS 24.05 as of a couple months ago.

You should also only use that generation for testing whether the tablet works and revert to a generation built from your channels’ Nixpkgs as soon as possible as it’d be quite out of date in every other regard.

1 Like

Yeah, I think it should be no problem I’ve already made like 50+ builds on this machine alone. I haven’t stumbled across any graphical issues on my current setup so far though, even tested renders in latest blender version, but I haven’t tried out gaming and some other 3d packages, that I plan to run via a virtual machine.

Is it okay if I switch channels to check stuff and rebuild boot and do garbage collection afterwards? I’m new to Nixos and I don’t know all the best practices, I’ve rewritten my configuration.nix file so many times and haven’t experienced any problems as of yet so far. I’ve always used nixos-rebuild boot and then just ran garbage collection.

So regarding these drivers, you suggest me to just run nixos-rebuild boot -I nixpkgs= and test things out?

I’m not sure what you intend to achieve with either.

As mentioned previously, you do not need to touch your channels in any way here.

If you’re experimenting with multiple NixOS versions, running an aggressive GC may delete previous generations that you might have wanted to keep because they’re known good states. I would not recommend running GCs in between experiments.
Garbage collection is generally only necessary if you’re running low on disk space. If you have plenty space remaining, there is no point in GC’ing.


You could augment that command with the --profile parameter which puts the generation into a separate directory in your boot loader rather than the main list of generations. This is useful to do if you’re just testing something out but must boot the generation to do so as is the case here.

nixos-rebuild boot --profile test-pentablet -I nixpkgs=
1 Like

Well, so far I’m just learning NixOS’ quirks and trying to come up with perfect configuration files to replicate on all my devices and say goodbye to Windows finally (leave it on VM level). I don’t mind reinstalling everything as everything is stored in config files. Still have to learn how to use home-manager and nix language syntax, but I think it is worth it, so far, it is the most stable linux distro that I’ve tried that you can actually experiment on and not be afraid of it breaking suddenly (well, at least that was my experience so far).

I also try to do garbage collection when I’ve more or less tested all the vital packages and I’m sure that everything is working (hopefully). I might be doing something wrong, probably, and acting recklessly because of the way how easily editable config files are, but so far NixOS was remarkably unbreakable! I’m very impressed!

Okay I’m going to do exactly that and report if it works, if there’s some other commands I need to run, maybe to get some log outputs or something else please tell me, because I’m new to whole linux thing and I’m not that very well-versed with CLI. It would be cool to make drivers for my hardware working at last and help others too! Thank you for your patience and answers, btw! You are super helpful, it is always good to have a mentor to teach you things about a new tech you try out!

1 Like

That’s why we’re all here :wink:

While it’s “wrong” in the sense that it’s unnecessary, it’s also not like it hurts very much. Running GCs all the time is a little like treating a cough with homeopathy. It doesn’t actually do anything good for you but it also doesn’t really do anything bad either.

From now on, please only run a GC when you’re running low on free disk space; that’s how it’s intended to be used :wink:

In case you’re using GCs in order to get rid of a certain generation from the list of available generations because it was some experimental configuration you did, I’d recommend you to delete the link in /nix/var/nix/profiles/system-$numberhere instead (and update the bootloader config via nixos-rebuild boot).
To avoid even generating these while you’re testing things, make use of nixos-rebuild test (won’t create a new bootable generation, will only make it active for the current boot) or --profile if you must boot the generation (as is the case here).

That’d be great, please do!

Log outputs are generally only really necessary when things aren’t working.

If it works, simply report that fact and I’ll merge the PR :slight_smile:

You’re new to Linux and you jumped right into NixOS? Well, you seem like the kind of person who could pull through with this as you’ve clearly seen the light, so best of luck! :smiley:

I must disappoint you but that’s likely out of reach. If some hardware thing doesn’t work out of the box or with a little tweaking, it’s usually either entirely unsupported or only very poorly supported and improving either situation requires really quite advanced knowledge that even very advanced Linux users often do not have.

I don’t mean to discourage you; quite the opposite, it’s intended as a warning to not feel discouraged if you cannot get your hardware to work because some hardware simply cannot be made to work without unreasonable effort.

1 Like


I just built a separate boot profile to test the drivers. And they work perfectly, everything works as I remember, all the options are there, pen sensitivity, tilt functions hotkeying of buttons on both pen and tablet are working as intended!

Here are some screenshots!

Thank you very much! I’ll keep that in mind from now on and will try to follow your advices! )

I hope so XD. First I’ve tried running Mint on my laptop, then I tried Manjaro because it had a lot of packages in their aur repository, but when I tried NixOS I was amazed that you can actually declare everything in a config file and replicate everything on other devices. I was like, yep, that is my distro XD, because I always store all the settings, hotkeys for software, write little code here and there to make things more customized, and I just kinda got slowly addicted to NixOS’ philosophy of declaring everything via code. I’ve spent some time playing around with it on my laptop and then I realized, I’m pretty sure I have all the necessary programs running with no problems or substituted by similar software (sometimes more flexible and robust) and decided that it’s about time to install it on every device I own XD.

Yeah, I guess it a huge problem for all linux desktop users, we’re a rare breed and it’s a damn shame to be honest. I don’t have too complex of a desktop though, just need some graphics tablets to be working, I’ve tested most things that are necessary for my work, apart from some nitpicks here and there it’s perfectly fine and super smooth and performant!

1 Like