Description of problem: I booted the F38 KDE Plasma live images Fedora-KDE-Live-x86_64-38-20230318.n.0.iso and Fedora-KDE-Live-x86_64-38-20230320.n.0.iso in GNOME Boxes QEMU/KVM VMs. I created a new user with the standard account type in System Settings. I logged out of the liveuser session. I logged in as the second user from sddm. An update notification Updates available and the update widget in the System Tray was shown after a minute or two in the second user's session. This update notification wasn't shown in the liveuser session. The F38 final blocker criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." might be violated, but I'm unsure if that only applies to the liveuser's account. https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#Update_notification Version-Release number of selected component (if applicable): plasma-discover-5.27.3-1.fc38.x86_64 kf5-plasma-5.104.0-2.fc38.x86_64 qt5-qtbase-5.15.8-6.fc38.x86_64 How reproducible: I saw the update notification in at least 4 sessions of the second user which was most which lasted at least a minute. Steps to Reproduce: 1. Boot a F38 KDE Plasma installation updated to 2023-3-21 with updates-testing enabled 2. Log in to Plasma on Wayland 3. Install GNOME Boxes if it isn't already with sudo dnf install gnome-boxes 4. Download Fedora-KDE-Live-x86_64-38-20230320.n.0.iso from https://koji.fedoraproject.org/koji/buildinfo?buildID=2172856 5. Start GNOME Boxes 6. Boot Fedora-KDE-Live-x86_64-38-20230320.n.0.iso in a GNOME Boxes QEMU/KVM VM with EFI enabled, 3D acceleration disabled, 3 GiB RAM 7. Start System Settings in Plasma 5.27.3 on Wayland in the VM 8. Select Users in System Settings 9. Select Add New User in Users in System Settings 10. Create a new user with standard account type and a password 11. Close System Settings 12. Log out of Plasma from the Application Launcher menu's Leave menu 13. Log in to Plasma on Wayland as the second user that was created 14. When Plasma starts, wait until the update notification is shown which usually happened after a minute or two Actual results: Update notifications were shown for the second user created in F38 KDE Plasma live image VMs Expected results: Update notifications wouldn't be shown for the second user created in F38 KDE Plasma live image VMs Additional info:
Proposed as a Blocker and Freeze Exception for 38-final by Fedora user mattf using the blocker tracking app because: Update notifications were shown for the second user created in F38 KDE Plasma live image VMs. The F38 final blocker criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." might be violated, but I'm unsure if that only applies to the liveuser's account. https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#Update_notification
I'd say this isn't even really a bug. The customizations to the live environment are only done, and really can only be done, for the precreated user (liveuser). (I mean, you could imagine a mechanism to make them apply to newly-created accounts, but it would be a whole new feature that just doesn't exist, and quite a lot of development work for a corner case). They all apply to that user's config specifically. It's really not intended or envisaged that you create more user accounts in a live session. It's definitely not a blocker or FE, to me.
I only proposed this as a blocker based on the criterion's "...must not do so when running as a live image." The criterion could specify that only applies to the liveuser's session.
I created the second user in a VM running the live image Fedora-KDE-Live-x86_64-38-20230318.n.0.iso to reproduce the black screen problem on logout with the second user as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2179591
-5 blocker and -3 FE in https://pagure.io/fedora-qa/blocker-review/issue/1125 , marking rejected.
Re-assigning to livesys-scripts which I *guess* is the most logical place for this. I think we may just close it as WORKSFORME or WONTFIX, though.
This is pretty much by design. I'm not even certain how we could reliably do this properly for other users. I don't think we envisioned user creation happening in non-persistent live environments, either. And in a scenario where you have full-disk overlay persistence, then updates would make sense to expose and allow.
Let's just close this, I don't think we're gonna be doing anything about it.