Gnome-software usually update system packages every 2 weeks if the user didn't manually update. Since a week or so gnome-software downloads the system updates every time I turn on my pc, even only a couple of packages. It's pretty annoying because at every shut-down I have to wait for the installation or uncheck the installation from the turn off dialogue. Reproducible: Always Steps to Reproduce: Turn on Fedora 38 and login. Actual Results: Gnome-Software will download the system packages updates every day when turning on Fedora 38. Expected Results: Gnome-Software will download the system packages updates every two weeks since the last system update.
Thanks for a bug report. What is the "Automatic Updates" option set to in the Menu->Preferences, please? The two weeks delay depends on this: https://gitlab.gnome.org/Teams/Design/software-mockups/-/blob/master/old/updates-logic.png thus it's possible some of the updates have been set as critical.
(In reply to Milan Crha from comment #1) > Thanks for a bug report. What is the "Automatic Updates" option set to in > the Menu->Preferences, please? The two weeks delay depends on this: > > https://gitlab.gnome.org/Teams/Design/software-mockups/-/blob/master/old/ > updates-logic.png > > thus it's possible some of the updates have been set as critical. The "Automatic Updates" option is turned on, I didn't touch those options since I installed Fedora. Though, today is the first day in over a week that a update is not automatically downloaded, maybe they were really all critical? But it's strange because I work with 2 PC with Fedora and only one behaved like that. I also posted on Fedora subreddit and another user have the same issue. So we should keep it open few days to see if the problem appear again?
I do not think there is a way to do selective updates, thus when at least one package for update is a critical update, all pending updates are prepared together with it. I do not see any other reason why there would be done the update preparation prematurely. Could it be the two Fedoras you have do not have installed precisely the same package set? When you run gnome-software from a terminal for the first time of the day with debug logging on: gnome-software --quit; gnome-software --verbose then roughly a minute after that the update monitor will start checking for updates and will log about it. There might be a corresponding notification about pending updates to be installed shown as well, though not necessarily.
Created attachment 1990209 [details] Gnome-software update bug
Comment on attachment 1990209 [details] Gnome-software update bug Ok, I tried to do "gnome-software --verbose" some days ago, but I messed up the command the first time (gnome-software updated the flatpaks and the bug appeared), then I killed gnome-software, deleted the cache, tried another time but there wasn't the bug. Today I retried, I noticed that when gnome software update the flatpaks it will also download the system updates. Or I am very unlucky and there are critical updates almost every day, or while updating the flatpaks gnome-software pick up the system packages too, and also it explain why the other day I wasn't able to reproduce the bug, because the flatpaks where already updated when I started gnome-software for the second time. I add an attachment with the log of the command "gnome-software --verbose", unfortunately my terminal cut the log to the last 10'000 lines, the next time I will upload the full log if necessary.
The update monitor claims what updates had been recognized on a line with "should_notify_about_pending_updates" (quotes for clarity only). It corresponds to the update message shown in the system. To easily re-trigger the update monitor (it runs roughly a minute after start of the gnome-software), you can reset the timestamps, thus the code behaves like the update was never checked, neither installed. That can be done from a terminal with this long command: for key in `gsettings list-keys org.gnome.software | grep timestamp`; do gsettings reset org.gnome.software $key; done To get the full log, you can run gnome-software as: gnome-software --verbose &>/tmp/log.txt Only note that the saving to the file is cached by the kernel, thus the log is not always fully up-to-date. It's better to stop gnome-software gracefully in this case, like to run in another terminal: gnome-software --quit
I forgot to add, the idea about having downloaded all updates when online (Flatpak) updates are available sounds interesting to me. That would be a regression, because the updates are split into offline (like PackageKit) updates and online updates, where only the list of the online updates is used to run the update process with. The log may contain a line with: Received NNN apps to update, XXX are online and YYY offline updates; will/not download online updates confirming the split of the recognized updates.
Created attachment 1990623 [details] Gnome-software log Here's the log got with the command you suggested. I tried to search for the "Received NNN apps to update, XXX are online and YYY offline updates; will/not download online updates" but I didn't get any result. Another thing about my system: I use Fedora Workstation like it was Silverblue, so I use almost only flatpaks, so I have many of them. Maybe too many flatpaks bug the update system?
Thanks for the log. I see in it a relevant information: 15:26:57:591 Gs should_notify_about_pending_updates: last_test_days:5 n-apps:5 should_download:1 has_important:0 all_downloaded:0 any_downloaded:1 res:0 15:26:57:591 Gs No update notification needed which is about notification only, but it shows there are no important updates. I see the "Received NNN apps to update...." is not in the log, because it went by a different path: 15:23:16:305 Gs got 5 updates 15:23:16:305 Gs Getting updates The gnome-software does this when it should download updates (the above line shows it should) and when either security timestamp from the apps for the update mismatches (it's `gsettings get org.gnome.software security-timestamp`) or when the last installed update was more than 14 days ago (that is `gsettings get org.gnome.software install-timestamp`). Looking for how it works, I think it's possible the security timestamp check misbehaves when there is no "important" update, while there had been an "important" update the last time. I opened a proposed change for this upstream: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1805 Let's continue there. Thank you for your help with this.
I have tested the upstream merge request !1805 and unfortunately it does not fix this issue for me.
We spoke about this with Michael and as he did some detailed testing, it seems the problem is with `installed-timestamp`, which is in summer for him, even after yesterday update. I'll focus my investigation that way and possibly open a new merge request. I'll keep you updated here as well.
Interestingly, I just finished an update on one machine and it says: gsettings get org.gnome.software install-timestamp int64 1701969938 which is just the time the update finished. Nonetheless, relying on an update time, rather than the local time when the update finished, doesn't look right (Michael pointed to that when we spoke about it).
I gave this a try on my machine and I do not face the problem, but I made a scratch build of the gnome-software [1], which prints what install dates are returned by the plugins, which might help to see what the problem is. Could any of you install it, then get the current install-timestamp value: gsettings get org.gnome.software install-timestamp and then run it, to see what it'll print, please? gnome-software --quit gnome-software Do not turn on the verbose logging, I'm interested in the added debug prints only. After the prints are shown, the install-timestamp might change as well, depending on the provided recently installed apps by the plugins. If this debug change won't work, I'm afraid the only way to cover this is to add yet another timestamp into the GSettings, something like "install-pending-timestamp", which will hold the last date, when the last update had been prepared and it'll be moved to the "install-timestamp" only after restart. The problem with this might be that the install of the updates can be done out of gnome-software, like when restarting the machine from the system, which the app cannot catch, I'm afraid (or at least I do not know how to do it). Thus recognizing "the updates had been installed" proves to be tricky, as the proposed "install-pending-timestamp" can be irrelevant, due to the update not being installed. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=110227601
get_updates_historical_cb: [0] app:'*/cabinet/*/org.linuxfoundation.dbx.x64.firmware/*'|'UEFI dbx' install-date:1688400957 get_updates_historical_cb: [1] app:'(null)'|'python3-dnf-plugins-core' install-date:1702313539 get_updates_historical_cb: [2] app:'(null)'|'dnf-plugins-core' install-date:1702313539 get_updates_historical_cb: [3] app:'(null)'|'dnf-utils' install-date:1702313539 There's the problem. You're using the timestamp of the first app in the list as the timestamp for when updates were last installed, but it's the UEFI dbx update from July. Firmware updates shouldn't be considered here because they're not RPMs.
Thanks for testing. What is your "install-timestamp" now, please? I think of using the highest install-date as the timestamp, checking with the current time and saved install-timestamp, to not get into the future and below the stored time.
(In reply to Milan Crha from comment #15) > Thanks for testing. What is your "install-timestamp" now, please? 1702313539. Huh. That's not what I expected to see. I checked my chat log with you, and I see that when you asked me to check my install-timestamp on Thursday last week, it was 1688400957.
(In reply to Michael Catanzaro from comment #16) > 1702313539. Huh. That's not what I expected to see. > > I checked my chat log with you, and I see that when you asked me to check my > install-timestamp on Thursday last week, it was 1688400957. It fixed that test build, it already picks the highest date and stores it into the install-timestamp. I'll create a merge request upstream, with additional changes as I mentioned in my previous comment. Thank you again for the testing of this and your patience.
I opened [1] with the fix upstream, which I'll merge for gnome-software 45.3 too. This change can have side effects, like being notified about recent updates, even the updates happened days ago. It's due to changed timestamp and it's expected. Once the values get in sync, it'll stop notify and things will return "back to normal". [1] https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1848