I have no idea why the release checks fail. The attribute evals just fine when building.

Result of nixpkgs-review run on x86_64-darwin 1

The Agda build was killed manually because it takes so long. The other failures were already broken.

Result of nixpkgs-review run on x86_64-linux 1

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/49

Quoting ofborg:

access to URI 'ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.2-mac-8.3.tar.gz' is forbidden in restricted mode

You should probably switch to an HTTP URL, preferably with a European or US domain.

There's also merge conflicts now.

I don't think the tarball is available through any other means.

We could build from source instead of the patches but I wanted to preserve the previous status-quo as much as possible.

Is that what causes the basic eval checks? Because the URL is unchanged, it was like this before too. The only thing I did change was go from fetchurl to fetchTarball since it's actually a tarball, not just a file.

Alright, I just tried using the exact same fetchurl string again but I still get eval errors. How the hell did it work before and why doesn't it work anymore?

The same ftp server is also used with fetchTarball inside the drv and the eval checks don't complain about that when I comment out the problematic patches fetcher.

What gives?

Should I just give up and build from source instead?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/need-help-on-passing-eval-checks-with-ftp-in-fetchtarball/17673/1

Should I just give up and build from source instead?

YES

In my not so humble opinion, looking at the huge size of this patch, I think the macport should stay separated.
A whole source input, a set of patches, a set of MacOS-only libraries... All of It makes difficult to read and understand the expression.

huge size of this patch

It's not very big IMO. In fact, it removes more code than it adds.

A whole source input, a set of patches

It's one or the other.

a set of MacOS-only libraries

Many were already present for the upstream NS port of emacs which is different from the macport.

All of It makes difficult to read and understand the expression.

I disagree. It's trivial to ignore everything guarded behind things like withMacport and it isn't really all that much here. The emacs drv is simply a pretty complex thing all-together because emacs itself is a complex piece of software. Nothing wrong with that.

The problem with keeping the macport separated is that most of the drv is the same as regular emacs. The only difference would be that you wouldn't have to cater towards Linux toolkits in the macport drv and vice versa.

As macport is being developed with a 28.1 base now, integrating native-comp would mean maintaining even more duplicate code.

Okay then.
Nonetheless your current code is conflicting the repo.

I'll get to that tomorrow hopefully.

this is a great patch! it is sad that it hasn't been merged yet. Have you consider publishing it as an overlay?

it is sad that it hasn't been merged yet

It can’t be merged because it has merge conflicts. The conflicts need to be resolved.

It also can't be merged because there's an odd eval error that I need to get rid of first or rip out the tarball build.

If anyone wants to pick this up, feel free because I'm going to have exams for the next few weeks.

Drafting.

Rebased and now building from source. I'll squash some of these together but the end-result will be the same.

The high number of rebuilds are the emacsPackages, no need for staging.

Thank you all!