python310Packages.pyopenssl: mark broken on aarch64-darwin

[SuperSandro2000]

Description of changes

Closes #172117

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/)
• 22.05 Release Notes (or backporting 21.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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Mindavi]

This seems sensible since it seems it cannot be fixed without upstream work.

[bobrik]

I don't think this is a good solution. You don't have to use callbacks in pyopenssl.

Marking pyopenssl as broken locks out a ton of packages on aarch64-darwin that were working perfectly fine. 1703 were removed in the latest evaluation:

• https://hydra.nixos.org/eval/1761158#tabs-removed

[SuperSandro2000]

You don't have to use callbacks in pyopenssl.

There is no reasonable way we can figure out which packages uses callbacks and which not and this could change with every update. Keeping maintainers busy with marking downstream packages broken which happen to use callbacks is also not a great solution or maintainable. Since I am the maintainer I'd rather mark pyopenssl broken on aarch64-darwin because it is not fully working or has proper upstream support. If we find a good solution I am more than happy to add a workaround but I don't have the darwin knowledge or time to find one especially if most likely code changes are required.

were working perfectly fine.

I am not fully sure on this one. It could also be that we ignored problematic tests on darwin in other packages which actually where caused by pyopenssl.

1703 were removed in the latest evaluation:

762 of them are duplicates between python39 and python310, so only 941 got removed.

[bobrik]

There are plenty of packages with bugs that do not prevent them from being useful. GCC is not marked as broken.

I have a package that I've been using without any issues and now it's not available due to pyopenssl being marked as broken.

[Mindavi]

@bobrik one direction to look in is to stub out the callbacks with assertions, making it very clear that it's related to that issue when it fails. Such a patchset will require maintenance though, so it's not ideal. Maybe upstream will even accept something like that? Would be useful to be able to backtrack easily instead of having weird crashes.

[SuperSandro2000]

Yeah, I am no longer willing to invest time to debug this exact issue in downstream package tests.

[avanov]

This led to ansible being unavailable in all available Python package sets on Apple M1.

[kwohlfahrt]

At least ansible(cc @avanov) is fixed by #173809, I suspect many other packages will be as well.