Re: Porter roll call for Debian Stretch

[Adrian Bunk]

On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote:
> On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> > [ adding debian-powerpc ]
> > 
> > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > > Niels Thykier  schrieb:
> > > > 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.
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > > a powerpc-specific build failure of mariadb in stable. The maintainer
> > > said he can't work on it, so if anyone considers himself/herself a
> > > powerpc porter, this is something to look it.
> > 
> > Can you give a hint what exactly should be looked at?
> 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0=powerpc=10.0.27-0%2Bdeb8u1=1473621159
> 
> > The bug did not make it clear that there is any problem left at all when 
> > I looked at it recently.
> > 
> > The last message was closing the bug.
> > 
> > There was a control command reopening the bug without giving any 
> > rationale, but the last control command was
> >   fixed 832931 10.0.27-1
> 
> For unstable, yes. The stable package is still broken.

Thanks.

When skimming through that the bug I thought it was fixed in 
upstream 10.0.27, and no comment in the bug indicated otherwise.

As (pretty passive) reader of debian-powerpc, I am also puzzled by the 
fact that I cannot recall #832931 ever being mentioned there.

An email to the bug and the mailing list of the port stating that there 
is a problem, and what is known about it, can be really helpful for 
getting such a bug resolved.


> > buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]
> 
> That's an artefact of how builds for suites with "overlays" (i.e. pu /
> tpu) are displayed. If one actually looks at the archive:
> 
> mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
> mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
> armhf, i386, mips, mipsel, ppc64el, s390x

Ouch.

I thought the information in the version tracking was wrong
when buildd.d.o showed green.


> Regards,
> 
> Adam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Porter roll call for Debian Stretch

[Adam D. Barratt]

On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> [ adding debian-powerpc ]
> 
> On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier  schrieb:
> > > 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.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > a powerpc-specific build failure of mariadb in stable. The maintainer
> > said he can't work on it, so if anyone considers himself/herself a
> > powerpc porter, this is something to look it.
> 
> Can you give a hint what exactly should be looked at?

https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0=powerpc=10.0.27-0%2Bdeb8u1=1473621159

> The bug did not make it clear that there is any problem left at all when 
> I looked at it recently.
> 
> The last message was closing the bug.
> 
> There was a control command reopening the bug without giving any 
> rationale, but the last control command was
>   fixed 832931 10.0.27-1

For unstable, yes. The stable package is still broken.

> buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

That's an artefact of how builds for suites with "overlays" (i.e. pu /
tpu) are displayed. If one actually looks at the archive:

mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
armhf, i386, mips, mipsel, ppc64el, s390x

Regards,

Adam

Re: Porter roll call for Debian Stretch

[Adrian Bunk]

[ adding debian-powerpc ]

On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier  schrieb:
> > 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.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> a powerpc-specific build failure of mariadb in stable. The maintainer
> said he can't work on it, so if anyone considers himself/herself a
> powerpc porter, this is something to look it.

Can you give a hint what exactly should be looked at?

The bug did not make it clear that there is any problem left at all when 
I looked at it recently.

The last message was closing the bug.

There was a control command reopening the bug without giving any 
rationale, but the last control command was
  fixed 832931 10.0.27-1

buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

If there is a problem left somewhere it is well-hidden, and not visible 
immediately when looking at the bug - I thought this was already resolved.

> Cheers,
> Moritz

cu
Adrian

[1] https://buildd.debian.org/status/package.php?p=mariadb-10.0=jessie

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Porter roll call for Debian Stretch

[Moritz Mühlenhoff]

Niels Thykier  schrieb:
> 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.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
a powerpc-specific build failure of mariadb in stable. The maintainer
said he can't work on it, so if anyone considers himself/herself a
powerpc porter, this is something to look it.

Cheers,
Moritz

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

Re: Porter roll call for Debian Stretch

[Milan Kupcevic]

On 09/20/2016 05:46 PM, 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.
> 


Thank you Adrian for stepping up. You will have my support in this
endeavor for the Stretch release.

Milan




signature.asc
Description: OpenPGP digital signature

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

[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

Re: Porter roll call for Debian Stretch

[Christoph Biedl]

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.

For somewhat personal reasons I'm interested in keeping powerpc in
stretch as well. I certainly cannot take the entire role as a porter,
especially since I don't know what amount of work this implies. But I
am willing to help.

There are two powerpc boxes in my collection, used regulary. One runs
on stable, the other on testing. I haven't done d-i tests but
certainly could do.

Christoph



signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/23/2016 03:54 PM, Matthias Klose wrote:
> 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 ;)

So, what are the criteria to be knighted to become a maintainer of powerpc?

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

[Matthias Klose]

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

Matthias

Re: Porter roll call for Debian Stretch

[Moritz Mühlenhoff]

John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> schrieb:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --a6PKWkjgHofM7jQeP6IIWOK9h7Ax8iC64
> Content-Type: multipart/mixed; boundary="bwOPGPFUk1EHlmixEJpS4SCMBBipFWjH9";
>  protected-headers="v1"
> From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
> To: Niels Thykier <ni...@thykier.net>, debian-po...@lists.debian.org
> Cc: debian-release@lists.debian.org, debian-de...@lists.debian.org
> Message-ID: <3e8c329c-85a2-7c29-f9ec-7fa071ab5...@physik.fu-berlin.de>
> Subject: Re: Porter roll call for Debian Stretch
> References: <20160817200524.c2e23...@bendel.debian.org>
> <25ca2f9f-e5a8-87d8-b397-208db2d7d...@thykier.net>
> In-Reply-To: <25ca2f9f-e5a8-87d8-b397-208db2d7d...@thykier.net>
>
> --bwOPGPFUk1EHlmixEJpS4SCMBBipFWjH9
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> 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.

Great, please look into the mariadb build failure reported at #832931.

Cheers,
Moritz

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

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.

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



signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Niels Thykier]

ni...@thykier.net:
> Hi,
> 
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  [...]
> 

Thanks to all that replied to the roll call.

We got replies from all architectures except amd64 (Waived), i386
(Waived) and powerpc (problematic).  For the ports that replied, all had
at least 2 or more porters.
  We also got a parallel update from Matthias Klose on the toolchain
state[1].  Based on these we have updated the current state of the
architecture qualification for Stretch[2].

 * Please check that your name is listed as a porter on [2] (see [3]
   for how).  If I missed you, please do not hesitate to let me know.

 * For powerpc, mips and mipsel: Please note that we have added a
   (potentially) blocking issues for your architecture.
   - powerpc: No porter (RM blocker)
   - mips+mipsel: #834147 (RM concern, possibly blocker)


As for the piggy backed question about PIE by default:

 * arm64: 2 OK, 1 did not mention it
 * armel: 3 OK, 1 OK if tested first, 1 was neutral and 1 did not
   mention it
 * armhf: 4 OK, 1 OK if tested first, 1 was neutral and 2 did not
   mention it
 * mips+mipsel+mips64el: 3 OK, 1 OK later, 4 did not mention it.
 * ppc64el: 3 OK, 1 recommended further testing/research
 * s390x: 2 OK

Over all, most people (who answered it) was positive towards the switch.
 Based on this, I suspect that if we make PIE default in Stretch, then
we will do it for all architectures.  That said, you will be notified if
that default changes for Stretch.

Thanks,
~Niels

[1] https://lists.debian.org/debian-release/2016/09/msg00263.html

[2] https://release.debian.org/stretch/arch_qualify.html

[3] Hover your mouse over the number of porters for your architecture
or download the underlying data file from:
  https://release.debian.org/stretch/arch_spec.yaml




signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Aurelien Jarno:
> On 2016-08-17 22:05, ni...@thykier.net wrote:
>> Hi,
>>
>> Like last release, we are doing a roll call for porters of all release
>> architectures.  If you are an active porter behind one of the [release
> 

Hi,

Apologies for the tardiness on my part for this.

> Does it really concerns *all* release architectures? Traditionally amd64
> and i386 have been granted waivers as "the toolchain maintainers are
> happy to support" these architectures "as-is".

Indeed you are correct that amd64 and i386 has generally been granted a
waiver.  Said waiver has not been retracted, so the roll call was
intended for all except amd64 + i386.

> That said the toolchain
> maintainers do not fix ports specific bugs outside of the toolchain.
> 
> While I fully agree that we can have a waiver for amd64 due to being the
> de facto standard architecture, it seems that a few leaf packages do
> not build on i386 and that we have no porters to fix them. That is
> probably still fine, but I wonder how fast the number of such packages
> will increase in the future.
> 

You are not the first to race the concern for i386.  To my knowledge, it
is still a "minor" issue for Stretch.  Nonetheless, I suspect that we
should revisit that decision for Buster.

>> architectures] for the entire lifetime of Debian Stretch (est. end of
>> 2020), please respond with a signed email containing the following
> 
> What is the relation between the end of support of Stretch...
> 
>> before Friday, the 9th of September:
>  
>>  * Which architectures are you committing to be an active porter for?
>>  * Please describe recent relevant porter contributions.
>>  * Are you running/using Debian testing or sid on said port(s)?
>>  * Are you testing/patching d-i for the port(s)?
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
> 
> ... and the above questions?
> 
> I fully agree that running testing/sid, fixing bugs or working on d-i up
> to the release of Stretch will improve its quality. But after the
> release it will improve the quality of Buster and later Bullseye. On the
> other hand running testing/sid after the release of Stretch will not
> help to catch bugs that can be fixed through a point release.
> 
> Aurelien
> 

Most of the questions were intended to help and inspire people in how to
report what they did.  We were also interested in concrete examples,
which unfortunately did not happen in all answers.

That said, there are some questions that were intended to catch
potential issues *before* we committed to a release architecture.  As an
example, the "running testing/sid on said port" was meant to help us
spot a potential "broken release architecture discovered post release"
in the making (as happened with sparc).

As for the d-i question, I am a bit surprised that you understood it as
implicitly limited to sid/testing.

(Finally, as mentioned elsewhere, the PIE question was simply
piggy-backed because I thought it was simpler that way).

~Niels







signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Aníbal Monsalve Salazar]

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For mips, mipsel. mips64el I or my team at work
- test (most|all) packages on this architecture
- run a Debian testing or unstable system on port that I use regularly
- refer toolchain issues to our toolchain team at work
- refer kernel issues to our kernel team at work
- triage arch-specific bugs
- refer arch-related bugs to my team at work
- refer triage d-i bugs to my team at work
- test d-i regularly
- fix d-i bugs/issues
- test and supply machines for the buildds

I am a DD.

I believe the port is ready to have -fPIE/-pie enabled by default.

Aníbal Monsalve Salazar


signature.asc
Description: Digital signature

Re: FTBFS with PIE & bindnow (was: Re: Porter roll call for Debian Stretch)

[Matthias Klose]

Hi,

thanks for the work on this.  I'd like to defer the final decision to the
release team, however I'm not keen on having these defaults turned on
architectures which already have enough issues on their own.  In the recent
porters call people claim that turning on these "should not be a problem"
without giving any details why. I don't like this "laissez faire" attitude.
Without doing even a (limited) test rebuild on these architectures.  I don't
think this is the right time to turn on the defaults, that should be better done
when starting the development for the next release cycle.  If people are
confident to turn these on on amd64, fine.  If people are fine to trust Ubuntu's
experience to turn these on on ppc64el and s390x, fine as well.  But for any
other architecture please do a partial test rebuild before turning these on.

Matthias

On 09.09.2016 16:04, Bálint Réczey wrote:
> Hi,
> 
> First of all thanks to Lucas Nussbaum who ran the first test build!
> 
> 2016-08-31 19:21 GMT+02:00 Steve Langasek :
>> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>>> Hello,
 Results are available at
 https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>>
 I did a full rebuild with bindnow and PIE enabled, then rebuilt all
 failed packages with a pristine unstable chroot.
>>
 You can take a look at
 https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
 and grep for "OK Failed" (failed with PIE+bindnow, built fine in
 unstable). (There are 1188 packages failing to build)
>>
 Logs for both builds are available in the respective subdirectories.
>>
>>> Are you sure these are correct? The numbers for PIE+bindnow are a lot
>>> higher than what we see in Ubuntu, for same unmodified packages.
>>
>>> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>>
>>> amd64/ppc64el/s390x have PIE+bindnow enabled, and
>>> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
>>> range. There might be a dozen packages with PIE+bindnow fixes in
>>> ubuntu, that's not in debian, but that amount cannot be more than a
>>> dozen or two.
> 
> Is there a list available or an easy way of collecting them?
> 
>>
>> Note that enabling PIE by default is going to cause build failures for a
>> number of packages which link against static libraries, if those static
>> libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
>> this transition, so a direct comparison would require a rebootstrap test in
>> Debian instead of just a rebuild test (i.e.: test rebuild packages in
>> dependency order, and build later packages against the output of the earlier
>> rebuilds).
> 
> True. Full rebootstrapping of the archive is not available
> automatically and this
> was really useful as a first test.
> 
> I have added more dpkg patches [1] to make -pie hardening flag a noop since 
> GCC
> upstream is not interested in making -no-pie easily usable [2].
> 
> I tested the packages failing to build with the previous patches and
> many of them
> could be built.
> The logs of the remaining failures can be found here:
> https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/
> 
> If we ignore the packages having "haskell" in their name the failures are down
> to 295 packages.
> 
> I'm starting ot file bugs for the FTBFS-s.
> 
> Patched dpkg and gcc is still available for those who would like to reproduce
> the issues.
> 
> Cheers,
> Balint
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
> [3] https://people.debian.org/~rbalint/ppa/pie-bindnow/
> 

FTBFS with PIE & bindnow (was: Re: Porter roll call for Debian Stretch)

[Bálint Réczey]

Hi,

First of all thanks to Lucas Nussbaum who ran the first test build!

2016-08-31 19:21 GMT+02:00 Steve Langasek :
> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>> Hello,
>> > Results are available at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>
>> > I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> > failed packages with a pristine unstable chroot.
>
>> > You can take a look at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> > and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> > unstable). (There are 1188 packages failing to build)
>
>> > Logs for both builds are available in the respective subdirectories.
>
>> Are you sure these are correct? The numbers for PIE+bindnow are a lot
>> higher than what we see in Ubuntu, for same unmodified packages.
>
>> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>
>> amd64/ppc64el/s390x have PIE+bindnow enabled, and
>> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
>> range. There might be a dozen packages with PIE+bindnow fixes in
>> ubuntu, that's not in debian, but that amount cannot be more than a
>> dozen or two.

Is there a list available or an easy way of collecting them?

>
> Note that enabling PIE by default is going to cause build failures for a
> number of packages which link against static libraries, if those static
> libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
> this transition, so a direct comparison would require a rebootstrap test in
> Debian instead of just a rebuild test (i.e.: test rebuild packages in
> dependency order, and build later packages against the output of the earlier
> rebuilds).

True. Full rebootstrapping of the archive is not available
automatically and this
was really useful as a first test.

I have added more dpkg patches [1] to make -pie hardening flag a noop since GCC
upstream is not interested in making -no-pie easily usable [2].

I tested the packages failing to build with the previous patches and
many of them
could be built.
The logs of the remaining failures can be found here:
https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/

If we ignore the packages having "haskell" in their name the failures are down
to 295 packages.

I'm starting ot file bugs for the FTBFS-s.

Patched dpkg and gcc is still available for those who would like to reproduce
the issues.

Cheers,
Balint

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
[3] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Re: Porter roll call for Debian Stretch

[Philipp Kern]

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For s390x, I
- triage d-i bugs
- test d-i regularly
- fix d-i bugs/issues
- am currently trying to get an automated test setup running for d-i
- provide hardware for a buildd and am working with IBM to obtain
  more support on that front

I am a DD.

I have no real opinion about -fPIE/-pie on s390x. Ubuntu sets both, so
it seems sane to me to do the same in Debian.

  Philipp Kern



signature.asc
Description: OpenPGP digital signature

RE: Porter roll call for Debian Stretch

[Radovan Birdic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For mips, mipsel and mips64el, I
 - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
 - detect toolchain issues and bring it to the attention of toolchain
   maintainers whom we already have contact to,
 - triage arch-specific bugs
 - fix arch-related bugs

I am not a DD/DM.

Radovan Birdic

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXzRUOAAoJEFPgpzyfkdV4lPUIAIpd3yh1nlzUxa0xo+w3TBVG
F5CABA1vS6YiMqmV4TkELZrcO1RMOAq06sczzPchwIscY/HnMqcGO5vZPLcB9t/g
hGOmgH/+bYsgsoBYWqrlRDIMy2AG5PwbIeHYcfnX5aCcacoSIqw+nZPn6VFn4TKB
wF7aIlqBhvkwmivl2BQrPMNp84t1zvEs+JwhaEesTkAAz+JH82V+d6ww76pVxm+c
TRQ5I2fvvqsMDGJ+aCd+9gZFJWuJvv9ap2R7R64ER3cIBEDkHwX+18kkVU38xb3h
OYJO4WsXGLhPHIBWbgK4zU5d+WfW+hD+eBRHQaq7Y2xgEko9+oBqAipI3U0ap1Y=
=7OQr
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[Roger Shimizu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 17 Aug 2016 22:05:06 +0200
ni...@thykier.net wrote:

> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For armel, I
 - submit device-tree patch to upstream (linux kernel), and backport to debian 
kernel to get more devices supported
 - support new device for d-i and flash-kernel package
 - test most packages on this architecture
 - run Debian stable / testing / unstable system on port that I use regularly
 - triage arch-specific bugs
 - fix arch-related bugs
 - triage d-i bugs
 - test d-i regularly
 - fix d-i bugs/issues

I am a DM.

Altough I enabled -fPIE/-pie for most of my maintaining packages, I'm not sure 
/ I don't have enough knowledge whether it's able to be applied to all packages.
Since all other ARM porters seem agree on this, I believe it definitely 
deserves a try to enable this hardening on stretch.

Cheers,
- -- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXzEFiAAoJEKR4aw2nAzSoAekP/j4eNf0jKvmArPlPbhA7XkBk
/5u9Un4qOHBNcSMAU5YVLHkpnT1CX/C08W+/ctGbB9AnnRwyn8X0uailjedZ13jK
oZYW/kUSwWiPmOkRTeNgFepzuKL+TNsAGgjHOY4ZbzYKC+h9C0UNWwyA77L3GUep
3HA9eTrtxMAAvJPNN4AhOjMeCI3qXIZ+wLKjhT+u/OUETWly8MolBw8PUjjwW6yy
Va7ciRMQf8KL149+Pa/tYFaENoAOV6//3M2QkJyaGbfxJp3xiFFcrlw+kw6J4RyH
vNIewz78nZwN88Y7JWa2EdBVcJr0897REXpDPXK/OpzlWw0R0xqB86jtmHfc+rQJ
IiNGt5Uc4Y3mD04O6AEDDJFJnEQ/QLi8OR8/TuxHiBJ6JTv0m67KsJVgdFqeRnlz
wJqcIQAzTF1iixVXjreVqW6P/+pGNHDbh9APfUz+UV97sZ4tD2BV1K1Rgk7cPDCn
zcpVhkQRy5PzLmK315vb8h9juFDDS/18yzmXwGMnmIhv4+8GBJIQLm5gvk9NuEbw
V/hBC42+fqX6RzGCoV3M8V+A6aLSpG/BcIAQOx8ewVfzMHIFSJmYParCHKXdiX+z
WB8UBt2xCHuzg98jxU80UwR492X9WvKeb6xA8dKqOW22XzsLxaQTe+SLSaGQ7er2
cpuhCpYFDKj/TL6UE2f9
=Vckg
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[Steve Langasek]

On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
> Hello,
> > Results are available at
> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/

> > I did a full rebuild with bindnow and PIE enabled, then rebuilt all
> > failed packages with a pristine unstable chroot.

> > You can take a look at
> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
> > and grep for "OK Failed" (failed with PIE+bindnow, built fine in
> > unstable). (There are 1188 packages failing to build)

> > Logs for both builds are available in the respective subdirectories.

> Are you sure these are correct? The numbers for PIE+bindnow are a lot
> higher than what we see in Ubuntu, for same unmodified packages.

> E.g. looking at http://qa.ubuntuwire.org/ftbfs/

> amd64/ppc64el/s390x have PIE+bindnow enabled, and
> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
> range. There might be a dozen packages with PIE+bindnow fixes in
> ubuntu, that's not in debian, but that amount cannot be more than a
> dozen or two.

Note that enabling PIE by default is going to cause build failures for a
number of packages which link against static libraries, if those static
libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
this transition, so a direct comparison would require a rebootstrap test in
Debian instead of just a rebuild test (i.e.: test rebuild packages in
dependency order, and build later packages against the output of the earlier
rebuilds).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-31 12:26 GMT+02:00 Dimitri John Ledkov :
> Hello,
>
> On 30 August 2016 at 23:07, Lucas Nussbaum  wrote:
>> On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
>>> Hi Guillem,
>>>
>>> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
>>> > Hi!
>>> >
>>> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>>> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow 
>>> >> for all
>>> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>> >>
>>> >> My assumption was that this set of architectures need the least amount of
>>> >> additional work since they are tested already in Ubuntu, but I would be 
>>> >> happy
>>> >> if more ports would opt in for PIE.
>>> >>
>>> >> I plan filing wishlist bugs against dpkg and gcc with the patches
>>> >> after I rebuilt a
>>> >> few packages with the defaults.
>>> >
>>> > TBH I think PIE should in fact be safer to enable globally than
>>> > bindnow, because the latter changes the run-time behavior and things
>>> > might break (perhaps even silently) when failing to load plugins
>>> > or similar.
>>>
>>> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
>>> I don't expect too many surprises either, since other distributions
>>> already tested enabling bindnow and probably they found
>>> most issues.
>>>
>>> >
>>> > From dpkg PoV enabling both, would at least require a full-archive
>>> > rebuild, for bindnow ideally also a full autopkgtest run (as the
>>> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>>> > weeks ago mentioning he was willing to do such archive-wide rebuild).
>>>
>>> The patches at [2] seem to work well and since you expressed that you would
>>> prefer changing both toolchain and dpkg, too, I would like to suggest 
>>> running
>>> the rebuild with those patches.
>>>
>>> I think Matthias would be OK with the patch since it is very small and 
>>> brings
>>> Debian's gcc closer to Ubuntu's.
>>>
>>> Lucas, could you please run the rebuild with the three patches?
>>
>> Hi,
>>
>> Results are available at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>>
>> I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> failed packages with a pristine unstable chroot.
>>
>> You can take a look at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> unstable). (There are 1188 packages failing to build)
>>
>> Logs for both builds are available in the respective subdirectories.
>>
>> Lucas
>>
>
> Are you sure these are correct? The numbers for PIE+bindnow are a lot
> higher than what we see in Ubuntu, for same unmodified packages.
>
> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>
> amd64/ppc64el/s390x have PIE+bindnow enabled, and
> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
> range. There might be a dozen packages with PIE+bindnow fixes in
> ubuntu, that's not in debian, but that amount cannot be more than a
> dozen or two.
>
> Looking at e.g. ace buildlog the PIE+bindnow has this:
> -fno-PIE -no-pie -Wl,-z,relro -Wl,-z,now
>
> Which is bindnow without pie, instead of with pie.

Ubuntu sets bindnow in GCC in Ubuntu while it is set by dpkg in Debian.

Ace requests those flags in d/rules:
...
export DEB_BUILD_MAINT_OPTIONS =
hardening=+format,+fortify,+stackprotector,+relro,+bindnow,-pie
...

I have just started looking at the logs and I think I have a patch to GCC which
will fix many of the FTBFS-es.
I'm also looking at the GCC diff in Ubuntu.

Cheers,
Balint

>
> And same ace build fine in Ubuntu, with PIE+bindnow on the relevant
> arches. https://launchpad.net/ubuntu/+source/ace/6.3.3+dfsg-1.1
>
> --
> Regards,
>
> Dimitri.

Re: Porter roll call for Debian Stretch

[Dimitri John Ledkov]

Hello,

On 30 August 2016 at 23:07, Lucas Nussbaum  wrote:
> On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
>> Hi Guillem,
>>
>> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
>> > Hi!
>> >
>> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow 
>> >> for all
>> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>> >>
>> >> My assumption was that this set of architectures need the least amount of
>> >> additional work since they are tested already in Ubuntu, but I would be 
>> >> happy
>> >> if more ports would opt in for PIE.
>> >>
>> >> I plan filing wishlist bugs against dpkg and gcc with the patches
>> >> after I rebuilt a
>> >> few packages with the defaults.
>> >
>> > TBH I think PIE should in fact be safer to enable globally than
>> > bindnow, because the latter changes the run-time behavior and things
>> > might break (perhaps even silently) when failing to load plugins
>> > or similar.
>>
>> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
>> I don't expect too many surprises either, since other distributions
>> already tested enabling bindnow and probably they found
>> most issues.
>>
>> >
>> > From dpkg PoV enabling both, would at least require a full-archive
>> > rebuild, for bindnow ideally also a full autopkgtest run (as the
>> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>> > weeks ago mentioning he was willing to do such archive-wide rebuild).
>>
>> The patches at [2] seem to work well and since you expressed that you would
>> prefer changing both toolchain and dpkg, too, I would like to suggest running
>> the rebuild with those patches.
>>
>> I think Matthias would be OK with the patch since it is very small and brings
>> Debian's gcc closer to Ubuntu's.
>>
>> Lucas, could you please run the rebuild with the three patches?
>
> Hi,
>
> Results are available at
> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>
> I did a full rebuild with bindnow and PIE enabled, then rebuilt all
> failed packages with a pristine unstable chroot.
>
> You can take a look at
> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
> and grep for "OK Failed" (failed with PIE+bindnow, built fine in
> unstable). (There are 1188 packages failing to build)
>
> Logs for both builds are available in the respective subdirectories.
>
> Lucas
>

Are you sure these are correct? The numbers for PIE+bindnow are a lot
higher than what we see in Ubuntu, for same unmodified packages.

E.g. looking at http://qa.ubuntuwire.org/ftbfs/

amd64/ppc64el/s390x have PIE+bindnow enabled, and
i386/armhf/arm64/powerpc do not. here is nothing in the thousands
range. There might be a dozen packages with PIE+bindnow fixes in
ubuntu, that's not in debian, but that amount cannot be more than a
dozen or two.

Looking at e.g. ace buildlog the PIE+bindnow has this:
-fno-PIE -no-pie -Wl,-z,relro -Wl,-z,now

Which is bindnow without pie, instead of with pie.

And same ace build fine in Ubuntu, with PIE+bindnow on the relevant
arches. https://launchpad.net/ubuntu/+source/ace/6.3.3+dfsg-1.1

-- 
Regards,

Dimitri.

Re: Porter roll call for Debian Stretch

[Lucas Nussbaum]

On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
> Hi Guillem,
> 
> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
> > Hi!
> >
> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for 
> >> all
> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
> >>
> >> My assumption was that this set of architectures need the least amount of
> >> additional work since they are tested already in Ubuntu, but I would be 
> >> happy
> >> if more ports would opt in for PIE.
> >>
> >> I plan filing wishlist bugs against dpkg and gcc with the patches
> >> after I rebuilt a
> >> few packages with the defaults.
> >
> > TBH I think PIE should in fact be safer to enable globally than
> > bindnow, because the latter changes the run-time behavior and things
> > might break (perhaps even silently) when failing to load plugins
> > or similar.
> 
> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
> I don't expect too many surprises either, since other distributions
> already tested enabling bindnow and probably they found
> most issues.
> 
> >
> > From dpkg PoV enabling both, would at least require a full-archive
> > rebuild, for bindnow ideally also a full autopkgtest run (as the
> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
> > weeks ago mentioning he was willing to do such archive-wide rebuild).
> 
> The patches at [2] seem to work well and since you expressed that you would
> prefer changing both toolchain and dpkg, too, I would like to suggest running
> the rebuild with those patches.
> 
> I think Matthias would be OK with the patch since it is very small and brings
> Debian's gcc closer to Ubuntu's.
> 
> Lucas, could you please run the rebuild with the three patches?

Hi,

Results are available at
https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/

I did a full rebuild with bindnow and PIE enabled, then rebuilt all
failed packages with a pristine unstable chroot.

You can take a look at
https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
and grep for "OK Failed" (failed with PIE+bindnow, built fine in
unstable). (There are 1188 packages failing to build)

Logs for both builds are available in the respective subdirectories.

Lucas

Re: Porter roll call for Debian Stretch

[Fernando Seiti Furusato]

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For ppc64el, I
- test most packages on this architecture
- run a Debian testing or unstable system on port that I use regularly
- triage arch-specific bugs
- fix arch-related bugs
- test d-i with some regularity
- am currently woking on providing ppc64el hardware so to include the
arch to ci.d.n

I am not a DD/DM.

I believe the port is ready to have -fPIE/-pie enabled by default.

Fernando Seiti Furusato




signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Yunqiang Su]

Sorry for the previous post without signature.

  Hi,

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the Stretch release (est. end
  of 2020):

  For mips, mipsel and mips64el, I
  - test most packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
jenkins.d.n (etc.)
  - run other automated tests outside the Debian QA services
 Run daily build test
 Run autopkgtest
  - ...

  I am a DD

  I believe the ports *are* ready to have -fPIE/-pie enabled by default.

  YunQiang Su

> 在 2016年8月31日，00:04，YunQiang Su  写道：
> 
>  Hi,
> 
>  I am an active porter for the following architectures and I intend
>  to continue this for the lifetime of the Stretch release (est. end
>  of 2020):
> 
>  For mips, mipsel and mips64el, I
>  - test most packages on this architecture
>  - run a Debian testing or unstable system on port that I use regularly
>  - fix toolchain issues
>  - triage arch-specific bugs
>  - fix arch-related bugs
>  - triage d-i bugs
>  - test d-i regularly
>  - fix d-i bugs/issues
>  - maintain buildds
>  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
>jenkins.d.n (etc.)
>  - run other automated tests outside the Debian QA services
> Run daily build test
> Run autopkgtest
>  - ...
> 
>  I am a DD
> 
>  I believe the ports *are* ready to have -fPIE/-pie enabled by default.
> 
>  YunQiang Su
> 
> On Sun, Aug 28, 2016 at 11:53 PM, Aurelien Jarno  wrote:
>> On 2016-08-17 22:05, ni...@thykier.net wrote:
>>> Hi,
>>> 
>>> Like last release, we are doing a roll call for porters of all release
>>> architectures.  If you are an active porter behind one of the [release
>> 
>> Does it really concerns *all* release architectures? Traditionally amd64
>> and i386 have been granted waivers as "the toolchain maintainers are
>> happy to support" these architectures "as-is". That said the toolchain
>> maintainers do not fix ports specific bugs outside of the toolchain.
>> 
>> While I fully agree that we can have a waiver for amd64 due to being the
>> de facto standard architecture, it seems that a few leaf packages do
>> not build on i386 and that we have no porters to fix them. That is
>> probably still fine, but I wonder how fast the number of such packages
>> will increase in the future.
>> 
>>> architectures] for the entire lifetime of Debian Stretch (est. end of
>>> 2020), please respond with a signed email containing the following
>> 
>> What is the relation between the end of support of Stretch...
>> 
>>> before Friday, the 9th of September:
>> 
>>> * Which architectures are you committing to be an active porter for?
>>> * Please describe recent relevant porter contributions.
>>> * Are you running/using Debian testing or sid on said port(s)?
>>> * Are you testing/patching d-i for the port(s)?
>>> * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>   also apply to this port? [0]
>> 
>> ... and the above questions?
>> 
>> I fully agree that running testing/sid, fixing bugs or working on d-i up
>> to the release of Stretch will improve its quality. But after the
>> release it will improve the quality of Buster and later Bullseye. On the
>> other hand running testing/sid after the release of Stretch will not
>> help to catch bugs that can be fixed through a point release.
>> 
>> Aurelien
>> 
>> --
>> Aurelien Jarno  GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
> 
> 
> 
> --
> YunQiang Su



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Porter roll call for Debian Stretch

[YunQiang Su]

  Hi,

  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the Stretch release (est. end
  of 2020):

  For mips, mipsel and mips64el, I
  - test most packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
jenkins.d.n (etc.)
  - run other automated tests outside the Debian QA services
 Run daily build test
 Run autopkgtest
  - ...

  I am a DD

  I believe the ports *are* ready to have -fPIE/-pie enabled by default.

  YunQiang Su

On Sun, Aug 28, 2016 at 11:53 PM, Aurelien Jarno  wrote:
> On 2016-08-17 22:05, ni...@thykier.net wrote:
>> Hi,
>>
>> Like last release, we are doing a roll call for porters of all release
>> architectures.  If you are an active porter behind one of the [release
>
> Does it really concerns *all* release architectures? Traditionally amd64
> and i386 have been granted waivers as "the toolchain maintainers are
> happy to support" these architectures "as-is". That said the toolchain
> maintainers do not fix ports specific bugs outside of the toolchain.
>
> While I fully agree that we can have a waiver for amd64 due to being the
> de facto standard architecture, it seems that a few leaf packages do
> not build on i386 and that we have no porters to fix them. That is
> probably still fine, but I wonder how fast the number of such packages
> will increase in the future.
>
>> architectures] for the entire lifetime of Debian Stretch (est. end of
>> 2020), please respond with a signed email containing the following
>
> What is the relation between the end of support of Stretch...
>
>> before Friday, the 9th of September:
>
>>  * Which architectures are you committing to be an active porter for?
>>  * Please describe recent relevant porter contributions.
>>  * Are you running/using Debian testing or sid on said port(s)?
>>  * Are you testing/patching d-i for the port(s)?
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
>
> ... and the above questions?
>
> I fully agree that running testing/sid, fixing bugs or working on d-i up
> to the release of Stretch will improve its quality. But after the
> release it will improve the quality of Buster and later Bullseye. On the
> other hand running testing/sid after the release of Stretch will not
> help to catch bugs that can be fixed through a point release.
>
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net



-- 
YunQiang Su

Re: Porter roll call for Debian Stretch

[Aron Xu]

Hi,

I am an active porter for the following architectures and I intend to continue
this for the lifetime of Streth release (est. end of 2020):

For mips, mipsel and mips64el, I
- run several Debian testing/unstable system on real mipsel/mips64el hardware
- maintain 3 mipsel/mips64el machines at data center for porting purpose
- triage arch-specific bugs
- fix arch-related bugs

I am a DD.


Regards,
Aron


signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[Aurelien Jarno]

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For mips, mipsel and mips64el, I
- run a Debian testing system on a real mipsel machine that I use
  regularly
- run a Debian stable system on a real mipsel machine that I use
  regularly
- run a Debian testing or unstable system on emulated mips, mipsel and
  mips64el machines that I use regularly
  regularly
- fix toolchain issues
- triage arch-specific bugs
- fix arch-related bugs
- test d-i more or less regularly using QEMU
- fix d-i bugs/issues
- maintain buildds
- fix kernel issues in stable and testing/unstable

I am a DD.

The mips* ports do support -fPIE/-pie and we already have binaries in
the archive built that way. I believe the ports are ready to have
-fPIE/-pie enabled by default. That said I am not aware of another
distribution doing so (Fedora still uses pie only for a few binaries
just like us), so we should probably not do that at the last minute
before the Stretch release.

Aurelien Jarno

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Aurelien Jarno]

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For s390x, I
- run a Debian testing system on an emulated s390x machine, that I use
  regularly
- fix toolchain issues, though in practice there is almost nothing to do
- triage arch-specific bugs
- fix arch-related bugs
- test d-i on an emulated machine from time to time
- maintain buildds

I am a DD.

I believe the port is ready to have -fPIE/-pie enabled by default,
Ubuntu has proven so.

Aurelien Jarno

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Aurelien Jarno]

On 2016-08-17 22:05, ni...@thykier.net wrote:
> Hi,
> 
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release

Does it really concerns *all* release architectures? Traditionally amd64
and i386 have been granted waivers as "the toolchain maintainers are
happy to support" these architectures "as-is". That said the toolchain
maintainers do not fix ports specific bugs outside of the toolchain.

While I fully agree that we can have a waiver for amd64 due to being the
de facto standard architecture, it seems that a few leaf packages do
not build on i386 and that we have no porters to fix them. That is
probably still fine, but I wonder how fast the number of such packages
will increase in the future.

> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following

What is the relation between the end of support of Stretch...

> before Friday, the 9th of September:
 
>  * Which architectures are you committing to be an active porter for?
>  * Please describe recent relevant porter contributions.
>  * Are you running/using Debian testing or sid on said port(s)?
>  * Are you testing/patching d-i for the port(s)?
>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>also apply to this port? [0]

... and the above questions?

I fully agree that running testing/sid, fixing bugs or working on d-i up
to the release of Stretch will improve its quality. But after the
release it will improve the quality of Buster and later Bullseye. On the
other hand running testing/sid after the release of Stretch will not
help to catch bugs that can be fixed through a point release.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

RE: Porter roll call for Debian Stretch

[Daniel Knezevic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For mips, mipsel and mips64el, I
 - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
 - detect toolchain issues and bring it to the attention of toolchain
   maintainers whom we already have contact to,
 - triage arch-specific bugs
 - fix arch-related bugs

I am not a DD/DM.

Daniel Knezevic

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXwEEeAAoJEJg7dWwzb8w/h3AH/Ar0NCDJL0tmMKOFDsZT/xsG
NaDRr63/zxz4wYNWw0zRcJIYZhfhsL6h03qmoTvSqWe9TCy5+SBjpepIbmzwiu+k
UAdX8ob1pYd0WJIataARy8wvhY/52LMjufcEVUp8dguNGmTCnkVgL7bN+PaYG+il
gziGeMdmDRHyszGlpIOd7byf090gMWtnuxkSofqwxlLdOG9szmUQ88YFy19F9mNW
/b3BQcxqNj6svluEjNMeozmfhcmB2EdRJR60zonL67TDf/Yj8FO7SiiVpaL2JOQV
VtWP2SngZrDnJpzbluF+Cu/23S/ScYnD7arKhWJdeJKHOkr1nXPOYAs4EE7/OoY=
=SvJh
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[James Cowgill]

Hi,

On 17/08/16 21:05, ni...@thykier.net wrote:
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  * Which architectures are you committing to be an active porter for?

I'm an active porter for mips, mipsel and mips64el.

>  * Please describe recent relevant porter contributions.

Numerous mips64el related bugs and some assistance bootstrapping parts
of it. Lately I've been looking at some toolchain issues and bugs in
various other packages.

>  * Are you running/using Debian testing or sid on said port(s)?

Yes we have a number of mips machines running testing. They are mostly
used for development (some quite heavily used). I test common packages
on them (I'd be surprised if anyone can claim they test *all* packages
on their arch).

>  * Are you testing/patching d-i for the port(s)?

I don't use d-i a huge amount with the port unfortunately. Having said
that I am about to setup another machine so I'll try it out on that :)

>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>also apply to this port? [0]

I'm not aware of any issues with enabling -fPIC on mips arches so I
think you can go ahead with it. PIE is already enabled in a number of
packages and there doesn't seem to be any issues with them mips.

I'm a DD

James



signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Frederic Bonnard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For ppc64el, I
- - test most packages on this architecture
- - run a Debian testing or unstable system on port that I use regularly
- - fix arch-related bugs
- - triage d-i bugs
- - test d-i regularly
- - fix d-i bugs/issues

I am a DM.

About -fPIE/-pie, I'd say my packages should be ready to have it enabled by
default, even if, for skiboot package, on Ubuntu (with gcc having pie by
default since 16.04) I had to disable (or it crashed) it with -no-pie because
of assembly code being used for some part and that will not be changed soon by
upstream I guess.
In another package, I had another issue where a static test binary was compiled
with -pie because of hardening and -static, which produced a dynamically linked
executable.. which failed at runtime. I'm not an expert but gcc does not seem
to be ready for static+pie and it didn't complain either about both flags being 
used
( https://gcc.gnu.org/ml/gcc/2015-06/msg8.html )

I always add DEB_BUILD_MAINT_OPTIONS = hardening=+all to my packages (else
lintian reports about "hardening-no-pie"), but in default hardening there is no 
pie,
and I'm not sure all packages do so.
Checking https://lintian.debian.org/tags/hardening-no-pie.html, 
59088 packages have "hardening-no-pie" lintian... so pie doesn't not seem really
tested to me.
As I had 3 issues out of ~10 packages I maintain, I'm unsure of the result on 
the
whole archive, but it's worth trying.

Frédéric Bonnard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXwDvrAAoJEGt0mPy5s1isGhEP/AwlaXn0BhLsFeW7E3L0H75X
B1gqGAbqGYNx4d8KX1uWX56khwwUh2Wt91ENNttYeUqQL5qm4juts03sRINnrUFD
x1kNJ7nrjTF4Ecc2sICLL/viA7wM95r+KDH4vuSwcr4eiQeTqOWp1zFuIOKlez71
l0cJCKZA+Y7Znz1/Q+53OnREk50rtrT/zf41qqMm7/ZIqXxec4fm+40i4BLAMxVT
RtQUp/xRY4sIwqTP/JlDN1PuIq1HqW992j09C1tBb3Kle/WNo/efG4q3Z9uCi9wn
oFbmrnQO9z757G04nyMsy+u9AetHUeu9JFEYxErXXvZvH/j5JSY7Gd+tqIrQqrHY
bNilGAhFFUsL/1cOB6InohAaj+aIwfzoxiDx9KHV7qiP/TKJONZgs83UCo9AUH+M
kSBuLRt/+xP9yKTIBuQb8G52EoXkH1xnJEE6KUfpEwCeee9lifoNvyabEg+/Hs0j
DKSuS0YXA+tikeEP09m4EbTA8g213TrbvPfojG37ODsOVsZ7IxmFrMvPuDUfZICz
1zJ+olgTr1Ym/WpbSBDbklrtEHXc/Z//lyUTl98Mksn1QT+/Sq1QbiSY7wKqE7ky
PgDLtkjnmF6xO+zQ6/oQJjf8994q6SNQ9yFkkPq1Z15AeqWH83FlIV5zkXJizWzN
42VSValqXtOHkpuLr9Zb
=uobB
-END PGP SIGNATURE-

RE: Porter roll call for Debian Stretch

[Dejan Latinovic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For mips, mipsel and mips64el, I
 - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
 - detect toolchain issues and bring it to the attention of toolchain
   maintainers whom we already have contact to,
 - triage arch-specific bugs
 - fix arch-related bugs

I am not a DD/DM.

Dejan Latinovic 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXwCyhAAoJEDMjygTNXW5pdSkH/01mG18xVhNxmAoRSwv45ZsQ
V3GnUpKoUNBiANO0JHG/5T2AIKE/bDQP5atkNdbH6OaawYnTjK807er0oNaBQNtV
r0eSzJGCnF2+LQGxg8FJABRhSu+e8+TdoXgVTYodq3w/joGRPh0KqA37NtvKrlKl
7rqgJpbvDmfHrlCyZANlntVO+90FKZSbU543K0JHR0lMtL3uv7jmGN68rRTgQ+7r
nkLQO1BuMeZcXT1bc8XavatRS5P/HrUlBC83PRka+OziornHrYH/FzLrCGDjYKAq
KpyvOFkVgtCmdeh3EVYE6vADSecshD2uVkw19TQepYURk699hNPEGySABbm+KHg=
=XAXS
-END PGP SIGNATURE-

Porter roll call for Debian Stretch

[Erwan Prioul]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For ppc64el, I
- - test most packages on this architecture
- - run a Debian testing or unstable system on port that I use regularly
- - fix arch-related bugs
- - test d-i regularly
- - run other automated tests outside the Debian QA services: 
I maintain a tool that installs daily image and runs tests
The web report is here: http://ftp.unicamp.br/pub/ppc64el/DAT/

I am not a DD/DM

I believe the port is ready to have -fPIE/-pie enabled by default.
   
Erwan Prioul
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXvwgZAAoJEAJTiVBp/xW+vSsP/AtE2nCRN+fHIH+gtDgAU3QH
3wZlrRZJCG8G6vEaRE+JMNG+xhc/maeETWmV3SZU39hk2pk7/PGpeTHcQ6p0xbES
Z4CVZes1DXDFqhyg2LcI+Fiyp9G6M9CaMclk8c7edzfUl6hVx2oQy8+yfgD6HBUs
qBIjO98Jl+XgxD3k/yPOtIutSSXCRHKANYSHSt0YLRHh1jjFX8TSVLxxRJDEOrgO
/UERt7Qv8dqVzTCm1+2NQDXu3Hzph1pNpLiN3IwO6B0YqCWb+eGL9ON7wyifj+Ta
MOpjdNT0nAfs5TNtIDZBgmjFPkFTnWYWXaqMjcm3vf5XzA5zarQvU/Y9e9PmrH4A
M9/T5Xh3lpPSrvzbssFj4iJE4dfa959vp0lbJbfrNpBr3B3nh+9TjJsRnFMLiZUc
GzS3CHXV4Eh8Z0Q1Jx3Rm4QrKqDWDv3Gk+NqTtVbrONCqx4G1fMlNJOajyr/J+I9
OHpWbDUC022qIP74SE5B8X9nmccJ8oN8cBkonkgyS8rxAJqsczxo+MFBLKDLdEFy
RtT9F0x9tTgWBnvQb2wCibQvZRBN68El5+8+6iNTItj3xmKJkReRzxQERGWXQa9E
ra2E/grLewdBfD/L/V10YkcrDKg0OrhcHQ9tyNX/2cm0ukCq3bmkA011LJ7+X2qH
u47DdYwqoprUtKIQQ9Kr
=/gmO
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[Balint Reczey]

On 08/22/2016 07:12 PM, Bálint Réczey wrote:
> Hi Guillem,
> 
> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
>> Hi!
>>
>> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for 
>>> all
>>> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>>
>>> My assumption was that this set of architectures need the least amount of
>>> additional work since they are tested already in Ubuntu, but I would be 
>>> happy
>>> if more ports would opt in for PIE.
>>>
>>> I plan filing wishlist bugs against dpkg and gcc with the patches
>>> after I rebuilt a
>>> few packages with the defaults.
>>
>> TBH I think PIE should in fact be safer to enable globally than
>> bindnow, because the latter changes the run-time behavior and things
>> might break (perhaps even silently) when failing to load plugins
>> or similar.
> 
> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
> I don't expect too many surprises either, since other distributions
> already tested enabling bindnow and probably they found
> most issues.
> 
>>
>> From dpkg PoV enabling both, would at least require a full-archive
>> rebuild, for bindnow ideally also a full autopkgtest run (as the
>> updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>> weeks ago mentioning he was willing to do such archive-wide rebuild).
> 
> The patches at [2] seem to work well and since you expressed that you would
> prefer changing both toolchain and dpkg, too, I would like to suggest running
> the rebuild with those patches.
> 
> I think Matthias would be OK with the patch since it is very small and brings
> Debian's gcc closer to Ubuntu's.
> 
> Lucas, could you please run the rebuild with the three patches?
> 
> I'll attach the patches to the bug reports.

For the record I have opened #835146, #835148 and #835149 against dpkg
and gcc-6 with the patches.

> 
> [2] https://people.debian.org/~rbalint/ppa/pie-bindnow/
> 

Re: Porter roll call for Debian Stretch

[Breno Leitao]

Hello Mattia,

On Mon, Aug 22, 2016 at 03:51:17PM +, Mattia Rizzolo wrote:
> On Mon, Aug 22, 2016 at 12:00:50PM -0300, Breno Leitao wrote:
> > - maintain/provide hardware for automated tests on ci.d.n,
> >   jenkins.d.n (etc.)
> 
> At jenkins.d.n we don't have any ppc64el slave; I don't know whether you
> recently did private offers to Holger alone about this, but I was not
> informated.  Anyway "maintain" is for sure inappropriate.
> 
> Also, ci.d.n doesn't build for ppc64el currently, so I'm wary of that
> too.

You are correct and 'maintain' is not corrected used here. I should say:

 * Work to provide hardware for automated tests on ci.d.b and jenkins.d.n.


pgpJcqBRCrlFN.pgp
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi Guillem,

2016-08-21 14:02 GMT+02:00 Guillem Jover :
> Hi!
>
> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for 
>> all
>> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>
>> My assumption was that this set of architectures need the least amount of
>> additional work since they are tested already in Ubuntu, but I would be happy
>> if more ports would opt in for PIE.
>>
>> I plan filing wishlist bugs against dpkg and gcc with the patches
>> after I rebuilt a
>> few packages with the defaults.
>
> TBH I think PIE should in fact be safer to enable globally than
> bindnow, because the latter changes the run-time behavior and things
> might break (perhaps even silently) when failing to load plugins
> or similar.

Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
I don't expect too many surprises either, since other distributions
already tested enabling bindnow and probably they found
most issues.

>
> From dpkg PoV enabling both, would at least require a full-archive
> rebuild, for bindnow ideally also a full autopkgtest run (as the
> updated dpkg FAQ states now, after Lucas Nussbaum approached me some
> weeks ago mentioning he was willing to do such archive-wide rebuild).

The patches at [2] seem to work well and since you expressed that you would
prefer changing both toolchain and dpkg, too, I would like to suggest running
the rebuild with those patches.

I think Matthias would be OK with the patch since it is very small and brings
Debian's gcc closer to Ubuntu's.

Lucas, could you please run the rebuild with the three patches?

I'll attach the patches to the bug reports.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Re: Porter roll call for Debian Stretch

[Mattia Rizzolo]

On Mon, Aug 22, 2016 at 12:00:50PM -0300, Breno Leitao wrote:
> - maintain/provide hardware for automated tests on ci.d.n,
>   jenkins.d.n (etc.)

At jenkins.d.n we don't have any ppc64el slave; I don't know whether you
recently did private offers to Holger alone about this, but I was not
informated.  Anyway "maintain" is for sure inappropriate.

Also, ci.d.n doesn't build for ppc64el currently, so I'm wary of that
too.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Porter roll call for Debian Stretch

[Breno Leitao]

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For ppc64el, I
- test most of the important packages on this architecture
- run a Debian testing or unstable system on port that I use regularly
- fix or address toolchain issues
- triage arch-specific bugs
- fix arch-related bugs
- triage d-i bugs
- test d-i regularly on Bare-metal and PowerVM hypervisor
  * http://ftp.unicamp.br/pub/ppc64el/DAT/
- fix d-i bugs/issues
- maintain/provide hardware for automated tests on ci.d.n,
  jenkins.d.n (etc.)

I am DD.

I believe the port is ready to have -fPIE/-pie enabled by default. Other
distros are using it without major issues.

Breno Leitao
lei...@debian.org


pgpcHOzYQIos8.pgp
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Wookey]

On 2016-08-17 22:05 +0200, ni...@thykier.net wrote:

> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  * Which architectures are you committing to be an active porter for?

arm64, armhf, (and armel in maintenance mode).

>  * Please describe recent relevant porter contributions.

arm64 bootstrap, much initial package porting, bugreps and NMUs. 
arm64 buildd admin. Backup onsite admin for build machines at ARM site.
multiarch, bootstrapping, cross-building and cross-toolchain work.

>  * Are you running/using Debian testing or sid on said port(s)?

yes, but not on main daily usage machines due to criminal lack of
dogfooding at ARM meaning no-one makes suitable hardware yet. One
day...

>  * Are you testing/patching d-i for the port(s)?

Yes, regularly, as I get hardware to test.

>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>also apply to this port? [0]

This is probably not well-tested on arm64, but it should work fine,
with some (believed-to-be-small) performance cost, so defaulting to it
seems sensible.

I understand that the performance penalty on armhf/armel is
significantly larger. Some testing to see whether it is a reasonable
tradeoff would be a good idea.
 

I am a DD


Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Ian Campbell:
> On Wed, 2016-08-17 at 22:05 +0200, ni...@thykier.net wrote:
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
> 
> OOI does this relate somehow to the porter roll-call/architecture
> qualification or was this just a convenient mail to piggy-back this
> question to all porters on?
> 
> Or to put it another way, is there any penalty/risk (from a release
> PoV) to an arch which says no here?
> 
> Ian.
> 

There is no requirement for any given port to have PIE by default in
Stretch.  It was simply convenient to "piggy-back" it.

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Ian Campbell]

On Wed, 2016-08-17 at 22:05 +0200, ni...@thykier.net wrote:
>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>    also apply to this port? [0]

OOI does this relate somehow to the porter roll-call/architecture
qualification or was this just a convenient mail to piggy-back this
question to all porters on?

Or to put it another way, is there any penalty/risk (from a release
PoV) to an arch which says no here?

Ian.

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>
> My assumption was that this set of architectures need the least amount of
> additional work since they are tested already in Ubuntu, but I would be happy
> if more ports would opt in for PIE.
> 
> I plan filing wishlist bugs against dpkg and gcc with the patches
> after I rebuilt a
> few packages with the defaults.

TBH I think PIE should in fact be safer to enable globally than
bindnow, because the latter changes the run-time behavior and things
might break (perhaps even silently) when failing to load plugins
or similar.

From dpkg PoV enabling both, would at least require a full-archive
rebuild, for bindnow ideally also a full autopkgtest run (as the
updated dpkg FAQ states now, after Lucas Nussbaum approached me some
weeks ago mentioning he was willing to do such archive-wide rebuild).

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-21 8:22 GMT+02:00 Niels Thykier :
> Kurt Roeckx:
>> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>also apply to this port? [0]
>>
>> If -fPIE is the default will -fPIC override it?
>>
>> It will also default to tell the linker to use -pie, but then
>> don't do it when you want to create a shared library?
>>
>
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.
>
> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).
>
> Regardless, it seems to "just work(TM)" if you pass the proper flags
> when compiling your SOs.
>
>>>From what I understand, depending on what the .o file is going to
>> be used for you want different things:
>> - shared library: -fPIC
>> - executable: -fPIC or -fPIE both work, but prefer -fPIE
>> - static library: Same as executables
>>
>> For static libraries we now have a policy to not use -fPIC,
>> should that then get replaced by using -fPIE?
>>
>>
>>
>> Kurt
>>
>
> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.

My assumption was that this set of architectures need the least amount of
additional work since they are tested already in Ubuntu, but I would be happy
if more ports would opt in for PIE.

I plan filing wishlist bugs against dpkg and gcc with the patches
after I rebuilt a
few packages with the defaults.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/


>
> Thanks,
> ~Niels
>
> [1] Example spec files for this case seems to be something like:
>
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
>
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
>
> NB: I manually carved them out of a diff without testing them.
>

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Kurt Roeckx:
> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
> 
> If -fPIE is the default will -fPIC override it?
> 
> It will also default to tell the linker to use -pie, but then
> don't do it when you want to create a shared library?
> 

I believe so.  At least, Ubuntu made PIE default in their compiler
without having to change all SO packages to still build.

Admittedly, it could also be that GCC uses some built "compiler spec"
files for this case (a la an implicit "-specs=$FILE"), which are similar
to those Redhat uses for this purposes (see [1] for an example of such
files).

Regardless, it seems to "just work(TM)" if you pass the proper flags
when compiling your SOs.

>>From what I understand, depending on what the .o file is going to
> be used for you want different things:
> - shared library: -fPIC
> - executable: -fPIC or -fPIE both work, but prefer -fPIE
> - static library: Same as executables
> 
> For static libraries we now have a policy to not use -fPIC,
> should that then get replaced by using -fPIE?
> 
> 
> 
> Kurt
> 

Honestly, I had not thought about that.  From the looks of it, de facto
we will end up with -fPIE being the default for static libraries as well.
  I would be supporting that change on the assumption that it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).

Thanks,
~Niels

[1] Example spec files for this case seems to be something like:

pie-compile.specs
"""
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
"""

pie-link.specs:
"""
*self_spec:
+ %{!shared:%{!r:-pie}}
"""

NB: I manually carved them out of a diff without testing them.

Re: Porter roll call for Debian Stretch

[Vagrant Cascadian]

>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the Stretch release (est. end
>   of 2020):

Some people have suggested to me that I'm an active porter... maybe it
just sort of happens to people. I'll likely continue to help in the
following ways during the stretch release.


>   For armhf, I
>   - triage d-i bugs
>   - test d-i regularly
>   - fix d-i bugs/issues

I do some debian-installer testing; the frequency and regularity varies
depending on what projects I'm actively working on.

I've submitted bugs and patches to enable several new armhf platforms by
getting needed configuration options enabled in the linux, flash-kernel,
debian-installer and u-boot packages.

As the active u-boot maintainer, I do quite a bit of u-boot testing, and
usually test new uploads against most of the armhf boards I have access
to. Most of the platforms enabled in u-boot are armhf, followed by armel
and arm64.


>   - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
> jenkins.d.n (etc.)

Maintain 20+ build machines for the reproducible build network as part
of jenkins.debian.net:

  https://tests.reproducible-builds.net

Most of them do run debian stable with stable or backports kernels, and
routinely build packages in experimental, unstable and testing chroots.


>   

I am a DD.

I don't have much of any opinions on compiler options to enable by
default.


I'll likely also start working more on arm64, but we'll see what the
future holds in retrospect. I also have some waning experience with
armel systems, which might seem less and less relevent by the end of
stretch.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Steve McIntyre]

On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>
> * Which architectures are you committing to be an active porter for?
> * Please describe recent relevant porter contributions.
> * Are you running/using Debian testing or sid on said port(s)?
> * Are you testing/patching d-i for the port(s)?
> * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>   also apply to this port? [0]
>
>Feel free to use the following template as your reply:

Hi Niels,

I'm a porter for armel, armhf and arm64.

For all 3 architectures, I host and maintain buildds, work on d-i and
installation support, work on core arch-specific things like toolchain
and glibc and I triage and fix other bugs.

I'm a DD.

In terms of -fPIE/-pie, I'm happt that we are ready to enable by
default. I've checked with the gcc maintainers in ARM too, and the
worst effect we expect is a small performance impact. If anything more
crops up, we have expert help available.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt


signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch [arm]

[Martin Michlmayr]

* ni...@thykier.net  [2016-08-17 22:05]:
>  * Which architectures are you committing to be an active porter for?
>  * Please describe recent relevant porter contributions.
>  * Are you running/using Debian testing or sid on said port(s)?

For armel, armhf and arm64, I:
 * Triage d-i bugs
 * Test d-i regularly
 * Fix d-i bugs/issues
 * Test latest kernels
 * Enable kernel options
 * Write and update documentation

armel has support for 2 major SoC platorms, Orion and Kirkwood (both
use the "marvell" kernel flavour in stretch).

I posted a call for help regarding Orion a few months ago.  Since
then, Roger Shimizu has been very active with Buffafo devices.  I
fixed a major problem with HP mv2120 devices (#809611).  I also
brought back installer support for Orion-based QNAP devices a few
months ago.  Orion devices are quite old now but they are in good
shape for stretch.

We support a number of Kirkwood devices (mostly NAS) and they
generally work well.  I don't see any concerns there from a d-i or
kernel perspective.

armhf: Karsten Merker, Ian Campbell and Vagrant Cascadian have done a
great job with d-i support for armhf.  I recently enabled some kernel
options for 32-bit NVIDIA Tegra and wrote some documentation.

arm64: Steve McIntyre has done great work getting UEFI arm64 platforms
supported in d-i.  I am working on getting some arm64 platforms
supported that use u-boot.  A new flash-kernel was uploaded recently
and there's more to come.

I wrote some documentation about running Debian on ARM devices, e.g.:
https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1
https://wiki.debian.org/InstallingDebianOn/Seagate/PersonalCloud

If you need more evidence, check out the changelogs for
debian-installer, flash-kernel, mv2120-utils and linux.

I'm a DD.

Martin Michlmayr

-- 
Martin Michlmayr
http://www.cyrius.com/


signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[Kurt Roeckx]

On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>also apply to this port? [0]

If -fPIE is the default will -fPIC override it?

It will also default to tell the linker to use -pie, but then
don't do it when you want to create a shared library?

>From what I understand, depending on what the .o file is going to
be used for you want different things:
- shared library: -fPIC
- executable: -fPIC or -fPIE both work, but prefer -fPIE
- static library: Same as executables

For static libraries we now have a policy to not use -fPIC,
should that then get replaced by using -fPIE?



Kurt

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Martin Michlmayr:
> * ni...@thykier.net  [2016-08-17 22:05]:
>> 2020), please respond with a signed email containing the following
>> before Friday, the 9th of September:
> 
> Can you please specify where to respond to?  I don't think dozens of
> emails to -ports and -devel make any sense.
> 

Ah, sorry I had indeed forgotten to set Reply-To. :)

> Maybe debian-release with CC debian- or to you personally and
> you'll collect the info?
> 

Please send the replies to debian-release. :)

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Martin Michlmayr]

* ni...@thykier.net  [2016-08-17 22:05]:
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:

Can you please specify where to respond to?  I don't think dozens of
emails to -ports and -devel make any sense.

Maybe debian-release with CC debian- or to you personally and
you'll collect the info?

-- 
Martin Michlmayr
http://www.cyrius.com/

Porter roll call for Debian Stretch

[niels]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Like last release, we are doing a roll call for porters of all release
architectures.  If you are an active porter behind one of the [release
architectures] for the entire lifetime of Debian Stretch (est. end of
2020), please respond with a signed email containing the following
before Friday, the 9th of September:

 * Which architectures are you committing to be an active porter for?
 * Please describe recent relevant porter contributions.
 * Are you running/using Debian testing or sid on said port(s)?
 * Are you testing/patching d-i for the port(s)?
 * If we were to enable -fPIE/-pie by default in GCC-6, should that change
   also apply to this port? [0]


Feel free to use the following template as your reply:

"""
  Hi,
  
  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the Stretchj release (est. end
  of 2020):

  For , I
  - test (most|all) packages on this architecture
  - run a Debian testing or unstable system on port that I use regularly
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - triage d-i bugs
  - test d-i regularly
  - fix d-i bugs/issues
  - maintain buildds
  - maintain/provide hardware for (or assist with) automated tests on ci.d.n,
jenkins.d.n (etc.)
  - run other automated tests outside the Debian QA services (Please describe
these)
  - ...
  
  

  I believe the port  ready to have -fPIE/-pie enabled by default.
  
  
"""

Niels, on behalf of the release team

[0] Enabling -fPIE/-fpie by default would harden debian systems against certain
attacks.  See https://lintian.debian.org/tags/hardening-no-pie.html for
more details.
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXtMMHAAoJEAVLu599gGRCArEP/j259ofvIXh0NE5uLqOtA8vu
4J84y6o15rHgg0iUGFwqAhk6GVtbvpxxqgH5vpj90UmUyIe55tHL7mf4NDjbEu9x
w12DezTHpyGmmGSNNkQO6MV6FE0JeDjlSUlgBU27RamCQ7uKWCCNMMV48YZ/vtA0
4gj8KZtYxUNY5PEaCyV2WHXvU4sMuetnqZ4JfVDykCWlHV6yDCWMN/crar7XyWll
iulUZFn9KlioVlSfQbkhrdJqwwbzXYaYee+GnD6rfVzPCIwpnVfKWoCYS8Zr0wub
chmFx8EYAcBQ9OT5okfxZsN5J8kylX2CCDMEX5Ek6o7+4W76+L+V6F0hi1Npb2AH
MFE5JLQLZGPs/3ilZSCz9io3u0vG78sLXPrQFbgJpa1E70W+bxohaieENPB0zGmS
YBqF0BLM6XoySAURGMv8ohP3nT53PXtPDCU4EMF75bTvJa3QWJRSBC6uRtAY67tp
h1bTWaE7Nmrtw9/mK+1oukjm8N7skvl1n0ZGQ+OmhfNcs8ii33fAV+u5zoGrywG5
0kXOfKfbt231/ManvsdGTHBd6Wodhprbo+Nw5tOA6B1R5jsSs0fvizKBRewrwiY7
66LNPtamSyqVapTBZqMEWaxvpfoWOgU8ZA1F9msD+qTHDd6OPCV692DAJbXlHfJe
jof1hm/X+SyTZzungBvV
=TKl5
-END PGP SIGNATURE-