python3Packages.libarcus: fix build for GCC 15

[samestep]

This PR fixes the python3Packages.libarcus build failure (caused by #471587) via a backport of Ultimaker/libArcus#160 from v5 to the v4 we currently have in Nixpkgs.

ZHF: #516381

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.

[samestep]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review
Commit: ffa2e94355be78122a24e79d4563647c5ce51b00

---

x86_64-linux

❌ 1 package failed to build:

• cura

✅ 5 packages built:

• curaengine
• python313Packages.libarcus
• python313Packages.uranium
• python314Packages.libarcus
• python314Packages.uranium

[thunze]

Commit message should say python3Packages.libarcus instead of libarcus. (There is no libarcus attr, see OfBorg.) Otherwise diff LGTM.

[samestep]

@thunze apologies, had a brain fart there! Fixed now.

[thunze]

ModuleNotFoundError: No module named 'PyQt5'

when trying to import Arcus.

Python packages typically have pythonImportsCheck set as a last resort to catch missing dependencies, especially if they cannot use pythonRuntimeDepsCheck.

The derivation could generally use some cleanup. Just as an example, distutils in propagatedBuildInputs is probably incorrect.

[samestep]

@thunze given that the only maintainer for this package and its transitive dependents was removed almost a year ago in #429059, do you think it may make more sense to just drop them like in #520610?

[thunze]

@thunze given that the only maintainer for this package and its transitive dependents was removed almost a year ago in #429059, do you think it may make more sense to just drop them like in #520610?

Yeah, that's probably fine. Cura 4.13.1 is from January 2022 and hasn't been updated since, so I'd argue it's effectively unmaintained. All of the relevant packages have been broken for a while. There's cura-appimage as an alternative, which is maintained.

[samestep]

Closing in favor of #520610.