Needed for ddupdate.
See https://tdawson.fedorapeople.org/epel/willit/epel10/status-wont-install.html

Well, there is a missing test dependency on python3dist(pyfakefs), but it looks like its use in the tests is very minimal. I’m investigating whether conditionalizing that test dependency is enough to unblock this package for EPEL10.

I have conditionalized the dependency on python3dist(pyfakefs) in Rawhide. Now:

$ fedpkg --release epel10 mockbuild -- --postinstall
[…]
No matching package to install: 'python3dist(jaraco-classes)'
No matching package to install: 'python3dist(jaraco-context)'
No matching package to install: 'python3dist(jaraco-functools)'
[…]
No matching package to install: 'python3dist(jeepney) >= 0.4.2'
[…]
No matching package to install: 'python3dist(secretstorage) >= 3.2'
[…]
No matching package to install: 'python3dist(shtab) >= 1.1'

Once all of these dependencies are available in EPEL10, I will be happy to branch, build, and maintain python-keyring there. However, someone who cares about keeping ddupdate in EPEL10 would need to handle actually requesting the dependencies (and any dependencies they might have, and so on).

The remaining missing dependencies in EPEL10 are:

No matching package to install: 'python3dist(jeepney) >= 0.4.2'
No matching package to install: 'python3dist(secretstorage) >= 3.2'
No matching package to install: 'python3dist(shtab) >= 1.1'

Again, I’m happy to maintain this package in EPEL10, but I’m not interested in requesting or maintaining its dependencies myself.

Checking right now, it seems we miss this:

No matching package to install: 'python3dist(jeepney) >= 0.4.2'
No matching package to install: 'python3dist(secretstorage) >= 3.2'

With python-secretstorage which is for now in testing, this package can now be built but... the tests fail on EPEL 10...

There are two issues:
 - The tests inside test_multiprocess.py are deadlocked. These tests are actually marked as xfail upstream, so I am not sure it's actually ok to just skip them with something like:

%if 0%{?el10}
k="${k-}${k+ and }not test_multiprocess.py"
%endif

  - The libsecret tests seems to fail with errors like:

__________________ TestLibSecretKeyring.test_password_set_get __________________

self = <tests.backends.test_libsecret.TestLibSecretKeyring object at 0x7fcb87ada570>
    
    def test_password_set_get(self):
        password = random_string(20)
        username = random_string(20)
        service = random_string(20)
>       self.check_set_get(service, username, password)

keyring/testing/backend.py:71:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
keyring/testing/backend.py:60: in check_set_get
    self.set_password(service, username, password)
keyring/testing/backend.py:50: in set_password
    self.keyring.set_password(service, username, password)
keyring/backend.py:60: in wrapper 
    return orig(self, system, username, *args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <keyring.backends.libsecret.Keyring object at 0x7fcb858fa4b0>
service = 'lRopHVQ7YMSflc0PLfup', username = 'IprHAxnOQDsI3qy3q1p4'
password = 'KUCxDGnHc9EuektcAc0E'   

    def set_password(self, service, username, password):
        """Set password for the username of the service"""
        attributes = self._query(service, username, application=self.appid)
        label = f"Password for '{username}' on '{service}'"
        try:
>           stored = Secret.password_store_sync(
                self.schema, attributes, self.collection, label, password, None
            )
E           gi.repository.GLib.GError: g-dbus-error-quark: Couldn't create item: The secret was transferred or encrypted in an invalid way. (0)

keyring/backends/libsecret.py:88: Error
---------------------------- Captured stdout setup -----------------------------
Testing LibSecretKeyring; the following password prompts are for this keyring

Also note that pyfakefs is now available in EPEL 10.

I’m investigating.

FEDORA-EPEL-2025-62c2a1bbc0 (python-keyring-25.6.0-4.el10_1) has been submitted as an update to Fedora EPEL 10.1.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-62c2a1bbc0

FEDORA-EPEL-2025-62c2a1bbc0 has been pushed to the Fedora EPEL 10.1 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-62c2a1bbc0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2025-62c2a1bbc0 (python-keyring-25.6.0-4.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository.
If problem still persists, please make note of it in this bug report.