Bug 10066 - Update: realplayer-8-r4.ebuild
|
Bug#:
10066
|
Product: Gentoo Linux
|
Version: 1.4_rc1
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: seemant@gentoo.org
|
Reported By: danny@ricin.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: Update: realplayer-8-r4.ebuild
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2002-11-01 16:57 0000
|
Quick fix to have the RealVideo9 codecs be installed as well.
Description:
* media-video/realplayer
Latest version available: 8-r3
Latest version installed: [ Not Installed ]
Homepage: http://forms.real.com/real/player/unix/unix.html
Description: Real Player 8 basic with RV9 support
Details:
- Quick fix to install the RV9 patch with RealPlayer8. Interfered with
existing r2 ebuild as little as possible.
- See also #10065. There is no depend or block relationship between 10065 and
10066 though.
Digest:
MD5 525f6f050d076148e9e02769f2055d53 rp8_linux20_libc6_i386_cs2_rpm 4929328
MD5 b2fd9f4148edfd8e2a714dd57634ae1b rv9_libc6_i386_cs2.tgz 814305
Changelog:
Updated ebuild to include RealVideo9 codecs.
Attached files:
realplayer-8-r3.ebuild
Description: * media-video/realplayer Latest version available: 8-r3
Latest version installed: [ Not Installed ] Homepage:
http://forms.real.com/real/player/unix/unix.html Description: Real
Player 8 basic with RV9 support Details: - Quick fix to install the RV9
patch with RealPlayer8. Interfered with existing r2 ebuild as little as
possible. - See also #10065. There is no depend or block relationship between
10065 and 10066 though. Digest: MD5 525f6f050d076148e9e02769f2055d53
rp8_linux20_libc6_i386_cs2_rpm 4929328 MD5 b2fd9f4148edfd8e2a714dd57634ae1b
rv9_libc6_i386_cs2.tgz 814305 Changelog: Updated ebuild to include
RealVideo9 codecs. Attached files: realplayer-8-r3.ebuild
Description: * media-video/realplayer Latest version available: 8-r3
Latest version installed: [ Not Installed ] Homepage:
http://forms.real.com/real/player/unix/unix.html Description: Real
Player 8 basic with RV9 support Details: - Quick fix to install the RV9
patch with RealPlayer8. Interfered with existing r2 ebuild as little as
possible. - See also #10065. There is no depend or block relationship between
10065 and 10066 though. Digest: MD5 525f6f050d076148e9e02769f2055d53
rp8_linux20_libc6_i386_cs2_rpm 4929328 MD5 b2fd9f4148edfd8e2a714dd57634ae1b
rv9_libc6_i386_cs2.tgz 814305 Changelog: Updated ebuild to include
RealVideo9 codecs. Attached files: realplayer-8-r3.ebuild
Sorry for making such a mess. Was jumping between two browsers. Both ebuilds
are the same.
Hi;
I just tested this ebuild, and it seems ok. realplayer-8-r2.ebuild however
is broken for me. It turns the rpm into a gzip'd tarball, but doesnt unpack it, so
there are no files found come install time. (seems to be simply missing the
'tar xzf ${blah}')
And -r2 is the only realplayer ebuild currently in my rsync'd portage.
Paul
Paul,
rpm2cpio ${DISTDIR}/${A} | cpio -i --make-directories
is what's being used in r2 to extract the archive. I left it largely unchanged
in r3, but it doesn't use the ${A} variable which appears to be the crux. I
suspect that ${A} already includes ${DISTDIR} but would need to test to find
out. It's not missing a tar command though, cpio does the extracting.
I am not responsible for r2, neither can I change it. If you get a
reproducable error with r2 but not with r3 I'd suggest you either use r3 from
a local portage tree, or emerge realone player [bug #10065] which has gone
into the tree as "~x86", or file a separate bug report for r2. However the
last option would probably just be marked as a duplicate of this one because
r3 seems to fix it (accidentally I might add).
Please note that I have no saying about whether or not this r3 will be put
into the portage tree. I do think it would be a good idea to do this,
especially if the r2 indeed has a fatal bug. FYI, I made the r3 more or less
as a courtesy fix to include RV9 after I did the realone ebuild. I only
verified that r3 ran and that it could play a RV9 clip. I have never used r2.
You may want to ask the portage team to get r3 into the tree faster, but
please take into consideration the huge amount of submitted ebuilds they have
to go through. If impatient, just emerge realone.
I suggest adding yourself to the CC list top-right of this page if you'd like
to track the status of r3.
HTH,
Dan
Hey Dan;
rpm2cpio may have been in rc2 once, but its not now. It uses
rpm2targz ${DISTDIR}/${A} which creates a tarball, and
doesnt extract it.
Thanks for the pointer to realone-- I currently running -r3
in local portage, and just wanted to mention the brokenness
of -r2 as it appears in my tree after recent rsync, and that
-r3 seems like what should be the fix. Unless, 'realplayer'
should just go away, and 'realone' replace it.
Paul
Thanks for clarifying, Paul.
I just rsync'ed -last time was Nov 5- and noticed the change in r2 made on
Nov 8. I'm rather new to Gentoo and perhaps I don't understand the development
model and QA policy, but this sure seems kinda sloppy. No revision bump, no
changelog, no apparent reason for the change, and it doesn't work. But I'll
shut up now :)
Regarding realplayer vs. realone, well I don't expect Real to release any new
versions of rp8. Currently realone lacks some GUI functionality. If Real does
the same as they did with their previous Linux players, I expect a second
"gold" release of the player soon, hopefully with some bugfixes and that will
be it. That may be a good time to let rp8 die but for now I'd say let users
decide because with the RV9 codecs rp8 and realone have the same rendering
capabilities. I'm not the one to decide this, just MHO.
first, my apologies for having a broken ebuild. it got checked in by accident.
I am actually working on rehashing the realplayer stuff completely. Currently,
I am waiting for word from real.com as to whether we can do what we do in the
realone.ebuild (I'm not convinced we're being kosher on that one).
NP Seemant. I forgive you :)
About the realone ebuild and whether Real likes it or not: I know, the realone
ebuild might be on the edge. And I have been thinking about this a lot when
creating it, written a disclaimer, removed that again, etc. There was this
certain four letter word popping up in my head but in the end I decided to let
others decide and almost forgot about it. Two facts: no bypassing of any
identifiable protective measures and unless reading plain text is a dubious
act, no reverse engineering. It was one of those challenges that once started
you just have to get working...
But you are right, it may be wise to check with Real. However, I expect them
to say no or nothing which can always be explained as a no, even if the net
result isn't really any different compared to single user install except for
20+ megs in every user's home page. Well, who knows, they might surprise me.
It's good that you care about the legalese. Thank you. I don't want to cause
no trouble and will back you fully if we need to withdraw the ebuild. Ditto if
it would have to be put "on hold". Think of the good PR (and start looking
into the helix DNA code :)
Thanks for your reaction, it clarifies a whole lot to me. Perhaps the ebuild
got thrown into cvs a bit too soon. Perhaps I should have known better than to
post it. Once again, I'm really sorry if causing trouble, I never meant to.
I considered mailing privately but I thought this should be public. Not
everything has to be though. Please let me know how this is progressing.
Best regards,
Dan
Urgh! "home page" should have been "home directory" hehe
Danny, no you did a good thing by submitting it. In fact, your realone ebuild
has led to the development of the rp8 ebuild to include other architectures, in
fact. The only bad thing is that the realone got committed by another developer
(who I asked to just try it), and by the time I found out, it had hit portage
already :/
I've contacted real via e-mail and phone. Let's see what happens :)
Uhm I noticed it got rsync'ed but was not in CVS log yeah. Oh well let's not
blame him, let's not blame anyone. Let's save the blame for Real :)
[sorry couldn't resist]
OK, so I've been on the phone with Rob over at real.com -- we should know
something on Wednesday about both the realone ebuild (which I have shown him)
and the rp8 stuff. Ideally, we want to be able to get these dynamically...
Let's see what happens on Wednesday.
for now, we have to still ask the user to fetch the files themselves, but Danny
is working on a new, improved ebuild which should allow realplayer to be
installed on all our arches.
Created an attachment (id=5812) [details]
media-video/realplayer/realplayer-8-r3.ebuild
Description:
* media-video/realplayer
Latest version available: 8-r3
Homepage: http://forms.real.com/real/player/unix/unix.html
Description: RealPlayer 8 is a streaming media player
Details:
- Ebuild should be able to install RP8 for all architectures
- RV9 support for the x86 version
- RP8 binaries still have fetch restriction
- Ebuild installs Netscape/Mozilla plugin and a desktop entry
- OBSOLETES FORMER r3 EBUILD!
Digest:
MD5 42624f63c980156da8fb9ff7fd86b083 rp8_linux20_libc6_i386_cs2.bin 5890331
MD5 b2fd9f4148edfd8e2a714dd57634ae1b rv9_libc6_i386_cs2.tgz 814305
MD5 39a5d43cea49198464b2caddfffc6c09 rp8_linux_powerpc_cs1.bin 8758422
MD5 f6956d7daa5b35295b7b3560a00f8631 rp8_linux_alpha_rh62_cs1.bin 8899116
MD5 3e400b804a0874a0865fd53c1e1a0f0d rp8_linux_sparc_cs1.bin 7484808
Changelog:
Workover to support all architectures and add RV9 for x86, danny@ricin.com
Attached files:
realplayer-8-r3.ebuild
realplayer.desktop
mimeinfo (currently for reference only)
Needed testing:
- Archs other than x86, all I can verify myself is that they unpack properly
- Whether desktop entry works OK with Gnome (and its default mimetypes)
Notes:
- Formally, the KEYWORDS should actually be ~x86 -ppc -sparc -sparc64 -alpha
until we have at least one success report on each arch other than x86
- This ebuild should not be committed without prior testing :)
waiting for portage to be fixed, so it doesn't require all the archs' files to
be downloaded into distfiles.
DAnny, ok this is going into portage finally (with a couple of tweaks), but we
need ONE more thing from you :)
The stuff for the alpha CPU, if you could?
Weird error while fetching the file rv9_libc6_i386_cs2.tgz:
I - until now - got 4 different files (aka four different md5sums). I do not have any problems with other files (I correctly got rp8_linux20_libc6_i386_cs2.bin).
Can anyone verify this?
Also you need to remove the ${MY_P} from SRC_URI because else the ebuild fails before getting to pkg_setup where it would display the "fetch-by-hand" message.
Regards,
Tobias
I'm speaking about -r4.
Sorry for the long rows before.. :-/
This ebuild should use something like pkg_nofetch() (?) or src_unpack() (see
ebuild for dev-java/java-sdk-docs which also needs a manual download) instead of
the pkg_setup() it uses now. pkg_setup() is too late in the process, the ebuild
crashes ungracefully long before that.
Created an attachment (id=7134) [details]
realplayer-8-r4.ebuild, fixed prefetch message
This works for me with displaying the prefetch-message.
(Note the changed message)
It does not solve my digest-failure-problem tough.
ok, the ebuild does alpha anyway (thanks again danny), and Tobias's fix is in
cvs.
I'm still having the digest-error, though downloading it directly using the
link in the ebuild solves the problem.
Weird, since I never had errors downloading (using prozilla) until now...
