Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski <kilob...@angband.pl> 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
>> <glaub...@physik.fu-berlin.de> 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

[Mathieu Malaterre]

Adrian,

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.
[...]

Thanks very much for stepping up as porter, you have my vote !

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.

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 ?

-M

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Hi all,

On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
>> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>>- powerpc: No porter (RM blocker)
>>
>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>> maintaining powerpcspe which is very similar to powerpc.
>
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

[Let's assume that we can't find a powerpc porter in time for Stretch.]

1. Will `powperpc` automatically be downgraded to simple port ? Or is
this also not automated and the port may simply be removed (eg. sparc)
?
2. Apart from loosing the automatic debian-installer stuff, what else
are we going to loose in that scenario ?

Thanks much for pointers !

-M

Re: [Stretch] Status for architecture qualification

[Mathieu Malaterre]

Hi Hector,

On Thu, Jun 16, 2016 at 2:12 AM, Hector Oron  wrote:
[...]
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
[...]

The debian-powerpc@l.d.o mailing list is active so I would say it
still has some users. I have been using partch.d.o for doing some work
on PowerPC. I posted a summary of work people have been doing on this
port lately:

https://lists.debian.org/debian-powerpc/2016/06/msg00046.html

However I do agree that true PowerPC hardware is actually
disappearing, and it is alive mostly thanks to being an ABI using
32bits integer for PPC64 CPU(s).

-M

Re: GCC-4.5 as the default for (at least some) architectures

[Mathieu Malaterre]

On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis
mar...@genesi-usa.com wrote:
 On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote:
 I'll make GCC 4.6 the default after the release of
 GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
 powerpc.

 Could you include armhf in the list as well?

I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package:

https://buildd.debian.org/status/package.php?p=vxl

but since there is no log I cannot confirm this is the same ICE as on i386/armel

thanks,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com