[ATrpms-users] Dahdi w/ Oslec

[Axel Thimm]

On Tue, Mar 30, 2010 at 09:37:06PM +0000, Joseph L. Casale wrote:
> >dahdi still needs manual intervention (copying over the echo dir from
> >the kernel), so it is not turned on by default.
> >
> >But for CentOS there is also another issue: the kernel doesn't carry
> >oslec at all, so it needs either a lucky backport or the old install
> >method outlined at the oslec homepage. So for RHEL/CentOS we would
> >need an oslec kmdl first and then patching dahdi.
> 
> Hey Axel,
> Thanks for the post. So after further looking (I admit now I don't know
> much about rpm building yet!) I see a few things:
> 
> I have only ever done it manually and as patch to rpms using this method:
> http://www.rowetel.com/ucasterisk/oslec.html#install_dahdi

Did it work? I kind of doubt that parts of kernel 2.6.28+ could build
cleanly on 2.6.18, but maybe it does.

> It seems Tzafrir Cohen has a git repo with a bit of code that can make a nice
> patch that actually creates the kernel echo files etc and writes them in the
> dahdi source dir to build similarly to the rowetel link:
> http://git.tzafrir.org.il/?p=dahdi-extra.git;a=summary

That looks most promising.

> I am unclear about the need for the oslec kmdl, it can't be just included
> in the dahdi rpm?

If the dahdi kmdl is to be treated similar on RHEL and Fedora, then on
Fedora it would have no oslec bits as these are part of the
kernel. The two kmdls would account for this and the fact that these
are indeed two different projects.

> How is it intended that one deploys and uses the rpm you provide?
> It doesn't have any deps or provides?

It has dependencies on the kernel it needs.

> Does one handle getting the user space tools on his own, the digium ones
> are rather tailored to their build methods.

Which tools are you referring to? Most are already packaged up.

> lastly, the testing rpm for your latest build added and "extra" dir in the
> module path under the kernel, was that by mistake?

"extra" is the default dir for modules built oot. It is nicer to have
them in a parallel tree under updates, but ultimatively it is a
cosmetic issue.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.atrpms.net/pipermail/atrpms-users/attachments/20100331/fd833002/attachment.sig>