This probably needs more of an explanation for the issue with this pattern on CHERI than we had downstream

Our pkg is old enough to predate that support, but we're also not doing pkgbase yet, so presumably once it's mature enough upstream for us to adopt it downstream we'll first update pkg.

Won’t that break the dependencies list if clang is itself 32-bit? This also introduces a new hard-coding of the set of compat libraries rather than using _ALL_libcompats.

the "extint-gpio1" check returned NULL

In D54757#1251288, @aokblast wrote:

In D54757#1251272, @jrtc27 wrote:

I don’t understand, other than it sounding like bear is broken

Sorry, the commit message is not clear. I try to explain with more detail. Please tell me if you need anymore information.

When

pwd == $OBJTOP

, and after

run rm -rf "$OBJTOP"

getcwd(3) will return with error since the directory is deleted.

Under this condition:

When shell is executing:

mkdir -p "$OBJTOP"

bear intercepts the libc exec(3) function call and call getcwd in here. As a result, it causes an error.

I don’t understand, other than it sounding like bear is broken

Switching from name ## _baseclasses to basevar ## _baseclasses to avoid the gross #defines you removed seems worthwhile, but I don't see the point of the churn for the rest. Especially since deprecating something that is the only thing being used is a foolish thing to do.

Inline them? There are only 5 calls in total.

Another minor issue is visual distinction between elements. The same colour and text styling (when not hovered over) are used for headings and links here:

In D53910#1245581, @mark_freebsdfoundation.org wrote:

In D53910#1241780, @jrtc27 wrote:

Just looking at the homepage there is some very strange use of whitespace: specifically, there is a lot of extra vertical whitespace in various places that look unbalanced and make the content too spread out, and there is vertical whitespace lacking in the feed headings. See the attachments for before and after fixing these oddities that make the design feel more cohesive, polished and readable.

freebsd.fortasse.cloud.pdf267 KBDownload

jrtc27-freebsd.fortasse.cloud.pdf267 KBDownload

@jrtc27 Where did you make these changes? I can see from the PDFs it is a 'nicer' look — I'd like to put your changes into this edit. Feel free to either ping me the changes as a diff, or just tell me and I'll update the files :) Many thanks!

Will you also be implementing this for csu for static binaries (often forgotten, including by me in the past)?

That's... unhelpful. Also not sure how I managed to miss testing that case :(

(Also this applies equally to Linux, and I believe also on FreeBSD with CROSS_TOOLCHAIN=, though the latter only gets noticed if the host's tools are old enough)

.gitattributes is a footgun and can give confusing behaviour. tools/build/checkstyle9.pl should enforce this for GitHub PRs already, and clang-format can (will?) normalise this too. There are significant downsides for this with little benefit that I can see.

In D54399#1243356, @jhb wrote:

Hmm, looking at the code both before and after this change on armv7, it is just using plain ldrh and strh which will fault on unaligned accesses?

Personally I would avoid confusing GNU C underaligned attributes and just write it in ISO C using memcpy. LLVM will inline the memcpy as load(s) based on the target's unaligned access support anyway. That is:

On this point specifically:

Your response reads to me as dismissive, and this annoys me. Yes, it does not need to be perfect. However, it needs to be good enough, and the feedback I gave was for various aspects in which I do not believe it is good enough for the project. Once live, the world will have to see and deal with it. I have no clue how long it will take to fix the issues I see that make the site look unprofessional or be painful to navigate. This is compounded by the fact that there has been no recent attempt to solicit feedback and get buy-in from the developer community. This feels like it's being pushed forward whether we like it or not, and that is not a good way to build goodwill. I hope you rethink this strategy and don't continue to burn bridges with the developer community.

Oh and what happened to the sidebar for various pages like https://freebsd.fortasse.cloud/where/? They feel rather lacking without that (pages of text and tables with a lot of empty space around them), and there are various pages on the site I've never known how to find without the sidebar...

Other bug reports (all on Safari):

Just looking at the homepage there is some very strange use of whitespace: specifically, there is a lot of extra vertical whitespace in various places that look unbalanced and make the content too spread out, and there is vertical whitespace lacking in the feed headings. See the attachments for before and after fixing these oddities that make the design feel more cohesive, polished and readable.

Move INSTALLEXTRAKERNELS after NO_INSTALLEXTRAKERNELS is set. Hidden by testing originally on CheriBSD where we set NO_INSTALLEXTRAKERNELS to no early for Morello..

D54291

In D54282#1240665, @ivy wrote:

In D54282#1240471, @jrtc27 wrote:

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

Does the confusingly-named NO_INSTALLKERNEL not do what you want?

possibly, but this is an awful hack that works by adding incorrect entries to ${BUILDKERNELS}, which means the logic for create-dtb-package would probably need to be updated to work around that... the amount of new code for this specific change is very small, so i think i prefer doing it this way.

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

So the current code tries 10 times to hit a failure, and will use the last value if all 10 reads succeeded, given the condition after the loop is correct? Importantly, there's no security issue here, because we didn't actually report a successful read when it failed?