iB::Topic::July Extensions

	Damn Small Linux :: Damn Small Linux Board The DSL Forums

» Welcome Guest
[ Log In :: Register ]

Damn Small Linux Board » MyDSL Extensions » The Testing Area » July Extensions

		Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
		Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic

Pages: (9) </ 1 2 [3] 4 5 6 7 8 ... >/

[ Track this topic :: Email this topic :: Print this topic ]

Topic: July Extensions

< Next Oldest | Next Newest >

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 03 2007,20:20

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

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 03 2007,20:57

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.

stupid_idiot Offline

Group: Members
Posts: 344
Joined: Oct. 2006

Posted: July 03 2007,21:46

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'.

stupid_idiot Offline

Group: Members
Posts: 344
Joined: Oct. 2006

Posted: July 04 2007,14:08

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.

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 09 2007,10:52

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

40 replies since July 02 2007,23:24

< Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (9) </ 1 2 [3] 4 5 6 7 8 ... >/

Damn Small Linux Board » MyDSL Extensions » The Testing Area » July Extensions