Musescore 3 Ubuntu PPA

• Jun 22, 2020 - 18:01

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 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 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 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:

/usr/lib/x86_64-linux-gnu/libjack.so.0
/usr/lib/x86_64-linux-gnu/libnss3.so
/tmp/.mount_MuseScd10Zkf/bin/mscore4portable: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /tmp/.mount_MuseScd10Zkf/bin/mscore4portable)
/tmp/.mount_MuseScd10Zkf/bin/mscore4portable: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by /tmp/.mount_MuseScd10Zkf/bin/../lib/libQt5NetworkAuth.so.5)

Running the install command gives me:

/usr/lib/x86_64-linux-gnu/libjack.so.0
/usr/lib/x86_64-linux-gnu/libnss3.so
Installation step 1 of 3.
PREFIX is '/home/chris/.local'.
Preparing to install resources to:
     PREFIX/share/applications/*
     PREFIX/share/icons/*
     PREFIX/share/man/*
     PREFIX/share/mime/*
gtk-update-icon-cache: Cache file created successfully.
Resources installed to '/home/chris/.local'.
Step 2 of 3.
MuseScore is at: /home/chris/Desktop/MuseScore-4.0.2.230651545-x86_64.AppImage
Moving AppImage to 'PREFIX/bin'.
Finished installing MuseScore to /home/chris/.local
Step 3 of 3.
Symlinks can be created to make it easier to launch MuseScore from
the command line. (Symlinks are like shortcuts or aliases.)
INFORMATION: MuseScore is not in PATH. If you want to run MuseScore from
the command line you will have to type the full file path, like this:

  /home/chris/.local/bin/MuseScore-4.0.2.230651545-x86_64.AppImage

This does not affect you if you launch MuseScore by clicking on the icon.

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:

bash: home/chris/.local/bin/MuseScore-4.0.2.230651545-x86_64.AppImage: No such file or directory

In reply to 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 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 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 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 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:

sudo mv /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.bak
sudo ln -s /opt/qt515/lib/libQt5Core.so.5 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

However, that just causes Musescore4 to throw a different error:

/tmp/.mount_MuseScdvFd8e/bin/mscore4portable: symbol lookup error: /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5: undefined symbol: _ZN14QMetaCallEventC1EttPFvP7QObjectN11QMetaObject4CallEiPPvEPKS0_iiPiS5_P10QSemaphore, version Qt_5_PRIVATE_API

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 by XrayFoxtrot

If i try:

LD_LIBRARY_PATH=/opt/qt515/lib/ /home/chris/.local/bin/MuseScore-4.0.2.230651545-x86_64.AppImage

that fixes the other errors, but then gives me the new error:

/tmp/.mount_MuseSc2gIqh0/bin/mscore4portable: symbol lookup error: /tmp/.mount_MuseSc2gIqh0/bin/mscore4portable: undefined symbol: _ZNSt28__atomic_futex_unsigned_base19_M_futex_notify_allEPj, version Qt_5

which again, I don't know what to do with.

In reply to 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 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 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 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 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:

LD_LIBRARY_PATH= ./MuseScore-4.0.2.230651545-x86_64.AppImage

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 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…

Do you still have an unanswered question? Please log in first to post your question.