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]

* 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

[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: 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-amd64-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: Dropping the amd64-generic flavour

[Florian Weimer]

* Francesco Pietra:

> What about k8-smp?

Do we still need non-SMP kernels in the age of hyperthreading,
multi-core CPUs, and preemption?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dropping the amd64-generic flavour

[Florian Weimer]

* Frederik Schueler:

> -generic is odd and too long. I am considering to change the naming
> scheme completely, and call the flavours 2.6.x-y-amd64 and
> 2.6.x-y-em64t respectively.

Newer GCCs produce AMD64 code which is supposed to be closed to
optimal to what GCC can produce on EM64T.  Does it still make sense to
distinguish between them?  Or has it got something to do with the way
the kernel sets up its data structures?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dropping the amd64-generic flavour

[Florian Weimer]

* Goswin von Brederlow:

> I would suggest keeping the name amd64-generic. It is easier for users
> to see that -generic fits all than -k8.

It's also easier to reintroduce split packages if necessary.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]