| Summary: | app-text/jabref needs to depend on dev-java/antlr:4 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markus Walter <gentoo> |
| Component: | Current packages | Assignee: | James Le Cuirot <chewi> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | java, jstein, nicolasbock, sci |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info jabref | ||
emerge --info app-text/jabref please I'll take this one as antlr is a tricky beast. This must be 2.10-r4 because -r2 doesn't have antlr:0. The error can't be coming directly from this ebuild though because it doesn't reference antlr:4 at all. I don't have antlr:4 installed and if I install jabref, nothing pulls it in and the build still succeeds. Your system must have got into an odd state with one of the dependencies pulling it in. This should tell us which one. fgrep antlr-4 /usr/share/*/package.env To be honest, this ebuild isn't great. You generally shouldn't use --with-dependencies in src_compile. I tried without and it works. You shouldn't even use java-pkg_getjars for an Ant-based package as EANT_GENTOO_CLASSPATH deals with this. I suspect the ebuild was written like this for a reason but I can't find it. It also bundles all the dependency jars inside the final jabref.jar, which is very bad. This triggers a ton of warnings when you have JAVA_PKG_STRICT=yes set. (In reply to James Le Cuirot from comment #2) > I'll take this one as antlr is a tricky beast. Thanks! Created attachment 430436 [details] emerge --info jabref Sorry I was a bit grumpy because this repeatedly hit me on my work machine. My work machine is a mostly stable amd64 system and I checked this problem with my home machine (an ~amd64 box) and it wasn't present there. So I did some more testing and now I'm in the unlucky position to say, that I cannot reproduce the problem anymore. I did some digging [1] and the jabref ebuild did indeed at one point depend on antlr:4, but this was changed in place. And around that time the offending jabref instance was built on my box (the log says Thu Jun 18 12:26:15 2015 >>> app-text/jabref-2.10-r2). So I assume, that this is some dependency weirdness and gone now. For reference: the fgrep command returned /usr/share/jabref/package.env:DEPEND="antlr:antlr-4:fontbox-1.7:glazedlists:jempbox-1.7:log4j:microba:spin" [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-text/jabref/jabref-2.10-r2.ebuild?r1=1.3&r2=1.4 any news? Is a bump a solution/workaround? I've never seen this issue again, so it is probably gone for good. OK, then I close the bug, please reopen if this was premature. |
Otherwise one gets the following error. Currently the ebuild only depends an antlr:0 and antlr:3. Manually merging antlr:4 fixes the issue (but it gets removed by depclean regularily for me). Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/gjl", line 121, in <module> args = get_args(pkg) File "/usr/lib/python-exec/python2.7/gjl", line 38, in get_args classpath, library = get_pkg_args(pkg) File "/usr/lib/python-exec/python2.7/gjl", line 19, in get_pkg_args classpath = manager.build_dep_path([package.name()], "CLASSPATH", missing_deps) File "/usr/lib64/python2.7/site-packages/java_config_2/EnvironmentManager.py", line 354, in build_dep_path p = self.get_package(dep[-1]) File "/usr/lib64/python2.7/site-packages/java_config_2/EnvironmentManager.py", line 154, in get_package return self.load_package(pkgname) File "/usr/lib64/python2.7/site-packages/java_config_2/EnvironmentManager.py", line 83, in load_package raise UnexistingPackageError(name) java_config_2.Errors.UnexistingPackageError: Package antlr-4 was not found! Couldn't get needed information