Flatpak related issues

Bugs and issues Linux
#1

I posted in the Flatpak request thread but received no response, and tried my luck getting a response from the dev team via email but that didn’t work also, so I hope I’ll get more feedback by posting here.

I’m packaging Insync as a Flatpak for myself (see here) but if the issues will be resolved then it can be picked up for distributing via Flathub.org.

Blocking issues: must be fixed or get workarounds

  1. Traybar status icon is missing. /usr/share/icons/hicolor/48x48/status is probably hardcoded, Insync is not considering $XDG_DATA_DIRS.
    /usr/share/ and /usr/share/runtime/share are from the Flatpak runtime while /app/share is from the Flatpak packaged app. So Insync should at least also check /app/share/.
    I was able to confirm that the problem is with /usr/share being the only path used for looking up the icons by injecting them into the Flatpak runtime (changing the filesystem), updating the icons cache, and watch the status icon appear.

  2. The use of Unix file socket at /tmp/insync${UID}.sock to check if another Insync instance already running and communicate with file-manager extensions.
    I believe this should be changed to a Linux named socket that could be shared across the network (edit:) namespace, accessible to the host, and other Flatpak applications (that could be file-managers).

Not blocking but would nice to have:

  1. Check $XDG_CONFIG_HOME value before defaulting to ~/.config/Insync as the settings folder.

Please consider fixing these issues.
It’s very easy to build and install the Flatpak package.

flatpak instal flathub org.gnome.Sdk//3.36
flatpak-builder --install --user --force-clean --state-dir=build/flatpak-builder --repo=build/flatpak-repo build/flatpak-target com.insynchq.insync.yaml

#2

Hi @tinywrkb, thanks for your efforts, it’s a pity you are not getting answered here either :worried:

1 Like
#3

Two other alternatives for the Unix file socket:

  1. Instead of hard-coding the socket path as /tmp/insync${UID}.sock use instead $TMPDIR/insync${UID}.sock and fall back to /tmp/insync${UID}.sock if $TMPDIR is empty or does not exist.

  2. Use d-bus instead.

#4

I noticed a similar status icon issue with another QT5 app so I’m guessing the same workaround I used for the other app could be applied to Insync.
My guess is that Insync is loading the status icons from an hardcoded path that isn’t available on Flatpak as Insync is installed at /app.
So instead, I suggest that Insync would use QIcon::fromTheme to load icons for the status bar and that should solve the issue, at least as long as icons were exported by Flatpak, meaning they should have the AppData app-id as a prefix, e.g. com.insynchq.insync.status-alert.png and trayIcon->setIcon(QIcon::fromTheme("com.insynchq.insync.status-alert"));

#5

Considering the lack of response from an informed Insync representative, I’m posting here my last opinion on the matter.
I don’t think anyone that is not an Insync developer should put any effort into trying to publish a Flatpak package on Flathub before these issues are resolved.

There are blocking issues:

  1. No system status icon. Probably can be easily solved by Insync if they would load a pixmap instead of using a file path and this change should have zero negative affect.
    A solution that will be also compatible with desktop icon themes is to use the Freedesktop icon naming (with QIcon::fromTheme) but this means it should follow the Flatpak guidelines for icon exports by using the AppData app-id as a prefix.

  2. Using an IPC for communicating between the Insync daemon to file manager extensions that can compatible with both host applications and Flatpak applications. The current Unix file socket at /tmp is terrible for Flatpak, it means every packaged Flatpak file manager that wants to use the Insync extension would need to add /tmp filesystem permission, and I don’t see this happening.
    My suggestion is to use D-Bus, it should be perfect for this. It should be possible to also a Linux named socket without making much changes to the code, but I’m not sure this is a great idea security-wise, and it will break in the future when Flatpak will have network namespaces capability.

If both these will be solved then Insync will be ready for being packaged as a Flatpak package.

1 Like
#6

Thanks for investigating this @tinywrkb.

I hope the devs will take a look at your findings at some point and implement this feature.

It’s being a while since their last word on that matter AFAIK.

#7

After looking at the tray icon problem in a different application I think I found another workaround that requires minimal changes to Insync’s code.

I don’t have access to Insync’s code but I’m guessing it’s doing something like
trayIcon->setIcon(QIcon("/usr/share/icons/hicolor/48x48/status/insync-normal.png"))

There are two problems with this:

  1. /usr is where the runtime lives while /app is for the app, so the status icons are not in /usr.
  2. When setIcon method is used like that (and not with QIcon::fromTheme) it creates an icon file in $XDG_RUNTIME_DIR/qt-trayicon-XXXXX.png and set this path as the value of IconName in the D-Bus interface. This path is not accessible on the host so the system tray app can not load the icon.

The workaround for 2. is to set XDG_RUNTIME_DIR as a path that is accessible on the host, I settled on export XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR/app/$FLATPAK_ID, and so far it doesn’t seem to break anything. This is a change to the Flatpak packaging, no Insync code change is needed. edit: this seems to break Wayland but I think it’s acceptable a a temporary solution.

A possible workaround for 1. would be to test if /usr/share/icons/hicolor/48x48/status/insync-*.png are available, and if not to try /app/share/icons/hicolor/48x48/status/insync-*.png. This should be a pretty minimal change to Insync’s code, that’s if my guess about the current implementation is correct.

#8

@tinywrkb I’m currently trying to package insync as a nix-package. Having it would make not having a flatpak less painful, because using nix, it could also be installed on any distro. Plus: Nix is not sandboxed and this should make it a bit easier. But not yet successful as well: NixOS? Portable insync?

#9

@VanCoding This got nothing to do with the Flatpak issues. I believe the issue you’re experiencing is due to insync-headless testing the real path of insync-headless executable so it must be running from /usr/lib/insync/insync-headless.
I also notice this because I’m maintaining the AUR package for insync-headless and wanted to not have it conflict with insync and installed under /usr/lib/insync-headless but to no avail. I reported it but this is the answer I received.

I personally will be moving my insync-headless installation into a container (Podman) as I only need this on my server and not in my base image so I lost the interest to nag the InsyncHQ about this.

#10

@tinywrkb Thank you, that’s really helpful! If really that is the problem, that I probably can work around this :slight_smile:

Docker of course is also a good solution. It won’t work for the GUI version though, if I’m not mistaken.

#11

Actually, for my needs, the desktop Insync version is working fine through Flatpak, but it’s not something that can be considered ready for shipping via Flathub due to the mentioned issues reported here.

#12

I had to remove my config folder this week and noticed that I forget to mention another bug.
Basically there’s an issue where it’s not possible to choose a folder via the XDG File Portal.
I’m not sure if this is only affecting QT5 apps.

The workaround for this is to set FileDialog::DontUseNativeDialog as false when needing to select a folder, specifically in the account setting/new account wizard when choosing the local Insync folder for the account.

See more details in the Flatpak documentation here: https://docs.flatpak.org/en/latest/portals-qt.html

As users we don’t have access to Insync’s code so we can’t fix that but possible non-code workarounds:

  • Edit the sqlite DB ~/.config/Insync/data/gd-*.db directly and update the folder path.
  • Create a symlink in the default path location to wherever you want to put that folder. With proper Flatpak filesystem override settings you should be able to have the symlink buried under ~/.var while the actual target would be in a more sane location, like `~/public/google-drive’