Seamonkey progress

[Hendrik-Jan Heins]

Hello Mike,

first of all: thank you for the answers.
I think there's not much more I have to say about it. So far it has
been a very good learning experience for me.
Below are a couple of small things.

> > 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 ?
>
Well, just what I wrote: I like the solutions. Some of them I sort of
guessed that they would work like that, but some are completely new to
me. Nice to learn this sort of stuff.
I started out on this without any knowledge on Debian packaging. I
think I now at least understand some of the workings.

> 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.
>
Aah right. I don't really know autoconf that well, but I am always
afraid for this sort of issues. Good to know I'm not the only one..
:-D

> 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.
>
ok

> > 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...
>
never seen it before.... I guess some thing you really have to know.

> > 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.
>
ok

> > 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.
>
yes that would be the alternative solution :-D
I don't know the way these things work in Debian, but I guess either
way would do it.

> > 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...
>
strange.. I'll look into that here.

> > 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.
>
I attached a patch to this e-mail that, as far as I can see, "fixes"
all seamonkey locations when building from a standard source package
from mozilla.org
There are some locations in there that refer to web locations, just as
in the two proposed default pages for mail and browser.
With this set, I think you can change everything that needs to be
changed on the branding.

> 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.
>
Ok. Will other .js files in that dir. be detected and used by default?

> > 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.
>
ok

> > 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.
>
I just tried it. I think you're right.

> 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.
>
Agreed.
-> so make the iceape-browser package the one that needs to be
installed by default?

> > your current version won't work in anything but basemode with gmail
>
> What do you mean ?
>
I saw your errata. It's about the Gecko definition that is not in the
browser string.

> > -> 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.
>
That might be the solution. On the other hand: I haven't been testing
that much with your version. I have been with mine. And the
differences between the two aren't huge. Mine has never crashed on me
(yet). So maybe it was just a fluke?

> 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.
>
ok, I realised this later. Thanks.

Hendrik-Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: app_name.dpatch
Type: application/octet-stream
Size: 4724 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/attachments/20061013/89f61dca/app_name-0001.obj