===> The following configuration options are available for python33-3.3.6_11:
DEBUG=off: Build with debugging support
IPV6=on: IPv6 protocol support
LIBFFI=on: Use libffi from ports instead of bundled version
NLS=on: Enable gettext support for the locale module
PYMALLOC=on: Enable specialized mallocs
THREADS=on: Threading support
TSC=off: Enable rocessor timestamp counter profiling
===> Use 'make config' to modify these settings
Remove Python 3.3 and related ports, it expired today:
2017-09-01 lang/python33: No longer receives bug fixes, only security updates.
Please update to Python 3.6
databases/py33-gdbm
databases/py33-sqlite3
devel/py33-setuptools
x11-toolkits/py33-tkinter
devel/py3-enum34
Pointyhat to me.
A stray '.' somehow made it past my testing.
Do *not* bump portrevision as this only affects the packaging/stage
of these ports on mips/armv6 or other cross compiled targets.
PR: 221202
Reported by: antoine
Add a code block for the qemu-user enabled cross build environment. When using
this environment in poudriere, CC is not set to the default of /usr/bin/cc and
a cross-compile toolchain is used. We need to hand edit this so that the run
time configuration for python matches what the FreeBSD base system provides.
PR: 208282
Submitted by: manu
Approved by: portmgr (mat)
lang/python{27,33,34,35,36}: Make Python curses module work with Unicode
Use readline from ports (USES= readline:port) and patch
setup.py to ignore readline from base. The patch is necessary for
FreeBSD < 1100000, as after this the readline library became an
INTERNALLIB, see base r268461 [1]
Link devel/readline against termcapw instead of termcap is part of
this change, see ports r444463 [2]
Note that this is the **ports** approach for getting Python curses
module working with Unicode. The other way is splitting libncurses
into separate libncurses and libtinfo in base, for which an open
issue exists [3].
(Only the first 15 lines of the commit message are shown above )
lang/python{27,33,34,35,36}: Install GDB debugging script
Users with a GDB that supports [1] Python extensions will automatically
load the extra debugging extensions when debugging programs that are
linked with libpythonX.Y.so.foo.
This enables extensions like 'py-bt' and 'py-frame' as described in
the Fedora Wiki Article: Easier Python Debugging [2], which can be
useful for debugging Python program state from crashes in C extensions,
for example.
[1] PYTHON option enabled in devel/gdb
[2] https://fedoraproject.org/wiki/Features/EasierPythonDebugging
PR: 203021
Submitted by: cem
Reviewed by: mat, koobs (python)
Approved by: koobs (python)
Differential Revision: D10398
Remove no-op patch.
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.
Use USES=pathfix where applicable.
PR: 213195
Submitted by: mat
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D8093
lang/python[xx]: backport upstream fix for CVE-2016-5636
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
For the various lang/python* ports, improve the __FreeBSD_version
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
lang/python{27,3*}: Backport patch in upstream issue20397
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.
(Only the first 15 lines of the commit message are shown above )
lang/python27(3*), Mk/Uses/python.mk: remove make spawn
There are some inefficiencies in python.mk that significantly slow down
full tree scanning. The use of bmake to obtain the current version of
a specific python is responsible for the majority of the slow done.
This commit splits out the PYTHON_PORTVERSION definition (which is the
same as the lang/python* PORTVERSION) into separate files. With this
change, python.mk can simple include the makefile fragment instead of
spawning a new instance of make.
Different Revision: https://reviews.freebsd.org/D4660
Approved by: antoine (python), mva (python)
lang/python33: Fix typo in No-SSLv3 patch
- Fix typo that was introduced with the No-SSLv3 patch [1]
[1] http://svnweb.freebsd.org/changeset/ports/404347
Reported by: antoine via pkg-fallout
Reviewed by: koobs (mentor, python), antoine (python)
Approved by: koobs (mentor, python), antoine (python)
Differential Revision: https://reviews.freebsd.org/D4721
Add version specified ports of separated standard Python modules for
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
lang/python{27,32,33}: Fix missing shlib path in python-config
In Python 3.4+, upstream added and switched to using a shell
implementation of the python-config script [1]. The Python
implementation (python-config.py) remained used by all versions < 3.4.
While the shell implementation returns the path to the Python
shared library when using the --ldflags script argument, the Python
implementation of the script does not. The bug has been reported, but
has not yet been merged [2].
The Python ports currently default to including ${LOCALBASE}/lib
in LIBS when the NLS option is enabled (which it is by default).
When built *with* NLS (gettext) support, the flags added to LIBS
(Only the first 15 lines of the commit message are shown above )
lang/python{27,32,33,34}: Mark MAKE_JOBS_UNSAFE
Parser/pgen code intermittently and non-deterministically fails
at build time causing errors including, among others:
* Parser/pgen.o: file not recognized: File truncated
* pgenmain.c:(.text+0x244): undefined reference to `_Py_pgen'
This is apparently due to incorrect uses of recursive make [1] which
was fixed in the upstream Python 'default' (3.5) branch [2].
This change marks all Python port versions as MAKE_JOBS_UNSANFE until
the the original changeset [1] and the resulting regression in
cross-builds [3], whos fix is still pending, can be backported.
[1] https://bugs.python.org/issue22359
[2] https://hg.python.org/cpython/rev/c2a53aa27cad
[3] https://bugs.python.org/issue22625
PR: 200622
Reported by: marino
MFH: 2015Q3
MASTER_SITES cleanup.
- Replace ${MASTER_SITE_FOO} with FOO.
- Merge MASTER_SITE_SUBDIR into MASTER_SITES when possible. (This means 99.9%
of the time.)
- Remove occurrences of MASTER_SITE_LOCAL when no subdirectory was present and
no hint of what it should be was present.
- Fix some logic.
- And generally, make things more simple and easy to understand.
While there, add magic values to the FESTIVAL, GENTOO, GIMP, GNUPG, QT and
SAMBA macros.
Also, replace some EXTRACT_SUFX occurences with USES=tar:*.
Checked by: make fetch-urlall-list
With hat: portmgr
Sponsored by: Absolight
Force a rebuild/upgrade to chase head r280306 which removed SSLv2 support.
This fixes head package users so they have working SSL support. There was
already a built-time fix for this.
lang/python33: BROKEN on i386 without LIBFFI
As per lang/python27 (r377581):
- Add BROKEN for i386 without LIBFFI option, and add upstream
issue references.
While I'm here, clean up after the LIBFFI option addition:
- Sort options variables: OPTIONS_* and *_DESC
- Use OPTIONS helpers
- Reduce diffs between lang/python* ports
Change INSTALL_DATA to install with mode 644
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
lang/python{27,33,34}: Bump PORTREVISION, sanitizes builds.
Bump PORTREVISION, as prior to the previous change that fixed upstream Issue
#21166, Python builds could be potentially polluted by the host environment
which could caused runtime issues because of ABI differences.
lang/python{27,33,34}: Backport fix for upstream Issue #21166
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
- Add USE_OPENSSL, since all lang/python ports build the _ssl module, which
requires a working OpenSSL implementation
Phabric: D569
Reviewed by: wg@
With hat: python@
- Remove everything related to USE_PYTHON and bsd.python.mk. This is a
preparatory step to convert bsd.python.mk into a USES file.
- Remove the shared/static build separation, which is the source of many
problems and even more hacks. Instead build only the shared version, which
greatly simplifies the build.
- Use NLS_LIBS instead of NLS_LDFLAGS as done for lang/python27 (r357486)
- Remove the FPECTL option to align the build with the clean "template" from
lang/python34.
- Remove PORTDATA and EXAMPLES. Those will be made available via separate
ports.
- Add a new DEBUG option to enable debug builds as for lang/python34.
- Add a new TSC option for precise timestamp counter support as for
lang/python34.
- Reactivate curses/ncurses support.
- Use buildbottest in the regression-test: target.
Phabric: D410
Exp-run: 192242, 192244
Reviewed by: koobs, bapt
With hat: python@
Convert GMAKE to MAKE_CMD
Please note that lots of invocation of MAKE_CMD here are wrong as they do not
properly respect MAKE_ENV and friends
With hat: portmgr
lang/python{31,32,33}: Fix stage/package as non-root
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
lang/python{31,32,33}: Add clang 3.4 fix from python27
Copy change committed to python27 [1] to python31, python32 and
python33 to fix builds of some extensions with Clang 3.4.
Also add breadcrumbs to the patch header in lang/python27 referencing
the upstream issue. [2]
The Python 3.4 port (lang/python34) already carries the patch.
[1] https://svnweb.freebsd.org/ports?view=revision&revision=346428
[2] http://bugs.python.org/issue20767
lang/python*: Backport security fix for CVE-2014-1912
A vulnerability was reported [1] in Python's socket module, due to a
boundary error within the sock_recvfrom_into() function, which could be
exploited to cause a buffer overflow.
This could be used to crash a Python application that uses the
socket.recvfrom_info() function or, possibly, execute arbitrary code
with the permissions of the user running vulnerable Python code.
This vulnerable function, socket.recvfrom_into(), was introduced in
Python 2.5. Earlier versions are not affected by this flaw. This is
fixed in upstream branches for version 2.7, 3.1, 3.2 and 3.3.
[1] http://bugs.python.org/issue20246
MFH: 2014Q1
Security: 8e5e6d42-a0fa-11e3-b09a-080027f2d077
All Python ports: Address abort() for ctypes import on FreeBSD/ARM
The current FreeBSD/ARM __clear_cache() implementation does nothing #if
__i386__ || __x86_64__ #else abort();
cognet@ advises this is an issue for anything !Apple that is using the
libcompiler_rt provided by Clang on ARM, and requires upstreaming.
This is the root cause of abort() on import for the ctypes module in
Python, as they bundle libffi. [1]
This change patches the bundled libffi library in all Python ports, even
though it is a NOOP for the ports that use devel/libffi. These ports,
currently python31, will get the fix via ports/184517
A huge shout out to cognet@ who helped diagnose the issue and created
the patch to address it. Thank you!
PR: ports/149167 [1]
PR: ports/184517
Submitted by: cognet [3]
Reviewed by: cognet, eadler, milki, ak
- Move the symlink magic for the default python version into lang/python
and lang/python2 and lang/python3. This change brings us closer to the goal
of making Python ports usable with different Python versions at the same
time.
- Add a new lang/python2 port to handle the symlinks for bin/python2,
bin/idle2, bin/pydoc2 and so on.
- Add a new lang/python3 port to handle the symlinks for bin/python3,
bin/idle3, bin/pydoc3 and so on.
- Bump the PORTREVISION on all lang/python* ports.
Add patch that resolves the issue, found after r250991 in src HEAD.
Investigation and the patch are from Marcel Moolenaar.
I also added upstream bug-report, based on Marcel's info:
http://bugs.python.org/issue18178
There also was relevant discussion on current@:
http://lists.freebsd.org/pipermail/freebsd-current/2013-June/
Please see there for details of the issue.
Submitted by: marcel (python@ ML)
Reported by: many
Using GNU make to build this port now, because people reporting various
build problems with pmake, that's cannot be reproduced reliable. There is
also upstream bug-report [1]. The solution is suggested by Marcus von Appen.
PORTREVISION isn't bumped, because there is no need in gmake for people
that already built python33 successfully.
Reported by: many
Submitted by: mva (by mail)
Tested by: demon
- update to latest upstream versions:
. lang/python27: 2.7.3 -> 2.7.5
. lang/python32: 3.2.3 -> 3.2.4
. lang/python33: 3.3.0 -> 3.3.1
- update Mk/bsd.python.mk with new versions
- mark lang/python26 and lang/python31 as deprecated (set them to
upstream EoL dates)
- update docs (lang/python-doc-html)
- align databases/py-bsddb patch for python27 - most of it was applied
upstream. Raise BDB version to 4.3 atleast, according to
upstream requirements.
Many thanks to Martin (miwi) for his time on this update.
PR: 178506
(Only the first 15 lines of the commit message are shown above )
Commit all the non-functional changes to python ports to reduce the diff size
for an exp-run of updated python versions.
- trim Makefile headers
- remove leading indefinite article from COMMENT
- use PYTHON shortcut in MASTER_SITES
- whitespace fixes
- remove checks for unsupported versions of FreeBSD
- use static value ``33'' instead of PYTHON_SUFFIX in lang/python33/pkg-plist,
because this value is not supposed to be changed across the branch and for
consistency with other python3 ports
- remove conflicts in lang/python-mode.el with not more existing python-2.4
Fix logic (should be defined to true integer, not false).
While here, let's use patch from upstream so it obviously conflicts on
the next update.
Submitted by: koobs
Obtained from: http://bugs.python.org/issue16753
- Remove "first-installed-win" logic for automatically setting
${PYTHON_DEFAULT_VERSION}, this generates conflicting packages.
- Create symbolic links as PEP 394 [1] suggests. ${PYTHON_DEFAULT_VERSION}
will create python and python${MAJOR_VERSION} links. In current default,
lang/python27 will create: python -> python2 -> python2.7
- Introduce ${PYTHON3_DEFAULT_VERSION}, which will handle bin/python3 link.
At this point, lang/python33 will create python3 -> python3.3
- Minor cleanups
* Trim Makefile headers
* Remove ${OSVERSION} detection for xz, whihc is done by USE_XZ
[1] http://www.python.org/dev/peps/pep-0394/
- Remove test and regression-test targets for now - they pollute the
installation on tinderboxes causing leftovers
Discussed with: Kubilay Kocak <koobs.freebsd@gmail.com>
Create python2 symlink for the latest version of python2.X executable and
python3 symlink for the latest version of python3.X executable.
People who really want to use older python version for both python branches
should specify explicit version number in interpreter invocation.
Discussed on python@ long ago.
