Via PR 231029
- Giving maintainership to email@example.com
- Use of shebangfix
- Reordering of some variables
- Rework of do-install
Via PR 231029
I can not test this program.
The port is amd64 only because it depends on devel/gnu-efi that is 64 bit only. That's at least on FreeBSD because the upstream project does not say they don't support ia32 (in fact, according to the Makefile, they do).
The override ARCHpart is because $ARCH is "amd64" in FreeBSD but the Makefile expects to check against "x86_64" as it is often reported in Linux.
|14 ↗||(On Diff #47666)|
Sure, you're right.
Since there seems to be chance for this port to be available for i386 (if devel/gnu-efi can be made to work on i386 as it seems possible) I would leave the patch untouched though
I can assist in building/patching but I won't be able to run test it. Unfortunately some of the commits of these ports are a bit confusing. The initial commit in r377068 states the port is amd64 only despite the fact that the description says:
SDK for developing EFI applications for ARM-64, ARM-32, x86_64, IA-64 (IPF), and IA-32 (x86) platforms...
In addition we should be careful with the sensitive software (sensitive in the sense that it is something that deals with private keys and such) and check carefully the other dependent port: sysutils/sbsigntool/
|14–15 ↗||(On Diff #47719)|
I don't think having this is a good idea. The day gnu-efi grows to support more than amd64, someone will have to sweep the tree for dependencies. (I know it was there before.) Poudriere will ignore it because it cannot build gnu-efi, and when building manually, it will fail very early when it tries to build gnu-efi.
|4 ↗||(On Diff #47647)|
Because if devel/gnu-efi supports more than amd64, this port would be hard-coded to amd64 in a patch file which might be hard to find back. And this port itself does not enforce amd64.
Could you add NO_ARCH=yes to the port? poudriere hinted at this:
pkg-static: DEVELOPER_MODE: Notice: arch "FreeBSD:13:amd64" -- no architecture specific files found: