Back to article
Don't Trip on the Red Carpet, Evolve with GNOME CVS
A Good Week for Compulsive Updaters
February 23, 2001
I bet there's a malady common to all Debian users, courtesy of the addictive simplicity of apt-get: it involves running apt-get update ten times a day looking to see if any of the archives have changed, heralding the arrival of something good, like a nagging bug that's been fixed, or the latest release of a closely watched program. It's a sickness, but when you have a sources.list that includes everything from Galeon's latest builds to Evolution to the ever-evolving KDE2 archives maintained by Ivan Moore, there's always a chance something's changed.
This last week has been a great one for GNOME watchers, and it provided plenty of opportunities for a lot of apt-getting. Last Saturday, GNOME 1.4's first beta release came out. Ximian had it packaged and ready to go in remarkably short time. A few days later, Ximian was at it again,rolling out Red Carpet 0.9, which we'll look at further along in this column.
GNOME 1.4 Beta One: Hold Your Horses and Give it a Week
Sometimes helping out your favorite project by compulsively downloading the latest snapshot or refreshing your copy of the CVS tree of a favorite project is hard. It involves things breaking, or going wrong, or not working as billed, and this particular release is no exception. Though the version of gdm, the GNOME X display manager, that ships with the beta has a "GNOME Classic" option for using GNOME 1.2, there are a lot of core libraries that get updated for this beta, and some things break as a result.
Download this with your eyes open or, better yet, give it another week or two: a second beta that will likely take care of the worst of the bugs unearthed by the more adventurous is supposed to be making its way out in a week (February 28).
Opportunity knocks in the form of a broken library
Evolution and Red Carpet both depend on the gtkhtml library. Evolution, for instance, uses it in part to render HTML mail and in part for composition of messages. A version of gtkhtml was shipped out that broke elements of the library needed to compose messages in Evolution, leaving a lot of people curious about Red Carpet with a broken mail client to contend with.
By the time this hits the web, there's a chance the snapshots Ximian is shipping will have corrected the problem (they're reportedly moving their servers this week, contributing to a slowdown), but in case it doesn't, this is an excellent opportunity for the curious to learn a little about GNOME CVS, because all that's needed to get both Red Carpet up and running and restore Evolution to proper functionality is a build of gtkhtml from CVS.
The GNOME project has provided a page that teaches a little about how to use anonymous CVS to get the latest elements of the GNOME project. There's no point in replicating all the information that link provides, since it's clear and concise and even I can follow along. The thing to keep in mind is just that in order to have both Red Carpet and Evolution running alongside each other at this point, you want to get a copy of gtkhtml with cvs -z3 checkout gtkhtml once you've set the proper environmental variables. You'll need to build the library and replace the existing gtkhtml once you've installed Red Carpet, because most of the means for obtaining it will automate the installation of the newer, broken version of the library.
Building from CVS, just to provide one more caveat for newer users, isn't the same as building from a tarball. CVS builds involve using the autogen.sh script found in the package's directory and passing appropriate variables to it much as you would with a typical configure script found in source tarballs. In the case of building for GNOME packages, putting new builds in right place is key. You'll likely want to use the line:
./autogen.sh --prefix=/usr --sysconfdir=/etc
if you're building against a GNOME installation you downloaded as binary packages for your distribution.
You can probably install the library over the existing one Red Carpet
will install, but if you can, force the removal of the package using
either the dpkg -r --force-depends command or RPM's rpm
-e --force. Your package manager may complain for a day or two,
but it's tidier when it comes time to resync with whoever's providing
your binary packages, because you'll be able to simply make
uninstall the library you built from CVS and replace it with a
normal binary package when the time's right without worry of cruft
being left laying around in your directories.