Firefox 4.0 Simple Build on RHEL 6

Update: This is now out of date. Unless you insist on running FF4 or FF5, please see the update for FF6.

As far as I can tell, there will be no official release of Firefox 4 for RHEL 6 and clones (running Scientific Linux here).

If you scramble around for SRPMs to build FF4 on RHEL 6, you’ll end up with Fedora stuff which is utterly heedless of those of us who prefer stability. In other words, the SRPM is crafted for the latest and greatest, and unless you are an RPM hacker, you won’t get it to work.

The other course is to absorb another Yum repo, in case this the one from Remi. This means you must also absorb the EPEL repository, which has broken my system in the past and often does not have what I need. It also means there will be conflicts if you happen to like the ATrpm repository, since that tends to be mutually exclusive with EPEL. In other words, you must allow the Fedora folks to own your machine or you can’t have any of their stuff at all. It doesn’t help the Fedora folks are serious die-hard fanboys, and not very friendly to those who aren’t.

The point is, when running RHEL or any of the derivatives, it’s best to build Firefox 4.0 for yourself from source. At the same time, you want it as close to the RPM way of doing things as you can get it, by making sure the package you build includes as many of the same build options as are used in the RPMs. That’s because it will tend to reflect the way your system is designed in the first place.

Download the source from Mozilla, the item labeled firefox-4.0.source.tar.bz2 (or whatever is current by the time you read this). The older orthodox build location is /usr/local/src/, but these days you are encouraged to build everything from your user account and login as root only to install. I created a src folder in my home directory, and moved the file there. Then I unzip and untar it, and drop down into the resulting directory (mozilla-2.0).

You’ll need some basic configuration instructions, which comes in the form of a file named mozconfig. After several attempts, I find the following is as close to the Fedora RPM as you can get for RHEL 6:

mk_add_options MOZ_MAKE_FLAGS="-j4"
ac_add_options --enable-application=browser
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-pthreads
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --disable-installer
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --disable-strip
ac_add_options --enable-pango
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-startup-notification
ac_add_options --enable-libxul
ac_add_options --disable-crashreporter
ac_add_options --enable-safe-browsing
ac_add_options --enable-libnotify
ac_add_options --disable-necko-wifi
ac_add_options --disable-cpp-exceptions
ac_add_options --disable-updater
ac_add_options --enable-url-classifier
ac_add_options --enable-gio
ac_add_options --disable-gnomevfs

That first line is for machines with at least a dual core CPU. Change that -j4 to a -j2 if you have an older, single core processor. Otherwise, the only thing you’ll lack are a few dependencies even after installing the basic collection of development packages.

The way to do this is note the instructions here, which are a little out of date. Use the instructions for Fedora to add some packages with Yum. Then run the command make -f client.mk — if you are still missing something, the build will error out. By scanning upward a few lines from what you see on the command line, you’ll see the name of the package that’s missing. Sometimes you’ll have to run Yum searches to identify what RHEL calls the package you seek, but I didn’t have much trouble working it out. I recall it was three items, but I didn’t take notes at the time. If you need the kind of guidance I offer here, it’s a good time for you to learn for yourself. C’mon; you can do it!

Once it builds successfully, login as root and type make install, and hit ENTER. Should install nicely with the executable script in /usr/local/bin named “firefox” — just create your desktop applink to that file.

Just in case things don’t work as you like, I recommend you save a backup copy of your old Firefox settings. In my case, I chose to make a copy of the entire ~/.mozilla folder, renaming it ~/xmozilla. The addons for Firefox 3 don’t always work, and you’ll need to upgrade some of them, but on startup the new Firefox 4 will walk you through that.

Enjoy.

Geek Wars: Overriding RHEL Defaults in Vim Plugins

Between the RHEL package managers and the upstream providers for Vim, the default formatting options for some file types is wrong and exceedingly difficult to override. (I’m using Scientific Linux 6.0, but they deny changing the Vim packages provided by Red Hat.)

We want it our way, and we will fight until we get it. Most people do not use proper headings in their HTML files, but as long as things work, it’s no big deal. However, when the folks coding some of the most nit-picking purist orthodoxy in the world accommodate bad practices by forcing that accommodation on others, it’s just plain wrong. But I know better than to try appealing to the arrogant code gods for some flexibility. They are infallible, and won’t talk to ordinary users who can’t recite obscure pages of their voluminous documentation. Okay, so at least they write documentation. But it’s far outside the grasp of ordinary users, and the elitist mindset refuses to compromise with folks who simply want to use the software, not worship it. One way or another, you’re going to invest some time or the answers will not come.

I code my HTML files according to a currently accepted standard, known as XHTML Transitional. It renders well in all but a few obscure browsers, and it’s easier for me to remember all the precise details for tagging and so forth. As part of my training, I learned to put what are called “hard returns” at the end of each line, so that no matter what editor I had to use at the time, I could still read my own code and figure out what I did. Soft wrapping does not work for me. Again, it’s a valid choice, well understood and most text editors can work with that.

Except in Vim. I am by no means a Zen Master of Vim, nor do I ever want to be, nor should I have to be. I just use it for what I do. I took the time to learn how to construct a .vimrc and .gvimrc configuration files so I get Vim to behave as I like.

.vimrc
set spell spelllang=en
set spellfile=~/.vim/spellfile.add
set nocompatible
behave xterm
set shiftwidth=3
set tabstop=3
set backspace=indent,eol,start
set incsearch
syntax on
set showcmd
set wrap linebreak textwidth=72
set whichwrap=<,>,h,l,[,]
colorscheme koehler

I have fewer settings in my .gvimrc because it inherits most of the settings from .vimrc. The vast number of options are mind-numbing, and it was no small chore, but I found it worthwhile. But the code gods in their abundant wisdom have forced things which make Vim a real hassle when I use it for writing my HTML files. You see, they have developed this highly complex system of plugins for each file type, and they load after Vim parses my personal configurations. That means their choices cause Vim to ignore mine. It’s all explained here. I am utterly certain the Vim developers know this, and how it affects users, and probably snicker at the idea a really large number of duffers like me are either forced to become code gods themselves to fix it, or suffer in silence with the inconvenience.

I got lucky. I found out about querying Vim to see just where this hassle originates in the default plugin configurations. After poking around a bit, I discovered the problem was down to something which reset the format options from the default. In an open Gvim window, having typed nothing into the new unnamed file, hit the ESC key and then type exactly — :set formatoptions? This returns "formatoptions=tcq". That’s what we like for those of use auto wrapping at fixed line widths.

But for HTML and related file types, that’s broken. If I load one of my HTML files, and perform the same incantations, I get "formatoptions=croql". Aside from a few other details, the missing “t” is what causes my pain. I used another query which pointed which file was doing this. After hitting the ESC key, I typed exactly — :verbose set formatoptions — and found out it was /usr/share/vim/vim72/ftplugin/html.vim.

So I logged in as root and opened that file. At around line 18, I found a batch of code starting with the highly offensive line — setlocal formatoptions-=t — which specifically disables my line-wrap settings. Sure, after I finish a paragraph I can always wrap it with various commands to apply my chosen margins, but soft-wrap is very distracting for me while writing and trying to keep up with the HTML tags. I’d rather re-wrap after making changes. It’s the way I’ve done things since the first DOS editor I ever used, back in 1990. So I changed that file. Opening it in an editor, I used the peculiar Vim way of commenting out that (inserting a double quotation mark) and the next few lines which set those formatting options:

"setlocal formatoptions-=t
"if !exists("g:ft_xml_autocomment") || (g:ft_xml_autocomment == 1)
" setlocal formatoptions+=croql
"endif

I saved the file and test Gvim and all is now working as I like it.