Status of misdn support

[Simon Richter]

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.

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.

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.

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.

> Note that misdn is a rather low priority for me at the moment.

Same thing for me. I might be coerced into preparing a new version RSN
in order to support the new kernels, and possibly even Xen. I'm not
convinced it is a good idea to get new upstream sources as, frankly, I
have no idea whether it still works as everyone else seems to be using
i386 only, and I cannot test it easily ATM as the box I'd use for that
is currently sitting in the living room, so I cannot leave it open,
which I'd have to do because the machine is half-height but the ISDN
card is full height. :-)

   Simon