Closed Bug 713802 Opened 8 years ago Closed 8 years ago
Build with GIO support (and drop Gnome
3.79 KB, patch
|Details | Diff | Splinter Review|
786 bytes, patch
|Details | Diff | Splinter Review|
2.71 KB, patch
|Details | Diff | Splinter Review|
GnomeVFS has been deprecated for a long time, and may not even be shipped by default on modern operating system. The exalted successor is GIO, which will be on any system with GTK+-2.14. --enable-gio builds require GTK+-2.14 and GLib/GIO-2.18 (which is a requirement of GTK+-2.14). Our current build machines have only GTK+-2.10, even though Mozilla builds support only GTK+-2.12 or newer (since bug 666735). Upgrading libraries on our build machines is blocked by Bug 670707. The only major freely supported OS I found with GTK+-2.12 is Debian lenny which has security support until about 2012-02-06. With some minor changes (Bug 467168 comment 30) GIO builds could be made to work even on that system because it has GTK+-2.12.12 and GLib-2.16.6. However, changes made on mozilla-central now won't ship until well after then, so there's probably no point making those changes. https://wiki.mozilla.org/RapidRelease/Calendar
Do you want to do everything together as switching to gio and remove? gnome-vfs code from the tree? Or is it about switching for default build first and deprecate gnome-vfs for later removal?
Note that because of 710972, we need glib 2.26 to build with --enable-gio. What versions of gtk and glib are on RHEL5/Centos5? Or alternatively, do we want to continue supporting running mozilla builds on these?
Ubuntu still needs glib 2.24 until Apr 2013
It might also be a good idea to drop the gconf hard runtime dependency at the same time too. Future distributions will likely start to drop this from their default installs (we're quite close to dropping it in Ubuntu already), and --enable-gio turns on the GSettings support. As it stands, using GSettings on newer distro's will still require gconf to be installed (so that libmozgnome can be loaded). Should we start to dlopen gconf in nsGConfService? If so, I can open a separate bug for that and do that work.
ISTR there is already such a bug (dlopening gconf)
Maybe I was. Their scope is different though. I guess one or both will end up WONTFIX.
(In reply to Mike Hommey [:glandium] from comment #2) > Note that because of 710972, we need glib 2.26 to build with --enable-gio. Mike already has a trivial patch in bug 710972 so that we don't need to depend on 2.26. > What versions of gtk and glib are on RHEL5/Centos5? Or alternatively, do we > want to continue supporting running mozilla builds on these? GTK+-2.10 and GLib-2.12. Mozilla builds may run on these systems, but we don't provide updates, so they are already unsupported. The decision was made in bug 666735 comment 8.
Depends on: 710972
(In reply to Wolfgang Rosenauer [:wolfiR] from comment #1) > Do you want to do everything together as switching to gio and remove? > gnome-vfs code from the tree? I propose we at least --disable-gnomevfs at the same time as --enable-gio. If we don't --disable-gnomevfs, then to make libmozgnome.so load on systems without gnomevfs we'd need to change the gnomevfs code to use dlopen, and I don't see much point in doing that. We can remove the gnomevfs code any time after changing the build.
(In reply to Chris Coulson from comment #4) > Should we start to dlopen gconf in nsGConfService? If so, I can open a > separate bug for that and do that work. Yes, sounds good (and thanks for filing bug 710972), but that doesn't need to be a prerequisite for switching from gnomevfs to gio, which on its own is a step in the right direction.
Depends on: 696030
This bug doesn't seem to have concrete actions for RelEng at the moment. Perhaps we could move it over to Core:Build Config, and file a new bug if there are specific upgrades RelEng needs to make ?
Or re-summarize to 'Upgrade build slaves to gtk+-2.14 and glib-2.18' ?
If we make this bug "Upgrade build slaves to gtk+-2.14 and glib-2.18", will there still be build slaves capable of building Firefox 3.6? Do we still need to do 3.6 builds? Are there other products that would be affected?
3.6 is EOL on April 24, but 10 ESR will last a good deal longer than that. Blocking on bug 670707 is the right thing to do to deal with that, since it'll give us multiple build environments per slave.
Thanks. I wouldn't see a problem with building 10 ESR against GTK+-2.14 as we already dropped 2.10 support for Firefox 7.
http://lists.debian.org/debian-security-announce/2011/msg00238.html confirms Debian Lenny EOL 2012-02-06.
I notice that the Debian Squeeze (the release after Lenny) has GTK+-2.20 and even Ubuntu 10.04 LTS has GTK+-2.20. RHEL-6.2 has GTK+-2.18.9. SUSE Linux Enterprise 11-SP2 has GTK+-2.18.9. That made me wonder whether the Fedora 12 reference platforms (with GTK+-2.18.something) could be used as build machines. However, the Evergreen project is still supporting openSUSE 11.1, which had 2.14.4. That supports sticking with the GTK+-2.14 target.
Moving this bug to Core:Build Config as bug 740690 now covers upgrades on the build slaves.
Component: Release Engineering → Build Config
Product: mozilla.org → Core
QA Contact: release → build-config
Version: other → Trunk
(In reply to Karl Tomlinson (:karlt) from comment #18) > However, the Evergreen project is still supporting openSUSE 11.1, which had > 2.14.4. > > That supports sticking with the GTK+-2.14 target. The Evergreen support for openSUSE 11.1 went into "best effort" mode beginning of the year. For that it's fine to use FF/TB 10esr for its lifetime so no need to block further updates on that (speaking as openSUSE mozilla and Evergreen maintainer).
On a related note, what is the oldest libstdc++ in use on these systems we'll end up supporting?
(In reply to Wolfgang Rosenauer [:wolfiR] from comment #20) > For that it's fine to use FF/TB 10esr for its > lifetime so no need to block further updates on that (speaking as openSUSE > mozilla and Evergreen maintainer). Thanks, Wolfgang. I don't see any major new features between GTK+ 2.14 and 2.18 or between GLib 2.18 and 2.22 that we would use. Only a few possibilities that we could check at runtime. However, if it is easier for RelEng to adapt our Fedora 12 systems for building that could offer another option.
(In reply to Mike Hommey [:glandium] from comment #21) > On a related note, what is the oldest libstdc++ in use on these systems > we'll end up supporting? Looking at gcc versions on distrowatch, OpenSUSE 11.1 has gcc 4.3. If we ignore that then 4.4 is our oldest. Of course it is possible that some of these gcc builds may be customized to avoid recent libstdc++ symbols, but there's a quick estimate.
Is there an ETA on when GIO will be enabled by default? I'm working on the webapprt launcher for Linux and I'd like to use GIO.
When this is fixed, we should try to back out http://hg.mozilla.org/mozilla-central/rev/aa3266ba9cab
If comm-central builders are not migrated soon, then they'll need to explicitly disable these options. There are still some issues with the GIO extension trying to pull in trace-malloc symbols. https://tbpl.mozilla.org/php/getParsedLog.php?id=15534635&tree=Try#error0 talos runs: before change: https://tbpl.mozilla.org/?tree=Try&rev=78961ae08fc6 after change: https://tbpl.mozilla.org/?tree=Try&rev=e17b59691891
DeadlockDetector.h depends on NS_TraceMallocPrintStackTrace and BlockingResourceBase.cpp depends on NS_TraceMallocGetStackTrace. These symbols are exported from libxul.so, presumably precisely for this purpose. I wonder why XPCOM_GLUE_LDOPTS doesn't include libxul, but I haven't found descriptions of the intended purposes of XPCOM_GLUE_LDOPTS or MOZ_COMPONENT_LIBS.
Assignee: nobody → karlt
Attachment #664829 - Flags: review?(benjamin)
Comment on attachment 664769 [details] [diff] [review] part 2: default enable GIO support and disable GnomeVFS Review of attachment 664769 [details] [diff] [review]: ----------------------------------------------------------------- ::: configure.in @@ +4903,2 @@ > > if test "$MOZ_ENABLE_GIO" -a "$MOZ_ENABLE_GTK2" You should either drop gio from MOZ_EXTENSIONS when gio is disabled, or add a check for the gio libs when gio is in MOZ_EXTENSIONS. I'd go for the former. At the same time, the same semantics should be implemented for the case where gnomevfs is disabled (currently, it does the latter ; both should do the same thing).
Attachment #664769 - Flags: review?(mh+mozilla) → review-
Comment on attachment 664769 [details] [diff] [review] part 2: default enable GIO support and disable GnomeVFS Review of attachment 664769 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/confvars.sh @@ +20,5 @@ > MOZ_SERVICES_AITC=1 > MOZ_SERVICES_NOTIFICATIONS=1 > MOZ_SERVICES_SYNC=1 > MOZ_APP_VERSION=$FIREFOX_VERSION > +MOZ_EXTENSIONS_DEFAULT=" gio" Can we just move this out of extensions while we're at it? I don't like things being in extensions, the build logic is more complicated and it was never a great concept to begin with.
(In reply to Ted Mielczarek [:ted] from comment #29) > > +MOZ_EXTENSIONS_DEFAULT=" gio" > > Can we just move this out of extensions while we're at it? I expect it can be compiled into libxul, because gio will already be required by the icon image decoder. GIO is part of the GLib version Firefox require's now. But I fear it's more than a "while we're at it" project. The GIO extension is for the protocol handler to support additional protocols (sftp and smb iirc) while other GIO support is for more core functionality such as MIME type handling, so we'd still want a configure switch for the additional protocols. I don't want decisions re the right approach there to block turning off GnomeVFS.
Ok. Can you file a followup on that?
File bug 794698.
I doubt there are good reasons to use gnomevfs protocols without the rest of the gnomevfs support. Actually there is no good reason to use gnomevfs at all. (In reply to Mike Hommey [:glandium] from comment #28) > You should either drop gio from MOZ_EXTENSIONS when gio is disabled, or add > a check for the gio libs when gio is in MOZ_EXTENSIONS. I'd go for the > former. The former is already the case AFAICS. Corrected the warning messages a bit... > At the same time, the same semantics should be implemented for the > case where gnomevfs is disabled (currently, it does the latter ; both should > do the same thing). ... and changed the gnomevfs case to match.
Attachment #665223 - Flags: review?(mh+mozilla)
Attachment #664769 - Flags: review- → review?(mh+mozilla)
Attachment #665223 - Flags: review?(mh+mozilla) → review+
Attachment #664769 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/00e193643aa9 https://hg.mozilla.org/integration/mozilla-inbound/rev/e520ade90abf https://hg.mozilla.org/integration/mozilla-inbound/rev/157f3efdee37
https://hg.mozilla.org/mozilla-central/rev/00e193643aa9 https://hg.mozilla.org/mozilla-central/rev/e520ade90abf https://hg.mozilla.org/mozilla-central/rev/157f3efdee37
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Shouldn't gio module be also installed like the one for gnomevfs? Just curious. browser/installer/package-manifest.in (firefox) suite/installer/package-manifest.in (seamonkey)
(In reply to Jan Beich from comment #37) > Shouldn't gio module be also installed like the one for gnomevfs? Just > curious. > browser/installer/package-manifest.in (firefox) > suite/installer/package-manifest.in (seamonkey) You're right. Please file a followup bug.
You need to log in before you can comment on or make changes to this bug.