Created attachment 166783 [details] security/py27-keyring-8.3.diff Update security/py-keyring to 8.3. Since version 8.0, they have split some of the backends into a separate package so I have made a port for that as well (security/py-keyrings.atl, which I will attach here as well). There probably needs to be an UPDATING message about this. For security/py-keyring "portlint -C" reports "looks fine." For security/py-keyrings.alt "portlint -A" reports "looks fine." I will attach the "poudriere testport" logs for both. --- 8.3 --- * Issue #207: Library now requires win32ctypes on Windows systems, which will be installed automatically by Setuptools 0.7 or Pip 6 (or later). * Actually removed QtKwallet, which was meant to be dropped in 8.0 but somehow remained. --- 8.2 --- * Update readme to include how-to use with Linux non-graphical environments. --- 8.1 --- * Issue #197: Add ``__version__`` attribute to keyring module. --- 8.0 --- * Issue #117: Removed all but the preferred keyring backends for each of the major desktop platforms: - keyring.backends.kwallet.DBusKeyring - keyring.backends.OS_X.Keyring - keyring.backends.SecretService.Keyring - keyring.backends.Windows.WinVaultKeyring All other keyrings have been moved to a new package, `keyrings.alt <https://pypi.python.org/pypi/keyrings.alt>`_ and backward-compatibility aliases removed. To retain availability of these less preferred keyrings, include that package in your installation (install both keyring and keyrings.alt). As these keyrings have moved, any keyrings indicated explicitly in configuration will need to be updated to replace "keyring.backends." with "keyrings.alt.". For example, "keyring.backends.file.PlaintextKeyring" becomes "keyrings.alt.file.PlaintextKeyring". ----- 7.3.1 ----- * Issue #194: Redirect away from docs until they have something more than the changelog. Users seeking the changelog will want to follow the `direct link <https://pythonhosted.org/keyring/history.html>`_. --- 7.3 --- * Issue #117: Added support for filtering which backends are acceptable. To limit to only loading recommended keyrings (those with priority >= 1), call:: keyring.core.init_backend(limit=keyring.core.recommended) --- 7.2 --- * Pull Request #190: OS X backend now exposes a ``keychain`` attribute, which if set will be used by ``get_password`` when retrieving passwords. Useful in environments such as when running under cron where the default keychain is not the same as the default keychain in a login session. Example usage:: keyring.get_keyring().keychain = '/path/to/login.keychain' pw = keyring.get_password(...) --- 7.1 --- * Issue #186: Removed preference for keyrings based on ``XDG_CURRENT_DESKTOP`` as these values are to varied to be a reliable indicator of which keyring implementation might be preferable. ----- 7.0.2 ----- * Issue #187: Restore ``Keyring`` name in ``kwallet`` backend. Users of keyring 6.1 or later should prefer an explicit reference to DBusKeyring or QtKeyring instead. ----- 7.0.1 ----- * Issue #183 and Issue #185: Gnome keyring no longer relies on environment variables, but instead relies on the GnomeKeyring library to determine viability.
Created attachment 166784 [details] security/py-keyrings.alt.shar Here is the shar for security/py-keyrings.alt.
Created attachment 166785 [details] logs/py27-keyring-8.3.log Here is the poudriere testport log for security/py-keyring.
Created attachment 166786 [details] logs/py27-keyrings.alt-1.1.log Here is the poudriere testport log for security/py-keyrings.alt.
Thanks Douglas! Can you please create a separate issue for the NEW PORT that blocks this issue please. If py-keyrings depends on keyring.alt by default, is there still a need for an UPDATING entry?
Okay, I will create a new PR for security/py-keyrings.alt. I don't think I can make security/py-keyring depend on it since that would create a circular dependency as I have it right now, but maybe I can switch that around?
(In reply to douglas from comment #5) keyrings.alt doesn't appear to "require" keyrings: https://github.com/jaraco/keyrings.alt/blob/master/setup.py#L48 In this case we could look to creating an OPTION and add it to OPTIONS_DEFAULT to retain the existing behaviour/implementations (if that indeed does keep the current behaviour), which precludes needing an UPDATING entry
Yep, already figuring that part out. Regarding the UPDATING thing though there is this part from CHANGES.rst: As these keyrings have moved, any keyrings indicated explicitly in configuration will need to be updated to replace "keyring.backends." with "keyrings.alt.". For example, "keyring.backends.file.PlaintextKeyring" becomes "keyrings.alt.file.PlaintextKeyring". It seems like we could have the OPTIONS_DEFAULT as well as a note about changing any configuration.
Created attachment 166789 [details] security/py27-keyring-8.3.diff I have updated the patch so keyring now has a default option to depend on security/py-keyrings.alt which I have made a separate PR for.
Created attachment 166790 [details] logs/py27-keyring-8.3.log Here is the poudriere testport log for the updated diff.
Take
A commit references this bug: Author: rm Date: Fri Feb 12 21:05:59 UTC 2016 New revision: 408763 URL: https://svnweb.freebsd.org/changeset/ports/408763 Log: security/py-keyring: update to 8.3 - update to 8.3 Since version 8.0, they have split some of the backends into a separate package (security/py-keyrings.alt), so change this port options accordingly. PR: 207044 Submitted by: Douglas Thrift <douglas@douglasthrift.net> (maintainer) Changes: head/security/py-keyring/Makefile head/security/py-keyring/distinfo
Committed, thank you!