Re: The (uncalled for) toolchain maintainers roll call for stretch

2016-09-10 Thread Matthias Klose
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

2016-09-10 Thread John Paul Adrian Glaubitz
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

2016-09-10 Thread Paul Gevers
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


The (uncalled for) toolchain maintainers roll call for stretch

2016-09-09 Thread Matthias Klose
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