elmPackages.elm: fix build failure on darwin

[sandydoo]

Patches crypton-x509-system to use the full path to the security binary. Same as x509-system.

Fixes #297775.

cc @domenkozar @turboMaCk

Description of changes

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.11 Release Notes (or backporting 23.11 and 24.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.

---

Add a 👍 reaction to pull requests you find important.

[turboMaCk]

@sandydoo since this is touching Haskell modules (which is indeed the right way to do it!) I think we might need to first merge it to haskell-updates branch.

@sternenseemann or would it be OK with you if we merge this patch directly to main?

[sandydoo]

Oh, that did not do what I wanted 🤦 Let me fix this...

[turboMaCk]

gosh. Yeah now the diff is all the master commits that haskell-updates lack behind. Version control is fun. Maybe you can keep master as base for now. I think maybe @sternenseemann will be OK with us merging this to the master? I'm not sure about how many rebuilds that could cause.

If not then maybe new branch based on haskell-updates and cherry-pick the comment on top of that? That's probably what I would do.

[turboMaCk]

LGTM. There is just what seems to be easy to resolve conflict.

[sandydoo]

Waiting for the the latest branch to download 🙂 Sorry for the noise, everyone!

[turboMaCk]

Oh no worries at all. I'm so glad someone picked this up. I was afraid I will need to steal Mac from my GF and set nix and everything up myself. Thanks a lot for looking into this.

Also... If you wish -- consider adding yourself to the maintainers of elm. It would be great to have someone with MacOS at hand there. It's important platform we need to keep supporting.
Just reminder that this is usually done in its own commit so if you choose to it can be its own PR.

[sandydoo]

Managed to wrangle git. Should be good now.

Also... If you wish -- consider adding yourself to the maintainers of elm. It would be great to have someone with MacOS at hand there. It's important platform we need to keep supporting.

Will do, thanks!

[sternenseemann]

This can't go to master due to the high amount of rebuilds. I'm also confused – weren't we supposed to be able to build security tool again?

[sandydoo]

I'm also confused – weren't we supposed to be able to build security tool again?

So this just applies the same workaround that was used for x509-system. A lot of packages, including http-client-tls have switched over to crypton-x509-system, which inherits the same issue with security.

I can try out the security-tool approach tomorrowsome time. Has anyone managed to build it?

[domenkozar]

Can we merge this?

[turboMaCk]

I think so. I think usually maintainer of haskell-updates does so but this is already open for some time.

[github-actions]

Successfully created backport PR for staging-24.05:

• [Backport staging-24.05] elmPackages.elm: fix build failure on darwin #318352

[sternenseemann]

I'd still appreciate it if someone could look into packaging the tool properly so we can get rid of these unsatisfactory workarounds!