aliza: init at 1.9.7

[luxzeitlos]

Description of changes

We used to have aliza, but it was removed because it needed gtk4, was not build form source, and broke. We now build aliza from source and with gtk5.

We don't use by-name, because we need libsForQt5.callPackage.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[h7x4]

We don't use by-name, because we need libsForQt5.callPackage.

I think it still fits into by-name, if you callPackage the path of the package in by-name. There's a lot of new packages that do this to inherit from darwin.apple_sdk.frameworks for example.

[luxzeitlos]

We don't use by-name, because we need libsForQt5.callPackage.

I think it still fits into by-name, if you callPackage the path of the package in by-name. There's a lot of new packages that do this to inherit from darwin.apple_sdk.frameworks for example.

@h7x4 thanks for the hint, but the validation does not like it if the second arg is empty.
Besides that this is stolen from nextpnrWithGui, which does the libsForQt5.callPackage ../by-name....

Also this does work. Not sure if the validation is correct or not, or how to proceed here.

[h7x4]

@h7x4 thanks for the hint, but the validation does not like it if the second arg is empty.

That seems like an oversight in the pkgs/by-name check.

@infinisil have you seen this before?

[h7x4]

Maybe it would make more sense to import libsForQt5 as an argument in the package, and access the qt packages through libsForQt5.<name>?

[infinisil]

The error could be improved, but it means that only packages for pkgs.callPackage are allowed, so no libsForQt5.callPackage. But indeed as @h7x4 suggests, you can likely refactor it to work with a standard callPackage, though I'm not 100% sure this would be exactly the same in the end.

Besides that this is stolen from nextpnrWithGui, which does the libsForQt5.callPackage ../by-name....

The extended definition of that is

  nextpnrWithGui = libsForQt5.callPackage ../by-name/ne/nextpnr/package.nix { ... }

Only attributes defined via pkgs/by-name need to use pkgs.callPackage, there's no restrictions for other attributes. In this case, only nextpnr is defined in pkgs/by-name (via an implicit pkgs.callPackage), nextpnrWithGui is not (it merely reuses the same file).

[luxzeitlos]

Maybe it would make more sense to import libsForQt5 as an argument in the package, and access the qt packages through libsForQt5.<name>?

How would that look like then?

[luxzeitlos]

Well, so I took it out of by-name, should be good now?

[AndersonTorres]

Usually it goes on nativeBuildInputs.

[AndersonTorres]

Suggested change

	"-DCMAKE_BUILD_TYPE:STRING=Release"
	"-DALIZA_QT_VERSION:STRING=5"
	"-DITK_DIR:STRING=${itk}"
	"-DMDCM_USE_SYSTEM_ZLIB:BOOL=ON"
	(lib.cmakeFeature "CMAKE_BUILD_TYPE" "Release")
	(lib.cmakeFeature "ALIZA_QT_VERSION" "5")
	(lib.cmakeOptionType "filepath" "ITK_DIR" itk)
	(lib.cmakeBool "MDCM_USE_SYSTEM_ZLIB" true)

[luxzeitlos]

are you sure (lib.cmakeBool "-MDCM_USE_SYSTEM_ZLIB" true) is correct?

[AndersonTorres]

... why not?

[AndersonTorres]

Maybe it would make more sense to import libsForQt5 as an argument in the package, and access the qt packages through libsForQt5.<name>?

To be honest, I do not like that extra scoping.
I don't believe QT5/QT6 libraries are so important to the point of deserving an "overlay" like this.
X11 is way more important than this, and no one created a "libsForXorg.callPackage" (yet).

Also it contaminates some decisions. I remember when cmake was wrapped under libsForQt5.callPackage...