Bugzilla Bug 112207

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.