Re: openjdk maintenance for wheezy and squeeze
Am 22.03.2013 19:08, schrieb Moritz Mühlenhoff: Matthias Klose d...@ubuntu.com schrieb: I'm not familiar with the Java internals, but if we're following that approach it would make sense to upgrade Wheezy to the version in experimental (i.e. 7u15 instead of 7u3). I won't upload this myself. IcedTea 7-2.3 uses two hotspot versions, one for the zero ports, one for the hotspot runtimes. From my point of view it would be good to update to a 7-2.[45] with a unified hotspot version capable to build both zero and hotspot, and keep the current 7-2.1.x for now. (I'm not familiar with icedtea development policies and I don't use Java except for freecol. My only interest is avoiding future security disasters for stable-security.) What are the effective consequences for openjdk-7 in Wheezy? Will only the branch in experimental be supported with future releases or both? IcedTea probably will support the 2.3 branch a bit longer, however the 2.3 branch does include two hotspot versions (one for Hotspot, and one for Zero). I would prefer to only update testing/unstable to a 2.x version, if Zero builds with a current Hotspot version. Are there currently security fixes missing in unstable in comparison to experimental? both unstable and experimental were missing the latest updates. now uploaded 2.1.7-1 to unstable. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515702c9@ubuntu.com
Re: openjdk maintenance for wheezy and squeeze
On Tue, Mar 5, 2013 at 11:46 AM, Matthias Klose wrote: Am 01.03.2013 04:35, schrieb Moritz Mühlenhoff: Backporting security fixes with Java has turned out to be more of less unfeasible. I tried this once with DSA 2507 and I think that amounted to at least two man days of work for that update alone. Also, Ubuntu has shipped backports to all suites in USN-1724 and AFAICS the world hasn't stopped. After all, everyone using Oracle Java will be exposed to the same behaviourial changes. So we should proceed with providing backports for openjdk in the future. will that be in backports, stable updates, or security? Via stable-security (i.e. DSAs). If Matthias keeps the Debian/Ubuntu packaging in a state that it's easily buildable on squeeze/wheezy for ojdk6 and for wheezy on ojdk7 I think we should be able to handle Java updates resource-wise. I do not intend to break that intentionally. Some back-porting may show some issues, like patches not updated for older releases. There is a chance to break zero on some architectures, however if you feel that might become an issue, just disable zero for powerpc, ppc64, s390, s390x, as done for mips/mipsel. The hotspot port for sparc/sparc64 seems to work currently, so your call how to maintain it for wheezy. Based on that and the below, it sounds like zero is troublesome, so it should be disabled. I'm not familiar with the Java internals, but if we're following that approach it would make sense to upgrade Wheezy to the version in experimental (i.e. 7u15 instead of 7u3). I won't upload this myself. IcedTea 7-2.3 uses two hotspot versions, one for the zero ports, one for the hotspot runtimes. From my point of view it would be good to update to a 7-2.[45] with a unified hotspot version capable to build both zero and hotspot, and keep the current 7-2.1.x for now. It looks like icedtea is currently at 1.3.1 and you want to bump it to a 2.x version? I don't think the release team will like that very much. Do you have any ideas on a solution that gets to openjdk 7u15 while sticking with icedtea 1.3.1? Thanks, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnwpa6jwriyeykd_a4ja6fyajzjw9-9guwird6+yey...@mail.gmail.com
Re: openjdk maintenance for wheezy and squeeze
I won't upload this myself. IcedTea 7-2.3 uses two hotspot versions, one for the zero ports, one for the hotspot runtimes. From my point of view it would be good to update to a 7-2.[45] with a unified hotspot version capable to build both zero and hotspot, and keep the current 7-2.1.x for now. It looks like icedtea is currently at 1.3.1 and you want to bump it to a 2.x version? I don't think the release team will like that very much. Do you have any ideas on a solution that gets to openjdk 7u15 while sticking with icedtea 1.3.1? Nevermind, so you're refering to icedtea, which is part of the openjdk source, not icedtea-web. Since that is part of the source package, you're certainly free to choose whichever version you think best. Would you mind doing that and uploading your choice to unstable? Thanks, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpvfry4zpexmx+pqi0hdhn5h1-3bps86bxbaccyke9...@mail.gmail.com
Re: openjdk maintenance for wheezy and squeeze
Am 01.03.2013 04:35, schrieb Moritz Mühlenhoff: Backporting security fixes with Java has turned out to be more of less unfeasible. I tried this once with DSA 2507 and I think that amounted to at least two man days of work for that update alone. Also, Ubuntu has shipped backports to all suites in USN-1724 and AFAICS the world hasn't stopped. After all, everyone using Oracle Java will be exposed to the same behaviourial changes. So we should proceed with providing backports for openjdk in the future. will that be in backports, stable updates, or security? If Matthias keeps the Debian/Ubuntu packaging in a state that it's easily buildable on squeeze/wheezy for ojdk6 and for wheezy on ojdk7 I think we should be able to handle Java updates resource-wise. I do not intend to break that intentionally. Some back-porting may show some issues, like patches not updated for older releases. There is a chance to break zero on some architectures, however if you feel that might become an issue, just disable zero for powerpc, ppc64, s390, s390x, as done for mips/mipsel. The hotspot port for sparc/sparc64 seems to work currently, so your call how to maintain it for wheezy. I'm not familiar with the Java internals, but if we're following that approach it would make sense to upgrade Wheezy to the version in experimental (i.e. 7u15 instead of 7u3). I won't upload this myself. IcedTea 7-2.3 uses two hotspot versions, one for the zero ports, one for the hotspot runtimes. From my point of view it would be good to update to a 7-2.[45] with a unified hotspot version capable to build both zero and hotspot, and keep the current 7-2.1.x for now. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51362171.6060...@ubuntu.com
Re: openjdk maintenance for wheezy and squeeze
Moritz Mühlenhoff: I'm not familiar with the Java internals, but if we're following that approach it would make sense to upgrade Wheezy to the version in experimental (i.e. 7u15 instead of 7u3). +1 (I am using the experimental version) Cheers, Andreas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51344a8f.8080...@ping.de
Re: openjdk maintenance for wheezy and squeeze
Op donderdag 28 februari 2013 21:35:09 schreef Moritz Mühlenhoff: So we should proceed with providing backports for openjdk in the future. If Matthias keeps the Debian/Ubuntu packaging in a state that it's easily buildable on squeeze/wheezy for ojdk6 and for wheezy on ojdk7 I think we should be able to handle Java updates resource-wise. So it seems we are in agreement that it's not feasible to remove OpenJDK-6 from Wheezy, and there's the expectation that it can be supported in a relatively acceptable way. Perhaps the RT can tag #675495 wheezy-ignore (and retitle). I'm pretty sure we don't want OpenJDK-6 in Jessie. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: openjdk maintenance for wheezy and squeeze
Control: retitle -1 openjdk-6 should not be released with jessie Control: tag -1 + wheezy-ignore On Sun, Mar 3, 2013 at 14:08:44 +0100, Thijs Kinkhorst wrote: Op donderdag 28 februari 2013 21:35:09 schreef Moritz Mühlenhoff: So we should proceed with providing backports for openjdk in the future. If Matthias keeps the Debian/Ubuntu packaging in a state that it's easily buildable on squeeze/wheezy for ojdk6 and for wheezy on ojdk7 I think we should be able to handle Java updates resource-wise. So it seems we are in agreement that it's not feasible to remove OpenJDK-6 from Wheezy, and there's the expectation that it can be supported in a relatively acceptable way. Perhaps the RT can tag #675495 wheezy-ignore (and retitle). I'm pretty sure we don't want OpenJDK-6 in Jessie. Alright. Cheers, Julien signature.asc Description: Digital signature
Re: openjdk maintenance for wheezy and squeeze
Niels Thykier ni...@thykier.net schrieb: On 2013-02-17 23:04, Matthias Klose wrote: There is a bug report open for openjdk-6 in wheezy (#675495) and squeeze didn't see any security updates for several months. To summarize, no party involved is capable or willing to provide security updates based on backports of single patches to the released openjdk-6 version in a stable release. So what to do about it? Hi, Thanks for bringing up this topic. Here is my view on it: - Remove openjdk-6 in wheezy. Probably would require falling back to gcj. Not recommended as a runtime environment, but should work fine for building packages, as ecj is used for byte-code compilation. Falling back to an easier-to-main jvm could be an option too, but I didn't check how well that would work. Not having a fall-back would require removing most of java in Debian. I do not believe this is a functional solution. In my experience, gcj is not capable of running a lot of our Java programs reliably. - Updating to openjdk-7 in wheezy would not solve any issues from my point of view, and it would need some porting of packages to 7, and probably removing some packages which are not yet ported. Otoh removing openjdk-7 for wheezy could be an option if only one version should be supported for a stable release. We tried to accomplish this (replacing openjdk-6 with openjdk-7) a couple of months before the freeze; there was too much then and the freeze has not changed that. If we were to do this, we should have done it before the freeze (and continued in the early freeze). - Release openjdk-6 with wheezy, and provide security support by updating to new OpenJDK and IcedTea versions. Usually this does include some backports and other fixes. The potential for regressions could be higher, however even the single security fixes show regressions, as shown by the last security update on Feb 1. These builds could be provided as security updates, updates to the stable releases, or as backports. As a proof of concept, see [1]. I am sad to hear that stable releases are having regressions (especially for security fixes), but I do not see a way to release Wheezy without OpenJDK-6 (as default java). - Release openjdk-7 with wheezy, and do the same as with openjdk-6. The issue here is that 7 sees more changes than 6, and that the current openjdk-7 release doesn't build anymore on mips or mipsel, as communicated to the Debian mips porters, so an update would require removal of the binary mips packages. Fine if somebody wants to fix it, but apparently there is no-one interested in that. So this looks more difficult than the openjdk-6 updates. Removing the openjdk mips binaries would require changes to source packages building arch any packages and build-depending on default-jdk or openjdk. openjdk-7/7u3-2.1.3-1 is currently in testing, so we would release openjdk-7 with Wheezy? Admittedly with the security bugs in Java currently, I suspect the u13 might be better for us. That said, I got the feeling that this option would include us replacing the default-jdk with openjdk-7? As mentioned above, I don't see how that can happen with breaking a lot (unless we only change the default plugin). I've looked into the openjdk/icedtea in disguise situation of the last days. It's great to see that their will be ongoing icedtea6 releases. I wasn't aware of that so far. Backporting security fixes with Java has turned out to be more of less unfeasible. I tried this once with DSA 2507 and I think that amounted to at least two man days of work for that update alone. Also, Ubuntu has shipped backports to all suites in USN-1724 and AFAICS the world hasn't stopped. After all, everyone using Oracle Java will be exposed to the same behaviourial changes. So we should proceed with providing backports for openjdk in the future. If Matthias keeps the Debian/Ubuntu packaging in a state that it's easily buildable on squeeze/wheezy for ojdk6 and for wheezy on ojdk7 I think we should be able to handle Java updates resource-wise. I'm not familiar with the Java internals, but if we're following that approach it would make sense to upgrade Wheezy to the version in experimental (i.e. 7u15 instead of 7u3). Cheers, Moritz I recognise that OpenJDK-7 would most likely have been better default. However, I do not think it is possible for us to change the default-java at this point of the freeze without great distruption. * Even if we were to change the default to OpenJDK-7, we would still have a lot way to go before we could get rid of OpenJDK-6. * Using GCJ as default java will just cause programs to fail/crash. I believe I mentioned this to you at UDS-R; I do not think GCJ should be a provider of Java for programs anymore (for fixing post Wheezy). To my knowledge it is (at best) a
Re: openjdk maintenance for wheezy and squeeze
On 18/02/2013 07:26, Andreas Kuckartz wrote: Thanks a lot for explaining the situation and alternative paths forward. My view as a user: I only want OpenJDK7 (maybe OpenJDK8 when that becomes generally available on September 9, 2013 :-) Oracle has announced that no more new public updates of Java SE 6 will be made available after February 2013: http://www.oracle.com/technetwork/java/eol-135779.html OpenJDK6 therefore should be considered obsolete when Wheezy is released. Is there any collaboration with other distributions and/or the OpenJDK project on this ? Andrew from RedHat said that OpenJDK will still be maintained after that: http://lists.debian.org/debian-java/2013/02/msg5.html Sylvestre -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5121dfc9.3000...@debian.org
openjdk maintenance for wheezy and squeeze
There is a bug report open for openjdk-6 in wheezy (#675495) and squeeze didn't see any security updates for several months. To summarize, no party involved is capable or willing to provide security updates based on backports of single patches to the released openjdk-6 version in a stable release. So what to do about it? - Remove openjdk-6 in wheezy. Probably would require falling back to gcj. Not recommended as a runtime environment, but should work fine for building packages, as ecj is used for byte-code compilation. Falling back to an easier-to-main jvm could be an option too, but I didn't check how well that would work. Not having a fall-back would require removing most of java in Debian. - Updating to openjdk-7 in wheezy would not solve any issues from my point of view, and it would need some porting of packages to 7, and probably removing some packages which are not yet ported. Otoh removing openjdk-7 for wheezy could be an option if only one version should be supported for a stable release. - Release openjdk-6 with wheezy, and provide security support by updating to new OpenJDK and IcedTea versions. Usually this does include some backports and other fixes. The potential for regressions could be higher, however even the single security fixes show regressions, as shown by the last security update on Feb 1. These builds could be provided as security updates, updates to the stable releases, or as backports. As a proof of concept, see [1]. - Release openjdk-7 with wheezy, and do the same as with openjdk-6. The issue here is that 7 sees more changes than 6, and that the current openjdk-7 release doesn't build anymore on mips or mipsel, as communicated to the Debian mips porters, so an update would require removal of the binary mips packages. Fine if somebody wants to fix it, but apparently there is no-one interested in that. So this looks more difficult than the openjdk-6 updates. Removing the openjdk mips binaries would require changes to source packages building arch any packages and build-depending on default-jdk or openjdk. We should find a solution where the resources are available to handle this solution. In the OpenJDK team, I think it's safe to assume that Torsten Werner isn't currently working on openjdk anymore and recently I got an email from Damien Raude-Morvan, that he can't work on OpenJDK-7 in the forseeable future anymore. Apparently one of the security team members who did work on OpenJDK security updates left the team too. I think that moving maintainership to the Debian Java team would just make the maintainership issue less explicit. While not a that important issue, the mips and kfreebsd issue could be improved as well: - The mipsel porter box is again down for several months. Having a porter box to test backports would be appreciated (yes, openjdk-7 in experimental currently fails on mips, not mipsel). - Afaik openjdk-7 for kfreebsd does build on kfreebsd (according to Damien) with the kfreebsd kernel from wheezy. So maybe some commitment could be found to upgrade and maintain the kernels before wheezy is released? Matthias [1] deb http://people.debian.org/~doko/tmp/openjdk-6-squeeze ./ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51215401.8010...@ubuntu.com
Re: openjdk maintenance for wheezy and squeeze
On 2013-02-17 23:04, Matthias Klose wrote: There is a bug report open for openjdk-6 in wheezy (#675495) and squeeze didn't see any security updates for several months. To summarize, no party involved is capable or willing to provide security updates based on backports of single patches to the released openjdk-6 version in a stable release. So what to do about it? Hi, Thanks for bringing up this topic. Here is my view on it: - Remove openjdk-6 in wheezy. Probably would require falling back to gcj. Not recommended as a runtime environment, but should work fine for building packages, as ecj is used for byte-code compilation. Falling back to an easier-to-main jvm could be an option too, but I didn't check how well that would work. Not having a fall-back would require removing most of java in Debian. I do not believe this is a functional solution. In my experience, gcj is not capable of running a lot of our Java programs reliably. - Updating to openjdk-7 in wheezy would not solve any issues from my point of view, and it would need some porting of packages to 7, and probably removing some packages which are not yet ported. Otoh removing openjdk-7 for wheezy could be an option if only one version should be supported for a stable release. We tried to accomplish this (replacing openjdk-6 with openjdk-7) a couple of months before the freeze; there was too much then and the freeze has not changed that. If we were to do this, we should have done it before the freeze (and continued in the early freeze). - Release openjdk-6 with wheezy, and provide security support by updating to new OpenJDK and IcedTea versions. Usually this does include some backports and other fixes. The potential for regressions could be higher, however even the single security fixes show regressions, as shown by the last security update on Feb 1. These builds could be provided as security updates, updates to the stable releases, or as backports. As a proof of concept, see [1]. I am sad to hear that stable releases are having regressions (especially for security fixes), but I do not see a way to release Wheezy without OpenJDK-6 (as default java). - Release openjdk-7 with wheezy, and do the same as with openjdk-6. The issue here is that 7 sees more changes than 6, and that the current openjdk-7 release doesn't build anymore on mips or mipsel, as communicated to the Debian mips porters, so an update would require removal of the binary mips packages. Fine if somebody wants to fix it, but apparently there is no-one interested in that. So this looks more difficult than the openjdk-6 updates. Removing the openjdk mips binaries would require changes to source packages building arch any packages and build-depending on default-jdk or openjdk. openjdk-7/7u3-2.1.3-1 is currently in testing, so we would release openjdk-7 with Wheezy? Admittedly with the security bugs in Java currently, I suspect the u13 might be better for us. That said, I got the feeling that this option would include us replacing the default-jdk with openjdk-7? As mentioned above, I don't see how that can happen with breaking a lot (unless we only change the default plugin). I recognise that OpenJDK-7 would most likely have been better default. However, I do not think it is possible for us to change the default-java at this point of the freeze without great distruption. * Even if we were to change the default to OpenJDK-7, we would still have a lot way to go before we could get rid of OpenJDK-6. * Using GCJ as default java will just cause programs to fail/crash. I believe I mentioned this to you at UDS-R; I do not think GCJ should be a provider of Java for programs anymore (for fixing post Wheezy). To my knowledge it is (at best) a Java5 claiming to support both Java6 and Java7 - and when called on that bluff the program has to terminate (usually for missing methods or classes in the std library). We should find a solution where the resources are available to handle this solution. In the OpenJDK team, I think it's safe to assume that Torsten Werner isn't currently working on openjdk anymore and recently I got an email from Damien Raude-Morvan, that he can't work on OpenJDK-7 in the forseeable future anymore. Apparently one of the security team members who did work on OpenJDK security updates left the team too. I think that moving maintainership to the Debian Java team would just make the maintainership issue less explicit. I agree it would be nice to have more hands on packages like OpenJDK; but I suspect OpenJDK is sufficiently intimidating to scare people away at first (or even second) sight. I know from experience with Eclipse that people offered help, but in practise never submitted any patches (or at best did one or two trival things and then we never heard from them again on Eclipse). I
Re: openjdk maintenance for wheezy and squeeze
Am 18.02.2013 00:08, schrieb Niels Thykier: On 2013-02-17 23:04, Matthias Klose wrote: - Remove openjdk-6 in wheezy. Probably would require falling back to gcj. Not recommended as a runtime environment, but should work fine for building packages, as ecj is used for byte-code compilation. Falling back to an easier-to-main jvm could be an option too, but I didn't check how well that would work. Not having a fall-back would require removing most of java in Debian. I do not believe this is a functional solution. In my experience, gcj is not capable of running a lot of our Java programs reliably. There are CACAO and jamvm. At least for jamvm James Page did do a test rebuild once. - Release openjdk-7 with wheezy, and do the same as with openjdk-6. The issue here is that 7 sees more changes than 6, and that the current openjdk-7 release doesn't build anymore on mips or mipsel, as communicated to the Debian mips porters, so an update would require removal of the binary mips packages. Fine if somebody wants to fix it, but apparently there is no-one interested in that. So this looks more difficult than the openjdk-6 updates. Removing the openjdk mips binaries would require changes to source packages building arch any packages and build-depending on default-jdk or openjdk. openjdk-7/7u3-2.1.3-1 is currently in testing, so we would release openjdk-7 with Wheezy? well, with an IcedTea 2.1.x release and packaging backports from experimental, but I'm not going do that for now before the next batch of OpenJDK security updates scheduled for Feb 19. Admittedly with the security bugs in Java currently, I suspect the u13 might be better for us. That said, I got the feeling that this option would include us replacing the default-jdk with openjdk-7? No. And I would not recommend 7u13 now, because it has two hotspot versions for different architectures. I believe you and I talked about dropping mips from the Java7 list if no one stepped up to assist here (at UDS-R)? I could see that happen in Jessie - actually for Java7, I suppose it could happen in Wheezy as well since OpenJDK-6 will stay (for better and for worse). As I said, dropping mips/mipsel as the only java architecture would require changes to many packages. At last Debconf in the release session I raised the issue about early architecture re-qualification for the next release cycle, so maybe delay that after that, if it doesn't come late in the jessie cycle. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512169ab.4050...@ubuntu.com
Re: openjdk maintenance for wheezy and squeeze
Hi! Matthias Klose d...@ubuntu.com writes: - Afaik openjdk-7 for kfreebsd does build on kfreebsd (according to Damien) with the kfreebsd kernel from wheezy. So maybe some commitment could be found to upgrade and maintain the kernels before wheezy is released? Actually as far as I could narrow it down it was the squeeze/buildd schroot/sbuild combination that is not able to build openjdk-7 on kfreebsd while it worked fine for me using only schroot/sbuild from wheezy. I tried narrowing down further but went out of ideas and round-trip-time for trying things out was somewhat a show-stopper. If Damien has different/additional results I'm happy to try on that again but I guess it would be somewhat hard to get a change in for wheezy and it *should* work once wheezy is released (I'll try that again as soon as I can -- but then I'm somewhat bussy right now and wheezy RC bugs have priority). Regards Christoph -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gm6ryno@mitoraj.siccegge.de
Re: openjdk maintenance for wheezy and squeeze
Thanks a lot for explaining the situation and alternative paths forward. My view as a user: I only want OpenJDK7 (maybe OpenJDK8 when that becomes generally available on September 9, 2013 :-) Oracle has announced that no more new public updates of Java SE 6 will be made available after February 2013: http://www.oracle.com/technetwork/java/eol-135779.html OpenJDK6 therefore should be considered obsolete when Wheezy is released. Is there any collaboration with other distributions and/or the OpenJDK project on this ? Cheers, Andreas --- Matthias Klose: There is a bug report open for openjdk-6 in wheezy (#675495) and squeeze didn't see any security updates for several months. To summarize, no party involved is capable or willing to provide security updates based on backports of single patches to the released openjdk-6 version in a stable release. So what to do about it? - Remove openjdk-6 in wheezy. Probably would require falling back to gcj. Not recommended as a runtime environment, but should work fine for building packages, as ecj is used for byte-code compilation. Falling back to an easier-to-main jvm could be an option too, but I didn't check how well that would work. Not having a fall-back would require removing most of java in Debian. - Updating to openjdk-7 in wheezy would not solve any issues from my point of view, and it would need some porting of packages to 7, and probably removing some packages which are not yet ported. Otoh removing openjdk-7 for wheezy could be an option if only one version should be supported for a stable release. - Release openjdk-6 with wheezy, and provide security support by updating to new OpenJDK and IcedTea versions. Usually this does include some backports and other fixes. The potential for regressions could be higher, however even the single security fixes show regressions, as shown by the last security update on Feb 1. These builds could be provided as security updates, updates to the stable releases, or as backports. As a proof of concept, see [1]. - Release openjdk-7 with wheezy, and do the same as with openjdk-6. The issue here is that 7 sees more changes than 6, and that the current openjdk-7 release doesn't build anymore on mips or mipsel, as communicated to the Debian mips porters, so an update would require removal of the binary mips packages. Fine if somebody wants to fix it, but apparently there is no-one interested in that. So this looks more difficult than the openjdk-6 updates. Removing the openjdk mips binaries would require changes to source packages building arch any packages and build-depending on default-jdk or openjdk. We should find a solution where the resources are available to handle this solution. In the OpenJDK team, I think it's safe to assume that Torsten Werner isn't currently working on openjdk anymore and recently I got an email from Damien Raude-Morvan, that he can't work on OpenJDK-7 in the forseeable future anymore. Apparently one of the security team members who did work on OpenJDK security updates left the team too. I think that moving maintainership to the Debian Java team would just make the maintainership issue less explicit. While not a that important issue, the mips and kfreebsd issue could be improved as well: - The mipsel porter box is again down for several months. Having a porter box to test backports would be appreciated (yes, openjdk-7 in experimental currently fails on mips, not mipsel). - Afaik openjdk-7 for kfreebsd does build on kfreebsd (according to Damien) with the kfreebsd kernel from wheezy. So maybe some commitment could be found to upgrade and maintain the kernels before wheezy is released? Matthias [1] deb http://people.debian.org/~doko/tmp/openjdk-6-squeeze ./ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5121c991.5020...@ping.de
Re: openjdk maintenance for wheezy and squeeze
Niels Thykier: - Updating to openjdk-7 in wheezy would not solve any issues from my point of view, and it would need some porting of packages to 7, and probably removing some packages which are not yet ported. Otoh removing openjdk-7 for wheezy could be an option if only one version should be supported for a stable release. We tried to accomplish this (replacing openjdk-6 with openjdk-7) a couple of months before the freeze; there was too much then and the freeze has not changed that. * Even if we were to change the default to OpenJDK-7, we would still have a lot way to go before we could get rid of OpenJDK-6. Can you provide more info on what too much and a lot consists of ? Cheers, Andreas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5121d6d5.5040...@ping.de
Re: openjdk maintenance for wheezy and squeeze
On 2013-02-18 08:23, Andreas Kuckartz wrote: Niels Thykier: - Updating to openjdk-7 in wheezy would not solve any issues from my point of view, and it would need some porting of packages to 7, and probably removing some packages which are not yet ported. Otoh removing openjdk-7 for wheezy could be an option if only one version should be supported for a stable release. We tried to accomplish this (replacing openjdk-6 with openjdk-7) a couple of months before the freeze; there was too much then and the freeze has not changed that. * Even if we were to change the default to OpenJDK-7, we would still have a lot way to go before we could get rid of OpenJDK-6. Can you provide more info on what too much and a lot consists of ? Cheers, Andreas Certainly (btw, I meant to write s/a lot/a long/). When we tried to replace OpenJDK-6 with OpenJDK-7 as default-java, we mostly focused on problems that would occur by OpenJDK-7 now being the JDK used for building. We mostly ignored all the packages that explicitly (build-)depended on OpenJDK-6. The todo list I used for this purpose is available at [1]. Keep in mind that it hasn't been updated for 6-8 months now (but given the freeze, I doubt there has been a lot of improvement in this area). ~Niels [1] http://titanpad.com/WciYqDGRNd -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5121da25.2020...@thykier.net
