After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769284 - Don't enable libmount by default for now
Don't enable libmount by default for now
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-07-28 18:17 UTC by Mario Sánchez Prada
Modified: 2016-07-28 18:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't enable libmount by default for now (1.47 KB, patch)
2016-07-28 18:24 UTC, Mario Sánchez Prada
committed Details | Review

Description Mario Sánchez Prada 2016-07-28 18:17:57 UTC
As reported on IRC today, I found that the org.gnome.Platform flatpak does not bundle libmount (e.g. no /lib/libmount.so* files) while the org.gnome.Sdk does which is causing quite some trouble with any flatpak built after the patches for bug 522053 landed in master:

As the Sdk contains libmount's files Glib is compiled with libmount support linking against the relevant files, but as those files are not in the Platform runtime, any flatpak built from that point on will fail with something like this:

$ flatpak run org.gnome.PortalTest
portal-test: error while loading shared libraries: libmount.so.1: cannot open shared object file: No such file or directory

Emmanuele has looked a bit into why this could be happening and it seems the issue could be somewhere in the recipes of the freedesktop.org Yocto base but, as it seems like Alex Larsson would be the best person anyway to check this, I'm proposing to disable libmount support on Glib in the meantime, as a temporary measure so that flatpaks built will work fine back again.

After all, glib did not have libmount support for quite some time, we can certainly wait a bit more.
Comment 1 Mario Sánchez Prada 2016-07-28 18:21:13 UTC
For reference, I'm pasting the IRC conversation related to this below:

<msanchez> morning, can anyone point me to how to file a bug on the gnome runtimes?
<mclasen> msanchez: tbh, I'm not sure if there's a bug tracker for it
<msanchez> mclasen: yes, that's why I asked here :)
<msanchez> what I found is that libmount seems to be present in the Sdk but not in the org.gnome.Platform runtime
<mclasen> I've filed a flatpak issue for the one thing I had in that area
<mclasen> thats odd
<msanchez> so when I build your portal test now, I can only run it with flatpak -d
<msanchez> well, if you run flatpak run --command=bash org.gnome.PortalTest, you'll see there's no /usr/lib/libmount* files, while running flatpak with -d those files are there
<msanchez> I've updated my runtime/sdk before double checking even
<msanchez> but I'm not sure how or where to check what should go into the runtime / sdk

[...]

<msanchez> mclasen: ebassi has been helping me check what could be wrong with the runtime thing and libmount, and seems we have confirmed the org.gnome.Platform runtime does not have libmount
<msanchez> this is a pretty bad thing because any flatpak build after the changes I landed in glib for libmount won't work
<msanchez> glib will link against libmount, but libmount won't be in the Platform runtime
<msanchez> I'm thinking it might make sense to push a small patch to glib to not enable libmount support by default in glib if present while Alex is on PTO, and then flipt that switch back once the issue with libmount in the runtime is fixed 
<msanchez> mclasen: what do you think?
<mclasen> sure, a --disable-libmount configure option for glib would be an ok workaround
<mclasen> I'm still looking around to see where libmount comes into the sdk in the first place
<ebassi> mclasen: From the freedesktop.org's Yocto base
<ebassi> mclasen: Seemingly something is pulling it in inside the SDK, but not inside the Platform
<mclasen> I'm looking at freedesktop-sdk-base - is that it ?
<ebassi> mclasen: https://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base/tree/meta-freedesktop/recipes-core/tasks
<ebassi> libmount is provided by util-linux
<mclasen> I see various util-linux subpackages (?) in those lists
<mclasen> nothing spells out libmount, though
<ebassi> Yeah, I'm struggling to find it into the yocto recipes either
<mclasen> http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/util-linux/util-linux.inc 
<mclasen> has some references to libmount
<mclasen> eg an rprovides for util-linux-libmount-dev
<mclasen> and there's this: https://git.congatec.com/yocto/poky/commit/8e849a23e9ce83fd8e855e8971f8e4803447ee65
<mclasen> sadly I know too little about how the yocto level is put together to make any changes there
<ebassi> mclasen: As far as I can see, and paging back in all the memories of poky/bitbake, the util-linux-lib* packages are generated dynamically
<ebassi> mclasen: I guess somebody should add 'util-linux-libmount' to meta-freedesktop/recipes-core/tasks/task-freedesktop-contents-platform.bb
Comment 2 Mario Sánchez Prada 2016-07-28 18:24:46 UTC
Created attachment 332301 [details] [review]
Don't enable libmount by default for now

This is causing trouble with flatpaks because the org.gnome.Platform
runtime does not bundle libmount, while the org.gnome.Sdk does it.

As this probably requires a change in the freedesktop.org Yocto base,
we disable this support by default for now as a temporary measure
until it can be properly reviewed by someone who knows those bits
better, probably Alex Larsson.
Comment 3 Matthias Clasen 2016-07-28 18:26:47 UTC
Review of attachment 332301 [details] [review]:

Looks good to me
Comment 4 Matthias Clasen 2016-07-28 18:26:59 UTC
Review of attachment 332301 [details] [review]:

Looks good to me
Comment 5 Mario Sánchez Prada 2016-07-28 18:29:38 UTC
Thanks Matthias, just pushed it to master now:
Attachment 332301 [details] pushed as fbf72a3 - Don't enable libmount by default for now