in
time for inclusion in buster.
On behalf of the release team,
Niels Thykier
signature.asc
Description: OpenPGP digital signature
Niels Thykier:
> Hi,
>
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
> * It is a substantial hardening feature
> * Upstream has vastly reduced the performance penalty for x86
> * The ma
ased on the current information?
>
> cu
> Adrian
>
It reflects all the issues we are aware of at the present time (except
for archive-{coverage,uptodate}, which can be seen from
https://buildd.debian.org/stats/).
If you believe we have overlooked an issue or an update, please do not
hesitate to let us know. :)
Thanks,
~Niels
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
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
ended 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 Stret
t 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}
ails 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
not> 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
mo
Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
&
rt of the arch release
> qualification anyway IMHO.
>
> Regards,
>
Hmm, the rebootstrap idea is interesting as a new requirement. I will
look into it.
Thanks,
~Niels
signature.asc
Description: OpenPGP digital signature
John Paul Adrian Glaubitz:
> Hi Niels!
>
> On 06/05/2016 12:01 PM, Niels Thykier wrote:
>> Beyond mips64el, we are not aware of any new architectures for Stretch.
>>
>> I kindly ask you to:
>>
>> * Porters, please assert if your architecture is targeting St
).
- DSA/Security/RT: Please use the word "blocker" or "RC" for issues
that *must* be solved for you to be willing to support the
architecture.
Thanks,
~Niels
signature.asc
Description: OpenPGP digital signature
On 2013-11-03 16:03, Steven Chamberlain wrote:
On 03/11/13 10:54, Niels Thykier wrote:
Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS).
We've had this on kfreebsd, due it to having been a release goal:
http://udd.debian.org
On 2013-11-03 23:04, Steve Langasek wrote:
On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote:
[...]
I suppose a sponsor-only DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes. I guess
On 2013-10-29 17:48, Ian Jackson wrote:
Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)):
[...]
As mentioned we are debating whether the 5 DDs requirement still makes
sense. Would you say that we should abolish the requirement for DD
porters completely? I.e. Even
On 2013-11-03 15:49, Thorsten Glaser wrote:
Niels Thykier dixit:
[...]
Until we have a clear definition of actively maintained ports, I would
recommend porters to err on the side of being verbose over being silent.
I’ve held off on the m68k side because I think the role call was only
On 2013-11-03 16:54, Niels Thykier wrote:
On 2013-11-03 15:49, Thorsten Glaser wrote:
Niels Thykier dixit:
[...]
Until we have a clear definition of actively maintained ports, I would
recommend porters to err on the side of being verbose over being silent.
I’ve held off
On 2013-10-29 16:05, Ian Jackson wrote:
Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
Results of porter roll-call
===
...
Summary table:
Arch || DDs || NMs/DMs || Other || Total
On 2013-10-19 16:38, Jeremiah C. Foster wrote:
Hello,
On Sun, Oct 13, 2013 at 05:01:31PM +0200, Niels Thykier wrote:
[snip freeze policy]
Hi,
I s/-arm/-ports/'ed the CC, since I figured the rest of the porters
would find the answer equally interesting.
Results of porter roll-call
) with your concerns or
corrections.
At this time, I have *not* updated the arch qualification table yet. I
will do that in a couple of days. We will also follow up on this in the
next bits from the release team.
~Niels
[AP] http://release.debian.org/jessie/arch_policy.html
[CD] I may (or may
On 2013-09-01 09:33, Niels Thykier wrote:
Hi,
As we announced in [LAST-BITS], we would like to get a better idea of
that status of the ports, to make an informed decision about which
port can be released with jessie. One of the steps is to get an
overview of which of the porters are (still
a DD|I am a DM|I am not a DD/DM
YOUR NAME
Niels, on behalf of the release team
[LAST-BITS] http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
[WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux
23 matches
Mail list logo
