[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#933101: marked as done (buster: baseline for armel raised to ARMv5T)

Your message dated Sun, 29 Jan 2023 21:15:21 +0100
with message-id <f608cc71-3f8d-6368-1079-049420ab53d0@debian.org>
and subject line buster is EOL for a while; closing release-notes bugs
has caused the Debian Bug report #933101,
regarding buster: baseline for armel raised to ARMv5T
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

933101: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933101
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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,

Attachment: signature.asc
Description: PGP signature

--- End Message ---
--- Begin Message ---
Dear bug submitter,

Thanks for taking the time to file bugs. However, the bug you reported was aimed at buster (or hasn't seen activity after the last queries). buster is EOL for a while now and we're preparing for the release of bookworm. Hence, I'm closing these bugs as no longer valid or actionable.


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

--- End Message ---

Reply to: