Seamonkey progress

[Mike Hommey]

On Thu, Oct 12, 2006 at 09:05:03PM +0200, Hendrik-Jan Heins <hjheins at gmail.com> wrote:
> Ooooh I'm so going to pick your brain about this!
> 
> First of all: thanks a lot:
> A lot of the changes are about the way you define how and where to
> install files. I didn't dare to do it as you did it (yet), but I sort
> of thought it would work like that.
> I saw your "script in rulesfile" I needed that, but didn't know how to
> do it, nice! I learned a lot from this!

What do you mean ?

> But now on to the "real work".
> I do have a lot of questions and some suggestions about your build.
> First of all: Alexander, yes as far as I found out, the update script
> is still needed.
> 
> Now for my points;
> first about the patches
> why a complete configure file? -> patch it?
> -> why again setting settings here you can sat with mozconfig?
> lots of "changes" are identical to the original; why?
> isn't patching configure.in a better/shorter way?
> why not enable embedding tests in mozconfig? (same goes for myspell
> and some other stuff I saw defined in configure)
> why enable them thru a patch?

configure is patched instead of being updated with autoconf, so that we
don't need a dependency on autoconf, and so that the configure file
doesn't get changed in unknown broken ways by a new version of autoconf.

All the changes are actually done in configure.in, and the fact is we
*add* argument flags that we actually use in mozconfig, such as
enable-system-myspell.

For embedding tests, it was a request in an upstream bug that i
implemented and eventually got applied upstream, which means when the
fix lands in an upstream release, we can easily find out it did and just
need to remove the patch.

> what's this/what does it do: ac_add_options --with-gssapi=/usr (mozconfig)

it used to be used for kerberos authentication, it seems to be useless
now...

> same: ac_add_options --disable-xpcom-obsolete --disable-javaxpcom

javaxpcom is disabled by default, but still it's better to disable it by
hand, and xpcom-obsolete is to disable some very old xpcom stuff that
may not be used anymore. These are options that are used on firefox and
xulrunner.

> Just a suggestion, but why not create an IceApe build directly from a
> Seamonkey source package? I attached a patch with the exact thing
> Alexanders source package does.
> Something to remember: a symlink in /usr/bin named seamonkey -> iceape
> is probably needed for compatability reasons. Gaim for instance will
> include a seamonkey connection in 2.0beta4.

We can ask the gaim maintainer to remove seamonkey support and add
iceape one.

> what about my jar compress patch? Are you already using that? (your
> jars are compressed mine weren't by default)

I didn't change anything for jar files...

> What about my patch for the browsertype and help pages (I placed that
> on the list a couple of e-mails ago, I think it is needed when you
> make it into IceApe; there you can also define the default project
> page)
 
The thing is that we need to change upstream files anyway, so I don't
know exactly (yet) what needs to be changed from our own orig.tar.gz
provided files.

> why the /etc/pref/<thingie> instead of /etc/prefs.js ?

Because then people can add as many pref files as they want in the /etc
directory. These files could be placed by other packages, etc.

> why install .autoreg?  it's generated anyway.

Not to have to remove it when removing the package. Having it in the
package makes us sure dpkg will know it exists and will know it has to
remove it.

> I think all "dom_*" files in base should (and can) be in the
> dom-inspector package.

I think all dom_* files are for components from the DOM implementation,
not of the DOM inspector.

> Now about the workings of the packages:
> 
> with only base and mailnews installed: cannot compose mails; read html
> mails etc...

Actually I'm not very surprised... I already had a problem with
chatzilla requiring files in the navigator chrome... I think we'll need
to end up doing as it used to be with mozilla... i.e. merge
-base and -browser... We don't have a huge amount of time to work on
file repartition between the packages, let's go the easy way and work on
better solutions after etch.

> your current version won't work in anything but basemode with gmail

What do you mean ?

> hmm, is it somewhat unstable (not sure!)?
> -> killed itself with this error:
> symbol lookup error: /usr/lib/seamonkey/components/libctl.so:
> undefined symbol: pangolite_find_map

Dammit, visibility hidden problem... the libmozpango.so doesn't export
the necessary pangolite_* symbols... Note that the ctl component and
pangolite are not built on xulrunner and firefox, maybe we could disable
it for the moment and work on reenabling it after etch.

> do I understand from your seamonkey-runner file that you by default
> disable pango?
> -> export MOZ_DISABLE_PANGO

That means the previously set MOZ_DISABLE_PANGO is exported. You'll note
it is not defined, which means pango is enabled. This trink is necessary
to be able to add MOZ_DISABLE_PANGO=1 in ~/.mozilla/seamonkeyrc file.

Mike