{sigrok-cli, libsigrok, pulseview, libsigrok-sipeed}: bump version, init libsigrok fork

[AwesomeQubic]

Updated sigrok packages, and swiched libsigrok to a fork so I can use my devices (its just libsigrok with extra drivers)
Tested pulseview and sigrok-cli seems to work fine

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.

[qweered]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 483165
Commit: 30bedb4e855254a010225ffa65ea2f51360bc6ff (subsequent changes)
Merge: 281d40f5eb80427a8f8a3db7a1ebd13d7a3effa1

Logs: https://github.com/qweered/nixpkgs-review-gha/actions/runs/21304419596

---

x86_64-linux

✅ 7 packages built:

• collectd
• libsigrok
• pulseview
• python313Packages.sigrok
• python314Packages.sigrok
• sigrok-cli
• smuview

---

aarch64-linux

✅ 7 packages built:

• collectd
• libsigrok
• pulseview
• python313Packages.sigrok
• python314Packages.sigrok
• sigrok-cli
• smuview

---

x86_64-darwin (sandbox = relaxed)

✅ 6 packages built:

• libsigrok
• pulseview
• python313Packages.sigrok
• python314Packages.sigrok
• sigrok-cli
• smuview

---

aarch64-darwin (sandbox = relaxed)

✅ 6 packages built:

• libsigrok
• pulseview
• python313Packages.sigrok
• python314Packages.sigrok
• sigrok-cli
• smuview

[qweered]

Approved automatically following the successful run of nixpkgs-review.

[sternenseemann]

I don't think this change of upstream makes sense to do since it isn't even a fork with any kind of maintenance goals (except adding drivers for a device its authors are developing). It should rather be a separate package, e.g. libsigrok-sipeed for now.

[AwesomeQubic]

yes but you need to build everything against it for it to well work, also we could just fetchPatch from their PR to libsigrok adding device support

sigrokproject/libsigrok#275

[sternenseemann]

This can be achieved by final: prev: { libsigrok = final.libsigrok-sipeed; } downstream. Patching would be better, but I'm not really comfortable declaring that this big code addition is fine to ship to users necessarily.

[AwesomeQubic]

Sure, but if you do not these users will have hardware that is unusable without knowing why.
I am fine with using a overlay tho I would ask kindly that you test my changes on your devices that work with upstream libsigrok since well I will not be able to for obvious reasons.

[AwesomeQubic]

Perhaps a good idea would just be to add a option like hardware.sipeed.enable and then deciding what libsigrok to use systemwide?
Tho idk if that is a good solution for a problem that will be fixed in 4 weeks

[AwesomeQubic]

@sternenseemann please review

[cab404]

@AwesomeQubic hi! thanks for your PR

since pulseview got broken in master, I came across it)

given that pulseview does require a bump rn (upstream boost stopped being compatible with the current version), and that upstream libsigrok didn't merge slogic yet (alas they do seem close), maybe let's just go ahead and merge it.

however i don't really think that temporary not-yet-upstream patches like libsigrok-sipeed belong in nixpkgs — and more like in nixos documentation or wiki
if it makes it to 26.05 — we'll have to add a shim upon removal, which will have to stay there for a while, which is undesirable

so... would it be okay for you to not add libsigrok-sipeed, since it seems that you yourself agree it will be upstreamed soon?

eeh, if it will be upstreamed soon (in the next two months) — we'll have time to remove it. otherwise we would be justified to have it.

since from what i've checked it appears to be functioning just fine, and that edits appear to coinside with wishes of package maintainer, I'll be merging it