The Testing Area :: July Extensions



Quote
export your CFLAGS variable


Not useful in this case since the gcc1-with-libs headers are in the expected place so theres's no need to point at it.  The problem as I've said is there appears to a mismatched header/lib. The mplayer ./configure script points this out in the configure log.  Unfortunately I can't recall the version numbers (long time ago), if I get obsessed enough I'll get it out and run it again.

Woody's libpng2 is 1.0.12-3.woody.9 which does have the same soname and minor version as dsl's.

MMmm..  looking now I notice gcc1-with-libs.dsl has a symlink libpng.so that points eventually at /KNOPPIX/usr/lib/libpng10.so.1.0.15
dsl also has libpng12 and libpng.so.2.1.0.12

The only headers gcc1-with-libs contains are libpng -> libpng12  (no libpng10?).

I'm wondering if that has the effect of pointing anything looking for libpng.so.2 away from /usr/lib/libpng.so.2.1.0.12, and instead finds libpng10.so.1.0.15 ie the wrong lib ....

That might be the problem.  Looking on Fedora, there is a soname symlink:

libpng12.so ->libpng12.so.0 ->libpng12.so.0.1.2.8

ie no confusion with libpng2

libpng.so.2 ->libpng.so.2.1.0.18

or with libpng3:

libpng.so ->libpng.so.3 ->linpng.so.3.1.2.8

I think libpng.so is supposed to point at the highest version of libpng
OK, now I'm weirded out.

I had some 6-month old svn sources for mplayer on a partition so I just tried compiling them - and - the GUI compiled without problems!  I didn't have to install libpng2-dev etc, nothing.

So, perhaps my issue there was only with mplayer1.0pre8, where I definitely had to install that and where I still could only get the gui by compiling statically.
Quote (WDef @ July 03 2007,10:57)
Not sure there's much point in posting all the codecs in your uci.
I read a post where one of the mplayer developers said that users would only ever need those in the essential codecs tarball - the others are apparently not of any use ordinarily?

Thanks WDef.
I am sorry for not informing all of you about what my naming actually means. 'w32codecs.uci' is actually 'essential-20061022' with unneeded codecs removed. 'w32codecs-essential.tar.gz' is a minimal set which people usually need (Real,vivo,WM).
mplayer's $src_dir/etc/codecs.conf was edited to remove entries which I think are not needed, i.e. multiple-versions of the same codec, codecs which are obsolete but included for backward-compatibility, codecs which I did not compile in (e.g. libdv, libmpcdec). Personally, I consider a codec essential only if there is no other codec supporting the format(s), or if the native decoder is listed as 'buggy'.
Quote (mikshaw @ July 03 2007,10:20)
The one thing I'd be concerned about is the license of individual codecs. Please make sure each one you use is actually allowed to be redistributed, and include any required license texts.

They are certainly not under the GPL. I plan to put 'Copying-policy: ' as blank. I will understand, if this is unacceptable.
REMOTE EXPLOIT VULNERABILITY IN GNUPG EXTENSIONS

Versions of GnuPG < 1.4.6 and GnuPG-2 < 2.0.2 contain a serious remote exploit vulnerability. This affects the existing GnuPG extensions in the dsl repo, including gpgpatched.dsl that I posted recently.

Refer: http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000246.html

DO NOT USE THESE OLDER VERSIONS.  These should perhaps be considered for withdrawal from the repo.

I've sent the current maintaned version of gnupg-1.x (gnupg-1.4.7.dsl) to Robert.

gpgpatched.dsl is now redundant in any case since increased iterations can be obtained with this newer version by setting s2k-count 8388608 in ~/.gnupg/gpg.conf or as a command line parameter: --s2k-count=8388608

If you have a hard drive install and have installed gnupg.dsl, you will need to delete the old gnupg binaries since gnupg-1.4.7 puts these in the default locations /usr/local/bin whereas gnupg.dsl puts these in /usr/bin
Next Page...
original here.