Building Musescore 2.0 on Fedora 21

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

also texlive-scheme-basic

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.

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.

good points Marc

Works perfect! Thank you

What if I want to update from 2.0 to 2.0.1? Simply "overwrite" the install or what? Thank you

Yes, simply overwrite

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.

It worked without any problems! Simply downloaded the new source code, built and installed with:

make release
sudo make install

I don't know anything about .rpm and how they're done but let me know if I can help in some way.

FWIW mscore 2.0 is now available in the fedora repositories. I would venture 2.1 will be available soon.

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.

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.

You should probably ask on a new thread. File associations are working here, but I am running Fedora 22 with mscore installed currently from the fedora repositories.

FWIW same instructions work on Fedora 22 with Musescore 2.0.1

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-instruc...

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!

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.

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.

As you are familiar with Debuntu I suggest you start with a ppa

https://help.launchpad.net/Packaging/PPA

If you would like, I can set up a ppa for you and walk you through how to use it. You will need a launchpad account. Go ahead and set that up (LP account) and I can make a museScore team on LP -> PPA. You can then take over the team /ppa if you wish (I will set you up as an admin)

I would contact the MuseScore Team and see if you can help or create a daily build

https://launchpad.net/~mscore-ubuntu

Looks maintained

https://launchpad.net/~mscore-ubuntu/+archive/ubuntu/ppa

Most recent build 6/9, although they could use an updated stable release =)

Just add yourself to this team.

As lasconic said, there is already a MuseScore PPA. I could either create a private "test" PPA just to see how it works, or would it be enough to just learn how to build a .deb on its own?

Personally, I do not think there is any need to learn how to build a .deb unless you have time and interest.

When using a ppa, you upload the source code and LP builds the .deb, so no need to learn more. If you are interested, read https://www.debian.org/doc/manuals/maint-guide/

BTW, I already have a launchpad account too: https://launchpad.net/~shoogle

Fedora has a similar system, koji

https://fedoraproject.org/wiki/Using_the_Koji_build_system?rd=PackageMai...

To create a .rpm see https://fedoraproject.org/wiki/How_to_create_an_RPM_package

I am memberr of Fedora and will see what I can to to get Koji going.

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?

For Fedora, if there is no package for Fedora 22, it's a bug. We should file it in the Fedora bug tracker. I did it for 2.0 https://bugzilla.redhat.com/show_bug.cgi?id=1205809 It tooks several weeks but it works...

I create a new bug here for 2.0.1 here
https://bugzilla.redhat.com/show_bug.cgi?id=1230407

From that page...

    "Also, upstream bemoaned the fact that they need to file a bug for every distro to get things updated."

Classic!

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_S...

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_Koji

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

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.

If you are looking into the automation direction. You might want to take a look to OpenSuse build service. It should support building deb, rpm etc...
http://openbuildservice.org/

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?

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 ;)

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.

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.

AttachmentSize
fedora-patches.zip 6.26 KB

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.)

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

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

Hi bodhi,

I've finally managed to build a working package for debian/ubuntu and to automate it via Launchpad. Thank you very much for your help early on! If you have a copy of Ubuntu 15.04 you can give it a try here: https://musescore.org/en/node/71466

I'll be upstreaming the patches from my git repo in a few days time.

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.

post your spec file . Sounds as if you did not apply my patches.

OK, got it to build. But it doesn't start. It looks at the wrong location for the fonts:
"Mscore: fatal error: cannot load internal font /usr/share/fonts/MuseJazz.ttf "
they are in /usr/share/fonts/mscore/

attached is my spec file. I had to add for being able to upload.

AttachmentSize
mscore.spec_.txt 9.98 KB

Nothing obvious, can you post a link to the source rpm so I can look at the patchs ?

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

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.

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.

I added freetype-devel to the list of dependencies here: https://musescore.org/en/developers-handbook/compilation/compile-instruc...
as it became a requirement. (see here).

I also added texlive-scheme-basic which is not a requirement but causes warnings when building.

Syndicate content