juniper ssl vpn w/ Fedora 14

I use the juniper ssl vpn client to connect to my work's internal network. Although there is a linux client, it requires the Sun (Oracle) jre to work, which doesn't play well with selinux on Fedora 14. (It's not Fedora's fault, it's a bug in the plugin.)

Temporary fix:

# setsebool allow_execstack 1

It's not persistent, so it's not a permanent hole, but it would be best if I figured out what needed to be set for the various files involved. *Sigh*

Intel atom D510 motherboard, take 2

The cpu in my home server is dying, so I decided to replace it with an atom motherboard. All was going well, until the screen went wonky, and the computer shut itself down. I rebooted, there was a large pop, followed by the delightful smell of ozone. Ah, well. I now get to experience the Intel warranty system. Wish me luck!

Twitter via weechat + tircd

I've been accessing twitter through the weechat irc client using tircd. That worked pretty well until twitter switch to OAuth authentication for all twitter API clients.

Helpful hints:

1. http://code.google.com/p/tircd/ has directions for oauth, but leaves out the fact that a (fake) password is still required, even after setting the username to "oauth". http://code.google.com/p/tircd/issues/detail?id=80&q=oauth
2. The download version of tircd (0.10, although when run it thinks it's 0.08) doesn't seem to work with oauth. See http://code.google.com/p/tircd/issues/detail?id=84&q=oauth, and then download a forked version from http://github.com/drags/tircd.
3. weechat expects "/stats" to be run in a window connected to the server. For twitter there wasn't yet one, because the oauth handshake still needed a PIN to be sent. As the tircd homepage suggested, I used "/quote -server twitter stats pin MYPIN", where my weechat config uses "twitter" as the internal server name for tircd configuration.
4. The twitter oauth PIN seems to have been cached somewhere. I've no idea where, so I'm sure this will bite me eventually.

Using the mythtv to record from a VCR

It seems that how one uses a WinTV PVR-250 to record from a VCR has changed since the last time I did it. Here's what I ended up doing, after temporarily killing mythbackend. I have my directv box plugged into the SVideo and stereo audio ports, while the VCR was attached by coax.

# list the allowed frequency names
ivtv-tune -L
# set the tuner (to the wrong channel, but oh well...)
ivtv-tune -tus-bcast -c2
# search the web, and eventually learn that ivtv-ctl functionality
# has mostly moved to v4l2-ctl
v4l2-ctl 
v4l2-ctl --all
v4l2-ctl -T
# list possible outputs; I want the tuner
v4l2-ctl -n
# choose the tuner (coax input)
v4l2-ctl -i 0
# choose the s-video input (to test, since it works w/ the mythtv)
v4l2-ctl -i 1
v4l2-ctl --all
# copy a bit from the s-video input
cat /dev/video0 > foo.mpg
ls -l foo.mpg 
totem foo.mpg
rm foo.mpg
# switch to the tuner
v4l2-ctl -i 0
# copy fuzz since I'm on the wrong channel
cat /dev/video0 > foo.mpg
# switch to the right channel
ivtv-tune -tus-bcast -c3
# run a test
cat /dev/video0 > foo.mpg
totem foo.mpg
# success!

Rpy2 on ubuntu

python -m 'rpy2.tests' was failing because libR.so wasn't being found when using the latest dev version of rpy2 installed in my home directory.

Ugly, simple fix: sudo ln -s /usr/lib64/R/lib/libR.so /usr/lib/libR.so

printer overspray

Sarah enjoys digital scrapbooking, until she wants to print a carefully-aligned page. If the page is 8.5x11 inches, then one would expect borderless printing to be exactly what she wants. Um, not so much. For borderless printing, printers expand the image slightly to avoid alignment issues, assuming that people won't mind if the edges get cut off slightly. (http://www.steves-digicams.com/knowledge-center/size-matters-paper-size-vs-print-size.html) Our HP deskjet 5400 has an "overspray" setting that can be turned off, which at least ensures that the entire image gets printed.

mythtv on both TV and 720p projector with nouveau

I just finished installing my mythtv (mythbuntu) box to lucid. The upgrade went well enough, although X wasn't working well afterwards. No problem, since I really wanted to switch from the proprietary nvidia drivers to the nouveau drivers anyway.

I have both a (SD)TV and an HD projector connected to my nvidia FX 5200, the former via S-Video, and the latter via an hdmi cable plugged into a DVI-to-hdmi adapter. With the "nv" or "nvidia" drivers, xrandr only sees the projector if both are plugged in, although it sees the TV if the projector is unplugged. So, I've been restarting X when I want to use the projector, which is a pain. With the nouveau drivers in lucid, though, xrandr now shows all three connections at boot time:

grant@mythbuntu:~$ xrandr -q
Screen 0: minimum 320 x 200, current 720 x 480, maximum 4096 x 4096
VGA-1 disconnected (normal left inverted right x axis y axis)
TV-1 connected 720x480+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
  720x480        59.9*+
  1024x768       59.9 
  800x600        59.9 
  720x576        59.9 
  640x480        59.9 
  400x300       119.9 
  320x240       119.9 
  320x200       119.9 
DVI-D-1 connected (normal left inverted right x axis y axis)
  1280x720       60.0 +   60.0     50.0 
  1280x1024      60.0 
  1024x768       60.0 
  800x600        60.3 
  720x576        50.0 
  720x480        59.9 
  640x480        60.0

Awesome!

Unfortunately, the TV output was showing up in black and white. Oops. Looking at the output from xrandr --verbose, I realized that nouveau was assuming the TV out should be PAL instead of NTSC-M. After a great deal of searching, I completely failed to find any document that would tell me how to fix that problem for nouveau, since I couldn't find the magic incantation for xrandr that actually worked, and the old standby of Option "TVStandard" "NTSC-M" in xorg.conf just lead to (WW) NOUVEAU(0): Option "TVStandard" is not used showing up in Xorg.0.log. Sigh.

When all else fails, ask on IRC. So I asked about it in #nouveau on freenode. It turns out that what I needed was to have nouveau.tv_norm=NTSC-M in the kernel boot line, because it's the kernel that does the detection. Oh. Works, though. (Incidentally, the list of settable parameters may be found from modinfo nouveau.)

Now my TV is in color, and xrandr may be used to set which output device I want to use with no plugging/unplugging involved. There's a bit of a catch, though, since the aspect ratios and screen sizes are different between the two displays. If I have mythfrontend filling the screen on the TV, then cloning that display on the HD projector leaves a bit of unused real estate. I don't really want to use both screens at the same time, though, so I wrote a couple simple scripts and connected them to "Switch to TV" and "Switch to Projector" buttons that I added to the mythtv main menu:

grant@mythbuntu:~$ cat bin/tv.sh 
#!/bin/bash

export DISPLAY=:0
xrandr --output DVI-D-1 --off
killall mythfrontend.real
xrandr --output TV-1 --auto
nohup mythfrontend &

along with

grant@mythbuntu:~$ cat bin/projector.sh 
#!/bin/bash

export DISPLAY=:0
xrandr --output TV-1 --off
killall mythfrontend.real
xrandr --output DVI-D-1 --auto
nohup mythfrontend &

Now I just have to get two minor bugs worked out. The first is the fact that putting the GRUB_CMDLINE_LINUX="nouveau.tv_norm=NTSC-M kernel line in /etc/grub.d/40_custom and running update-grub doesn't seem to actually append that string to the kernel boot line. That's annoying, but fixing it in /etc/default/grub does work, and I'll just have to remember to update that when grub is updated. The other bug is that now mythfrontend crashes when I put a DVD in the drive. A mythtv box makes for a great upscaling DVD player, or at least it would if QT wouldn't segfault. All in all, not too bad a set of problems.