PoC Flatpak packaging

[tinywrkb]

This is a quick Flatpak packaging, and without much testing.

As far as I can tell, this would be mostly useful for remote debugging, and debugging with the Flatpak runtime.

I'm not sure how GDBFrontend works, but maybe it would be also possible to access GDB on the host using a host running tmux session. I haven't tried this as I don't have GDB on the host, and my system is immutable.
Another possible alternative is to have a flatpak-spawn wrapper executing GDB from the host, and have GDBFrontend select the wrapper instead of the default GDB executable.

A few notes about the packaging:

• Tmux vars were unsetted as I'm running a tmux session on the host and this seems to break GDBFrontend.
• The app is using the Freedesktop SDK as the runtime, but with the --runtime option, it's possible to run the app with another Flatpak SDK that is based on the same version of the Freedesktop SDK.
• The home filesystem access might seem superfluous, but some of us users globally block permissive permissions, so I think that being explicit is more correct.
• An AppStream appdata/metainfo should be added.
• Maybe also add a desktop file and icon.
• It's likely you would want to set the app-id as com.oguzhaneroglu.GDBFrontend.

[rohanrhu]

Hi, thank you for your contribution. I've never used Flatpak before so I don't know how it works.

What should I add to README.md to describe installing it with Flatpak?

• Maybe also add a desktop file and icon.

Yes, I'm planning to make a manager that places into system tray. Creating different debugger sessions would be easier with a manager that is running at system tray, we would easily create different sessions with setting their port and tmux terminal IDs.

I really don't have any idea how Flatpak and its packages work. In this situation, what we should do?

[tinywrkb]

What should I add to README.md to describe installing it with Flatpak?

I wouldn't recommend it to users. This is more for evaluating the Flatpak packaging and the usefulness of the app when packaged as a Flatpak.
If or when it's considered production ready, then it should be published via Flathub.org.

Anyway, building is quite simple, you just need Flatpak-Builder and the Freedesktop SDK. So something like this:

# Arch Linux
sudo pacman -S flatpak flatpak-builder

# Fedora
sudo dnf install flatpak flatpak-builder

# Debian/Ubuntu
sudo apt install flatpak flatpak-builder

# Install the SDK
flatpak install flathub org.freedesktop.Sdk//21.08

# get Flatpak manifest
git clone https://github.com/tinywrkb/flatpaks.git
git submodule update --init

# build and install the app
cd flatpaks/com.oguzhaneroglu.gdb-frontend
flatpak-builder --install --user --force-clean build/flatpak-target com.oguzhaneroglu.gdb-frontend.yaml

# you can also set the state dir and add the app to a local repo
flatpak-builder --install --user --force-clean --state-dir=build/flatpak-builder --repo=build/flatpak-repo build/flatpak-target com.oguzhaneroglu.gdb-frontend.yaml

# run the app, you can also add some overrides, see flatpak-override.1 man page
flatpak run com.oguzhaneroglu.gdb-frontend

# or if your distro correctly appends the Flatpak bin exports dir to your PATH var then just run
com.oguzhaneroglu.gdb-frontend

[rohanrhu]

Thank you. So you mean It should be published on flathub.org?

I'm going to test the package. I will let you know the result.

[tinywrkb]

Thank you. So you mean It should be published on flathub.org?

Correct.

Yes, I'm planning to make a manager that places into system tray.

This would be a pretty nice feature to have, and this desktop integration would make a good case of why Flatpak packaging is fitted for the app.

Creating different debugger sessions would be easier with a manager that is running at system tray, we would easily create different sessions with setting their port and tmux terminal IDs.

It might be worth looking into flatpak-spawn if you want to start multiple instances of the app instead of multiple processes in a single Flatpak app instance.

[rohanrhu]

Sorry for delay. I will look at this soon.

What does flatpak-spawn provide us? We are currently able to create different sessions with different ports and tmux IDs. I never looked at Flatpak, I don't know how it works. When we install it with Flatpak, how different it will be than creating instances with gdbfrontend -p PORT -t IDs?

[tinywrkb]

Let's say you have one session of gdbfrontend 1 already running in a Flatpak gdbfrontend app instance A.
The instance also have a status bar indicator associated with it.
Now the user start another Flatpak gdbfrontend frontend instance B, will it continue running as a gdbfrontend session 2, or will it communicate to the session 1 that the user request another session, and immediately quit, letting session 1 forking and creating session 2 as a process under the Flatpak instance A? Remember that Flatpak uses IPC PID namespaces.

If you let Flatpak instance B to continue running, and session 2 is not created under Flatpak instance A, then how do replicate this behavior when the user wants to create another gdbfrontend session from the menu of the status bar indicator? or from the webuן of gdbfrontend instance 1?
The answer is flatpak-spawn.

[rohanrhu]

The instance also have a status bar indicator associated with it.

You mean Flatpak already has a status bar indicator for apps?

As I understand (I maybe wrong) Flatpak has a kind of capsulation for apps? I meant I will make a session manager that allows us creating multiple sessions without command line; a tray icon that has a menu to manage running debugger sessions and create new ones.

I will check it out soon. Thank you again for packaging!

[tinywrkb]

You mean Flatpak already has a status bar indicator for apps?

No, I was referring to this

I'm planning to make a manager that places into system tray.

As I understand (I maybe wrong) Flatpak has a kind of capsulation for apps?

It uses user namespaces, specifically, you need to take in consideration the fact you have a different PID namespace for each Flatpak instance of the app.

[rohanrhu]

It uses user namespaces, specifically, you need to take in consideration the fact you have a different PID namespace for each Flatpak instance of the app.

Session manager will have a PID and it will spawn processes for debugger sessions. So I don't think that we need something from Flatpak for spawning debugger sessions.

When we close the session manager, it will send SIGTERM to debugger session processes.

[tinywrkb]

If only a single session manager will be allowed to exist, then there's no need to worry about having multiple Flatpak instance of the app, and all the debugger sessions will be created in the same Flatpak instance / same PID namespace.

[rohanrhu]

If only a single session manager will be allowed to exist, then there's no need to worry about having multiple Flatpak instance of the app, and all the debugger sessions will be created in the same Flatpak instance / same PID namespace.

I will make a session manager with Qt but I'm using Windows 11/WSL2. WSLg doesn't support tray icons for now xD but I will make it on Linux soon.

Also I will publish the Flatpak package soon.

[tinywrkb]

I haven't coded anything with Qt, so I'm not exactly sure how Qt is handling the status icon, but from my experience as a user and looking at D-Bus (with Bustle, D-Feet), I can tell you the following.

Make sure to use a reverse DNS naming scheme as a prefix for the tray icon name, so it will be exported by Flatpak and be available to the host as part of the icon theme.
So if the app ID is com.oguzhaneroglu.GDBFrontend, then the status bar icon can be called com.oguzhaneroglu.GDBFrontend-status, or com.oguzhaneroglu.GDBFrontend.status, or com.oguzhaneroglu.GDBFrontend.status-active, etc.

Without doing so, users with status bars that don't support the old XEmbed protocol, and using instead the StatusNotifierItem (SNI) protocol, might not see the icon and will have a default blank icon.

SNI is using D-Bus as IPC, and from what I've seen it can handle a status icon as a pixmap element in D-Bus, a name of an icon from the icon theme (why the icon should be exported), and the full path to an icon file.

In the latter case, it's possible that the icon file path will only be accessible from the Flatpak sandbox, and not from the host, and then the status bar won't display the icon correctly.

Again, I'm not exactly sure what Qt is doing, but I'm guessing here that it probably would be best to load the icon with QIcon::fromTheme.

As one who uses Waybar, I had too many issues with SNI and Qt5 apps, and while I should, I didn't look further into this.

I believe that KDE users shouldn't be affected as it ships with XEmbed to SNI proxy, but Gnome users might, and definitely users like me who use a Wayland window manager instead of a desktop environment.

If you need further guidance and recommendations, then I suggest dropping by the #flatpak Matrix channel.

[rohanrhu]

In the latter case, it's possible that the icon file path will only be accessible from the Flatpak sandbox, and not from the host, and then the status bar won't display the icon correctly.

So, we don't have any way to use Flatpak for only installation of our app? What if we don't want any sandbox stuff?

If you need further guidance and recommendations, then I suggest dropping by the #flatpak Matrix channel.

Yes.. I will ask about it. Thank you again.

[rohanrhu]

Hiiii again @tinywrkb sorry for late response but I don't much time 😿

Could you publish this Flatpak package somehow? Otherwise, I had to understand how Flatpak works exactly. As I remember, it is doing a kind of isolation but I don't know exactly.

I would be happy if you could contribute about publishing the Flatpak package.