Aurelien Jarno:
> On 2016-08-17 22:05, 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


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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to