Bug#275119: Sparc sun4u packages needed.

[Mark Purcell]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi People,

Could I ask that we at least keep the 275119@bugs.debian.org in the email l=
oop=20
so we maintain some history of where we are going with this.

Asterisk has been buildd in Debian GNU/Linux for sparc since Jan 2002, way=
=20
back with asterisk-0.1.9, have a look at=20
http://buildd.debian.org/build.php?&pkg=3Dasterisk&arch=3Dsparc.

That said I do acknowledge that asterisk is very resource hungry, we even h=
ave=20
this same issue with intel as Debian asterisk is compiled for i386 and thus=
=20
lacks a lot of i686 optimisations which the compiler might be able to bring=
=20
about.  Certainly on Intel asterisk does still require a decent sized=20
hardware (~ 500 Mhz) otherwise it can't handle even a moderate load.


Debian policy mentions this at 4.8, and dpkg-architecture(1) is also releva=
nt. =20
In the asterisk scripts I have tried to force the use of dpkg-architecture =
to=20
remove build time cpu optimisations and also to ensure the binary packages=
=20
build comply with policy.  I once did a build for i586 and spent ages tryin=
g=20
to debug a problem report, turns out the remote site was running on i486=20
hardware.

The other point, is with the support for lowest common hardware support mea=
ns=20
it is available for use for all, and if people want to optimise they can=20
download the deb, dsc & diff file make a few minor changes and rebuild for=
=20
their own optimisations.

IMHO debian-sparc is the correct place to be discussing this, and I would b=
e=20
happy to apply any concensus patches to the Debian asterisk package as they=
=20
become available.

Mark



On Thu, 7 Oct 2004 05:17 pm, Kilian Krause wrote:
> 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.
> >
> > 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
> > 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
> > 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..
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBZTJfoCzanz0IthIRAvs8AJ43Ga+hZBd84DufxEECIMMDddy8qQCfV1Gc
+vjU/Sv0XjzyJNttYxbGtDs=3D
=3DE7rW
=2D----END PGP SIGNATURE-----