Package: release-notes Severity: important X-Debbugs-CC: debian-arm@lists.debian.org
Full quote for context. On Vi, 26 iul 19, 19:29:26, John Paul Adrian Glaubitz wrote: > Hi Dick! > > On 7/26/19 7:13 PM, Dick Hollenbeck wrote: > > The website says that you are supporting 4T in the ARMEL repo: > > > > See the first sentence of this page: > > > > > > https://wiki.debian.org/ArmEabiPort > > It is a wiki page, not the official Debian documentation. Unfortunately, this > page hasn't been updated yet. Could you please point to where this is documented in order to link to it from the Release Notes? > > On that basis I invested a lot of time getting a kernel ready and scripts > > and C/C++ > > development system ready, then I got body slammed after all that time when > > I learned that > > the minimum arm machine required for ARMEL BUSTER is 5T, not 4T. At least > > this was the > > case for busybox-static and also systemd. I could not boot into userspace. > > That's unfortunate, indeed. > > > $ readelf -a busybox | grep Tag_CPU > > > > > > This shows that this particular binary is not 4T compatible. And I must > > say, this is a > > huge disappointment for me, given the time I have spent on it. Because I > > am supporting > > multiple machines, 5 debian architectures in total, each with rootfs, > > custom kernels, and > > customer C/C++ toolkits, this was all hoping to come together on a common > > Debian version > > named buster. > > > > It seems that the last support of 4T for ARMEL was Stretch. But I cannot > > dovetail all > > these C/C++ toolkits using different versions of the tools. I did this > > using multi-arch > > in a Docker container based on buster for all archs. > > > > If this was an oversight, please consider rebuilding these packages using > > the corrected > > compiler options. Or at least fix the website so somebody else does not > > lose so much time. > > It was not an oversight. The bump happened because various other upstream > projects > announced they would raise their minimum baselines to ARMv5T such as OpenJDK. > > > In either case a policy statement seems to be needed. Was this an oops or > > was it > > deliberate? (Why deliberately make an architecture which is attempting to > > support old ARM > > CPUs NOT support old ARM CPUs?) > > The raise to ARMv5T was necessary to keep armel supported. It wouldn't have > been > possible to keep the port if had let it at ARMv4T. Wikipedia only mentions ARMv5TE. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
