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)
- Set PORTNAME to python and add PKGNAMESUFFIX
- 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 %%
- Fix shebang:
- Update SHEBANG_FILES
- Remove over-patched shebang fix of Lib/cgi.py
- Update http:// links in Makefile comments and patch files
Changes: https://docs.python.org/3.4/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
Remove patches and hacks that were used to work around the previous
situation
This allows to stage more ports as a regular user
Differential Revision: https://reviews.freebsd.org/D703
Reviewed by and discussed with: bapt
With hat: portmgr
Backport fix [1] for upstream Python Issue #21704 [2]: Fix build error for
_multiprocessing when semaphores are not available.
The symptom was originally reported by RedPorts 8.4-QAT/i386,
ultimately resulting in a packaging error:
...
checking for sem_open... yes
checking for sem_timedwait... yes
checking for sem_getvalue... yes
checking for sem_unlink... yes
...
checking whether POSIX semaphores are enabled... no
checking for broken sem_getvalue... yes
...
*** WARNING: renaming "_multiprocessing" since importing it failed:
build/lib.freebsd-8.4-RELEASE-i386-3.4/_multiprocessing.so: Undefined
symbol "_PyMp_sem_unlink"
...
pkg-static: lstat(/work/a/ports/lang/python34/work/stage/usr/local/lib/
python3.4/lib-dynload/_multiprocessing.so): No such file or directory
Something is funny for Jail-based systems when it comes to host/jail
semaphore detection. A config.log would be handy to help determine why.
[1] http://hg.python.org/cpython/rev/f618f6739200
[2] http://bugs.python.org/issue21704
Backport fix for upstream Issue #21166:
Prevent possible segfaults and other random failures of python
--generate-posix-vars in pybuilddir.txt build target by ensuring
that pybuilddir.txt is always regenerated when configure is run and
that the newly built skeleton python does not inadvertently import
modules from previously installed instances. [1]
This changeset has been committed for release in 2.7.9, 3.4.2, and 3.5.0.
A HUGE thank you to Ned Deily from the Python Core Development Team
for helping to identify the underlying cause, produce a fix and
wonderfully document the explanation.
[1] http://bugs.python.org/issue21166
Copy the second part of a change previously made to python27 [1], to
python31, python32 and python33.
This fixes staging and packaging of these ports by a non-root user by
running ranlib on the archive prior to it being installed read-only.
While I'm here:
- python27: Add breadcrumbs and references to the patch header
- python34: Update breadcrumbs and references to the patch header
[1] https://svnweb.freebsd.org/ports?view=revision&revision=350207
Submitted by: antoine
Reviewed by: kwm, sbz
The FreeBSD Python Team warmly welcomes Python 3.4 to the Ports tree:
- Add lang/python34
- Add devel/py-setuptools34
- Add Python 3.4.0 docs to lang/python-doc
Release Announcement and Major Features:
https://www.python.org/download/releases/3.4.0/
This also marks the next stage of a cleaner, much-closer-to-upstream
approach to Python on FreeBSD, that builds upon the hard work of the
entire FreeBSD Python team over the last year.
This port is built "entirely" from scratch, retiring as much of the
legacy, workarounds, patches and hacks from the existing Python
ports as possible.
Of particular note: static + shared dual-build is gone, as it was flaky
at best, grossly untested upstream and caused more issues than it
solved. It is replaced by a shared build by default. The static python
library remains installed and usable.
Major changes in this structure are:
- Replace dual static and shared in-tree build with shared-only.
- Use options helpers
- Replace plat-freebsd* hacks with a lighter weight alternative
- Strip all libraries and shared extensions
- Only retain patches that are absolutely necessary
- Replace static disabled_module_list with one from upstream
- Retain NIS and sparc64 workarounds from python33
- Deprecate SEM option, no longer optional.
- Deprecate PTH option, no longer maintained or supported upstream
- Deprecate FPECTL option, no longer maintained or supported upstream
- Add upstream issue references & breadcrumb annotations where possible
Tested by: many (Special thanks to Andrew Berg)
Reviewed by: xmj, nemysis, antoine
