112207 2005-11-11 11:20 0000 Test request for media-libs/dssi and dev-java/gnu-classpath-0.19 2006-05-01 06:51:26 0000 1 1 1 Unclassified Gentoo Linux Unspecified unspecified All Linux RESOLVED FIXED P2 enhancement --- 116297 1 betelgeuse@gentoo.org java@gentoo.org ppc64@gentoo.org betelgeuse@gentoo.org 2005-11-11 11:20:55 0000 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. betelgeuse@gentoo.org 2005-11-11 11:22:43 0000 Note to sparc: gnu-classpath is the java class library and such does not need a vm so you can test this. weeve@gentoo.org 2005-11-11 17:25:35 0000 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. betelgeuse@gentoo.org 2005-11-12 03:00:59 0000 (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. weeve@gentoo.org 2005-11-12 15:44:38 0000 We are unable to test this at this time as dssi has a dependency on alsa-lib SPARC cannot meet in its default profile betelgeuse@gentoo.org 2005-11-12 16:16:57 0000 (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? weeve@gentoo.org 2005-11-12 16:44:04 0000 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. wormo@gentoo.org 2006-01-05 12:36:29 0000 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? wormo@gentoo.org 2006-02-04 10:16:03 0000 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 corsair@gentoo.org 2006-05-01 05:15:46 0000 added ~ppc64 betelgeuse@gentoo.org 2006-05-01 06:51:26 0000 (In reply to comment #9) > added ~ppc64 > Last arch so this is now fixed.