I realize that the java startup script for gatk does not seem to do anything. $ equery belongs /usr/bin/GenomeAnalysisTK * Searching for /usr/bin/GenomeAnalysisTK ... sci-biology/gatk-2.4 (/usr/bin/GenomeAnalysisTK) $ equery belongs /usr/share/java-config-2/launcher/launcher.bash dev-java/java-config-2.2.0 (/usr/share/java-config-2/launcher/launcher.bash) $ $ head /usr/share/java-config-2/launcher/launcher.bash #!/@GENTOO_PORTAGE_EPREFIX@bin/bash # Not-so-elegant? patches more then welcome abort() { echo ${@} >&2 exit 1 } # Save Python-specific variables for support for Jython # --------------------- $ Seems the variable was not expanded before installation. Shouldn't this be caught also by some QA checks?
Please post your emerge --info.
Judging by the ChangeLog, I suspect this has been like this for 2 years already but it doesn't actually break anything because launcher.bash isn't executed directly, it's sourced by scripts like /usr/bin/GenomeAnalysisTK. While I agree that the shebang should be fixed, the problem with gatk not starting must be something else. I don't have time to look into it immediately.
While the lack of expansion in the shebang is probably unproblematic, there are more cases of unexpanded @GENTOO_PORTAGE_EPREFIX@ in the script: gjl_user_env="${HOME}/.gentoo@GENTOO_PORTAGE_EPREFIX@/java-config-2/launcher.d/$ {gjl_package}" gjl_system_env="@GENTOO_PORTAGE_EPREFIX@/etc/java-config-2/launcher.d/${gjl_package}" This makes the global launcher.d settings not work at all, and require a rather peculiar directory to be created for user launcher.d settings to work...
Good point, though even as Java lead, I must admit that I was unaware of that feature! In the very few cases where I needed to do that, I used the -pre option of java-pkg_dolauncher instead.
Created attachment 433640 [details, diff] Patch fixing the @GENTOO_PORTAGE_EPREFIX@ issue Interresting. How would I use that option to make arduino always launch with icedtea-8 (which has AWT) rather than the default JVM (oracle, which does not have AWT)? With launcher.d, I can just put "export GENTOO_VM=icedtea-8" into /etc/java-config-2/launcher.d/arduino. Provided it works, of course. :-) I created a small patch that fixes the issue, adding it as an attachment.
(In reply to Marcus Comstedt from comment #5) > Created attachment 433640 [details, diff] [details, diff] > Patch fixing the @GENTOO_PORTAGE_EPREFIX@ issue > > Interresting. How would I use that option to make arduino always launch > with icedtea-8 (which has AWT) rather than the default JVM (oracle, which > does not have AWT)? It is not possible to install these without AWT. Do you mean you used the headless-awt flag? If you're referring to the -pre option, that applies to the ebuild, it's not an end user thing. > With launcher.d, I can just put "export GENTOO_VM=icedtea-8" into > /etc/java-config-2/launcher.d/arduino. Provided it works, of course. :-) I believe that should work, yes. I'd like to make this workaround unnecessary though. If a particular package requires the full AWT for its GUI then we could put RDEPEND="virtual/jre[-headless-awt]" and java-config would use this information to ensure that a JVM with full AWT support is selected.
(In reply to James Le Cuirot from comment #6) > It is not possible to install these without AWT. Do you mean you used the > headless-awt flag? For arm64 the current upstreams package of oracle-jdk-bin is headless. But the effect is the same as if I had installed it with headless-awt, I assume. If I try to run a program using AWT I get a java.awt.HeadlessException. > If you're referring to the -pre option, that applies to > the ebuild, it's not an end user thing. Ok. Modifying ebuilds is usally a bad idea, yes. > I believe that should work, yes. I'd like to make this workaround > unnecessary though. If a particular package requires the full AWT for its > GUI then we could put RDEPEND="virtual/jre[-headless-awt]" and java-config > would use this information to ensure that a JVM with full AWT support is > selected. For this to work, the ebuild for oracle-jdk-bin would also need to make headless-awt a REQUIRED_USE for cases where the upstreams package is headless. Should be possible to do I guess.
(In reply to Marcus Comstedt from comment #7) > > For arm64 the current upstreams package of oracle-jdk-bin is headless. But > the effect is the same as if I had installed it with headless-awt, I assume. > If I try to run a program using AWT I get a java.awt.HeadlessException. I was going to say "Are you sure about that?" but I thought I better check for myself. Indeed you are right! I knew that neither includes javafx but I thought they at least included X11-based AWT. Turns out only arm32 does! The key file here is libawt_xawt.so. # tar ztf jdk-8u91-linux-arm32-vfp-hflt.tar.gz| fgrep awt jdk1.8.0_91/include/linux/jawt_md.h jdk1.8.0_91/include/jawt.h jdk1.8.0_91/jre/lib/arm/libawt_headless.so jdk1.8.0_91/jre/lib/arm/libawt.so jdk1.8.0_91/jre/lib/arm/libjawt.so jdk1.8.0_91/jre/lib/arm/libawt_xawt.so jdk1.8.0_91/lib/arm/libjawt.so # tar ztf jdk-8u91-linux-arm64-vfp-hflt.tar.gz| fgrep awt jdk1.8.0_91/include/linux/jawt_md.h jdk1.8.0_91/include/jawt.h jdk1.8.0_91/jre/lib/aarch64/libawt_headless.so jdk1.8.0_91/jre/lib/aarch64/libjawt.so jdk1.8.0_91/jre/lib/aarch64/libawt.so jdk1.8.0_91/lib/aarch64/libjawt.so > For this to work, the ebuild for oracle-jdk-bin would also need to make > headless-awt a REQUIRED_USE for cases where the upstreams package is > headless. Should be possible to do I guess. package.use.force is the thing to use. Given the above, I will make that change shortly.
(In reply to James Le Cuirot from comment #8) > > I was going to say "Are you sure about that?" but I thought I better check > for myself. Indeed you are right! I knew that neither includes javafx but I > thought they at least included X11-based AWT. Turns out only arm32 does! The > key file here is libawt_xawt.so. You know what's really strange? arm64's libjawt.so still links to libawt_xawt.so. So Oracle have shipped it with a dangling link. Way to go. I wonder if this was a mistake?
(In reply to James Le Cuirot from comment #8) > package.use.force is the thing to use. Ah, yes. That would do the trick. (In reply to James Le Cuirot from comment #9) > You know what's really strange? arm64's libjawt.so still links to > libawt_xawt.so. So Oracle have shipped it with a dangling link. Way to go. > I wonder if this was a mistake? Who knows what Oracle is thinking. I just take comfort in the fact that Gentoo is flexible enough to handle this kind of crap. :-)
Hi. Sorry for piggy-backing some more on this issue. I just noticed that virtual/jdk and virtual/jre are missing headless-awt in their IUSE. Surely this would need to be fixed before 'RDEPEND="virtual/jre[-headless-awt]"' can work?
(In reply to Marcus Comstedt from comment #11) > I just noticed that virtual/jdk and virtual/jre are missing > headless-awt in their IUSE. Surely this would need to be fixed before > 'RDEPEND="virtual/jre[-headless-awt]"' can work? Yes but I'd like to do the necessary work to java-config before adding that. On the other hand, I suppose it is an easy win that would get us half way there. I'll think about it.
What is the status of this bug?
I've got to look into it.
(In reply to Benda Xu from comment #13) > What is the status of this bug? What aspect of it is bothering you? The prefix issue mentioned in the subject doesn't actually break anything at all.
I have problems with this, too. I was looking into setting user-level system properties for various packages which use java-config-2, and from what I saw I guessed that I could put a file in ~/.gentoo/java-config-2/launcher.d with the filename being the package name provided by the launcher script and a line like this in it: > export JAVA_TOOL_OPTIONS="-Dsun.java2d.uiScale=2.0 -Dawt.useSystemAAFontSettings=on" However, because of this bug it doesn't appear to work - the $gjl_user_env variable has the unexpanded @GENTOO_PORTAGE_EPREFIX@ in it. I don't know of another method to do this; is there another method I should be using?
(In reply to Sophie Hamilton from comment #16) > However, because of this bug it doesn't appear to work - the $gjl_user_env > variable has the unexpanded @GENTOO_PORTAGE_EPREFIX@ in it. I don't know of > another method to do this; is there another method I should be using? Agreed, this aspect of it is still broken. I was reviewing the unreleased java-config code the other week because I thought I might need to push out a new release to deal with recent profile changes. That wasn't necessary in the end but I did notice some other problems and potential problems that need addressing. I'll bump this up the priority list.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b106da22dbce2245ff14d4a6f72ab762afea55a commit 2b106da22dbce2245ff14d4a6f72ab762afea55a Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-05-30 17:58:55 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-05-30 17:58:55 +0000 dev-java/java-config: replace @GENTOO_PORTAGE_EPREFIX@ in launcher.bash Closes: https://bugs.gentoo.org/544836 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../{java-config-2.3.1.ebuild => java-config-2.3.1-r1.ebuild} | 7 ++++++- dev-java/java-config/java-config-9999.ebuild | 7 ++++++- 2 files changed, 12 insertions(+), 2 deletions(-)