Preamble

Having ruled a thousand nations, loved a million Homo sapiens and assembled light-years of Z++ code, the greatness of the almighty Schivmeister has sparked an uproar so great that it is only sane to publish an equally mighty weblog.

mpkgclean: a makepkg cache cleaner

Holy crap. This “blog” is almost dead. Lemme give it some love.

While finishing up a rewrite of our database scripts at ArchAudio I had to figure out a solution to clear out old packages in the repositories. The way our stuff works is actually dependent solely on Subversion, and there is no SSH involved. You can guess that this means our binary packages are just SVN commits.

As such, without getting too hacky, you are not going to get a list of packages being “uploaded”. You are going to need to work with an arbitrary number of packages at a time, so fellow Arch Linux user Bluewind‘s script for his personal repositories is not going to cut it (note: this is false and is actually an excuse for my inability to read Perl). I also want to keep our scripts in Bash (aside from the mailer which is in Python and is just a copy-paste from a template) to allow potentially more people to contribute.

I figured I would just need something like Pacman‘s clean function, but for the makepkg cache instead. I thought something like that might already exist, but a search through the AUR, ArchWiki and Arch Forums turned up nothing. In not wanting to waste any more time, I figured reinventing the wheel wouldn’t be that great of a loss if I couldn’t find the wheel in the first place. So here it is:

#!/bin/bash

# Copyright (c) 2011 Ray Rashif  - GNU GPL

get_fext() {
	echo $1 | rev | awk -F "-" '{print $1}' | rev
}

get_pver() {
	echo $1 | rev | awk -F "-" '{print $2"-"$3}' | rev
}

get_pname() {
	local fext pver

	fext=$(get_fext $1)
	pver=$(get_pver $1)

	echo ${1/-$pver-$fext}
}

# clean package extensions first
echo -n "Getting rid of old package formats..."

for pfile in *.pkg.tar.*; do
	# exit cleanly if nothing was found
	if [[ "$pfile" = '*.pkg.tar.*' ]]; then
		echo "none found"
		echo "No packages found, nothing to do."
		exit 0
	fi

	fext=$(get_fext $pfile)
	pver=$(get_pver $pfile)
	pname=${pfile/-$pver-$fext}
	parch=${fext/.*}

	# just edit the RE for more formats
	id=$pname-$pver-$parch.pkg.tar
	pext_matches=($(\ls -v $id.[gx]z))

	if [[ ${#pext_matches[@]} -gt 1 ]]; then
		for match in ${pext_matches[@]}; do
			[[ "$match" != "$id.xz" ]] && \
				rm -f $match && oldremoved=1
		done
	fi
done

[[ $oldremoved -eq 1 ]] && echo "done" || echo "none found"

# now clean the rest
for pfile in *.pkg.tar.*; do
	fext=$(get_fext $pfile)
	pver=$(get_pver $pfile)
	pname=${pfile/-$pver-$fext}
	parch=${fext/.*}

	matches=($(\ls -v $pname-*-$parch.*))

	# for cases like foo, foo-bar, prevent mixing them up
	for oldpkg in $(seq 0 $((${#matches[@]} - 1))); do
		oldname=$(get_pname ${matches[$oldpkg]})
		[[ "$oldname" != "$pname" ]] && unset matches[$oldpkg]
	done

	t_matches=${#matches[@]}

	# if only one match then obviously nothing to do
	[[ $t_matches -eq 1 ]] && continue

	# get oldest and newest versions
	oldest=$(get_pver ${matches[0]})
	newest=$(get_pver ${matches[$t_matches-1]})

	echo "Cleaning $pname [$oldest -> $newest] ($parch)"

	# WARNING: logic based on ls natural version sort order;
	#   some types of versioning may fail this order
	#   last item is assumed latest
	for oldpkg in $(seq 0 $(($t_matches - 2))); do
		rm -f ${matches[$oldpkg]} && pkgremoved=1
	done
done

[[ $pkgremoved -ne 1 ]] && echo "All clear, nothing to clean."

# vim:set ts=4 sw=4 noet:

Nicely highlighted here: http://paste.pocoo.org/show/416372/

It removes all but the latest one for every package found in the current directory. It also checks for and removes older package formats for eg. those in .gz instead of .xz. Caveats apply (read through the code), and it’s also not optimised for speed. For instance, getting the name of the package via a functon is really expensive. Sort order may be a problem if your locale is not a form of English, but I’m not sure. Just test it out in a copy of the directory you want manipulated.

Arch Linux: Boot-time Music

Note: This is not really Arch-specific although I deal with Arch Linux files in this article; anyone can adapt it for their *NIX platform’s init process.

Quickstart
First, get your sound file ready. We are going to read it after the system has sourced our rc.conf MODULES array, so you are free to choose a player, format and location. To be safe, I have mine in boot, and use aplay instead of mplayer, so it is at /boot/audio.wav as (obviously) a WAVE instead of MP3 or OGG.

Edit /etc/rc.sysinit and look for the line:

# Load modules from the MODULES array defined in rc.conf

and then add:

# start some background audio
/usr/sbin/alsactl restore
/usr/bin/aplay /boot/audio.wav &

before the lines:

if [ -d /proc/acpi ]; then
  stat_busy "Loading standard ACPI modules"
  ACPI_MODULES="ac battery button fan processor thermal"

Or if you manually load modules (all or even a couple), then before:

# Wait for udev uevents

Else, as a last resort, before:

# bring up the loopback interface

Try from the earliest, and if you get low-level ALSA errors, it means the sound device didn’t initialise by the time you wanted it to run. In that case, try the other two positions. Any later than that, I don’t see a point. Also, remember to set a nice level beforehand with alsamixer and then alsactl store it. If you want a different set of levels separate from the post-boot system, simply use a different file with the –file option:

~# alsactl store -f /etc/asoundboot.state

Since this is still a little too late for my taste, I don’t kill it. Good for a non-invasive ambience track, especially if you run a login manager. If you’re very clever and into Rocket Science, you can also use a sound file which fits into the period of bootup from after modules have been loaded (Rocket Science Hint: time or bootchart). Or if you’re not very clever, you can just kill the process from somewhere, eg. /etc/rc.local:

killall -9 aplay

For what it’s worth, that is the earliest time we can play a sound file without modifying the system, and this is before any daemons are run. You can remove your alsa daemon from the system since we already restore the state during the above run (edit the alsactl line accordingly if you have made changes to /etc/conf.d/alsa). Like mentioned, the result is not good enough for me (and possibly a lot of others), because my bootup is 40 seconds til a fully-functional, action-ready and tiled KDE 4 desktop (30 to Awesome WM). Nevertheless, curiosity killed.

Warning: An update to initscripts will replace the sysinit file. Look for “NoUpgrade” in pacman.

Background
Sabayon Linux has been doing it ever since their LiveDVD releases of year 2006, and even though it’s not something everyone would like, the fact is that it gets the curious user excited no matter how nonsensical a purpose it serves. I used Sabayon from around late 2006 to early 2007, at which point I moved to Arch (and I never hopped again), so I can still remember that it had an option to “turn off” the music via the kernel line. Regardless of the on/off state, I never did hear the music. At one point of time, on Arch, I tried to implement something similar. I forgot what I did, whether it even worked, and lost the related prototype files if any at all (I do recall a custom daemon).

Anyway, someone on #archlinux asked about this yesterday, and it got me curious again. My stance is always the same:

There is no reason for any kind of “boot music” aside from when live media is used. Optical read speed is inherently slower than traditional disks or flash drives, and for LiveDVDs it equates to a significant amount of waiting time during the boot process. There, it makes ample sense. If you _are_ curious enough to try it nonetheless, on a sane, installed system, you have to ensure that the music does not start too early or too late, or else it becomes pointless to the extent I should have to punch you.

From this and this it appears Sabayon has something called a “Boot Music Infrastructure”, which is technically nothing more than an init script. The sound file itself is stored in /usr/share/sounds, and the script will read (i.e play) it while the rest of the daemons are being started. The following:

depend() {
  after modules
  before hostname
  before alsasound
}

Translates linguistically to:

Start only after all modules have loaded, before the hostname is set, and before alsa state is restored.

I have no idea why they’re creating their own values for the audio levels. Anyway, theoretically, it might be possible to start the sound subsystem even earlier. That would mean injecting the modules (along with dependencies) and binaries into the kernel image (see mkinitcpio), and reconstructing init itself.

Say..a low-level method to play music from POST onwards would be really nice.

Another Rocket Science Hint: iPod

=p

Modding the Motorola ROKR E8

I’ve hacked computers, office equipment/machinery, guitars, drums, bikes (the BMX kind), PCBs, microcontrollers, ovens, wooden tables/chairs..but I’ve never hacked a cellphone. I got myself a Linux-based cellular device sometime last year hoping to remedy that lack just for a bit, but not until I made sure to actually use it extensively as-is.

Well, “hacking” may still be far away, but I finally got around to flashing this not-so-great-by-default Motorola product. I am, and if not – I choose to be, a total noOb in this area. I found myself having to join a forum and make queries. It wasn’t a bad idea.

Step 1

Check whether you can actually flash your set: http://www.mmus.us/forum/showthread.php?t=7450

To see bootloader version: Hold [*] + [#] while switching ON phone

To see firmware version: Settings > Phone Settings > Properties (sorry can’t remember the shortcut)

Anything “locked” is not a good sign. For sets bought/contracted in Singapore, you’re most probably safe. I have:

Bootloader
06.A3

AP S/W Version:
R6713_G_71.01.8BR

Step 2

Back up your phone.

Everything on the internal memory will be wiped off, so move stuff to the memory card if you have one.

For the phonebook, if it’s not on the SIM, then use a PIM to save it. On Windows, you have Motorola Phone Tools. On Linux, I have Wammu. It fails miserably, yes. So I relied on my “Virtual XP Professional SP 3” to run the Motorola one.

Step 3

Get the Motodev USB driver. I don’t know if the consumer driver works or what the difference is, but who cares? I do know that they’re different – your Phone Tools won’t work with this driver. You can have both drivers installed as far as I can tell.

See http://developer.motorola.com/docstools/USB_Drivers

Step 4

Get the flashing program: RSD Lite

This appears to be a developer-only utility bound by an unopen license, so you’ll have to google it. Don’t fret, though, because you’ll be downloading the latest version of it before you can even search for the latest version of Ubuntu.

Step 5

Charge your phone if it has one bar or less.

Plug in. You don’t need to do anything weird like booting it in bootloader mode. Just normal mode.

Start RSD Lite.

Wait for about a minute until it finds your device and the status does not change anymore.

Step 6

Check out how to flash and keep the steps in mind: http://www.mmus.us/forum/showthread.php?t=3912

Basically you just select a *.sbf file (press the “…” button beside the input box) and press START, then wait until it says “PASS” somewhere. It took just less than 5 minutes for me for each of the three flashing steps (two pre-firmware and one firmware). You can flash each one after the other as long as they’re successful.

Step 7

Flash the bootloader (noRSA): http://www.mmus.us/forum/showthread.php?t=9083

The files you need depends on your bootloader version. For me:

E8_06A3_noRSA.zip

Step 8

Flash the bootloader (patched cg31): http://www.mmus.us/forum/showthread.php?t=9083

Again, for me:

Patched-cg31-for-No-RSA-06.A3-or-06.A5-boot.loader.zip

Step 9

Flash a firmware of choice. There are recommendations in the above forum threads.

You can also just see what’s available for yourself: http://www.mmus.us/forum/forumdisplay.php?f=153

BUT, but, you have to take note of this awesome thing called “MpkgBox” which allows you run “Mgx Applications”:

http://www.mmus.us/forum/showthread.php?t=6924

When I chanced upon the term “ScummVM”, I knew I couldn’t do without this Mpkg thing, because that’s a ScummVM Mgx port. I mean, WHOA. How awesome could this get?

Step 10

Enjoy your “new” phone (remember: whatever warranty you had is now VOID). You can drag and drop skins and Mgx apps to the folders via Memory Card mode. There are other ways where you can access the filesystem via Telnet or FTP!

But don’t forget to do a reset of the data from Settings after the flash.

Now you can go on and try other mods/flashes to see which one suits you best.

Closing:

The people behind these mods are amazing at what they do. Special thanks goes to tankrider for helping me sort it all out, and to bestwebs, nikhil007 for creating these awesome reflashes.

Linux Audio: To RT or to BFS?

My first brush with the new scheduler was when I came across http://lwn.net/Articles/350820/ via a mail to the LMMS lists (might have been LAU/LAD, can’t recall and lazy to search the archives or GMail trash). This prompted me to investigate it further, but not before I assumed some horrible things (mainly how the rt patch and the resulting realtime actually works). Suspecting my own judgement, I went over to #ck (irc.oftc.net) and posted my queries. True enough, part of my thinking was right – in that BFS can be a drop-in replacement for realtime audio work (traditionally so used to the -rt patch).

First of all, the “realtime” we have access to in an rt-patched kernel is “hard real, realtime”. Now, do recall that this patch was never designed with multimedia usage at the top of the priority list, but that it simply became a by-product of sorts. Primarily, we’re talking “embedded” and “lasers” here, then “audio”. Before this, us audio users only had this patch as our sole saviour. Well, not anymore.

Reason 1: The rt-tree has been slowly merged in mainline. Well, to an extent at least. As such, people have claimed to be able to run shitloads of VSTs and jconv IRs while recording a guitar sitting on top of Mt. Everest without -rt. The simple answer here is that “we no longer need a patch”.

Reason 2: Due to the revelation of BFS, users have found out that the “desktop experience” can apparently be better by a significant leap. Indirectly, this also means multimedia realtime becomes better proportionately. And this is not something hypothetical, you would (not should) immediately notice the difference if you’re a regular Linux Audio guy. What BFS introduces is a better “soft realtime” via SCHED_ISO, and this is more than enough unless we are audio rocket/laser scientists. Furthermore, in the BFS FAQ, Con Kolivas mentions realtime and jackd.

An extract of the conversation (by reading the following you agree not to hold anyone responsible for their comments and that it is just for your information):

[23:03] <Diablo-D3> bfs has realtime-compatible latencies
[23:03] <Diablo-D3> iso’ed processes on bfs generally defeats the entire point of having rt
[23:03] <mb_> Diablo-D3: It doesn’t change interrupt and spinlock latencies.
[23:03] <Diablo-D3> no it doesnt
[23:03] <Diablo-D3> but for something like, say, daft punk discovering linux, its good enough
[23:04] <Diablo-D3> if I was building a cruise missile, I wouldnt be using linux to begin with.

NI Guitar Rig 3 on Linux

Ardour’s recent implementation of the revitalised FST initiative means that Linux sound engineers now have one more easy-access path to VST plug-ins. Among the tested DLLs, Native Instruments’ Guitar Rig 2 & 3 have been claimed to work well. If you’re a guitarist using Linux, it’s blasphemy to not have been moved by this revelation, so allow me to be your road to salvation.

Virtualization: VirtualBox – Windows 7 Preview

So I got around to actually putting my preview ISO to good use. After all, I’d be wasting valuable disk space costing less than $0.50/GB if I don’t at least do something. I wonder why I bothered in the first place, but I decided that this is purely technical and has no significance to the opinions I have regarding Microsoft’s softducts.

Wait..I lied. This was not just for the sake of knowledge. I surmise from the hype that this time Microsoft actually fixed a mistake (which we gladly call “Vista”).  As such, it will be on my list the next time I’m told to upgrade a Windows box. Maybe I should start planning my consultation rates.

Professional Audio on Linux: An Early 2009 Overview

It’s not hard to start recording on Linux – it’s just hard to start migrating to record on Linux. The documentation is so fragmented that even I myself have no idea which would be the perfect FAQ, or how I learnt all that. That’s why a lot of times we end up providing information from what we know instead of citing sources to beginners. And that’s exactly why, yet again, there’s another level of fragmentation. This may not be true now, though. I’m probably assuming but things should pretty much be 95% 95% really 95% plug-and-play by now, aside from the occassional quirks, bugs, and glitches.

Uninstall Linux: Fix MBR from within Windows XP

(serious folks can skip the bullshite and start reading from “just fix it” below)

As a gift to myself for putting up a blog (not using the word “having” for I fear this domain may cease to exist without your prior knowledge), I am unleashing the geek in me with this first post. Actually, the only reason I would continue to actively maintain this online “journal” would be solely for magnificently geeky purposes (software, hardware, geekwear etc). Do not expect gay (in the correct form of the term) stuff like images of my sexy fierce face, body and all that is me with daily write-ups documenting my trips to the toilet, refrigerator and all that shebang.

Without further delay like a second-hand DC-10 refuelling in Mumbai, let us depart.