merge

.hgtags

@@ -58,3 +58,4 b' 656fe41c1965602997032e8d8d00d63b57b825d2'
 678b0342e43894511601306c2a660cc678a29411 1.1.8
 13ceb03ee4b3ba074ee0e12273559da2ba3ff50c 1.1.9
 42e1da83e6dde50e12e8708bee649e5291a42b58 1.2.0
+e01afc28bac525a133a6ff4fd59812333e4b756d 1.2.1

HISTORY.txt

@@ -1,3 +1,8 b''
+
+1.2.1
+~~~~~~~~~~~~
+
+Tested against hg 4.8 (no changes needed).
 
 1.2.0
 ~~~~~~~~~~~~
@@ -15,8 +20,6 b' handling (propts).'
 Refreshing smtp monkeypatch to be a bit more like modern mercurials
 (in particular, obligatory cert falidaton).
 
-
-
 1.1.9
 ~~~~~~~~~~~~
 

README.txt

@@ -367,12 +367,19 b' install some missing tool, or library, a'
 
 .. note::
 
-   Recent versions of keyring library (since version 12) use python
+   Depending on keyring_ version, installation of some dependency may
+   resolve problem. For example (as of late 2018), I got KDE Wallet
+   backend working with pip-installed keyring after::
+
+       pip install dbus-python
+
+   Note also, that recent versions of keyring library (since version 12) use Python
    entrypoints to find available backends. Those are incompatible with
    some binary packaging methods (like ``py2app``) and may cause
    problems. In particular there were packaged installations of TortoiseHG
    which were unable to load keyring backends. See `#61 <https://bitbucket.org/Mekk/mercurial_keyring/issues/61/tortoisehg-encounters-unknown-exception>`_ for some more details.
 
+
 If ``keyring`` command works, but mercurial with mercurial_keyring does not,
 try enforcing  proper backend (by means of ``keyringrc.cfg``, see above).
 Only if this doesn't help, there may be a bug in mercurial_keyring.
@@ -385,6 +392,7 b' keyring`` and looking for binary package'
 
 
 
+
 History
 =======================================================
 

setup.py

@@ -1,5 +1,5 b''
 
-VERSION = '1.2.0'
+VERSION = '1.2.1'
 
 # pylint: disable=unused-import