smlnj: 110.95 -> 110.99.6.1

[Skyb0rg007]

Description of changes

Standard ML of New Jersey is updated to 110.99.6.1.
Change log can be found on the smlnj.org website.

Outside of updating hashes, this version bump allows the removal of the heap2exec.diff file, since the build system issue was fixed. It also requires a slightly different regex to pass to sed during patching.

The compiler binary and libraries have been extensively tested. The other binaries all run but have not yet been as extensively tested.

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.

[smancill]

LGTM

[jasoncarr0]

@thoughtpolice Can this be merged?

[smancill]

@thoughtpolice Can this be merged?

No, there are merge conflicts.

[Skyb0rg007]

One remaining issue is the use of a timestamp in the build process.
There is a call to the SML function Time.now during build, which is output on startup. This means that the build is currently not fully reproducible.

If this is an issue, I could try to add a patch that fixes the date of the version release.

[jasoncarr0]

One remaining issue is the use of a timestamp in the build process. There is a call to the SML function Time.now during build, which is output on startup. This means that the build is currently not fully reproducible.

If this is an issue, I could try to add a patch that fixes the date of the version release.

I'm not the maintainer but I think adding a small patch to fix this would be the best. If it must be a time/date it's typically the unix epoch and that is overall pretty straightforwardly clear where it's coming from / since it's in nixpkgs the user can check the path to determine what build it was from nonetheless.

[Skyb0rg007]

Although the call to Time.now is in a specific file (base/system/smlnj/internal/version.template), that code is ran by the boot file which is downloaded as binary. I can try to get a change made upstream but it will take time, and the existing nixpkgs derivation has this same issue, so I do not think it should block merging.

[Skyb0rg007]

I got verbal confirmation that this will be fixed in the next upstream release. I think it doesn't make sense to implement the patch in Nix since it cannot be done via patch, especially since it already exists in the current nixpkgs version.

[Skyb0rg007]

110.99.6.1 fixes a bug, but also changes removes the build-time dependency. This should fix the non-reproducibility issue.

[thoughtpolice]

This looks fine, but collapse these commits into one; that's a typical policy for many packages here. There is no reason to have the intermediate updates when they will be immediately superseded anyway due to bugfixes or whatnot.

[Skyb0rg007]

Should be squashed now. Do I need to document the changelog, or link to the changelog on smlnj.org anywhere?

[thoughtpolice]

No. If you write an update script so that updates are automatic, then the @r-ryantm can normally do the links and stuff for you. But I wouldn't worry about it for now.

[thoughtpolice]

Approved, but needs a rebase after the maintainer update.

[Skyb0rg007]

Should be fixed now.
Regarding the update script, I have a Perl script that I can use to manually update the nix file, but unfortunately there aren't many examples of packages with update scripts which have multiple hashes to update. Can take a look here if that's something worthwhile to add, though with SML/NJ only updating once a month it's fine to keep it manual for now.

[thoughtpolice]

An example of updating multiple hashes is here, in another package I maintain, if you're interested: https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/tools/build-managers/buck2

In short, I'd recommend you just generate .json file somehow and then just use builtins.fromJSON (builtins.readFile ./hashes.json) in order to read the JSON into a nix attribute set. Handling everything from there is something I'm sure you can figure out.

Update scripts like this are a little fragile but it's often not too bad if you expect things won't change much e.g. as the maintainer of that package I know buck2 isn't going to change drastically, so it's worked reliably for months even though it just does sed and stuff.

In any case I'll merge this once I see the CI go green.