flatpak and TCL

[GNUser]

Every now and then there is an interesting application that I would like to try which is available for linux only as source code or flatpak. I don't have a specific application in mind at the moment but it happens often enough.

Would a flatpak extension add value to TCL x86_64? I'm not sure--maybe it is philosophically incompatible with TCL principles (too complex, with too many hooks into dbus +/- gnome-things)?

I'd be interested in knowing what the TCL developers and other users think about this. I don't want to put in the work of creating a flatpak.tcz (or requesting it if my efforts lead to a dead end) if it's not a good fit for our favorite OS.

[GNUser]

It seems a TCL extension and a flatpak are antithetical in every possible way. I think I've answered my own question. Sorry for the noise.

[hiro]

i for one would like your answer to be more concrete. is it just the dbus things? or what exactly? i have never looked deeply what dependencies there are for flatpak.

[GNUser]

is it just the dbus things? or what exactly?

Hi hiro. I'm not sure but I will investigate and will get back to you.

[GNUser]

Hi hiro. It seems flatpak is heavily dependent on dbus but not on systemd or other "gnome things".

I almost have it working in TCL with a binary-only extension (built from borrowed binaries and libraries from Devuan), but I don't know enough about dbus to get it quite right:

Code: [Select]

$ tce-load -i flatpak

$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...

$ flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo

Note that the directories

'/var/lib/flatpak/exports/share'
'/home/bruno/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so applications installed by Flatpak may not appear on your desktop until the session is restarted.

error: Rejected send message, 1 matched rules; type="method_call", sender=":1.2" (uid=1000 pid=12259 comm="flatpak remote-add flathub https://flathub.org/rep")
interface="org.freedesktop.Flatpak.SystemHelper" member="EnsureRepo" error name="(unset)" requested_reply="0" destination="org.freedesktop.Flatpak.SystemHelper" (bus)
It seems flatpak-system-helper is important, so let's try to run it:

Code: [Select]

$ sudo /usr/libexec/flatpak-system-helper

(/usr/libexec/flatpak-system-helper:11896): GLib-GIO-WARNING **: 08:36:06.570: Unexpected reply 2 when releasing name org.freedesktop.Flatpak.SystemHelper

If someone knowledgeable about dbus can give me a hand, I would be happy to proceed--the goal being to submit a binary-only flatpak extension for the x86_64 repo. Otherwise, dbus and flatpak-system-helper have stopped me dead in my tracks.

[GNUser]

I got it to work, hiro. In Devuan, flatpak works as regular user with window popup asking for root password to elevate privileges when adding a channel or installing an app. In TCL, no such window appears, so I need to use sudo at the command line:

This works:

Code: [Select]

$ tce-load -i flatpak

$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...

$ sudo flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo

$ sudo flatpak install foo

I'm going to add some polish to this then submit it for the x86_64 repo.

P.S. I don't particularly like portable package formats but I can imagine situations in which they may have some utility (e.g., trying an application's flatpak to see if I like the application, prior to creating a proper TCL extension of that application).

[GNUser]

I got it to work, hiro.

Scratch that. Everything works until I try to run an installed application:

Code: [Select]

$ flatpak run org.gnome.Recipes

Note that the directories

'/var/lib/flatpak/exports/share'
'/home/bruno/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

bwrap: pivot_root: Invalid argument
error: ldconfig failed, exit status 256
It seems Juanito bumped into this same error 8 years ago: https://github.com/containers/bubblewrap/issues/214

Juanito, did you ever find a solution for this "pivot_root: Invalid argument" error?

[GNUser]

Juanito, did you ever find a solution for this "pivot_root: Invalid argument" error?

It seems this error may have something to do with the fact that TCL's root filesystem is an initramfs:

https://unix.stackexchange.com/questions/455223/pivot-root-from-initramfs-to-new-root-error-invalid-argument

If this is the case, it may be tough to get flatpak to work on TCL. Either we'd need to bypass bwrap's pivot_root or else create a wrapper script for bwrap that does some kind of hack.

[GNUser]

Now I'm motivated to solve this, even if I never use flatpak on TCL

hiro, here is a simple way to reproduce the problem on TCL16 x86_64:

Code: [Select]

$ tce-load -wi bwrap
$ bwrap --bind / / true
bwrap: pivot_root: Invalid argumentIf someone can help me find a fix or workaround for this error, I should be able to package flatpak for TCL.

[Juanito]

Juanito, did you ever find a solution for this "pivot_root: Invalid argument" error?

Sorry, no 

[GNUser]

Thanks, Juanito. Good to know.

I've learned the hard way that flatpak and other sandboxed applications (e.g., nix package manager with default configuration) were designed under the assumption that they are running inside a "real" root filesystem.

TCL, on the other hand, is (beautifully and cleverly) designed to stay at the initramfs stage of the boot process, where it runs from RAM without ever pivoting to a mounted filesystem.

It seems to bridge this gap we'd need either a complex userland hack or a kernel patch:

https://lore.kernel.org/all/20210914170933.1922584-2-graham@determinate.systems/T/#m433939dc30c753176404792628b9bcd64d05ed7b

The complication is just not worth it. This is the end of my flatpak explorations.

P.S. The more I learn, the more I appreciate TCL's minimalistic approach to everything, including package management.  TCL

[hiro]

thanks for your investigation, i'll try to look what bwrap is all about, if i ever get some time
i use chroot+namespaces directly on tcl bec. it was easier for me, less than 10lines of shell iirc

[GNUser]

thanks for your investigation

Hi hiro. You're welcome. Thanks for the kick in the pants to be more specific about what "things" are required

If you discover anything interesting about bwrap + TCL, please do share.

Here are the portable package formats I've tried on TCL and whether they worked or not, in case it's helpful to others:

==========
Snaps: No (systemd) *
Flatpak: No (bwrap doesn't like initramfs root)
AppImage: Yes **
nix package manager: Yes ***
==========

* If not a hard dependency on systemd, it needs more than Devuan's systemd shims provide and is banned from Devuan for this reason. See https://pkgmaster.devuan.org/bannedpackages.txt

** Most AppImages work fine, but they all need fuse.tcz plus one or more of these:
$ sudo ln -s /usr/local/etc/fonts /etc/fonts
$ sudo ln -s /usr/local/etc/ssl /etc/ssl
$ sudo ln -s /lib /lib64
$ tce-load -wi bash

*** I only tested the single-user installation (see https://nixos.org/download). There are several caveats to using it on TCL:
1. sandboxing needs to be off: $ sudo mkdir /etc/nix; sudo sh -c "echo 'sandbox = false' >/etc/nix/nix.conf"
2. GNU cp is needed: $ tce-load -wi coreutils
3. Over 80,000 files are placed in user's home directory just for initial setup, before even a single package is installed!

Bottomline for me is that 95% of the software on my daily driver are official TCL extensions, 5% are AppImages. Things will remain this way.