| Summary: | net-vpn/i2p-0.9.44: Ebuild fundamentally broken by bump. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Cecil Curry <leycec> |
| Component: | Current packages | Assignee: | tharvik |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | java, juippis, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
My bad, I'm clearly not familiar with java eclasses. I only build-tested it. Thanks for the verbose description of the problem, and also thanks for including the fix. I'll test it and attempt fixing. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=967fab266a2942f3c6d068b8c43b92bbb5a9ee2f commit 967fab266a2942f3c6d068b8c43b92bbb5a9ee2f Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2020-01-16 05:46:32 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-01-16 05:48:15 +0000 net-vpn/i2p: adhere to java-utils-2.eclass with 0.9.44 Closes: https://bugs.gentoo.org/705520 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-vpn/i2p/{i2p-0.9.44.ebuild => i2p-0.9.44-r1.ebuild} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) |
"i2p-0.9.44.ebuild" is fundamentally broken. "i2p-0.9.42.ebuild" is not. Someone (who is fortunately not me) has made untested, harmful modifications to "i2p-0.9.42.ebuild" during the most recent bump to I2P 0.9.44 ten days ago. Thanks to this, I2P 0.9.44 silently fails at startup. Tailing "/var/log/i2p/wrapper" yields the culprit: $ tail /var/log/i2p/wrapper 2020/01/15 23:48:17 | Error: Could not find or load main class org.tanukisoftware.wrapper.WrapperSimpleApp 2020/01/15 23:48:32 | Launching a JVM... 2020/01/15 23:48:32 | JVM exited while loading the application. 2020/01/15 23:48:32 | Error: Could not find or load main class org.tanukisoftware.wrapper.WrapperSimpleApp 2020/01/15 23:48:47 | Launching a JVM... 2020/01/15 23:48:47 | JVM exited while loading the application. 2020/01/15 23:48:47 | Error: Could not find or load main class org.tanukisoftware.wrapper.WrapperSimpleApp 2020/01/15 23:49:01 | Launching a JVM... 2020/01/15 23:49:01 | JVM exited while loading the application. 2020/01/15 23:49:01 | Error: Could not find or load main class org.tanukisoftware.wrapper.WrapperSimpleApp Allow us to dissect this for the captive audience at home. "org.tanukisoftware.wrapper.WrapperSimpleApp" is the fully-qualified name of the main Java class in the "/usr/share/java-service-wrapper/lib/wrapper.jar" file installed by the "dev-java/java-service-wrapper" package required by I2P. Clearly, this JAR file is missing from the classpath of I2P 0.9.44. But...why? Let us recall that I2P defines its classpath as a sequentially ordered list of "wrapper.java.classpath."-prefixed variables in the user-configurable "/usr/share/i2p/wrapper.config" file. In I2P 0.9.42, this list referenced "/usr/share/java-service-wrapper/lib/wrapper.jar". In I2P 0.9.44, this list only references core I2P JAR files installed with I2P itself; all references to external JAR files installed by dependencies (including "/usr/share/java-service-wrapper/lib/wrapper.jar") have now been removed. Specifically, the classpath for I2P 0.9.44 has been truncated to a one-liner: wrapper.java.classpath.1=/usr/share/i2p/lib/* That's it. How did this terrifying act of depravity come to be? Sadly, someone thought it would be an intelligent idea to globally rename the ${CP_DEPEND} global in "i2p-0.9.42.ebuild" to ${COMMON_DEPEND} in "i2p-0.9.44.ebuild". They then failed to test. If I2P were not a Java application, this might have been the right thing to do. Since I2P is in fact a Java application, this really was the wrong thing to do. Java ebuilds inheriting the "java-pkg-2" and thus "java-utils-2" eclasses require the ${CP_DEPEND} global to be declared at package scope. When this global is undefined, the java-pkg_gen-cp() utility function that generates each package's classpath *SILENTLY REDUCES TO A NOOP.* That function is called by both the generic java-pkg-2_src_compile() phase function and this ebuild's src_prepare() phase function -- fundamentally breaking everything. The fix is trivial: just globally rename the ${COMMON_DEPEND} global in "i2p-0.9.44.ebuild" back to ${CP_DEPEND} and bump to "i2p-0.9.44-r1.ebuild". The more concerning question is: how, exactly, did a non-working, untested modification creep unmolested into the Portage tree in the first place? I leave that question to my superiors.