I have just ssen that opendx-sample has been keyed stable on amd64 following bug report #118683 I have been using this package for far longer on both x86 and ppc (#54047 and #101951 for example)and I think it's time that they are marked stable. Especially considering that I will ask for a version bump to the new version 4.4.0 of opendx.
From the ppc side: Picking random examples from the package it's just fine (*no* way i'm going through all of them :P) Considering it's just merely data: please mark that stable.
I have been through quite a lot myself when I learned how to use opendx. But yes it's just data-tutorials in fact. Initially the plan was to include them with opendx using the "doc" use flags and then it didn't happen that way.
How did you guys get opendx to emerge on ppc, so that you could test the samples? It bails out for me due to not having the extra jar files shown in the ebuild comment: #SRC_URI="${SRC_URI} # http://opendx.npaci.edu/libs/netscape-java40.tar.gz # http://opendx.npaci.edu/libs/cosmoplayer-jar.tar.gz I manually tweaked the configure to turn off the feature that used those jars, but that's not something I expect to have to do for a stable ebuild... Am I missing something here? Or should I file a bug against opendx?
(In reply to comment #3) > How did you guys get opendx to emerge on ppc, so that you could test the > samples? It bails out for me due to not having the extra jar files shown in the > ebuild comment: > > #SRC_URI="${SRC_URI} > # http://opendx.npaci.edu/libs/netscape-java40.tar.gz > # http://opendx.npaci.edu/libs/cosmoplayer-jar.tar.gz > > I manually tweaked the configure to turn off the feature that used those jars, > but that's not something I expect to have to do for a stable ebuild... > > Am I missing something here? Or should I file a bug against opendx? > If you look at the opendx build there is the following comment: # java support gives some trouble - deprecated api and other unresolved symbols # java? ( virtual/jdk # dev-java/java-config )" java is in fact disabled on all ebuilds of opendx on any platform at the moment: IUSE="hdf cdf netcdf tiff imagemagick szip" # java doc" and # `use_with java javadx` # This is broken So I really don't know how you managed to run into those troubles. I have emerged opendx on ppc several time and I never ran into this problem. Now of course you cannot test the samples that depends on java but all the other I tried were OK. For info the last time I emerged opendx on ppc was last evening with gcc4.1.0 and it went flawlessly: [ebuild R ] sci-visualization/opendx-4.4.0 +cdf (-hdf) +imagemagick +netcdf +szip +tiff 0 kB [1] Sure this is the latest version but I emerged 4.3.2-r1 less than one month ago and the ebuild I made for 4.4.0 is just a clone of 4.3.2-r1. You are not trying to emerge opendx-4.3.2 instead of 4.3.2-r1 by any chance?
Yes, I am using -r1 and I do see those comments. For me they were not enough; I needed to add --without-javadx since the default seems to be to trying to compile the java stuff. Possibly upstream did change the default behavior in 4.4.0 so that java is off by default. Meanwhile... opendx-sample is stable on ppc, and thanks for the report Francois
(In reply to comment #5) > Yes, I am using -r1 and I do see those comments. For me they were not enough; I > needed to add --without-javadx since the default seems to be to trying to > compile the java stuff. Possibly upstream did change the default behavior in > 4.4.0 so that java is off by default. > > Meanwhile... opendx-sample is stable on ppc, and thanks for the report Francois > Just to try to elucidate that problem when I do emerge -v =sci-visualization/opendx-4.3.2-r1 During the configuration phase I have the following: configure: checking for java compiler... configure: WARNING: JAVAC was preset checking for /opt/ibm-jdk-bin-1.4.2.03/bin/javac... /opt/ibm-jdk-bin-1.4.2.03/bin/javac checking if /opt/ibm-jdk-bin-1.4.2.03/bin/javac works...... yes configure: checking for jar... checking for jar... jar configure: checking for javah... checking for javah... javah checking for java... /opt/ibm-jdk-bin-1.4.2.03/bin/java checking java architecture type... genunix checking for jdk classes... none trying default path checking for jni headers path... /usr/include:/usr/include/genunix checking for valid jni headers path... no configure: WARNING: JavaDX will be skipped during compilation due to limitations. =============== So do you have something that looks like jni headers on your system? In that case javadx could be enabled with unknown results as far as I am concerned.
x86 done
