294182 - move seamonkey to linux ref VM

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Bernd]

see mozconfig from creature
-->mozconfig<----------------------------------------
mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite

ac_add_options --without-system-jpg
ac_add_options --without-system-zlib
ac_add_options --enable-extensions=default,tasks
ac_add_options --enable-crypto
ac_add_options --disable-auto-deps
ac_add_options --disable-debug
ac_add_options --enable-optimize
-->end mozconfig<----------------------------------------

and from beast

-->mozconfig<----------------------------------------
. $topsrcdir/browser/config/mozconfig

ac_add_options --enable-optimize
ac_add_options --disable-debug
# ac_add_options --enable-codesighs
ac_add_options --disable-tests
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --enable-official-branding
ac_add_options --enable-svg
ac_add_options --enable-canvas
-->end mozconfig<----------------------------------------

Comment 1

[Stefan Persson]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050530

SVG and Cairo are also disabled on Linux.  Quoting about:buildconfig:

--enable-application=suite --disable-tests
--enable-extensions=default,irc,tasks,negotiateauth --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug '--enable-optimize=-O2 -gstabs+'
--enable-crypto --enable-default-toolkit=gtk

Comment 2

[Jean-Marc Desperrier]

Chase is the build engineer for the nightlies.

Either changes like this one for seamonkey should be assigned to him or he
doesn't actually maintain  the seamonkey nighlies, and the seamonkey council
needs to be made aware of that and search an alternative solution.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

why were canvas/svg not enabled by changing the default values for them in
configure.in?

Comment 4

[Chase Phillips]

(In reply to comment #3)
> why were canvas/svg not enabled by changing the default values for them in
> configure.in?

Until all of the owners of Tinderbox systems (including myself) can place
--disable-svg and --disable-canvas in their mozconfigs, the default values
should remain disabled.  Otherwise, many trees will go up in flames.

Comment 5

[Robert Kaiser]

(In reply to comment #3)
> why were canvas/svg not enabled by changing the default values for them in
> configure.in?

Because of the needed prerequisites that are not in place on tinderboxen and
probably even private machines where people are building.
Note that it's the same situation for Firefox, only that some release
tinderboxen that have everything needed installed, have turned on that stuff in
their own build configurations.

That's something we could do as well, given someone ensures our realease
tinderboxen have the needed prerequisites installed.

Comment 6

[Jean-Marc Desperrier]

(In reply to comment #5)
> That's something we could do as well, given someone ensures our realease
> tinderboxen have the needed prerequisites installed.

Good. Who can do that ? When ? The bug is opened since two months (and it had
been discussed before) so the best is probably to assume Chase is not available
to do such things, and we need to have another solution to update the seamonkey
tinderboxen.

And can the council decide whether or not it blocks seamonkey 1.0 and update the
flag ? I think the philosophy of SeaMonkey is to include everything and the
kitchen sink, so it would make no sense to ship without svg/canvas, so we need
to test it as much as possible ASAP and include it in the nightlies.

Comment 7

[Robert Kaiser]

(In reply to comment #6)
> Good. Who can do that ? When ? 

The "who" is Chase. The "when" is unclear.
He may need to update the systems of the affected tinderboxen (or at least check
for the prerequisites) and such stuff, and he might not have time for that.

> And can the council decide whether or not it blocks seamonkey 1.0 and update the
> flag ? I think the philosophy of SeaMonkey is to include everything and the
> kitchen sink, so it would make no sense to ship without svg/canvas, so we need
> to test it as much as possible ASAP and include it in the nightlies.

We will discuss that. Our philosophy is not to just bloat our application for
any feature though (as you make it sound). SVG/canvas are things we want to have
in the long terms for sure, though. I personally don't think we will push out an
alpha for that bug to be fixed though - but we will discuss that in council.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We don't want Seamonkey to make decisions about what Gecko features are/are not
included in the build. The Gecko used by Firefox and Seamonkey (and XULRunner
etc) must remain consistent.

Comment 9

[Stefan Persson]

The thing is that different Mozilla products use different Gecko features.  For
example, I doubt that anyone would need SVG support in the standalone calendar
(a.k.a. Sunbird).

Comment 10

[Robert Kaiser]

(In reply to comment #8)
> We don't want Seamonkey to make decisions about what Gecko features are/are not
> included in the build. The Gecko used by Firefox and Seamonkey (and XULRunner
> etc) must remain consistent.

Well, in fact, your argument might speak for the bug being resolved in favor of
SVG/canvas support, as IIRC firefox nightlies for certain platforms are
generated with SVG support (not completely sure about canvas though) currently -
or is my information on that incorrect?

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #9)
> The thing is that different Mozilla products use different Gecko features.  For
> example, I doubt that anyone would need SVG support in the standalone calendar
> (a.k.a. Sunbird).

If you plan to support extensions or rendering of any externally-provided HTML,
then people may rely on the standard Gecko features being enabled.

Kairo: yep, since FF will have SVG and canvas enabled, so should Seamonkey, eat
least for the real release.

Comment 12

[Robert Kaiser]

(In reply to comment #11)
> Kairo: yep, since FF will have SVG and canvas enabled, so should Seamonkey, eat
> least for the real release.

Exactly what I'm thinking.

So, to make all that clear, marking as an alpha blocker. We really want those
features enabled (like they are already in FF releases/nightlies) as soon as
possible.
If it comes down to this being the only thing that holds back an alpha and no
chance for the changes to be done any time soon (from that point in time), we
might consider slipping it to beta, but we still hope we won't have to get into
that discussion.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

(bug 291765 seems a duplicate of this, or the other way round...)

http://www.hg23.at/~robert/thebot-logs/%23seamonkey-20050602-110035.xml is an
irclog of the day where chase tried to turn on svg/canvas on beast

the tbox log would be at
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1117662960.12514.gz&fulltext=1
but seems gone...

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

filed bug 301489 on the error with the newer platform sdk.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 291765 has been marked as a duplicate of this bug. ***

Comment 16

[Jean-Marc Desperrier]

If I follow the link I see that the palmsync problem that made the build with
the new platform sdk fail is solved, so Chase can try again.

Maybe someone could check on a clean platform that it works correctly and what
exactly is needed, so that we can simplify Chase's work ?

Comment 17

[Rafal Likus]

From #seamonkey:
2005-08-17T00:28:05Z CTho:
FYI, chase said
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-08-16-14-trunk/
should be SVG & Canvas-enabled

Tested, on win32 works OK.

Comment 18

[Stefan Persson]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050828 SeaMonkey/1.1a

Linux still doesn't have SVG or Cairo.

about:buildconfig:

Configure arguments
--enable-application=suite --disable-tests --enable-extensions=default,tasks
--without-system-nspr --without-system-jpeg --without-system-zlib
--without-system-png --without-system-mng --disable-debug '--enable-optimize=-O2
-gstabs+' --enable-crypto --enable-default-toolkit=gtk

URL:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/seamonkey-1.1a.en-US.linux-i686-gtk1.tar.gz

Comment 19

[Robert Kaiser]

The builds made by some individuals for SeaMonkey 1.0 Alpha have svg/canvas
enabled, so not blocking that release any more.
Leaving this open for ensuring trunk and branch tinderboxen will generate builds
with svg/canvas in the future.

Could we get a short update which boxen build it and which still need it enabled?
For trunk, it looks from here like that:
creature (windows): enabled & working
comet (linux, gtk1): not enabled, not working
lhasa (linux, gtk2): ???
barcelona (mac): ???

For branch, we obviously have no build machines yet, so no status.

Comment 20

[Robert Kaiser]

Looks like we have to ship branch builds from our private boxen anyways, which have this enabled already.

Chase, just as a reminder once you are back from vacation:
Could you trun on svg/canvas on lhasa?
And as you'll need to do some stuff on barcelona for bsmedberg's QI checkin anyways, could you enable this stuff there as well?

(When those two are done, all SeaMonkey nightly builds - except comet's gtk1 builds, where we don't care about this - will be SVG/canvas-enabled and this bug can be marked FIXED)

Thanks!

Comment 21

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 22

[Alfred Kayser]

So, when this is all done, we can remove the non-Cairo old code?

Comment 23

[Robert Helmer [:rhelmer]]

bz tells me that this is important and blocking work, i bumped the subject and severity accordingly.

Comment 24

[Chris Cooper [:coop] (he/him)]

Setting up a new SeaMonkey build on the new Linux ref VM right now. Is luna's mozconfig file (modulo the Disable cairo section) a suitable starting point for a current set of cairo-ready configuration options? 

Please feel free to attach a better example.

Comment 25

[Andrew Schultz]

Attachment: better mozconfig

This is based on Linux argo-vm Dep Nightly's mozconfig.  It's a lot closer to what we need than luna's.

Comment 26

[Chris Cooper [:coop] (he/him)]

The new ref VM, sea-linux-tbox, is running now. It's also running all the same set of tests as lhasa.

At what point will people be comfortable with me switching release builds to sea-linux-tbox from lhasa? We'd like to retire lhasa (since it doesn't have cairo anyway) as soon as is feasible.

Comment 27

[Andrew Schultz]

As soon as possible.  :)  Can the new box push its builds to ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/ for now just to make sure they work.  If I can start one up, I think we should just switch and if we discover something is broken we'll fix it.

lhasa's builds are just not that relevant (and are slated to become pretty broken soon due to gecko changes).

Comment 28

[Chris Cooper [:coop] (he/him)]

sea-linux-tbox's builds are going here for now:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/sea-linux-tbox-trunk/

Comment 29

[Andrew Schultz]

Chris: the build seems fine.  Please switch out lhasa => sea-linux-tbox for nightlies.

Thanks so much!

Comment 30

[Chris Cooper [:coop] (he/him)]

sea-linux-tbox is now generating the nightlies.