[continued from previous message]

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

Sponsor: The FreeBSD Foundation

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

FreeBSD GitHub Pull Request Report

Links:
GitHub Working Group wiki page URL: https://wiki.freebsd.org/WorkingGroup/GitHub
FreeBSD Base System Pull Requests URL: https://github.com/freebsd/freebsd-src/pulls

Contact: Warner Losh <imp@FreeBSD.org>

The FreeBSD Project has been trying an experiment to accept contributions via GitHub pull requests. We have learned a lot in the last year that we’ve been doing this. We have created a number of rules relating to the pull requests. In general, pull requests should only be for things that are user-visible, add value to the project and are ready to go, modulo final review.

Current status:

• We are able to keep up with the pull requests doing everything by hand, but
only if we do it at least weekly.

• We have discovered the by-hand process is tedious and error-prone.

• We can stage multiple pull requests in a testing branch so we can batch-up
testing.

• We can automatically land the result so merged pull requests show up as
merged in GitHub infrastructure.

We need help with automating the process:

• Add automated testing that is context specific (for example, run igor over
man pages).

• Add build/install tests that test-boot the resulting image.

• Automate common tasks, like man page corrections, into staging process.

• Add simple smoke testing for the staging branch for tier 1 architectures.

• Investigate optionally integrating Jenkins testing to scale up the size of
changes we can accept.

• Integrate with Bugzilla problem reports and Phabricator reviews.

• Improve the submitter experience on GitHub by automating common feedback to
mistakes in the pull requests.

• Create checklists for submitters to reduce errors.

• Create better reporting about pull requests, especially the frequent
contributors of good pull requests.

We are coordinating on FreeBSD’s Discord in the #github-hacking channel. Join us there to pitch in, or just chat about the project.

Once things are fine-tuned, we want to publicity to steer contributors, at least the base system, to GitHub pull requests. We need more developers looking at the FreeBSD GitHub pull requests. We will also need more developers to review and land pull requests once it is automated and the automation has matured. We sincerely hope that we can improve the FreeBSD contribution experience with this, as well as gain useful fixes from the community.

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

Userland

Changes affecting the base system and programs in it.

Capsicum-rs

Links:
capsicum-rs on GitHub URL: https://github.com/dlrobertson/capsicum-rs capsicum-net on GitHub URL: https://github.com/asomers/capsicum-net

Contact: Alan Somers <asomers@FreeBSD.org>

Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model.

I have adopted the library providing Rust bindings for Capsicum, and extended it with support for libcasper(3) and cap_net(3). It is already being used by net-mgmt/nfs-exporter and by a TLS-enabled FTP server (the FTP server is closed-source, but all of the interesting bits reside in an open source library, and an example server can be found at https://github.com/bolcom/libunftp/tree/master/crates/unftp-sbe-fs/examples).

Sponsor: Axcient

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

Service jails — Automatic jailing of rc.d services

Links:
rc-article part for Service Jails URL: https://docs.freebsd.org/en/articles/rc-scripting/#rcng-service-jails

Contact: Alexander Leidinger <netchild@FreeBSD.org>

Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional
configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)).

The base system infrastructure and the basesystem rc.d services are committed to 15-current, and the handbook / rc article updates are committed to the documentation. Next steps are to extend services in the ports collection to be able to make use of it.

If you want to put e.g. nginx into a service jail and allow IPv4 and IPv6 access, simply change rc.conf(5) to have:

nginx_svcj_options=net_basic
nginx_svcj=YES

While this does not have the same security benefits as a manual jail setup with a separate filesystem and IP/VNET, it is much easier to set up, while providing some of the security benefits of a jail like hiding other processes of the same user.

Any testing and feedback (even as simple as "service X works in a service jail") is welcome.

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

Kernel

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

Hierarchical rate limits for OpenZFS

Links:
Pull request URL: https://github.com/openzfs/zfs/pull/16205

Contact: Pawel Dawidek <pawel@dawidek.net>

Rate limits allow to limit bandwidth and number of metadata operations per dataset.

Hierarchical rate limits allow for granular resource control especially in shared environments, eg. when a single ZFS pool serves data to multiple, independent virtual machines or jails.

Because the limits are hierarchical, they are enforced like the quota property: the children datasets must obey the limits of the parent dataset.

The limits can be configured using six new properties: limit_bw_read, limit_bw_write, limit_bw_total, limit_op_read, limit_op_write, limit_op_total The limit_bw_* properties limit the read, write, or combined bandwidth, respectively, that a dataset and its descendants can consume. Those limits are in bytes per second. The limit_op_* properties limit the read, write, or both metadata operations, respectively, that a dataset and its descendants can generate. Those limits are in number of operations per second.

Limits are applied to file systems and ZFS volumes (and their snapshots).

The initial work is done and the pull request is up for review.

Sponsor: Klara Systems Sponsor: FreeBSD Foundation

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

A low-cost conditional execution mechanism

Links:
FreeBSD wiki URL: https://wiki.freebsd.org/SummerOfCode2024Projects/ZeroCostConditionalExecutionMechanism

Contact: Marko Vlaić <mvlaic@freebsd.org> Contact: Bojan Novković (mentor) < bnovkov@freebsd.org>

This project aims to implement a low-cost conditional execution mechanism, similar to the static_key interface in Linux. The current working name is zcond, as in zero-cost conditional. The idea is to reduce the overhead of rarely used features in performance sensitive kernel code paths. Specifically, code blocks of the following, simple structure, are targeted:

if(some_global_flag == true) {
do_some_additional_task();
}

A block like this can cause performance overhead in a frequently executed piece of code.

The motivating use case for the mechanism is tracing (as outlined here in the wiki), but the project will identify more areas where this mechanism could be applied.

The backbone of the mechanism is runtime instruction hot patching, making it highly architecture dependent. Great care has to be given to security, because kernel instructions are overwritten at runtime. More details and some implementation ideas can be found in the project proposal on the project wiki page. More documents describing the implementation and design decisions will be produced, as the project moves along.

The goal of the project is to produce a working implementation of the mechanism for the x86-64 architecture. It will then be applied to an existing piece of kernel code and benchmarked. If the benchmark results come out positive, it will be ported to other architectures.

This project is a part of the Google Summer of Code 2024.. The project is still in its early stages, but any feedback would be highly appreciated.

Help wanted

• General feedback on the mechanism, API and implementation

• More use cases besides tracing are welcome

• Code review

• Name suggestions

Sponsor: Google LLC (GSoC 2024)

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

Architectures

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

FreeBSD/riscv64

Links:
Wiki Homepage URL: https://wiki.freebsd.org/riscv

Contact: Mitchell Horne <mhorne@FreeBSD.org>
Contact: Ruslan Bukin <br@FreeBSD.org>
Contact: Jari Sihvola <jsihv@gmx.com>

The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture.

BSDCan Devsummit Updates

Mitchell gave a presentation on the status of the FreeBSD/riscv64 platform at the June developers' summit, part of BSDCan 2024. The presentation discussed the challenges of supporting the evolving RISC-V ISA, and gave a brief overview of some available hardware targets. It is informal in nature, but available to watch on youtube.

https://www.youtube.com/watch?v=O7zW7Z9U0ns

StarFive JH7110 SoC / VisionFive v2

Work has been ongoing to support the JH7110 RISC-V SoC in FreeBSD. This SoC is present in several existing RISC-V SBCs. The primary support target is the VisionFive v2, but this work is likely to benefit similar hardware such as the Pine64 Star64 and the Milk-V Mars.

At present, the support in CURRENT is partially complete. What is working: * UART * clk/reset drivers * MMC/SD

The next target is working ethernet, which is supported with extensions to the if_eqos driver. This code is functional, but still in review.

Work on this has been performed by Jari, with review, testing, and integration from Mitchell.

https://wiki.freebsd.org/riscv/StarFive

T-HEAD/XuanTie CPU Support

As discussed in the devsummit presentation, these CPUs present several barriers to support. The problems come primarily from custom vendor extensions: non-coherent device I/O with custom cache management instructions, and a custom (spec-violating) implementation of page-based memory types. Combined, these quirks require difficult and invasive changes to pmap, busdma, and early boot code.

At the same time, we are seeing an increasing amount of available hardware based on this IP, and so support becomes a repeated question and incentive.

Work on page-based memory types is underway and expected to land soon in CURRENT. This feature allows individual virtual memory pages to be assigned specific properties, e.g. cacheability requirements. The riscv64 pmap has been extended to support the official RISC-V 'Svpbmt' extension, and the T-HEAD version of PBMT. These alternative encodings are incompatible, but provide similar functionality.

Work on the device coherence and cache management challenges will begin next quarter.

The hope is that this foundational work will (eventually) enable board support for available RISC-V hardware such as: * Allwinner D1 (Nehza) * Sipeed Lichee Pi 4A * Beagle-V Ahead * Milk-V Pioneer

RISC-V Hypervisor

Experimental support for the RISC-V hypervisor in bhyve/vmm(4) is under active development. Currently, single-core VMs are possible, and the guest can boot to multi-user.

Note: the "H" (hypervisor) extension is not implemented by any known existing or upcoming RISC-V hardware. It is fully supported by software simulators such as Spike or QEMU.

https://wiki.freebsd.org/riscv/bhyve

Sponsor: The FreeBSD Foundation (mhorne’s work) Sponsor: UKRI (br’s work)

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

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 published the 14.1-RELEASE on Azure Marketplace. Souradeep Chakrabarti from Microsoft has improved the TLB flushing mechanism in Azure.

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.

• Testing adding FreeBSD support in Azure Pipelines

□ https://github.com/microsoft/azure-pipelines-agent/pull/3266

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

Open tasks:

• Update FreeBSD-related doc at Microsoft Learn

• Update sysutils/azure-agent 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

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

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 integrate OpenStack cloud infrastructure with the FreeBSD operating system, utilizing FreeBSD’s unique features while maintaining compatibility with OpenStack standards.

In the second quarter of 2024, we continued to advance the project significantly. One of our key activities was attending BSDCan 2024, where we presented on "Towards a Robust FreeBSD-based Cloud: Porting OpenStack Components". This presentation helped increase the project’s visibility and attracted interest from potential contributors.

We expanded the current single-node proof-of-concept (POC) site to a three-node setup. This involved detailed environment setup and network planning. Additionally, we began migrating the base to FreeBSD 15.0-CURRENT to ensure our project stays aligned with the latest advancements in FreeBSD.

We also started working on adapting the manual installation steps and code patches into FreeBSD ports, aiming to streamline the installation process for future users. Another major milestone was initiating work on making bare-metal provisioning function on both FreeBSD instances and service hosts for OpenStack Ironic.

Looking forward to the next quarter, our focus will be on refining these advancements and further enhancing the project’s robustness and ease of use. Specifically, we aim to upgrade our OpenStack components from the Xena version to a more recent release, as Xena has entered the "unmaintained" phase and will soon reach EOL. We welcome any suggestions and contributions from the community to help us achieve our goals.

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/url Link: FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/url
Link: Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-docengurl

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.

Document changes

During this quarter multiple pieces of the documentation were updated including the removal of mentions to ports that were removed from the ports tree, typos, URL corrections, and asciidoc improvements.

These are three highlighted contributions in this quarter:

• Best practices related to vendor import were documented. URL:
https://cgit.freebsd.org/doc/commit/?id=fe494e72df138266f6da2b9170cf0215275a6aaf

• A section about service jails was added to the handbook. URL:
https://cgit.freebsd.org/doc/commit/?id=8f4754a9a6ee8f2503cfb68d14afa99b17729e7f

• bhyve documentation was improved. URL:
https://cgit.freebsd.org/doc/commit/?id=68cbd16c4e7c199cfdfb2b54110ad1470b4d7a2e

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

Q2 2024 Status

• 17 team languages

• 214 registered users

9 new translators joined Weblate:

• BFR (de_DE)

• Elwood (de_DE)

• Freebsd-Freund (de_DE)

• MSantos (pt)

• SINF-KEN (fr_FR, nl_NL)

• aperechnev (ru)

• edsonwolf

• fdecunta (es_ES)

• wheatfox (zh_CN, zh_HANS)

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.

Packages maintained by DocEng

During this quarter the following work was done in packages maintained by doceng@:

• textproc/docproj-legacy: Fix build with DBLATEX

• textproc/docproj-legacy: Fix poudriere warning

• textproc/rubygem-asciidoctor-epub3: Add missing run dependency

• www/gohugo: Update to 0.125.4

Open issues

There are 3 Open PRs in bugzilla assigned to doceng@:

• 279815 status reports: ERR_TOO_MANY_REDIRECTS

• 276923 www/gohugo link error under poudriere

• 267274 Please remove the zh-CN Handbook of the current FreeBSD website

During this quarter doceng@ closed 3 PRs:

• 278904 misc/freebsd-doc-en: HTML should be single page

• 278732 www/gohugo: Update to v125.5

• 278504 textproc/rubygem-asciidoctor-epub3: A run-time dependency is missing
for rubygem-asciidoctor-epub3 port

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

Ports

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

GCC on FreeBSD

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/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/
GCC 14 release series URL: https://gcc.gnu.org/gcc-14/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

Upstream has released GCC 14.1. Therefore port lang/gcc-14 has been created, as well as lang/gcc15-devel which tracks the new latest development GCC version. Previous major versions of GCC are being updated as well.

Only very little work has been done on existing bugs for GCC ports this quarter, contrary to the original plan stated in the precedent report. This is due to the fact that I noticed an increasing interest in upstream to support GCC on FreeBSD, which however gets blocked by the fact that GCC sources do not build out-of-the-box on our platform, but needs instead many patches which are in our ports tree framework. It is then necessary to focus on upstreaming all of those patches, possibly at once and not one at the time as it has been done until now, and to also regularly run the tests suite, fixing all tests that fail. Then I am working on a new setup of automation that allows me to build and test all supported GCC versions as efficiently as possible, including GCC from sources but without the ports tree framework support. All of this has significantly slowed down usual GCC ports maintainership (users of the -devel ports have probably noticed that they are being updated much less frequently), but I am confident that it will eventually pay off.

It should also be noted that Robert Clausecker has enabled lang/gcc11, lang/ gcc12, and lang/gcc13 for riscv64 architecture as the ports build fine on 15-CURRENT.

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

KDE on FreeBSD

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

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

The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation.

We missed a quarter, while the broader KDE community celebrated the KDE Megarelease of KDE Frameworks 6, KDE Plasma 6 and KDE Gear. The latest software is still not available on FreeBSD, pending more testing and some integration work.

Infrastructure

CMake was updated several times and is now version 3.29.6, the latest upstream release. CMake in the ports framework now supports setting parallel-build for tests.

Qt5 is now on long-term support and updates only rarely. An update to 5.15.14 and WebEngine to 5.15.17 was landed in May.

Qt6 and the Python bindings for Qt, Pyside, were updated to version 6.7.2.

KDE Stack

KDE Gear, Plasma and Frameworks release happen very regularly. These updates arrive in the FreeBSD ports tree only piecemeal, due to lagging work on compatibility and testing.

• KDE Frameworks reached version 6.3.0

• KDE Plasma 6 Desktop was updated to version 6.0.4

• KDE Gear 6 has not yet arrived in the ports tree

Related Ports

The KDE ecosystem includes a wide range of ports — most maintained by kde@, all
building on a shared base of Qt and KDE Frameworks. The KDE team updates them all as needed. This quarter the KDE team would like to thank Tobias C. Berner, Gleb Popov and Jason E. Hale again for keeping things up-to-date.

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

FreeBSD Erlang Ecosystem Ports update

Links:
FreeBSD Erlang wiki URL: https://wiki.freebsd.org/Erlang
Erlang/OTP language URL: https://erlang.org/
Elixir language URL: https://elixir-lang.org/
Gleam language URL: https://gleam.run/

Contact: FreeBSD Erlang mailing list <erlang@FreeBSD.org>

The Erlang runtime system, commonly known as the BEAM, provides a runtime that is used by a number of programming languages and applications in the FreeBSD ports collection.

Notable changes in 2024 include:

• adding OTP27, the latest Erlang runtime release, Elixir 1.17, and Gleam
1.20

• more than 57 point release updates so far in 2024

• improved inline documentation within Erlang ports

• moved RabbitMQ port to the generic UNIX build, decoupling this from Elixir
as a build-time dependency. This enables moving RabbitMQ to the latest
supported release. Users of RabbitMQ need to update each quarter to avoid
being stuck on an unsupported release of Erlang/OTP + RabbitMQ

Note that as the upstream Erlang OTP team only commit to supporting the two latest major releases, more and more point updates are arriving for OTP26-27, but not for the older Erlang runtime releases, which are now unlikely to get security and bug fixes.

During 2024Q3, the Erlang team is planning to:

• migrate the base lang/erlang port to OTP26 and update related dependencies

Additional testing and community contributions are welcome, please reach out on the mailing list, especially if you are able to help testing of specific port updates.

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

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 images saw some updates again though. All images have been rebuilt for the new quarterly packages, a new Opensearch container has been added. Additional features, updates and fixes have been committed to containers like PostgreSQL-Patroni or Nomad-Server-TLS.

In total, there are 58 container images and templates available now.

As always, feedback and patches are welcome.

Sponsors: Nikulipe UAB, Honeyguide Group

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