Upgrade security/py-keyring to 3.2.1 and add PYDISTUTILS_AUTOPLIST and STAGE
support.

https://redports.org/buildarchive/20131124231600-59585/

From CHANGES.rst:

-----
3.2.1
-----

* SecretService backend: use a different function to check that the
  backend is functional. The default collection may not exist, but
  the collection will remain usable in that case.

  Also, make the error message more verbose.

  Resolves https://bugs.launchpad.net/bugs/1242412.

---
3.2
---

* Issue #120: Invoke KeyringBackend.priority during load_keyring to ensure
  that any keyring loaded is actually viable (or raises an informative
  exception).

* File keyring:

   - Issue #123: fix removing items.
   - Correctly escape item name when removing.
   - Use with statement when working with files.

* Add a test for removing one item in group.

* Issue #81: Added experimental support for third-party backends. See
  `keyring.core._load_library_extensions` for information on supplying
  a third-party backend.

---
3.1
---

* All code now runs natively on both Python 2 and Python 3, no 2to3 conversion
  is required.
* Testsuite: clean up, and make more use of unittest2 methods.

-----
3.0.5
-----

* Issue #114: Fix logic in pyfs detection.

-----
3.0.4
-----

* Issue #114: Fix detection of pyfs under Mercurial Demand Import.

-----
3.0.3
-----

* Simplified the implementation of ``keyring.core.load_keyring``. It now uses
  ``__import__`` instead of loading modules explicitly. The ``keyring_path``
  parameter to ``load_keyring`` is now deprecated. Callers should instead
  ensure their module is available on ``sys.path`` before calling
  ``load_keyring``. Keyring still honors ``keyring-path``. This change fixes
  Issue #113 in which the explicit module loading of keyring modules was
  breaking package-relative imports.

-----
3.0.2
-----

* Renamed ``keyring.util.platform`` to ``keyring.util.platform_``. As reported
  in Issue #112 and `mercurial_keyring #31
  <https://bitbucket.org/Mekk/mercurial_keyring/issue/31>`_ and in `Mercurial
  itself <http://bz.selenic.com/show_bug.cgi?id=4029>`_, Mercurial's Demand
  Import does not honor ``absolute_import`` directives, so it's not possible
  to have a module with the same name as another top-level module. A patch is
  in place to fix this issue upstream, but to support older Mercurial
  versions, this patch will remain for some time.

-----
3.0.1
-----

* Ensure that modules are actually imported even in Mercurial's Demand Import
  environment.

---
3.0
---

* Removed support for Python 2.5.
* Removed names in ``keyring.backend`` moved in 1.1 and previously retained
  for compatibilty.

-----
2.1.1
-----

* Restored Python 2.5 compatibility (lost in 2.0).

---
2.1
---

*  Issue #10: Added a 'store' attribute to the OS X Keyring, enabling custom
   instances of the KeyringBackend to use another store, such as the
   'internet' store. For example::

       keys = keyring.backends.OS_X.Keyring()
       keys.store = 'internet'
       keys.set_password(system, user, password)
       keys.get_password(system, user)

   The default for all instances can be set in the class::

       keyring.backends.OS_X.Keyring.store = 'internet'

*  GnomeKeyring: fix availability checks, and make sure the warning
   message from pygobject is not printed.

*  Fixes to GnomeKeyring and SecretService tests.

-----
2.0.3
-----

*  Issue #112: Backend viability/priority checks now are more aggressive about
   module presence checking, requesting ``__name__`` from imported modules to
   force the demand importer to actually attempt the import.

-----
2.0.2
-----

*  Issue #111: Windows backend isn't viable on non-Windows platforms.

-----
2.0.1
-----

*  Issue #110: Fix issues with ``Windows.RegistryKeyring``.

---
2.0
---

*  Prioritized backend support. The primary interface for Keyring backend
   classes has been refactored to now emit a 'priority' based on the current
   environment (operating system, libraries available, etc). These priorities
   provide an indication of the applicability of that backend for the current
   environment. Users are still welcome to specify a particular backend in
   configuration, but the default behavior should now be to select the most
   appropriate backend by default.