Re: Regarding older Sparc hardware (32-bit)

2009-05-06 Thread Martin
On Mon, 2009-05-04 at 19:52 +, brian m. carlson wrote:
 On Mon, May 04, 2009 at 01:37:46PM -0500, Dan Oglesby wrote:
  Does Debian need/want more testers for older Sun systems like the IPC,
  SPARCStation 1/2/5/20?  I have a handful of older systems and a small
  pile of SBus cards, all in working order, and didn't know if setting
  these systems up for testing would be useful or not.
 
 As far as I'm aware, Debian does not support 32-bit SPARC system since
 lenny.  Apparently, there is nobody working on the upstream kernel for
 32-bit SPARC machines.  It's also my understanding that jettisoning the
 32-bit systems allows Debian to compile for SPARC v9 systems, which can
 provide significant performance benefits.
 
 So, probably not.

IIRC support was dropped because no one wanted to maintain them.  At one
point there was an effort to provide packages for them; this may still
exist.  If not, if the original poster wanted to set these machines up
and work on supporting them again I'm sure there would be greatful
users.  I suspect it wouldn't be too much effort, esp. for the SPARC V8
based machines.

Cheers,
 - Martin



-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Regarding older Sparc hardware (32-bit)

2009-05-06 Thread brian m. carlson
[Please don't CC me; I'm subscribed.  M-F-T set appropriately.]

On Wed, May 06, 2009 at 11:26:19AM +0100, Martin wrote:
 IIRC support was dropped because no one wanted to maintain them.  At one
 point there was an effort to provide packages for them; this may still
 exist.  If not, if the original poster wanted to set these machines up
 and work on supporting them again I'm sure there would be greatful
 users.  I suspect it wouldn't be too much effort, esp. for the SPARC V8
 based machines.

This is true; if somebody was willing to maintain support for 32-bit
SPARC machines, it is possible (although unlikely) that support might be
restored.  I think there would need to be more than just testers,
though; somebody would need to support the kernel.  For example, I fix
alignment bugs (for SPARC) on occasion, but I'm hardly the person you
want to maintain the SPARC/UltraSPARC kernel.

I don't want to dissuade people from working on the port, but I don't
want to give people false hope either.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature


Re: X in lenny: 'cannot run in ramebuffer mode'

2009-05-06 Thread Bob Wilkinson
On Mon, May 04, 2009 at 12:27:42PM +0200, Martin Lemmen wrote:
 you inserted the line BusID SBUS:/SUNW,f...@1e,o into your xorg.conf - 
 where did you get that, exactly? 
 I want to try the same (and see if it does me any good), but I'm not sure my 
 card has the same busID.

spain:/home/bob# prtconf -p -v | less

HTH

Bob


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: sparc/debian/linux procedures

2009-05-06 Thread Martin
[ Apologies for the cross post ]
On Mon, 2009-05-04 at 15:26 -0400, Brian Thompson wrote:
 All,
snip
 It's my understanding that there are a team of people who are focused
 on the sparc kernel itself (which is used by Debian as well as some of
 the other distributions - Aurora, etc).
This is a subset of the kernel developers.  David Miller is (I believe)
the key man.

 It's also my understanding that there are a team of people who are
 focused on making sure that the sparc port of Debian works properly
 as a complete Debian OS distribution for sparc.
It's more of a loose affiliation, but yes, these are some of the Debian 
developers on the debian-sparc list.

 In addition, I understand that there's also a team of people who are
 focused on making sure that the Debian distribution as whole
 (non-arch specific) functions properly and that changes on one port
 don't end up inadvertently causing problems for other Debian ports.
Again, more a loose affiliation - this is essentially the work of the
Debian developers.  A small number of developers have responsibility for
over all integration (i.e. the release team, buildd maintainers, etc.)
but most work is done on a package by package basis with a small number
of folks working on each (often one or two).

 Likewise I understand that there's a team of people who are focused
 on making sure that the linux kernel as a whole functions properly and
 that changes specific to one arch don't end up inadvertently causing
 problems for other linux kernel archs.
This is, in general the Linux kernel developers; although, again, their 
responsibilities and organisational structure vary.

 My question is - when I find things that worked in Ubuntu sparc
 but not on Debian, what is the proper procedure for resolving the
 issue? Is there a checklist or flowchart anywhere public that should
 be followed when issues are found?
 
 I'm guessing the first step is probably to determine whether it's a
 kernel issue or an issue external to the kernel so that a bug report can
 be filed with the correct team (while also checking to see if the issue
 has already been reported), but again that's just a guess.
A general procedure might be:

1. Identify which package(s) are causing the problem.
2. Attempt to identify what conditions / factors / circumstances trigger
the issue.  All the normal rules about writing bug reports apply.
3. File a bug report against the relevant Debian package.
4. Assist the package maintainer with any follow up queries.

If you have time and access to a version of the package that does work,
it might be helpful to track down which differences are causing the
problem, and if possible, submit a patch.  Certainly, including a
reference / pointer to the nearest version of Ubuntu package that works
would be helpful.

If the bug turns out to be something that is not specific to Debian and
is a more general problem then the packages maintainer may forward it
(upstream) to the main developers for that package.

 Any guidance would be greatly appreciated.
Does the above help?  I'm far from an expert on this; I'm just an
end-user, but the above procedure has worked for me.

HTH

Cheers,
 - Martin



-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org