[ATrpms-users] Asterisk rpms busted...

[Axel Thimm]

On Mon, Jul 17, 2006 at 04:07:26PM -0400, Michael H. Warfield wrote:
> On Mon, 2006-07-17 at 21:40 +0200, Axel Thimm wrote:
> > On Mon, Jul 17, 2006 at 01:07:53PM -0400, Michael H. Warfield wrote:
> > > 	I'm seeing this error after updating an FC5 system to 1.2.10:
> > > 
> > > asterisk -vvv
> > > 	: - lots of verbose stuff...
> > >  [app_rxfax.so]Jul 17 12:55:11 WARNING[26304]: loader.c:325 __load_resource: /usr/lib/asterisk/modules/app_rxfax.so: undefined symbol: t30_get_far_ident
> > > Jul 17 12:55:11 WARNING[26304]: loader.c:554 load_modules: Loading module app_rxfax.so failed!
> > > 
> > > rpm -qf /usr/lib/asterisk/modules/app_rxfax.so
> > > asterisk-1.2.10-26.fc5.at
> 
> > t30_get_far_ident is a symbold defined in libspandsp. Isn't spandsp
> > installed on your system? What does ldd on app_rxfax.so say?
> 
> 	That was it.  Spandsp has been installed all along but it didn't get
> updated, for some reason.  It was linking against an old version of
> libspandsp.  What's curious is that spandsp didn't get updated when I
> updated asterisk.  It showed that he older version had been installed
> from atrpms but it didn't update it.  I just manually updated it from
> atrpms and that seems to have done the trick.

Well, given the thread I read on fedora-list you were badly
recommended to selectively enable ATrpms and that's the expected
outcome.

Just to make it once again clear, as it comes up every few weeks:
Partial or selective enabling of repos is broken already in concept. I
don't need to go again into the datail, as you have given the example
already. Therefore no repo maintainer will ever (be even able to)
support this kind of half-enabled setup.

> 	I've added spandsp explicitly to my list of packages to be updated from
> atrpms so that shouldn't be a problem again.

Aha, here it comes. :)

And did you think about further dependencies? spandsp is just one. In
another thread you mentioned mythtv, which has about 40
dependencies. This will break, too, on the next update, and don't
blame ATrpms for that.

> Thx.  Don't know how I missed that one when I set my update package
> list up but, I guess, it didn't get pulled in through dependencies.

If it's selectively/partially enabled it never will.

> > > 	Also...  In attempting to upgrade I ran into a critical dependency
> > > where I couldn't update the Zaptel packages because of conflicts with
> > > the zaptel-kmdl modules.  I tried installing the newer modules, but that
> > > also failed.  I had to erase the older modules from the system, then
> > > upgrade Asterisk and Zaptel and then install the newer zaptel-kmdl
> > > packages.  Seems to be a catch-22 in the upgrade path there.
> 
> > If the upgrade succeeds manually, then it's not a dependency issue
> > (otherwise you would run into it again, dependencies are static and
> > stateless), but probably more an issue with your depsolver, which I
> > guess is yum. Try smart or even apt and feel the difference ;)
> 
> 	I've lost the error messages at this point but, basically, it would
> complain that something was required by the lkm modules for the 2145
> kernel and then abort.  It would do that if I tried to "update" zaptel
> or simply "install" the lkm package for the 2157 kernel (which, I
> believe, then required the zaptel update by dependency, thus tripping
> over the conflict with the 2145 lkm package).  Manually removing the lkm
> package for the 2145 kernel allowed me to update asterisk and zaptel and
> then I could go back and separately install the lkm modules for that
> version of zaptel.  It was basically a catch-22 as long as the lkm
> modules for the 2145 kernel were installed.

Given the spandsp issue before and lack of any reporducability by
others or myself, I'll file that as "yum configuration bug".

Repeating myself, but it's worth it:

1) never, ever use selective/partial enabling of ATrpms or any other
   repo.
2) If you still do so, don't come crying with the broken pieces.
3) If yum goes bananas, verify the situation with smart. Too many yum
   bugs are mistakenly considered bugs in ATrpms packages [1].

[1] to give an idea of bug ins yum breaking ATrpms see for instance
    http://www.redhat.com/archives/fedora-list/2005-January/msg01826.html
    It's an old post, but the general situation hasn't changed. yum
    bugs hit the user and he thinks it was ATrpms.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20060719/2f3d9e4d/attachment.bin