Shorter line and use the :H modifier instead ../

In D51443#1178659, @emaste wrote:

Why would we not do this unconditionally?

In D51443#1179395, @jrtc27 wrote:

To make this work in cheribuild I passed INSTALL="sh /path/to/src/tools/install.sh". Doing something automatically here that works would be good, though I'd want confirmation from someone like @sjg that ${.OBJDIR}/.. is definitely going to always be world's ${OBJTOP}.

To make this work in cheribuild I passed INSTALL="sh /path/to/src/tools/install.sh". Doing something automatically here that works would be good, though I'd want confirmation from someone like @sjg that ${.OBJDIR}/.. is definitely going to always be world's ${OBJTOP}.

Why would we not do this unconditionally?

Fix possible symlink problem for ports.txz as well.

In D51335#1172765, @emaste wrote:

I think ports.txz has the same issue and should get the same fix. (Aside, please upload diffs with full context (e.g. with -U999999))

I think ports.txz has the same issue and should get the same fix. (Aside, please upload diffs with full context (e.g. with -U999999))

In D50331#1157176, @dch wrote:

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

Address some of the issues mentioned here.

I like this article. A lot. No specific feedback, just a general comment - who is the target audience for this?

I see, so we are not planning to disable them at this time. Sorry for the noise.

LGTM

It would be very good to get this committed (to main) before this week's snapshots

In D47942#1094368, @bofh wrote:

In D47942#1094365, @bz wrote:

@bofh are you going to commit this?

To be frank, although I wear a re@ hat, we have strict directives from @cperciva not to commit to /release without his approval. As he is in AWS REINVENT for now; I am not sure how this works. :(

In D47942#1094365, @bz wrote:

@bofh are you going to commit this?

@bofh are you going to commit this?

I am still contemplating if we should simply put the cache-dir outside the

In D47942#1093222, @emaste wrote:

want to remove the repo data in the cache and unregister the pkg itself like what we do in VM

Perhaps, but I think this issue is fundamentally different than the VM case and I would suggest we both make this (D47942) change and MFC it as soon as we can, and consider following up with further changes.

want to remove the repo data in the cache and unregister the pkg itself like what we do in VM

In D47942#1093167, @lwhsu wrote:

That's a good catch, and not sure if we also want to remove the repo data in the cache and unregister the pkg itself like what we do in VM. Having those might cause an issue when pkg is boostraped but repo data is seriously out-of-date. We encountered this in the past in the cloud images.

That's a good catch, and not sure if we also want to remove the repo data in the cache and unregister the pkg itself like what we do in VM. Having those might cause an issue when pkg is boostraped but repo data is seriously out-of-date. We encountered this in the past in the cloud images.

Thanks Mitchell!

Thanks! That seems much more reasonable than what I was thinking.

I'd drop all the changes before 12.x. The CS driver was around for a long time. I forget which release we dropped it in, but changing things older than 12 is likely not a good idea.

Missed a spot, sorry.

Yes. I also wondered if the website could have the template build as "CURRENT" continuous release notes so we'd have an almost constant view of the expansion and the state of FreeBSD main AS-IS.

In D47272#1084351, @mhorne wrote:

Thank you so much! I will screenshot these in the future.

This is indeed an improvement. On its own the change is non-controversial, so if @bofh does not reply today I will just commit it.

Thank you!

If you do not use arc diff --create/--update please upload a diff -U9999 so that there is context to be displayed.

I'm sorry, I won't do it again. I thought it would be a hilarious way to ping.

Please don't accept your own revisions. That's implied ;-)

Bump dates

Yes. Going to do so now.

Can you bump .Dd on all these (I'll also need to do on iwm.4 given I forgot)

Correct I missed another spot, some of my slashes were backwards.

I did miss a spot.
The table in urtw looked ever so slightly off, turns out the syntax was completely wrong (e.g. mdoc(7) says mdoc files should never have a tab for any reason, but the linter didn't see that.
Also, every network device driver manual afaik uses driver in the title, except a few, so fix those.

Once this is settled, I'll begin writing a section in style.mdoc(5) describing preferred style for hardware section in manuals, so we can make it more consistent going forward.

@bofh ping6

I'll just get this in; we'll have a few days until we'll expand anything from this file again.

Use a bullet list for hardware
While here improve some language and fold pesky lines.

In other words, I'd prefer the way iwlwifi got rendered over the way rtw88 got rendered.