Description of problem: In F42, gnome-abrt has a new UI design. Unfortunately, there's no button to open ABRT settings. This then leads to inability to adjust Bugzilla apikey, when it eventually changes. For the first reported bug, ABRT asks for the bugzilla apikey. This works. However, if the user wants or needs to change the apikey at a later time, it's not possible, there's no way to open abrt settings. Also, once the apikey is invalid/expired, the next bug report simply fails with an error like this one: --- Running report_Bugzilla --- Checking for duplicates Bug search failed. Server says: 400 Bad Request Creating a new bug... Failed to create bug. Server says: 400 Bad Request {"error":true,"message":"The API key you specified has been revoked by the user that created it.","code":306,"documentation":"https://bugzilla.redhat.com/docs/en/html/api/index.html"} ('report_Bugzilla' exited with 1) It does not ask user for a new apikey, and it doesn't give any option to the user to change it. Once this happens, no new bugs can be reported. Version-Release number of selected component (if applicable): abrt-2.17.6-4.fc42.x86_64 abrt-addon-ccpp-2.17.6-4.fc42.x86_64 abrt-addon-kerneloops-2.17.6-4.fc42.x86_64 abrt-addon-pstoreoops-2.17.6-4.fc42.x86_64 abrt-addon-vmcore-2.17.6-4.fc42.x86_64 abrt-addon-xorg-2.17.6-4.fc42.x86_64 abrt-cli-2.17.6-4.fc42.x86_64 abrt-dbus-2.17.6-4.fc42.x86_64 abrt-desktop-2.17.6-4.fc42.x86_64 abrt-gui-2.17.6-4.fc42.x86_64 abrt-gui-libs-2.17.6-4.fc42.x86_64 abrt-libs-2.17.6-4.fc42.x86_64 abrt-plugin-bodhi-2.17.6-4.fc42.x86_64 abrt-tui-2.17.6-4.fc42.noarch gnome-abrt-1.5.0-2.fc42.x86_64 libreport-2.17.15-5.fc42.x86_64 libreport-anaconda-2.17.15-5.fc42.x86_64 libreport-cli-2.17.15-5.fc42.x86_64 libreport-fedora-2.17.15-5.fc42.x86_64 libreport-filesystem-2.17.15-5.fc42.noarch libreport-gtk-2.17.15-5.fc42.x86_64 libreport-plugin-bugzilla-2.17.15-5.fc42.x86_64 libreport-plugin-kerneloops-2.17.15-5.fc42.x86_64 libreport-plugin-logger-2.17.15-5.fc42.x86_64 libreport-plugin-reportuploader-2.17.15-5.fc42.x86_64 libreport-plugin-systemd-journal-2.17.15-5.fc42.x86_64 libreport-plugin-ureport-2.17.15-5.fc42.x86_64 libreport-web-2.17.15-5.fc42.x86_64 python3-abrt-2.17.6-4.fc42.x86_64 python3-abrt-addon-2.17.6-4.fc42.noarch python3-libreport-2.17.15-5.fc42.x86_64 How reproducible: always Steps to Reproduce: 1. report bug number 1 using apikey1 2. revoke apikey1 3. try to report bug number 2 4. fails because of apikey1 being revoked 5. can't change apikey1 to apikey2 anywhere
Upstream bug: https://github.com/abrt/gnome-abrt/issues/370 Proposing for a blocker discussion: https://fedoraproject.org/wiki/Fedora_42_Final_Release_Criteria#Default_application_functionality
Created attachment 2082818 [details] screenshot from abrt UI thats form the last compose Fedora-Workstation-Live-42-20250331.n.0.x86_64.iso It really lack any buttons for configuration
This also affects these cases: * A user makes a typo during their first apikey entry. The bug reporting fails, but no new prompt for a proper apikey is shown. * A user hasn't used their apikey in a long time (so it expired), then upgraded to F42 and wants to report a bug. They can no longer remedy the situation.
Discussed during the 2025-03-31 blocker review meeting [1]: * AGREED: 2356257 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the Final criterion requiring preinstalled apps on Workstation to "start successfully and withstand a basic functionality test", with the Beta upgrade criterion also relevant. We agreed this bug renders the app effectively useless if an invalid API key is set, and there are enough scenarios where that may be the case - e.g. a typo or a previously-valid key on an upgraded system which has now expired - to accept this as a blocker [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-31/f42-blocker-review.2025-03-31-16.01.log.html
Created attachment 2083393 [details] preferences menu button
The preferences menu was never implemented in gnome-abrt. It was, however, linked from there in the previous version. I see how this can be confusing, and I agree that it's an downgrade from the UX perspective. On the other hand, the new gnome-abrt is an amazing improvement over the old version (imo). The implementation always lived in "report-gtk", which is the window that gets opened when the user clicks the "Create Report" button. When user is reporting a problem, they can access the preferences menu from the upper left corner (see the screenshot: https://bugzilla.redhat.com/attachment.cgi?id=2083393). This is the window where the user is when for example reporting fails because of the expired API token. I don't think I will have time to look into re-adding the button to gnome-abrt right now, but if anybody wants to take a stab at this, I will be happy to accept the code contribution ;)
If people think that this is a showstopper, then reverting to the older version of gnome-abrt is also an option.
Oh, wow, I don't think I would ever have thought to look there. Would it be possible to make that more...findable? Or, alternatively, prompt to edit the API key if reporting to RHBZ fails? If either of those is easier to achieve, it would help. We can *maybe* get away with a common bugs note explaining how to find that setting, but most people don't read the docs, and it sure isn't intuitive.
Created attachment 2083431 [details] abrt preferences in F41 I can confirm that the workaround from comment 5 works. But I'm quite certain that nobody will find it on their own :( I attach a screenshot from F41 ABRT, for comparison. I wonder if there are technical difficulties in adding the Preferences button to the new menu, if it's already contained in the hidden menu under the titlebar icon? It would be a shame to revert to the old UI just because of it... (but if I *had to* choose, my choice would be the old UI with preferences that can be found).
as I understand msrb's comment, the gnome-abrt main window and the 'report a crash' flow are actually *entirely different executables*, they're not just different bits of the same app. There is a /usr/bin/report-gtk , which is part of the libreport-gtk package, not the gnome-abrt package. That's what you're looking at when you're in the 'report a crash' flow, AIUI.
Michal, if it's not feasible to add the Preferences menu item, could you please prepare a Bodhi update with the old ABRT interface? There's a Go/No-Go meeting on Thursday, so we'd ideally want to request a Final RC compose tomorrow, if everything else works out. Thanks!
Reverting to an older version would also solve the issue with gnome-abrt being untranslated on F42 (rhbz#2357036) and is a good idea in my opinion.
FEDORA-2025-ca5e949120 (gnome-abrt-1.4.3-4.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-ca5e949120
FEDORA-2025-ca5e949120 (gnome-abrt-1.4.3-4.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Please reopen until the "new" build gets pushed to F42. Thanks!
FEDORA-2025-80a4b526e5 (gnome-abrt-1.4.3-4.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-80a4b526e5
Created attachment 2083927 [details] last build reverted ok
FEDORA-2025-80a4b526e5 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-80a4b526e5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-80a4b526e5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #16) > FEDORA-2025-80a4b526e5 (gnome-abrt-1.4.3-4.fc42) has been submitted as an > update to Fedora 42. > https://bodhi.fedoraproject.org/updates/FEDORA-2025-80a4b526e5 Preferences are reachable, a new bug can be reported.
FEDORA-2025-80a4b526e5 (gnome-abrt-1.4.3-4.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.