* 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 (thou
* 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
* 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:
> 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.
* 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?
* 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
* Niko Tyni:
It doesn't show up on my own sparc uniprocessor host, which has the
Etch kernel, so it's either specific to new kernels or SMP hosts. As it
works on sperger in the sid chroot, it would seem that newer versions
of glibc work better.
Could you build the latest security update
* Sven Luther:
i guess sparc-*-* should be changed by sparc*-*-*, and we can then
close this bug.
But why does the host triplet not match sparc*-*-*?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
8 matches
Mail list logo
