Re: Porter roll call for Debian Stretch

[Adam Borowski]

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.

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

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

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

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

[John Paul Adrian Glaubitz]

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. 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).

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.

>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.

Well, mistakes happen and while I think it's good and important to learn
from mistakes, we should not dramatize such issues. We have had worse
issues like the OpenSSL entropy bug, for example, and we still managed
to cope with the fallout in a very professional manner.

> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).

I don't think there is any concern regarding the powerpc port in this
regard. wanna-build shows almost 11800 packages that are up-to-date
which is a good indicator that the port is in good shape, both regarding
the toolchain and various source packages which need architecture-specific
adaptations like LibreOffice or JavaScript packages.

On the other hand, some packages dropped support for PowerPC32 like Mono
but this isn't a concern for most users, I would say.

> If I am to support powerpc as a realease architecture for Stretch, I
> need to know that there are *active* porters behind it committed to
> keeping it in the working.  People who would definitely catch such
> issues long before the release.  People who file bugs / submit patches etc.

I agree and I'm actually doing that all the time. I always run unstable
on my machines and constantly check wanna-build for build issues and
report them upstream whenever they occur. I have helped dozens of such
issues on "sh4" and "sparc64", for example.

> If you need inspiration: Have a look at the [automatic testing of
> ppc64el images].  Or the [arm64 machines on ci.debian.net] with
> comparable results to amd64.  This is the sort of thing that inspires
> confidence in the ports for me and I think we should have vastly more of.

I agree that would be nice to have. However, to be fair, we don't have
that type of testing for all release architectures and to my current
knowledge, automated testing of installation images is not a criteria
for an architecture to maintain release status.

My main argument for why we should keep the powerpc port is its
popularity. If we look at the numbers from popcon [1], powerpc
is still the fourth-most-popular port and I think we would disappoint
many users if we were to drop the port for Stretch. Note that while
ports like "arm64" or "ppc64el" receive lots of support, especially
from companies, they still haven't reached the same popularity as the
powerpc port for example. Heck, there are even more users for "hppa"
and "sparc64" which both are just unofficial ports architectures.

Thanks,
Adrian

> [1] http://popcon.debian.org/

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

[Niels Thykier]

Niels Thykier:
> [...]
> 
> 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.
> 
>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.
> 
> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).
> 
> 
> [...]
> 

I have been reminded of my inaccurate memory.  The broken sparc kernel
was released in Wheezy (and discovered during Jessie).  The roll call
for Jessie happened shortly after Wheezy release but before DSA
discovered the broken kernel.

Nonetheless, the core argument still stands.

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Adam D. Barratt]

On Fri, 2016-09-30 at 19:04 +, 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.

fwiw, you mean wheezy.

Regards,

Adam

Re: Porter roll call for Debian Stretch

[Niels Thykier]

John Paul Adrian Glaubitz:
> On 09/30/2016 06:08 PM, Niels Thykier wrote:
>> I strongly /suspect/ that "no porters" for powerpc will imply the
>> removal of powerpc for Stretch.  It may or may not be moved to ports
>> (assuming someone is willing to support it there).
> 
> So, I take this as a "no" for the offer from me and Christoph Biedel to take
> over the powerpc port for Stretch?
> 
> [...]
> 
> Thanks,
> Adrian
> 

My statement above was made based on the assumption stated in the first
line of Mathieu's mail, which was "Assume there are no powerpc porters
for Stretch".

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.

  That was an embarrassment to the Debian stability and quality
  reputation that I never - ever - want to repeat.

(For avoidance of doubt: I want to ensure that release architectures
"just work(tm)" and I have no desire to blame that volunteer).


If I am to support powerpc as a realease architecture for Stretch, I
need to know that there are *active* porters behind it committed to
keeping it in the working.  People who would definitely catch such
issues long before the release.  People who file bugs / submit patches etc.


If you need inspiration: Have a look at the [automatic testing of
ppc64el images].  Or the [arm64 machines on ci.debian.net] with
comparable results to amd64.  This is the sort of thing that inspires
confidence in the ports for me and I think we should have vastly more of.


Thanks,
~Niels

[automatic testing of ppc64el images]:
 https://lists.debian.org/debian-powerpc/2016/06/msg2.html

[arm64 machines on ci.debian.net]:
 https://ci.debian.net/status/

Re: Porter roll call for Debian Stretch

[Adam Borowski]

On Fri, Sep 30, 2016 at 10:03:47AM +0200, Mathieu Malaterre wrote:
> [Let's assume that we can't find a powerpc porter in time for Stretch.]

Two potential porters stepped up, who might or might not be accepted.

> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?

Removal from the main archive isn't automatic, and assuming no serious
kernel or toolchain breakage, I guess there's no reason for such removal
to be hasty.

On the other hand, place in -ports (aka second-class architectures) isn't
automatic either, and relies on someone doing the work.

> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?

Security support and stable release.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Enabling PIE by default for Stretch

[Matthias Klose]

[CCing porters, please also leave feedback in #835148 for non-release 
architectures]

On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> As agreed on during the [meeting], if there are no major concerns to
> this proposal in general within a week, I shall file a bug against GCC
> requesting PIE by default on all release architectures (with backing
> porters).

please re-use #835148

>   If there are only major concerns with individual architectures, I will
> simply exclude said architectures in the "PIE by default" request.
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> Fall-out
> 
> 
> There will be some possible fall-out from this change:
> 
>  * There will be some FTBFS caused by some packages needing a rebuild
>before reverse dependencies can enable PIE.  These are a subset of
>the bugs filed in the [pie+bindnow] build tests.
> 
>  * Some packages may not be ready for PIE.  These will have to disable
>it per package.  A notable case being ghc (#712228), where we can
>reuse the patch from Ubuntu to work around the issue.
> 
>  * A possible issue from Matthias was that no one has done a large scale
>"PIE by default" on "arm* mips*".
> 
>  * There was concern about whether the 32bit arm architectures would be
>notably affected by the PIE slow down (like x86 used to be).
>It is not measured, but two arm porters did mention a possible
>slowdown
> 
>  * It was questioned whether it made sense to invest time and effort in
>enabling PIE for architectures which would not be included in Buster
>(armel?). Personally, I do not see an issue, if the porters are
>ready to put in the effort required.
> 
> Thanks,
> ~Niels
> 
> [meeting]:
> http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html
> 
> [pie+bindnow]:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable
> 
> 
> 
> 

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/30/2016 06:08 PM, Niels Thykier wrote:
> I strongly /suspect/ that "no porters" for powerpc will imply the
> removal of powerpc for Stretch.  It may or may not be moved to ports
> (assuming someone is willing to support it there).

So, I take this as a "no" for the offer from me and Christoph Biedel to take
over the powerpc port for Stretch?

I have quite some experience with working on ports and unlike what Matthias 
claimed,
I'm not just maintaining a few buildds but also getting architecture-specific 
bugs
fixed and so on.

Is there any specific qualification I am missing?

Thanks,
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: Porter roll call for Debian Stretch

[Niels Thykier]

Mathieu Malaterre:
> Hi all,
> 
> [...]
> 
> [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
> 

I strongly /suspect/ that "no porters" for powerpc will imply the
removal of powerpc for Stretch.  It may or may not be moved to ports
(assuming someone is willing to support it there).

Not sure I can answer your 2nd question though.

~Niels

Re: Porter roll call for Debian Stretch

[Christian Zigotzky]

You have a porter for PowerPC. See email from Adrian. ;-)

-- Christian

Sent from my iPhone

> On 30 Sep 2016, at 10:03, Mathieu Malaterre  wrote:
> 
> 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: 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