The build was broken in the update to 3.10.2 due to the upstream commit
3ce6945f5f
This seems to have escaped notice of the maintainers because the build
system only whines and carries on instead of failing (although this was
also visible in the PLIST). Avoid use of undefined short names and NIDs
and do not use an inexistent flag.
ok sthen
python-3.8)
-@conflict py3-setuptools-<=57.4.0v0
+@conflict py3-setuptools-<57.4.0p0v0
<= in this case covers 57.4.0v0 *and* any 57.4.0pXXv0 version,
which is not we want. Use < and the specific p0v0 instead.
Since the non-default versions of Python now have pip executables
(in this case named bin/pip3.8) when updating from the OpenBSD version
where that file was in py3-pip, pkg_add needs to merge the updates
of the new py3-pip and python-3.8 packages. Found by sdk@ testing
7.0->-current updates. Add to the "switching default version"
checklist.
if you want to run some software that needs an older or newer version
of Python you can do so in most cases. For the default versions (2.7, 3.9)
pip is available from the separate port (devel/py2-pip, devel/py-pip).
Factor out some common parts to ../Makefile.inc while there. OK kmos@
It doesn't cover every py2 port that uses py-test, but it lets us
whittle down the number. The remaining py2 ports using py-test can then
either move to using MODPY_PYTEST (preferably) or a flavour-dependent
NO_TEST directly until we remove all use of py2 py-test and can then
update the py-test stack.
The goal is to shuffle things around allowing us to use this variable in
the packing lists. This should reduce a little bit of churn going
forward given some files get bumped with every point release.
For example in Python 3.9 we make the following update:
-lib/python3.9/lib2to3/Grammar3.9.10.final.0.pickle
+lib/python3.9/lib2to3/Grammar${FULL_VERSION}.final.0.pickle
-lib/python3.9/lib2to3/PatternGrammar3.9.10.final.0.pickle
+lib/python3.9/lib2to3/PatternGrammar${FULL_VERSION}.final.0.pickle
ok kmos@ (MAINTAINER), sthen@
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.
