handyfloss

The music loving community may rejoice, ogg2mp3 is out! OK, OK, that is too much to say, but nonetheless someone could find it useful.

Visit its site at: http://isilanes.org/soft/ogg2mp3

ogg2mp3 is a simple Python script I have made to make the task of converting OGG files to MP3 and the other way around easier. There might be other (better) tools out there for the same task, but I had some need, and this script fulfills it. ogg2mp3 can convert single files, lists of them, or even whole directory contents, and reads the [[ID3]] tags of the input OGG/MP3 files, saving them into the output MP3/OGG.

I basically convert bunches of OGG files to MP3 when I want to put them in portable players that don’t read OGG. I do the opposite when someone passes me an MP3 and I want to add it to my collection, which is in OGG format.

Enjoy!

Last friday I wrote about how to install a Huawei E220 modem under MacOSX. Today I will write the corresponding HowTo for Linux.

Usually installation of hardware with non-free drivers is a bit more difficult in Linux than in MacOS and Windows, because the drivers are only made for the latter two. However the E220 is well supported by the Linux kernel (starting at 2.6.20, apparently), so we only need to tweak some configuration files.

1 – Make the system see it properly

The Huawei E220 is a dual machine: apart from being a modem, it is also an USB flash device, with some space to save the Mac/Windows drivers, so that it will “autoinstall” when plugging it under those OSs.

This adds a small level of difficulty, because we have to make sure that the OS sees it as a modem, not as a storage device. In principle the command dmesg (or the file /var/log/messages) will tell us about it. However, I have had it work when dmesg would say that it was a storage device!

The short story is that some [[Kernel (computer science)|kernel modules]] must be loaded, and some others unloaded, when you plug the device. Needed modules: option, usbserial, ppp_async. Must not be present: airprime. In my case usb_storage made no harm, some people say you should unload it. For airprime not to be automatically loaded, put it in some [[Modprobe#Blacklist|blacklist]] file in /etc/modprobe.d/. I decided to add the following line to /etc/modprobe.d/blacklist-modem:

You can ensure the required modules are loaded by taking advantage of [[udev]], but it is not really necessary (in my case it wasn’t). udev can also give you a consistent name for the modem. For me the relevant device was always /dev/ttyUSB0, but you can make it /dev/huawei if you will. For that, you can put the following optional rules in a file in /etc/udev/rules.d/ (for example create 55-huawei.rules):

Two notes: the strings in idProduct and idVendor are obtained running the command lsusb when the modem is plugged. It will show something like:

This is a very neat trick for any USB device we want to manage with udev. The second note is that [[kppp]] (see later) only allows to choose a modem device from a list. If you make the modem be /dev/huawei, you will not be able to use kppp, since that device won’t appear in the list.

2 – Configure wvdial / kppp

You can make use of programs such as [[wvdial]] or [[kppp]] to make the actual connection. I use kppp myself, but that’s up to you (wvdial is apparently more flexible).

wvdial

To use it you have to create a /etc/wvdial.conf file. You can achieve this by running wvdialconf as root, or editing the file by hand, if you are brave.

For me, the output of wvdialconf yielded:

And my current /etc/wvdial.conf looks as follows:

In bold, the relevant user-provided settings. In italics, some items in which you can put whatever, because it doesn’t seem to make a difference.

To connect, run wvdial simyo (or whatever you put in the “[Dialer xxx]” setting above), in the command line. To terminate, Ctrl+C.

kppp

This is the one I use. To open the config/run dialog, run kppp (you can do this as user). There you will have to configure two things: the account and the modem. By pressing “Configure” you will be presented with a window with four tabs. In the first one you will create a new account, in which the relevant data is:

• Phone number: *99#
• Authentication: PAP/CHAP
• Callback type: none

In the second tab you will configure the modem:

• Modem device: /dev/ttyUSB0
• Flow control: Hardware
• Line termination: CR/LF
• Connection speed: 921600

Please note that those are parameters that work for me. I can not assure that they are the “correct” ones. I have player around with different values, and many times the modem would work all the same with different settings. If you find some error in my setup, please tell me :^)

It is common to hear that recent advances in the Linux desktop, such as [[Compiz Fusion]], are more of a fancy but useless aesthetic contribution to the desktop. While it may be true for many of the CF features, it is no less true that you never know when a given effect will turn out to be useful.

In this post I want to praise the Enhanced Zoom Desktop plugin. It turned out to be of great use for me in the following situation. I wanted to run [[Diablo II]] in my laptop (yes, it runs in Linux, under Wine). The native resolution of the program (640×480 or 800×600) is lower than that of my screen (1280×800), so I have two options: to execute it in windowed mode, or fullscreen. In windowed mode the window occupies less than 2/3 of the 13.3″ screen, wasting space and making it unnecessarily small. Fullscreen mode seems to be better, but it isn’t. Since the width/height ratio is smaller for Diablo than for the screen, the former will be stretched horizontally, distorting the images (everything looks more squat). Fullscreen mode also gave me other problems, like crashing more easily when alt-tabbing.

Here is where the zooming of Compiz Fusion comes in handy. Apart from an arbitrary zoom (using the mouse wheel while pressing the Super key, a.k.a. windows key), there is a handy shortcut (Super+r) that zooms up to the point of the screen under the cursor occupying the whole screen. When zooming, the movement of the mouse makes the zooming “window” to move around, showing different parts of the desktop. To avoid it (clearly unwanted if we want to stay inside the Diablo window), we have another shortcut: Super+l. This shortcut toggles on and off the “zooming lens follows the mouse” movement.

So now, if I want to play Diablo I open it in windowed mode, then put the cursor inside the window, then hit Super+r, then Super+l, and I have a Diablo window as big as possible to fit in my screen, preserving height/width ratio, and keeping the mouse inside the window.

I am a heavy user of the [[Grace (plotting tool)|Xmgrace]] plotting program, and I love it. An operation very ofter used is to scale the X and Y axes to our liking, to show different parts of our data in the resulting plot. You can do that from the command line by setting the “world” of the graph, providing four numbers as X,Y boundaries:

% xmgrace -world xmin ymin xmax ymax file.dat

Apart from setting the maximum and minimum values for X and Y, we can make use of the autoscale option to selectively show some ranges. The four options to autoscale are:

• none – show the X,Y ranges defined by the “world” variable (if not set, the default is “0 0 1 1”).
• xy – forget about “world” data, make plot range in X and Y enough to plot all data in input.
• x – autoscale X to show all data, but respect Y given by “world”. This means that if a point is not shown because it lies outside the Y range, then it doesn’t count to force X autoscale. This is a wee bit trickier than it sounds.
• y – see previous point, with X and Y swapped.

But Xmgrace is not only about [[command-line interface|command line]], or even [[Graphical user interface|GUI]]. You can write a .agr file (for example by saving a plot from the Xmgrace GUI), and manipulate it so that the following command:

% xmgrace file.agr

will bring up a plot with all the data and formatting we have put into the .agr file. It’s really handy to save a file as-is.

Now, the syntax for inputting the world in the .agr is well known:

@ world xmin, ymin, xmax, ymax

where xmin etc. are floating point numbers.

The problem is how to hardcode the autoscale feature into the .agr. I had always been forced to do:

% xmgrace -autoscale none file.agr

from the command line, because I couldn’t find out how to include it in the .agr. Finally I did find it, and that’s the main reason of this post. The syntax is explained in the manual at the Xmrace site, but I found it after googling for agr files containing “autoscale” in them. The line to include seems to be:

@ autoscale onread none

A .agr containing the above line will produce, when called as follows:

% xmgrace file.agr

the same output as a file not containing it, when called as follows:

% xmgrace -autoscale none file.agr

A request from a friend made me face the problem of converting a color [[Portable Document Format|PDF]] into a [[grayscale]] one. Searching the web provided some ways of doing so with [[Adobe Acrobat]], via some obscure menu item somewhere.

However, the very same operation could be undertaken with free tools, such as [[ghostscript]]. I found a way to do it in the YANUB blog, and I will copy-paste it here, with a small modification.

Assuming we have a file called color.pdf, and we want to convert it into grayscale.pdf, we could run the following command (all in a single line, and omitting the “\” line continuation marks):

I prefer the above to YANUB’s version below (in red what he lacks, in blue what I lack), because a shell operation is substituted by some option(s) of the command we are running:

A sample [[Perl]] script to alleviate the tedious writing above:

Assuming we call the Perl script “togray.pl”, and that we have a color file “input.pdf”, we could just issue the command:

and we would get a grayscale version of it, named “input_gray.pdf”.

I recently subscribed to [[simyo]]’s mobile internet service. I was considering also [[Orange (brand)|Orange]], as explained in a previous post (es), but simyo’s offer is better.

I am writing how to make the modem simyo provides (the commonplace [[Huawei E220]]) on MacOSX first, because apparently the [[Personal identification number|PIN]] has to be deactivated for the modem to work in Linux. I have to admit that in MacOSX installation was a breeze.

Software installation

Start MacOS, then plug the USB modem. A window will open automatically, with two objects inside: “MobileConnect” and “User Manual”. The former is the installer binary, and the latter is a folder with the manuals in PDF format (for me, they were in English and Spanish).

Clicking on the “MobileConnect” icon the installer will start, and after being asked to accept an [[Software license agreement|EULA]], then introduce the admin password, then choosing a location for placing the files (actually just a hard disk, not a concrete dir), the installer does its thing.

Profile setting

After that, we only need to configure a connection in the “Mobile Connect” window that opens automatically after installation. For that, click on “Setting…” and create a new profile. If you read the manual (see above), it is easy to fill in the blanks. In short:

• Profile name: whatever you want
• Access Point Name: this is the APN value that simyo tells you in some paper (gprs-service.com)
• Telephone number: *99#
• Account name: irrelevant
• Password: irrelevant

Save the above, then choose the profile you just created in the drop-down list in “Profile name”, then hit the “Connect” button. If after saying “Dialing up, please wait”, it tells you “Connection succesfull!”, then everything is fine!

PIN deactivation

Apparently using the modem under Linux requires that the PIN is deactivated. Doing that under MacOSX is easy: when the “Mobile Connect” window is active, go to the “Manage PIN” drop-down menu in the top bar. There you can find “Activate”, “Deactivate” and “Modify”. Self-explanatory, ain’t it?

I recently updated the [[MediaWiki]] installation in one of my [[DreamHost]] domains from 1.12 to 1.13, and I started to see the following error messages when trying to edit/save pages (the capital letter triplets used for privacy):

Database error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function “Article:getHiddenCategories”. MySQL returned error “1146: Table XXX.YYY_page_props’ doesn’t exist (mysql.ZZZ.AAA)”.

After a Google search that yielded only two results, I checked a mediawiki.org page talking about the subject. The (maybe obvious) reason for my error was that I hadn’t run the MediaWiki update script, as one should after any upgrade.

The procedures is outlined in this other mediawiki.org page. However there is a little catch: the [[PHP]] version (at least in my case) accessible in the shell of the server where my wiki is is 4.4.8, but the MediaWiki update script needs PHP5. No problem, I checked the DreamHost wiki, and found out that for PHP5 I could use the following executable: /usr/local/dh/cgi-system/php5.cgi.

Running that executable on the corresponding update.php script (after setting up AdminSettings.php as told to), everything was OK again.

OK, so the 2GB [[Secure Digital card|SD]] card I use in my camera has its problems. Apparently, only 1GB of it are recognized by the OS (Linux) and/or the card readers I own. The problem seems to be common, as you can see by googling about it. More info, from the Wikipedia article for SD cards:

Devices that use SD cards identify the card by requesting a 128-bit identification string from the card. For standard-capacity SD cards, 12 of the bits are used to identify the number of memory clusters (ranging from 1 to 4096) and 3 of the bits are used to identify the number of blocks per cluster (which decode to 4, 8, 16, 32, 64, 128, 256 or 512 blocks per cluster).

In older 1.x implementations the standard capacity block was exactly 512 bytes. This gives 4096 x 512 x 512 = 1 gigabyte of storage memory. A later revision of the 1.x standard allowed a 4-bit field to indicate 1024 or 2048 bytes per block instead, yielding more than 1 gigabyte of memory storage. Devices designed before this change may incorrectly identify such cards. Usually by misidentify a card with lower capacity than is the case by assuming 512 bytes per block rather than 1024 or 2048.

For the new SDHC high capacity card (2.0) implementation, 22 bits of the identification string are used to indicate the memory size in increments of 512 KBytes. Currently 16 of the 22 bits are allowed to be used, giving a maximum size of 32 GB. All SDHC 4-GB and larger cards must be 2.0 implementations. Two bits that were previously reserved and fixed at 0 are now used for identifying the type of card, 0=standard, 1=HC, 2=reserved, 3=reserved. Non-HC devices are not programmed to read this code and therefore cannot correctly read the identification of the card.

All SDHC readers work with standard SD cards.[ref]

Many older devices will not accept the 2 or 4 GB size even though it is in the revised standard. The following statement is from the SD association specification:

“To make 2 GByte card, the Maximum Block Length (READ_BL_LEN=WRITE_BL_LEN) shall be set to 1024 bytes. However, the Block Length, set by CMD16, shall be up to 512 bytes to keep consistency with 512 bytes Maximum Block Length cards (Less than and equal 2 Gbyte cards[ref].”

I have had problems in the past with this issue, and could only retrieve the photos exceeding the “first GB” of the card with a tedious operation: copy some photos from the card to the internal memory of the camera (28MB), remove the card from camera, connect camera to computer, download the photos in the internal memory (and empty it), unplug and repeat. 1GB/28MB = boring as hell.

However yesterday I realized that I had a shinny MacBook with its MacOSX intact. I read somewhere that Windows would sometimes read 2GB cards that Linux couldn’t, by the simple method of happily ignoring the f*cked up file system in them. Maybe MacOSX could, too.

Well, it turns out it couldn’t. When I attached the card in the card reader (I didn’t try with the camera directly), MacOSX found the device and mounted it, giving me a nice icon in the Mac version of “My PC”. However, the directory the icon led to was empty. I thought “Tough luck, Mac reads nothing in the card”, unmounted it and unplug it. Then I placed it in the camera again, turned it on and… there was no photo in the darned thing! MacOSX had erased them!

There is still the (likely) possibility that I made some deep mistake, but the explanation for now seems that MacOSX ate my pics. Sad.

I use [[Inkscape]] to do many of the drawings for my articles and talks, and have come across an irritating problem: I could not include [[LaTeX]] formulas on it. I have googled a bit about it, and the first match already led me to a bug report, where a comment by Kees Cook gives a fix that I quote below:

% cd /usr/share/inkscape/extensions
% curl -s 'http://launchpadlibrarian.net/12978623/eqtexsvg.py.patch' | sudo patch -p0

The bug affects (and the patch fixes) Inkscape 0.46 on [[Ubuntu]] Hardy Heron and [[Debian]] Lenny (that I know of).

As I said in a previous post, I bought a [[MacBook]], and I am making all bits work correctly. Out-of-the-box support from Ubuntu (the only GNU/Linux I tried on the MacBook so far) is excellent, but some things (camera, WiFi…) need proprietary drivers, so some more tweaks are needed.

I have followed the instructions in the Ubuntu community site, as with the procedures detailed in the previous post.

Basically, it all boils down to:

Fetch the Apple drivers for the camera

As root (if, unlike me, you like sudo, then run the following as user, but prepended with sudo), mount the Mac OSX partition (you didn’t delete it, right?) and copy the relevant file somewhere else (the cp command should be all in one line):

# cd
# mkdir /mnt/macosx
# mount /dev/sda2 /mnt/macosx
# cp /mnt/macosx/System/Library/Extensions/
     IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/
     Contents/MacOS/AppleUSBVideoSupport .
# umount /mnt/macosx

You might have noticed that the Mac OSX partition is not sda1, but sda2. Don’t ask me. It turns out like this after following my own installation instructions. Apple must have decided to install the OS in the second partition for some reason.

Install the required packages

We need a package called isight-firmware-tools. Unfortunately it is not present in the Hardy repos at the moment (it was in the Gutsy ones, I think). You can add a Launchpad repo, editing /etc/apt/sources.list to add:

deb http://ppa.launchpad.net/mactel-support/ubuntu hardy main
deb-src http://ppa.launchpad.net/mactel-support/ubuntu hardy main

Then, as root:

# aptitude update
# aptitude install isight-firmware-tools

You will be prompted for a path to the driver you copied before. You can press Enter without paying much attention, then execute (assuming you copied the driver to your root home):

# cd
# ift-extract -a ./AppleUSBVideoSupport

To activate the driver, restart [[HAL (software)|HAL]]:

# /etc/init.d/hal restart

Test it with [[Ekiga]]

As explained in the Ubuntu community site, you can run Ekiga as user (after installing the ekiga package). Choose V4L2 as video plugin, and Built-in iSight should appear among the Input device list. If it does, the process worked.