Bug 2064623

Proposed as a Blocker for 36-beta by Fedora user lruzicka using the blocker tracking app because:

 This bug violates the Upgrade requirements criterion, because the system cannot be upgraded from the second last version of Fedora. Therefore, I am proposing it a Beta blocker.

https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria#Upgrade_requirements

Thanks for a bug report. I guess you wrote the gsettings command, rather than copy&paste it, because it's `show-upgrade-prerelease` key (no 's' in `upgrade`). That's just to avoid confusion for anybody else trying to reproduce it.

I tried it and I did have offered only the f35 upgrade, but since I closed gnome-software and restarted it with: "gnome-software --quit && gnome-software", then it begun to offer me the f36 upgrade.

The Refresh button does not check for the upgrades, it's done only once, thus even if you changed the GSettings key it's not considered and the previously found upgrade is offered.

It works quite the same in f35, as far as I know. Maybe you've been just lucky about the change of the GSettings key, maybe you changed it within the first 60 seconds after the gnome-software start, when a refresh of the upgrades is done.



I would close this without any change. Doing more often pings (and downloads) of the https://admin.fedoraproject.org/pkgdb/api/collections/ feels like a waste of the resources on the user's side. That file does not change that often.

The most I can propose upstream some patch to refresh the cache after the GSettings key changes, but it's a hidden key, thus the users may expect it not working immediately, but only after a restart of the gnome-software.

By the way, this should be filled against Fedora 34 (it's currently filled against Fedora 36). The two Fedoras use very different versions of the gnome-software.

(In reply to Milan Crha from comment #2)
> Thanks for a bug report. I guess you wrote the gsettings command, rather
> than copy&paste it, because it's `show-upgrade-prerelease` key (no 's' in
> `upgrade`). That's just to avoid confusion for anybody else trying to
> reproduce it.

Yes, I typed it here.

> The most I can propose upstream some patch to refresh the cache after the
> GSettings key changes, but it's a hidden key, thus the users may expect it
> not working immediately, but only after a restart of the gnome-software.

I did not expect to start it immediately after I changed the settings. I fully restarted
the virtual machine before I even attempted to upgrade, so this should have restarted 
gnome-software. I ended up with the above result. 

What I can do, is try to wait some time and hope it will start working.

I do not think that upgrading from F34 to F35 and then to F35 is what 
users would want to do (which is the only thing I am offered at the moment).

(In reply to Lukas Ruzicka from comment #4)
> I fully restarted the virtual machine before I even attempted to upgrade,
> so this should have restarted gnome-software. I ended up with the above result.

That's odd. I only `gnome-software --quit; gnome-software` and it showed me the F36. Maybe the cache file (~/.cache/gnome-software/fedora-pkgdb-collections/fedora.json) has an old content, but the file is marked new enough to not trigger its download?

> What I can do, is try to wait some time and hope it will start working.

I would try:
1) Check the cache file
2) Move the cache file away, restart the gnome-software. it will trigger the file download.

> I do not think that upgrading from F34 to F35 and then to F35 is what 
> users would want to do (which is the only thing I am offered at the moment).

No no, I'm not suggesting anything like that. I only see it working here, but not for you.

FWIW, I tested this myself and didn't reproduce; I followed the steps in the test case on a clean F34 install, after changing the gsettings and rebooting, I got a notification in a couple of minutes. Clicking on it launched Software, which showed the upgrade to 36 (not 35).

There probably *is* a real issue here where it can show you 35 instead of 36 depending on some detail of cache timing or whatever, but I don't think that's really worth blocking the Beta release on. We don't honestly expect many people to really upgrade this way at Beta, it's more a case of us wanting to test that the underlying mechanism does work. We only really expect people to *use* it after the Final release, when they start seeing it without having to hack any gsettings settings. If you really want to upgrade early, it's probably easier to use `dnf system-upgrade` than do this twiddling to make the upgrade appear in Software...

> without having to hack any gsettings settings. If you really want to upgrade
> early, it's probably easier to use `dnf system-upgrade` than do this
> twiddling to make the upgrade appear in Software...

I am not saying I do not agree. I always use dnf for all software manipulation and updates/upgrades. The thing is there is the Beta Criterion for this specifically, as they are Beta tests in matrices that test exactly this scenario. Therefore I proposed it.

However, today after approximately 18 hours since last trying, when the VM got restarted again, I am being offered the Fedora 36 upgrade which is fine and this bug becomes sort of obsolete.

Right, what I'm trying to say is, I'd +1 a bug like "this flat out does not work at all, there is no way you can get GNOME Software to run the upgrade" but would tend to be -1 to any less clear-cut case like this. Though I might see if I can tweak the criteria to only require this to work at Final, in fact, it really does seem more appropriate that way.

Anyway, do you want to keep this bug open, or what?

-3 in https://pagure.io/fedora-qa/blocker-review/issue/678 , marking as rejected.

No need to keep this open. With the latest Beta candidate I did not have that problem, so I assume that the underlying condition has been fixed.