on 3.18.11-gentoo #1 SMP Sun Apr 26 16:25:35 PDT 2015 x86_64 I installed dev-util/netbeans 8.0.2 and it 90+ dependencies. All was working fine, I had run several sessions of it. There was a warning dialog every time I started saying that one component, Jinit (I think), was missing or could not be found and did I want to install it. I finally clicked yes and the installation proceeded as evidenced by another dialog. The 100% mark appeared, but the window hung for several minutes. I finally killed the application. Thereafter is when my problems began. I could not get netbeans to start. I posted a topic on the portage forum, https://forums.gentoo.org/viewtopic-t-1018356-highlight-netbeans.html, outlining my attempts to emerge and emeger -C. Now, when I emerge dev-util/netbeans the emerge appears successful, there are no error messages. However, there is no /usr/bin/netbeans... file. What do I need to provide you to help troubleshoot this silent failure to install?
themis netbeans # FEATURES="keepwork" emerge dev-util/netbeans * WARNING: The FEATURES variable contains one or more values that * should be disabled under normal circumstances: keepwork Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-util/netbeans-8.0.2::gentoo * Using: oracle-jdk-bin-1.7 >>> Unpacking source... >>> Source unpacked in /var/tmp/portage/dev-util/netbeans-8.0.2/work >>> Preparing source in /var/tmp/portage/dev-util/netbeans-8.0.2/work ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-util/netbeans-8.0.2/work ... >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-util/netbeans-8.0.2/work ... >>> Source compiled. >>> Test phase [not enabled]: dev-util/netbeans-8.0.2 >>> Install netbeans-8.0.2 into /var/tmp/portage/dev-util/netbeans-8.0.2/image/ category dev-util >>> Completed installing netbeans-8.0.2 into /var/tmp/portage/dev-util/netbeans-8.0.2/image/ >>> Installing (1 of 1) dev-util/netbeans-8.0.2::gentoo >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. themis netbeans # ls /usr/bin/netb* ls: cannot access /usr/bin/netb*: No such file or directory themis netbeans #
Created attachment 404692 [details] enviornmnet
Created attachment 404694 [details] eclass-debug
I performed: emerge dev-java/netbeans-nb and /usr/bin/netbeans-8.0.2 was restored. However, when I try to launch it, it fails: jlpoole@themis /usr/local/src/libreveris/trunk $ netbeans-8.0 /bin/bash: : No such file or directory jlpoole@themis /usr/local/src/libreveris/trunk $ eselect java-vm list Available Java Virtual Machines: [1] icedtea-bin-7 [2] oracle-jdk-bin-1.7 system-vm user-vm [3] oracle-jdk-bin-1.8 jlpoole@themis /usr/local/src/libreveris/trunk $ The file /usr/share/netbeans-nb-8.0/bin/netbeans is present and populated. So I'm guessing something in my configuration has been thrown out of whack.
I created a netbeans_test which is a copy of netbeans and determined that around linke 206: launchNbexec() { nbexec=`grep -v "^#" "$basedir"/etc/netbeans.clusters | grep -v "^$" | grep platform | while read X; do if expr "$X" : "/.*" >/dev/null; then echo $X/lib/nbexec elif [ -f "$basedir"/$X/lib/nbexec ]; then echo "$basedir"/$X/lib/nbexec fi done | head -n 1` the variables "nbexec" is not getting defined. Hence further down when a launch of it is attempted, the error message "No such file..." comes back.
themis bin # ls -la /etc/netbeans-8.0/ total 24 drwxr-xr-x 2 root root 4096 Jun 6 08:47 . drwxr-xr-x 72 root root 4096 Jun 6 09:04 .. -rw-r--r-- 1 root root 275 Jun 6 08:47 netbeans.clusters -rw-r--r-- 1 root root 2950 Jun 6 08:47 netbeans.conf -rw-r--r-- 1 root root 4573 Jun 6 08:47 netbeans.import themis bin # cat /etc/netbeans-8.0/netbeans.clusters # platform cluster first platform # application cluster second nb # ergonomics cluster if present ergonomics # and now the rest ide extide java apisupport webcommon websvccommon enterprise mobility profiler python php identity harness cnd dlight groovy extra javacard javafx themis bin #
I was able to get a GUI, albeit a GUI that did not seem to offer any functionality. No doubt there are other environmental values that have not been set given my attempt to short-cut the initialization script. But here is what got me there and may prove helpful: themis bin # locate nbexec /opt/oracle-jdk-bin-1.7.0.80/lib/visualvm/platform/lib/nbexec /opt/oracle-jdk-bin-1.8.0.45/lib/visualvm/platform/lib/nbexec /usr/bin/nbexec-8.0 /usr/share/netbeans-platform-8.0/lib/nbexec themis bin # ls -la /usr/bin/nbexe* lrwxrwxrwx 1 root root 43 Jun 3 07:33 /usr/bin/nbexec-8.0 -> /usr/share/netbeans-platform-8.0/lib/nbexec themis bin # export JAVA_HOME=/opt/oracle-jdk-bin-1.7.0.80 themis bin # nbexec-8.0 Cannot find java. Please use the --jdkhome switch. themis bin # nbexec-8.0 --jdkhome /opt/oracle-jdk-bin-1.7.0.80
The hack below worked for me; netbeans IDE started up again. I created a working copy of the launch script, "netbeans", and then used a soft link to switch between my hacked version "_test" and the original. Here's my directory as follows: themis bin # pwd /usr/share/netbeans-nb-8.0/bin themis bin # ls -la total 24 drwxr-xr-x 2 root root 4096 Jun 6 09:39 . drwxr-xr-x 4 root root 4096 Jun 6 08:47 .. lrwxrwxrwx 1 root root 13 Jun 6 09:39 netbeans -> netbeans_test -rwxr-xr-x 1 root root 7808 Jun 6 08:47 netbeans_ORIGINAL -rwxrwxrwx 1 root root 8164 Jun 6 10:07 netbeans_test themis bin # Then, with the link pointing to my hacked version, I modified netbeans_test as follows ( lines having "jlpoole" are the modifications): launchNbexec() { nbexec=`grep -v "^#" "$basedir"/etc/netbeans.clusters | grep -v "^$" | grep platform | while read X; do if expr "$X" : "/.*" >/dev/null; then echo $X/lib/nbexec elif [ -f "$basedir"/$X/lib/nbexec ]; then echo "$basedir"/$X/lib/nbexec fi done | head -n 1` echo jlpoole hard-wiring nbexec nbexec=/usr/share/netbeans-platform-8.0/lib/nbexec echo jlpoole nbexec = $nbexec The failure point is in the wizardry of the commands creating the value for nbexec which fails, they result is an empty string. The big question is: something I downloaded from within NetBeans, e.g. the junit (not jinit as I mistakenly recalled earlier) update, altered something breaking the above command sequence. At least I'm back up and running while the ebuild maintainer sorts this out. I'll leave my system as is so if there is anything I can do to assist ferreting out what happened, I'll have a setup ready to reference.
Created attachment 404700 [details] screen shot of NetBeans start up with "Update" dialog warning Also, as I run my Netbeans IDE, at startup there is a temporary dialog saying that there are 16 updates for my environment. Here's the dialog that flashes by and disappears after several seconds. I'm NOT updating via that method unless asked to by whoever is handling this bug. A policy of whether people using NetBeans biult via Gentoo's ebuild should use the automatic update features from within NetBeans should be articulated and promulgated.
with regard to your issue, i have no idea what is going wrong. my netbeans runs fine without any issue. what you might try is to delete or rename ~/.netbeans/8.0.2/ directory. it contains the local configuration and other stuff of your netbeans that is user specific. you can also use command line switch for the netbeans-8.0 script to use different user dir. with regard to the updates of netbeans, i bump only those versions that are officially available at netbeans.org. at this time the latest stable available version is 8.0.2. feel free to update any modules. it should cause no harm. up to that, these updates are again stored in user dir (default is ~/.netbeans/8.0.2/) so you can later switch to different user dir or delete the original one to start fresh.
John are you still experiencing this issue? Thanks in advance for letting us know.
Reopen if that's still an issue.
I ended up re-installing and then never using their automatic updates. It's been months since I was in the space, I finally got it to work and just moved forward accomplishing what I needed. I'll probably be back there and will try to remember this bug and update with any further findings.
