Bug 112374 – media-video/mplayer-1.0_pre7-r1 fails compile against dev-libs/lzo-2

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Daniel Black (RETIRED) 2005-11-12 23:28:07 UTC]

The compile failure is cause by a move in the location of the libraries and 
headers. 
  
Please make mplayer R/DEPEND on lzo? ( =dev-libs/lzo-1* )

[Comment 1 Daniel Black (RETIRED) 2005-11-12 23:43:22 UTC]

Created attachment 72799 [details, diff]
files/mplayer-1.0_pre7-lzo2.patch

for if/when mplayer does a revision bump and wants to depend on lzo2

[Comment 2 Kenton Groombridge 2005-12-29 18:18:49 UTC]

This patch works perfect for me.  I am not sure what packages still require /usr/lib/liblzo.so.1, but mplayer was the only package on my system that required this.

It is always good to get rid of old stuff.

Thanks,
Ken

[Comment 3 Daniel Black (RETIRED) 2006-01-03 03:12:46 UTC]

dependency changed =dev-libs/lzo-1* so that unmasking lzo-2 won't
break this. lzo1 and lzo2 are slotted.

Version with lzo2 support still required as per attached ebuild.

[Comment 4 Luca Barbato 2006-03-30 23:05:02 UTC]

lzo support is going to be provided by libav, I'd drop the dependency once a snapshot with it will be in portage.

[Comment 5 Daniel Black (RETIRED) 2006-04-22 18:28:54 UTC]

sounds good.

[Comment 6 Christian Faulhammer (RETIRED) 2006-07-26 05:02:59 UTC]

can this be closed?

[Comment 7 Jakub Moc (RETIRED) 2006-08-27 00:33:38 UTC]

(In reply to comment #6)
> can this be closed?

No, it still depends on =dev-libs/lzo-1* 

[Comment 8 Sebastian Krämer 2006-09-27 09:00:10 UTC]

(In reply to comment #7)
> (In reply to comment #6)
> > can this be closed?
> 
> No, it still depends on =dev-libs/lzo-1* 

Hm, actually, the ebuild isn't in portage any more..

[Comment 9 Jakub Moc (RETIRED) 2006-10-19 07:08:55 UTC]

(In reply to comment #4)
> lzo support is going to be provided by libav, I'd drop the dependency once a
> snapshot with it will be in portage.

Hmmm, can we drop the dependency now? 

[Comment 10 Sebastian Krämer 2006-10-19 07:21:14 UTC]

(In reply to comment #9)
> (In reply to comment #4)
> > lzo support is going to be provided by libav, I'd drop the dependency once a
> > snapshot with it will be in portage.
> 
> Hmmm, can we drop the dependency now? 

Actually I meant that pre7 ebuild (*mplayer*) isn't in portage any more..
I suggest the bug reporter checks if this problem persists with pre8 (and possibly this bug gets closed).

[Comment 11 Sebastian Krämer 2006-10-19 07:25:51 UTC]

I just looked it up and mplayer ebuilds pre8 and newer still depend on lzo-1 while both verstions 1 and 2 are unmasked and not keyworded (for *most* archs).
Unfortunately I have no idea if mplayer takes both ot uses the one from libav..

[Comment 12 Sebastian Krämer 2006-10-19 07:28:12 UTC]

(In reply to comment #0)
> The compile failure is cause by a move in the location of the libraries and 
> headers. 
>   
> Please make mplayer R/DEPEND on lzo? ( =dev-libs/lzo-1* )

D'oh, I really should do more reading and thinking here.
In all three currently available ebuilds for mplayer, lzo-1 is defined as RDEPEND. So can this case be closed?

[Comment 13 Jakub Moc (RETIRED) 2006-10-19 07:29:58 UTC]

(In reply to comment #12)
> In all three currently available ebuilds for mplayer, lzo-1 is defined as
> RDEPEND. So can this case be closed?

No. Please, re-read Comment #4 

[Comment 14 Sebastian Krämer 2006-10-19 07:41:25 UTC]

(In reply to comment #13)
> (In reply to comment #12)
> > In all three currently available ebuilds for mplayer, lzo-1 is defined as
> > RDEPEND. So can this case be closed?
> 
> No. Please, re-read Comment #4 

Ok I see the point now I think. Sorry for the trouble.

[Comment 15 Reimar Döffinger 2007-02-19 18:19:02 UTC]

MPlayer SVN now uses internal (libavutil) lzo for all features except one:
For ve_nuv.c liblzo2 is used now, but there really should be very, very few people who actually want this encoder nowadays.

[Comment 16 Steve Dibb (RETIRED) 2007-03-23 01:25:14 UTC]

(In reply to comment #4)
> lzo support is going to be provided by libav, I'd drop the dependency once a
> snapshot with it will be in portage.
> 

closing the bug