FreeBSD The Power to Serve

FreeBSD Status Report Fourth Quarter 2025

Here is the fourth 2025 status report, with 28 entries.

Since allowing late submissions leads to reports consistently coming out months late, it has been decided to change it. Starting from next quarter, report submission will have a deadline on the 14th of the first month past the end of quarter and this deadline will be actually enforced for everyone, including committers and teams. Then the full status report shall be published as soon as assembled (probably within the end of the month) with the entries that were submitted within the deadline.

Reports will not be chased anymore. If you miss the deadline, just submit a broader report next quarter.

This new strategy should help each report remain fresh, relevant, and timely.

For more information, please see https://docs.freebsd.org/en/articles/freebsd-status-report-process/#_timeline.

Have a nice read!

Lorenzo Salvadore, on behalf of Status Team

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the Administration Page.

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://freebsdfoundation.org/
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://freebsdfoundation.org/donate/
Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://freebsdfoundation.org/journal/
Foundation Events URL: https://freebsdfoundation.org/our-work/events/

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

The FreeBSD Foundation is a 501(c)(3) non-profit dedicated to advancing FreeBSD through both technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters.

OS Improvements

Throughout the quarter, there were 346 src, 72 ports, and 58 doc commits sponsored by the FreeBSD Foundation.

Refer to the following report entries describing much of that committed development work:

Other highlights include:

  • A new kqueue1(KQUEUE_CPONFORK) facility to copy kqueue into the child on fork

  • exterror(9) infrastructure for asynchronous io and geom

  • libuvmem(3) usermode port of vmem(9)

  • Fixes for anonymous memory corruption

  • Fine-grained support for groups and manual page MFCed to 14

  • Bug fixes

    • A 32-bit mdo(1) on a 64-bit FreeBSD would always fail with EINVAL

    • Panic when using mdo(1) and resource accounting is enabled (kern.racct.enable set to 1)

  • MAC system reviews

  • Kick-off of S4 (hibernate) support

  • Background work on VFS (in particular supporting unionfs changes)

The Foundation also continued to support two major initiatives: the Laptop Support and Usability project (in collaboration with Quantum Leap Research) and an infrastructure modernization project commissioned by the Sovereign Tech Agency. For background on both efforts, see the 2025Q1 quarterly status report.

We began preparing for FreeBSD’s 22nd consecutive participation in Google Summer of Code (GSoC). Those interested in contributing project ideas or mentoring are encouraged to contact soc-admins@FreeBSD.org.

Advocacy

In the fourth quarter of 2025, our advocacy work focused on expanding our educational video content, reaching more viewers than ever, bringing the community together for a productive Vendor Summit, and reflecting on the work that is helping sustain and grow interest in FreeBSD. Here are just a few of the ways the Foundation advocated for FreeBSD in Q4 2025:

Continuous Integration and Workflow Improvement

The Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise.

Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you!

FreeBSD Release Engineering Team

Links:
FreeBSD 15.0-RELEASE announcement URL: https://www.freebsd.org/releases/15.0R/announce/
FreeBSD 14.4-RELEASE schedule URL: https://www.freebsd.org/releases/14.4R/schedule/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/

Contact: FreeBSD Release Engineering Team, <re@FreeBSD.org>

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things.

The Team managed 15.0-RELEASE, leading to the official RELEASE build and announcement in December; this was the first release from the new stable/15 branch. As part of this, considerable work went into setting up a system for securely building, signing, and distributing package repositories for the 15.0-RELEASE base system.

Planning has started for the upcoming 14.4-RELEASE cycle.

The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches, and started providing weekly development snapshot builds for the new stable/15 branch.

Projects

Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.

Alpha-Omega Beach Cleaning project

Links:
Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev
Alpha-Omega on GitHub URL: https://github.com/ossf/alpha-omega
FreeBSD Foundation URL: https://freebsdfoundation.org
Project repository from the FreeBSD Foundation URL: https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

Alpha-Omega’s mission is to catalyze sustainable security improvements to critical open source projects and ecosystems. After a successful project with the FreeBSD Foundation in 2024 — auditing the bhyve hypervisor and the Capsicum sandboxing framework — Alpha-Omega has selected FreeBSD again, for the Alpha Omega Beach Cleaning project this time. This new grant consists in generally improving the security and maintenance of third-party software within the FreeBSD base system. The FreeBSD Foundation received the grant and is managing and executing the project.

Since the previous report from 2025Q3, the following tasks have been completed:

  • Inventory of dependencies

  • Security risk assessments

  • Propose list of priorities

  • Plan the respective actions

  • Formalize code owners

A global database file contains the information collected for the project, in collaboration with the SBOM initiative sponsored by Germany’s Sovereign Tech Agency. Its structure has also been simplified in the past few months, but remains in the YAML format. It is available like before as database.yml.

The aobc-generate Go program in the repository has been renamed to aobc-tool. In addition to the previous deliverables, it is now able to generate a collection of SBOM files. This is performed through intermediate files in the pkg-config format, which are then converted into SPDX thanks to the bomtool program from the pkgconf project:

This information includes the respective code owners identified for each third-party component. The aobc-tool program is also able to suggest the known code owners for a given part of the source tree. All of the code owners listed have been contacted in December 2025 to inform them about the project, and to confirm their association with the component.

The feedback collected so far has only been positive, including a suggestion to package the tool into the FreeBSD ports. However, it seems more relevant as of now to rewrite the tool in a way suitable for inclusion into the base system, e.g., in Lua.

Finally, the remaining tasks will be performed until the end of the first quarter of 2026:

  • Integrate review methodologies

  • Plan execution & coordination

  • Final report

This initiative was presented to the srcmgr committee in November. Their input and feedback will be taken into account through this last phase of the project.

Monthly reporting is submitted to alpha-omega and available as before on GitHub for 2025 and soon for 2026 as well.

Sponsor: Alpha-Omega, The FreeBSD Foundation

Converting VuXML to Open Source Vulnerability database

Links:
FreeBSD OSV database for pkg URL: https://github.com/illuusio/freebsd-osv/blob/main/db/freebsd-osv.json
FreeBSD Vulnerabilities for year 2025 in Markdown/Commonmark format URL: https://github.com/illuusio/freebsd-osv/tree/main/md/2025
Lua OSV tool URL: https://github.com/illuusio/freebsd-osv/blob/main/bin/osvf-tool.lua
Python VuXML to OSV conversion tool URL: https://github.com/illuusio/freebsd-osv/blob/main/bin/convert_vuxml.py
pkg PR for OSV URL: https://github.com/freebsd/pkg/pull/2558
OSV Schema pull request URL: https://github.com/ossf/osv-schema/pull/237
OSV issue to track down OSV integration in Google OSV GitHub repository URL: https://github.com/google/osv.dev/issues/3901
FreeBSD PURL effort URL: https://github.com/package-url/purl-spec/pull/496

Contact: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

The Open Source Vulnerability database effort has been ongoing since May. The target for this effort was to produce an OSV database and retire the old VuXML database format.

Currently, there is a test database and a pull request for pkg(8). The test database can be updated from VuXML and converted to OSV JSON format. Needed tooling to update and create a merged database file for pkg is complete. There is also exporting for Commonmark which renders fine in GitHub.

Additionally, upstream support for FreeBSD in the OSV Schema has been implemented, allowing OSV files to be validated against official sources. There has also been an effort for PURL that is slowly moving forward.

If you want to help with this project, here are some tasks:

  • Verify that conversion from VuXML to OSV is accurate

  • Verify that pkg can use the OSV database and produces correct output

Sponsor: The FreeBSD Foundation

FreeBSD Software Bill of Materials

Links:
pkgconf PR 429 which adds spdxtool URL: https://github.com/pkgconf/pkgconf/pull/429
SPDX Lite 3.0.1 documentation URL: https://spdx.github.io/spdx-spec/v3.0.1/
FreeBSD SPDX 3.0.1 JSON-LD file: FreeBSD.jsonld URL: https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning/blob/illuusio/update-licenses/json-ld/FreeBSD.jsonld
Source files to make SBOM URL: https://github.com/illuusio/freebsd-src/tree/freebsd-sbom/share/sbom
Current status of license gathering for SBOM in Markdown file URL: https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning/blob/illuusio/update-licenses/license.md
Add sbom target to Makefile and needed Lua scripts URL: https://reviews.freebsd.org/D53318
Lua functions to handle make command output for specific FreeBSD ports targets URL: https://reviews.freebsd.org/D53317
Add Lua Logging module to FreeBSD ports tree and introduce Lua functions and modules to ports URL: https://reviews.freebsd.org/D53316

Contact: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

The Software Bill of Materials (SBOM) project has been ongoing since May, with the goal of providing the necessary tooling to create SBOMs from FreeBSD Ports and the base system.

One of the major developments in 2025Q4 was upstreaming spdxtool to the pkgconf upstream. The upstreamed code ensures that pkgconf tools have an SPDX Lite 3.0.1 profile-compatible SBOM creation tool with the next release.

Another significant effort has been gathering information about applications that form part of the FreeBSD base system. These applications are primarily located in the usr.bin, usr.sbin, sbin, and bin directories inside FreeBSD git repository. The FreeBSD Alpha Omega Beach Cleaning project has been instrumental as it gathers information about third-party libraries and applications, and I have contributed to this effort. Now there is Lua scripts and a file that can produce the needed files for pkgconf’s spdxtool, which can be exported in SPDX JSON-LD format.

Tools using this gathered information and current raw data can be found in my fork of the FreeBSD src tree. Mainly, all C and header files that hold SPDX-License-Identifier are now gathered and processed.

There have also been efforts to upstream SBOM creation per package for FreeBSD Ports, but this has stalled and needs updating.

If you want to help with this effort:

  • Add SPDX-License-Identifier headers to C and header files under the FreeBSD src.

  • Verify that the files current SPDX-License-Identifier is correct.

  • Verify that the gathered information is accurate. Currently, all tools that have some man page for section 1, 7, and 8 are added, with descriptions taken from the man page using a script. These may be incorrect.

Sponsor: The FreeBSD Foundation

Full CPUID Control for bhyve

Contact: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>

Introduction

Operating system kernels as well as certain user space libraries and programs often need to know what CPU model they are running on and which architectural features are available for use. On x86-based platforms, the CPUID instruction can be used to query the CPU for all of this information.

In a virtual machine environment, not all of the information reported by the host CPU should be made available to the VM guest, some other CPU information such as for system topology needs to be modified to match the VM configuration, and then there is some additional information that needs to be reported that no real CPU supports, such as the hypervisor identification.

Thus as part of its normal operation as a hypervisor, bhyve emulates the x86 CPUID instruction for its VM guests. At this time, most of the CPUID information from the host CPU is passed to the VM guest with some features masked out, and it also reports synthetic information about the hypervisor, its capabilities, and its configuration. None of this is presently explicitly configurable in bhyve.

Motivation

Being in full control of the CPUID information emulated for the VM guest has a variety of important use cases:

VM Migration

In order to migrate a running or suspended VM between different VM hosts, usually both involved VM hosts have to be running on the same or at least feature-compatible host CPU families, models, and steppings. Even slight differences in CPU model and stepping may cause a difference in the featureset available.

Being in control of the CPUID information for the guest VM allows the operator to restrict the VMs to use a common subset of the CPU features shared by all VM hosts the VM is possibly going to run on, which could also be based on an abstract x86 architecture level, rather than a real CPU model.

This is currently supported by QEMU/KVM on Linux and equivalent support in bhyve is a key step towards supporting fully-featured VM live migration.

Fixed CPU Model

Some software checks the CPU family/model/stepping and also the CPU brand string for software compatibility reasons. A change in those parameters due to migration of a VM or a hardware change in the VM host would be detected and could be considered a system change, potentially disabling a proprietary software license. Being able to use a pre-defined CPU model, be it based on a real CPU or an architectural subset, would avoid this problem entirely.

Hypervisor Signature Modification

Some software such as the Nvidia drivers check the hypervisor signature to match certain known values. Bhyve identifies itself as "bhyve bhyve ", while KVM reports "KVMKVMKVM\0\0\0". While implementing a command line switch to change the hypervisor signature of bhyve on a per-VM basis would be possible without full CPUID control, an implementation of this feature utilizing full CPUID control would be more natural and lead to a cleaner design.

Feature Masking & Architectural Downgrade / Upgrade

Being able to easily downgrade or upgrade the CPU model, or mask individual feature bits can provide benefits to operating system and application development and testing.

Current state of CPUID control for bhyve

A basic implementation of the vmm kernel part for CPUID control has been available in bhyve on illumos for a number of years now. This code was written by Oxide for use with their Propolis hypervisor, which is based on the kernel components of FreeBSD/bhyve that have been ported to illumos without using any of bhyve’s userspace code.

Like all bhyve improvements made on illumos, the vmm kernel code for CPUID control is dual-licensed CDDL and BSD. It has been ported to bhyve on FreeBSD under the BSD license. As a proof of concept, new config options for CPUID control have been implemented in the bhyve userspace, showing the potential of the full CPUID control on bhyve.

Project Overview

Ongoing work on this project aims to integrate the existing proof-of-concept work into FreeBSD, and to add the following usability features:

  • a user-friendly configuration method to override individual bits, parts or even whole CPUID functions as needed, while keeping the rest of the host CPUID information or a pre-defined CPUID configuration

  • a user-friendly configuration method for the hypervisor signature reported by bhyve

  • a set of predefined CPUID configurations based on common x86 architecture levels, perhaps also including a set of CPUID data for a few real CPU models, and a user-friendly configuration method to choose one for a VM

Sponsor: The FreeBSD Foundation

Infrastructure Modernization

Contact: Ed Maste <emaste@FreeBSD.org>
Contact: Alice Sowerby <alice@freebsdfoundation.org>

The project started in Q3 of 2024 and was commissioned by the Sovereign Tech Agency with a budget of $745,000, to be spent until the end of 2025. The main goals are to improve security tools for the base system, ports, and packages, update the project’s infrastructure to speed up development, enhance build security, and make it easier for new developers to get started.

For more detailed information and updates, please visit the new project information repo.

Q4 update

All five work packages are complete as of the end of December 2025 and the project is closed. At the time of writing (mid-December) some elements are still in review and these have been handed over to Foundation staff to land appropriately.

Work Package A: Technical Debt Reduction

This work package was completed in September 2025. The project successfully ran alongside the setting up of the FreeBSD Project’s Source Management team as they created and embedded their new processes to make bug management easier and more sustainable.

The scope was co-created with srcmgr@.

Work items are as follows:

Work Package B: Zero Trust Builds

This work package has made it possible to build FreeBSD reproducibly, and without requiring root privilege.

The detailed scope was co-created with core@, srcmgr@, secteam@.

Work items are as follows:

  • Must

    • No-root for all source release build cases/artifacts (complete)

    • Src artifacts to build reproducibly (complete)

    • Formalize and document make world and release.sh (in review)

  • Should

    • Remove privilege from orchestration tooling (descoped due to an alternative solution being likely in the medium-term)

    • Move build scripts into the public repository (in review)

    • Address dependencies (complete)

  • Could

    • Environment Standardization (in review)

    • Ports to build reproducibly (in review)

    • CI to verify reproducibility (in review)

    • Documentation to allow 3rd parties to confirm reproducibility (in review)

Work Package C: CI/CD Automation

This work package has improved CI/CD automation to streamline software delivery and operations for new and existing software by modernizing and securitizing the existing CI/CD system and extending it to cover the third party packages in the FreeBSD Ports Collection.

The detailed scope was co-created with core@, srcmgr@, portmgr@, doceng@.

Work items are as follows:

  • Must

    • Improve quality of incoming commits (in review)

    • Pre-merge CI (complete)

    • Environment Metadata (complete)

    • Extend CI to the Ports tree (in review)

    • CI Threat Model (in review)

    • CI Management Process (in review)

    • Documentation (in review)

  • Should

    • 3rd-party Interoperability (in review)

    • Automated analysis in tests (in review)

    • Test Case Management (in review)

  • Could

    • Granular Debugging (in review)

Work Package D: Ports and Packages security improvements

This work package improved security for the FreeBSD Ports and Package Collection in several ways. We added support for the OSV (Open Source Vulnerability) format, which is a standardized way to describe security vulnerabilities. We also built basic tools to download vulnerability information from global security databases, with a particular focus on the NIST Common Platform Enumeration (CPE) Dictionary.

The pkg(8) tool can now create and read CPE strings, though it does not yet support CPE JSON format. We wrote new test cases for CPE and OSV parsing, and updated the existing pkg(8) security audit tests. Additionally, we created a test repository that converts FreeBSD vulnerability data to OSV format, which works with pkg(8). This test repository has been reviewed for accuracy, and the process of converting from the old FreeBSD VuXML format to the new OSV format is now straightforward.

The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@.

Work items are as follows:

  • Must

    • New Database Format (complete)

    • Set up 2+ Database Instances (descoped due to time constraints)

    • Migrate Data from old to new database (POC complete)

    • Add support for new format in pkg(8) (complete)

    • Upstream engagement (complete)

    • SBOM on demand (in review)

    • Document how to set up build and test targets (in review)

    • Integrate 3rd party test targets (descoped due to time constraints)

    • Continuous Testing (in review)

  • Could

    • Make CI artifacts available (descoped due to time constraints)

Work Package E: SBOM improvements

This work package delivered foundational improvements to the tools and processes for generating the FreeBSD Software Bill of Materials (SBOM).

We made changes (currently under review) to consolidate individual provenance data from both the base system and ports trees into a unified, higher-level view. We also created tooling that can scan the FreeBSD source tree and generate an SBOM report covering the entire software stack.

The FreeBSD ports tree already had good metadata for creating SBOMs and established tools for tracking package dependencies, so our SBOM solutions for ports are now mature and in the review stage. However, the FreeBSD base system uses a completely different build system, with SBOM information scattered throughout the repository. The main challenge here has been gathering all the dependencies and package information into one place. As a result, SBOM creation for the FreeBSD base system is still at the technical preview stage with only example data currently available.

A follow-on project has been commissioned for early 2026 to build on the foundational elements and develop a full, robust SBOM solution.

The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@, releng@.

Work items are as follows:

  • Must

    • Evaluate projects/solutions available in the wider ecosystem (complete)

    • Propose the target solution for SBOM (in review)

    • Produce an SBOM in CI (e.g. weekly builds) (descoped due to time constraints)

    • Produce an SBOM as an artifact as part of the release process (partially complete)

    • SBOM artifact on demand (in review)

    • Roll up existing data (in review)

    • Record and explain decisions made (in review)

  • Could

    • Engage with other similar projects (complete)

Commissioning body: Sovereign Tech Agency

Parthenope — Design and ideas

Link:
Parthenope Repository URL: https://gitlab.com/alfix/parthenope

Contact: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>

Parthenope is a modular, two-step installer for the FreeBSD operating system, written primarily in Lua. The installation process is divided into two phases:

  1. In the first step, configuration files and installation commands are generated using a variety of interactive interfaces.

  2. In the second step, the actual system installation is executed based on the previously created files.

The project is simple, extensible, and flexible. It is designed to support multiple frontends, languages, installation modes ("Auto", "Easy", and "Expert"), interactive levels, and logging options.

Parthenope began as a personal project to answer a simple question: "What features would I want when installing FreeBSD on my laptop?" It has since evolved into an open source tool that anyone can use, adapt, or extend to meet their own requirements.

During this quarter:

  • The motivations, a proof of concept, and some screenshot previews were presented at EuroBSDCon 2025, slides.

  • The ISO image generation script and the internationalization subsystem were refactored.

  • A public repository was created.

At the moment it is not yet possible to install FreeBSD. The next steps are:

  • Refactor the configuration file.

  • Refactor the subsystems: logging, modes, phase-2, etc.

  • Implement the installer components: partitioner, network manager, date/time, etc.

In the initial phase, the only frontend will be a Text User Interface, very similar to bsdinstall, the default FreeBSD installer. Additional frontends will be added in the future.

QEMU vmm Accelerator Support

Links:
Project Link URL: https://wiki.freebsd.org/SummerOfCode2025Projects/VMMAcceleratorSupportForQEMU
Code (FreeBSD fork) URL: https://github.com/dumrich/freebsd-src
Code (QEMU fork) URL: https://github.com/dumrich/qemu.git

Contact: Abhinav Chavali <abhinavchavali12@gmail.com>

Description

This project aims to implement a vmm(4) accelerator backend for QEMU. By interfacing QEMU with FreeBSD’s native hypervisor infrastructure, users can run virtual machines with near-native performance using hardware virtualization extensions (VMX/SVM), similar to how KVM functions on Linux. This combines the extensive device emulation ecosystem of QEMU with the performance of the FreeBSD kernel hypervisor.

Status

The backend is now functional enough to boot a FreeBSD guest using a single vCPU. The core infrastructure for interfacing QEMU with libvmmapi is in place. Crucially, interrupt controllers (8259 PIC, IOAPIC, LAPIC) are now successfully utilizing the kernel’s vmm implementations rather than userspace emulation.

Open Items & Call for Help

While the heavy lifting is complete, there are key areas where community contributions would be highly valued to get this merged upstream:

  • Guest SMP Support: Currently, the guest is limited to 1 vCPU. We are looking for assistance in debugging the existing loop/thread handling in the backend to enable multi-CPU support.

  • Device Offloading: The RTC and HPET timers are currently still emulated in userspace by QEMU. These need to be reworked to use the vmm in-kernel versions for better performance and correctness.

  • General Stability: As with any hypervisor backend, we need help with edge-case testing and stress testing across different guest OS types.

I would like to thank Google for the sponsorship, and the FreeBSD Project for the mentorship and opportunity to contribute to the system.

Sponsor: Google Summer of Code 2025

Sylve — A Unified System Management Platform for FreeBSD

Links:
GitHub URL: https://github.com/AlchemillaHQ/Sylve
CI URL: https://sylve-ci.alchemilla.io
Discord URL: https://discord.gg/bJB826JvXK

Contact: Hayzam Sherif <hayzam@alchemilla.io>

Sylve is a modern, unified system management platform for FreeBSD, inspired by Proxmox. It provides an integrated web interface for managing virtual machines (via Bhyve), Jails, ZFS storage, networking, and firewalling.

The backend is implemented in Go, while the frontend is built with SvelteKit, Tailwind CSS, and ShadCN UI components.

The project emphasizes a minimal system footprint. By default, it only requires the following packages:

Optional runtime dependencies, required only when their respective features are used, include:

Q4 Progress Highlights

Storage

  • ZFS Management: we now use GitHub - gzfs that is a go wrapper around zfs/zpool/zdb CLI to provide full support for creating and managing ZFS pools and datasets. This has improved performance and reliability compared to our previous implementation.

  • VM and Jail storage management: During the initialization user can pick the pool(s) where VM (disks/zvols) and Jail (datasets) will be created, and all the disk/dataset creation will be done under the hood automatically.

Jails

  • Support for Linux Jails using the FreeBSD Linuxulator has been added. Users can create, manage, and monitor Linux Jails via the web interface. It is still considered experimental but we have tested extensively with Rocky Linux and Alpine.

  • A bunch of improvements to jails has been added where in people can now supply a lot more options when creating/editing/viewing thick jails.

Virtual Machines

  • Cloud-Init Support: Sylve now supports Cloud-Init for automated VM provisioning. Users can provide Cloud-Init configuration during VM creation/editing.

  • Serial Console: A web-based serial console for VMs has been implemented, allowing users to access the VM console directly from the Sylve UI.

Networking

  • DHCP Server: A web UI around dns/dnsmasq has been added, we allow creation of Ranges, Reservations, and Options.

Utilities

The downloader now supports automatic extraction of various archive formats including .tar.gz, .zip, .xz, and .bz2 and also supports automatic conversion of disk images to raw format.

General

Sylve now requires FreeBSD 15.0 or later, as we now depend on features like Jail metadata, and ZFS v2.4.0+ which includes JSON output for many commands that we rely on.

We also have made numerous improvements to the UI/UX, performance optimizations, and bug fixes across the platform, some of them include:

  • Improved graphing with the ECharts library for better performance and interactivity.

  • Enhanced accessibility features to ensure compliance with WCAG standards.

  • Internationalization (i18n) support with the help of Wuchale, starting with Hindi (hi) translations for the UI.

  • Backend optimizations for faster data retrieval and reduced load times.

  • Removed several frontend dependencies (notably tanstack), opting for lighter alternatives to reduce overall bundle size and improve load times.

Roadmap Update

Some clustering work is still ongoing. Once completed, we will release full project documentation and begin packaging Sylve for easy installation via pkg.

We are also developing a new, tightly integrated backup system within the Sylve monorepo, enabling simple backup and restore of VMs, jails, and configurations.

Sponsor: The FreeBSD Foundation

Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

Suspend/Resume Improvement

Links:
Blog URL: https://obiw.ac/s0ix/
BSDCan talk on s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Sleep testing image URL: https://people.freebsd.org/~obiwac/s0ix/
Tip of the s2idle/S0ix + AMD SMU stack URL: https://reviews.freebsd.org/D48721

Contact: obiwac <obiwac@FreeBSD.org>

Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD.

This will allow modern Intel and AMD laptops, some of which do not support ACPI S3 sleep, to enter low power states to increase battery life.

Entry to S0i3 is now working semi-reliably on the Framework 13 AMD Ryzen 7040 series laptops on FreeBSD 15.

The sleep type and sysctl code has been committed, and a fix for a regression that introduced made (D53909). Because of some existing issues in our ACPI D-state code causing some devices which were previously working to fail entering S3, related commits for D-state changes necessary for S0ix had to be rolled back, though these do not seem to affect S0i3 entry on the aforementioned machine. Work has been made on cleaning up and fixing our D-state code, but this is not a huge priority so long as it does not prevent S0i3 entry on the targeted machine(s).

The s2idle and SPMC revisions (D48734 and D48387 respectively) have been reviewed and have had some work done on them to prepare them for being committed. New exploratory revisions have been made to implement the s2idle loop (D54406 and D54410) and some necessary scheduler changes (D54407 and D54409).

Some issues have cropped up when resuming from S0i3, seemingly only when loading the USB4 driver, which have been looked into.

A pre-built sleep testing image is available to easily test S0i3 entry on machines. Detailed instructions are on the webpage.

With respect to the links, the blog post entry is still outdated.

Sponsor: The FreeBSD Foundation

Audio Stack Improvements

Contact: Christos Margiolis <christos@FreeBSD.org>

I have been working on the audio stack since 2024Q1. Below is a list of the previous status reports:

2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements
2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements
2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements
2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements
2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements
2025Q2 URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements
2025Q3 URL: https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements

Important work since last report:

You can also follow the development process in freebsd-multimedia@, where I post regular reports.

Sponsor: The FreeBSD Foundation

LinuxKPI 802.11 and Native Wireless Update

Links:
Support the MediaTek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Support the Realtek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/99

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

This report focuses on the efforts using permissively licensed Linux wireless drivers, mostly unmodified, on FreeBSD, as well as preparing the native net80211 stack for support of newer standards.

Driver updates

With vendor updates to Linux v6.16 being stalled in the last quarter for a conflict with drm-kmod and later an nvidia-drm problem we update to v6.17-based drivers right before the 15.0-RELEASE deadline in September. Unfortunately multiple fixes did not make it anymore in time for the release. In the aftermath we also had to fix graphics/drm-515-kmod and had to correct LinuxKPI code to unbreak SR-IOV for mlx5en.

In December we started tracking Linux v6.18 for some drivers. More will likely follow or we will go straight to v6.19-rcN to benefit from upstream improvements.

Firmware

With the update of drivers to newer versions a few firmware files needed updates. The automated way we used to use for iwlwifi(4) no longer works so we now pick all we can get but still try to classify the files into flavors for as long as we can. The wifi-firmware ports framework got completely switched to only shipping plain firmware files and no more kernel modules. This means that kernel updates no longer require package upgrades and firmware can be updated independently (for most). Firmware for all the other drivers supported (or unsupported) also got updated.

Intel iwlwifi support

A few bug fixes were implemented, mostly related to the fact that the iwlwifi(4) mvm sub-driver now officially got split up into mvm and mld in the newer versions. Also support for 1x1 cards, such as AX101, which suffered a firmware crash with 11n and 11ac, got fixed.

Mediatek mt76 chipset support

After finally finding some laptop in which the MT7922 card could be used for development, which was not the main WiFi slot of my framework laptop, we had packets passing at basic rates within 10 days. The mt76 driver continues to be blocked on the LinuxKPI struct page conflict and further page pool work. A pull request for the master branch for drm-kmod was opened to try to deal with possible conflicts for struct page changes upfront. Work is ongoing to support 11n and 11ac rates. Further mt76 supported chipsets will be added over time, likely the MT7925 next.

Realtek rtw88 and rtw89 11n and 11ac support

Some Realtek chipsets had/have problems with the LinuxKPI compat implementation to work or not crash. At least one rtw88(4) chipset will not associate (or scan properly), while the rtw89(4) driver can cause a panic at times. Work to improve some of this is on the way. In addition work to support 802.11n and 802.11ac rates with these drivers is also on the way. BlockACK support got sorted and rtw89(4) seems fine with RX but is still stuck on basic rates for TX. The latter is likely caused by newer driver downcalls which we are now starting to support in LinuxKPI to address the issue.

Sponsor: The FreeBSD Foundation

GENEVE Tunnel

Links:
Add Support for Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172

Contact: Seyed Pouria Mousavizadeh Tehrani <info@spmzt.net>

I have been working on GENEVE tunnel implementation for three months and it is now under review. GENEVE creates a generic network virtualization tunnel interface for tenant systems over an L3 (IP/UDP) underlay, providing Layer 2 (ethernet) or Layer 3 services using the GENEVE protocol.

Here is what I have done:

  • Support for unicast and multicast underlay for both IPv4 and IPv6.

  • Jail support and per-VNET geneve tunnel.

  • RXCSUM/TXCSUM/TSO offload capabilities.

  • Support for inheritance and configuration of ToS, TTL, and DF values.

  • Support for NETLINK/WITHOUT_NETLINK for if_geneve.

  • Updated ifconfig to support tunnel creation and modification using NETLINK for if_geneve.

  • Wrote man page for geneve(4) and updated ifconfig(8) to include geneve parameters.

  • Wrote tests.

Dependencies and related reviews to support geneve implementation:

  • Bug fix on netlink dump assignment D54190 (done)

  • Bug fix on netlink credential inheritance 54109 (under review)

  • Update ECN tunneling behavior per RFC6040 (required by GENEVE) 53516 (under review)

The review is large because I implemented features that are already available on other platforms before submitting. You can help to speed up the process by reviewing and providing feedback on phabricator.

Kernel Rust Support

Links:
rust KPI repository URL: https://github.com/ayrtonm/freebsd-kpi-rs
virtio sound rust driver URL: https://github.com/ayrtonm/freebsd-src/tree/virtio_snd

Contact: Ayrton Muñoz <a.munoz3327@gmail.com>

I have been adding support for using rust in the kernel and writing device drivers with it. Rust is a good tool for taking existing rules about how pointers may be used and enforcing them with the type system. These rules are often implicit in C meaning additional mental bookkeeping for developers. Rust will not prevent every bug, but it lets developers avoid some of this and focus more on implementing the functionality they care about.

The rust KPIs are currently under development and not very stable, but there is no dependency on the wider rust ecosystem or unstable language features/APIs. This means that they should eventually be able to provide as much stability as equivalent C KPIs and upgrading to newer rust toolchains should not introduce breakage. It also provides as much transparency as C about when allocations happen since it uses a non-allocating subset of the rust standard library. Different kernel subsystems will require rust wrappers, but these can build off of the base functionality provided in the rust KPI repository.

I have been experimenting on and off with this since late 2024 and development mainly happens in my rust KPI repository. This repository also has makefiles and patches for config(8)/build system integration. The easiest driver for developers to build and try themselves is my virtio sound driver. Some interfaces it uses are in flux, but the driver is functional enough for music playback in QEMU. That branch also includes rust wrappers that may be reused for other virtio devices or sound/PCM drivers.

Only x86-64 and aarch64 are currently supported. Other architectures supported by LLVM can be added if there is interest, but I wanted to initially focus on just a few use-cases. Aside from QEMU I have also been testing rust drivers on hardware with some drivers for ARM64 Apple machines. This was the initial use-case and involves taking some WIP drivers I started helping with in 2024 and porting the greenfield parts to rust. This is mostly low-level drivers, but also includes the DockChannel HID driver for the keyboard on the M2 MacBook.

At some point in early 2026 the rust KPIs should be stable enough for interested developers to try writing new code with them. They will not be perfect, but I want to make sure they work roughly like existing drivers expect and also fit the expectations of rust developers before asking for testers. Hopefully the Apple drivers will be back up to parity with the initial WIP in C in the first half of 2026 as well.

USB Kernel Debugging Improvements

Contact: Tom Jones <thj@FreeBSD.org>

XHCI USB controllers offer a mode which allows them to be used as a system debugging interface. XHCI debug uses a special USB 3 cable with VBUS, D+ and D- disconnected. The feature can be used to live debug the FreeBSD kernel, enabling investigation of issues which cause the system video console to lock up and there is not an alternative such as a serial console. This can happen when debugging issues with graphics drivers.

Hiroki Sato developed support for the XHCI debug interface and made it available as some in progress git branches. This implementation enables FreeBSD to operate as both a Debug Host and a Debug Target, with support for debugging from the loader through to the kernel.

In this quarter there has been significant debugging of the debug interfaces associated with the host side of xhci debug. A custom board was designed to support two debug modes with USB-C, xhci debug and the USB-C Debug Accessory Mode (DAM). DAM enables an alt mode for USB-C connectors, on some devices such as 2025 Framework laptops and the desktop this mode enables access to a SOC UART for debugging.

Further revisions of the hardware are needed to create a complete xhci USB-C adapter and a more fully featured DAM adapter.

Reviews have been created for the loader portion of the implementation and several changes have been extracted out and landed in the tree.

Sponsor: The FreeBSD Foundation

Architectures

Updating platform-specific features and bringing in support for new hardware platforms.

FreeBSD Driver Development for BananaPi-R64

Links:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi

Contact: Martin Filla <freebsd@sysctl.cz>

Introduction

The Banana Pi R64 is a MediaTek MT7622-based development board (ARM Cortex-A53, dual-core ~1.35 GHz) featuring 4× Gigabit LAN, 1× Gigabit WAN, Wi-Fi (4×4n), Bluetooth 5.0, and multiple peripheral interfaces (UART, SPI, I²C, GPIO, SATA, mini-PCIe, eMMC, etc.).

Current State of FreeBSD Support

Implemented so far:

  • UART driver

  • Clock management (clocks)

  • Pinctrl

  • Storage controllers (eMMC/SD/MMC) driver

  • Ethernet Switch mt7531 driver

  • Ethernet mt7622 driver

  • XHCI driver

  • Watchdog driver

  • RTC driver

  • RNG driver

  • Pciecfg driver

  • SysIRQ driver

Development roadmap

Implement missing drivers:

  • USB3 / T-PHY

  • SATA / AHCI / T-PHY

  • Wi-Fi (likely MediaTek MT7615)

  • GPIO subsystems

  • I2C

  • SPI

  • PWM

  • PCIE

Work in progress drivers:

  • T-PHY

Documentation

Noteworthy changes in the documentation tree, manual pages, or new external books/documents.

Accessibility Handbook

Link:
FreeBSD Accessibility Handbook URL: https://docs.freebsd.org/en/books/accessibility/

Contact: FreeBSD Accessibility mailing list <freebsd-accessibility@FreeBSD.org>
Contact: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>

In recent reports, the new Accessibility Handbook was announced and its reviews were published. The handbook aims to document the assistive technologies available in FreeBSD, covering both the base system and the Ports Collection.

During this quarter:

At present, the handbook describes assistive technologies related to visual disabilities. It is part of the Vision Accessibility project sponsored by the FreeBSD Foundation. The handbook is structured into two parts and six chapters:

  1. Help — Covers how to request assistance effectively through appropriate FreeBSD communication channels.

  2. Virtual Terminal — Documents vision-related accessibility features of the FreeBSD virtual console (vt(4)).

  3. Colors — Explains how to configure color schemes, including high-contrast themes and adjusting screen colors for ambient lighting.

  4. Low Vision — Outlines accessibility tools in graphical desktop environments for users with low vision, such as screen magnifiers, readable fonts, and scaling.

  5. Blindness — Describes assistive technologies for blind users, focusing primarily on screen readers and compatible tools.

  6. Development — Provides resources for developers to make their software accessible, test accessibility, and improve support for users with visual impairments.

The handbook deliberately avoids images and minimizes non-plain-text elements to enhance compatibility with assistive technologies. Tips and new ideas are welcome. If possible, send reports to the FreeBSD Accessibility mailing list, to share and to track discussions in a public place.

Sponsored by: The FreeBSD Foundation

FreeBSD Git Weekly

Links:
FreeBSD Git Weekly URL: https://freebsd-git-weekly.tarsnap.net/

Contact: Graham Percival <gperciva@tarsnap.com>

These are weekly lists of commits to the FreeBSD source tree, split into categories such as "documentation", "hardware support", "testing", and "kernel". We also include quarterly lists of the categorized commits, for those who prefer to see three months of development at once.

Our goal is to make it easier for developers and users to keep track of changes in FreeBSD that are relevant to them, without needing to subscribe to the dev-commits-src-main mailing list and look at every single commit which lands in their mailbox.

There is a freebsd-git-weekly@tarsnap.com mailing list that provides announcements about each report.

Sponsor: Tarsnap Backup Inc.

The FreeBSD Russian Documentation Project

Links:
FreeBSD Official Website in Russian URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
The FreeBSD Russian Documentation Project site URL: https://github.com/freebsd-doc-ru/freebsd-doc/discussions

Contact: Andrey Zakhvatov <andy@FreeBSD.org>
Contact: Vladlen Popolitov <vladlen@FreeBSD.org>

The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of the FreeBSD documentation (FAQ, Handbook, website content). It is essential to support Russian speaking users with high-quality official technical materials and to increase the adoption of the operating system worldwide. We hope this initiative will gain support within the Russian-speaking FreeBSD community and lead to an increase in translated materials.

During the last quarter:

  • 100% of the text in Weblate has been translated, accounting for all recent changes.

  • The review and update process for the remaining documentation has been completed. All 47 documents (books and articles) are now fully synchronized on the Russian documentation site.

  • The Russian language section of www.FreeBSD.org/ru has been restored, with approximately 90% of its pages updated.

  • News, event announcements, and press links are now being translated and published on the Russian website. Additionally, Errata Notices and Security Advisories have been translated into Russian starting from January 2025.

  • For the FreeBSD 15.0 release, the complete set of release documentation (release notes, errata, etc.) has been translated into Russian in a timely manner alongside the English originals.

  • The project to translate FreeBSD man pages has been initiated and is in its very early stages. Preliminary examples can be found at GitHub.

This report acknowledges with appreciation the contributions of the following colleagues who performed reviews of our commits during the quarter (in Phabricator or by email):

Plan for next quarter:

  • Finalize the update of all remaining pages on the Russian language website.

  • Establish a sustainable workflow to keep the translated content (News, Events, Press, Errata, Security Advisories) up to date and publish it on the website as promptly as possible.

  • Translate the new "FreeBSD Accessibility Handbook" as soon as it becomes available for translation in Weblate.

  • Continue the ongoing project to translate FreeBSD man pages.

Check the official translation guide if you would like to help.

We would appreciate your assistance with translating the following materials:

  • Web pages

  • Man pages

Ports

Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.

FreeBSD HPC Ports Modernization: Slurm 25.11 and Unbundled PMIx/PRRTE

Links:
sysutils/slurm-wlm: 23.11.7 → 25.11.0 URL: https://cgit.freebsd.org/ports/commit/?id=1536bac0dd26d81e315652929b8bfaff9c136089
net/pmix: Process Management Interface for Exascale (PMIx) URL: https://www.freshports.org/net/pmix/
net/prrte: PMIx Reference RunTime Environment (PRRTE) URL: https://www.freshports.org/net/prrte/
sysutils/py-clustershell: Python framework for efficient cluster administration URL: https://www.freshports.org/sysutils/py-clustershell/
Kavocado Monthly Status Reports – FreeBSD HPC notes URL: https://kavocado.net/reports/

Contact: Generic Rikka <rikka.goering@outlook.de>

During this quarter, a significant amount of work has gone into making FreeBSD a more practical target for modern HPC clusters by bringing key components of the Slurm + PMIx + PRRTE stack up to date and available as first-class ports.

Work completed

  • Updated sysutils/slurm-wlm from 23.11.7 to 25.11.0, tracking the latest upstream long-term series and drastically reducing the number of local patches required for FreeBSD.

  • Refreshed the Slurm rc.d scripts so that slurmctld and slurmd integrate better with a typical FreeBSD deployment (configurable config/log directories, pidfiles, status and cleanup helpers).

  • Introduced net/pmix and net/prrte as standalone ports, and switched net/openmpi to use these unbundled runtimes instead of the copies shipped inside the OpenMPI distfile. This aligns FreeBSD more closely with how many Linux HPC distros package the MPI runtime stack.

  • Added sysutils/py-clustershell, a Python framework widely used for scalable cluster administration, providing FreeBSD users with a familiar tool found on many production HPC systems.

Work in progress

  • Iterating on additional Slurm integration improvements (plugins, defaults, documentation) to make it easier to deploy Slurm on FreeBSD in real clusters.

  • Extending the HPC userland stack with further tools such as test frameworks and job-oriented utilities, so that FreeBSD can serve as a realistic development and validation platform for HPC software.

  • Porting sysutils/mpifileutils and its dependencies (devel/libcircle, devel/lwgrp, devel/lwgrpd) to provide MPI-parallel file utilities commonly used on large HPC filesystems (currently under review).

  • Adding and refining HPC-oriented Python tooling, including benchmarks/py-reframe (HPC regression testing framework) and continued work around sysutils/py-clustershell.

  • Initial work on bringing devel/spack to FreeBSD as a complementary tool for HPC software development and experimentation, with the goal of improving compatibility with existing HPC workflows.

Future plans

  • Continue tracking upstream Slurm, PMIx and PRRTE releases closely so that FreeBSD remains a viable target for sites that expect a modern MPI/Slurm stack.

  • Document a “reference” Slurm + OpenMPI + PMIx + PRRTE setup on FreeBSD, to lower the barrier for new sites that want to experiment with FreeBSD in an HPC context.

  • Identify and address FreeBSD-specific gaps or regressions to ensure the software stack remains feature-complete and robust on FreeBSD.

GCC on FreeBSD

Links:
GCC Project URL: https://gcc.gnu.org/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/
GCC 14 release series URL: https://gcc.gnu.org/gcc-14/
GCC 15 release series URL: https://gcc.gnu.org/gcc-15/
GCC 16 release series URL: https://gcc.gnu.org/gcc-16/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

Very little has happened for GCC on FreeBSD this quarter.

The main news is that the exp-run to update GCC default version from 13 to 14 is finally finished. It took longer than expected due to some segmentation fault which happens in the emacs ports only on most recent FreeBSD versions. Since the GCC_DEFAULT update was already long due, it has been chosen to pin the emacs ports to GCC 13 for now, so that this single bug does not prevent the rest of the ports tree from getting advantage of a more recent GCC version by default. Please see PR 288303 for more information.

GCC 15 is already in our ports tree and the process to bring GCC_DEFAULT to 15 will soon start.

Improve libvirt support for bhyve hypervisor

Links:
libvirt: Bhyve driver URL: https://libvirt.org/drvbhyve.html

Contact: Roman Bogorodskiy <novel@FreeBSD.org>

Completed work

  • libvirt/bhyve driver:

    • NVMe device support added.

    • PCI passthrough support added.

    • SLIRP networking support added.

    • More configuration options added: SATA nmrr/RPM, NVMe queues, VNC wait.

  • Enabled libvirt-tck hooks tests.

Plans for the next quarter

  • Add support (targeted, but might roll over to next quarter) for:

    • Boot order configuration.

    • TPM devices.

    • Complete suspend/resume support.

    • arm64 support.

    • virtio-scsi support.

    • Guest NUMA configuration support.

  • Improve virt-manager support on FreeBSD.

Sponsor: The FreeBSD Foundation

Improve OpenJDK on FreeBSD

Links:
Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Project repository URL: https://github.com/freebsd/openjdk

Contact:
Harald Eilertsen <haraldei@FreeBSD.org>
FreeBSD Java mailing list <freebsd-java@lists.freebsd.org>

The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and FreeBSD/arm64.

Java is an important runtime environment for many high performance, critical enterprise systems. Making sure Java based applications run correctly and efficiently on FreeBSD is important to ensure that FreeBSD will continue to be a viable and attractive platform for enterprises, as well as businesses and organizations of all sizes.

In this quarter the following issues/milestones were reached:

  • Released a port for OpenJDK 25, later updated to OpenJDK 25.0.1. Thanks to Greg Lewis and Kurt Miller for helping.

  • Added headless and jre FLAVORS to the OpenJDK 25 port. This enables building and installing only a headless (no GUI) version of the JDK or just the Java Runtime Environment (no compiler or dev tools). It is also possible to combine these to only install a headless-jre variant. This is useful in server environments, or other resource constrained environments where the full JDK and tools are not necessary. The plan is to extend these FLAVORS to the remaining OpenJDK ports as well.

  • Submitted a fix upstream that fixed invalid memory alignment on systems using jemalloc, or other allocators that do not use the strong alignment interpretation of the C standard alignment requirements. This caused problems when allocating small off-heap memory segments using the java.lang.foreign.Arena API on FreeBSD. This fix will be included in OpenJDK 26.

  • Deprecated OpenJDK ports no longer supported by upstream. The ports will expire and be removed throughout the first half of 2026, leaving the LTS versions and the latest maintained ports behind.

Other notes:

  • Spent some time digging into the history of getrlimitusage(2) system call discovering it was available since version 14.2 despite the man page saying it first appeared in version 15. See also related review by emaste. This was relevant because the performance improvements from previous quarter relies on this system call. Knowing that it is available for all currently maintained versions of FreeBSD, means we do not need to keep code to fall back to less efficient ways of obtaining the same information.

  • Updates made to the Mac OS X implementation of the Hotspot Serviceability Agent debugging facility broke the BSD implementation. Due to history, these implementations share the same source files and directories despite being somewhat different implementations. Work has been started on moving the OS X code to it’s own implementation, so that we can work on the BSD implementation without having to step on each others toes.

  • Work on changing the way we bootstrap OpenJDK builds in the ports system has been resumed. This work is more relevant again as deprecating unmaintained ports breaks the previous assumption that you could depend on the previous OpenJDK version to build the current version. The new bootstrapping mechanism must be in place before actually expiring the existing ports.

  • I lost access to my Aarch64 test system in the beginning of this quarter, so I have not been able to test as well as I want on that architecture. This situation is now remedied, and I am in the process of getting the new system set up for building and testing.

Sponsor: The FreeBSD Foundation

Make OpenJDK 21 the default JAVA_VERSION

Links: Issue 272855 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272855
Sheet tracking Work in Progress URL: https://docs.google.com/spreadsheets/d/17hmRQ0ShY4SHHVEkQBVxqK2G88fPZLriTzO26zXdjC4/edit?usp=sharing

Contact: Ronald Klop <ronald@FreeBSD.org>

The default JAVA_VERSION in FreeBSD ports is still OpenJDK 8. It is time to upgrade this to a more modern version like OpenJDK 21. We need to test and fix all ports using Java to build or run with JDK 21, or pin JAVA_VERSION in the port to the latest supported version.

The work is being tracked in PR 272855 and a Google Sheet for more details. Already more than half of the ports that failed a test run is fixed.

If you have experience with Java and the ports system you are invited to help. I think it is reasonable to have the ports in shape for the JAVA_VERSION=21 setting in February 2026.

Plan:

  • Check the last 12 ports and create a PR or commit

  • Commit the PRs that are timing out on maintainer feedback

  • Ask for another exp-run

  • If done, increase JAVA_VERSION

KDE on FreeBSD

Links:
KDE/FreeBSD initiative URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Contact: KDE on FreeBSD Mailing List <kde@FreeBSD.org>

The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation.

Infrastructure

CMake was updated to 3.31.10. Ninja was updated to 1.13.2.

Qt6, PyQt6, and PySide6 were updated to 6.10.1.

Qt5 was updated to 5.15.18 KDE patch collection. Upstream standard support for Qt5 is officially over. This might be the last update for Qt5 on FreeBSD.

KDE Stack

KDE Frameworks, Plasma, and Gear release happen very regularly. KDE team lands these updates shortly after their upstream release.

  • KDE Frameworks ports were updated to 6.21.0.

  • KDE Plasma Desktop was updated to 6.5.4.

  • KDE Gear was updated to 25.12.0.

With KDE Gear 25.12.0 the last two applications have been finally ported to Qt6, and KDE Stack is liberated from Qt5 packages now. The x11/kde port has been reduced and does not install Plasma 6 integration plugins for Qt5 and GTK2 applications anymore. They are still available and can be installed via x11/plasma6-plasma port if required.

Support for Plasma/Wayland has been improved. It can be used as a daily driver instead of Plasma/X11.

Related Ports

The KDE team maintains nearly 730 ports and updates them all as needed. According to portscout only 1% ports are outdated.

The KDE team would like to thank Gleb Popov, Jason E. Hale, Loïc Bartoletti, and Max Brazhnikov for keeping things up-to-date. The KDE team is grateful to Harley (SponiX on IRC) for sharing his building box.

Use Bazel as build tool for MongoDB 8.0

Links:
MongoDB 8.0 port URL: https://www.freshports.org/databases/mongodb80/
Bazel 8 PR URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287546

Contact: Ronald Klop <ronald@FreeBSD.org>

MongoDB is a production level NoSQL database. Our ports has the Community edition of MongoDB for many years already. MongoDB is used by several WiFi controller software in ports like Unifi and Omada. In MongoDB 8.0.13 the build system is changed from SCons to Bazel.

We have version 8 of Bazel in Bugzilla (PR 287546). With this version the build of MongoDB 8.0 starts. Unfortunately the build errors pretty quickly.

Because of security issues in the MongoDB 8.0 port it becomes important to upgrade the port to the latest version.

I am looking for somebody with experience of a Bazel build to help.

  • Contact me.

  • Set up your build environment with Bazel 8.

  • Compile and fix.

  • Let us commit it!

OpenVox (Puppet)

Links:
Vox Pupuli URL: https://voxpupuli.org/
OpenVox GitHub organization URL: https://github.com/OpenVoxProject/
Vox Pupuli GitHub organization URL: https://github.com/voxpupuli/

Contact: Puppet Team <puppet@FreeBSD.org>

OpenVox (Puppet) is a Free Software configuration management tool, composed of a source of trust (OpenVox Server) that describes the expected configuration of machines with a domain-specific language, and an agent (OpenVox Agent) on each node which enforces that the actual configuration matches the expected one. An optional database (OpenVoxDB) can be setup for reporting and describing advanced schemas where the configuration of a machine depends on the configuration of another one.

A lot of things happened in the Puppet world this year. After Perforce announced major changes regarding how they contribute to Open-Source, they discontinued the Open Source version of Puppet (also known as OSS Puppet), advising users to switch to Puppet Enterprise (closed source flavor of Puppet that has existed for years) or Puppet Core (a new closed source flavor of Puppet, not developed in the open, and accessible only after signing an End-User License Agreement (EULA)). The Vox Pupuli community tried to reason with Perforce, but without success. Vox Pupuli therefore took maintainership of the Apache-2.0 licensed Puppet code, and continue to maintain it, update it, provide packages, instead of Perforce. The name "Puppet" being owned by Perforce, the project has been renamed to "OpenVox" in order for users to not confuse the old unmaintained Open-Source Puppet with the new version maintained by OpenVoxProject, which is part of Vox Pupuli.

To follow these changes, a bunch of ports have been added to the FreeBSD ports tree:

They are drop-in replacement of the former ports: while the packages are named "openvox", the service keep their legacy name for now. Switching to them is as easy as installing them, and answering yes when pkg propose to remove the legacy packages and install the new ones. No other action is required: the module you used with Puppet are expected to continue working with OpenVox.

During this year, Puppet 7 has also reached End-of-Life, so the corresponding ports have been deleted from the FreeBSD ports tree. Puppet 7 was the last version that allowed to choose between the C and the Ruby version of facter, the port for the C version (sysutils/facter) has therefore also been removed. Because the legacy ports of Puppet 8 will not be updated anymore, they will be deprecated soon, and follow the same fate.

Last modified on: February 21, 2026 by Lorenzo Salvadore