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

* Florian Weimer: >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) > > I'm surprised to read this. ppc64el features prominently in the > toolchain work I do (th

Re: Using Debian funds to support a gcc development task

* John Paul Adrian Glaubitz: > But I think the list on the page archive criteria is a bit dishonest as > well when it asks "Are machines available to buy for the general public?" > while I don't think an IBM Z mainframe is available to buy for the general > public. At last for upstream, the diffe

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

* Riku Voipio: > On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote: >> * Niels Thykier: >> >> > armel/armhf: >> > >> > >> > * Undesirable to keep the hardware running beyond 2020. armhf VM >> >s

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

* Niels Thykier: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] Fedora is facing an issue running armhf under virtualization on arm64:

Re: [Stretch] Status for architecture qualification

* Lennart Sorensen: > There are a lot of 32bit powerpc chips still going into embedded systems > being built today. They are not going away anytime soon. Do they implement the ISA required by the existing Debian port?

Re: [Stretch] Status for architecture qualification

> In other words, i don't think a s390x box will ever just die. I'm sure “death” encompasses all events which might lead Debian to lose access to relevant hardware. It's not just about faults with a piece of equipment.

Re: RFC: Support non-standard extension (call via casted function pointer)

On 01/27/2016 04:17 PM, Richard Biener wrote: > We are trying to support > > t.c > --- > void *foo(); > > int bar() > { > return ((int (*)())foo) (); > } > > t2.c > - > int foo () { return 0; } > > thus doing a direct call to a function with a (wrong) prototype via a function > pointer c

Re: DSO linking changes for wheezy

* Roland McGrath: >> I can't see why you think --as-needed is fundamentally wrong or unnecessary. > > It is fundamentally wrong because -lfoo means I demand that the > initializers of libfoo.so run, whether or not I called anything in it. So it's more like static linking. 8-) IMHO, the current d