See my upstream report of this issue: https://github.com/jaraco/keyring/issues/727 It seems that the generated ZSH completion files are invalid. Even though the version in F42/F43 seems to be the same, the completion files for ZSH are different. Reproducible: Always
Looking at the exact differences in the completion scripts between Fedora 42 and 43, I think that this can be fixed by using a slightly different technique for generating them during the RPM build. I will follow up after I investigate further.
Can you help me figure out what packages I need to install in a Fedora 43 mock chroot in order to reproduce this? I would like to be able to test a proposed fix. I tried: $ mock -r fedora-43-aarch64 -i python3-keyring+completion zsh $ mock -r fedora-43-aarch64 --shell <mock-chroot> sh-5.3# zsh <mock-chroot> \s-\v\$ python3 <tab> but this just completes with <mock-chroot> \s-\v\$ python3 build/
According to https://github.com/jaraco/keyring/issues/703 the version we currently have in F42 is also invalid, but it does not affect python3.
(In reply to Lumír Balhar from comment #3) > According to https://github.com/jaraco/keyring/issues/703 the version we > currently have in F42 is also invalid, but it does not affect python3. Indeed, the difference between F42 and F43 is --- /var/lib/mock/fedora-42-aarch64/root/usr/share/zsh/site-functions/_keyring 2025-01-18 00:00:00.000000000 +0000 +++ /var/lib/mock/fedora-43-aarch64/root/usr/share/zsh/site-functions/_keyring 2025-09-19 01:00:00.000000000 +0100 @@ -1,16 +1,16 @@ -#compdef __main__.py +#compdef python3 -m keyring # AUTOMATICALLY GENERATED by `shtab` -_shtab___main___py_commands() { +_shtab_python3__m_keyring_commands() { local _commands=( ) - _describe '__main__.py commands' _commands + _describe 'python3 -m keyring commands' _commands } -_shtab___main___py_options=( +_shtab_python3__m_keyring_options=( "(- : *)"{-h,--help}"[show this help message and exit]" {-p,--keyring-path}"[Path to the keyring backend]:keyring_path:_files -/" {-b,--keyring-backend}"[Name of the keyring backend]:keyring_backend:backend_complete" @@ -35,19 +35,19 @@ ) -_shtab___main___py() { +_shtab_python3__m_keyring() { local context state line curcontext="$curcontext" one_or_more='(-)*' remainder='(*)' - if ((${_shtab___main___py_options[(I)${(q)one_or_more}*]} + ${_shtab___main___py_options[(I)${(q)remainder}*]} == 0)); then # noqa: E501 - _shtab___main___py_options+=(': :_shtab___main___py_commands' '*::: :->__main__.py') + if ((${_shtab_python3__m_keyring_options[(I)${(q)one_or_more}*]} + ${_shtab_python3__m_keyring_options[(I)${(q)remainder}*]} == 0)); then # noqa: E501 + _shtab_python3__m_keyring_options+=(': :_shtab_python3__m_keyring_commands' '*::: :->python3 -m keyring') fi - _arguments -C -s $_shtab___main___py_options + _arguments -C -s $_shtab_python3__m_keyring_options case $state in - __main__.py) + python3 -m keyring) words=($line[1] "${words[@]}") (( CURRENT += 1 )) - curcontext="${curcontext%:*:*}:_shtab___main___py-$line[1]:" + curcontext="${curcontext%:*:*}:_shtab_python3__m_keyring-$line[1]:" case $line[1] in esac @@ -77,9 +77,9 @@ if [[ $zsh_eval_context[-1] == eval ]]; then # eval/source/. command, register function for later - compdef _shtab___main___py -N __main__.py + compdef _shtab_python3__m_keyring -N python3 -m keyring else # autoload from fpath, call function directly - _shtab___main___py "$@" + _shtab_python3__m_keyring "$@" fi Currently, I generate the completions in %build with for sh in bash zsh tcsh do PYTHONPATH="${PWD}/build/lib" '%{python3}' -m keyring \ --print-completion "${sh}" | tee "keyring.${sh}" done I suspect that the fix will be to generate them in %install, using the generated entry point with the proper "keyring" name, something like: for sh in bash zsh tcsh do %{py3_test_envvars} keyring --print-completion "${sh}" | tee "keyring.${sh}" done …but I do want to be able to test this properly before shipping updates.
I'm able to reproduce the issue with the following commands in a fresh container with Fedora rawhide: $ podman run --rm -it fedora:rawhide # dnf install -y python3-keyring+completion zsh # zsh -f # autoload -U compinit; compinit # python3 _keyring:47: parse error near `-m'
(In reply to Lumír Balhar from comment #5) > I'm able to reproduce the issue with the following commands in a fresh > container with Fedora rawhide: Thank you, that works for me as well. I always forget about the compinit dance. It looks like, with the change I suggested above: - the correct command name "keyring" appears in the completions file - zsh completions for python3 are no longer broken - zsh, tcsh, and bash completions for the keyring command work properly with keyring-specific suggestions I think that this change can only help, not hurt, even in branches where no problems have been reported, so I’ll plan to ship it in all branches.
https://src.fedoraproject.org/rpms/python-keyring/pull-request/32
FEDORA-2025-dd899b531d (python-keyring-25.6.0-13.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-dd899b531d
FEDORA-2025-0e67b91192 (python-keyring-25.6.0-13.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-0e67b91192
FEDORA-2025-dd899b531d (python-keyring-25.6.0-13.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-2e37b571ff (python-keyring-25.6.0-13.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-2e37b571ff
FEDORA-2025-ab9cdd5847 (python-keyring-25.6.0-13.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-ab9cdd5847
FEDORA-EPEL-2025-1a36185859 (python-keyring-25.6.0-8.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-1a36185859
FEDORA-EPEL-2025-c604f3aaa4 (python-keyring-25.6.0-8.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-c604f3aaa4
FEDORA-2025-0e67b91192 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-0e67b91192` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-0e67b91192 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-2e37b571ff has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-2e37b571ff` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-2e37b571ff See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-c604f3aaa4 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-c604f3aaa4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-1a36185859 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-1a36185859 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-ab9cdd5847 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-ab9cdd5847` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-ab9cdd5847 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-0e67b91192 (python-keyring-25.6.0-13.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-2e37b571ff (python-keyring-25.6.0-13.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-1a36185859 (python-keyring-25.6.0-8.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-ab9cdd5847 (python-keyring-25.6.0-13.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-c604f3aaa4 (python-keyring-25.6.0-8.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.