Bug 942315 – media-video/qmplay2-24.06.16 automagic depend on media-libs/rubberband

• Product: Gentoo Linux
• Status: UNCONFIRMED ---

[Description Duncan 2024-10-27 06:23:42 UTC]

qmplay2 has an automagic dep on media-libs/rubberband.  It'd be good to have that fixed before rubberband-4.0.0 goes stable.

My (~amd64) --update --deep @world today included the media-libs/rubberband upgrade: 3.3.0-r1 -> 4.0.0, both default-slot 0.

After that I ran my traditional revdep-rebuild, tho of course these days it seldom has anything to rebuild due to preemptive subslot-dep rebuilds.  But occasionally it catches deps that fell through the cracks, as it did today:

[ 47% ]  *   broken /lib64/libqmplay2.so (requires librubberband.so.2)

Of course libqmplay2.so is part of qmplay2, and librubberband.so.2 is from the old rubberband-3.3.0 (-r1) while rubberband-4.0.0 has librubberband.so.3 but remains default-slot-0.  As confirmation, before the rebuild an ldd of either libqmplay2.so or the QMPlay2 executable lists:

librubberband.so.2 => not found

So I checked the qmplay2 ebuild, and to my shock it didn't list a rubberband dependency /at/ /all/!  And equery depends rubberband lists only ffmpeg (with USE=rubberband, which I have on globally tho equery hasuse rubberband lists only ffmpeg).

OK, so next question, hard undefined dep, or automagic?

Canceling the revdep-rebuild, I -C unmerged rubberband (I have FEATURES=buildpkg so it's a quick binpkg remerge!) and rebuilt qmplay2.  It built fine and an ldd then lacked the librubberband.so listing (tho I didn't runtime-test).  After remerging the rubberband-4.0.0 binpkg I rebuilt qmplay2 again, and now ldd says:

librubberband.so.3 => /usr/lib64/librubberband.so.3 (0x00007526723d5000)

A grep -i rubberband of the qmplay2 build log (with rubberband remerged) starts with this in configure:

-- Checking for module 'rubberband>=3.0.0'
--   Found rubberband, version 4.0.0
-- Checking for module 'rubberband>=3.0.0'
--   Found rubberband, version 4.0.0

Down a bit further in the config summary (under "Enabled Features:" due to automagically finding it in the above for me):

* RubberBand, Build with RubberBand support

Then a bunch of hits in the compile (starting at [151/218]).  All but the last hit appear to be -DQMPLAY2_RUBBERBAND thus giving us the cmake variable I assume the USE flag will need to toggle along with the dep, with the last being a single lowercase -lrubberband when linking libqmplay2.so (at [210/218]).

Adding --count to that grep commandline says 65 hits total.

OK, so it's an automagic dep.  G2Bug search time... nothing apropos found; time to file one!

USE flags:

[ebuild   R    ] media-video/qmplay2-24.06.16::gentoo  USE="alsa inputs notifications opengl qt6 shaders taglib vaapi vulkan -audiofilters -avdevice -cdio -cuvid -extensions -gme -libass -modplug -pipewire -portaudio -pulseaudio -sid -videofilters -visualizations -xv" 0 KiB

[Comment 1 Duncan 2024-10-30 07:22:26 UTC]

Thought maybe I should do the same grep on the build log when rubberband was /not/ installed:

-- Checking for module 'rubberband>=3.0.0'
--   Package 'rubberband' not found

... And obviously now under "Disabled features:"
* RubberBand, Build with RubberBand support


Meanwhile, checked the github homepage.  The README.md says nothing about rubberband (search finds nothing), but the root CMakeLists.txt (both github master and from the version tarball) has:

if(NOT DEFINED USE_RUBBERBAND)
    pkg_check_modules(RUBBERBAND rubberband>=3.0.0)
endif()
option(USE_RUBBERBAND "Build with RubberBand support" ${RUBBERBAND_FOUND})
add_feature_info(RubberBand USE_RUBBERBAND "Build with RubberBand support")

... and src/qmplay2/CMakeLists.txt has:

if(USE_RUBBERBAND)
    add_definitions(-DQMPLAY2_RUBBERBAND)
    pkg_check_modules(RUBBERBAND REQUIRED rubberband>=3.0.0)
    include_directories(${RUBBERBAND_INCLUDE_DIRS})
    link_directories(${RUBBERBAND_LIBRARY_DIRS})
    list(APPEND LIBQMPLAY2_LIBS ${RUBBERBAND_LIBRARIES})
endif()


So the -DQMPLAY2_RUBBERBAND in comment #0 comes from the latter but is controlled by the root CMakeLists.txt USE_RUBBERBAND ... despite the README.md document saying /nothing/ about rubberband in its optional deps discussion, presumably why the gentoo ebuild says nothing about it either...

[Comment 2 Vladislav Mikhailikov 2024-10-31 15:25:34 UTC]

Created attachment 907483 [details, diff]
Rubberband-4.0/GLSLang patch 1 of 3

[Comment 3 Vladislav Mikhailikov 2024-10-31 15:26:02 UTC]

Created attachment 907484 [details, diff]
Rubberband-4.0/GLSLang patch 2 of 3

[Comment 4 Vladislav Mikhailikov 2024-10-31 15:26:30 UTC]

Created attachment 907485 [details, diff]
Rubberband-4.0/GLSLang patch 3 of 3

[Comment 5 Vladislav Mikhailikov 2024-10-31 15:28:36 UTC]

Found the same issue, dig it for a while and make the fix. Now it builds with rubberband-4.0 and glslang-1.3.296.0-r1. For immediate solution put the patches into /etc/portage/patches/media-video/qmplay2 and rebuild qmplay2.

[Comment 6 Duncan 2024-11-01 00:22:47 UTC]

(In reply to Vladislav Mikhailikov from comment #5)
> Found the same issue, dig it for a while and make the fix. Now it builds
> with rubberband-4.0 and glslang-1.3.296.0-r1. For immediate solution put the
> patches into /etc/portage/patches/media-video/qmplay2 and rebuild qmplay2.

??  The effort is appreciated, but something isn't adding up.  I believe your bug is a different bug.

Those are the rubberband/glslang versions I have and it builds fine for me without patches.  Are you saying it wasn't building for you or am I reading that wrong?  (If it's not building for you as-is, compare USE flags at a first guess.  Mine are at the bottom of comment #0.  Maybe I'm not building the affected component due to having a flag off you have on?)

Rather, what this bug is about is that the rubberband dep (glslang isn't declared as a dep either but shaderc is; I'd guess it uses that instead, shaderc-2024.3 here, FWIW) is "automagic", that is, it's detected by the configure step and built against if found, without that dependency declared in the ebuild (AFAIK upstream sources are fine and don't need patched, it's the ebuild that doesn't declare the dep, but should) and either hard-coded on or off, or controlled via USE flag.

It builds fine here against either rubberband version or without any; the ebuild just doesn't declare the dep, so if it finds it and builds against it, and rubberband is unmerged or a version providing a different so version (2 vs. 3) is merged, because portage doesn't know about that dep it doesn't automatically rebuild qmplay2 after the rubberband change, leaving qmplay2 broken until it's rebuilt, either manually, or due to something like revdep-rebuild being run to detect the broken qmplay2 and rebuild it so it works again.

That would be a problem with the ebuild not declaring the dep and not setting the configure-time option for it appropriately, so the ebuild must be fixed.  While the upstream sources /could/ need patched if the option is there (it is) but broken (untested, since the ebuild never sets it either way), for sure the ebuild needs patched.

But I don't see an ebuild patch in the three you provided (and your given /etc/portage/patches instructions only work for upstream patches in any case), they're all three upstream sources patches, and your comment seems to indicate that it wasn't building for you with the same versions it built fine with for me, so whatever problem you had and the patches are supposed to fix, I don't see here and it wasn't what I filed the bug about.

[Comment 7 Vladislav Mikhailikov 2024-11-01 10:12:44 UTC]

(In reply to Duncan from comment #6)
> (In reply to Vladislav Mikhailikov from comment #5)
> > Found the same issue, dig it for a while and make the fix. Now it builds
> > with rubberband-4.0 and glslang-1.3.296.0-r1. For immediate solution put the
> > patches into /etc/portage/patches/media-video/qmplay2 and rebuild qmplay2.
> 
> ??  The effort is appreciated, but something isn't adding up.  I believe
> your bug is a different bug.
> 
> Those are the rubberband/glslang versions I have and it builds fine for me
> without patches.  Are you saying it wasn't building for you or am I reading
> that wrong?  (If it's not building for you as-is, compare USE flags at a
> first guess.  Mine are at the bottom of comment #0.  Maybe I'm not building
> the affected component due to having a flag off you have on?)
> 
> Rather, what this bug is about is that the rubberband dep (glslang isn't
> declared as a dep either but shaderc is; I'd guess it uses that instead,
> shaderc-2024.3 here, FWIW) is "automagic", that is, it's detected by the
> configure step and built against if found, without that dependency declared
> in the ebuild (AFAIK upstream sources are fine and don't need patched, it's
> the ebuild that doesn't declare the dep, but should) and either hard-coded
> on or off, or controlled via USE flag.
> 
> It builds fine here against either rubberband version or without any; the
> ebuild just doesn't declare the dep, so if it finds it and builds against
> it, and rubberband is unmerged or a version providing a different so version
> (2 vs. 3) is merged, because portage doesn't know about that dep it doesn't
> automatically rebuild qmplay2 after the rubberband change, leaving qmplay2
> broken until it's rebuilt, either manually, or due to something like
> revdep-rebuild being run to detect the broken qmplay2 and rebuild it so it
> works again.
> 
> That would be a problem with the ebuild not declaring the dep and not
> setting the configure-time option for it appropriately, so the ebuild must
> be fixed.  While the upstream sources /could/ need patched if the option is
> there (it is) but broken (untested, since the ebuild never sets it either
> way), for sure the ebuild needs patched.
> 
> But I don't see an ebuild patch in the three you provided (and your given
> /etc/portage/patches instructions only work for upstream patches in any
> case), they're all three upstream sources patches, and your comment seems to
> indicate that it wasn't building for you with the same versions it built
> fine with for me, so whatever problem you had and the patches are supposed
> to fix, I don't see here and it wasn't what I filed the bug about.

Ok. Got that. Thank you for suggestion.