In D36825#836513, @des wrote:

This is @grembo's code.

In D36457#828154, @imp wrote:

In D36457#828129, @grembo wrote:

So definitely nothing that's easy to reproduce it seems.

OK. That's both good and bad. Good that not everybody will hit it, bad that some will and we don't know who / how :(. If you manage to find a way to reproduce it, please let me know.

In D36457#827888, @imp wrote:

NOTE: When setting up the partition, I used the instructions from https://wiki.freebsd.org/UEFI which recommend newfs_msdos -F 32 -c 1. When simply using newfs_msdos /dev/..., the change in loader.env actually did the trick (and I could also list files on the resulting FAT16 partition).

Yea, usually one should only do -F 32 for partitions that are at least 1.25 * minimum size. Any smaller and there's too many buggy UEFI implementations that have heartburn...
These days with 4k sectors, the minimum is 4k x 65527 = 268MB, which means anything smaller than about 300-350MB will be more portable to more UEFI implementations as FAT16. Some guides go so far as to suggest doing FAT16 for < 500MB. However, it's hard to be categorical... We've run into at least one UEFI BIOS that only did FAT32 and the spec seems to suggest that only FAT32 is required. So your milage may vary, though there's a possibility there might be one or more bugs in stand/libsa/dosfs.c (which is what ls would use inside of loader.efi, for example). If you have a reproducible formula, I'll chase that down.

Straightforward and balanced.

@wulf Thanks for reviewing

• Make strlen calculation behave like on Linux (count trailing NUL)

Minor style change

D32369 landed in https://cgit.freebsd.org/ports/commit/devel/git?id=ff5ded75bcda28c580623504e01f5db8eb6be9cf

In D32369#749664, @bdrewery wrote:

Very nice. Thank you!

@garga I think this can be closed.

@garga Didn't find the time to test yet, therefore only suggestions to improve the UPDATING message.

In D30239#710881, @bdrewery wrote:

I've added a foot shooter in https://cgit.freebsd.org/ports/commit/?id=154492dd1f1d8c9a8f9c283f830a737c96e64a10

Thanks for the heads-up!

In D30238#697416, @grembo wrote:

@garga There is a MOVED entry on git-cvs, seems like there was something python based of that name before. So you would need to take care of this to allow the port to build in bulk (non-testport) mode.

@garga There is a MOVED entry on git-cvs, seems like there was something python based of that name before. So you would need to take care of this to allow the port to build in bulk (non-testport) mode.

In D30238#697016, @garga wrote:

@grembo Patch is not applying after latest changes on git port. Could you please rebase it? I finally found the time to work on it, sorry for the delay

Rebase to main

In D30807#695734, @ceri wrote:

'approved', 'allowed', 'rejected': may be clearer.

In D30807#695219, @kevans wrote:

So basically "blacklisted" was not the correct term to begin with.

This is my opinion, yes. I'm still searching for more ideal verbiage

@imp thanks for reviewing

In D30807#695022, @kevans wrote:

IMO this verbiage is all too active for what the feature really does. Trusted certs are trusted because we put them into a directory that OpenSSL understands to mean trusted, while these are simply certs that are not default-trusted.

Actually run mandoc -T lint, fix some more issues found.

@ceri I'm not sure if "untrusted" is a good choice in naming. To me, there were traditionally three levels: