Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Jeffrey Walton]

On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser
 wrote:
>
> I’m answering back from the $dayjob address because Googlemail
> cannot communicate with normal mailservers.
>
> >I can send you two dev boards, if you want them. The first is
> >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is
> >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I
> >don't use them much anymore. I've mostly moved on to Aarch64.
>
> That is certainly an option, if you don’t want them any more and want
> to ship them to .de, although it’ll likely take longer than just getting
> access on a suitable project machine. RAM is tight on them, but with
> swap the compiling should work. Both seem to have serial console, good.

Nothing beats a native compile in your basement. It sure beats the
snot out of a cross-compile, or an emulator like a Debian QEMU/Chroot.
I switched to the dev boards after getting frustrated with
cross-compiles. (So many makefiles are poorly written, and can't
handle a simple cross-compile).

And I run a first class swap file on all of my dev boards. SDcards are
easy to replace. A SDcard lasts 6 to 9 months before you start seeing
unexplained file system errors. That's around the time you know it's
time to replace the SDcard.

> Do they run stock Debian armhf?

So the CubieTruck is embarrassingly down level:

cubietruck:~$ lsb_release -a
Distributor ID: Linaro
Description:Linaro 14.04
Release:14.04
Codename:   trusty

The Wandboard is doing better:

wandboard:~$ lsb_release -a
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye

I don't mind shipping to Europe if you don't mind paying the VAT. I
think you will be the fourth or fifth Debian maintainer I've sent
hardware to.

Jeff

Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Jeffrey Walton]

On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser  wrote:
>
> [...]
>
> The options for the armel/armhf porters are to either get the
> .debs from me, install them in a chroot, and then the other B-D,
> and rebuild the packages, or to use dpkg --force-depends to
> install the dependencies (which makes it hard to use apt to
> install the other ones unless you also edit /var/lib/dpkg/status
> by hand first, something I was already used to from my reviving
> m68k back in 2012–2015) into the chroot then rebuild there.
>
> I will gladly help if it’s made possible for me to help. This
> cannot be done on a porterbox because it’s still impossible to
> either install arbitrary .debs into a chroot there or to obtain
> root in the chroot to be able to force installation in the absence
> of some Depends.
>
> So if you have a fast armhf box or two, ideally with chroots
> already made for sid, which you don’t mind temporarily giving
> me root on, I’m in, otherwise I’ll answer questions from these
> doing that work if needed.

I can send you two dev boards, if you want them. The first is
Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is
CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I
don't use them much anymore. I've mostly moved on to Aarch64.

Provide your postal mailing address, if you want them.

Jeff

Re: Ability to further support 32bit architectures

[Jeffrey Walton]

On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank  wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist.  But none of them look really
> promising.

Also see .

> > Separately, I wish we had cross-builders available, and cross-build
> > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> > compiler.
>
> Real cross-builders would use some fast amd64/arm64/ppc64el (and for
> amd64 also reasonably cheap) machines to build all other architectures.

Jeff

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

>>> Is anybody else interested in helping? Thoughts/comments?
>>
>>Sorry to bump an old thread
>>
>>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
>>the platform.
>>
>>Clang 3.5 and 3.6 are no longer maintained. The bugs we are
>>discovering and reporting are being closed as "invalid" and "won't
>>fix" because Clang is outside its freshness date.
>>
>>Also pick up this for glibc:
>>http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
>>. Though it was first seen in Clang 3.3, its still a problem today.
>
> ACK, thanks for thinking about this still.
>
> Progress to date has been quiet, but work is ongoing. KiBi has a good
> set of patches ready for d-i already, and I'm working on debian-cd to
> add useful backports support. My first quick-hack attempt failed
> dismally, so I'm midway down a more disruptive but thorough set of
> changes now.

Another pothole for Clang... '-march=native' does not perform as
expected at least about one third of the time. I have not narrowed it
down, but it affects at least MacPorts and Ubuntu. Apple Clang appears
to be OK. I don't recall the results of Debian testing.

When we added code generation tests to our test script, we found Clang
was not generating SSE3, SSSE3, SSE4, AVX, BMI, etc. The work around
in the field is to cat /proc/cpuinfo, and then do something like the
following based on the CPU flags (from
http://github.com/weidai11/cryptopp/blob/master/cryptest.sh):

X86_CPU_FLAGS=$(cat /proc/cpuinfo 2>&1 | "$AWK" '{IGNORECASE=1}{if ($1
== "flags"){print;exit}}' | cut -f 2 -d ':')

if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "ssse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mssse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.1") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.1"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "aes") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-maes"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "pclmulqdq") -ne "0")
]]; then PLATFORM_CXXFLAGS+=("-mpclmul"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdrand") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdrnd"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdseed") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdseed"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "adx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-madx"); fi

Most users don't realize the silent failure is occurring. Ideally,
this would be fixed in the compiler front end.

Also see Clang {3.4|3.5|3.6|3.7} only advertises SSE2:
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616723,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616729,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616731,
etc.

Jeff

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

Sorry to bump an old thread

Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
the platform.

Clang 3.5 and 3.6 are no longer maintained. The bugs we are
discovering and reporting are being closed as "invalid" and "won't
fix" because Clang is outside its freshness date.

Also pick up this for glibc:
http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
. Though it was first seen in Clang 3.3, its still a problem today.

Jeff

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

I think it would benefit more than Skylake users. The last few
processors are missing support. Below is from a Core i5-5300U (5th
gen) and a 3.19.0-64-generic kernel.

**

$ dmesg | egrep -i '(error|failed)'
...
[35679.953137] mce: [Hardware Error]: Machine check events logged
[35980.749723] mce: [Hardware Error]: Machine check events logged
[36280.594838] mce: [Hardware Error]: Machine check events logged
[36580.439940] mce: [Hardware Error]: Machine check events logged
[37029.202190] mce: [Hardware Error]: Machine check events logged
[37179.118743] mce: [Hardware Error]: Machine check events logged
[37629.831878] mce: [Hardware Error]: Machine check events logged
[37779.748453] mce: [Hardware Error]: Machine check events logged
[38229.510127] mce: [Hardware Error]: Machine check events logged

$ sudo mcelog
mcelog: Family 6 Model 3d CPU: only decoding architectural errors