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
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
- pycompile only once, previously it would pycompile 3 imported modules
(getopt, struct and py_compile) and make them read-only, and later try
to pycompile them again and fail
- ranlib before installing archive read-only
With hat: portmgr
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
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
lang/python26, lang/python27 and lang/python31 now add
ac_cv_opt_olimit_ok=no to CONFIGURE_ENV to disable functionality that
was removed in Python 3.2+ [1]
Pending a backport of the commit [2] to 2.7, we can now remove the
locally maintained patch to configure that disabled the functionality
when CC = clang.
Apart from being narrower in scope than ac_cv_opt_olimit_ok=no, the patch
doesn't work for FreeBSD versions where clang *is* cc (eg: 10.0+)
[1] http://hg.python.org/lookup/r85656
[2] http://bugs.python.org/issue877121
Reviewed by: antoine
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.
. 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
Submitted by: rm (myself)
Exp-run by: portmgr (miwi)
- revert erroneous threads patch in lang/python26 and lang/python27,
that was added after ports/131080. It was rejected upstream, because it's
not actually a bug, but misuse.
Gabor Pali (pgj) in collaboration with Kubilay Kocak (koobs) did an
independent investigation regard the issue. See here for details:
http://lists.freebsd.org/pipermail/freebsd-python/2013-April/005376.html
PR: 153167
Submitted by: Duncan Findlay <duncan@duncf.ca>
Reported by: pgj/koobs (at python@ ML)
Exp-run by: portmgr (miwi)
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
${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/
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.
(PYTHON_DISTFILE variable)
- switch lang/python ports (and it's slaves) to tar.xz
I compared all the four pairs .tgz/.tar.xz and they have no content differences.
Discussed on: python@
