Bug 236521 - (nspluginwrapper) Review Request: nspluginwrapper - A compatibility layer for Mozilla/Firefox plugins
Review Request: nspluginwrapper - A compatibility layer for Mozilla/Firefox p...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Package Reviews List
:
: 198786 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-15 20:57 EDT by Deji Akingunola
Modified: 2013-04-30 19:35 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-23 06:17:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
atkac: fedora‑review+
wtogami: fedora‑cvs+


Attachments (Terms of Use)
nspluginwrapper.spec patch (2.78 KB, patch)
2007-05-31 09:40 EDT, Jakub Jelinek
no flags Details | Diff

  None (edit)
Description Deji Akingunola 2007-04-15 20:57:23 EDT
Spec URL: ftp://czar.eas.yorku.ca/pub/nspluginwrapper/nspluginwrapper.spec
SRPM URL: ftp://czar.eas.yorku.ca/pub/nspluginwrapper/nspluginwrapper-0.9.91.4-1.fc7.src.rpm
Description: 
nspluginwrapper makes it possible to use Mozilla/Firefox compatible plugins
compiled for %{target_arch} into Mozilla for another architecture,
e.g. x86_64

NB: If approved, this package will need a special handling to copy the 32-bit builds into the respective arch's 64-bit tree, for it to function properly.
Comment 1 Chris Weyl 2007-04-25 20:19:37 EDT
Ok, stupid question time :)  I see configure supports a "--with-biarch" option,
to compile for both arches at the same time (e.g. i386 and x86_64).  Wouldn't
enabling that obviate the need to copy builds around, or other multi-arch fun?

Second stupid question:  if we can use --with-biarch, do we even need to build
this package for, say, i386?
Comment 2 Deji Akingunola 2007-04-25 20:48:31 EDT
The two questions are same IMO, and they are not stupid ;). The answer is simply
because there's no way to require arch-specific package in rpm (that I know of).
That is, you can require say gtk2-devel.x86_64 and gtk2-devel.i386 at the same
time for an x86_64 build. However if you have these dependencies installed
locally, you can easily build using --with-biarch to produce both the main
nspluginwrapper package and the  nspluginwrapper-i386 subpackage (i do that for
my personal builds).
Comment 3 Remi Collet 2007-04-26 00:25:50 EDT
Building with --biarch is possible and i also do that.

Dependencies should be put on file (/usr/lib/libX11.so and /usr/lib64/livX11.so
p.e.) (see http://remi.collet.free.fr/rpms/SPEC/nspluginwrapper-0.9.91.4.spec)

But this can't be build on mock where yum config exclude i386 RPM.
Comment 4 Bryan O'Sullivan 2007-05-01 23:54:29 EDT
Hi, Deji -

Please respond to Remi's comment #3 before I start a complete review.  Not
building with mock is OK, but avoiding --with-biarch is a problem.  It would be
much easier to have a biarch build that worked on x86_64 and ppc64 without
needing to copy the 32-bit packages around.
Comment 5 Remi Collet 2007-05-02 00:23:12 EDT
Sorry but my comment wasn't a question....

Building with mock, is, AFAIK, mandatory for the Extras build system.
So the Deji's solution is problably a good one.

Regards
Comment 6 Bryan O'Sullivan 2007-05-02 02:12:19 EDT
No, building with mock is not mandatory.  It would be nice, but it's not a
showstopper.  Having to combine packages built on separate architectures is more
of a problem.
Comment 7 Deji Akingunola 2007-05-02 08:36:09 EDT
Hello Bryan,

Repeating what Remi has already confirm to you, building with mock IS MANDATORY
for packages that will officially be in Fedora repos, because the build system
depends on it. The problem you alluded to above doesn't exist. However if you
own a x86_64 system and you want to build the complete package for yourself, do
the following;
i. Build the main package normally, i.e. rpmbuild --rebuild
nspluginwrapper-0.9.91.4-1.fc7.src.rpm
ii. mv /etc/rpm/platform{,.save}
iii. 'setarch i386 pmbuild --rebuild nspluginwrapper-0.9.91.4-1.fc7.src.rpm' to
build the i386 subpackage.
Comment 8 Warren Togami 2007-05-05 20:49:14 EDT
How about splitting this into two source RPM packages?
nspluginwrapper-i386.src.rpm
nspluginwrapper-x86_64.src.rpm
Comment 9 Deji Akingunola 2007-05-05 22:35:42 EDT
(In reply to comment #8)
> How about splitting this into two source RPM packages?
> nspluginwrapper-i386.src.rpm
> nspluginwrapper-x86_64.src.rpm

Hmm, seems a good idea but it's not really better than the present scenario,
IMHO. The nspluginwrapper-i386.src.rpm so called will still have to be built in
the 32-bit tree and the binary some-how copied over to the 64-bit tree.
Comment 10 Jakub Jelinek 2007-05-31 09:40:40 EDT
Created attachment 155815 [details]
nspluginwrapper.spec patch

I think the basic idea of building the package with --without-biarch is sound.
But I have a few comments:
1) %ifarch ppc64 || x86_64
is wrong syntax, %ifarch takes a list of arches, so %ifarch ppc64 x86_64.
Still better to create a rpm macro so that it can be easily changed.
2) by default nspluginwrapper strips the files, so nspluginwrapper-debuginfo is
(almost) empty
3) x86_64 or ppc64 mozilla plugins go into /usr/lib64/mozilla/plugins/
rather than /usr/lib/mozilla/plugins/
4) on ppc I'm not sure it is a good idea to only ship the variant where
64-bit nspluginwrapper runs 32-bit nspluginviewer, if you have 32-bit firefox
(does ppc64 firefox already work, it has been certainly always broken in FC6),
then you might on the other side be interested in running 64-bit ppc plugins
in 32-bit firefox
5) the symlink the spec file created was broken
6) after this package hits fedora, it might make sense to clean up some of the
scripts and programs, either the scripts are overly portable (testing for
non-linux OSes all the time), distro specific (mkruntime script) or handle
many Linux distros (see get_system_mozilla_plugin_dir) but not Fedora resp.
RHEL - that means unneeded stats of /etc/SUSE-release etc. and likely wrong
paths
in the end anyway.
Comment 11 Warren Togami 2007-05-31 12:16:00 EDT
Yo Caillon, these suggestions might be useful for your package.
Comment 12 Christopher Aillon 2007-05-31 13:15:23 EDT
We've independently been working on this package.  My requirements have been:

- Each arch builds separately (no need to do 32 bit builds on 64 bit)
- If you want to run 32 bit plugins, you install the 32 bit version.
- If you want to run 64 bit plugins, you install the 64 bit version.

It is currently in a working state, but needs some cleaning up still before it's
pushed out.  I expect to push out an srpm and spec next week.
Comment 13 Deji Akingunola 2007-05-31 13:23:56 EDT
Thanks a lot Jakub. Before I post a new srpm with your modifications, i have a
couple of questions.
Firstly, is there any particular reason you remove %{_bindir}/nspluginwrapper
from the file list? Most documentations on how to use the wrapper refers to it.
Secondly, the symlink in the spec file you referred to doesn't seem broken,
rpmlint was quiet about it. But rpmlint returned an error for the symlink with
your change;
>>
[deji@agape ~]$ rpmlint rpmbuild/SRPMS/nspluginwrapper-0.9.91.4-2.fc7.src.rpm
E: nspluginwrapper hardcoded-library-path in
../../lib/%{name}/%{_arch}/%{_os}/npwrapper.so
<<
Comment 14 Christopher Aillon 2007-05-31 13:33:46 EDT
> ../../lib/%{name}/%{_arch}/%{_os}/npwrapper.so

Also, the above path stuff is broken.  We can do better here than hard coding
arch info in paths.  I've got fixes for that.
Comment 15 Jakub Jelinek 2007-06-07 08:21:59 EDT
Sorry for late reply, forgot to add me into CC.
The reason to remove %{_bindir}/nspluginwrapper was that that would clash.
Say on ppc if you want 64-bit nspluginwrapper with ppc target_arch
and 32-bit nspluginwrapper with ppc64 target_arch at the same time, what
would %{_bindir}/nspluginwrapper point to?
Ideally the configuration program would be changed, so that it finds out
what nspluginwrapper host versions are available, what their target arch is
and depending on the architecture of the target plugin you want to install into
nspluginwrapper it would register it for all hosts that have those target_arch
configured.  So, if you have ppc -> ppc64 and ppc64 -> ppc nspluginwrapper,
running the proglet to install 32-bit plugin would register it in the 64-bit
nspluginwrapper and vice versa.

Regarding npwrapper.so symlink, perhaps rpmlint was quite on your package,
that doesn't mean it was correct.
ln -s npwrapper.so %{buildroot}%{nslibdir}/mozilla/plugins/npwrapper.so
creates a symlink pointing to itself (i.e. a symlink loop).
Comment 16 Jakub Jelinek 2007-06-07 08:23:24 EDT
s/quite/quiet/
Comment 17 Martin Stransky 2007-06-08 05:59:57 EDT
There's an updated nspluginwrapper package:

http://people.redhat.com/stransky/nsplugin/
http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-1.fc7.src.rpm
http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec

it should met:

- fedora packaging guidelines
- multi-arch requests (32&64 bit packages can be installed simultaneously)
- cailon's requests

It supports i386/x86_64 arches only.
Comment 18 Martin Stransky 2007-06-08 06:04:23 EDT
btw. plug-ins are installed by /usr/bin/nspluginsetup
Comment 19 Sander Hoentjen 2007-06-08 06:13:33 EDT
(In reply to comment #17)
> There's an updated nspluginwrapper package:
> 
> http://people.redhat.com/stransky/nsplugin/
> http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-1.fc7.src.rpm
> http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec
> 
> it should met:
> 
> - fedora packaging guidelines
> - multi-arch requests (32&64 bit packages can be installed simultaneously)
> - cailon's requests
> 
> It supports i386/x86_64 arches only.

missing BR gtk2-devel
Comment 20 Martin Stransky 2007-06-08 07:06:28 EDT
Added to BuildRequires, thanks!

Updated package is here:

http://people.redhat.com/stransky/nsplugin/
http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-2.fc7.src.rpm
http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec

An output from rpmlint:

----------------------------------------------------------
W: nspluginwrapper non-standard-group Networking/WWW
E: nspluginwrapper hardcoded-library-path in /usr/lib
E: nspluginwrapper configure-without-libdir-spec
W: nspluginwrapper mixed-use-of-spaces-and-tabs (spaces: line 75, tab: line 1)
----------------------------------------------------------

E: nspluginwrapper hardcoded-library-path in /usr/lib

- it has to be here because this package has to do cross-platform detection

E: nspluginwrapper configure-without-libdir-spec

- it's a bogus error because it's used non-standart configure script
Comment 21 Martin Stransky 2007-06-08 08:14:09 EDT
there's how-to test:

1) install 32-bit flash plug-in (to /usr/lib/mozilla/plugins)
2) install nspluginwrapper package

or (if you have nspluginwrapper package already installed)

1) install 32-bit flash plug-in (to /usr/lib/mozilla/plugins)
2) run /usr/bin/nspluginsetup -u

note: it only wraps libflashplayer.so file because only this one works fine now
(or at least for me). We'll add more plug-ins if they work fine.

Comment 22 Sander Hoentjen 2007-06-08 08:50:56 EDT
I tried to test but it fails for me:
ll /usr/lib/mozilla/plugins
total 4
lrwxrwxrwx 1 root root 39 2007-06-08 12:20 libflashplayer.so ->
/usr/lib/flash-plugin/libflashplayer.so
(installed through the yum repo)
after i run /usr/bin/nspluginsetup -u, what should happen, should i see a file
appear somewhere?
should i run /usr/bin/nspluginsetup -u as root or as user (i tried both)
Comment 23 Martin Stransky 2007-06-08 08:58:34 EDT
if you want to run 32-bit plugin in 64-bit browser, you need both 32bit and
64bit nspluginwrapper packages installed.

after "nspluginsetup -u" you should have:

/usr/lib/mozilla/plugins/npwrapper.libflashplayer.so
/usr/lib/mozilla/plugins-backup/libflashplayer.so

/usr/lib64/mozilla/plugins/npwrapper.libflashplayer.so

so npwrapper.libflashplayer.so is a plug-in wrapper what runs
/usr/lib/mozilla/plugins-backup/libflashplayer.so.
Comment 24 Martin Stransky 2007-06-08 09:00:37 EDT
btw. you have to be root and be able to write to /usr/lib(64)/mozilla/plugins
and plugins-backup
Comment 25 Deji Akingunola 2007-06-08 10:50:43 EDT
(In reply to comment #15)
Hi Jakub,

> 
> Regarding npwrapper.so symlink, perhaps rpmlint was quite on your package,
> that doesn't mean it was correct.
> ln -s npwrapper.so %{buildroot}%{nslibdir}/mozilla/plugins/npwrapper.so
> creates a symlink pointing to itself (i.e. a symlink loop).
I just checked again, and it doesn't point to itself, here is what I have on a
newly installed system,
>>
[deji@agape Desktop]$ ll /usr/lib64/mozilla/plugins/npwrapper.so
lrwxrwxrwx 1 root root 54 2007-06-08 10:40
/usr/lib64/mozilla/plugins/npwrapper.so ->
../../../lib/nspluginwrapper/x86_64/linux/npwrapper.so
>>
If you look at original spec file again, you'll see it,
cd %{buildroot}%{nslibdir}/%{name}/%{_arch}/%{_os}
and then,
ln -s npwrapper.so %{buildroot}%{nslibdir}/mozilla/plugins/npwrapper.so

Comment 26 Deji Akingunola 2007-06-08 11:05:19 EDT
(In reply to comment #17)
> There's an updated nspluginwrapper package:
> 
> http://people.redhat.com/stransky/nsplugin/
> http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-1.fc7.src.rpm
> http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec
> 
I don't really understand this, putting up a parallel package in the same review
process, it's confusing to me and potentially to reviewers too. I would have
expected that discuss your change with me and present a patch to what is already
on ground (see Comment #10). However if you want a complete take-over (I'm not
very opposed to that either), you should have close this ticket, and open a new one.
BTW, is this what Christopher Aillon was referring to in Comment #12? If it
were, it would also have been best we agree to substitute the original review
request with it, rather than simultaneously creating another implemetation.
Comment 27 Martin Stransky 2007-06-08 11:17:01 EDT
I see. I didn't realize that so I'm sorry.

And yes, this is a package from Comment #12. I think if the new package meets
all requests and works fine we can replace this request by it.
Comment 28 Christopher Aillon 2007-06-08 11:50:43 EDT
(In reply to comment #26)
> BTW, is this what Christopher Aillon was referring to in Comment #12? If it
> were, it would also have been best we agree to substitute the original review
> request with it, rather than simultaneously creating another implemetation.

Yes, it was.  I'm not trying to hijack the bug and apologies if it came off that
way.  We were working on this in parallel.  I own the browser stack and I was
unaware that anybody else was doing this (someone should have notified me
earlier) until Warren cc'd me after we'd gotten this to the point it was
basically done.

I meant to convey that the approach in this package review was broken and I
would deny review based on that.  The package we uploaded fixes those major
issues.  I don't see why we need a new review for that.  Again, sorry for any
confusion.
Comment 29 Jakub Jelinek 2007-06-08 12:09:53 EDT
Re: comment #25
ln -s npwrapper.so %{buildroot}%{nslibdir}/mozilla/plugins/npwrapper.so
command, no matter in which cwd you run it, will be always a circular symlink.
Perhaps something changes this symlink during %post or you have changed
it yourself, but I don't believe npwrapper.so in your binary rpms is anything
but circular symlink.  Try rpm -qplv nspluginwrapper*.rpm | grep npwrapper.so

Re: comment #23
does your nspluginwrapper really change the /usr/lib/mozilla/plugin/ directory?
What's the reason for that?  In 32-bit firefox there is no reason for wrapping
a 32-bit plugin (the shell script actually says it should be used directly
when target is the same as host) and if say
/usr/lib/mozilla/plugin/libflashplayer.so is owned by some other rpm, e.g.
rpm -V of that package will fail miserably if nspluginwrapper changes it.
Also, limiting nspluginwrapper to flash is IMHO a bad idea, there are many other
plugins.  And ExclusiveArch: i386 x86_64 is a bad idea as well, this is needed
also on ppc{,64}, sparc{,64}, ia64, s390x, ...
Comment 30 Christopher Aillon 2007-06-08 12:22:23 EDT
(In reply to comment #29)
> Re: comment #23
> In 32-bit firefox there is no reason for wrapping
> a 32-bit plugin (the shell script actually says it should be used directly
> when target is the same as host) 

Actually, I disagree.  If a plugin crashes currently, it takes down the entire
browser.  The idea is to run all plugins out of process so this is no longer the
case.  Also, with out of process plugins, we can more actively employ SELinux
for security purposes here for example.
Comment 31 Jakub Jelinek 2007-06-08 14:50:21 EDT
npviewer has:
# Don't wrap host plugins
case " $@ " in
*" --test "*|*" -t "*)
    if test "$TARGET_OS" = "$OS" -a "$TARGET_ARCH" = "$ARCH"; then
        exit 20 # EXIT_VIEWER_NATIVE
    fi
    ;;
esac

In any case, if all plugins are supposed to be wrapped, then firefox etc. should
Requires: nspluginwrapper, the above script needs to be changed and I'd say that 
firefox etc. should just use a different directory than
/usr/lib*/mozilla/plugins/ - that would be for plugins that need wrapping and
the wrapped links would go elsewhere.
Comment 32 Christopher Aillon 2007-06-08 15:10:21 EDT
Yeah, once this lands, firefox will require it.  The plugin wrapper itself
should be installed to $lib/mozilla/plugins and the install should move things
to e.g. $lib/nspluginwrapper/plugins.  Plugin RPMs should also require
nspluginwrapper and call the appropriate install/uninstall scripts.  But those
should be handled out of process from this review.

I'll let Martin handle the rest of the technical comments.
Comment 33 Christopher Aillon 2007-06-08 15:16:19 EDT
(In reply to comment #29)
> plugins.  And ExclusiveArch: i386 x86_64 is a bad idea as well, this is needed
> also on ppc{,64}, sparc{,64}, ia64, s390x, ...

By the way, the upstream code does not really work with anything other than
i386/x86_64 AFAIK.  Unless that's changed recently.  We would probably need help
from various arch teams porting the code.  The ppc port requires qemu, and I
really don't want firefox to (implicitly) require qemu.
Comment 34 Martin Stransky 2007-06-09 02:03:58 EDT
(In reply to comment #29)
> Re: comment #23
> Also, limiting nspluginwrapper to flash is IMHO a bad idea, there are many other
> plugins.

I don't think so. Have you tried any other plug-ins? They just didn't work in
the wrapped environment. It can be a bug in packaging or something else, but
only flash works fine under nspluginwrapper now (at least for me).

But it's really easy to add any other plug-in to wrap, there's a list of wrapped
plug-ins in a spec file. 

Comment 35 Sander Hoentjen 2007-06-11 09:37:49 EDT
(In reply to comment #20)
> Added to BuildRequires, thanks!

Not sure if this is the package currently under review, but it is missing
pkgconfig BuildRequire
Comment 36 Martin Stransky 2007-06-11 09:41:53 EDT
it's already fixed, see
http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec
Comment 37 Warren Togami 2007-06-11 10:07:15 EDT
nspluginwrapper-0.9.91.4-2.fc7

[root@newcaprica ~]# nspluginsetup -i
nspluginwrapper: no appropriate viewer found for
/usr/lib/mozilla/plugins-backup/libflashplayer.so
nspluginwrapper: no appropriate viewer found for
/usr/lib/mozilla/plugins-backup/libflashplayer.so

[root@newcaprica plugins-backup]# pwd
/usr/lib/mozilla/plugins-backup
[root@newcaprica plugins-backup]# ls
libflashplayer.so

[root@newcaprica plugins]# pwd
/usr/lib/mozilla/plugins
[root@newcaprica plugins]# ls
libjavaplugin_oji.so  nphelix.so  nphelix.xpt  npwrapper.so  nsdejavu.so

nspluginsetup is failing to do its thing for me.  Any ideas?
Comment 38 Bryan O'Sullivan 2007-06-11 10:42:16 EDT
So what's the plan?  Do we keep this bug open, or file a new one?
Comment 39 Martin Stransky 2007-06-11 10:53:31 EDT
(In reply to comment #37)
> nspluginsetup is failing to do its thing for me.  Any ideas?

checking. What browsers do you have installed? Do you want to wrap flash only
for i386 browser (not for x86_64)?
Comment 40 Martin Stransky 2007-06-11 11:13:16 EDT
I've just checked it again (on FC-6/i386) and works fine, libflashplayer.so is
wrapped as expected. Is there any error message in log? Did you disable SE
linux? What says "about:plugins" page in your browser?
Comment 41 Martin Stransky 2007-06-11 11:19:35 EDT
(In reply to comment #38)
> So what's the plan?  Do we keep this bug open, or file a new one?

I prefer to keep this one.
Comment 42 Deji Akingunola 2007-06-11 11:32:09 EDT
Frankly I don't see how the originally proposed package 'was broken' (referring
to comment #28), it just worked, at least as upstream designed it. This new
package on the other hand seems to have regressed, tying its use to only flash
plugin and wrapping native plugins expressly against upstream design. This
program cannot rely on plugin RPMs calling appropriate install scripts as most
of the plugins it is useful for are non-OSS, and thus their packaging can't be
directly controlled by Fedora.
Comment 43 Christopher Aillon 2007-06-11 13:08:42 EDT
Quite honestly, upstream's build system design is broken.  It meets a specific
feature goal but does so outside of the constraints of rpm: shipping/building
32bit stuff in a 64bit rpm is plain broken.  You'd effectively force an install
of 64bit firefox to install 32 bit userspace since the idea is to make firefox
Require this for plugins.  Shipping things which interact with firefox in a
broken way is a quick way to make my life hard and to upset upstream.  Either we
fix it, or we don't allow it in our repo, and I go through lengths to ensure
that firefox will conflict with a broken package as I am well within rights to
do as I have to maintain both our Firefox package and our relationship with
upstream.

Additionally, plugins out of process provides a benefit of not crashing the
browser when the plugin crashes and we can improve our security defenses with
SELinux being able to sandbox them into a different context.  Those two reasons
alone make it worth doing for every arch combination we support.  This includes,
e.g. i386 on i386.
Comment 44 Sander Hoentjen 2007-06-11 13:45:49 EDT
(In reply to comment #39)
> (In reply to comment #37)
> > nspluginsetup is failing to do its thing for me.  Any ideas?
> 
> checking. What browsers do you have installed? Do you want to wrap flash only
> for i386 browser (not for x86_64)?

It fails with the same error for me too:
# nspluginsetup -i
nspluginwrapper: no appropriate viewer found for
/usr/lib/mozilla/plugins-backup/libflashplayer.so
nspluginwrapper: no appropriate viewer found for
/usr/lib/mozilla/plugins-backup/libflashplayer.so

# rpm -q --qf='%{name}-%{version}-%{release}.%{arch}\n' nspluginwrapper firefox
nspluginwrapper-0.9.91.4-2.fc8.i386
nspluginwrapper-0.9.91.4-2.fc8.x86_64
firefox-2.0.0.4-2.fc7.x86_64

Comment 45 Warren Togami 2007-06-11 14:32:53 EDT
[root@newcaprica ~]# rpm -q --qf='%{name}-%{version}-%{release}.%{arch}\n'
nspluginwrapper firefox
nspluginwrapper-0.9.91.4-2.fc7.x86_64
nspluginwrapper-0.9.91.4-2.fc7.i386
firefox-2.0.0.4-2.fc7.i386
firefox-2.0.0.4-2.fc7.x86_64

I am trying to wrap it to run in x86_64 firefox.
Comment 46 Bill Nottingham 2007-06-12 01:18:54 EDT
*** Bug 198786 has been marked as a duplicate of this bug. ***
Comment 47 Martin Stransky 2007-06-12 04:20:25 EDT
(In reply to comment #44)

Aha, okay. I can reproduce it. It looks like a problem in package ordering
during installation.
Comment 48 Martin Stransky 2007-06-12 05:14:02 EDT
Looks like a race condition during rpm installation. Please try to install the
i386 nspluginwrapper package first and than the x86_64 one. 

Comment 49 Martin Stransky 2007-06-12 11:15:24 EDT
btw. rpmbuild -ba nspluginwrapper.spec --target=i386 doesn't produce an i386
binaries / package if you run it on x86_64.

Cross-compilation is broken in this package, you have to build it in i386
environment.
Comment 50 David Woodhouse 2007-06-12 18:39:06 EDT
(In reply to comment #33)
> By the way, the upstream code does not really work with anything other than
> i386/x86_64 AFAIK.  Unless that's changed recently.  We would probably need help
> from various arch teams porting the code.  The ppc port requires qemu, and I
> really don't want firefox to (implicitly) require qemu.

nspluginwrapper consists of two parts. I'm not entirely sure what to call them;
I'll settle for 'plugin' (which is the x86_64 plugin which actually runs in your
native firefox) and 'runtime' (which is normally the i386 bit that loads the
actual flash plugin library). 

When you run i386 plugins in x86_64 you'll want the x86_64 'plugin' package and
the i386 'runtime' package. 

There's no reason not to build both 'plugin' and 'runtime' packages for other
architectures too. It wouldn't create an implicit dependency on qemu -- users
would need to do something special to install the
nspluginwrapper-runtime.i386.rpm on their system.
Comment 51 Callum Lerwick 2007-06-12 22:14:09 EDT
Has any one checked out my package?

http://www.haxxed.com/rpms/nspluginwrapper-0.9.90.1-0.src.rpm

I only just found out about this review. I attempted to package nspluginwrapper
a while back but at the time I wasn't able to get the damned thing to actually
work so I gave up and haven't got around to revisiting it. I take it it's
actually functional now?

My approach is a bit different. (and may be outdated)
Comment 52 Martin Stransky 2007-06-13 11:16:41 EDT
There's an updated package at http://people.redhat.com/stransky/nsplugin/

http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec
http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-3.fc7.src.rpm

fixes:

- updated nspluginsetup script and package install/uninstall scripts

- added cross-compilation support (you can build an i386 package on x86_64
system with "--target=i386" now)

- removed binaries stripping, moved debug info to nswrapperplugin-debuginfo package
Comment 53 Warren Togami 2007-06-13 11:32:53 EDT
Build failure on x86-64

+ export 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
+ export 'LDFLAGS=-m64 -L/usr/lib64'
+ LDFLAGS='-m64 -L/usr/lib64'
+ mkdir objs-64
+ pushd objs-64
~/rpmbuild/BUILD/nspluginwrapper-0.9.91.4/objs-64
~/rpmbuild/BUILD/nspluginwrapper-0.9.91.4
+ ../configure --prefix=/usr --target-cpu=x86_64 --pkgdir=nspluginwrapper
--pkglibdir=/usr/lib64/nspluginwrapper --with-lib32=lib --with-lib64=lib64
--with-base-lib=lib64 --with-base-libdir=/usr/lib64 --with-x11-prefix=/usr
../configure: line 234: /home/komat/log.txt: No such file or directory
GTK+ 2.0 environment not usable
error: Bad exit status from /var/tmp/rpm-tmp.38424 (%build)
Comment 54 David Woodhouse 2007-06-13 11:43:46 EDT
Build failure on PPC too.

error: Architecture is not included: ppc

There's no reason for this; please fix.
Comment 55 Martin Stransky 2007-06-13 11:48:17 EDT
fixed at http://people.redhat.com/stransky/nsplugin/
(new nspluginwrapper-0.9.91.4-3.fc7.src.rpm file)
Comment 56 David Woodhouse 2007-06-13 11:51:49 EDT
(In reply to comment #51)
> Has any one checked out my package?
> 
> http://www.haxxed.com/rpms/nspluginwrapper-0.9.90.1-0.src.rpm
> 
> I only just found out about this review. I attempted to package nspluginwrapper
> a while back but at the time I wasn't able to get the damned thing to actually
> work so I gave up and haven't got around to revisiting it. I take it it's
> actually functional now?
> 
> My approach is a bit different. (and may be outdated)

That approach looks better, as it splits the package appropriately into plugin
and runtime packages. As an added bonus, it also happens to build.
Comment 57 Martin Stransky 2007-06-13 13:28:19 EDT
(In reply to comment #54)
> Build failure on PPC too.
> 
> error: Architecture is not included: ppc
> 
> There's no reason for this; please fix.

ppc is not currently supported by this package a we can simply add its support
later, when this package works fine for the major arches (i.e. i386/x86_64). I
don't think it's a big problem (to add this support) but let's make thing
subsequently.

http://www.haxxed.com/rpms/nspluginwrapper-0.9.90.1-0.src.rpm is based on an old
upstream version what doesn't supress ppc:ppc wrapping.
Comment 58 Martin Stransky 2007-06-13 13:40:56 EDT
btw. see the review process at
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines

There's a line there:

- The package must successfully compile and build into binary rpms on at least
one supported architecture.

So let's make this package into fedora with a base functionality and then
improve it.
Comment 59 Warren Togami 2007-06-13 13:50:55 EDT
[root@newcaprica mock]# rpm -ivh
fedora-7-i386/result/nspluginwrapper-0.9.91.4-3.fc7.i386.rpm
fedora-7-x86_64/result/nspluginwrapper-0.9.91.4-3.fc7.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:nspluginwrapper        ########################################### [ 50%]
Installing plug-ins for 64-bit browser...
   2:nspluginwrapper        ########################################### [100%]
Installing all plug-ins...
Install plugin /usr/lib/mozilla/plugins-backup/libflashplayer.so
  into /usr/lib/mozilla/plugins/npwrapper.libflashplayer.so
Install plugin /usr/lib/mozilla/plugins-backup/libflashplayer.so
  into /usr/lib64/mozilla/plugins/npwrapper.libflashplayer.so

1) You must quiet these messages during %post and %preun.  Redirect the output
to /dev/null.
2) Please offload the list of plugins to wrap to /etc/sysconfig/nspluginwrapper
or someplace.  It must be possible for users to edit the list and have it
survive package upgrades.
3) Please allow a config boolean like WRAPALL=yes or WRAPALL=no for users to
enable wrapping of all plugins if they wish it.  (It would of course need to
avoid wrapping itself or already wrapped plugins...)
4) Cross-compile with --target=i386 fails here, although my builds done in mock
on both archs work.  I think it isn't necessary to fix cross-compile but it
would be nice.

~/rpmbuild/BUILD/nspluginwrapper-0.9.91.4/objs-32
~/rpmbuild/BUILD/nspluginwrapper-0.9.91.4
+ ../configure --prefix=/usr --target-cpu=i386 --pkgdir=nspluginwrapper
--pkglibdir=/usr/lib/nspluginwrapper --with-lib32=lib --with-lib64=lib64
--with-base-lib=lib64 --with-base-libdir=/usr/lib --with-x11-prefix=/usr
GTK+ 2.0 environment not usable
error: Bad exit status from /var/tmp/rpm-tmp.3311 (%build)

5) Decide whether you want to use this packaging or the alternative that dwmw2
prefers.  I don't want to decide that.
6) *PLEASE* allow ppc builds before the initial version of this goes into the
repo.  It really wont take much to make it buildable.
Comment 60 Martin Stransky 2007-06-13 14:14:54 EDT
(In reply to comment #59)

Great, thanks for the suggestions, we can move forward now.

> [root@newcaprica mock]# rpm -ivh
> fedora-7-i386/result/nspluginwrapper-0.9.91.4-3.fc7.i386.rpm
> fedora-7-x86_64/result/nspluginwrapper-0.9.91.4-3.fc7.x86_64.rpm 
> Preparing...                ########################################### [100%]
>    1:nspluginwrapper        ########################################### [ 50%]
> Installing plug-ins for 64-bit browser...
>    2:nspluginwrapper        ########################################### [100%]
> Installing all plug-ins...
> Install plugin /usr/lib/mozilla/plugins-backup/libflashplayer.so
>   into /usr/lib/mozilla/plugins/npwrapper.libflashplayer.so
> Install plugin /usr/lib/mozilla/plugins-backup/libflashplayer.so
>   into /usr/lib64/mozilla/plugins/npwrapper.libflashplayer.so
> 
> 1) You must quiet these messages during %post and %preun.  Redirect the output
> to /dev/null.

okay.

> 2) Please offload the list of plugins to wrap to /etc/sysconfig/nspluginwrapper
> or someplace.  It must be possible for users to edit the list and have it
> survive package upgrades.

okay, makes sense

> 3) Please allow a config boolean like WRAPALL=yes or WRAPALL=no for users to
> enable wrapping of all plugins if they wish it.  (It would of course need to
> avoid wrapping itself or already wrapped plugins...)

It should be a part of /etc/sysconfig/nspluginwrapper, right?

> 4) Cross-compile with --target=i386 fails here, although my builds done in mock
> on both archs work.  I think it isn't necessary to fix cross-compile but it
> would be nice.
> 
> ~/rpmbuild/BUILD/nspluginwrapper-0.9.91.4/objs-32
> ~/rpmbuild/BUILD/nspluginwrapper-0.9.91.4
> + ../configure --prefix=/usr --target-cpu=i386 --pkgdir=nspluginwrapper
> --pkglibdir=/usr/lib/nspluginwrapper --with-lib32=lib --with-lib64=lib64
> --with-base-lib=lib64 --with-base-libdir=/usr/lib --with-x11-prefix=/usr
> GTK+ 2.0 environment not usable
> error: Bad exit status from /var/tmp/rpm-tmp.3311 (%build)

You may miss some 32-bit library (i got this message for missing cairo-devel.i386) 
 
> 5) Decide whether you want to use this packaging or the alternative that dwmw2
> prefers.  I don't want to decide that.

Definitely this one. It consists from only one package for each architecture
what contains everything what's important (wrapper&viewer) and meets all
cailon's requests.

> 6) *PLEASE* allow ppc builds before the initial version of this goes into the
> repo.  It really wont take much to make it buildable.

okay, i'll check that.
Comment 61 Warren Togami 2007-06-13 14:22:12 EDT
> %define name            nspluginwrapper
> %define version         0.9.91.4
> %define release         3%{?dist}

Why this instead of simply writing this into Name, Version and Release?  What
does this gain you?  This could make things messy if your release number is
bumped in an automated mass rebuild.
Comment 62 David Woodhouse 2007-06-13 14:24:39 EDT
(In reply to comment #60)
> You may miss some 32-bit library (i got this message for missing
cairo-devel.i386) 

The BuildRequires: should handle this. Unless you're doing something really evil
like building x86_64.rpm packages which actually have i386 binaries in, in which
case you fall foul of RPM's limitations.

> > 5) Decide whether you want to use this packaging or the alternative that dwmw2
> > prefers.  I don't want to decide that.
> 
> Definitely this one. It consists from only one package for each architecture
> what contains everything what's important (wrapper&viewer) and meets all
> cailon's requests.

But you don't want both wrapper and viewer for the same arch. That's the whole
point, surely? You'll want x86_64 plugin, and i386 wrapper.

> > 6) *PLEASE* allow ppc builds before the initial version of this goes into the
> > repo.  It really wont take much to make it buildable.
> 
> okay, i'll check that.

The tarball builds fine, certainly. It doesn't look like upstream support was
removed.
Comment 63 Christopher Aillon 2007-06-13 15:02:47 EDT
> But you don't want both wrapper and viewer for the same arch. That's the whole
> point, surely? You'll want x86_64 plugin, and i386 wrapper.

That is one use case.  Another is to run plugins out of process at all times for
security reasons and to prevent a crashy plugin from taking down the browser. 
So you'd want to run e.g. x86-64 plugins on x86-64 or i386 on i386.
Comment 64 Martin Stransky 2007-06-13 16:16:47 EDT
(In reply to comment #62)
> (In reply to comment #60)
> > You may miss some 32-bit library (i got this message for missing
> cairo-devel.i386) 
> 
> The BuildRequires: should handle this. Unless you're doing something really evil
> like building x86_64.rpm packages which actually have i386 binaries in, in which
> case you fall foul of RPM's limitations.

It's a consequence of building rpm on x86_64 platform with --target=i386
argument. BuildRequires don't handle this situation... I'll check if it's
possible to fix it by some sensible way.
Comment 65 Christopher Aillon 2007-06-13 16:41:10 EDT
I wouldn't bother.  should be using setarch anyway.  comment 7 had this right.
Comment 66 Warren Togami 2007-06-13 20:03:12 EDT
> It's a consequence of building rpm on x86_64 platform with --target=i386
> argument. BuildRequires don't handle this situation... I'll check if it's
> possible to fix it by some sensible way.

Write an explicit comment about this in the spec file for people who build it
themselves manually.  Most users wont be building it, and mock builds it
correctly, so don't worry about this.
Comment 67 Nils Philippsen 2007-06-14 03:27:08 EDT
(In reply to comment #59)

> 2) Please offload the list of plugins to wrap to /etc/sysconfig/nspluginwrapper
> or someplace.  It must be possible for users to edit the list and have it
> survive package upgrades.

I'd suggest a directory (say /etc/nspluginwrapper/plugins.d) that contains one
file for each plugin. This would make it so much easier to sensibly ship plugins
in their own packages, i.e. they only have to include an appropriate file, call
the wrapper install utility and are set. It's a similar reason why we have
/etc/ld.so.conf.d nowadays and don't let packages muck with /etc/ld.so.conf
directly.
Comment 68 Martin Stransky 2007-06-14 07:34:34 EDT
(In reply to comment #67)
> I'd suggest a directory (say /etc/nspluginwrapper/plugins.d) that contains one
> file for each plugin. This would make it so much easier to sensibly ship plugins
> in their own packages, i.e. they only have to include an appropriate file, call
> the wrapper install utility and are set. It's a similar reason why we have
> /etc/ld.so.conf.d nowadays and don't let packages muck with /etc/ld.so.conf
> directly.

I don't quite understand what it can help us.
Comment 69 Martin Stransky 2007-06-14 07:40:50 EDT
An updated package is there: 

http://people.redhat.com/stransky/nsplugin/

http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-4.fc7.src.rpm
http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec

contains:

- ppc support (but i didn't test it, i don't have any ppc handy)
- plugin configuration at /etc/sysconfig/nspluginwrapper (but w/o the WRAPALL
option, i don't want to use it now)
- silent install/uninstall
Comment 70 Nils Philippsen 2007-06-14 08:14:05 EDT
(In reply to comment #68)
> (In reply to comment #67)
> > I'd suggest a directory (say /etc/nspluginwrapper/plugins.d) that contains one
> > file for each plugin. This would make it so much easier to sensibly ship plugins
> > in their own packages, i.e. they only have to include an appropriate file, call
> > the wrapper install utility and are set. It's a similar reason why we have
> > /etc/ld.so.conf.d nowadays and don't let packages muck with /etc/ld.so.conf
> > directly.
> 
> I don't quite understand what it can help us.

Consider this scenario:
- I want to package a plugin
- I want it to be automatically wrapped in nspluginwrapper if available

With the scheme I described, I could just put a small file into a known
directory and call the wrapper install utility. The utility scans the directory,
and creates the necessary symlinks (or whatever it does). When the package is
uninstalled, I call the utility to remove me and it removes the symlinks. I
don't have to insert stuff in a text file and subsequently remove it and run the
risk of erroneously removing the references to other plugins this way.

Comment 71 Martin Stransky 2007-06-14 08:25:05 EDT
(In reply to comment #70)

That looks quite complicated to me. Everything you have to do now is to install
a normal mozilla plug-in, run nspluginsetup and it will do everything for you
(e.g. it backups your current plugin, installs a symlink and so on).
Comment 72 Jakub Jelinek 2007-06-14 08:29:08 EDT
But that backing up of current plugin and replacing it with a symlink is
very unfriendly to rpm packaged plugins - if the rpm with the plugin owns
the plugin's path (whether it is the actual DSO or symlink to it), then
nspluginwrapper moves it away and replaces, at least rpm -V won't be very happy
about that.
Comment 73 Martin Stransky 2007-06-14 08:39:37 EDT
(In reply to comment #72)

Yep, but i don't see any better solution. If we want to avoid this we have to
change the default plug-in dir (/usr/lib(64)/mozilla/plugins) what is scanned by
browser.
Comment 74 Warren Togami 2007-06-22 15:13:38 EDT
Last I heard from caillon, he's working with stransky on a better solution to
some of these problems including:
- Do not move plugins installed by other RPMS.
Comment 75 Martin Stransky 2007-06-25 04:43:46 EDT
Cailon tries to find out some way how we can fix this issue. 

I keep work on compatibility / more plugins support. Work-in-progress package
(now with added x86_64:x86_64 wrapping) is here:
http://people.redhat.com/stransky/nsplugin/devel/
Comment 76 Martin Stransky 2007-06-25 09:31:27 EDT
A new package is there: 

http://people.redhat.com/stransky/nsplugin/

http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-5.fc7.src.rpm
http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec

contains:

- added x86_64:x86_64
- updated nspluginsetup script (you can install selected plugin by "-p" option)
- fixed plugin compatibility, mplayer/totem plug-ins work fine now
Comment 77 Martin Stransky 2007-06-25 10:12:14 EDT
This updated version works fine with an acrobat reader from RHEL-5.
Comment 78 Dominik 'Rathann' Mierzejewski 2007-07-22 09:53:52 EDT
$ rpmlint /var/lib/mock/fedora-6-x86_64-core/result
W: nspluginwrapper symlink-should-be-relative
/usr/lib64/mozilla/plugins/npwrapper.so /usr/lib64/nspluginwrapper/npwrapper.so
E: nspluginwrapper non-executable-script /etc/sysconfig/nspluginwrapper 0644
W: nspluginwrapper non-standard-group Networking/WWW
W: nspluginwrapper conffile-without-noreplace-flag /etc/sysconfig/nspluginwrapper
W: nspluginwrapper non-standard-group Networking/WWW
E: nspluginwrapper hardcoded-library-path in /usr/lib
E: nspluginwrapper configure-without-libdir-spec
W: nspluginwrapper mixed-use-of-spaces-and-tabs (spaces: line 104, tab: line 4)
Comment 79 Dominik 'Rathann' Mierzejewski 2007-07-22 12:04:59 EDT
What do I do to make it work? I've installed the 64bit build of nspluginwrapper
and put libflashplayer.so in /usr/lib/mozilla/plugins. nspluginsetup doesn't
seem to do anything if I run it and firefox doesn't show Flash plugin in
about:plugins after restarting it.
Comment 80 Martin Stransky 2007-07-23 05:00:56 EDT
you have to build and install the 32-bit version, too.
Comment 81 Martin Stransky 2007-07-25 03:57:34 EDT
Okay, there's an update what should fix that file-moving issue. It's here:

http://devserv.devel.redhat.com/~stransky/

(it's not public because i don't have enough space for it on my
people.redhat.com account)

All plugins are installed to common location in /usr/lib(64)/mozilla/plugins.
The modified firefox package uses plugins from
/usr/lib(64)/mozilla/plugins-wrapped. 

The plugins are linked (or wrapped, if the nspluginwrapper package is installed)
to mozilla/plugins-wrapped directory by firefox-plugin-config utility. 

firefox-plugin-config is called when firefox is starting and all should work
out-of-the-box (all you need to do is restart the browser).
Comment 82 Nils Philippsen 2007-07-25 07:04:30 EDT
(In reply to comment #81)

> (it's not public because i don't have enough space for it on my
> people.redhat.com account)

You should have enough space on your people.fedoraproject.org account, see the
recent announcement on fedora-maintainers-list (or was it
-devel/-devel-announce? I don't quite remember).
Comment 83 Martin Stransky 2007-07-25 07:56:36 EDT
ahh. so it's there, too.

http://people.fedoraproject.org/~stransky/
Comment 84 Martin Stransky 2007-07-26 03:55:13 EDT
Can we please move forward with that review? 

Package for review is here:
http://people.redhat.com/stransky/nsplugin/nspluginwrapper-0.9.91.4-7.fc7.src.rpm
Spec file for review is here:
http://people.redhat.com/stransky/nsplugin/nspluginwrapper.spec
Comment 85 Warren Togami 2007-07-26 10:00:36 EDT
So this requires a modified firefox?
Comment 86 Martin Stransky 2007-07-26 10:02:41 EDT
(In reply to comment #85)
> So this requires a modified firefox?

Exactly.
Comment 87 Adam Tkac 2007-07-27 07:31:06 EDT
rpmlint says:
E: nspluginwrapper hardcoded-library-path in /usr/lib
- if no sophisticated solution exists (like
%{_exec_prefix}/{target_libdir})leave this be...
E: nspluginwrapper configure-without-libdir-spec
- doesn't matter, %{_prefix} is defined and --with-lib{32,64} is specified

additional questions:
- why statements like
%if "%{target_bits}" == "64"
    export CFLAGS="-g -m64 -DDEBUG"
%else
    export CFLAGS="-g -m32 -DDEBUG"
%endif

I think it could be substituted with
export CFLAGS="$CFLAGS $RPM_OPT_FLAGS"
export CPPFLAGS="$CPPFLAGS -DDEBUG"

- this statement isn't needed
%if "%{target_bits}" == "64"
    export LDFLAGS="-m64 -L%{libdir64}"
%else
    export LDFLAGS="-m32 -L%{libdir32}"
%endif

-in %install section I've found
ln -s %{pkglibdir}/npwrapper.so $RPM_BUILD_ROOT/%{plugindir}/npwrapper.so
isn't it typo? (ln -s $RPM_BUILD_ROOT/%{pkglibdir}/npwrapper.so
$RPM_BUILD_ROOT/%{plugindir}/npwrapper.so)

Other things look fine. Please only check potential problems written upper. If
I'm wrong leave them be...

Adam
Comment 89 Martin Stransky 2007-07-27 07:57:18 EDT
(In reply to comment #87)
> additional questions:
> - why statements like
> %if "%{target_bits}" == "64"
>     export CFLAGS="-g -m64 -DDEBUG"
> %else
>     export CFLAGS="-g -m32 -DDEBUG"
> %endif

Fixed in package above (nspluginwrapper-0.9.91.4-8.fc7.src.rpm)

> - this statement isn't needed
> %if "%{target_bits}" == "64"
>     export LDFLAGS="-m64 -L%{libdir64}"
> %else
>     export LDFLAGS="-m32 -L%{libdir32}"
> %endif

It has to be there (this package uses his own ./configure & make)
 
> -in %install section I've found
> ln -s %{pkglibdir}/npwrapper.so $RPM_BUILD_ROOT/%{plugindir}/npwrapper.so
> isn't it typo? (ln -s $RPM_BUILD_ROOT/%{pkglibdir}/npwrapper.so
> $RPM_BUILD_ROOT/%{plugindir}/npwrapper.so)

It's correct, you can check a binary package.
Comment 90 Adam Tkac 2007-07-27 09:59:23 EDT
Looks fine for me now
Comment 91 Martin Stransky 2007-07-27 10:13:30 EDT
New Package CVS Request
=======================
Package Name: nspluginwrapper
Short Description: A compatibility layer for Netscape 4 plugins
Owners: stransky@redhat.com caillon@redhat.com
Branches: F-7
InitialCC:
Comment 92 Warren Togami 2007-07-27 11:47:41 EDT
Is the new firefox going into F7 updates prior to this?
Comment 93 Martin Stransky 2007-07-28 02:27:28 EDT
(In reply to comment #92)
> Is the new firefox going into F7 updates prior to this?

Yes, we'll update firefox/seamonkey according to this package. But it will be
released and tested in devel/f8, first.
Comment 94 Jens Petersen 2007-09-20 00:49:07 EDT
+1 for a F-7 build

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