xar: 1.6.1 -> 498

[tie]

Description of changes

This change switches the xar package from unmaintained fork of the original project to the Apple Open Source tarball. We also add some patches from Debian/Gentoo on top, but otherwise the patch set is original and fixes some longstanding bugs (i.e. I’ve spent a considerable amount of time to ensure that all tests provided in the tarball are passing). If merged, Nixpkgs would probably be the only distribution that actually runs xar tests…

See also https://repology.org/project/xar/versions

Things done

• Built on → for platform(s)
  • x86_64-linux
  • aarch64-linux
  • aarch64-linux → aarch64-linux (pkgsMusl)
  • aarch64-linux → aarch64-linux (pkgsStatic)
  • aarch64-linux → x86_64-linux (pkgsCross.gnu64)
  • 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/)
  Built darwin.apple_sdk.MacOSX-SDK.
• 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.

[tie]

Mostly ready for review, but there are some test failures because of mismatching mtime in pkgsMusl.xar.tests.integrationTest (that is, with musl in particular).

[emilazy]

Thanks for this impressive effort, by the way! Really nice to see clean‐ups like this.

[reckenrode]

Also, sorry about causing the merge conflict. I did a search for PRs against the Darwin stdenv but missed this one. I reformatted the stdenv in #333962 because I anticipate doing quite a bit of cleanup while working on the SDK refactor, and it’s easier/nicer if I can work on a formatted stdenv.

[tie]

Also, sorry about causing the merge conflict.

It’s OK, I’ll have to update the PR with suggested changes anyway and it’s just a single line change in stdenv for separate outputs.

[tie]

Rebased, addressed previous review comments, should be ready for another round of reviews.

[emilazy]

Diff looks good, reproduced the build and tests (pure and impure) on aarch64-linux and aarch64-linux. Happy to merge once @reckenrode has taken another look and once someone reproduces the build on x86-64.

[reckenrode]

I haven’t run the tests or tried to build it, but the changes look good to me.

[JohnRTitor]

Built on x64-linux.

[emilazy]

Lots of warnings like this on x86_64-darwin:

xar> src/xar.c:810:23: warning: 'xar_get_safe_path' is only available on macOS 12.0 or newer [-Wunguarded-availability-new]
xar>                         const char *file = xar_get_safe_path(f);
xar>                                            ^~~~~~~~~~~~~~~~~
xar> include/xar.h:269:7: note: 'xar_get_safe_path' has been marked as being introduced in macOS 12.0 here, but the deployment target is macOS 10.12.0
xar> char *xar_get_safe_path(xar_file_t f) API_AVAILABLE(macos(12.0));
xar>       ^
xar> src/xar.c:810:23: note: enclose 'xar_get_safe_path' in a __builtin_available check to silence this warning
xar>                         const char *file = xar_get_safe_path(f);
xar>                                            ^~~~~~~~~~~~~~~~~

I can’t tell if this is using a system library that actually won’t be available, or if the xar code itself is defining that function so it’ll be okay?

[reckenrode]

It’s defined at https://github.com/apple-oss-distributions/xar/blob/eaeb03d085970f94938dc6785cd86d22eaa54b47/xar/include/xar.h.in#L268. The availability annotation could be removed since nixpkgs will be shipping the same dylib regardless of deployment target.

[emilazy]

Seems reasonable. It shouldn’t cause anything worse than warnings to leave it in, though, right?

[reckenrode]

Probably shouldn’t cause any issues other than warnings unless one uses -Werror.

[emilazy]

Let’s merge this as‐is for now and we can make a decision about whether to patch the availability stuff out of the headers in another PR. Thank you for the great work as always, @tie!