Ebuild for Opera6.1 final with shared QT3. Changed to use wrapper-script. This avoids opera's error messages about missing files. This seems also to fix also Bug 9871.
Created attachment 5234 [details] Ebuild for 6.1final
small update: openmotif is a dependency -> url is the same
Created attachment 5238 [details] Ebuild for 6.1final - fix #1 added openmotif as dependency
And again me (sorry :) - fixed: not openmotif dependency, instead lesstif of course !! - change opera's policy-file and opera's wrapper file to work with java
Created attachment 5251 [details] Ebuild for 6.1final - fix #2 (forget previous) - add lesstf depend instead of openmotif - changed wrapper + policy to get java work
Carsten: Thanks for your work. I have actually had plans on unifying the opera ebuilds (I mean opera-static and opera) into one. I am not sure how exactly I'm going to do that, but I just took a shot in the ebuild that was committed to the CVS just a minute ago. Here are the issues: there are now four versions of opera available for download: static, shared+gcc-2.95, shared+gcc-2.96, shared+gcc-3.2. The problem is that, for instance, shared+gcc-3.2 build does not work for people with gcc 2.95. THere have also been problems with shared libraries of the dynamically linked package when we upgraded libpng to 1.2. That's why I think that the static version should be the default. The nice thing is that the installation procedure is identical for all the versions, and that's why I wanted to unify the ebuilds in one. Please have a look at the new ebuild and tell me what you think.
Hi, Idea: is there away to check something like: "gcc -dumpversion" and integrate it as path ? Or might be easier to check the /etc/make.profile or /etc/gentoo-release file. So autodetection of the system compiler can be done. One thing to hide for the user. If I have had a look at opera-shared I would never change back to static. So I think the shared should be default. Overiding the "autodection" and "default" can be done with your environment-variable. I had also no problems with libpng-1.2.5,so I would prefer shared. I also see a few (may-be-)problems: Java isn't enabled: every time a user restarts opera, java is turned off. Look at my ebuild, there you see the changes. Means for user: first start java disabled. Turns it on (if he want) - stays on. So in my opinion there's no security lack because the user has it to turn on manually. Also it would be necassary to use the wrapper /opt/opera/share/bin/opera instead of linking the binary. So I recommend to link this. (For me it ssems to solve java-probs and netscape plugins like flash work) And why you say yes for install_config=yes? (In my ebuilds it doesn't work, if in yours it's ok)
Also have a look at http://forums.gentoo.org/viewtopic.php?t=20574. Currently it seems to work for all with java+flash and shared. But might be better to look there in a few hours again.
The digest in the portage tree is not correct. If I get the file (from 3 different mirrors), I have: 58816c45b055d40191e4d77ead36ed46 opera-6.10-20021029.1-static-qt.i386.tar.bz2 you are expecting: 0bbf000275745f51ece957c190e2bca0 What's the source of this? Regards, Tobias
Java is not working. You have to edit the /opt/opera/share/opera/java/opera.policy file to have the path inside pointing to opera.jar: --- opera.policy.org 2002-11-04 13:45:21.000000000 +0100 +++ opera.policy 2002-11-04 13:46:16.000000000 +0100 @@ -6,7 +6,7 @@ }; // Opera package classes get all permissions -grant codebase "file:///var/tmp/portage/opera-static-6.1/image//opt/opera/share/opera/java//opera.jar" { +grant codebase "file:///opt/opera/share/opera/java//opera.jar" { permission java.security.AllPermission; }; Somehow it is pointing into ${D} of portage...
Which ebuild you've tested ? The one from gentoo's portage tree or the above (attachments)? In the above it should be fixed. But it's not in portage.
Oops, sorry, thought they're all the same. I tested the portage-ebuild.
No they are different. The attachment were submitted before the other's were in portage. But the commited changes (java, wrapper etc.) weren't (yet ?) included in portage's.
For the digest corruption, please see bug 10132. (Bottom line: it should have been fixed now). What do you mean the wrapper is not being used? /usr/bin/opera points to /opt/opera/bin/opera, which is the original wrapper that came with the tarball. I'll get to the java stuff very soon now (busy with my own stuff right now).
With wrapper I meant /opt/opera/share/bin/opera. This enables (with the modifications from my ebuild): - preload libawt.so (without at least for me java dosen't work) - enables OPERA_FORCE_JAVA_ENABLED=1, so java isn't turned of on every opera start Also it's usefull for plugin-dirs, opera-dir (for the "there's no /usr/share/opera/chartables.bin"-warning) and (if you want) it autmagically searches for java (not in my ebuild, you'll have to change the search-path's).
Hi, Carsten: I have just committed opera-6.1-r1. As far as I know, it incorporates all of the stuff that you have suggested here. 1. /opt/opera/bin/opera is the same wrapper script as /opt/opera/share/bin/opera in your ebuild; it's simply installed in the different location. 2. The script has the three lines, pertaining to the Java plugin and libawt.so uncommented, as you are suggesting. Could you please test and see whether I missed something? If I did, please send in a diff against the ebuild in the portage tree. Many thanks!
Good job ! For me it works without any problems except one: for qt-3-shared with gcc3.2 the digest file is wrong. Just add this line to the digest-file: MD5 3b1186c859f176b161cad71a2c6a73a5 opera-6.10-20021029.4-shared-qt.i386.tar.gz 3565479 Maybe it will be better to show some info about QT_VARIANT flag. But only maybe :)
Okay, thanks for testing! I fixed the digest file. Not sure what to do with the environment variable; maybe I'll throw it out for a discussion. Closing this bug now.
