Imported in 1998 and modified in 2009 to "fix Y2K bug" which means
"we may not distribute modified versions [due to its license]".
There has been no update and it now fails to build with "-fno-common".
The servers used by "getsts" and "gettle" to fetch satellite information
no longer exist.
FreeBSD removed it in 2011, "No more public distfiles". (thanks naddy)
OK naddy
Both are Python 2 only, collecting dust, their common upstream is dead
and py-vorbis is the only consumer of py-ogg.
Nothing in the tree uses either of them, not even as TEST_DEPENDS.
py-ogg now fails to build with "-fno-common".
OK sthen
It often aborts upon start due to "free(): recursive call",
does not support IPv6,
segfaults in vfscanf(3) due to "traceroute: sendto: No route to host" and
specifying a target only seems to work on the command line but not during
runtim in the window.
At runtime, it eventually aborts again.
tb even reported graphics related crashes in X11's iris driver when clicking
on the globe.
This port fails to build with "-fno-common".
No objections tb
OK sthen
Release notes: https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-7.10.2.html
Port changes:
* build: set BUILD_DEPENDS += lang/python/ instead of
using MODULES += lang/python to prevent unnecessary python dependecy
* metricbeat: report correct CPU/memory metrics - requires files/sigar_openbsd.go
* metricbeat: swap usage metrics are turned off due to metricbeat crashes
* metricbeat: remove configuration options which are useless under OpenBSD
Many thanks to David Alten for providing the fix for metricbeat CPU metrics
and testing
Over half a year ago I dropped MAINTAINER on this port due to not using it
any longer. At that time it was already outdated. Noone spoke up to
update or even maintain it.
The new (unported) version 1.6.0 already suffers from TLS related build
failures, now there's another problem: it does not build with "-fcommon"
which will become a default compiler option in the tree.
If someone wants to fix both and get an up-to-date version running they
recover it from the attic.
OK tb
From https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html:
There is a heap buffer overflow in libgcrypt due to an incorrect
assumption in the block buffer management code. Just decrypting some
data can overflow a heap buffer with attacker controlled data, no
verification or signature is validated before the vulnerability
occurs.
