Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

NexAdn
Copy link
Contributor

@NexAdn NexAdn commented Mar 12, 2023

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

@gentoo-bot
Copy link

Pull Request assignment

Submitter: @NexAdn
Areas affected: ebuilds
Packages affected: media-sound/musescore

media-sound/musescore: @gentoo/sound

Linked bugs

No 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 [please reassign] to the pull request title.

Docs: Code of ConductCopyright policy (expl.) ● DevmanualGitHub PRsProxy-maint guide

@gentoo-bot gentoo-bot added assigned PR successfully assigned to the package maintainer(s). no bug found No Bug/Closes found in the commits. labels Mar 12, 2023
@NexAdn
Copy link
Contributor Author

NexAdn commented Mar 12, 2023

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.

@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2023-03-12 20:08 UTC
Newest commit scanned: 9f39266
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/45321c8fe9/output.html

@NexAdn
Copy link
Contributor Author

NexAdn commented Mar 14, 2023

4.0.2 just got released, so we might just add that version instead of 4.0.1

@NexAdn NexAdn changed the title media-sound/musescore: add 4.0.1 media-sound/musescore: add 4.0.2 Mar 15, 2023
@NexAdn
Copy link
Contributor Author

NexAdn commented Mar 15, 2023

4.0.2 now added in the PR

@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2023-03-15 16:13 UTC
Newest commit scanned: e1be4a9
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/0ba77c5dd6/output.html

@ghost
Copy link

ghost commented Mar 26, 2023

Hello.
I just found out this work on musescore 4. Maybe you could be interested by my work in particular the patch I created to use the system encoders libs. I am beginner in cmake so I do not guarantee that it is perfect in any case but it works on my side. File export tested and it works. Here is the link to musescore ebuild. Note that I also had to patch libopusenc. Here is the link to libopusenc ebuild.

Have a nice day.

@NexAdn
Copy link
Contributor Author

NexAdn commented Mar 26, 2023

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.

@ghost
Copy link

ghost commented Mar 27, 2023

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.

@thesamesam thesamesam requested a review from fordfrog May 12, 2023 20:25
@fordfrog
Copy link
Contributor

i get failures when the tests are running:

>>> Test phase: media-sound/musescore-4.0.2
 * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/media-sound/musescore-4.0.2/work/MuseScore-4.0.2"
 * Build directory  (BUILD_DIR):     "/var/tmp/portage/media-sound/musescore-4.0.2/work/MuseScore-4.0.2_build"
ctest -j 17 --test-load 999
Test project /var/tmp/portage/media-sound/musescore-4.0.2/work/MuseScore-4.0.2_build
      Start  1: global_tests
      Start  2: draw_tests
      Start  3: mpe_test
      Start  4: ui_tests
      Start  5: accessibility_tests
      Start  6: engraving_utests
      Start  7: iex_bb_tests
      Start  8: iex_braille_tests
      Start  9: iex_bww_tests
      Start 10: iex_capella_tests
      Start 11: iex_guitarpro_tests
      Start 12: iex_midi_tests
      Start 13: iex_musicxml_tests
      Start 14: project_test
      Start 15: plugins_tests
 1/15 Test  #1: global_tests .....................Subprocess aborted***Exception:   0.02 sec
 2/15 Test  #2: draw_tests .......................Subprocess aborted***Exception:   0.02 sec
 3/15 Test  #3: mpe_test .........................Subprocess aborted***Exception:   0.02 sec
 4/15 Test  #4: ui_tests .........................Subprocess aborted***Exception:   0.01 sec
 5/15 Test  #5: accessibility_tests ..............Subprocess aborted***Exception:   0.01 sec
 6/15 Test  #6: engraving_utests .................Subprocess aborted***Exception:   0.01 sec
 7/15 Test  #8: iex_braille_tests ................Subprocess aborted***Exception:   0.01 sec
 8/15 Test #10: iex_capella_tests ................Subprocess aborted***Exception:   0.01 sec
 9/15 Test #11: iex_guitarpro_tests ..............Subprocess aborted***Exception:   0.01 sec
10/15 Test #14: project_test .....................Subprocess aborted***Exception:   0.01 sec
11/15 Test  #9: iex_bww_tests ....................Subprocess aborted***Exception:   0.02 sec
12/15 Test #12: iex_midi_tests ...................Subprocess aborted***Exception:   0.01 sec
13/15 Test  #7: iex_bb_tests .....................Subprocess aborted***Exception:   0.02 sec
14/15 Test #13: iex_musicxml_tests ...............Subprocess aborted***Exception:   0.01 sec
15/15 Test #15: plugins_tests ....................Subprocess aborted***Exception:   0.01 sec

0% tests passed, 15 tests failed out of 15

Total Test time (real) =   0.03 sec

The following tests FAILED:
	  1 - global_tests (Subprocess aborted)
	  2 - draw_tests (Subprocess aborted)
	  3 - mpe_test (Subprocess aborted)
	  4 - ui_tests (Subprocess aborted)
	  5 - accessibility_tests (Subprocess aborted)
	  6 - engraving_utests (Subprocess aborted)
	  7 - iex_bb_tests (Subprocess aborted)
	  8 - iex_braille_tests (Subprocess aborted)
	  9 - iex_bww_tests (Subprocess aborted)
	 10 - iex_capella_tests (Subprocess aborted)
	 11 - iex_guitarpro_tests (Subprocess aborted)
	 12 - iex_midi_tests (Subprocess aborted)
	 13 - iex_musicxml_tests (Subprocess aborted)
	 14 - project_test (Subprocess aborted)
	 15 - plugins_tests (Subprocess aborted)
Errors while running CTest
Output from these tests are in: /var/tmp/portage/media-sound/musescore-4.0.2/work/MuseScore-4.0.2_build/Testing/Temporary/LastTest.log

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?

@NexAdn
Copy link
Contributor Author

NexAdn commented May 13, 2023

i get failures when the tests are running:

I'll have a look at that. Tbf, I didn't run the tests when doing the version bump.

dropping all those use flags means that all those features are now mandatory?

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.

i don't like much dropping all the use flags

If you really want all the stuff configurable, take a look at the root CMakeLists.txt.
There are still some configuration options left, like the audio module, midi module, network module, etc. Some of these could be made configurable, but that would introduce use flags with are probably not very related to the flags from <4. Also, this would mean reading through the whole conglomerate of CMakeLists and trying to find all the dependencies each module introduces. With all the dead and/or unused code or dependency checks lying around, this is not a very pleasant experience. It took me long enough to understand how MuseScore detects libjack and why that doesn't work, just to find out that I've looked at some dead code the developers didn't even use and that libjack isn't even a dependency anymore.

it would be good to at least add comment about what all is bundled and why.

That should be possible. All the bundled stuff seems to be in the thirdparty folder in the repo. I didn't unbundle anything, since I didn't want to put the burden to maintain the unbundling stuff on you (see my comment above). If you think that system packages should be unbundled (or whatever you think is worth unbundling), I can work on that.

@fordfrog
Copy link
Contributor

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.

@NexAdn
Copy link
Contributor Author

NexAdn commented May 15, 2023

Short update: I've tried to unbundle a few dependencies. Luckily it seems like all the bundled stuff is inside the thirdparty-Folder and included by using add_subdirectory(). The targets to link against are added to MODULE_LINK in the CMakeLists. That makes unbundling system deps relatively easy, since we can just replace add_subdirectory() with find_package() or pkg_check_modules() and update MODULE_LINK.

The more challenging part is that I've already seen that some dependencies' headers are included in the sources by means of #include <thirdparty/..., which makes unbundling a bit harder. I still have to check if this maybe only applies to stuff which isn't available as system package anyway. In some other places, unbundling requires to change the #include statements to include the lib's directory name in /usr/include (e.g. #include "lame.h" becomes #include "lame/lame.h"). This might increase future maintenance overhead a bit depending on how much the files with these includes change over time.

@NexAdn
Copy link
Contributor Author

NexAdn commented May 21, 2023

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:

  • flac (replaced with media-libs/flac)
  • freetype (replaced with media-libs/freetype)
  • googletest (replaced with dev-cpp/gtest)
  • lame (replaced with media-sound/lame)
  • opus (replaced with media-libs/opus)
  • opusenc (replaced with media-libs/libopusenc)

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 rm -r call in src_prepare() to remove the directories of the unbundled dependencies as a safety measure (I want to fail hard if the sources still access those bundled libs to prevent both versions of such a lib being used during compilation).

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 #includes in the source code are updated.

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 (Global_IO_IODeviceTests.Open_ReadOnly and Global_IO_IODeviceTests.Open_WriteOnly, but I'm not entirely sure, why. Some death tests fail because the function which is executed doesn't seem to die. However, when running the tests in a local checkout of the repo with a real X environment, the tests work like a charm. Interestingly, the error messages which are expected to occur are present both in the failing tests for the Gentoo package as well as in the local checkout, so it looks like the death tests fail despite the error, that is being tested for, occuring in both cases. How should we proceed with this situation?

@NexAdn NexAdn force-pushed the musescore-4.0.1 branch 2 times, most recently from 907181e to 8dee13d Compare May 21, 2023 09:56
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2023-05-21 10:03 UTC
Newest commit scanned: 907181e
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/e2c29580e0/output.html

@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2023-05-21 10:13 UTC
Newest commit scanned: 8dee13d
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/96643f7030/output.html

@fordfrog
Copy link
Contributor

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

@fordfrog
Copy link
Contributor

sorry, still too busy...

@fordfrog
Copy link
Contributor

fordfrog commented Jun 5, 2023

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:

QMake version 3.1
Using Qt version 5.15.9 in /usr/lib64
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.13.0") 
-- Found PkgConfig: /usr/bin/x86_64-pc-linux-gnu-pkg-config (found version "1.8.1") 
-- Found sndfile: /usr/lib64/libsndfile.so /usr/include
-- Enabled testing
-- Found GTest: /usr/lib64/cmake/GTest/GTestConfig.cmake (found version "1.13.0")  
CMake Error at src/framework/global/CMakeLists.txt:125 (find_package):
  By not providing "Findtinyxml2.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "tinyxml2",
  but CMake did not find one.

  Could not find a package configuration file provided by "tinyxml2" with any
  of the following names:

    tinyxml2Config.cmake
    tinyxml2-config.cmake

  Add the installation prefix of "tinyxml2" to CMAKE_PREFIX_PATH or set
  "tinyxml2_DIR" to a directory containing one of the above files.  If
  "tinyxml2" provides a separate development package or SDK, be sure it has
  been installed.


-- Configuring incomplete, errors occurred!

@NexAdn
Copy link
Contributor Author

NexAdn commented Jun 5, 2023

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>
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2023-06-05 06:20 UTC
Newest commit scanned: d85f2f3
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/1f7152d170/output.html

@gentoo-bot gentoo-bot closed this in fbe6b84 Jun 6, 2023
@fordfrog
Copy link
Contributor

fordfrog commented Jun 6, 2023

merged, thanks! would you mind porting the changes also to the live ebuild?

@NexAdn
Copy link
Contributor Author

NexAdn commented Jun 11, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assigned PR successfully assigned to the package maintainer(s). no bug found No Bug/Closes found in the commits.
Projects
None yet
4 participants