[BUG] Import not showing Lutris

[dginovker]

Describe the bug According to the import documentation, selecting "Import and export", then clicking on the circle arrow will list available imports from Bottles/Lutris/POL. However, I am not seeing my Lutris games.

Installation

• Method: Flatpak
• Version: 2021.11.28-treviso

To Reproduce Steps to reproduce the behavior:

1. Install Lutris Battle for Middle Earth through the first option in the README here: https://github.com/Linux-BFME/Installers
2. Open Bottles, select "Import and export"
3. Click the refresh arrow
4. See no Lutris games

Expected behavior I would be able to import Lutris game into Bottles

Desktop (please complete the following information):

• OS: Arch Linux
• Display server: Xorg

Additional context The Lutris game is a custom one not displayed on the Lutris.net website. May be related?

[mirkobrombin]

Hi read this https://docs.usebottles.com/flatpak/expose-directories you need to give flatpak permissions to ~/Games path. 😁

[MiraiSubject]

Method: Flatpak Version: 2022.4.14-trento-2

I just went through this and I might be missing something. The prefix that Lutris uses is stored in /run/media/mmcblk0p1/PCGames/Game Name/wineprefix/

Here is the configuration in Lutris:

This is how I set up the directories in Flatseal:

I double checked it in the cli:

(deck@steamdeck ~)$ flatpak info com.usebottles.bottles --file-access=/home/deck/.var/app/net.lutris.Lutris/cache/lutris
read-write
(deck@steamdeck ~)$ flatpak info com.usebottles.bottles --file-access=/home/deck/.var/app/net.lutris.Lutris/config/lutris
read-write
(deck@steamdeck ~)$ flatpak info com.usebottles.bottles --file-access=/home/deck/.var/app/net.lutris.Lutris/data/lutris
read-write
(deck@steamdeck ~)$ flatpak info com.usebottles.bottles --file-access=/run/media/mmcblk0p1
read-write

When I press the refresh button in the import/export screen it says 0 prefixes found:

Gtk-Message: 15:17:42.090: Failed to load module "canberra-gtk-module"
(15:17:43) INFO Bottles Started! 
(15:17:43) INFO Performing Bottles checks... 
(15:17:43) INFO Dxvks found:
         - dxvk-1.10.1

(15:17:43) INFO Vkd3ds found:
         - vkd3d-proton-2.6

(15:17:43) INFO Nvapis found:
         - dxvk-nvapi-v0.5.4

(15:17:43) INFO Latencyflexs found:
         - latencyflex-v0.1.0

(15:17:43) INFO Runners found:
         - sys-wine-7.0
         - caffe-7.4

(15:17:48) INFO Found 0 wineprefixes… 

OS: Steam OS (Linux steamdeck 5.13.0-valve10.3-1-neptune-02176-g5fe416c4acd8 #1 SMP PREEMPT Wed, 23 Feb 2022 20:55:35 +0000 x86_64 GNU/Linux) Display Server: Xorg

Additional notes: read only on root filesystem is disabled

[mirkobrombin]

Bottles looks for Lutris prefixes in ~/Games. You can try to workaround this linking ~/Games to the right path

[MiraiSubject]

Made the symlink with ln -s /run/media/mmcblk0p1/PCGames/ /home/deck/Games

The prefix is now visible like this in Dolphin: /home/deck/Games/Hatsune Miku Project DIVA Arcade Future Tone/drive_c/so it should be in line with this: https://github.com/bottlesdevs/Bottles/blob/260c0d76c76278197a4e95cdf8fd52e4c3ba7b8f/src/backend/managers/importer.py#L70

I added the ~/Games entry to Flatseal as well:

However I still get no found prefixes:

(17:16:17) INFO Found 0 wineprefixes… 
(17:16:18) INFO Found 0 wineprefixes… 

After entering the shell of the flatpak using flatpak run --command=sh --devel com.usebottles.bottles I can see the directory correctly in ~:

[📦 com.usebottles.bottles ~]$ ls -lh
total 0
lrwxrwxrwx 1 deck deck 34 Apr 21 17:48 Games -> ../../run/media/mmcblk0p1/PCGames/
[📦 com.usebottles.bottles ~]$ 

I noticed from here https://github.com/bottlesdevs/Bottles/blob/260c0d76c76278197a4e95cdf8fd52e4c3ba7b8f/src/backend/globals.py#L79 that it queries XDG_DATA_HOME, so I queried the variable in the shell of the container and got this: /home/deck/.var/app/com.usebottles.bottles/data which definitely is not ~/ in the container.

So I did this instead from in my normal shell: ln -s /run/media/mmcblk0p1/PCGames/ /home/deck/.var/app/com.usebottles.bottles/data/Games and then as you can see below, it finally showed up.

So something is going wrong here, either in the code or in the documentation, maybe even with how XDG_DATA_HOME is defined inside the container or maybe it's even my device, I don't know, but it definitely did not read from ~/Games.

[mirkobrombin]

Try pointing to the full path instead of ~/Games

[MiraiSubject]

Doing /home/deck/Games instead of ~/Games yields nothing either. I tried again just now to sanity check, but I forgot to document that in my previous comment.

[mirkobrombin]

Mmh, weird. I'm able to list lutris prefixes in this way

[MiraiSubject]

I don't know if I can give you more information to get this problem solved (please let me know if I can!), but I have submitted a feature request/proposal as an alternative to all the fiddling with a hardcoded path.

[Ugzuzg]

I have the same issue. And looking at the code I find it weird that it works for @mirkobrombin. Here xdg_data_home is expected to resolve to Flatpak's overridden home: https://github.com/bottlesdevs/Bottles/blob/260c0d76c76278197a4e95cdf8fd52e4c3ba7b8f/src/backend/globals.py#L48

But here the same variable is used to look for external prefixes (but the files are in HOST_XDG_DATA_HOME, not XDG_DATA_HOME, so it doesn't work): https://github.com/bottlesdevs/Bottles/blob/260c0d76c76278197a4e95cdf8fd52e4c3ba7b8f/src/backend/globals.py#L78-L81

Flatpak also overrides the XDG environment variables to point sandboxed applications at their writable filesystem locations below ~/.var/app/$APPID/:

XDG_DATA_HOME XDG_CONFIG_HOME XDG_CACHE_HOME XDG_STATE_HOME (since Flatpak 1.13)

The host values of these variables are made available inside the sandbox via these HOST_-prefixed variables:

HOST_XDG_DATA_HOME HOST_XDG_CONFIG_HOME HOST_XDG_CACHE_HOME HOST_XDG_STATE_HOME (since Flatpak 1.13) -- https://docs.flatpak.org/en/latest/flatpak-command-reference.html

[mirkobrombin]

I had already noticed this problem, caused by a migration to xdg vars. I was sure I fixed it, I must have lost the changes for some reason.