Status of misdn support

[Tzafrir Cohen]

On Wed, Aug 30, 2006 at 01:23:53AM +0200, Simon Richter wrote:
> Hello,
> 
> Tzafrir Cohen wrote:
> 
> [mISDN]
> 
> > Let's look at the scope of the package.
> 
> > We have the basic package, providing kernel support and basic userspace
> > tools. What is its status?
> 
> There are two packages, one for the kernel, one for the userspace. Both
> exist in unstable and are synchronized to each other, but are not in etch.
> 
> > The kernel support package seem overly complex to me. It aims at
> > generating not only a modules sources list but also a kernel patch. Its
> > build is very complex and requires quite a few kernel source trees.
> 
> The kernel patch is largely unneeded ATM because the initialisation in
> the code is broken and depends on the correct init order, which can only
> be done by loading the modules in the right order, so monolithic builds
> are disabled by upstream anyway.

Are those userspace 

> 
> It requires one kernel source tree, as it essentially uses the script
> provided in the source to insert the respective files into the kernel
> tree. Said script is heavily patched, I should have committed that
> upstream long ago. In fact, only one file is really needed from the
> kernel tree, and we only require the kernel tree to be installed on the
> buildds because of the lack of "build-arch" support (that is, we build
> the patch and discard it afterwards).
> 
> The other packages generated are a source package that is supposed to
> work with m-a (granted, an older version that did things slightly
> different, so ATM it only works if you compile as root :-( ), a package
> containing the two headers defining the official kernel API (that
> package is a build-dependency of the userspace stuff) and lots and lots
> of prebuilt module packages for the kernels that were current at the
> time the package was last updated. MC Hammer is responsible for
> upgrading this, if you look at the rules file, you see what I mean.
> 
> > I can try to reproduce that package. The infrastructure for building
> > modules has only since improved.
> 
> Yes, but every time I made it work the infrastructure changed under me. :-(
> 
> > Then there is the asterisk-misdn package. That one is not necessary
> > anymore, as it is part of the official Asterisk (source) package.
> 
> Yes, but I'd prefer not to use that and build it out-of-tree. mISDN is
> on its own schedule, chan_misdn is on its own schedule, and tying
> asterisk releases to either of them is going to be painful.

Not exactly. Digium have their own ISDN/BRI card and use misdn as the driver
for it. Thus the ISDN channel is now safely in the tree and getting
attention.

It was actually even rushed into 1.2.11 , even before 1.4 (in earlier
1.2.x versions there was an obsolete version that didn't work well and
wa disabled by default).

> 
> The chan_misdn upstream suggested to me we stick with their stable
> series, which AFAIK is on a different branch in the Asterisk repository,
> also there may be legal issues (essentially, the company that sponsored
> chan_misdn is in direct competition with Digium). Deviating from the
> Asterisk releases in that single directory will mess up the Debian diff
> and do no obvious good, so I suggest to keep it out-of-tree and kick the
> conffile from asterisk-config as well, as it makes the packages conflict.

So would you recommend to disable the build of chan_misdn in Asterisk?

> 
> Also, the Debian package for the userspace deviates from upstream in
> that it builds a _PIC.a instead of a .so for the library stuff, which
> needs to be respected by the packages building against it. Unstable ABI.
> Here be dragons.

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