segger-systemview: init at 352a

[StarGate01]

Description of changes

This PR adds the SEGGER SystemView debugging utility. It depends on the SEGGER J-Link libraries which are tracked in PR #255185 .

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[StarGate01]

Now that #255185 has been merged, I have rebased this PR to only contain the changes for the systemview package.

[Aleksanaa]

We don't accept more qt4 package and have been trying to remove or update them.

[StarGate01]

The package has a hard dependency on QT4. Without QT4, it does not run. Please review the discussion on QT4 at #255185 , SEGGER is unwilling to upgrade the QT version.

[h7x4]

Please see #255185 and #319342 for context.

We know that the segger software reintroduce qt4 dependencies, but the dependency is not exposed to toplevel, and the package is properly marked as insecure. The user knows what they are doing if they install this package.

[Aleksanaa]

So to introduce a proprietary software with outdated dependencies... why? It's not like it was ever there and we need to remove it.

[StarGate01]

I understand your concerns, but as @h7x4 pointed out, this package required the user to explicitly understand and allow (1) the license and (2) the outdated libs. Other packages and systems are unaffected by this package, i.e. if you do not use it you are unaffected.

SystemView is a widely used industry-standard embedded debugging suite, see https://www.segger.com/products/development-tools/systemview/ . It would be nice for NixOS to evolve from a project for ambitions hobbyists into a system which supports real-world software.

If I could, I would just provide this package out-of tree, similar to how e.g. Arch (https://aur.archlinux.org/packages/jlink-systemview) does it, but this does not work for nixpkgs. I do not have the bandwidth to maintain an eternal fork for a simple package.

[SuperSandro2000]

Can we dedupe this with https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/se/segger-jlink/qt4-bundled.nix ?

[StarGate01]

We might be able to, but the bundled QT libs may change in between releases. AFAIK only the libraries which are directly needed by the related package are included, which might not be enough for the other packages.

I have not verified this, but I am hesitant to de-duplicate these "independent" libs.

[emilazy]

Hi, sorry that this PR was dormant for a long time.

If I could, I would just provide this package out-of tree, similar to how e.g. Arch (https://aur.archlinux.org/packages/jlink-systemview) does it, but this does not work for nixpkgs. I do not have the bandwidth to maintain an eternal fork for a simple package.

This is totally possible – since this is a leaf package that other packages don’t depend on, you can put up a repository containing just the additional packages that users can overlay on top of Nixpkgs. Flakes can help do this, and there are already a lot of third‐party repositories doing this (e.g. rust-overlay, nixos-cosmic, and even from before flakes were a thing the Nix User Repository).

I would encourage you to do that since we removed Qt 4 two and a half years ago and really don’t want to accept new packages using Qt 4 or take up the burden of maintaining them; if anything, we’re trying to reduce out use of Qt 5 in anticipation of it going EOL next year. I think that #255185 should not have been accepted either, unfortunately, but it should be simple to provide these packages in your own repository without having to maintain a fork of Nixpkgs. Please let me know if you need any pointers on how to accomplish this.

[StarGate01]

@emilazy Thank you for your suggestion. Although I don't agree on the removal of the tools from nixpkgs (yet), I would like to explore the option of providing them via a flake. Do you have some resources I could use as a template?

[emilazy]

The simplest thing would be a flake that just provides an overlay:

{
  outputs = { self }: {
    overlays.default = final: prev: {
      segger-jlink = final.callPackage ./pkgs/segger-jlink { };
      nrfconnect = final.callPackage ./pkgs/nrfconnect { };
      # …
    };
  };
}

Users could include it in their configuration with inputs.segger-flake.url = "…"; and set nixpkgs.overlays = [ inputs.segger-flake.overlays.default ]; to get the packages available. If you wanted to expose a full package set so that things like nix run …#segger-jlink also worked, you could do:

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  };

  outputs = { self, nixpkgs }: {
    packages = let
      systems = [
        "x86_64-linux"
        "i686-linux"
        "aarch64-linux"
        "armv7l-linux"
      ];
    in nixpkgs.lib.genAttrs systems (system:
      nixpkgs.legacyPackages.${system}.extend self.overlays.default
    );

    overlays.default = …; # same as before
  };
}

[qweered]

Bump, now we started removing qt5