This is for adding other pending stabilizations as blockers and, for now, the 2.2 tracker
@pacho: why does this depend on gnome-3.14 stable ? I'd say it's the opposite: you need ffmpeg-2 for gst 1.4 stable
apart from that, I'd say we're good to go as long as arch teams proceed with blocker bugs before this one
(In reply to Alexis Ballier from comment #1) > @pacho: why does this depend on gnome-3.14 stable ? I'd say it's the > opposite: you need ffmpeg-2 for gst 1.4 stable This is because of the gst-libav, I thought on two options: - Stabilize its 1.4.x version at the same time of this one (and then all together). - Stabilize all the other gnome-3.14+gst-1.4 pack *but* the gst-livav-1.4 (as 1.2 works ok still with gstreamer-1.4) and, then, stabilize that plugin in this bug report. Anyway we can rethink about it if it becomes the last blocker :/ (ideally we could CC arches in all soon but... we are waiting for bug 530652 and some others and then I don't know how much gnome-3.14+gst-1.4 will be delayed :S)
(In reply to Pacho Ramos from comment #3) > (In reply to Alexis Ballier from comment #1) > > @pacho: why does this depend on gnome-3.14 stable ? I'd say it's the > > opposite: you need ffmpeg-2 for gst 1.4 stable > > This is because of the gst-libav, I thought on two options: > - Stabilize its 1.4.x version at the same time of this one (and then all > together). > - Stabilize all the other gnome-3.14+gst-1.4 pack *but* the gst-livav-1.4 > (as 1.2 works ok still with gstreamer-1.4) and, then, stabilize that plugin > in this bug report. > > Anyway we can rethink about it if it becomes the last blocker :/ (ideally we > could CC arches in all soon but... we are waiting for bug 530652 and some > others and then I don't know how much gnome-3.14+gst-1.4 will be delayed :S) But wait, the starting point of all this was: - gst 1.2 is fine with ffmpeg 2.2 but not with libav-10 - gst 1.4 required ffmpeg 2.2 or libav 10. I patched it to work with libav-9. - ffmpeg 2.2 can be stabilized before gst. - gst-1.4 is then a pivot version: it can be stabilized so that libav-10 can be stabilized later. Is any of the above not true ? (what is not fine with gst 1.2 is ffmpeg 2.3+, which version are still masked)
(In reply to Alexis Ballier from comment #4) [...] > - gst 1.2 is fine with ffmpeg 2.2 but not with libav-10 -> this is not 100% true, if I don't misremember it builds with ffmpeg-2.2 but doesn't really work ok with it (some people have memory leaks), I remember this problem when months ago I needed to look at Mageia patches for that but the memleaks were not really solved until upstream handled them in 1.3.x (at first I remember they backported the fixes from 1.3 to 1.2 but later they reverted that commits as they caused breakages with the libav versions 1.2 is supposed to work)
you'd know better, but i thought this was fixed: *gst-plugins-libav-1.2.4 (25 Jun 2014) 25 Jun 2014; Pacho Ramos <pacho@gentoo.org> +files/gst-plugins-libav-1.2.4-ffmpeg2.patch, +files/gst-plugins-libav-1.2.4-fix-memory-leak.patch, +gst-plugins-libav-1.2.4.ebuild, -gst-plugins-libav-1.2.0.ebuild: Version bump, fix memory leak (#494282)
Oh, yeah, you are true, sorry, many time passed since I committed it. Anyway, reading bug 494282 I am not sure if maybe a rebuild of the plugin after ffmpeg bump (with the := subslots?) would be needed :/
(In reply to Pacho Ramos from comment #7) > Oh, yeah, you are true, sorry, many time passed since I committed it. > Anyway, reading bug 494282 I am not sure if maybe a rebuild of the plugin > after ffmpeg bump (with the := subslots?) would be needed :/ this will be done with the := subslot, but even without it, it'll have preserved-libs or revdep-rebuild
It currently doesn't set := because it's using the virtual: >=virtual/ffmpeg-9-r1[${MULTILIB_USEDEP}] But as the preserved-libs will do the trick, no problem
cc'ing security@g.o since that's from here that we'll handle stabilization to fix blocked sec bugs
2.2.13 Fixes following vulnerabilities: CVE-2015-1872, 4c246c65bfa221c45452923cf148f7b11245b6d5 / fabbfaa095660982cc0bc63242c459561fa37037 2.2.12 Fixes following vulnerabilities: CVE-2014-9603, 7279be7c75c38547994466b6f95bc3cadb05238b / 3030fb7e0d41836f8add6399e9a7c7b740b48bfd CVE-2014-9604, c351cd720a0c870dc09a15b6e191188978349bc7 / 3881606240953b9275a247a1c98a567f3c44890f
been waiting long enough, lets go
arches should also package.use.stable.mask x265 for now, we'll stabilize it later.
Stable for HPPA.
amd64 stable
Why was media-libs/x265 stabilized for hppa?
(In reply to redneb from comment #16) > Why was media-libs/x265 stabilized for hppa? @jer, (In reply to Alexis Ballier from comment #13) > arches should also package.use.stable.mask x265 for now, we'll stabilize it > later.
(In reply to Mikle Kolyada from comment #17) > (In reply to redneb from comment #16) > > Why was media-libs/x265 stabilized for hppa? > > @jer, > > (In reply to Alexis Ballier from comment #13) > > arches should also package.use.stable.mask x265 for now, we'll stabilize it > > later. it's not really a big issue; x265 should go stable rather sooner than later, it's just that its bugs tend to pile up
x86 stable
(In reply to Alexis Ballier from comment #18) > (In reply to Mikle Kolyada from comment #17) > > (In reply to redneb from comment #16) > > > Why was media-libs/x265 stabilized for hppa? > > > > @jer, > > > > (In reply to Alexis Ballier from comment #13) > > > arches should also package.use.stable.mask x265 for now, we'll stabilize it > > > later. > > it's not really a big issue; x265 should go stable rather sooner than later, > it's just that its bugs tend to pile up x265 is stable now on amd64 too, because libav pulls it too.
ppc stable
ppc64 stable
sparc stable
ia64 stable
arm stable
There is now a vulnerability against this version. Non Vulnerable version is 2.2.15. See Bug #548006
This also required these on alpha: =net-libs/libssh-0.7.0-r1 =dev-util/cmocka-0.3.1-r1 Tested and stabilized all three, closing.
