Musescore 3 Ubuntu PPA
Hello everybody out there!
I am running Ubuntu 20.04. I have set up stable PPA for Musescore 3:
ls /etc/apt/sources.list.d/ | grep mscore
mscore-ubuntu-ubuntu-mscore3-stable-focal.list
But the only available version of Musescore 3 is version 3.2.3:
$ aptitude search musescore
v musescore-compatible-soundfont -
p musescore-general-soundfont - General SoundFont from MuseScore (HQ version, lossy)
i musescore-general-soundfont-lossless - General SoundFont from MuseScore (uncompressed)
i A musescore-general-soundfont-small - General SoundFont from MuseScore (lossy)
p musescore3 - cross-platform multi-lingual music composition and notation
idA musescore3-common - MuseScore 3 (music composition and notation) shared files
$ aptitude versions musescore3
Paquet musescore3 :
p 3.2.3+dfsg1-4build1 focal 500
However, Musescore 3.4.2 is available on Snap store:
$ snap search musescore
Nom Version Auteur Notes Résumé
musescore 3.4.2 musescore✓ - Create, play and print beautiful sheet music.
audovia-classic 4.0 songbuilder - Music Making application for Classical Musicians
Will Musescore 3.4 be available on PPA or the new recommand way to install Musescore is Snap?
Best regards.
Comments
Hello,
i'm on Linux too and i use the AppImages. These do not need to be installed. (But you have to give permission to run). This is always the newest version, but you have to downlad them manually if a new version is availible. Greetings, Pentatonus
In reply to Hello, i'm on Linux too and… by Pentatonus
Thank you for the answer.
I do know AppImages. Now, 3.4.2 is the latest stable version. Also, Snap system does automatically update software.
Anyway, whenever possible, I prefer to use packages to install software: the system is then more coherent and it uses less resources. So, as far as possible, I really rather install Musescore from PPA. The thing is, 3.4 version does fix many bugs in functionalities I use, so I need this version.
Still, is Musescore 3.4.2 planed to integrate Ubuntu PPA, or will Snap be the preferred way to install Musescore?
In reply to Thank you for the answer. I… by ylebars
Neither, not from the MuseScore developers. Only the AppImage does come directly from MuseScore.org. (and of course the Windows and macOS versions too)
In reply to Thank you for the answer. I… by ylebars
Neither, distribution nor snap packages are maintained from MuseScore. So if you want to use the actual version and distributions-/snappackage isn't available, use the AppImage.
In reply to Hello, i'm on Linux too and… by Pentatonus
But AppImages don't integrate with most Linux UIs. Every time I want to run Musescore, I'd have to call it's direct path instead of just launching it like any other app.
In reply to But AppImages don't… by XrayFoxtrot
Maybe some don't integrate, but MuseScore does. Just run it with the "install" command option and it installs itself, creating the desktop file, setting up the program icon and file associations, etc. Then you can run it like any other app.
In reply to Maybe some don't integrate,… by Marc Sabatella
Just tried it. It complained about a half dozen missing libraries and failed to install. That's why AppImages are a waste of time and why packaging systems like apt/deb have existed for decades. They tell you exactly what libaries you need and where to find them.
In reply to Just tried it. It complained… by XrayFoxtrot
? You're saying the AppImage ran from the command line but not when you gave the "install" option"? I've never heard of that happening, and I'm not sure how that would even be possible. In fact, in general, AppImages comes with all needed libraries, that is but one of their great advantages. So it sounds like something is not quite right, but we'll need more information to assist. Can you show the terminal output of your running the 4.0.2 AppImage with the install option so we can see the error you are seeing? I have a feeling there is some sort of misunderstanding here.
Anyhow, yes, the apt installation system was great in its day when there were only a handful of distributions in the world, but imagine being an application developer today and trying to provide application packages on a hundred different distributions each and every time you update the app. It's a real problem, and that why alternatives have come into being.
In reply to ? You're saying the AppImage… by Marc Sabatella
"You're saying the AppImage ran from the command line but not when you gave the "install" option"? "
Neither running the AppImage, nor the install command work for me.
Just running it gives me:
Running the install command gives me:
However, despite this message, the install appears to have failed because running
/home/chris/.local/bin/MuseScore-4.0.2.230651545-x86_64.AppImage
gives me the error:In reply to "You're saying the AppImage… by XrayFoxtrot
Regarding the installation: looks to me like it worked, but like you left out the leading "/" when typing the pathname after installing. FWIW, though, much easier to just have .local/bin in your path. Then you can simply type "mscore4portable" to run it.
Anyhow, it looks like only a single library is missing, or more particularly, too old - libQt5Core. That would normally be present and up to date on all Linux distributions supported by MuseScore, but maybe something is unique about your specific distribution / version. Best to start a new thread - this one is from three years ago talking about an older version of MuseScore so not really applicable - - and say which Linux distribution and version, and someone should be able to help you update what you need. Again, the world of Linux is unfortunately not as simple as it was 20 years ago, and while ApplImage solves most problems that otherwise plague attempts to distribute software via repositories, it can't solve them all.
In reply to Regarding the installation:… by Marc Sabatella
~/.local/bin should be in the $PATH by default.
The claim that
In fact, in general, AppImages comes with all needed libraries, that is but one of their great advantages
is not entirely correct.
To check this:
-extract Appimage:
./MuseScoreNightly-latest-x86_64.AppImage --appimage-extract
=> this will extract the Appimage files under squashfs-root
Then we can check which dependencies, not included in the Appimage, are needed (binary under squashfs-root/bin)
On my system:
ldd mscore4portablenightly | grep -v squashfs (so all dependencies not under squashfs-root)
linux-vdso.so.1 (0x00007ffc50573000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3bf4bc1000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3bf4a3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3bf4a39000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3bf4a17000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3befdd6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3bf4930000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3bf4910000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3befbae000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3bf822a000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f3bf44cd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3bf4887000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f3bf38c6000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f3bf4148000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f3bf4849000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f3bf4843000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3bf30a6000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f3bf22c0000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3bf4425000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3bf389c000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f3bf441d000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3bf4415000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f3bf3884000)
libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f3bf413b000)
Easy enough to check which libraries are missing , ldd will tell you.
And then you can install them, if still available for the system.
On my system, all the QT libraries are from the Appimage however.
ldd mscore4portablenightly | grep -i qt | cut -d' ' -f1
libQt5NetworkAuth.so.5
libQt5QuickWidgets.so.5
libQt5Quick.so.5
libQt5Qml.so.5
libQt5Xml.so.5
libQt5XmlPatterns.so.5
libQt5Network.so.5
libQt5Svg.so.5
libQt5PrintSupport.so.5
libQt5Widgets.so.5
libQt5Gui.so.5
libQt5Core.so.5
libQt5QmlModels.so.5
The problem with a missing ppa, is simply because nobody from the debian/ubuntu community feels it is needed.
Ubuntu is moving away to snap anyway.
In reply to ~/.local/bin should be in… by graffesmusic
Indeed, the AppImage does not contain every single library - just the ones that are expected to be "needed" (as I wrote), because they won't be present on all supported systems. So really basic things like libc etc don't need to be duplicated in every AppImage. That's the theory anyhow.
But yeah, I'm not sure what the story is with libQtCore5 on this particular system. The error message received indicates the system version is being used for whatever reason. I was frankly just guessing based on that evidence in assuming that this was assumed to come from the OS. I know for some libraries the AppImage itself explicitly checks whether to use the installed version or the local version.
Anyhow, that's why we need more relevant details here - ideally, a separate thread with info on what specific distribution & version we are actually talking about here. Probably relevant also to see LD_LIBRARY_PATH and PATH, and if there are any other non-standard settings that might be influencing library selection.
In reply to Indeed, the AppImage does… by Marc Sabatella
$ echo $LD_LIBRARY_PATH
:/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/jni
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/default-java/bin
I'm also running Ubuntu 20.04.
In reply to $ echo $LD_LIBRARY_PATH … by XrayFoxtrot
What happens if you add ".local/bin" to your PATH? Or if you remove (perhaps temporarily) the conflicting GNU stuff from LD_LIBRARY_PATH?
If you continue to have trouble, again, I recommend starting a new thread, since this one is about MuseScore 3 and an older PPA not relevant to the current situation. Thus this thread will potentially be skipped over by people with the sort of expertise that would be helpful here.
In reply to What happens if you add "… by Marc Sabatella
Same error as before. I guess Musescore4 just requires QT 5.15 and Ubuntu 20.04 only has 5.12.
In reply to Same error as before. I… by XrayFoxtrot
I tried following this guide (https://github.com/ksnip/ksnip/issues/712) to install QT 5.15 via a PPA, but the library files don't appear to get installed into the normal location, so Musescore4 still defaults to the old one.
I tried manually symlinking the new library in place of the old one with:
However, that just causes Musescore4 to throw a different error:
That I'm not sure how to fix since the 5.15 packages don't seem to contain a version of libQt5Qml.so.5.
In reply to I tried following this guide… by XrayFoxtrot
If i try:
that fixes the other errors, but then gives me the new error:
which again, I don't know what to do with.
In reply to If i try: LD_LIBRARY_PATH=… by XrayFoxtrot
I don't know that you should be putting the AppImage itself in the LD_LIBRARY_PATH; try removing that. But make sure /local/bin itself is in PATH.
Again, if you continue to have true, it would be much better to start a new thread with a more appropriate title - like "libQt5Core issue with MuseScore 4 on Ubuntu 20.04" or whatever - so people who might actually be able to help more will be more likely to see the thread.
In reply to I don't know that you should… by Marc Sabatella
I'm not putting the AppImage in the library path. I'm putting the QT 5.15 library in the library path. That's how you define inline shell variables in Linux.
In any case, it doesn't matter where I ask. Looks like Musescore's AppImage, and whatever version of QT is requires, simply isn't available for Ubuntu 20. I could probably spend a few more hours compiling it from scratch, but that's more time than I want to spend on this. I'll just use the older version that still works.
This is why packages will always be the better option. I've wasted hours just trying to find which version of QT Musescore4 requires and how to install it. No time's being saved by publishing a runs-everywhere AppImage, because it doesn't run everywhere.
In reply to I'm not putting the AppImage… by XrayFoxtrot
My bad on the LD_LIBRARY_PATH, I misread the space. But are you sure you tested removing everything from the LD_LIBRARYP_PATH? As mentioned, the AppImage actually should be including the Qt libraries already, so it should work to have LD_LIBRARY_PATH empty.
Anyhow, again, in simpler times decades ago, yes, it was feasible to have separate builds for every single distribution. I'm not sure if you've ever tried releasing a major Linux software package today, but that just isn't viable anymore. Too many different distributions with too many different versions floating about.
MuseScore tried this for many years, and there were constant problems - packages being way out of date because repository mintainers would be months or in some cases literally years behind in making updates available, or there would be unresolvable cross-dependencies, or they'd be built with wrong options leading to hard-to-diagnose bugs, and soo on and so on. Yes, in theory, it's possible to build software this way. In the real world, it just isn't viable. You're welcome to single-handedly take full responsibility for releasing each and every update to MuseScore on each and every distribution for the rest of your life itf you truly think it's easy, but experience has proven - it just isn't.
AppImages really do solve the problems almost completely. Like, there are probably only 1/100th as many issues now as before AppInmage. I'm not kidding in the slightest.
Anyhow, again, I am practically begging you to let people help you, and the best way to do that will be to open a new thread with a more appropriate title. The only people reading this many years-old thread are those few people who responded back in 2020 and are thus subscribed to updates already. None of the people who would be able to help you are seeing this conversation. There are people who can help, and I want them to be able to find you.
In reply to My bad on the LD_LIBRARY… by Marc Sabatella
The $LD_LIBRARY_PATH on my Ubuntu 20.04LTS laptop is empty. MS works perfectly. Everything is in the appimage.
You can check it. See above.
About a PPA: Ubuntu would not have made a MS4.0 package for Ubuntu 20.04, even if they made packages for MS in general. Only security fixes are backported to previous releases. See Backports:
https://help.ubuntu.com/community/UbuntuBackports
When Ubuntu releases a new version of its OS every 6 months, that release is largely frozen in time. While the software that is part of that release will get bug fixes and security patches, new major releases of software and the new features that come with them will not be available.
Perhaps a third party would do this, but Ubuntu would not. (and consider: do you trust every ppa on the internet?)
You could be the maintainer for a MuseScore ppa if you wanted to.
I do agree that packages are better, but IMHO, an Appimage for MS IS a good idea. The MS developers cannot possibly make packages for every Linux system out there.
In reply to The $LD_LIBRARY_PATH on my… by graffesmusic
"The $LD_LIBRARY_PATH on my Ubuntu 20.04LTS laptop is empty. MS works perfectly. Everything is in the appimage."
Ah, that might be it. My default LD_LIBRARY_PATH is ":/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/jni".
But if I launch the AppImage with:
then it runs fine. I guess my system libraries must be overriding and then breaking what's built-in to the AppImage.
Thanks.
In reply to "The $LD_LIBRARY_PATH on my… by XrayFoxtrot
If you run
LD_LIBRARY_PATH= ./MuseScore-4.0.2.230651545-x86_64.AppImage
you tell MS not to use your $LD_LIBRARY_PATH but instead use " "
As for that library path, you don"t need to do that. (at least for /usr/lib/x86_64-linux-gnu )
Those libraries are already configured system wide under /etc/ld.so.conf and /etc/ld.so.conf.d/*
e.g. /usr/lib/x86_64-linux-gnu is in:
/etc/ld.so.conf.d$ more x86_64-linux-gnu.conf
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
Have a look at this maybe
https://unix.stackexchange.com/questions/425251/using-ldconfig-and-ld-s…