Bugzilla Bug 245662

Just a status bug while things get worked out.

Support for realplayer and realplayer binary codecs is going to be masked
because of security and packaging issues.

As far as security, just search bugzilla for the many times there have been
security vulns reported either with realplayer or real codecs.

Packaging issues summarized: upstream does not version their RPMs, licensing
will not allow redistribution, meaning it's a matter of time before the
Manifest breaks.

For more details, including how to install realplayer and its codecs, see
http://forums.gentoo.org/viewtopic-p-5263785.html

*** Bug 244947 has been marked as a duplicate of this bug. ***

real use flag is masked on profiles for mplayer, amarok.

Also, realplayer, amd64codecs (64 bit real binary codecs only) and realcodecs
(32 bit real binary codecs) are all in package.mask as well, hopefully to avoid
any confusion.

Created an attachment (id=170871) [details]
remove all unmaskings of the "real" USE flag

I've just committed this patch to the profiles, to ensure that the "real" flag
is really masked everywhere. This fixes packages like media-video/mplayer so
that the flag is properly masked and repoman won't complain anymore.

OK, I'm just a user and I know that I should shut up and worship all
developers, but I really must react to this bug.

Please use the same approach that is used with java-sdk-docs/java-sdk-docs
ebuild. Warn the user, that the upstream does not correctly version the
packages, set to manual download and prepare one bug (that will remain open) to
report the file changes.

BTW. why do you use security masking anyway? That makes GLSA sort of redundant
project.

Upstream is one reason it's masked.  The others are all the security bugs that
it constantly has.

amd64codecs contains only real codecs?  If not, why mask all of them and not
simply remove the real codecs from that package?

(In reply to comment #6)
> amd64codecs contains only real codecs?

Yes.

I'll note it here as I can not on the forum page - If, after unmasking
everything, gcc-3.3.x come up in the build list, sys-libs/libstdc++-v3 should
be emerged instead. I believe this has to do with the virtual/libstdc++-3.3
dependency.

(In reply to comment #8)
> everything, gcc-3.3.x come up in the build list, sys-libs/libstdc++-v3 should
> be emerged instead.

That's the intend behavior (see bug 161953). If you don't want gcc-3.3.x then
you can put it in /etc/portage/package.mask.

There is a topic not covered in forum post. That topic is if there are any
alternatives to real which are capable of playing real files .rm, .rmvb, .ram
etc.

For example: there is a flash alternative {gnash - granted it still needs a lot
of work ...}. Does such exist for real?

I don't have an objection to real being masked due to the issues with upstream.
In fact, I welcome it. Real Networks needs to get it's act together and
apparently doesn't care.

A little clarification regarding possible playback alternatives in the forum
post would be appreciated. If there are no alternatives, then a line indicating
there are no alternatives available would be good.

Further clarification of some circumstances where an enduser might want to
unmask the various packages would be appreciated as well. For example: If all
the enduser wants to do is play back some existing real media files, then some
guidance as to which packages to unmask and why would be nice.

i.e. -- enduser wants to use mplayer for playback and is arch "amd64", which
package(s) should be unmasked?

Thank you all for your efforts. They are much appreciated.

(In reply to comment #10)
> There is a topic not covered in forum post. That topic is if there are any
> alternatives to real which are capable of playing real files .rm, .rmvb, .ram
> etc.

FFmpeg has support for it now.  RealVideo 4.0
(http://www.phoronix.com/scan.php?page=news_item&px=NjkwMg) and RealVideo 3.0
(http://www.phoronix.com/scan.php?page=news_item&px=Njk0Nw).  So it will be
possible to play them in mplayer (since mplayer uses FFmpeg). Not sure when
exactly, but hopefully "soon".

(In reply to comment #11)
> FFmpeg has support for it now.  RealVideo 4.0
> (http://www.phoronix.com/scan.php?page=news_item&px=NjkwMg) and RealVideo 3.0
> (http://www.phoronix.com/scan.php?page=news_item&px=Njk0Nw).  So it will be
> possible to play them in mplayer (since mplayer uses FFmpeg). Not sure when
> exactly, but hopefully "soon".
> 

Now _that_ is a welcome and good piece of news. I'll be very happy to dump
RealPlayer ASAP.

Let's hope it does happen soon.

Thank you for the tip,

(In reply to comment #11)
> (In reply to comment #10)
> > There is a topic not covered in forum post. That topic is if there are any
> > alternatives to real which are capable of playing real files .rm, .rmvb, .ram
> > etc.
> 
> FFmpeg has support for it now.  RealVideo 4.0
> (http://www.phoronix.com/scan.php?page=news_item&px=NjkwMg) and RealVideo 3.0
> (http://www.phoronix.com/scan.php?page=news_item&px=Njk0Nw).  So it will be
> possible to play them in mplayer (since mplayer uses FFmpeg). Not sure when
> exactly, but hopefully "soon".
> 

Current mplayer (1.0_rc2_p28058-r1) should already support it, though
libavcodec is an early snapshot of when it first got merged and I know there
have been some small bugfixes since the initial inclusion.  If it's not working
all that great, a later snapshot might help out.

(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > There is a topic not covered in forum post. That topic is if there are any
> > > alternatives to real which are capable of playing real files .rm, .rmvb, .ram
> > > etc.
> > 
> > FFmpeg has support for it now.  RealVideo 4.0
> > (http://www.phoronix.com/scan.php?page=news_item&px=NjkwMg) and RealVideo 3.0
> > (http://www.phoronix.com/scan.php?page=news_item&px=Njk0Nw).  So it will be
> > possible to play them in mplayer (since mplayer uses FFmpeg). Not sure when
> > exactly, but hopefully "soon".
> > 
> 
> Current mplayer (1.0_rc2_p28058-r1) should already support it, though
> libavcodec is an early snapshot of when it first got merged and I know there
> have been some small bugfixes since the initial inclusion.  If it's not working
> all that great, a later snapshot might help out.
> 

mplayer-1.0_rc2_p28288.ebuild is in the tree, should have RV30 and RV40
support.

media-video/mplayer-20090226.28734 finally splits up real support from one use
flag (real) into two (real, realcodecs) to actually free up confusion, believe
it or not.

The 'real' use flag, which is unmasked, will enable users to build support for
the internal codecs provided by libavcodec.

The 'realcodecs' use flag is for external, binary support, which is still
masked and unsupported.

The reason for this was because users kept thinking they needed to unmask the
real use flag (on older mplayer ebuilds) to enable real player codecs, which
was never the case.

Hopefully this helps.

And no plans at this time to re-instate support for the binary codecs.  If
anything, I'm more convinced to drop them completely from the tree.

(In reply to comment #15)
> The reason for this was because users kept thinking they needed to unmask the
> real use flag (on older mplayer ebuilds) to enable real player codecs, which
> was never the case.

The name choice seems a bit unfortunate for me.
"real" -> real codecs from libavcodec
"realcodecs" -> binary codecs from real player
Both, in fact, enable codecs, so the names are not good and they will cause
confusion. Maybe "realbinary" would be better, or "realproprietary".

Just my little two cents.

Otherwise, good work!

(In reply to comment #16)
> (In reply to comment #15)
> > The reason for this was because users kept thinking they needed to unmask the
> > real use flag (on older mplayer ebuilds) to enable real player codecs, which
> > was never the case.
> 
> The name choice seems a bit unfortunate for me.
> "real" -> real codecs from libavcodec
> "realcodecs" -> binary codecs from real player
> Both, in fact, enable codecs, so the names are not good and they will cause
> confusion. Maybe "realbinary" would be better, or "realproprietary".
> 
> Just my little two cents.
> 
> Otherwise, good work!
> 

I just figured it'd make more sense to go with the naming scheme of the other
two: win32codecs, amd64codecs, both binary.

(In reply to comment #17)
> I just figured it'd make more sense to go with the naming scheme of the other
> two: win32codecs, amd64codecs, both binary.

Makes sense, but unfortunately there is a flaw in this logic.

win32codecs and amd64codecs are packs, with many different codecs inside (or at
least that's what I understand). But, also, "win32" and "amd64" aren't codecs,
they are platforms. So, they are packs of codecs for those platforms.

realcodecs, however, seems a bit ambiguous, because you need real codecs in
order to play real files. (if those codecs come from libavcodecs or binary real
player... that's another story)

Maybe this can be somewhat "fixed" by adding einfo at mplayer ebuild,
explaining about the difference between these useflags, but it's more like a
dirty hack, a workaround.

If you still want to keep these names, go on. Just make sure the difference is
very well explained.

(In reply to comment #15)
> media-video/mplayer-20090226.28734 finally splits up real support from one use
> flag (real) into two (real, realcodecs) to actually free up confusion, believe
> it or not.
> 
> The 'real' use flag, which is unmasked, will enable users to build support for
> the internal codecs provided by libavcodec.
> 
> The 'realcodecs' use flag is for external, binary support, which is still
> masked and unsupported.
> 
> The reason for this was because users kept thinking they needed to unmask the
> real use flag (on older mplayer ebuilds) to enable real player codecs, which
> was never the case.
> 
> Hopefully this helps.
> 
> And no plans at this time to re-instate support for the binary codecs.  If
> anything, I'm more convinced to drop them completely from the tree.
> 

The problem with this is that on amd64 no-multilib, the "real" USE flag is
masked in /usr/portage/profiles/arch/amd64/no-multilib/use.mask

# 2006/03/22 Danny van Dyk <kugelfang@gentoo.org>
# media-sound/realplayer is x86 only.
real

I have manually un-masked this USE flag, but I see that a few other packages
use this USE flag still in the original intent, so it won't for them, only for
MPlayer.

(In reply to comment #19)
> so it won't for them, only for MPlayer.

Sorry, I missed the word "work" between "won't" and "for"

(In reply to comment #18)
> (In reply to comment #17)
> > I just figured it'd make more sense to go with the naming scheme of the other
> > two: win32codecs, amd64codecs, both binary.
> 
> Makes sense, but unfortunately there is a flaw in this logic.
> 
> win32codecs and amd64codecs are packs, with many different codecs inside (or at
> least that's what I understand). But, also, "win32" and "amd64" aren't codecs,
> they are platforms. So, they are packs of codecs for those platforms.
> 
> realcodecs, however, seems a bit ambiguous, because you need real codecs in
> order to play real files. (if those codecs come from libavcodecs or binary real
> player... that's another story)
> 
> Maybe this can be somewhat "fixed" by adding einfo at mplayer ebuild,
> explaining about the difference between these useflags, but it's more like a
> dirty hack, a workaround.
> 
> If you still want to keep these names, go on. Just make sure the difference is
> very well explained.
> 

Having so many codecs packages is confusing.  Sometimes I wonder if it'd be a
good idea to just scrap all three of them and put them in one ebuild
(binarycodecs, or something) with the proper use flags and leave it at that.

(In reply to comment #18)
> because you need real codecs in order to play real files

All my files and my codecs are real. What are you insinuating ?

Denis.

media-video/realplayer has been punted from the tree.

media-libs/realcodecs will probably be merged into a new ebuild for all the
binary codecs sometime in the future.

No real reason to keep an unmaintained GUI in the tree, though.