Please support Flatpak as an installation platform instead of or in addition to AppImage.

[IPlayZed]

Is your feature request related to a problem? Please describe.
I wish to deploy this software per-user without fuse dependencies on a system supporting Flatpak as a packaging platform.

Describe the solution you'd like
I think it would be a good idea to publish the software on Flathub as a Flatpak instead of relying on AppImage, as it is an emerging technology on most significant distributions, it has no fuse dependency and updates are managed better, this would also be beneficial long-term to the maintainer.

[TheTumultuousUnicornOfDarkness]

Duplicate of #83.
Sorry, that is not I do not want, be I can't because of Flatpak sandbox.

[IPlayZed]

Similar problems as GWE has seems like. I wonder if this should be a feature to be added to Flatpak itself.
Doesn't HostCommand expose reading /dev/cpu/N/msr and /sys/firmware/dmi/tables/smbios_entry_point?

[IPlayZed]

This is an example of Mission Center doing it to access privileged-only information of system RAM.
Of course I understand that one might not wish to implement this on a maintenance project and I have no skills (yet) to offer a PR for this, but at least it seems possible as far as I understand.

[TheTumultuousUnicornOfDarkness]

Mission Center uses a command like /usr/bin/flatpak-spawn --host sh -c pkexec {}/bin/dmidecode --type 17 in that case, where {} is a path in Flatpak.

In CPU-X, UI runs as regular user. Privileged tasks (CPU MSRs, DMI table, kernel module loading) are delegated to the daemon which is running as root. Communication between both processes is done through IPC (UNIX socket).

It looks like one issue is I was not able to properly setup the daemon in Flatpak. The socket is /run/cpu-x.sock, but it may work if we put this socket under /tmp for Flatpak build.

My Flatpak manifest is still available (CPU-X URL need to be updated): https://gist.github.com/TheTumultuousUnicornOfDarkness/51c192a77bc5458a3dad0596295d3e52#file-org-cpu-x-cpu-x-json

If someone is interested to work on Flatpak for CPU-X, you are welcome.

[TheTumultuousUnicornOfDarkness]

Hello,

Good new: I did some workaround in 741ec48 to allow the daemon to run in Flatpak.
I am submitting the app on Flathub: flathub/flathub#4609

[JakobDev]

Does the Daemon now run outside the Flatpak?

[TheTumultuousUnicornOfDarkness]

Does the Daemon now run outside the Flatpak?

@JakobDev Yes, the daemon will run outside the sandbox.
The problem is starting the daemon requires pkexec but this command is not available in the sandbox, so there is a need to access host in that case.

[JakobDev]

I'm not sure if that's a good idea. One mayor point of Flatpak is, that it runs on any System. To make this work, he OS is hipped with Flatpak in form of Runtimes. If you start a Binary that you ship with the Flatpak outside the Sandbox, there is no guarantee it will work. You can't be sure the Host has all needed dependencies. You may also run into the famous problem, that the binary is compiled with a newer version of some libs that the host has.

[TheTumultuousUnicornOfDarkness]

I'm not sure if that's a good idea. One mayor point of Flatpak is, that it runs on any System. To make this work, he OS is hipped with Flatpak in form of Runtimes. If you start a Binary that you ship with the Flatpak outside the Sandbox, there is no guarantee it will work. You can't be sure the Host has all needed dependencies. You may also run into the famous problem, that the binary is compiled with a newer version of some libs that the host has.

I agree with you. But the binary involved does not depend on external libraries (the daemon is built against libcpuid.a in that case). There is only standard libraries:

$ ldd ./.local/share/flatpak/app/com.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/0558e756043bf16b2206c19492e230951483e3377107c4b8a8e183a39fd945ca/files/lib/cpu-x/cpu-x-daemon
	linux-vdso.so.1 (0x00007fff1758f000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f5e7e400000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5e7e735000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5e7e222000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5e7e654000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5e7e76b000)

[TheTumultuousUnicornOfDarkness]

Hello,

Good news: CPU-X is now available on Flathub!
https://flathub.org/fr/apps/io.github.thetumultuousunicornofdarkness.cpu-x

The daemon may not start on every system (glibc >= 2.35 is required on host). I should find a way to improve this.

[JakobDev]

You should verify CPU-X on Flathub

[TheTumultuousUnicornOfDarkness]

You should verify CPU-X on Flathub

Done.

[JakobDev]

The daemon may not start on every system (glibc >= 2.35 is required on host). I should find a way to improve this.

I have a Idea (not tested): You could maybe use the LD_LIBRARY_PATH variable to load the glibc version of your Flatpak. flatpak-spawn allows you set set a env variable with --env . As I said, I have not tested it, but it might be worth a try.

[TheTumultuousUnicornOfDarkness]

The daemon may not start on every system (glibc >= 2.35 is required on host). I should find a way to improve this.

I have a Idea (not tested): You could maybe use the LD_LIBRARY_PATH variable to load the glibc version of your Flatpak. flatpak-spawn allows you set set a env variable with --env . As I said, I have not tested it, but it might be worth a try.

I agree with you: starting cpu-x-daemon on host with host's libc make more sense than the current approach.
The problem is flatpak-spawn calls pkexec but pkexec does not preserve environments variables.

Starting daemon binary from host produces the following error:

$ ./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon 
./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon)

Setting LD_LIBRARY_PATH to runtime produces a different error:

$ LD_LIBRARY_PATH=/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/23.08/75d6f5f7daf46127a5e53608274216b46405b7197894970021bb7230113a30a7/files/lib/x86_64-linux-gnu ./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon 
./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon: error while loading shared libraries: __vdso_gettimeofday: invalid mode for dlopen(): Invalid argument

I found a workaround here and it seems I need to use ld-linux-x86-64.so.2 from runtime to fix the issue:

$ LD_LIBRARY_PATH=/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/23.08/75d6f5f7daf46127a5e53608274216b46405b7197894970021bb7230113a30a7/files/lib/x86_64-linux-gnu /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/23.08/75d6f5f7daf46127a5e53608274216b46405b7197894970021bb7230113a30a7/files/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon 
./.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/active/files/lib/cpu-x/cpu-x-daemon requires socket path as argument.

In other words, starting the daemon from the sandbox without libc issue requires a command like this one:

$ flatpak-spawn --host pkexec --disable-internal-agent env LD_LIBRARY_PATH=/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/23.08/75d6f5f7daf46127a5e53608274216b46405b7197894970021bb7230113a30a7/files/lib/x86_64-linux-gnu /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/23.08/75d6f5f7daf46127a5e53608274216b46405b7197894970021bb7230113a30a7/files/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /home/vagrant/.local/share/flatpak/app/io.github.thetumultuousunicornofdarkness.cpu-x/x86_64/master/39ab9ff2b2c2c725b5253819b68c671d1ef6d2db811ebf1d2b101199a0ad85db/files/lib/cpu-x/cpu-x-daemon /run/user/1000/app/io.github.thetumultuousunicornofdarkness.cpu-x/cpu-x.sock

So something like that seems to work: flatpak-spawn -> pkexec -> env (LD_LIBRARY_PATH) -> ld-linux-x86-64.so.2 -> cpu-x-daemon.

[TheTumultuousUnicornOfDarkness]

"Improved" in ec5176c. I will update runtime version for next CPU-X release (not scheduled yet).