On Thu, Oct 15, 2009 at 08:09:19 +0300,
Axel Thimm <Axel.Thimm(a)ATrpms.net> wrote:
On Wed, Oct 14, 2009 at 12:25:00PM -0500, Bruno Wolff III wrote:
> On Wed, Oct 14, 2009 at 18:31:03 +0200,
> > Why should we make peoples' lives harder getting the tools they
> > need? Example: Somebody without the DAHDI Kernel Modules would
> > probably not try to use the DAHDI Tools since he probably won't even
> > know what it's good for. However It makes things easier for the
> > people who do know what DAHDI is to have tools to use their DAHDI
> > hardware (they compiled/got the Kernel modules for) just a yum
> > install away.
>
> Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time
> without having a version for a specific version Fedora. For example there
> is no rawhide version now and there was a long period without one for
> F11.
Rawhide support has quite low demand and the kernel changes daily or
more frequently in early rawhide, so any kernel bound support is
outdated before it is released. We usually fire up the rawhide support
Yes, but usually just rebuilding from the source rpm would work if
I had an environment where I could do that. I am doing that now with
the version based on a spec file from
messinet.com.
about a month or so before the targeted release date (which means
about now). I don't think that F11 was w/o dahdi-linux kmdls for any
long period.
Possibly it was during the F11 rawhide period that I looked and I didn't
check back for a while after the release.
Unfortunately my tdm card is in my only machine at home that has 3d graphics at
all working using the drivers in Fedora. And I needed to go to rawhide to
get that working more than I needed to having tdm card working (though in
the end I got both).
> There are issues trying to rebuild atrpms src rpms on fedora.
Just
> grabbing atrms-rpm-config doesn't help with recursion issues that Alex
> doesn't see because of his custom environment.
Who's Alex, and why doesn't atrms-rpm-config work? You may see
Sorry about misspelling your name.
`recursion' warnings due to rpm's limitation of macros depth
(which
has nothing to do with recursion), which is at 16, but in reality
means about 3-4 nested macros.
Yes. But I didn't see any clear instructions for how to work around it.
It seems that for some people using --define can work around the problem
if you know what to define. There was also a comment that you don't see
the problem because of something in your environment but I didn't see
any directions on how to set up a similar environment.
> What I had to do for F12 is grab a spec file (that get's
updates at
> the source) that was proposed for rpmfusion (but never got adopted
> by them) and then use an svn version of dahdi that has a fix for a
> change in the way the kernel is being built (some compatibility
> feature that got dropped in 2.6.32). That box has been extra
> unstable lately, though I don't know if that is do to 3D graphics or
> dahdi-linux.
Have you tried the common src.rpm at ATrpms? Maybe you should check
out ATrpms in a couple of days and see whether there is dahdi support
for F12 there.
I tried using the dahdi-linux src rpm while having atrpms-rpm-config
installed, but hit the recursion problem and got stuck there. I would
still have had the problem with the last released dahdi not working
with 2.6.31 kernels. But fixing that would have taken the same route
as with the path I ended up taking.