The new release of gnu-classpath has a new dependency on media-libs/dssi which is not yet keyworded for your arches. Please test dssi and after that gnu-classpath-0.19.
Note to sparc: gnu-classpath is the java class library and such does not need a vm so you can test this.
So if we don't have a working VM, how do we test class libraries? we might be able to build them without a working JVM and/or javac, but verification that they work seems like it wouldn't be possible. Granted I'm not overly fluent in the wide world of java, so if there is a way to actually test this that doesn't require, say a working blackdown installation, let us know.
(In reply to comment #2) > So if we don't have a working VM, how do we test class libraries? we might be > able to build them without a working JVM and/or javac, but verification that > they work seems like it wouldn't be possible. Granted I'm not overly fluent in > the wide world of java, so if there is a way to actually test this that doesn't > require, say a working blackdown installation, let us know. Use for example kaffe. It seems to be keyworded for your arch. There are plenty of vms in the tree besides blackdown to choose from. Because there are no >=virtual/jre-1.4 deps here you can use any of the not traditionally versioned vms.
We are unable to test this at this time as dssi has a dependency on alsa-lib SPARC cannot meet in its default profile
(In reply to comment #4) > We are unable to test this at this time as dssi has a dependency on alsa-lib > SPARC cannot meet in its default profile Can't you just disable the local dssi use flag in your profiles then?
Yes we could, however unless blackdown comes out with a new JRE/JDK by the time 2006.0 roles around, we will be having to ditch java as blackdown has been holding our toolchain back for some time now. As given their previous history, this seems unlikely, we're holding off on most java keywording requests at the moment.
I keyworded dssi. Most of the gnu-classpath demos work ok, with the exception of the midi demo. I get two empty selection boxes labeled "MIDI IN" and "MIDI OUT", even though I'm running a dssi client: # aconnect -lo client 62: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 128: 'Less Trivial synth' [type=user] 0 'Less Trivial synth' I have no hardware midi, but aplaymidi is able to use the dssi sw synth (Less Trivial synth) as an output port. Any suggestions on how to get the midi demo working? Or should I file a bug against classpath?
I finally realized that javax.sound.midi.MidiSystem.getMidiDeviceInfo was coming from my IBM jdk bootclasspath, not from gnu-classpath. Now I tested gnu-classpath with jamvm (Bug #116297) and it looks ok, so classpath is now keyworded ~ppc
added ~ppc64
(In reply to comment #9) > added ~ppc64 > Last arch so this is now fixed.
