GNU bug report logs -
#35591
Segfault on flatpak remote-add
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35591 in the body.
You can then email your comments to 35591 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Sun, 05 May 2019 20:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Jonathan Frederickson" <jonathan <at> terracrypt.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 05 May 2019 20:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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 <at> 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 <at> lambdacrypt ~$ cat guix.scm
(specifications->manifest
'("glibc-utf8-locales"
;;# Dotfiles management
"stow"
"rofi"
"gnupg"
"emacs-password-store"
"pcsc-lite"
;;# Hacking
"emacs"
"git"
"guile <at> 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"))
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Sun, 05 May 2019 22:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 35591 <at> debbugs.gnu.org (full text, mbox):
Hi Jonathan,
"Jonathan Frederickson" <jonathan <at> terracrypt.net> writes:
> 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.
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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Sun, 05 May 2019 23:37:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 35591 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sunday, May 5, 2019 6:36:06 PM EDT Mark H Weaver wrote:
> 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.
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.)
> 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.
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.)
> 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.
While this isn't my immediate goal, this is also something that I'm interested
in, if someone else knows more about this!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Thu, 31 Oct 2019 10:51:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 35591 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 05 May 2019, Jonathan Frederickson wrote:
> 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.
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Mon, 11 May 2020 20:24:01 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
Ben Sturmfels <ben <at> sturm.com.au> writes:
> On Sun, 05 May 2019, Jonathan Frederickson wrote:
>
>> 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.
>
> 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.
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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Mon, 11 May 2020 20:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35591
; Package
guix
.
(Mon, 11 May 2020 21:39:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 35591 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> writes:
> Ben Sturmfels <ben <at> sturm.com.au> writes:
>
>> On Sun, 05 May 2019, Jonathan Frederickson wrote:
>>
>>> 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.
>>
>> 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.
>
> 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.
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
Merged 35591 40489.
Request was from
Ricardo Wurmus <rekado <at> elephly.net>
to
control <at> debbugs.gnu.org
.
(Thu, 14 May 2020 05:22:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Ricardo Wurmus <rekado <at> elephly.net>
:
You have taken responsibility.
(Thu, 14 May 2020 05:27:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Jonathan Frederickson" <jonathan <at> terracrypt.net>
:
bug acknowledged by developer.
(Thu, 14 May 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 35591-done <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> 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.
Upstream has acknowledged and addressed the bug.
Closing.
--
Ricardo
Reply sent
to
Ricardo Wurmus <rekado <at> elephly.net>
:
You have taken responsibility.
(Thu, 14 May 2020 05:27:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
marmulak <at> disroot.org
:
bug acknowledged by developer.
(Thu, 14 May 2020 05:27:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 11 Jun 2020 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.