Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1034824: tomcat9 should not be released with Bookworm
292 views
Skip to first unread message
Paul Gevers
May 11, 2023, 3:50:24 PM5/11/23
to
Hi Markus,
On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany <a...@debian.org> 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
On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany <a...@debian.org> 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
Paul Gevers
May 12, 2023, 4:00:05 PM5/12/23
to
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
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
Salvatore Bonaccorso
May 13, 2023, 3:01:47 PM5/13/23
to
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 <pkg-java-m...@lists.alioth.debian.org>
------------------- 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
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 <pkg-java-m...@lists.alioth.debian.org>
------------------- 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
Timo Aaltonen
May 16, 2023, 3:20:04 AM5/16/23
to
Markus Koschany kirjoitti 13.5.2023 klo 23.38:
> Hi Salvatore,
>
> adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC
> 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
> 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
> 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
>
> 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
Timo Aaltonen
May 16, 2023, 10:40:05 AM5/16/23
to
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
Jérôme Charaoui
May 25, 2023, 6:00:04 PM5/25/23
to
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
>
> 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
Salvatore Bonaccorso
May 26, 2023, 5:42:24 AM5/26/23
to
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
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
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
tomcat9-user | 9.0.70-1 | all
Maintainer: Debian Java Maintainers <pkg-java-m...@lists.alioth.debian.org>
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
dogtag-pki: pki-server
Dependency problem found.
See the followup on that by Markus in
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
dogtag-pki: pki-server
Dependency problem found.
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
Paul Gevers
May 26, 2023, 3:21:38 PM5/26/23
to
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
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?
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
Markus Koschany
May 26, 2023, 3:40:05 PM5/26/23
to
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
> Markus, can you please revert you logback change by tomorrow at the latest?
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
Emmanuel Bourg
May 26, 2023, 4:01:33 PM5/26/23
to
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
> 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?
(#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
Markus Koschany
May 26, 2023, 4:11:37 PM5/26/23
to
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.
>
> 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.
Markus
0 new messages