commet
commet copied to clipboard
commetchat
Error while loading shared libraries: libmpv.so.1 on boot
Describe the bug
When trying to load the linux version of the v0.1.0 commet release I get: /var/home/dannymate/Downloads/commet-linux-x64/bundle/commet: error while loading shared libraries: libmpv.so.1: cannot open shared object file: No such file or directory and commet doesn't boot.
To Reproduce Steps to reproduce the behavior:
- Download the commet-linux.tar.gz from release v0.1.0
- Try the run the executable or run it in console
- See error
Expected behavior Commet should run.
Additional context Fedora Silverblue 38, Gnome 44.5, Wayland
Fedora Silverblue being immutable, people try to avoid layering packages on. Instead, I tried in a toolbox.
Installed mpv, mpv-devel, mpv-libs and in all cases I still get the same issue.
I see, im not too familiar with this distro unfortunately... I will try to reproduce in a vm and see what I can do
A toolbox creates a normal Fedora install in a container that has access to your Fedora Silverblue home directory. You're running Fedora on top of your immutable distro. It's useful for dev work to install packages for specific projects without cluttering your OS. And can also be used to install graphical apps. I use a toolbox for scrcpy for example.
In Fedora Silverblue the install options are in order of recommendation: Flatpak > AppImage > Toolbox > Package Layering (What you would consider apt-get install).
Flatpak and AppImages are both All-in-one container formats. And would be the ideal solution.
I agree, we are planning to distribute with Flatpak and AppImage soon. As it seems Silverblue is not a 'typical' distro, would you consider it fair to say that getting commet to run as a plain executable is not "important" in this scenario?
I recommend making sure it works in vanilla Fedora using a VM or what have you first before checking this one off. It should work in a toolbox and the fact it doesn't suggests that it may be a wider Fedora bug.
However, yes I would use a Flatpak every day of the week. I was just hoping to give this a shot and see what it was like, maybe give a run through the change client October thing.
Sounds good, will continue looking in to it on vanilla fedora.
In the mean time, we do host a web version over on https://app.commet.chat if you wanted to jump in to it now
I did know but I tend to use the desktop clients. I'll give it a shot now.
Obviously it takes great inspiration from a well known chat service :P. And clearly early in development. Even so it looks very nice and feel good to use. I would love to be able to use a custom theme. I use the Catppuccin Frappe theme from here.
I have some rooms that aren't in spaces and it's a bit of a pain to navigate to those. As I have to press home before I get a list of rooms.
Some icons don't show in the side panel. My Space for my discord bridge (it doesn't have a set icon but should show 'D'):
The only other feature I want is search.
Otherwise I'll let you get on with UI/UX design. It's too early to really give much feedback I imagine.
I'm excited for it, looks like it could be perfect for me and a couple others I know. Another project I'm interested in is Commune, a Matrix server to the Fediverse and the wider web. It's more a server than a client though.
Totally agree with those points! Will open some new issues for them!
As for this issue, it's seeming like it may need to be fixed by one of our upstream dependencies. I'll open an issue there and see what can be done.
On vanilla fedora, even with libmpv installed, it was unable to find the library unfortunately
I'll leave this issue open then. Hopefully it's an easy fix.
I'll also try to give more feedback as development progresses. Probably when a Flatpak gets released. I know someone who is very particular so he'll be useful for weeding out very small things nobody else would notice.
After talking to media_kit maintainers, they pointed out to me that the libraries are statically linked and need to be built for that specific platform - seems obvious now!
Moving forward we will be publishing releases as .deb, flatpak and .rpm. which should cover all our bases :D
That sounds like a good assortment to me. Us Linux users can be avaricious with our package formats. Be careful not to overload yourself with building packages in the future. :)
I leave it to you to close the issue when it's fixed.
Can confirm this occurs on normal Fedora as well.
After talking to media_kit maintainers, they pointed out to me that the libraries are statically linked and need to be built for that specific platform - seems obvious now!
@Airyzz maybe I can submit a PR to get this done. I'd like to try commet out!
I've been working on it today already, to get a flatpak build done this weekend. I think we will end up not releasing .rpm packages because we cant run github workers on Fedora.
This is still happening in Debian, because it's libmpv.so.2 in unstable and testing:
root in ~ ❯ ll /usr/lib/x86_64-linux-gnu/libmpv*
lrwxrwxrwx 1 root root 15 1 mai 11:10 /usr/lib/x86_64-linux-gnu/libmpv.so.2 -> libmpv.so.2.3.0
-rw-r--r-- 1 root root 2,7M 1 mai 11:10 /usr/lib/x86_64-linux-gnu/libmpv.so.2.3.0
This is still happening in Debian, because it's libmpv.so.2 in unstable and testing:
root in ~ ❯ ll /usr/lib/x86_64-linux-gnu/libmpv* lrwxrwxrwx 1 root root 15 1 mai 11:10 /usr/lib/x86_64-linux-gnu/libmpv.so.2 -> libmpv.so.2.3.0 -rw-r--r-- 1 root root 2,7M 1 mai 11:10 /usr/lib/x86_64-linux-gnu/libmpv.so.2.3.0
Is this using the released .deb package?
Yes, the package installed fine, it doesn't complain about mismatched dependency in libmpv. Indeed, the .deb has no dependencies:
❯ dpkg-deb -I ./commet-linux-x64.deb
new Debian package, version 2.0.
size 27645636 bytes: control archive=215 bytes.
146 bytes, 8 lines control
Package: commet
Version: 0.2.0
Architecture: all
Essential: no
Priority: optional
Depends:
Maintainer: Airyz
Description: Your space to connect!
to clarify, you are getting libmpv.so.2 from unstable/testing versions of mpv?
I probably need to tweak the .deb to actually consider dependencies properly, as I don't think this is correct.
I'm not sure if theres much that can be done without releasing a seperate build that is linked with this version, and I think probably in the future we'll be pushing flatpak as the recommended version for linux to avoid these types of issues - open to suggestions though!
root in ~ ❯ dpkg -S /usr/lib/x86_64-linux-gnu/libmpv.so.2.3.0
libmpv2:amd64: /usr/lib/x86_64-linux-gnu/libmpv.so.2.3.0
This means that yes, libmpv comes from libmpv2, which is built by source package mpv. As you can see in https://packages.debian.org/source/bullseye/mpv and https://packages.debian.org/source/bookworm/mpv libmpv1 was distributed in old stable (aka bullseye) and libmpv2 is in current stable (aka bookworm). So it doesn't make sense to still use libmpv.so.1 anymore, at least for Debian.
And yes, to be honest, this is to avoid the Flatpak package: it's a pain to track every software installed by AppImage/Flatpak/snap, and a tougher pain to update them. I'm using Debian because of "One tool to manage every software" :) Note that I fully understand the packager point of view: multiple Linux distros with random patches, sometimes very intrusive. Flatpak is a very tempting solution.
I see, if libmpv.so.2 is latest stable version then I agree it makes the most sense to be using this version going forward. Thanks for the info!
I'll look in to changing this :)
I've decided we'll be releasing two .deb files for now, one using libmpv1 and one with libmpv2. Worth noting in the next release they will be named as commet-ubuntu-22.04-x64.deb and commet-ubuntu-24.04-x64.deb as the name is being taken from the github runner that it's built on.