Re: RFS: python-keyring 1.4-1
Thanks for your review.
On Wed, Jun 12, 2013 at 2:34 AM, Sebastian Ramacher
<sramacher@debian.org> wrote:
> I'd put the script in /usr/share/doc/python-keyring or
> /usr/share/python-keyring. There's no need to put it in /usr/bin.
It's now in /usr/share/python-keyring.
> Also, I wouldn't copy the the master password from the old keyring to the
> new one. If the user already created a new Crypto keyring with a different
> password, this would destroy it. I'd also make it more explicit when asking
> for the password that it's the password for the old keyring.
Fixed.
>> Note that it fails to build when python3-secretstorage is installed
>> (see upstream #102), but there is no problem when you are building in
>> chroot.
>
> So either
> - get ImportKiller fixed,
> - disable ImportKiller based tests for Python 3.3 for now or
> - add python3-secretstorage and python3-gi to Build-Conflicts.
ImportKiller is fixed now.
> What's the status of all the other tests? Many tests are skipped because
> of missing dependencies.
Gnome-keyring-daemon refuses to run in xvfb. As I do not know other
Secret Service implementations, it's currently impossible to test
GNOME and Secret Service backends (libsecret's upstream testsuite has
some code for mocking Secret Service, but I didn't yet have time to
test it).
Python-fs is too old in Debian (python-keyring needs at least 0.4), so
this test can't be run also.
> The version from PyPI is versioned as 1.4. The version from bitbucket as
> 1.4dev. 1.4dev is not PEP 386 compatible version and breaks anything
> having a requirment on keyring >= 1.4 in setup.py or using
> pkg_resources.require
OK, I reverted the debian/watch change, so we can now use .zip tarballs again.
--
Dmitry Shachnev
Reply to: