My only other feedback from looking at the draft standard was that while we should have LicenseRef-Foo as described in the document, each time we have to do that because the matching score isn't high enough, we should encourage the maintainer to submit that to the SPDX legal team so that they can either tweak the markup for license Foo, or create a new Foo variant if the changes are legally different enough.

In D51414#1175013, @bofh wrote:

In D51414#1174997, @tuukka.pasanen_ilmi.fi wrote:

I've tested few random packages in ports.

• It's bit confusing that check-spdx-license compiles things when one might just want to check license. What I mean is that it should just extract and check license file in current port directory not try to compile whole package?

I think that is what this is doing. It's extracting and checking the license. There is no compiling involved.

Then is just me.. I find it confusing in some tested ports like Go ones just print so much stuff and it looks like it starts compile something.

In D51414#1174997, @tuukka.pasanen_ilmi.fi wrote:

I've tested few random packages in ports.

• It's bit confusing that check-spdx-license compiles things when one might just want to check license. What I mean is that it should just extract and check license file in current port directory not try to compile whole package?

I think that is what this is doing. It's extracting and checking the license. There is no compiling involved.

• Another one what might be easier to user to understand would be if match is 1.0 (I understood that is 100%) it should not be relevant to show other possible licenses?

Yes I have that code hidden and commented around somewhere still in the scripts and waiting for some other's feedback

• It would be nice to see unified diff if license differs from license that is mentioned in ports Makefile.

This is not easy to do. Initially we are actually normalizing the entire documents into a single line to avoid any ambiguity. So the unified diff is not helpful as it prints two huge lines. To have something really readable we have to break into lines again. I will look into it but no promises.

I've tested few random packages in ports.

Fix some corner cases of normalization.

Great, thank you for this work.

I do have the necessary CHANGES entry just not attached it here for keeping it clutter free. I will rerun one more mini exp tomorrow and commit.

Whatever is in the review description will do just fine for the CHANGES entry.

Oh, please add a entry to the CHANGES file too.

Approved as long as it's been tested with a "today" ports tree. ("today" being regarding to the day it will being pushed.)

In D48227#1100097, @rene wrote:

I can hold off branching 2025Q1

I can hold off branching 2025Q1

In D48227#1099827, @bofh wrote:

In D48227#1099753, @freebsd_dev.thsi.be wrote:

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

One other thing in that patch is the removal of USE_OCAMLFIND_PLIST, which make the bsd.ocaml.mk to Uses/ocaml.mk transistion less complicated. USE_OCAMLFIND_PLIST isn't really that useful, to the contrary it makes packaging error more likely (e.g. disabling a feature, not noticing less files are packages), so i think it is better to remove it.

Thanks for the work. Unfortunately due to the holidays and everything it's difficult to count maintainer-timeout and commit some of those patches.

In D48227#1099753, @freebsd_dev.thsi.be wrote:

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

One other thing in that patch is the removal of USE_OCAMLFIND_PLIST, which make the bsd.ocaml.mk to Uses/ocaml.mk transistion less complicated. USE_OCAMLFIND_PLIST isn't really that useful, to the contrary it makes packaging error more likely (e.g. disabling a feature, not noticing less files are packages), so i think it is better to remove it.

Here is the updated patch which converts everything from bsd.ocaml.mk to args for USES=ocaml. See the summary.

I've created https://reviews.freebsd.org/D48228
You can see there how I intended to re-do the USE_OCAML_LDCONFIG. I've been testingthat patch on 15amd64 and 13.3 armv7, everything build fine with the exception of math/coq which fails to build the documentation on armv7...

In D48227#1099727, @bofh wrote:

Hi,

We should have moved out of Mk/bsd.*.mk (except the obvious ones) maybe a decade ago and these are just some technical debts in the Mk directory. :)

So I am just trying to clear of the Mk directory and I plan to merge this before the next quarterly split. [...]

I am still trying to convert some other keywords into args.

We should have moved out of Mk/bsd.*.mk (except the obvious ones) maybe a decade ago and these are just some technical debts in the Mk directory. :)

The full list of arches is here: https://www.freebsd.org/platforms/

ping again

Update diff with more context

Can you re-upload the diff with arcanist or by generating the diff with more context, like arcanist does (git diff -U9999)

LGTM, but I didn't run-test this, as I don't use overlays.

ping

Not sure why but somehow I believe I failed to add this as the review in my commit message. This has already landed.