cc @thoughtpolice

@GrahamcOfBorg build tamarin-prover

No attempt on aarch64-linux (full log)

The following builds were skipped because they don't evaluate on aarch64-linux: tamarin-prover

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)

Attempted: tamarin-prover

/nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1/bin is not in
the system search path.
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1
shrinking /nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1/bin/.tamarin-prover-wrapped
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1/bin
patching script interpreter paths in /nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1
checking for references to /build in /nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1...
/nix/store/arfvnwrrada8n2yprmcp9z2w231v0pyg-tamarin-prover-1.3.1

Success on x86_64-darwin (full log)

Attempted: tamarin-prover

installing
Installing executable tamarin-prover in /nix/store/35frawdcyc50qg46b8f4r6avraf9pj9c-tamarin-prover-1.3.1/bin
Warning: The directory
/nix/store/35frawdcyc50qg46b8f4r6avraf9pj9c-tamarin-prover-1.3.1/bin is not in
the system search path.
post-installation fixup
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/35frawdcyc50qg46b8f4r6avraf9pj9c-tamarin-prover-1.3.1/lib  /nix/store/35frawdcyc50qg46b8f4r6avraf9pj9c-tamarin-prover-1.3.1/bin
patching script interpreter paths in /nix/store/35frawdcyc50qg46b8f4r6avraf9pj9c-tamarin-prover-1.3.1
/nix/store/35frawdcyc50qg46b8f4r6avraf9pj9c-tamarin-prover-1.3.1

@Mic92 in the future, please don't merge these changes so hastily. This change bumped Tamarin from what was effectively a version of 1.3.1 (actually the 1.4.0 version upstream, though, since the version is bumped immediately after every release, meaning they were basically the same at the time) to a prerelease version of 1.4.0, using a commit from a few days ago.

It was not simply a compilation fix, but effectively a major change including months of code differences. This should have been reflected with a version number change, at minimum, which I would have held off merging based on since it left it at 1.3.1.

The real fix for #40078 (most likely, I'm guessing -- I haven't looked closely) would have been to adjust the Haskell dependencies to be more constrained; we likely need to be a bit more strict and fix some version numbers more tightly. (Tamarin is more of an end-user application than a Haskell development library, so fixing version/compiler numbers independently of whatever is tracked-by-default in haskellPackages is OK, IMO.)

However, Tamarin Prover 1.4.0 was released today, and I have a patch that bumps it to a proper released tag with the proper version attribute set, so this is not a huge issue. Please double check major code-bumps like this next time if you would, though; simply comparing the two upstream sha256 revisions would have shown a delta of ~3 months of changes. Much appreciated.

(Also, in this particular case, the Tamarin developers are very active about reaching out to downstream maintainers and helping them upon every release, so updates for Tamarin should be relatively on-time anyway, I hope!)

@wchresta Thank you for the change! If something else needs to be fixed, please CC me on a ticket and I'll try to get to it. In the future, for changes that fix build failures, please let me know if you plan to advance the version "away" from the released one; ideally stable application versions should only require minimal patching to keep working vs big upgrades. Sometimes that's not possible though

@thoughtpolice thanks for the explanation! The main reason why I decided to bump the "version" from 1.3.1 to the current development state was because there was never an actual 1.3 in the master branch - so we were effectively always on the development branch. Should have probably been more careful, sorry about that.
We should probably clear the dependencies up to get rid of the dirty fix - as you suggested. If I have time in the near future, I'll see if I can get to it.