Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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
