| Summary: | mask realplayer support | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Steve Dibb (RETIRED) <beandog> |
| Component: | New packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | anotherbearcatfan, che, crusaderky, denilsonsa, dkarasik, gentoo, haavardw, jesse, mark+gentoobugs, pacho, realnc, sudrien, thomas.bettler, Thomas.Rausch, transacid, usefuljunk, zmedico |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | remove all unmaskings of the "real" USE flag | ||
|
Description
Steve Dibb (RETIRED)
2008-11-05 15:21:37 UTC
*** 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 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.
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. What is pending here? (In reply to Pacho Ramos from comment #24) > What is pending here? Closing this one out, the current situation is fine. |