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<----------------------------------------
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
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.
why were canvas/svg not enabled by changing the default values for them in configure.in?
(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.
(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.
(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.
(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.
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).
(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.
(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.
(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...
13 years ago
filed bug 301489 on the error with the newer platform sdk.
*** Bug 291765 has been marked as a duplicate of this bug. ***
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 ?
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.
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
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.
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!
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.
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.
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.
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.
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).
sea-linux-tbox's builds are going here for now: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/sea-linux-tbox-trunk/
Chris: the build seems fine. Please switch out lhasa => sea-linux-tbox for nightlies. Thanks so much!
sea-linux-tbox is now generating the nightlies.