from the problems-with-hardware-software-and-people dept.
Reported by LWN:
As of tonight, there is no more SPARC in testing. The main reasons were lack of porter commitments, problems with the toolchain and continued stability issues with our machines.
The fate of SPARC in unstable has not been decided yet. It might get removed unless people commit to working on it. Discussion about this should take place on #745938.
(Cross submitted on pipedot.org)
Related Stories
A grave bug has been introduced into the "wine" package of Debian Jessie, just days before the November 5th freeze deadline. The /usr/bin/wine launch script fails with an "error: unable to find wine executable. this shouldn't happen." message.
Debian has already suffered much unrest lately over the inclusion of systemd, with threats of a fork being issued, along with the possible cancellation of the GNU/kFreeBSD port and the possible dropping of support for the SPARC architecture. After so much strife and disruption, can Debian afford to have such a serious bug affect such a critical package so soon before such a major freeze?
(Score: 5, Interesting) by VLM on Wednesday April 30 2014, @04:03PM
WRT to the claimed 3 reasons, the porters seem to be committed, its just that linux and gcc don't "do" sparc so well anymore, making life extremely hard on the porters.
If upstream doesn't work on amd64, upstream is usually highly motivated to fix it. Doesn't work on sparc, eh, upstream shrugs shoulders while watching porter team grow gray hair.
68000, sparc, and mips (maybe others) are all on the cusp of "you want a porting machine, just program this COTS FPGA board and it'll be your 68000". Just a couple more years of FPGA hardware development and this will be BAU rather than a peculiar idea.
(Score: 2) by frojack on Wednesday April 30 2014, @06:49PM
Does it do it worse than it did before, or are some new coding constructs simply not supported when generating executables for spark?
How were previous spark versions produced? Massive re-coding?
No, you are mistaken. I've always had this sig.
(Score: 2) by VLM on Wednesday April 30 2014, @07:03PM
My likely inaccurate external observation of scaling, is as new coding constructs are implemented in the kernel and gcc, things are not getting quite as much testing on Sparc as they did in the 90s. So the re-coding load is increasing over time, along with plain old troubleshooting load.
So WRT the porters being committed there's about as many as the old days, maybe more, working as hard as the old days if not harder, but the workload is increasing.
Meanwhile Sparc hardware is not getting any more "available" for people who might want to jump in.
Someday, a build farm will be 1000 FPGA cards and when a package needs recompiling or testing you'll just be assigned FPGA #723 which will have a "whatever" loaded into it and away you'll go on your dedicated FPGA "box". Just not today, not yet. Or maybe a vast cloudy farm of huge processors running perfect emulators. Maybe.
(Score: 4, Interesting) by Anonymous Coward on Wednesday April 30 2014, @04:19PM
It's unfortunate that this happens to the only modern microprocessor with publicly available HDL sources http://www.oracle.com/technetwork/systems/openspar c/opensparc-t2-page-1446157.html [oracle.com] Don't count OpenRISC, it's crap against even mediocre ARMs; and there are at least 2 companies left behind Sparc. In contrast to OpenPower you can also grab a 99$ one-time SPARC license fee and do whatever you want with it.
Luckily there's still OpenBSD and Gentoo left for old Sparc hardware.
(Score: 2) by janrinok on Wednesday April 30 2014, @06:09PM
Luckily there's still OpenBSD and Gentoo left for old Sparc hardware.
Which is precisely what it says in TFA. You did read it, of course?
(Score: 3, Insightful) by frojack on Wednesday April 30 2014, @06:44PM
Read what TFA?
There appear to be links to bug report sites, and discussion boards. There is no TFA.
Instead we are expected to follow rambling threads on three different boards.
As an editor, I would have expected you to have insisted on an ACTUAL article and used these various board postings as backup. Instead we get three links to different discussion boards.
Further, it doesn't seem wise to start browbeating posters for not reading TFA that consists of 140+ comments on a bug reporting bulletin board.
No, you are mistaken. I've always had this sig.
(Score: 2) by omoc on Wednesday April 30 2014, @07:32PM
There is no real "article" at this time, the announcement was published on the mailing list/bug tracker. I don't write articles, I just submit stuff that is interesting to me. Sorry for that, but this is just early and raw news/information.
(Score: 2) by michealpwalls on Wednesday April 30 2014, @07:57PM
Somebody posted this same commentary on the original announcement page but, however, they didn't mention any real implications.
Out of morbid curiosity, unless you're an engineer building circuits that have to integrate with your existing SPARC hardware, why would you even care about this?
(Score: 0) by Anonymous Coward on Thursday May 01 2014, @02:25PM
Luckily there's still OpenBSD and Gentoo left for old Sparc hardware.
Let the NetBSD guys handle this one. They have proven processes in place for handling old hardware. Debian is not focused on this area. Most of what you'd want to do with old hardware does not require linux.
http://www.netbsd.org/ports/sparc/hardware.html [netbsd.org]
(Score: 3, Interesting) by GlennC on Wednesday April 30 2014, @07:22PM
Given that most of the Debian installations and derivatives I'm aware of are all on X86 or X64 type systems, is it that much of a problem that nobody is working on SPARC system development?
It appears that most people who continue to buy SPARC based systems intend to run Solaris.
Sorry folks...the world is bigger and more varied than you want it to be. Deal with it.
(Score: 2, Insightful) by nadaou on Thursday May 01 2014, @01:26AM
"I don't use this, therefore no one else would ever want to either" is a dangerous logical trap that as humans we all need to work hard to train ourselves to avoid.
For the record, we run Debian on several non-Intel/AMD architectures here, and the death of Debian for SPARC or Alpha means the death of the otherwise working fine hardware for many users, and a lot of work to get back to what was previously running smoothly. Historic hardware choice is often beyond our control for many reasons, and porting to a new platform is not always easily done for a number of other important reasons.
Running a common software environment, like Debian, helps ease that transition to new hardware when it does finally occur.
~ Forward in all directions ~
(Score: 1) by petecox on Thursday May 01 2014, @04:22AM
Would petitioning Oracle with a support contract work? According to wikipedia, they have 11,000 subscribers attached to Oracle Linux.
Employ a couple of SPARC experts to extend the program to Sun/Oracle hardware and by extension fix debian builds...
How many active debian-SPARC users actually exist and what financial contribution from each would see this become a reality?
(Score: 2) by GlennC on Thursday May 01 2014, @12:25PM
This is why I asked the question, and I appreciate the response.
Sorry folks...the world is bigger and more varied than you want it to be. Deal with it.
(Score: 1, Interesting) by Anonymous Coward on Wednesday April 30 2014, @10:55PM
There's a big difference between sparc and sparc64. This article seems to be talking about the old 32-bit SPARC architecture, but the summary doesn't clarify.
(Score: 1) by KiloByte on Thursday May 01 2014, @12:01AM
sparc64 isn't in unstable either.
Ceterum censeo systemd esse delendam.