This request is superseded by
request 867508
(Show diff)
Overview
Request 867207 superseded
video recording software and dependency for goverlay.
- Created by andythe_great
- In state superseded
- Superseded by 867508
- Open review for openSUSE:Factory:Staging:adi:109
-
Open review for
opensuse-review-team
Loading...
Request History
andythe_great created request
video recording software and dependency for goverlay.
dimstar_suse added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:109"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:adi:109"
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
34+BuildRequires: libdrm2
This sounds very suspect - you BuildRequire a library, no header information, to build? And expect the ABI of a specific version?
I received a report that I need to include it, but I will check it again.
games:tools/replay-sorcery/ReplaySorcery> grep drm . -r
0 hits - so this code has no clue about libdrm and never tries to load it.
neither the BuildRequires nor the recommends on libdrm2 seems justified
Judging from the source code / CMakeLists.txt, one would rather want
pkgconfig(libdrm)
.42+Recommends: libopenh264-6
This is also debatable - generally, you should never ever have to recommend a library in a specific ABI
A possible explanation is that ffmpeg may use dlopen; however, AFAIK, this is only ever done for the fdk-aac gunk and nothing else.
Furthermore, I don't see openh264 enabled in (pm's) ffmpeg, so replay-sorcery could not even make use of it. Which shouldn't be a problem, since there are indications that r-s can ask ffmpeg to use libx264 or libx265.
Lastly, openh264 libx264 and libx265 seem to be hardcoded. This would make this package seemingly useless on a bare openSUSE if it can't even produce webm/vp9/mkv.