Fedora Account System
Red Hat Associate
Red Hat Customer
After upgrading to F45, previously working Fractal installed from flatpak cannot unlock the secret backend, citing missing secret portal. In previous version I didn't need to do anything to use Fractal, so the switching to oo7 broke working setup and might be hard to fix for normal users. I think oo7-portal should be recommended by oo7-daemon. Reproducible: Always
Proposed as a Blocker for 45-final by Fedora user kanru using the blocker tracking app because: Breaks the Desktop keyring criteria. Flatpak application (Fractal in my case) is unable to unlock the keyring. I'm not sure whether flatpak applications should be counted as blocking though. https://fedoraproject.org/wiki/Fedora_45_Final_Release_Criteria#Desktop_keyring
> I think oo7-portal should be recommended by oo7-daemon. I don't think Recommends would be enough here. In many situations, weak dependencies aren't considered, so they're usually not a good way to ensure things are installed. CC Neal who implemented the DE integrations of oo7.
> In many situations, weak dependencies aren't considered Such as what? Weak deps are followed for new installs, and new weak deps should be followed for upgrades.
For example, in build environments, weak dependencies are not pulled in. And I don't know if weak dependencies are always active for image builds, either.
AGREED AcceptedFinalBlocker Discussed at the 2026-09-21 (blocker / freeze exception) review meeting: This is accepted as a violation of "Saving passwords to and retrieving passwords from the default keyring must work for all release-blocking desktops" for upgraded systems https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-09-21/f45-blocker-review.2026-09-21-16.01.log.txt
Fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2026-324f1dc298, hopefully? Can we close this?
How does gnome-session-51.0-1.fc45 fix the issue? I have gnome-session-51.0-1.fc45 installed: $ rpm -qa gnome-session gnome-session-51.0-1.fc45.x86_64 oo7-daemon is running: $ ps aux|grep oo7 kanru 15869 0.0 0.0 767536 13520 ? Ssl 23:18 0:00 /usr/libexec/oo7-daemon However Fractal still shows Secret Portal Error Could not restore previous sessions The secret storage file is corrupted.
Created attachment 2158343 [details] Screenshot showing Fractal error
Michael, I don't see why you think that update would fix it either? That update fixes the problem of the daemon not being started with the user's session, but this bug isn't about that. This bug seems to be about oo7-portal (not oo7-daemon) being needed for Flatpak apps to be able to access secrets, but it not getting installed on upgrade. I don't see any indication that there was a dep change in the 51 final update that would cause it to be pulled in?
oo7-portal doesn't appear to be in Silverblue either, currently, which may be why flatpak Element shows me an error when I run it: "Your system has a supported keyring but encryption is not available. Electron has detected that encryption is not available on your keyring gnome_libsecret. Please ensure that you have the keyring installed. If you do have the keyring installed, please reboot and try again."
gdm requires pam_oo7, which requires oo7-daemon, so we get oo7-daemon in GNOME installs. But the only thing that requires oo7-portal is budgie-desktop. Nothing recommends or suggests it, either. So there's nothing to make it get installed AFAICS.
As discussed during the blocker review meeting, we'll need to add Supplements and / or Requires accordingly. This is planned but not done yet. Currently working through dependency slog to be able to update oo7 from 0.7.0.alpha to 0.7.0.beta ...
Thanks for handling this. I don't understand why there are so many subpackages here. I see that the PAM config needs to be separate. Not sure why oo7-daemon and oo7-portal have to be separate. Sure they implement different interfaces, but seems unlikely that anybody would ever want one without the other. Is there a reason why Supplements would work but Recommends would not? That seems weird? Our tools should be respecting Recommends for both new installs and upgrades, and certainly the difference between Recommends vs. Supplements should not be significant?
I have since asked Neal about whether our image build tooling handles weak dependencies, and indeed it does. So Supplements and Recommends both should work. As to why there are subpackages ... I just wanted to be nice and do "the right thing" and split independent components into separate packages. In hindsight, splitting -daemon and -portal might have been too much, but adding the necessary Requires and Supplements will address this too.
FEDORA-2026-c52c1c8cbe (oo7-0.7.0~beta-1.fc45, rust-zbus-5.19.0-1.fc45, and 7 more) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-c52c1c8cbe
FEDORA-2026-c52c1c8cbe has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-c52c1c8cbe` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-c52c1c8cbe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.