Hi, On Sunday 10 February 2008 13:07, Petter Reinholdtsen wrote: > > I wonder if we should upload the very same package from bpo to our > > archive. To etch-test and then eventually move it to our etch. And > > if so, should we use a lower version number as in bpo (by adding > > ~edu.etch+1) or just upload from exactly the same source? It is the > > same after all. > If it is the exact same package, I suggest we use the same version > number. It is / can be. > If it is an autobuild binary package, we should use a > different version number. What do you mean with "autobuild" in this context? I just saw that 1:1.3 (in sid) is available for amd64, while it's explicitly disabled in 1:1.3~bpo40+1. I've asked the maintainer why :) On Sunday 10 February 2008 15:00, Knut Yrvin wrote: > I meet the lead developer on Gnash, Rob Savoye at Open Source in Mobile, > September 2007. I've met him in August - the free software world is small :) > If it's just about build parameters It's not. gnash is not present in etch. The version in sid is outdated too. > maybe a Gnash backport could be a > better solution for Etch than the proprietary nonfree-flashplugin? I was going to say "How about filing a wishlist bug against the package at bugs.debian.org?", but thats useless, see below... For getting accepted at backports.org gnash would needs to be in testing, which is blocked by 3 RC bugs. See http://release.debian.org/migration/testing.pl?package=gnash One of them is a real blocker preventing us from including latest gnash in our etch: gpl3 vs gpl3 compatibility problems, read the maintainers blog post about it: http://www.miriamruiz.es/weblog/?p=144 - so gnash is no option for etch. regards, Holger
Attachment:
pgp4ytrEeRIDG.pgp
Description: PGP signature