[continued from previous message]

other operating systems.

This year, Sayafdine Said <musikid@outlook.com> rewrote it under Google’s sponsorship. The new version has several improvements:

• More configurable, for better use with other file systems.

• Much faster, largely thanks to said configurability.

• Better test case isolation, making failure easy to debug.

• No longer requires root privileges for all test cases.

• Test cases can be run in a debugger.

• More maintainable, less duplication.

There are still a couple of lingering PRs to complete, but we expect to wrap those up and add pjdfstest to the ports collection soon. From there, it will be used both by /usr/tests for ZFS and UFS, and by external developers for other file systems.

Sponsor: Google Summer of Code

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

Ongoing work on LLDB multiprocess debugging support

Links:
Moritz Systems Project Description URL: https://www.moritz.systems/blog/ multiprocess-support-for-lldb/
Progress Report 1 URL: https://www.moritz.systems/blog/ implementing-non-stop-protocol-compatibility-in-lldb/
Progress Report 2 URL: https://www.moritz.systems/blog/ full-multiprocess-support-in-lldb-server/

Contact: Kamil Rytarowski <kamil@moritz.systems>
Contact: Michał Górny <mgorny@moritz.systems>

According to the upstream description, "LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler."

FreeBSD includes LLDB in the base system. The previous sponsored projects improved LLDB, to make it a credible debugger for the base system, although it still has a few limitations compared to the contemporary versions of GNU GDB. This project started in April 2022. It aims to implement full support for debugging multiple processes simultaneously.

At the start of the project, LLDB featured very limited support for multiprocess debugging. Currently, the server is already able to monitor multiple processes using the multiprocess extension to the GDB Remote Serial Protocol. The work on implementing the client-side counterpart for this protocol is ongoing.

Once the project is finished, LLDB will be able to trace an arbitrary number of forked processes simultaneously (equivalent to GDB’s detach-on-fork off).

Sponsor: The FreeBSD Foundation

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

DTrace: Instruction-level dynamic tracing

Links:
Wiki article URL: https://wiki.freebsd.org/SummerOfCode2022Projects/ InstructionLevelDynamicTracing
Final code review URL: https://reviews.freebsd.org/D36851

Contact: Christos Margiolis <christos@FreeBSD.org>
Contact: Mark Johnston <markj@FreeBSD.org>

kinst is a new DTrace provider that allows for arbitrary kernel instruction tracing.

The provider is currently implemented only for amd64, but we plan to port it to other architectures in the future as well.

kinst probes are created on demand by libdtrace, and a probe can be created for nearly every instruction in the kernel. Probes take the form of:

kinst:<module>:<function>:<offset>

where "module" is the kernel module containing the named function, "function" is the kernel function to be traced, and "offset" is the offset to a specific instruction. Omitting "offset" causes all instructions in the function to be traced. Omitting "module" causes DTrace to search all kernel modules for the function.

For example, to trace the second instruction in amd64_syscall(), first determine the offset of the second instruction:

# kgdb
(kgdb) disas /r amd64_syscall
Dump of assembler code for function amd64_syscall:
0xffffffff809256c0 <+0>: 55 push %rbp
0xffffffff809256c1 <+1>: 48 89 e5 mov %rsp,%rbp
0xffffffff809256c4 <+4>: 41 57 push %r15

The offset is 1. Then, to trace it:

# dtrace -n 'kinst::amd64_syscall:1'

A new "regs" keyword was also added to the D language, providing read-only access to CPU registers at the point where the probe fired. For example, to trace the contents of the frame pointer (register %rbp on amd64) when the kinst::amd64_syscall:1 probe fires:

# dtrace -n 'kinst::amd64_syscall:1 {printf("0x%x", regs[R_RBP]);}'

kinst works similarly to the FBT (function boundary tracing) provider in that it places a breakpoint on the target instruction and hooks into the kernel’s breakpoint handler. It is more powerful than FBT since it can be used to create probes at arbitrary points within a function, rather than at function boundaries. Because kinst has to be able to trace arbitrary instructions, it does not emulate most of them in software but rather causes the traced thread to execute a copy of the instruction before returning to the original code.

Planned future work includes porting kinst to additional platforms, especially arm64 and riscv, and developing tooling that can use kinst to trace calls to inline functions using the kernel’s debugging symbols.

Sponsor: Google, Inc. (GSOC 2022)

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

Kernel

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

ENA FreeBSD Driver Update

Links:
ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ ena/README.rst

Contact: Michal Krawczyk <mk@semihalf.com>
Contact: David Arinzon <darinzon@amazon.com>
Contact: Marcin Wojtas <mw@FreeBSD.org>

ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used.

Completed since the last update:

• Upstream of the ENA driver v2.6.0 and v2.6.1, included:

□ Fix for the performance degradation after reset issue on 6-gen
instances,

□ Fix of the false netmap assertions with KASSERT enabled,

□ Code cleanup and style fixes,

□ Logging improvements,

□ Fix to the retrieval of the ENI metrics.

Sponsor: Amazon.com Inc

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

wtap(4) enhancement

Links:
Add sta, hostap and adhoc mode to wtap wlan simulator

Contact: En-Wei Wu <enweiwu@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: Bjoern A. Zeeb <bz@FreeBSD.org>

wtap(4) is a net80211(4) Wi-Fi simulator introduced by Monthadar Al Jaberi < monthadar@gmail.com> and Adrian Chadd <adrian@FreeBSD.org> in 2012. It originally supported 802.11s mesh mode and was used for verification. During the 2022 Google Summer of Code, En-Wei had been working on bringing sta, hostap, adhoc and monitor modes to it. The work also covers adding basic tests for net80211(4) with wtap(4), written in atf(7).

For more details, please check the project wiki page.

Sponsor: Google Summer of Code Sponsor: The FreeBSD Foundation

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

Intel wireless towards 11ac

Links:
Intel iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/ Iwlwifi

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

The ongoing project aims to support the latest Intel wireless chipsets on FreeBSD using LinuxKPI compat code backed by native net80211 and kernel code. In addition work is on the way to support 11n and 11ac standards in the LinuxKPI 802.11 compat code and fill gaps for mostly 11ac in the native net80211 wireless stack.

For the Intel iwlwifi wireless driver there were no major updates in the last months. We updated the firmware to the latest publicly available version and fixed some of the most visible bugs. Work is also on the way to support the D3 power saving code.

LinuxKPI compat code also got some improvements and fixes which at times were only observable on certain generations of iwlwifi chipsets.

Changes in net80211 and LinuxKPI compat code for 11n and 11ac have little public visibility so far in order to not break basic support. Updates to constants based on newer 802.11 standards and other changes without user-visible effect were merged, and functional changes will follow in the coming months, initially hidden behind compile-time or runtime options.

Improvements and updates were largely merged back to stable/13 for the benefit of the users tracking this branch and to help with more testing.

For the latest state of the development, please follow the freebsd-wireless mailing list and check the wiki pages.

Sponsor: The FreeBSD Foundation

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

More wireless updates

Links:
Bjoern’s Wireless Work In Progress landing page URL: https://people.freebsd.org
/~bz/wireless/
Realtek rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88 Realtek rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw89 MediaTek mt76 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Mt76 QCA ath11k status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Ath11k

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

Currently development is mostly driven by Intel’s iwlwifi driver again (see other report). As the saying goes ''each one helps the other'' so has work on Realtek’s rtw89 driver helped find a bug in LinuxKPI bothering iwlwifi users. For this status report the topic is mostly more drivers, which do need more LinuxKPI support.

Various work in progress:

• Realtek’s rtw88 PCI is in-tree as-is and after a fruitful discussion with
Hans Petter Selasky at EuroBSDCon work on LinuxKPI USB support for the
rtw88 USB WiFi dongles will continue.

• Realtek’s rtw89 driver was committed to main but is not connected to the
build yet. Scanning already works but packets are not yet passing. Having
the driver in-tree already eased testing for users having that chipset in
order to identify more unimplemented LinuxKPI bits (some of which will help
the other drivers as well) and reduced work for me.

• The next drivers to probably hit the tree will be based on MediaTek’s mt76
driver (for 7921 and 7915) which I have compiling and started testing.

• Based on requests I am also working on ath11k to support STA mode given
some vendors seem to ship Laptops with those chips.

While some of this clearly benefits from work sponsored by The FreeBSD Foundation for iwlwifi and newer standard support, a lot of this is just free-time work. If you are interested in any of these drivers I would greatly appreciate if some more hands would help with one or the other. This could be regularly testing updates to main, writing documentation and updating wiki pages, tracking PRs, trying out patches, helping with work on individual LinuxKPI bits with or without 802.11 work, or simply debugging problems with individual drivers and/or chipsets. If you are interested in helping with any one of the above, please drop me an email.

For the latest state of the development, please follow the freebsd-wireless mailing list and check the wiki pages (as soon as they exist).

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

Enabling Snapshots on Filesystems Using Journaled Soft Updates

Links:
Milestone 1 Core Changes URL: https://reviews.freebsd.org/D36491

Contact: Kirk McKusick <mckusick@FreeBSD.org>

This project will make UFS/FFS filesystem snapshots available when running with journaled soft updates.

The UFS/FFS filesystem has the ability to take snapshots. Because the taking of snapshots was added after soft updates were written they were fully integrated with soft updates. When journaled soft updates were added in 2010, they were never integrated with snapshots. So snapshots cannot be used on filesystems running with journaled soft updates.

Snapshots became less important with the support for ZFS on FreeBSD since ZFS can take snapshots quickly and easily. However there remain two instances where UFS snapshots are still important. The first is that they allow reliable dumps of live filesystems which avoids possibly hours of down time. The second is that they allow the running of background fsck. Similar to the need for scrub in ZFS, fsck needs to be run periodically to find undetected disk failures. Snapshots allow fsck to be run on live filesystems rather than needing to schedule down time to run it.

This project has two milestones:

1. enable snapshots when running with journaled soft updates and ensure that
they can be used for doing background dumps on a live filesystem. This
milestone should be completed by the end of 2022.

2. extend fsck_ffs to be able to do a background check using a snapshot on a
filesystem running with journaled soft updates. This milestone is expected
by Q3 of 2023.

Sponsored by: The FreeBSD Foundation

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

Architectures

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

FreeBSD/Firecracker

Links:
Firecracker VM

Contact: Colin Percival <cperciva@FreeBSD.org>

Firecracker is an open source "microVM" developed by Amazon Web Services; it is designed for the needs of "serverless" compute environments and has a particular focus on security and minimalism.

Starting in June 2022, Colin Percival has been working to port FreeBSD to run in the Firecracker environment, with significant assistance from other FreeBSD developers. As of this quarterly report, a set of patches are pending review which collectively add the needed support to make FreeBSD functional in a patched version of Firecracker.

In Q4 Colin intends to finish committing the relevant patches to FreeBSD, release a kernel and disk image so other FreeBSD users can experiment with Firecracker, and update and merge Firecracker patches which add PVH boot support (used by FreeBSD).

This work has already produced "spinoff" benefits in revealing ways to speed up the FreeBSD boot process; due to its low overhead and minimal environment, Firecracker is an excellent context to work on this.

This work is supported by Colin’s FreeBSD/EC2 Patreon.

Sponsor: https://www.patreon.com/cperciva

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

Documentation

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

Documentation Engineering Team

Link: FreeBSD Documentation Project
Link: FreeBSD Documentation Project Primer for New Contributors
Link: Documentation Engineering Team

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:

• 0mp@ stepped down as Doceng’s Secretary, fernape@ joined as the new
Secretary. Doceng would like to thank 0mp@ for his service.

• eadler@'s doc bit was taken in for safekeeping per his request.

• A git commit message template was added for the doc repository.

Items pending and in the discussion:

• Remove outdated translations from the Website and Documentation portal.

FreeBSD’s Documentation Project Primer

The FDP was expanded with information on trademark handling.

Porter’s Handbook:

• The documentation on porting Haskell programs was updated.

• The move of WWW from pkg-descr to Makefile was documented.

• Qt 6-related documentation has been added following the import of the
library in the ports framework.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate
Link: FreeBSD Weblate Instance

Q3 2022 Status

• 12 languages

• 148 registered users

□ Gasol Wu joined the Chinese translation team.

□ Alvaro Felipe Calle joined the Spanish translation team.

Languages

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

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

• Dutch (nl) (progress: 1%)

• French (fr) (progress: 1%)

• German (de) (progress: 1%)

• Indonesian (id) (progress: 1%)

• Italian (it) (progress: 4%)

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

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

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

• Spanish (es) (progress: 15%)

• Turkish (tr) (progress: 2%)

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

Please, promote this effort in your local user group, we always need more volunteers.

FreeBSD Manual Pages Portal

Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>

The Manual Pages Portal has been redesigned to use mandoc(1) for rendering. A portal preview is available. Feedback has been collected and addressed where possible. There are some remaining non-blocking issues. Doceng@ would like to move forward with the migration to this new portal.

Thanks to all of those who reviewed it and provided feedback.

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>

Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases:

1. Redesign of the Documentation Portal

Create a new design, responsive and with global search. (Complete)

2. Redesign of the Manual Pages on web

Scripts to generate the HTML pages using mandoc. (Complete)

3. Redesign of the Ports page on web

Ports scripts to create an applications portal. (Work in progress)

4. Redesign of the FreeBSD main website

New design, responsive and dark theme. (Not started)

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

Ports

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

Calendar-data: License added

Links
GitHub calendar-data repository URL: https://github.com/freebsd/calendar-data

Contact: Stefan Eßer <se@FreeBSD.org>
Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>
Contact: Warner Losh <imp@FreeBSD.org>

The port deskutils/calendar-data contains calendar files for the BSD calendar program and is maintained by se@. The data for this port lives in a GitHub repository, which at the moment is maintained mainly by salvadore@.

About two years ago, the calendar files in the base repository were removed from there and a new repository was created on GitHub; see also this Phabricator review about the creation of the associated port. This improvement allows calendar files to be updated independently from the base system.

Unfortunately, when the repository was created, it was forgotten to add a license to it. The issue has been solved this quarter with this pull request submitted by salvadore@ and merged by imp@. Since the data originally came from the src repository, the same licence applies. If in the past you have contributed to the calendar files with different licensing assumptions, please inform us so that we can license your contributions accordingly or remove them.

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

KDE on FreeBSD

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

Contact: Adriaan de Groot <kde@FreeBSD.org>

The KDE on FreeBSD project packages the software from the KDE Community, along with dependencies and related software, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine.

The KDE team (kde@) is part of desktop@ and x11@, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. The notes below describe mostly ports for KDE, but also include items that are important for the entire desktop stack.

Qt6 Landed

The big news in the KDE ports is not directly KDE-related. Qt6 has landed, which prepares us for the next generation of Qt-based applications.

It is now possible to have USES=qt:6 to select the new Qt version. Some ports have been flavorized to make use of the new version.

KDE itself is not affected: the upstream work on KDE Frameworks for Qt6 is not yet completed. Most of the KDE Frameworks will compile with Qt6, but that is not important for FreeBSD ports yet. With devel/qt6 you get Qt 6.4.0, released at the end of the quarter.

KDE Stack

KDE Gear releases happen every quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release every month as well. These (large) updates land shortly after their upstream release and are not listed separately.

• KDE Frameworks 5 is now at version 5.98 (latest monthly release from
September 2022).

• KDE Gear is now version 22.08.1 (update for September 2022).

• KDE Plasma is now version 5.24.6 (update for July 2022).

Note that KDE Plasma 5.25 has been released upstream, but is waiting on fixes before it can land in the ports tree (for example, this KActivityManager bug in KDE’s bug-tracker).

Related Ports

• accessibility/qt5-speech now supports multiple backends, as well as
no-backends, for speech synthesis.

• devel/cmake was reorganized, so that devel/cmake is now a metaport that
installs devel/cmake-core and the rest of the CMake suite. (Thanks to
diizzy@) The CMake ports were also updated to version 3.24, with attendant
changes in ports all over the tree.

• net/qt5-network has improved compatibility with libressl.

• x11/plasma-wayland-protocols was updated in advance of KDE Plasma Desktop
updates in the next quarter.

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

GCC: New maintainer, GCC 12.2 and more

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

Contact: <toolchain@FreeBSD.org>
Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

• salvadore@ adopted all existing ports corresponding to supported versions
of gcc, namely: lang/gcc10, lang/gcc11, lang/gcc11-devel, lang/gcc12, lang/
gcc12-devel and lang/gcc13-devel. At the moment -devel ports are updated
weekly, unless a build failure makes it impossible. Of course, in the
latter case, the build failure is fixed and/or reported upstream as soon as
possible.

• GCC 12.2 has been released. Traditionally, FreeBSD waits for the release of
the second minor version of GCC to use it as default GCC version, so that
most of the software needing to be compiled with GCC has already been
ported to the latest major version. Thus, work has started to update the
default GCC version to version 12. Thank you very much to antoine@ who has
already run the first exp-run and to all the contributors, maintainers and
committers involved in the process. https://bugs.freebsd.org/bugzilla/
show_bug.cgi?id=2659548

• Discussion about LTO keeps going with many different points of view. If
interested, you can read the latest contributions to the topic: lang/gcc11:
Needs build time warning for /tmp consumption and lang/gcc11: build gets
stuck. Reminder: LTO_BOOTSTRAP is an option enabled by default. If you
build the port on your machine and its resources consumption is not
acceptable, disabling this option will get you a lighter compilation.

• jbeich@ submitted a patch to expose non-default -stdlib=libc++ support,
which has been successfully committed to all relevant ports (gcc >= 11).
link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265962

• diizzy@ refreshed the mirrors list in the MASTER_SITE_GCC variables, also
removing ftp mirrors. The main GCC site is used as fallback. link: https://
reviews.freebsd.org/D36372

• Help is still needed with these three changes to work through with upstream
GCC (requires expertise with the GCC sources and upstream, not with the
ports framework):

□ upstreaming lang/gcc11/patch-gets-no-more

□ upstreaming lang/gcc11/patch-arm-unwind-cxx-support

□ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874

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

sysutils/lsof major upgrade

Link:
lsof project repo URL: https://github.com/lsof-org/lsof

Contact:
Larry Rosenman <ler@FreeBSD.org>

sysutils/lsof had a major upgrade to no longer look in /dev/kmem for data, and to use the userland API. This took a long time to hit the tree, but is finally done. It fixes lsof(8) to work with ZFS again for the first time since 13.0-RELEASE.

This will make maintenance much easier going forward.

To the kernel folks: if you make changes that break lsof, please submit a GitHub pull request to https://github.com/lsof-org/lsof. Please test any changes to the interfaces that lsof uses and make sure they still work. These all should be userland interfaces now, but please test.

My thanks to Warner Losh <imp@FreeBSD.org>, Mateusz Guzik <mjg@FreeBSD.org>, and Ed Maste <emaste@FreeBSD.org> for help getting this major change landed.

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

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: Stephan Lichtenauer (Potluck) <sl@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@freebsd.org>

Pot is a jail management tool that also supports orchestration through Nomad.

During the last quarter, pot 0.15.3 was released. It contains a number of improvements like mount-out to remove or unmount a previously mount-in folder or filesystem, signal and exec commands, better jail lifecycle handling, and many bug fixes.

A new version of the Nomad driver, nomad-pot-driver 0.9.0, was also released with signal and exec support and stability fixes.

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.

Since the last status report, many changes were committed, including many fixes and improvements to core images like grafana, postgresql-patroni or loki. Additionally, all images have been rebuilt for FreeBSD 13.1 and 12.3 and to include the current quarterly versions of the packages being used.

Last not least, Luca held the pot implementation and ecosystem talk How far a naive FreeBSD container implementation can go at EuroBSDCon 2022.

As always, feedback and patches are welcome.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)