diff --git a/website/content/en/status/report-2025-07-2025-09/ACPI.adoc b/website/content/en/status/report-2025-07-2025-09/ACPI.adoc index 14a2f67524..8ef70078e4 100644 --- a/website/content/en/status/report-2025-07-2025-09/ACPI.adoc +++ b/website/content/en/status/report-2025-07-2025-09/ACPI.adoc @@ -1,80 +1,80 @@ === ACPI Lua Bindings Links: + -link:https://www.github.com/kpowkitty/freebsd-src[Github] URL: link:https://www.github.com/kpowkitty/freebsd-src[] + +link:https://www.github.com/kpowkitty/freebsd-src[GitHub] URL: link:https://www.github.com/kpowkitty/freebsd-src[] + link:https://www.github.com/freebsd/freebsd-src/pull/1740[PR: libsa: Add isprint()] URL: link:https://www.github.com/freebsd/freebsd-src/pull/1740[] + link:https://www.github.com/freebsd/freebsd-src/pull/1843[PR: loader: Move ACPI RSDP detection] URL: link:https://www.github.com/freebsd/freebsd-src/pull/1843[] + link:https://www.github.com/freebsd/freebsd-src/pull/1818[PR: efi: Create libacpi] URL: link:https://www.github.com/freebsd/freebsd-src/pull/1818[] + link:https://www.github.com/freebsd/freebsd-src/pull/1819[PR: liblua: ACPICA Lua bindings] URL: link:https://www.github.com/freebsd/freebsd-src/pull/1819[] Contact: Kayla Powell (AKA Kat) + Mentor: Warner Losh ==== Introduction For Google Summer of Code 2025, I have been working on a project under mailto:imp@FreeBSD.org[Warner Losh] for ACPI Lua Bindings. ACPI (Advanced Power and Configuration Interface) is an interface for managing power in the OS, rather than in the BIOS. The goal is to expose ACPI to Lua in the loader for amd64 platforms, with future arm64 support. ==== Outcomes * Lua is a much simpler, higher level scripting language that enables faster development. * It reduces ACPI-related guesswork in the bootloader. * It allows users to query and manipulate ACPI data before the kernel is entered, giving them control over loader-time configuration. ==== Remarks If there are any specialized use cases for ACPI in the loader that my interface does not aid in, please reach out to me, and I will see what I can do. For now, this is the interface that I will be committing to the tree for GSoC, so while any extra work will have to come afterwards, I am interested in it (and encourage it). ==== Current status * Completed: ** ACPICA initialized in loader for amd64 *** [.filename]#OsdMemory.c# *** [.filename]#osunixxf.c# *** AcpiInitializeSubsystem *** AcpiInitializeTables *** AcpiEnableSubsystem (in reduced hardware mode, with events enabled) *** AcpiLoadTables *** AcpiWalkNamespace *** AcpiEvaluateObject *** AcpiAttachData *** AcpiGetData *** AcpiDetachData ** Lua bindings *** [.filename]#lacpi_walk.c# **** Users can walk and read nodes on the namespace *** [.filename]#lacpi_object.c# **** Users can evaluate objects *** [.filename]#lacpi_data.c# **** Users can attach, get, and detach data from nodes *** Man Page * Future plans: ** [.filename]#lacpi_walk.c# (V2) *** Namespace printout format ** [.filename]#lacpi_walk.c# (V3) *** Strategies for walking the namespace ** arm64 compat ==== Design constraints The loader is meant to be lightweight and prepare the kernel. In order to adhere to that, its initialization of ACPI has been reduced by 130 functions. These functions were picked such that they were not necessary for the above interface, or lacked possibility in the loader. They are: * AcpiInitializeObjects * AcpiInstallNotifyHandler * AcpiRemoveNotifyHandler Some functions needed to be stubbed in respect to the loader's limited library (specifically in [.filename]#osunixxf.c#). Some functions needed to handle physical addresses, rather than virtual memory mappings (specifically in [.filename]#OsdMemory.c#). ==== Testing * Confirmation tests were performed, demonstrating that the ACPI namespace is initialized correctly by dumping it in the loader (in C and in Lua) and in the kernel (in C) and comparing the results. * Regression tests were performed, ensuring FreeBSD builds across all architectures with this change. * Unit tests were performed on the Lua bindings, verifying their functionality. Sponsor: Google Summer of Code 2025 diff --git a/website/content/en/status/report-2025-07-2025-09/appjail.adoc b/website/content/en/status/report-2025-07-2025-09/appjail.adoc index 3a0193be69..217a9a04c2 100644 --- a/website/content/en/status/report-2025-07-2025-09/appjail.adoc +++ b/website/content/en/status/report-2025-07-2025-09/appjail.adoc @@ -1,41 +1,41 @@ === Container orchestration: Overlord, Director, AppJail and cloud-init Links: + -link:https://github.com/DtxdF/AppJail[AppJail on Github] URL: link:https://github.com/DtxdF/AppJail[] + -link:https://github.com/DtxdF/Director[Director on Github] URL: link:https://github.com/DtxdF/Director[] + -link:https://github.com/DtxdF/Overlord[Overlord on Github] URL: link:https://github.com/DtxdF/Overlord[] + +link:https://github.com/DtxdF/AppJail[AppJail on GitHub] URL: link:https://github.com/DtxdF/AppJail[] + +link:https://github.com/DtxdF/Director[Director on GitHub] URL: link:https://github.com/DtxdF/Director[] + +link:https://github.com/DtxdF/Overlord[Overlord on GitHub] URL: link:https://github.com/DtxdF/Overlord[] + link:https://github.com/AppJail-makejails[Makejails] URL: link:https://github.com/AppJail-makejails[] Contact: Jesús Daniel Colmenares Oviedo **AppJail** is an open-source BSD-3 licensed framework entirely written in POSIX shell and C to create isolated, portable and easy to deploy environments using FreeBSD jails that behaves like an application. **Director** is a tool for running multi-jail environments on link:https://github.com/DtxdF/AppJail[AppJail] using a simple YAML specification. A Director file is used to define how one or more jails that make up your application are configured. Once you have a Director file, you can create and start your application with a single command: `appjail-director up`. **Overlord** is a fast, distributed orchestrator for FreeBSD jails oriented to GitOps. You define a file with the service intended to run on your cluster and deployment takes seconds to minutes. This orchestration tool uses link:https://github.com/DtxdF/AppJail[AppJail], link:https://github.com/DtxdF/director[Director] and can even create VMs with link:https://github.com/FreeBSD/vm-bhyve[vm-bhyve], but as its philosophy is "deploy using code" you can create a single file once and deploy many times. Through a tree chaining system Overlord deploys jails on connected systems sharing their resources almost infinitely. See the link:https://github.com/DtxdF/Overlord/wiki[wiki] for articles that use Overlord. **Recently written articles about Overlord**: * link:https://freebsdfoundation.org/our-work/journal/browser-based-edition/networking-3/overlord-deploy-jails-as-fast-as-you-code/[Overlord: Deploy Jails as Fast as You Code] * link:https://github.com/DtxdF/overlord/wiki/cloud-init[Deploying virtual machines using cloud-init] * link:https://github.com/DtxdF/overlord/wiki/ephemeral[Deploying virtual machines with ephemeral jails] * link:https://github.com/DtxdF/overlord/wiki/gitops[Using GitOps with Overlord] * link:https://dtxdf.github.io/jellyseerr.html[How to install Jellyfin and Jellyseerr using Overlord] **Makejails** are simple text files that automate the steps to create a jail, a widely used feature of link:https://github.com/DtxdF/AppJail[AppJail]. Currently, there are many Makejails created and hosted in the link:https://github.com/AppJail-makejails[Centralized Repository], but here are some of the recently written ones: * link:https://github.com/AppJail-makejails/odoo[Odoo] * link:https://github.com/AppJail-makejails/writefreely[WriteFreely] * link:https://github.com/AppJail-makejails/adminer[Adminer] * link:https://github.com/AppJail-makejails/shiori[Shiori] * link:https://github.com/AppJail-makejails/healthchecks[Healthchecks] * link:https://github.com/AppJail-makejails/ntfy[ntfy] Sponsor: https://www.patreon.com/appjail diff --git a/website/content/en/status/report-2025-07-2025-09/bananapi-r64-drivers.adoc b/website/content/en/status/report-2025-07-2025-09/bananapi-r64-drivers.adoc index 5eaa5f9918..5465ce3d39 100644 --- a/website/content/en/status/report-2025-07-2025-09/bananapi-r64-drivers.adoc +++ b/website/content/en/status/report-2025-07-2025-09/bananapi-r64-drivers.adoc @@ -1,31 +1,32 @@ === FreeBSD Driver Development for BananaPi-R64 Contact: Martin Filla Wiki: https://wiki.freebsd.org/arm/Bananapi ==== 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/gpio driver** – in active development gpio part * **Storage controllers (eMMC/SD/MMC) driver * **Ethernet Switch mt7531 driver * **Ethernet mt7622 driver Other essential components—Ethernet, USB, SATA, Wi-Fi, etc.—are not yet implemented. ==== Technical Context and Significance Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks drivers exist but ppl clock is under development, gpio is under development -- while most critical subsystems remain unimplemented. ==== Development roadmap * Implement missing drivers - USB (XHCI/OTG) - SATA / AHCI - Wi-Fi (likely MediaTek MT7615) - GPIO subsystems ==== Conclusion -Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks drivers exist but ppl clock is under development, gpio is under development—while most critical subsystems remain unimplemented. Publishing working code and artifacts, plus active collaboration with the FreeBSD community, will be essential to bring this board toward usable status under FreeBSD. \ No newline at end of file +Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks drivers exist but ppl clock is under development, gpio is under development—while most critical subsystems remain unimplemented. +Publishing working code and artifacts, plus active collaboration with the FreeBSD community, will be essential to bring this board toward usable status under FreeBSD. diff --git a/website/content/en/status/report-2025-07-2025-09/foundation-sta.adoc b/website/content/en/status/report-2025-07-2025-09/foundation-sta.adoc index c8cd2a96cb..ccb52ac0a6 100644 --- a/website/content/en/status/report-2025-07-2025-09/foundation-sta.adoc +++ b/website/content/en/status/report-2025-07-2025-09/foundation-sta.adoc @@ -1,114 +1,114 @@ -=== Infrastructure Modernization - -Contact: Ed Maste + -Contact: Alice Sowerby - -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 link:https://github.com/FreeBSDFoundation/all-projects/tree/main/Infrastructure%20Modernization%20(STA%20commissioned)[project information repo]. - -==== Q3 update - -All five work packages are in progress and will run until the end of December 2025, at which time the project will close. - -===== Work Package A: Technical Debt Reduction - -This work package is complete as of 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 bug backlog dashboard they commissioned remains available to help make the backlog easier to understand. - -In August, we held a panel discussion at link:https://osseu2025.sched.com/event/25VsE/from-backlog-to-breakthrough-how-freebsd-and-bitergia-tackled-7k+-bugs-with-data-driven-dashboards-alice-sowerby-freebsd-foundation-contractor-daniel-izquierdo-cortazar-miguel-angel-fernandez-sanchez-bitergia-moin-rahman-freebsd-project[Open Source Summit Europe] to share this work with a wider audience. -Two members of the Foundation project staff (Alice Sowerby and Moin Rahman) were on the panel along with two representatives from Bitergia who delivered the GrimoireLab implementation for this project. -(Members of the FreeBSD Project Source Management team were not available to attend.) - -The Foundation will continue to check in with the Source Management team regularly until at least the end of 2025 to ensure that we understand the value of the project going forward. - -The scope was co-created with srcmgr@. Work items are as follows: - -* Create a dashboard for the Source Management team to get a clearer picture of the bug backlog, and how effectively it's being managed (e.g. Time to First Attention for new bugs). -** Output: https://grimoire.freebsd.org/ -* Upgrade Bugzilla to a supported release to improve security and benefit from new functionality. -** Output: https://wiki.freebsd.org/Bugzilla/Roadmap -* Create a method for applying patches automatically. -** Output: https://github.com/linimon/patchQA -* Creating upstream documentation for running GrimoireLab (bug dashboard) on FreeBSD. -** Output: https://github.com/chaoss/grimoirelab/blob/main/FreeBSD.md - -===== Work Package B: Zero Trust Builds - -This work package intends to improve tooling and processes to support Zero Trust Builds of FreeBSD by extending the current components to enable the project to build release artifacts (package sets, ISO images, etc.) without requiring any special 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 (in progress) -** Formalize and document make world and release.sh (in review) -* Should -** Remove privilege from orchestration tooling (not started) -** Move build scripts into the public repository (in progress) -** Address dependencies (in progress) -* Could -** Environment Standardization (in progress) -** Ports to build reproducibly (in progress) -** CI to verify reproducibility (in progress) -** Documentation to allow 3rd parties to confirm reproducibility (not started) - -===== Work Package C: CI/CD Automation - -This work package intends to improve 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@ -* Must -** Improve quality of incoming commits (completed) -** Pre-merge CI (completed) -** Environment Metadata (in progress) -** Extend CI to the Ports tree (in progress) -** CI Threat Model (in progress) -** CI Management Process (in progress) -** Documentation (not started) -* Should -** 3rd-party Interoperability (in progress) -** Automated analysis in tests (in progress) -** Test Case Management (in progress) -* Could -** Granular Debugging (in progress) - -===== Work Package D: Ports and Packages security improvements - -This work package intends to modernize and extend security controls in the FreeBSD Ports and Package Collection by: Migrating from our VuXML Vulnerability Database to OSV or similar contemporary format; developing a package audit backend and server to reliably fetch vulnerability data from global agency databases in any format (JSON - NIST) and produce insight and; improving CI tooling for FreeBSD Ports. - -The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@ - -* Must -** New Database Format (in progress) -** Set up 2+ Database Instances (not started) -** Migrate Data from old to new database (in progress) -** Add support for new format in pkg(8) (in progress) -** Upstream engagement (in progress) -** SBOM on demand (not started) -** Document how to set up build and test targets (not started) -** Integrate 3rd party test targets (not started) -** Continuous Testing (not started) -* Could -** Make CI artifacts available (not started) - -===== Work Package E: SBOM improvements - -This work package intends to improve existing, and implement new, tooling and processes for FreeBSD Software Bill of Materials (SBOM) by implementing: tooling to roll up the individual provenance data/markers from across the tree into a higher-level view; developing tooling to parse/review/inspect the FreeBSD source tree and produce a comprehensive/holistic report to act as a SBOM for the full software stack and; extending pkg to enable this capability for software installed from ports/packages. - -The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@, releng@ - -* Must -** Evaluate projects/solutions available in the wider ecosystem (in progress) -** Propose the target solution for SBOM (in progress) -** Produce an SBOM in CI (e.g. weekly builds) (in progress) -** Produce an SBOM as an artifact as part of the release process (in progress) -** SBOM artifact on demand (in progress) -** Roll up existing data (in progress) -** Record and explain decisions made (in progress) -* Could -** Engage with other similar projects (in progress) - -Commissioning body: Sovereign Tech Agency +=== Infrastructure Modernization + +Contact: Ed Maste + +Contact: Alice Sowerby + +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 link:https://github.com/FreeBSDFoundation/all-projects/tree/main/Infrastructure%20Modernization%20(STA%20commissioned)[project information repo]. + +==== Q3 update + +All five work packages are in progress and will run until the end of December 2025, at which time the project will close. + +===== Work Package A: Technical Debt Reduction + +This work package is complete as of 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 bug backlog dashboard they commissioned remains available to help make the backlog easier to understand. + +In August, we held a panel discussion at link:https://osseu2025.sched.com/event/25VsE/from-backlog-to-breakthrough-how-freebsd-and-bitergia-tackled-7k+-bugs-with-data-driven-dashboards-alice-sowerby-freebsd-foundation-contractor-daniel-izquierdo-cortazar-miguel-angel-fernandez-sanchez-bitergia-moin-rahman-freebsd-project[Open Source Summit Europe] to share this work with a wider audience. +Two members of the Foundation project staff (Alice Sowerby and Moin Rahman) were on the panel along with two representatives from Bitergia who delivered the GrimoireLab implementation for this project. +(Members of the FreeBSD Project Source Management team were not available to attend.) + +The Foundation will continue to check in with the Source Management team regularly until at least the end of 2025 to ensure that we understand the value of the project going forward. + +The scope was co-created with srcmgr@. Work items are as follows: + +* Create a dashboard for the Source Management team to get a clearer picture of the bug backlog, and how effectively it is being managed (e.g. Time to First Attention for new bugs). +** Output: https://grimoire.freebsd.org/ +* Upgrade Bugzilla to a supported release to improve security and benefit from new functionality. +** Output: https://wiki.freebsd.org/Bugzilla/Roadmap +* Create a method for applying patches automatically. +** Output: https://github.com/linimon/patchQA +* Creating upstream documentation for running GrimoireLab (bug dashboard) on FreeBSD. +** Output: https://github.com/chaoss/grimoirelab/blob/main/FreeBSD.md + +===== Work Package B: Zero Trust Builds + +This work package intends to improve tooling and processes to support Zero Trust Builds of FreeBSD by extending the current components to enable the project to build release artifacts (package sets, ISO images, etc.) without requiring any special 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 (in progress) +** Formalize and document make world and release.sh (in review) +* Should +** Remove privilege from orchestration tooling (not started) +** Move build scripts into the public repository (in progress) +** Address dependencies (in progress) +* Could +** Environment Standardization (in progress) +** Ports to build reproducibly (in progress) +** CI to verify reproducibility (in progress) +** Documentation to allow 3rd parties to confirm reproducibility (not started) + +===== Work Package C: CI/CD Automation + +This work package intends to improve 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@ +* Must +** Improve quality of incoming commits (completed) +** Pre-merge CI (completed) +** Environment Metadata (in progress) +** Extend CI to the Ports tree (in progress) +** CI Threat Model (in progress) +** CI Management Process (in progress) +** Documentation (not started) +* Should +** 3rd-party Interoperability (in progress) +** Automated analysis in tests (in progress) +** Test Case Management (in progress) +* Could +** Granular Debugging (in progress) + +===== Work Package D: Ports and Packages security improvements + +This work package intends to modernize and extend security controls in the FreeBSD Ports and Package Collection by: Migrating from our VuXML Vulnerability Database to OSV or similar contemporary format; developing a package audit backend and server to reliably fetch vulnerability data from global agency databases in any format (JSON - NIST) and produce insight and; improving CI tooling for FreeBSD Ports. + +The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@ + +* Must +** New Database Format (in progress) +** Set up 2+ Database Instances (not started) +** Migrate Data from old to new database (in progress) +** Add support for new format in pkg(8) (in progress) +** Upstream engagement (in progress) +** SBOM on demand (not started) +** Document how to set up build and test targets (not started) +** Integrate 3rd party test targets (not started) +** Continuous Testing (not started) +* Could +** Make CI artifacts available (not started) + +===== Work Package E: SBOM improvements + +This work package intends to improve existing, and implement new, tooling and processes for FreeBSD Software Bill of Materials (SBOM) by implementing: tooling to roll up the individual provenance data/markers from across the tree into a higher-level view; developing tooling to parse/review/inspect the FreeBSD source tree and produce a comprehensive/holistic report to act as a SBOM for the full software stack and; extending pkg to enable this capability for software installed from ports/packages. + +The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@, releng@ + +* Must +** Evaluate projects/solutions available in the wider ecosystem (in progress) +** Propose the target solution for SBOM (in progress) +** Produce an SBOM in CI (e.g. weekly builds) (in progress) +** Produce an SBOM as an artifact as part of the release process (in progress) +** SBOM artifact on demand (in progress) +** Roll up existing data (in progress) +** Record and explain decisions made (in progress) +* Could +** Engage with other similar projects (in progress) + +Commissioning body: Sovereign Tech Agency diff --git a/website/content/en/status/report-2025-07-2025-09/geomman.adoc b/website/content/en/status/report-2025-07-2025-09/geomman.adoc index 81a97ee5ff..5fa04dd650 100644 --- a/website/content/en/status/report-2025-07-2025-09/geomman.adoc +++ b/website/content/en/status/report-2025-07-2025-09/geomman.adoc @@ -1,33 +1,33 @@ === Geomman Release Links: + link:https://gitlab.com/brauliorivas/geomman[geomman gitlab repo] URL: link:https://gitlab.com/brauliorivas/geomman[] + link:https://www.freshports.org/sysutils/geomman[geomman port] URL: link:https://www.freshports.org/sysutils/geomman[] Contact: Braulio Rivas Geomman is a partitioning tool (TUI) based on man:sade[8] that brings more functionality such as copying, pasting partitions, creating ext filesystems or encrypting partitions using man:geli[8]. Geomman is relevant for both newcomers and experienced users because it is a complete and unified management of partitions and disks. Features added to geomman since last report are: * Grow UFS, NTFS, ext2, ext3 and ext4 filesystems. * Shrink NTFS, ext2, ext3 and ext4 filesystems. * New partition dialog, where users can visually select a free space to place the partition to be pasted or moved, added to link:https://gitlab.com/alfix/bsddialog[bsddialog]. * Create exFAT, NTFS, ext2, ext3 and ext4 filesystems. * Check all the mentioned filesystems. Then, two GEOM-related features were added too: * Label man:glabel[8] new partitions. * Encrypt man:geli[8] new partitions by adding an optional "keyfile", plus a "passphrase" (or passfile). -Finally, with the help of mailto:fuz@FreeBSD.org[Robert Clausecker], we published the link:https://www.freshports.org/sysutils/geomman[geomman port] to let people try it out. +Finally, with the help of mailto:fuz@FreeBSD.org[Robert Clausecker], we published the link:https://www.freshports.org/sysutils/geomman[geomman port] to let people try it out. Future work includes: * Add geomman to FreeBSD natively (userland) * Add ZFS management Sponsor: Google Summer of Code 2025 diff --git a/website/content/en/status/report-2025-07-2025-09/hackathon.adoc b/website/content/en/status/report-2025-07-2025-09/hackathon.adoc index 663478e5b3..53cf41d276 100644 --- a/website/content/en/status/report-2025-07-2025-09/hackathon.adoc +++ b/website/content/en/status/report-2025-07-2025-09/hackathon.adoc @@ -1,25 +1,25 @@ === July 2025 FreeBSD Hackathon in Berlin, Germany Links: link:https://wiki.freebsd.org/Hackathon/202507[Event page] URL: link:https://wiki.freebsd.org/Hackathon/202507[] + Date: July Saturday 12th and Sunday 13th 2025 Location: Chaos Computer Club Berlin We had been invited to hold our two day Hackathon in the halls of the Chaos Computer Club Berlin. The full report can be found link:https://pad.lorenz.lu/Hackathon202507[here]. -The approximately 30 participants hacked on the the following projects: +The approximately 30 participants hacked on the following projects: * link:https://pad.lorenz.lu/Hackathon202507#Local-Chatbot-RAG-with-FreeBSD-Knowledge[Local Chatbot RAG with FreeBSD Knowledge] * link:https://pad.lorenz.lu/Hackathon202507#Cross-compiling-FreeBSD-on-macOS[Cross compiling FreeBSD on macOS] * link:https://pad.lorenz.lu/Hackathon202507#Pierre-P-khorben[Importing OpenSSL 3.5] * link:https://pad.lorenz.lu/Hackathon202507#Kristof-P-kp[The netlinkification of PF] * link:https://pad.lorenz.lu/Hackathon202507#Jan-B[Injecting host executable into jails] * link:https://pad.lorenz.lu/Hackathon202507#Li-Wen-H-lwhsu[Updating OpenSearch ports] * link:https://pad.lorenz.lu/Hackathon202507#Benedict-R-bcr[Ambushing Mark Phillips with a Microphone] * link:https://pad.lorenz.lu/Hackathon202507#Rodrigo-O-rodrigo[Patching rsync to handle extattr] * link:https://pad.lorenz.lu/Hackathon202507#NN[Checking LICENSE files against SPDX templates] * link:https://pad.lorenz.lu/Hackathon202507#Timo[TCP/UDP checksum offloading for bhyve] * link:https://pad.lorenz.lu/Hackathon202507#Dave-C-dch[Native FreeBSD containers with Podman] * and more. diff --git a/website/content/en/status/report-2025-07-2025-09/kde.adoc b/website/content/en/status/report-2025-07-2025-09/kde.adoc index 7d3e78181c..85447d5577 100644 --- a/website/content/en/status/report-2025-07-2025-09/kde.adoc +++ b/website/content/en/status/report-2025-07-2025-09/kde.adoc @@ -1,54 +1,56 @@ === KDE on FreeBSD Links: + link:https://freebsd.kde.org/[KDE/FreeBSD initiative] URL: link:https://freebsd.kde.org/[] + link:https://community.kde.org/FreeBSD[FreeBSD -- KDE Community Wiki] URL: link: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 mailto:kde@FreeBSD.org[KDE team] is part of mailto:desktop@FreeBSD.org[desktop@], building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation. -We missed last quarterly status report. The changes from the second quarter are included in this report. +We missed last quarterly status report. +The changes from the second quarter are included in this report. ==== Infrastructure CMake was updated to 3.31.9, the latest release in 3.x series. Ninja was updated to 1.13.1. Qt6 was updated to 6.9.2. Both of the Python bindings for the Qt6 toolkit have been updated to their latest releases: * PyQt6: updated to 6.9.1 * PySide6: updated to 6.9.2 The package:graphics/qt6-wayland[] port was patched to fix crashes of Plasma on Wayland when right-clicking the desktop. Qt5 was updated to 5.15.17 KDE patch collection. Upstream standard support for Qt5 is officially over. This might be the last update for Qt5 on FreeBSD. The package:www/qt5-webengine[] port has been updated to 5.15.19 with security patches up to Chromium 135.0.7049.95. The Qt5 WebEngine component, however, is and forever will be based on Chromium 87.0.4280.144, which is over 4 years old. -Security updates for the underlying Chromium base have now ceased. Use at your own risk. +Security updates for the underlying Chromium base have now ceased. +Use at your own risk. ==== KDE Stack KDE Frameworks, Plasma, and Gear release happen very regularly. mailto:kde@FreeBSD.org[KDE team] lands these updates shortly after their upstream release. * KDE Frameworks reached version 6.18.0. * KDE Plasma Desktop was updated to 6.4.5. * KDE Gear was updated to 25.08.1. Plasma 6.5 Beta (6.4.90) was ported but not committed to the main ports-tree. The package:net-mgmt/kf6-networkmanager-qt[] port with stub implementation for Linux NetworkManager was added to aid porting third-party software. ==== Related Ports The mailto:kde@FreeBSD.org[KDE team] maintains a wide range of ports and updates them all as needed. According to link:https://portscout.freebsd.org/kde@freebsd.org.html[Portscout] less than 0.7% ports are outdated. The KDE team would like to thank mailto:fluffy@FreeBSD.org[Dima Panov], mailto:arrowd@FreeBSD.org[Gleb Popov], mailto:jhale@FreebSD.org[Jason E. Hale], mailto:kenrap@kennethraplee.com[Kenneth Raplee], mailto:lbartoletti@FreeBSD.org[Loïc Bartoletti], and mailto:makc@FreeBSD.org[Max Brazhnikov] for keeping things up-to-date. The KDE team is grateful to Harley (SponiX on IRC) for sharing his building box. diff --git a/website/content/en/status/report-2025-07-2025-09/suspend.adoc b/website/content/en/status/report-2025-07-2025-09/suspend.adoc index 1e4f48a9bb..f56dc23e0b 100644 --- a/website/content/en/status/report-2025-07-2025-09/suspend.adoc +++ b/website/content/en/status/report-2025-07-2025-09/suspend.adoc @@ -1,29 +1,29 @@ === Suspend/Resume Improvement Links: + link:https://obiw.ac/s0ix/[Blog] URL: link:https://obiw.ac/s0ix/[] + link:https://youtu.be/RCjPc4X2Edc[BSDCan talk on s2idle/S0ix] URL: https://youtu.be/RCjPc4X2Edc[] + link:https://people.freebsd.org/~obiwac/s0ix/[Sleep testing image] URL: https://people.freebsd.org/~obiwac/s0ix/[] + -link:https://github.com/obiwac/freebsd-s0ix/tree/everything[Working Repo] URL: link:https://github.com/obiwac/freebsd-s0ix/tree/everything[] + +link:https://github.com/obiwac/freebsd-s0ix/tree/everything[Working Repository] URL: link:https://github.com/obiwac/freebsd-s0ix/tree/everything[] + link:https://reviews.freebsd.org/D48721[Tip of the s2idle/S0ix + AMD SMU stack] URL: https://reviews.freebsd.org/D48721[] + Contact: obiwac 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 reliably on the Framework 13 AMD Ryzen 7040 series laptops on FreeBSD 15. This required changes to LinuxKPI for DRM to know whether the system intends to enter S3 or S0ix: link:https://reviews.freebsd.org/D51591[D51591]. These changes in turn required the creation of generic sleep types, separate from ACPI. Not all of these changes have yet been committed, but new hw.power.* sysctls will be created to choose the sleep type for various sleep state transition requests. The amdsmu driver, some ACPI changes and fixes, and GPIO interrupt servicing in amdgpio have been committed. A pre-built sleep testing image is now available to easily testing 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 diff --git a/website/content/en/status/report-2025-07-2025-09/sylve.adoc b/website/content/en/status/report-2025-07-2025-09/sylve.adoc index 923b181cc5..0a1f6ee077 100644 --- a/website/content/en/status/report-2025-07-2025-09/sylve.adoc +++ b/website/content/en/status/report-2025-07-2025-09/sylve.adoc @@ -1,72 +1,73 @@ === Sylve -- A Unified System Management Platform for FreeBSD Links: + link:https://github.com/AlchemillaHQ/Sylve[GitHub] URL: link:https://github.com/AlchemillaHQ/Sylve[] + link:https://sylve-ci.alchemilla.io[CI] URL: link:https://sylve-ci.alchemilla.io[] + link:https://discord.gg/bJB826JvXK[Discord] URL: link:https://discord.gg/bJB826JvXK[] Contact: Hayzam Sherif Sylve is a modern, unified system management platform for FreeBSD, inspired by Proxmox. -We aim to provide 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 uses SvelteKit with Tailwind CSS and ShadCN UI components. +We aim to provide 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 uses SvelteKit with Tailwind CSS and ShadCN UI components. The project emphasizes a minimal system footprint, currently requiring only package:sysutils/smartmontools[], package:sysutils/tmux[], package:libvirt[], package:samba419[], package:swtpm[] as runtime dependencies. ==== Q3 Progress Highlights ===== Clustering Sylve now supports simple clustering with a single-pane-of-glass (SPOG) experience. This multi-master design, built on top of `hashicorp/raft` and SQLite, allows users to manage multiple nodes from a single interface. ===== Networking * Network Objects: Subnets, hosts, and MACs are now treated as first-class objects. Users can create and reuse them across VMs, Jails, and switches. * Manual Switches: Existing FreeBSD bridges can now be imported into Sylve and managed as switches. ===== Storage * A new file explorer has been introduced for managing each node's local filesystem (copy, cut, delete, etc.). * ZFS pools now feature extensive health monitoring, including support for special vdevs (cache, log, etc.). * Major performance improvements to ZFS dataset viewing and editing. * Ability to flash images to ZFS zvols directly from the UI. * Samba integration: Users can now create Samba shares. A comprehensive audit log has been added to track file share activity. ===== Authentication * Ability to create and manage users directly in the UI, including Samba users. * Groups can now also be created and managed from the UI. ===== Virtual Machines * Full VM editing is now supported (storage, network, PCI devices, etc.). * TPM support (via package:swtpm[]) is available in both UI and API, this feature is currently experimental. * Support for reusing existing raw disks. * Added Wake-on-LAN functionality for VMs. ===== Jails * Full support for thick jails (creation, editing, viewing). * Resource limiting for CPU and RAM has been implemented. * Networking for Jails supports both inherited configurations and switch-based (manual/standard) setups. ==== Roadmap Update Due to community demand, Q3 focused on clustering instead of firewalling and network services. The following items have been pushed to Q4: * Firewall rules configuration. * DHCP support. * WireGuard VPN integration. The current roadmap is to complete clustering with external storage backup support (e.g., S3) before returning to networking services. Contributions, testing, and feedback are very welcome. If you are interested in contributing, consider helping with: * UI testing and accessibility feedback. * Bug reports and feature requests via GitHub. Sponsor: FreeBSD Foundation and Alchemilla (development and infrastructure support) diff --git a/website/content/en/status/report-2025-07-2025-09/valgrind.adoc b/website/content/en/status/report-2025-07-2025-09/valgrind.adoc index 9a8a2e1193..390cc96d18 100644 --- a/website/content/en/status/report-2025-07-2025-09/valgrind.adoc +++ b/website/content/en/status/report-2025-07-2025-09/valgrind.adoc @@ -1,53 +1,59 @@ === Valgrind: preparing for 15.0-RELEASE Links: + link:https://www.valgrind.org/[Valgrind Home Page] URL: link:https://www.valgrind.org/[] + link:https://www.valgrind.org/docs/manual/dist.news.html[Valgrind News] URL: link:https://www.valgrind.org/docs/manual/dist.news.html[] + link:https://github.com/paulfloyd/freebsdarm64_valgrind[arm64 port] URL: link:https://github.com/paulfloyd/freebsdarm64_valgrind[] Contact: Paul Floyd -I have not submitted any reports for over a year. On the whole that is good news as it means that there have not been any major issues. Back then I said that aarch64 support was about to land and indeed it did in mid April 2024. +I have not submitted any reports for over a year. +On the whole that is good news as it means that there have not been any major issues. +Back then I said that aarch64 support was about to land and indeed it did in mid April 2024. -I added a nice little script for use with Valgrind called `vgscript`. This works in a similar manner to `pstack` (or `bstack` on FreeBSD) in that you give it a PID and it will generate a stack trace for that process. If you use `bstack` with a Valgrind process you will see the Valgrind call stack which is probably of no use to you. If you run `vgstack` with a Valgrind PID it will print the call stack of the test exe running under Valgrind. +I added a nice little script for use with Valgrind called `vgscript`. +This works in a similar manner to `pstack` (or `bstack` on FreeBSD) in that you give it a PID and it will generate a stack trace for that process. +If you use `bstack` with a Valgrind process you will see the Valgrind call stack which is probably of no use to you. +If you run `vgstack` with a Valgrind PID it will print the call stack of the test exe running under Valgrind. If you use Valgrind regularly could you take a look and answer the survey that I posted on the forums (if you have not done so already). Here is the link:https://forums.freebsd.org/threads/valgrind-feature-poll.98707/#post-716085[link]. Valgrind 3.26 is due out at the end of October 2025 and package:devel/valgrind[] will be updated shortly after that. package:devel/valgrind-devel[] will get one (or maybe more) updates as I fix issues with FreeBSD 15.0. The outstanding issues that I have on FreeBSD 15.0 are -* aarch64: there is a problem when using Valgrind with gdb/vgdb. Hitting ctrl-c to interrupt the process running under Valgrind does not work and Valgrind crashes with an assert. +* aarch64: there is a problem when using Valgrind with gdb/vgdb. + Hitting ctrl-c to interrupt the process running under Valgrind does not work and Valgrind crashes with an assert. * aarch64: a known old issue that was infrequent regarding initialisation of thread memory now seems to occur much more often. -* amd64: maybe similar to the first issue with gdb/vgdb and interrupting a process, but this time I'm seeing `select` return an 'impossible' value. +* amd64: maybe similar to the first issue with gdb/vgdb and interrupting a process, but this time I am seeing `select` return an 'impossible' value. * amd64: a test for `setcred` is getting an extra "Conditional jump" error message. Most of the above are not too serious unless you are a heavy user of gdb/vgdb. Here is a list of bugfixes since my last report, Q1 2024. * Several suppressions added for libc, libc++ and libstdc++ functions * Improvements to `setcontest` argument checking * Some more `aio_*` fixes * Syscall `_sysctlname` was checking the wrong length of the name argument * New syscall wrappers for `kcmp`, `getrlimitusage`, `close_range`, `fchroot`, `setcred`, `exterrctl`, `inotify_add_watch_at`, `inotify_rm_watch`, `jail_attach_jd` and `jail_remove_jd` * Started adding better `ioctl` argument checking * Fixes to Valgrinds self-checking modes * Support aarch64 auxv AT_HWCAP, AT_CHERI_STATS, AT_HWCAP3 and AT_HWCAP4 * Valgrind file descriptor checking has been significantly enhanced and this includes FreeBSD * Some old code that I could never test for FreeBSD 10 has been removed * Removed as much as possible FreeBSD version dependent code. This reduces everyday maintenance at the cost of making version-independent regression tests more difficult * Turn off check for lock created during text handling that will deliberately leak * Syscall `sigwait` was not correctly dealing with its atypical return value * Improved checking of `utrace` syscall arguments * amd64: syscall arguments 7 and 8 were swapped (it turns out that argument 8 is never needed and has been removed) * amd64: added `sysarch` subcommands `AMD64_SET_TLSBASE` and `AMD_GET_TLSBASE` * Reduced warnings that get printed in quiet (-q) mode * Improved checking done by `sysctl` kern.proc.pathname * Handle `mmap` MAP_STACK and MAP_GUARD * Syscalls `open*` now produce an error if you try to open the guest exe for writing * Syscalls `sigwait` and `sigwaitingfo` were too lax in accepting NULL arguments * Many of the `*at` system calls (like `faccessat`) were not checking that the directory fd is not one of the file descriptors reserved for Valgrind's use * Function `memalign` now accepts a size of zero