-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mumble AppImage not working #3959
Comments
From this thread, I found this image that works in Debian 10 and not in Fedora 30. The two VMs where I have tested. In Fedora 30 I get an error of a missing library.
|
The latter error with |
Yes, the JACK library is not installed by default. The issue was fixed in 2e1d3f1, the library is not required anymore when Mumble is built with JACK support. |
Maybe @probonopd can help us with this error. It would be very nice to have a working AppImage for Mumble. |
Assuning that you mean the JACK situation and not the QSsl situation: As far as I know there is no way to build in a way that works on systems with and without JACK. So it may be best to build a version for systems without JACK and a version for systems with JACK, and make two AppImages. (If you want to be more fancy, you could probably put both into one AppImage and have a bash script that would select the one that matches the system.) |
I mean the QSsl situation. I have try to use the AppImages listed here: https://dl.mumble.info/snapshot/ without success. I always get the QSsl error and Mumble does not open :( |
All I can say at this point is that it is working for me on a Ubuntu 18.04 system:
Maybe the OpenSSL in Debian 10 is broken in binary incompatible ways? |
What do you mean? Compatibility between Openssl and the AppImage? Compatibility between QT and OpenSSL? I get this error, not only in Debian 10, but in Fedora 30, Fedora 31 and a very similar one in Debian 9. I can confirm that the AppImage works fine in Ubuntu 18.04 and in an updated Manjaro Linux. I also tested in Debian 9 and it did not worked, but I get a similar error, but with more info:
Thanks so much for your time! |
Googling the error message pointed me to amra/DocumentationAsCode#2 and there it is suggested that |
Installing libssl1.0-dev fixes the issue in Debian 9. There is no libssl1.0-dev in Debian 10, but I installed libssl-dev I get different error:
My understanding is that the libssl-dev should be installed in the Appimage so the users won't have to installed anything extra in their system. Just download, give permissions and run. I would try Fedora 30 later. |
Yeah to my understanding an AppImage should contain everything it needs so it can run on any system no matter what's installed on it... @probonopd do you have an idea why these SSL things don't seem to be included in the AppImage? |
SSL things are probably assumed by the author of this AppImage to be part of every target system (distribution) and are hence not bundled inside every AppImage. Maybe we need to change this policy as long as OpenSSL breaks in ABI incompatible ways despite keeping the same MAJOR version number. Personally, I expect any application built against version 1.x.x of a library to be able to run with subsequent versions 1.y.z of the same library. Apparently OpenSSL has not been working this way, at least until now. Reference: |
Aha. Didn't even know that was possible with AppImages ^^ Well in my opinion we should bundle everything into the AppImage to really make it independent of the target system (as long as it's Linux of course). The question is, how'd we go about including things like OpenSSL? 🤔 |
Ideally we should bundle everything, yes. Hopefully we don't end up with way bigger AppImage files. @probonopd What should be done in order to achieve that? |
The downside of this is that the AppImage will be larger (from my experience in the range 5 MB to 10 MB), will not honor system styles, and may have difficulties interacting with things like OpenGL drivers and possibly Jack. Let me know if I should give it a try. |
Our AppImage file currently weights 34 MB, in my opinion a size of ~50 MB is completely fine.
Aren't the styles handled by Qt at runtime?
In our case it shouldn't be an issue, since we don't directly make use of OpenGL.
Probably not, we now load the library at runtime.
That would be great, thank you! |
For testing purposes, I have made an experimental Mumble 1.3.0 AppImage based on the Mumble package in Alpine Linux using musl libc. The toolset and process used is still a work in progress and subject to change, so I would be interested in whether you think the result is worthwhile. It is well possible that I am still missing things that need to be bundled or symlinked. Especially I am not sure whether the audio setup is currently working (or what is missing in case it is not). Comparison
Code (to be further simplified)
|
@probonopd thanks a lot!!! |
Thanks @rafaelbonifaz. Did you (or anyone else) have a chance to verify functionality, i.e., that it works and not just launches? |
Sorry for the delay.
Also I tested in a Debian 10 installation and it did not start. I use QuebOs and it's Virtual Machines do not have all the packages a normal installation does. Here I got the following message
The last thing it would be really nice is that Mumble app image could work together with torsocks. That is running Mumble this way Anyway, when I try to run Mumble AppImage with Tor I get this error. Hopefully you can helps us with this too.
|
Further inspection shows: We are getting
Why? Apparently
It looks like The approach given by @TheAssassin in probonopd/linuxdeployqt#237 shows:
Note that
So, would it be the right thing to do to deploy (bundle) the
What about the
What about the the Would it be the right thing to do to deploy (bundle) the
What about the |
Currently I am stuck at Does anyone know how to achieve this? Is Would https://github.com/flatpak/freedesktop-sdk-images/blob/1.6/alsa-lib-plugin-path.patch need to be applied for this to work? |
Now that sounds like a dendency-hell xD I just thought whether we might have a better time if we were to try and compile everything statically into our executable for creating the AppImage... Do you think that'd be easier? 🤔 |
Yes... I'm assuming they are |
https://stackoverflow.com/a/17716576/3907364 mentions some tags that can be part of the calling executable which influence the way |
Thanks for the hint @Krzmbrzl, so if we could get it to I did not find out yet where alsa gets this |
According to the answer on SO I posted above, it should work by
That's the default behaviour of |
It says
I belive that is what we are running into. Investigating right now. Running the AppImage gives:
So what is actually tried to be loaded? As per
We can see that other libraries are being searched in Unfortunately there is no
If that were the case, then we should see |
Maybe we also need to bundle the whole Here is a similar question: https://gitter.im/ubuntu/snappy-playpen/archives/2016/07/17?at=578b46eb9f79ee4f2bcc61e7 |
Okay now I see why you are confused - I don't get what's going on either. I think that if this path is really hard-coded into the library and these strings aren't hints only, then we don't have a chance of convincing alsa to load the bundled libraries... I guess at this point it might be best, if we were to create an issue in the alsa GitHub project and ask them if and how something like this is possible 🤔 |
Exporting However, setting |
The troublesome line seems to be This looks intriguing, "Handle the plugin dir not being on the default dlopen search path", can you make sense of I guess we want to use "the default dlopen search path" and this code prevents it? Possibly this is caused by Which says
Wouldn't the right thing to do be to:
cc @perexg @vorlonofportland @tiwai (TL;DR: We want to bundle a private copy of ALSA with our application, so that the ALSA from the Linux distribution is not used at all. Yet it seems ALSA is relying on some absolute paths compiled in with no clear way to pass in a different location for ALSA at runtime. How to do this?) |
We are getting somewhere:
results now in
I am almost sure that if we could get rid of the extra |
You could do Then the resulting path should be
And thus it should search in the current directory as this is now a relative path. Then we inky have to make sure that we put the library in the correct spot in the current dir ☝️ |
Great idea, but somehow I could not made that to work... |
What does the error message say? EDIT: You did notice that I intentionally left out the |
It said it can't find the file there.
Sure, otherwise it would crash immediately. |
The patch described in alsa-project/alsa-lib#34 has been committed to ALSA master, which means that there is now a |
Awesome! |
~/Downloads/AppImage$ ./Mumble-3eaee7c6-x86_64.AppImage Appimage does not work |
Maybe a stupid question, but why do I get: /bin/sh: ./appimagetool: not found` |
Do you have |
I will check and come back to you. So it must be built by the script? |
The contents of the directory:
|
This is the source code, you need to run the compiled |
So I can build it with go build /home/me/go/src/github.com/probonopd/go-appimage/src/appimagetool/? |
Given that we no longer build or provide an AppImage, I think this can be closed. |
I try to test Mumble from AppImage, but it does not work. I have try the newst versions at this time downloaded from here. That is: Mumble-1ffbbc44-x86_64.AppImage, Mumble-e0a4eb21-x86_64.AppImage, Mumble-72e1f47b-x86_64.AppImage, Mumble-f384cca9-x86_64.AppImage
and Mumble-ce40787c-x86_64.AppImage
I Debian 10 I get this error:
In Fedora 30 I get the same error. I guess there is a QT ssl reletaded library missing.
The text was updated successfully, but these errors were encountered: