Bugzilla Bug 132922

Patch attached for net-www/gplflash-0.4.13-r1

Created an attachment (id=86557) [edit]
removes "extra qualification" errors

Patch makes it compile.

cant confirm 
even without patch it compiles fine here

Portage 2.1_pre10-r5 (default-linux/amd64/2006.0, gcc-4.0.3, glibc-2.4-r2,
2.6.16.9 x86_64)
=================================================================
System uname: 2.6.16.9 x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.12.0_pre19
ccache version 2.4 [enabled]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r1
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.92
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox
sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage-local"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="amd64 7zip X a52 aac alsa async audiofile avi bash-completion bitmap-fonts
browserplugin bzip2 cdparanoia cdr cli crypt cups dga djbfft dts dtslive dv dvb
dvd dvdr dvdread encode ffmpeg flac font-server geoip ggi gif glut ieee1394
imagemagick imlib isdnlog joystick jpeg jpeg2k kde lcms lm_sensors
logitech-mouse lzo lzw lzw-tiff mad matroska mikmod mjpeg mng mp3 mp4 mpeg
mplayer musepack nas ncurses nls nowin nptl nptlonly nsplugin nvidia ogg
oggvorbis openal opengl oss pcre pdflib png pppd profile qt quicktime readline
reflection samba sdl session slang sndfile speex spl sql ssl tcpd tga theora
threads tiff truetype truetype-fonts type1-fonts usb v4l v4l2 vcd vdr vorbis
x264 xchatdccserver xine xinerama xml2 xmms xorg xv xvid yv12 zlib zvbi
elibc_glibc input_devices_keyboard input_devices_mouse input_devices_joystick
kernel_linux linguas_de userland_GNU video_cards_nv video_cards_nvidia
video_cards_vesa"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

Adjusted the summary and removed the blocker.

It is related to bug #118816.

Sorry for the confusion :-/

Added the blocker again after i've read that gcc-4.1 issues should block 117482
too.

If no one objects to me adding this patch soon, I'll be adding it.

patch works ok

Patch works here as well but I just noticed that gplflash is rather dead and
replaced by gnash which is also in portage...

CCing treecleaner(s)

03-02-2006 :: GPLFlash2 shutting down! (gplflash1 continues)

After going through the code of gplflash2, it was decided it was too messy and
a new design was needed. But before a the design process took off, a new
project caught our eye: gnash. It is not perfect, but it got some advantages
over gplflash2, and most of the developers of gplflash2 will move to gnash.

But this does not mean the gplflash-project is shutting down. The old gplflash1
code is still being hacked and improved, and will continue to be maintained.

http://gplflash.sourceforge.net/


The last CVS commit was on 2005-04-03.  Last ml message is Dec 2005, but it's
about gnash ;d.  Bring out yer dead..

(In reply to comment #8)
> CCing treecleaner(s)
> 
> 03-02-2006 :: GPLFlash2 shutting down! (gplflash1 continues)
> 
> After going through the code of gplflash2, it was decided it was too messy and
> a new design was needed. But before a the design process took off, a new
> project caught our eye: gnash. It is not perfect, but it got some advantages
> over gplflash2, and most of the developers of gplflash2 will move to gnash.
> 
> But this does not mean the gplflash-project is shutting down. The old gplflash1
> code is still being hacked and improved, and will continue to be maintained.
> 
> http://gplflash.sourceforge.net/
> 
> 
> The last CVS commit was on 2005-04-03.  Last ml message is Dec 2005, but it's
> about gnash ;d.  Bring out yer dead..
> 

We need to wait for gnash to go stable.

Running Amd64 and the patches works for me. Just Curios, Why hasn't it been
merged into portage?

*** Bug 153658 has been marked as a duplicate of this bug. ***

I can confirm making these changes manually allowed gplflash to compile, if
verifcation helps :)

work on gplflash has been abandoned in favor of net-www/gnash.  although the
web page promises work on gplflash1 will continue, no one has touched the code
in almost two years.  once we have gnash stabilized, gplflash will be removed
from portage.

*** Bug 158977 has been marked as a duplicate of this bug. ***

I appreciate we want this to be removed, but gplflash is still in the tree and
it looks like it will remain there for an indefinite period of time while gnash
is being improved. We have a patch available, that several users have confirmed
works. Is there any reason to delay applying the patch, and continue to leave
broken stuff in the tree?

(In reply to comment #15)
> I appreciate we want this to be removed, but gplflash is still in the tree and
> it looks like it will remain there for an indefinite period of time while gnash
> is being improved. We have a patch available, that several users have confirmed
> works. Is there any reason to delay applying the patch, and continue to leave
> broken stuff in the tree?
> 

Just cause it builds does not mean it is usuable. This has a dead upstream and
needs to be removed from the tree. 

After talking to Anarchy on IRC, I'm reassigning this to treecleaners. Anarchy
says mozilla isn't going to support this, so its effectively unmaintained. As
it causes more problems than it seems to solve, and it appears there are better
alternatives (gnash), I think it would be best to punt it. Putting this to a
vote. (In case anyone isn't aware, antarus set the number of votes needed to
punt a package at 3). Mozilla team, feel free to remove yourselves from CC if
you're not interested in the progress of the removal.

Nuke it. There's a better alternative. Upstream is dead. It has issues. Reason
enough for a boot to me. (I swear I added this earlier but bugs was sucking it
up)

(In reply to comment #17)
+1 from me.

Voting yes, but we need a version of gnash to be stabilized first.

anarchy points out that the stable version of gplflash is broken anyways, so i
don't think we need to wait for stabilization in this case.

(In reply to comment #21)
> anarchy points out that the stable version of gplflash is broken anyways, so i
> don't think we need to wait for stabilization in this case.
> 

Can you confirm that it's broken (compiled with this patch?)

(In reply to comment #22)
> (In reply to comment #21)
> > anarchy points out that the stable version of gplflash is broken anyways, so i
> > don't think we need to wait for stabilization in this case.
> > 
> 
> Can you confirm that it's broken (compiled with this patch?)
> 

This is out ragous .. As I am telling you it flat out makes firefox way to
unstable to be supported you still want to support. I suggest you take the
package then as you seem to be the only one interesting in supporting such a
broken implementation of gplflash.

it looks like it'll build with the patch, however stable gplflash depends on
libflash-0.4.10-r1.  libflash builds with gcc-4.1.1, but for some reason not
with the current 4.1 branch of svn, meaning when 4.1.2 gets released this'll
end up breaking again.  i see no problem with applying the patch to the stable
version until then though.

i noticed netscape-flash has a stable version.  maybe we could remove gplflash
now  and just use that for a replacement instead of gnash.  or we could just
patch both gplflash versions and leave it in portage.  if it builds and works,
what reason do we have to punt it?  if we stabilize the ~arch version (which
has no libflash dependency) relatively soon we could avoid the whole 4.1.2
issue.


here's the error if anyone's interested.

c++ -DPACKAGE=\"libflash\" -DVERSION=\"0.4.10\" -I. -I. -I../lib -O3 -Wall
-fno-rtti -fno-exceptions -g3 -c flash.cc  -fPIC -DPIC -o flash.lo
c++ -DPACKAGE=\"libflash\" -DVERSION=\"0.4.10\" -I. -I. -I../lib -O3 -Wall
-fno-rtti -fno-exceptions -g3 -c font.cc  -fPIC -DPIC -o font.lo
swf.h:199: error: previous declaration of 'int shape_size' with 'C++' linkage
flash.cc:266: error: conflicts with new declaration with 'C' linkage
swf.h:199: error: previous declaration of 'int shape_nb' with 'C++' linkage
flash.cc:266: error: conflicts with new declaration with 'C' linkage
swf.h:199: error: previous declaration of 'int shaperecord_size' with 'C++'
linkage
flash.cc:266: error: conflicts with new declaration with 'C' linkage
swf.h:199: error: previous declaration of 'int shaperecord_nb' with 'C++'
linkage
flash.cc:266: error: conflicts with new declaration with 'C' linkage
swf.h:199: error: previous declaration of 'int style_size' with 'C++' linkage
flash.cc:266: error: conflicts with new declaration with 'C' linkage
swf.h:199: error: previous declaration of 'int style_nb' with 'C++' linkage
flash.cc:266: error: conflicts with new declaration with 'C' linkage
make[1]: *** [flash.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
c++ -DPACKAGE=\"libflash\" -DVERSION=\"0.4.10\" -I. -I. -I../lib -O3 -Wall
-fno-rtti -fno-exceptions -g3 -c graphic.cc  -fPIC -DPIC -o graphic.lo
make[1]: Leaving directory
`/var/tmp/portage/media-libs/libflash-0.4.10-r1/work/libflash-0.4.10/lib'
make: *** [all-recursive] Error 1

!!! ERROR: media-libs/libflash-0.4.10-r1 failed.

(In reply to comment #23)

> This is out ragous .. As I am telling you it flat out makes firefox way to
> unstable to be supported you still want to support. I suggest you take the
> package then as you seem to be the only one interesting in supporting such a
> broken implementation of gplflash.

ah, sorry.  this is the first time anyone's mentioned that it breaks stuff.  i
thought the only issue was the build error.

Yay, more phun here... ;) This crashes FF & Co. pretty badly, anyone can try :)
+1 for removal.

ahh lovely, a completely mishandled bug due to new policy ;)

Mozilla, you want it dead, kill it.

Sorry for the bugspam.

*** Bug 159615 has been marked as a duplicate of this bug. ***

(In reply to comment #27)
> ahh lovely, a completely mishandled bug due to new policy ;)
> 
> Mozilla, you want it dead, kill it.

(In reply to comment #17)
> Anarchy says mozilla isn't going to support this, so its effectively unmaintained.

I'll do it. Antarus has already masked it, punting is all that's left.

net-www/gplflash is the successor of media-libs/libflash which is in the tree
and not masked and maintainer-needed and dev-libs/DirectFB-extra uses it.

Is libflash not broken?

libflash at least compiles.

gplflash is removed, yay!

(In reply to comment #31)
> libflash at least compiles.

Yeah, because it was fixed in bug #118816. Compare the patch attached to 118816
and the patch here.

> gplflash is removed, yay!

Yay. The son is dead, long live the father.
Well, i don't care.