Description of problem: Hello, this can happen with the prerelease images of Sway or vanilla workstation. If I install the sway spin, having sway alone, the portals seem to work fine, but if I install gnome-shell (which will bring xdg-desktop-portal-gnome), then I keep getting these messages in my log and have no portal (so gtk apps and flatpaks are useless) Log messages https://ibb.co/RQL5nCY Version-Release number of selected component (if applicable): 38 How reproducible: Steps to Reproduce: 1. Install Workstation 38 2. Install sway 3. Log in sway session Actual results: Waybar waits the portal to timeout to start, flatpaks too and when they open, they cant do much Expected results: Desktop portals to work so apps dependent on them too Additional info:
Does it help if you apply https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/78?
(In reply to Jonas Ådahl from comment #1) > Does it help if you apply > https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/78? I tried editing the service file of the commit, it alone didnt work. The other patch I'm not sure I know how to apply on my VM
The patch worked, it seems the whole patch including the C part is needed. I built the package in copr with the patch, now xdg-desktop-portal service starts up correctly https://copr.fedorainfracloud.org/coprs/jackorp/xdg-desktop-portal-gnome-mr78-gitlab/ And it seems like apps are now working and starting up correctly.
(In reply to Jarek Prokop from comment #3) > The patch worked, it seems the whole patch including the C part is needed. > > I built the package in copr with the patch, now xdg-desktop-portal service > starts up correctly > https://copr.fedorainfracloud.org/coprs/jackorp/xdg-desktop-portal-gnome- > mr78-gitlab/ > > And it seems like apps are now working and starting up correctly. I cant enable the copr on a Fedora 38 install, but I'm happy it indeed solve the problem, thanks for testing it, will try to test the beta once this fix make into the oficials repos I'm not sure how to close this one here, so I'll leave it for you Thank you
> I cant enable the copr on a Fedora 38 install Sorry, I am on rawhide and minimized used buildroots to what I use. I have extended the available buildroots (for testing), but I'd advise waiting for official build as that should cause you less trouble down the road.
Just confirmed that the copr fixed the sway session (waybar doesnt wait the portal to timeout) but the flatpak I tested didnt work. I tried using bottles to install a software but the file picker wont show up. Keeps showing that xdg-desktop-portal-gnome failed to start Logs https://ibb.co/CVFYNn0
Could you also try https://koji.fedoraproject.org/koji/taskinfo?taskID=98648806 ?
(In reply to Jonas Ådahl from comment #7) > Could you also try > https://koji.fedoraproject.org/koji/taskinfo?taskID=98648806 ? That seemed to work, the flatpak can now use a file picker, is there anything else I should make sure to test for you guys ? (regarding the portals) I still see gnome portal trying to start and failing multiple times (eventually it seems to stop trying), dont know if this is expected. I noticed theres a difference between using bottles in the sway session and the gnome session. The file picker uses the new layout in the gnome session and the gtk3 in the sway session, is this expected ? (just asking because I dont know what to expect haha)
> That seemed to work, the flatpak can now use a file picker, is there anything else I should make sure to test for you guys ? (regarding the portals) Testing portals in general would always be good, but the fact that the file picker shows up is a good sign. I suspect the portal frontend (xdg-desktop-portal) eventually finds xdg-desktop-portal-gtk as a fallback. > I still see gnome portal trying to start and failing multiple times (eventually it seems to stop trying), dont know if this is expected. That is because the portal frontend tries all the installed portals one by one until it finds something suitable. xdg-desktop-portal-gnome now requires running under a GNOME session, and will refuse to start outside of it, because it depends on a somewhat awkward X11 compatibility Wayland protocol for doing cross windowing system and process window stacking. The patch that was put in that scratch build checks that the portal backend actually managed to launch - before it blindly assumed it worked and wouldn't try any other backend implementation. > I noticed theres a difference between using bottles in the sway session and the gnome session. The file picker uses the new layout in the gnome session and the gtk3 in the sway session, is this expected ? (just asking because I dont know what to expect haha) Yes, that's more or less the point of the change in that build - fall back on xdg-desktop-portal-gtk (gtk3) instead of completely bailing due to xdg-desktop-portal-gnome currently can only manage to in a GNOME session.
> Testing portals in general would always be good, but the fact that the file picker shows up is a good sign. I suspect the portal frontend (xdg-desktop-portal) eventually finds xdg-desktop-portal-gtk as a fallback. I meant as if you know if another portal would probably be affected by this. Thinking of it, I dont recall another obvious graphical portal functionality to test Regarding the difference in style, what changed between the portals in 37 and 38 that they dont "share" the same stylesheet ? Because I tested in my main machine and the file picker for the flatpak is with the "updated" style, just curiosity. Thank you for your time and support
> I meant as if you know if another portal would probably be affected by this. Thinking of it, I dont recall another obvious graphical portal functionality to test Try the screen cast portal, e.g. share a screen via Firefox; that one is provided by xdg-desktop-portal-wlr, so if can be good to make sure it still works. > what changed between the portals in 37 and 38 that they dont "share" the same stylesheet In 37 tbh I don't know what portal you got, but now you get xdg-desktop-portal-gtk, which is gtk3.
The screencast portal worked fine. Apparently these will be good to close this issue. In 37 I have these installed libportal.x86_64 0.6-3.fc37 @anaconda libportal-gtk3.x86_64 0.6-3.fc37 @anaconda libportal-gtk4.x86_64 0.6-3.fc37 @anaconda xdg-desktop-portal.x86_64 1.15.0-4.fc37 @updates xdg-desktop-portal-gnome.x86_64 43.1-1.fc37 @anaconda xdg-desktop-portal-gtk.x86_64 1.14.1-1.fc37 @updates xdg-desktop-portal-wlr.x86_64 0.6.0-3.fc37 @updates And both sessions worked from a clean install. Funny enough, the xdg-desktop-portal-gnome is working on my sway session without additional setup. Just on Fedora 38 it seems to do something different
> Just on Fedora 38 it seems to do something different Yea, the difference is that we had to turn on hardware acceleration in GNOME 44 and that needed non-trivial changes to how Wayland and X11 interacts with each other, and that requires some special sauce making it only work in a GNOME session.
(In reply to Jonas Ådahl from comment #13) > > Just on Fedora 38 it seems to do something different > > Yea, the difference is that we had to turn on hardware acceleration in GNOME > 44 and that needed non-trivial changes to how Wayland and X11 interacts with > each other, and that requires some special sauce making it only work in a > GNOME session. I see, thank you for your patience and time.
There is a related issue reported in Bug 2176759, also due to xdg-desktop-portal not starting.
Hello Everyone, I apologize for dragging on this issue for longer, but I believe I may have come against a very similar issue using i3 on Fedora 37. I migrated from GNOME and fedora-release-identity-workstation to fedora-release-identity-basic, erasing almost all GNOME packages from my system. Even though XDG_CURRENT_DESKTOP is set as "i3", almost all of my flatpak apps try to use xdg-desktop-portal-gnome with the same error message as this bug. I'm clueless as to what environment variable or config might be causing this and felt like asking here might be a good try. I have been redirected here following this issue on the com.discordapp.Discord flathub package : (https://github.com/flathub/com.discordapp.Discord/issues/284)
What you're describing is likely a known limitation of xdg-desktop-portal, and how it selects portal backends. While https://github.com/flatpak/xdg-desktop-portal/pull/985 helps in F38, it's unlikely to make a difference in F37. Eventually this will hopefully be fixable more properly once https://github.com/flatpak/xdg-desktop-portal/pull/955 lands and reaches hopefully the next Fedora release.
Thank you for pushing me in the right direction. It feels much better to know why this is happening. I'm hoping the next fedora release comes sooner than later.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.