gnome-software update notification needs a new testing approach

kparal commented

2026-05-05 12:02:49 +00:00

Owner

Testcase https://fedoraproject.org/wiki/QA:Testcase_Gnome_software_update_preparation shows up in Bodhi for gnome-software, we reference it from https://fedoraproject.org/wiki/QA:Testcase_desktop_update_notification and it's also used in OpenQA. But, with the plumbing change from PackageKit to DNF5, the described steps no longer work.

The suggested approach was:

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

The update-notification-timestamp shows a notification only once in 14 days. But in order to show it, the updates need to be downloaded first. Downloading is now handled by dnf5daemon-server, and only happens after 14 days from the install-timestamp, or if any update is critical. The new problem is that overwriting install-timestamp is no longer sufficient - on each gnome-software start (which initializes dnf5daemon-server), it updates the timestamp with whatever DNF determines to be the latest time it installed any package. Because it has its own database (dnf history list), it's not enough to reset the gsettings value, it will always overwrite it back.

Which means the current approach works for a fresh new installed OS (which is why it probably works in OpenQA), but it doesn't work for any system where you installed any RPM in the last <14 days.

We need to figure out a new approach for testing gnome-software update notifications. Milan Crha is available for gnome-software related discussions, but we need to talk to DNF folks as well.

Or we will give up on persuading the tools to do what we want, and simply adjust system time to test this. That's not a great approach to recommend to general audience for release validation (and Bodhi updates validation), though, because resetting the time back to the present can potentially cause issues for certain apps/services.

One potential idea is that we could create a repository with a fake critical update, which could convince the tools to show it due to its importance. Needs to be tested, if that would even work. (But maybe OpenQA does this already?)

Testcase https://fedoraproject.org/wiki/QA:Testcase_Gnome_software_update_preparation shows up in Bodhi for gnome-software, we reference it from https://fedoraproject.org/wiki/QA:Testcase_desktop_update_notification and it's also used in OpenQA. But, with the plumbing change from PackageKit to DNF5, the described steps no longer work. The suggested approach was: ``` 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 ``` The `update-notification-timestamp` shows a notification only once in 14 days. But in order to show it, the updates need to be downloaded first. Downloading is now handled by dnf5daemon-server, and only happens after 14 days from the `install-timestamp`, or if any update is critical. The new problem is that overwriting `install-timestamp` is no longer sufficient - on each gnome-software start (which initializes dnf5daemon-server), it updates the timestamp with whatever DNF determines to be the latest time it installed any package. Because it has its own database (`dnf history list`), it's not enough to reset the gsettings value, it will always overwrite it back. Which means the current approach works for a fresh new installed OS (which is why it probably works in OpenQA), but it doesn't work for any system where you installed any RPM in the last <14 days. We need to figure out a new approach for testing gnome-software update notifications. Milan Crha is available for gnome-software related discussions, but we need to talk to DNF folks as well. Or we will give up on persuading the tools to do what we want, and simply adjust system time to test this. That's not a great approach to recommend to general audience for release validation (and Bodhi updates validation), though, because resetting the time back to the present can potentially cause issues for certain apps/services. One potential idea is that we could create a repository with a fake critical update, which could convince the tools to show it due to its importance. Needs to be tested, if that would even work. (But maybe OpenQA does this already?)

kparal added the

labels

2026-05-05 12:03:21 +00:00

mcrha commented

2026-05-05 14:21:47 +00:00

A quick note: Kamil summarized it well. It worked earlier, in "the gnome-software with PackageKit", because PacakgeKit has its own "offline updates" file, from which it reads when it was done the last time. The dnf5 plugin uses the dnf5daemon-server, which also sees changes from the command line, which is sometimes nice to have, as you can see what had been changed not only from the gnome-software itself (or through pkcon for the PackageKit), but, unfortunately, it stays in the way of this functionality.

Thinking of it, I'd say the test uncovered a difference in the behavior, aka the test did its job well. The test showed the things can be broken for the people relying on the gnome-software update (notifications) when they use dnf command line from time to time.

I'm afraid the only chance is to add dnf5-plugin specific timestamp into the GSettings for the last offline update ran by the gnome-software itself, which will be also used as a clamp on the discovered past updates.

I'll think about it a bit more. Feel free to comment and/or suggest things.

A quick note: Kamil summarized it well. It worked earlier, in "the gnome-software with PackageKit", because PacakgeKit has its own "offline updates" file, from which it reads when it was done the last time. The dnf5 plugin uses the dnf5daemon-server, which also sees changes from the command line, which is sometimes nice to have, as you can see what had been changed not only from the gnome-software itself (or through `pkcon` for the PackageKit), but, unfortunately, it stays in the way of this functionality. Thinking of it, I'd say the test uncovered a difference in the behavior, aka the test did its job well. The test showed the things can be broken for the people relying on the gnome-software update (notifications) when they use dnf command line from time to time. I'm afraid the only chance is to add dnf5-plugin specific timestamp into the GSettings for the last offline update ran by the gnome-software itself, which will be also used as a clamp on the discovered past updates. I'll think about it a bit more. Feel free to comment and/or suggest things.

kparal commented

2026-05-05 16:02:27 +00:00

Author

Owner

This is what OpenQA does:
https://openqa.fedoraproject.org/tests/4690934#step/desktop_notifications/28

This is what OpenQA does: https://openqa.fedoraproject.org/tests/4690934#step/desktop_notifications/28

adamwill commented

2026-05-05 20:05:14 +00:00

Owner

Sorry, a better source is here. That's most of the relevant test source; you can see all the messing about we do to try and get notifications to appear reliably. Note some of the things are probably obsolete/unneeded; we don't touch this unless/until it stops working.

One thing that isn't there is the thing we do to make sure an update is actually available. That's prepare_test_packages which is called on line 55. You can see the implementation here. Notably it does run dnf commands.

Sorry, a better source is [here](https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/src/commit/4394c668db693d7aab13081df4590377e93f611c/tests/desktop_notifications.pm#L36). That's most of the relevant test source; you can see all the messing about we do to try and get notifications to appear reliably. Note some of the things are probably obsolete/unneeded; we don't touch this unless/until it stops working. One thing that *isn't* there is the thing we do to make sure an update is actually available. That's `prepare_test_packages` which is called on line 55. You can see the implementation [here](https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/src/commit/4394c668db693d7aab13081df4590377e93f611c/lib/packagetest.pm#L13). Notably it *does* run dnf commands.

kparal added this to the Fedora 45 milestone

2026-05-06 08:26:32 +00:00

kparal commented

2026-05-06 10:36:43 +00:00

Author

Owner

Notably it does run dnf commands.

This is interesting and it just means that we still don't fully understand the current behavior.

Anyway, our current assumption is that if the user performs some RPM operations (through DNF or gnome-software) every <14 days, they will never get a "new updates available" notification (unless there's a critical update in the set, which might trigger a different code path). It needs to be tested, but would pose a bigger (and general) problem than this ticket. If that's the case, we should file it separately (might even propose it as an F45 blocker), and Milan could think about a different implementation (that would only track system updates, possibly done just through gnome-software, for the purpose of future updates notifications).

> Notably it _does_ run dnf commands. This is interesting and it just means that we still don't fully understand the current behavior. Anyway, our current assumption is that if the user performs some RPM operations (through DNF or gnome-software) every <14 days, they will **never** get a "new updates available" notification (unless there's a critical update in the set, which might trigger a different code path). It needs to be tested, but would pose a bigger (and general) problem than this ticket. If that's the case, we should file it separately (might even propose it as an F45 blocker), and Milan could think about a different implementation (that would only track system updates, possibly done just through gnome-software, for the purpose of future updates notifications).

mcrha commented

2026-05-06 16:46:58 +00:00

Right, right, I remember the acpica-tools package, I used it for some testing in the past too :)

I still cannot think of any better way than a new timestamp key (there are never enough timestamp keys, right?), I'll look on it tomorrow or so. I'll let you know with a test package once I have any.

Right, right, I remember the acpica-tools package, I used it for some testing in the past too :) I still cannot think of any better way than a new timestamp key (there are never enough timestamp keys, right?), I'll look on it tomorrow or so. I'll let you know with a test package once I have any.

mcrha commented

2026-05-06 16:49:04 +00:00

Anyway, our current assumption is that if the user performs some RPM operations (through DNF or gnome-software) every <14 days, they will never get a "new updates available" notification (unless there's a critical update in the set, which might trigger a different code path). It needs to be tested, but would pose a bigger (and general) problem than this ticket.

That's what I meant as the test worked, it uncovered a (hidden?) problem. I would not open a new ticket for it, it might be just duplicate of this one, as when i fix this, it'll fix that as well.

> Anyway, our current assumption is that if the user performs some RPM operations (through DNF or gnome-software) every <14 days, they will never get a "new updates available" notification (unless there's a critical update in the set, which might trigger a different code path). It needs to be tested, but would pose a bigger (and general) problem than this ticket. That's what I meant as the test worked, it uncovered a (hidden?) problem. I would not open a new ticket for it, it might be just duplicate of this one, as when i fix this, it'll fix that as well.

mcrha commented

2026-05-07 12:34:14 +00:00

Could you give a try to this test build, please?
https://koji.fedoraproject.org/koji/taskinfo?taskID=145218699

It contains a patch which seems to work better here, but I often miss some detail and it works slightly differently on other machines than on mine, thus better to test it before that. If you'd want to be super-sure, then also reset packagekit-historical-updates-timestamp key, which the dnf5 plugin already uses, I extended its use on other places and use it as an upper date/time clamp of a package install, thus any later package changes are not interfering.

Other plugins can still interfere, like the fwupd, but that would be a question on the gnome-software upstream and the gs-update-monitor, how to deal with it, because it's independent of the dnf5 plugin. Of course, such change would void a change on the dnf5 plugin side, but I guess its fine for now.

Could you give a try to this test build, please? https://koji.fedoraproject.org/koji/taskinfo?taskID=145218699 It contains a patch which seems to work better here, but I often miss some detail and it works slightly differently on other machines than on mine, thus better to test it before that. If you'd want to be super-sure, then also reset `packagekit-historical-updates-timestamp` key, which the dnf5 plugin already uses, I extended its use on other places and use it as an upper date/time clamp of a package install, thus any later package changes are not interfering. Other plugins can still interfere, like the fwupd, but that would be a question on the gnome-software upstream and the gs-update-monitor, how to deal with it, because it's independent of the dnf5 plugin. Of course, such change would void a change on the dnf5 plugin side, but I guess its fine for now.

kparal commented

2026-05-11 11:09:10 +00:00

Author

Owner

@mcrha wrote in #899 (comment):

Could you give a try to this test build, please?
https://koji.fedoraproject.org/koji/taskinfo?taskID=145218699

This seems to be working great for me. With this approach:

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
gsettings set org.gnome.software packagekit-historical-updates-timestamp $TIMESTAMP
gnome-software --verbose

I have no problem making gnome-software pop up "Updates Ready" notification any time I tried.

Will you make this change go into the main branch?

@mcrha wrote in https://forge.fedoraproject.org/quality/tickets/issues/899#issuecomment-698550: > Could you give a try to this test build, please? > https://koji.fedoraproject.org/koji/taskinfo?taskID=145218699 This seems to be working great for me. With this approach: ``` 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 gsettings set org.gnome.software packagekit-historical-updates-timestamp $TIMESTAMP gnome-software --verbose ``` I have no problem making gnome-software pop up "Updates Ready" notification any time I tried. Will you make this change go into the main branch?

mcrha commented

2026-05-11 11:20:56 +00:00

Will you make this change go into the main branch?

Sure thing, I've been only waiting for a (second) confirmation, aka also have it tested from someone else than me.

> Will you make this change go into the main branch? Sure thing, I've been only waiting for a (second) confirmation, aka also have it tested from someone else than me.

kparal commented

2026-05-11 11:36:35 +00:00

Author

Owner

Great. I've updated our test case with new instructions.

@adamwill @lruzicka Can we also update OpenQA and make the additional timestamp key reset as well?

Once there's a new official GS build, this should be hopefully done.

Great. I've [updated our test case](https://fedoraproject.org/w/index.php?title=QA%3ATestcase_Gnome_software_update_preparation&diff=772326&oldid=771471) with new instructions. @adamwill @lruzicka Can we also update OpenQA and make the additional timestamp key reset as well? Once there's a new official GS build, this should be hopefully done.

kparal self-assigned this

2026-05-11 11:36:42 +00:00

mcrha commented

2026-05-11 11:46:03 +00:00

Expected versions with the fix are gnome-software-50.1-5.fc45 and gnome-software-50.1-5.fc44 (currently building). I won't spam here once the builds are done, it'll be reflected in bodhi.
//Update: F44 Bodhi update

Expected versions with the fix are `gnome-software-50.1-5.fc45` and `gnome-software-50.1-5.fc44` (currently building). I won't spam here once the builds are done, it'll be reflected in bodhi. //Update: [F44 Bodhi update](https://bodhi.fedoraproject.org/updates/FEDORA-2026-340cf988ec)

kparal added this to the Sprint 9 project

2026-05-11 12:30:41 +00:00

adamwill commented

2026-05-11 21:38:45 +00:00

Owner

@kparal wrote in #899 (comment):

Great. I've updated our test case with new instructions.

@adamwill @lruzicka Can we also update OpenQA and make the additional timestamp key reset as well?

Once there's a new official GS build, this should be hopefully done.

sure, adding one more to the pile can't hurt I guess. You can send a PR if you like? Just add it to all the others. :D

@kparal wrote in https://forge.fedoraproject.org/quality/tickets/issues/899#issuecomment-705806: > Great. I've [updated our test case](https://fedoraproject.org/w/index.php?title=QA%3ATestcase_Gnome_software_update_preparation&diff=772326&oldid=771471) with new instructions. > > @adamwill @lruzicka Can we also update OpenQA and make the additional timestamp key reset as well? > > Once there's a new official GS build, this should be hopefully done. sure, adding one more to the pile can't hurt I guess. You can send a PR if you like? Just add it to all the others. :D

kparal referenced this issue from a commit

2026-05-12 12:03:57 +00:00

desktop_notifications: add one more gsettings timestamp to be reset

kparal referenced this issue from quality/os-autoinst-distri-fedora

2026-05-12 12:04:48 +00:00

desktop_notifications: add one more gsettings timestamp to be reset #548

kparal commented

2026-05-12 12:07:31 +00:00

Author

Owner

@adamwill wrote in #899 (comment):

You can send a PR if you like?

Not really...? It took me 20 minutes just to clone the repo! Oh well, here it is: quality/os-autoinst-distri-fedora#548

Closing this ticket as done.

@adamwill wrote in https://forge.fedoraproject.org/quality/tickets/issues/899#issuecomment-707966: > You can send a PR if you like? Not really...? It took me 20 minutes just to clone the repo! Oh well, here it is: https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/pulls/548 Closing this ticket as done.

kparal closed this issue

2026-05-12 12:07:32 +00:00

adamwill commented

2026-05-13 06:44:21 +00:00

Owner

Hum. I think this is causing the updates to actually get installed? See https://openqa.fedoraproject.org/tests/4722563#step/desktop_notifications/124 . We don't really want that...

Hum. I think this is causing the updates to actually get *installed*? See https://openqa.fedoraproject.org/tests/4722563#step/desktop_notifications/124 . We don't really want that...

mcrha commented

2026-05-13 07:11:02 +00:00

The packagekit-historical-updates-timestamp is used to determine how old package/dnf changes are considered as "recent updates". Anything beyond that date is considered a recent change and is announced by the referenced notification. Did it notify about the acpi-tool downgrade/install?

The `packagekit-historical-updates-timestamp` is used to determine how old package/dnf changes are considered as "recent updates". Anything beyond that date is considered a recent change and is announced by the referenced notification. Did it notify about the acpi-tool downgrade/install?

kparal commented

2026-05-13 07:44:06 +00:00

Author

Owner

I don't that believe really installs updates, because it need a reboot cycle to install updates (and that didn't happen in that test case). But I have a suspicion what happens there. I also saw some unexpected "Software updates installed" notifications in certain cases during my testing. I believe that's a notification about the previous RPM transaction (might not even be initiated by gnome-software), which in this case might be the acpi-tool downgrade, as Milan suggests. Resetting the additional timestamp perhaps caused a difference in behavior for these "previous transaction complete" notifications.

I don't that believe _really_ installs updates, because it need a reboot cycle to install updates (and that didn't happen in that test case). But I have a suspicion what happens there. I also saw some unexpected "Software updates installed" notifications in certain cases during my testing. I believe that's a notification about the _previous_ RPM transaction (might not even be initiated by gnome-software), which in this case might be the `acpi-tool` downgrade, as Milan suggests. Resetting the additional timestamp perhaps caused a difference in behavior for these "previous transaction complete" notifications.

lruzicka referenced this issue from a commit

2026-05-13 09:57:26 +00:00

desktop_notifications: add one more gsettings timestamp to be reset

mcrha commented

2026-05-13 14:42:14 +00:00

Correct, it can be the other dnf commands interfering. When you run gnome-software --mode=updated you can check what changes it found.

To add to the confusion, the dnf5daemon does not return the install/change time, the only time information is the build time of the (installed) packages, thus it's currently used as the install time. It mostly works, but can misbehave. I opened a bug against the dnf5daemon to provide the transaction time in the response.

The acpi-tool package should be fine, it has an ancient build time, due to that I suppose some other operation triggered the notification.

Correct, it can be the other `dnf` commands interfering. When you run `gnome-software --mode=updated` you can check what changes it found. To add to the confusion, the dnf5daemon does not return the install/change time, the only time information is the build time of the (installed) packages, thus it's currently used as the install time. It mostly works, but can misbehave. I opened [a bug against the dnf5daemon](https://github.com/rpm-software-management/dnf5/issues/2734) to provide the transaction time in the response. The `acpi-tool` package should be fine, it has an ancient build time, due to that I suppose some other operation triggered the notification.

adamwill commented

2026-05-13 15:49:42 +00:00

Owner

Well that's annoying. Is there some way to prevent this happening?

mcrha commented

2026-05-14 06:31:27 +00:00

It depends. Can you find out what it sees as the recent updates, please? It'll help to narrow the problem.

The packagekit-historical-updates-timestamp is supposed to help. Maybe set it only a minute in the past, not two weeks, aka just before the update? Err, but even with it, as the transaction time is not known, the updated package will be missed... That's... not ideal... Trusting the dnf5daemon server returning only transaction since that time, I can ignore the buildtime of the package and use the packagekit-historical-updates-timestamp as the packages install time, until/if the dnf5 folks will add the real transaction time to the response. I know they return transactions since that time, thus it should be fine. Opinions?

By the way, this happens when the tools are accurate ;)

It depends. Can you find out what it sees as the recent updates, please? It'll help to narrow the problem. The `packagekit-historical-updates-timestamp` is supposed to help. Maybe set it only a minute in the past, not two weeks, aka just before the update? Err, but even with it, as the transaction time is not known, the updated package will be missed... That's... not ideal... Trusting the dnf5daemon server returning only transaction since that time, I can ignore the buildtime of the package and use the `packagekit-historical-updates-timestamp` as the packages install time, until/if the dnf5 folks will add the real transaction time to the response. I know they return transactions since that time, thus it should be fine. Opinions? By the way, this happens when the tools are accurate ;)

kparal reopened this issue

2026-05-14 07:18:24 +00:00

kparal commented

2026-05-14 07:46:07 +00:00

Author

Owner

Actually, my PR that resets packagekit-historical-updates-timestamp is not yet deployed to OpenQA production, as far as I can say. So this change we're seeing in OpenQA seems to be related to GS code changes only, not the adjustments of our tests. I'm trying to dig more into it.

//Edit: Ok, I officially don't understand it. The executed script doesn't contain this line:

script_run "gsettings set org.gnome.software packagekit-historical-updates-timestamp ${longago}", 0;

but the video from the test shows it as being executed. I have no idea what's happening here.

Actually, [my PR](https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/pulls/548) that resets `packagekit-historical-updates-timestamp` is not yet deployed to OpenQA production, as far as I can say. So this change we're seeing in OpenQA seems to be related to GS code changes only, not the adjustments of our tests. I'm trying to dig more into it. //Edit: Ok, I officially don't understand it. [The executed script](https://openqa.fedoraproject.org/tests/4722563/modules/desktop_notifications/steps/1/src) doesn't contain this line: ``` script_run "gsettings set org.gnome.software packagekit-historical-updates-timestamp ${longago}", 0; ``` but [the video](https://openqa.fedoraproject.org/tests/4722563/video?filename=video.webm) from the test shows it as being executed. I have no idea what's happening here.

kparal referenced this issue from a commit

2026-05-14 10:49:31 +00:00

desktop_notifications: try to prevent "System Updates Installed" notifications

kparal referenced this issue from quality/os-autoinst-distri-fedora

2026-05-14 10:49:39 +00:00

desktop_notifications: try to prevent "System Updates Installed" notifications #551

kparal commented

2026-05-14 10:50:23 +00:00

Author

Owner

I've done a lot of local testing with Milan's help. This DNF bug complicates the testing a lot. However, these claims currently seem to be true:

The "Updates installed" notification appears when there are some new DNF transactions after packagekit-historical-updates-timestamp, and install-timestamp < packagekit-historical-updates-timestamp .
When packagekit-historical-updates-timestamp is 0, it suppresses any "Updates installed" notification, because it's considered as a clean OS installation state.

I'm not sure why we're seeing "Updates installed" notification in OpenQA, because we reset the timestamps to the exactly same value. That timestamp can also be adjusted during GS startup, but we can't look more into it without adding debug info to the OpenQA test. I tried but I can't reproduce it locally.

However, the second point could help us avoid that problem. Simply set packagekit-historical-updates-timestamp = 0, and it should prevent these notifications (but still allow "Updates available" notifications, at least in my local testing).

@adamwill Can you test if quality/os-autoinst-distri-fedora#551 fixes the problem?

I've done a lot of local testing with Milan's help. [This DNF bug](https://github.com/rpm-software-management/dnf5/issues/2734) complicates the testing a lot. However, these claims currently seem to be true: * The "Updates installed" notification appears when there are some new DNF transactions after `packagekit-historical-updates-timestamp`, and `install-timestamp` < `packagekit-historical-updates-timestamp` . * When `packagekit-historical-updates-timestamp` is 0, it suppresses any "Updates installed" notification, because it's considered as a clean OS installation state. I'm not sure why we're seeing "Updates installed" notification in OpenQA, because we reset the timestamps to the exactly same value. That timestamp can also be adjusted during GS startup, but we can't look more into it without adding debug info to the OpenQA test. I tried but I can't reproduce it locally. However, the second point could help us avoid that problem. Simply set `packagekit-historical-updates-timestamp = 0`, and it should prevent these notifications (but still allow "Updates available" notifications, at least in my local testing). @adamwill Can you test if https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/pulls/551 fixes the problem?

adamwill commented

2026-05-14 15:43:30 +00:00

Owner

@kparal wrote in #899 (comment):

Actually, my PR that resets packagekit-historical-updates-timestamp is not yet deployed to OpenQA production, as far as I can say. So this change we're seeing in OpenQA seems to be related to GS code changes only, not the adjustments of our tests. I'm trying to dig more into it.

//Edit: Ok, I officially don't understand it. The executed script doesn't contain this line:
script_run "gsettings set org.gnome.software packagekit-historical-updates-timestamp ${longago}", 0;
but the video from the test shows it as being executed. I have no idea what's happening here.

I reverted your commit directly on openQA prod (which I meant as a temporary test but then forgot about). I did that at Date: Wed May 13 06:46:15 2026 +0000. A test run after your PR merged but before that revert would have run your step. A test run after that point would not.

Note openQA - at least openQA the way we run it, we're still using the very old-fashioned way - always shows the current state of the test code when you click on those links in the web UI. It does not display the code as it existed at the time the test was executed.

There's a newer-style way to do things in openQA where I think it knows what state of the test repo was used to execute each test and can display the right source, but...we're not using that.

@kparal wrote in https://forge.fedoraproject.org/quality/tickets/issues/899#issuecomment-711299: > Actually, [my PR](https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/pulls/548) that resets `packagekit-historical-updates-timestamp` is not yet deployed to OpenQA production, as far as I can say. So this change we're seeing in OpenQA seems to be related to GS code changes only, not the adjustments of our tests. I'm trying to dig more into it. > > //Edit: Ok, I officially don't understand it. [The executed script](https://openqa.fedoraproject.org/tests/4722563/modules/desktop_notifications/steps/1/src) doesn't contain this line: > > ```text > script_run "gsettings set org.gnome.software packagekit-historical-updates-timestamp ${longago}", 0; > ``` > > but [the video](https://openqa.fedoraproject.org/tests/4722563/video?filename=video.webm) from the test shows it as being executed. I have no idea what's happening here. I reverted your commit directly on openQA prod (which I meant as a temporary test but then forgot about). I did that at `Date: Wed May 13 06:46:15 2026 +0000`. A test run after your PR merged but before that revert would have run your step. A test run after that point would not. Note openQA - at least openQA the way we run it, we're still using the very old-fashioned way - always shows the *current* state of the test code when you click on those links in the web UI. It does not display the code *as it existed at the time the test was executed*. There's a newer-style way to do things in openQA where I think it knows what state of the test repo was used to execute each test and can display the right source, but...we're not using that.

👍 1

kparal referenced this issue from a commit

2026-05-14 16:24:49 +00:00

desktop_notifications: try to prevent "System Updates Installed" notifications

adamwill referenced this issue from a commit

2026-05-14 18:54:56 +00:00

desktop_notifications: try to prevent "System Updates Installed" notifications

adamwill referenced this issue from a commit

2026-05-14 19:06:07 +00:00

desktop_notifications: try to prevent "System Updates Installed" notifications

kparal commented

2026-05-15 07:12:01 +00:00

Author

Owner

quality/os-autoinst-distri-fedora#551 seems to have fixed our tests. Closing again.

https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/pulls/551 seems to have fixed our tests. Closing again.

kparal closed this issue

2026-05-15 07:12:01 +00:00

mcrha commented

2026-05-15 08:33:01 +00:00

For what it's worth, the dnf5 folks have some good changes, which I'll incorporate into the gnome-software sooner or later. I guess you'll notice soon if I break anything with it ;)

Rows
Columns

gnome-software update notification needs a new testing approach #899