For the PR make sure to use a commit message trailer "PR: 296419" so that it gets copied to the bug.

Oops

Some suggestions, style polishing, commit dates check.
Great work, Vladlen!

In D57262#1312511, @cperciva wrote:

Looks good to me. I assume you've tested it?

Yes, I have tested it. It works with releng, stable and main branches.

Looks good to me. I assume you've tested it?

While the wiki will continue to evolve, it may be helpful as a pointer to the effort in case people want to know more.

In D57100#1308693, @fuz wrote:

Please link to the wiki page if possible.

@ziaee Alexander , what do you think about linking to wiki? Relnotes are long living documents with stable content, but wiki can be changed in any moment.

Changed to your proposed version.

For me is ok, thanks for the improvements you are making to this tool

This version showed warnings

What do you think?

I like that idea

I added the review https://reviews.freebsd.org/D57133

In D56646#1309125, @vladlen wrote:

In D56646#1299250, @ziaee wrote:

Sorry I didn't have time to review this. This is absolutely wonderful, thank you so much for doing this. I wanted this for a long time but couldn't make it myself. Could you make the links also bold to match the drivers without manuals?

@ziaee

Hi Alex,
I am preparing the next fix for this script (replace '\[' to '[' , mandoc generates \[, if driver descrition has [ in the text).

I could also add the feature you are asking for.
Now hardware-notes-processor.rb generates messages to stdout and skips processing.
The current list for 15.1R is:

WARNING: The manual page man4.i386/ep does not exists

WARNING: The manual page man4.i386/ex does not exists

WARNING: The manual page man4.i386/fe does not exists

WARNING: The manual page hme does not exists

WARNING: The manual page pcn does not exists

WARNING: The manual page sf does not exists

WARNING: The manual page sn does not exists

WARNING: The manual page tl does not exists

WARNING: The manual page txp does not exists

WARNING: The manual page man4.i386/vx does not exists

WARNING: The manual page wb does not exists

WARNING: The manual page xe does not exists

WARNING: The manual page man4.i386/ce does not exists

WARNING: The manual page man4.i386/cx does not exists

WARNING: The manual page man4.i386/cp does not exists

WARNING: The manual page man4.i386/ctau does not exists

WARNING: The manual page ufintek does not exists

I have other proposal.
If line
&hwlist.man4.i386/ep;
generates this warning

WARNING: The manual page man4.i386/ep does not exists

then I can put this line again into the hardware.adoc. It can be easily found by '&hwlist' string.

1. If this driver is not supported by this release, then this line can be manually removed one time.
2. if driver supported by it does not have HARDWARE section, this line will be updated

next time, when HARDWARE section added before reease date.

3. If HARDWARE section is not added, this line will be removed day before release.

In this case hardware.adoc will be improved during every run
make generate-hardware-notes
One times to copy from template and every run to add new HARDWARE sections.

What do you think?

In D56646#1299250, @ziaee wrote:

Sorry I didn't have time to review this. This is absolutely wonderful, thank you so much for doing this. I wanted this for a long time but couldn't make it myself. Could you make the links also bold to match the drivers without manuals?

@ziaee

I think this is a bit too verbose. We don't need to list every single API change, as most of them are rather minor and uninteresting.

LGTM!

fix comment typos, thanks @cperciva!

implement cperciva/lwhsu sha256 suggestion, thanks guys!

In D56381#1302616, @bapt wrote:

In D56381#1302615, @cperciva wrote:

Fair point, but I'm a little bit concerned about this being brittle -- /var/db/pkg/local.sqlite is not a public interface for pkg, so there's no guarantee that a future pkg won't (a) change that path, or (b) touch that file even if nothing has changed. I don't want to suddenly discover in FreeBSD 16.3 that VMs aren't rebooting after applying security updates because something changed in pkg.

that is a valid concern from @cperciva I don't think I will change anything in that area, but yes the content of /var/db/pkg is supposed to be opaque. (I know I am the one who recommended the mtime check in the first place).

In D56381#1302615, @cperciva wrote:

In D56381#1302566, @ziaee wrote:

In D56381#1302390, @cperciva wrote:

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

I think pkg info | sha256 would work? If any packages are updated (or installed or removed) then that hash will change.

I think it would work too, but I don't see why we wouldn't want to stat the mtime in between updating and upgrading instead. By my rough estimate, time(1) shows 0.08 real for the pkg info | sha256, but for stat -f %c /var/db/pkg/local.sqlite it shows 0.00 real, so, that's less electricity, right?

Fair point, but I'm a little bit concerned about this being brittle -- /var/db/pkg/local.sqlite is not a public interface for pkg, so there's no guarantee that a future pkg won't (a) change that path, or (b) touch that file even if nothing has changed. I don't want to suddenly discover in FreeBSD 16.3 that VMs aren't rebooting after applying security updates because something changed in pkg.

In D56381#1302566, @ziaee wrote:

In D56381#1302390, @cperciva wrote:

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

I think pkg info | sha256 would work? If any packages are updated (or installed or removed) then that hash will change.

I think it would work too, but I don't see why we wouldn't want to stat the mtime in between updating and upgrading instead. By my rough estimate, time(1) shows 0.08 real for the pkg info | sha256, but for stat -f %c /var/db/pkg/local.sqlite it shows 0.00 real, so, that's less electricity, right?

In D56381#1302390, @cperciva wrote:

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.

I think pkg info | sha256 would work? If any packages are updated (or installed or removed) then that hash will change.

In D56381#1302386, @ziaee wrote:

ok, what if we separate the pkg update, and take the state after updating, but before upgrading, then we will actually know if the upgrade did anything. maybe because of this we can simplify the logic at the end a bit more.