segger-jlink: init at 794a, nrfconnect: init at 4.3.0, nrf-command-line-tools: init at 10.23.2

[StarGate01]

Description of changes

This PR re-adds some packages which were purged due to their usage of QT4 in #174634 : segger-jlink, and two packages which depend on it: nrfconnect and nrf-command-line-tools.

Unfortunately the SEGGER J-Link tools are only distributed in binary form and have a hard requirement on (the bundled) QT4. I have packaged the bundled QT4 libs as a secondary package to not pollute the global namespace.

Supersedes #252137, #244637, #263487

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.11 Release Notes (or backporting 23.05 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
• Fits CONTRIBUTING.md.

[ajs124]

Why have this as a second derivation and not just as part of the main one?

[StarGate01]

I wanted to ensure that QT4 libs (which are considered outdated) are not contained in /bin or /lib of a top-level package, in order to not pollute the global namespace. Am I mistaken? Should this be included?

[h7x4]

I think that makes sense

[nixos-discourse]

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

https://discourse.nixos.org/t/nrfconnect-package-wrongly-removed/33261/2

[Mindavi]

I think this may be more suitable as an overlay at this point

[pinpox]

@StarGate01 Are you still working on this? I'm waiting for this package.

[StarGate01]

@pinpox Yes I am , I'll implement the suggestions made by @SuperSandro2000 , however I don't really agree with @Mindavi - I would want to keep this as a package instead of a (somewhat cumbersome) overlay.

[liarokapisv]

The J-Links are an industry standard, I believe that the package is definitely worth keeping. I don't think that leaving the bundled qt4 libraries as is, is that huge of a deal in this case.

[StarGate01]

I have implemented most of the suggestions by @SuperSandro2000 , and also updated all three packages to the latest versions.

[liarokapisv]

@StarGate01 I think it is useful to also provide desktop files for the graphical applications like JLinkRTTViewer, JMem etc.
I have a working reference implementation in my own pull-request (which I will probably close in favor of this one) if it is deemed useful.

[StarGate01]

@liarokapisv Good idea - is the list at https://github.com/liarokapisv/nixpkgs/blob/1f6683d53373179b761055239616c7e65a0a71fc/pkgs/by-name/jl/jlink-software-tools/package.nix#L95 the complete list of all apps which should have a dektop icon?

[liarokapisv]

I think so. It was taken from the AUR package. I double-checked it but I could be missing something.

[StarGate01]

Okay. Some entries like JLink are CLI tools, would it be a sensible to add a dektop entry for those CLI-only tools?

[liarokapisv]

I manually went through all executables and this is what I got.

GUIs:

• JFlash
• JFlashLite
• JFlashSPI
• JLinkConfig
• JLinkGDBServer
• JLinkLicenseManager
• JLinkRTTViewer
• JLinkRegistration
• JLinkRemoteServer
• JLinkSWOViewer
• JLinkUSBWebServer
• JMem
• JScope

CLI-only:

• JLink
• JLinkGUIServer
• JLinkRTTClient
• JLinkRTTLogger
• JLinkSTM32
• JLinkXVCDServer
• JRun
• JTAGLoad

As a sidenote - the official deb package also makes various symlinks without the Exe suffix.
There are a few exceptions, most notably:

• JLinkExe
• JLinkConfigExe
• JLinkGDBServerCLExe
• JLinkGUIServerExe
• JLinkRTTViewerExe
• JLinkSWOViewerCLExe
• JLinkUSBWebServerExe
• JLinkXVCDServerExe

These do not have symlinks without the Exe suffix.
Maybe it would be a good idea to provide symlinks for these too?

[maxhbr]

Works for me 👍

[teburd]

Works for me, and I'm using it in a flake today with an overlay in a very janky and unfriendly way. Would really much prefer this in tree

[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/3395

[github-actions]

Successfully created backport PR for release-23.11:

• [Backport release-23.11] segger-jlink: init at 794a, nrfconnect: init at 4.3.0, nrf-command-line-tools: init at 10.23.2 #286801

[Mindavi]

Okay, there seems to be a need for this, and hydra won't help building this anyway. So I guess we can carry this package for now. But I'm not super thrilled about carrying such an old qt, it'll inevitably break at some point, with a compiler update or so. Anyhow, it won't burden hydra much.

[h7x4]

Maybe it would be possible to split the package? I suspect that most things depending on segger jlink only depends on the libraries and/or cli tools, not the GUI stuff. Some kind of segger-jlink-headless?

[Mindavi]

QT also contains quite some libraries, it seems unlikely only the GUI parts were used and none of the non-gui parts.

[StarGate01]

Interesting idea, we would have to figure out which of the tools actually use QT. This might also change with future updates. I am unsure if there is a usecase for a "reduced" JLink tool suite - even mundane things like a license popup use QT4.

[emilazy]

I’ve opened #353880 to revert this, per #214195 (comment).