Bug#275119: Sparc sun4u packages needed.

[Kilian Krause]

--=-kisvXunN5VP3er78K/n4
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi D,

Am Do, den 07.10.2004 schrieb dking@pimpsoft.com um 0:08:
> I'm sorry if I got the version wrong, I have been very busy lately and
> I must have had a brain fart or something. My bad.
>=20
> All my sparc support patches have gone directly to asterisk CVS,
> before I started submitting them asterisk refused to compile on the
> debian based sparc system I was using, ad the lists had allot of posts
> from others saying they could not compile it for there sparc systems
> either. Zaptel is also another problem.

Ok, good work.

> The reason debian uses the lowest common instruction set (sparclite)
> is due to binary compatibility; They want to make sure the binaries
> they offer as a service will run on as many of that type of hardware
> as possible.

Doesn't it make sense that way?! Would you prefer to find out that your
sparc is "unfortunatelly not supported for being too old"?! We aren't
Gentoo, are we (where everyone needs to recompile stuff to make it
work)?

> While this means that the software will technically run on systems, it
> does not guarantee that they will run at a reasonable or even the
> required speed to function properly. The problem with that some
> software (Like asterisk) is very needy in resources for things like
> encoding voice streams for example.

ok, agreed. Yet how much of this recoding is done in asterisk itself,
and how much in like openh323 or pwlib or whatever. (At least if you use
chan_h323/chan_oh323 there might be an issue with openh323 aswell).
Please keep in mind that we technically *CAN* make an asterisk-usparc
package from the same debian sources, but then this needs to work with
all the multitude of combinations possible. And in the end it's us to
have to maintain this. So if there's a reason sparc is too slow by
default in debian, I consider it the best way to raise this against
debian-sparc, debian-policy and debian-release.. I'm not sure who is
currently in charge of deciding what's the best-practice default for
sparc and what's the required minimum and max. allowed optimization, but
for sure one of these three will be able to discuss and address this
problem.

>  If a application can not run fast enough to do its job on a system
> then by definition it is unusable and thus broken; I believe the speed
> increase given by the at least version 8 instruction set would be
> worthy of a additional package, same software just compiled for
> ultrasparc. The highest 32 bit instruction set available would be v8+
> and that would be best ultrasparc systems unless you wanted full 64
> bit for the streams encoding, in that case you would compile for -m64
> as well as -mcpu=3Dultrasparc and get the=20
> v9b 64 bit instruction set used.

Ok, agreed. Yet this is not a problem of the asterisk package as such,
but a matter of wrong defaults by the debian-policy, don't you think?
Further i'd really like to be sure there's no problem with say openh323
after "fixing asterisk" in the way you outline.

> The main =91sweet spot=92 in speed increase and support is actually v8 of
> the instruction set. Anything compiled lower then that has a series
> speed liability due to the limitations of the instruction set used. A
> perfect example of this would be the current ssh libs for the current
> debian stable under sparc: On a internal network with no possible lag
> it takes them 3-5 seconds to set up and do the encoding needed to give
> a local uses a login prompt via ssh. If they had been compiled for v8
> of the instruction set they=20
> would be much faster by several magnitudes.

How did the ssh team decide in this question? Would they go for v8
instruction set in a separate binary package like ssh-usparc-v8?

> I'm not saying do not support the lower arches: if people think they
> can use it let them. But I think it would be best if we had a added
> option of having the sun4u compiled package for asterisk and zaptel.

Then bring on the patch for us to see. Just keep in mind what i told
you. All possible combinations must still be valid!

> My suggestion that the package is updated was because the asterisk
> community has released Asterisk/Zaptel stable release 1 already, and I
> noticed you still had a rc release in the tracker system.  For sparc
> support alone you want the newest version available.

1.0.1 is rolled out to sid. No idea where you're checking..

--=20
Best regards,
 Kilian

--=-kisvXunN5VP3er78K/n4
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBZO18vdkzt4X+wX8RAhtYAJ9t7n5ouoCXtWl+MMU0VFz7gy2uCwCfUjFI
uEs1AkF5gB32ZYAmUen/lzE=
=Pk8i
-----END PGP SIGNATURE-----

--=-kisvXunN5VP3er78K/n4--