When it has been more than two weeks since the last update was installed, GNOME Software should automatically prepare an update (unless the preference to do so has been disabled): * On the Updates page, the "Download" button should automatically change to "Restart & Install." The user should not need to press Download unless it has been less than 2 weeks. * On the GNOME Shell end session dialog, there should be a checkbox offering to install the prepared update. Currently, it looks like GNOME Software actually is sort of preparing the update by downloading all available updates in the background. But it seems to somehow fail to recognize that it has done so. Also, even if I manually prepare the update by pressing Download, the update is not visible on the end session dialog. I have: gnome-software-50~rc-1.fc44, gnome-shell-50~rc-1.fc44. Reproducible: Always
Proposed as a Freeze Exception for 44-final by Fedora user catanzaro using the blocker tracking app because: GNOME Software is not properly preparing updates. We will need to do an emergency update. I don't think it violates any blocker criterion, because the user can manually install updates if desired.
+4 in https://pagure.io/fedora-qa/blocker-review/issue/2108 , marking accepted FE.
Does it mean I'm forced to look on it or it means when/if I get to it I will be free to merge before release? This came up only yesterday, why I already have full of my capacity booked (as we are supposed to have), thus...
The Fedora community isn't going to tell you what you do or do not have to work on. The freeze exception just means you are allowed to push an update, not that you have to. That said, this bug is serious and I don't want to knowingly release F44 like this. Can we try reverting back to PackageKit backend once again? I understand that reverting is itself quite risky. :( If you disagree, I will ask Workstation Working Group to decide. (Even that will not force you to do work, but it could result in somebody else touching the package if you don't want to make the change.) I know the timing is extremely unfortunate. Sadly, I didn't notice until Saturday. Go/no-go is Thursday.
"Reverting" to PackageKit is a bad idea, simply the worst you could come up with. You said on Matrix that this is not a problem per release criterion, then you do all this yelling. It's very sad. You said on Matrix you did receive a notification about critical updates being ready, or that they should be installed. You did not pay attention to the notification. That's not gnome-software's fault, neither the dnf5 plugin's. You _think_ how people install updates, that they use (almost exclusively?) the logout/poweroff dialog to notice about the updates, but are you really with all those users? Was there any research done in this area? There is a big difference between "I think" and "I know". I myself quite often just think, but I do not know. It often hurts (not literally, but still). I currently do not know how to change the dnf5 plugin to behave similarly as the PackageKit. The thing is the PackageKit is sort of pretending. The PackageKit has prepared an offline update only for itself. When you restart the machine by other means, like from the command line, force reboot, whatever, it'll not trigger the update the next time the machine starts, while the dnf5 really prepares the update, for the systemd to know about it, thus the next boot the machine might install the update and then, maybe reboot or poweroff the machine (the reboot is default, thus probably do that). The gnome-shell asks whether there is a prepared offline update when the EndSessionDialog shows up. Doing any expensive operations like "are all packages downloaded, then we can claim the offline update is prepared" is a big no no, it takes time, which delays the dialog opening. In fact, the 50.0 of the gnome-software has an additional fix just in this area, where the end session dialog had been opening for 1 second due to the gnome-software (and the dnf5 and rpm-ostree plugins, to be fair), which was considered too slow. I still live in an impression that what the gnome-software does, in general, follows the "old" update design [1]. Your case for "after two weeks for package updates" speaks of the download and notification. Both happened. It does not speak of "force-install". The PackageKit plugin cheats too. The PackageKit daemon is very quick in discarding prepared offline updates, but the gnome-software's PackageKit plugin notices when an offline update had been previously prepared and when it's discarded it's re-prepared shortly afterwards. It's out of any design, it's a plain cheating, it can be even waste of resources when it comes to it, but it was chosen as a fix and it lives in the code. [1] https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw/master/old/updates-logic.png
Yeah, I agree that 'reverting' to PK at this point is a bad idea, honestly. Personally I'd be happier shipping with this known state - which we can document and potentially fix with a post-release update - than ditching the whole cycle's testing on the dnf5 backend two days before the next go/no-go. As Michael said, freeze exception status just means we are *willing* to push a fix for this through the freeze if one appears, not that we are requesting/demanding one. Blocker status means "we need this addressed before release", it's closer to a request.
I do not agree with Adam. I had been hoping this was just a bug that we could fix, but after reading Milan's comment, it's clear the dnfdaemon backend is just not ready, and we should revert immediately. We cannot expect anybody to fix this in the next couple of days. (In reply to Milan Crha from comment #5) > "Reverting" to PackageKit is a bad idea, simply the worst you could come up with. Why? > You said on Matrix that this is not a problem per release criterion, then you do all this yelling. It's very sad. I actually could make a (tenuous) argument that this bug violates the default panel basic functionality criterion, but I decided that a freeze exception would suffice because you invariably respond promptly to bug reports (as you did here) (thank you). > You said on Matrix you did receive a notification about critical updates > being ready, or that they should be installed. You did not pay attention to > the notification. That's not gnome-software's fault, neither the dnf5 > plugin's. Even if I had paid attention to the notification, I would have simply closed it, because I know that I'll install the updates at the end of the day, when I power off. I never imagined that you would intentionally remove this functionality. > You _think_ how people install updates, that they use (almost exclusively?) > the logout/poweroff dialog to notice about the updates, but are you really > with all those users? Was there any research done in this area? There is a > big difference between "I think" and "I know". I myself quite often just > think, but I do not know. It often hurts (not literally, but still). I am not sure whether we have ever done a usability study on software updates. > I currently do not know how to change the dnf5 plugin to behave similarly as > the PackageKit. The thing is the PackageKit is sort of pretending. The > PackageKit has prepared an offline update only for itself. When you restart > the machine by other means, like from the command line, force reboot, > whatever, it'll not trigger the update the next time the machine starts, > while the dnf5 really prepares the update, for the systemd to know about it, > thus the next boot the machine might install the update and then, maybe > reboot or poweroff the machine (the reboot is default, thus probably do > that). OK, now I understand why you want to avoid scheduling the update. In fact, I see you implemented those changes because I requested it in bug #2392062, the same bug where I requested that we defer dnfdaemon backend from F43 to F44. Problem here is I didn't know that you were planning to change the behavior of prepared updates, and I highly doubt our designers knew about them either. I think we do not want to change the user experience. If dnfdaemon is not able to emulate the same user experience as PackageKit prepared updates, then dnfdaemon is not ready yet. We could have a conversation about whether we're willing to accept the new behavior. I think the answer should be no, but maybe other developers will disagree. But it's going to be pretty tough to debate this within the next couple of days, before go/no-go meeting. If you really don't want to revert, then I can try creating an emergency Working Group ticket tomorrow. > The gnome-shell asks whether there is a prepared offline update when > the EndSessionDialog shows up. Doing any expensive operations like "are all > packages downloaded, then we can claim the offline update is prepared" is a > big no no, it takes time, which delays the dialog opening. In fact, the 50.0 > of the gnome-software has an additional fix just in this area, where the end > session dialog had been opening for 1 second due to the gnome-software (and > the dnf5 and rpm-ostree plugins, to be fair), which was considered too slow. Ah! I had been wondering what was causing that delay. > I still live in an impression that what the gnome-software does, in general, > follows the "old" update design [1]. Your case for "after two weeks for > package updates" speaks of the download and notification. Both happened. It > does not speak of "force-install". We don't need force install. We do need the checkbox to appear and work. > The PackageKit plugin cheats too. The PackageKit daemon is very quick in > discarding prepared offline updates, but the gnome-software's PackageKit > plugin notices when an offline update had been previously prepared and when > it's discarded it's re-prepared shortly afterwards. It's out of any design, > it's a plain cheating, it can be even waste of resources when it comes to > it, but it was chosen as a fix and it lives in the code. I've noticed that too. I agree it's annoying.
> Problem here is I didn't know that you were planning to change the behavior of prepared updates, and I highly doubt our designers knew about them either. I did not intent to, it's how gnome-software works. It downloads the offline updates, then when the user goes tot he Updates tab and click the Download button it's lightning fast, because "everything" is locally available already. That the dnf5 plugin does not cheat like the PackageKit plugin is for good, I believe. Your conclusion that the dnf5daemon is not ready yet is rather false. You expect that two different apps behave exactly the same, but they rarely do, especially when it comes to the details. I said in lengthy above what the consequences can be. If you wish I can enable systemd-sysupdate in the gnome-software, then the checkbox won't be there either, that plugin does not implement needed things, even it's shipped in the upstream. It's not mature enough yet though, according to a comment in the gnome-software sources. I'm happy _you_ do not use Silveblue, that checkbox never worked there, for aaaaall those years. Why? The gnome-shell understood only PackageKit and nothing else. The rpm-ostree is way different from dnf5 and PackageKit, you cannot expect 1:1 behaviour with these. Anyway, _your_ opinion to revert back to the PackageKit, especially at this stage, _I_ consider very extremist non-solution. Wasting effort of multiple people and teams. My personal opinion.
Workstation Working Group issue: https://forge.fedoraproject.org/workstation/tickets/issues/509
This [1] gnome-software dnf5 plugin commit fixes the problem, but it needs: a) a change on the dnf5daemon-server side [2], which simplifies the dnf5-plugin code significantly; b) a regression fix on the gnome-shell side [3], which is independent of the dnf5-plugin code (aka it would be broken for the PackageKit as well). [1] https://gitlab.gnome.org/mcrha/gnome-software/-/commit/7dcb7cd32ae5a86e481e5d5cbbff891351081870 [2] https://github.com/rpm-software-management/dnf5/pull/2699 [3] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/4185
Thanks! On the whole I think I'd rather see that land as a post-release update than try and rush it into the release.
My preference is to land these changes via freeze exception and just hope that nothing breaks. But I understand it's *really* late for that. I am satisfied with a 0-day update. Thanks, everybody, especially Milan.
FEDORA-2026-9e31da3931 (gnome-software-50.1-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-9e31da3931
FEDORA-2026-9e31da3931 (gnome-software-50.1-2.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
Please try and avoid having Rawhide updates marked as fixing blocker/FE bugs for branched...
I wanted to clearly reference what the changes are for, even in rawhide (where I start patching and then propagate it to other branches). The automation did it wrong, the update was created by the automation. I know now I should have used a side tag for the rawhide too (I have one for f44), then I'd get multiple packages tested at once and also get them to the users by single update, and here I could also influence whether the rawhide change would touch this bug or not (I hope), but I failed with that. Maybe next time, unless I forget (which is pretty likely).
No big deal, it was just a minor note. I know the automations and the inability to edit Rawhide updates make it awkward.
Common issue description: https://discussion.fedoraproject.org/t/common-issue/189212
FEDORA-2026-3af4072a43 (dnf5-5.4.2.0-1.fc44, gnome-shell-50.1-2.fc44, and 1 more) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3af4072a43
FEDORA-2026-3af4072a43 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-3af4072a43` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3af4072a43 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The reboot dialog now includes the update checkbox and works fine
I tried testing this but failed. I run: $ gnome-software --quit $ gsettings reset org.gnome.software install-timestamp $ gnome-software Then for whatever reason, Software sets the install timestamp to 1777115090, the value it was before I reset it. Accordingly, it's not possible to force an update by resetting the timestamp. It seems I'll have to actually wait two weeks in order to test it! Is this a recent behavior change? I don't remember this happening before. Why is the install-timestamp stored someplace other than gsettings? This won't be a problem for users, but it makes it very difficult to test. I suppose I would need to change my system clock, which seems risky. I'm not sure how Kamil managed to test it, unless he just hasn't installed updates for two weeks. I've also opened System Monitor just to make certain gnome-software is not starting itself before I run the 'gsettings reset' (which it does like to do) (I often have to run 'gnome-software --quit' twice).
I used this procedure to this it, and it worked for me: https://fedoraproject.org/wiki/QA:Testcase_Gnome_software_update_preparation (I rebooted instead of starting gnome-software as the last step)
There are used multiple timestamps when determining the "should notify" about updates. The other one is `check-timestamp`. When I want to reset these things and be sure that all of them are I just run: for key in `gsettings list-keys org.gnome.software | grep timestamp`; do gsettings reset org.gnome.software $key; done when gnome-software is not running. That's tricky in f44, I think due to the gnome-session changes around systemd, which was adapted by many apps, including gnome-software.
gnome-software must be storing the install-timestamp somewhere else, because it resets it to its original value *even if not running* when I clear the setting. (Like I said, I have System Monitor open to ensure Software does not relaunch before I clear the setting.) That is curious.
It gets the date from the plugin, when asking for "historical updates", those which had been done "recently", then the latest time of the returned install date is used for this GSetting value in the gs-update-monitor.c (and no where else). That is, there is a known past update in dnf5 (or PackageKit if it's used), which influences what date is set into this install-timestamp key.
From the QE testcase, I was missing this step: sudo touch --no-create --date='08:00 15 days ago' /var/lib/PackageKit/offline-update-competed Note there is a typo in that filename, but I guess the typo has become API now.
When I follow the test case steps properly, then I see the prepared updates on end session dialog. Thank you!
FEDORA-2026-3af4072a43 (dnf5-5.4.2.0-1.fc44, gnome-shell-50.1-2.fc44, and 1 more) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
> Note there is a typo in that filename, but I guess the typo has become API now. Yes, that file name has a typo, a typo in PackageKit sources. You can call it API now. Nonetheless, that file is completely ignored with the gnome-software's dnf5-plugin, it's pure PackageKit thing. No idea why that step would help you with anything when the dnf5 plugin is used.
I tried to test the update notification again today (there are updates available), and it just doesn't work for me (regardless of touching /var/lib/PackageKit/offline-update-competed or not): gnome-software --quit TIMESTAMP=$(date '+%s' --date='08:00 15 days ago') gsettings set org.gnome.software check-timestamp $TIMESTAMP gsettings set org.gnome.software install-timestamp $TIMESTAMP gsettings set org.gnome.software update-notification-timestamp $TIMESTAMP sudo touch --no-create --date='08:00 15 days ago' /var/lib/PackageKit/offline-update-competed reboot I tried 5 times already, with different variations, but no notification. It seems there's some race condition or some other problem in this approach, that used to work before.
Try to run gnome-software with `--verbose` and then search the log for "should_" (quotes for clarity only). The check happens a minute after start of the app, thus you've plenty of time to replace gnome-software started by the GNOME session.
(In reply to Kamil Páral from comment #31) > I tried to test the update notification again today (there are updates > available), and it just doesn't work for me (regardless of touching > /var/lib/PackageKit/offline-update-competed or not): A follow-up of this topic is here: https://forge.fedoraproject.org/quality/tickets/issues/899