luaPackages.luaossl: mark broken for lua 5.5

[wishstudio]

• NixOS 26.05 – Zero Hydra Failures #516381
• https://hydra.nixos.org/build/326830139

In file included from vendor/compat53/c-api/compat-5.3.c:7:
vendor/compat53/c-api/compat-5.3.h:404:4: error: #error "unsupported Lua version (i.e. not Lua 5.1, 5.2, 5.3, or 5.4)"
  404 | #  error "unsupported Lua version (i.e. not Lua 5.1, 5.2, 5.3, or 5.4)"
      |    ^~~~~

Vendorred an upstream pull request.

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.

[wishstudio]

I feel the knot-resolver problems are unrelated here:

knot-resolver_5> [net   ] bind to '127.0.0.1@48758' (TCP): Operation not permitted
knot-resolver_5> [net   ] bind to '127.0.0.1@48558' (TCP): Operation not permitted
knot-resolver_5> [net   ] bind to '127.0.0.1@49557' (TCP): Operation not permitted
knot-resolver_5> [net   ] bind to '127.0.0.1@42803' (TCP): Operation not permitted
knot-resolver_5> [system] error while loading config: ...714615/knot-resolver-5.7.6/modules/daf/daf_http.test.lua:24: unable to bind a port for HTTP module (1000 attempts) (workdir '/nix/build/nix-6613-2230714615/tmp.n5vHGTY70U')

[teto]

I would rather mark it as broken for 5.5 rather than fixing the package ourselves. You can still submit the patch upstream if you dont want to get it lost

[wishstudio]

I would rather mark it as broken for 5.5 rather than fixing the package ourselves. You can still submit the patch upstream if you dont want to get it lost

It's actually taken from an upstream pull request: wahern/luaossl#221

[teto]

upstream request was not merged and seems to be from external contributor. If the library doesn't support 5.5 it's not our responsibility to add support for it the same way that if there is a bug in the library we dont have to fix it. Please just mark it as broken and it makes things easier for everyone. If someone wants to have 5.5 support he can apply the patch.

[wishstudio]

Well, I completely agree with you that marking it as broken is easier for us to maintain. But since this patch is external, I think conceptually it's the same thing as toggling a fetchpatch which IMO isn't much harder than setting broken = true.

On the other hand, if you look closer to the patch it's just updating the list of supported lua versions to support lua 5.5. From my point of view it's no difference from the cmake/boost patches we do and much more benign than the newer-gcc-version patches where we usually have to touch code. Every major distro does this and if we really disallow such practice I guess we would throw thousands of packages out of nixpkgs.

Even if we only talk about lua packages there is an existing patch luuid.patch in the same directory that adds support to an older lua version, and it actually touches code.

So I feel you are applying a different standard here. Could you elaborate a bit more about the reasoning? No offense. I'm perfectly ok with whatever resolution this comes out. I just want to be clear about the policy (or lack of).

[teto]

it's just updating the list of supported lua versions to support lua 5.5. From my point of view it's no difference from the cmake/boost patches

cmake/boost patches allow a program to build with the caveats of nixpkgs, without those you can't package the software.
Lua versions can be thought of different platforms. By merging this we are making the software work on eg. "windows" while the author intented to make it work only for "macos", it's not equivalent at all.

What does the maintainer do when someone opens up a bug report against lua 5.5 and the maintainer mentions: "How could you make it work, my program isn't compatible with 5.5 yet ? I am using nixpkgs". Then it gives nixpkgs bad press for modifying upstream programs.

It's not because luarocks can install the program that it works correctly. I dont have the expertise nor the time to check nor the responsibility to check a program works in conditions it's not supposed to work (yet) in the first place.

[wishstudio]

Lua versions can be thought of different platforms.

Great. I think this makes the most sense for me.

The cmake/boost patches I mentioned are for patching the packages to support newer versions of the respective packages. For example, the most CMake 4 patches we do is to change the cmake_minimum_required designation in CMakeLists.txt to newer versions. It's actually an upstream issue per your reasoning and has nothing to do with nixpkgs. I can't believe we patched these many packages without a single (hidden) failure. Otherwise the CMake team won't make it a breaking change in the first place. The recent boost patches are better but they are still upstream issues.

The problem is much worse for python packages, looking at all these patches, dependency-loosening tricks and test-skips we do. Can anyone guarantee such patching won't backfire? Like lua there isn't a reliable way to test. I bet even the upstream maintainer don't know, unless after they change their dev environment to the newer version.

It's not because luarocks can install the program that it works correctly. I dont have the expertise nor the time to check nor the responsibility to check a program works in conditions it's not supposed to work (yet) in the first place.

While I agree with your stance, for pragmatical reasons I think it's really broken everywhere in nixpkgs (and every major distro). Anyway since I'm a passerby here I shouldn't pass any unwanted maintenance burden to you. Thank you for your time in explaining to me and I will do what you suggested.

[wishstudio]

Done. Just a side note I did test the patch with some simple programs so while I can't guarantee it to be flawless it should at least work to some extent. So anyone encountering this issue can try that first.

[teto]

I feel sorry that you initially did more work than what I was ready to accept in nixpkgs. Thanks for understanding my point of view and thanks for contributing to ZHF you are awesome ;)