Update to the very latest nightly version of BlastEm and restrict home directory access

[techmetx11]

This PR updates the BlastEm's source archive to the very last commit made (as of the time of this PR)

Also, the program has been patched to use the XDG Desktop Portal file chooser and enable it by default within the program's settings, which means the program no longer requires read-only access to the user's home directory.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

❌ Test build failed.

Help

• bot, build - Restart the test build
• bot, ping admins - Contact Flathub admins

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/252070/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-missing-vcs-browser-url' warning found in linter repo check. Details: Please consider adding a vcs-browser URL to the Metainfo file

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/252194/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/252240/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[techmetx11]

CC @hadess

[hadess]

We would definitely need to see separate patches (and reordering) for the build fixes, the version update, new dependencies, and applying the file chooser patch.

There's one big problem with this whole patch though, we only get access to the ROM file, and BlastEm expects to be able to access the directory the ROM is in to save the corresponding .SAV file when the game supports saves. This will be broken with this setup. What's the plan for fixing that?

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/260395/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[techmetx11]

There's one big problem with this whole patch though, we only get access to the ROM file, and BlastEm expects to be able to access the directory the ROM is in to save the corresponding .SAV file when the game supports saves. This will be broken with this setup. What's the plan for fixing that?

From what I can tell, BlastEm saves game files (if you're talking about EEPROM and SRAM files) in its own directory:

	#path template for saving SRAM, EEPROM and savestates
	#accepts special variables $HOME, $EXEDIR, $USERDATA, $ROMNAME
	save_path $USERDATA/blastem/$ROMNAME	#path template for saving SRAM, EEPROM and savestates
	#accepts special variables $HOME, $EXEDIR, $USERDATA, $ROMNAME
	save_path $USERDATA/blastem/$ROMNAME

Regardless, I'm already planning to patch BlastEm further to fix the screenshot, and VGM/video+audio recording paths (using the XDG user directory paths). If you can point out where it does this, I can also patch that

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/262985/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[hadess]

I've rebased the patches on top of the latest changes in the repo.

BlastEm is due a 1.0 release soon:
https://bsky.app/profile/retrodev.com/post/3mssyytxbhc2g
and your file chooser patches don't apply to the latest tip of the hg repo. Do you think you could rebase your patches?

Then we'd be ready for 1.0. Thanks!

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/311400/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[flathubbot]

🚧 Started test build.

[hadess]

Do you think you could rebase your patches?

It was my directory patch that needed updating, it builds correctly against today's tip!

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/311412/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

it's mine

[hadess]

I think I might have screwed something up, or the fact that the patches apply with quite a bit of fuzz means that it's not actually being enabled.

Short version is this doesn't seem to work.

[techmetx11]

There has been a bit of a problem with the file chooser approach. The developer of BlastEm told me that the Sega CD emulator accepts BIN/CUE files, (which loads CUE sheets that reference other files that it should open). Since the Desktop Portal API is too limited to do this properly, I'll need to do this in a way that might be the least infuriating for the user while not granting overreaching file permissions to the emulator

My idea was to allow for coarse folder access or maybe access to a specific library instead of asking for access to specific files, and then let the user access the specific files within the emulator's own file picker, just like RetroArch.

But, I wonder if you have some other idea to solve this problem? I really do not want to resort to granting BlastEm access to the entire user's home directory again.

[hadess]

There has been a bit of a problem with the file chooser approach. The developer of BlastEm told me that the Sega CD emulator accepts BIN/CUE files, (which loads CUE sheets that reference other files that it should open). Since the Desktop Portal API is too limited to do this properly, I'll need to do this in a way that might be the least infuriating for the user while not granting overreaching file permissions to the emulator

This is flatpak/xdg-desktop-portal#463

I really do not want to resort to granting BlastEm access to the entire user's home directory again.

I think there's nothing wrong with shipping with home directory access again, and those that think they don't need it can disable it in Flatseal for example. The filechooser codepath should still work when not sandboxed.

In the meanwhile, the problem I was reporting was that the portal code doesn't seem to be used, it just shows non-sandboxed data. I'll try to see if I need to rebase those patches.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/311503/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[hadess]

In the meanwhile, the problem I was reporting was that the portal code doesn't seem to be used, it just shows non-sandboxed data. I'll try to see if I need to rebase those patches.

Found the problem. Because I used older versions of BlastEm, it had already set the use_native_filechooser option somewhere to off. I think this should be hardcoded to on for the Flatpak.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/311511/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[hadess]

I've also tweaked the filters, I'm happier with those labels.

The only problem I've found now is that BlastEm locks up when calling out to xdg-desktop-portal, waiting on files to be selected, and that triggers the "application is not responding" popup from gnome-shell.

It's still better than using the internal file selection to me, so I'm going to merge those changes.

Can you please create a repo somewhere on GitHub when you could prepare this work to be integrated upstream? At the very least, it could be used to rebase those patches, as I'm sure we'll need in the future.

[hadess]

It's still better than using the internal file selection to me, so I'm going to merge those changes.

Hmm, it seems to cause lock ups in some cases. Can you please look into that?

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/311559/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/311566/com.retrodev.blastem.flatpakref

Built for x86_64 architecture.

[techmetx11]

Hmm, it seems to cause lock ups in some cases. Can you please look into that?

I can't reproduce this predictably. This might be a race condition (which doesn't sound too good)
Do you have a coredump of the program from when this happened?

[hadess]

I can't reproduce this predictably. This might be a race condition (which doesn't sound too good)

It's easy to reproduce. Launch BlastEm, click "Load ROM", move the filechooser window away (it's not correctly parented, and it runs in another process), and wait 10 seconds. The "not responding" popup will show while the filechooser is still open.

Do you have a coredump of the program from when this happened?

No, but my guess is that in your native_filechooser_pick() which spins the GLib mainloop, you probably also need to spin the SDL one, so that SDL can respond to ping events from the compositor/gnome-shell. Maybe something like https://stackoverflow.com/questions/38293820/integrate-sdl-into-glib-mainloop ?