e time during 26Q3. Native net80211 updates (tech debt) • Some work last year discovered issues in the way we are presenting RSSI to user space. Due to a possible double wraparound the values may not be correct. The driver and net80211 parts of this problem were fixed. The user space API is not fixed yet in order to avoid breakage (incl. major web browsers). • Talks have resumed during the last week of June in order to get ports fixed using lib80211, which will help us to move forward on various issues without constantly breaking user space. Final note It recently got quiet on issues despite more people using wireless on FreeBSD again. I am not sure this is a good sign or not. We appreciate all the feedback and problem reports we get and if they come in on bugzilla we also try to categorize them into specific groups (see link). Some may seem to fall through the cracks but we generally try not to let that happen. Sometimes larger works are planned dedicated to the area of your problem and so may not see immediate help, sometimes other things may be ahead of the queue. If the issues are properly documented it will be easier to get back to them at a later time. If you have any issues with (LinuxKPI based) wireless please try to use the official channels: check open PRs, send a note to the wireless mailing list, if needed drop me a private email (e.g., if you have a core dump with possible private information), or open a new PR if the issue is not yet known (or seems to fall through the cracks as then it is up for public tracking). Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DRM drivers Links: Update to Linux 6.13 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/469 Contact: Jean-Sébastien Pédron DRM drivers are kernel drivers for integrated and discrete GPUs. They are maintained in the Linux kernel and we port them to FreeBSD. As of this report, we take the AMD and Intel DRM drivers only (NVIDIA FreeBSD drivers are proprietary and provided by NVIDIA themselves). We port them one Linux version at a time. This allows us to ship updates more often and it eases porting and debugging because we have a smaller delta compared to a bigger jump skipping several versions. This quarter, we finished the porting of DRM drivers from Linux 6.12 LTS in time for the release of FreeBSD 15.1-RELEASE. Because this is an LTS version, we will track changes from the Linux 6.12.x patches. Currently, we are at 6.12.81 and work is underway to continue to bump to the latest patch. These drivers are available from the Ports tree and as packages. As part of the work on 6.12 drivers, several bugs or regressions were fixed for already supported GPUs. Some newer GPUs started to work as well. We still have several instabilities to fix in both the i915 and the amdgpu drivers. We also continued to port DRM drivers from following Linux versions: * The update to Linux 6.13 is under review and testing. * The update to Linux 6.14 is ready as well and will be reviewed after the 6.13 update. This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop and Desktop Project. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GENEVE Tunnel Links: Add Support for Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172 Contact: Pouria Mousavizadeh Tehrani Since the last report, I have committed the geneve(4) driver and it is now available on CURRENT. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Series of IPv6 Improvements Contact: Pouria Mousavizadeh Tehrani For the past 6 months, I have worked on refreshing our IPv6 stack and implementing pending RFCs in our stack, and they are now available on CURRENT. So far, I have added the support for: • RFC 9131 and RFC 9898 Section 3.9: Support for Gratuitous Neighbor Discovery (GRAND). • RFC 8781 (Section 5): Ability to have multiple PREF64 options. • RFC 4861 (Section 7.2.6 - 7.2.8): Support for delayed Neighbor Advertisement for both anycast and proxy addresses. • RFC 4191: Support for Route Information option in Router Advertisement. • Removed the support for DRAFT_IETF_6MAN_IPV6ONLY_FLAG to replace it with RFC 8925. Ongoing works: • RFC 8925: IPv6-Only Preferred Option For DHCPv4 (D56637) • RFC 4429: Add support for Optimistic DAD. (D55229) I want to specially thanks Gleb Smirnoff for his timeless guidance and help on these works. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Support for Routing Metric Contact: Pouria Mousavizadeh Tehrani I have been working on the metric implementation since 2026Q1. Routing metrics are configuration values used by a router to make routing decisions. Router metrics help the routing stack to choose the best route among multiple feasible routes to a destination. The route will go in the direction of the gateway with the lowest metric. Support for metric in our routing stack is implemented and available in CURRENT. Metric support requires numerous updates to both kernel and userland. These are some highlights that were added: • Support for metric in rtsock via rmx_metric. • RTA_PRIORITY support for metric in netlink. • The upper 8-bit weight reservation for metric has been removed. • route(8) now shows the metric value. • netstat(1) now shows the metric value of each route when -w is used. You can also leverage metric using net/bird for your routing protocols. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Native MPLS Support for FreeBSD Links: GSoC Project Wiki FreeBSD Source Fork Contact: Subhash Murmu This project adds native Multiprotocol Label Switching (MPLS) support to the FreeBSD kernel as part of Google Summer of Code 2026, mentored by Bruce Simpson and Alexander Chernikov. MPLS is widely deployed for label-switched forwarding in production networks, but FreeBSD has no MPLS data plane in the base system, so MPLS-capable routing daemons have no kernel forwarding path to program. The work is built bottom-up, from wire-level encapsulation through the control plane, and integrates with the existing FreeBSD network stack rather than sitting beside it. Phases 1 through 3 are complete and pushed as a five-commit layered history on the mpls branch of the Codeberg fork. Phase 1 adds link-layer encapsulation and netisr(9) dispatch for EtherType 0x8847. Phase 2 ports OpenBSD’s ldpd(8) to FreeBSD, where it now builds and runs. Phase 3 adds the forwarding engine and a per-VNET Label Information Base, with end-to-end LSP transit verified under tcpdump between VNET jails over epair(4). The series has not yet been submitted to Phabricator. Work continues on kernel route programming for ldpd. Sponsor: Google Summer of Code 2026 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Bluetooth HID drivers Links: FreeBSD wiki project page URL: https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices Project GitHub repo URL: https://github.com/majintosh/freebsd-bthid Contact: Majed Alkhaleefah I have been working on two drivers to enable support for HID drivers for Bluetooth devices as part of GSoC 2026. The primary goal of this project is to register connected Bluetooth HID devices as Newbus devices via two new drivers: bthidbus and bthid. bthidbus acts as the parent bus that manages the creation and attachment of bthid child devices. bthid serves as the transport layer, spawning a hidbus device and routing all received packets to it once they are stripped of their headers. The short-term goal here is to enable support for wireless HID connections. The longer-term goal is to begin setting the foundation that allows others to write drivers for devices that can only connect via Bluetooth. What has been accomplished: • bthidbus can successfully open a connection to a Bluetooth device via sockets. • bthid can receive and manage sockets handed down from bthidbus via ivars. • bthid can send the report descriptor to hidbus, which successfully spawns the correct HID device and driver. (e.g., a gamepad connected over Bluetooth spawns an hgame device and an evdev node.) • Input from Bluetooth devices is successfully received by hidbus and evdev. Current issues and planned changes: • The actual report descriptors, Bluetooth addresses, etc, have to be hardcoded into bthidbus. I initially considered adding the querying/ listening logic to bthidbus to make it act like a pseudo-server, but I worried this would risk bloating and scope creep. The approach I will be going with instead is to rely on the bthidd daemon’s existing querying logic and have it send new connection information to bthidbus via an ioctl. This would remove bthidbus 's current role as the connection-initiator and instead have it only manage connections that have already been opened. • There is significant input latency when monitoring via evtest. I have two different working hypotheses. The first is that the issue lies in bthid and how it manages interrupts via taskqueues. The second is that it lies in the Networking stack, as Bluetooth packets are piped between multiple different Netgraph nodes before being received by bthid. This could also very well be an issue with evtest; I still have to look into this. All testing so far has been done with the Nintendo Switch Pro Controller. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ NTSYNC(9) Contact: Konstantin Belousov Recently there was a stream of articles hyping the Linux driver ntsync which implemented a helper for Wine to accelerate Windows NT synchronization primitives. The substrates to implement semaphores, mutexes, and events from the Win32 land are provided by it. The driver represents each NT object as a file descriptor, which has the set of the ioctls defined that directly map into the Win32 operations. The project implemented the driver providing the compatible ntsync interface as specified in the Linux 7.0-rc3 document Documentation/userspace-api/ntsync.rst. Both native FreeBSD interface, and the Linux ABI compatibility layers, are written. To test the driver, a minimal version of the Linux kernel test harness was ported. FreeBSD driver follows the interface details as encoded by the tests, when a discrepancy between Linux documentation and tests was found. Both the driver and its man page ntsync(4) were written from scratch, without consulting the Linux source code. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Raspberry Pi Imager FreeBSD Port Links: rpi-imager upstream URL: https://github.com/raspberrypi/rpi-imager FreeBSD Port pull request URL: https://github.com/raspberrypi/rpi-imager/pull/1655 PR 296480 - FreeBSD Ports open review URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296480 Contact: Jim Chen Contact: Nimish Jain The Raspberry Pi Imager is a convenient graphical tool developed by the Raspberry Pi Foundation that allows users to easily configure and flash operating system images to storage cards for the Raspberry Pi Zero and Raspberry Pi 1-5 series single-board computers. Our goal in porting this app to FreeBSD is to continue lowering barriers to entry. We want users unfamiliar with the command line to easily flash operating systems to their Raspberry Pi. Currently, the upstream project supports only Linux, MacOS, and Windows. We have created a FreeBSD port that uses native I/O, disk, and network APIs and links against pre-packaged FreeBSD libraries. The main blocker for this project is currently upstream uncertainty. The maintainers have requested buy-in from FreeBSD developers to help with the long-term maintenance of the FreeBSD-specific code. If you are a committer or a contributor invested in Raspberry Pi tooling on FreeBSD, please let us know or join the discussion on the GitHub pull request! If this work is accepted upstream, a Makefile for the FreeBSD Ports repository is ready for review as PR 296480 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296480). If you’re interested, please do try out a local release by cloning the Ports tree and applying the patch in the PR mentioned above, and let us know if you have any issues! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Enhancing Arduino and ESP32 Development Ecosystem on FreeBSD Contact: Deepan Sai Project Overview I am working on adding the Arduino CLI package to the FreeBSD Ports Collection. The Arduino CLI is a command line tool that helps users work with Arduino boards. By adding it to FreeBSD I want to make it easier for developers to use. Importance of the Work A lot of people use Arduino CLI for embedded systems and automation. Having it on FreeBSD as a port makes it easy to install and update the software. This helps keep FreeBSD in line with tools that hardware and embedded developers use. Progress This Period This time I worked on getting the new port ready to be reviewed. I wrote the Makefile and made sure the package built correctly. I found a problem where a test was failing because it did not have the settings for FreeBSD. I fixed this. The test now works. I did all the checks for a new port like making sure the files are in the right place and that the tests run correctly. I also fixed some issues that people found when they reviewed my work. The port is now much closer to being ready to be added to the FreeBSD Ports Collection. Sponsor: Google Summer of Code ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Driver Development for BananaPi-R64/R2-PRO Links: Wiki URL: https://wiki.freebsd.org/arm/Bananapi Contact: Martin Filla Contributors are welcome. If you are interested in helping with this project, testing the current implementation, or contributing code, please contact me. R64 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 R64 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 • USB3 • T-PHY Development roadmap R64 Implement missing drivers: • SATA / AHCI • Wi-Fi (likely MediaTek MT7615) • GPIO subsystems • I2C • SPI • PWM • PCIE R2-PRO Introduction The Banana Pi BPI-R2 Pro is the next generation smart router development board. It is powered by Rockchip RK 3568 processor. Onboard 2GB LPDDR4 memory and 16GB eMMC storage, and supports 2 USB 3.0 interface, 5 gigabit network port. M.2 key-E and mini PCIe interface, 2 mipi DSI interface (one can change to LVDS by software), 1 CSI camera interface, 1 HDMI output. Current State of FreeBSD Support R2-PRO Implemented so far: • UART driver • Clock management (clocks) • Pinctrl • GPIO • Storage controllers (eMMC/SD/MMC) driver • XHCI driver • Watchdog driver • PCIE driver Development roadmap R2-PRO Implement missing drivers: • HDMI • MIPI • USB3 • SATA ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Framework Laptop support Links: Framework Laptop page on FreeBSD Wiki URL: https://wiki.freebsd.org/Laptops/Framework_Laptop/ Guide on installing and using FreeBSD on Framework systems URL: https://github.com/FrameworkComputer/freebsd-on-framework Framework system management tools URL: https://github.com/FrameworkComputer/framework-system Tracking ticket: Framework Laptop: Feature support, bugs and improvements URL: https://bugs.freebsd.org/262152 Contact: Daniel Schaefer Contact: Li-Wen Hsu Contact: Sheng-Yi Hong Framework Computer Inc. continues to support the FreeBSD Project in many ways. This includes providing engineering samples and development hardware to the FreeBSD Foundation, helping with hardware testing, and working with FreeBSD developers on compatibility improvements. The Foundation continues to improve overall laptop support. Framework laptops are among the target platforms of the Laptop Support and Usability Project. During 2026Q2, Daniel updated the sysutils/framework-system port to version 0.6.2 and later to version 0.6.4. This package provides Framework-specific system and firmware management tools for FreeBSD users. Framework also hosted a small hackathon at its Taipei office during the quarter. FreeBSD developers tested newly announced hardware, including the Intel Panther Lake-based Framework Laptop 13 Pro and the 10GbE adapter. Li-Wen is working on FreeBSD support for the 10GbE adapter, which uses a Realtek RTL8159 controller. Support for Intel Panther Lake systems also progressed through development and testing on Framework hardware, including pre-release systems made available by Framework during the Taipei hackathon. Daniel added PCI IDs for Panther Lake I2C and SMBus controllers, and Sheng-Yi committed the work to FreeBSD. A follow-up correction removed an ID for an SPI flash controller that had been incorrectly identified as an SPI bus controller. In June, Li-Wen also started testing and debugging the Linux 6.12-based DRM drivers from the graphics/drm-612-kmod port, which was added during the quarter . He investigated display-related problems on Framework systems and suspected that some of them might be the same as, or related to, the external-display hot-plug problem tracked in the Laptop Support and Usability Project. The investigation was still in progress at the end of the quarter and continued into Q3. Power and performance management continued to improve on both Intel and AMD systems. Framework systems were among the development and test platforms used for this work. Some systems were provided by Framework, while FreeBSD developers also carried out development and testing on their own Framework hardware. Sheng-Yi disabled Intel HWP package-control mode on hybrid-core CPUs. Without this change, a request from an efficiency core could limit all cores to its performance level and cause a significant loss of performance. Other HWP and CPPC improvements completed during the quarter include: • Exposing available AMD legacy-pstate nodes. • Caching AMD CPUID information. • Using IPIs for Intel per-CPU HWP updates. • Using the full 8-bit Intel Energy Performance Preference scale. Work also progressed on suspend and resume support for the Framework Laptop 12. Devin Teske developed and tested a proposed ACPI fix for a wake-up issue that could cause the system to suspend again immediately after resume. Daniel investigated the laptop’s ACPI and embedded-controller firmware behavior, while Warner Losh and Olivier Certner provided technical review and helped improve the implementation. Sponsor: The FreeBSD Foundation for Li-Wen and Sheng-Yi’s work Sponsor: Framework Computer Inc. for Daniel’s work and for hardware and space provided to the project ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ROCm support on FreeBSD Links: drm-kmod fork with partial amdkfd support URL: https://github.com/Yohello1/drm-kmod-rocm/tree/super-special rocm-systems fork with fixes for FreeBSD URL: github.com/Yohello1/rocm-systems Contact: Sourojeet Adhikari ROCm is the compute platform used by AMD for their GPUs. As of now, FreeBSD does not support ROCm at all, neither at the toolchain level nor at the driver level. I am working to change that and upstream the required changes. To my knowledge, on FreeBSD there are a few ways to run compute loads (like AI/ ML, graphics, etc) on the GPU; those ways, to my knowledge, are Vulkan and OpenGL. Both Vulkan and OpenGL are fairly good for compute workloads, namely in graphics and sometimes machine learning loads too. But sometimes there are tasks which are not well-suited for Vulkan and OpenGL, and are instead done in ROCm/CUDA because ROCm and CUDA give the developer a lot more control over how the task is done. So I am trying to introduce ROCm support to FreeBSD so we can run ROCm code/programs on FreeBSD. There are a few things we need working to get ROCm working. The first is AMD’s LLVM fork, which I have patched, gotten working, and have upstreamed the patches. Next are the ROCm runtimes, which have been patched, and I am currently working on upstreaming the patches. Finally is the amdkfd driver, which I am working on patching, and am upstreaming some of the LinuxKPI-related patches back to the FreeBSD kernel. As of late, I have upstreamed changes to AMD’s LLVM fork allowing the compilation of their fork on FreeBSD so you can build their ROCm toolchain. Beyond that, I have worked on getting a series of patches into LinuxKPI to slowly bring in amdkfd support. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on EC2 Contact: Colin Percival FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances. An issue causing the ena(4) driver to drop packets when receiving jumbograms has been fixed. The fix was present in 15.1-RELEASE (June) and will be present in 14.5-RELEASE (September). This fix improved single-TCP-stream network performance on some EC2 instances from 110 Mbps to 9.5 Gbps and also significantly improved multiple-TCP-stream throughput. An issue causing the ena(4) driver to launch taskqueues on the wrong CPU(s) on NUMA systems has been identified. The fix should be present in 14.5-RELEASE (September) and produces a 2x increase in multiple-TCP-stream throughput on c8gn.48xlarge instances. Sponsor: Amazon Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu , Contact: Li-Wen Hsu Publishing the 15.1-RELEASE image to Azure Marketplace is in progress. It is expected to become publicly available early in the third quarter. Li-Wen is investigating the technical details needed to support Azure Trusted Launch. Wei and Li-Wen, together with other Microsoft engineers, are investigating an issue preventing mana(4) from working correctly on AMD-based Azure VMs. The mana(4) device is present on the latest v7-generation Azure VMs. Work in progress tasks: • Automating the image publishing process and merging it into src/release/. • Making the process of publishing to Azure Marketplace smoother. • Supporting FreeBSD in Azure VM utilities. Open tasks: • Update FreeBSD-related documentation at Microsoft Learn. • Update sysutils/azure-agent to the latest version. • Upstream local modifications of Azure agent. • Port Linux Virtual Machine Extensions for Azure. • Add FreeBSD support in Azure Pipelines. □ https://github.com/microsoft/azure-pipelines-agent/pull/3266 □ Build and publish snapshot builds to Azure community gallery. Sponsor: Microsoft for people in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The FreeBSD Russian Documentation Project Links: The 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 Contact: Vladlen Popolitov 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. • The Russian language section of www.FreeBSD.org/ru has been fully translated, with 100% of its pages now available in Russian. • For the FreeBSD 15.1 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. Plan for the next quarter: • Continue the ongoing efforts 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. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Dockerbox Links: freebsd-dockerbox GitHub URL: https://github.com/leafoliage/freebsd-dockerbox dockerbox-broker GitHub URL: https://github.com/leafoliage/dockerbox-broker freebsd-dockerbox-debian GitHub URL: https://github.com/leafoliage/freebsd-dockerbox-debian Contact: Chun-Cheng Yeh Dockerbox is a virtualized Docker daemon. Although the Docker daemon is not natively available on FreeBSD, Dockerbox runs it inside a Debian Bhyve virtual machine to provide access to it. Dockerbox supports common Docker features such as Docker Compose, port publishing, and bind mounts. This project aims to facilitate non-production Docker usage on FreeBSD. Related Ports and Repositories • freebsd-dockerbox Provides Docker on FreeBSD by running dockerd inside a Linux Bhyve VM. This service manages the lifecycle of the Dockerbox guest, along with its network and storage settings. v0.2.5 — ported. • dockerbox-broker A child service of Dockerbox that handles port forwarding from the host to the Dockerbox guest when a container requests port publishing. Not yet ported. • freebsd-dockerbox-debian Codebase used to generate Dockerbox’s disk image. Not ported. • docker-cli The Docker CLI tool. v29.4.2 — ported. • docker-compose A Docker CLI plugin for defining and running multi-container applications. v5.1.3 — ported. • docker-buildx A Docker CLI plugin providing extended build capabilities via BuildKit. v0.34.1 — ported. sysutils/dockerbox, sysutlis/docker-cli, sysutils/docker-compose, and sysutils/ docker-buildx are now available in the FreeBSD Ports Collection and via pkg. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 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 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.12. Qt6 and PySide6 were updated to 6.11.1. PyQt6 was updated to 6.11.0. Qt5 and PySide2 were updated to 5.15.19 KDE patch collection. Upstream standard support for Qt5 is officially over. This is the final update for Qt5. 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.28.0. • KDE Plasma Desktop was updated to 6.6.6. • KDE Gear was updated to 26.04.3. Related Ports A number of new KDE ports have been added. Amarok, the classic KDE music player, has been reinstated and updated to 3.3.3. Sunsetting Qt5 ports Qt5 is still used by approximately 350 ports. Although Qt5 is deprecated there is no definite date for its removal from the ports tree yet. Still, the port for Qt5WebEngine which is based on very old Chromium with multiple vulnerabilities is scheduled for removal just before 2026Q4. KDE team encourages maintainers to migrate their ports to Qt6, remove Qt5 flavors, and remove abandoned Qt5 software. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 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/ GCC 17 release series URL: https://gcc.gnu.org/gcc-17/ Contact: Lorenzo Salvadore Two new ports have been created: lang/gcc16 and lang/gcc17-devel. PR 294062 about arm64 build failures has been fixed. More precisely, in 2026Q2 lang/gcc16-devel and lang/gcc17-devel have been fixed, while lang/gcc16 has been fixed in the beginning of 2026Q3 (at the time this report is written the patch still needs to be forwarded to the ports quarterly branch). Unfortunately, the solution is local to the FreeBSD ports tree and cannot be upstreamed directly. Discussion for an upstream solution can be found in the upstream bugzilla. Thanks to all those who have helped, in particular to Mark Millard. I have not worked personally on the process to get GCC_DEFAULT=15 this quarter, but some work is being done in the associated PRs, so this is getting forward as well. Moreover, minor version updates to lang/gcc13, lang/gcc14 and lang/ gcc15 are planned. As I continue to work on the GCC ports, I realize that I am having less time and less energy to put into them. These ports are important, I prefer not to leave them unmaintained at least until I am able to deal with them, even if slowly. But if there is someone who would like to take them, please stand up and I would be glad to transfer maintainership. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improve OpenJDK on FreeBSD Links: Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/ Project repository URL: https://github.com/freebsd/openjdk Upstream BSD port repo URL: https://github.com/openjdk/bsd-port Contact: Harald Eilertsen FreeBSD Java mailing list 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. This quarter has been spent mostly on getting the upstreaming process properly going. We submit patches to a separate repository under the OpenJDK org on GitHub, and make sure that each PR is reviewed by at least one upstream reviewer. This way, when we get to the point where we want to merge our port into the upstream mainline, all commits should already be reviewed by someone in the project. This is a fairly slow process, as we depend on upstream reviewers having time. We also encounter that some of the changes that has been living in our port for a long time is rejected. Then we have to rework them, or if not strictly needed, just throw them out. I feel this is a useful correction, but sometimes causes quite a bit of work. In this quarter the following issues/milestones were reached: • OpenJDK 25 port was updated to version 25.0.3. • Upstream mainline changes and bugfixes: □ 8382614: Consolidate implementation of current_stack_base_and_size on BSD □ 8384085: Make os::Bsd::dlopen_helper private, and drop unused arg □ 8384088: osThread _thread_id should be an int on all BSD’s □ 8384946: os::Bsd::gettid misses the return value □ 8386344: runtime/StackGuardPages/TestStackGuardPages build failure after JDK-8303612 • Upstream BSD Port: □ Fix conditional sections for BSD in hotspot/cpu □ Port hotspot/os/posix for BSD □ Merged changes accepted for mainline. • Current (out-of-tree) BSD port: □ Merge + Remove VFORK for BSD + rebase GHA workflow on OpenJDK26 □ Merge + Fix usage of FREE_C_HEAP_ARRAY macro on BSD □ Sync aarch64 cpuinfo impl for *BSD with Linux □ Remove duplicate include in global defs for zero □ Remove ThreadWXEnable from BSD code □ Backported changes accepted for mainline upstream BSD port. • Ports: □ java/javavmwrapper: JAVA_VERSION does not work with openjdk25 In addition, these tasks are still ongoing, or waiting for review: • Upstream BSD port: □ Port hotspot/os/bsd/os_perf_bsd.cpp to BSD (Waiting for refactor, see WIP: Split os_perf impl for macOS and BSD) □ os::get_process_uid and os::rss for BSD (Still ongoing) Other notes: • Started preparing for OpenJDK 27 port. • Presented the project at Foss North 2026. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD HPC Ports Modernization: Slurm 26.05, UCX 1.20 Upstreaming, and MPI-Parallel File Utilities Links: sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/ net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/ sysutils/mpifileutils URL: https://cgit.freebsd.org/ports/tree/sysutils/ mpifileutils/ devel/libcircle URL: https://cgit.freebsd.org/ports/tree/devel/libcircle/ devel/lwgrp URL: https://cgit.freebsd.org/ports/tree/devel/lwgrp/ devel/dtcmp URL: https://cgit.freebsd.org/ports/tree/devel/dtcmp/ benchmarks/py-reframe-hpc URL: https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/ openucx/ucx#11354: UCS/TYPE portability fixes for non-glibc/Clang environments (merged) URL: https://github.com/openucx/ucx/pull/11354 openucx/ucx#11549: UCS/SYS portability fixes for non-Linux platforms (in review) URL: https://github.com/openucx/ucx/pull/11549 hpc/mpifileutils#664: Portability fixes for FreeBSD/non-Linux builds (in review) URL: https://github.com/hpc/mpifileutils/pull/664 Kavocado Monthly Status Reports – FreeBSD HPC notes URL: https://kavocado.net/reports/ Contact: Generic Rikka This report continues the FreeBSD HPC Ports Modernization initiative. Previous quarters focused on bringing the Slurm + PMIx + PRRTE + UCX stack up to date and filling gaps in the surrounding ecosystem. This quarter’s work centered on three things: keeping the core scheduler and communication libraries current against fast-moving upstream releases, upstreaming the FreeBSD portability fixes accumulated while maintaining these ports so the local patchsets keep shrinking, and adding a new port for MPI-parallel file utilities that are common on large HPC filesystems. Work completed • Updated sysutils/slurm-wlm twice this quarter, from 25.11.4 to 25.11.5 and then from 25.11.5 to 26.05.1, tracking the latest upstream releases. • Fixed several FreeBSD-specific runtime issues in net/ucx: hardened async thread state handling, corrected UCM relocation handling, fixed mm signal socket binding, and resolved other FreeBSD runtime portability issues. • Updated net/ucx from 1.20.0 to 1.20.1, and separately fixed a libucm early-init panic together with several gtest suite failures uncovered while validating the update. • Added sysutils/mpifileutils as a new port, along with its dependency stack: devel/libcircle, devel/lwgrp, and devel/dtcmp. These provide MPI-parallel file utilities (copy, remove, checksum, etc.) commonly used on large HPC filesystems. • Updated benchmarks/py-reframe-hpc twice this quarter to track upstream releases of the regression testing framework. • Upstreamed "UCS/TYPE: Portability fixes for non-glibc/Clang environments" to UCX, which was reviewed and merged. • Opened "UCS/SYS: portability fixes for non-Linux platforms" against UCX, covering hostname buffer sizing, MAC address retrieval via getifaddrs()/ AF_LINK, shared-memory error reporting, mmap/munmap-based reallocation, and cpuset_getaffinity()-based thread affinity queries; currently addressing review feedback. • Opened a portability PR against mpifileutils guarding Linux-only APIs for FreeBSD and other non-Linux builds; currently in review. • Collaborated with SchedMD on a Slurm configure-time probe for H5PTopen, used to detect the HDF5 high-level library, which was merged upstream. Work in progress • Addressing reviewer feedback on the open UCX and mpifileutils portability pull requests to get them merged upstream and reduce the FreeBSD ports' local patchsets further. • Continuing collaboration with SchedMD to upstream additional portability fixes discovered while maintaining sysutils/slurm-wlm on FreeBSD, including BSD socket-handling improvements. • Evaluating a proctrack/freebsd_reaper Slurm plugin design, made possible by recently landed FreeBSD kernel support for exposing reaper metadata in process information. • Continuing to track upstream Slurm, UCX, and PMIx/PRRTE releases closely to keep the FreeBSD ports current with minimal local patching. Future plans • Land the outstanding UCX and mpifileutils upstream pull requests, and continue identifying further portability issues to upstream rather than patch locally. • Prototype and submit the Slurm proctrack/freebsd_reaper plugin once the underlying kernel interface work is finalized. • Continue expanding the HPC software ecosystem available in the FreeBSD Ports Collection and reduce local patchsets across the stack wherever upstream acceptance is possible. • Document a reference Slurm + OpenMPI + PMIx + PRRTE + UCX deployment on FreeBSD to lower the barrier for new sites experimenting with FreeBSD in an HPC context. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improve libvirt support for bhyve hypervisor Links: libvirt: Bhyve driver URL: https://libvirt.org/drvbhyve.html Contact: Roman Bogorodskiy Completed work • libvirt/bhyve driver: □ virtio-console device support added. □ QEMU Guest Agent support added. □ Implemented a few features based on the QEMU Guest Agent, such as graceful reboot and shutdown, managing guest OS time, SSH keys, users passwords, etc. □ Added memory tuning and block I/O tuning based on rctl(8). • Work in progress on extend libvirt CI to test against FreeBSD-CURRENT snapshot VM images. Plans for the next quarter • Add support for boot order configuration. • Add support for TPM devices. • Complete suspend/resume support. • Continue implementing features based on the QEMU Guest Agent. • Continue extending CI, cover the new guest agent based features with new tests. Sponsor: The FreeBSD Foundation