(Fedora 13) Seamonkey 2.0.x constantly crashing

[Mason]

Hello everyone,

The Seamonkey 2.0.x package in Fedora 13 is unusable,
as it crashes randomly, sometimes within seconds.

This problem has been well-known for months.

Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=602437

Mozilla bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=522635

As far as I understand...

In Linux, gecko (the layout engine) links to libcairo. When Mozilla
upgraded from libcairo 1.8.8 to libcairo 1.8.10, they found a bug in
gecko that made the app crash. This bug was fixed on the gecko 1.9.2
branch, but not on the 1.9.1 branch.

Seamonkey 2.0.x is based on gecko 1.9.1, and the package is built
to link to the system's libcairo, which is > 1.8.8 => CRASH

There are (at least) two solutions to this problem.

1. Several people have back-ported the gecko 1.9.2 fix to the 1.9.1
branch. Applying one of these patches would make Seamonkey 2.0.x work
with the system's libcairo. (Debian and Ubuntu have done that.)

2. Seamonkey provides its own private version of libcairo 1.8.8
Linking to that version of libcairo does not trigger the crash.
(This is how the official build is compiled, and in fact, linking
to the private libcairo is the recommended method.)
All it takes is --disable-system-cairo in the build script.

Both of these suggestions have been ignored by the package maintainer.

Having an app crash randomly and constantly is a very frustrating
experience.

Solution 2 is extremely trivial to implement.
What can I do to make it happen?

[Development discussions related to Fedora]

On 06/10/10 20:04, Mason wrote:
> What can I do to make it happen?

Help the maintainer, by testing the proposed fix yourself with an rpmbuild:

1. yum downloader --source name-of-package(or parent package)
2. extract the rpm
3. test your rpmbuild capability works with the existing packages as is
4. open up the .spec
5. bump the release part
6. add a comment describing the action you are taking
7. add a patch from elsewhere to the patch file definition
8. add the apply patch command to the %prep section
9. rpmbuild -ba the-package
10. install the built package
11. test the application
12. when you are sure that the fix works and doesn't introduce other
issues, make a diff of the spec ot the original
13. post the spec patch and the actual patch to the bug. indicate that
this has successfully built and been running, perhaps with some stats
eg: a couple of runs of before and after:
- time applicationname

Much more on package development on the fedoraproject wiki, just ask if
you are having trouble...

[Mason]

David Timms wrote:
> Mason wrote:
> > What can I do to make it happen?
>
> Help the maintainer, by testing the proposed fix yourself with an rpmbuild:
> yum downloader --source name-of-package(or parent package)
> extract the rpm
> test your rpmbuild capability works with the existing packages as is
> open up the .spec
> bump the release part
> add a comment describing the action you are taking
> add a patch from elsewhere to the patch file definition
> add the apply patch command to the %prep section
> rpmbuild -ba the-package
> install the built package
> test the application
> when you are sure that the fix works and doesn't introduce other
>
> issues, make a diff of the spec ot the original
> 13. post the spec patch and the actual patch to the bug. indicate that
> this has successfully built and been running, perhaps with some stats
> eg: a couple of runs of before and after:
> time applicationname
>
> Much more on package development on the fedoraproject wiki, just ask if
> you are having trouble...

For the record, SUSE quickly fixed the problem, using the
--disable-system-cairo solution.

https://bugzilla.novell.com/show_bug.cgi?id=622375#c13

The SUSE package maintainer wrote in comment 9:
> Thanks for checking this out. There is/was another issue which would turn up
> when we use the internal cairo.
> This is basically sorted out and I'll drive switching to internal cairo asap
> (either 11.4 or even for security updates given this bugreport).

Is anyone aware of any potential issue when using Mozilla's private
libcairo on Fedora 13?

[Bill Davidsen]

Mason wrote:
> David Timms wrote:
> > Mason wrote:
> > > What can I do to make it happen?
> >
> > Help the maintainer, by testing the proposed fix yourself with an rpmbuild:
> > yum downloader --source name-of-package(or parent package)
> > extract the rpm
> > test your rpmbuild capability works with the existing packages as is
> > open up the .spec
> > bump the release part
> > add a comment describing the action you are taking
> > add a patch from elsewhere to the patch file definition
> > add the apply patch command to the %prep section
> > rpmbuild -ba the-package
> > install the built package
> > test the application
> > when you are sure that the fix works and doesn't introduce other
> >
> > issues, make a diff of the spec ot the original
> > 13. post the spec patch and the actual patch to the bug. indicate that
> > this has successfully built and been running, perhaps with some stats
> > eg: a couple of runs of before and after:
> > time applicationname
> >
> > Much more on package development on the fedoraproject wiki, just ask if
> > you are having trouble...
>
> For the record, SUSE quickly fixed the problem, using the
> --disable-system-cairo solution.
>
> https://bugzilla.novell.com/show_bug.cgi?id=622375#c13
>
> The SUSE package maintainer wrote in comment 9:
> > Thanks for checking this out. There is/was another issue which would turn up
> > when we use the internal cairo.
> > This is basically sorted out and I'll drive switching to internal cairo asap
> > (either 11.4 or even for security updates given this bugreport).
>
> Is anyone aware of any potential issue when using Mozilla's private
> libcairo on Fedora 13?

No, I gave up and pulled the 2.0.8 build off the mozilla.org site and installed 
it in /usr/local/seamonkey-2.0.8, and then added a custom launcher for it. Life 
is too short to waste time on unmaintained packages. Hopefully there will be a 
better package for RHEL-6.0 and packages for form-fill and lightning which are 
pretty desirable for business or home office use.

At one point any lib which Fedora provided was more solid than what came with, 
but that's not the case any more, lots of down ref and no maintainer interest.

(Fedora 13) Seamonkey 2.0.x - bundling external libraries

[Development discussions related to Fedora]

On 07/10/10 20:07, Mason wrote:
> Is anyone aware of any potential issue when using Mozilla's private
> libcairo on Fedora 13?

Fedora packaging guidelines [1] prevents bundling external libraries.
Main reason [2] is that security and bug fixes should be fixed in the
one library, and hence fix all applications against that issue. If there
was no such policy, then it would essentially be impossible to fix any
security issue against the library, because it becomes hidden in N
application binaries.

There is also a memory use improvement by using shared libraries.

[1]
http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_lib...
[2] http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

(Fedora 13) Seamonkey 2.0.x - bundling external libraries

[Bill Davidsen]

David Timms wrote:
> On 07/10/10 20:07, Mason wrote:
> > Is anyone aware of any potential issue when using Mozilla's private
> > libcairo on Fedora 13?
>
> Fedora packaging guidelines [1] prevents bundling external libraries.
> Main reason [2] is that security and bug fixes should be fixed in the
> one library, and hence fix all applications against that issue. If there
> was no such policy, then it would essentially be impossible to fix any
> security issue against the library, because it becomes hidden in N
> application binaries.

Given that the libraries needed by Seamonkey *are* packaged with the auite, and 
have been for years, I'm not sure what guidelines you mean.
> There is also a memory use improvement by using shared libraries.
>
> [1]
> http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_lib...
> [2] http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

[Bill Davidsen]

Mason wrote:
> David Timms wrote:
> > Mason wrote:
> > > What can I do to make it happen?
> >
> > Help the maintainer, by testing the proposed fix yourself with an rpmbuild:
> > yum downloader --source name-of-package(or parent package)
> > extract the rpm
> > test your rpmbuild capability works with the existing packages as is
> > open up the .spec
> > bump the release part
> > add a comment describing the action you are taking
> > add a patch from elsewhere to the patch file definition
> > add the apply patch command to the %prep section
> > rpmbuild -ba the-package
> > install the built package
> > test the application
> > when you are sure that the fix works and doesn't introduce other
> >
> > issues, make a diff of the spec ot the original
> > 13. post the spec patch and the actual patch to the bug. indicate that
> > this has successfully built and been running, perhaps with some stats
> > eg: a couple of runs of before and after:
> > time applicationname
> >
> > Much more on package development on the fedoraproject wiki, just ask if
> > you are having trouble...
>
> For the record, SUSE quickly fixed the problem, using the
> --disable-system-cairo solution.
>
> https://bugzilla.novell.com/show_bug.cgi?id=622375#c13
>
> The SUSE package maintainer wrote in comment 9:
> > Thanks for checking this out. There is/was another issue which would turn up
> > when we use the internal cairo.
> > This is basically sorted out and I'll drive switching to internal cairo asap
> > (either 11.4 or even for security updates given this bugreport).
>
> Is anyone aware of any potential issue when using Mozilla's private
> libcairo on Fedora 13?

I suggest you D/L the Mozilla version, unpack it (generates "seamonkey" dir), 
and move the directory to a reasonable place (/usr/local for me) and generate a 
custom icon for it. That seems solid.

Note: I have selinux on, and therefore needed to do
   chcon -t texrel_shlib_t /usr/local/seamonkey/lib*.so
to get solid operation.

HTH.

[Mason]

Bill Davidsen wrote:
> I suggest you D/L the Mozilla version, unpack it (generates "seamonkey"
> dir), and move the directory to a reasonable place (/usr/local for me)
> and generate a custom icon for it. That seems solid.

Seamonkey users,

I'm happy to announce that the bug that made Seamonkey crash
within minutes has been fixed, not only in Fedora :

https://bugzilla.redhat.com/show_bug.cgi?id=602437
( Thanks Martin )

but also upstream, for every Linux distro :

https://bugzilla.mozilla.org/show_bug.cgi?id=522635
( Thanks Karl )

seamonkey-2.0.8-2.fc13 was pushed to stable on Oct 22.
seamonkey-2.0.9-1 will be available in a few days.

Thanks to everybody who helped quash this bug!  :-)