Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] what to do with Mozilla's Bit Rot (was: Fixing Firefox's "find in page")

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] what to do with Mozilla's Bit Rot (was: Fixing Firefox's "find in page")
  • Date: Wed, 2 Mar 2005 13:46:44 -0600

On Mar 02, Jeremy Blosser [jblosser-smgl AT firinn.org] wrote:
> On Mar 01, Karsten Behrmann [BearPerson AT gmx.net] wrote:
> > On Tue, 1 Mar 2005 10:08:58 -0800
> > Seth Alan Woolley <seth AT positivism.org> wrote:
> > > I say go ahead, it's completely unusable as it is. Probably not our
> > > fault in the end, but bit-rot and poor documentation on their build
> > > process.
> > >
> > > I'll be first in line to test when you give the go.
> >
> > I'd probably help testing too with mozilla-related things, since currently
> > my mozilla (with mail client) refuses to start and just comes up with a
> > sigsegv, regardless of whether ~/.mozilla exists.
>
> K, time to test. I just submitted a version to devel that builds here and
> runs without menu errors. I haven't gone very deep into if the functions
> work yet, since none of my mail is pop/imap and you all can test it better
> than I can.
>
> Some notes:
>
> 1) Make sure you rm -rf ~/.thunderbird /usr/lib/thunderbird1.0/ before
> casting this. These both have caches that *will* cause the errors to
> remanifest, and dispel misses the cache files in /usr/lib/thunderbird1.0/
>
> 2) I've only tried a basic build of this, no enigmail or mathml or
> ldap/etc. If other people could help try some of those permutations and
> verify they work as well I would appreciate it. I spent all day yesterday
> building and rebuilding with different flags so now that I have a working
> one I figured you'd want it ASAP.
>
> All I changed was adding mozconfig as the base to configure, and commenting
> out some configure flags:
> a) the ones already in mozconfig
> b) all the compiler optimizations
> (I also removed all debug message disabling to check what's going on for
> now, so be prepared for debug output.) It's possible using the mozconfig
> extensions/necko_protocols list is what fixed it, but I doubt it because we
> were already using the same neck_protocols and the only difference in the
> extensions list is that they include webservices. However, our old build
> actually had 2 --enable-extensions lines to ./configure, so it's possible
> this was doing something. It's either going to be this or the compiler
> optimizations. I'll test reenabling some things until it breaks again.

Re-enabling optimizations still works. I suspect the problem is that we
had this:

THUNDERBIRD_EXTENSIONS="wallet,spellcheck,xmlextras" &&
...
./configure ... \
...
--enable-extensions=$THUNDERBIRD_EXTENSIONS \
...
--enable-extensions \
...

So probably it's like the problem with firefox, where the default
--enable-extensions isn't safe to use (bit rot). I'm doing another test
build now that just uses the mozconfig --enable-extensions and should be
"how we want it". If it works I'll submit it and we can consider moving it
to test as well.

Attachment: pgpIcw5ElIzFP.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page