Bug#275119: Sparc sun4u packages needed.

[Kilian Krause]

--=-xMkrI+3w2QyO78/6we9M
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Dking,

Am Do, den 07.10.2004 schrieb dking@pimpsoft.com um 23:02:
> I was checking the current testing via the website; There may be some=20
> lag in terms of the data on the site and what is current? Then again=20
> I use cvs-current so I guess anything less would be seen as old to=20
> me. <G>

well, reading "testing" as latest available debian is not my personal
preference. Somewhat i'd love seeing you try at least with SID (ok, scud
may be asking too much).

> Also keep in mind that the last debian stable release didn't have the=20
> development tools, much less the ability to do sun4u based packages=20
> outside of kernel images. It was impossible to compile for some=20
> instruction sets since the tools where not there from what I was told=20
> on the debian-sparc lists.

feel free to raise all you have to say as a group-reply to this mail.
Mark was so nice to put them in CC with his last mail, so i follow his
demand and CC them aswell. That way you have the best platform there is
in Debian to discuss if sparc64 is needed as new port (like amd64).

> This may be why for example the debian-ssh team may have chose to not=20
> release the ssh libs/tools as a additional sun4u based package; It=20
> was simply not a option then.
>=20
> I personally believe that debian policy needs to be upgraded with the=20
> times and sparc64 added as a official port now that this time around=20
> it is a valid option, but as I am not a official debian developer=20
> *yet* I do not have the kind of pull someone like yourself may have.=20
> Also the sudden addition of a new port may tick people off hoping to=20
> get testing released as current so while the idea is sound it may=20
> need to wait till after the release.

Well, amd64 is also waiting and apparently not included into the
official sarge release aswell. That's no excuse for not starting now
though. So if you think sparc64 is needed, bring it on. You seem to own
sparc hardware.. That's about unlimited times better than my chances.
I'm neither DD yet, nor do i have any sparc around to even try your
problem.=20

> Either way it would be nice to have the added option of the=20
> additional package.=20

Our last offer is unchanged. Bring on the patch you need to see for your
problem to be solved, and we'll evaluate if we can make it fit into the
package.

> All that would be required is different=20
> compilation defaults as all the c code is fairly portable. The real=20
> problems we have been having are with zaptel. But with the large=20
> development tools upgrade in this release I am told that will no=20
> longer be a problem, just remember by default debian policy sparc=20
> kernel images can be both 32 bit sparclite and ultrasparc64 sun4u so=20
> the zaptel kernel modules need to be packaged both ways to be=20
> complaint as far as I am aware of.=20

zaptel is kernel MODULES, not kernel IMAGES. Yet this all is some sort
of discussion that should be held by debian-sparc folks (with help of
debian-policy philosophers)...

> Thanks for your time.
>=20
>   - D
>=20
>=20
> On 7 Oct 2004 at 9:17, Kilian Krause wrote:
>=20
> > Hi D,
> >=20
> > 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 an=
d
> > > 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 post=
s
> > > from others saying they could not compile it for there sparc systems
> > > either. Zaptel is also another problem.
> >=20
> > Ok, good work.
> >=20
> > > 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.
> >=20
> > 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)?
> >=20
> > > While this means that the software will technically run on systems, i=
t
> > > 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.
> >=20
> > 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 us=
e
> > 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, bu=
t
> > for sure one of these three will be able to discuss and address this
> > problem.
> >=20
> > >  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 spee=
d
> > > 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.
> >=20
> > 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.
> >=20
> > > The main =91sweet spot=92 in speed increase and support is actually v=
8 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 giv=
e
> > > 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.
> >=20
> > 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?
> >=20
> > > 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.
> >=20
> > Then bring on the patch for us to see. Just keep in mind what i told
> > you. All possible combinations must still be valid!
> >=20
> > > 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.
> >=20
> > 1.0.1 is rolled out to sid. No idea where you're checking..
> >=20
> > --=20
> > Best regards,
> >  Kilian
> >=20
>=20
>=20

--=20
Best regards,
 Kilian

--=-xMkrI+3w2QyO78/6we9M
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)

iD8DBQBBZbO+vdkzt4X+wX8RAoHfAKCEM6BYmwlCOsUgWhdf8a1JTq9DqwCfctKD
kCbCYJYneWTJySwRGZVD3dQ=
=VKfw
-----END PGP SIGNATURE-----

--=-xMkrI+3w2QyO78/6we9M--