Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 245662 - mask realplayer support
Summary: mask realplayer support
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: media-video herd
URL:
Whiteboard:
Keywords:
: 244947 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-05 15:21 UTC by Steve Dibb (RETIRED)
Modified: 2014-12-27 12:56 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
remove all unmaskings of the "real" USE flag (real_unmasks.patch,4.28 KB, patch)
2008-11-06 00:10 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Dibb (RETIRED) gentoo-dev 2008-11-05 15:21:37 UTC
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
Comment 1 Steve Dibb (RETIRED) gentoo-dev 2008-11-05 15:22:43 UTC
*** Bug 244947 has been marked as a duplicate of this bug. ***
Comment 2 Steve Dibb (RETIRED) gentoo-dev 2008-11-05 15:31:48 UTC
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.
Comment 3 Zac Medico gentoo-dev 2008-11-06 00:10:33 UTC
Created attachment 170871 [details, diff]
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.
Comment 4 Simon Toth 2008-11-08 14:37:11 UTC
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.
Comment 5 Steve Dibb (RETIRED) gentoo-dev 2008-11-09 16:32:16 UTC
Upstream is one reason it's masked.  The others are all the security bugs that it constantly has.
Comment 6 Nikos Chantziaras 2008-11-09 19:45:25 UTC
amd64codecs contains only real codecs?  If not, why mask all of them and not simply remove the real codecs from that package?
Comment 7 Steve Dibb (RETIRED) gentoo-dev 2008-11-10 00:14:18 UTC
(In reply to comment #6)
> amd64codecs contains only real codecs?

Yes.
Comment 8 Sudrien 2008-11-13 05:21:51 UTC
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.
Comment 9 Zac Medico gentoo-dev 2008-11-13 05:32:52 UTC
(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.
Comment 10 Guy 2008-12-27 21:30:55 UTC
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.
Comment 11 Nikos Chantziaras 2008-12-27 22:14:56 UTC
(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".
Comment 12 Guy 2008-12-28 00:46:58 UTC
(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,
Comment 13 Steve Dibb (RETIRED) gentoo-dev 2008-12-31 03:33:26 UTC
(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.
Comment 14 Steve Dibb (RETIRED) gentoo-dev 2009-01-10 14:32:32 UTC
(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.
Comment 15 Steve Dibb (RETIRED) gentoo-dev 2009-02-27 05:28:27 UTC
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.
Comment 16 Denilson Sá Maia 2009-02-27 06:15:32 UTC
(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!
Comment 17 Steve Dibb (RETIRED) gentoo-dev 2009-02-27 07:17:23 UTC
(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.
Comment 18 Denilson Sá Maia 2009-02-27 07:29:21 UTC
(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.
Comment 19 Steve Kutnar 2009-04-04 18:11:40 UTC
(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.
Comment 20 Steve Kutnar 2009-04-04 18:14:17 UTC
(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"
Comment 21 Steve Dibb (RETIRED) gentoo-dev 2009-05-28 15:51:19 UTC
(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.
Comment 22 Denis Dupeyron gentoo-dev 2009-05-30 04:23:54 UTC
(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.
Comment 23 Steve Dibb (RETIRED) gentoo-dev 2009-08-01 05:34:33 UTC
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.
Comment 24 Pacho Ramos gentoo-dev 2013-11-23 16:57:14 UTC
What is pending here?
Comment 25 Steve Dibb (RETIRED) gentoo-dev 2014-03-18 22:54:57 UTC
(In reply to Pacho Ramos from comment #24)
> What is pending here?

Closing this one out, the current situation is fine.