[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nonfree-flashplugin in debian-edu etch


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 

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 


Attachment: pgp4ytrEeRIDG.pgp
Description: PGP signature

Reply to: