On Qua, 2016-12-07 at 10:51 -0600, Yaakov Selkowitz wrote:

On 2016-12-07 10:06, Michael Cronenworth wrote:

...

As I'm sure everyone is well aware gstreamer-0.10 is obsolete and has been replaced by gstreamer-1.0. An upstream release for gst-0.10 has not been made in over 4 years. Last month there were a handful of security vulnerabilities disclosed[1] and upstream no longer maintains the 0.10 series. While we could patch and update our Fedora packages this is a perfect opportunity to retire it.

Here is an approximate list of packages depending on gst-0.10. They themselves should be considered obsolete or retirement material as their upstreams may not have adopted gst-1.0. If the package doesn't have a gst-1.0 equivalent there may be some cases where we could patch in support for gst-1.0. Are there any non-Fedora software that would prevent retirement from being possible?

anchorman banshee-community-extensions bigloo-libs clutter-gst compat-wxGTK3-gtk2-media drawtk evas-generic-loaders flumotion gcompris gloobus-preview gnome-mud gnomebaker gstreamer-devel gstreamer-ffmpeg gstreamer-plugins-bad gstreamer-plugins-bad-free gstreamer-plugins-bad-free-extras gstreamer-plugins-base gstreamer-plugins-base-tools gstreamer-plugins-good gstreamer-plugins-good-extras gstreamer-plugins-ugly gstreamer-python gstreamer-rtsp gstreamer-rtsp-python gstreamermm gstreamermm-devel ignuit iptux libgnome-media-profiles libnice-gstreamer lordsawar media-explorer moodbar oggconvert perl-GStreamer perl-GStreamer-Interfaces player pocketsphinx-plugin presence psimedia qt-mobility-multimediakit sap subtitleeditor vagalume winswitch wxGTK-media wxGTK3-media xfce4-mixer xfce4-volumed

There are more via the Python bindings:

beets-plugins decibel-audio-player exaile flumotion gmediafinder gst-inspector oggconvert pogo pychess radiotray soundconverter sugar-clock sugar-memorize sugar-record sugar-speak turpial whaawmp wordgroupz

Hi, like webkit < 3 retirement , you shouldn't repoquery with  --recursive, If I am correct .

Again after wxGTK and wxGTK3 be updated all dependencies will be solved automatically , also same case for wxPython , If I am correct.

What I mean is: first we should concern in --whatrequires gstreamer- 0.10 directly to understand what really is in question .

Thanks.

Thanks for reply

On Qua, 2016-12-07 at 11:56 -0600, Yaakov Selkowitz wrote:

On 2016-12-07 11:49, Sérgio Basto wrote:

...

Hi, like webkit < 3 retirement , you shouldn't repoquery with --recursive, If I am correct .

Again after wxGTK and wxGTK3 be updated all dependencies will be solved automatically , also same case for wxPython , If I am correct.

Incorrect.  I was talking about gstreamer-python, not wxPython.  Furthermore, wxGTK's gstreamer dependency is already isolated in  wxGTK{,3}-media, so only its reverse dependencies are affected, not  everything that uses wxGTK.

Yes, I mention wxGTK{,3} because we have other process similar to this around webkit [1]

...

What I mean is: first we should concern in --whatrequires gstreamer- 0.10 directly to understand what really is in question .

Anything which --whatrequires gstreamer-python is clearly affected as well.

But for gstreamer-python we don't have gstreamer1-python ? so how we can fix the packages that have dependencies on gstreamer-python ?

As part of a global ideia of maintain packages, should be good have specialists in migrating components, in this case gstreamer0 to gstreamer1.

Also do all migrations (maintain) of all the packages together could be more efficient (just an ideia).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1375846

On 7 Dec 2016, at 18:20, Sérgio Basto sergio@serjux.com wrote:

Thanks for reply

On Qua, 2016-12-07 at 11:56 -0600, Yaakov Selkowitz wrote:

...

On 2016-12-07 11:49, Sérgio Basto wrote:

...

Hi, like webkit < 3 retirement , you shouldn't repoquery with --recursive, If I am correct .

Again after wxGTK and wxGTK3 be updated all dependencies will be solved automatically , also same case for wxPython , If I am correct.

Incorrect. I was talking about gstreamer-python, not wxPython. Furthermore, wxGTK's gstreamer dependency is already isolated in wxGTK{,3}-media, so only its reverse dependencies are affected, not everything that uses wxGTK.

Yes, I mention wxGTK{,3} because we have other process similar to this around webkit [1]

...

...

What I mean is: first we should concern in --whatrequires gstreamer- 0.10 directly to understand what really is in question .

Anything which --whatrequires gstreamer-python is clearly affected as well.

But for gstreamer-python we don't have gstreamer1-python ? so how we can fix the packages that have dependencies on gstreamer-python ?

We do, however, have python-gstreamer1 in both flavours (Python 2 and Python 3), which is the extras on top of GI to make it easy to work with.

As part of a global ideia of maintain packages, should be good have specialists in migrating components, in this case gstreamer0 to gstreamer1.

Also do all migrations (maintain) of all the packages together could be more efficient (just an ideia).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1375846 -- Sérgio M. B.

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org

On Wed, 2016-12-07 at 10:51 -0600, Yaakov Selkowitz wrote:

soundconverter

I use this a lot, but there is active work on it upstream and the active git branch (py3k) uses gstreamer 1.0:

https://github.com/kassoulet/soundconverter/

there hasn't been a stable release of the 'new generation' code though (which converts to python3 as well as using gstreamer 1.0).

beets-plugins

Beets uses gstreamer 1.x in the latest release.

On 12/07/2016 05:07 PM, Sérgio Basto wrote:

gstreamermm-1.4.3-1.fc25 looks like already use gstreamer1 subtitleeditor-0.53.0-1.fc25 also already use gstreamer1

That's good! My initial list was run from Fedora 24 at the time. Here is a revised list run from Rawhide (with Python packages):

anchorman banshee-community-extensions beets-plugins bigloo-libs clutter-gst compat-wxGTK3-gtk2-media decibel-audio-player drawtk evas-generic-loaders exaile flumotion gcompris gloobus-preview gmediafinder gnome-mud gnomebaker gst-inspector gstreamer-ffmpeg gstreamer-plugins-bad-free gstreamer-plugins-bad-free-extras gstreamer-plugins-bad-nonfree gstreamer-plugins-base gstreamer-plugins-base-tools gstreamer-plugins-good gstreamer-plugins-good-extras gstreamer-python gstreamer-rtsp gstreamer-rtsp-python ignuit iptux libgnome-media-profiles libnice-gstreamer moodbar oggconvert perl-GStreamer perl-GStreamer-Interfaces player pocketsphinx-plugin pogo presence psimedia pychess qt-mobility-multimediakit radiotray sap soundconverter sugar-clock sugar-memorize sugar-record sugar-speak turpial vagalume whaawmp winswitch wordgroupz wxGTK-media wxGTK3-media xfce4-mixer xfce4-volumed

beets-plugins

Beets can use gstreamer 1.x in the latest releases.

I sent this weeks ago when it was a popular topic, but my email client was misconfigured, so it never made it.

sorry, I meant webkitgtk4 instead of gtkwebkit4.

On Wed, Dec 7, 2016 at 4:59 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:

On Wed, 2016-12-07 at 10:06 -0600, Michael Cronenworth wrote:

...

While we could patch and update our Fedora packages this is a perfect opportunity to retire it.

I just want to add an explicit +1 in support of this proposal. Packages with insecure dependencies like gstreamer-0.10 are not likely to get fixed anytime soon unless we go ahead and remove the dependency from the distro.

-1 at least for the moment. b

On Thu, Dec 8, 2016 at 4:49 AM, Michael Cronenworth mike@cchtml.com wrote:

On 12/07/2016 04:29 PM, Peter Robinson wrote:

...

-1 at least for the moment. b

Is this due to sugar? Would you accept patches?

One of the reasons, and of course, I think if we want to actively retire packages we need to enage with the owners of the dependencies.

On Thu, 2016-12-08 at 14:24 +0100, Dominik 'Rathann' Mierzejewski wrote:

One important example is the Citrix Receiver for Linux[1], which depends on gstreamer-0.10: $ rpm -qR ICAClient|grep gst libgstapp-0.10.so.0()(64bit) libgstbase-0.10.so.0()(64bit) libgstinterfaces-0.10.so.0()(64bit) libgstpbutils-0.10.so.0()(64bit) libgstreamer-0.10.so.0()(64bit)

I will try and give them heads-up on their community forum[2], but I don't hold much hope. They're still using the old webkitgtk, too.

So since old WebKitGTK+ is going away, the decision to retire gstreamer-0.10 doesn't make any difference for Citrix Receiver.

Michael

On 12/10/2016 02:16 PM, Peter Oliver wrote:

On 9 Dec 2016 5:02 a.m., "Kevin Kofler" <kevin.kofler@chello.at mailto:kevin.kofler@chello.at> wrote:

Retiring such a library
is a very long process and not doable within a Fedora release.

Is this true?

Yes, it is.

One could drop a library and it's dependants and that would be that.

You can not remove any package without a drop-in replacement in a released version of Fedora, because it would break user installations.

I.e. you can only retire packages from rawhide.

Ralf

On Tue, 2017-01-31 at 11:29 +0000, Christian Stadelmann wrote:

The same should probably be done for qtwebkit (Qt4) and qt5-qtwebkit (Qt5) …. Is there any procedure for this? I cannot find the F27 proposed change to remove webkitgtk and webkitgtk3 either.

The reason I proposed holding off on removing QtWebKit is that there is an active QtWebKit fork that we can switch to soon, instead of relying on the insecure QtWebKit distributed by the Qt project.

There is no release yet, but one is coming soon. It will be based on WebKitGTK+ 2.12, which means it will still have dozens of security bugs, but way fewer than upstream QtWebKit, so it's at least a huge improvement over the status quo; an update straight to future WebKitGTK+ 2.16, skipping the current version 2.14, will come next. (Yes, QtWebKit will be a downstream of WebKitGTK+... it will work out fine. ;) So once that is ready, we can change our upstream for QtWebKit from the Qt project to this new project, and then we don't have to get rid of KDE applications that haven't ported to QtWebEngine. I think this can happen for Fedora 26, and then we can start doing major QtWebKit version updates to all supported Fedoras >= F26 the same way we are already handling WebKitGTK+ updates.

The catch is I am not a Qt or KDE developer and so am not motivated to work on this, so someone from that community will have to step up to handle the switch, plus handle future QtWebKit updates.

Note: new upstream is https://github.com/annulen/webkit/. First release is expected in 3-4 weeks. Konstantin, the developer, says it's almost ready now except for problems with QML applications that he wants to fix before releasing.

Michael

P.S. FWIW I agree with retiring gstreamer-0.10 and its dependencies. Old insecure libs will stay around forever unless we set a deadline for dependencies to be ported.

On Tue, 31 Jan 2017, Sérgio Basto wrote:

...

How about handling it the same way we handle old GtkWebKit versions? As soon as F26 is branched from Rawhide (expected in 2017-02-21), retire this package? This would give package maintainers enough time to get their packages fixed (about 9 months) until Fedora 27 is released. Any package that has not been ported until then is unmaintained or under-maintained anyway and should not be in Fedora due to other (compatibility, stability) reasons.

The same should probably be done for qtwebkit (Qt4) and qt5-qtwebkit (Qt5) …. Is there any procedure for this? I cannot find the F27 proposed change to remove webkitgtk and webkitgtk3 either.

Before we have any decision , we should have a map of what will be retired , since one of the package is wxGTK3, we have wxGTK3-devel and and wx3-GTK2-devel (which looks that still works better) and a bunch of package depend on it , so 9 months could not be much . Remove just gstreamer-0.10 and not all webkitgtk  and webkitgtk3 it will IMO a bad plan , we have some good software that is still based on it , some of them are in RPMFusion .

wxGTK3 has already moved to gstreamer 1.0.

compat-wxGTK3-gtk2 should also move to gstreamer 1.0 - I filed [1] for this - they can use the same patch that is used in wxGTK3.

As for the original wxGTK - well it should be retired itself. :) At the very least it could probably be rebuilt without the -media subpackage. It appears that only wxPerl depends on it.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1421920

Scott