Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 544836 - dev-java/java-config-2.2.0: expand @GENTOO_PORTAGE_EPREFIX@ in shebang line
Summary: dev-java/java-config-2.2.0: expand @GENTOO_PORTAGE_EPREFIX@ in shebang line
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Java team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-28 21:37 UTC by Martin Mokrejš
Modified: 2018-01-12 20:43 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch fixing the @GENTOO_PORTAGE_EPREFIX@ issue (gentoo_portage_eprefix.patch,543 bytes, patch)
2016-05-08 10:39 UTC, Marcus Comstedt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2015-03-28 21:37:51 UTC
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?
Comment 1 Andrew Savchenko gentoo-dev 2015-04-02 10:35:42 UTC
Please post your emerge --info.
Comment 2 James Le Cuirot gentoo-dev 2015-04-02 12:06:37 UTC
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.
Comment 3 Marcus Comstedt 2016-05-08 10:00:02 UTC
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...
Comment 4 James Le Cuirot gentoo-dev 2016-05-08 10:09:46 UTC
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.
Comment 5 Marcus Comstedt 2016-05-08 10:39:48 UTC
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.
Comment 6 James Le Cuirot gentoo-dev 2016-05-08 12:32:53 UTC
(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.
Comment 7 Marcus Comstedt 2016-05-08 12:55:22 UTC
(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.
Comment 8 James Le Cuirot gentoo-dev 2016-05-08 13:45:58 UTC
(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.
Comment 9 James Le Cuirot gentoo-dev 2016-05-08 13:49:20 UTC
(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?
Comment 10 Marcus Comstedt 2016-05-08 14:11:58 UTC
(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.  :-)
Comment 11 Marcus Comstedt 2016-07-06 12:49:09 UTC
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?
Comment 12 James Le Cuirot gentoo-dev 2016-07-06 13:00:50 UTC
(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.
Comment 13 Benda Xu gentoo-dev 2017-12-11 08:33:32 UTC
What is the status of this bug?
Comment 14 Patrice Clement gentoo-dev 2017-12-11 09:28:56 UTC
I've got to look into it.
Comment 15 James Le Cuirot gentoo-dev 2017-12-11 10:07:21 UTC
(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.
Comment 16 Sophie Hamilton 2018-01-12 19:00:07 UTC
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?
Comment 17 James Le Cuirot gentoo-dev 2018-01-12 20:43:53 UTC
(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.