labrador: init at 0-unstable-2026-01-05

[randomizedcoder]

Summary

Add EspoTek Labrador - an open-source USB device that turns your PC into a full-featured electronics lab bench with oscilloscope, signal generator, logic analyzer, and multimeter functionality.

This package builds the Qt5 desktop application for interfacing with the Labrador hardware.

Features

• Cross-platform: Supports Linux (x86_64, aarch64, i686, armv7l) and macOS (Darwin)
• Firmware updates: Includes bundled libdfuprog library
• Complete installation: Firmware files, waveforms, icons, and desktop file

udev rules (Linux)

For non-root USB access, users need to add udev rules. On NixOS:

services.udev.extraRules = ''
  ENV{ID_VENDOR_ID}=="03eb", ENV{ID_MODEL_ID}=="ba94", MODE="0666"
  ENV{ID_VENDOR_ID}=="03eb", ENV{ID_MODEL_ID}=="a000", MODE="0666"
  ENV{ID_VENDOR_ID}=="03eb", ENV{ID_MODEL_ID}=="2fe4", MODE="0666"
'';

Build verification

$ nix-build -A labrador
/nix/store/...-labrador-0-unstable-2026-01-05

$ ls result/bin/
labrador

$ ldd result/bin/.labrador-wrapped | grep -E "(Qt|fftw|usb)"
libfftw3_omp.so.3 => /nix/store/...-fftw-double-3.3.10/lib/libfftw3_omp.so.3
libusb-1.0.so.0 => /nix/store/...-libusb-1.0.29/lib/libusb-1.0.so.0
libfftw3.so.3 => /nix/store/...-fftw-double-3.3.10/lib/libfftw3.so.3
libQt5PrintSupport.so.5 => /nix/store/...-qtbase-5.15.18/lib/libQt5PrintSupport.so.5
libQt5Widgets.so.5 => /nix/store/...-qtbase-5.15.18/lib/libQt5Widgets.so.5
libQt5Gui.so.5 => /nix/store/...-qtbase-5.15.18/lib/libQt5Gui.so.5
libQt5Core.so.5 => /nix/store/...-qtbase-5.15.18/lib/libQt5Core.so.5

Application launches successfully and scans for USB device (expected "DEVICE NOT FOUND" without hardware connected).

---

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
  • Ran nixpkgs-review on this PR. See nixpkgs-review usage.
  • Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/6238

[SuperSandro2000]

Suggested change

	# maintainers = with lib.maintainers; [ randomizedcoder ];
	maintainers = with lib.maintainers; [ randomizedcoder ];

[randomizedcoder]

Sorry, my github name hasn't landed in https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix yet. Once it does, I can add this line. ( Speaking of which, this maintainer-list.nix is very large. I wonder if it should be split by subdirs "aa" ... ? )

[SuperSandro2000]

Just add yourself to that list. I don't think there are currently plans to split that file.

[randomizedcoder]

@SuperSandro2000 Thanks for the review. - In general, if I want to document how a package.nix is setup, and why, what's the best way please? Could I make a README.md in the folder? The reason I ask is that I'm working on packaging Performance Co Pilot ( https://github.com/performancecopilot/pcp ) and it's a bit of a nightmare. Anyone coming back to look in a couple of months will be very confused.

[randomizedcoder]

Good idea about the udev rule. Updated, and fixed the commits (doh!)

Labrador now also has flake.nix
espotek-org/Labrador#393

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/6430

[SuperSandro2000]

@SuperSandro2000 Thanks for the review. - In general, if I want to document how a package.nix is setup, and why, what's the best way please? Could I make a README.md in the folder? The reason I ask is that I'm working on packaging Performance Co Pilot ( performancecopilot/pcp ) and it's a bit of a nightmare. Anyone coming back to look in a couple of months will be very confused.

I would add comments to key lines that are not very intuitive and raise questions.

[SuperSandro2000]

Suggested change

	# maintainers = with lib.maintainers; [ randomizedcoder ];
	maintainers = with lib.maintainers; [ randomizedcoder ];

other bits are looking good

[randomizedcoder]

@SuperSandro2000

Thanks again.

I made the mistake of including randomizedcoder maintainer into this PR, which I just fixed up
#473609

[randomizedcoder]

@SuperSandro2000
I'm really wondering about making a bit of automation, maybe with a local LLM to do the nixpkgs code reviews

... And I also think we need some commit hooks for run nix fmt - I assume this has come up before, so I'm not sure why it didn't make progress

[SuperSandro2000]

Please rebase in a few minutes when the other PR is merged.

[SuperSandro2000]

... And I also think we need some commit hooks for run nix fmt - I assume this has come up before, so I'm not sure why it didn't make progress

I don't know, I don't use commit hooks as they interfere when rebasing when not done correct.

[infinisil]

Closing and reopening to fix CI, see #499751

[randomizedcoder]

Addressed @SuperSandro2000's review feedback, rebased, and squashed into a single commit. Changes applied:

• Replaced shell-level binary install with Nix-level if stdenv.hostPlatform.isDarwin to prevent silent failure
• Verified all other suggestions were already applied (udev rule as file, platform throw, sharedLibrary extension, qmake hook, simplified firmware/icon install, maintainer)