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?

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.

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.

Fixed comment about mtree latest update.

Not sure about the snapshot wording, but that's similar to what we've don in the past.
Thank you for creating this revision!

greatly simplify based on cperciva feedback.

I'm inclined to skip the "figure out if we need to reboot or just restart services" complexity at this point because

incorperate suggestions by @bapt. Do not reboot unless kernel is updated. In all other situations, including situations where only the pkg database is updated, just restart all services.

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?

VERY GOOD!

In D56646#1297538, @carlavilla wrote:

Thank you so much for taking care of this :)

Thank you so much for taking care of this :)

In D56381#1295504, @ziaee wrote:

note, i like a blank line at the end of scripts for cat reasons. if we don't want this, i can remove it, but it doesn't hurt anything and we do it all over the place.

In D56381#1295529, @ziaee wrote:

use logic inspired from @lwhsu to prevent reboot if nothing happened. compare the file size in bytes of the pkg database instead of using pkg inf and checksum to save water/coal. tested on my laptop

In D56381#1295532, @ivy wrote:

@lwhsu out of interest, how do you end up with a system that has FreeBSD-base packages installed but doesn't have pkg bootstrapped?