Discussed during the 2020-09-28 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as we want confirmation that this bug only occurs with VNC sessions and that VNC is intended to be covered in the "default panel must function correctly" criterion.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-09-28/f33-blocker-review.2020-09-28-16.01.txt

After reading the bug, this seems to be by design. Remote unlocking would lead to the session being accessible to any user physically present at the original location. While surprising, refusing to unlock makes a lot of sense. The situation can be improved, either by design changes, or maybe better messages or documentation, but I don't think we should require to be done before release.

FinalBlocker -1

Regardless of whether it's a real bug or not, this seems to me to be stretching the criterion too far. We kinda should reconsider that criterion a bit for current GNOME, really; when it was written you couldn't really read it as covering "everything in Settings", given how GNOME 2 (which was current at the time) looked.

FinalBlocker -1

Only a problem with a tool that isn't even in the stock repo

FinalBlocker -1

Only a problem with a tool that isn't even in the stock repo

Either you're misunderstanding the bug or I'm misunderstanding your sentence. Please explain in detail.

VNC isn't important enough to delay the entire Fedora release

So, for me, this might be a partial violation of the basic functionality of GNOME Settings. Screen sharing is a part of Settings, so I expect it to work at least basically. The problem here is that the vino server crashes on client disconnect and then you can't reconnect again. I've just verified this myself, only the first connection works (if it is not successful, you're out of luck, no second connection is possible). I met this problem several times in the past, but never forced myself to report it. The outcome is, however, that screen sharing works only once and then becomes broken. I'd consider it a pretty major wrinkle in screen sharing basic functionality. So at the moment, I'm leaning towards:

FinalBlocker +1

The upstream decision to disallow remote session unlocking is an unfortunate decision, because it's a regression and it kills the major use case for VNC functionality - to work remotely. However, since it is an upstream decision and not a bug, we can't block on it. I'll just flag it with CommonBugs to highlight the change.

But I'd still prefer to block on that crash. Thoughts?

The problem here is that the vino server crashes on client disconnect and then you can't reconnect again.

vino shouldn't be in F33 at all. This was an oversight. I've just mailed the package maintainer to ask that it be retired from rawhide. Justification here.

vino shouldn't be in F33 at all. This was an oversight. I've just mailed the package maintainer to ask that it be retired from rawhide. Justification here.

I'm sorry, I was typing blind, I didn't actually mean vino-server. I meant "the process which makes it possible to connect via vnc" :-) Which actually is gnome-remote-desktop, yes. Thanks for correction.

AGREED AcceptedFinalBlocker

Discussed during the 2020-10-05 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"All applications that can be launched...after a default installation of Fedora Workstation...must start successfully and withstand a basic functionality test", counting screen sharing as part of Settings, as the crash means only one screen sharing session can be attempted, after which the server crashes and all subsequent attempts will fail.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-10-05/f33-blocker-review.2020-10-05-16.00.txt

The following votes have been closed:

• Accepted FinalBlocker (+1, 0, -3)
  • +1 by kparal
  • -1 by zbyszek, adamwill, kleinkravis

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