Created attachment 610612 [details] Build log The new update seems to fail for me. Is a dependency missing?
Created attachment 610614 [details] emerge --info
It appears that the search path is wrong. It looks like the quotation marks in JFX_DEPS_URL are causing the path to be treated as relative. I was able to get it to install properly by removing the quotation marks. --- openjfx-11.0.6_p2.ebuild 2020-01-28 04:09:34.000000000 -0500 +++ openjfx-11.0.6_p2.ebuild 2020-02-08 23:35:52.573562231 -0500 @@ -193,7 +193,7 @@ LINT = none CONF = $(usex debug DebugNative Release) NUM_COMPILE_THREADS = $(makeopts_jobs) - JFX_DEPS_URL = "${T}"/jars + JFX_DEPS_URL = ${T}/jars COMPANY_NAME = "Gentoo" _EOF_ }
is there anything special about your portage tmpdir? uncommon filesystem? I can't reproduce and it works for me just fine. unquoting path containing variables is not good as it'll split if it ever contains a space. I'll poke it later to see how it behaves, maybe we can use quoting at heredoc/cat level.
(In reply to Georgy Yakovlev from comment #3) > is there anything special about your portage tmpdir? uncommon filesystem? > I can't reproduce and it works for me just fine. > > unquoting path containing variables is not good as it'll split if it ever > contains a space. > > I'll poke it later to see how it behaves, maybe we can use quoting at > heredoc/cat level. It occurred to me that it might not be the most universal fix. For me the tmpdir (in /var/tmp) is an ext4 filesystem, mounted in zram. I just tried remounting it as tmpfs and I get the same issue. I also tried /"${T}"/jars, but it causes the same error. It fixes the issue of gradle treating it as a relative path, but still fails to find lucene.
My /var/tmp/portage is symlinked to /home/.root/var/tmp/portage, which is on a different drive, both / and /home are ext4. This hasn't caused any problems thus far in the year I've been running gentoo, and I wouldn't think it would given this path has no special characters.
To both of you have somewhat non-standard setup. Portage may handle it well, but it’s gradle failing. It’s rather complex beast. Thanks, I have some datapoints and will see what I can do.
s/^To/So/ Sorry for typos.
My Error was: * Where: Build file '/var/tmp/portage/dev-java/openjfx-11.0.6_p2/work/rt-11.0.6+2/build.gradle' line: 4637 * What went wrong: A problem occurred evaluating root project 'rt-11.0.6+2'. Could not resolve all files for configuration ':apps:lucene'. Could not find org.apache.lucene:lucene-core:7.1.0. Searched in the following locations: - file:/var/tmp/portage/dev-java/openjfx-11.0.6_p2/work/rt-11.0.6+2/apps/"/var/tmp/portage/dev-java/openjfx-11.0.6_p2/temp"/jars/ivy-7.1.0.xml - file:/var/tmp/portage/dev-java/openjfx-11.0.6_p2/work/rt-11.0.6+2/apps/"/var/tmp/portage/dev-java/openjfx-11.0.6_p2/temp"/jars/ivy.xml - file:/var/tmp/portage/dev-java/openjfx-11.0.6_p2/work/rt-11.0.6+2/apps/"/var/tmp/portage/dev-java/openjfx-11.0.6_p2/temp"/jars/lucene-core-7.1.0.jar - file:/var/tmp/portage/dev-java/openjfx-11.0.6_p2/work/rt-11.0.6+2/apps/"/var/tmp/portage/dev-java/openjfx-11.0.6_p2/temp"/jars/lucene-core.jar My Fix in openjfx-11.0.6_p2.ebuild, probably not ideal, but it worked for me: JFX_DEPS_URL = ../../../../../../../../${T}/jars COMPANY_NAME = "Gentoo" _EOF_ cat <<- _EOF_ > "${S}"/modules/javafx.graphics/gradle.properties JFX_DEPS_URL = ../../../../../../../../../${T}/jars _EOF_
relative dir is not possible because different users may have different directories at different depth levels. probably I could do $(realpath ${T}). I'll test/fix it sometime soon, at least workaround is known now.
For me, the 'fix' from comment #2 worked on two machines already. One of them has a non-standard PORTAGE_TMPDIR, for the other it's the standard one.
The bug is still there. What happens is that for some reason the element is injected (using quotes) as a single element into the path: Could not find org.apache.lucene:lucene-core:7.1.0. Searched in the following locations: - file:/var/tmp/portage/dev-java/openjfx-11.0.3_p1/work/rt-11.0.3+1/apps/"/var/tmp/portage/dev-java/openjfx-11.0.3_p1/temp"/jars/ivy-7.1.0.xml - file:/var/tmp/portage/dev-java/openjfx-11.0.3_p1/work/rt-11.0.3+1/apps/"/var/tmp/portage/dev-java/openjfx-11.0.3_p1/temp"/jars/ivy.xml I have not set PORTDIR_TMPFS at all I had a quick look. According to the Oracle jdk quotation in properties values is not valid: https://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) As such the quotes need to go. It is possible to escape values using backslashes instead.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80c41a511e6c80e1a2f542e360addb4bee553c5e commit 80c41a511e6c80e1a2f542e360addb4bee553c5e Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-03-17 00:13:06 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-03-17 01:01:24 +0000 dev-java/openjfx: fix path to jars Bug: https://bugs.gentoo.org/707798 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-java/openjfx/openjfx-11.0.6_p2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
ok comitted unqoted fix, sorry for taking long. also new version with security fixes. if someone encounters a build failure with a path that has spaces it's their fault, at least for normal paths it should work now. closing, LMK if you encounter it again.
