geek + red sox + cooking = peter ryan

In Ubuntu I accidentally tried connecting to a wireless network. After that every time go near it now the Gnome network manager would connect to it. There is no handy way that the manager lists of “allowed” networks can be managed. After some digging I found the solution - removing a directory that made it “preferred” and restarting networking. After that the manager no longer did an auto connect.

cd .gconf/system/networking/wireless/networks/
ls
rm -rf <essid>


After a few weeks of trying Compiz Fusion on my Kubuntu Gutsy laptop I have returned to using the standard KWin window manager. My reasons for this were:

• Buggy decorators. After running for a short period of time with compiz the windows decorators (maximum, minimize, close, resize, etc) stopped appearing.
• Tray icons not loading correctly. When I booted my laptop and immediately logged in a few of the system tray icons (PowerManager for one) would not load in the tray but instead be running on the top left of the screen. Restoring to kwin would cause this issue to go away.
• Occasionally on login the keyboard would not be functional. This was resolvable by logging out with the mouse and logging back in.

Overall I liked the effects but couldn’t handle the issues and not being a kde developer didn’t feel like sifting through bug reports and trying to tinker with the window manager. I setup my compiz fusion configuration according to the help.ubuntu.com’s instructions.

Today I was experimenting with Advanced Desktop Effects for Kubuntu Gutsy. I set them up easily enough. I first removed everything I had installed before (legacy beryl) and reinstalled CompizFusion according to the ubuntu help documentation.

Everything installed fine but I ran into a troubling issue. I was looking at the list of activated plugins and trying to get a handle on everything (including what the super key is…I still have no idea but I’ll figure it out soon enough) and after playing with the “Move window plugin” which was tied to ALT-F7 I said “that is cool but I’ll never use it…I’ll just drag the window around with my mouse” and disabled it.

Anyway that behavior was opposite of what I was expecting. The compiz desktop effect was also the base move window action so disabling it made it impossible to move any windows at all. I re-enabled it and moving windows (with the mouse) once again worked as expected.

I suspect that other effect “plugins” behave similarly so when playing with desktop effects be careful what you disable! IMHO a window manager’s core functionality includes things like “move window” “resize window” and treating them like plugins as opposed to core elements is an extreme that could lead an unaware user down a road that disables features that one might view as critical. That said there are things like “Application Switcher”, “Ring Switcher”, and “Shift Swticher” all of which are different ways to switch between windows. So I guess one could deliver an alternate “Move Window plugin.”

At some point after I completed my Feisty to Gutsy upgrade I discovered that whenever I ran a perl module (whether it was when I was reinstalling vmware or running aptitude) I received the following warning:


perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


I ran across the following ubuntu forum thread and executed the following two commands to clean up the broken locale:


sudo locale-gen
sudo dpkg-reconfigure locales


That resolved the issue and the perl warnings disappeared when I ran aptitude again as a smoke test. I am not sure what could have caused this corruption as the thread is dated. The issue might not be gutsy upgrade related but it is likely the culprit as I have done little on my machine in terms of config changes beyond it.

After I completed the upgrade to Kubuntu 7.10 Gutsy Gibbon I realized my Automatix installation was broken. Since I had installed Automatix to get an easy Thunderbird 2 upgrade I said to myself “no big deal” and removed it from my system. This didn’t cause me too much of a worry until I ran an aptitude show thunderbird to see what happened to the automatix package.

I wasn’t comfortable returning to Automatix - I have gotten to the point where I am trying to keep my sources.lst as clean as possible to make upgrades simpler. However without Automatix, I discovered that the package was for all intensive purposes lost. I could run thunderbird but aptitude had no idea it was there and I figured at that point my upgrade path was not so clear. I set about to uninstall it manually and after reading a couple posts on how best to accomplish this I did the following:

sudo rm /usr/bin/thunderbird

This removes the link to /usr/bin.

sudo rm -rf /opt/thunderbird

Automatix Thunderbird 2 was installed in this directory. A nice way to perform an install since files are not trickled all over the place.

sudo rm -rf /etc/thunderbird

There was nothing really in this directory but I noticed it and I deleted it.

sudo rm /usr/share/applications/thunderbird.desktop

Remove the Icon from my KDE Menu

At this point as far as I could tell Thunderbird was uninstalled. Performing an aptitude search thunderbird revealed no installed thunderbird packages. I completed my migration back to a proper ubuntu package by installing the default thunderbird package (which in Gutsy is Thunderbird 2).

sudo aptitude install thunderbird

This restored Thunderbird and my Thunderbird 2 was now back to an official Ubuntu package.

I completed the upgrade from feisty fawn (4.10) to gutsy gibbon (7.10) over the weekend. There were a few issues - the upgrade hung during the installation of a package and I had to resume it manually using dpkg. This was not really much of a big deal - the same thing happened when I upgraded from edgy.

However today I was sliding my mouse over the KDE Power Manager and I noticed that the CPU Frequency only displayed one processor. Given my Dell D620 came equipped with a duo core processor I took immediate notice. Inspecting /proc/cpuinfo revealed the issue wasn’t with the PowerManager but rather in the CPU detection being performed by the kernel.

It turned out that during the upgrade a 386 kernel was installed and made the default. The 386 kernel lacks duo support (I believe) based on a few things I read on the topic. I rebooted into the generic kernel and the Power Manager displayed the two processors.

After determining that was the problem I removed the 386 kernel from my system which fixed my system to use the correct generic kernel as that was the next one on the list.

I am not sure why the upgrade process nixed the cpu detection but given the ease of the fix not something I will dwell on much. It could have been caused by my interrupted upgrade, the fact my kernel had been patched for vmware, or something wrong with the upgrade process itself.