Steve McIntyre wrote... > First released with Lenny, supports ARMv4t & later. QNAS etc. kirkwood > & some freedombox. Toolchain and kernel support upstream are probably > never going away due to the massive number of simple ARM devices still > being made and shipped, however...
Quite recently I saw an ARMv4 (without thumb, long-gone arm architecture) hardware on sale. Probably too small for Debian, but bigger boxes were sold until 2009-ish, and fell out of support rather soon. What I'm trying to say: Please keep old arches as long as reasonably possible. There's still a surprising amount of people who use it. So in my opinion it is *way* too early to consider ending armel support. (But this is not a plea to restore arm, with oabi support dropped in gcc it's really dead now. Although it still shows up on popcon.) > Should we keep it for Stretch? Maybe with subarchitecture support, > when available. We still have some users, but not *many*. tbm would > miss it and is still supporting quite a lot of users. Could we get the > people who care about armel to do a minimally-supported LTS for > Jessie/Stretch? Typical users are now on NAS boxes or some > Freedomboxes, just using server software - no X, no graphics etc. > Should be possible? It's sound to assume virtually nobody runs big packages like iceweasel or libreoffice on armel boxes. My problem with a subset is rather why you would want to do this at all. Is there any reason beside buildd utilization? Since the whole idea raises a lot of questions: Where to draw the line, and how to assert no breakage is introduced in build dependencies. As an example, if the armel box is a router, the admin might want to install mtr-tiny to debug some kind of network problems. The mtr source package also builds a GUI version "mtr", so either you'd still have to support libgtk2.0-dev, and subsequently the X core - or you'd have to split the build scripts for different use cases. Something similar had been done before for stage builds, which is quite a pain to understand and to maintain. Long story short: You might drop a few leaf packages but anything beyond this creates a lot of continuous work I doubt many people are willing to do. > Summary: if people care about armel for Stretch, they should make > noise NOW and convince people it's needed and can/should be supported > in future. So add me to your list. I run four Seagate DockStar (v5) and two Raspberry Pi (v6, first generation). Although bout the latter, I was hoping for a "arm6hf" port and used armel until then. But with more recent Pi models AFAIK being armhf compliant, this will not happen anymore. Combined with the really poor performance I should rather wait for the right moment to brush them under some carpet. Also, flash size for the kernel image is not a problem: These boxes boot from external mmc or usb. Christoph