[Pkg-voip-commits] r1911 - in zaptel/trunk: . debian vzaphfc

[Tzafrir Cohen]

On Sat, Jun 17, 2006 at 10:54:54PM +0200, Kilian Krause wrote:
> Tzafrir,
> 
> > >    zaptel/trunk/vzaphfc/vzaphfc.h
> > >    zaptel/trunk/vzaphfc/vzaphfc_main.c
> > 
> > The bristuff modules are currently "manually" added by me to the zaptel
> > bristuff patch. Do you recon we should import them into our tree as
> > well?
> 
> the bristuff patch comes as patch whereas the vzaphfc comes as tarball.

Bristuff comes as a tarball. It has three patches (zaptel, libpri and
asterisk), a number of subdirectories: zaphfc, qozap, cwain, ztgsm,
libgsmst, isdnguard. The first four are zapbri kernel modules.

If we follow the same logic, we should add those subdirectories, and
reduce zaptel's bristuff.dpatch to the original proprotions of
zaptel.patch.

> Therefore I found it easier to commit it as part of the SVN dirstructure
> than to make it artificially become a dpatch.
> 
> > Or should we stick with a patch that only changes debian/ ?
> 
> I'd rather stick with it while it comes as a patch from upstream. Let's
> just hope the vzaphfc fixes the problems that I had already tried to
> solve with zaphfc-florz and which at some point remained there. Once
> I'll have a new setup up and running stable, I think we can dump
> zaphfc-florz and concentrate on vzaphfc and visdn for consumer cards.
> 
> 
> [snip - 2.4 builds and 2.6.8]
> 
> Well, the decision was to support what debian-kernel is targetting at.
> That's 2.6.16 at the least. Thus there should be no problem dropping the
> legacy support. Unfortunately right now the makefiles seem to be
> incomplete at some point as zaptel-modules won't build. That's still to
> be verified and I'm hoping on waldi to give a helping hand here. I know
> the version with the double makefile infrastructure eases things for a
> larger set of possible kernels, yet the cost is surely much more code to
> maintain. If you see a real demand for custom kernels that are not
> covered by what's now in SVN, feel free to switch over to whatever you
> see fit and drop me a note once you think I should give the
> zaptel-modules another go.

I believe you lost me here:

My main point is that mixing Kbuild config and standard makefile is
yuck. I then suggested some two ways to separate the two. The "proper"
one (using a file named "Kbuild" will not work on Sarge. I suggested a
workaround that will.

On 2.6 there will not be a need to call make directly from that dir:
you'll only need to add it to the list of targets (as you do for xpp).

> 
> 
> > Speaking of other drivers: interested in the driver for a modified tor2
> > card as sold in http://pbxhardware.com/ ? In this case I'll need actual
> > users, as I kind of lost touch with the author. I can add the patch in
> > just the same.
> 
> If there's a demand for it, why not. If there's no need, we shouldn't
> bloat the package without having a proper testbed.

Just what I thought and why I have not commited that patch. Should
testers arise, give me a beep.

-- 
Tzafrir Cohen      sip:tzafrir at local.xorcom.com
icq#16849755       iax:tzafrir at local.xorcom.com
+972-50-7952406           
tzafrir.cohen at xorcom.com  http://www.xorcom.com