Re: The (uncalled for) toolchain maintainers roll call for stretch
Re: The (uncalled for) toolchain maintainers roll call for stretch
Re: The (uncalled for) toolchain maintainers roll call for stretch
Re: The (uncalled for) toolchain maintainers roll call for stretch
Matthias Klose wrote: > Afaiu the security team also doesn't care > about these ports when they fail to build for security updates. Indeed. The openjdk updates are already really time-consuming, we can't afford additional update rounds for exotic archs without official upstream support. Cheers, Moritz
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 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
The (uncalled for) toolchain maintainers roll call for stretch
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. I appreciate that the release criteria are somehow "reset" for the stretch release, and not copied from previous release decisions. GNU toolchain (GCC / binutils) -- GCC upstream has the notation of primary and secondary platforms, with the commitment to fix issues on these platforms [1], [2]. Debian architectures within the set of these platforms are: - aarch64-none-linux-gnu (starting with GCC 7) - arm-linux-gnueabi - i686-pc-linux-gnu - powerpc64-unknown-linux-gnu - x86_64-unknown-linux-gnu - s390x-linux-gnu Release architectures missing in the primary and secondary platforms: - armhf - mips* - powerpc - ppc64el As you see with arm64, new architectures become primary or secondary platforms only after a while, so that may explain the absence of powerpc64le-unknown-linux-gnu. 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). 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. For the mips* architectures we apparently have five or more active toolchain maintainers. I very much doubt that view. From my point of view these architecture would be perfect candidates for partial architectures, and until then should be removed from the set of the release architectures. For mips* that shouldn't be no news; please see my comments regarding both the toolchain and buildd status since at least DebConf 12 (release meetings during DebConfs). 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. Other toolchains - clang/llvm not available on armel since 3.8. - fpc not available on powerpc anymore (may have changed recently) - mono not available more on powerpc Being demoted as a release architecture certainly is not a nice thing, and looking at past demotions, these were not done very coordinated, not allowing builds in the ports archive for some months. It would be good to find some middle-ground such that a port's demotion isn't a final thing, and it has a chance to become a release architecture again, maybe even as a partial architecture if we can define the meaning of such a thing. Matthias [1] https://gcc.gnu.org/gcc-6/criteria.html [2] https://gcc.gnu.org/gcc-7/criteria.html
