Add changelog

Hope to hear from pi@ soon. This tool helped me to migrate a lot of accounts with ease.

In D52303#1196821, @jrtc27 wrote:

It does appear both macOS and GNU date support -Iseconds. However, my concern with this change is that such timestamps are rather uglier and less human-readable, which is less of a problem for build system messages but more so for uname. I note that Linux uses LC_ALL=C date output for its uname, running uname -a on an Ubuntu system.

Drop PORTREVISION

Bump revision

Example from Proxmox:

root@pve-1:~# uname -a
Linux pve-1.ppmd.siemens.net 6.14.8-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.8-2 (2025-07-22T10:04Z) x86_64 GNU/Linux

Just update the port

In D52303#1196821, @jrtc27 wrote:

It does appear both macOS and GNU date support -Iseconds. However, my concern with this change is that such timestamps are rather uglier and less human-readable, which is less of a problem for build system messages but more so for uname. I note that Linux uses LC_ALL=C date output for its uname, running uname -a on an Ubuntu system.

In D52303#1196819, @cperciva wrote:

In D52303#1196813, @michaelo wrote:

Interesting...I'd like to know how it could break it.

Well, date -I is not POSIX. So it might produce no output, or an odd error message instead.

Update UPDATING

In D52303#1196812, @cperciva wrote:

I like the idea, but this might break on cross-building from non-FreeBSD systems. @jrtc27 can you comment on this? I know you do such things.

Folks, any opinion on this? This is a readability and internationalization improvement.

Just noticed that I should update UPDATING as well.

Maintainer timeout is approaching, any opinion here?

Maintainers, any objections?

In D52329#1195479, @markj wrote:

In D52329#1195478, @michaelo wrote:

@markj , would you mind to backport it as well? Very useful!

Yes, that's what "MFC after" in the commit log message refers to.

@markj , would you mind to backport it as well? Very useful!

I am fine with the change as long as this is met: https://reviews.freebsd.org/D52158#1192019

Nice idea, hopefully this will be backported.

I agree with @jlduran, all three should be covered. I applied the patch locally and the issue is gone.

Already removed by @rene.

@des done

Waiting for a format approval from mentors.

In D52304#1194232, @ziaee wrote:

This is good with me since compression is stated as a default earlier in the page, but like @diizzy said, a more specific commit message for our readers would be expedient, like:

bsdinstall/zfsboot examples: zap compress comments

Remove compression comments from examples as zroot datasets are compressed by default since FreeBSD 1?.? [0].

[0] {$COMMITID}

add ref to default compression

In D52304#1194192, @diizzy wrote:

In D52304#1194191, @michaelo wrote:

In D52304#1194190, @diizzy wrote:

You might want to add a refence?

You mean https://github.com/freebsd/freebsd-src/blob/fb37e38fbe99039a479520b4b596f4bfc04e2a88/usr.sbin/bsdinstall/scripts/zfsboot#L52-L54?

More like historical, this has been the case since the inital commit of zfsboot
https://github.com/freebsd/freebsd-src/blob/cd88b8869f9b2c280b1de02608f52fdf497b4cb1/usr.sbin/bsdinstall/scripts/zfsboot

In D52304#1194190, @diizzy wrote:

You might want to add a refence?

Used the following search pattern: grep -r -e '$(date' -e '$( date' -e 'date' -e 'C date' --exclude '/tests/' --exclude '/sys/contrib/' --exclude '/contrib/' --exclude '/tools/' --exclude '/crypto/' . --color`

@mikael, exp-run is complete. No related failures. Are we good to approve and merge this one?

Folks, any opinion on this? Waiting for the port maintainer...

Now waiting for the maintainer...

Generalize patching

You also forgot to delete the expired distrusted one.

You can completely remove: untrusted/Explicitly_Distrust_DigiNotar_Root_CA.pem: Not After : Mar 31 18:19:22 2025 GMT

You need to update ObsoleteFiles.inc as well, no?

In D52158#1191948, @des wrote:

In D52158#1191856, @michaelo wrote:

The last time I worked on this I checked every untrusted CA whether the it is authentic because there could be a change in the format and our script didn't notice. ran the current bundle from curl (https://curl.se/docs/caextract.html) and our output by Copilot.

I didn't bother reading beyond this point.

I did check this thoroughly. Eight formerly trusted certificates are no longer trusted. “Baltimore CyberTrust Root” has expired and was dropped outright. The other seven moved to untrusted: “GLOBALTRUST 2020” had a “distrust after” date which has now passed, and Mozilla switched the remaining six from “trusted delegator” to “must verify”, cf. Mozilla bug 1957685.

The last time I worked on this I checked every untrusted CA whether the it is authentic because there could be a change in the format and our script didn't notice. ran the current bundle from curl (https://curl.se/docs/caextract.html) and our output by Copilot. They don't match:

Thanks for the detailed list! I checked the [Mozilla CA bundle used by curl](https://curl.se/ca/cacert.pem)and compared it against your list. Here's a summary of **mismatches**—certificates you marked as **Trusted** or **Untrusted** that **do not appear** in the Mozilla bundle:

@antoine is performing exp-run...

Rebase

Will wait for rust reviewers for a couple of more days.

Folks, is this change something we should abandon or still worth considering for 15?

Fix invalid change

Completely updated to version 5 and thus renamed. Maintainer didn't take any action for years since 5.0.2 is almost a year old. I took the liberty to take ownership of this port since (a) of the former and (b) I do use it in production and it is a low-profile port. It builds now just fine with 3.12.

In D51804#1190438, @tijl wrote:

It's just to respect AR and CC. I discovered this on a system where everything is built with ports llvm (no base system compiler installed).

In D51461#1190378, @scottl wrote:

I responded to Michael in private just now. For posterity, my advice is to release the self-imposed vendor lock, they stopped officially supporting freebsd many years ago.

In D51461#1190376, @otis wrote:

In D51461#1190360, @michaelo wrote:

In D51461#1190358, @eugen_grosbein.net wrote:

Maybe Scott has something to say on the topic.

I wrote him weeks ago. No response.

You probably don't know, but Scott Long gave up on FreeBSD completely. For $reasons.

In D51802#1190361, @yuri wrote:

Committed.
Sorry for the delay.

In D51461#1190358, @eugen_grosbein.net wrote:

Maybe Scott has something to say on the topic.

Let me give you guys background why I started this in the first place. We need a bunch of new servers from HPE which include MR408i-o RAID controller with Broadcom SAS3908 ROC for OEMs. I had a hell of a time to figure out which chip that it and which driver supports this card. Spent days. Hoped Broadcom would answer. What I have figured out that the PCI device IDs don't match the manpages (read outdated) and you have to read the source code. After a longer discussion with @eugen_grosbein.net on the Russian FreeBSD TG channel and Git archeology we figured out that @kadesai has added support many years ago (https://cgit.freebsd.org/src/commit/?id=2909aab4cfc296bcf83fa3e87ed41ed1f4244fea), but never touched the manpage. IMHO only Broadcom or @imp are able to properly update this manpage.

In D51461#1190299, @jrm wrote:

@michaelo, have you heard back from Kashyap Desai?

@mikael Do you want to take a look at this as well?

In D51804#1190233, @mikael wrote:

You have my approval if it doesn't break ports (you can ask for an exp-run)

In D51804#1190231, @mikael wrote:

Are any ports broken without (or with) this patch?
I really have no clue why this patch is (or isn't) necessary.

Related issue: https://reviews.freebsd.org/D51802

Maintainer timeout?

Anyone willing to review?