Re: Potato readiness ?
Personally I don't think any of these really constitute whether sparc is
release ready. They are package specific and not really related to sparc.
On Sun, Jan 23, 2000 at 10:35:27PM +0900, Ragga Muffin wrote:
>
> Hi all,
>
> A coupla days ago I successfully installed debian on a sparc 5 and I'm left
> wondering about the status of debian-sparc vs the potato freeze.
> I understand that sparc support was added in slink so it's still in
> it's infancy I guess.
> But I wonder if sparc-potato will be ready with the other archs.
Sparc was not "added" in slink. The sparc port has been around since
pre-hamm. However, it's first release under Debian was for slink.
> Problems I've found:
>
> Netscape: Utter confusion, people suggest converting from rpm or
> building from slink. I succeeded in building v4.5. Why are there numerous
> versions that don't include the actual beast ?
Umm, the only versions of linux that Netscape supports anymore is alpha
and i386. So what, what can we do about this? Nothing. We are not
netscape, and we don't go around basing our release readiness on the
availability of non-free proprietary software for a particular arch.
> ---
> Mule2: There's a bug report on this; it won't compile and there's no binary
> available. Anybody has a solution ? It seems to be a #define problem..
Talk to the mule2 maintainer. I filed this bug a long time ago. It is not
about sparc, it is related to glibc 2.1 AFAICT.
> ---
> Removing pppconfig and ppp:
>
> dpkg (subprocess): unable to execute pre-removal script: Exec format error
> dpkg: error processing pppconfig (--remove):
> subprocess pre-removal script returned error exit status 2
>
> I just filed a bug report on this.
> (how many sparc users need ppp by default ?)
This is also not sparc specific. We always include ppp by default, simply
because if they need ppp, they are going to have to have it by default.
Else how will the install it if their only install option is via the net
over ppp? This is true for all archs, not just sparc. As for the problem
with it, it does not appear to be sparc specific either.
> ---
> Xapps:
> fonts, Login.app etc need XF86Config, however Xsun doesn't use this file.
> Maybe a dummy file (touch /etc/X11/XF86Config ) should be created when
> installing xbase ?
[bmc@blimpo(10:48am)-/<1>src/packages]%l /etc/X11/XF86Config
-rw-r--r-- 1 root root 1664 Jan 20 23:12 /etc/X11/XF86Config
That is on my sparc. I believe what you are talking about is the package
"xf86config", which is not on sparc, since it does not require
configuration. This is not a bad thing, given the reason is because Sparc
hardware allows for auto configuration, and doesn't require a lot of crap
to set it up. Complain to login.app for not having a decent work around.
> ---
> man:
> man freezes (randomly) if there is no manual page available for your search.
> Anyone else experiencing this ?
This is the same on all archs. What you did not wait to see was that man is
trying to reindex all of the man pages to make sure it's cache is
up-to-date.
> gman:
> Doesn't display the manpages, just blank screens. Recompiled and works ok.
> ---
Send a bug report.
> The kernel and Xsun seem rock solid so I'd really like to see the
> distribution getting more near the level of debian-x86 ;)
> Just my 2jpy...
If you look at the level of packages that have bad deps and also Sparcs
level of up-to-date deps (eg, packages depending on the most recent
version of a library), you will see that it is far superior to the i386
specs. For example, check the deps on the obsolete packages libncurses4
and libreadline2g for sparc and i386. Sparc has far fewer dependencies on
these old packages. Sparc also has far less unmet deps than i386 for
"main".
Just remember, a bug while running on "sparc" does not mean a bug in the
sparc distribution.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bmc@visi.net '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: