Now that 3.1 is out what would needed to be done to update this? Can I be of any help?

Cor Blom (cornelisbb) - over 5 years ago

maintainer

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?

Cor Blom (cornelisbb) - almost 4 years ago

maintainer

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

Cor Blom (cornelisbb) - over 3 years ago

maintainer

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

[...]
Crash reporter disabled
Version 0.0 of the MuseScore SoundFont is outdated, downloading version 0.2.0.
-- [download 0% complete]
-- [download 1% complete]
-- [download 2% complete]
-- [download 3% complete]
[...]

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

1. The VERSION file download failed (maybe the server was down on that day, maybe the OBS firewall doesn't like that server). But if this is what happens, it doesn't explain how the build eventually ends up featuring some version of the MuseScore soundfont, albeit an incorrect one, as no version of that is featured in the source package (check share/sound directory).
2. A soundfont is indeed downloaded, but due to some mysterious and clearly excessive caching from the OBS build farm, it is an old version of the soundfont, not the current one. But if that were what actually happens, then the build log should feature some trace of it, as seen above, which is not the case.

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.

Hadrien Grasland (HadrienG) - over 2 years ago

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.

---

Cor Blom (cornelisbb) - over 2 years ago

maintainer

I have uploaded a version that uses the newer soundfont.

Cor Blom (cornelisbb) - over 2 years ago

maintainer

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.

---

Hadrien Grasland (HadrienG) - over 2 years ago

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.