Description of problem: When trying to use bash completion as a standard user, the command always freezes for me and I have to kill it with Ctrl+C. I debugged it and found the cause. It's related to certain third-party repos I have installed. My example command is "dnf install bzfla[TAB]". I used "set -x" in terminal first and then tried to complete the command. It showed executing this command: +++ /usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install bzfla -d 0 -q -C When I execute it manually, it shows this: $ /usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install bzfla -d 0 -q -C Is this ok [y/N]: Aha, so it's actually waiting for input! It shouldn't do that. If I reply: $ /usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install bzfla -d 0 -q -C Is this ok [y/N]: n bzflag-maps-sample-2.4.14-2.fc29.noarch bzflag-2.4.14-2.fc29.x86_64 I get the results. Looking in the source code, the request comes from `def userconfirm()` called by `class CliKeyImport` inside /usr/lib/python3.7/site-packages/dnf/cli/output.py . After more debugging, it's related to my /etc/yum.repos.d/atom.repo with this contents: [Atom] name=Atom Editor baseurl=https://packagecloud.io/AtomEditor/atom/el/7/$basearch enabled=1 gpgcheck=0 repo_gpgcheck=1 gpgkey=https://packagecloud.io/AtomEditor/atom/gpgkey When I disable it, my problems go away, dnf now autocompletes. Another solution is to edit and add "--assumeno" into `_dnf_show_packages()` in /usr/share/bash-completion/completions/dnf. That's probably the right thing to do and it should be there by default. The weird thing is, I already accepted the key as root for that repo, so it's clearly not considering that key. I also ran "dnf repolist" as the standard user and it asked for key confirmation once more (I'm not sure whether this is correct, when root already accepted that key), but I confirmed it once more (subsequent repolist runs don't ask for further confirmation). But dnf autocompletion still gets stuck! So it's ignoring both root keys and user keys, and that's probably yet another bug. If this is only fixed by adding "--assumeno" as mentioned above, I guess it wouldn't still autocomplete packages from that Atom repo. There is probably one more bug to resolve in there, regarding confirmed keys for a repo. Version-Release number of selected component (if applicable): dnf-3.3.0-2.fc29.noarch How reproducible: always, I think Steps to Reproduce: 1. add the repo above 2. run `dnf install packag[TAB]`
Having a same bug, sudo dnf install firefox[TAB], freeze.
Yes, still present with dnf-4.0.4-2.fc29.noarch
I had this problem, after running `/usr/libexec/system-python -c 'import sys; from dnf.cli import completion_helper as ch;ch.main(sys.argv[1:])' install lyn -d 0 -C` (please note the removal of `-q` ) i get this error message: ``` Google Cloud SDK 1.7 kB/s | 1.8 kB 00:01 Importing GPG key 0xA7317B0F: Userid : "Google Cloud Packages Automatic Signing Key <gc-team>" Fingerprint: D0BC 747F D8CA F711 7500 D6FA 3746 C208 A731 7B0F From : https://packages.cloud.google.com/yum/doc/yum-key.gpg Is this ok [y/N]: y ``` I guess that it is a bug that auto-complete hangs rather than ignoring updates or exit with an error but the actual problem seems to be with one or more repos. I do NOT have this problem if i use `sudo -u` and then run `rpm install lynx<TAB>`. It seems as if this file `/var/cache/dnf/google-cloud-sdk-2367166c9fd8d791/pubring/trustdb.gpg` is only readable by root. I guess that this is an issue in googles packaging for RPM. It works for normal users after running `sudo chmod +r /var/cache/dnf/google-cloud-sdk-2367166c9fd8d791/pubring/trustdb.gpg` but since i am not quite sure of DNFs security model I can not recommend this solution (it might be OK i just dont know so i can't recommend it)
Addendum: If I had read the Original Post more carefully I would have realized that it was due to GPG errors on some repos but at least I figured out that it was some kind of permissions problem (in my case).
This has been the case for me as well since Fedora 28. This is a rather frustrating bug depriving me of package name completion. Happens every time with `dnf install *<TAB>`
Same problem here since Fedora 29 (clean install). My custom repos do not include Atom, but I do have some.
Thank you Simon for the tip about permissions on GPG files. In my case it was $ sudo find /var/cache/dnf/ -name "*.gpg" /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gp $ ls -l /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg -rw-------. 1 root root 1200 Nov 2 14:04 /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg Aha! chmod go+r $ ls -l /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg and the problem went away. Open H264 is included in base Fedora 29 install as far as I remember. It's the only repository on my machine (in /etc/yum.repos.d) which has "repo_gpgcheck=1" (all the others have "...=0"). So maybe that's a workaround until the bugs are fixed, setting repo_gpgcheck=0. In terms of fixing I think there are two takeaways here: 1 - If the gpg file's permissions are controlled by the repository itself - then they need to be fixed there, should I be filing a separate bug? But most likely the .gpg file is created by dnf? 2 - If the gpg file is not readable, can dnf autocompletion be made to not hang like this?
The above comment hits the nail on the head. But doesn't quite cover all the files. ``` $ sudo find /var/cache/dnf/ -iname "*.gpg" -exec ls -l {} \; -rw-------. 1 root root 1200 Nov 3 16:27 /var/cache/dnf/fedora-cisco-openh264-debuginfo-faf9c4e066239216/pubring/trustdb.gpg -rw-------. 1 root root 1200 Nov 1 00:12 /var/cache/dnf/fedora-cisco-openh264-3bbe8a0adcce9aa5/pubring/trustdb.gpg ``` That's the default repos with fedora with incorrect perms. So, running this should fix it up. `sudo find /var/cache/dnf/ -iname "*.gpg" -exec chmod go+r {} \;` And I also agree that if the gpg file is not readable `dnf` autocomplete should still work with the ones it can read, while displaying a warning on stderr which files aren't readable.
> while displaying a warning on stderr which files aren't readable Please "no" on this one. A repo with gpg enabled should "just work".
This bug is still present in Fedora 30, with dnf-0:4.2.5-2.fc30.
*** Bug 1648686 has been marked as a duplicate of this bug. ***
*** Bug 1674432 has been marked as a duplicate of this bug. ***
One fast workaround I found is: -Symlinking /usr/bin/dnf to /usr/bin/yum (as Fedora doesn't have yum installed by default). -Then use the yum command instead. Works in CentOS 8, RHEL 8 and Fedora 31 Beta with Sat 19 Oct 2019 "non testing" updates. This is more than likely a bash-completion related problem with how the dnf completions are written, rather than permissions with new repos.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I still have the same extra repo in comment 0, and I have root-only readable cache files: $ ll /var/cache/dnf/Atom-e10748eea27cca31/pubring/trustdb.gpg -rw-------. 1 root root 1.2k Aug 21 2018 /var/cache/dnf/Atom-e10748eea27cca31/pubring/trustdb.gpg But the package name completion now works for me. Perhaps it was fixed recently? dnf-4.2.11-2.fc30.noarch
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.