Description of problem: The org.freedesktop.reportd service used to emit a Prompt signal on a Task object that runs reporter-bugzilla when a password was required. This no longer happens and the Task gets stuck waiting for input that nobody will provide. Version-Release number of selected component (if applicable): libreport-plugin-bugzilla-2.17.6-2.fc38.x86_64 How reproducible: Always Steps to Reproduce: 1. Run the TestJournal-testAbrtReport test of the Cockpit CI suite. I can try to provide more concrete steps if necessary. Actual results: Cockpit receives these Progress signals during the test but no Prompt signal PROGRESS /usr/lib64/python3.11/getpass.py:91: GetPassWarning: Can not control echo on the terminal. PROGRESS passwd = fallback_getpass(prompt, stream) PROGRESS Warning: Password input may be echoed. Expected results: With libreport-plugin-bugzilla-2.17.4-1.fc37.x86_64 on Fedora 37, Cockpit sees two Prompt signals and no Progress signals: PROMPT 4 (ASK_PASSWORD) PROMPT 1 (ASK_YES_NO)
I see that /usr/bin/reporter-bugzilla is now a Python program that just calls getpass, while it used to be a C program that uses libreport_ask_password. The latter presumably does the right thing to cause reportd to emit the expected Prompt signal. Did someone accidentally replace the C version of reporter-bugzilla with the Python version? :)
This wasn't by accident -- Python version was the default implementation in Rawhide since August 2022 :) This looks like a regression, we will take a look. Thanks for the bug report!
> 1. Run the TestJournal-testAbrtReport test of the Cockpit CI suite. I can try to provide more concrete steps if necessary. It would be really helpful -- could you please share those more concrete steps? . I think the fix should be trivial, but I am kinda surprised that nobody hit this problem up until now. Thanks!
> but I am kinda surprised that nobody hit this problem up until now. I would expect this test case to hit it: https://fedoraproject.org/wiki/QA:Testcase_ABRT_Desktop_auto-reporting Is that something you can try easily? I'll see if I can come up with a way to reproduce this in the CLI, via busctl etc.
(In reply to Marius Vollmer from comment #4) > > but I am kinda surprised that nobody hit this problem up until now. > > I would expect this test case to hit it: > https://fedoraproject.org/wiki/QA:Testcase_ABRT_Desktop_auto-reporting Or some variation of it. I am not familiar with these tests...
> I would expect this test case to hit it: https://fedoraproject.org/wiki/QA:Testcase_ABRT_Desktop_auto-reporting Is that something you can try easily? It doesn't. It uses a completely different path. In your case, you're trying to use ABRT via DBus/reportd. Which is definitely rare. If we come up with a scratch build in Koji, would it be possible for you to test it in your CI?
Actually, even better: do you, by any chance, have a tmt plan that we could run ourselves? :)
Created attachment 1946688 [details] Reproducer
(In reply to Michal Srb from comment #6) > In your case, you're trying to use ABRT via DBus/reportd. Which is definitely rare. Oh, I wasn't aware that this is rare. Should Cockpit move to a different API? I have attached a little Python program that reproduces the bug for me.
(In reply to Michal Srb from comment #7) > Actually, even better: do you, by any chance, have a tmt plan that we could > run ourselves? :) Not right now, but this bug report triggered me to work on it. See https://github.com/cockpit-project/cockpit/pull/18437 . That is just hilariously uncooperative -- installing ABRT packages into a running TMT machine without a reboot just simply refuses to pick up a crash. In our own CI (where the cockpit ABRT tests run), it is pre-installed into our test VMs, and after a reboot it works. With a local `tmt run` in a VM it also works, just not in the TF EC2 instances. Perhaps you have an idea what goes wrong there.
Michal: OK, I got the PR working. On Fedora 37, both tests pass: https://artifacts.dev.testing-farm.io/29329487-59b5-4d43-ba60-9da57062af84/ On F38 and F39 the TestJournal.testAbrtReport test fails due to this bug: https://artifacts.dev.testing-farm.io/f60ae1a8-ce74-4499-a67d-bba3f545f4c1/ . The other test TestJournal.testAbrtSegv passes. So once that PR lands (hopefully today), you should be able to trigger the "basic" plan of cockpit's TMT tests.
Thank you both! :) I think I have a fix here: https://github.com/abrt/libreport/pull/781 -- I used the reproducer from Marius to verify that libreport should be doing the right thing now. Once the team reviews the pull request, I will let packit to push an update to Fedora. So hopefully it will land later today.
FEDORA-2023-b5eeeb9670 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b5eeeb9670
(In reply to Michal Srb from comment #12) > Thank you both! :) > > I think I have a fix here: https://github.com/abrt/libreport/pull/781 -- I > used the reproducer from Marius to verify that libreport should be doing the > right thing now. > > Once the team reviews the pull request, I will let packit to push an update > to Fedora. So hopefully it will land later today. https://github.com/abrt/libreport/pull/781 makes our TestJournal.testAbrtReport pass. Thanks!
FEDORA-2023-b5eeeb9670 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b5eeeb9670 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-b5eeeb9670 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.