It was pointed to me by the tuxguitar developer in bug 501048 that if we create the directory /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/audio/ and put a symlink to a soundfont, openjdk's gervill can use a nice soundfont. On the next openjdk update, could you please create this directory and put a symlink inside this directory that points to Fedora's default soundfont which is /usr/share/soundfonts/default.sf2 It is really much better than using what comes with openjdk. Optionally, you can add a "Requires: soundfont2-default" but this may be left out since that is a large package and it is not a very direct dependency. I verified that when the symlink is broken, openjdk falls back to its built-in crappy soundfont (I don't know if it is a regular soundfont). So having a symlink there won't hurt anyone in any case. Thanks!
Do you mind if I commit this simple fix with the symlink? I am not going to make a build, I'll just test and commit so it will be there next time you make a build.
Ping? Any progress? This is just a 2-liner fix.
Hello? This is an extremely simple fix. Why does this take so long? Can I fix it myself on cvs?
Sorry for the lateness. Creating such a link would create a dependency on fluid-soundfont-gm for openjdk which we cannot do, unfortunately. Is there any other workaround?
(In reply to comment #4) > Creating such a link would create a dependency on fluid-soundfont-gm for > openjdk which we cannot do, unfortunately. Is there any other workaround? Would it be possible to java a fluid-soundfont-gm-icedtea subpackage that depends on both soundfont2-default and java-1.6.0-openjdk, which just contains this link?
(In reply to comment #4) > Sorry for the lateness. > > Creating such a link would create a dependency on fluid-soundfont-gm for > openjdk which we cannot do, unfortunately. Is there any other workaround? Well, if the link is broken, openjdk reverts to its own crappy sound generator. Therefore the fluid-soundfont-gm dependency is not needed absolutely. fluid-soundfont-gm soundfont will be used only if it exists. Is the broken link a problem for us?
(In reply to comment #5) > Would it be possible to java a fluid-soundfont-gm-icedtea subpackage that > depends on both soundfont2-default and java-1.6.0-openjdk, which just contains > this link? Yes, that's another option that will make things work. Shall we go that way instead?
(In reply to comment #5) > (In reply to comment #4) > > Creating such a link would create a dependency on fluid-soundfont-gm for > > openjdk which we cannot do, unfortunately. Is there any other workaround? > > Would it be possible to java a fluid-soundfont-gm-icedtea subpackage that > depends on both soundfont2-default and java-1.6.0-openjdk, which just contains > this link? Assuming that a broken link does not break existing functionality, I think this scenario is acceptable. When this sub-package is added in Fedora, can you please add a note to this bug along with some simple steps to test it? We can make the appropriate changes to the OpenJDK rpm then.
Well, if I make a subpackage fluid-soundfont-gm-icedtea and make it depend on soundfont2-default and java-1.6.0-openjdk, then there won't be any broken link in any situation, right? Am I missing something?
I think that if broken link doesn't broke anything else, we can go this way, without adding new package. When a user wants to use soundfont2-default, he will install it and everything works. I can prepare that, and with next release, we can test that.
Possibly. It is arch-specific: http://download.oracle.com/javase/1.5.0/docs/guide/vm/class-data-sharing.html On x86_64, I just get: $ java -Xshare:dump Error occurred during initialization of VM Dumping a shared archive is not supported on the Server JVM.
wrong bug, Andrew?
Yes, sorry; that was for 513605. Has the symlink now been added?
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Sorry I missed your question. Nope, the symlink is still not there even in the rawhide package. Here is a test case where you can listen to the difference in the quality of the sound: 0- Make sure you are using openjdk for java, and you have the packages fluid-soundfont-gm and tuxguitar installed 1- Run tuxguitar 2- Go to Tools->Settings->Sound. Set Midi Port to "Gervill". Hit OK, then hit Yes. 3- Push the play button. Now you are hearing the crappy sound. 4- Exit tuxguitar 5- (for 32 bit, adjust the following lines accordingly) sudo mkdir -p /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/audio/ sudo ln -s /usr/share/soundfonts/default.sf2 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/audio/ 6- Run tuxguitar once more. Push play. Now you are hearing the good sound. Setting Fedora version on the bug to 13. Do you guys mind if I fix this? I can just commit and won't make a build. It will be picked up in your next build.
Can you post patch at first here?
Orcan, yes please post a patch, just to make sure we're all on the same page, and then, once approved, you can commit that to the package. It would need to be fixed in f13, f14 and rawhide.
Created attachment 457839 [details] link to soundfont Sure, attached is the proposed patch to the spec file
Orcan, Should a dependency not also be added so that the soundfont is provided?
Sorry, I thought we discussed this before. A dependency can be added. However fluid-soundfont-gm is fairly large (114 MB). And only those who use midi with java really need it. The thing is, if fluid-soundfont-gm is not installed, the symlink will be broken. However, when the symlink is broken, then java reverts back to the internal (crappy) soundfont. So it makes no harm to have the symlink broken.
Yeah I saw the refusal to add it, but no explanation of why. I'm still not sure "it's big" is really a sufficient excuse either. I'm not convinced having a dangling symlink and part of the JDK broken unless someone knows to download a specific package is really a good solution. Plus it's hypocritical to say we can't support this when we happily depend on NetBeans in order to provide VisualVM which, again, is something not all users want. I'd go back to Mark's suggestion and add a java-1.6.0-openjdk-sound package that brings in this font. We could then have a metapackage that provides the complete JDK. Those who don't want working midi can install one of the packages further down the hierarchy. We need such a metapackage for icedtea-web anyway, and probably for the fonts issue.
Note that no part of JDK will be broken with the dangling symlink. Java will just fall back to its internal soundfont, and nobody will notice it unless they specifically look for it. I am okay with a subpackage+meta package idea. But that's something for you folks to decide.
I'm about to add this simlink to spec. The patch is ok. No dependency will be added (unless some subpackage will be created as mentioned)
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The symlink is still not there. Seems like a good idea to add it.
Is thsi relevant to openjdk7 in same way as it was for 6? (both bonuses and fallback)?
pushed to rawhide - http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/?id=d4e0936acce23c9fc1539800828f165cb741e457
Thanks fr the update. In 7, I am not sure if this works the same way as for 6. We dropped the affected java packages (that I know) a couple Fedora releases ago. I will see if I can find a way to test the soundfont in Java.
I now have broken links pointing to a non-existent /usr/share/soundfonts directory because of this update.
And that is a problem why? Because having been discovered via IA vulnerability scans, I now have to explain them. The fact that these are the only broken symlinks on my system suggests that you opted for a non-standard solution.
The fix with the dangling symlink which becomes undangled when you install fluid-soundfont-gm works perfectly with openjdk7. Please follow the steps from comment #16 to experience the difference in sound quality. (my comment #30 is misleading. We still have tuxguitar in the repo. I don't remember what I was thinking when I wrote that) It took us nearly 3 years to fix this bug, and it is _really_ fixed now. What kind of vulnerability scenario do you have in mind, that yields this fix broken? Sorry, I am not familiar with "IA" vulnerability. Please don't suggest a change unless life-critical. We don't want to go for another 3 years.
Where does one find a RHEL6 package with fluid-soundfont-gm?
(In reply to R. Letsinger from comment #34) > Where does one find a RHEL6 package with fluid-soundfont-gm? Easiest would be to target fluid-soundfont for EPEL. https://apps.fedoraproject.org/packages/fluid-soundfont But that is offtopic for this bug report. Please contact the maintainer if you want that.
This is causing bugs in some applications on RHEL. See bug 1264099.
I don't maintain the soundfont package anymore. You probably need to let the RHEL maintainer of java package know, so he makes the symlink Fedora only.
(In reply to Orcan Ogetbil from comment #37) > You probably need to let the > RHEL maintainer of java package know, so he makes the symlink Fedora only. Actually, the RHEL maintainer of the java package brought it up to me :) > I don't maintain the soundfont package anymore. If you have a few minutes, I would appreciate your input, though. I am actually thinking of removing the symlink, and modifying the code to look for the sf2 files directly. This would allow the same piece of code to work on both Fedora and RHEL and minimize differences between the packages. One option is to patch the java package to look for /usr/share/soundfonts/default.sf2 only. The other option is to look for some /usr/share/soundfonts/*.sf2 file and select one arbitrarily. Do you have a preference on which approach would work better? (And why?)
Sure, this is my opinion as the previous maintainer: I don't mind changing the current solution in favor of another solution as long as it works. Currently, the default Fedora soundfont is /usr/share/soundfonts/FluidR3_GM.sf2 but this doesn't mean that it will be this file forever. So, hardcoding this soundfont file name in the Java code needs mutual maintenance, which I find difficult. There are other soundfont files that get installed in this directory, e.g. from PersonalCopy-Lite package, so random selection is not desirable either. This is why we prefered the symlink solution some 4-5 years ago. If you can come up with a better solution, by all means, go for it.