Re: The (uncalled for) toolchain maintainers roll call for stretch
On 15.09.2016 22:43, Helge Deller wrote: > Hi Matthias, > > On 10.09.2016 00:48, Matthias Klose wrote: >> While the Debian Release team has some citation about the quality of the >> toolchain on their status page, it is not one of the release criteria >> documented >> by the release team. I'd like to document the status how I do understand it >> for >> some of the toolchains available in Debian. > >> Java/OpenJDK >> >> >> For the stretch release openjdk-8 will be fine as the default java >> implementation. For buster, gcj (to be removed in GCC 7) won't be available >> anymore, and we'll end up with architectures without a java implementation. >> At >> the same time I'd like to consider to stop providing OpenJDK zero builds, >> leaving powerpc and mips* without a java implementation as well (currently >> not >> building for openjdk-9). armhf (not armel) and s390x have Hotspot ports >> underway. > > Can you explain the reason why you consider stopping OpenJDK zero builds? the zero builds usually break on various architectures when the hotspot version is updated. So the zero ports require extra work and hinder migration of the packages to testing when they ftbfs. Afaiu the security team also doesn't care about these ports when they fail to build for security updates. > I'm asking, because on hppa we currently use gcj and we don't have any > OpenJDK port yet. > My hope was to fix at some point in future the old existing OpenJDK zero port > patches to get some newer > JDK even if it's slower. With your intention to stop zero builds, we probably > won't have any > JDK at all... I can't care for all ports which are not release architectures. Feel free to - send patches for the openjdk-8 package - look at the openjdk-9 build failures and send patches for the openjdk-9 package - Prepare to get these patches into openjdk-10, do regular builds of openjdk-10 when it becomes open for development, and continue to do so as long as you want to have it building. Matthias
Re: The (uncalled for) toolchain maintainers roll call for stretch
Hi Matthias, On 10.09.2016 00:48, Matthias Klose wrote: > While the Debian Release team has some citation about the quality of the > toolchain on their status page, it is not one of the release criteria > documented > by the release team. I'd like to document the status how I do understand it > for > some of the toolchains available in Debian. > Java/OpenJDK > > > For the stretch release openjdk-8 will be fine as the default java > implementation. For buster, gcj (to be removed in GCC 7) won't be available > anymore, and we'll end up with architectures without a java implementation. > At > the same time I'd like to consider to stop providing OpenJDK zero builds, > leaving powerpc and mips* without a java implementation as well (currently not > building for openjdk-9). armhf (not armel) and s390x have Hotspot ports > underway. Can you explain the reason why you consider stopping OpenJDK zero builds? I'm asking, because on hppa we currently use gcj and we don't have any OpenJDK port yet. My hope was to fix at some point in future the old existing OpenJDK zero port patches to get some newer JDK even if it's slower. With your intention to stop zero builds, we probably won't have any JDK at all... Thanks, Helge
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 10.09.2016 09:59, Paul Gevers wrote: > Hi, > > On 10-09-16 00:48, Matthias Klose wrote: >> - fpc not available on powerpc anymore (may have changed recently) > > For whatever it is worth, this was finally fixed this week. It is > missing on mips*, ppc64el and s390x though, while at least some form of > MIPS is supported upstream. the trunk/3.1 works at least for ppc64el too.
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 10.09.2016 10:21, Simon McVittie wrote: > On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote: >> The arm-linux-gnueabi is not that well defined, so it may include the hard >> float >> variant as well. However Debian default to armv4t, while the default >> configuration for upstream is armv5. However with the selected defaults >> Debian's libstdc++::future module is not complete and causes build failures >> on >> this architecture (same for sparc). > > This sounds as though armhf might in fact be better-supported than armel > in practice, because it targets armv7 which is an armv5 superset. > > Devil's advocate: what supported devices would be lost if armel's baseline > advanced from armv4t to armv5, in much the same way that x86's baseline > recently advanced to i686? > > According to the installation guide, jessie supported ixp4xx (scheduled > to be dropped in stretch anyway), kirkwood (which I think is always armv5), > orion5x, and versatile (qemu). In sid, the kirkwood and orion5x kernels > have been combined into a marvell kernel which appears to use > ARCH_MULTI_V5. ARCH_VERSATILE also depends on ARCH_MULTI_V5, so I think > the only supported use for armel on armv4 at this point is with a > self-compiled kernel (or another distro's kernel outside a > container/chroot) anyway? > > (Perhaps I'm just being selfish here, because my only armel device is a > Kirkwood, which I'm fairly sure is v5 and would survive this change.) I don't think that the move to armv5/armv5t is enough to fix issues like #727621, for that you would need v7. You certainly would loose support for the Raspi Pi, however the Raspian derivative already rebuilds the armhf architecture for armv6 outside of Debian. Matthias
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 09/10/2016 12:48 AM, Matthias Klose wrote: > Uncovered by the upstream primary and secondary platforms are the mips* > architectures and powerpc. For the uncovered archs I would expect somehow > more > and pro-active Debian maintenance, however I fail to see this happen. > > - see the history of ftbfs on the buildd page of the gcc-snapshot package > - see the status of the gcc-6 package for the pre-release uploads > - see the number of RC issues for binutils which came up with 2.27, >some still open. > - Toolchain packages are not watched by porters, and I can't track >every regression myself, however this is not done well by porters. > > On the recent Porter's call I didn't see any toolchain support for the powerpc > architecture. I would actually be happy to take over the powerpc port as its official porter. I'm already taking care of powerpcspe, so I think it would be a perfect fit. Let me know what needs to be done to make this happen! I don't want to see powerpc go too soon. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: The (uncalled for) toolchain maintainers roll call for stretch
On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote: > The arm-linux-gnueabi is not that well defined, so it may include the hard > float > variant as well. However Debian default to armv4t, while the default > configuration for upstream is armv5. However with the selected defaults > Debian's libstdc++::future module is not complete and causes build failures on > this architecture (same for sparc). This sounds as though armhf might in fact be better-supported than armel in practice, because it targets armv7 which is an armv5 superset. Devil's advocate: what supported devices would be lost if armel's baseline advanced from armv4t to armv5, in much the same way that x86's baseline recently advanced to i686? According to the installation guide, jessie supported ixp4xx (scheduled to be dropped in stretch anyway), kirkwood (which I think is always armv5), orion5x, and versatile (qemu). In sid, the kirkwood and orion5x kernels have been combined into a marvell kernel which appears to use ARCH_MULTI_V5. ARCH_VERSATILE also depends on ARCH_MULTI_V5, so I think the only supported use for armel on armv4 at this point is with a self-compiled kernel (or another distro's kernel outside a container/chroot) anyway? (Perhaps I'm just being selfish here, because my only armel device is a Kirkwood, which I'm fairly sure is v5 and would survive this change.) S
Re: The (uncalled for) toolchain maintainers roll call for stretch
Hi, On 10-09-16 00:48, Matthias Klose wrote: > - fpc not available on powerpc anymore (may have changed recently) For whatever it is worth, this was finally fixed this week. It is missing on mips*, ppc64el and s390x though, while at least some form of MIPS is supported upstream. Paul signature.asc Description: OpenPGP digital signature