Segfault on flatpak remote-add

I'm attempting to use Flatpak on my Guix system, and I'm experiencing segfaults when attempting to add a remote repo. Provided below are the output of the command I'm attempting to run, as well as some info about my system.

=====

jfred@lambdacrypt ~$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Note that the directories

'/var/lib/flatpak/exports/share'

'/home/jfred/.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.

Segmentation fault

=====

Current guix commit:

jfred@lambdacrypt ~$ guix describe -f channels

(list (channel

(name 'guix)

(url "https://git.savannah.gnu.org/git/guix.git")

(commit

"187f9636f176d62bf869b787ad410e3a528aa1a0")))

=====

Current user package manifest:

jfred@lambdacrypt ~$ cat guix.scm

(specifications->manifest

'("glibc-utf8-locales"

;;# Dotfiles management

"stow"

"rofi"

"gnupg"

"emacs-password-store"

"pcsc-lite"

;;# Hacking

"emacs"

"git"

"guile@2.2"

"font-adobe-source-code-pro"

"emacs-guix"

;;# Devops

"docker"

"docker-cli"

"docker-compose"

;; System Administration

"htop"

"curl"

;;# Desktop

"gnome-tweak-tool"

"icecat"

"luakit"

"flatpak"

"evolution"

;; Gaming

"tintin++"

"powwow"))

Hi Jonathan,

"Jonathan Frederickson" <jonathan@terracrypt.net> writes:

My knowledge of Flatpak is weak, but in general, foreign pre-compiled

binaries will not work on Guix unless they are statically linked.

Traditional dynamically-linked executables expect to find a dynamic

linker and system shared libraries in /lib or /lib64, which do not exist

on a Guix system. It is also fairly common for foreign binaries to

depend on standard files and programs in /usr, /bin, and /sbin, none of

which are present on a Guix system except for /bin/sh.

Having said that, if you must run foreign pre-compiled binaries on Guix,

there are various hacks to do it. One approach is to install symlinks

in /lib*, /usr, /bin, /sbin, etc, pointing to the needed components in

/run/current-system. Another is to modify the pre-compiled binaries to

look for components in the right place using 'patchelf'. We use the

latter approach to bootstrap GHC (Glasgow Haskell Compiler), which can

only be compiled by itself.

I'm sorry I don't have a better answer for you, but Guix was not

designed to run foreign pre-compiled binaries. If that's important to

you, it might be that Guix is not a good fit for you.

However, if your goal is to run Guix-compiled programs in a sandbox,

that's something we are certainly very interested in, and we could use

help. We have "guix container" as a building block, and I know that

some Guix users have experimented with running e.g. GNU IceCat within a

container. I don't know the current status of those efforts. Hopefully

someone more knowledgable in this area will chime in.

Regards,

Mark

On Sunday, May 5, 2019 6:36:06 PM EDT Mark H Weaver wrote:

I believe Flatpak applications are statically linked. (Or rather, individual

applications may be dynamically linked, but they are eventually combined with

a full OS image similarly to how Docker works.)

It's not the most important thing to me; it may end up being one more reason

for me to start attempting to package things for Guix! But it would still be

nice to be able to run the same tooling that e.g. some Gnome developers are

using to publish their apps across distros. (And the fact that Flatpak is

packaged for Guix seems to imply that it should be possible to use it here.)

While this isn't my immediate goal, this is also something that I'm interested

in, if someone else knows more about this!

On Sun, 05 May 2019, Jonathan Frederickson wrote:

I learnt on #guix IRC that flatpak works when run with the --user flag:

$ flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

$ flatpak install flathub org.gnome.Builder

$ flatpak run org.gnome.Builder

The segfaulting behaviour is still a bug in my opinion, because it's

extremely user un-friendly, and the requirement for --user is not

obvious.

Regards,

Ben

Ben Sturmfels <ben@sturm.com.au> writes:

Yes, segfaults are always bugs, unless you forced the program to

load garbage.

I traced the execution of flatpak and saw that it segfaults right after

failing to created /var/lib/flatpak. Sure enough, after creating it

manually the program no longer segfaults.

--

Ricardo

Ricardo Wurmus <rekado@elephly.net> writes:

I reported this here:

https://github.com/flatpak/flatpak/issues/3612

I’d say we close this issue here, because the segfault isn’t our fault.

Thoughts?

--

Ricardo

merge 40489 35591

quit

Ricardo Wurmus <rekado@elephly.net> writes:

Upstream has acknowledged and addressed the bug.

Closing.

--

Ricardo