This change cleans up the Makefile to follow Porter's Handbook guidance.
Here is the rationale for each change:
* As per https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github,
ports are urged to move to using Github releases instead of git tags.
This change replaces USE_GITHUB with MASTER_SITES to statically point
to htop release tarballs. This also requires the addition of USES=tar:xz
* Remove USES=autoreconf because the release tarball doesn't need to run it
* Remove USES=compiler:c11 since upstream https://github.com/htop-dev/htop
states that a C99 compiler is needed.
* Add USES=desktop-file-utils as the port installs htop.desktop
* htop does not exist in the official NVD CPE dictionary, so as per
https://docs.freebsd.org/en/books/porters-handbook/book/#uses-cpe, we
should "not ever make up CPE data." Thus, USES=cpe is removed until an
entry is contributed to the CPE dictionary
* USES={libtool,localbase,pkgconfig,python:build,shebangfix} are not
necessary for a successful build and run with the GH release tarball.
* GNU_CONFIGURE_MANPREFIX was unnecessary since default value in
Mk/bsd.port.mk is same ${PREFIX}/share
PR: 280820
Approved by: Hung-Yi Chen <gaod@hychen.org> (maintainer)
This is a standalone version of the JSON parser used in
pydantic-core. The recommendation is to only use this package directly
if you do not use pydantic.
WWW: https://github.com/pydantic/jiter
<ChangeLog>
*) Security: processing of a specially crafted mp4 file by the
ngx_http_mp4_module might cause a worker process crash
(CVE-2024-7347).
Thanks to Nils Bars.
*) Change: now the stream module handler is not mandatory.
*) Bugfix: new HTTP/2 connections might ignore graceful shutdown of old
worker processes.
Thanks to Kasei Wang.
*) Bugfixes in HTTP/3.
</ChangeLog>
This version includes enhancements and features such as
- supports PUSH or PULL replication
- supports LOCAL or REMOTE replication
- supports multiple pool/dataset pairs to replicate
- everything is logged to `${SCRIPTPATH}/logs` by default (can be set to custom location using $LOGBASE variable) but its better to keep it together with the scripts
- runs off a well documented `config.sh` file (see below)
- can be run on any schedule using cron with `bash zfs-replicate.sh -config.sh`
- (for XigmaNAS) includes a `status-report.sh` that can be used to email latest replication status, which will email the latest replication status at your preferred schedule. Simply add it as a custom script in the email settings under "System > Advanced > Email Reports"
- includes ALLOW_REPLICATE_FROM_SCRATCH option (see below, or `config.sh` file for details)
PR: 280987
Reported by: Victor <tschetter.victor@gmail.com> (Maintainer)
