New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
media-sound/musescore: add 4.0.2 #30081
Conversation
Pull Request assignmentSubmitter: @NexAdn media-sound/musescore: @gentoo/sound Linked bugsNo bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment. If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
Another note: with this version, we also tell the build system that we make a MuseScore release build, thus finally dropping the “development” in the user interface's displayed version and the default file paths. |
Pull request CI reportReport generated at: 2023-03-12 20:08 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
4.0.2 just got released, so we might just add that version instead of 4.0.1 |
4.0.2 now added in the PR |
Pull request CI reportReport generated at: 2023-03-15 16:13 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Hello. Have a nice day. |
Allowing to use system libraries is definitely a good idea. However, I'm not a maintainer of media-sound/musescore, so I don't want to put the burden on the current maintainers to maintain such patches. Since those actually change the code, it might be more work to maintain them (especially since the MS4 codebase is relatively fresh and might receive a bunch of frequent changes to the code which in turn might force the package maintainers to refactor their patches. If the package maintainers are up for patching the sources to allow system libraries in a few extra places, they can always publish a new revision of this ebuild. But until then I'd stick with the unpatched version. |
Thank you for the reply. Anyway it seems that Musescore team is not really interested to maintain the possibility to build the software against system libs since the FREETYPE option has been removed from the master branch. |
i get failures when the tests are running:
also, i don't like much dropping all the use flags and system deps, but i personally don't have a capacity for unbundling all the stuff and the link to the unbundled version gave me error 500. it would be good to at least add comment about what all is bundled and why. also, dropping all those use flags means that all those features are now mandatory? |
I'll have a look at that. Tbf, I didn't run the tests when doing the version bump.
More or less. At lease the audio backends were reduced to just ALSA, so we need to depend on ALSA unconditionally and can drop all the other dependencies and stuff. Other features which upstream deemed unnecessary or not so important to keep around were removed entirely, e.g. the OSC remote control. But I might be mistaken. The build system is a mess since v4 (e.g. the code to check for JACK is still in there and is executed, but the software isn't even linked against libjack) and the changelog for v4 is quasi nonexistent. Reasons for some of the changes were explained on YouTube. Anyway, it's hard to find your way around the build system with not a single explanation of which options are available.
If you really want all the stuff configurable, take a look at the root CMakeLists.txt.
That should be possible. All the bundled stuff seems to be in the |
ok, if most of the stuff is now mandatory then that is understandable that the use flags are dropped. i did a quick check of the top level cmake configuration file and i did not find there much of the previous configuration parameters. i suggest we try to unbundle the libs that we already have in the tree. but if that would mean some great amount of work on unbundling or maintenance, we might reconsider it. wrt use flags, we can try to keep it as you did it, unless some issues arise. thank you for working on the ebuild. |
Short update: I've tried to unbundle a few dependencies. Luckily it seems like all the bundled stuff is inside the The more challenging part is that I've already seen that some dependencies' headers are included in the sources by means of |
So, I finished grepping through the repo and unbundle most of the dependencies. MuseScore still works as expected after the unbundling process. I was able to get rid of:
The rest of the bundled dependencies couldn't be unbundled mostly due to the lack of a corresponding package in ::gentoo. Unfortunately, fluidsynth must remain bundled (although it is available in ::gentoo), since MuseScore seems to use parts of the private API which has been removed in recent versions of fluidsynth. rtf2html can't be unbundled either as MuseScore has modified its sources so that this dependency is built as as static library instead of an executable. Also, app-text/rtf2html seems to have received its latest update in 2013 and as such it might become a candidate for last-rite in ::gentoo. The patch updates the CMakeLists and source files to not use the bundled versions of the unbundled libraries. Additionally, I have added an I expect the unbundling process to become a major maintenance burden at least for the next release(s). Since the version 4 release, MuseScore has put much effort into refactoring the build system, so I expect my patches to fail to apply at least at the next release and the work required to rebase them on top of the next release to be quite big. Furthermore, as these patches need to touch source code, I am afraid these might also fail to apply for new releases whenever I have also looked at the test failures. Most of them fail due to a missing X environment, so using virtualx.eclass did the job just fine. Two IO death tests still fail ( |
907181e
to
8dee13d
Compare
Pull request CI reportReport generated at: 2023-05-21 10:03 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2023-05-21 10:13 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
@NexAdn perfect, great job! i'll try to do some tests during the week. wrt the tests, we might disable them if we won't come up with a solution. thank you for the work you do. |
sorry, still too busy... |
just tested the ebuild and it ended up during configuration. it seems dev-libs/tinyxml2 is missing in deps and i don't have it installed in my system so it triggered the issue:
|
My bad! Apparently I missed adding tinyxml to dependencies... |
Closes: https://bugs.gentoo.org/887289 Signed-off-by: Adrian Schollmeyer <nex+b-g-o@nexadn.de>
Pull request CI reportReport generated at: 2023-06-05 06:20 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
merged, thanks! would you mind porting the changes also to the live ebuild? |
Sure, but this might take a some time. Upstream has probably modified parts the build system between 4.0.2 and master again... |
Closes: https://bugs.gentoo.org/887289
I recommend keeping a 3.x version around, since this version did some big changes and dropped some features which some users want to re-implemented before switching from 3.x. The git tree also contains major changes to the way CMake options are named (and maybe the build system in general), so we can't just use a slightly modified version this ebuild as 9999 (hence I didn't alter the 9999 ebuild, yet).