Bug#1034824: tomcat9 should not be released with Bookworm
Paul Gevers kirjoitti 26.5.2023 klo 22.14: Hi, On 26-05-2023 10:58, Moritz Muehlenhoff wrote: Can't we just do the pragmatic fix of updating src:tomcat9 to only ship libtomcat9-java and libtomcat9-embed-java? The maintenance burden for security updates lies within the server stack, the percentage of issues affecting the libtomcat9-java binary packages as used by rdeps will be small to none? I have just added removal hints for tomcatjss and dogtag-pki. As mentioned in my previous message, I want the changes in logback reverted. You can do the reduced upload of tomcat9. Huh, that was a surprising outcome of the discussion.. -- t
Bug#1034824: tomcat9 should not be released with Bookworm
Am Freitag, dem 26.05.2023 um 21:44 +0200 schrieb Emmanuel Bourg: > > The changes to jetty9 have to be reverted too, the package is broken > (#1036798). > > Sadly we can't do without tomcat9. The path forward implies packaging > Jetty 11 or 12 first and migrating all the reverse dependencies, but > that's a task for Trixie. Thanks for investigating Emmanuel. I'll take care of jetty9 too. Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Hi, On 26-05-2023 21:34, Markus Koschany wrote: Do I understand you correctly, that we only ship libtomcat9-java in Bookworm now? Shall I upload a new revision of tomcat9 too? Yes and yes. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034824: tomcat9 should not be released with Bookworm
Le 2023-05-26 21:14, Paul Gevers a écrit : I have just added removal hints for tomcatjss and dogtag-pki. As mentioned in my previous message, I want the changes in logback reverted. You can do the reduced upload of tomcat9. Markus, can you please revert you logback change by tomorrow at the latest? The changes to jetty9 have to be reverted too, the package is broken (#1036798). Sadly we can't do without tomcat9. The path forward implies packaging Jetty 11 or 12 first and migrating all the reverse dependencies, but that's a task for Trixie. Thanks again to Oracle for forcing the javax to jakarta transition on the community, what a waste of energy just to please a couple of lawyers in an office. Emmanuel Bourg
Bug#1034824: tomcat9 should not be released with Bookworm
Hi, > Markus, can you please revert you logback change by tomorrow at the latest? Sure. I will take care if it. Do I understand you correctly, that we only ship libtomcat9-java in Bookworm now? Shall I upload a new revision of tomcat9 too? Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Hi, On 26-05-2023 10:58, Moritz Muehlenhoff wrote: Can't we just do the pragmatic fix of updating src:tomcat9 to only ship libtomcat9-java and libtomcat9-embed-java? The maintenance burden for security updates lies within the server stack, the percentage of issues affecting the libtomcat9-java binary packages as used by rdeps will be small to none? I have just added removal hints for tomcatjss and dogtag-pki. As mentioned in my previous message, I want the changes in logback reverted. You can do the reduced upload of tomcat9. Markus, can you please revert you logback change by tomorrow at the latest? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034824: tomcat9 should not be released with Bookworm
hey all, I was involved with a discussion on site here in Hamburg with Paul about it. On Fri, May 26, 2023 at 10:58:48AM +0200, Moritz Muehlenhoff wrote: > On Fri, May 26, 2023 at 12:10:18AM +0200, Markus Koschany wrote: > > First of all trapperkeeper-webserver-jetty9-clojure should add a build- > > dependency on logback to detect such regressions in advance. > > > > #1036250 is mainly a logback problem, not a tomcat problem. I still would > > like > > to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we > > don't find a solution though. > > > > The tomcatjss / dogtag-pki situation is simple too. If there is no way to > > make > > the application work with Tomcat 10, then there are three options: > > > > 1. Embed Tomcat 9 in your application by creating a standalone jar > > > > 2. Continue to use the current Tomcat 9 package as is but make sure that > > nobody > > else than dogtag-pki uses it. (Package descriptions should be adjusted, and > > the > > binary tomcat9 package should be probably removed too) Nobody should think > > that > > we support two major Tomcat versions. > > > > In any case the dogtag-pki maintainers must commit to at least three years > > of > > security support, web application + Tomcat 9. Otherwise this is pointless. > > > > 3. Remove dogtag-pki and tomcatjss from testing and prepare backports as > > soon > > as dogtag-pki and Co support Tomcat 10. > > Can't we just do the pragmatic fix of updating src:tomcat9 to only ship > libtomcat9-java and libtomcat9-embed-java? The maintenance burden for > security updates lies within the server stack, the percentage of issues > affecting the libtomcat9-java binary packages as used by rdeps will be small > to none? This indeed would have been the most desirable and pragmatic appraoch, which was looked at, but my (limited!) understanding of the situation is still that this won't work out as we have dogtak-pki's pki-server binary package depending on tomcat9-user: respighi:~$ dak rm --suite=bookworm -n -R -b tomcat9-user Will remove the following packages from bookworm: tomcat9-user | 9.0.70-1 | all Maintainer: Debian Java Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Depends: dogtag-pki: pki-server Dependency problem found. See the followup on that by Markus in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034824#45 the answer seems to be from the the answer from Timo Aaltonen, that a switch to tomcat10-user won't work ... Thus the proposal to at this stage keep in need the both source packages. Paul made another way forward in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034824#98 which now involves one dependency rollback and documenting in release note and debian-security-support what support level we can we expect during the bookworm cycle for src:tomcat9. To otherwise drop tomcat9 and tomcat9-user binary package it would be needed to drop as well dogtag-pki. Does this make sense for you Moritz? Salvatore
Bug#1034824: tomcat9 should not be released with Bookworm
Le 26/05/2023 à 10:58, Moritz Muehlenhoff a écrit : Can't we just do the pragmatic fix of updating src:tomcat9 to only ship libtomcat9-java and libtomcat9-embed-java? The maintenance burden for security updates lies within the server stack, the percentage of issues affecting the libtomcat9-java binary packages as used by rdeps will be small to none? dogtag-pki has a popcon of 4, do we really want to keep that package and tomcat9 for so few users? It could come back later in Bookworm as a backport once it supports Tomcat 10. If tomcat9 is kept in Bookworm most users won't realize it's no longer supported. I think we should add a prominent warning in the NEWS file that it's not supported. I'd even suggest disabling the tomcat9 service when upgrading to force the users to act (either migrate to tomcat10, or re-enabling it willingly). Emmanuel Bourg
Bug#1034824: tomcat9 should not be released with Bookworm
On Fri, May 26, 2023 at 12:10:18AM +0200, Markus Koschany wrote: > First of all trapperkeeper-webserver-jetty9-clojure should add a build- > dependency on logback to detect such regressions in advance. > > #1036250 is mainly a logback problem, not a tomcat problem. I still would like > to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we > don't find a solution though. > > The tomcatjss / dogtag-pki situation is simple too. If there is no way to make > the application work with Tomcat 10, then there are three options: > > 1. Embed Tomcat 9 in your application by creating a standalone jar > > 2. Continue to use the current Tomcat 9 package as is but make sure that > nobody > else than dogtag-pki uses it. (Package descriptions should be adjusted, and > the > binary tomcat9 package should be probably removed too) Nobody should think > that > we support two major Tomcat versions. > > In any case the dogtag-pki maintainers must commit to at least three years of > security support, web application + Tomcat 9. Otherwise this is pointless. > > 3. Remove dogtag-pki and tomcatjss from testing and prepare backports as soon > as dogtag-pki and Co support Tomcat 10. Can't we just do the pragmatic fix of updating src:tomcat9 to only ship libtomcat9-java and libtomcat9-embed-java? The maintenance burden for security updates lies within the server stack, the percentage of issues affecting the libtomcat9-java binary packages as used by rdeps will be small to none? Cheers, Moritz
Bug#1034824: tomcat9 should not be released with Bookworm
Control: clone -1 -2 -3 Control: reassign -2 release-notes Control: reassign -3 debian-security-support Control: tag -1 bookworm-ignore Hi, On 26-05-2023 00:10, Markus Koschany wrote: #1036250 is mainly a logback problem, not a tomcat problem. I still would like to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we don't find a solution though. I want the logback changes reverted and go back to tomcat9. We'll ship two versions. We failed to remove tomcat9 properly and it's well past the line where we can try more variant. Just like the apt/adduser situation where we stopped experimenting, let's go back to the situation we know and understand. The tomcatjss / dogtag-pki situation is simple too. Small note, I don't like you framing the situation simple. The time pressure is huge. The tomcat9 situation has drained a lot of energy already, so no, it's not simple. If there is no way to make the application work with Tomcat 10, then there are three options: 2. Continue to use the current Tomcat 9 package as is but make sure that nobody else than dogtag-pki uses it. (Package descriptions should be adjusted, and the binary tomcat9 package should be probably removed too) Nobody should think that we support two major Tomcat versions. I think we have no *reasonable* other option than to do that somewhat. So let's make this clear in the release notes and in debian-security-support. I propose something along these lines for the release notes: Although tomcat9 and tomcat9-user are shipped with bookworm next to tomcat10 binaries, they are exclusively supported for use with dogtag-pki. Users of dogtag-pki have to ensure they run the application in a sufficiently trusted network. Paul (and Salvatore) OpenPGP_signature Description: OpenPGP digital signature
Bug#1034824: tomcat9 should not be released with Bookworm
First of all trapperkeeper-webserver-jetty9-clojure should add a build- dependency on logback to detect such regressions in advance. #1036250 is mainly a logback problem, not a tomcat problem. I still would like to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we don't find a solution though. The tomcatjss / dogtag-pki situation is simple too. If there is no way to make the application work with Tomcat 10, then there are three options: 1. Embed Tomcat 9 in your application by creating a standalone jar 2. Continue to use the current Tomcat 9 package as is but make sure that nobody else than dogtag-pki uses it. (Package descriptions should be adjusted, and the binary tomcat9 package should be probably removed too) Nobody should think that we support two major Tomcat versions. In any case the dogtag-pki maintainers must commit to at least three years of security support, web application + Tomcat 9. Otherwise this is pointless. 3. Remove dogtag-pki and tomcatjss from testing and prepare backports as soon as dogtag-pki and Co support Tomcat 10. Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Le 2023-05-25 à 17 h 41, Martin Hostettler a écrit : Quoting from J�r�me Charaoui in (#1036250): I did further tests with puppetserver, which is a downstream dependency of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web requests (access) logging remains broken. There are no warnings or error messages anywhere: as you can imagine, the logging events are simply lost in the ether. I'm not sure if the latest patches from 2023-05-22 do fix those, but there was no follow up on the bug with details. For the record, these patches only fix the build issue and work around the test failures by disabling the affected tests. The logging problem is still present in puppetserver (and almost certainly puppetdb) with the patched trapperkeeper-webserver-jetty9-clojure package. Thanks, -- Jérôme
Bug#1034824: tomcat9 should not be released with Bookworm
I was asked to send a update to this bug from my notes/open tabs. >From what i can see this is still a problem and it is getting very late to fix all the fallout. There are still 2 packages that are not fixed for this. src:trapperkeeper-webserver-jetty9-clojure (#1036250) which is as far as I understand a dependency of puppet, which is used by a lot of admins including Debian's own DSA. Which even after trying to fix the build problem left the package in a state where it the whole logging is non functional: Quoting from J�r�me Charaoui in (#1036250): > I did further tests with puppetserver, which is a downstream dependency > of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web > requests (access) logging remains broken. There are no warnings or error > messages anywhere: as you can imagine, the logging events are simply > lost in the ether. I'm not sure if the latest patches from 2023-05-22 do fix those, but there was no follow up on the bug with details. Then there is src:tomcatjss (1031816) which seems to have zero progress since the bug was filed. This is a dependency of at least dogtag-pki, pki-ca, pki-kra, pki-ocsp, pki-server, pki-tks and pki-tps I'm not sure what the actual state of src:logback is. It seems the problems in trapperkeeper-webserver-jetty9-clojure are partially related to the state of logback. Do we know that it properly works with the tomcat10 migration patchset? Logback seems to have quite a few reverse dependencies as well. Some bugs have according to the bts been fixed and migrated meanwile: #1035995: bazel-bootstrap #1011597: tiles #1033366: resteasy3.0 What is the plan here to get this in shape for in time before last unblock requests for bookworm on the 28th? - Martin
Bug#1031816: Bug#1034824: tomcat9 should not be released with Bookworm
On Tue, May 16, 2023 at 05:28:11PM +0300, Timo Aaltonen wrote: > Timo Aaltonen kirjoitti 16.5.2023 klo 10.12: > > Markus Koschany kirjoitti 13.5.2023 klo 23.38: > > > Hi Salvatore, > > > > > > adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC > > > > > > Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso: > > > > Hi Markus, > > > > > > > > On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: > > > > > I have just pushed the necessary changes to our Git repository. > > > > > > > > > > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 > > > > > > > > Do we need to have done more here? When Paul asked on #debian-release > > > > I noted that pki-server depends on tomcat9-user, so reducing > > > > libtomcat9-java only would now cause a broken dpeends for pki-server: > > > > > > > > $ dak rm --suite=bookworm -n -R -b tomcat9-user > > > > Will remove the following packages from bookworm: > > > > > > > > tomcat9-user | 9.0.70-1 | all > > > > > > We could simply replace tomcat9-user with tomcat10-user because it > > > only ships a > > > script to create a standalone tomcat instance. We have to do > > > s/tomcat9/tomcat10/ in some debian service files as well. > > > > > > The question is: If we ship libtomcat9-java in Bookworm and change the > > > dependency from tomcat9-user to tomcat10-user, will a web > > > application like > > > dogtag-pki, which is designed for Tomcat 9, continue to work with > > > Tomcat 10? I > > > don't know yet and maybe Timo can chime in here. > > > > I don't know, dogtag uses the skel files from tomcat9-user, but I diffed > > them between tomcat9 and 10 and couldn't see why it would regress. > > Had a closer look at dogtag, and it's launching the tomcat instance from > CATALINA_HOME, so it's a one-way ticket to migrate an installed instance to > use tomcat10 in the configuration, so I don't think moving to tomcat10-user > would fly.. Does that mean the two bugs (in tomcat9 and tomcatjss) should be tagged "trixie sid" to no longer affect and bookworm will ship with two versions of tomcat, or what else is now supposed to happen? cu Adrian
Bug#1034824: tomcat9 should not be released with Bookworm
Hi, On 12-05-2023 21:49, Paul Gevers wrote: I'll check on Sunday on the proposal, unless somebody beats me to it. I don't have time before then. This dropped off my radar and I don't expect I have decent time to look at this until a week from now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034824: tomcat9 should not be released with Bookworm
Timo Aaltonen kirjoitti 16.5.2023 klo 10.12: Markus Koschany kirjoitti 13.5.2023 klo 23.38: Hi Salvatore, adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso: Hi Markus, On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: I have just pushed the necessary changes to our Git repository. https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 Do we need to have done more here? When Paul asked on #debian-release I noted that pki-server depends on tomcat9-user, so reducing libtomcat9-java only would now cause a broken dpeends for pki-server: $ dak rm --suite=bookworm -n -R -b tomcat9-user Will remove the following packages from bookworm: tomcat9-user | 9.0.70-1 | all We could simply replace tomcat9-user with tomcat10-user because it only ships a script to create a standalone tomcat instance. We have to do s/tomcat9/tomcat10/ in some debian service files as well. The question is: If we ship libtomcat9-java in Bookworm and change the dependency from tomcat9-user to tomcat10-user, will a web application like dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I don't know yet and maybe Timo can chime in here. I don't know, dogtag uses the skel files from tomcat9-user, but I diffed them between tomcat9 and 10 and couldn't see why it would regress. Had a closer look at dogtag, and it's launching the tomcat instance from CATALINA_HOME, so it's a one-way ticket to migrate an installed instance to use tomcat10 in the configuration, so I don't think moving to tomcat10-user would fly.. -- t
Bug#1034824: tomcat9 should not be released with Bookworm
Markus Koschany kirjoitti 13.5.2023 klo 23.38: Hi Salvatore, adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso: Hi Markus, On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: I have just pushed the necessary changes to our Git repository. https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 Do we need to have done more here? When Paul asked on #debian-release I noted that pki-server depends on tomcat9-user, so reducing libtomcat9-java only would now cause a broken dpeends for pki-server: $ dak rm --suite=bookworm -n -R -b tomcat9-user Will remove the following packages from bookworm: tomcat9-user | 9.0.70-1 | all We could simply replace tomcat9-user with tomcat10-user because it only ships a script to create a standalone tomcat instance. We have to do s/tomcat9/tomcat10/ in some debian service files as well. The question is: If we ship libtomcat9-java in Bookworm and change the dependency from tomcat9-user to tomcat10-user, will a web application like dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I don't know yet and maybe Timo can chime in here. I don't know, dogtag uses the skel files from tomcat9-user, but I diffed them between tomcat9 and 10 and couldn't see why it would regress. -- t
Bug#1034824: tomcat9 should not be released with Bookworm
Le 2023-05-13 22:38, Markus Koschany a écrit : The question is: If we ship libtomcat9-java in Bookworm and change the dependency from tomcat9-user to tomcat10-user, will a web application like dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I'm pretty sure it won't work. dogtag-pki depends on tomcatjss which is tightly coupled with Tomcat's internal code. Unfortunately tomcatjss upstream is lagging with the Tomcat 10 adoption [1], and we can't hold back Tomcat 10 in Debian indefinitely just for that (for the reminder, Tomcat 10 is a very important release implementing the new Jakarta EE specification, not having it in Bookworm would be a real disservice to our users). The thing I don't understand is why a CA webapp needs a custom Tomcat connector (tomcatjss), maybe it could be patched to work without it? Emmanuel Bourg [1] https://github.com/dogtagpki/tomcatjss/issues/68
Bug#1034824: tomcat9 should not be released with Bookworm
Hi Salvatore, adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso: > Hi Markus, > > On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: > > I have just pushed the necessary changes to our Git repository. > > > > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 > > Do we need to have done more here? When Paul asked on #debian-release > I noted that pki-server depends on tomcat9-user, so reducing > libtomcat9-java only would now cause a broken dpeends for pki-server: > > $ dak rm --suite=bookworm -n -R -b tomcat9-user > Will remove the following packages from bookworm: > > tomcat9-user | 9.0.70-1 | all We could simply replace tomcat9-user with tomcat10-user because it only ships a script to create a standalone tomcat instance. We have to do s/tomcat9/tomcat10/ in some debian service files as well. The question is: If we ship libtomcat9-java in Bookworm and change the dependency from tomcat9-user to tomcat10-user, will a web application like dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I don't know yet and maybe Timo can chime in here. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Hi Markus, On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: > I have just pushed the necessary changes to our Git repository. > > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 Do we need to have done more here? When Paul asked on #debian-release I noted that pki-server depends on tomcat9-user, so reducing libtomcat9-java only would now cause a broken dpeends for pki-server: $ dak rm --suite=bookworm -n -R -b tomcat9-user Will remove the following packages from bookworm: tomcat9-user | 9.0.70-1 | all Maintainer: Debian Java Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Depends: dogtag-pki: pki-server Dependency problem found. Does that means that though given the dependency on tomcat9-user only for pki-server that the package could switch to tomcat10-user instead? Would that already solve the problem? Regards, Salvatore
Bug#1034824: tomcat9 should not be released with Bookworm
I have just pushed the necessary changes to our Git repository. https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Hi Markus, Thanks for the reply and sorry for my bit grumpy mail yesterday. I was tired and surprised. On 11-05-2023 23:31, Markus Koschany wrote: [...] (all good reply). I'll check on Sunday on the proposal, unless somebody beats me to it. I don't have time before then. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034824: tomcat9 should not be released with Bookworm
Hi Paul, Le 2023-05-11 21:44, Paul Gevers a écrit : From a quick look at the key packages: It seems you didn't follow up (86 days) on libcommons-dbcp-java which can't migrate to bookworm because it would make libbiojava-java-doc uninstallable (no fix there, no bug report filed). I have to apology for this one, I forgot to check the transition of libcommons-dbcp-java. Is it still possible to remove libbiojava-java-doc to fix this (very low popcon and unused like the other -java-doc package)? src:tiles also build-depends on libtomcat9-java, with no bug filed for the migration to tomcat10 *and* it having it's own FTBFS bug. (It's key because of src:libspring-java) I remember pulling my hair on src:tiles to make it build with OpenJDK 17, without success unfortunately (#1011597). The project is dead upstream, that doesn't help. Patching src:libspring-java and removing src:tiles is likely the next step. On IRC carnil and jmm_ suggested that src:tomcat9 could be left in bookworm but have it's server component stripped. Would that help the situation? I agree, this is a good compromise. Emmanuel Bourg
Bug#1034824: tomcat9 should not be released with Bookworm
Hello Paul, Am Donnerstag, dem 11.05.2023 um 21:44 +0200 schrieb Paul Gevers: > Hi Markus, > > On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany wrote: > > We can only support one major Tomcat version per release. Tomcat9 has > > been part of Buster and Bullseye already and is superseded by Tomcat > > 10 in Bookworm. I wanted to wait with the removal request until the > > issues in [resteasy3.0] and [tomcatjss] have been resolved but to make > > it more obvious I am filing this bug report now. > > Release Team member here. I'll note that I'm not impressed by the > communication and timing of this bug. We're in Full Freeze for bookworm. > This is no time for transitions, let alone for *uncoordinated* ones. This bug report was merely intended as a reminder. I assumed that tomcatjss (#1031816) and resteasy3.0 were the only two issues left to resolve. I agree that we should have filed the bug report earlier. I was under the impression that all affected packages are maintained by the Java team. IMHO it doesn't make much sense to maintain a Tomcat plugin outside of it, which is by definition tightly coupled with the web server. Still, there was plenty of time and I have pointed to several possible ways to resolve this problem but there was no response. [1] > > You should have raised the issue earlier and brought it to the release > team. tomcat9 and tomcat10 are both key packages so neither can easily > be removed. > > From a quick look at the key packages: > > It seems you didn't follow up (86 days) on libcommons-dbcp-java which > can't migrate to bookworm because it would make libbiojava-java-doc > uninstallable (no fix there, no bug report filed). I did not upload libcommons-dbcp-java and I was not aware of the problem. I will take care of it. > src:tiles also build-depends on libtomcat9-java, with no bug filed for > the migration to tomcat10 *and* it having it's own FTBFS bug. (It's key > because of src:libspring-java) Again I was not aware of src:tiles, probably because there was an RC bug already. This problem seems solvable too. > On IRC carnil and jmm_ suggested that src:tomcat9 could be left in > bookworm but have it's server component stripped. Would that help the > situation? Yes, that was one of my suggestions. > Everything in this transition would still need an unblock by the release > team, as we're now very close to the hard freeze (24 May) and nearly > ready to release. I suggest we just drop all tomcat9 binary packages except libtomcat9-java and I fix tiles and libcommons-dbcp-java. That seems to be the easiest solution right now. Regards, Markus [1] https://bugs.debian.org/1031816#37 signature.asc Description: This is a digitally signed message part
Bug#1034824: tomcat9 should not be released with Bookworm
Hi Markus, On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany wrote: We can only support one major Tomcat version per release. Tomcat9 has been part of Buster and Bullseye already and is superseded by Tomcat 10 in Bookworm. I wanted to wait with the removal request until the issues in [resteasy3.0] and [tomcatjss] have been resolved but to make it more obvious I am filing this bug report now. Release Team member here. I'll note that I'm not impressed by the communication and timing of this bug. We're in Full Freeze for bookworm. This is no time for transitions, let alone for *uncoordinated* ones. You should have raised the issue earlier and brought it to the release team. tomcat9 and tomcat10 are both key packages so neither can easily be removed. From a quick look at the key packages: It seems you didn't follow up (86 days) on libcommons-dbcp-java which can't migrate to bookworm because it would make libbiojava-java-doc uninstallable (no fix there, no bug report filed). src:tiles also build-depends on libtomcat9-java, with no bug filed for the migration to tomcat10 *and* it having it's own FTBFS bug. (It's key because of src:libspring-java) On IRC carnil and jmm_ suggested that src:tomcat9 could be left in bookworm but have it's server component stripped. Would that help the situation? Everything in this transition would still need an unblock by the release team, as we're now very close to the hard freeze (24 May) and nearly ready to release. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034824: tomcat9 should not be released with Bookworm
Source: tomcat9 Version: 9.0.70-1 Severity: serious X-Debbugs-Cc: a...@debian.org We can only support one major Tomcat version per release. Tomcat9 has been part of Buster and Bullseye already and is superseded by Tomcat 10 in Bookworm. I wanted to wait with the removal request until the issues in [resteasy3.0] and [tomcatjss] have been resolved but to make it more obvious I am filing this bug report now. [resteasy3.0] https://bugs.debian.org/1033366 [tomcatjss] https://bugs.debian.org/1031816
