Merge branch 'dev-python/pyvows'

* dev-python/pyvows:
  pyvows-9999.ebuild: Bump to EAPI 6 and git-r3

Conflicts:
dev-python/pyvows/pyvows-2.0.3.ebuild

The conflicts are due to the file addition/removal and thte local
dev-python/pyvows namespacing, and were resolved by removing
pyvows-2.0.3.ebuild and adding pyvows-2.1.0.ebuild.

Merge branch 'dev-python/derpconf'

* dev-python/derpconf:
  derpconf-9999.ebuild: Bump to EAPI 6 and git-r3

Merge branch 'dev-python/pexif'

Replacing the obsolete thumbor-pexif.

* dev-python/pexif:
  pexif-9999.ebuild: Convert from thumbor-pexif to pexif

Conflicts:
dev-python/thumbor-pexif/thumbor-pexif-0.14.1.ebuild
dev-python/thumbor-pexif/thumbor-pexif-9999.ebuild
pexif-9999.ebuild
thumbor-pexif-9999.ebuild

The conflicts are due to the change in dev-python/* namespacing, and
were resolved by creating dev-python/pexif to exactly match the branch
and removing dev-python/thumbor-pexif.

pyvows-9999.ebuild: Bump to EAPI 6 and git-r3

There were no changes impacting this ebuild [1].

I've also compared pyVows's setup.py since I last checked (59e6737,
2.0.6) to the current tip (a26b59a, 2.1.0), and there were no
dependency changes.

[1]: https://devmanual.gentoo.org/ebuild-writing/eapi/#eapi=6

derpconf-9999.ebuild: Bump to EAPI 6 and git-r3

There were no changes impacting this ebuild [1].

I've also compared derpconf's setup.py since I last checked (26f909f,
0.7.2) to the current tip (37ee111, 0.8.0-6-g37ee111), and the only
change is tornado-pyvows -> pyVows.  That was already part of my
ebuild though, since I'd submitted the change [2].

Alphabetize the test dependencies while I'm touching the ebuild,
although none of these have changed upstream.

[1]: https://devmanual.gentoo.org/ebuild-writing/eapi/#eapi=6
[2]: https://github.com/globocom/derpconf/pull/11
     Subject: Depend on pyVows, not tornado-pyvows

pexif-9999.ebuild: Convert from thumbor-pexif to pexif

Now that pexif has cut 0.15 [1,2].

Also bump from EAPI 5 to 6 and from git-2 to the newer git-r3 (there
were no changes impacting this ebuild [3]).

[1]: https://github.com/thumbor/thumbor/issues/294
     Subject: As pexif is now on pypi revert from thumbor fork
[2]: https://pypi.python.org/pypi/pexif/0.15
     Uploaded on: 2014-12-03
[3]: https://devmanual.gentoo.org/ebuild-writing/eapi/#eapi=6

dev-embedded: Remove simulavr and teensy-*

I don't have time to maintain these.

virtual/monkeysphere-validation-agent: Drop Monkeysphere

I don't actively use this anymore, and don't have time to maintain a
package I don't use.

dev-perl/Crypt-X509 is in the main Gentoo repository since 2014-05-28.

dev-python/geopy: Remove package

Geopy has been in the main Gentoo tree since at least 2012-06-26 [1].

[1]: https://bugs.gentoo.org/show_bug.cgi?id=423625

Merge remote-tracking branch 'origin/dev-python/thumbor'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/thumbor
  $ git read-tree --prefix=dev-python/dev-python/thumbor/ -u origin/dev-python/thumbor
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/thumbor-pexif'

* origin/dev-python/thumbor-pexif:
  thumbor-pexif-0.14.1.ebuild: Dead ebuild for thumbor (which wants <1.0)

Merge remote-tracking branch 'origin/dev-python/tornado-pyvows'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/tornado-pyvows
  $ git read-tree --prefix=dev-python/dev-python/tornado-pyvows/ -u origin/dev-python/tornado-pyvows
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

files/init.d/thumbor: Change the default port to 8888

Avoid:

  Traceback (most recent call last):
    File "/usr/lib/python-exec/python2.7/thumbor", line 9, in <module>
      load_entry_point('thumbor==4.5.4', 'console_scripts', 'thumbor')()
    File "/usr/lib64/python2.7/site-packages/thumbor/server.py", line 87, in main
      server.bind(context.server.port, context.server.ip)
    File "/usr/lib64/python2.7/site-packages/tornado/tcpserver.py", line 162, in bind
      backlog=backlog)
    File "/usr/lib64/python2.7/site-packages/tornado/netutil.py", line 90, in bind_sockets
      sock.bind(sockaddr)
    File "/usr/lib64/python2.7/socket.py", line 224, in meth
      return getattr(self._sock,name)(*args)
  socket.error: [Errno 13] Permission denied

because port 80 is a privledged port, and it's not worth using an
additional service like authbind [1] to give us the capability to bind
to it.  8888 is unprivileged, and it's Thumbor's default [2]

[1]: http://en.wikipedia.org/wiki/Authbind
[2]: https://github.com/thumbor/thumbor/wiki/Running#-p-or---port

files/init.d/thumbor: Remove --syslog option

Thumbor doesn't support syslog-logging out of the box (yet [1]).

[1]: https://github.com/thumbor/thumbor/issues/377

thumbor-9999.ebuild: Hard-code OpenCV Python version

media-libs/opencv uses python-single-r1, which means it doesn't like
our ${PYTHON_USEDEP}:

  emerge: there are no ebuilds built with USE flags to satisfy
  "media-libs/opencv[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]".

Note the '-' in front of python_single_target_python2_7.  I'm not sure
what the best way to handle this is, since *without* the OpenCV
dependency, Thumbor could theoretically be installed for multiple
Python versions simultaneously.  It would be nice to translate the
OpenCV ebuild to python-r1 or distutils-r1, but it ties the Python
binding config into its main CMake setup:

  local mycmakeargs=(
    ...
    $(cmake-utils_use_build python opencv_python)
    ...
  )

That makes it hard to step in and build Python bindings for a
different version.  Until someone thinks up (or tells me about) a
cleaner way to handle this, I'm just going to hardcode the
single-version we need.

dev-python/thumbor: Add this image-thumbnailing service

thumbor-pexif-0.14.1.ebuild: Dead ebuild for thumbor (which wants <1.0)

tornado-pyvows-9999.ebuild: Loosen the pyVows dependency to blacklist only 2.0.4 and 2.0.5

The breakage was fixed with pyVows 2.0.6.  I've reported this
dependency change upstream with [1].

[1]: https://github.com/rafaelcaricio/tornado_pyvows/pull/15

Merge remote-tracking branch 'origin/dev-python/raven'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/raven
  $ git read-tree --prefix=dev-python/dev-python/raven/ -u origin/dev-python/raven
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/webtest'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/webtest
  $ git read-tree --prefix=dev-python/dev-python/webtest/ -u origin/dev-python/webtest
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

raven-9999: Convert the old 2.0.10 ebuild into a live ebuild

That also serves double-duty as a 5.0.0 ebuild, since the changes
between 5.0.0 and the current master don't require different install
instructions.

Upgrade changes:

* Modernize PYTHON_COMPAT entries.  The upstream package is compatible
  with all of these (or at least tries to test on all of these [1]).
  They test on 2.6 too, but that's not in the Portage tree anymore.
* I've added an if block to swap in git-2 live ebuild handling
  depending on the package version.
* I've dropped the runtime dependencies, because the only runtime
  dependency is simplejson, which I imagine they only use for Python
  2.6 support [2].
* The new dependencies are almost straight from the 5.0.0 setup.py,
  except I don't include python-coveralls (and neither will the next
  version of setup.py [3]).  You'll want to emerge it by hand if
  you're using 5.0.0, to avoid Setuptools trying to install it for
  you.

[1]: https://github.com/getsentry/raven-python/blob/5.0.0/.travis.yml
[2]: https://github.com/getsentry/raven-python/blob/5.0.0/docs/install/index.rst#requirements
[3]: https://github.com/getsentry/raven-python/pull/497
     9b5c3d3d (setup.py: Remove python-coveralls requirement,
     2014-09-30)

webtest-*.ebuild: Add lxml to DEPEND[test]

Avoid:

  File "/var/tmp/portage/dev-python/webtest-1.4.3-r1/work/WebTest-1.4.3/docs/index.txt", line 320, in index.txt
  Failed example:
      res.lxml
  Exception raised:
      Traceback (most recent call last):
        File "/var/tmp/portage/dev-python/webtest-1.4.3-r1/work/WebTest-1.4.3/webtest/app.py", line 568, in lxml
          from lxml import etree
      ImportError: No module named 'lxml'

      During handling of the above exception, another exception occurred:

      Traceback (most recent call last):
        File "/usr/lib64/python3.3/doctest.py", line 1313, in __run
          compileflags, 1), test.globs)
        File "<doctest index.txt[22]>", line 1, in <module>
          res.lxml
        File "/var/tmp/portage/dev-python/webtest-1.4.3-r1/work/WebTest-1.4.3/webtest/app.py", line 571, in lxml
          "You must have lxml installed to use response.lxml")
      ImportError: You must have lxml installed to use response.lxml

and:

  File "/var/tmp/portage/dev-python/webtest-2.0.11/work/WebTest-2.0.11-python3_3/docs/testresponse.txt", line 124, in testresponse.txt
  Failed example:
      res.lxml
  Exception raised:
      Traceback (most recent call last):
        File "/var/tmp/portage/dev-python/webtest-2.0.11/work/WebTest-2.0.11-python3_3/webtest/response.py", line 477, in lxml
          from lxml import etree
      ImportError: No module named 'lxml'

      During handling of the above exception, another exception occurred:

      Traceback (most recent call last):
        File "/usr/lib64/python3.3/doctest.py", line 1313, in __run
          compileflags, 1), test.globs)
        File "<doctest testresponse.txt[8]>", line 1, in <module>
          res.lxml
        File "/var/tmp/portage/dev-python/webtest-2.0.11/work/WebTest-2.0.11-python3_3/webtest/response.py", line 480, in lxml
          "You must have lxml installed to use response.lxml")
      ImportError: You must have lxml installed to use response.lxml

webtest-*.ebuild: Drop old stable versions

I'm only testing 1.4.3-r1 and later.  1.4.3-r1 is stable so I doubt
anyone is still using the older versions.

webtest-*.ebuild: Install lint3 for Python 3

As I reported in Gentoo's #524724 [1]:

  $ docker run --rm -i -t wking/gentoo-portage:20140911 /bin/bash
  # emerge -av dev-python/webtest
  # python3.3 -c 'import webtest'
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/usr/lib64/python3.3/site-packages/webtest/__init__.py", line 11, in <module>
      from webtest.app import TestApp
    File "/usr/lib64/python3.3/site-packages/webtest/app.py", line 41, in <module>
      from webtest import lint3 as lint
  ImportError: cannot import name lint3

I've also trimmed the Manifest, because my overlay uses thin, unsigned
manifests.  Feel free to re-thicken if you prefer.

I've also skipped the ChangeLog entry, because folks can just look at
this commit message.  Feel free to extract a ChangeLog entry from this
if you prefer.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=524724

Merge remote-tracking branch 'origin/dev-python/pytest-django'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/pytest-django
  $ git read-tree --prefix=dev-python/dev-python/pytest-django/ -u origin/dev-python/pytest-django
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/django-configurations'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/django-configurations
  $ git read-tree --prefix=dev-python/dev-python/django-configurations/ -u origin/dev-python/django-configurations
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/dj-search-url'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/dj-search-url
  $ git read-tree --prefix=dev-python/dev-python/dj-search-url/ -u origin/dev-python/dj-search-url
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/dj-email-url'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/dj-email-url
  $ git read-tree --prefix=dev-python/dev-python/dj-email-url/ -u origin/dev-python/dj-email-url
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/dj-database-url'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/dj-database-url
  $ git read-tree --prefix=dev-python/dev-python/dj-database-url/ -u origin/dev-python/dj-database-url
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/django-cache-url'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/django-cache-url
  $ git read-tree --prefix=dev-python/dev-python/django-cache-url/ -u origin/dev-python/django-cache-url
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/pytest-xdist'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/pytest-xdist
  $ git read-tree --prefix=dev-python/dev-python/pytest-xdist/ -u origin/dev-python/pytest-xdist
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/execnet'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/execnet
  $ git read-tree --prefix=dev-python/dev-python/execnet/ -u origin/dev-python/execnet
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/south'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/south
  $ git read-tree --prefix=dev-python/dev-python/south/ -u origin/dev-python/south
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

dev-python/pytest-django-9999.ebuild: Add this Raven test dependency

I haven't been able to get the test suite working locally, so I'm
leaving it out of this commit.

dev-python/django-configurations: Add this Raven test dependency

The django-cache-url dependency avoids the following test failure:

  Traceback (most recent call last):
    File "/.../configurations/utils.py", line 32, in import_by_path
      module = import_module(module_path)
    File "/usr/lib64/python3.3/importlib/__init__.py", line 90, in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
    File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
    File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
    File "<frozen importlib._bootstrap>", line 1529, in _find_and_load_unlocked
  ImportError: No module named 'django_cache_url'

The dj-database-url dependency avoids the following test failure:

  Traceback (most recent call last):
    File "/.../configurations/utils.py", line 32, in import_by_path
      module = import_module(module_path)
    File "/usr/lib64/python3.3/importlib/__init__.py", line 90, in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
    File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
    File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
    File "<frozen importlib._bootstrap>", line 1529, in _find_and_load_unlocked
  ImportError: No module named 'dj_database_url'

The dj-email-url dependency avoids the following test failure:

  Traceback (most recent call last):
    File "/.../configurations/utils.py", line 32, in import_by_path
      module = import_module(module_path)
    File "/usr/lib64/python3.3/importlib/__init__.py", line 90, in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
    File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
    File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
    File "<frozen importlib._bootstrap>", line 1529, in _find_and_load_unlocked
  ImportError: No module named 'dj_email_url'

The dj-search-url dependency avoids the following test failure:

  Traceback (most recent call last):
    File "/.../configurations/utils.py", line 32, in import_by_path
      module = import_module(module_path)
    File "/usr/lib64/python3.3/importlib/__init__.py", line 90, in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
    File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
    File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
    File "<frozen importlib._bootstrap>", line 1529, in _find_and_load_unlocked
  ImportError: No module named 'dj_search_url'

dev-python/dj-search-url: Add this (indirect) Raven test dependency

dev-python/dj-email-url: Add this (indirect) Raven test dependency

dev-python/dj-database-url: Add this (indirect) Raven test dependency

dev-python/django-cache-url: Add this (indirect) Raven test dependency

Merge remote-tracking branch 'laurentb/dev-python/pytest-xdist'

Add DOCS and a missing Setuptools DEPEND.

I've dropped LICENSE from his DOCS because its content matches the
wording used by the Open Source Initiative [1].  It also matches the
wording used by the MIT license in the gentoo tree, although that one
has an additional:

  [Except as contained in this notice ...]

block at the end.

[1]: http://opensource.org/licenses/MIT

clean old python impls, add py3.3 3.4 support, add IUSE test and testrunner dep, upgrade test phase, fixes bug #524246 by W. T. King requesting added py3 support, rm old

Package-Manager: portage-2.2.10/cvs/Linux x86_64
Manifest-Sign-Key: 0xB8072B0D

execnet-1.2.0-r1.ebuild: Update python* entries in PYTHON_COMPAT

Python 2.6 is no longer in the tree, but 3.3 and 3.4 are.

I went with a revbump here (in contrast to bc861e9e, Add support for
the new PyPy slotting, 2014-03-31).  From the devmanual [1]:

  Ebuilds should have their -rX incremented whenever a change is made
  which will make a substantial difference to what gets installed by
  the package — by substantial, we generally mean "something for which
  many users would want to upgrade".

Whether or not the 2.6, 3.3, or 3.4 versions of the package are
installed for a given PYTHON_TARGETS seems like a substantial
difference to me ;).

I've also trimmed the Manifest, because my overlay uses thin, unsigned
manifests.  Feel free to re-thicken if you prefer.

I've also skipped the ChangeLog entry, because folks can just look at
is commit message.  Feel free to extract a ChangeLog entry from this
if you prefer.

[1]: http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

dev-python/pytest-xdist-9999.ebuild: Add this (indirect) Raven dependency

The tests currently fail due to a bug in Setuptools' egg-info handling
[1] which is only partially worked around in the distutils-r1 eclass
[2].

[1]: https://bitbucket.org/pypa/setuptools/pull-request/85/egg_info-search-egg-base-for-files-to-add/diff
[2]: https://bugs.gentoo.org/show_bug.cgi?id=524322

south-1.0: Package the 2014-07-01 release

South is now end-of-life [1]:

  Please note that South is now end of lifed in favour of the ​new
  migrations framework in Django 1.7, which is based on South but with
  significant design improvements. South will not work with Django
  1.7; it supports only versions 1.4, 1.5 and 1.6.

so I've limited compatibility to <dev-python/django-1.7.

I've also included a Python 3 compatibility patch (direct download
from [2]) which was merged into South's master branch with e2c9102
(Merged in gdub/south/python3-iteritems, pull request #162,
2014-08-01).  Without this patch, the Python 3 tests fail.  With it,
the tests pass, although a number are skipped and there are still some
odd messages on stderr like [3]:

  FATAL ERROR - The following SQL query failed: DROP TABLE "test_nonexistdeltable";
  The error was: no such table: test_nonexistdeltable

I've also trimmed the Manifest, because my overlay uses thin, unsigned
manifests.  Feel free to re-thicken if you prefer.

I've also skipped the ChangeLog entry, because folks can just look at
this commit message.  Feel free to extract a ChangeLog entry from this
if you prefer.

[1]: http://south.aeracode.org/
[2]: https://bitbucket.org/andrewgodwin/south/commits/3753b49ca9f3d34c94156622b380def245d88e80/raw/
[3]: http://south.aeracode.org/ticket/1256

Merge remote-tracking branch 'origin/dev-python/aiohttp'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/aiohttp
  $ git read-tree --prefix=dev-python/aiohttp/ -u origin/dev-python/aiohttp
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/asyncio'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/asyncio
  $ git read-tree --prefix=dev-python/asyncio/ -u origin/dev-python/asyncio
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/exam'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/exam
  $ git read-tree --prefix=dev-python/exam/ -u origin/dev-python/exam
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/thumbor-pexif'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/thumbor-pexif
  $ git read-tree --prefix=dev-python/thumbor-pexif/ -u origin/dev-python/thumbor-pexif
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/derpconf'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/derpconf
  $ git read-tree --prefix=dev-python/derpconf/ -u origin/dev-python/derpconf
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/pyvows'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/pyvows
  $ git read-tree --prefix=dev-python/pyvows/ -u origin/dev-python/pyvows
  $ git commit -v

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Merge remote-tracking branch 'origin/dev-python/preggy'

Pull in this per-package branch with a subtree merge [1]:

  $ git merge -s ours --no-commit origin/dev-python/preggy
  $ git read-tree --prefix=dev-python/preggy/ -u origin/dev-python/preggy
  $ git commit -av

so folks who aren't using a version of Layman that supports submodules
(currently everybody) can use this modular package.

[1]: https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

dev-python/aiohttp: Add this dev-python/raven test dependency

dev-python/asyncio: Add this backport from 3.4 to 3.3

dev-python/exam: Add this (indirect) thumbor test dependency

I've submitted the find_packages sed upstream [1].

[1]: https://github.com/Fluxx/exam/pull/39

dev-python/derpconf: Add this thumbor dependency

I've submitted the tornado-pyvows -> pyVows dependency change upstream
[1].  I don't know if the package itself is compatible with Python 3,
but the test suite isn't (because pyVows isn't) so I'm sticking with
2.7 in PYTHON_COMPAT.

[1]: https://github.com/globocom/derpconf/pull/11

dev-python/thumbor-pexif: Add this thumbor dependency

I've submitted the new homepage upstream [1].  This package is old,
and not Python 3 compatible, with stuff like:

  print >> sys.stderr, usage

[1]: https://github.com/thumbor/pexif/pull/1

pyvows-2.0.3.ebuild: Add a versioned package for tornado-pyvows

Which claims it requires pyvows <= 2.0.3.

pyvows-9999.ebuild: Fix 'pyvows' -> 'pyVows' for PyPI page

dev-python/tornado-pyvows: Add this (indirect) thumbor test dependency

I haven't tracked down the cause of the pyvows 2.0.5 breakage [1].

[1]: https://github.com/rafaelcaricio/tornado_pyvows/commit/1d264b963f36c77d5e109df946fe38cb2457fc7b
     1d264b96 (Pyvows 2.0.5 has broken tornado_pyvows, 2014-05-19)

dev-python/pyvows: Add this (indirect) thumbor test dependency

I've submitted the find_packages sed upstream [1].  I don't know if
the package itself is compatible with Python 3, but the test suite
isn't so I'm sticking with 2.7 in PYTHON_COMPAT [2].  The test suite
also depends on gevent, because the fallback VowsSequentialRunner is
broken [3].

[1]: https://github.com/heynemann/pyvows/pull/109
[2]: https://github.com/heynemann/pyvows/issues/110#issuecomment-57243488
[3]: https://github.com/heynemann/pyvows/issues/111

dev-python/preggy: Add this (indirect) thumbor test dependency

I've submitted the find_packages sed upstream [1].

[1]: https://github.com/heynemann/preggy/pull/18

dev-python/flask-cors-1.9.0: Bump to 1.9.0

Which was just released on Saturday [1] and fixes some tests on Python
3.4 [2] and improves coverage [3] among other thing.

[1]: https://github.com/wcdolphin/flask-cors/pull/77
[2]: https://github.com/wcdolphin/flask-cors/pull/74
[3]: https://github.com/wcdolphin/flask-cors/pull/75

pytest-xdist: Bump to 1.11

dev-python/flask-cors-1.8.1: Bump to 1.8.1

Which was just released [1] and now bundles tests/ [2].

[1]: https://github.com/wcdolphin/flask-cors/pull/72
[2]: https://github.com/wcdolphin/flask-cors/pull/71

dev-python/flask-cors: Use best_version instead of equery

To find the location of the installed python-docs.  Zero_Chaos suggested
the best_version approach on #gentoo-python just now.

The installed version of these docs may soon change, with the
python-docs package shifting to a per-slot naming scheme that more
closely matches the upstream Python naming scheme [1].

[1]: https://bugs.gentoo.org/show_bug.cgi?id=522794

Thanks-to: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>

dev-python/flask-cors: Only depend on the python-docs:2.7

PEP 430 says that links to Python docs without an explicit version are
implicitly requesting the latest 2.x release [1].

[1]: http://legacy.python.org/dev/peps/pep-0430/#don-t-break-useful-resources

dev-python/flask-cors: Drop ROOT and use stricter python-docs dependencies

We're not supposed to use ROOT in ebuild functions (see the discussion
in f3893ec9, dev-python/flask-cors/flask-cors-9999.ebuild: Use local
intersphinx, 2014-09-02).  I had been using it to build against the
objects.inv from that ROOT, but we're actually supposed to build
against the local (non-ROOT) copy [1]:

  ROOT isn't used for library dependencies. When building, libraries,
  headers etc. on / have to be used. Cross-compiling etc is done by
  configuring the toolchain correctly, not by hacking ebuilds in a way
  that breaks binary packages.

I'm also using equery to list the python-docs files (on /), to avoid
hard-coding /usr/share/doc"/python-docs-*/html.  equery knows what was
installed, and I really don't care where it is, so long as I can find
the objects.inv (and so long as that's the directory with the HTML
docs too).

Finally, the python-docs dependencies make sure we accept any of the
python-docs versions that install objects.inv [2].  Ian Delaney bumped
versions to -r1 so we could determine if objects.inv was installed,
and Ian Stakenvicius pointed out the slotted approach to the disjoint
dependency.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=258125#c0
[2]: https://bugs.gentoo.org/show_bug.cgi?id=521768

Thanks-to: Ian Delaney <idella4@gentoo.org>
Thanks-to: Ian Stakenvicius <axs@gentoo.org>

dev-python/flask-cors/flask-cors-9999.ebuild: Use local intersphinx

Gentoo's python-docs recently learned how to install objects.inv (with
the 2.7.6, 3.3.5, and 3.4.0 ebuilds, but without a revbump [1]).
Avoid the troublesome web access [2,3]:

  loading intersphinx inventory from http://docs.python.org/objects.inv...

Unfortunately, the approach to locating the local objects.inv is a bit
awkward.  Ideally there would be some sort of pkg-config approach to
listing a package's HTML doc directory :p, but until then the best I
can do is shell out to ls with an EROOT-based glob.  Using ROOT in
ebuild functions is illegal though [4] (and by extension, using it via
EROOT may be illegal as well).  Even if it was legal, you're going to
run into trouble if the python-docs dependency was installed with a
different ROOT, which is why I die if PYTHON_DOC is empty.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=521768
     Summary: dev-python/python-docs-3.4.0 doesn't install objects.inv
       for intersphinx
[2]: https://bugs.gentoo.org/show_bug.cgi?id=522064
     Summary: should explicitly disallow network access from existing
       ebuild functions
[3]: https://github.com/gentoo/devmanual.gentoo.org/pull/21
     Summary: ebuild-writing/functions: Don't allow network access
[4]: http://devmanual.gentoo.org/ebuild-writing/common-mistakes/#invalid-use-of-root

dev-python/flask-cors: Add this docker-registry dependency

dev-python/parse: Add this Fig dependency (via dockerpty and behave)

With a symlink to the most recent version (1.6.4, uploaded to PyPI on
2014-05-02) for folks who don't want a floating ebuild.

dev-python/texttable: Add this Fig dependency

I can't find a version control repository for texttable.  Gerome
Fournier seems to just post the most recent version of the module [1]
without linking to a repository [2].

[1]: http://foutaise.org/code/texttable/texttable
[2]: http://foutaise.org/code/

Remove Python 2.6 support

Bump package compatibility to Python 3.4

For all the Python-3-compatible packages:

* dev-python/ipython-irc
* dev-python/ipythonblocks
* dev-python/wheel
* dev-util/update-copyright
* net-proxy/package-cache

I've installed all of these locally with 3.4, and they seem to work.

net-proxy/package-cache: Strip trailing whitespace

dev-python/ipython-irc: Fix DESCRIPTION

I dunno where the previous value came from :p.

Update support to Python 3.4

Add support for the new PyPy slotting.

Package-Manager: portage-2.2.10/cvs/Linux x86_64
Manifest-Sign-Key: 0xEFB4464E!

Update pytest-xdist to 1.10

net-proxy/package-cache: Package my package-cache server

Version bump

Package-Manager: portage-2.2.8-r1/cvs/Linux i686
Manifest-Sign-Key: 0x3AFFCE974D34BD8C!

Remove unneeded versions.

Package-Manager: portage-2.2.8/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

arm stable, bug #450174

Package-Manager: portage-2.2.8/cvs/Linux x86_64
RepoMan-Options: --include-arches="arm"
Manifest-Sign-Key: 0x072AD062

Remove non-deterministic doctest, reported by maekke.

Package-Manager: portage-2.2.8/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

Fix tests.

Package-Manager: portage-2.2.8/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

Fix tests in 1.4.3-r1, and port changes to 2.0.11. Bug 484222.

Package-Manager: portage-2.2.8/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

Bump

Package-Manager: portage-2.2.8/cvs/Linux x86_64

app-crypt/monkeysphere: Remove now that it's in upstream Gentoo

With Kristian Fiskerstrand as the proxy maintainer [1].

https://bugs.gentoo.org/show_bug.cgi?id=313253#c13

dev-util/update-copyright: Update to Python 3 master branch

Also bump the ebuild to EAPI 5 and the distutils-r1 eclass.

Update pytest-xdist to 1.9

Also:
 * license change (to more permissive)
 * added version requirements

Revert last change and replace distutils-r1_python_test with distutils-r1_src_test.

Package-Manager: portage-2.2.7/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

Remove pointless src_test function.

Package-Manager: portage-2.2.7/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

Bump

Package-Manager: portage-2.2.7/cvs/Linux x86_64

Add missing PYTHON_REQUIRED_USE

Package-Manager: portage-2.2.7/cvs/Linux x86_64
Manifest-Sign-Key: 0xA188FBD4

Bump

Package-Manager: portage-2.2.7/cvs/Linux x86_64

Remove Python 2.5 and 3.1 support

Following Gentoo.

virtual/unfolding-disasters: Require app-text/itex2mml and perl-gcpan/MathML-Entities

We need these for compiling *.mdwn_itex pages.

updating 1.3.3 to distutils-r1 for openstack

Package-Manager: portage-2.1.12.2/cvs/Linux x86_64
Manifest-Sign-Key: 0x2471EB3E40AC5AC3

Clean up PYTHON_COMPAT from old implementations.

Package-Manager: portage-2.2.1/cvs/Linux x86_64
Manifest-Sign-Key: 0xEFB4464E!

Add missing deps.

Package-Manager: portage-2.2.1/cvs/Linux x86_64
Manifest-Sign-Key: 0x0BBEEA1FEA4843A4

Stable for sparc, wrt bug #450174

Package-Manager: portage-2.1.13.7/cvs/Linux x86_64
RepoMan-Options: --include-arches="sparc"
Manifest-Sign-Key: 0x7194459F