Arch qualification for buster: call for DSA, Security, toolchain concerns

in time for inclusion in buster. On behalf of the release team, Niels Thykier signature.asc Description: OpenPGP digital signature

Re: libsbc1: compiling with gcc > 4.9 causes stack corruption

On Mon, 17 Apr 2017 17:02:32 +0100 Paul Brook wrote: > Package: libsbc1 > Version: 1.3-1+b2 > Followup-For: Bug #856487 > > Not a stack corruption. > > This is miscompilation of sbc_analyze_4b_8s_armv6. gcc appears to look > into the asm function and decides that it does not

Re: [d-i/stretch] Status on Installation guide and Release notes (from a d-i PoV)

Holger Wansing: > Hi, > > [...] > > After Samuel's commits > https://anonscm.debian.org/viewvc/d-i?view=revision=70661 > and > https://anonscm.debian.org/viewvc/d-i?view=revision=70695 > this issue is now done. > > > Holger > > Thanks for the follow up and thanks to Samuel for the work :)

Re: Bug#856487: libsbc1: compiling with gcc > 4.9 causes stack corruption (on arm{el,hf}-only?)

On Sun, 19 Mar 2017 18:51:00 +0100 Linus =?utf-8?Q?L=C3=BCssing?= wrote: > On Sat, Mar 04, 2017 at 07:37:36PM -0300, Felipe Sateler wrote: > > > Not really familiar with how binaries get created or uploaded in > > > Debian, but is it possible to determine the gcc +

Re: Bug#839840: ghci segfaults on armel, related to doctest failure

On Fri, 7 Oct 2016 11:10:50 +0200 Sven Bartscher wrote: > On Wed, 5 Oct 2016 17:12:45 + > Clint Adams wrote: > > > Source: ghc > > Version: 7.10.3-9 > > Severity: serious > > > > clint@abel ~/haskell-http-api-data-0.2.4 > > % ghci

Re: Bug#837359: ocaml: FTBFS on -fPIE binNMU on armhf - test failure

Control: retitle -1 ocaml: FTBFS on -fPIE binNMU on armhf - test failure Dear maintainer, We have tried to binNMU ocaml in unstable now that PIE is on by default. This worked fine on all release architectures except armhf, where 4 tests failed: """ Summary: 468 test(s) passed 4 test(s)

Re: Enabling PIE by default for Stretch

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

Re: Architecture qualification meeting, scheduling

Adrian Bunk: > [ fullquote adding -ports, for people not following -release or -devel ] > > [...] > > Is https://release.debian.org/stretch/arch_qualify.html the up-to-date > information available to you, and the "candidate" line how a decision > would look like based on the current

Re: Porter roll call for Debian Stretch

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

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 sup

Re: Porter roll call for Debian Stretch

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

Re: Porter roll call for Debian Stretch

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

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

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

Re: [Stretch] Status for architecture qualification

Steve McIntyre: > [...] - armel has a RT concern about lack of buildds (only 2) >>> I think this is outdated, my understanding is that armel and armhf are >>> now using a shared buildd pool. I see arnold, hoiby, henze, hasse, >>> antheil and hartmann recently active on the armel

Re: [Stretch] Status for architecture qualification

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

Re: [Stretch] Status for architecture qualification

Steven Chamberlain: > Hi, > Hi, > John Paul Adrian Glaubitz wrote: >> I have invested lots of time and effort to get sparc64 into a usable state >> in Debian. >> We are close to 11.000 installed packages. Missing packages include Firefox, >> Thunderbird/Icedove, golang and LibreOffice to name

Re: [Stretch] Status for architecture qualification

peter green: > On 05/06/16 11:01, Niels Thykier wrote: >> all arm ports have DSA concerns. >> > Is there a current reference to what these concerns are? Is there still > a lack of out of band management? (the old mail I found on the topic > said it was "b

[Stretch] Status for architecture qualification

Hi members of DSA, Security, RT and all porters. While the freeze still seem far away, I think it is time to start with the architecture qualifications. For starters, here are the architectures we are aware of: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x -

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

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

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

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

Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

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

Re: Potential issues for most ports

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

Re: Potential issues for most ports

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

Re: Bits from the Release Team (Jessie freeze info)

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

Re: Bits from the Release Team (Jessie freeze info)

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

Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

Hi, The final results are in: Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 hurd-i386 || 5 || 0 || 3 ||8

Roll call for porters of architectures in sid and testing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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

Re: java architecture names and armhf/sh4

On 2012-01-17 10:24, peter green wrote: While looking at armhf build failures I took a look at uwsgi I determined it was failing on armel, armhf, sh4 and powerpc due to using incorrect paths for java stuff (it's also failing on ia64 and alpha for what appears to be unrelated reasons).