Re: Tomcat 9 removed from Debian 12
Le 03/05/2024 à 15:46, Thorsten Glaser a écrit : Full disclosure, while I’m a Debian Developer and team member, Emmanuel has veto’d the changes to the tomcat9 package in the past (mostly on the grounds of using adduser… *sigh*). Still shooting in my direction five years later? Will that ever stop? Can't we agree to disagree and move on please? There are other challenges in the Debian Java ecosystem that require our focus and energy. because the javax.* to jakarta.* packages problem Upstream Tomcat says they can convert that automatically, but I wouldn’t rely on just that because from experience I know that upgrading the Tomcat version is always a breaking change that needs changes to all applications. The Tomcat migration tool is fairly reliable, but if you find specific issues please report them to: https://github.com/apache/tomcat-jakartaee-migration/ Emmanuel Bourg
Re: Tomcat 9 removed from Debian 12
Hi Luis, Le 03/05/2024 à 11:54, Luis Panadero Guardeño a écrit : I know that the remove tomcat9 packages was done on December of 2023 and that this was decided a long time ago. But I think that nobody has stopped to consider that you *cannot simply migrate from Tomcat 9 to 10 *(inserte here meme), because the javax.* to jakarta.* packages problem. The changes needed to move a web application from javax to jackarte aren't simple to do. Specially when *3rd party java libraries, aren't migrated yet to jakarta packages* ( for example Apache Commons Email ). You don't have to migrate to the jakarta.* namespace yet, Tomcat 10 supports both javax and jakarta webapps, just install the tomcat-jakartaee-migration package and drop your .war file to the webapps-javaee directory, the classes will be automatically converted, see: https://tomcat.apache.org/migration-10.html#Specification_APIs I really hope that someone could reconsider to keep both Tomcat 9 and Tomcat 10 on Debian 12. If some help it's needed to do this, I could help (however I don't have idea how to do this). This won't happen unfortunately, Tomcat is a security intensive package and we can really maintain efficiently only one version per Debian release. I choose Debian instead of keeping using Ubuntu server, because the well know stability of Debian (plus I HATE Canonical weird things and forcing snap on everything) and I don't expected this kind of changes inside a stable version. The javax->jakarta transition is annoying for everyone, but you should blame Oracle lawyers for this mess, the Debian Java Team is just following the trend. Emmanuel Bourg
Re: Removing freeplane 1.7.x from Debian?
Le 06/04/2024 à 17:10, Thorsten Glaser a écrit : On Sat, 6 Apr 2024, Emmanuel Bourg wrote: since upstream already provides a package. That is not a justification appropriate for a Debian mailing list. Got caught by the mailing list police, doh! ;) Not need to invent mailing list rules to state your disagreement. IMHO upstreams providing packages contribute to the success of the Debian ecosystem, which is a good thing overall. Emmanuel Bourg
Re: Removing freeplane 1.7.x from Debian?
Le 31/03/2024 à 20:32, tony mancill a écrit : What do you think? In my opinion we should be remove the outdated freeplane package from Debian. +1, even if fixing the security manager issue is easy, I'm tempted to think there is little benefit packaging freeplane ourself since upstream already provides a package. Emmanuel Bourg
Re: Intended use of ${maven:CompileDepends}
Hi Sebastiaan,
Le 11/11/2023 à 09:15, Sebastiaan Couwenberg a écrit :
What's the intended use of the ${maven:CompileDepends} substvar?
It shouldn't be added to Depends nor Built-Using. The dpkg-gencontrol
warning makes it very tempting to add it to Depends as some package in
the archive have incorrectly done.
I've resorted to stripping it from the generated substvars file before
dh_gencontrol to get rid of the warning, but it seems better to do this
in maven-debian-helper.
I'll have to check but I think the intended use of
${maven:CompileDepends} is for packaging parent poms, in this case you
want the plugin dependencies to appear in the Depends field of the package.
Emmanuel Bourg
Re: Bug#1054361: ITP: jruby-jzlib
Le 24/10/2023 à 16:28, Jérôme Charaoui a écrit : Right, my thinking was to use the same path usj/jzlib.jar to signal the classpath conflict. Otherwise, we can install it to usj/jruby-jzlib.jar and not make the packages conflict, but I'm not sure what would happen if both were installed at the same time, at the JVM-level. If both jars are loaded in the classpath the JVM will randomly resolve the classes from the 2 files, that may lead to runtime errors if the two implementations are not binary compatible. There are some (small) code changes as well, here is a pkgdiff report: https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html Looking at the changes : * DeflaterOutputStream.java: exception message changed * GZIPHeader.java: private 'time' variable removed * GZIPInputStream.java: getModifiedTime method added (typo fix) * Inflate.java: call a setter instead of setting the variable directly * ZStream.java: comment change The only notable change is the addition of getModifiedTime(), we can add it to the existing package. In addition, I believe there may be more substantive changes in the future since there are zlib-related bugs reported against JRuby which may lead to further changes in jruby-jzlib, see https://github.com/jruby/jruby/issues/6613 Good point. If the code diverges significantly an independent package is perfectly justified then. Emmanuel Bourg
Re: Bug#1054361: ITP: jruby-jzlib
Hi Jérôme, Le 24/10/2023 à 15:18, Jérôme Charaoui a écrit : I've prepared the jruby-jzlib package, but I'm uncertain about the relationship it should have with jzlib. Since the module itself is still using the same "com.jcraft" namespace, I'm thinking of using a Conflicts: and Provides: on libjzlib-java. No that's not necessary, because the libjzlib-java and libjruby-jzlib-java packages do not conflict at the filesystem level. The Conflicts field doesn't cover classpath conflicts. You can check out the package here: https://salsa.debian.org/lavamind/jruby-jzlib I got a quick look at the jzlib fork [1] and there are very few changes compared to the original project, it just adds a JPMS auto module name. We could simply patch our existing jzlib package instead of introducing a new one. On the jruby side, that would mean patching the Maven coordinates of jzlib (org.jruby:jzlib -> com.jcraft:jzlib). Emmanuel Bourg [1] https://github.com/jruby/jzlib
Re: Q: javac -source and -target version
Hi Hideki, Le 08/10/2023 à 05:25, Hideki Yamane a écrit : Thank you, and how about adding java_compat_level=8 for Java21? Since some FTBFS reports are there. https://salsa.debian.org/java-team/java-common/-/merge_requests/3 java_compat_level=8 is supported in java-common/0.75+exp1 in experimental. If you want to test the compatibility with Java 21 you can install default-jdk from experimental, it will switch the default JDK to Java 21 and update the java_compat_level macro. Emmanuel Bourg
Re: Q: javac -source and -target version
Le 05/10/2023 à 01:07, Hideki Yamane a écrit : We should probably provide the minimum language level supported as a variable in the /usr/share/java/java_defaults.mk file from java-common. Nice, each Java packages do not need to care about which level should use and drop it safely, then? I've just uploaded java-common/0.75 with a new java_compat_level variable if you want to give it a try: #!/usr/bin/make -f include /usr/share/java/java_defaults.mk build: javac -source $(java_compat_level) -target $(java_compat_level) ... It's preferable to keep using the -source/-target options rather than removing them, it extends the lower bound of the Java versions range usable with the package. Emmanuel Bourg
Re: Q: javac -source and -target version
Le 04/10/2023 à 13:36, Hideki Yamane a écrit : Well, is there any text / document to use which version should be used for -source and -target version, or is just dropping those options allowed? For Java 17 the minimum was 7, and with Java 21 the minimum is 8. For packages using ant, Maven or Gradle the level is adjusted automatically. You can drop the language level, but the package will require the same version or higher at runtime. We should probably provide the minimum language level supported as a variable in the /usr/share/java/java_defaults.mk file from java-common. Emmanuel Bourg
Re: FYI: I created a Gradle issue for bootstrappable Debian support
Hi Sean, Thank you for your support, I'm glad someone appreciates our FrankenGradle ;) Gradle is difficult to upgrade in Debian for a variety of reasons. For one thing it's a huge monolith and thus it's a bit all or nothing, if one part is missing your are stuck. Maven in comparison is highly modular and can be upgraded piece by piece. The major pain point currently is the Kotlin DSL, I wish the core of Gradle would have remained pure Java/Groovy. And then there is the non-free stuff like the Gradle enterprise plugin that gets in the way. Addressing these issues in Gradle isn't a trivial task, and I doubt the bootstrappability is compelling enough to motivate the Gradle developers to work on it. If this is important for bitcoinj I would suggest switching to another build tool, either Maven if you have a fairly standard project structure, or Ant if you need the flexibility of an imperative build system (and Ant is by far the easiest to bootstrap). Emmanuel Bourg Le 25/09/2023 à 22:17, Sean Gilligan a écrit : Hi Everyone, I appreciate the efforts of the Debian Java team and know that your job is not easy. I work on bitcoinj (Java) and we are (for better or worse) using Gradle for our builds. We are stuck supporting Gradle 4.4.x, when the latest version of Gradle 8.3 (or 8.4) is required to support JDK 21 (if you're not using the Debian-patched Gradle, of course.) I had thought there was already an issue for this on the Gradle GitHub project, but today I couldn't find anything. So I created a new one: https://github.com/gradle/gradle/issues/26516 I thought I would share that with you for reference purposes. Or maybe someone might want to comment on the issue, especially if anyone from Gradle responds or asks questions. I'm hoping that priorities at Gradle may be changing now that supply-chain security has become a more visible issue in the industry. (Yes, I'll admit to being an optimist.) Anyway, thanks for your efforts. We do appreciate them. Regards, Sean p.s. If you're interested in how we are dealing with this at bitcoinj, I created an issue there as well: https://github.com/bitcoinj/bitcoinj/issues/3287
Re: Updating source/target level for Java 21 compatibility to 8
Le 2023-09-25 04:17, Vladimir Petko a écrit : I have prepared a script[1] to report the obvious failures here[2]. I wonder if I should send a mass bug filing email to debian-devel mailing list before running it? Best Regards, Vladimir. [1] https://git.launchpad.net/~vpa1977/+git/default-java21/tree/report-all.sh?h=main [2] https://git.launchpad.net/~vpa1977/+git/default-java21/tree/?h=main Nice! I've rebuilt the Java packages last week and started filling a few bugs, but it looks like you've already caught most of them. I suggest a minor tweak to the script, the severity could be set to important since these bugs will turn into build failures in the near future. Also there is an unnecessary space before "FTBFS". Go ahead and file the bugs. I'll probably reword the titles afterwards to add a description of the issue, that's convenient to pick and fix similar bugs from the list. Emmanuel Bourg
Re: Updating source/target level for Java 21 compatibility to 8
Le 2023-09-14 01:03, Vladimir Petko a écrit : Java 21 removes source/target compatibility level 7. Some packages (80 in total as per the attached list) have it specified in rules or Makefiles. I was wondering if it is okay to raise a single bug to update them and submit the changes as pull requests on Salsa. For the previous Java migrations I started with a mass rebuild and then filling a bug report for each broken package. The reports had a user tag to be able to follow the progress (and document the main issues encountered). Here is for example the bug list for the migration to Java 17: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-java@lists.debian.org Personally I find it satisfying to see the list shrinking over time, I also hoped that it would entice new contributors to join the migration effort (but it barely materialized, if at all). But as long as the work is done it doesn't really matter how it is organized. Also, we could add a DEB_ variable to specify the minimal supported level. The variable will allow us to avoid repeating this work in the future, but I am not sure what is the best way to provide it. Interesting idea. Where would that variable be declared? In debhelper? Will the maintainers agree? As a side note, bumping the source/target level isn't always the best solution. For example olap4j breaks when building the Javadoc, in this case I recommend scrapping the -java-doc package. These packages are a recurrent source of issues when migrating to more recent JDKs, and they are almost never used. Emmanuel Bourg
Re: [RFC] Removing support for GCJ and GCJFLAGS from dpkg?
Hi Guillem, On 31/08/2023 02:23, Guillem Jover wrote: So I guess it should be fine to rip that off? Yes go ahead, GCJ is long dead and gone, you can remove the remaining references safely. Emmanuel Bourg
Re: Maintainer field of openjdk-8
On 07/07/2023 19:29, Thorsten Glaser wrote: Alioth is no longer maintained, but the old lists.alioth.debian.org addresses have been preserved and should still be used. But not for new things, I understood? Not for new teams, but new packages in existing teams can keep using the same address. Emmanuel Bourg
Re: openjdk-8 still needed for bootstrapping?
On 26/06/2023 20:53, Thorsten Glaser wrote: Last time I asked the answer was a vague yes; is this still the case? Nothing has changed, so yes. We just need openjdk-8 in unstable. Emmanuel Bourg
Re: Maintainer field of openjdk-8
On 04/07/2023 20:42, Thorsten Glaser wrote: This is how I understood team-maintained packages to be handled. Especially how else are people supposed to get the bug traffic. debian-java@lists.debian.org is a discussion list, notifications should go to pkg-java-maintain...@lists.alioth.debian.org wnpp bugs are also welcome on debian-java@lists.debian.org I remember that a few years ago, I had put the list as the Maintainer of one of my packages and I was asked to set it to pkg-java-maintain...@lists.alioth.debian.org instead. AIUI Alioth lists are no longer maintained, deprecated and should especially not be used in new places. Alioth is no longer maintained, but the old lists.alioth.debian.org addresses have been preserved and should still be used. Emmanuel Bourg
Re: Installing runnable Eclipse from Debian packages
Hi Gervase, The Debian project doesn't provide packages to install the Eclipse IDE, this is a complex software and we don't have enough volunteers to maintain it properly. However we do package some of the libraries developed by the Eclipse project since they are used by other applications (for example Tomcat uses the Eclipse JDT compiler, BiglyBT uses Eclipse SWT). That's why there are several eclipse-platform-* packages, but that doesn't mean you can install the Eclipse IDE from them. Emmanuel Bourg On 26/04/2023 22:01, Gervase wrote: Currently, I have access to the packages 'eclipse'/'eclipse-platform' on Ubuntu. Having either installed then allows additional packages/plug- ins to be installed for the various computer languages (e.g. JDT, CDT, pydev). With a view to moving to Debian, I looked through the debian-java mailing list archive and noticed the package 'eclipse-platform-runtime' mentioned in a post from mid-January 2023. However, it is not a package for installing a directly runnable Eclipse platform. Looking at "https://wiki.debian.org/Eclipse;, there is no mention of installing Debian packages to install Eclipse. In fact, in the history of edits to the wiki page, I found the following dated 2019-10-04: "eclipse can not be installed as package in the current stable, not even as backport, download from originating page is only option left..." To me, not being able to install Eclipse using Debian packages does not square with the fact that 'eclipse-platform-runtime' exists. Therefore, what is the how-to with regards to installing Eclipse using only Debian packages? In other words, how to make it so that the Eclipse wiki page has valid instructions for installing Eclipse using only Debian packages. Thanks, Gervase.
Re: OpenJDK package - JTREG 7.1
Le 2023-03-02 01:30, Thorsten Glaser a écrit : openjdk-8 was switched to jtreg6 recently. See if doko will follow for 11. openjdk-11/11.0.18+10-1 in unstable now uses jtreg6 Is a new package needed anyway? I agree with Thorsten, a new package is probably not needed. All openjdk-* packages in unstable now use jtreg6. So I suggest upgrading the unused jtreg package to the version 7 instead of creating a new package. Emmanuel Bourg
Re: OpenJDK package - JTREG 7.1
Hi, Thank you for the package Vladimir, I'll take care of it. I think I'll rebase it on top of the previous jtreg package to keep the continuity. Emmanuel Bourg Le 2023-03-15 08:23, Vladimir Petko a écrit : Hi, Thank you very much for your help!!! I have filed ITP here [1]. Best Regards, Vladimir. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032981 On Wed, Mar 15, 2023 at 8:53 AM Thorsten Glaser wrote: On Wed, 15 Mar 2023, Vladimir Petko wrote: >Since I can not upload I will file the ITP then. Depends on your sponsor, whether they insist on one. But, go ahead. >Would it be ok to >keep ownership with the Debian Java Team in line with jtreg6? Usual procedure is that for team-maintained packages, the Maintainer field is the team and the Uploaders field has at least one human who ideally is the primary maintainer for that package; this can be a nōn-Debian member. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Re: reply: Bazel Removal from Debian
Le 2023-02-23 12:48, Thorsten Glaser a écrit : How about asking Doko to locally add that parameter to 17 as a Debian-specific patch, just ignoring it? Patching the JDK is overkill, it's just a flag to change in a script. The question is, where is this script? Emmanuel Bourg
Re: ca-certificate-java/openjdk installation issues
Hi Vladimir, Thank you for tackling this annoying issue. You said that JKS was required to support OpenJDK 8, but there is no such requirement, at the Debian level at least. What about generating a PKCS#12 certstore with OpenSSL instead, would that work? The python script could still be used for OpenJDK 8 (with a dedicated ca-certificate-java8 package maybe). This way installing openjdk-17 would not drag in python dependencies. Emmanuel Bourg Le 2023-02-07 20:12, Vladimir Petko a écrit : Dear Maintainers, Would it be possible to consider a proposal to break dependency of ca-certificates-java on the installed JVM? Abstract ca-certificates-java package contains a circular dependency with Java that causes issues during openjdk installation. I am proposing switching the ca-certificate-java certificate import tool to Python to break the dependency cycle. Rationale The certificate import tool in ca-certificate-java is written in Java. This is a constant source of bugs [1] and requires updates (including stable release updates [2]) whenever a new JDK version comes out. Switching certificate import to Python will remove the maintenance load and break a cyclic dependency. Existing Functionality ca-certificates-java synchronizes content of Java keystore /etc/ssl/certs/java/cacerts with trusted certificates in PEM format located in /etc/ssl/certs using jks-keystore hook registered with ca-certificates package. During hook invocation or post installation following actions are performed: - ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts and attempts to convert it into legacy Java Key Store(JKS) format due to the requirement to support OpenJDK 8. OpenJDK 11 and up support both legacy and PKCS11 formats. - ca-certificate-java lists all available certificates in the keystore using Java keytool, filters certificate aliases and compares the list with the system certificates. An input file containing '+debian:' for addition and '-debian:' is generated and passed to import utility. Import utility updates /etc/ssl/certs/java/cacerts and sets updated certificate alias to 'debian:' Note: Import utility only updates certificates with 'debian:' alias Requirements In order to remove dependency on Java, the certificate import tool must: - List certificate aliases - Add or update certificate in Java Key Store - Convert PKCS12 store to JKS format - Load certificate in PEM format - Retain any user's certificates in Java Key Store Implementation This functionality can be implemented using the following Python packages: - python3-pyjks: Java Key Store format support [4]. It supports loading, manipulation and serialization of the JKS files. It is needed for requirements 1 and 2. - python3-oscrypto: PKCS12 and X509 support [3]. The package depends on OpenSSL 3.0. The package supports loading PKCS12 certificate store and extracting certificates along with SafeBag aliases. It is needed for requirements 3 and 4. ca-certificates-java will install the /usr/sbin/ca-certificates-java tool. It will accept following options: - sync - synchronize the keystore - list - list certificate aliases in the keystore - convert- convert the keystore into JKS format. Best Regards, Vladimir. [1] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java [2] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065 [3] https://launchpad.net/ubuntu/+source/oscrypto [4] https://launchpad.net/ubuntu/+source/pyjks
Re: Bazel Removal from Debian
Le 2023-02-21 16:03, Olek Wojnar a écrit : I *have* temporarily disabled the Java tests [1]. As you said, to not hold back the package due to a possibly flaky test. But my concern is that this is actually an issue with how Bazel uses Java rather than a flaky test. Again, I'd be happy to be wrong about that. :) This is really just an optimization parameter, I don't think this is a critical issue. There is probably a UseParallelOldGC parameter left somewhere in the bazel source files. I can't find it on codesearch [1], maybe in a zip extracted at build time? Emmanuel Bourg [1] https://codesearch.debian.net/search?q=UseParallelOldGC+package%3A%5CQbazel-bootstrap%5CE
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-02-13 16:38, Hans-Christoph Steiner a écrit : android-framework-23 is in bullseye. So I doublechecked, it is actually just a conflict with JDK17, due to the removal of com.sun.javadoc, which was deprecated in JDK11. JDK8 would cover that though. I have no idea how much work it'd be to port to the new API https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567 Another solution, maybe simpler: package the com.sun.javadoc API in a standalone package, independent from openjdk-8 Emmanuel Bourg
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-02-10 18:07, Thorsten Glaser a écrit : The MIPS buildds are at it currently and expected to finish soon, in case you still want to go forward. It’s close to soft freeze. It's still building but that's fine, we won't need openjdk-8 for kotlin, the beast has been tamed. Emmanuel Bourg
Re: help with plugin versions and maven-debian-helper
Le 2023-02-10 15:01, Thorsten Glaser a écrit : DevRef §6.7.8.2 indicates that using such a suffix for *all* repacked origtgz is better. Almost all our packages are repacked, that's pointless and brings no useful information. https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#repackaged-upstream-source "may use packagename-upstream-version+dfsg (or any other suffix which is added to the tarball name) as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones." The 'may' requirement for the suffix is very weak. The Lintian repackaged-source-not-advertised warning should be downgraded to pedantic. Our time is limited, let's focus on important things. Emmanuel Bourg
Re: help with plugin versions and maven-debian-helper
Le 2023-02-10 01:50, Joe Nahmias a écrit : - Don't build the -java-doc package, that's useless Um, why do you say it's useless? Because with every new Java release we keep getting new javadoc issues breaking the builds and violating the Debian policies. Considering that almost nobody use these packages it's not worth the time we're investing in maintaining them. So the current trend is rather to remove them. - Drop the +ds suffix Why? Isn't that traditionally used to show a repack? I have a preference for clean version numbers. The suffix is useful if a version was already packaged and needs to be modified afterward because unwanted files were included by mistake. Emmanuel Bourg
Re: help with plugin versions and maven-debian-helper
Le 2023-02-09 19:39, Joe Nahmias a écrit : Thanks for all your help. I think I managed to figure this out finally. I've put my repo on salsa here: https://salsa.debian.org/java-team/jackson-modules-java8 Anyone care to do a(n in-depth) review before I upload? Great! Here is my review: - Don't build the -java-doc package, that's useless - The Maven wrapper should be removed (mwn* and .mvn/wrapper/*) - I'd use the default gbp branch layout (master/upstream/pristine-tar) instead of the DEP 14 layout (debian/latest). Most Java packages follow the gbp layout and it's important all packages remain consistent. - Drop the +ds suffix - debian/changelog doesn't close an ITP bug - Why declaring a Provides field on virtual packages? That's unusual The content of the binary package is perfect. Nice trick in debian/control to reuse the same description, I didn't know that was possible. Emmanuel Bourg
Re: help with plugin versions and maven-debian-helper
Le 2023-02-09 00:24, Joe Nahmias a écrit : I see jackson-annotations comes from package libjackson2-annotations-java, and indeed version 2.14.0-1 does not contain a debian symlink for /u/s/maven-repo [0]. Any more ideas? You are probably missing a substitution rule for jackson-annotations: com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * * Emmanuel Bourg
Re: help with plugin versions and maven-debian-helper
Le 2023-02-08 05:47, Joe Nahmias a écrit : [ERROR] Unresolveable build extension: Error resolving version for plugin 'org.apache.felix:maven-bundle-plugin' from the repositories [local (/usr/share/maven-repo), central (https://repo.maven.apache.org/maven2)]: Plugin not found in any plugin repository @ Is this a bug in libjackson2-core-java (which provides oss-parent) for stripping the version tags in the plugin section (they are present upstream and in the source) or am I misusing mh_make and/or maven-debian-helper in some non-obvious (to me) way? Hi Joe, You can try changing the packaging type from bundle to jar, or ignore the parent pom, just to get the initial run of mh_make to complete without error. Emmanuel Bourg
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-01-26 17:17, Emmanuel Bourg a écrit : I've been working on Kotlin lately, trying to make it build with OpenJDK 17 only, and hopefully have it included in Bookworm. Long story short, after days banging my head on this issue, I don't think it's possible. I take that back, kotlin now builds with OpenJDK 17 and is on track to migrate to testing. This comes at a price though, besides my sanity I had the sacrifice the Android support (the Android dependencies still build with OpenJDK 8) and the -Xuse-javac option which hasn't been updated for OpenJDK 17 yet [1]. It isn't extensively tested yet but the resulting package is good enough to rebuild itself. The next hurdle is to enable the Kotlin DSL in Gradle. I've packaged the version of gradle-kotlin-dsl that came with Gradle 4.4 but it doesn't work. When Gradle encounters a .kts file an obscure error is thrown (NoDescriptorForDeclarationException: Descriptor wasn't found for declaration SCRIPT). I have no idea how to fix this, and I now think this is a dead end anyway. gradle-kotlin-dsl uses internal Gradle APIs that changed in Gradle 5, so if we use the Kotlin syntax to upgrade Gradle, it'll break immediately and we'll be unable to rebuild Gradle. The solution I think is to upgrade Gradle to the first version with the Kotlin DSL source code merged, which is Gradle 5.3. I leave that to someone else. Emmanuel Bourg [1] https://youtrack.jetbrains.com/issue/KT-56235
Re: Kotlin and OpenJDK 8 in Bookworm?
Le 2023-01-26 19:39, Thorsten Glaser a écrit : ineluctable truth: we need OpenJDK 8 back into the stable distribution. Not going to happen, sorry. This has been vetoed by the security team and was the condition for keeping it in unstable at all. Are you opposed to this idea, or just pessimistic it could be accepted? I think it's important to highlight that the situation has evolved. We thought openjdk-8 was good enough in unstable only to bootstrap Kotlin and then move to a more recent JDK, but this isn't going to happen. Also there was an uncertainty on the lifetime of OpenJDK 8, but it's clear now that it'll be maintained for at least two more Debian releases. We have invested an insane amount of time in these Kotlin/Gradle issues, maintaining openjdk-8 in stable would require only a fraction of that. The longer we wait, the more likely we are going to paint ourself in a corner, with a completely broken and unmaintainable Gradle for example, or other elements in our tool chain that will no longer work with OpenJDK 8 and break even more the kotlin build. We still have some time to discuss this before the Bookworm release. I suggest that we let openjdk-8 transition to testing now before the beginning of the soft freeze, just to keep our options open. We won't expand the usage of kotlin during that time (no Gradle upgrade for example) such that the situation remains reversible before the release. Emmanuel Bourg
Kotlin and OpenJDK 8 in Bookworm?
Hi all, I've been working on Kotlin lately, trying to make it build with OpenJDK 17 only, and hopefully have it included in Bookworm. Long story short, after days banging my head on this issue, I don't think it's possible. The latest upstream version, Kotlin 1.8.0, released last month, still expects OpenJDK 6 and 7 to build! It doesn't look like Kotlin is anywhere near being buildable with a modern JDK. For example, the Kotlin compiler imports classes from the com.sun.tools package which is no longer exported since OpenJDK 9, and it doesn't seem possible to set the --add-exports options to let the Kotlin compiler access them. Kotlin has become, for the better or worse, a central piece of the Java ecosystem, mostly due to its adoption by Gradle and Android. We see an increasing number of project using Gradle with the Kotlin DSL and they are difficult to maintain. We basically have to rewrite the build system, either translating the Kotlin build files into Groovy (as was done for bootstrapping Kotlin, and for the Gradle 6 packaging attempts) or replacing them with something different (the junit5 package now uses Maven). This is extremely tedious and error prone. We can continue struggling like this for a few more years (the Kotlin packaging effort started 3 years ago already), or we can accept the ineluctable truth: we need OpenJDK 8 back into the stable distribution. Looking around, Ubuntu kept shipping the openjdk-8 package in its latest 22.04 LTS [1], Red Hat still includes it and even pushed back the EOL date by 6 months, from May 2026 to November 2026 [2]. Temurin is also aligned on November 2026 [3]. Azul [4] and Oracle [5] will support OpenJDK until 2030. So should Debian include OpenJDK 8 back, we can expect it to be supported by the Java community for the lifetime of Bookworm. How do you feel about allowing openjdk-8 in testing/bookworm with a clear mention in the release notes that it's only there for technical reasons and we make no commitment about its support? Emmanuel Bourg [1] https://packages.ubuntu.com/source/kinetic/openjdk-8 [2] https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions [3] https://adoptium.net/support/ [4] https://www.azul.com/products/azul-support-roadmap/ [5] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Re: Possibly revert eclipse-platform-runtime to version 4.23?
Hi, It looks like the missing methods have moved to org.eclipse.core.internal.runtime.AuthorizationHandler. We could either add them back to the Platform class, or patch the affected packages to call the AuthorizationHandler methods. Emmanuel Bourg Le 2023-01-22 09:40, Pierre Gruet a écrit : Hello everyone, Two weeks ago, eclipse-platform-runtime 4.26 entered testing, entailing the removal of some methods in org.eclipse.core.runtime.Platform which raised the RC bug #1028768 in its rdep svnkit. As a consequence, many reverse dependencies will get removed and not make it to Bookworm. Could we consider reverting eclipse-platform-runtime to 4.23? Given this breaking change happened so close to the freeze, we won't have time to ask the svnkit people to change their code to get rid of the problematic methods, and in my opinion the fix is not trivial. Cheers,
Re: Bootstrapping Kotlin from scratch
Le 2021-04-19 16:33, Emmanuel Bourg a écrit : I'm still making progress and I'm now at the version 0.8.409. I've started a GitHub project detailing the full build procedure from Kotlin 0.6.786 to 0.8.409: https://github.com/ebourg/kotlin-bootstrapping Follow up on the Kotlin bootstrapping project: thanks to the help of Julien Lepiller from the Guix project, it's now possible to bootstrap Kotlin 1.0.0! The full build path is detailed on GitHub and involves 55 steps. Emmanuel Bourg
Re: OpenJDK Zero interpreter: fast bytecodes
Hi Aleksey, Le 05/01/2023 à 10:16, Aleksey Shipilev a écrit : Last year, I implemented the fast bytecodes feature in OpenJDK Zero interpreter [1]. It shipped with JDK 18, and I have recently backported it to 17u. This should land in 17.0.7 in April 2023. I believe Debian runs with Zero on some architectures that do not have "server" ports. From the look at openjdk-17-jdk [2], I assume at least alpha, mips64el, mipsel, riscv64, sparc64, m68k, sh4 are running with Zero. This feature should make the builds that involve OpenJDK -- for example, building Java packages -- considerably faster. On my RISC-V board, the 17u tests are routinely >10% faster, some tests are 50% faster. This looks promising, thank you! Is it enabled in all JDKs after JDK 18 too? But there might be new bugs, so I wanted to give you a heads-up about this. -XX:-RewriteBytecodes restores the original behavior, if needed. If there are even more serious problems, we can revert the backport completely. It would be nice to know about this before the 17.0.7 release crunch in late March, though. Is there an easy way to check if e.g. bookworm can be fully re-built with latest and greatest 17.0.7 EA? Its tricky, the arch all packages are usually built and tested on amd64 only (reproducible-builds.org also rebuilds on i386, arm64 and armhf). Rebuilding the 1500+ Java packages takes at least two days on a 4c/8t 4GHz Xeon, but on m68k it's going to take ages and that would abuse a bit the shared porter boxes. Technically, this implies: - logging into a porter box (https://db.debian.org/machines.cgi) - cloning the java-common and openjdk-17 packages (using debcheckout) - rebuilding these two packages - running ratt (https://tracker.debian.org/pkg/ratt) with the .changes files of java-common and openjdk-17 - relax and grab some popcorn - cry because you forgot to use 'screen' - analyze the build logs, looking for unexpected failures compared to amd64 (reproducible-builds.org [1] has a good summary of the know build issues) Emmanuel Bourg [1] https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_maint_pkg-java-maintainers.html
Re: tomcat9 access denied /var/lib/tomcat9/conf/web.xml
Hi Alban,
Did you try this rule:
grant codeBase "file:/etc/tomcat9/-" {
permission java.security.AllPermission;
};
Emmanuel Bourg
Le 22/12/2022 à 11:05, Alban Espié-Guillon a écrit :
Hello,
I'm very new to tomcat, forgive me if I did not found my answer
elsewhere, i'm currently out of of ideas.
I'm trying to setup a standalone tomcat9 (9.0.31-1~deb10u7) on Debian
11, with security manager enabled.
I'm seeing in catalina logs the following stacktrace (full stacktrace
provided in attachment):
37 21-Dec-2022 16:12:04.587 SEVERE [main]
org.apache.tomcat.util.descriptor.web.WebXmlParser.parseWebXml Parse
error in application web.xml file at [file:/var/lib/tomcat9/conf/web.xml]
38 java.security.AccessControlException: access denied
("java.lang.RuntimePermission"
"accessClassInPackage.org.apache.tomcat.util.buf")
Disabling the security manager makes it disappear, but I don't
understand why tomcat has an issue reading
/var/lib/tomcat9/conf/web.xml, which is a simlink to
/etc/tomcat9/web.xml, and I did not edit the file as you see:
# ll /etc/tomcat9/web.xml
-rw-r- 1 root tomcat 169K Feb 5 2020 /etc/tomcat9/web.xml
I tried to add the following policy in case of it could help:
grant codeBase "file:/var/lib/tomcat9/conf/web.xml" {
permission java.security.AllPermission;
};
But the error was still logged.
I tried to report the issue to us...@tomcat.apache.org and I got the
following answser:
>The security manager is deprecated in newer versions of Java. If you
are new to Tomcat, whatever problem using the security manager is
intended to solve, I'd strongly encourage you to find an alternative
solution.
>The codebase refers to the JAR trying to read the file, not the file
the JAR is trying to read.
>I suspect the Debian distribution hasn't updated the catalina.policy
file to take account of the way Debian redistributes the Tomcat files
around the file system. If you really do want to use the security
manager, you'll need to take that up with the Debian folks.
>Mark
Re: Jetty11 in Debian
Hi Tomas, Jetty 11 is unlikely to be included in Bookworm. It may come later as a backport though. In the meantime, you can also use Tomcat 10 which will be part of the next Debian release. Emmanuel Bourg Le 13/12/2022 à 01:36, Tomas Potok a écrit : Hello! May I ask about any plans to integrate Jetty 11 (Jakarta namespaces) into Debian? In our case this seems to be the missing piece preventing us from migrating our software product to Java 17 (which itself is available in Bullseye). Many thanks, Tomas
Re: Tomcat 10 packaging
Le 28/09/2022 à 17:53, Emmanuel Bourg a écrit : Pros: - no need to create a new package, replacing tomcat with tomcat everywhere, and then wait for the NEW queue - unique packaging repository - no more transition, replacing the libtomcat-java dependency with libtomcat-java everywhere (currently about 15 packages) - no need to install tomcat and transfer /etc/tomcat to /etc/tomcat when upgrading Debian - the log files and the deployed web applications also remain at the same place There is another benefit of a versionless package: backport continuity. When the tomcat package replaces tomcat in testing/unstable, it's no longer possible to update the tomcat backport in stable (because the version must exist in testing). With a unique tomcat package we can keep updating the stable backport even after upgrading to a more recent release in testing. (this is just a note for later discussions) Emmanuel Bourg
Re: Tomcat 10
Hi Markus, Thank you for taking care of the upgrade. I have no objection to push the packaging changes to the next Debian release. Bug 965006 happened because I forgot to update the Maven rules, if the 9->10 substitution is done well the tomcat10 package will be co-installable with tomcat9. I would just suggest dropping the current tomcat10 repository on Salsa and starting with a fresh clone of the latest tomcat9 repository, from the 9.0.70 release (and with the full history preserved). Let me know if you need any help. Emmanuel Bourg Le 12/12/2022 à 00:40, Markus Koschany a écrit : Hi all, I would like to upload tomcat10 to unstable and discontinue tomcat9 for the upcoming next stable release. https://tracker.debian.org/pkg/tomcat10 I don't intend to introduce any of the changes we have previously discussed on this list for now and just move on with the usual modifications. Looking at https://bugs.debian.org/965006 Do we really want to achieve co-installability or could be a Breaks+Replaces relationship sufficient? Regards, Markus
Re: OpenJDK for Bookworm and beyond
Le 11/11/2022 à 01:46, Thorsten Glaser a écrit : 3. openjdk-11-jre-headless was used in bullseye (most people I know do this to avoid the needless metapackage), the user will end up with both because the Provides on java-runtime-headless in bullseye was unversioned but maybe they don’t (worse if the package is backported). Not installing default-jre isn't really a good idea, because once the system is upgraded to bookworm, openjdk-11-jre will not be updated anymore and a manual update to openjdk-17-jre will be necessary at some point. That said, by the time bookworm is released openjdk-11 is likely to be updated in bullseye, and the update will provide the java-runtime (= 11) dependency. This is somewhat similar to the case 2. It’s worse for sid users, especially for rare cases. Why worse? sid users will be the first to receive the updated openjdk package with the versioned java-runtime dependency. Emmanuel Bourg
Re: OpenJDK for Bookworm and beyond
Le 10/11/2022 à 22:39, Thorsten Glaser a écrit : That’s not the point. That much is true, but the point here is that the user *CAN* use Java 11, *if* they have installed it beforehand, i.e. that they are not _forced_ to upgrade. If they don’t have it installed, the default-jre will be installed anyway. This is about not forcing, possibly multiple, unnecessary JREs. Sorry but I'm still not sure to understand. Let's take tomcat9 as an example. Currently in bullseye/testing/sid it depends on: default-jre-headless | java11-runtime-headless Let's assume this is changed in bookworm to: default-jre-headless | java-runtime-headless (>= 11) Considering a tomcat9 user upgrading from bullseye to bookworm, there are two cases: 1. the default JRE was used on bullseye, default-jre-headless and openjdk-11-jre were already installed. During the upgrade, openjdk-17-jre is pulled (required by default-jre), openjdk-11-jre remains (but could be removed manually), and tomcat9 expects java-runtime-headless (>= 11) which is satisfied by both default-jre-headless and openjdk-17-jre-headless. Tomcat will run with OpenJDK 17 and all is fine. 2. an external JRE 11 was used (Oracle JDK, Azul Zulu, Amazon Corretto or a java-package generated JRE), default-jre may or may not be installed, let's say it isn't. When upgrading to Bookworm, if the external JRE doesn't provide java-runtime-headless (>= 11), then default-jre and openjdk-17-jre will be pulled. If JAVA_HOME was defined in /etc/default/tomcat9, the old JRE 11 is still used to run Tomcat, otherwise openjdk-17-jre is picked. Is this the problem you are underlining? A side note on the external JREs: - Oracle JDK doesn't provide any of the java-runtime and java-runtime-headless dependencies, it only provides jdk- which is used nowhere AFAIK - Azul Zulu provides a JRE package which satisfies java<5..n>-runtime but no the -headless variant. It also provides a JDK package with java<5..n>-runtime and java<5..n>-sdk - Amazon Corretto provides only a JDK package for Debian. It satisfies java<5..n>-runtime, java<5..n>-runtime-headless and java<5..n>-sdk, but only for the LTS versions (so no java12-* for example, only 5-8, 11 and 17). - java-package generated JDKs provide java<5..n>-runtime, java<5..n>-runtime-headless and java<5..n>-sdk. java-package was last updated 6 years ago and doesn't support Java >= 9 (#876426). Since most JDK vendors now provide .deb packages (the notable exception being Eclipse Temurin) we can probably declare it obsolete and drop it from bookworm. We can reasonably expect Azul and Amazon to adopt the new java-runtime (= n) by the time Bookworm is released. This will prevent the installation of the default JDK when the system is upgraded (but this isn't that problematic anyway). Regarding the backports, the java-runtime (>= n) dependency will have to be changed back to java-runtime, that's not a huge constraint. And I expect the openjdk security updates to introduce the java-runtime (= n) provides in stable/oldstable, so that may no be even necessary. Emmanuel Bourg
Re: OpenJDK for Bookworm and beyond
Le 10/11/2022 à 22:15, Thorsten Glaser a écrit : The application defines default-jre (>= 2:1.11) | java-runtime (>= 11) but openjdk-11-jre does not yet Provides java-runtime, only java11-runtime. This will force the user to 17. But openjdk-17-jre also provides java11-runtime. So even with: default-jre (>= 2:1.11) | java11-runtime there is no guarantee Java 11 will be used. If you want Java 11 only, you'll be able to depend on: openjdk-11-jre | java-runtime (= 11) Emmanuel Bourg
Re: OpenJDK for Bookworm and beyond
Le 31/10/2022 à 19:54, Thorsten Glaser a écrit : No, we really should not: the various JDKs also only provide java-runtime and this dependency is specifically meant to also make it possible for software to use a JRE *other* than the default (the dependency reads like default-jre (>= x) | javaX-runtime by design/for a reason). That should also be possible with the versioned virtual package: default-jre (>= 2:1.n) | java-runtime (>= n) Given how they stretch across versions and how many releases are supportable (ELTS from jessie on, *buntu from trusty on) I will argue that if and only if the openjdk-X source packages also start providing these _now_, that we can start switching to the versioned java-runtime provide in 2030, maybe later. I agree the sooner the openjdk- packages provide java-runtime (= n) the better. But I don't see the need to wait a decade before using the versioned java-runtime dependency in the packaged applications, what issue do you foresee? Emmanuel Bourg
Re: OpenJDK for Bookworm and beyond
Le 08/11/2022 à 20:49, Moritz Mühlenhoff a écrit : If the Security Team agrees I think we should continue with this strategy in Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The first OpenJDK 21 EA release will be available in December well before the freeze in March, so that fits with the Bookworm release timeline. That's fine with me (if doko continues to update it in unstable) (and if we again only have 17 as the default + 21 preview/secondary JRE). And 11 not in testing. Thank you Moritz. I've filed #1023237 to get openjdk-11 removed from testing. Emmanuel Bourg
Re: OpenJDK for Bookworm and beyond
Le 29/09/2022 à 12:00, Emmanuel Bourg a écrit : I propose to switch on October 31th for Halloween, such that the switch will unleash compatibility nightmares and runtime horrors haunting those who have ignored the bug reports for months ;) As announced last month, I've just uploaded java-common/0.73 which switches the default JRE to OpenJDK 17. The severity of the remaining bugs has been increased to serious. Also worth noting, default-jre now provides a versioned java-runtime dependency. This means we can now replace the java-runtime dependencies with java-runtime (>= n). Happy Halloween! Emmanuel Bourg
Re: Status of antlr4 in Debian
Hi Pierre, Le 26/10/2022 à 16:47, Pierre Gruet a écrit : My question is: apart from time to work on the package, is there any reason we should remain with antlr4 4.7.2 in Debian although 4.11.1 has been released upstream? Yes, antlr is the kind of package you don't want to upgrade, because it's likely to break another package and debugging a language grammar without upstream consent is really the last thing you want to do. So as long as it works, I'm not touching it :) The safe way to upgrade antlr4 is to: - check the version used by the reverse dependencies - if the lowest version used is above the package version, then upgrade - if the version you need is still higher, checkout the project, update the antlr dependency and run the upstream test suite (not from the Debian package build since tests are sometime disabled) - if all goes well, upgrade the antl4 package - if if not, clone the package to keep the previous version (we had to do this with antlr 3.2) Good luck! Emmanuel Bourg
Re: Tomcat 10 packaging
Le 29/09/2022 à 15:06, Markus Koschany a écrit : While less packaging work is always a plus, I don't mind copy and pasting the existing debian sources. Also the wait in the NEW queue is rather negligible if the upload is done way ahead of the stable freeze as it was done with Tomcat 10. I agree, it's nice to ease the packaging work, but the deciding factor should be the user experience. Currently, upgrading Tomcat in Debian consist in: - install tomcat - move the content of /var/lib/tomcat to /var/lib/tomcat (especially the lib directory containing the JDBC drivers) - move the log files from /var/log/tomcat to /var/log/tomcat - copy and adapt the configuration files from /etc/tomcat to /etc/tomcat - uninstall tomcat A unique package would reduce this procedure to the configuration update step. The same result could be achieved by having versioned packages conflicting with each other. For example tomcat10 would use versionless paths (/etc/tomcat, /var/lib/tomcat, /var/log/tomcat), and installing tomcat11 would trigger the removal of tomcat10, while reusing the same paths. On the packaging side, we could mimic the openjdk package and generate the versioned packaging files automatically. There are often breaking changes between major Tomcat versions and users can't expect that their applications will seamlessly work when they upgrade their tomcat packages to newer major releases. So this is a point where I find two tomcat packages in unstable or at least experimental very useful. You also have to keep in mind that Ubuntu and other distributions just copy the package and release more frequently. With a versionless tomcat package it could easily happen that there are major regressions in between two Debian stable releases which would directly hit Ubuntu and co users because they release more often. While we would fix those bugs in unstable eventually, other users had to deal with those issues in a stable release. A sudden and automatic upgrade from 9.x to 10.x may be surprising for them. It's interesting to consider the Debian derivatives side. For Ubuntu I don't think this will change the situation that much. They already apply their own security fixes anyway since their stable Tomcat versions aren't aligned with ours. And major updates in Debian won't trigger a major update in the stable Ubuntu releases. At the moment I would play it safe for Debian 12 and go with src:tomcat10. However we could think about introducing a libtomcat-default-java package which always points to the latest major Tomcat version in Debian. Thus we could avoid updating our r-deps for every new release, similar how we deal with the JDK. The default libtomcat-java package is a good idea. Thank you for sharing your thoughts! Emmanuel Bourg
Re: OpenJDK for Bookworm and beyond
Le 29/09/2022 à 14:06, Thorsten Glaser a écrit : Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping of some packages that can't build directly with the latest JDK (more specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK 11 in unstable after the transition to OpenJDK 17. Who’s going to maintain that? I don't think the maintenance is a concern, we only have to ensure it keeps building in sid. It's just to compile stuff in sid, not to run critical production systems. So I think we should keep 11 around *only* if someone (could be Doko, could be someone else) commits to maintaining it. If nobody does, Scala and Kotlin are SOL. I don't mind for Scala, but Kotlin can't be ignored unfortunately. Its integration into Gradle makes it an essential part of the Java ecosystem. Emmanuel Bourg
OpenJDK for Bookworm and beyond
Hi all, OpenJDK 11 has been the default JDK in the last two releases, and a more recent version for Bookworm is highly expected. The current LTS version is OpenJDK 17, released in September 2021 one month after Bullseye. The next LTS version will be OpenJDK 21 (the LTS cadence has been shortened from 3 to 2 years) to be released in September 2023, again shortly after the Debian release which can be expected in July or August 2023 if the rhythm of the previous releases is kept. This scenario is likely to continue in the future since the Debian and Java releases are now synchronized on the same 2 years cycle. The first point is to plan when we'll switch the default JDK to OpenJDK 17. The transition has progressed well, with 113 bugs fixed already, but there are still 36 bugs left to fix [1] (this is a much smoother transition than the jump from OpenJDK 8 to 11 where we had to deal with over 500 bugs). There are no critical issues, the build tools and the main packages all work fine. So I suggest that we switch without waiting for the remaining bugs to be fixed. I propose to switch on October 31th for Halloween, such that the switch will unleash compatibility nightmares and runtime horrors haunting those who have ignored the bug reports for months ;) That'll leave sufficient time to address the remaining issues before the release. Another point is how to deal with the next LTS, OpenJDK 21. For Bullseye the Security Team agreed to ship OpenJDK 17 as a "technology preview" in addition to OpenJDK 11, with no promise it would be as well supported as OpenJDK 11. In practice, thanks to Matthias and Moritz prompt uploads, the OpenJDK 17 updates landed in stable-security on average 8 days after the GA release, which is as good as the OpenJDK 11 updates. Popcon reports 4524 installs of OpenJDK 17 with a steady growth, and 51690 installs of OpenJDK 11. Assuming OpenJDK 17 users also have OpenJDK 11 installed that's about 8% of the Java users interested in the latest LTS JDK. This is a significant share of users and it shows the extra effort involved in maintaining an additional JDK is worth it. If the Security Team agrees I think we should continue with this strategy in Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The first OpenJDK 21 EA release will be available in December well before the freeze in March, so that fits with the Bookworm release timeline. Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping of some packages that can't build directly with the latest JDK (more specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK 11 in unstable after the transition to OpenJDK 17. Emmanuel Bourg [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-java@lists.debian.org
Tomcat 10 packaging
Hi all, For Debian Bookworm I'd like to replace Tomcat 9 with Tomcat 10. But this time instead of introducing a "tomcat10" package, I wonder if we could instead create a version-less "tomcat" package and keep it for the next major releases. Pros: - no need to create a new package, replacing tomcat with tomcat everywhere, and then wait for the NEW queue - unique packaging repository - no more transition, replacing the libtomcat-java dependency with libtomcat-java everywhere (currently about 15 packages) - no need to install tomcat and transfer /etc/tomcat to /etc/tomcat when upgrading Debian - the log files and the deployed web applications also remain at the same place Cons: - the unique repository will probably have multiple upstream branches when Tomcat upgrades are uploaded to oldstable as part of the LTS, this may be tricky with gbp - if the new configuration files are incompatible with the previous format, upgrading Debian may break the Tomcat instance. Either it no longer starts, or some configuration elements or features no longer work. With separate packages, the system upgrade is unlikely to break Tomcat, but the user may forget to upgrade it and will keep an unsupported instance that is no longer receiving security updates. What do you think? Emmanuel Bourg
Re: wrong information in the manifest files of eclipse-platform-runtime
Hi Sudip, Le 19/09/2022 à 17:47, Sudip Mukherjee a écrit : While investigating #1010983, I noticed that the manifest files of eclipse-platform-runtime mentions that it needs javax.annotation version="1.3.5", but in Debian we have version 1.3 as supplied by libgeronimo-annotation-1.3-spec-java. Is this causing an issue somewhere? Unless anyone has any objection I will like to do a team upload with the attached patch fixing the manifest files. Its only a change in the manifest file to add a range of 1.3 to 1.3.5 for javax.annotation and remove javax.annotation from "Require-Bundle". What about changing the version in libgeronimo-annotation-1.3-spec-java instead? The Eclipse source packages publish 120+ binary packages, if we start tweaking manually their OSGi metadata to fit what we have in Debian this will turn into a maintenance nightmare. Emmanuel Bourg
Re: javacc5 issues
Hi Sebastiaan, Le 18/05/2022 à 09:24, Sebastiaan Couwenberg a écrit : javacc5 is not built on the buildds preventing testing migration: https://qa.debian.org/excuses.php?package=javacc5 This is why it's good practice to upload NEW packages to experimental, which can then be followed-up with a source-only upload to unstable. Two consecutive uploads to unstable is fine too. The git repo is empty: https://salsa.debian.org/java-team/javacc5 I pondered keeping the javacc5 package as a branch of the javacc repository, but I've eventually pushed it to a new repository. The watch file doesn't limit to 5.x releases: https://sources.debian.org/src/javacc5/5.0-10/debian/watch/ Yes, because there is no 5.x release tagged in the upstream repository :( Emmanuel Bourg
Re: maven-*-helper JAR placement seems to contradict Java policy
I vaguely remember that replacing a symlink with a file during a package update was causing some issues (i.e. the target is updated but the symlink isn't replaced). If that's still true I'd refrain from applying this change to maven-debian-helper. The slight deviation from the Java policy isn't worth the trouble, and I'd instead amend the policy to accept what has been done de facto for years. Emmanuel Bourg
Bug#1001463: java-policy: Please retitle to "Java Policy for Debian"
Le 10/12/2021 à 15:20, Felix Lechner a écrit : Lintian cites your manual as supporting documentation for several tags. [1][2][3][4][5][6][7][8] Such references help users when grasping the conditions that provoke Lintian's recommendations. In our view, your policy [9] should be named "Java Policy for Debian." "Debian Policy for Java" or "Java Policy for Debian", which one is correct? Emmanuel Bourg
Re: maven-*-helper JAR placement seems to contradict Java policy
Le 15/10/2021 à 15:17, Andrius Merkys a écrit : > Not sure though what is the impact of this policy inversion. Most of > Java-related software seems to read both regular files and symbolic > links transparently. There isn't much impact, both styles are fine in my opinion. Emmanuel Bourg
Re: packaging Go runtime for ANTLR4
Le 2021-07-28 17:08, tony mancill a écrit : I don't disagree with Emmanuel's statements about the importance of ANTLR and why it is helpful to maintain separation. However, I don't think introducing a separate source package each language ecosystem is necessarily best for Debian. It's not optimal for the number of source packages in the distribution, but it's optimal wrt the human resources available to maintain the packages, and that's much more important than a few saved megabytes on the APT repository mirrors. With separate source packages, I'm confident that an issue with the Go/Python/C++ compiler and build tools won't hinder the work on the Java library. Bootstrapping ANTLR4 wasn't a trivial task (there was circular self dependencies) and I don't think I would have been able to do it if I had to care about the other languages. It causes additional work for the Security team when in the event there vulnerabilities. AFAIK there was no CVE reported for ANTLR so far, so separate packages do not induce an increased security maintenance in this case. It potentially confuses users (and Debian developers) by creating a distinction that does not exist upstream. I'm thinking about documenting in debian/README.source why the languages are isolated in separate packages, this isn't the first time this question arises. It also means that we will release with different versions of ANTLR for different languages, which feels very "non-distro" to me. (What happens if the version of the ANTLR parser for language X is subtly incompatible with language Y, and a user runs a system on Debian that requires both bindings?) We already have several versions of ANTLR for Java packaged (2.7.7, 3.2, 3.5.2 and 4.7.2). If a new version of ANTLR creates regressions, we just clone the package to preserve the old version. That's the only sane solution, because you really don't want to test, debug and fix grammars with an incompatible version of ANTLR, that's the reponsability of the upstream developers. Emmanuel Bourg
Re: packaging Go runtime for ANTLR4
Le 2021-07-28 21:36, Nilesh Patra a écrit : Thoughts? I think you are trying to find a solution for a problem that doesn't exist. Source packages per language isn't an issue that needs to be fixed. antlr4-cpp-runtime works fine, python3-antlr4 works fine, libantlr4-runtime-java works fine, the packages are independent and are free to evolve as needed without impacting the others. An unified package will only bring pain and tears, and distract us from more important topics (like the OpenJDK 17 transition, the Kotlin packaging or the Gradle upgrade). Emmanuel Bourg
Re: packaging Go runtime for ANTLR4
Hi Peymaneh, Le 2021-07-27 10:09, Peymaneh Nejad a écrit : Is it intended or wished for that additional runtimes other than Java are packaged in seperate source packages Yes it is, for several reasons: - The Java Team doesn't have the time and skills to maintain properly a multi-language package like ANTLR. The Java part is sufficiently complex on its own, we'd rather not have to care about the other languages. - Different language ecosystems often require distinct and slightly incompatible versions of ANTLR. - Handling several languages in the same package makes upgrades and regression testing much more difficult. - ANTLR is a core package of the Java ecosystems, including more languages increases the dependency tree of the Java packages and makes the bootstrapping harder. So it's preferable to have a clear separation of responsability with different source packages, each language team having the freedom to maintain its version as needed without impacting the others. Emmanuel Bourg
Re: remove tomcat8 from Debian experimental? WAS: Re: Bug#925454: RM: tomcat8 -- ROM; Replaced by tomcat9
Le 26/07/2021 à 05:03, Paul Wise a écrit : > Since tomcat9 was released in buster a long time ago, > is it now time to remove tomcat8 from Debian experimental? Yes no objection. Emmanuel Bourg
Re: upload of libstringprep-java to NEW
Le 09/05/2021 à 14:51, Sudip Mukherjee a écrit : >> We both picked the same binary name, but different source names. Do >> you (or the java team) have a preference for either of these names? > > iiuc, based on Debian Java policy the source should be 'stringprep' > and the binary package should be 'libstringprep-java'. There is no absolute rule but personally I tend to prefer the upstream project name for the source package (if it isn't too generic or confusing). Emmanuel Bourg
Re: Kotlin: looking for a DD to review/upload
Le 2021-05-07 14:55, Phil Morrell a écrit : I disagree on the version numbering. As described in README.source and the commit messages for the watch file, this is the standardised format for MUT support in uscan, admittedly more often seen in javascript. There is an alternative, checksum '1.3.31+~cs1.11.13', but that does not support uscan --download-current-version which is needed until we can bump them all to their latest tags. If the '+' is required, maybe mangling the kotlin version would work? Something like this for example: 1.3.31~bootstrap+~cs1.11.13 Emmanuel Bourg
Re: Kotlin: looking for a DD to review/upload
Le 07/05/2021 à 10:12, Matthias Klose a écrit : > With that, I can build a deb. However the deb has *no* dependencies. I've started reviewing the package and I stumbled on this issue as well, the kotlin .deb should indeed declare its dependencies, otherwise the symlinks in /usr/share/kotlin/kotlinc/lib/ are broken and kotlinc fails with a FileNotFoundException. I also agree with Matthias on the version, the '+' could be removed so we can upload a clean 1.3.31 version later. lintian reports unused paragraph in debian/copyright but that's fairly minor. The paragraphs with the same license can be merged to simplify the layout. The are also two (unused?) android-support-v4.jar files that could be removed from the source package. Did you start working on packaging kotlinx coroutines and atomicfu separately yet? That will be the next step once kotlin is uploaded. Also, are all the jar files downloaded by debian/bootstrap rebuilt? None is copied directly into the stage 2 .deb, right? Emmanuel Bourg
Re: OpenJDK 8 archive re-entry
Le 22/04/2021 à 02:51, Thorsten Glaser a écrit : > unfortunately not yet. They’re probably depriorising sid in times of > freeze, but the grace period for not bothering them is probably over > by now so if ebourg doesn’t want to prod them now, I can do this but > nobody else should so they don’t get annoyed. > > Emmanuel, will you or should I? Please do. That said, we may also upload kotlin now even if openjdk-8 is still in the queue. As long as they enter sid in the right order, that's fine. In the worst case kotlin will be accepted before openjdk-8 and simply prevented from transitioning to testing until openjdk-8 arrives. > I’m not exactly sure this method is the preferred one, especially > given ebourg’s alternative bootstrapping path from source is > progressing admirably. (Not to throw away that work though, it’ll > become useful nearer to that bootstrapping processes end.) To be honest, I still have a very long way to go and I'm not even sure to succeed (I spent a full day dealing with 2 months worth of commits, and I'm only at the Q2 2015 code). They've done a great work, I don't think my approach replaces theirs, at best I may reconnect with them to provide the bootstrap compiler, or certify later that both approaches produce the same binaries. Emmanuel Bourg
Re: Bootstrapping Kotlin from scratch
Le 06/04/2021 à 09:40, Emmanuel Bourg a écrit : > There are missing symbols when building the first 0.7.x tag, I'm still > working on it. I'm still making progress and I'm now at the version 0.8.409. I've started a GitHub project detailing the full build procedure from Kotlin 0.6.786 to 0.8.409: https://github.com/ebourg/kotlin-bootstrapping Emmanuel Bourg
Re: New source package httpcomponents-client5
Le 14/04/2021 à 16:34, Markus Koschany a écrit : > there anything against packaging the 5.x series as src:httpcomponents-client5? +1 for src:httpcomponents-client5, the new version is incompatible with the previous one, and has different Maven coordinates, so the new package makes sense. Thank you for the work. Emmanuel Bourg
Re: No CI/CD settings in packages of Debian Java team?
Le 16/04/2021 à 15:13, Andreas Tille a écrit : >> repos in java-team have pipelines disabled by default. > > Is there any good reason for this setting? When Salsa was set up we were instructed no to overuse the CI system, I don't know how this has evolved now. Personally I think this isn't very useful, it's more a waste of resources since I've already built the packages locally before pushing the changes to Salsa. In an era of digital sobriety I prefer to keep it turned off. And it's also a source of spam on the IRC channel. Emmanuel Bourg
Re: Bootstrapping Kotlin from scratch
Le 02/04/2021 à 22:56, Emmanuel Bourg a écrit : > Step 5: how to build Kotlin 0.6.2350 ??? I have the next steps, the decompiler code was refactored in the SDK in the commit f6c6bec7361fba61ecb3aa955e4145a789d4ed97, and this wasn't used until Kotlin 0.6.2443. Kotlin 0.6.2350 builds with Kotlin 0.6.2338 and the SDK at the preceding commit a28195118431b514179fffe75c9ef5ed1247d6a6. And it works up to Kotlin 0.6.2389. Starting with Kotlin 0.6.2407 two new jar files are required, kotlin-jdk-annotations.jar and kotlin-android-sdk-annotations.jar, they do no contain any code, just xml files defining the JDK methods that are null safe. They can be downloaded from http://teamcity.jetbrains.com (the URL are in the update_dependencies.xml file). With these files the build climbs to Kotlin 0.6.2415. Kotlin 0.6.2422 fails at the "builtins" phase, adding kotlin-runtime.jar to the classpath fixes the issue. Kotlin 0.6.2433 requires a new version of the SDK, the latest from the 134 line (commit 1168c7b8cb4dc8318b8d24037b372141730a0d1f) works fine. There is also a minor nullable type definition to fix in JavaToKotlinTranslator.kt. It continues up to Kotlin 0.6.2500 (except 0.6.2463 which was a short lived branch). Kotlin 0.6.2516 fails because the jet.* packages were renamed to kotlin.*. It turns out the bootstrap compiler must be built with the bootstrap.build.no.tests=true parameter. This embeds the runtime into the compiler jar and allows it to build a more recent, incompatible compiler/runtime. I picked Kotlin 0.6.2451 as the bootstrap compiler to build Kotlin 0.6.2516, then built Kotlin 0.6.2516 with itself and bootstrap.build.no.tests=false. The resulting compiler is able to build Kotlin 0.6.2517. And this is the end of the 0.6.x line. There are missing symbols when building the first 0.7.x tag, I'm still working on it. Emmanuel Bourg
Bootstrapping Kotlin from scratch
sure why but since it is optional I disabled it too. In Kotlin 0.6.1910 the following error appears: [javac2] ERROR: /home/ebourg/kotlin-from-scratch/kotlin.upstream/compiler/frontend/src/org/jetbrains/jet/lang/evaluate/OperationsMapGenerated.kt: (104, 64) Unresolved reference: compareTo I worked around this by commenting the offending line. The process continues up to Kotlin 0.6.2052 and this is the end of the road for Kotlin 0.6.1364 as the bootstrap compiler. The next version 0.6.2063 has unresolved references in compiler/builtins-serializer/src/run.kt. Kotlin 0.6.2052 becomes the new bootstrap compiler and we continue. Kotlin 0.6.2052 + SDK 133 builds Kotlin up to the version 0.6.2107. We switch again the bootstrap compiler. Kotlin 0.6.2107 + SDK 133 works up to Kotlin 0.6.2338. And now start the real troubles with Kotlin 0.6.2350. It breaks because this is the first version using the SDK 134, but there is no tag nor branch for the SDK 134. The 135 branch doesn't work due to the switch to ASM 5 (and Kotlin didn't switch to ASM 5 until the version 0.7.391). I've located where the version of the SDK changed from 134 and 135 (commit 4bb7296c2747fa73898247da03e7c9923935cc61) and I've built the SDK just before this point. The Kotlin build fails with this error: runtime: [echo] Cleaning /home/ebourg/kotlin-from-scratch/kotlin.upstream/dist/classes/runtime [mkdir] Created dir: /home/ebourg/kotlin-from-scratch/kotlin.upstream/dist/classes/runtime [java] exec() finished with INTERNAL_ERROR return codeEXCEPTION: java.lang.IllegalArgumentException: Missing extension point: com.intellij.psi.classFileDecompiler in area null [java] at com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.getExtensionPoint(ExtensionsAreaImpl.java:373) [java] at com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.getExtensionPoint(ExtensionsAreaImpl.java:37) [java] at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:110) [java] at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:98) [java] at com.intellij.openapi.extensions.ExtensionPointName.getExtensions(ExtensionPointName.java:48) [java] at com.intellij.psi.compiled.ClassFileDecompilers.find(ClassFileDecompilers.java:88) [java] at com.intellij.psi.ClassFileViewProviderFactory.createFileViewProvider(ClassFileViewProviderFactory.java:33) [java] at com.intellij.psi.impl.file.impl.FileManagerImpl.createFileViewProvider(FileManagerImpl.java:202) [java] at com.intellij.psi.impl.file.impl.FileManagerImpl.findViewProvider(FileManagerImpl.java:160) [java] at com.intellij.psi.impl.file.impl.FileManagerImpl.findFile(FileManagerImpl.java:328) [java] at com.intellij.psi.impl.PsiManagerImpl.findFile(PsiManagerImpl.java:188) I have no idea how to fix this. In a last attempt I tried to build Kotlin 0.7.391 with Kotlin 0.6.2338 + SDK 135 but it failed. This is where the story halts. To summarize: Step 1: build Kotlin 0.6.786 with a patched SDK 133 Step 2: build Kotlin 0.6.1364 Step 3: build Kotlin 0.6.2052 Step 4: build Kotlin 0.6.2107 (good up to Kotlin 0.6.2338). Step 5: how to build Kotlin 0.6.2350 ??? If someone figures out the next step, or has any hint about the last error, please ping me :) Emmanuel Bourg
Re: Sixth Android Tools Team Monthly Meeting
Le 24/03/2021 à 23:03, Thorsten Glaser a écrit : > Hmmm, considering… does this also mean I’ll need to figure out > how to bootstrap it using JDK 11 as bootstrap compiler? Probably… > anyway, this will take a while. Good point, if it doesn't build with OpenJDK 11 I suggest building with the latest openjdk-8 package from snapshot.debian.org and doing a binary upload. Emmanuel Bourg
Re: Sixth Android Tools Team Monthly Meeting
Le 24/03/2021 à 22:13, Thorsten Glaser a écrit : > I can certainly bring it back to unstable, built with > gcc 10, if there are no major issues involved in making > it build with GCC 10, if there is interest. We are certainly doomed without openjdk-8 in unstable, we really need it back. Emmanuel Bourg
Re: Sixth Android Tools Team Monthly Meeting
Le 24/03/2021 à 21:29, Sunil Mohan Adapa a écrit : > openjdk-8 appears to been removed from unstable recently[1][2]. Sorry I misunderstood your message, I didn't realize it got kicked already :( Emmanuel Bourg
Re: Sixth Android Tools Team Monthly Meeting
Le 24/03/2021 à 19:33, Sunil Mohan Adapa a écrit : > As one of the items on the agenda, I would like to us to discuss how to > deal with the removal of openjdk-8 from Debian[3]. openjdk-8 has already been removed from the Debian stable releases. It's still in unstable to help with the bootstrapping of Kotlin. Until the kotlin package builds fine with openjdk-11 it's premature to consider the removal of openjdk-8. Emmanuel Bourg
Re: Packaging Gradle
Le 12/03/2021 à 21:59, Raman Sarda a écrit : > Is there a way we can go about updating gradle using some another way? I > have worked on major part of the update last summer but seems we can't > go any further without gradle enterprise plugin. Are you sure this plugin is required? My understanding is that it merely provides build time improvements and some code/build reports. I guess it could be simply disabled. Emmanuel Bourg
Re: Setting JAVA_HOME
Le 28/02/2021 à 15:26, Mechtilde a écrit : > at most of my Java packages i set > > export JAVA_HOME := /usr/lib/jvm/default-java > > in debian/rules You can remove it from debian/rules, unless you want to build with a specific JRE (for example Java 8 when Java 11 is the default) that's useless. Emmanuel Bourg
Re: tomcat9 bugfix
Hi Thorsten, Le 2021-02-13 06:42, Thorsten Glaser a écrit : I’ve just committed a rather important bugfix for tomcat9 to git (administrators no longer could read the logfiles). Good catch. This was fixed in tomcat9/9.0.37-1 last summer but sysvinit systems without systemd-tmpfiles are still affected. Do you wish to upload this yourself or should I? I'll upload it with the next monthly update. Emmanuel Bourg
Re: OpenJDK 17 for bullseye-backports
Le 07/02/2021 à 00:43, Thorsten Glaser a écrit : > Users will probably ignore that and use it anyway. It would have been > good if it could be included and kept up to date, but that’s doubling > of efforts, not worth the hassle, I wonder if the effort of maintaining OpenJDK 17 in bullseyes could be significantly reduced by automating the process. The upstream LTS branch is going to be extremely stable, the releases are clearly tagged in the upstream repository, and the Debian packaging is very flexible and compatible with several Debian releases. It should be possible to fetch the upstream security updates, rebase the Debian packaging and upload the package automatically. That wasn't possible a few years ago, I vaguely remember Matthias telling me that up to Java 8 the security updates were not easily identifiable in the upstream repository (if available at all), and that some architectures required changes cherry picked from alternative repositories. If we can't rely on the main upstream repository to support all the Debian architectures, maybe we can restrict the automatic updates to those supported upstream (at least amd64 and i386, maybe arm64 too). > plus it would mean people would expect Java packages shipped with bullseye > to work with 17, which isn’t the case (plus shipping only one makes > iteasier/clearer). The compatibility of the Java packages in bullseye with OpenJDK 17 is rather good. I ran a mass rebuild this week and the success rate was around 85%. There were many trivial build issues (javadoc errors, language level to change from 6 to 7) so the runtime compatibility is likely to be higher. I've filed the issues in the BTS: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-java@lists.debian.org Emmanuel Bourg
Re: OpenJDK 17 for bullseye-backports
Le 02/02/2021 à 19:04, Adrian Bunk a écrit :
> bullseye-backports would be the perfect place for providing
> OpenJDK 17 to users on bullseye.
>
> OpenJDK can only be built with the previous version, and doing a
> 11 -> 12 -> 13 -> 14 -> 15 -> 16 -> 17
> bootstrap for 9 release architectures in bullseye-backports would be
> quite painful.
I did that to backport openjdk-11 to stretch and that was indeed
tedious. It consisted in uploading openjdk-{9,10,11} to
stretch-backports, not as separate packages but sequentially as the
final openjdk-11 package. At each step I had to wait for the builders to
complete the build before uploading the next version. And it took a lot
of time on some architectures (especially mipsel if I remember well, the
backport queue is processed with a lower priority and the builder is
constantly used for higher priority builds).
The whole backport was completed in 2 weeks. I guess a similar process
to bootstrap openjdk-17 from openjdk-11 would take 1 month.
> Shipping without any security support either OpenJDK 16 or a pre-release
> of OpenJDK 17 in bullseye only for avoiding an OpenJDK bootstrap in
> bullseye-backports would sound very wrong.
I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad
idea. Shipping OpenJDK 17 is worth considering though.
> My suggestion:
>
> No OpenJDK other than 11 is shipped in bullseye.
>
> If at the time of the bullseye release openjdk-17 in unstable is ready
> to migrate to testing except for the freeze, this means that:
> 1. it will migrate at the first migration of bookworm, and
> 2. the binaries will be installable on all architectures in bullseye
>
> The bootstrap could then be avoided by verbatim copying of this
> openjdk-17 sources and binaries for all architectures from bookworm
> to bullseye-backports.
>
> Subsequent updates of openjdk-17 in bullseye-backports would then follow
> the normal backports rules.
If openjdk-17 can't be shipped in bullseyes even with prominent warnings
that it's unsupported, then this sounds like a good idea.
Emmanuel Bourg
Re: Packages take over for the Java Team
Hi Baptiste, Le 25/01/2021 à 20:46, Baptiste Beauplat a écrit : > The following packages have Chris as a Maintainer and could be taken > over by the Team: > > - geronimo-ejb-3.0-spec > - geronimo-j2ee-connector-1.5-spec > - geronimo-jms-1.1-spec > - geronimo-jpa-3.0-spec Thank you for spotting this. I'll take care of them (except geronimo-jpa-3.0-spec which was removed 3 years ago). > And the following have Uploaders references to them (including the > packages listed above): > > - dnsjava > - euca2ools > - geronimo-interceptor-3.0-spec > - geronimo-jacc-1.1-spec > - libaxiom-java > - netty These packages (minus euca2ools) are already handled by the Java Team, we'll change the uploaders in the next uploads. Emmanuel Bourg
Re: gs-collections vs eclipse-collections
Hi Vincent, libgs-collections-java is still used to build libreactor-core-java. eclipse-collections is incompatible with gs-collections because the package name was changed to org.eclipse.collections. For these reasons I suggest to keep the gs-collections package for now, and create a new eclipse-collections source package building libeclipse-collections-java. The gs-collections repository on Salsa can be cloned and used as a starting point for the new package. Emmanuel Bourg Le 07/01/2021 à 01:56, Vincent Prat a écrit : > Dear all, > > The latest version of NatTable (2.0.0) depends on Eclipse Collections > (https://www.eclipse.org/collections/). > Originally, it was called GS Collections, and was renamed when it > migrated to the Eclipse Foundation. > GS Collections is present in Debian (as gs-collections: > https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections. > > Should we package Eclipse Collections as a separate project (in which > case I will submit an ITP bug), or update and rename the existing package? > For your information, the package gs-collections has no reverse > dependency and has not been updated since September 2017. > > Best wishes for the new year > Vincent >
Re: Help with removing the Jruby build-dependency in mustache-java (#979845)
Le 12/01/2021 à 19:59, Louis-Philippe Véronneau a écrit : > I spent an hour looking at the changes 0.9.7 introduces, and I feel it > would be more than a "small, targeted fixes" (the Soft-Freeze has > started!). Maybe someone with more Java skills than I would be confident > the update wouldn't break things right and left, as I'm not. Hi Louis-Philippe, I've updated mustache-java to the version 0.9.1, it no longer depends on jruby. Emmanuel Bourg
Re: maven 3.6.3, please?
Le 15/01/2021 à 10:26, Sudip Mukherjee a écrit : > I think we will also need to update libmodello-maven-plugin-java, > libmodello-java and libplexus-utils2-java in backport to update maven. > Do you see any problem with that? Hi Sudip, I don't remember but I think the versioned dependencies are properly set to ensure a smooth backporting. Go ahead, if it breaks I'll look into it. Emmanuel Bourg
Re: problem with swt4-gtk update
Le 29/12/2020 à 01:46, Sudip Mukherjee a écrit : > So, I will wait for any other objection or Ack till tomorrow night and > then upload. Thank you for spotting issue. Please go ahead and upload the fix. Emmanuel Bourg
Re: List of consultants focusing on Debian packaging for Java?
Le 08/12/2020 à 12:24, Pirate Praveen a écrit : > I maintain gitlab using https://wiki.debian.org/FastTrack > > gitlab has a long dependency tree and very fast release cycle. It gets > new releases every month and security updates are given only for 3 months. > > If more people find this approach useful, this could become official > some day. This could be very useful to get openjdk-8 in buster. Emmanuel Bourg
Re: List of consultants focusing on Debian packaging for Java?
Le 07/12/2020 à 15:33, Thorsten Glaser a écrit : > Does maven-debian-helper handle multi-module projects (where some of > the modules depend on some of the other modules to be built as part > of the project) nowadays? That was the biggest problem, back when I > tried to package something… Yes it does (for example jetty9, javamail or maven itself) but there are edge cases that require some tweaking of the poms (typically when the project uses OSGi bundles and with convoluted submodule layouts). Emmanuel Bourg
Re: List of consultants focusing on Debian packaging for Java?
Le 07/12/2020 à 11:38, Antonin Delpeuch (lists) a écrit : > Keep the suggestions coming, this is super useful! Another point to keep in mind, if you build and distribute your own .deb or Flatpak package you keep the control on the release schedule. Using jdeb you could publish your first package in a couple of weeks. Going the official Debian archive route takes a lot more time and you're tied by the Debian release schedule and update policy. If the application is mature and stable it works well, but it can become frustrating if it evolves quickly. Emmanuel Bourg
Re: List of consultants focusing on Debian packaging for Java?
Le 06/12/2020 à 21:46, Antonin Delpeuch (lists) a écrit : > Ok! I would personally love to be able to get involved, but I think it > is pretty clear that it would be pretty risky to start such a big > packaging project on my own with no prior experience. So I'll definitely > follow up offlist. Hi Antonin, Did you consider building a .deb package with jdeb [1] ? It's an alternative that involves much less work than uploading to the Debian repository. For a complex and very specialized software like OpenRefine that might be more suitable. This list can still give some guidance on how to structure the package and ensure it plays well with the Java ecosystem in Debian. Emmanuel Bourg [1] https://github.com/tcurdt/jdeb
Re: [RFS] libjaba-client-java
Hi Pierre, I think the Maintainer field of debian/control should reference the Java Team. Emmanuel Bourg On 14/11/2020 07:37, Pierre Gruet wrote: > Hi, > > I have worked on libjaba-client-java, with the further aim to revive > jalview in Debian. Would you mind either reviewing [0] or giving me DM > rights? > > > dcut dm --uid "Pierre Gruet" --allow libjaba-client-java > > > Thanks a lot, > Pierre > > [0] https://salsa.debian.org/java-team/libjaba-client-java >
Re: [RFS] libapfloat-java
Hi Pierre, There is a minor mistake with the email address of the Java team in debian/control: pkg-java-maintain...@alioth-lists.debian.net should be replaced by: pkg-java-maintain...@lists.alioth.debian.org Emmanuel Bourg On 03/11/2020 07:46, Pierre Gruet wrote: > Hi, > > I have made the initial packaging of apfloat for Java, which lies in its > Salsa repository [0]. > > If time permits, could someone please have a look at it and sponsor if it's > OK? > > Warm thanks in advance, > > Pierre > > > [0] https://salsa.debian.org/java-team/libapfloat-java >
Re: morfologik-stemming update
On 21/10/2020 23:55, Sudip Mukherjee wrote: > Any ideas please? > I think the only possible way now is to package > morfologik-stemming_2.1.6 as a new package. Yes that's the way to go (unless you have an good understanding of the stemming API and are able to patch Lucene 4 and test it thoroughly). Emmanuel Bourg
Re: jni launcher library
Le 04.10.2020 23:02, Sudip Mukherjee a écrit : I have modified d/rules and added the version in 'dh_gencontrol' and you can see it in sudip/jni branch. It now builds libequinox-executable-jni_3.8.900+eclipse4.17-2_amd64.deb package. Not sure if there is some simple way to extract the version from feature.xml file and use. Yes there is, we can use xmlstartlet: xmlstarlet sel -t -v '//feature/@version' features/org.eclipse.equinox.executable.feature/feature.xml I've pushed the modification to the sudip/jni branch with a few other changes. Emmanuel Bourg
Re: jni launcher library
Le 02.10.2020 18:14, Sudip Mukherjee a écrit : Thanks. I did it in a fairly simple (hacky) way and have pushed to 'sudip/jni' branch for you to have a look first. It is now building 'libequinox-executable-jni_4.17-2_amd64.deb' and 'libequinox-executable-jni-dbgsym_4.17-2_amd64.deb' for this change. Can you please have a look at the branch when you get some time.. I think the version should be picked from the feature.xml file, so the package would have the version 3.8.900+eclipse4.17-2. Emmanuel Bourg
Re: jni launcher library
Le 29.09.2020 18:10, Sudip Mukherjee a écrit : The launcher library code is part of "equinox-framework" and lives at 'features/org.eclipse.equinox.executable.feature/library/gtk' but its not built and packaged. I get the splash screen working when I build it and use it as a launcher library. Just wanted to confirm if you left it out intentionally? Is there any problem if I add it as a package name "libequinox-launcher-jni" ? No objection to add the jni package, but be careful with the version of the binary package, it has to match the version of the associated -java package. The version of the eclipse packages is heavily tinkered to use the OSGi bundle version instead of the tag version. So you'll need a tweak in debian/rules for the jni package. I can get a look before you upload if you aren't sure to do it right. Emmanuel Bourg
Re: Removing netbeans
Le 30.09.2020 18:34, Markus Koschany a écrit : I wanted to move the idea forward and just pushed a new update of netbeans to Git. Currently there is only one reverse-dependency in Debian, openstereogram, that requires libnb-absolutelayout-java. I have simplified netbeans and now it only builds this extra library which consists of two classes. That will ensure opensterogram can migrate to testing again. If nobody objects, I can upload the changes. I intend to update libnb-platform18-java soon, it is basically the same source package as src:netbeans but it only builds the platform code. For instance the platform packages are needed for visualvm. I believe maintaining this package is viable. It sounds good, as long as visualvm is preserved that's fine for me. Emmanuel Bourg
Re: Solr version
On 27/09/2020 00:23, Markus Koschany wrote: > from my point of view we need to package at least > > hadoop-common-3.2.0.jar > hadoop-annotations-3.2.0.jar > hadoop-hdfs-client-3.2.0.jar > hadoop-auth-3.2.0.jar I did package hadoop 2.6 a few years ago if someone wants to continue the work [1]. That was a naïve attempt to update the solr package, but the size of the beast dissuaded me to upload it (and I had enough of my plate at this time with the JDK upgrades). > Why don't we just create more or less official (even though not really > perfect) Debian packages for netbeans, eclipse, solr, hadoop, etc. by > using tools like jdeb [1] for ant and maven projects or > gradle-ospackage-plugin for gradle [2]. I fully share Markus' analysis. Packaging these huge projects isn't viable without more regular, dedicated, contributors. For client side applications such as Netbeans or Eclipse I tend to think the community would be better served with flatpak packages (it would be nice to have a pure Java toolchain generating these packages), and for complex server side applications a .deb package simply generated by jdeb would be fine. Emmanuel Bourg [1] https://github.com/ebourg/hadoop-debian
Re: Request to join Java team
On 25/08/2020 19:59, Mechtilde wrote: > Hello, > > is it possible to use some of the commands in the script manually to fix > some repos, I created before? I think we need a script to normalize the settings of the existing repositories but I've never found the time to write it. Any taker? Emmanuel Bourg
Re: Request to join Java team
Hi Ole, I've added you to the group. Please try to use this script to create the new repository: https://salsa.debian.org/java-team/pkg-java-scripts/raw/master/setup-salsa-repository Emmanuel Bourg On 25/08/2020 10:33, Ole Streicher wrote: > Hi, > > I think that I was in the team before, but this seems to get lost during > the transition to Salsa. > > Could you add me (@olebole) to the Salsa group > https://salsa.debian.org/groups/java-team ? > > I need this to create a repository for jfreesvg (ITP #968983). > > Thank you! > > Ole >
Re: jimfs: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jimfs: Compilation failure
On 06/08/2020 11:05, Andreas Tille wrote: > [INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /build/jimfs-1.1/jimfs/src/main/java/com/google/common/jimfs/PathService.java:[290,30] > error: is not abstract and > does not override abstract method test(Object) in Predicate Have you tried setting the source/target level to Java 8? Just add this to debian/maven.properties: maven.compiler.source=8 maven.compiler.target=8 Emmanuel Bourg
Re: libisnativec-java - NMU or team upload?
Le 27/07/2020 à 21:43, Sudip Mukherjee a écrit : > Hi All, > I just did a NMU for libisnativec-java and uploaded to DELAYED queue. > But I am confused with that one. Old changelog shows it has always > been "Team upload" but the "Maintainer:" does not say it is team > maintained. > > Is NMU correct or shall I cancel that and do a normal "Team upload" instead ? You can team upload this one just like I did the last time I updated it, but it isn't that important if you uploaded a NMU instead. Just ensure that your changes are pushed to the Salsa repository under the java-team group. Emmanuel Bourg
Re: RFS : libcharts4j-java
On 26/07/2020 10:31, Andreas Tille wrote: > I admit I personally think that having some suffix (alternatively for > +dfsg the suffix +ds is used for "Debian source) is very informative > when deriving from the original upstream download tarball. There is > also a lintian warning (or info?) issued if Files-Excluded is used but > the change is not "advertised" in a version suffix. I agree here with > lintian due to my personal preference. If features were removed to make the package DFSG compliant I agree that the suffix provides a useful indication. Otherwise it raises a doubt that something important may have been removed, and that's not the case when the project was merely cleaned from unwanted build files. > Could you please remove the now unused Git repository in Salsa to avoid > confusion? Done Emmanuel Bourg
