security/py-securesystemslib: Update version 1.1.0=>1.2.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/blob/v1.2.0/CHANGELOG.md

security/py-securesystemslib: Update version 1.0.0=>1.1,0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v1.1.0

security/py-securesystemslib: Update version 0.31.0=>1.0.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v1.0.0

security/libsodium: update to 1.0.19, bump dependent ports

PR:	278259
Reported by:	Andrey Korobkov <alster-vinterdalen.se>

security/py-securesystemslib: Convert to USE_PYTHON=pytest

Approved by:	portmgr (blanket)
With hat:	python

security/py-securesystemslib: Unbreak

security/py-securesystemslib: Update version 0.30.0=>0.31.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.31.0

security/py-securesystemslib: Update version 0.29.0=>0.30.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.30.0

*: Replace USES=pycryptography* with USE_PYTHON=cryptography{,_build,_test}

- Introduce USE_PYTHON=cryptography{,_build,_test}
- Switch all 96 ports from USES=pycryptography to with
USE_PYTHON=cryptography{,_build,_test}
- Remove Mk/Uses/pycryptography.mk

PR:		273727
Approved by:	tcberner (portmgr)
Exp-run by:	antoine

security/py-securesystemslib: Update version 0.28.0=>0.29.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.29.0

framework: convert tree to use USES=pycryptography

A future commit will update to security/py-cryptography will introduce a
rust dependency.

PR:		254853

all: remove explicit versions in USES=python for "3.x+"

The logic in USES=python will automatically convert this to 3.8+ by
itself.

Adjust two ports that only had Python 3.7 mentioned but build fine
on Python 3.8 too.

finance/quickfix: mark BROKEN with PYTHON

libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I../.. -I -I. -I.. -I../.. -I../C++
-DLIBICONV_PLUG -DPYTHON_MAJOR_VERSION=3 -Wno-unused-variable
-Wno-maybe-uninitialized -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong
-fno-strict-aliasing -DLIBICONV_PLUG -Wall -ansi
-Wno-unused-command-line-argument -Wpointer-arith -Wwrite-strings
-Wno-overloaded-virtual -Wno-deprecated-declarations -Wno-deprecated -std=c++0x
-MT _quickfix_la-QuickfixPython.lo -MD -MP -MF
.deps/_quickfix_la-QuickfixPython.Tpo -c QuickfixPython.cpp  -fPIC -DPIC -o
.libs/_quickfix_la-QuickfixPython.o
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
'-Wno-uninitialized'? [-Wunknown-warning-option]
QuickfixPython.cpp:175:11: fatal error: 'Python.h' file not found
          ^~~~~~~~~~
1 warning and 1 error generated.

Reviewed by:	portmgr, vishwin, yuri
Differential Revision:	<https://reviews.freebsd.org/D40568>

security/py-securesystemslib: Update version 0.27.0=>0.28.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.28.0

USE_PYTHON=pep517: bump PORTREVISION

security/py-securesystemslib: Update version 0.26.0=>0.27.0

Changelog:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.27.0

Revert "Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install
bytecode"

Despite installer's default behaviour to compile and install bytecode,
we are not doing so going forward at stage/package time. [0] During
initial development and qualification of PEP-517 framework support,
compiling and installing bytecode at stage/package time was considered,
but was found problematic, fragile and ultimately unreliable, both
currently and historically (with USE_PYTHON=distutils), due to our
fixed plist requirement. While the living binary distribution format
(wheel) specification [1] says to compile bytecode, that is in the
pure Python package management context (pip, etc); nuance always
exists when interacting with "system" package management.

Additionally, "bytecode is an implementation detail of the CPython
interpreter. No guarantees are made that bytecode will not be added,

Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install bytecode

- While I'm here, use long options for easier reading [1][2]
- Bump PORTREVISION of dependent ports (USE_PYTHON=pep517) for package change

It fixes build_fs_violation of dependent ports in poudriere (with -t flag).
It is also the default behavior of installer [2].

from py-sphinx log:
=>> Checking for staging violations... done
=>> Error: Filesystem touched during stage (files must install to ${STAGEDIR}):
extra: usr/local/lib/python3.9/site-packages/importlib_metadata/__pycache__
=>> Cleaning up wrkdir

from installer documentation:
--compile-bytecode
    Possible choices: 0, 1, 2
    generate bytecode for the specified optimization level(s) (default=0, 1)
--no-compile-bytecode
    don’t generate bytecode for installed modules
    Default: False

With hat:	python
Reference:	https://pypa-build.readthedocs.io/en/stable/ [1]
		https://installer.pypa.io/en/stable/cli/installer/ [2]

security/py-securesystemslib: Update version 0.25.0=>0.26.0

- Change to pep517 from distutils

Relnotes:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.26.0

*/*: rename CHEESESHOP to PYPI in MASTER_SITES

PR:			267994
Differential revision:	D37518
Approved by:		bapt

security/py-securesystemslib: Update version 0.23.0=>0.25.0

Relnotes:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.25.0

Remove WWW entries moved into port Makefiles

Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.

This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.

Approved by:		portmgr (tcberner)

Add WWW entries to port Makefiles

It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.

Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.

There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.

security/py-securesystemslib: Update version 0.22.0=>0.23.0

Relnotes:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.23.0

security/py-securesystemslib: switch to USES=pytest, fix tests

Reported by:	reprise
Approved by:	portmgr blanket

security/py-securesystemslib: Update 0.22.0

- Change MASTER_SITES to CHEESESHOP

Relnotes:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.22.0

*/*: Take maintainership

all: return koobs' ports to the pool after safekeeping his commit bit.

One more small cleanup, forgotten yesterday.
Reported by:	lwhsu

Remove # $FreeBSD$ from Makefiles.

Drop python 2.7 support from a few ports

With hat:	portmgr

[NEW PORT] security/py-securesystemslib: Cryptographic and general-purpose
routines

securesystemslib supports public-key and general-purpose cryptography,
such as ECDSA, Ed25519, RSA, SHA256, SHA512, etc. Most of the
cryptographic operations are performed by the cryptography and PyNaCl
libraries, but verification of Ed25519 signatures can be done in pure
Python.

WWW: https://github.com/secure-systems-lab/securesystemslib

[1] https://github.com/secure-systems-lab/securesystemslib/issues/166
[2] https://github.com/secure-systems-lab/securesystemslib/issues/167