Weird Caja Bug

In the past day or so I've tripped over a rather annoying bug in Caja, the file manager for the MATE desktop (which I use with Linux Mint, and which is also used by many Ubuntu users). Theoretically, the F2 key is a shortcut for Edit > Rename..., which lets you rename selected files. Usually, it works fine, but today (and at least once in the recent past) the F2 key had no effect.

At first I thought there was a problem with my keyboard, but no, the F2 key was being recognized. A Google search led me to a bug report from 2018 (!) where a diligent soul with screen name "terzag" discovered that the problem occurred when the Caja window displayed a vertical scrollbar and disappeared when the window was resized large enough to lose the scrollbar. Sure enough, that fix worked for me today ... and then things got weirder.

I did a little experimenting, and the bug reappeared when the scrollbar reappeared and disappeared whenever the scrollbar disappeared. Then I tried F2 with multiple file icons selected (which opens a dialog to bulk rename them), and it worked, despite there being a visible scrollbar. Since then, no matter how many times I close and reopen Caja, the bug does not manifest. So it is temporarily fixed, I guess, with emphasis on "temporarily".

I also encountered a possibly related bug, again reported years ago. If I hit either F2 or Edit > Rename... without first selecting one or more files, it closes (crashes?) all open Caja windows. I'm pretty sure that's a bug and not a "feature".

Hopefully this all gets fixed relatively soon ... although looking at bug reports from almost five years ago does not make me feel sanguine about the prospects.

rJava: The Gift That Keeps On Giving

I've written not once but twice before (in 2011 and 2015) about the hassles of getting the rJava package to work with R. Every time I think I have a fix for it, someone changes something somewhere and the previous fix no longer works. I had to reinstall rJava today (from the Canonical repositories) after a system upgrade on PC. So, naturally it declined to work.

The symptoms, in both R terminal sessions and when running RStudio, were the same as in 2015. Executing library(rJava) in an R session earned me an error message containing the same nugget

libjvm.so: cannot open shared object file: No such file or directory

as before. Executing Sys.getenv(c("JAVA_HOME", "LD_LIBRARY_PATH")) showed me that the proximate cause was the same as in 2015: the library path was missing the "/jre" piece near its middle. So, same problem implies same cure, right? Wrong! The paths in /usr/lib/R/etc/ldpaths were correct; they just were not working as expected.

The key lines in  /usr/lib/R/etc/ldpaths were as follows.

: ${JAVA_HOME=/usr/lib/jvm/java-8-oracle/jre}
: ${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server}

They look correct, but apparently they are only executed if the corresponding environment variables (JAVA_HOME and R_JAVA_LD_LIBRARY_PATH) are not already defined. I suspect this is due to the colon at the start of each line, but I'm no expert on BASH syntax. You can test this in a terminal by running something like the following: execute

JAVA_HOME="silly" R

at the terminal prompt (which temporarily resets the JAVA_HOME environment variable to something, well, silly), and in the R session execute

Sys.getenv("LD_LIBRARY_PATH")

which prints a path whose Java portion starts with "silly".

The source of the predefined value of JAVA_HOME, at least on my system, is /etc/profile.d/jdk.sh, which contains the following lines.

export J2SDKDIR=/usr/lib/jvm/java-8-oracle
export J2REDIR=/usr/lib/jvm/java-8-oracle/jre
export PATH=$PATH:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin
export JAVA_HOME=/usr/lib/jvm/java-8-oracle
export DERBY_HOME=/usr/lib/jvm/java-8-oracle/db

One solution would be to append "/jre" to JAVA_HOME in that file (making it identical to J2REDIR), but that has two problems. The first is that whatever installer created /etc/profile.d/jdk.sh is likely to overwrite the change the next time the installer is run. The second, potentially more serious, problem is that JAVA_HOME is presumably being set to its current value for a reason. Changing it might have unforeseen consequences with another program.

So my "solution" (hack) is to modify one line in /usr/lib/R/etc/ldpaths as seen below.

## : ${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server}
: ${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/jre/lib/amd64/server}

That's still subject to being overwritten by an installer in the future, but at least it only affects R (and it works).

Oracle Java 8 Update

For quite a while, I was getting security nags from Firefox every time a web site wanted to run a Java applet. Firefox would tell me I needed to upgrade to the latest version of Java. That would have been fine, except that I was already running the latest Java (1.8.0_66 as of this writing). I manually downloaded and installed the SDK (which includes the JRE). So apparently there was something about the installation that was confusing Firefox into using an earlier version (?).

Anyway, long story short, I found a PPA from the ever helpful folks at Web Upd8 that makes it easy to get the installation correct, at least on Ubuntu and derivatives (including Mint). The PPA installs a package that downloads the binaries from Oracle, installs them, makes them the defaults etc.

On an unrelated note, this was not the post I started to write. I enter the math notation in this blog in LaTeX and rely on MathJax to translate it to MathML for browsers that understand MathML (Firefox being one). I noticed a week or so ago when viewing an old post that Firefox was inserting copious unnecessary (and unwanted) vertical space on either side of any line containing math, whether the math was "inline" or "display mode". Horizontal spacing was fine; only vertical spacing was munged. Checking around, I found that (a) it was happening on every page with MathJax content, not just on my blog, (b) it depended to some extent on which font was being used (with the XITS font, no extra space was inserted), and (c) Google Chrome was unaffected. So it appeared to be something involving the combination of Firefox and specific fonts. I did some research on Firefox extensions and was literally half way through typing up a post with a solution when, by chance, I discovered that the problem apparently went away. I don't know what changed, but suddenly Firefox is getting the vertical spacing correct again.

So my new tool for all technical problems is to write half a blog post about them and then see if that is enough to cure the problems. :-)

The rJava Nightmare

I like R. I like Java. I hate the rJava package, or more precisely I hate installing or updating it. Something (often multiple somethings) always goes wrong. I forget that for some reason I need to invoke root privileges when installing it. It needs a C++ library that I could swear I have, except I don't have the developer version of that library installed. Whatever. See this post from 2011 for a previous misadventure.

Today's battle was fought after a "successful" installation on my laptop. The good news: the package was installed, and RStudio knew it was installed. The bad news: neither RStudio, nor R run in a terminal, would let me load it. The key nugget in the error message:

libjvm.so: cannot open shared object file: No such file or directory

Now libjvm.so was definitely installed (as part of Oracle Java 8), so this was a matter of somehow breaking the news to R and/or RStudio. Search for "rJava" and "libjvm" on Google and you'll find a lot of hits, because I'm apparently not the first person to trip over this. Most solutions involving adding the requisite directory (which for me is ${JAVA_HOME}/jre/lib/amd64/server) to the LD_LIBRARY_PATH environment variable in your .profile file. I tried both that and .bashrc, with the result that R in a terminal agreed to load rJava but R running in RStudio still did not. Some of the posts I found said that this was expected if you made the tweeked .bashrc, but tweaking .profile instead was supposed to fix things. Except it didn't.

Fortunately, my laptop and desktop both run the same OS (Linux Mint), pretty much the same version, and rJava was working fine on the desktop. So the trick was to figure out how they differed. The route to libjvm.so does not appear in LD_LIBRARY_PATH on my PC, and is not mentioned in either of those profile files. It turns out that the path is set in the profile for R (/usr/lib/R/etc/ldpaths, to be specific), in the definition of a new variable R_JAVA_LD_LIBRARY_PATH. On the laptop, that was set to ${JAVA_HOME}/lib/amd64/server; on the PC, it was ${JAVA_HOME}/jre/lib/amd64/server. The latter path is correct on both the PC and the laptop. So I edited ldpaths on the laptop (as root), inserted the missing piece of the path, and lo and behold both R in a terminal and R inside RStudio could execute "library(rJava)" without bellyaching!

Note that, per my 2011 post, I had run sudo R CMD javareconf (more than once), with the correct value of the JAVA_HOME environment variable in place. Why that did not fix the path in ldpaths, and why the path was wrong in the first place, remain mysteries to me.

Update (12/30/16): I ran into the same problem, with a somewhat different cause. Updated details are in this post.

Updating Adobe Flash

Within the past week, give or take, Firefox started blocking the Adobe Shockwave plugin from running in web pages, due to a security problem with it. I could (and did, when I trusted the site) override the warning, but in general bypassing security is a bad idea. Even when the site is trusted, you have to consider the possibility that someone managed to sneak a malicious Flash application onto it.

I was initially happy to upgrade the bugger (to version 11.2.202.425, which I think is the first one Firefox will allow), but the universe conspired to make that ridiculously difficult. I'm running Linux Mint 16 Petra, which is plumbing-compatible with Ubuntu 13.10 Saucy Salamander. Shockwave is packaged for Ubuntu, not for Mint.

The "Plugins" tab of the Firefox Add-ons Manager flagged Shockwave and gave me a link for updating. That link took me to an Adobe page where I selected which Linux release of the latest version I wanted. I was hoping it would then download a .deb package file, but nooo, it gave me an "APT link", to which I needed to associate an application. Fortunately, I had AptURL installed, so I just had to point to it (in /usr/bin/apturl). Unfortunately, it did not work; I got a message about an unknown channel. So I was stymied there.

The Synaptic package manager was no help; it thought (incorrectly) that the version I had was the most recent. I added the Ubuntu Mozilla Security PPA, which has the latest version, as a source, but I still could not update.

I think I finally figured out what was causing all this wasted effort. As best I can tell, Adobe skipped Ubuntu 13.10 when they released 11.2.202.425. The version they released for Ubuntu 12.04 (Precise Pangolin) also apparently works on 13.10 ... but the package manager either can't see it or won't use it, because it's for an earlier version of the operating system than what I have. At least I'm guessing that's the problem. The "unknown channel" error I got trying to update via the Adobe site named "Precise" as the channel, so apparently it was looking for the "Precise" version but the package manager wasn't having any of that.

I did eventually succeed, though, and I'll document it here in case any weary pilgrim stumbles on this page. You can find the AMD64 version of the installer package on the Ubuntu packages site. (If you need a different version, backtrack along the bread crumbs -- and good hunting!) The link on that page will download the installer .deb file. Right-click that file, open it with GDebi, click "Install", give the necessary password, and it will download and install the actual Flash player. Restart Firefox and check on the plugins page to verify that you have the up-to-date version.

This was a rather remarkable time-suck compared to most upgrades on Mint or Ubuntu. :-(

Automated Volume Reset in Linux Mint/Ubuntu

I've been watching course videos lately, which requires me to crank up the volume on my speakers of my Linux Mint PC (using the volume applet in the bottom panel of the display). Being absent-minded (a job requirement when I was a professor), I often forget to reset the volume after watching a video. I'll suspend or hibernate the machine, go off to do something else, come back and resume/thaw, and at some point get blasted out of my chair by an unexpectedly loud system sound. Today I decided it was time to fix this by automatically resetting the volume any time I resume from suspend or "thaw" from hibernation.

I've previously described how to create a script to reset the volume. It turns out that running it at resume/thaw is a bit tricky. There are a number of forum posts on how to run a script at resume/thaw, but the standard solution did not work in this case. I believe the problem was that PulseAudio (the audio system) was running in my user session, whereas the script (being run as the root user) was looking for it in the root user's session and not finding it. The solution involved both baking in a short delay (to ensure that PulseAudio had restarted before trying to control it) and running the volume reset script as me, rather than as root. Adding to the confusion: the usual way to run as someone else, in this case

sudo -u paul ..., did not work (and I'm not sure why, but I'm pretty sure it's tied to whose environment is in use).

Cutting to the chase scene, here is the solution. The script to reset the volume (see the previous post) is /home/paul/Scripts/resetVolume.sh. I created a wakeup script by doing the following in a terminal:

  cd /etc/pm/sleep.d
  sudo touch 00_reset-volume.sh
  sudo chmod +x 00_reset-volume.sh
  sudo gedit 00_reset-volume.sh

There is nothing sacred about the name (00_reset-volume.sh) I used, but the "00" prefix should help ensure that it runs late in the resume sequence (giving more time for my user session to be reloaded, including the PulseAudio daemon).

The contents of 00_reset-volume.sh are as follows:

#!/bin/bash
case "$1" in
  thaw|resume)
    sleep 10 && su -c - paul /home/paul/Scripts/resetVolume.sh
      # wait 10 sec. for PulseAudio to restart
    ;;
  *)
    ;;
esac
exit $?

The 10 second delay before running my volume reset script may not be necessary, but it works, and if it ain't broke, don't fix it. su -c - paul ... runs the script as me rather than as root, apparently using my environment.

Mint Petra Odds and Ends

As I complete (hopefully) the upgrade of my home PC to Linux Mint 16 Petra (which appears to be commensurable with Ubuntu 13.10 Saucy Salamander), I'm making notes on glitches small and large.

• I initially had some display problems booting and resuming from hibernation. By "display problems" I mean totally corrupted displays, or what appeared to be hang-ups during the boot process. This is not the first time I've experienced display problems of this nature. So I reinstalled the sgfxi script (this time to my home partition, where it should survive future system upgrades, and ran it. Since installing the latest NVIDIA proprietary drivers, I've had no boot failures. The display is still sometimes a bit slow redrawing itself, something I'll need to investigate when I have time.
• As noted in my previous post, Petra has the annoying habit of opening the Disk Usage Analyzer (a.k.a. "Baobab") when it ought to be displaying a folder in Nemo, the replacement for Nautilus. The fix (in the second update of the previous post) is to add
  

  inode/directory=nemo.desktop;baobab.desktop;

  to  ~/.local/share/applications/mimeapps.list. 
• Back in June, I posted about using the µswsusp package to accelerate hibernation and return from hibernation. Unfortunately, while the package seems to work as far as saving a compressed image to disk, Petra is unable to return from hibernation. I get a message that it is "Resuming from /dev/disk/by-uuid/you-don't-want-to-know", and I get to stare at that message for as long as I want before rebooting the machine. So I uninstalled µswsusp. Fortunately, Petra seems to be faster than Nadia was at both hibernating and (more importantly, at least to me) resuming. If I need to bring back µswsusp at a later date, the answer may be here (change the configuration file for µswsusp so that "resume device" is set to the UUID of the drive rather than its name). [Update: No joy. I reinstalled µswsusp, confirmed that it hung on resume, edited its config file to use /dev/disk/by-uuid/you-don't-want-to-know as the resume device, ran update-initramfs -u (as root), and it still hung on resume. Apparently I need to give up on µswsusp.]

• While messing around with the hibernation stuff, I periodically encountered a message "No support for locale en_US.utf8". This seemed harmless enough, but I decided to do a quick search, and turned up clear instructions (albeit for an older version, Mint 13) on how to fix it. Running

sudo locale-gen --purge --no-archive

hopefully fixes it.

Updating JabRef

I rely on JabRef to created and edit bibliographic databases (for use with BibTeX in LaTeX documents). For whatever reason, the supported version in the Canonical repositories for Ubuntu (and Linux Mint) is lagging further behind than is usual for the repositories (which is saying something). The current stable version (as of this writing) is 2.9.2, while the current beta version is 2.10 beta 2. The "official" version in the repositories is 2.7 beta 1, which I estimate to be between 12 and 18 months old.

I looked around for more current Debian packages but ultimately decided the easiest way to update is manually. Most of the files from the official version do not need to be changed. Here are step-by-step instructions for installing a new version. They worked for me and should work for anyone else using a Linux distribution that employs the Debian packaging system. I assume here that you already have the "official" version of JabRef installed. Do not uninstall the old package, since we're going to retain a lot of its files.

1. Download the latest version (stable or beta, your choice) from the SourceForge project page. Henceforth I will refer to the file (whose name should be JabRef-<version information>.jar) as <new jar>.
2. Open a terminal in the download directory.
3. Run the command

   sudo mv <new jar> /usr/share/jabref

   which will install the new version in parallel with the old one.
4. Optional but recommended: run

   java -jar /usr/share/jabref/<new jar>

   just to make sure the downloaded version works. Once you're sure it works, exit JabRef.
5. Still in the terminal, run the commands

   sudo rm /usr/share/java/jabref.jar
   sudo ln -s /usr/share/jabref/<new jar> /usr/share/java/jabref.jar

   This switches the version of JabRef being executed from the old one to the new one.
6. Test JabRef by running it from the application menu and/or by double-clicking a .bib file.
7. Optional: run

   sudo rm /usr/share/jabref/<old jar>

   to delete the old version. 

I'm not sure whether Synaptic will identify JabRef as a "broken" package as a result of this. We'll see.

Selecting the Default Application for a File Type

In Linux Mint (and Ubuntu, other Linux distributions and various competing operating systems), it is frequently possible to open a data file in an appropriate program by double-clicking the icon for the file, either on your desktop or in a file browser. This is handled by associating the file's extension (which Linux treats as a MIME type) with the corresponding program. In Linux, the association is done by the file manager. The distributions I've used in recent years (Ubuntu and Mint) have been based on the GNOME desktop, which in turn uses the Nautilus file manager.

Many programs set up file associations at the time you install them. For example, the LibreOffice productivity suite associates itself with OpenDocument file extensions (.odt etc.). Many programs, however, do not do that automatically; in some cases, it is because they claim no specific file extensions. In those cases, Nautilus offers the option to right-click a file of the desired type (extension), click Properties > Open With, select the application (clicking Show other applications if necessary to find it), and Add the application to the list of default choices for that file type.

This works fine as long as Nautilus lists your application of choice. I ran into a problem with that today. I was trying to make SQLite Studio the default application to open files with the extension .sqlite. (Incidentally, if you are looking for a program that will let you create, browse and modify SQLite databases, I definitely recommend SQLite Studio. It's available on Linux, Mac OSX, Windows and a few other operating systems.) Unfortunately, it did not appear on the application list when I clicked Show other applications. This appears to be the result of a bug in current versions of Nautilus.

Two things are necessary to have your application display in the list. First, there needs to be a .desktop file for it, typically residing either in /usr/share/applications or in ~/.local/share/applications. In my case, the .desktop file already existed: I had added SQLite Studio to the start menu, which automatically creates a .desktop file in the latter directory. So why was it not appearing on the list??

After considerable searching, I found the answer here: the command line must end with "%u" (which is the placeholder into which Nautilus will insert the name and path of the file to be opened). I suppose this makes sense in hindsight; without that placeholder, the user might be selecting an application that does not accept a file to open as a command line argument. Still, I would have thought Nautilus would just append the file name to the command line, with or without the placeholder.

You can add the placeholder either by editing the .desktop file directly, in a text editor (append it to the "Exec=" line) or by right-clicking the start menu, selecting Edit Menu, finding the application, clicking Properties and editing the Command field. Once you have a .desktop file containing the "%u" placeholder, the application should appear on the Nautilus list of available applications.

Resetting Speaker Volume in Mint/Ubuntu

Okay, you have to promise not to laugh or make "old guy" cracks here. I keep the master volume on my Linux Mint PC cranked fairly low (between 40% and 45% of maximum) because I have powered speakers (and reasonably acute hearing). When I watch YouTube videos, I usually have to crank the volume up a bit. When the video is on the long side (think slide show or lecture rather than cats mugging for the camera), I often (usually?) forget to crank the volume back down again. Mint remembers the volume, so the next time I log in I get blasted by the log-in chime. If I'm not sitting at the PC when the desktop comes up -- and frequently I'm off getting a cup of coffee or doing some chore while it boots -- I'll forget to reset the volume, and eventually get blasted by some other sound.

So here's a partial fix, a script that resets the volume on log-in.

1. In a terminal, run pactl list sinks to get a list of output devices controlled by the PulseAudio driver. Note the device number for the device that handles your speakers. (In my case, the only entry is device #1.)
2. Using your favorite text editor, create a script file (mine is named resetVolume.sh) in a directory of your choice (~/Scripts for me). Putting the script somewhere in your home directory should keep it safe from being lost during system upgrades. Put the following two lines of code in the script file:
   

   #!/bin/sh
   pactl set-sink-volume 1 45%
   

   Change 1 to whatever device number you obtained in the first step and 45% to whatever volume setting you want. Note that the pactl command seems to suffer some rounding errors when it does volume changes; this script actually sets my volume to 44%, according to the panel audio control applet.
3. In a terminal, run chmod +x ~/Scripts/resetVolume.sh (changing the path and file name as appropriate) to make the script executable.
4. Test the script: use the panel audio applet (or whatever mechanism you normally use to control volume) to crank the master volume up or down, then run the script in a terminal and verify the volume resets correctly.
5. Find Startup Applications in the system menu (the easiest way is to search for it by name) and run it. Click the Add button and create an entry for the script.
6. Test once more by screwing with the volume setting and then logging out and back in.

The one drawback I've found to this is that the volume reset takes place after the startup chime sound has begun playing. So the initial auditory assault is not entirely avoided, but at least I've averted any future ones for that session.

UPDATE: I apparently declared victory prematurely. The script seems to run fairly reliably when I log out and log back in, but if I shutdown and restart, or reboot, it does not work. I switched from the pactl command to the pacmd command, but that did not help. I added a line 'sudo alsactl store' to reset the stored volume (and added the script to the sudoers file), but that did not help. I linked the script from /etc/rc0.d and from /etc/rc6.d, so that it would run when shutting down or rebooting, and confirmed that the script did indeed run; it just did not reset the stored volume. (I named it both K99resetVolume, so that it would run late in the shutdown sequence, and K00resetVolume, so that it would run early, but no joy either way.) My suspicion (and it's just a suspicion) is that there's a timing issue, with the script perhaps failing because alsa and/or pulse-audio is not running at the time the script executes. In any event, I'm at a loss how to get it to run properly.

UPDATE #2: Another day, another failure.  This time I symlinked the script in /etc/X11/Xsession.d, so that the script would run when the X system started after login. I gave it a name starting with "99z", which I think would make it the last script to run during the X start. Once again, the script ran but failed to affect the audio volume.

[SOLVED] UPDATE #3: I fixed this a while back and apparently forgot to update this post. The script that works for me is as follows:

#!/bin/sh
#
# There seems to be some inconsistency about whether the sound card
# is sink 0 or sink 1, so hit them both just to be safe.
#
pacmd set-sink-volume 0 27500
pacmd set-sink-volume 1 27500
sudo alsactl store

It will generate a harmless warning message because one of the two sinks (0, 1) will not exist when the script runs.

A GEdit Headache

What should have been a simple task just ate an hour of my life (and, trust me, the marginal value of an hour of your life is an increasing function of age). I'm trying to compare two parts of a text file, and I wanted to use a split view in gedit. That's not a feature of gedit, so I sought out and found a plug-in, GeditSplitView, that should do the trick. I downloaded it and installed it to ~/.local/share/gedit/plugins (after creating ~/.local/share/gedit and the child plugins folder). That I had to create the folders was a bit surprising, as I was sure I'd previously created them for a different plug-in (now gone missing). I keep my home folder tree on a separate disk partition from everything else, so upgrades (such as my recent installation of Mint 14 Nadia over Mint 11 Katya) should not disturb anything in the home folder. Well, whatever.

After installing the plug-in, I restarted gedit - and discovered it was not seeing the plug-in. Hmm. As an experiment, I installed the gedit-plugins package (a set of optional plug-ins) from the Ubuntu repositories, using Synaptic. Gedit didn't see those, either, which sent me off on a fruitless expedition of web searching.

It turns out the problem is simple, if not intuitive. There was a change in plug-in formatting (and naming conventions) between gedit 2.x and gedit 3.x. The GeditSplitView plugin requires gedit 3.x. That brings me to the daffy (to me) part. Mint, as it installs itself, uses the Ubuntu 12.10 "Quantal Quetzal" repositories. (Mint is a fork of Ubuntu.) It lists version 3.6.0-0ubuntu1 as the current version of gedit-plugins (which is what I installed unsuccessfully) ... but it comes with gedit 2.30.4-ubuntu1 (and the corresponding version of the gedit-common package) preinstalled, and lists those as the current versions. So it's giving you incompatible versions of gedit and gedit-plugins as defaults (and lists no other options).

Once I sorted that out, a quick search turned up instructions on how to uninstall gedit 2.30 and install gedit 3.6.1 in its place. After that, I was able to install GeditSplitView easily, and gedit had no trouble finding it.

Boot Bug: Anniversary Edition

A year ago July, I ran into a problem in which my AMD-64 Mint Katya system started to hang on boots. As noted in that post, the problem stemmed from messing with the video settings for the boot loader. Reinstalling the nVidia display driver might or might not have helped eliminate the problem, but eventually it sorted itself out.

A month later, I ran into a second problem linked to the nVidia driver, in which the X server decided to spontaneously reboot on occasion. I got rid of that problem by using the sgfxi script to update to the latest version of the nVidia driver.

Do gremlins celebrate anniversaries? Slightly over one year after fixing the second problem, the first one came back. It started when I tried to run a program that crashed because it could not find a way to do XGL hardware graphics acceleration. That led me to the Additional Drivers dialog in the Control Center, where I discovered that the proprietary nVidia driver was not selected. As it turns out, that's probably because the Control Center sees the one the operating system installed but not the newer one that the sgfxi script installed. I'm not sure that either version was running, though, since both should provide XGL.

Anyway, I decided to turn on the proprietary driver in the Additional Drivers dialog. When I rebooted, the machine hung at the battery test stage. (Note to self: if this happens again, do not turn on the proprietary driver. Get out of X and run the sgfxi script.) I could boot into safe mode, but no way could I boot regularly (despite repeated attempts). Safe mode worked, but it used too low a resolution, with the desktop off-center (left edge cut off, blank screen on the right), and I could not change the resolution. In Control Center > Monitors I discovered that the system could not detect what kind of monitor I had, so it gave me a wimpy default choice that I could not edit.

Eventually I booted into safe mode, went back to Additional Drivers and discovered that I now had a new option: an "experimental" driver. This was the nouveau driver, which I selected. With the nouveau driver, I could boot normally and get to the desktop, but the resolution was still wrong, and the desktop was still off-center. So I switched back to the nVidia driver, and the next boot predictably hung.

I booted into safe mode again, but this time I selected the option to repair packages, thinking perhaps one of the X packages was damaged. That was apparently not the case, but it did remind me that I had seven updates I had not installed. These were updates to the Linux core, including the X system. Normally I don't install those updates because I like to upgrade to a new version of the entire system at once. This was not a normal time, though (particularly as it was getting on 1:30 in the morning), so I let the system install the updates and rebooted again ... and everything worked. Mint automatically detected my monitor correctly, the resolution was set correctly, everything was back the way it had been.  As an added bonus, the nVidia driver was being used, and the program that triggered this whole cluster worked correctly. Woo-hoo!

I subsequently ran the sgfxi script, and sure enough I was on a one-iteration-old nVidia driver. I let the script upgrade me to the latest version, and everything still seems to work properly.

There won't always be a core update waiting to bail me out, so I guess the solution process next time (a year from now?) will be as follows:

1. Try the sgfxi script.
2. If that fails, see if there's an update to any of the X packages that can be installed. If not, try reinstalling the X system.
3. If that also fails, swear mightily and see if there's a new version of Mint I can download.

Updating Java on Mint (and Ubuntu)

For various reasons, including compatibility issues with some third-party programs and a need to generate cross-platform code on occasions, I routinely use Sun (now Oracle) Java on Linux systems, rather than GCJ (which is frequently included in Linux distributions). Following a suggestion in a recent email from the folks at Mozilla, I checked my Firefox plugins and discovered a security warning for the Java 6 plugin. I'm not sure if I could upgrade just the plugin, using the Java 7 browser plugin while still using the Java 6 JRE (runtime environment) and the Java 6 JDK (development kit); so I decided to upgrade everything to Java 7. Small problem: the Ubuntu repositories still contain version 6 and not version 7.

A quick search turned up a blog post at Web Upd8 which explains why the official repositories lag behind:

Oracle JDK7 itself is not hosted in the PPA because that's not allowed by the new Java license (which is also the reason why it has been removed from the official Ubuntu repositories); the package in the PPA automatically downloads (and installs) Oracle Java JDK 7 from its official website and installs it on your computer, just like the flashplugin-installer package does.

The PPA (personal package archive) repository to which they refer contains a package that automatically downloads and installs the current version of the Oracle Java 7 JDK. (Note that there is no comparable package to install just the JRE; you have to install the full JDK, which contains the JRE as a subset. That's fine with me, since I need the JDK for program development.)

The instructions are straightforward and worked fine for me. Once I had confirmed that Java 7 was installed and was the default choice, there was one more step. I use the Netbeans IDE for writing Java code. I could have installed the latest version with Java 7 bundled, but that's a hefty download, and my current version of Netbeans is recent enough. In Netbeans, I clicked Help > About and discovered that Netbeans was still launching with Java 6. The solution is to edit the configuration file <netbeans>/etc/netbeans.conf (where <netbeans> is the top directory of the Netbeans installation) and change the setting for netbeans_jdkhome to point to the Java 7 directory. When I restarted Netbeans, it launched with Java 7 and also changed the default Java platform for compiled code to Java 7.

Big thanks to the PPA maintainers for simplifying the process.

Installing Mythbuntu with WinTV-DCR

A few years back, I bought a tower PC with Windows Vista Media Center (home version) and a tuner card built in.  I've used it almost exclusively as a personal video recorder. For a variety of reasons, Vista has increasingly gotten on my nerves, so I finally bit the bullet and replaced it with MythTV.  The process has taken much longer than I expected, partly due to dopiness on my part, partly due to sketchy instructions here and there (or presumptions that I know things I do not). Herein I chronicle some of the details in case they'll help anyone else. It will be a long post, as it was a long process.

I should note a few more things about my equipment before diving in. I am a Comcast cable customer. I run the incoming cable through a splitter, with one connection to the TV (flat-screen HD) through a set-top cable box and the other to the tuner card in the PC. The PC has an NVidia graphics card (the precise model is, I think, irrelevant) that connects to the TV via an HDMI cable.

The tuner in the PC can only capture analog channels (NTSC), and Comcast is moving more and more channels to digital. So part of the motivation of trying out MythTV was that I needed to install a new tuner in any case. After a little online shopping, I settled on a Hauppauge WinTV-DCR (model 2650), a dual-tuner CableCARD receiver that connects to the PC via USB. The 2650 is not explicitly recognized by MythTV, but according to multiple success stories by other people, you can falsely identify it as an HDHomeRun Prime and it will work fine with MythTV.

As I've mentioned more than once, I run Linux Mint on various PCs and laptops, so I initially thought about installing Mint on my PVR machine and then adding MythTV. A couple of things I read online about complications, coupled with the  discouraging thought of downloading a potentially large number of dependent packages via my slow DSL line, caused me instead to download Mythbuntu 12.04 (at the office, where speeds are much greater) and burn an ISO image to a DVD. Mythbuntu is basically Ubuntu with things deemed inessential to a media server stripped out and MythTV added.

My initial thinking was to run Mythbuntu from the DVD, give it a test drive, then install it alongside Vista long enough to confirm that I liked it and to move my existing recordings over. Fortuitously, I took the precaution of copying almost all the recordings to an external hard drive before beginning the experiment. (The "almost" refers to one two-hour recording, approximately 5.3 GB, which could not be copied to the external drive. The issue was not lack of space; apparently the file was too large for the file system -- which might be FAT; I can't recall -- on the drive.)

Like other Ubuntu-based distributions, including Mint, you can boot from the CD or DVD, try out the system, and optionally install it. The test drive is useful to determine whether Mythbuntu correctly identifies and has drivers for your keyboard, mouse, display, network connections etc. In my case, this all worked fine, including installation of the NVidia proprietary drivers. For what it's worth, my keyboard and mouse are wireless, through a hub connect by USB. There was no problem with either of them.

I expected also to test MythTV itself, but as it turns out that cannot be done booting from the DVD. MythTV is a client-server system, so it comes with two parts, a front-end (client) and a back-end (server). You can test MythTV's front-end with a preexisting back-end, but if (like me) this is your first foray into MythTV, you will not have a back-end installed. No back-end, not test.

There was nothing for it but to install Mythbuntu. Mythbuntu initially gave me a screen with three choices, the first being to install alongside Vista. I chose that and took the default choice for disk partitioning. Shortly thereafter, Mythbuntu informed me that one of the partitions (it was not clear which; possibly the swap partition) was too small at the size it had selected itself and that I should back up and make it bigger. So I backed up and got what looked like the "how do you want me to install it" dialog again. Apparently I paid insufficient attention when I clicked the top choice, because this time the top choice was to wipe the old system and install just Mythbuntu. When I realized what it was doing (almost immediately) I ejected the DVD (the only way I could find to stop it), then reinserted the DVD and tried to restart the installation ... only to be told that the hard drive now had no system on it. To paraphrase Captain Keith Mallory, my "bystanding days" were over and I was "in it now up to [my] neck". A full install was on.

Thereafter, installation of Mythbuntu was quick and painless. There were 89 MB of updates awaiting me, which I deferred while I worked on the TV part. Physical connection of the WinTV was trivial (power cord, USB to the PC, attach the cable, insert the CableCARD).  The installation screen lets you select an IR remote if you have one. I do, left over from Media Center, and selecting the standard Media Center remote worked ... for a while ... more about that below. The WinTV comes with its own remote, but I thought it would be easier to stick to the MCE remote (to which I'm used) rather than figure out how to get the WinTV remote to work.

For the video device, I selected the NVidia driver. There were a couple of drop down boxes to configure "TV-Out". I wasn't sure whether that was necessary, but I figured probably not; the prompt starts "If you would like to configure TV-Out". So I stuck with the default settings, which seems to have worked.

MythTV itself started, and suddenly the mouse was gone.  My first thought was "how the heck do I navigate", but the keyboard arrow and tab keys worked fine. I later discovered this is a design feature, not a bug. When you are in a MythTV window, there is no mouse cursor. MythTV expects you to navigate via the remote. I wish I'd seen that somewhere before I launched into the installation, but no harm done. The remote worked fine to advance, retreat, select and cancel. At least it worked for a while (more to come).

In the video setup menu, I clicked the hi-def test button. It downloaded a 70+MB HD movie clip and played it successfully in the TV ... other than a lack of sound. The setup wizard theoretically allowed me to configure sound. I chose ALSA, but no joy. So I tried various other ALSA settings in the list (specifically those that mentioned NVidia), along with clicking the rescan button, and had no luck.

After a bit of searching, I exited MythTV, opened a terminal, and ran aplay -L, which showed me default:NVidia as a recognized sound device. That's what I'd hoped for, so I ran sound-test -Ddefault:NVidia -c 2 -t sine and heard tones in both of the TV's built-in speakers. (Sidebar: without the -t sine argument, you get "pink noise", which to me sounds like a bad connection.)

I then went back to the sound configuration screen in the front-end, and lo and behold the choice had changed, on its own, to ALSA:dmix:CARD=NVidia, DEV=0, and sound was working in MythTV. Maybe I forgot to try that one, or maybe my tests in the terminal somehow made the device more visible (?).

To configure the video source, I followed these instructions with minimal difficulty. I've had an account with Schedules Direct for a while, so my channel lineup was already configured. The one hiccup was that clicking Fetch channels from listing source repeatedly failed to do anything, until I realized that the CableCARD was not firmly seated in the receiver slot. (Paul slaps himself a few times.)

Pairing the device required a call to Comcast, in which I needed to give them three pieces of data: the card's serial number; a host ID, and a device (data) ID. The serial number was on the receipt I got from Comcast, but where to get the other two things? The back-end settings have a menu for Capture Card, in which I selected HDHomeRun Prime for each of the two tuners, and was given addresses for them and an IP address (on my home network, so a nonroutable address). This turns out not to be what Comcast wants. When you install the WinTV in Windows 7, the information is magically provided to you, but where would I find it in Mythbuntu? After a bit of searching, I indirectly stumbled on the answer. That IP address in the Capture Card screen was for a web server built into the WinTV. I opened that in a browser and it handed me the necessary information, including the serial number, on a silver platter. I called Comcast and in fairly short order had the card authorized (although they warned me it could take 45 minutes for the card to download all the channel information it needed).

Somewhere in the middle of this process I turned off the PC and went out to dinner. When I returned and booted the PC, the IR remote no longer worked! That's happened a second time as well. When I first observed this, I wasted considerable time searching for the source of the problem, playing with various remotes, and looking in the wrong places for where I could reconfigure it. (System > Control Center > Infrared is where I select the remote.) The lsusb command, run in a terminal, failed to show the remote being attached. As it turns out, unplugging the receiver's USB cable and then plugging it back in fixes the problem. I think I ran across some tweaks one can make in system files to eliminate the need to do that, and I will definitely research that tomorrow. I can't picture having to reseat the remote cable every time I wake the computer.

I have not yet tried to record anything, nor to import my Windows recordings, so there will probably be a follow-up post. Meanwhile, there are two pressing issues. One is fixing that bug with the IR remote. The other is to figure out why the first channel in my cable lineup (which happens to be ABC) is showing programming dubbed in Spanish (?!). All the other channels coming through the WinTV tuner are in English, and the one that is dubbed when viewed through the tuner is in English when viewed through the cable box.

Launching Windows Apps with Wine

Although I work almost 100% with Linux these days, I have a few Windows applications I find useful (including IrfanView for quick image edits and OCR -- much simpler, albeit less powerful, than GIMP) and PathSync for synchronizing local directories with my thumb drives. I also find PDF-XChange Viewer handy for adding annotations to PDF files.  All these programs run fine under Wine, with one small "gotcha".  When I install them (by downloading the Windows installer and then running "wine name-of-installer.exe" in a terminal), shortcuts to them are added to the Wine submenu of the GNOME menu ... but the shortcuts are often  dysfunctional.  They attempt to launch the Windows .lnk file added to the (virtual) Windows start menu, and typically I either get a "file not found" pop-up or the launch simply fails silently.

The solution I have found is to manually edit the shortcuts.  Suppose that I am logged in as user "paul" and I've just installed IrfanView.  My first step is to track down the Windows path to the executable.  Assuming defaults were used (generally a good thing when installing software under Wine), I open a terminal and drill down to /home/paul/.wine/drive-c/Program\ Files, where I find the IrfanView directory and, in that, the i_view32.exe executable.

The next step is to run

env WINEPREFIX="/home/paul/.wine" wine "C:\Program Files\IrfanView\i_view32.exe"

in a terminal and make sure that it launches correctly.  Note that the path to the executable is written Windows-style (backslashes, no escaping things) in quotation marks.  If the program launches properly, I close it, copy the entire line to the clipboard, find the launcher in the GNOME menu, right-click and choose "Edit properties", and replace the contents of the "Command:" field with the contents of the clipboard.  I also confirm that launcher type is "Application" and not "Application in Terminal".  With that done, I close the launcher edit panel and test it.  Sometimes it seems to take a while before the menu detects and adopts the change I just made.  I'm not sure, shy of logging out (overkill?), what the best way to impose the change immediately is.  I've tried "killall gnome-panel" (possibly also overkill) with mixed success.

Android-Linux File Transfers

I recently acquired a Toshiba Thrive tablet (Android Honeycomb, currently version 3.2.1), in part because it comes with two USB ports (one full size, one mini).  The USB ports theoretically allow me to move files between my Ubuntu PC and the tablet by mounting the tablet as a disk drive on the PC.  I say "theoretically" because Google recently moved to Media Transfer Protocol for handling connections over USB. This seems to be okay for Windows PCs and Macs, but for Ubuntu (and other Linux systems) it requires using the mtpfs package. I've found connections to be excruciating slow, and for some reason (probably a setting I'm missing), when I do get connected, all I see is an empty root and an empty Playlists subdirectory. Trust me, there are tons of files on the Thrive.

Fortunately, I found WebSharingLite File/Media Sync, a free app in the Android Market. (As one might expect from the "Lite" part, there is a paid version, rather economically priced.) I have a WiFi DSL gateway at home (and of course my laptop has WiFi). Running WebSharingLite on the tablet, I can connect via a web browser from my PC or laptop and upload/download files considerably faster than what mtpfs over USB seems to allow. (Again, though, I should stress that there's no guarantee I'm setting up mtpfs correctly, despite hours of poking around the web looking for help.) The connection requires a password; coupled with the fact that it's on a nonroutable segment, behind the firewall in my gateway, I think the security is adequate.

I can definitely recommend WebSharingLite.

Mint/Ubuntu Update Broke Printing

Today I was suddenly unable to use my home HP ink jet printer with Linux Mint, despite the fact that this morning it was printing fine from Windows (my system is dual-boot).  The error message informed me that /usr/lib/cups/backend/hp had failed for unspecified reasons.  Toggling the printer off and back on did not help, nor did rebooting the system, nor did switching the driver.

A quick web search, however, revealed the fact that some unspecified update had screwed up permissions on the /usr/lib/cups/backend directory (restricting it to root only).  Most of the executables in that directory looked okay, but the permissions for cups-pdf were also root only, so I'm guessing that it was an update to cups-pdf that blew things up.

The solution: sudo chmod -R 755 /usr/lib/cups/backend.

I thought Microsoft had a patent on destructive updates.  Guess not.

Fixing CUPS-PDF

Not that I needed to find another bug in Mint 11 Katya/Ubuntu 11 Natty, but I just discovered that the "Print to PDF" printer (cups-pdf) was writing a 2.1 KB PDF file containing a single blank page, regardless of what I printed.  A quick web search turned up multiple reports of this.  I used Synaptic to reinstall the cups-pdf package, to no avail.  The solution (which I found on a bug report web page) was to go into Control Center > Printing, delete the "Print to PDF" printer entirely, then use Server > New Printer to reinstall it.  It seems to be working now.  I wonder what the interarrival time for the next gremlin is.  :-(

Spontaneous Reboots

Mint Katya (a derivative of Ubuntu Natty Narwhal) on my AMD-64 system has suddenly developed a penchant for spontaneously rebooting.  So far, it has only happened while I'm typing. I think it has happened twice when I was typing messages in Thunderbird and once or perhaps twice when I was typing in the Yoono plug-in for Firefox. I don't recall any recent updates to T-bird, Firefox or Yoono, nor have I changed my keyboard (in case this is related to n-key rollover -- my fingers sometimes get ahead of my brain when I'm typing). The mosquitoes have gotten quite aggressive (and numerous) around my house; maybe they drove some gremlins indoors?

Update #1: I was sloppy above. It's not Mint that is rebooting; it's the X server. This is apparently a common problem,although the variety of symptoms posted there suggest that this is in fact multiple distinct bugs with a common end result (X crashing). Things I have discovered:

• Unlike several of those reports, I have not experienced any crashes as a result of clicking. Only typing triggers a crash.
• Unlike the reports from laptop users, power management is not the culprit (the machine that crashes for me is a desktop).
• Someone pointed the finger at running the AMD-64 version of Natty on an Intel CPU. My copy of Mint is in fact based on the AMD-64 Natty, but my box has an AMD-64 CPU.
• Turning the proprietary nVidia driver off and then on did not help. (I have a GPU from nVidia.)
• Installing xserver-xorg-video-nv did not help.

Update #2: I used the wizardous sgfxi script to update my nVidia drivers a few days ago. Since then I have had no spontaneous X crashes. I hesitated to claim victory lest it be premature, but today I wrote a moderately lengthy blog post (touch-typing at my usual subsonic speed) with nary a glitch. So hopefully the driver reload cured this problem. Thanks to Harald Hope for a handy script!

Update #3: See this post for earlier problems and this post for a later round of nVidia issues (and how I resolved them).

Tab Completion Bug in Mint 11

This is really a tab completion bug in Ubuntu 11.04 - and may actually be a pair of bugs (I'm not sure), one not the fault of Ubuntu.  Details can be found in this bug report. The short form is that command line tab completion (where you start typing a path and hit TAB to complete it) started breaking down on one of my Mint machines. Hitting TAB would add an unwanted space at the end of the path (forcing me to backspace if I were not yet done) and also failed to escape spaces.  In fact, if I typed the portion of the path containing the space and escaped it, then hit TAB, the escape character (backslash) would be removed.

The bug report contains two possible fixes. As it happens, I had started out with Acrobat Reader 9 installed from the repository on this machine, then replaced it with the version downloaded from Adobe's web site.  This is my 64 bit box, and there's an issue with Acrobat Reader looking for 32 bit versions of libraries (which I have installed), finding the 64 bit versions instead, and tripping over them.  I thought maybe using the Adobe version would fix the problem.  (It did not.)

At any rate, I tried one of the two suggestions in the bug report: deleting /etc/bash_
completion.d/acroread.sh (which is a symlink to a script that comes with the Adobe version of Reader). That seems to have fixed the tab completion bug (knock on virtual wood). It does not seem to have done any harm to Reader, either.