FreeBSD Status Report - First Quarter 2024

From: Lorenzo Salvadore <salvadore_at_freebsd.org>
Date: Sun, 05 May 2024 15:41:48 UTC
FreeBSD Status Report First Quarter 2024

Here is the first 2024 status report, with 21 entries.

The New Year brings us many new interesting projects, such as the new libsys
that separates system calls from libc and libpthread or work on a graphical
installer for FreeBSD, which will help making our OS more user-friendly. Of
course, the usual projects keep going on, such as the work on cloud-init,
OpenStack, or the GCC ports. As usual our main teams share their progress with
us.

Have a nice read.

Lorenzo Salvadore, on behalf of the Status Team.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A rendered version of this report is available here:
https://www.freebsd.org/status/report-2024-01-2024-03/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents

  • FreeBSD Team Reports
      □ FreeBSD Core Team
      □ FreeBSD Foundation
      □ FreeBSD Release Engineering Team
      □ Cluster Administration Team
      □ Continuous Integration
      □ Ports Collection
  • Projects
      □ Audio Stack Improvements
      □ Bhyve Improvements
      □ Graphical Installer for FreeBSD
  • Userland
      □ libsys
      □ PackageKit backend for FreeBSD pkg
  • Kernel
      □ iwlwifi(4) and wireless for 13.3-RELEASE
  • Architectures
      □ Ten64, WHLE-LS1, and HoneyComb
  • Cloud
      □ FreeBSD on Microsoft HyperV and Azure
      □ FreeBSD as a Tier 1 cloud-init Platform
      □ OpenStack on FreeBSD
  • Documentation
      □ Documentation Engineering Team
  • Ports
      □ FreshPorts: Notification of new packages
      □ GCC on FreeBSD
      □ Valgrind: port to arm64 on its way
  • Third Party Projects
      □ Containers and FreeBSD: Pot, Potluck and Potman

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FreeBSD Team Reports

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

FreeBSD Core Team

Contact: FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team is the governing body of FreeBSD.

13.3-RELEASE

FreeBSD 13.3 was released on March 5th, 2024.

The release announcement is at:

https://www.freebsd.org/releases/13.3R/announce/

Along the release engineering team, the project dedicates the 13.3-RELEASE to
Glen Barber, with thanks for his many years of contributions as Release
Engineer.

Future of 32-bit platform support

Core announced Future of 32-bit platform support in FreeBSD for deprecating
32-bit platforms over the next couple of major releases.

Commit bits

  • Core approved the src commit bit for Bojan Novković

  • Core reactivated the src commit bits for Mark Peek, Mark Murray, and
    Lawrence Stewart

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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 organization dedicated to
supporting and promoting the FreeBSD Project and worldwide community, and
helping to advance the state of FreeBSD. We do this in both technical and
non-technical ways. We are 100% supported by donations from individuals and
corporations and those investments help us fund the:

  • Software development projects to implement features and functionality in
    FreeBSD

  • Sponsor and organize conferences and developer summits to provide
    collaborative opportunities and promote FreeBSD

  • Purchase and support of hardware to improve and maintain FreeBSD
    infrastructure

  • Resources to improve security, quality assurance, and continuous
    integration efforts

  • Materials and staff needed to promote, educate, and advocate for FreeBSD

  • Collaboration between commercial vendors and FreeBSD developers

  • Representation of the FreeBSD Project in executing contracts, license
    agreements, and other legal arrangements that require a recognized legal
    entity

Operations

We kicked off the new year with ambitious goals to help move the FreeBSD
Project forward by identifying features and functionality to support in the
operating system and increasing our advocacy efforts to increase and expand the
visibility of FreeBSD. Stay tuned for a blog post that will provide more
information on our 2024 goals and plans.

We also published the 2024 Budget. In order to provide greater transparency
about the budgeting process, we wrote a blog post that provides more details on
how funding is allocated, new breakouts of some of the project expense
categories, and more details on where the funding is going.

OS Improvements

During the first quarter of 2024, 180 src, 65 ports, and 18 doc tree commits
identified The FreeBSD Foundation as a sponsor.

Three new projects began this quarter.

  • Work began to improve FreeBSD’s audio stack and provide audio developers
    with useful tools and frameworks to make sound development on FreeBSD
    easier. Read more in Christos Margiolis Audio Stack Improvements report
    entry.

  • Olivier Certner began his second contract with the Foundation, and this
    time around, the main goal is to make unionfs stable and useful on FreeBSD.
    Other work may include revamping VFS lookups, improving out-of-memory
    handling, implementing a notification system for en-masse detection of
    filesystem changes such as inotify, and improving console usability.

  • This quarter, a new project to add hierarchical rate limits to the OpenZFS
    file system began. Pawel Dawidek will add support for limits that will be
    configurable, similar to quotas, but would limit the number of read/write
    operations and read/write bandwidth.

Six projects continued this quarter.

  • You can read about the continued work to port OpenStack components to
    FreeBSD in Chih-Hsin Chang’s OpenStack on FreeBSD report entry.

  • Work continued to improve cloud-init support for FreeBSD. You can read
    about Mina Galić’s work in her FreeBSD as a Tier 1 cloud-init Platform
    report entry.

  • A new joint project began between Advanced Micro Devices (AMD) and The
    FreeBSD Foundation to develop a complete FreeBSD AMD IOMMU driver. This
    work will allow FreeBSD to fully support greater than 256 cores with
    features such as CPU mapping and will also include bhyve integration. For
    those interested in the technical details, follow Konstantin Belousov
    commits tagged with Sponsored by fields for Advanced Micro Devices (AMD)
    and The FreeBSD Foundation.

  • Refer to Pierre Pronchery’s Graphical Installer for FreeBSD report entry to
    read about the status of FreeBSD’s new graphical installer.

  • Work continues to port the Vector Packet Processor (VPP) to FreeBSD. VPP is
    an open-source, high-performance user space networking stack that provides
    fast packet processing suitable for software-defined networking and network
    function virtualization applications. Look for a pending article from the
    developer working on the project, Tom Jones, that details the experience of
    porting VPP to FreeBSD.

  • Björn Zeeb and Cheng Cui continue their wireless work. This quarter was
    mostly focused on bug fixes and stability improvements to LinuxKPI 802.11
    and net80211. Much of this work made it into the 13.3 release.

Here is a sampling of other Foundation-sponsored development completed over the
first quarter of 2024:

  • FreeBSD was accepted in Google Summer of Code 2024 after receiving 22
    contributor proposals; on May 1, we will learn how many projects we will be
    awarded

  • OpenSSH: update to 9.6p1 then 9.7p1

  • Deprecate bsdlabel

  • Import the kernel parts of bhyve/arm64

  • Various RISC-V improvements

FreeBSD Infrastructure

A contract was completed to set up a new cluster site at NYI Chicago. You can
read about the details of that project on the Foundation’s blog.

Continuous Integration and Workflow Improvement

As part of our continued support of the FreeBSD Project, the Foundation
supports a full-time staff member dedicated to improving the Project’s
continuous integration system and the test infrastructure. The full update can
be found within the quarterly status report.

Partnerships and Research

A focus of Partnerships this Quarter has been to educate the industry about the
innovations in the FreeBSD community and the impact that FreeBSD continues to
have as a cornerstone to our digital society. This is an ongoing priority, and
one we invite (encourage) everyone using and working on FreeBSD to join us in.
Greg Wallace, the Foundation Partnerships lead, is grateful for the
opportunities he has had to meet with open source and industry leaders at
Microsoft, Google, AWS, OpenSSF, Alpha-Omega, CISA, Eclipse Foundation, Open
Source Initiative, Apache Software Foundation, Rust Foundation, Red Hat, Linux
Foundation and many others to ensure they have visibility into the key role
FreeBSD plays in the global digital infrastructure. This is a role FreeBSD has
earned through its technical excellence, security by design, high availability,
simplicity of operations, commitment to open source collaboration, and
cohesiveness.

One sees these characteristics of FreeBSD in the important ongoing funded
development work such as porting VPP to FreeBSD, sponsored by RG Nets.

Ensuring industry visibility to the excellence and impact of FreeBSD is vital
to ensuring tier one support for FreeBSD across all key hardware and software
platforms. As a community, every conversation we have with people outside the
BSD communities, and every piece of content we publish, that attest to how
FreeBSD powers our individual and corporate success, brings us one step closer.

To this end, the Foundation is working on a FreeBSD Impact Report that will
aggregate the core and often mission critical role FreeBSD plays in society,
from embedded systems powered by QNX, to payments and check processing, to
digital entertainment, internet and cybersecurity infrastructure.

Our community is stepping up in innumerable ways, including to make sure
FreeBSD supports industry-standard containerized workloads — check out the Open
Container Initiative FreeBSD runtime extension working group.

The recently opened hardware vendor support survey will feed into a hardware
support guide that reflects the collective experience of all respondents that
is intended to help everyone identify hardware vendors that prioritize FreeBSD;
it will also help focus Partnerships' outreach on the priority vendors.

To close, please TELL THE WORLD YOU USE FREEBSD AND WHY. There is no wrong way
to do this — put it on your blog, on your favorite social media channel, list
FreeBSD on your company’s Open Source page, contact the Foundation about a Case
Study, etc.

Stormshield, a leading cybersecurity company based in Europe, provides a great
example of how vendors that use FreeBSD can do this. The footer of their blogs
says: "A strong supporter of Open Source, Stormshield is an active member (and
sponsor) of the FreeBSD community…​Whenever we modify Open Source software,
make patches or add features, we offer them to the community for inclusion."

Advocacy

The first quarter of 2024 marked the beginning of a new era for the Foundation
Advocacy team. We welcomed Kim McMahon in the role of Senior Director of
Advocacy and Community and also brought on two new technical writers to help
increase the frequency and depth of the FreeBSD-related content we produce.
Just some of our expanded Q1 efforts to support FreeBSD are below.

  • Began work planning the on the May 2024 FreeBSD Developer Summit,
    co-located with BSDCan, taking place May 29-30, 2024 in Ottawa, Canada

  • Introduced FreeBSD to new and returning folks at State of Open Con 24 in
    London, UK, February 6-7, 2024

  • Held an Introduction to FreeBSD half-day workshop and staffed a booth at
    SCaLE21x, which took place March 14-17, 2024 in Pasadena, CA. Thanks to
    Gordon Tetlow for his help with the workshop

  • The Foundation team also worked on a common message on the improvement and
    benefits of FreeBSD to ensure consistency between the FreeBSD Foundation
    and Core Team

  • Members of the Foundation team served as Administrators for the 2024 Google
    Summer of Code. This year marks the 20th anniversary of Google Summer of
    Code and the 20th year that the FreeBSD Project was accepted as a mentoring
    organization. The Project received 23 applications from prospective interns

  • Provided an overview of FreeBSD 13.x including the 13.3 release

  • Worked on the final report of the 2024 FreeBSD Community Survey. Be on the
    lookout for the report at the end of April

  • In partnership with Innovate UK and Digital Security by Design (DSbD), the
    Foundation held the first annual Digital Security by Design (DSbD)
    Ecosystem Beacon Awards to celebrate innovators working with and enhancing
    CheriBSD

  • Published numerous blogs including:

      □ What Makes the FreeBSD Governance Model Successful

      □ Guiding the future of FreeBSD releases: Colin Percival, the new Release
        Engineering Team Lead

  • Authored or participated in a number of Thought Leadership and News
    articles including:

      □ The Cybersecurity Battle Has Come to Hardware

      □ Ampere in the Wild: How FreeBSD Employs Ampere Arm64 Servers in the
        Data Center

      □ ISAs and the Dawning Hardware Security Revolution

      □ Published the March 2024 FreeBSD Update with a new look

      □ Released the November/December 2023 and January/February 2024 issues of
        the FreeBSD Journal now with HTML versions of the articles

Fundraising

Thank you to everyone who gave us a financial contribution last quarter to help
fund our work to support the Project. 2024 started strong with a total of
$250,855 raised this quarter. We are grateful for your investment in FreeBSD!

Please consider supporting our efforts in 2024 by making a donation here:
https://freebsdfoundation.org/donate/.

Or, check out our Partnership opportunities here:
https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/.

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 13.3-RELEASE announcement URL: https://www.freebsd.org/releases/13.3R/announce/
FreeBSD 14.1-RELEASE schedule URL: https://www.freebsd.org/releases/14.1R/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.

During the first quarter of the year, the Team managed 13.3-RELEASE, leading to
the final RELEASE build and announcement in March. Planning has started for the
upcoming 14.1-RELEASE cycle.

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cluster Administration Team

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm

Contact: Cluster Administration Team <clusteradm@FreeBSD.org>

FreeBSD Cluster Administration Team members are responsible for managing the
machines the Project relies on to synchronize its distributed work and
communications.

In this quarter, the team has worked on the following:

  • Regular support for FreeBSD.org user accounts.

  • Regular disk and parts support (and replacement) for all physical hosts and
    mirrors.

  • Set up a new mirror in Chicago.

FreeBSD Official Mirrors Overview

Current locations are Australia, Brazil, Germany, Japan (two full mirror
sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror
site), United States of America — California, Chicago, New Jersey (primary
site), and Washington.

The hardware and network connection have been generously provided by:

  • Bytemark Hosting (being decommissioned)

  • Cloud and SDN Laboratory at BroadBand Tower, Inc

  • Department of Computer Science, National Yang Ming Chiao Tung University

  • Equinix

  • Internet Association of Australia

  • Internet Systems Consortium

  • INX-ZA

  • KDDI Web Communications Inc

  • Malaysian Research & Education Network

  • MetaPeer

  • New York Internet

  • NIC.br

  • Teleservice Skåne AB (new since 2023Q4)

  • Your.Org

New official mirrors are always welcome. We have noted the benefits of hosting
single mirrors at Internet Exchange Points globally, as evidenced by our
existing mirrors in Australia, Brazil, and South Africa. If you are affiliated
with or know of any organizations willing to sponsor a single mirror server,
please contact us. We are particularly interested in locations on the United
States West Coast and throughout Europe.

See generic mirrored layout for full mirror site specs and tiny-mirror for a
single mirror site.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Continuous Integration

Links:
FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
FreeBSD CI Tinderbox view URL: https://https://tinderbox.freebsd.org
FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI
3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI
Tickets related to freebsd-testing@ URL:
https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals
FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci

Contact: Jenkins Admin <jenkins-admin@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

In the first quarter of 2024, we worked with the project contributors and
developers to address their testing requirements. Concurrently, we collaborated
with external projects and companies to enhance their products by testing more
on FreeBSD.

Important completed tasks:

  • With help from clusteradm, the host running test VMs had disk and memory
    upgraded by reusing the parts of decommissioned machines.

  • Update the build environment of stable/13 jobs to 13.3-RELEASE.

  • Turn i386 build on main branch to use cross build on amd64.

Work in progress tasks:

  • Merging https://reviews.freebsd.org/D43786

  • Merging https://reviews.freebsd.org/D36257

  • Adding new hardware purchased by the FreeBSD Foundation to the CI cluster

  • Designing and implementing pre-commit CI building and testing and pull/
    merge-request based system (to support the workflow working group)

  • Proof of concept system is in progress.

  • Designing and implementing use of CI cluster to build release artifacts as
    release engineering does, starting with snapshot builds

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Redesigning the hardware test lab and adding more hardware for testing

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Planning to run ztest tests

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages:
    3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and do
not hesitate to join the effort!

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ports Collection

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#
ports-contributing
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: Tobias C. Berner <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>

The Ports Management Team is responsible for overseeing the overall direction
of the Ports Tree, building packages, and personnel matters. Below is what
happened in the last quarter.

According to INDEX, there are currently 32,244 ports in the Ports Collection.
There are currently ~3,300 open ports PRs. The last quarter saw 12,991 commits
by 158 committers on the main branch and 888 commits by 61 committers on the
2024Q1 branch. Compared to last quarter, this means a large increase in the
number of commits on the main branch (up from 9,424) and slightly more
backports to the quarterly branch (up from 781). The number of ports also
increased (up from 31,942).

In Q1 there were around 14,127 commits to main: The most active committers
were:

  • 2934 sunpoet

  • 2676 bofh

  • 1297 yuri

  • 748 eduardo

  • 545 jbeich

  • 347 arrowd

  • 233 diizzy

  • 195 yasu

  • 170 ehaupt

  • 164 wen

A lot has happened in the ports tree in the last quarter, an excerpt of the
major software upgrades are:

  • pkg 1.21.0

  • New USES: ocaml

  • Default version of gcc switched to 13

  • Default version of ruby switched to 3.2

  • Default version of lazarus switched to 3.2.0

  • Default version of go switched to 1.21

  • Chromium updated to 123.0.6312.105

  • Electron-28 updated to 28.2.10

  • Electron-27 updated to 27.3.9

  • Firefox updated to 124.0.2

  • Firefox-esr updated to 115.9.1

  • KDE updated to Frameworks 5 5.115, Frameworks 6 to 6.0.0 Plasma Desktop 5
    to 5.27.11, Plasma Desktop 6 to 6.0.2

  • Qt5 updated to 5.15.13

  • Qt6 updated to 6.6.3

  • Python updated to 3.11.9, 3.10.14 and 3.8.10

  • Ruby updated to 3.2.3

  • Rust updated to 1.77.0

  • SDL updated to 2.30.2

  • Sway updated to 1.9

  • wlroots updated to 1.17.2

  • Wine updated to 9.0

  • Xorg server updated to 0.17.2

During the last quarter, FreeBSD Packages Management Team ran 17 exp-runs to
test various ports upgrades, updates to default versions of ports, subpackage
support and base system changes.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Projects

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

Audio Stack Improvements

Contact: Christos Margiolis <christos@FreeBSD.org>

The FreeBSD audio stack is one of those fields that does not attract the same
attention and development as others do, since it has been left largely
unmaintained, and, although high in quality, there is still room for
improvement — from lack of audio development frameworks, to missing userland
utilities and kernel driver-related bugs. This project is meant to touch on all
those areas, and as such, is more of a general improvement project, than an
implementation of a specific feature.

So far, my focus has been towards the kernel side of the audio stack, with
D43545 being probably the most requested and notable patch. I am also working
on scrapping the rather outdated "snd_clone" audio device cloning framework of
sound(4), and replacing it with DEVFS_CDEVPRIV(9) (D44411).

Some of the future tasks include:

  • Attempt to find a better (ideally automatic) way to handle snd_hda(4)
    pin-patching.

  • Implement an oss(3) library and audio(8) utility, in similar fashion to
    mixer(3) and mixer(8).

  • Write a bluetooth device management utility.

  • Improve mixer(3) and mixer(8).

  • Improve documentation and test suite where needed.

A more detailed description can be found here.

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

  • Report #1

  • Report #2

  • Report #3

  • Report #4

  • Report #5

  • Report #6

  • Report #7

  • Report #8

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Bhyve Improvements

Links:
bhyve production users calls URL: https://callfortesting.org
FreeBSD Wiki - Enterprise Working Group URL: https://wiki.freebsd.org/EnterpriseWorkingGroup
FreeBSD Wiki - EWG - bhyve and jails management tooling URL: https://wiki.freebsd.org/ChrisMoerz/bhyve_management
Jan Bramkamp’s work on s6rc URL: http://static.bultmann.eu/s6-talk/
vmstated on GitHub URL: https://github.com/christian-moerz/vmstated
YouTube - vmstated explained URL: https://www.youtube.com/watch?v=f60NCrunXyw

Contact: Chris Moerz <freebsd@ny-central.org>

Bhyve I/O Performance Measurements

Participants of the weekly bhyve production users calls recently discussed
bhyve’s I/O performance. Various ways of measuring and comparing were brought
up, however it was quickly clear that there is currently no formal analysis and
report on this. So, we started this effort in the hopes of better understanding
the various impacts of configuration options for a guest on its I/O
performance. We created a set of shell scripts that harness a FreeBSD guest for
running benchmarks/fio I/O performance measurements under various
configurations. This allows us to compare multiple criteria like bandwidth,
latency, IOPS, and more.

So far, we are testing for

  • different storage backends (i.e. ahci-hd, nvme, virtio-blk)

  • different memory settings

  • different CPU pinning options

  • different block sizes for the backing storage

  • different block sizes for accessing virtual disks

We are also pitting results for different CPU manufacturers against each other
and contrasting guest vs host performance to better understand the performance
impact of virtualization.

We plan to continue discussing our results during Michael Dexter’s weekly bhyve
production users call - come join us if you are interested. We also hope to be
able to present the results at EuroBSDCon in Q3.

Bhyve Virtual Machine Tooling

Last year, Greg Wallace at the FreeBSD Foundation founded the Enterprise
Working Group with the specific goal of addressing pain points of Enterprise
users of FreeBSD. One of the work groups that emerged clustered around bhyve
and jails management tooling. After collecting a set of desired features and
functionality, one overarching key point for bhyve emerged: the desire to have
configuration concepts and tooling for bhyve like the ones available for jails.

While other desirable features were identified as well, i.e. TPM software
emulation and snapshot/restore/host-migration, the conceptual tooling question
won over those due to the lower degree of complexity and its clarity on goal
and the path on how to take steps towards it.

Technically, this means working out existing gaps around process supervision
and virtual machine state management. First steps were taken by experimenting
with existing frameworks (i.e. s6rc work by Jan Bramkamp) and
eventually — through discussions in the weekly bhyve production user’s calls
(organized by Michael Dexter) — this led to a proof-of-concept implementation
of "vmstated".

Started as an experiment to better understand the problem space of process
supervision and virtual machine state handling, vmstated is constructed of a
daemon and vmstatedctl management utility. It is built with base-only tooling
and libraries and leverages FreeBSD specific constructs like kqueue to minimize
its resource impact.

vmstated is configured via a UCL configuration file (similar to jails.conf)
and — in combination with a bhyve_config(5) configuration file — already
provides highest flexibility in configuring virtual machines. vmstatedctl
provides a jail-like command set to start, stop, and retrieve status
information about guests. State transitions can easily be hooked via shell
scripts and allow running additional commands for network or storage set up and
tear down when relevant state changes occur.

An initial release is already in ports as sysutils/vmstated and updates are
pending commit; however, the newest version can be found on GitHub. We are
considering expanding the work; we would also like to invite anyone interested
to join us in this work! Patches, suggestions, feedback, etc. are all very much
welcome!

If you want to know more about our work, come join us at one of Michael
Dexter’s weekly bhyve production users calls or reach me by email.

Documentation

We managed to update a few parts of the Handbook and Porter’s Handbook (thanks
to Ed Maste, Joseph Mingrone, Pau Amma, and Rodney W. Grimes):

  • several improvements and expansions to the virtualization chapter in the
    FreeBSD Handbook

      □ using a bhyve_config(5) configuration file

      □ jailing bhyve

      □ experimental snapshot and restore feature

      □ setting up a Windows guest

  • we also have a review (D43940) up for an initial step to improving the
    bhyve man page

      □ this was intentionally started with a structural update first to
        separate the many -s flag options

      □ once this lands, we can move to a more widespread update to the overall
        content

Feedback is obviously very welcome — on the existing content as well as any
additional content we should be looking into!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Graphical Installer for FreeBSD

Links:
Slides from AsiaBSDCon 2024 URL: https://people.defora.org/~khorben/FreeBSD/bsdinstall/bsdinstall%20-%20Now%20with%20Graphics!%20-%20AsiaBSDCon%202024%20-%20WIP%20Session.pdf
gbsddialog URL: https://github.com/khorben/gbsddialog
preview video URL: https://youtu.be/jm6byc7N2O4

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

The first hurdle to overcome when testing a new Operating System is to get it
installed. What is more, the first impression new users gather from an
Operating System is its installation process. The state of the art for
Operating System installers nowadays definitely involves a graphical process.
This is the case for mainstream systems but also for other UNIX systems
comparable to FreeBSD: RedHat Enterprise Linux, Ubuntu, Debian GNU/Linux, or
even Devuan GNU+Linux Regardless of the technical level of the actual user,
this is how the platform will be compared in the public eye.

In practice, FreeBSD has already been derived as a desktop-oriented Operating
System by different projects. Of these, I only found GhostBSD as a maintained
project offering a graphical procedure to install the system. The objective
here was to consider a procedure that FreeBSD could adopt as part of its base
system, in order to ship a graphical installer much like the current installer.
However, GhostBSD’s installer relies on a Gtk+ interface driven with Python,
implying a hefty footprint on the installation media when adopting FreeBSD’s
usual image generation procedure. It would also imply importing and maintaining
new projects into the ports tree.

Instead, with knowledge of the current bsdinstall(8) and bsdconfig(8)
utilities, I envisioned a BSD-licensed replacement for Xdialog(1). Just like
when invoking bsdconfig with the -X switch for graphical mode, it could be
dropped in instead of bsddialog(1) and allow graphical installation - while
sharing the infrastructure of the current installer. To avoid confusion with
the current implementation of Xdialog from the x11/xdialog port, I have named
its replacement gbsddialog(1). It also has to be said that Xdialog is quite
obsolete (latest release in 2006) and this shows visually too.

After creating a Proof-of-Concept prototype past the 14.0 release, I was
provided with a 2-months window by the FreeBSD Foundation, in order to complete
a working implementation. Thanks to a few shortcuts, I was glad to present the
outcome of this effort during the WIP session of AsiaBSDCon 2024, including a
working graphical installer.

Most of the necessary patches are already available for review in FreeBSD’s
Phabricator:

  • D44279 bsdinstall: implement adduser with bsddialog

  • D44280 bsdinstall: implement rootpass with bsddialog

  • D44670 bsdinstall: implement timezone with bsddialog

  • D44671 bsdinstall: allow forcing a specific partitioning mode

  • D44672 bsdinstall: obtain the dialog binary from $DIALOG

  • D44673 bsdinstall: handle command-line options in targets

  • D44674 bsdinstall: add support for graphical mode

I have tried to keep these patches in growing order of friction expected before
integration.

The most important objective of this project was to improve bsdinstall,
regardless of the success of this integration. From the items above, it should
be noted that D44279, D44280, D44670 are expecting to improve the general look
& feel of the installer, even while in text mode. Similarly, D44671 and D44672
improve the overall versatility of the installer when scripted or customized.
D44673 and D44674 bring it on par with bsdconfig -X, even allowing the
graphical installation of jails.

Some parts are still missing, or made use of shortcuts still unsuitable for
integration:

  • The "fetchmissingdists" target was avoided by shipping every component on
    the installation media;

  • The "checksum" and "extract" targets had to be re-implemented with simpler
    code, degrading the user experience also with the regular installer;

  • Creation of the installation media generates an additional, heavy image
    (almost 8 GB), and is suspected to be hindered by a bug in makefs(8).

The corresponding code can be found in my GitHub fork in the khorben/
bsdinstall-graphical4 branch. As can be guessed from the branch name, depending
on the complexity of rebasing operations, combined with the (hopefully)
progressive integration of the changes proposed, new branches may be added to
keep track of the progress. (In fact a khorben/bsdinstall-graphical5 branch
already exists.)

Still, a lot needs to be done for the installer to reach a new level of
maturity overall. While working on this project, I have received general
complaints on the installer, and calls for a complete rewrite. It is true that
the current code base suffers from a number of issues and limitations. The lack
of a graphical installer is one of many symptoms, which range from the lack of
recovery from errors, of navigability to previous steps, of a general vision of
the installation progress, or of a network-based installer. In the meantime,
this is the installer we have and are familiar with, and I think it can still
be saved and improved.

Special thanks go to Ed Maste and Joe Mingrone for the opportunity, and to
Philippe Audeoud, Tobias C. Berner, Olivier Certner, Jessica Clarke, Olivier
Cochard-Labbé, Baptiste Daroussin, Brad Davis, Michael Dexter, Li-Wen Hsu,
Mateusz Piotrowski, Alfonso Siciliano, Emmanuel Vadot, and Robert Watson for
the feedback, reviews, and encouragements. (If I missed anyone, you know I did
not mean to!)

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Userland

Changes affecting the base system and programs in it.

libsys

Contact: Brooks Davis <brooks@FreeBSD.org>

The libsys project removes direct system calls from libc.so and libpthread.so
(aka libthr.so) to a separate libsys.so. This will:

  • Isolate language runtimes from the details of system call implementations.

  • Better support logging and replay frameworks for systems calls.

  • Support elimination of the ability to make system calls outside trusted
    code in the runtime linker and libsys.

This work was initially inspired by a compartmentalization prototype in
CheriBSD in 2016. Ali Mashtizadeh and Tal Garfinkel picked that work up and
attempted to upstream it (D14609). Unfortunately we could not figure out how to
review and land the massive reorganization required through a phabricator
review so it languished. Last year the CHERI project once again found a need
for system call separation in a new library-based compartmentalization
framework in CheriBSD so I rebuilt the patch from scratch, committing dozens of
libc cleanups along the way. I landed the first batch of changes on February
5th. Since then I have made a number of refinements to the way we link libsys
as well as which symbols are provided in which library.

Thanks to Konstantin Belousov for many rounds of review and feedback as well as
runtime linker fixes. Thanks to Mark Johnston for runtime linker debugging and
Dimitry Andric for sanitizer fixes. Thanks also to everyone who reported bugs
and helped debug issues.

Known issues (as of the end of the reporting period)

  • The libsys ABI is not yet considered stable (it is safe to assume __sys_foo
    () will be supported so language runtimes can use it now).

  • Programs using the address sanitizer must be linked with -lsys (resolved in
    base at publication time).

TODO

  • Add a libsys.h. (See D44387 and other reviews in the stack.)

  • Update intro(2) for libsys.

  • Finalize the ABI. I am likely to reduce the set of _ (underscore) prefixed
    symbols we expose.

  • MFC the existence of libsys? It is not clear this is practical, but it
    might be possible to MFC something useful for language runtimes.

Help wanted

  • Port language runtimes that do not use libc to use libsys for system calls
    rather than rolling their own interfaces.

  • Explore limitations on where system calls can be made similar to OpenBSD’s
    msyscall(2) (now obsolete) and pinsyscalls(2) (not an obvious match to our
    libsys).

Sponsor: AFRL, DARPA

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PackageKit backend for FreeBSD pkg

Contact: Gleb Popov <arrowd@FreeBSD.org>

PackageKit is a small D-Bus daemon program that serves as a backend for
"application store" type of apps - most notably Plasma Discover and Gnome
Software Center. The latest PackageKit release features a libpkg backend, which
means that you can now use PackageKit-enabled programs on FreeBSD to manage
software. Plasma Discover is already switched to using PackageKit, so you will
get it working out of the box once you update your ports/packages.

If you observe any crashes or bugs in PackageKit please let me know by opening
an issue upstream. If you are interested in contributing, there is a lot of
work to do too!

Sponsor: Serenity Cybersecurity, LLC

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Kernel

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

iwlwifi(4) and wireless for 13.3-RELEASE

Links:
Categorised Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0

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

In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally
make iwlwifi(4) usable. The upcoming 14.1-RELEASE will benefit from this work
too. The response has since generally been positive and iwlwifi(4) supporting
chipsets up to BE200 seems mostly stable, yet still slow.

A lot of testing was provided by the FreeBSD Foundation and by many users.
Massive thanks to everyone who tested, reported back, updated PRs and helped
other users.

I have also slowly started to "categorise" more (old) wireless problem reports
and will try to continue with some spring cleaning throughout the year.

If you have questions or feedback please use the freebsd-wireless mailing list.
That way everyone will see, be able to join in, and the answers will be
publicly archived.

Sponsor: minipci.biz (BE200 hardware)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Architectures

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

Ten64, WHLE-LS1, and HoneyComb

Links:
My wiki page with links to some status URL: https://wiki.freebsd.org/BjoernZeeb
/

Contact: Bjoern A. Zeeb <bz@FreeBSD.ORG>

Solid-Run’s HoneyComb, Traverse Technologies’s Ten64 and some versions of
Conclusive Engineering’s WHLE-LS1 all are NXP based platforms with the Data
Path Acceleration Architecture Gen2 (DPAA2).

Work has happened to support or improve support for peripherals on these
boards.

For DPAA2 I have local changes which will need review (or further discussion):

  • Cleanup of memac (MDIO) code reducing bus attachment (ACPI and FDT
    specific) code into more common code.

  • Cleanup of MC bus attachment code (again ACPI, FDT).

  • For reasons of mii_fdt.c support on some PHYs on FDT-based platforms
    restructure MAC/MII code and mostly migrate it out of the network interface
    (NI).

  • Improve Dmitry Salychev’s (dsl) initial SFF/SFP code, prototyping a bus
    similar to MII for SFP with the hope that with more work it can grow into a
    larger, general FreeBSD framework and hooked it up to DPMAC.

  • With this, minimal support (still fairly hacked up) for "managed" SFP+ mode
    (using the Ten64 terminology) is usable on FDT-based systems using DAC and
    fiber cables.

  • Add more sysctl statistics to DPMAC and NI.

In short, I mostly cleaned up some of the mess I contributed to during the
initial bring-up.

For the LS1088a based WHLE-LS1 systems changes include:

  • device-tree file updates.

  • Added support for the PCA9546 I2C Switch (committed).

  • Added basic support for the PCAL6524 24-bit Fm+ I2C-bus/SMBus I/O expander.

  • Added basic support for the PCA9633 4-bit Fm+ I2C-bus LED driver to drive
    the status LEDs.

  • Added support to program the rgephy(4) LEDs (which needs to be validated).

  • Started testing the eMMC with MMCCAM and GENERIC but had trouble (needs
    further investigation, seemed fine from firmware for updates).

  • Tested one of three PCIe slots and USB fine.

For the Ten64:

  • Most of the basic lifting happened a while ago and it has generally been
    usable.

  • Detecting the VSC8514 PHY as such went in end of last year.

  • Used as the default platform to test the DPAA2 changes and SFP/SFP+ code.

In addition Pierre-Luc Drouin has overhauled the Vybrid I2C support now
attaching and working on both FDT- and ACPI-based systems (committed).

Sponsor: Traverse Technologies (Ten64 hardware a while ago, support)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cloud

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

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 <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>
Contact: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

In this quarter, we have solved all the blocking issues and published the
13.3-RELEASE on Azure Marketplace.

Work in progress tasks:

  • Automating the image building and publishing process and merging to src/
    release/.

  • Building and publishing snapshot builds to Azure community gallery.

The above tasks are sponsored by The FreeBSD Foundation, with resources
provided by Microsoft.

Open tasks:

  • Update FreeBSD-related doc at Microsoft Learn

  • Support FreeBSD in Azure Pipelines

  • Update Azure agent port to the latest version

  • Upstream local modifications of Azure agent

  • Port Linux Virtual Machine Extensions for Azure

Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FreeBSD as a Tier 1 cloud-init Platform

Links:
cloud-init Website URL: https://cloud-init.io/
cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/

Contact: Mina Galić <freebsd@igalic.co>

cloud-init is the standard way of provisioning servers in the cloud. Over the
past year and a half, thanks to this FreeBSD support has steadily improved.
This year, together with cloud-init developers and the FreeBSD Foundation, we
decided to explicitly focus on making improvements in FreeBSD itself, that will
aid the cloud-init team to test future changes to FreeBSD code-paths
themselves. To achieve this goal, I need to make FreeBSD run in LXD (and
Incus), under the control of lxd-agent (or incus-agent).

Here are some improvements from the recent weeks:

  • I have written a small testing-framework (in sh, and I’m slowly porting it
    to OpenTofu/Terraform), which installs the latest version of net/
    cloud-init-devel or net/cloud-init and runs a couple of standard cloud-init
    tests.

  • To do this, I have created a dedicated public repository which contains the
    latest versions of net/cloud-init-devel and net/cloud-init for FreeBSD 13
    and 14 on amd64 and aarch64.

  • I have ported Linux’s vsock testing framework to FreeBSD

  • I created a driver skeleton for a VirtIO Socket driver, based on the HyperV
    Socket driver.

  • In doing so, I made numerous improvements to HyperV sockets, some of which
    are accepted, others still need more work.

  • I have tested and released the latest 24.1 series cloud-init, where the
    cloud-init team and I have finally fixed some longstanding bugs, such as
    moving /run/cloud-init to /var/run/cloud-init on BSD, as well as fixing the
    homedir argument to user_groups to actually do something.

  • This release also sees numerous fixes to the OpenBSD code-paths from the
    community and not just me.

  • I have also started an official port for OpenBSD, but that work has stalled
    .

The work to come, in broad strokes:

  • Finish the FreeBSD VirtIO Socket driver.

  • Fix Go’s runtime to support VirtIO on FreeBSD.

  • Port lxd-agent’s dependencies to FreeBSD.

  • Port lxd-agent to FreeBSD.

That work will be interspersed with more improvements to cloud-init on BSDs,
and more tests on different cloud providers.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

OpenStack on FreeBSD

Links:
OpenStack URL: https://www.openstack.org/
OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd

Contact: Chih-Hsin Chang <starbops@hey.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

The OpenStack on FreeBSD project aims to seamlessly integrate OpenStack cloud
infrastructure with the FreeBSD operating system. It uses FreeBSD’s unique
features while ensuring compatibility with OpenStack standards.

In the first quarter of 2024, we made significant progress on the OpenStack on
FreeBSD project. This included submitting a proposal for BSDCan 2024 and
attending AsiaBSDCon 2024 to share our porting experiences and gain exposure
for the project. The feedback received at AsiaBSDCon was particularly valuable
and helped in refining the project’s direction. During this period, we also
reviewed the project’s phase 1 tasks and made necessary adjustments. We also
planned for phases 2 and 3, aligning them with the project’s long-term goals.
One technical achievement was verifying the functionality of bhyve serial
console over TCP, an important part of the project’s infrastructure.
Additionally, we created a demo video showcasing the project’s progress and
features.

Looking ahead, our focus for the next quarter includes confirming the
feasibility of implementing FreeBSD privilege-management user space tools
leveraging mac(4) and priv(9), simplifying installation steps by transitioning
to FreeBSD ports, and porting OpenStack Ironic to FreeBSD. These tasks will
enhance the project’s capabilities and compatibility.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Documentation

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

Documentation Engineering Team

Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/
Link: FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/
Link: Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng

Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>

The doceng team is a body to handle some of the meta-project issues associated
with the FreeBSD Documentation Project; for more information, see FreeBSD
Doceng Team Charter.

During the last quarter:

Edward Tomasz Napierała's doc commit bit was taken for safekeeping. Tom Rhodes
's doc commit bit was taken for safekeeping.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblateurl
Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/url

Q1 2024 Status

  • 17 team languages

  • 189 registered users

Three new translators joined Weblate:

  • piker3 in Polish team (pl)

  • chrislongros in Greek team (el)

  • grip in Italian team (it_IT)

Languages

  • Chinese (Simplified) (zh-cn) (progress: 7%)

  • Chinese (Traditional) (zh-tw) (progress: 3%)

  • Dutch (nl) (progress: 1%)

  • French (fr) (progress: 1%)

  • German (de) (progress: 1%)

  • Greek (el) (progress: 1%)

  • Indonesian (id) (progress: 1%)

  • Italian (it) (progress: 5%)

  • Korean (ko) (progress: 32%)

  • Norwegian (nb-no) (progress: 1%)

  • Persian (fa-ir) (progress: 3%)

  • Polish (progress: 2%)

  • Portuguese (progress: 0%)

  • Portuguese (pt-br) (progress: 22%)

  • Spanish (es) (progress: 36%)

  • Turkish (tr) (progress: 2%)

We want to thank everyone that contributed, translating or reviewing documents.

And please, help promote this effort on your local user group, we always need
more volunteers.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ports

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

FreshPorts: Notification of new packages

Links:
FreshPorts URL: https://freshports.org/
FreshPorts blog URL: https://news.freshports.org/

Contact: Dan Langille <dvl@FreeBSD.org>

FreshPorts and FreshSource have reported upon FreeBSD commits for 20 years.
They cover all commits, not just ports.

FreshPorts tracks the commits and extracts data from the port Makefiles to
create a database of information useful to both port maintainers and port
users.

For example, https://www.freshports.org/security/acme.sh/#history shows the
history of the security/acme.sh port, back to its creation in May 2017. Also
available are dependencies, flavors, configuration options, and available
packages. All of this is useful for both users and developers of ports.

Notification: New Package Available

One of the original features of FreshPorts is notification of ports updates.
You can create a list of ports and receive notifications about those ports.
This new feature can also notify when a new package is available for that port.
The use case: a known security vulnerability has been patched. FreshPorts will
tell you the port has been patched, and then you wait for the package. This new
feature will tell you when that package is available.

Details at:

  • https://github.com/FreshPorts/freshports/issues/542

Help Needed

It has been over 23 years since FreshPorts started. Others must take over
eventually. I have started that process recently. There are several aspects to
FreshPorts:

  • FreeBSD admin (updating the OS and packages)

  • front end code (website - mostly PHP)

  • back end code (commit processing - Perl, Python, shell)

  • database design (PostgreSQL).

The database does not change very often and requires little maintenance
compared to the applications and OS. The website pretty much runs itself. From
time to time, a change to the FreeBSD ports infrastructure breaks something or
requires a modification, but there is rarely any urgency to fix that. This is
not a huge time commitment. There is a lot of learning. While not a complex
application, FreshPorts is also not trivial.

To contribute, please join the https://lists.freshports.org/mailman/listinfo/freshports-coders
mailing list and let us know what you would like to help
with.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

GCC on FreeBSD

Links:
GCC Project URL: https://gcc.gnu.org/
GCC 10 release series URL: https://gcc.gnu.org/gcc-10/
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/
GCC 12 release series URL: https://gcc.gnu.org/gcc-12/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

Updating GCC default version to 13 is finally finished. Thanks to Antoine
Brodin who ran the exp-runs and to all other developers and ports maintainers
involved.

As promised in the preceding report, the next goal is to reduce the number of
open bugs for GCC ports. Some work on existing bugs has already started.

In particular, lang/gcc14-devel has long stayed out of date due to some issues
with building the port without any BOOTSTRAP option. Thanks to the help of
other developers and contributors (a special thank to Mark Millard), I noticed
that according to the official documentation building GCC without bootstrap
requires a working GCC binary and thus I switched lang/gcc14-devel to require
that a BOOTSTRAP option is set. However it has later been stated that
bootstrapping GCC using clang and libc++ is officially supported. But it has
also been stated that this is not a high priority.

At the moment lang/gcc14-devel is the only GCC port requiring a BOOTSTRAP
option to be set. The plan is to have all GCC ports for versions greater or
equal than 14 (i.e. future GCC ports) to require such an option: even if
building without bootstrap is more or less officially supported, being low
priority for upstream it increases the burden of maintaining GCC ports for low
results. In case lower versions start to have issues building without
bootstrap, I am going to require bootstrap for those as well.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Valgrind: port to arm64 on its way

Links:
Valgrind Home Page URL: https://www.valgrind.org/
Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html
arm64 port URL: https://github.com/paulfloyd/freebsdarm64_valgrind

Contact: Paul Floyd <pjfloyd@wanadoo.fr>

The major news, as per the title, is that a port to FreeBSD arm64 (or aarch64)
is now ready. The next steps are to get it reviewed and pushed upstream.

Valgrind 3.23 is due out at the end of April 2024 and devel/valgrind will be
updated shortly after that.

devel/valgrind-devel will get an update as soon as I have pushed the changes
for arm64.

--track-fds=yes now checks for and warns about attempts to close a file
descriptor more than once. Handling of closefrom has been improved to use this
feature.

There are some important fixes for FreeBSD 15, in particular handling the new
libsys.

Here is a list of smaller bugfixes:

  • Support for FreeBSD 13.3 has been added.

  • Added a redirect for reallocarray.

  • Several fixes for aio* functions.

  • Added a redirect for memccpy.

  • There is a fix for _umtx_op OP_ROBUST_LISTS.

  • Added redirects for C23 free_sized and free_aligned_sized.

  • Correctly propagate the ELF stack protection flags to the guest stack that
    Valgrind synthesizes.

  • Fixes for --sanity-level-3 and above (only used for Valgrind self-testing
    at runtime).

  • Several fixes to checking done for semctl.

  • Fixed argument checking for utrace.

  • Fixed argument checking for clock_nanosleep.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into
their project. As these projects may be of interest to the broader FreeBSD
community, we sometimes include brief updates submitted by these projects in
our quarterly report. The FreeBSD project makes no representation as to the
accuracy or veracity of any claims in these submissions.

Containers and FreeBSD: Pot, Potluck and Potman

Links:
Pot organization on GitHub URL: https://github.com/bsdpot

Contact: Luca Pizzamiglio (Pot) <pizzamig@FreeBSD.org>
Contact: Bretton Vine (Potluck) <bv@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>

Pot is a jail management tool that also supports orchestration through Nomad.
Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a
repository of Pot flavours and complete container images for usage with Pot and
in many cases Nomad.

During this quarter, there were no new Pot releases.

Potluck saw quite some activity though. Not only have the images been rebuilt
for FreeBSD 14, but also the new Adminer container has been submitted by
first-time contributor Sidicer. Additionally a large number of additional
features, updates and fixes have been committed to containers like
HAProxy-Consul, Grafana, PostgreSQL-Patroni, or Prometheus.

For the Mastodon container, a blog post has been published explaining how to
use it to run your own instance.

As always, feedback and patches are welcome.

Sponsors: Nikulipe UAB, Honeyguide Group