Bug#275119: Sparc sun4u packages needed.

[Kilian Krause]

--=-7U/lSUt+7CvD92kK12mI
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Dking,

Am Fr, den 08.10.2004 schrieb dking@pimpsoft.com um 1:35:
> Well my main problem right now is understanding what you mean by a=20
> 'patch' in this case. All code I have done is in the cvs and you can=20
> get that from the asterisk cvs. Are you asking for a patch to the=20
> current from what you are currently using?

actually i was referring to a "patch" for packaging. Like *HOW* to spit
out the sun4u package additionally to the sunlite package, without
breaking either of both.
But a patch from CVS against 1.0.1 should be included too, if it's
needed.

> When you say mark you mean 'Mark Spencer'  or do you mean another=20
> mark? I have yet to get any mail from any other mark about this bug=20
> so clarification would be helpful. It would also help if you would be=20
> so kind as to point to any documentation you think would be helpful=20
> for me to read so I can get sparc64 like amd64 to be a official port.

Mark Purcell <msp@debian.org>, our internal maintainer inside the
pkg-voip group. Before forking into another port for Debian, please be
so kind to discuss this with the folks at debian-sparc@lists.debian.org.
Maybe they have an easy alternative other than forking the whole Debian
sparc archive into a sparc64 port.

> Thank you again for all your time.; I=92m a long time debian user but=20
> this has been the first time I have reported a bug or taken a=20
> interest in being a DD.
>=20
>=20
>  - D
>=20
>=20
>=20
>=20
> On 7 Oct 2004 at 23:23, Kilian Krause wrote:
>=20
> > Hi Dking,
> >=20
> > 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>
> >=20
> > well, reading "testing" as latest available debian is not my personal
> > preference. Somewhat i'd love seeing you try at least with SID (ok, scu=
d
> > may be asking too much).
> >=20
> > > 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.
> >=20
> > 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).
> >=20
> > > 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.
> >=20
> > 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
> >=20
> > > Either way it would be nice to have the added option of the=20
> > > additional package.=20
> >=20
> > Our last offer is unchanged. Bring on the patch you need to see for you=
r
> > problem to be solved, and we'll evaluate if we can make it fit into the
> > package.
> >=20
> > > 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
> >=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)...
> >=20
> > > 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 latel=
y 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 t=
he
> > > > > 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 syst=
ems
> > > > > either. Zaptel is also another problem.
> > > >=20
> > > > Ok, good work.
> > > >=20
> > > > > The reason debian uses the lowest common instruction set (sparcli=
te)
> > > > > is due to binary compatibility; They want to make sure the binari=
es
> > > > > they offer as a service will run on as many of that type of hardw=
are
> > > > > 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 system=
s, 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 li=
ke
> > > > > encoding voice streams for example.
> > > >=20
> > > > ok, agreed. Yet how much of this recoding is done in asterisk itsel=
f,
> > > > and how much in like openh323 or pwlib or whatever. (At least if yo=
u use
> > > > chan_h323/chan_oh323 there might be an issue with openh323 aswell).
> > > > Please keep in mind that we technically *CAN* make an asterisk-uspa=
rc
> > > > package from the same debian sources, but then this needs to work w=
ith
> > > > 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 i=
s
> > > > currently in charge of deciding what's the best-practice default fo=
r
> > > > 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 thi=
s
> > > > problem.
> > > >=20
> > > > >  If a application can not run fast enough to do its job on a syst=
em
> > > > > 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.
> > > >=20
> > > > Ok, agreed. Yet this is not a problem of the asterisk package as su=
ch,
> > > > but a matter of wrong defaults by the debian-policy, don't you thin=
k?
> > > > Further i'd really like to be sure there's no problem with say open=
h323
> > > > after "fixing asterisk" in the way you outline.
> > > >=20
> > > > > The main =91sweet spot=92 in speed increase and support is actual=
ly v8 of
> > > > > the instruction set. Anything compiled lower then that has a seri=
es
> > > > > speed liability due to the limitations of the instruction set use=
d. A
> > > > > perfect example of this would be the current ssh libs for the cur=
rent
> > > > > 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 fo=
r 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 t=
hey
> > > > > can use it let them. But I think it would be best if we had a add=
ed
> > > > > option of having the sun4u compiled package for asterisk and zapt=
el.
> > > >=20
> > > > Then bring on the patch for us to see. Just keep in mind what i tol=
d
> > > > you. All possible combinations must still be valid!
> > > >=20
> > > > > My suggestion that the package is updated was because the asteris=
k
> > > > > community has released Asterisk/Zaptel stable release 1 already, =
and I
> > > > > noticed you still had a rc release in the tracker system.  For sp=
arc
> > > > > 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
> > --=20
> > Best regards,
> >  Kilian
> >=20
>=20
>=20

--=20
Best regards,
 Kilian

--=-7U/lSUt+7CvD92kK12mI
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)

iD8DBQBBZlRGvdkzt4X+wX8RAjZWAJ9kKqDHEUxP3px1qzh7g/r+pBLugACfQOfR
Uh7/oqn8J/JTvpXgE2aPVm0=
=lfKd
-----END PGP SIGNATURE-----

--=-7U/lSUt+7CvD92kK12mI--