Date: Sun, 5 May 2024 15:38:51 +0000 From: Lorenzo Salvadore <salvadore@freebsd.org> To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebd.org Subject: FreeBSD Status Report - First Quarter 2024 Message-ID: <ZjeoC3WlvIedXZsZ@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZjeoC3WlvIedXZsZ>