| Summary: | media-libs/mlt with media-video/ffmpeg USE=flite - mlt_repository_init: failed to dlopen /usr/lib64/mlt/libmltavformat.so (/usr/lib64/libflite_cmu_us_slt.so.1: undefined symbol: usenglish_init) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Red <redblade7> |
| Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kde, randy-andy-, redblade7 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/festvox/flite/pull/5 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Red
2019-04-20 06:19:52 UTC
Newer versions of dependency libraries breaking their users are normally not caused by the dependency library - the users of those libraries need to be updated instead. Hence, this bug report is now about media-libs/mlt - please file a separate bug report for kde-apps/kdenlive The kde-apps/kdenlive issues are filed as bug 683924. Is that still happening with mlt-6.16.0? (In reply to Andreas Sturmlechner from comment #3) > Is that still happening with mlt-6.16.0? Yes, still having the same problem with mlt-6.16.0. *** Bug 683924 has been marked as a duplicate of this bug. *** The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5af67be60304b4e83f60ffb4e1e827e0e88df3c commit e5af67be60304b4e83f60ffb4e1e827e0e88df3c Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-06-29 20:51:17 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-06-29 21:33:53 +0000 media-libs/mlt: Disallow media-video/ffmpeg[flite] Bug: https://bugs.gentoo.org/683870 Package-Manager: Portage-2.3.67, Repoman-2.3.16 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-libs/mlt/mlt-6.16.0-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) No longer blocks stabilisation after USE=-flite was forced. Wouldn't this be a workaround rather than a fix? That's a status we don't have. ;) (In reply to Andreas Sturmlechner from comment #9) > That's a status we don't have. ;) So this bug will exist forever, even though it's considered fixed with a workaround? The fix will probably need to come from upstream, and I would recommend to take it there. Our immediate downstream symptoms are fixed. The blocker is documented in the ebuild anyway, so a considerate bump will involve checking this in changelog. (In reply to Andreas Sturmlechner from comment #11) > The fix will probably need to come from upstream, and I would recommend to > take it there. Our immediate downstream symptoms are fixed. The blocker is > documented in the ebuild anyway, so a considerate bump will involve checking > this in changelog. Oh OK, thank you for clearing that up! I can't find any reference to this upstream in mlt. I suspect this was an issue in flite, probably fixed by https://github.com/festvox/flite/pull/5. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67f62630c15c9b4d26a89bdfeddbf062a97f5136 commit 67f62630c15c9b4d26a89bdfeddbf062a97f5136 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-14 16:27:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-06-14 16:28:32 +0000 media-libs/mlt: drop ffmpeg[-flite] dep I can't find a reference to this in MLT's repo. I suspect this was really an flite-underlinking bug and it was fixed by https://github.com/festvox/flite/pull/5 in flite-2.2. Bug: https://bugs.gentoo.org/683870 Signed-off-by: Sam James <sam@gentoo.org> media-libs/mlt/mlt-7.16.0-r1.ebuild | 158 ++++++++++++++++++++++++++++++++++++ 1 file changed, 158 insertions(+) |
