Java9: 90 broken by -source/-target
The Java 9 games continue! There are around 90 packages which fail today, but which will succeed if the -source and -target flags are fixed. Here are the build logs / package list: https://rbuild.fau.xxx/2017-08-30/regress/ This is after the current round of ant and Maven changes. There's not a super strong correlation in the results. Some will be fixed by asking ant to force the javadoc source option to 1.6, like the javac option. e.g. https://rbuild.fau.xxx/2017-08-30/regress/opticalraytracer.log I did this test with this minimal patch: https://github.com/FauxFaux/debjdk9/blob/6298e520cb315d93d03872aa8e70b7b964f5e1eb/jdk/allow-old-source-versions.diff The System.err logging is lost in most cases, unfortunately; I suspect build systems typically drop it, or javac is being run as part of some abnormal ant build, or... We could... fiddle the version iff we're running inside dpkg-buildpackage, using environment detection again? Pretty ew. Not sure it would work for Ubuntu. Are we going to fix these all by hand? i.e. shall I raise 90 bugs, and then start changing packages? Or are we going to fix this in the compiler? Or does someone have an ant/environent suggestion? Cheers.
javadocs links with maven-debian-helper
Hi I am packaging some java libraries with maven-debian-helper but having problems setting the javadocs links properly. I have done this for ant based projects but I can't figure out how to do it for maven projects. I took a look on a few other *-java-doc packages that are maven only projects (libjgoodies-looks-java-doc, libakuma-java, and libmetadata-extractor-java-doc) hoping to find the answer. However, they all are linking do docs.oracle.com too instead of the local javadocs. libmetadata-extractor-java-doc on Stretch had the correct javadoc links, back when upstream made use of ant and not maven. I have tried to set user property links [1] in the maven.properties file as described in the javadoc plugin documentation but no avail. How do I set the path for the javadocs of other java libraries when using maven-debian-helper? Thank you Carnë
Help needed: PDFsam
Hi all, Finally fontawesomefx was accepted into the archive and I could upload a slightly more recent version of PDFsam to experimental. So why experimental? At the moment the program fails with an exception message when I try to execute anyone of the available PDF operations: (see below) I already know that downgrading libhibernate-validator-java to version 4.2.1 (exactly the version PDFsam expects, surprise, surprise) resolves all my problems. When I look at the LoggerFactory class in hibernate I can see that they switched from slf4j in version 4.2.1. to jboss-logging in the most recent version. [1] I suspect this is some kind of classpath issue and I either miss a symlink in /usr/share/pdfsam/lib or I have to configure /usr/share/pdfsam/etc/logback.xml accordingly or I have to start PDFsam with some sort of parameter to fix the whole logging mess. Unfortunately I am stuck here. Any ideas? P.S.: That's the problem which I mentioned to tony at Debconf 17 . ;) [1] https://anonscm.debian.org/cgit/pkg-java/libhibernate-validator-java.git/tree/hibernate-validator/src/main/java/org/hibernate/validator/util/LoggerFactory.java?h=debian/4.2.1-1 INFO [17:55:27]: Gestarted in 4 seconds INFO [17:56:01]: example.pdf loaded ERROR [17:56:06]: Unexpected error java.lang.ExceptionInInitializerError: null at org.hibernate.validator.internal.engine.ConfigurationImpl.(ConfigurationImpl.java:63) at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:41) at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:173) at org.sejda.core.validation.DefaultValidationContext.(DefaultValidationContext.java:41) at org.sejda.core.validation.DefaultValidationContext.(DefaultValidationContext.java:36) at org.sejda.core.validation.DefaultValidationContext$DefaultValidationContextHolder.(DefaultValidationContext.java:70) at org.sejda.core.validation.DefaultValidationContext.getContext(DefaultValidationContext.java:50) at org.sejda.core.service.DefaultTaskExecutionService.validate(DefaultTaskExecutionService.java:97) at org.sejda.core.service.DefaultTaskExecutionService.execute(DefaultTaskExecutionService.java:66) at org.sejda.core.service.DefaultTaskExecutionService.execute(DefaultTaskExecutionService.java:58) at org.pdfsam.task.TaskExecutionController.lambda$request$0(TaskExecutionController.java:87) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalArgumentException: Invalid logger interface org.hibernate.validator.internal.util.logging.Log (implementation not found in sun.misc.Launcher$AppClassLoader@1b28cdfa) at org.jboss.logging.Logger$1.run(Logger.java:2556) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529) at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516) at org.hibernate.validator.internal.util.logging.LoggerFactory.make(LoggerFactory.java:28) at org.hibernate.validator.internal.util.Version.(Version.java:27) ... 14 common frames omitted signature.asc Description: OpenPGP digital signature
Re: javadocs links with maven-debian-helper
Am 31.08.2017 um 18:03 schrieb Carnë Draug: [...] > How do I set the path for the javadocs of other java libraries when > using maven-debian-helper? I believe maven-debian-helper requires that you build-depend on related -doc packages and in one of the final steps it tries to resolve those cross-references. But without them you will end up with something like that for libmetadata-extractor-java-doc. Analysing pom.xml... Checking dependencies for documentation packages... > dpkg --search /usr/share/doc/libxmpcore-java/api/index.html dpkg failed to execute successfully Offline mode. Give up looking for package containing /usr/share/doc/libxmpcore-java/api/index.html This step often takes too long and I have recently filed [1] because of it. [1] https://bugs.debian.org/871669 signature.asc Description: OpenPGP digital signature
Re: javadocs links with maven-debian-helper
Le 31/08/2017 à 18:03, Carnë Draug a écrit : > How do I set the path for the javadocs of other java libraries when > using maven-debian-helper? Good question, I'm not even sure this is supported, which is interesting because the *-java-doc package resolution occurring at the end of the build takes a lot of time for basically no benefit since the documentation isn't linked :D My advice: Life is short, forget the javadoc ;) Emmanuel Bourg
Re: javadocs links with maven-debian-helper
On 31 August 2017 at 17:15, Markus Koschany wrote: > Am 31.08.2017 um 18:03 schrieb Carnë Draug: > [...] >> How do I set the path for the javadocs of other java libraries when >> using maven-debian-helper? > > I believe maven-debian-helper requires that you build-depend on related > -doc packages and in one of the final steps it tries to resolve those > cross-references. > > But without them you will end up with something like that for > libmetadata-extractor-java-doc. > > Analysing pom.xml... > Checking dependencies for documentation packages... >> dpkg --search /usr/share/doc/libxmpcore-java/api/index.html > dpkg failed to execute successfully > Offline mode. Give up looking for package containing > /usr/share/doc/libxmpcore-java/api/index.html > I do have all the docs dependencies listed as Build-Depends-Indep. I have tried to move them to Build-Depends but the issue remains. The build log does find them: Analysing pom.xml... Checking dependencies for documentation packages... > dpkg --search /usr/share/doc/libcommons-math3-java/api/index.html Found libcommons-math3-java-doc bash -c "rm -f target/apidocs/*.sh target/apidocs/options" If this step is what should find the right javadoc links, it seems like it's not searching for the javadoc links for default-jdk-doc. The links to String are still to docs.oracle.com. On 31 August 2017 at 17:25, Emmanuel Bourg wrote: > Le 31/08/2017 à 18:03, Carnë Draug a écrit : > >> How do I set the path for the javadocs of other java libraries when >> using maven-debian-helper? > > Good question, I'm not even sure this is supported, which is interesting > because the *-java-doc package resolution occurring at the end of the > build takes a lot of time for basically no benefit since the > documentation isn't linked :D When building upstream directly with maven, this works fine: mvn -Dlinks=/usr/share/doc/default-jdk-doc/api package However, setting links on maven.properties file has no effect. Do you have any idea why? Thank you Carnë
Re: Java9: 90 broken by -source/-target
Le 31/08/2017 à 14:20, Chris West a écrit : > Are we going to fix these all by hand? i.e. shall I raise 90 bugs, > and then start changing packages? Or are we going to fix this in the > compiler? Or does someone have an ant/environent suggestion? I don't think we should touch the compiler, or the peanut gallery will scream in horror and complain that Debian's OpenJDK isn't Java. Let's fix Ant first and see what's left. If a package calls javac or javadoc directly (like junit [1]) a bug can be raised right now. Emmanuel Bourg [1] https://sources.debian.net/src/junit/3.8.2-8/debian/rules/#L24
Re: The state of Maven
Le 3/08/2017 à 10:31, Emmanuel Bourg a écrit : > This caused some disruptions, not all are resolved yet, but > fortunately I've managed to avoid the trap of breaking Maven completely > and being unable to fix it. I take that claim back :) As I switched more packages from the older dependencies to the new ones I've hit a point where some packages expecting an older dependency but not declaring it directly now fail to run. Fortunately this affects rarely used packages like... maven-debian-helper :) I suspected this could happen but it was difficult to guess where it would strike. I'm rushing to upload a fix tonight, sorry for the disruption. Emmanuel Bourg
Re: The state of Maven
Le 5/08/2017 à 23:39, Thorsten Glaser a écrit : > The C function isatty() on the output filedescriptor, but in a > build helper like that I’d expect it to always be disabled. I tried istty() but it's disabled when using pbuilder even if the terminal supports colors. I used 'tput colors' in maven-debian-helper 2.2.3 to detect if the colors are supported, but the escape sequences still appear in the reproducible build logs. I'd like to avoid disabling the colors completely, if someone has a good idea I'm interested. Emmanuel Bourg
