module-assistant support for zaptel

[Diana Cionoiu]

Hello,

Most people do forget that Yate also support zaphfc. I wonder why?

Diana
http://yate.null.ro - Free Software for Telephony.

> On Sat, Mar 26, 2005 at 02:08:04AM +0100, Jose Carlos Garcia Sogo wrote:
> > 
> >  Hi again!
> > 
> >  Module-assistant support is completed by the time you read this mail.
> > For now, we are shipping a overrides file for module-assistant, but a
> > bug has also been filled in that package to cope with this little
> > problem. Thus, I have uploaded all this to svn.
> 
> Looking over the diff, here's something:
> 
> - This package contains the source code for zaptel, a kernel module providing
> - the Zapata telephony API, and device drivers for various telephony hardware,
> - including the Wildcard series of interface cards (X100P, T400P, E400P, S100P,
> - S100U).
> + This package contains the source code for zaptel kernel module providing
> + device drivers for various telephony hardware, including the Wildcard 
> + series of interface cards (X100P, T400P, E400P, S100P, S100U).
> 
> So while we're at fixing the descriptions, what extra hardware is 
> supported by zaphfc?
> 
> Apart from that, I moved all the file copying I could to after copying
> the files from tmp/ to the packages directories. This allows the use of
> dh_installexamples and dh_installdocs and simple dh_install without
> explicit cp and install. I have no idea who'd like to override those
> commands later.
> 
> The name 'zaptel' appears too many times in that package. I tried to
> replace it with my own var called SRCPKG to make it easier to 
> copy&paste copde from this package to another one. Is there such
> existing debian/rules var?
> 
> If the target foo-stamp ends with 'touch foo-stamp' it better be
> replaced with 'touch $@'. This way it won't have to be edited when the
> target name changes.
> 
> I also used make text functions instead of a call to sed through shell
> to calculate KVER . However if you ever define a variable using 
> $(shell command) use:
> 
>   var := $(shell command)
> 
> Rather than:
> 
>   var = $(shell command)
> 
> Otherwise the shell command will be re-expanded every time you use this
> variable.
> 
> torisa.h is created as a symlink to a directory that is not guaranteed
> to be generated until m-a has been invodes. Nor is it guaranteed to be
> of the right version, because m-a is run on-top of dpkg/apt and not by
> dpkg/apt.
> 
> After playing with m-a a bit, I still don't see it saving me work with
> automated builds. It requires quite a lot of initial setup, and most of
> it appears to be the job of root. 
> 
> In addition, packaging the files in an internat tgz bypasses any sanity 
> check lintian and others would do to them.
> 
> I've played with it all day long and it seems very unsuitable for
> non-root builds. If it requires that the code module is compressed to a
> rather than kept in its own directory than it really does harm. If not,
> I have no problem with it and it might actually turn out useful one day.
> 
> > 
> >  I have also changed and improved package descriptions (please review
> > and comment) and I have added a README.Debian file telling about how to
> > compile modules and use them with udev.
> 
> Hmmm... Something the user has to do. Is there any way to do it for the
> user?
> 
> For instance, quoting from README.Debian:
> 
> | If you cannot access the zap/ctl device, check which user asterisk is 
> | running as and add these permissions to your permissions file
> | (ie /etc/udev/permissions.d/50-udev.permissions):
> | # zaptel devices -- if you want to run asterisk as a different user
> | # (asterisk in this case, subtitute it for the appropiate one)
> | zap/*:asterisk:asterisk:660
> 
> So shouldn't the asterisk package include a file
> /etc/udev/permissions.d/60-asterisk-udev.permissions which reads:
> 
>   zap/*:asterisk:asterisk:660
> 
> In thoe worst case the use will have to unload and load the zaptel
> modules.
> 
> In addition, hotplug does a good job at detecting the PCI cards. I
> wouldn't think of automating the scan after installing zaptel. However
> telling the user how to do that would help. 
> 
> Anything better than /etc/init.d/hotplug restart ?
> 
> Another common case to handle is installation of kernel 2.4 without udev
> and without devfs (the default of sarge). My current hack for them is to
> create the device files at asterisk install time if no udev/devfs is
> detected.
> 
> This won't help in a case where someone installed asterisk with kernel 
> 2.6/udev but later runs with kernel 2.4/no-udev. But it still handles
> the common case and does practically no harm.
> 
> > 
> >  Last, I have a comment to make on device ownership. When we create them
> > by hand, when udev or devfs is not being used, we set the ownership for
> > them as root.dialout. At the same time, asterisk is being runned as
> > asterisk.asterisk, and user asterisk is only added to audio group. Here
> > there is a lack of coordination. Or we think that zaptel is going to be
> > used only by asterisk, and we make devices as root.asterisk (which has
> > the problem of failing if asterisk is not installed), or we add asterisk
> > to dialout group, which has the problem of giving with thas asterisk
> > power to lauch modem calls (using ppp, for example)
> 
> Moreover. The x100p is practically a modem with the PCI ID of such.
> Other TDM cards have the PCI IDs of some ISDN cards. Giving permissions
> to dialout on them may actually cause confusion: it has the pci ids
> of a modem, and the permissions of a modem, so it must be a modem :-) .
> 
> However asterisk is not the only user of zaptel. What about yate? I
> don't want the config files of Asterisk to mess with the installation of
> yate and vice-versa.
> 
>