When python3.?-config is symlinked to another location it starts
outputting bogus paths. For example
$ pwd
/home/tobias
$ python3.6-config --includes
-I/usr/local/include/python3.6m -I/usr/local/include/python3.6m
$ ln -s /usr/local/bin/python3.6-config python3-config
$ ./python3-config --includes
-I/home/include/python3.6m -I/home/include/python3.6m
This breaks ports trying to use BINARY_ALIAS together with
python3.?-config. Apply a patch to resolve the symlink first before
trying to find the install prefix.
PR: 229749
Submitted by: tobik
Reviewed by: antoine, miwi
Approved by: python (miwi)
- Update Makefile and PLIST to be similar with python36
- Sort USES
- Remove CPE_*: all of them are default values
- Update PLIST_FILES: do not use %%
- Remove over-patched shebang fix of Lib/cgi.py
- Update http:// links in Makefile comments and patch files
Changes: https://docs.python.org/3.5/whatsnew/changelog.html
Security: 0fe70bcd-2ce3-46c9-a64b-4a7da097db07
MFH: 2018Q1
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464
This patch was submitted to upstream libffi and from there to upstream
libtool, but it doesn't do anything. The original patch committed in
r158131 did do something but when it was no longer needed it was changed
into something that doesn't make sense in r221521 instead of being removed.
Remove it now before it causes more confusion.
Add patch for integer overflow in zipimport module to all our python ports.
While I'm here, get rid of -f flag in ${RM} invocation, because ${RM} already
expands to rm -f, so in result we are getting something like:
/bin/rm -f -f /wrkdirs/usr/ports/lang/python35/work/stage/usr/local/lib/libpython3.so
PR: 210325
Submitted by: Vladimir Krstulja <vlad-fbsd@acheronmedia.com>
Security: 1d0f6852-33d8-11e6-a671-60a44ce6887b
With hat: python
check in pyport.h for working around a very old ctype issue.
If the workaround for this issue is enabled, pyport.h redefines
toupper() and some other ctype macros, and this wreaks havoc when
including newer libc++ headers (or any other system header which tries
to declare those functions).
Approved by: portmgr (antoine)
PR: 208486
MFH: 2016Q2
In certain situations, file references (.py[co]) for Python files that
fail to compile with compileall() are still added to distutils --record
output.
This output is used for pkg-plist generation and must only contain
references to files that will be installed.
One example of a failure condition is when a Python 2/3 compatible
package containing a file containing Python 3.x only code is built with
Python 2.x, such as Gunicorn's _gaiohttp.py [1]
This change backports patches submitted against upstream issue 20397 [2]
that has not yet been committed.
- For Python 2.7 and 3.5, backport both install_lib and test
- For Python 3.2, 3.3 and 3.4, only backport install_lib
[1] https://svnweb.freebsd.org/changeset/ports/404558
[2] https://bugs.python.org/issue20397
Thank you to Brendan Molloy for producing and submitting the patches
against upstream sources.
Reviewed by: sbz (python)
MFH: 2016Q1
Differential Revision: D4832
non-default Python versions:
- Add pyXY-{sqlite3,gdbm,tkinter} ports for generating binary packages
- Improve/add pkg-message to point users to install respective packages of
separated Python standard modules
- Add COMMENT to explicitly show the Python version that package should be
used with
- Simplify version-related PYTHON_* for lang/python35
Reviewed by: koobs
Differential Revision: https://reviews.freebsd.org/D4170
FreeBSD welcomes Python 3.5 (early, pre-release) to the Ports tree,
with 3.5.0 release candidate 3!
Please test this port and Python 3.5 profusely. If you notice issues,
please report them upstream at: https://bugs.python.org to ensure a
robust upcoming 3.5.0 release.
Whats New in Python 3.5:
* https://docs.python.org/3.5/whatsnew/3.5.html
Python 3.5 Release Schedule (PEP 478)
* http://www.python.org/dev/peps/pep-0478
Note: This port retires an old fcntlmodule.c patch, possibly
temporarily. User impact *should* be zero. For more information
see: https://bugs.python.org/issue25026
Requested by: Webair Inc :)
