Closed
Bug 713802
Opened 13 years ago
Closed 12 years ago
Build with GIO support (and drop GnomeVFS)
Categories
(Firefox Build System :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla18
People
(Reporter: karlt, Assigned: karlt)
References
(Blocks 4 open bugs)
Details
(Whiteboard: [buildslaves])
Attachments
(3 files)
(deleted),
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
glandium
:
review+
|
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
Comment 1•13 years ago
|
||
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?
Comment 2•13 years ago
|
||
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?
Comment 3•13 years ago
|
||
Ubuntu still needs glib 2.24 until Apr 2013
Comment 4•13 years ago
|
||
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.
Comment 5•13 years ago
|
||
ISTR there is already such a bug (dlopening gconf)
Comment 6•13 years ago
|
||
The closes thing I found was bug 563628 and bug 547800. Were you thinking of one of those?
Comment 7•13 years ago
|
||
Maybe I was. Their scope is different though. I guess one or both will end up WONTFIX.
Assignee | ||
Comment 8•13 years ago
|
||
(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
Assignee | ||
Comment 9•13 years ago
|
||
(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.
Assignee | ||
Comment 10•13 years ago
|
||
(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
Updated•13 years ago
|
Priority: -- → P3
Whiteboard: [buildslaves]
Comment 12•13 years ago
|
||
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 ?
Comment 13•13 years ago
|
||
Or re-summarize to 'Upgrade build slaves to gtk+-2.14 and glib-2.18' ?
Assignee | ||
Comment 14•13 years ago
|
||
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?
Comment 15•13 years ago
|
||
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.
Assignee | ||
Comment 16•13 years ago
|
||
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.
Assignee | ||
Comment 17•13 years ago
|
||
http://lists.debian.org/debian-security-announce/2011/msg00238.html confirms Debian Lenny EOL 2012-02-06.
Assignee | ||
Comment 18•13 years ago
|
||
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.
Assignee | ||
Comment 19•13 years ago
|
||
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
Comment 20•13 years ago
|
||
(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).
Comment 21•13 years ago
|
||
On a related note, what is the oldest libstdc++ in use on these systems we'll end up supporting?
Assignee | ||
Comment 22•13 years ago
|
||
(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.
Assignee | ||
Comment 23•13 years ago
|
||
(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.
Comment 24•13 years ago
|
||
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.
Assignee | ||
Comment 25•12 years ago
|
||
When this is fixed, we should try to back out http://hg.mozilla.org/mozilla-central/rev/aa3266ba9cab
Assignee | ||
Comment 26•12 years ago
|
||
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
Assignee | ||
Comment 27•12 years ago
|
||
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)
Assignee | ||
Updated•12 years ago
|
Attachment #664769 -
Attachment description: default enable GIO support and disable GnomeVFS → part 2: default enable GIO support and disable GnomeVFS
Attachment #664769 -
Flags: review?(mh+mozilla)
Comment 28•12 years ago
|
||
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 29•12 years ago
|
||
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.
Updated•12 years ago
|
Attachment #664829 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 30•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=bab2232caaed
Assignee | ||
Comment 31•12 years ago
|
||
(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.
Comment 32•12 years ago
|
||
Ok. Can you file a followup on that?
Assignee | ||
Comment 33•12 years ago
|
||
File bug 794698.
Assignee | ||
Comment 34•12 years ago
|
||
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.
Assignee | ||
Updated•12 years ago
|
Attachment #665223 -
Flags: review?(mh+mozilla)
Assignee | ||
Updated•12 years ago
|
Attachment #664769 -
Flags: review- → review?(mh+mozilla)
Updated•12 years ago
|
Attachment #665223 -
Flags: review?(mh+mozilla) → review+
Updated•12 years ago
|
Attachment #664769 -
Flags: review?(mh+mozilla) → review+
Assignee | ||
Comment 35•12 years ago
|
||
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
Blocks: 682838
Flags: in-testsuite-
Comment 36•12 years ago
|
||
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: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Comment 37•12 years ago
|
||
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)
Comment 38•12 years ago
|
||
(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.
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•