move seamonkey to linux ref VM

RESOLVED FIXED

Status

SeaMonkey
Build Config
--
blocker
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Bernd, Assigned: coop)

Tracking

Trunk
x86
Windows XP
Dependency tree / graph
Bug Flags:
blocking-seamonkey1.0a -
blocking-seamonkey1.0b -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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<----------------------------------------

Updated

13 years ago
Version: unspecified → Trunk

Updated

13 years ago
Flags: blocking-seamonkey1.0a?

Comment 1

13 years ago
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

13 years ago
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.
Assignee: nobody → chase
why were canvas/svg not enabled by changing the default values for them in
configure.in?

Comment 4

13 years ago
(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

13 years ago
(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

13 years ago
(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

13 years ago
(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.
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

13 years ago
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

13 years ago
(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?
(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

13 years ago
(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.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a+
(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...
Depends on: 301489
filed bug 301489 on the error with the newer platform sdk.
*** Bug 291765 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
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

13 years ago
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

13 years ago
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

12 years ago
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.
Flags: blocking-seamonkey1.0b+
Flags: blocking-seamonkey1.0a-
Flags: blocking-seamonkey1.0a+
Summary: enable svg and cairo in seamonkey windows nightly builds → enable svg and cairo in seamonkey nightly builds

Comment 20

12 years ago
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!
Flags: blocking-seamonkey1.0b+ → blocking-seamonkey1.0b-

Updated

12 years ago
Depends on: 286422

Comment 21

12 years ago
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build

Comment 22

11 years ago
So, when this is all done, we can remove the non-Cairo old code?
bz tells me that this is important and blocking work, i bumped the subject and severity accordingly.
Severity: normal → blocker
Summary: enable svg and cairo in seamonkey nightly builds → move seamonkey to linux ref VM
(Assignee)

Updated

11 years ago
Assignee: build → ccooper
(Assignee)

Comment 24

11 years ago
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.
Status: NEW → ASSIGNED

Comment 25

11 years ago
Created attachment 253414 [details]
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.
(Assignee)

Comment 26

11 years ago
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

11 years ago
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).
(Assignee)

Comment 28

11 years ago
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

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

Thanks so much!
(Assignee)

Comment 30

11 years ago
sea-linux-tbox is now generating the nightlies.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Blocks: 368990
You need to log in before you can comment on or make changes to this bug.