gzipping man page: idlj.1 QA Notice: the following files contain runtime text relocations Text relocations force the dynamic linker to perform extra work at startup, waste system resources, and may pose a security risk. On some architectures, the code may not even function properly, if at all. For more information, see http://hardened.gentoo.org/pic-fix-guide.xml Please include this file in your report: /var/tmp/portage/sun-jdk-1.5.0.07/temp/scanelf-textrel.log "TEXTREL opt/sun-jdk-1.5.0.07/jre/lib/i386/motif21/libmawt.so" "TEXTREL opt/sun-jdk-1.5.0.07/jre/lib/i386/libdeploy.so" * checking 2297 files for package collisions existing file /usr/share/applications/sun_java.desktop is not owned by this package 1000 files checked ... 2000 files checked ... existing file /usr/lib/nsbrowser/plugins/javaplugin.so is not owned by this package * spent 0.109940052032 seconds checking for file collisions * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package dev-java/sun-jdk-1.5.0.07 NOT merged
This is going to be a tricky one to fix... It brings to light something that has been lacking for some time: choosing which java nsplugin to use. Bacally, I think we'll need an eselect module for placing a symlink at /usr/lib/nsbrowser/plugins/javaplugin.so pointing to one of the JRE/JDK's plugin.
I have a preliminary java-nsplugin eselect module working. JRE and JDKs will now install a symlink to their nsplugin under /usr/share/java-config-2/nsplugin. The module uses this to see what is available, and will symlink from the chosen plugin in that directory to /usr/lib/nsbrowser/plugins/javaplugin.so. I also updated the java-vm-2 eclass for pkg_postinst, so that it will check if the javaplugin.so is in place, and if it isn't, it will try to set it to the now being installed plugin. This will help future installs... but what about old installs where all the USE=nsplugin VMs own /usr/lib/nsbrowser/plugins/javaplugin.so ?
(In reply to comment #2) > This will help future installs... but what about old installs where all the > USE=nsplugin VMs own /usr/lib/nsbrowser/plugins/javaplugin.so ? What's the problem? Users have to update to the currently masked ebuilds anyways. And those who use these ebuilds should know what it means to use package.masked stuff. Last not least it's just a symlink. ;)
Good point. I committed changes to java-vm-2.eclass and java-config-2.0.26 this morning. Could you please remerge your VMs, and see if they still have collisions? Assuming that works, I'll do revbumps to make sure people get the affected changes to the VM.
Works fine. An einfo line how to set the plugin symlink would probably nice, though.
I am running Sun Java instead of Blackdown and using ~x86 to get ver1.5. I --sync'd this morning, updated to 1.5.07 and my java plugin disappeared. I found this bug report so tried remerging sun-jre-bin (comment#4). The plugin still failed to symlink from the emerge. I know I could have just created the symlink myself, however, I wanted to ensure it works properly before I tell friends to update machines as they get lost doing this stuff :-) I ran "emerge -C sun-jre-bin" and emerged sun-jdk after which the plugin reappeared properly. Just to be sure I unmerged sun-jdk, env-updated, rebooted the system then did it all again. The sun-jre-bin still didn't install the plugin and sun-jdk did. Both worked fine for VM.
This is my experience. - run equery belongs /usr/lib/nsbrowser/plugins/javaplugin.so Got list of vm's "owning" the file and reemerged them: # emerge -1 =blackdown-jre-1.4.2.03-r11 =dev-java/sun-jdk-1.4.2.12 =dev-java/sun-jdk-1.5.0.07 =dev-java/blackdown-jdk-1.3.1-r23 =dev-java/blackdown-jdk-1.4.2.03-r12 =dev-java/sun-jre-bin-1.4.2.12 =dev-java/sun-jre-bin-1.5.0.07 # ls -la /usr/lib/nsbrowser/plugins/javaplugin.so lrwxrwxrwx 1 root root 59 2006-07-03 16:56 /usr/lib/nsbrowser/plugins/javaplugin.so -> /usr/share/java-config-2/nsplugin/sun-jdk-1.5-javaplugin.so - looks like it got set to the system vm when it was emerged, and the other vm's didn't overwrite it, nice :) - however, a glitch in eselect list: # eselect java-nsplugin list Available Java browser plugins [1] blackdown-jdk-1.3 [2] blackdown-jdk-1.4.2 [3] blackdown-jre-1.4.2 [4] sun-jdk-1.4 [5] sun-jdk-1.5 current [6] sun-jre-bin-1.4 current [7] sun-jre-bin-1.5 current - seems some variable is assigned "current" when it approaches the vm which has nsplugin set, and isn't reinitialized to null string in next loop so all vm's after the real current are "current" too - it should also support "eselect java-nsplugin <number>" as other eselect modules do, but... # eselect java-nsplugin set 1 !!! Error: Expected to /usr/share/java-config-2/nsplugin/1-javaplugin.so to exist, but it doesn't. !!! Error: Perhaps 1 isn't a valid plugin name? - fine otherwise, now is it possible to make it per-user setting too? tricky :)
Caster, Fixed those two bugs you pointed out. If someone wanted to add support for per-user settings... by all means go for it. So, I think this particular issue is pretty much cleared up. The only things left to do are to document it in the user guide, and to add a little more information during postinst of jdks/jres which install a plugin.
Created attachment 90801 [details, diff] add actions to set <number>, show, better error messages (In reply to comment #8) > Fixed those two bugs you pointed out. If someone wanted to add support for > per-user settings... by all means go for it. Yeah the "current" in eselect java-nsplugin list is shown correctly. But still can't be set with number. Anyway, found some more cosmetic glitches and tried to patch them, here goes... So this patch adds ability to eselect set <number>. Also adds "eselect java-nsplugin show" action and better error messages when bad number of arguments given to set action or when non-root tries to set nsplugin.
Created attachment 90835 [details, diff] patch against 2.0.26-r2, adds show action, better error messages + input checking updated patch as 2.0.26-r2 contains set <number>
Caster, Are you positive setting by number didn't work? I was working well enough when I was adding it :) Aside from that, I've applied the patch for 2.0.27, which will go into the tree as soon as the distfile propogates to the mirrors. As far as when to resolve this bug, I think we're pretty set now.
(In reply to comment #11) > Caster, > > Are you positive setting by number didn't work? I was working well enough when > I was adding it :) Well when you wrote comment #8, I saw only 2.0.26-r1 in portage which fixed the current in list. Set by number appeared later with 2.0.26-r2 so I thought it weren't fixed yet :) > Aside from that, I've applied the patch for 2.0.27, which will go into the tree > as soon as the distfile propogates to the mirrors. > > As far as when to resolve this bug, I think we're pretty set now. > Cool.
*** Bug 144952 has been marked as a duplicate of this bug. ***
