12:36 antoine 

Deprecate a few broken ports

With hat:	portmgr

 

12:48 antoine 

Mark a few ports BROKEN, unfetchable

 

17:05 mat 

Use PY_FLAVOR for dependencies.

FLAVOR is the current port's flavor, it should not be used outside of
this scope.

Sponsored by:	Absolight

 

11:10 antoine 

Reduce dependency on the python2 metaport

PR:		225752
Submitted by:	Yasuhiro KIMURA

 

15:50 mat 

Convert Python ports to FLAVORS.

  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

 

14:08 mat 

Remove ${PORTSDIR}/ from dependencies, categories h, i, j, k, and l.

With hat:	portmgr
Sponsored by:	Absolight

 

17:45 mva 

- Convert ports from german/, java/, japanese/ and ports-mgmt/ to new
  USES=python

Approved by:	portmgr (implicit)

 

02:13 danilo 

- Add stage support
- Improve WWW
- Add DOCS option

PR:		ports/191501
Submitted by:	beyert@cs.ucr.edu

 

21:00 rene 

Python cleanup:
- USE_PYTHON* = 2.X -> USE_PYTHON* = 2
- USE_PYTHON* = 2.X+ -> USE_PYTHON* = yes
Reviewed by:	python (mva, rm)
Approved by:	portmgr-lurkers (mat)

 

16:22 wg 

Use setuptools for all Python ports.

Setuptools is the preferred method to manage Python distributions after
many changes to the packaging ecosystem over the past couple of years.

Only ports using USE_PYDISTUTILS= yes are affected by this commit, ports using
USE_PYDISTUTILS= easy_install remains the same however this usage is now
deprecated and should be converted to USE_PYDISTUTILS= yes.

Some Python distributions do not work with setuptools out of the box because
they extend the install command from distutils and not setuptools, and
so they need to be patched accordingly.

pip (which leverages setuptools) works around the issue by using eggs, however
we want to get rid of those as well, as support for "flat" installation is
unavailable or has other issues associated with it.

This work allows us to unify how python packages are built, ensure that Python
distributions are installed consistently, reduces complexity for Python port
maintainers and paves the way for simplifying the Python ports framework in
the future.

With hat on:	python
Reviewed by:	koobs, antoine
Exp-run:	bdrewery
Approved by:	bdrewery (portmgr)

 

18:47 bapt 

Add NO_STAGE all over the place in preparation for the staging support (cat:
japanese)

 

19:38 rm 

- update to 0.3.1.2

While I'm here:
- drop LICENSE_FILE that isn't needed for well-known licenses
- strict python version to 2.x only (apps using pygtk do not (and will not)
  support python3)
- do not try to remove directories that we not installing

PR:             168181
Submitted by:   Timothy Beyer <beyert at cs.ucr dot edu> (maintainer)

10:28 miwi 

Tegaki Main program:

    * is free and open-source
    * is multi-plaform
    * focuses on Chinese (simplified and traditional) and Japanese characters
    * supports 2 different recognition engines
    * aspires to work on both desktop-PCs and mobile devices

WWW: http://www.tegaki.org/

PR:             ports/149690
Submitted by:   Timothy Beyer <beyert at cs.ucr.edu>
Feature safe:   yes