ns-usbloader: init at 7.0

[soupglasses]

Description of changes

Created a new package ns-usbloader versioned at 7.0.

Closes #85652

Things done

• Ensured it works with Nintendo Switch hardware correctly.
• Applied an extra patch to ensure the generated .jar file is reproducible. May get upstreamed down the line.

• 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.

[soupglasses]

One strange issue i hit when moving this project from my personal tree to nixpkgs was that the mvnHash changed. Further, using applyPatches of this PR will also change the mvnHash and fail to build. I am not sure if this is expected behaviour of maven.buildMavenPackage or if there is something funky i need to patch further in pom.xml, as its been a real pain to get it building in a reproducible way.

[soupglasses]

Building it directly against this PR's hash works correctly. So I am unsure what is going on when it gets used as a patch. 🤔

[soupglasses]

Yeah. hmm. There is most definetly something wrong with how its pulling dependencies. Just look at the OfBorg logs for "ns-usbloader.passthru.tests on aarch64-linux".

error: hash mismatch in fixed-output derivation '/nix/store/qidgfnjhiwi9dyiacrcmbc73m6ifi0h5-ns-usbloader-7.0-maven-deps.drv':
         specified: sha256-vXZAlZOh9pXNF1RL78oQRal5pkXFRKDz/7SP9LibgiA=
            got:    sha256-xC+feb41EPi30gBrVR8usanVULI2Pt0knztzNagPQiw=

I am not sure what is going on.

[soupglasses]

Doing nix-build /nix/store/jx6920dp838289g67bwqd5vkwcxf9bf2-ns-usbloader-7.0-maven-deps.drv --check --keep-failed locally gives back the exact same every time. Leading me to believe that architecture, maven/java versions, or similar changes in input may be at play.

[soupglasses]

Putting this into draft due to the fragile nature of mvnHash. I have narrowed the first issue down to a changing maven version 3.9.2 vs 3.9.3 to change the internal dependencies in the -deps derivation. Read as minus is removed, plus is added, otherwise it is in both.

maven-plugins (-36, 39)
maven-resources-plugin (-3.3.0, +3.3.1)
maven-filtering (-3.3.0, 3.3.1)
plexus-utils (-3.3.0, 3.5.0, 3.5.1)

[soupglasses]

Hmm. Seeing as 13dd515 (#238746) updated the mvnHashs for all buildMavenPackages in nixpkgs for a maven upgrade, it seems that this package is not exclusively struggling with bad version pinning.

However, im curious for why aarch64 fails, as it is based on the exact same inputs, but fails. 🤔

[soupglasses]

Pinned the rest of the dependencies and now maven versions should not matter. Waiting for CI to see if this also helped Aarch64.

[soupglasses]

Yeah hmm. Aarch64 is not happy about the missing javafx libs. It seems i might need to fix that too.

Could not resolve dependencies for project loper:ns-usbloader:jar:7.0: The following artifacts could not be resolved: org.openjfx:javafx-graphics:jar:linux-aarch64:19.0.2.1 (absent), org.openjfx:javafx-base:jar:linux-aarch64:19.0.2.1 (absent), org.openjfx:javafx-controls:jar:linux-aarch64:19.0.2.1 (absent), org.openjfx:javafx-fxml:jar:linux-aarch64:19.0.2.1 (absent): Cannot access redrise (https://repo.redrise.ru/releases) in offline mode and the artifact org.openjfx:javafx-graphics:jar:linux-aarch64:19.0.2.1 has not been downloaded from it before.

[soupglasses]

Gonna pull in @Tillerino and @wegank as both seem to have recent experience with buildMavenPackage, as i need advice for how to deal with JavaFX packaging architecture-dependent versions, and how i could pull extra arch's into mvnHash correctly.

[Tillerino]

Hi soupglasses, I gotta be honest, I just did some legwork surrounding the Maven update. I haven't done anything with architecture-specific packaging yet.

Good call on managing the plugin versions 👍 I have been trying to upstream that for the projects where we had issues with the Maven update. I hope the next one will go smoother.

[soupglasses]

Yeah. Outside of limiting the package to x86_64-linux and aarch64-linux with a if statement to swap the mvnHash based on architecture, then adding a comment expressing it's TODO/FIXME status.

I have no ability to test it on other architectures than that. But seems like a good first PR.

[soupglasses]

Not a first timer, just changed my handle in the maintainer-list.nix 😅

[soupglasses]

All lights green. This PR should be ready for merging now :)