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

[Florian Weimer]

* 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 (though I personally do not work on the GCC side).

The ppc64le situation has been clarified.  It's now listed explicitly
as a primary architecture, as powerpc64le-unknown-linux-gnu:

  <https://gcc.gnu.org/gcc-11/criteria.html>

This has always been the intent, but I can understand that
distributions view powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu quite very different things.

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

[Florian Weimer]

* 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
>> >support uncertain. (DSA)
>> >- Source: [DSA Sprint report]
>> 
>> Fedora is facing an issue running armhf under virtualization on arm64:
>> 
>>   <https://bugzilla.redhat.com/show_bug.cgi?id=1572916>
>
> I think you mean:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1576593

Yes, that's right, I copy-pasted the wrong bug URL.  It's filed as a
Red Hat Enterprise Linux bug because the Fedora builders run Fedora
VMs on that platform.

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

[Florian Weimer]

* 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:

  
  

Unless the discussion has moved somewhere where I can't follow it, no
one seems to have solid idea what is going on.  It's also not clear
that this configuration has substantial vendor or community support.
This makes me concerned that virtualization is a viable path forward
here.

(The discussion on the GCC list started off with a misdirection, sorry
about that.  The brief assumption that this was a hardware quirk is
likely quite wrong.)

>  * 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 (though I personally do not work on the GCC side).
>From my point of view, it's absolutely not in the same category as the
MIPS-based architectures.

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

> 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: [Stretch] Status for architecture qualification

[Florian Weimer]

* 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: DSO linking changes for wheezy

[Florian Weimer]

* 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 difference in behavior between dynamic and static
linking is quite odd.  --as-needed changes only one tiny aspect,
unfortunately.


-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkt95ciy@mid.deneb.enyo.de

Re: [SECURITY] [DSA 1847-1] New bind9 packages fix denial of service

[Florian Weimer]

* Florian Weimer:

> Package: bind9
> Vulnerability  : improper assert
> Problem type   : remote
> Debian-specific: no
> CVE Id(s)  : CVE-2009-0696
> CERT advisory  : VU#725188
> Debian Bug : 538975

Could someone please build this in a clean etch chroot for alpha and
s390?

The security buildds still pick up the broken LaTeX version, so bind9
FTBFS on these architectures for us.

Thanks!


-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org