Re: Bug#275119: Sparc sun4u packages needed.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi People,
Could I ask that we at least keep the 275119@bugs.debian.org in the email loop
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
back with asterisk-0.1.9, have a look at
http://buildd.debian.org/build.php?&pkg=asterisk&arch=sparc.
That said I do acknowledge that asterisk is very resource hungry, we even have
this same issue with intel as Debian asterisk is compiled for i386 and thus
lacks a lot of i686 optimisations which the compiler might be able to bring
about. Certainly on Intel asterisk does still require a decent sized
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 relevant.
In the asterisk scripts I have tried to force the use of dpkg-architecture to
remove build time cpu optimisations and also to ensure the binary packages
build comply with policy. I once did a build for i586 and spent ages trying
to debug a problem report, turns out the remote site was running on i486
hardware.
The other point, is with the support for lowest common hardware support means
it is available for use for all, and if people want to optimise they can
download the deb, dsc & diff file make a few minor changes and rebuild for
their own optimisations.
IMHO debian-sparc is the correct place to be discussing this, and I would be
happy to apply any concensus patches to the Debian asterisk package as they
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=ultrasparc 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 ?sweet spot? 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..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBZTJfoCzanz0IthIRAvs8AJ43Ga+hZBd84DufxEECIMMDddy8qQCfV1Gc
+vjU/Sv0XjzyJNttYxbGtDs=
=E7rW
-----END PGP SIGNATURE-----
Reply to: