Also see bug 516588, where removing the pangox dep was discussed "a while ago", but unfortunately never got fixed.

(In reply to comment #1)
> Also see bug 516588, where removing the pangox dep was discussed "a while
> ago", but unfortunately never got fixed.

And I don't have anything to add.

* pangox is still in rawhide - The package builds fine.

* What do you suggest to use instead of pangox?
  Patches welcome

* Fedora/RH can not "simply remove" packages, because they are "dead upstream" or because "upstream" wants it to be removed.

(In reply to comment #2)
> (In reply to comment #1)
> > Also see bug 516588, where removing the pangox dep was discussed "a while
> > ago", but unfortunately never got fixed.
> 
> And I don't have anything to add.
> 
> * pangox is still in rawhide - The package builds fine.

pangox is no longer part of pango since this build:
http://koji.fedoraproject.org/koji/buildinfo?buildID=349749

Which is why I filed this bug.

> * What do you suggest to use instead of pangox?

They way I read bug 516588, gtkglext is not actually using functionality from it, just
accidentally linking against it. I could be wrong though :)

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Also see bug 516588, where removing the pangox dep was discussed "a while
> > > ago", but unfortunately never got fixed.
> > 
> > And I don't have anything to add.
> > 
> > * pangox is still in rawhide - The package builds fine.
> 
> pangox is no longer part of pango since this build:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=349749

Read again what I wrote above: 
RH cannot simply abandon packages, which are in use.

Or differently, it's only the fact pangox is part of Gnome2 which enables RedHat to remove this package. If it was of arbitrary origin, you'd likely not have filed this BZ and share my opinion on what you are doing.

> Which is why I filed this bug.
> 
> > * What do you suggest to use instead of pangox?
> 
> They way I read bug 516588, gtkglext is not actually using functionality
> from it, just
> accidentally linking against it. I could be wrong though :)
I need to check, but IIRC, from the last time I checked, believe you to be wrong.

The latest git version of gtkglext (a couple years old) doesn't rely on pangox

(In reply to Michael Petch from comment #5)
> The latest git version of gtkglext (a couple years old) doesn't rely on
> pangox

Which gtkglext are you referring to?

git clone git://git.gnome.org/gtkglext   as mentioned at https://projects.gnome.org/gtkglext/download.html .

(In reply to Michael Petch from comment #5)
> The latest git version of gtkglext (a couple years old) doesn't rely on
> pangox

The unreleased version in git is ABI/API incompatible to gtkglext-1.2.0.
More precisely, it doesn't "not rely on pangox", it has the whole bunch of functions and functionality which currently are implemented through pangex removed.

This means it would break a lot of packages and cause a lot of problems, in Fedora and in different upstreams.

That said, I do not consider the upstream version to be an option[1], but will resort to using pangox-compat in Fedora.


[1] Formally, I am still one of the upstream maintainer, however the whole project actually is stalled, partially because of lack of agreement on how to handle the functional regressions the Gnome project has caused by abandoned pangox and partially because of dissatisfaction with the Gnome project in general.