hadess
hadess
> Here is a complete list of apps with `--talk-name=org.gtk.vfs.*`, maybe it helps I'm fairly certain most of them don't need to talk to gvfs...
Cozy doesn't need the change: https://github.com/flathub/com.github.geigi.cozy/issues/4 DejaDup doesn't need the change: https://github.com/flathub/org.gnome.DejaDup/issues/12 Handbrake fixed in https://github.com/flathub/fr.handbrake.ghb/commit/b5ac0a5a8e24704235af3688b8891e22e5894224 FreeCAD, timetrack, Daty, trenchboom, blastem, itopia, and thincast don't need the change.
(We also found that `--talk-name=org.gtk.vfs` did nothing [because there wasn't ever a daemon with that name on the other side of the bus](https://github.com/flathub/org.gnome.DejaDup/issues/12#issuecomment-811976066), I'm not sure whether folks would appreciate...
I've added documentation at https://docs.flatpak.org/en/latest/sandbox-permissions.html#gvfs-access if anyone if still curious about the options.
Tried installing with `yum` instead of `rpm`?
I have no idea how @ssaavedra generated those. They might not be installable if the proprietary binaries are built against newer versions.
> maybe the libstdc++ compatibility is automatically picked up by the rpm linter from the binaries' ldd result? That's exactly what it does. You'll need to get newer versions of...
> I don't have the sources from DisplayLink, I can do nothing about the binary itself. Should we bundle an older stdlibc++ or what kind of workaround are you thinking...
> To be clear, does this mean that displaylink needs a newer libstdc++ than it is currently provided in centos repos? Yes. > What should be the desirable approach? Bundle...
> Do we need to fix the LD_LIBRARY_PATH for that binary (without affecting the rest of the system), or does it get picked up automatically by being in the same...