Yes, makes Debian desktop perfect. Rock solid base system, all desktop apps updated to the latest and greatest without pollution.
Are you trusting Flathub?
Yes BUT… there should be a way to have / manage / install Flatpaks offline like AppImages and/or easy and officially supported ways of archiving the repository into something useful and easy to use.
I would love to install a browser, and a password manager through flatpaks but they won’t talk with each other.
I would get an IDE like visual studio code, through flathub, but it doesn’t talk with the system software I want to develop on.
I would love to get Steam or any other games as flatpaks but having to redownload mesa and other system files just for that uses a lot of space and feels like a second OS.
So yeah, I agree with you. It’s awesome! But it has some flaws right now (that I’m sure they’re being worked on)
Yes but they solve the cross distro packing problem and that’s neat. The GNOME Software integration is also amazing, those few times when you see that desktop Linux actually can do it. :P
I just hope for better and easier tools to mange the security / process communication. For me flatpaks are more about finally having a fast and decent way of packing stuff across distros with dependencies than a sandbox / security feature.
FWIW I figured out how to get a password manager (Browserpass, not KeePassXC) to communicate with flatpak Chrome if you want some advice on how to get it to work.
But yes, it was way more difficult than it should have been (which is “should work out of the box, just like a regular package”). So if you’re just listing some of the shortcomings of flatpak, never mind.
I don’t remember how much I used each one, but eventually I pieced together enough information information to get the Browserpass extension working in the Google Chrome flatpak. But three of those links are KeePassXC, which should be useful for adapting this for your use.
The main file that was having problems was the Browserpass Native Messaging Hosts file in my config directory for the Chrome flatpak, ~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts/com.github.browserpass.native.json. Originally it was a symlink to a file at /usr/lib/browserpass/hosts/chromium/com.github.browserpass.native.json:
{
"name": "com.github.browserpass.native",
"description": "Browserpass native component for the Chromium extension",
"path": "/usr/bin/browserpass-linux64",
"type": "stdio",
"allowed_origins": [
"chrome-extension://naepdomgkenhinolocfifgehidddafch/"
]
}
The call to /usr/bin/browserpass-linux64 did not see to work for me, so I ended up making a copy of the file in the NativeMessagingHosts directory and modified it to point to a script in my home mount:
I don’t remember why I picked to do it inside the ~/.config directory, but it worked so I left it. And here is the script I put at ~/.config/browerpass/browserpass.sh:
I don’t remember how I came up with that script, it must be somewhere in the four links at the top.
Finally, I needed to use Flatseal to allow access to the script. In the Google Chrome settings, under “Filesystem->Other files”, I added an entry saying ~/.config/browserpass:ro. Also modified from the default in Flatseal, I have “Filesystem->All user files” enabled, along with “Socket->D-Bus session bus” and “Socket->D-Bus system bus”. I don’t know how necessary the last three are, but I’m not messing with it now that I have it working.
So, that’s what I did to get the Browserpass extension working in the Google Chrome flatpak. You’ll have to modify some things to get it working for KeePassXC, or for Firefox. But that general pattern should work.
Keep an eye out, I’ll come back to this. It involves posting config file diffs and a script I wrote, it’ll be a longer post I don’t have the time to write right at this moment.
But yes, the fact that I need to find the time to post all the changes I needed to make to get this to work is part of the problem here.
Yes, that works really well and whatnot. Totally reliable way of doing it. :P
Because the flatpak components/dependencies of a program can differ depending on the host (for example if you have an NVIDIA card, it will pull some NVIDIA dependencies), so if you export a program from a non-NVIDIA system to the other, it won’t be complete to work reliably on the new system, but the missing parts can be downloaded on the Internet, it’s still reducing the bandwidth requirement.
Yes, makes Debian desktop perfect. Rock solid base system, all desktop apps updated to the latest and greatest without pollution.
Yes BUT… there should be a way to have / manage / install Flatpaks offline like AppImages and/or easy and officially supported ways of archiving the repository into something useful and easy to use.
Related: https://github.com/flatpak/flatpak/issues/4874
Too much security already: https://github.com/flathub/org.keepassxc.KeePassXC/issues/29#issuecomment-559476300 A password manger can’t community with a Browser as it is. This makes both useless and kills one of the best use cases for Flatpak.
I would love to install a browser, and a password manager through flatpaks but they won’t talk with each other.
I would get an IDE like visual studio code, through flathub, but it doesn’t talk with the system software I want to develop on.
I would love to get Steam or any other games as flatpaks but having to redownload mesa and other system files just for that uses a lot of space and feels like a second OS.
So yeah, I agree with you. It’s awesome! But it has some flaws right now (that I’m sure they’re being worked on)
Yes but they solve the cross distro packing problem and that’s neat. The GNOME Software integration is also amazing, those few times when you see that desktop Linux actually can do it. :P
I just hope for better and easier tools to mange the security / process communication. For me flatpaks are more about finally having a fast and decent way of packing stuff across distros with dependencies than a sandbox / security feature.
I’m not against them, at all. I use them extensively. I just wish I could use them for everything!
FWIW I figured out how to get a password manager (Browserpass, not KeePassXC) to communicate with flatpak Chrome if you want some advice on how to get it to work.
But yes, it was way more difficult than it should have been (which is “should work out of the box, just like a regular package”). So if you’re just listing some of the shortcomings of flatpak, never mind.
Point away!
OK, so I looked though my browser history, and here are some relevant pages I found:
I don’t remember how much I used each one, but eventually I pieced together enough information information to get the Browserpass extension working in the Google Chrome flatpak. But three of those links are KeePassXC, which should be useful for adapting this for your use.
The main file that was having problems was the Browserpass Native Messaging Hosts file in my config directory for the Chrome flatpak,
~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts/com.github.browserpass.native.json. Originally it was a symlink to a file at/usr/lib/browserpass/hosts/chromium/com.github.browserpass.native.json:{ "name": "com.github.browserpass.native", "description": "Browserpass native component for the Chromium extension", "path": "/usr/bin/browserpass-linux64", "type": "stdio", "allowed_origins": [ "chrome-extension://naepdomgkenhinolocfifgehidddafch/" ] }The call to
/usr/bin/browserpass-linux64did not see to work for me, so I ended up making a copy of the file in theNativeMessagingHostsdirectory and modified it to point to a script in my home mount:wile_e8 NativeMessagingHosts $ diff com.github.browserpass.native.json.orig com.github.browserpass.native.json 4c4 < "path": "/usr/bin/browserpass-linux64", --- > "path": "/home/wile_e8/.config/browserpass/browserpass.sh",I don’t remember why I picked to do it inside the
~/.configdirectory, but it worked so I left it. And here is the script I put at~/.config/browerpass/browserpass.sh:#!/bin/sh cd ~ /usr/bin/flatpak-spawn --host /usr/bin/browserpass-linux64 2>/tmp/error.logI don’t remember how I came up with that script, it must be somewhere in the four links at the top.
Finally, I needed to use Flatseal to allow access to the script. In the Google Chrome settings, under “Filesystem->Other files”, I added an entry saying
~/.config/browserpass:ro. Also modified from the default in Flatseal, I have “Filesystem->All user files” enabled, along with “Socket->D-Bus session bus” and “Socket->D-Bus system bus”. I don’t know how necessary the last three are, but I’m not messing with it now that I have it working.So, that’s what I did to get the Browserpass extension working in the Google Chrome flatpak. You’ll have to modify some things to get it working for KeePassXC, or for Firefox. But that general pattern should work.
Hmm I kind of tried that route before but haven’t gone so far. I’ll check it asap. Thanks!
Keep an eye out, I’ll come back to this. It involves posting config file diffs and a script I wrote, it’ll be a longer post I don’t have the time to write right at this moment.
But yes, the fact that I need to find the time to post all the changes I needed to make to get this to work is part of the problem here.
Flatpak devs: “Let’s make a new portal!”
flatpak create-usbbacks up an app and all dependencies for offline use.Yes, that works really well and whatnot. Totally reliable way of doing it. :P
For anyone interested: https://docs.flatpak.org/en/latest/usb-drives.html and https://dataswamp.org/~solene/2023-01-01-flatpak-export-import.html
Ah Nvidia, very true. I’m not sure a solution can exist for that. Nvidia needs the driver to match the kernel.