Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Sat, 2016-10-01 at 15:48 +0200, John Paul Adrian Glaubitz wrote:
> On 10/01/2016 02:17 PM, Ben Hutchings wrote:
> > 
> > > 
> > > This isn't the case for PowerPC32 where upstream development is still very
> > > active because it's part of the PowerPC kernel which is maintained by
> > > IBM.
> > 
> > This is not at all true.  My experience is that IBM doesn't even build-
> > test 32-bit configurations, as evidenced by several stable updates
> > causing FTBFS in Debian.
> 
> They care enough that they are fixing bugs. Just recently, a bug in the
> PowerPC kernel was fixed that affected 32-bit embedded PowerPCs only.

$ git log --author=ibm --grep='ppc-?32|powerpc-?32|32-bit' -i -E arch/powerpc

finds me fewer than ten commits per year.

> > 
> > > 
> > > As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> > > support, so even SPARC is getting back into shape which is why I hope
> > > we can add sparc64 as an official port soon.
> > [...]
> > 
> > Oracle cares about Solaris on SPARC, not Linux on SPARC.
> 
> Well, then you know more than the people at Oracle that I am talking to.
[... much evidence of Oracle supporting Linux on SPARC ...]

OK, I accept this has changed, but I'm quite surprised - Oracle is
ruthlessly commercial, and I'm mystified as to who they expect to buy
it.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.

signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski  wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
>> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>>  wrote:
>> [...]
>> > On the other hand, some packages dropped support for PowerPC32 like Mono
>> > but this isn't a concern for most users, I would say.
>> [...]
>>
>> However I need to mention that the specific ppc/mono issue is in fact
>> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
>> short version is that this issue only happen because we build the
>> ppc32 mono version on a ppc64 kernel, I know that since I did debug
>> this issue.
>
> Which, if I read the bug correctly, is a yet another case of a bogus
> build system looking at characteristics of the machine it's compiled on
> rather than baseline of the arch.

Well the bug is really upstream: one cannot assume page size at
compilation time. But that is a different story.

> And, per your own work, it's +patch +fixed-upstream.

Wow ! In fact I just realize my patch was against git/master at the
time, and was never backported. Need to get this fixed ASAP.

>> I have not heard from the ppc64el porters, but I suspect ppc64 will
>> not be a release arch. So you need to take into consideration that for
>> powerpc to remain a release arch, one need minimal working ppc64 port.
>> Could we solve the situation of ppc64 for Stretch, could it be moved
>> to official release arch ?
>
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
>
> powerpc has:
> linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
> i386 has:
> linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
> linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
> linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
> protection
> linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
> linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)
>
> Note the joke: "for modern PCs".  Unless you do embedded it takes some
> serious dumpster diving to find a machine not better served by an -amd64
> kernel (and thus multiarch).  The i386 architecture is not self-contained,
> powerpc is.
>
> Thus, there is no need for ppc64 (userland), as long as powerpc has the
> toolchain to build 64-bit kernels.  And that's a primary target for gcc
> upstream.

Great ! That's all I wanted to check. I was worried we would need
buildd(s) running on ppc64el.

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Sat, 2016-10-01 at 02:28 +0200, Adam Borowski wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
[...]
> > I have not heard from the ppc64el porters, but I suspect ppc64 will
> > not be a release arch. So you need to take into consideration that for
> > powerpc to remain a release arch, one need minimal working ppc64 port.
> > Could we solve the situation of ppc64 for Stretch, could it be moved
> > to official release arch ?
> 
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
[...]

This is only the case because ppc64 has a lower level of support
(unofficial port) than powerpc (release architecture).  The 64-bit
kernel package should be dropped once powerpc is at the same or lower
level of support than ppc64 - just as we've done for i386, s390 and
sparc.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Fri, 2016-09-30 at 22:34 +0200, John Paul Adrian Glaubitz wrote:
> On 09/30/2016 09:04 PM, Niels Thykier wrote:
> > 
> > As for "porter qualification"
> > =
> > 
> > We got burned during the Jessie release, where a person answered the
> > roll call for sparc and we kept sparc as a release architecture for
> > Jessie.  However, we ended up with a completely broken and unbootable
> > sparc kernel.
> 
> To be fair, this happened because the upstream kernel development for
> SPARC came to an almost complete stop. There was basically only David
> Miller working on the port which turned out not to be enough.
> 
> This isn't the case for PowerPC32 where upstream development is still very
> active because it's part of the PowerPC kernel which is maintained by
> IBM.

This is not at all true.  My experience is that IBM doesn't even build-
test 32-bit configurations, as evidenced by several stable updates
causing FTBFS in Debian.

> PowerPC32 is also still quite popular which is why it still sees
> quite some testing in the wild. There are still new PowerPC32 designs
> based on embedded CPUs (FreeScale and the like).

Which are very different from the Power Macs and similar platforms that
most Debian powerpc users care about.

> As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> support, so even SPARC is getting back into shape which is why I hope
> we can add sparc64 as an official port soon.
[...]

Oracle cares about Solaris on SPARC, not Linux on SPARC.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part