In D53085#1212807, @bofh wrote:

In D53085#1212806, @lwhsu wrote:

To my understanding that having those in tests/ci/tools/freebsdci means running in the testvm, right? If so it means the test environment, i.e., the provisioned VM for running full or smoke tests. I feel it's not necessary to do so and this can be done in the build environment, i.e., the env you run the buildworld and buildkernel commands, and building the VM images. That usually means more efficient and we don't really need to do full build in an env to be tested. We just need to build things (for test) in a verified env.

No. This is not possible. I have checked and replenished all possible way for that unless you have an entire better idea for this. Everything can be tested except the date change. Changing the date on the host itself might have catastrophic effect on our build servers and build environment. Which I am not willing to do. And after lots of test on Jenkins and scripts I have come to this conclusion. I am open to ideas but not what you have recommended. Do you remember our discussion that why SOURCE_DATE_EPOCH cannot help us really test the reproducibility on two different dates?

To my understanding that having those in tests/ci/tools/freebsdci means running in the testvm, right? If so it means the test environment, i.e., the provisioned VM for running full or smoke tests. I feel it's not necessary to do so and this can be done in the build environment, i.e., the env you run the buildworld and buildkernel commands, and building the VM images. That usually means more efficient and we don't really need to do full build in an env to be tested. We just need to build things (for test) in a verified env.

I think this is fine. Let's add a longer MFC time (say 2 weeks) to ensure there is no regression.

Oh, right, I was thinking how to deal with the cases of ${ESP} = "yes" and ${ESP} != "yes", but currently we only need to deal with amd64 and aarch64 and they both have ESP=yes so this should be better than the current situation, which only handles amd64. Thanks!

In D52724#1204536, @ziaee wrote:

Will this need any adjusting package base?

actually remove from tools/tools/net80211

misplaced.

In D9157#1203020, @adrian wrote:

In D9157#1203017, @lwhsu wrote:

Not sure if this patch is still making sense, but maybe some parts are still worth to be picked up.

It shouldn't be too hard to clean up and throw into the tree. Is there a doc somewhere showing what this was designed to do and how we'd use it?
(God, being able to do remote GDB / remote console over USB 3 debug ports would be great, I just wouldn't know where to start!)

Not sure if this patch is still making sense, but maybe some parts are still worth to be picked up.

Please corp with the comments about indentation and commit message. Also, we need this MFC to stable/15 at least so please add MFC after: 3 days to be in the next 15.0 build.

In D52159#1196628, @jlduran wrote:

I wonder if we should also check for presence of the public key.

check public key file

In D52159#1194978, @emaste wrote:

Do you know if there's some canonical reference for emitting the fingerprints to the system console on startup? Searching for -----BEGIN SSH HOST KEY FINGERPRINTS----- turns up lots of examples, but if there is some canonical reference it would be good to include here.

Remove unnecessary checks.

Oh, it would be better to have the subject like usb: Implement attach kernel driver function or feature or so.

Suggested commit message:

I'm cleaning up small local changes when sorting my git workspace. This patch may need to be improved, but need to get it out my private tree first.

Consider a MFC ?

Also use Fix: field in the commit message.

I think we also need to update usbconfig(8).

I believe this is good enough. Let's have this in -CURRENT first and if we still want to modify the comment, we can do that in the MFC waiting period and then MFC all the changes together.

Suggested commit message:

In D52101#1189908, @aokblast wrote:

In D52101#1189896, @lwhsu wrote:

In D52101#1189895, @aokblast wrote:

In D52101#1189879, @lwhsu wrote:

I mentioned perhaps making hkbd_no_leds a normal sysctl is that it can be used as a workaround for people in ticket 288968.

I locate the problem inside qemu and do some modification then it works. I will submit a patch to qemu later.

That's great. I feel then we have one more reason to have that sysctl to let people to workaround it before qemu having a new release and being deployed to the production environments.

Wouldn't it means I need to create another patch for that? Why not just use the fix in here?

In D52101#1189895, @aokblast wrote:

In D52101#1189879, @lwhsu wrote:

I mentioned perhaps making hkbd_no_leds a normal sysctl is that it can be used as a workaround for people in ticket 288968.

I locate the problem inside qemu and do some modification then it works. I will submit a patch to qemu later.

In D52101#1189875, @aokblast wrote:

The previous comment is incorrect. I check the HID document. HID has a usage page to locate the LED stuff. And FreeBSD kernel does check if such usage page exists. The problem maybe comes from qemu.

BTW for the commit message should can mention https://bugs.freebsd.org/288968

Adjusted commit message:

The KDSKBSTATE ioctl brings the LED up. However, some keyboards (like qemu
keyboard) may not have LED. Therefore, removing the error check as ukbd(4)
does allow the keyboard works correctly with kbdcontrol(4).

The Torrents page contains both latest production and legacy release versions so we may need to mention this in both places, perhaps under the table of each -RELEASE, or putting in the "Choosing an Image" section. For the wording I suggest saying something like The magnet links to download via BitTorrent protocol are available at link:https://wiki.freebsd.org/Torrents[FreeBSD Torrents Wiki page].

BTW we can mention PR 259673 in the commit message.

I believe you mean “multiple modules”

As there seems no license issue in this patch, hand over this to srcmgr.

in man page and code, there are iad_array and iad_arr, would be nice if this naming can be consistent.

Maybe make it optional and can be set in the config so we have "develop" and "release" modes?