MuseScore
http://musescore.org/
A free WYSIWYG music score typesetter
MuseScore is a graphical music typesetter. It allows for fast
and easy note entry on a virtual note sheet. It has an
integrated sequencer to allow for immediate play of the score.
MuseScore can import and export MusicXml and standard Midi files.
- Devel package for openSUSE:Factory
-
6
derived packages
- Links to openSUSE:Factory / musescore
- Has a link diff
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout multimedia:apps/musescore && cd $_
- Create Badge
Refresh
Refresh
Source Files (show merged sources derived from linked package)
Filename | Size | Changed |
---|---|---|
MuseScore-4.4.3.tar.gz | 0143462048 137 MB | |
MuseScore_General.sf3 | 0039900972 38.1 MB | |
MuseScore_General_Changelog.md | 0000015697 15.3 KB | |
MuseScore_General_License.md | 0000003419 3.34 KB | |
MuseScore_General_Readme.md | 0000005161 5.04 KB | |
README.SUSE | 0000001807 1.76 KB | |
_constraints | 0000000384 384 Bytes | |
_link | 0000000124 124 Bytes | |
musescore.changes | 0000063177 61.7 KB | |
musescore.spec | 0000011884 11.6 KB |
Comments 12
Now that 3.1 is out what would needed to be done to update this? Can I be of any help?
I see you have already branched musescore. Update it in your branch and make a submit request. If it is ok, it is accepted, otherwise you hear how you can improve it. And after it has been accepted, it will be submitted to factory. Feel free to ask for help.
The wiki can help, for example: https://en.opensuse.org/Portal:Packaging
Alternatively you can wait until I find time for it, but that will take at least a couple of days. :)
I started packaging version 3.6, however it's only compatible with Qt 5.14 and not with the newest Qt 5.15. See here
I'm quite new to packaging; how to resolve this issue? Shall we just wait until it's fixed (this is due to a bug in Qt)? Or is it possible to require a specific version of Qt in the spec file?
I know, having played with it already. It is possible to require a specific Qt version, but that would make it unresolvable for Tumbleweed. Each openSUSE version has one specific version of Qt.
What I have tested is patching build/FindQt5.cmake so that it build with Qt 5.15. I have done a local build and do not see the issues report in the link you mentioned. Palettes are working and I don't have a crash with opening documents made in older version. What I did get was a development build with MuseScore3Development as default folder for saving scores. I have not looked into this further to see how to correct this.
This is only an issue on Tumbleweed. An update for Leap should be no issue (except maybe that developement build thing).
I think it can be updated in this project, because Tumbeweed users have the backup in Tumbleweed itself, but it needs some solid testing before it can be submitted to Tumbleweed. Otherwise, Tumbleweed needs to wait.
I will upload what I have (the changes file still needs further updates) so that you can take a look and improve on it.
This package ships with Google Analytics by default. Can the telemetry be removed?
Edit: I noticed that a build flag is passed but would still prefer if the tracking code were removed altogether before building
I won't do that, but you can branch the package and do a submit request.
Or you can show that tracking is still going on in spite of the build flag, but then it's better to file a bug.
For some mysterious reason, this package is built with an incorrect version of the MuseScore soundfont. You can test this by creating a trivial empty score, opening the View > Mixer panel and trying to switch instruments : "Expr." variants of many instruments (such as "Contrabass Expr.") should be there, as seen on the official AppImage provided by the MuseScore devs, but they aren't present in this build. I tried to investigate a bit to help you resolve this, but the more I investigate, the more puzzled I am, so I'll still have to leave some of the bugfixing up to you :)
See, the soundfont is normally downloaded by CMake while the build is being configured, as seen here : https://github.com/musescore/MuseScore/blob/3224f342d12f4af8ea782e929c49f5ce85f97da6/CMakeLists.txt#L350 . The DOWNLOAD_SOUNDFONT build option that controls this is on by default, and you do not turn it off, so it should be on for your build. Except that process should print logs, which I see on a quick local build attempt with the same cmake flags that you use...
...but these logs do not appear in your own OBS build logs over there : https://build.opensuse.org/package/live_build_log/multimedia:apps/musescore/openSUSE_Tumbleweed/x86_64 . This, I suspect, might be a hint at the underlying issue.
But after going through your spec file and the aforementioned build logs, it is not clear to me what is going on. My best guess so far is this : if we go back to the CMake code I pointed at earlier, it starts by downloading a file from the server where the soundfont is located, which contains the soundfont version. The URL to that file is https://ftp.osuosl.org/pub/musescore/soundfont/MuseScore_General/VERSION. If that first download fails, the soundfont downloading process fails silently. This leaves two possible failure modes here, none of which are fully consistent with the observed build log:
If I were to debug this further, I would start by trying to run the rpm recipe locally and/or add more logging to the CMake script to see what happens at the soundfont download stage (whether the VERSION file is actually downloaded, what content the build thinks it has, whether the file timestamps match expectations from the https://ftp.osuosl.org/pub/musescore/soundfont/MuseScore_General/ server ...). But I obviously don't have access to your OBS build jobs, and have zero knowledge of OBS and RPM building so it would be hard for me to get started experimenting, thus I'll leave the rest up to you.
Actually, here's a quicker test for this bug that doesn't require running musescore at all : strangely enough, the file /usr/share/mscore-3.6/sound/MuseScore_General_License.md starts with soundfont versioning information, so you can check the beginning of that file. If the fourth line is "Current version: 0.1 alpha 1st March 2018", as in the current package, that's wrong, it should read "Current version: 0.2 13th May 2020" as in the current license file from ftp.osuosl.org.
I have uploaded a version that uses the newer soundfont.
Thanks for this. Because the build does not fail, I was not aware of this. The problem is that in OBS downloading a file during build is not allowed. So the download fails without the build failling. I would need to include this soundfont in the source, which is what is normally done in cases like these. I will look into this, at least in the context of the upcoming new version that is now in alpha.
Thanks ! I will ping upstream about the lack of a clear build failure when the download is enabled but fails.
It seems we have a licence issue:
https://build.opensuse.org/request/show/1063806
ATM I don't have time to look into this.