compatibility with LibreSSL 2.7 and tweak comments in the patches.
In Python 3.10, fix the security level patch. Add a missing const
and drop @SECLEVEL=2 from the PY_SSL_DEFAULT_CIPHER_STRING, as that
will currently result in a runtime failure.
ok kmos
Add a new SUBST_VARS variable that is set to "@comment " on
most Python versions, but is set to "" on the default one. This makes
it easier to swap between default versions because you don't need
to figure out which @comments should be kept and which should be moved.
While there I remove some existing lines with @comment markers for
files that are not created by any of our current Python ports:
@comment bin/pyvenv
@comment lib/libpython3.8m.so (etc)
The @comment -> ${PY_DEFAULTONLY} change doesn't affect the generated
PLISTs at all, so for that a REVISION bump is unnecessary, but removing
the pyvenv/libpython3.Xm.so does require a bump
right now the installed python retains paths to the python build objdir,
and also enforces -L/usr/local/lib when linking python shared extensions
(which might not be desired):
$python3 -m sysconfig|grep LDSH
BLDSHARED = "cc -pthread -shared -fPIC -L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12 -L/usr/local/lib/"
LDSHARED = "cc -pthread -shared -fPIC -L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12 -L/usr/local/lib/"
python 3.x provides LDFLAGS_NODIST/CFLAGS_NODIST to avoid that (cf
https://docs.python.org/3/using/configure.html#envvar-CONFIGURE_LDFLAGS_NODIST),
but sadly if we only use it (and remove CPPFLAGS/LDFLAGS pointing at
/usr/local from CONFIGURE_ENV), libintl/textdomain detection during
configure fails.
So, taking inspiration from freebsd PR181721, dont add
CONFIGURE_LDFLAGS/CONFIGURE_CPPFLAGS to PY_LDFLAGS/PY_CPPFLAGS.
extend CHANGES.OpenBSD to explain the change (reminded by sthen@).
went in a bulk build (thanks ajacoutot@!) with a single fallout
(devel/gdb) that will get fixed shortly.
LLVM 13 introduces the --print-multiarch option. OpenBSD isn't multi-arch,
but that option caused problems for the build anyway.
I neutralized those checks.
allows some additional debugging features for Python-based software
(for example there's a new "py-bt" command to print a Python backtrace
which can give clues if a py process is hanging).
ok rpointel@
other than the usual "python3/<blank>" python version selection and
remove setting MODPY_VERSION=${MODPY_DEFAULT_VERSION_3} again from the
affected ports.
if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.
While waiting for this to appear in a proper Python 3.9.x release,
use upstream's commit for this severe sprintf bug.
The bug was reported on Jan 16 and the fix was available since Jan 18,
but only 3.6 and 3.7 have new releases as of now.
ok sthen
While waiting for this to appear in a proper Python 3.8.x release,
use upstream's commit for this severe sprintf bug.
The bug was reported on Jan 16 and the fix was available since Jan 18,
but only 3.6 and 3.7 have new releases as of now.
ok sthen
MODPY_BIN_ADJ's perl snippt accepts multiple files so save a few execs.
To make it more robust, also append `--' to it such that ports cannot
(accidentially) pass options; I've checked the tree that no port does
this on purpose.
The only case where this could fail is with huge MODPY_ADJ_FILES but
that is not the case in our tree; ports where lots of shebangs are
fixed have their own construct around it, e.g. textproc/calibre which
uses the `find -exec ${MODPY_ADJ_FILES} {} +' idiom.
OK sthen
setuptools picks up plugins during the configure stage whether a port
needs them or not. In some cases (currently just setuptools_scm), these
register hooks to run in the install stage; if the plugin is not a
listed build dependency this will cause the install stage to fail.
Recently reported by naddy with py-sphinx but we've seen spurious
failures elsewhere before which are likely due to this.
ok kmos@
An earlier diff was okayed by rpointel@, kmos@. sthen@ requested to move
the @conflict and @pkgpath markers from 3.7 to 3.8 in the same commit (a
better approach). Final diff was ok sthen@.
