Patch attached for net-www/gplflash-0.4.13-r1
Created attachment 86557 [details, diff] 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.