ports/sysutils/py-docker, branch 13-eol

security/libsodium: Update to 1.0.21

2026-01-07T10:22:10Z

The API remains compatible but bumping all dependent ports as SHLIB has changed. Changelog: https://github.com/jedisct1/libsodium/releases/tag/1.0.21-RELEASE Security: https://00f.net/2025/12/30/libsodium-vulnerability/ PR: 279347

sysutils/py-docker: Fix build error

2025-02-11T09:43:15Z

Approved by: hrs (mentor, blanket)

sysutils/py-docker: Update to 7.1.0

2025-02-07T15:28:21Z

ChangeLog: https://github.com/docker/docker-py/compare/7.1.3...6.1.3 Approved by: hrs (mentor, blanket)

security/libsodium: update to 1.0.19, bump dependent ports

2024-05-20T10:33:03Z

PR: 278259 Reported by: Andrey Korobkov

devel/py-setuptools-scm: update to 8.0.4

2024-02-29T07:18:32Z

Directory and PORTNAME changed to match normalised name in release tarball; consumers updated to match. Although setuptools itself is specified as a run dependency in the Python package metadata, it is currently left out here to prevent environment pollution until at least PR 270510 is committed. Additionally, this version of setuptools-scm requires setuptools>=61, which means this version is only meant for USE_PYTHON=pep517 ports as all USE_PYTHON=distutils ports will switch to devel/py-setuptools58 also after PR 270510. science/py-emmet-core is switched to devel/py-setuptools_scm7 accordingly, as it specifies setuptools-scm<8. devel/py-{flit-scm,hatch-vcs} have ${PY_SETUPTOOLS} added to RUN_DEPENDS to compensate. Further details: https://wiki.freebsd.org/Python/setuptools Reported by: yuri Co-authored by: matthew Exp-run by: antoine (earlier iteration) Approved by: yuri (science/py-emmet-core, previous iteration) PR: 272134 Differential Revision: https://reviews.freebsd.org/D39288

sysutils/py-docker: Update to 6.1.3

2023-12-31T07:26:23Z

PR: 275494 Reported by: wen@(via email) Approved by: maintainer

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

2023-06-27T19:34:34Z

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:

USE_PYTHON=pep517: bump PORTREVISION

2023-04-04T18:29:11Z

sysutils/py-docker: Change MAINTAINERship to myself

2023-02-23T08:59:52Z

Approved by: hrs (mentor)

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

2023-02-05T19:05:02Z

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, removed, or changed between versions of Python," thus "should not be considered to work across Python VMs or Python releases." [2] This is important to ensuring correctness for those ports specifying NO_ARCH. Instead of compiling and installing bytecode at stage/package time, there is a WIP, review D34739, that compiles and installs bytecode at install time instead, using triggers. The aforementioned build_fs_violations will be investigated. This reverts commit de6965254c3a007efcf697c3d455b54d2aeb2383. With hat: python Approved by: tcberner (mentor, portmgr) Reference: https://wiki.freebsd.org/Python/PEP-517 [0] https://packaging.python.org/en/latest/specifications/binary-distribution-format/ [1] https://docs.python.org/3/library/dis.html [2]