Category Archives: linux

In which it takes over two hours to play an MP3 file on Linux in 2016

Let me preface by saying that it’s 2016. Right? Am I right? It’s 2016, I think.


Having problems in Banshee, Totem, Rhythmbox (GStreamer apps) on Lubuntu? Can’t play MP3? Can’t get any audio output at all? Try the following command:

sudo apt install gstreamer1.0-plugins-ugly gstreamer1.0-alsa

If you give a crap, it’s a combo of no MP3 decoder being installed by default for GStreamer (despite the existence of an MIT-licensed one), and dependency fail in Lubuntu (which uses ALSA, but inherits defaults from Ubuntu which uses pulseaudio).

I encountered this bug in Lubuntu 16.04, but a related report dates back as far as Lubuntu 13.04 – at least three years.

You’re welcome. :|

Complete accounting of sadfeels

A little background: I’ve fallen on hard times. My music library has been offline for years, at least 2 years if not more. I’m trying to restore it for the sake of my sanity, and all I have to work with is a 2008 Macbook running Lubuntu 16.04 – a choice of operating system not taken for the sake of my sanity, as you will soon see. I’m using Lubuntu due to economics.

Here’s what I’ve had to do in order to import my old library and get playback of MP3 music file working. MP3 is a codec which I first used in 1998. Importing and playing music should be dead simple in Banshee 2.6.2. It’s anything but. Unfortunately, I’m stuck with Banshee on Linux just like I was stuck with iTunes on OS X, because I’m a heavy user of smart playlists – when the apps manage to function at all, anyway.

It’s worth noting that Audacious, the lightweight music player installed by default in Lubuntu, was able to play MP3 out of the box as YHVH intended because it is fucking 2016 why is this a problem.

  1. Import my old iTunes media library into Banshee. Wait, no, that causes Banshee to freeze.
  2. Disable some plugins, then import! Wait, no, that causes Banshee to crash.
  3. Disable ALL the plugins except the import plugin, then import! It mostly works – a truly earth-shattering accomplishment for a program under development since 2005 and billed as version 2.6.2 (except in the Ubuntu package, which is billed as “2.9.0+really2.6.2-7ubuntu2,” I shit you not).
  4. Double-click the file and play! Wait, no, that pops up a red X icon for the given song and the next 4 songs, with no other feedback at all. Cute.
  5. First examine ~/.config/banshee-1/log and then run ‘tail -f’ on it while trying to play the MP3, in an attempt to figure out what the fuck is going on. (Why do I need to know about the existence of a log file for a fucking media player? Because I am in purgatory, that’s why, and nothing is ever simple.)
  6. Of course, there is absolutely no related human-readable output for an obvious playback error in the FUCKING LOG FILE.
  7. Do the next least-worst thing and search a vaguely-unique-sounding term in the log file which may or may not be related. BTW, 99% of users would have given up at step 1 and be left, if they had my library, trying to choose from within 89GB worth of music with the file manager.
  8. Receive vague hints from Internet that GStreamer (why do I need to know this exists?) may be “broken.” At this point, I begin to suspect licensing fail resulting in no MP3 decoder installed by default. At the moment, I don’t remember if Lubuntu 16.04 asked me about installing non-libre plugins, but if it did, this would be a GREAT candidate. :|
  9. ‘sudo apt install gstreamer1.0-plugins-ugly’ (since if there’s a plugin which handles MP3, Fluendo or otherwise, it’s likely to be “ugly,” because nerds).
  10. Double-click the file and play! NO FUCKING AUDIO OUTPUT. Begin writing this post because I need to vent and because I suspect documenting my tribulation will help at least 3d6 benighted searchers to play a FUCKING MP3 FILE on their FUCKING COMPUTER.
  11. Take a break to update a bug report on banshee, file a different bug report on banshee, and file a bug report on lxpanel for shits and giggles (volume control UX needs work). Plan an additional bug report on gstreamer for its utter lack of useful error messaging.
  12. Determine that additional gstreamer apps are also pretending to play back a file but producing no output. I’d installed totem in step 7 in order to confirm that the original playback fail was gstreamer-related. Indeed, totem is also exhibiting the new playback fail.
  13. Search ‘gstreamer “lubuntu” audio’ and find a bug from 2013 that is related.
  14. ‘sudo apt install gstreamer1.0-alsa’
  15. Double-click the file and play! Finally, it fucking works. Well, not for M4A files, but that’s another rant.

So by my count, I need to file the following bugs:

  • gstreamer error output is useless in the context of a missing MP3 decoder
  • Lubuntu has a dependency problem; gstreamer 1.0 installs a pulseaudio “sink” by default, but Lubuntu uses ALSA, not pulseaudio.

I’m tired, and I don’t get paid for this. But hey, now I can listen to the 70% of my library that’s not encoded in AAC.

Edit: If you want to play AAC (M4A) files, ‘sudo apt install gstreamer1.0-plugins-bad-faad’

Missing man pages on CentOS, or reason № INT_OVERFLOW why I hate CentOS/RHEL sofa king much.

I can’t remember all of find’s arcane incantations. Nobody can.

$ man find
No manual entry for find

wat. find is clearly installed, of course. man pages? nope.

Search search search. Searchity search. Horrible relevancy because what are you gonna get when you think you’re smart, do rpm -ql findutils and note that /usr/share/man/man1/find.1.gz doesn’t exist, and then start searching for how to find packages with missing files using Red Hat’s primitive yum and rpm commands.

It was only when I gave up and searched on “centos missing man pages” that I found the answer.

# yum install man-pages

Yes, seriously.

$ cat /etc/redhat-release
CentOS release 6.5 (Final)

Released 1 December 2013. So I guess I can’t ask what fucking year it is.

Linux users on Apple machines: how to find the system product name of your Mac

Here’s another nugget I’m dropping in the hopes it’ll get indexed, because I have a hell of a time remembering how to find my Apple Mac type in Linux (where by type I mean things like “Macbook4,1” or “iMac6,1” and the like). Finding the exact model of Mac you’re running is often useful when debugging the all-too-frequent rough edges of Linux running on a Mac.

Be advised, I’ve only tested this in Linux Mint. I expect it will probably work fine in Ubuntu and likely Debian.

In Terminal or on the command line, to find what model Mac you’re running Linux on, simply run

sudo dmidecode -s "system-product-name"

Installing Linux Mint 17.1 “Rebecca” (based on Ubuntu 14.04) on a 2008 Macbook 4,1

Nice clickbait title eh?

So I’m trying to get Linux Mint 17.1 “Rebecca” fully, really working on a 2008 Macbook 4,1. Fully working means webcam support (touchpads in another post maybe). It turns out that other drivers (2014) for other Apple bits existed as well, now in various states (2012) of possible abandonment (2006). Oh, and as we all know, Linux Mint 17 is based on Ubuntu 14.04 LTS which are important keywords too.

iSight webcam and AppleUSBVideoSupport firmware

The iSight webcam doesn’t work because of AppleUSBVideoSupport.kext being a binary blob that I don’t have. When I install the isight-firmware-tools package (now helpfully a part of Ubuntu / Mint 17, I think) it asks for the firmware file for the iSight webcam on the Macbook.

Dear reader, maybe you’re missing AppleUSBVideoSupport.kext as mentioned in all those other posts you found, or maybe you found it and you need the file size and hash to sorta-verify that the NSA didn’t mess with it. People won’t host it because of the chilling effect of Copyright Fear due to it being a proprietary Apple firmware blob, so best of luck.

Well I found two AppleUSBVideoSupport files (people often post it without the .kext):

  • One is 86744 bytes, found at two locations online, with ‘shasum’ b69f49d3fa6858416324c390effe14336a1ddb0b
  • One is 86712 bytes, found at one location online, with ‘shasum’ 01e291d529e7c18deea2eba252d18114e096276e, its ‘md5sum’ MD5 hash was mentioned online (in 2007) as 8b78709d02d3584f40cc041db9eecfe8.
  • Two others are mentioned online (in 2006): “Leopard” (OS X 10.5) with shasum of a14c159b176d27a6e98dcb5dea5d78b81e15ad41; and unpedigreed firmware with shasum 86430c04f9b67c5c3d84409138a7679827025ec2. I did not find these files online.

I have no idea if any of these files are legitimate but one I found at two download links, another I found at only one. I would appreciate somebody checking the shasum of their latest OS X 10.4 or 10.5 (these are the last two rumored to work as a binary blob on Ubuntu systems). It can be found at /System/Library/Extensions/IOUSBFamily.kext/Contents/Plugins/AppleUSBVideoSupport.kext/Contents/MacOS/ from what I hear.

Comments are open.

Everything Else

Every other driver for Apple computers running Ubuntu or Linux Mint which is mentioned here (last edited 2009 at this writing) appears abandoned (2012) except for these fan and boot (?) drivers (2014).

Edit: ‘macfanctld’ appears to be part of Ubuntu and/or Mint now, so I would strongly recommend doing an ‘apt-get install macfanctld’ and setting the minimums to something sane. Note that it’s buggy on many systems and may not actually adjust fan speed or sense it correctly, so you might just need to set the minimum fan speed to something that will keep your system from crashing.

I’d happily be corrected in these statements. I’ll update the post if I find out something new or receive something in comments. Thanks LazyWeb.

CRITICAL PROTIP: change ssh host keys on Raspbian, Cubian, and all premade images!

So you’re a Raspberry Pi or Cubieboard or BeagleBone hacker, and you download a Raspbian image, or a Cubian image for your Cubie, or whatever BeagleBones run, or, really, any premade *nix image. This applies to virtual appliances and prebuilt Virtualbox and VMware server images, too!

What critically important thing will you probably forget to do, that you’d never notice amiss (but the NSA will)? Change the ssh host keys.

I can’t overemphasize this enough. If you are using a premade Linux image of any kind, or an image of any OS which has ssh host keys, then other people already have your private keys. You NEED to change them, right now.

This can be accomplished pretty easily on a Debian based distro. I’m taking this straight off ServerFault, if you want a peek at all the answers (including those that will work for *hrk* Red Hat descendants).

The simplest solution

This one is courtesy of Pascal Polleunus on ServerFault.

  1. Become root, or tack ‘sudo’ on the front of all the following commands.
  2. Delete old ssh host keys: rm /etc/ssh/ssh_host_*
  3. Reconfigure OpenSSH Server: dpkg-reconfigure openssh-server
  4. Update all ssh client(s) ~/.ssh/known_hosts files – otherwise you’ll get the REMOTE HOST KEY HAS CHANGED freakout message – and if you see that message and don’t expect it, tread carefully – something very much like that but cleverer[1] is how my team came in 2nd in a penetration contest in a hands-on security class at Portland State.

Want a stronger RSA ssh host key than 2048 bits?

Some people prefer an RSA key of 4096 bits. I don’t disagree with them; RSA is getting a bit long in the tooth. To get a 4096 bit ssh host key, you can either do the above and then, as root:

  1. ssh-keygen -N "" -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key
  2. service ssh restart

Or, follow Olipro‘s generic procedure (which should work for *ulch* Red Hat type distros) and add -b 4096 to the RSA host key generation command. Note, you can’t really increase DSA key size[2], and I don’t believe there’s any security benefit to increasing ECDSA key size.

1. It wasn’t quite so bad as one of our team members ignoring the HUGE WARNING MESSAGE that OpenSSH gives off when a host key changes. This was 2007, so the details are hazy, but our attacker managed to gain access to our system as a sudo-blessed user with a man-in-the-middle attack. We were using an RSA host key, and he did an ssh version of the SSL stripping attack: he stepped in the middle, handed our team member a DSA host key when signing in, the team member saw the “new host key” message which is much less freaky than the key-change message, thought “that’s mildly odd” and proceeded to log in. Game over, man, game over.

2. DSA key size is specified in some standard somewhere, and as with ECDSA, I’m not sure there’s any benefit to increasing key size anyway at this point. Let me know if I’m wrong about either of those, though.

How to install bigger (or prettier) mouse cursors on Linux Mint Cinnamon

So, this turned out to be not as easy as I’d like, especially for Mint, but here’s a quick HOWTO and two related bugs.

  1. Visit the somewhat unpromising-appearing for all sorts of bells and whistles which may or may not work with Cinnamon on Linux Mint; however, mouse cursors (“X11 Mouse Themes” as they are called on should work.
  2. Obsidian X11 mouse cursor theme image

    Obsidian X11 mouse cursor theme

    Pick and download a theme. I wanted BIGGER mouse cursors – unfindable mouse pointers are the bane of tons of screen real estate and small default cursors; nothing to do with my age and eyesight – so I downloaded the Obsidian Cursors 1.0 theme, but there are tons of choices.

  3. You’ll get a .bz2 file; uncompress it and you will find two folders and an “index.theme” file.  Here’s where the above-mentioned bugs come in; sadly, you can’t yet in Linux Mint 15 “Olivia” just right-click that file and install the theme. :(
  4. Create the directory ~/.icons if it does not exist. In the shell, this can be accomplished by running mkdir -p ~/.icons
  5. Move the directory containing your downloaded cursor theme to ~/.icons.  In my case, I did mv ~/Downloads/Obsidian ~/.icons
  6. Go to Menu > System Tools > System Settings > Themes > Other Settings > Mouse Pointer. You should now be able to choose Obsidian. Sadly, it doesn’t seem like the pointers are scalable at this time, but it’s there!

If you are really looking for BIGGER mouse pointers in Linux Mint and don’t like Obsidian – and the jury’s still out for me – there is a theme called “Aero Mouse Cursors with Drop Shadow” which contains a set of extra-large cursors that you can try.

My terrible, no-good, very bad non-guide to installing “Cubian” (Debian wheezy) on the Cubieboard 2

As well as my forest of Raspberry Pis, I have a different kind of single-board computer to experiment with, a Cubieboard 2.  tl;dr on the link: dual-core Allwinner A20 (ARMv7 vs Pi’s ARMv6) at a higher clock rate than RasPi; 1GB RAM; 4GB onboard flash; 1 SATA port; microSD slot.  It’s a wee bit more powerful than a Pi.  I got one shipped for $64.50, now it’s a few bucks less.  It’s sort of a China-designed, China-made answer to the Pi, in that it’s an open system:

Anyway, I was discussing tuning a particular app to the limitations of the Pi, and somebody suggested a Cubie 2 instead.  It’s faster, he said, and it runs straight Debian wheezy armhf, not this weird cross-compiled “Raspbian” stuff.

Well, I’ve crashed that poor little Cube-esque warrior enough times on Debian stable to dispel any notion that it, running Debian wheezy, is more stable than a Raspberry Pi running Raspbian.  In fact, the entire reason I’m making this crappy post with a half-assed summary of my install procedure: I need to blow away the installation and redo it.  So, the post is more of a slightly cleaned up version of my notes.  Not a guide.

Update 28 March 2014:  This post is also quite out of date.  It might still be helpful, but Debian on Cubie2 (A20) is still very bleeding-edge.  If and when I come up with a real guide that’s appropriate for the modern day (and not the Jurassic of August 2013), I’ll come back and post a link here.  Read on, but beware. End update.

Thus, the following poor-quality and incomplete non-guide on installing Cubian – I went with some guy’s flavor of Debian wheezy – on your Cubieboard 2.  In case you couldn’t tell from the above, this is a pretty bleeding-edge piece of hardware.  There are plenty of bugs, in Debian stable, right now.  So keep that in mind.  They’ll probably be mostly fixed soon though, and it blows the doors off the Pi for less than double the price – if you actually need more computer than the Pi for your task, anyway.

This following is missing steps and is incomplete.  Mine it for clues.  Following it step by step might make you sad.

I will post an updated, much better guide to doing some things with the Cubieboard 2 in the future.

  • download image – and note that in the 2 weeks since I installed mine, they’d updated the kernel and the installer, so this non-guide is already out of date!
  • write to SD card
  • boot it and install / to the internal NAND using ~/installnand/ or whatever (note: using ext4 for the NAND is maybe not good? not sure if it’s a bare NAND chip or has wear leveling logic. but either way, if you boot from NAND your system cannot fsck itself without a rescue boot microSD, because reasons.)
  • somehow resize the partition so that / was taking up the whole 4GB internal flash
  • partitioned an external SATA drive with 1.5GB swap, 5GB /var, 35GB /home, 830GB /opt … booted again from SD card, mounted /dev/nand3 and all the targets, cd’d to the source and cp -ax * /mnt/target to move em off the old / onto their new homes.  Then edited fstab to point to the right partitions.  Then moved /var to /var.old, /home to /home.old, /opt to /opt.old
  • in both cases, partitioning was a PAIN complaining about misaligned sectors and poor performance.  I followed the advice in _____ but it was just a guide to get me in the ballpark – mkfs stopped complaining when I just guessed at ‘4096s’ for the external 1TB drive, and ‘512s’ for the NAND, cause those were the identical values that popped up for [vars] – told you this was a terrible guide.  It’s really just notes to myself.  Sorry.
  • reboot without SD card.  / now takes up the internal NAND, and /var, /home and /opt are all on the drive.
  • the ethernet doesn’t have a permanent MAC!  forget messing with weird binaries like some guides tell you, just set it before dhclient asks for an IP from the DHCP server:  make a file in /etc/dhclient/dhclient-enter-hooks.d called e.g. ‘setmac’ and put the following in it, where you PICK the mac address to replace xx in the following: /sbin/ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
  • set up encrypted swap as at … no swap was on but I formatted a partition on the SATA disk.
  • fails due to libdevmapper problems?  need to build own kernel, clearly… or wait for them to release newer ones for the A20, which they already did since I went through this pain.
  • ecryptfs-utils doesn’t work, just asks you to install cryptsetup…
  • root@cubie:~# cryptsetup -h sha256 -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/sda1   …. this didn’t work so I gave up for now.
  • Update: Also see this guide and fix your ssh keys, or you’re just handing your stuff over to the NSA:

So that’s essentially it to get you to a poorly running system.  Enjoy!  Come back to my blog in 2d12 weeks for a much better non-non-guide to an awesomely running system.

Other notes:

De-failing the make-jpkg install of Oracle Java 7 JRE on Debian Wheezy (Aug 2013)

So, any surprise this is a clusterf*ck?

Debian has removed Oracle Java from non-free and required the use of java-package to build .debs from Oracle’s binary distributions. More power to ’em; Oracle is considered evil for many good reasons. But, if you do need to taint your system with Oracle’s devilry — and there are plenty of Java apps that say “use the open source Java alternatives at your own risk and tears” — installing it involves dark arts.  Read on.

Update 28 March 2014:  This does not work for Java 8 yet.  Unless you really need Java 8 and you’re sure about that, just install Java 7.  Most applications don’t need Java 8 yet and won’t for a while.  I’ll come back and post a link to an updated guide once I figure it out (and I have to, for reasons).


First (updated 25 March 2014) you’ll need to install the java-package package. I was informed and subsequently confirmed that this package will not be found unless contrib is present in your /etc/apt/sources.list line, e.g.

deb wheezy main contrib

Once you make sure contrib is in /etc/apt/sources.list, you can go ahead and install java-package:

# aptitude install java-package

Then, download the Java “tarball” from Oracle’s Download Page, straight outta 2004:

When I did this, I downloaded what the site claimed was jre-7u25-linux-x64.tar.gz.

Once downloaded in my browser — doing so seems impossible in lynx and with wget, at least easily, so I had to download it to my desktop and scp it to my server, awesome, thanks for that — I actually got a file named jre-7u25-linux-x64.gz.

Upon observing that, you might think “that’s a gzip file, maybe wrapping one of those .bin files some of the java-package docs were mentioning.” Nope! It’s a bare tar file but with a .gz extension.  Not even .tar.gz, but .gz.

So, upon figuring that out, you’d gzip it — make-jpkg really expects a gzipped tarball — and re-run make-jpkg.

Nope!!! ‘This does not look like a tar archive.’ So not only did Oracle mislabel the freaking file twice, but whatever XSLT that told their Solaris tar how to pack the archive was clearly borked. (That’s a Solaris joke.)


tar xvf jre-7u25-linux-x64.gz
tar cvzf jre-7u25-linux-x64.tar.gz jre1.7.0_25 # make a readable tarball
fakeroot make-jpkg jre-7u25-linux-x64.tar.gz


Note to self: modifying a Debian source package, then building the binary.

Self?  Self.  I’m writing you a note since you’ll likely have to do more of this in the future, and for all the sad, sad people coming in from search engines.

It was difficult to figure out, as somebody who’s always just said “the hell with it” and build straight from source, to try The Debian Way and build a Debian binary package from a Debian source package.  Debian provided the software I needed as a binary package, but I needed to make a small change to how it was compiled.  It’s with frank embarrassment I admit I’ve been a user of Debian (and descendants) for ten years and never run into this yet – well, I did, but I always just built from scratch instead of packaging.

Anyway, my sob story: I’d got an SSL cert that was made with OpenSSL and it was proving troublesome to use with ngircd, which the Debian Commies (bless them all) built with GnuTLS support.  I didn’t feel like getting a replacement cert – this one was signed by a CA already, and yadda yadda, shave one yak to avoid another.

Anyway, I had to dig and dig to figure out the incantations, but here’s the process I went through to build my own local Debian binary package of ngircd with OpenSSL support.

# cd /usr/src
# mkdir ngircd
# cd ngircd
# apt-get build-deps ngircd
# apt-get source ngircd

Note, apt-get build-deps didn’t install openssl-dev – of course, it’s not a dependency for the official package, but it also doesn’t exist in Debian 7 (wheezy) and no I do not want to know any of the backstory behind that.  Anyway, the code built on my system just fine, thankfully.  Here’s what I did to change the ./configure parameter and then build a Debian package out of the modified source:

# cd /usr/src
# cd ngircd-19.2
# vim debian/rules # edit 'configure' params, sub --with-openssl w/ --with-gnutls
# dch -i # enter a changelog entry
# debuild -i -us -uc -b

Now it chastises me for linking GPL code with OpenSSL, but there is a compiled binary .deb in the parent directory.

If you’re wandering in from DuckDuckGo trying to figure out how to build a Debian deb-src package from source because you need to make a small change and compile a binary Debian package from it, well, I hope this simple example is of some use.

I am quite sure it gets worse from here as the complexity of changes you wish to make increases.

Pythonbrew warts on Debian Squeeze 6.0

I think the Pythonbrew developer is on vacation. There are a lot of outstanding pull reqeuests.

Anyway, I just created a new Debian 6.0 ‘Squeeze’ VM and installed Pythonbrew on it, but building Python was problematic:

$ pythonbrew install 2.7.3
Downloading Python-2.7.3.tgz as /home/gordon/.pythonbrew/dists/Python-2.7.3.tgz
######################################################################## 100.0%
Extracting Python-2.7.3.tgz into /home/gordon/.pythonbrew/build/Python-2.7.3

This could take a while. You can run the following command on another shell to track the status:
  tail -f "/home/gordon/.pythonbrew/log/build.log"

Installing Python-2.7.3 into /home/gordon/.pythonbrew/pythons/Python-2.7.3
Downloading as /home/gordon/.pythonbrew/dists/
######################################################################## 100.0%
Installing distribute into /home/gordon/.pythonbrew/pythons/Python-2.7.3
ERROR: Failed to install setuptools. See /home/gordon/.pythonbrew/build.log to see why.
Skip installation of setuptools.

Installed Python-2.7.3 successfully. Run the following command to switch to Python-2.7.3.
  pythonbrew switch 2.7.3

I could swear I’ve seen this before, I thought, and started searching. Eventually I gave up and just went to the Pythonbrew issues at Github. That’s where I found my own description of the problems building setuptools with Pythonbrew on Debian 6.0 Squeeze, followed by a very simple solution. This should also work for building Pythonbrew on some versions of Ubuntu.

(This includes additional dependencies that Github user alienone pointed out.)

sudo apt-get install curl build-essential zlib1g-dev libbz2-dev libreadline-dev \
  libgdbm-dev libssl-dev libsqlite3-dev libxml2 libxml2-dev libxslt1-dev \
  libgdbm-dev libgdb-dev libssl-dev libexpat1-dev libncursesw5-dev