-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 13, 2009 at 11:51:48PM +0200, Andreas Tille wrote: > On Mon, 13 Apr 2009, Jonas Smedegaard wrote: > >> Gnash 0.8.5 was released for Debian Sid the other day, and works >> nicely for me - I have now watched a youtube video online for the >> first time ever (I've used clive till now). Other flash sites, like >> the british mikmik webdesign website that interests my girlfriend, >> works too. > > > That's really good news. > >> I have backportet the new Gnash to Lenny for i386 and amd64. Add to >> /etc/apt/sources.lst the line below, if you want it: >> >> deb http://debian.jones.dk/ lenny gnash > > Any reason not to use backports.org?
I do not trust backports.org. So I won't encourage others to trust it either, by publishing my work there. backports.org "will run without new libraries (wherever it is possible)" but in many cases, especially with larger projects, that either means massaging the package so that in reality it becomes a slightly different package, there is cheating involved. I call it cheating because there is no structure for handling the needs for chains of backports - each backported package is assumed being possible to compile against old libraries only. This concrete case is a good example: Debian recently switched to a major new release of libtool, and shortly after that the new Gnash was released for Debian. My packporting effort revealed[1] that the package turns out to depend on that new libtool, and I needed to also backport the newer libtool. Alternatively I could probably have reworked the packaging to force-regenerate the libtool part - but I would risk breaking something in such invasive change. What I did was compile libtool 2.x in a clean Lenny environment, and afterwards compile gnash 0.8.5 in an _almost_ clean Lenny environment - poisened only by that backportet libtool. Oh, and I also tightened gnash build-dependencies on libtool and libltdl to force use that newer release. The difference between my backports and those at backports.org is that I keep track of the chains of poisening during chained backports. If later a bug is revealed in part of a chain, I can easily see what needs rebuilding and can redo same chains again using newer/corrected parts. Backports.org is not transparent about this need for hacking not only each single package but also sometimes their dependencies. Thanks for asking, - Jonas [1] See http://bugs.debian.org/523902 - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknj6KMACgkQn7DbMsAkQLhdAACeNDvDjh1Su1aTuXbZQ4WlffAT MLkAnic2+9BTRGiYI/5kwh9ORWf8Y8CH =A4P2 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
