I'm not sure about this one because some of the third-party repos do not distribute appstream metadata, which means they are expected to be broken. It's a design failure of fedora-workstation-repositories. I'd like to hear more from Milan regarding which apps are expected to be visible and which are not.

@catanzaro I expect PyCharm might be the case you're talking about (and I don't expect we block on this). The other apps are visible, just not immediately (except Chrome). Milan seems to have already found the root cause in https://bugzilla.redhat.com/show_bug.cgi?id=2010740#c9 and https://bugzilla.redhat.com/show_bug.cgi?id=2010740#c7 . I believe that's the issue we should discuss - whether we should block on apps not showing immediately in a search, but only after a day passes since the repo is enabled.

My take on this is: If I enable third party repos (which is even very prominently featured in the initial setup!), I expect the software to be then available. It isn't. Making it available a day later doesn't help. For these purposes I consider the "repo enable" feature simply broken, and seems to me as a pretty basic functionality, especially given how prominent the 3rd party repos are. It's similar to enabling a repo through dnf, but dnf searching in that repo only a day later.

FinalBlocker +1

FinalBlocker +1

FinalBlocker +1

OK, @kparal convinced me. We could also argue this under the requirement "each page or panel of the initial setup utility should withstand a basic functionality test" - there is a page whose sole job is to enable third party repos.
FinalBlocker +1

AGREED AcceptedFinalBlocker

The following votes have been closed:

• Accepted FinalBlocker (+4, 0, -0)
  • +1 by kparal, catanzaro, bcotton, adamwill

I'm afraid I'm still +1. This feature is important and needs to work reliably for new installs using the GA version of GNOME Software.

In case it's not obvious from the above, we are doing a:

REVOTE FinalBlocker

...because this seems to be not fully fixed in RC1. It fails about half the time, we think.
@catanzaro, for your vote to count, you'll need to comment again in the correct form after this comment.

FinalBlocker +1

:/

FinalBlocker +1

However, it would be nice it somebody except me could confirm this. @lruzicka tried already several times, and it worked for him each time. I'm not sure why all the race conditions happen just to me.

When testing this, finish the installation, power down the VM and make a snapshot. This way you can quickly test 5-10 first-boot cycles, just revert to the snapshot each time. During first boot, simply enable 3rd party repos in g-i-s, then immediately start gnome-software and search for nvidia+steam once you can. If you can't find them, try to find them using pkcon search [Steam|nvidia].

Tried many times (in vm, on bare metal, on uefi vs legacy, with different locales), didn't happen a single time to me.

FinalBlocker -1

This is a funny bug because it only appears from time to time (I did not see it a single time when trying to catch it yesterday). I think this would be a good candidate for a Common Bugs record, because it could easily be worked around and if not, it will go away on its own, once the package and the repository info refresh, I believe. Some users will not even notice it.

Therefore, I am more like

FinalBlocker -1

it will go away on its own, once the package and the repository info refresh, I believe

Yes, it will fix itself after a day or two. However, especially Nvidia users will likely want to install the drivers as the first thing after system install. And gamers will of course want Steam soon after install as well.

I'm quite surprised that you can't hit it at all.

I did try with multiple snapshots and I did hit it only once. Reverting same snapshot about 8 times and hitting it once isn't so bad, as @lruzicka points the workaround is clicks away. I am sure most users won't notice it.

I am leaning to

FinalBlocker -1

Changing my vote based on the comments above:

FinalBlocker -1

I'm happy that you're so lucky, folks, but remember that this is a race condition, and so your results might not have any statistical significance (neither mine). We simply have no estimation on how often people will hit this.

I just did 10 attempts, and the searched worked as excepted only once.

It seems this could be easily fixed by running pkcon refresh force at the end of fedora-third-party script. Which might be even the correct technical solution. But yes, we'd slip a week.

FinalBlocker +1

I've tried 9 times this morning, hit the bug 4 times.
FinalBlocker +1

Changing my vote based on the comments above:

Sorry for the flip-flopping, but I've been persuaded to change my vote yet again:

I'm afraid I'm still +1. This feature is important and needs to work reliably for new installs using the GA version of GNOME Software.

I was right yesterday. "It works half the time" is not good enough. Slipping another week is not the end of the world.

FinalBlocker +1

Release F35 is no longer tracked by BlockerBugs, closing this ticket.