How to remove the close button from your tabs in Firefox

Do you use Mozilla Firefox?

Do you hate the presence of the close buttons on tabs?

Do you want to hide the close buttons on tabs? 

I really do.  I use Tree-style view and they waste a bunch of space.  Stupid close buttons!  So, go to about:config, filter for the property browser.tabs.closeButtons, and change its integer value from 1 to 0.  This way, it will only display the close X button on the tab you are on.

Yay!

Xephyr

Running Fedora 11?  Running into an X11 crasher bug that you can reliably reproduce but don't have the hard iron to run all of X in gdb?  Perhaps like this one when you click on the Gimp's canvas and see X flash before your eyes?

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812d07b]
1: /usr/bin/Xorg(xf86SigHandler+0x9e) [0x80c061e]
2: [0xdf0400]

Fatal server error:
Caught signal 11.  Server aborting

Perhaps the bug is equally represented in Xorg and Xephyr.  In which case, you can probably run Xephyr from your desktop

Xephyr :1

with :1 to denote which display it should take (:0 should be in use by your session already).

Then, run which apps you need to inside Xephyr to reproduce the bug.  (e.g. the Gimp). 

You can tell them which X server to appear in by setting the DISPLAY variable like so

DISPLAY=:1 gimp

Now, right before you cause the Xephyr X server to crash,  run gdb on it

gdb --pid=`pidof Xephyr`

You might not have the debuginfo files installed, which you'll want to be able to trace through the human-readable source code.  gdb should prompt you with a command for any relevant, missing debuginfo.  Note that, on Fedora 11, you'll also need librpm.so available for it to do this (provided by rpm-devel).

Once you have the symbols loaded and gdb connected to your Xephyr process, tell gdb to "continue", and now reproduce your crasher.  gdb should catch the segfault (or signal SIGSEV or something).  Then you can get a backtrace ("bt") from gdb and start finding out where you are.

After that, I tend to restart Xephyr, reconnect gdb, and "break" at the names of functions where the crash happens, and then start "step"ing and "next"ing through, "print"ing the variables whose values I want to see until I find out why I'm crashing. 

RH bug 505823 will let me know if this was at all useful.

Unable to open "librpm.so"? Perhaps rpm-devel is missing.

In Fedora 11, are you getting something like this when using gdb when you're missing some debug info files? 

Unable to open "librpm.so" (librpm.so: cannot open shared object file: No such file or directory), missing debuginfos notifications will not be displayed.

I was, and it meant that gdb couldn't suggest which package I had to debuginfo-install to get the
misisng debug information and symbols.

I did a locate for librpm.so and found librpm.so.0 and friends in /usr/lib.   Guessing that's where librpm.so was supposed to be, I did "yum whatprovides /usr/lib/librpm.so" and that told me rpm-devel-4.7.0, which I then installed.

After that, I ran gdb on the process I wanted to inspect again, and ta-da, I am finally told the name of the package which I need to install to get my debugging symbols.  Copy, paste, yay. 

DJ Aqua

A plugin for Rhythmbox to have Speech Dispatcher announce a track's artist and title before and after play. The code, finally available.