Why do some security updates seemingly not get picked up as such in GNOME Software?

In this screenshot dnf shows pending security updates for Firefox, vim, and xxd, but GNOME Software thinks that only Firefox has a pending security update.

My understanding is that GNOME Software installs updates every two weeks OR right away if there are pending security updates. If some security updates don’t get picked up as such, then that means it could take two weeks before security updates get installed. That is unless the user remembers and bothers to update manually. Am I misunderstanding something here? Is this a bug, or is this intended behavior?

Just to head this off before it begins, please let’s not go through the “I never use GNOME Software and only ever update manually with dnf and that’s everyone else should do too” routine :slight_smile:

The Workstation is using packagekit to communicate with the software app. While this is still using DNF4.

Now the problem is that there is a dnf5 and dnf4 catalogue and you have them to refresh all the time you make some alterations. While dnf it selves not sees the flatpak applications packagekit does.

So for the moment you need to use the pkcon (packagekit console) to be on the same catalogue as the software app.

dnf is linked to dnf5. If you want to check some dnf4 stuff use dnf4 command instead.

I do not tell you that you have to use the terminal, just telling you that you have to compare the status with the same database of dnf. For the moment package-kit which is the engine behind software app is the reference to compare.

I found this in the opensuse community:

I do not know if this is with us the same and or if the info is to old already. It also shows the place where you can change the value with the dconf editor.

Answer to @mattipulkkinen
Is your query aimed at making the user experience with Gnome Software better?

There are three copies of the meta data possible on your system.
packagekit’s, dnf4’s and dnf5’s. Nothing syncs the meta data between them.

@mattipulkkinen You can see from your screen shot that the versions of vim are not the same in the Gnome Software (packagekit metadata) and the dnf4 meta data.

Gnome Software: 2:9.1-1122
dnf4: 2:9.1-1169

I am going to guess that it’s 1169 that contains a security fix and not the 1122.

When you get to see a particular update will depend on the latency with updating the meta data via packagekit. Maybe you can configure that?

It is a repetition what I already said above.

I am not sure if this question is up to me ? If yes, then I just try to make clear, that for the moment while we are still migrating from dnf4 to dnf5 we can not just open dnf and compare with the software app. You will need to use some command-line tools to get a accurate reference between software app and dnf.

Exactly … we can not compare apples with bananas. Most accurate source of data is in this case that from package kit because that is what it shows up in software. Or did I miss understand something?

@barryascott if you just pressed the wrong reply button, then this comment is obsolete.

Sorry wrong reply.

I wanted to quote you but reply to OP.

1 Like

That is what I was thinking and it happens quite often this way, as far no problem. There is a way to change before you send the replay:

Anyway, to avoid misunderstandings, it makes sense to mention in the top of topic. I will make it. As I know you could be around with a mobile device :wink:

1 Like

I don’t use dnf5 in any case because it is still broken, so I don’t think that this is relevant.

None of the updates listed are for flatpaks.

I do that, and did that in the screenshotted instance above as well.

Right now my query is aimed at understanding what is happening here, but if this isn’t just my misunderstanding and GNOME Software really isn’t installing security updates in a timely manner then that ought to be fixed, of course.

No, 2:9.1-1122 is the currently installed version. 2:9.1-1169 is the pending update in both GNOME Software and dnf4. In Software you can see that it shows the currently installed version on the left, an arrow pointing to the right, and the version of the pending update on the right.

There was a suggestion earlier that you can query the state of package kit to find out what it has in it’s meta data. I think that is your next step. But that is out side of my experience.

@mattipulkkinen please try this:

pkcon get-updates this gives a list like:

$ pkcon get-updates
Getting updates                         [=========================]         
Querying                                [=========================]         
Loading cache                           [=========================]         
Finished                                [=========================]         
Enhancement 	ImageMagick-1:7.1.1.44-1.fc41.x86_64 (updates)              	An X application for displaying and manipulating images
Enhancement 	ImageMagick-libs-1:7.1.1.44-1.fc41.x86_64 (updates)         	ImageMagick libraries to link with
Bug fix     	SDL2_image-2.8.6-1.fc41.x86_64 (updates)                    	Image loading library for SDL
Enhancement 	conmon-2:2.1.13-1.fc41.x86_64 (updates)                     	OCI container runtime monitor
Bug fix     	exfatprogs-1.2.8-1.fc41.x86_64 (updates)                    	Userspace utilities for exFAT filesystems
Security    	firefox-136.0-2.fc41.x86_64 (updates)                       	Mozilla Firefox Web browser
Security    	firefox-langpacks-136.0-2.fc41.x86_64 (updates)             	Firefox langpacks
...
$ pkcon get-updates |grep Security
Security     firefox-136.0-2.fc41.x86_64 (updates)
Security     firefox-langpacks-136.0-2.fc41.x86_64 (updates)
Security     vim-common-2:9.1.1169-1.fc41.x86_64 (updates)
Security     vim-data-2:9.1.1169-1.fc41.noarch (updates)
Security     vim-enhanced-2:9.1.1169-1.fc41.x86_64 (updates)
Security     vim-filesystem-2:9.1.1169-1.fc41.noarch (updates)
Security     vim-minimal-2:9.1.1169-1.fc41.x86_64 (updates)
Security     xxd-2:9.1.1169-1.fc41.x86_64 (updates)

FYI I found out how to see how old the cached meta data is:

pkcon get-time refresh-cache