Re: Porter roll call for Debian Stretch
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
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
Re: Porter roll call for Debian Stretch
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
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.