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: Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[Florian Weimer]

* YunQiang Su:

> Adrian Bunk  于2020年5月21日周四 上午4:44写道：
>>
>> On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
>> >
>> > FTR, after giving back golang-1.14 mipsel several times, it's finally
>> > built, by a longson builder.
>> > So I guess it only occurs on octeon. Since the porterbox eller is also
>> > octeon, it also can't build any go program.
>>
>> On eller golang-1.14 fails to build both in sid and buster chroots.
>>
>> golang-1.11 also fails to build in a buster chroot with floating point
>> test errors.
>>
>> golang-1.14 gets unbroken by GOMIPS=softfloat.
>>
>> The only kernel configuration change on eller in the buster point
>> release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
>> make sense if the problem is that golang-1.11 and golang-1.14 are
>> not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
>
> It is just support O32_FP64. I don't expect it will have any effect.

But apparently it does.  The question is why?  Is it a lack of proper
ABI markup?

Maybe we can tweak the kernel enablement so that it still preserves
the old behavior for these Go binaries.

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: bind9 failures on mips

[Florian Weimer]

* Robert Edmonds:

> James Cowgill wrote:
>> But to be honest, I would just replace all the functions in that file
>> with calls to the C11 atomic functions which GCC implements itself -
>> this way you can be sure they're right:
>
> What minimum version of gcc would be necessary?  The last time I looked
> at this topic, gcc still did not have stdatomic.h, but I see that's
> changed now.

GCC 4.7 has very similar atomic built-ins:



But the previous built-ins go *way* back:



The question is whether the relevant MIPS variants have proper support.
I don't know the answer.

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Florian Weimer:

 AFAICT, Debian is actually shipping IcedTea releases, but those are
 re-rebranded as IcedTea.

Sorry, re-rebranded as OpenJDK.


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

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Matthias Klose:

 Or does everybody see openjdk as an alibi for Debian to build things
 and then use the sun-java packages from non-free?

I know folks who use it in production, admittedly with compiler
excludes to work around some C2 bugs.

 For those who are interested in an openjdk-6 update for stable, I did
 prepare an update for some architectures at

   deb http://people.debian.org/~doko/archive stable/

Cool, it's based on OpenJDK 6b18.  However, we can't upload it as-is
because the version number is greater than the one in testing.

What can we do about the lack of mips support?

 I don't plan any updates for unstable/testing beyond 6b18.  6b20 is
 available in experimental, but disables the ARM assembler interpreter
 (which is 3-5x times faster than the plain zero build), and 6b20
 doesn't build anymore on sparc.

If upstream has ceased support for those architectures, should we
really release squeeze with them?  I'm pretty sure we we'll have to
upgrade to later versions at one point.


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

Re: gnat-4.4 is blocking most big transitions atm

[Florian Weimer]

* Luk Claes:

 The build failure for gnat-4.4 is filed as an RC bug (#558146),

This appears to be a bug in tar, perhaps due to a subarchitecture
mismatch:

| /bin/bash: line 1:  1933 Illegal instruction tar -cf - .

Is this really something that can be fixed on the gnat-4.4 side?  Does
tar -cf - . work at all in the relevant chroot on mayer?


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