Bug 192049 - Review Request: gnash - GNU Flash player
Review Request: gnash - GNU Flash player
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Package Reviews List
http://www.gnu.org/software/gnash/
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-05-16 21:37 EDT by Jens Petersen
Modified: 2007-11-30 17:11 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-27 20:54:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
use patch to skip install-info error (458 bytes, patch)
2006-05-17 10:54 EDT, Patrice Dumas
no flags Details | Diff
don't stop on install-info errors during staged install (542 bytes, patch)
2006-05-17 10:56 EDT, Patrice Dumas
no flags Details | Diff
Standard error of rpmbuild (250.07 KB, text/plain)
2006-06-19 07:04 EDT, Giuseppe Castagna
no flags Details
plugin-tempfile-dir.patch (639 bytes, patch)
2006-07-28 05:14 EDT, Jens Petersen
no flags Details | Diff
plugin-tempfile-dir.patch (639 bytes, patch)
2006-07-28 09:15 EDT, Jens Petersen
no flags Details | Diff
explanation of the /tmp/gnash-XXXXXX files (219 bytes, text/plain)
2006-08-20 08:55 EDT, Patrice Dumas
no flags Details
spec file diff to install the README for the plugin (721 bytes, patch)
2006-08-20 08:57 EDT, Patrice Dumas
no flags Details | Diff
spec file patch to add a warning in description and fix deffatr for klash (1019 bytes, patch)
2006-08-25 08:46 EDT, Patrice Dumas
no flags Details | Diff

  None (edit)
Description Jens Petersen 2006-05-16 21:37:27 EDT
Spec URL: http://people.redhat.com/petersen/extras/gnash.spec
SRPM URL: http://people.redhat.com/petersen/extras/gnash-0.7.1-1.src.rpm
Description:
Gnash is a GNU Flash movie player. Till now it has only been possible to play
flash movies with proprietary software. While there are a few other free flash
players, none supports anything higher than SWF v4 at best. Gnash is based on
GameSWF, and supports many SWF v7 features.
Comment 1 Patrice Dumas 2006-05-16 22:03:43 EDT
* klash is now gnash-klash for the subpackages upstream, this name should
  be used here also for consistency with what will appear.
* there is a security issue that should be patched in fedora extras package, 
  indeed there is an insecure use of /tmp. If it is too much work, at least
  there should be a note somewhere.
* the documentation should be distributed (see the specfile in the tarball
  for hints on how to do this), except if there is a good reason not to 
  distribute it? At least manpage and html manual, info files and 
  scrollkeeper files would be bonus 
Comment 2 Patrice Dumas 2006-05-16 22:13:53 EDT
* rpmlint gives those warnings:

W: gnash devel-file-in-non-devel-package /usr/lib/libgnashasobjs.so
W: gnash devel-file-in-non-devel-package /usr/lib/libgnashbackend.so
W: gnash devel-file-in-non-devel-package /usr/lib/libgnashgeo.so
W: gnash devel-file-in-non-devel-package /usr/lib/libgnashserver.so
W: gnash devel-file-in-non-devel-package /usr/lib/libgnashbase.so

Maybe it isn't necessary to have a distinct gnash-devel package, 
but in that case it may be good to 
Provides: %{name}-devel = %{version}-%{release}

There is also this warning that may be problematic, although I don't
know how to solve it:
E: klash binary-or-shlib-defines-rpath /usr/lib/kde3/libklashpart.so
['/usr/lib', '/usr/lib/qt-3.3/lib']

Other rpmlint warnings/errors are not problematic.

* Maybe the gnash package should be in 
Group:          Applications/Multimedia
and not in Applications/Internet (the plugins are rightly in Applications/Internet).

* also you could have a look at the descriptions and summary in the 
spec file in the tarball and pick ideas, although it is up to you,
the one you proposed are good.
Comment 3 Jens Petersen 2006-05-17 09:46:41 EDT
Thanks for the speedy review. :)

Sorry I missed the upstream update again....

(In reply to comment #1)
> * klash is now gnash-klash for the subpackages upstream, this name should
>   be used here also for consistency with what will appear.

Ok.

> * there is a security issue that should be patched in fedora extras package, 
>   indeed there is an insecure use of /tmp. If it is too much work, at least
>   there should be a note somewhere.

Is there a patch from cvs that can be backported for this?

> * the documentation should be distributed (see the specfile in the tarball
>   for hints on how to do this), except if there is a good reason not to 
>   distribute it? At least manpage and html manual, info files and 
>   scrollkeeper files would be bonus 

Sounds good.  I added buildrequires docbook2X for that.

(In reply to comment #2)
> W: gnash devel-file-in-non-devel-package /usr/lib/libgnashasobjs.so
> W: gnash devel-file-in-non-devel-package /usr/lib/libgnashbackend.so
> W: gnash devel-file-in-non-devel-package /usr/lib/libgnashgeo.so
> W: gnash devel-file-in-non-devel-package /usr/lib/libgnashserver.so
> W: gnash devel-file-in-non-devel-package /usr/lib/libgnashbase.so

I removed them for now.

> There is also this warning that may be problematic, although I don't
> know how to solve it:
> E: klash binary-or-shlib-defines-rpath /usr/lib/kde3/libklashpart.so
> ['/usr/lib', '/usr/lib/qt-3.3/lib']

I added --disable-rpath to configure.

> * Maybe the gnash package should be in 
> Group:          Applications/Multimedia
> and not in Applications/Internet (the plugins are rightly in
Applications/Internet).

Thanks, fixed.

I also subpackaged the libraries.

http://people.redhat.com/petersen/extras/gnash.spec
SRPM URL: http://people.redhat.com/petersen/extras/gnash-0.7.1-2.src.rpm
Comment 4 Patrice Dumas 2006-05-17 10:51:24 EDT
(In reply to comment #3)
 
> > * there is a security issue that should be patched in fedora extras package, 
> >   indeed there is an insecure use of /tmp. If it is too much work, at least
> >   there should be a note somewhere.
> 
> Is there a patch from cvs that can be backported for this?

Unfortunately not. I raised the issue on the gnash-dev list, though.
That's the only thing that retained me from proposing gnash to FE ;-)
 
> > * the documentation should be distributed (see the specfile in the tarball
> >   for hints on how to do this), except if there is a good reason not to 
> >   distribute it? At least manpage and html manual, info files and 
> >   scrollkeeper files would be bonus 
> 
> Sounds good.  I added buildrequires docbook2X for that.

This shouldn't be needed, as the files are allready up to date in the
tarball. Doesn't hurt, though.

There is a bug in doc/C/Makefile.am regarding info files installation
during staged install. I'll attach patches.

> > W: gnash devel-file-in-non-devel-package /usr/lib/libgnashbase.so
> 
> I removed them for now.

Agreed, this seems to be the best solution until they are really usefull
to develop something.

> I also subpackaged the libraries.

Really? It doesn't seems so to me... Anyway I think it is better to have
the libraries together with the standalone player. But if you want to
split, you can;
Comment 5 Patrice Dumas 2006-05-17 10:54:56 EDT
Created attachment 129322 [details]
use patch to skip install-info error
Comment 6 Patrice Dumas 2006-05-17 10:56:55 EDT
Created attachment 129323 [details]
don't stop on install-info errors during staged install
Comment 7 Patrice Dumas 2006-05-18 06:40:48 EDT
To build in mock in FC-5, I needed libXmu-devel. I don't know if it
is really needed by gnash, it doesn't seems so to me, I asked upstream.
Comment 8 Jens Petersen 2006-05-18 07:32:30 EDT
(In reply to comment #4)
> > I added buildrequires docbook2X for that.
> 
> This shouldn't be needed, as the files are allready up to date in the
> tarball. Doesn't hurt, though.

Ok, configure tests for it anyway.

> There is a bug in doc/C/Makefile.am regarding info files installation
> during staged install. I'll attach patches.

Oh, I didn't notice any error.

> > I also subpackaged the libraries.

> Anyway I think it is better to have
> the libraries together with the standalone player. But if you want to
> split, you can;

Well the libs are required by each of the other subpackages so I thought
it makes sense to separate them out: assuming many people would only
want one of the plugins.
Comment 9 Patrice Dumas 2006-05-18 08:57:45 EDT
(In reply to comment #8)
> (In reply to comment #4)
> > There is a bug in doc/C/Makefile.am regarding info files installation
> > during staged install. I'll attach patches.
> 
> Oh, I didn't notice any error.

That's strange. Do you have /sbin in your path or are you building 
as root? Not a big deal, it is upstream now.

> Well the libs are required by each of the other subpackages so I thought
> it makes sense to separate them out: assuming many people would only
> want one of the plugins.

Indeed, but having the standalone player together with the plugin
doesn't hurt and may even help, as sometimes the plugin fails but the
standalone player work and the .swf is always downloaded. Once the plugins
stream the flash maybe it could be reconsidered.

Comment 10 Patrice Dumas 2006-05-18 09:28:18 EDT
(In reply to comment #8)
> (In reply to comment #4)
> > > I added buildrequires docbook2X for that.
> > 
> > This shouldn't be needed, as the files are allready up to date in the
> > tarball. Doesn't hurt, though.
> 
> Ok, configure tests for it anyway.

Yes, but when not found there is only a warning by configure, the make 
target still exist but the files are touch'ed instead of being 
regenerated. However since the output files are up to date they are 
left untouched and just copied.
Comment 11 Jens Petersen 2006-06-02 01:43:30 EDT
I added the info install patch, thanks.  (Yes, I have sbin in my path...)

I unsubpackaged the libs for now then.  Since there is no desktop file yet
either it probably doesn't matter too much.  Perhaps when the plugin is
more stable, subpackaging can be revisited as you suggest.

I tried removing the docbook2X buildreq, but then had to remove --enable-docbook
too to stop configure barfing, and then the manpage, info manual and omf file
didn't get installed...

http://people.redhat.com/petersen/extras/gnash.spec
http://people.redhat.com/petersen/extras/gnash-0.7.1-3.src.rpm

This package builds ok for me with mock under fc5.
Comment 12 Giuseppe Castagna 2006-06-19 07:04:46 EDT
Created attachment 131128 [details]
Standard error of rpmbuild
Comment 13 Giuseppe Castagna 2006-06-19 07:07:48 EDT
It does not compile on my x86_64.

Here you are my configuration

Linux lampone 2.6.16-1.2129_FC5 #1 SMP Thu Jun 1 10:59:33 EDT 2006 x86_64 x86_64
x86_64 GNU/Linux

libjpeg-devel-6b-36.2.1
libogg-devel-1.1.3-1.2
libxml2-devel-2.6.23-1.2
SDL_mixer-devel-1.2.6-7.fc5
kdelibs-devel-3.5.3-0.2.fc5
gtkglext-devel-1.2.0-2.fc5
docbook2X-0.8.7-1.fc5
scrollkeeper-0.3.14-5.2.1

The errors when I try to execute

   rpmbuild --rebuild gnash-0.7.1-3.src.rpm 

are attached in the previous post

P.S. Is is possible to exclude compilation of knash?
Comment 14 Giuseppe Castagna 2006-06-19 08:00:59 EDT
BTW, if I modify the spec file by replacing --disable-klash for --enable-klash
and removing all the rest of the stuff about klash then it compiles
Comment 15 Patrice Dumas 2006-06-19 11:04:50 EDT
(In reply to comment #13)
> It does not compile on my x86_64.

It seems like the qt headers or libs aren't found by ./configure.
Do you have qt-devel installed? It should be required by 
kdelibs-devel which is installed.

Could you also please post the config.log file which is in 
the rpm build directory.
Comment 16 Rex Dieter 2006-06-19 11:11:53 EDT
The build.log reference in comment #12 contains:
...
 
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -I../.. -I../../server -I../../libbase -I../../backend -I../../libgeometry -I/usr/include -I/usr/include/SDL -I/usr/include/SDL -I/usr/include/libxml2 -I/usr/include/kde/kio -I/usr/include/kde -I. -DQT_THREAD_SUPPORT -D_REENTRANT -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -c 
klash_part.cpp  -fPIC -DPIC -o .libs/klash_part.o
klash_part.cpp:45:22: error: qcstring.h: No such file or directory
klash_part.cpp:46:24: error: qpopupmenu.h: No such file or directory
klash_part.cpp:47:20: error: qtimer.h: No such file or directory
In file included from klash_part.cpp:50:
/usr/include/kde/klibloader.h:21:21: error: qobject.h: No such file or 
directory
/usr/include/kde/klibloader.h:22:21: error: qstring.h: No such file or 
directory
/usr/include/kde/klibloader.h:23:25: error: qstringlist.h: No such file or 
directory
/usr/include/kde/klibloader.h:24:24: error: qasciidict.h: No such file or 
directory
/usr/include/kde/klibloader.h:25:22: error: qptrlist.h: No such file or 
directory

So, clearly qt's headers aren't being found.  The compiler step *should* 
include
-I${QTINC}
where the QTINC environment variable expands to %_libdir/qt-3.3/include
Comment 17 Giuseppe Castagna 2006-06-19 11:29:58 EDT
> It seems like the qt headers or libs aren't found by ./configure.
> Do you have qt-devel installed? It should be required by 
> kdelibs-devel which is installed.

Yes I do:

qt-devel-3.3.6-0.1.fc5

> Could you also please post the config.log file which is in 
> the rpm build directory.

Uhuuu, that really looks crazy. In order to generate the confi.log I just
executed again rpmbuild --rebuild gnash-0.7.1-3.src.rpm . Guess what? Now it
compiles. WHich is completely absurd since I did nothing in the meanwhile. Not
even rebooted the machine.
 The only thing I did between the two compilations, is to modify the spec
compile clash and install the obtained rpms. But I carefully cleaned up
/usr/src/redhat before recompiling.

Well, now I have my
/usr/src/redhat/RPMS/x86_64/gnash-klash-0.7.1-3.x86_64.rpm
Wonderful, after 21 years as a computer scientist these boxes can still surprise
me :-) Fortunately my attachment proves that I'm not completely crazy (yet)


Well, so long ... 




Comment 18 Rex Dieter 2006-06-19 11:38:13 EDT
Giuseppe, you may have just lucked into the fact that the latest,
recently-released qt-3.3.6-0.1 contains the fix for this particular problem,
reported as bug #169132
Comment 19 Michael J Knox 2006-07-28 01:44:37 EDT
This fails to build in mock. 

You need to add: 

BuildRequires: autoconf, automake, libtool

Comment 20 Jens Petersen 2006-07-28 05:04:56 EDT
Thanks.  Should be fixed in:

http://people.redhat.com/petersen/extras/gnash.spec
http://people.redhat.com/petersen/extras/gnash-0.7.1-4.src.rpm

I think the only remaining issue is Patrice's concerns about
a potential tmp file vulnerability in the mozilla plugin
(it just downloads .swf files straight to /tmp), though that is really
an upstream issue.  I'm not sure how the current behaviour compares
with other plugins but probably a reasonable soltion is to use mkdtemp in /tmp.
Comment 21 Jens Petersen 2006-07-28 05:14:39 EDT
Created attachment 133223 [details]
plugin-tempfile-dir.patch

untested patch to use mkdtemp
Comment 22 Jens Petersen 2006-07-28 09:15:26 EDT
Created attachment 133235 [details]
plugin-tempfile-dir.patch

better patch still untested
Comment 23 Patrice Dumas 2006-07-28 16:55:09 EDT
I'll test the patch but it would benefit from a bit
of error code testing ;-)
Comment 24 Patrice Dumas 2006-07-28 17:59:53 EDT
It segfaults with this patch. My wild guesses:

the template is constant, although, quoting the manpage:
"Since it will  be 
modified,  template  must  not  be  a  string  constant,  but should be
declared as a character array."

The other possibility I see is that something is needed to 
convert the resulting char* to string.
Comment 25 Dominik 'Rathann' Mierzejewski 2006-07-28 18:24:09 EDT
Same problem with QT on my amd64 box, too. Sourcing /etc/profile.d/qt.sh and
adding --with-qtdir=$QTDIR to %configure helps.
Comment 26 Dominik 'Rathann' Mierzejewski 2006-08-01 19:19:54 EDT
Another problem: it crashes the whole GNOME (i.e panel and terminal) on my FC5
AMD64 box when you enter the following URL (so don't click it blindly!):

B I G   F A T   W A R N I N G
THIS WILL KILL YOUR GNOME SESSION
DON'T SAY YOU WEREN'T WARNED!

http://www.cafepress.com/cp/search/search.aspx?cfpt=118%3A________________H&q=B5&x=0&y=0&cfpt2=&copt=&source=searchBox
Comment 27 Patrice Dumas 2006-08-02 04:39:13 EDT
(In reply to comment #26)
> Another problem: it crashes the whole GNOME (i.e panel and terminal) on my FC5
> AMD64 box when you enter the following URL (so don't click it blindly!):

That doesn't look like a gnash bug, but a GNOME (or maybe Xorg/Mesa) 
bug triggered by gnash. gnash embedded in firefox shouldn't be able 
to crash anything else than firefox. I also had many bugs revealed 
by gnash on FC5. Things are smoother on devel (but with other issues, 
like Xorg not starting with latest update of the driver, it's rawhide 
after all ;-)
Comment 28 Demond James 2006-08-08 11:53:38 EDT
The klash plugin fail to build on x86_64 arch using uptodate rawhide.  Are there
additional build-requirements?
Comment 29 Jens Petersen 2006-08-16 06:21:41 EDT
Thanks, problems in comment 24 and comment  25  (comment 28)
should be fixed in:

http://people.redhat.com/petersen/extras/gnash.spec
http://people.redhat.com/petersen/extras/gnash-0.7.1-5.src.rpm

I reproduced comment 26: this no longer seems to happen with gnash cvs head fwiw.
Comment 30 Dominik 'Rathann' Mierzejewski 2006-08-16 14:04:40 EDT
Great! I'm really looking forward to having this in extras.
Comment 31 Demond James 2006-08-19 07:30:22 EDT
Browsing to sites with flash 9 causes my X session/server to restart on my
x86_64 running rawhide.  I'm not sure if it's because of flash 9 but it happens
on sites like gap.com & myspace.
Comment 32 Jens Petersen 2006-08-19 22:25:48 EDT
(In reply to comment #31)
> Browsing to sites with flash 9 causes my X session/server to restart on my
> x86_64 running rawhide.

This sounds like the problem in comment 26, but I agree this blocks acceptance.
As I noted in comment 29 it seems to be fixed in cvs.
Comment 33 Patrice Dumas 2006-08-20 06:05:50 EDT
(In reply to comment #32)
> (In reply to comment #31)
> > Browsing to sites with flash 9 causes my X session/server to restart on my
> > x86_64 running rawhide.
> 
> This sounds like the problem in comment 26, but I agree this blocks acceptance.
> As I noted in comment 29 it seems to be fixed in cvs.

Once again it is not a gnash bug, but certainly an xorg/mesa bug
triggered by gnash.

Comment 34 Patrice Dumas 2006-08-20 08:52:45 EDT
The patch works for me. It fills /tmp with temporary dirs, but
it is better than what was before. It should be documented, however.
So I propose to add a 
README.fedora in the gnash-plugin documentation. I attach a spec 
diff and a gnash-README.fedora.

I also think that it would be better to prefix plugin-tempfile-dir.patch
with gnash, such that it is called gnash-plugin-tempfile-dir.patch 
instead.
Comment 35 Patrice Dumas 2006-08-20 08:55:38 EDT
Created attachment 134526 [details]
explanation of the /tmp/gnash-XXXXXX files
Comment 36 Patrice Dumas 2006-08-20 08:57:36 EDT
Created attachment 134527 [details]
spec file diff to install the README for the plugin
Comment 37 Patrice Dumas 2006-08-20 09:05:34 EDT
Another remark, autoconf is required by automake.
Comment 38 Jens Petersen 2006-08-20 21:48:06 EDT
(In reply to comment #33)
> Once again it is not a gnash bug, but certainly an xorg/mesa bug
> triggered by gnash.

Nod, but until that is fixed it doesn't make sense really to include gnash in
Extras.  I suggest a bug be opened for that issue and that it block this bug. 

(In reply to comment #34)
> The patch works for me. It fills /tmp with temporary dirs, but
> it is better than what was before. It should be documented, however.
> So I propose to add a 
> README.fedora in the gnash-plugin documentation. I attach a spec 
> diff and a gnash-README.fedora.

Ok.

> I also think that it would be better to prefix plugin-tempfile-dir.patch
> with gnash, such that it is called gnash-plugin-tempfile-dir.patch 
> instead.

Why? :)

(In reply to comment #37)
> Another remark, autoconf is required by automake.

So you mean it shouldn't be in BR?  It can be removed I suppose
though it makes the dependency on autoreconf less obvious...
Perhaps autoconf should require automake too?
Comment 39 Patrice Dumas 2006-08-21 02:49:33 EDT
(In reply to comment #38)

> Nod, but until that is fixed it doesn't make sense really to include gnash in
> Extras.  I suggest a bug be opened for that issue and that it block this bug. 

This bug will likely be driver dependent...


> > I also think that it would be better to prefix plugin-tempfile-dir.patch
> > with gnash, such that it is called gnash-plugin-tempfile-dir.patch 
> > instead.
> 
> Why? :)

Because it helps knowing that it is a source file associated with
the gnash rpm. Especially handy when you have a lot of patches and
source in SOURCES. But it is not a blocker, just a remark.
 
> (In reply to comment #37)
> > Another remark, autoconf is required by automake.
> 
> So you mean it shouldn't be in BR?  It can be removed I suppose
> though it makes the dependency on autoreconf less obvious...
> Perhaps autoconf should require automake too?

autoconf shouldn't require automake, since it doesn't require automake.
In our case builrequires for autoconf is not that bad, it is just an 
unneeded buildrequires, and the practice (and I think it is somewhere 
in the guidelines) is to avoid buildrequires when there are allready 
implied by another package. Not a blocker (other reviewers would consider
that a blocker, I think)
Comment 40 Jens Petersen 2006-08-21 10:29:26 EDT
(In reply to comment #39)
> > I suggest a bug be opened for that issue and that it block this bug. 
> 
> This bug will likely be driver dependent...

Quite possible.  Perhaps better would be to update the gnash source to cvs head?

> Because it helps knowing that it is a source file associated with
> the gnash rpm. Especially handy when you have a lot of patches and
> source in SOURCES.

Ok, you're right of course.  It is so long that I've used the default
directories for rpmbuilding, that I had quite forgotten about this
namespace issue.  (Personally I think it is much saner to build packages from
separate directories...)

> autoconf shouldn't require automake, since it doesn't require automake.

(but autoreconf does)

> In our case builrequires for autoconf is not that bad, it is just an 
> unneeded buildrequires, and the practice (and I think it is somewhere 
> in the guidelines) is to avoid buildrequires when there are allready 
> implied by another package. Not a blocker (other reviewers would consider
> that a blocker, I think)

I'll remove it anyway.

Updated package:
http://people.redhat.com/petersen/extras/gnash.spec
http://people.redhat.com/petersen/extras/gnash-0.7.1-5.src.rpm

For the record I don't really like the "flooding" of tmpdirs behaviour very
much, but it seems like the simplest secure implementation possible.  I guess
X uses something similar for its /tmp/xses-$USER.XXXXXX session log files.
A better implementation would probably save the .swf files in a directory like
"/tmp/gnash-$USER/" owned by USER having permission 0700.
It should also take account of TMPDIR I suppose.  But I'm lazy... ;)
Comment 41 Patrice Dumas 2006-08-25 06:26:05 EDT
(In reply to comment #40)

> Quite possible.  Perhaps better would be to update the gnash source to cvs head?

That would be bad idea, since the cvs head is moving very fast. In
my case what fixed the X crash issues was not a change in gnash, but 
switching to the rawhide Mesa/xorg (but not to the latest drv-i810...)


> Updated package:
> http://people.redhat.com/petersen/extras/gnash.spec
> http://people.redhat.com/petersen/extras/gnash-0.7.1-5.src.rpm
> 
> For the record I don't really like the "flooding" of tmpdirs behaviour very
> much, but it seems like the simplest secure implementation possible.  I guess
> X uses something similar for its /tmp/xses-$USER.XXXXXX session log files.
> A better implementation would probably save the .swf files in a directory like
> "/tmp/gnash-$USER/" owned by USER having permission 0700.
> It should also take account of TMPDIR I suppose.  But I'm lazy... ;)

It also seems the best compromise to me. It won't be a problem in next
release anyway, with streaming, and personal directory.

All the issues have been solved, so I am ready to approve. One
last thing I would like is that somewhere it is marked that gnash is
usable, but also that it won't work for many flash sites and that
it is known to crash often and even trigger bugs that crash the
graphical system (or something along those lines), either in the 
README.fedora or, maybe better, in the description.
Comment 42 Patrice Dumas 2006-08-25 07:00:13 EDT
There is a missing

%defattr(-,root,root,-)

for klash
Comment 43 Jens Petersen 2006-08-25 08:14:08 EDT
Patrice, good points: would you like to take ownership of this package? :-)
Comment 44 Patrice Dumas 2006-08-25 08:46:32 EDT
Created attachment 134912 [details]
spec file patch to add a warning in description and fix deffatr for klash
Comment 45 Patrice Dumas 2006-08-25 08:47:25 EDT
Sure, but it will be simpler if I take ownership after it
is imported in cvs by you. I attach a patch for the spec file,
with that patch applied it is approved, you can then import it
in cvs, but add me in the owner.list as primary owner, and
put yourself in the initial cc list. Does it sounds good?
Comment 46 Patrice Dumas 2006-08-25 08:50:43 EDT
Another thing, I don't think there shouldn't be a branch for 
FC-5, given that gnash seems to trigger a mesa bug a bit too often,
which seems to be fixed in FC-6. 

Does that sound good?
Comment 47 Jens Petersen 2006-08-25 16:26:15 EDT
Yup, sounds good to me.  I will import it over the weekend.
Comment 48 Jens Petersen 2006-08-27 04:39:20 EDT
I imported gnash-0.7.1-7 into cvs.
Comment 49 Jens Petersen 2006-08-27 04:48:53 EDT
and added entry in owners.list too.

I think this can be moved to FE-ACCEPT now, thanks.

Patrice, please feel free to go ahead and build this.
Comment 50 Jens Petersen 2006-08-27 04:53:14 EDT
(In reply to comment #46)
> Another thing, I don't think there shouldn't be a branch for 
> FC-5, given that gnash seems to trigger a mesa bug a bit too often

Perhaps an FC-5 branch can be made if and when such a bug is resolved for fc5.
Comment 51 Patrice Dumas 2006-08-27 07:45:19 EDT
I don't have FC5 to test on. I'll try to have a look from time
to time, to see if mesa is updated to mesa-libGL-6.5.* and 
otherwise wait for user asking a branch.

This is built now in devel, Jens you can close the bug.

Note You need to log in before you can comment on or make changes to this bug.