Building Musescore 2.0 on Fedora 21

• Apr 18, 2015 - 05:00

I built Musescore 2.0 on Fedora 21 as no .rpm were available as of yet. I contacted the Fedora package maintainers again and hope they will build .rpm soon. If not, I will build some .rpm , but am sort of waiting for Fedora 22 at the moment.

FWIW it is a moderately large build ;)

For those interested in building, the only compile errors I received were due to missing dependencies. The compile errors are a bit cryptic so you may need to identify and install the dependencies manually if I missed one.

To build on Fedora 21 ;)

Download and extract the .zip file from https://musescore.org/en/download#Source-code , extract the archive.

Install the dependencies

sudo yum install -y gcc gcc-c++ qt-devel pulseaudio-libs-devel alsa-lib-devel jack-audio-connection-kit-devel qt5-qtbase-devel qt5-qttools-libs-designercomponents qt5-qttools-devel portaudio-devel poppler-qt5-devel
qt5-qtdeclarative-devel qt5-qtscript-devel qtermwidget-qt5-devel qt5-qtwebkit-devel qt5-qtxmlpatterns-devel qt5-qtquick1-devel qt5-qtsvg-devel qt5-qttools-devel qt5-qttools-static lame-devel libsndfile-devel

Then compile

cd MuseScore-2.0.0
make release
sudo make install

So far working without obvious problems. I use standard and tab notation piano, guitar, mandolin, and mandolin

If you use an alternate distro, check your distro for similar packages.

FWIW it installs into /usr/local by default ;)

Comments

• Apr 20, 2015 - 09:00

I built my own mscore 2.0 on Fedora 21 some time ago. At first sight I had an issue with misaligned time signatures. This was caused by an old mscore-fonts package for mscore 1.3 that I forgot to remove together with mscore-1.3

Someone from the Musescore people told me Fedora should not put the fonts in a separate package. But it is a common packaging policy on Fedora to provide fonts as separate packages that can be used also by other software, without depending on the main package. In other words: you should be able to install and download the Musescore fonts, for example for use with LilyPond, without installing Musescore.

Anyway I hope Musescore 2.x will make it to Fedora 22.
I don't see it in the current F22 alpha release yet.

Reply

• Apr 20, 2015 - 16:51

The problem is, if you have those fonts installed, MuseScore will try to use them in preference to the compiled-in version, so if you have out of date versions of those fonts, you will see problerms like you did. The ideal of provided fonts separately makes sense for fonts that use a standardized encoding and metrics and thus can be shared between applications, but this has not traditionally been true of music fonts, which have generally been very specific to a particular application. SMuFL is changing this by providing a universal standard for fonts, so if you have a SMuFL compatible font installed, then you shouldn't have to worry *too* much about changes breaking things. So it is conceivable we could think about allowing this in the future.

Reply

• May 6, 2015 - 17:20

I have not tried as of yet, will get to it possibly in a few days. Post if you find any additional dependencies or error messages and I will help as time allows.

Still no answer from the Fedora maintainers. I can probably package a .rpm, but it is a large program and Fedora packaging standards mean the fonts have to be separate. I am not sure how to do that exactly, but would prefer to make a .rpm that can be put into the fedora repos.

Otherwise I can make a .rpm available to the musescore project or serve it from my web server (I maintain a few other .rpm for other projects, but outside Fedora guidelines for inclusion in the repos.

Reply

• May 11, 2015 - 10:28

It seems that IT IS available BUT for fedora 22 only. This is all I get with yum:

$ yum list available mscore --showduplicates
Plugin abilitati:langpacks
Pacchetti disponibili
mscore.i686 1.3-6.fc21 fedora
mscore.x86_64 1.3-6.fc21 fedora
mscore.i686 1.3-8.fc21 updates
mscore.x86_64 1.3-8.fc21 updates

In fact here there are only fedora 22 (and 23???) packages.

Reply

• May 11, 2015 - 11:17

I'm having an issue with file associations.
By default .mscz files are not opened with MuseScore.
I tried making it default with right click on the file > Properties > Open with and selecting MuseScore as default application. However by doing this I set default applications for all archives types, so now I should open .zip files with MuseScore, which is not really the case :P

So I tried adding mimetypes to ~/.local/share/applications/defaults.list. I've been trying the following:

application/x-musescore=mscore.desktop
application/x-musescore+xml=mscore.desktop
application/vnd.recordare.musicxml=mscore.desktop
application/vnd.recordare.musicxml+xml=mscore.desktop
text/x-lilypond=mscore.desktop

with no success. I also tried editing /usr/share/applications/defaults.list directly with the same result.

Reply

• Jun 10, 2015 - 11:46

Did you know that you can edit the Developers Handbook wiki-style? Perhaps you would like to update the Fedora instructions on this page so that you can access them all in one place rather than having to to scroll through this thread for updates?
https://musescore.org/en/developers-handbook/compilation/compile-instru…

Also, I need a bit of help from other Linux users because I'm trying to package MuseScore for the various Linux distributions. At the moment this is done manually by a dedicated person for each distribution, but I'm trying to automate the task as part of the "make && make install" sequence. This would ensure that MuseScore is released on Linux at the same time as it is released on Windows and Mac. See this page for details (I also have an active pull request on Github).
Linux packaging details: https://musescore.org/en/node/60131/
Pull Request: https://github.com/musescore/MuseScore/pull/2049

I'm an Ubuntu user myself, so I'd appreciate your help to see if my code runs on other Linux distros too. Specifically, could someone tell me whether these commands are available on Fedora (or any other Linux) and under which desktop environment (GNOME, KDE, etc)?

# Do these commands exist on your Linux distro?
# Are they installed by default, or available from the default repositories?
$ gzip
$ update-mime-database
$ gtk-update-icon-cache

Many thanks!

Reply

• Jun 10, 2015 - 15:58

All those commands are available in Fedora and likely most any distro.

In answer to your packaging questions, unless you intend to package yourself, I would worry about maintaining the source code.

The "problem" with packaging is that each distro has different specifications and although it is rather trivial to make a .deb or a .rpm, unless you are going to follow packaging standards it is no better the providing source code.

Your source code is nice in that it installs in /usr/local by default.

I can show you how to properly package .deb and / or .rpm if you so desire.

Reply

• Jun 10, 2015 - 16:57

Thanks for your reply. It would be good to know how to create .debs and .rpm packages properly and it would be great if you could show me, or at least give a few tips and point me to an existing tutorial. lasconic has also indicated that it would be good to have a static build that can run on all Linux.

I would eventually like to have the packaging performed by the source code (potentially using CPack) but it would be good to see how to do it manually first so I understand what CPack is doing behind the scenes. The packaging would probably be done via new Makefile targets (e.g. "make deb" or "make rpm". As well as making life easier for the maintainers, the advantage of automated packaging is that we can have proper Linux nightly builds available via PPA to ease the testing process for those unwilling/unable to compile from source.

In the meantime, there are still things that need doing outside of building .deb and .rpm packages. My pull request handles the man pages and MuseScore mimetype installation, both of which had to be done individually by package maintainers previously. My initial goal is to handle everything that is common to all Linux distros before moving on to the specifics for each distro.

Reply

• Jun 10, 2015 - 20:37

Thanks for being so helpful! The distribution maintainers page lists two maintainers for Fedora already, but it seems they haven't been active in the last 2 years (hence this thread I guess!).

If I'm not going to build packages myself, could you perhaps tell me (not in any detail) what the packaging process actually does, and what I need to supply?

For example, currently all files are installed to ${PREFIX}/share/..../various-directories and the command to do this is in the Makefile and CMakeLists.txt. Since the package is pre-compiled, how does it know where to install all of the files? Also, how does it know how to remove the files?

Reply

• Jun 10, 2015 - 21:27

I will try to contact the Fedora maintainers. In the meantime, all I need from you to make a .rpm is the source code.

I will work on some fedora rpm , should not really take all that long, can build in a Virtual Machine and throw the packages up on my server.

In the long run, if you want to learn to package, .deb or .rpm I will show you. I can make suggestions for your make file as well, but honestly, better to use a SPEC file

https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Creating_a_…

SPCE file and mock, one VM and mock = automated 323 and 64 bit packages for Fedora 20, 21, 22, and rawhide.

https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Mock_and_Ko…

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

Reply

• Jun 10, 2015 - 21:50

Right, I will read up on that. Ideally what we want is a "musescore-stable" and a "musescore-unstable" PPA for each distro. The unstable PPA would be set to do a checkout of the git repository once a day, so we'd just need to include these SPEC files in the Github master and everything from then would be automatic.

Reply

• Jun 11, 2015 - 15:00

lasconic: Thanks, that looks like it could be quite useful.

bodhi.zazen: So, if I've understood this correctly, we would keep the "make release" command from the Makefile, but ideally would replace the "make install" step with a customised script within the SPEC file?

Reply

• Jun 11, 2015 - 18:51

Building .deb and .rpm is easy and can be automated several ways.

The hard part is following distro specific packaging guidelines and, IMO, it does little or no good to a large project such as Musescore to provide low quality, automated packages.

Each distro has automation, PPA, koji, etc.

Just my 2c ;)

Reply

• Jun 11, 2015 - 20:47

Well we'll go for high quality automated packages then ;)

The packaging requirements don't change until the release of a new distro, and even then they are probably very similar, so there wouldn't be much "maintaining" to do once it is set up other than adding a new dependency every now and then. It will be difficult to get the automation going in the first place, but we'll do it one distro at a time to make sure it works properly on each.

Reply

• Jun 11, 2015 - 16:22

it gets a bit more complicated as each distro is going to make changes or "patches"

Such patches are distro specific and you start to get into distro speific packaging guidelines.

The fedora patches for MuseScore 2.0 are attached

The patches are not too bad, but I am going to guess you are not going to want to maintain a distro specific set of patches ;)

So, using Fedora as an example, you can see (I hope) there is a difference between making a generic .rpm /.deb and a .rpm / .deb that will install on a specific distro without breaking anything, conflicting, breaking packaging guidelines, and will be accepted into the official repos.

You get around many of the packaging issues by installing into /usr/local (so there are not conflicts with other packages) and not following licencing issues.

I would not build a generic .deb or .rpm, it does not more good then your source code.

Attachment Size
fedora-patches.zip 6.26 KB

Reply

• Jun 11, 2015 - 17:14

My thinking is we would be clever in who we target. If we package for Debian then we automatically get all the derivatives (Ubuntu, Mint, etc.) so it makes sense to start there. Then we target distributions in order of installed user base/in order of whichever is easiest.

Some distributions might have very strict requirements, but it might be that we can satisfy those requirements without breaking it for the others. So if one distribution requires "/usr/local/share" instead of "/usr/share", and the other distributions have no preference, then we can safely change the code for everyone without having to patch for individual distributions. (Of course that particular example is very easy to do anyway, but you get the idea.)

Reply

• Jun 11, 2015 - 17:39

You are on the right track. You will end up having essentially

1. General patches that apply to most distros, or all the distros you want to target -> perhaps musscore developers can use these.

2. Debian specific patches.

3. Fedora specific patches.

You would apply the patches as part of the packaging (so you would not put Debian patches in Fedora) etc

you can put the patches on git if you like

Reply

• Jun 16, 2015 - 00:30

I put fedora packages here

http://bodhizazen.net/mscore/

you will need 3 packages (fedora breaks fonts and documentation into separate packages).

http://bodhizazen.net/mscore/mscore-2.0.1-1.fc22.x86_64.rpm

http://bodhizazen.net/mscore/mscore-doc-2.0.1-1.fc22.noarch.rpm

http://bodhizazen.net/mscore/mscore-fonts-2.0.1-1.fc22.noarch.rpm

I do not mind if these rpm are uploaded to the mscore project

https://musescore.org/en/download - under fedora link

I also filed https://bugzilla.redhat.com/show_bug.cgi?id=1232040

Reply

• Jul 4, 2015 - 22:53

I am the packager for Mageia. But not like mentioned above, mscore isn't that easy to package. I am not experienced with cmake. I based my spec file on Fedora's, but many of the resulting files end up at the wrong location, specifically at usr/local/share, even the bin file . (BTW the cimpilation completes successfully)
We at Mageia should use the makro %cmake and should end up with the correct locations. Since it takes about 3 hours on my vbox to build, try and error takes a long time, especially, the problem show up after compilation, almost at the end of the build.
Programs using usually provide the configure options by calling configure --help
I would appreciate some help too.

Reply

• Jul 23, 2015 - 23:22

I still have this problem with vers 2.0.2.

Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font
Mscore: fatal error: cannot load internal font

Where can I change this so mscore will look at
$ locate MuseJazz.ttf
/usr/share/fonts/mscore/MuseJazz.ttf

Reply

• Jul 24, 2015 - 13:38

I don't know what going on with Fedora but the fonts should be in the MuseScore binary and not in /usr/share/fonts/mscore or /usr/share/fonts... Apparently, Fedora patched the MuseScore code to look into /usr/share/fonts, see patch1 in your spec file.

Reply

• Jul 24, 2015 - 16:26

See also https://musescore.org/en/node/56771#comment-263481. In the past, Linux packages of MuseScore that installed fonts directly were a real problem. I think Fedora and/or Mint maybe did this? Having the fonts installed directly caused things to break when the user wanted to install a newer version of MuseScore alongside the old. Either the old version of MuseScore choked on the new version of the fonts, or the new version of MuseScore choken on the old version of the fonts. That is why MuseScore normally has the fonts compiled in and not installed directly - it saves the user a lot of grief.

As I suggest in the post I reference in the previous paragraph, *maybe* with SMuFL now there is less concern about new versions of fonts breaking older versions of MuseScore. And I certainly understand the desire to be able to access the fonts from other applications. So in my opinion, it's worth considering for the future. For now, though, I personally think Linux distributions should compile the fonts in like it was designed to work.

Reply

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