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 > 'patch' in this case. All code I have done is in the cvs and you can > get that from the asterisk cvs. Are you asking for a patch to the > 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 > mark? I have yet to get any mail from any other mark about this bug > so clarification would be helpful. It would also help if you would be > so kind as to point to any documentation you think would be helpful > 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?m a long time debian user but > this has been the first time I have reported a bug or taken a > interest in being a DD. > > > - D > > > > > On 7 Oct 2004 at 23:23, Kilian Krause wrote: > > > 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 > > > lag in terms of the data on the site and what is current? Then again > > > I use cvs-current so I guess anything less would be seen as old to > > > 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 > > > development tools, much less the ability to do sun4u based packages > > > outside of kernel images. It was impossible to compile for some > > > instruction sets since the tools where not there from what I was told > > > 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 > > > release the ssh libs/tools as a additional sun4u based package; It > > > was simply not a option then. > > > > > > I personally believe that debian policy needs to be upgraded with the > > > times and sparc64 added as a official port now that this time around > > > it is a valid option, but as I am not a official debian developer > > > *yet* I do not have the kind of pull someone like yourself may have. > > > Also the sudden addition of a new port may tick people off hoping to > > > get testing released as current so while the idea is sound it may > > > 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. > > > > > Either way it would be nice to have the added option of the > > > additional package. > > > > 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 > > > compilation defaults as all the c code is fairly portable. The real > > > problems we have been having are with zaptel. But with the large > > > development tools upgrade in this release I am told that will no > > > longer be a problem, just remember by default debian policy sparc > > > kernel images can be both 32 bit sparclite and ultrasparc64 sun4u so > > > the zaptel kernel modules need to be packaged both ways to be > > > complaint as far as I am aware of. > > > > 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. > > > > > > - D > > > > > > > > > On 7 Oct 2004 at 9:17, 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.. > > > > > > > > -- > > > > Best regards, > > > > Kilian > > > > > > > > > > > > > > -- > > Best regards, > > Kilian > > > > -- Best regards, Kilian
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil