module-assistant support for zaptel
Tzafrir Cohen
tzafrir.cohen@xorcom.com
Sun, 27 Mar 2005 23:06:23 +0200
--BZaMRJmqxGScZ8Mx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
[ This post still does not refer to the issues rased by Eduard Bloch]
On Sun, Mar 27, 2005 at 02:13:44AM +0200, Tzafrir Cohen wrote:
> 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.
After some extra games: I couldn't make anything useful with m-a so I
reverted back to my original makefile for building the modules. I
changed the package so that the source will be extracted under
/usr/src/modules/zaptel-source and this appears to work well, but I
never did get m-a to work.
However the package still lacks a control file. I added it back manually
and started building, but found no way to generaet a changes file for
the generated package: dpkg-genchanges complained that the files list
was missing. This is where I left it. I attach my current rules file .
>
> >
> > 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.
>
> --
> Tzafrir Cohen icq#16849755 +972-50-7952406
> tzafrir.cohen@xorcom.com http://www.xorcom.com
>
> _______________________________________________
> Pkg-voip-maintainers mailing list
> Pkg-voip-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-voip-maintainers
--
Tzafrir Cohen icq#16849755 +972-50-7952406
tzafrir.cohen@xorcom.com http://www.xorcom.com
--BZaMRJmqxGScZ8Mx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=rules
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
# This version can build kernel modules via make-kpkg as
# well as with module-assistant. It also serves to build packages for
# userspace utils and for modules source.
# It is based on ipw2100 package rules file.
#
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
# This is the debhelper compatibility version to use.
export DH_COMPAT=3
include /usr/share/dpatch/dpatch.make
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
endif
## MODULE-ASSISTANT STUFF
# prefix of the target package name
SRCPKG:=zaptel
PACKAGE:=$(SRCPKG)-modules
# modifieable for experiments or debugging m-a
MA_DIR ?= /usr/share/modass
# load generic variable handling
-include $(MA_DIR)/include/generic.make
# load default rules
-include $(MA_DIR)/include/common-rules.make
MAJOR:=$(subst $(wordlist 1,2,$(subst $(KVERS),., )), ,.)
ifeq ($(MAJOR),2.6)
KO=k
endif
kdist_clean: clean-unpatched
kdist_config: prep-deb-files
binary-modules: prep-deb-files
dh_testdir
dh_testroot
dh_clean -k
sed -i -e 's/$${kpkg\:Kernel\-Version}/$(KVERS)/' \
debian/control
make -C modules KERNEL_SOURCES=$(KSRC) MODVERSIONS=detect \
KERNEL=linux-$(KVERS)
make install-modules \
DESTDIR=$(CURDIR)/debian/$(PKGNAME)/lib/modules/$(KVERS)/zaptel/
# dh_installdocs
dh_installdebconf
dh_installchangelogs
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol -- -v$(VERSION)
dh_md5sums
dh_builddeb --destdir=$(DEB_DESTDIR)
## END OF M-A SECTION
configure: configure-stamp
configure-stamp: patch-stamp
dh_testdir
touch $@
build: build-indep-stamp build-arch-stamp
build-arch-stamp: configure-stamp
dh_testdir
$(MAKE) programs
touch $@
build-indep-stamp:
touch $@
clean: clean-unpatched unpatch
clean-unpatched:
dh_testdir
dh_testroot
rm -f build-*-stamp configure-stamp
# Add here commands to clean up after the build process.
-$(MAKE) clean
dh_clean
install: install-arch install-indep
install-arch: build-arch-stamp
dh_testdir
dh_testroot
dh_clean -k -a
dh_installdirs -a
# Add here commands to install the package into debian/tmp
$(MAKE) install-programs DESTDIR=debian/tmp
dh_install -a --sourcedir=debian/tmp
dh_install -a debian/genzaptelconf usr/sbin/
dh_install -a debian/$(SRCPKG).lintian \
usr/share/lintian/overrides/$(SRCPKG)
SRCDIR=debian/tmp/modules
install-indep: build-indep-stamp
dh_testdir
dh_testroot
dh_clean -k -i
dh_installdirs -i
# driver source code
mkdir -p $(SRCDIR)
cp -r Makefile *.c *.h *.rbt zaphfc qozap $(SRCDIR)
dh_install -i zaptel.h usr/include/linux/
ln -s ../../src/modules/$(SRCPKG)-source/torisa.h \
debian/$(SRCPKG)-source/usr/include/linux/
# Packaging infrastructure
mkdir -p $(SRCDIR)/debian
cp -r debian/*-modules.* debian/rules debian/changelog \
debian/copyright \
$(SRCDIR)/debian
cp debian/control.modules.in $(SRCDIR)/debian/control
# isn't it strange to copy the files there only for packing them?
#tar cf - -C $(dir $(SRCDIR)) modules | gzip -9 \
# > debian/$(SRCPKG)-source/usr/src/zaptel.tar.gz
mkdir -p debian/$(SRCPKG)-source/usr/src/modules/$(SRCPKG)-source
cp -a $(SRCDIR)/* debian/$(SRCPKG)-source/usr/src/modules/$(SRCPKG)-source
# Build architecture-independent files here.
binary-indep: build install-indep
dh_testdir
dh_testroot
dh_installdocs -i
dh_installchangelogs -i ChangeLog
dh_link -i
dh_compress -i
dh_fixperms -i
dh_installdeb -i
dh_gencontrol -i
dh_md5sums -i
dh_builddeb -i
# Build architecture-dependent files here.
binary-arch: build install-arch
dh_testdir
dh_testroot
#install -m644 debian/zaptel.modprobe.d debian/zaptel/etc/modprobe.d/zaptel
dh_installdocs -a
dh_installman -a debian/ztmonitor.8 debian/ztcfg.8 debian/zttool.8 \
debian/genzaptelconf.8
# should be removed, eventually. Still left for compatibility
dh_installinit --update-rcd-params="defaults 15 30"
dh_installexamples -a zaphfc/*.conf* qozap/*.conf*
dh_installmodules -a
dh_installchangelogs -a ChangeLog
dh_link -a
dh_strip -a
dh_compress -a
dh_fixperms -a
dh_makeshlibs -a -V
dh_installdeb -a
dh_shlibdeps -a -ldebian/libtonezone1/usr/lib
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -a
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure patch unpatch
--BZaMRJmqxGScZ8Mx--