Latest release is > 1.5 year old and known to break some apps like freerdp. Please consider adding a -9999 ebuild building from git master
see also https://github.com/cisco/openh264/issues/3432 Upstream seems not to monitor the bug tracker. Spam remains open (https://github.com/cisco/openh264/issues/3421) and other tickets get no response for a long time. Perhaps a patch release would also help?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a8c788824e7b44ef0a406efe0a0e9471fd92c89e commit a8c788824e7b44ef0a406efe0a0e9471fd92c89e Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-01-07 17:44:56 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-01-07 17:44:56 +0000 media-libs/openh264: snapshot openh264 & gmp-api Closes: https://bugs.gentoo.org/829782 Signed-off-by: Joonas Niilola <juippis@gentoo.org> media-libs/openh264/Manifest | 2 + .../openh264/openh264-2.1.1_p20211226.ebuild | 119 +++++++++++++++++++++ 2 files changed, 121 insertions(+)
If you provide a live ebuild, I won't oppose to that. But I don't really feel like writing one. openh264 seems to be migrating towards meson - I hope for the next snapshot or release we can use that.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b9f0712b401d348f666d0087498ff2fc4fb4759e commit b9f0712b401d348f666d0087498ff2fc4fb4759e Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-01-07 18:26:33 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-01-07 18:27:57 +0000 Revert "media-libs/openh264: snapshot openh264 & gmp-api" This reverts commit a8c788824e7b44ef0a406efe0a0e9471fd92c89e. - it seems to downgrade the libraries instead, another better reviewed take later. Bug: https://bugs.gentoo.org/829782 Signed-off-by: Joonas Niilola <juippis@gentoo.org> media-libs/openh264/Manifest | 2 - .../openh264/openh264-2.1.1_p20211226.ebuild | 119 --------------------- 2 files changed, 121 deletions(-)
So the gist is that openh264 soname has broke its ABI while not bumping its SONAME, so it will silently break its revdeps unless we manually bump the subslot value. And doing so will force rebuilds to its revdeps, including monsters like chromium, thunderbird, firefox, and I have a feeling tg_owt is also a big one. So ideally we'd combine the bump with their version bumps. Although I need to check why the soname linking goes from 2.1.1 to 2.1.0 in this snapshot - it makes no sense. I guess we'll look into bumping this at next Firefox's release: https://wiki.mozilla.org/Release_Management/Calendar
(In reply to Joonas Niilola from comment #5) > So the gist is that openh264 soname has broke its ABI while not bumping its > SONAME, so it will silently break its revdeps unless we manually bump the > subslot value. And doing so will force rebuilds to its revdeps, including > monsters like chromium, thunderbird, firefox, and I have a feeling tg_owt is > also a big one. So ideally we'd combine the bump with their version bumps. > Although I need to check why the soname linking goes from 2.1.1 to 2.1.0 in > this snapshot - it makes no sense. > > I guess we'll look into bumping this at next Firefox's release: > https://wiki.mozilla.org/Release_Management/Calendar They updated FULL_VERSION to 2.1.1 on the release branch openh264v2.1.1 only: https://github.com/cisco/openh264/commit/a9f5ec7494331dfe31053711cb0ac9a6d1ebc924
I opened an issue upstream.
(In reply to Joakim Tjernlund from comment #7) > I opened an issue upstream. Could you link to it?
(In reply to Sam James from comment #8) > (In reply to Joakim Tjernlund from comment #7) > > I opened an issue upstream. > > Could you link to it? https://github.com/cisco/openh264/issues/3459
Appears to be two PRs dealing with this and meson: https://github.com/cisco/openh264/pull/3458 (new) https://github.com/cisco/openh264/pull/3351 (old)
I believe the newly committed version update in master fixes the .so version to match the 2.2.1 now. Don't know if ABI has changed in master though.
(In reply to Joakim Tjernlund from comment #11) > I believe the newly committed version update in master fixes the .so version > to match the 2.2.1 now. > Don't know if ABI has changed in master though. Thanks for communicating with upstream. "Will update and release new version in coming days after critical bugs are verified." I think we should wait for this for a few days. I can try to check the abidiff meanwhile if it takes a while, but for now I'd target pushing this along with Firefox-97, whose ETA is 2022-02-08.
(In reply to Joonas Niilola from comment #12) > (In reply to Joakim Tjernlund from comment #11) > > I believe the newly committed version update in master fixes the .so version > > to match the 2.2.1 now. > > Don't know if ABI has changed in master though. > > Thanks for communicating with upstream. > "Will update and release new version in coming days after critical bugs are > verified." > > I think we should wait for this for a few days. I can try to check the > abidiff meanwhile if it takes a while, but for now I'd target pushing this > along with Firefox-97, whose ETA is 2022-02-08. These few days has been going on forever so don't expect too much Got an unofficial comment in the issue that one "do not need to rebuild"
master just increased version to 2.2.0
They haven't made an "official" release yet. This is the "channel" I follow for updates: https://api.github.com/repos/cisco/openh264/releases/latest Also, unfortunately: # qa-cmp -I openh264 CMP: media-libs/openh264-2.1.1_p20190331/image with media-libs/openh264-2.2.0_pre20220125/image ABI: libopenh264.so.6(32) func(+2,-1) [BREAKING] ABI: libopenh264.so.6(64) func(+2,-1) [BREAKING] ------> ABI(+4,-2,>B<) I'm doing some rdep tests atm and am looking to push this together with firefox-96.0.3 and firefox-91.5.1 later today.
Oh and thank you for working with upstream on this!
(In reply to Joonas Niilola from comment #15) > They haven't made an "official" release yet. This is the "channel" I follow > for updates: https://api.github.com/repos/cisco/openh264/releases/latest > > Also, unfortunately: > # qa-cmp -I openh264 > CMP: media-libs/openh264-2.1.1_p20190331/image with > media-libs/openh264-2.2.0_pre20220125/image > ABI: libopenh264.so.6(32) func(+2,-1) [BREAKING] > ABI: libopenh264.so.6(64) func(+2,-1) [BREAKING] > ------> ABI(+4,-2,>B<) > > I'm doing some rdep tests atm and am looking to push this together with > firefox-96.0.3 and firefox-91.5.1 later today. Cool, tool. Can it tell more details about what the breakage is? Which Gentoo pkg has this tool?
(In reply to Joakim Tjernlund from comment #17) > (In reply to Joonas Niilola from comment #15) > > They haven't made an "official" release yet. This is the "channel" I follow > > for updates: https://api.github.com/repos/cisco/openh264/releases/latest > > > > Also, unfortunately: > > # qa-cmp -I openh264 > > CMP: media-libs/openh264-2.1.1_p20190331/image with > > media-libs/openh264-2.2.0_pre20220125/image > > ABI: libopenh264.so.6(32) func(+2,-1) [BREAKING] > > ABI: libopenh264.so.6(64) func(+2,-1) [BREAKING] > > ------> ABI(+4,-2,>B<) > > > > I'm doing some rdep tests atm and am looking to push this together with > > firefox-96.0.3 and firefox-91.5.1 later today. > > Cool, tool. Can it tell more details about what the breakage is? > Which Gentoo pkg has this tool? app-portage/iwdevtools (and the output for the ABI part is libabigail's abidiff)
(In reply to Joakim Tjernlund from comment #17) > > Cool, tool. Can it tell more details about what the breakage is? > Which Gentoo pkg has this tool? iwdevtools as sam mentioned. You can run abidiff directly on the libraries: # abidiff /var/tmp/portage/media-libs/openh264-2.1.1_p20190331/image/usr/lib64/libopenh264.so /var/tmp/portage/media-libs/openh264-2.2.0_pre20220125/image/usr/lib64/libopenh264.so Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 1 Removed, 2 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info 1 Removed function symbol not referenced by debug info: [D] _ZN7WelsDec12CWelsDecoder27ReleaseBufferedReadyPictureEPNS_21TagWelsDecoderContextEPPhP13TagBufferInfo 2 Added function symbols not referenced by debug info: [A] _ZN7WelsDec12CWelsDecoder34ReleaseBufferedReadyPictureReorderEPNS_21TagWelsDecoderContextEPPhP13TagBufferInfob [A] _ZN7WelsDec12CWelsDecoder36ReleaseBufferedReadyPictureNoReorderEPNS_21TagWelsDecoderContextEPPhP13TagBufferInfo I guess the "removed function" makes it a breaking change. If only functions were added, it shouldn't break backwards-compatibility. Anyway I've updated the soname to 6.1 just in case. Still running rdep test for chromium but every other package seem to have passed.
(In reply to Joonas Niilola from comment #19) > (In reply to Joakim Tjernlund from comment #17) > > > > Cool, tool. Can it tell more details about what the breakage is? > > Which Gentoo pkg has this tool? > > I guess the "removed function" makes it a breaking change. If only functions > were added, it shouldn't break backwards-compatibility. Anyway I've updated > the soname to 6.1 just in case. Still running rdep test for chromium but > every other package seem to have passed. Informed upstream in https://github.com/cisco/openh264/issues/3459
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=562810f98f70b4f6eb40547e264ee6f4d1016af9 commit 562810f98f70b4f6eb40547e264ee6f4d1016af9 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-01-27 13:33:40 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-01-27 13:40:19 +0000 media-libs/openh264: add 2.2.0_pre20220125 Closes: https://bugs.gentoo.org/829782 Signed-off-by: Joonas Niilola <juippis@gentoo.org> media-libs/openh264/Manifest | 1 + .../openh264/openh264-2.2.0_pre20220125.ebuild | 119 +++++++++++++++++++++ 2 files changed, 120 insertions(+)
