Re: advice on android-framework-23
Doclava is for generating the source of `android.jar`, which is just stubs of all Android API. Until we find other ways to generate the source, we can't replace it yet. Doclava is another mess, by the way. The latest version fails to generate compileable code so we have to keep using the old version... Hans-Christoph Steiner 於 2019/1/28 上午6:32 寫道: > > > Emmanuel Bourg: >> Le 27/01/2019 à 22:52, Hans-Christoph Steiner a écrit : >> >>> The call that is crashing out with all those errors is the doclava call. >>> I think there needs to be a --patch-module option to java when running >>> doclava, but I'm not sure what the path arg for --patch-module should be >>> there. >> >> doclava? Just kill the javadoc :) > > I think unfortunately it is doing something essential, perhaps seamlik > can fill us in since I think he did that. I think it makes the "stubs" > jar which is used in Android development. > > .hc > signature.asc Description: OpenPGP digital signature
Re: FOSDEM 19 Debian Java talk
Le 30/01/2019 à 22:59, Hans-Christoph Steiner a écrit : > I thought it was worth a blog post too, as a follow up to your talk: > https://salsa.debian.org/publicity-team/bits/merge_requests/16 Nice, remember the Java Team also has its own blog [1], that might be nice to announce the FOSDEM talk there. It's just a matter of updating the blog repository [2], the update is published automatically by a Gitlab trigger. [1] https://java.debian.net/blog/ [2] https://salsa.debian.org/java-team/pkg-java-blog
Re: FOSDEM 19 Debian Java talk
Markus Koschany: > > > Am 30.01.19 um 11:10 schrieb Hans-Christoph Steiner: >> >> Great that you are giving that talk! I think the Java Team's work is >> generally under-appreciated, so getting the word out should help with >> that. Here's what I would add: >> >> I think one thing to mention is how the Debian Java Team has to >> consistently fight the Java standard practice of bundling all deps into >> a single JAR. This means there is no shared security updates, each dev >> has to update every dependency themselves in that model. That works >> great for large companies with staff devoted to doing that. >> >> For the majority of Debian use cases, that works poorly. Debian >> delivers on the promise that people can just "apt install foo" and have >> it work, and receive security updates. The user does not even need to >> know what language the program is written in, it just works. >> >> Java developers need to learn the value of these use cases, and help >> Debian by making it easier to package Java projects in the standard >> distro method, with shared dependencies that are indepentently updated. > > Thanks for your feedback. Yes, that's a very good point and I will > mention it! I thought it was worth a blog post too, as a follow up to your talk: https://salsa.debian.org/publicity-team/bits/merge_requests/16 .hc
Re: Attempt to upgrade libjsonp-java - help needed
On Fri, Jan 25, 2019 at 10:03:44AM +0100, Olivier Sallou wrote: > >>> [INFO] > >>> > >>> [INFO] Reactor Summary for JSR 374 (JSON Processing) RI 1.1.2: > >>> [INFO] > >>> [INFO] JSR 374 (JSON Processing) RI ... SUCCESS [ > >>> 0.418 s] > >>> [INFO] JSR 374 (JSON Processing) API .. SUCCESS [ > >>> 1.684 s] > >>> [INFO] JSR 374 (JSON Processing) Default Provider . FAILURE [ > >>> 0.003 s] > >>> [INFO] JSR 374 (JSON Processing) Media for JAX-RS 1.1 . SKIPPED > >>> [INFO] > >>> > >>> [INFO] BUILD FAILURE > >>> [INFO] > >>> > >>> [INFO] Total time: 2.883 s > >>> [INFO] Finished at: 2019-01-24T17:25:53Z > >>> [INFO] > >>> > >>> [ERROR] Failed to execute goal on project javax.json: Could not resolve > >>> dependencies for project org.glassfish:javax.json:bundle:1.1.2: Cannot > >>> access central (https://repo.maven.apache.org/maven2) in offline mode and > >>> the artifact javax.json:javax.json-api:jar:debian has not been downloaded > >>> from it before. -> [Help 1] > > an other build-dep missing, but I can't see related package in debian Any hint how to resolve this? Kind regards Andreas. -- http://fam-tille.de
Re: Buster soft freeze question
Hi, Am 30.01.19 um 20:55 schrieb Felix Natter: > hi Debian-java, > > I would like to get freeplane-1.7.5-1 into buster, because it contains > important fixes. Unfortunately, upstream is still fixing regressions. > > For stretch, a soft freeze is described as: > "no new packages, no re-entry, normal migrations" [1] > > I think that means that I can get freeplane-1.7.5-1 into buster until > beginning of March (by full freeze)? > > [1] https://wiki.debian.org/DebianStretch > > Many Thanks and Best Regards, The important part for our soft freeze is: "Starting 2019-02-12, only small, targeted fixes are appropriate for buster. We want maintainers to focus on small, targeted fixes. This is mainly, at the maintainers discretion, there will be no hard rule that will be enforced." So ideally we try to avoid packaging new upstream releases and make only small bug fixes with patches. However it is "at the maintainers discretion". I think freeplane is a leaf package and the risk of breaking something unrelated is zero in this case. If you are sure, the new release will be usable and introduce no major regressions, you should be fine. "No new packages, no re-entry, normal migrations" means that every package that is not in testing on 2019-02-12 will not be released in Buster, e.g. triplea. Cheers, Markus signature.asc Description: OpenPGP digital signature
Re: New version has switched build system to Maven - any hint how to resolve dependencies?
On Tue, Jan 29, 2019 at 11:59:04AM +0100, Olivier Sallou wrote: > > > which are less issues but the according JARs are definitely inside Debian: > > > > com.ibatis:ibatis:jar:debian -> libibatis-java > > com.sshtools:j2ssh-core:jar:debian -> libj2ssh-java > > org.emboss:jemboss:jar:debian -> jemboss > > org.biojava:biojava:jar:debian -> libbiojava-java > > com.github.broadinstitute:picard:jar:debian -> picard-tools > > last 2 are build respectivly with ant and gradle, not maven, reason why they > do not expose any maven stuff. Nothing done by build-system. > But indeed we can manually (debian side) add some maven stuff to make it > maven compliant. > We need to add some pom related files and copy files to usr/share/maven > directories. Don't know what maven-helper can do to help us with this. > I think I will need to read maven-helper doc to see what can be done. That would be a nice long term solution. Any hint how we can get artemis out right now? Kind regards Andreas. -- http://fam-tille.de
Re: FOSDEM 19 Debian Java talk
Am 30.01.19 um 11:10 schrieb Hans-Christoph Steiner: > > Great that you are giving that talk! I think the Java Team's work is > generally under-appreciated, so getting the word out should help with > that. Here's what I would add: > > I think one thing to mention is how the Debian Java Team has to > consistently fight the Java standard practice of bundling all deps into > a single JAR. This means there is no shared security updates, each dev > has to update every dependency themselves in that model. That works > great for large companies with staff devoted to doing that. > > For the majority of Debian use cases, that works poorly. Debian > delivers on the promise that people can just "apt install foo" and have > it work, and receive security updates. The user does not even need to > know what language the program is written in, it just works. > > Java developers need to learn the value of these use cases, and help > Debian by making it easier to package Java projects in the standard > distro method, with shared dependencies that are indepentently updated. Thanks for your feedback. Yes, that's a very good point and I will mention it! Cheers, Markus signature.asc Description: OpenPGP digital signature
Buster soft freeze question
hi Debian-java, I would like to get freeplane-1.7.5-1 into buster, because it contains important fixes. Unfortunately, upstream is still fixing regressions. For stretch, a soft freeze is described as: "no new packages, no re-entry, normal migrations" [1] I think that means that I can get freeplane-1.7.5-1 into buster until beginning of March (by full freeze)? [1] https://wiki.debian.org/DebianStretch Many Thanks and Best Regards, -- Felix Natter debian/rules!
Re: FOSDEM 19 Debian Java talk
Great that you are giving that talk! I think the Java Team's work is generally under-appreciated, so getting the word out should help with that. Here's what I would add: I think one thing to mention is how the Debian Java Team has to consistently fight the Java standard practice of bundling all deps into a single JAR. This means there is no shared security updates, each dev has to update every dependency themselves in that model. That works great for large companies with staff devoted to doing that. For the majority of Debian use cases, that works poorly. Debian delivers on the promise that people can just "apt install foo" and have it work, and receive security updates. The user does not even need to know what language the program is written in, it just works. Java developers need to learn the value of these use cases, and help Debian by making it easier to package Java projects in the standard distro method, with shared dependencies that are indepentently updated. .hc Markus Koschany: > Hi all, > > I will attend FOSDEM 19 in Brussels this weekend (03.02.2019, 12:40 > local time) and give a lightning talk (15 min) about our heroics. > > https://fosdem.org/2019/schedule/event/debian_java/ > > Naturally there is not enough time to explain everything in detail but > it should be adequate to put our message across. Here is your chance. > What do you consider important or what would you like other people from > the community to know? > > I would like to reuse some of the scripts that we used for our last blog > post in 2016 [1] to fetch some packaging statistics. Are those scripts > still available? Otherwise I intend to use UDD a lot. > > I want to answer the following questions: > > How does the Java language rank in Debian? > > https://sources.debian.org/stats/sid/ > > How many Java source packages / binary packages do we maintain or are > maintained in total including by other teams? > > How many contributors are there? > > How many uploads were made by those contributors? > > How many bugs were fixed by them? > > How many RC bugs were reported/fixed during the > Wheezy/Jessie/Stretch/Buster release cycle? My guess is the total > numbers are increasing. > > How many RC bugs were caused by OpenJDK7/8/9/10/11? We have our tagged > bugs list for example. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-java@lists.debian.org;tag=default-java9 > > What specific OpenJDK changes caused the most grief? > > Why we all love JavaDoc? :E > > etc. > > If you have some other fun statistic, please let me know. > > Regards, > > Markus > > [1] > https://java.debian.net/blog/2016/06/wheezy-lts-and-the-switch-to-openjdk-7.html >
Fwd: #897945 still present/breaks with Java 8
Sorry, was sent to the wrong address. Forwarded Message Subject: #897945 still present/breaks with Java 8 Date: Tue, 29 Jan 2019 11:40:42 +0200 From: Per Lundberg To: 897...@bugs.debian.org CC: pkg-java-maintain...@lists.alioth.debian.org, Markus Koschany FWIW, version 1.4.2-1 works correctly with openjdk-11-jdk version 11.0.2+7-1, but it _does not_ work correct any more with Java 8 (openjdk-8-jdk version 8u191-b12-2) This worked correctly with 1.3.9-1 after downgrading the libnb-*-java packages as suggested by Ben - visualvm worked fine on Java 8 with this combination of packages. So, we should either: - Reopen the bug and fix the problem (likely by compiling visualvm with openjdk-8, which should make it work on newer JDK versions also) - Accept the breakage and indicate this somehow, preferably in the package metadata. (I don't know if we can use dpkg dependencies in this case? It's perfectly legal to have both OpenJDK 11 and 8 _installed_ on a machine; it's just that the latter is unusable with visualvm from now on.) Because the resolution here is not perfectly clear, I will refrain from just reopening the bug until it has been discussed a bit more. Best regards, -- Per
