git: bfd726f4a6 - main - Status/2026Q1: Vale fixes

From: Lorenzo Salvadore <salvadore_at_FreeBSD.org>
Date: Sat, 18 Apr 2026 09:08:36 UTC
The branch main has been updated by salvadore:

URL: https://cgit.FreeBSD.org/doc/commit/?id=bfd726f4a6f3bbfab42d4b5c90fd5c4b928dd273

commit bfd726f4a6f3bbfab42d4b5c90fd5c4b928dd273
Author:     Lorenzo Salvadore <salvadore@FreeBSD.org>
AuthorDate: 2026-04-18 09:07:33 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2026-04-18 09:08:17 +0000

    Status/2026Q1: Vale fixes
---
 website/content/en/status/report-2026-01-2026-03/dpaa2.adoc            | 3 ++-
 .../content/en/status/report-2026-01-2026-03/laptop-integration.adoc   | 3 ++-
 website/content/en/status/report-2026-01-2026-03/openjdk.adoc          | 3 ++-
 website/content/en/status/report-2026-01-2026-03/sbom.adoc             | 3 ++-
 website/content/en/status/report-2026-01-2026-03/valgrind.adoc         | 3 ++-
 5 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/website/content/en/status/report-2026-01-2026-03/dpaa2.adoc b/website/content/en/status/report-2026-01-2026-03/dpaa2.adoc
index d7db11ac25..8ae7011569 100644
--- a/website/content/en/status/report-2026-01-2026-03/dpaa2.adoc
+++ b/website/content/en/status/report-2026-01-2026-03/dpaa2.adoc
@@ -16,7 +16,8 @@ Contact: Dmitry Salychev <dsl@FreeBSD.org>
 
 ==== What is DPAA2?
 
-DPAA2 (Data Path Acceleration Architecture Gen2) is a hardware-level networking architecture found in some NXP SoCs which contains hardware blocks including Management Complex (MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O processor (WRIOP, packets distribution, queuing, drop decisions), Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer pools) and others. The Management Complex runs NXP-supplied firmware which provides DPAA2 objects as an abstraction layer over those blocks to simplify access to the underlying hardware.
+DPAA2 (Data Path Acceleration Architecture Gen2) is a hardware-level networking architecture found in some NXP SoCs which contains hardware blocks including Management Complex (MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O processor (WRIOP, packets distribution, queuing, drop decisions), Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer pools) and others.
+The Management Complex runs NXP-supplied firmware which provides DPAA2 objects as an abstraction layer over those blocks to simplify access to the underlying hardware.
 
 ==== Done
 
diff --git a/website/content/en/status/report-2026-01-2026-03/laptop-integration.adoc b/website/content/en/status/report-2026-01-2026-03/laptop-integration.adoc
index c380c4d467..48ef89485a 100644
--- a/website/content/en/status/report-2026-01-2026-03/laptop-integration.adoc
+++ b/website/content/en/status/report-2026-01-2026-03/laptop-integration.adoc
@@ -21,7 +21,8 @@ During this quarter the following items were completed,
 * Set up a link:https://github.com/FreeBSDFoundation/freebsd-laptop-testing/pull/23/files#diff-28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3[GitHub Actions] workflow to auto-run the parser and generate the website upon new merge or git actions from a user
 * Outlined a sub-set of relevant information created by `hw-probe` to be used in the FreeBSD laptop testing workflow
 * Created a link:https://github.com/FreeBSDFoundation/freebsd-laptop-testing/pull/27/changes[pull request] template for the users to follow outlining important features of the laptop that work or not.
-* Developed a scoring system to be used in the application to automatically score laptops based on how many devices on the laptop function or not. Added a workflow that makes manual adjustment of criteria and scores easier for maintainers.
+* Developed a scoring system to be used in the application to automatically score laptops based on how many devices on the laptop function or not.
+  Added a workflow that makes manual adjustment of criteria and scores easier for maintainers.
 * Created Makefile and shell scripts to aid users in running the tests using a simple `make` command within a terminal, complete with user-friendly prompts if required applications are not installed.
 * Tested all laptops and desktops in the Kitchener office with the test suite inside the repository to verify if it works properly across both laptops and desktops
 
diff --git a/website/content/en/status/report-2026-01-2026-03/openjdk.adoc b/website/content/en/status/report-2026-01-2026-03/openjdk.adoc
index 1d93d553f7..37786b3938 100644
--- a/website/content/en/status/report-2026-01-2026-03/openjdk.adoc
+++ b/website/content/en/status/report-2026-01-2026-03/openjdk.adoc
@@ -27,7 +27,8 @@ In this quarter the following issues/milestones were reached:
   - Fixed link:https://github.com/battleblow/jdk/pull/42[spurious issue] where symbol lookup of native symbols from shared objects would sometimes fail.
   - link:https://github.com/battleblow/jdk/pull/38/changes/39130dd99897437101169bddc032431ecf259461[Simplified function] for reading arbitrary memory from traced process.
 * Enabled link:https://github.com/battleblow/jdk/pull/41[building/installing the Hotspot Disassembler] (HSDIS) for FreeBSD.
-  This is needed for some tests for Aarch64 to check that Hotspot generates the correct instruction sequences in various environments. Only supporting the llvm backend for now, though there is no reason to believe the others would not work.
+  This is needed for some tests for Aarch64 to check that Hotspot generates the correct instruction sequences in various environments.
+  Only supporting the llvm backend for now, though there is no reason to believe the others would not work.
 * link:https://github.com/battleblow/jdk/pull/40[Synced ThreadWXEnable implementation] with macOS.
   This enables Hotspot to toggle Write/Execute access to memory segments so that it can generate code to later be executed on Aarch64.
   Just a minor tweak so we align with the API used by the macOS code, even though our implementation is different.
diff --git a/website/content/en/status/report-2026-01-2026-03/sbom.adoc b/website/content/en/status/report-2026-01-2026-03/sbom.adoc
index 5226014c67..9ebdb24e2e 100644
--- a/website/content/en/status/report-2026-01-2026-03/sbom.adoc
+++ b/website/content/en/status/report-2026-01-2026-03/sbom.adoc
@@ -27,7 +27,8 @@ Several missing features have been added and are under active development by pkg
 The tool is now nearly compatible with SPDX Lite 3.0.1 requirements and is ready for general use. +
 Additionally, there is an effort to import pkgconf as part of the FreeBSD source, led by Pierre Pronchery.
 * Adding missing SPDX-License-Identifier to files under the FreeBSD source in the [.filename]#bin#, [.filename]#sbin#, [.filename]#usr.bin#, and [.filename]#usr.sbin# directories.
-* Creating [.filename]#.pc#-files for SBOM. The first patch is expected to land in 2026Q2, starting with files from [.filename]#bin#.
+* Creating [.filename]#.pc#-files for SBOM.
+The first patch is expected to land in 2026Q2, starting with files from [.filename]#bin#.
 
 If you want to help with this effort:
 * Verify that SPDX-License-Identifier licenses are correct and assist with upstreaming files.
diff --git a/website/content/en/status/report-2026-01-2026-03/valgrind.adoc b/website/content/en/status/report-2026-01-2026-03/valgrind.adoc
index 2448ebfeb8..ec4d97e00f 100644
--- a/website/content/en/status/report-2026-01-2026-03/valgrind.adoc
+++ b/website/content/en/status/report-2026-01-2026-03/valgrind.adoc
@@ -18,7 +18,8 @@ The Valgrind regression tests are quite sensitive to that kind of change and som
 The asserts were caused by incorrect assumptions in Valgrind that are used when the tool reads its own binary, mainly to enable it to print its own callstack if there is a crash.
 The final problem was caused by a change in the way that library split debug files files are produced.
 
-Overall, this is more of a stabilization release. There are relatively few new features.
+Overall, this is more of a stabilization release.
+There are relatively few new features.
 
 Valgrind 3.27 is due out at the end of April 2026 and package:devel/valgrind[] will be updated shortly after that.