igir: 2.11.0 -> 3.0.1-unstable-2024-09-27, adding support for darwin

[docbobo]

Pronounced "eager," Igir is a zero-setup ROM collection manager that sorts, filters, extracts or archives, patches, and reports on collections of any size on any OS.

This PR achieves two things that are described in more detail below: upgrading to version 3.0.1, and enabling platform support for Darwin.

2.11.0 -> 3.0.1-unstable-2024-09-27

Version 2.11.0 of igir already contains some pre-built binaries that require their dependencies to be updated via autoPatchelfHook. Version 3.0.0 (and thus 3.0.1) adds two more binaries that require this treatment: chdman and maxcso.

During testing of the proposed changes it was determined that the build for aarch64-linux did not include the maxcso binary. Further investigation showed that this is an upstream problem: a subsequent commit to v3.0.1 updates the maxcso to a version that fixes "Linux x86 and ARM64".

As a result, this PR picks up a commit for igir that comes shortly after the v3.0.1 tag. Changes between the two relevant commits are minor dependency updates, mostly for development packages and documentation.

Support for Darwin

Similar to Linux, the Darwin build requires patching of binaries since the bundled ones are compiled against homebrew libraries found under /opt/homebrew. However, no hook comparable to autoPatchelfHook seems to exist (fixDarwinDylibNames does not apply in this scenario) at this point in time, and patching is done "manually" via install_name_tool on a case by case basis.

Tests

Since the whole process of manually patching binaries is somewhat more fragile than using autoPatchelfHook, this PR also introduces two test cases that execute chdman and maxcso to determine if they start correctly. As a nice side-effect, the maxcso test case also breaks with the stock v3.0.1 because the maxcso binary is missing there (at least on aarch64-linux).

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[eljamm]

Please format this with nixfmt-rfc-style.

[eljamm]

Looks good to me. @docbobo, can you squash the commits with git rebase -i?

[eljamm]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 372184

---

x86_64-linux

✅ 1 package built:

• igir

---

x86_64-darwin

✅ 1 package built:

• igir

---

aarch64-darwin

✅ 1 package built:

• igir

[keenanweaver]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 372184

---

x86_64-linux

✅ 1 package built:

• igir

[docbobo]

Not sure how many approvals this needs, but can you wait with merging this (in case 2 is already sufficient)? I just noticed something that should be fixed.

[docbobo]

Just to give a quick update: I realized that there is another binary that requires patchelf/install_name_tool patching: maxcso. While the patching itself is no big deal, I noticed that the binary itself seems to be missing on linux-aarch64. It is present on Darwin and I also believe that it's present on Linux-x86_64 - its presence was probably the reason for the build failure that was observed before.

After some digging and banging my head against the wall, I figured out that this is fixed in HEAD by picking up a slightly newer version of maxcso-js. According to the commit log, this version fixes "Linux x86 and ARM64".

At this point, the only option to get v3.0.1 consistently running on all platforms is to cherry-pick the updated maxcso-js which I am doing with a patch to package-lock.json and package.json. When igir gets a newer version in the future, that patch needs to be removed.

In order to ensure future correctness, I am also including tests.

[docbobo]

I'll happily squash into one commit at the end, but for now I'd like you to see the difference between now and the previous state.

[docbobo]

BTW, I could've just picked a newer igir commit, the one that introduces the update to v0.1380.8, but that would've included a few more dependency updates and I wanted to keep the difference to the tagged version as minimal as possible.

[keenanweaver]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 372184

---

x86_64-linux

✅ 1 package built:

• igir

[docbobo]

Okay, so I guess this has reached its final state for now then?

[eljamm]

Yes, but it would be great if you can also change the commit and PR titles and use the unstable version.

[eljamm]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 372184

---

x86_64-linux

✅ 1 package built:

• igir

---

x86_64-darwin

✅ 1 package built:

• igir

---

aarch64-darwin

✅ 1 package built:

• igir

[eljamm]

Looks good to me. Thanks a lot for your efforts and for maintaining this!

[docbobo]

So what's needed to get this over the actual finish line (aka. merge)? More approvals? Just curious.

[keenanweaver]

Time, patience, and the attention of a committer. More info here. It's a pain point that hopefully will be resolved in time.