•January 31, 2012 • 1 Comment

After reading a lot of good things about people running linux on the Pogoplug, I decided to pick one up off of eBay.  I settled on the Pogoplug Pro since I was able to get it at a low price (US$25), it had wifi and a dual core processor.

I had intended this to act as a replacement and upgrade from my aging NSLU2 (Slug) that I had monitoring my primary UPS and other trivial tasks.  My goal was to replicate the same tasks as well as move my Asterisk and create an LDAP+mail server.  The slug has worked flawlessly for me over the past few years, I just wanted something with more USB ports, more power and gigabit.  Aside from my cable modem and my (fake) PAP2, every wired piece of equipment I have is gig rated.

Unfortunately, my plan on installing Debian didn’t work out as well as I intended.  The Pro version is using the OXNAS SOC/chipset, rather than the more prevelant Kirkwood platform and there isn’t a real Debian installer like I found with my slug.  Instead, Arch Linux has taken the lead on this.

I’m honestly not that familiar with Arch, I’ve read a bit about it on Wikipedia, but that’s it.  I tend to stick with Gentoo on x86/amd64 or Debian on ARM.

The install guide is well written and includes detailed instructions on how to recover from a stupid move. Their main wiki has proved very helpful so far.  Particularly, I’ve referenced pacman, AUR and the makepkg multiple times.  Their user repository is also helpful for tracking packages down that aren’t in the main repository.

However, I did have a few issues in trying to get Asterisk to run.  The Asterisk server would run then just completely die.  I managed to get it to run, but it took several re-installs before that occurred.  I believe the problem was in the fact that I didn’t have all of my packages updated on the initial installs like I thought I had.  Now, all I have to do is correct my config files to get it talking properly.

Because OXNAS support apparently hasn’t landed in the mainline kernel, I’m stuck using a custom 2.6.31 kernel.

I am trying to get Debian loaded on it, but I haven’t had much luck thus far.  I’ve downloaded the image, followed the instructions, but the damn thing never connects to the network.  I haven’t tried seeing if I can get serial access yet and I don’t have a USB monitor to see what it’s doing.

At the end of the day, I have this to say about the whole thing:  Arch is okay, but not something I’m familiar enough with right now or really have an interest in getting all that familiar with.  Had I known in advance that this iteration would be such a pain and not completely supported by Debian, I would have picked up one of the pink models instead.  I am thoroughly impressed with the work the Arch devs have done thus far to get their distro running and I’ll continue using it and learning about it in order to accomplish my evil needs.  🙂



Falling to the dark side

•December 20, 2011 • 1 Comment

As much fun as it would be, this isn’t a post about Star Wars.  Maybe later…

The dark side, in this instance, is KDE.  I’ve used Gnome as my desktop environment for years now.  Before that, it was Openbox.   With the Gnome team’s great leap forward, I’ve decided the time is right to jump ship.

I’ll be honest, I was happy with Gnome 2.32.  Everything worked to my satisfaction. And while it’s true, I could have blocked the packages in Gentoo to remain on 2.32, it would only have been temporary.  The Gentoo team can’t continue to support old/legacy packages if there isn’t any support upstream.  I get that.   I made an honest effort to run 3.2 for a good month.  The fallback mode is good, the new shell is “okay.”  Even with the add-ons, it’s just not what I want.  I am sincerely disappointed in it.

I’d love to go back to using Openbox completely, but I need to keep options open for the rest of the family that uses the computer.  I feel lucky enough to have a wife that allowed me to move her laptop over to linux and that’s all she uses now.  My goal is to find something familiar enough for her that I won’t get my rear in trouble.

Thus, the switch to KDE.  I’ve read the reports of Gnome detractors claiming that the environment had been dumbed down and options removed or hidden.  I didn’t put much thought into it because for me, everything just worked.  Now into KDE, it sure seems like there are a ton more options available to me that weren’t before.

So far, it’s working out well.  The wife is apparently happy.  I’ll probably switch back to Openbox for my login, I’ve missed it.

Advantages to running a binary distro

•October 31, 2011 • Leave a Comment

As evidenced by the fact most of my linux posts are tagged with Gentoo, I run a source-based linux distribution.  The only reason for that these days is because it’s what I’m used to.  I’ve been running Gentoo since 2002 or 2003.  I’ve thrown it on almost every piece of equipment I can, from a P166 to my quad Athlon II.

While I recently switched my wife’s laptop over to Ubuntu to make it easier for her to manage, I haven’t tried running another distro full time on anything save one.

I’m the proud (?) owner of an NSLU2 aka SLUG that I occasionally power up for random nonsense.  I’ve finally gotten around to upgrading it from lenny to squeeze.  While I could cross-compile everything on another computer, I find it just easier to use Debian’s precompiled ARM binaries.


Another thing I’m likely to forget

•September 30, 2011 • Leave a Comment

While I’m still working on getting the on demand record feature to work in Asterisk, this will work as a manual method.

watch -n1 “asterisk -vvvvvrx ‘core show channels’ ”

This will show the channels/calls in progress.

In another window (just because it’s easier), log into asterisk using “asterisk -r” and run

mixmonitor start ${CHANNEL} ${FILENAME}.wav

This will save your recording under /var/spool/asterisk/monitor.

I’m still trying to figure out what I’m doing wrong that the *3 command isn’t working (Following http://answers.oreilly.com/topic/2741-how-to-record-phone-calls-using-asterisk/)

I’ll forget this later

•June 29, 2011 • Leave a Comment

Building the latest mesa from source
EXTRA_ECONF=”–enable-shared-glapi –enable-gallium-egl” emerge -qv1 mesa

[ebuild R #] media-libs/mesa-9999 USE=”egl gallium gles llvm motif nptl openvg* -bindist -classic -d3d -debug -pic (-selinux) -shared-dricore -wayland” VIDEO_CARDS=”r600 -i810 -i915 -i965 -intel -mach64 -mga -nouveau -r100 -r128 -r200 -r300 -radeon -savage -sis -tdfx -via -vmware” 0 kB [1]

this is because of this:




This was updated in the X11 overlay, but the EXTRA_ECONF trick can come in handy later.

Change of venues

•June 22, 2011 • Leave a Comment

If it’s not obvious, I’ve moved my blog from a self-hosted environment to WordPress.com’s hosting.

So far, my opinion is “meh”.  I’m already missing my custom environment and am chafing under the limitations provided here.  It does fit in my current budget though.

Davmail on Gentoo

•April 7, 2011 • Leave a Comment

Davmail is a java-based gateway for Microsoft Exchange to standards-based protocols.

While I didn’t write the original ebuild, I did write an init script and config and modify the ebuild to run as a service for Gentoo.

Give it a whirl, it’s working for me so far.  Bug 351417.

CrystalHD on Gentoo (again)

•April 7, 2011 • Leave a Comment

I’ve updated my ebuild for the CrystalHD card to reflect not only updates upstream but what I’ve learned through reading sources and other bug reports.

Given I’ve just been creating snapshots from particular days, I had originally opted to use a date-based scheme for the ebuilds.  I read through a bug report (here) that shows how upstream is referencing the version.  That makes sense.

Since the big focus is to get the library and firmware into the tree, I opted to move and rename the library to x11-libs/libcrystalhd.  My reasoning is the module is already in the kernel sources and can be compiled from there.  What other programs will be looking for is the library to compile against.  So, from crystalhd to libcrystalhd it is.   The ebuild still optionally installs the kernel module, which is still my preferred method.

Waiting games

•March 10, 2011 • Leave a Comment

Nothing like waiting 24+ hours for a RAID5 array to finish growing.  Thankfully, the array is still accessible while it’s growing.  That won’t hold true when the file system itself is expanded, but I don’t think that will be take as long.

My biggest fear is a power outage while it’s growing.  My UPS has been acting up lately and shutting down on its own.  I think it’s the batteries, but I’m not sure yet.  So for now, I’m living life dangerously.  Thankfully, the weather is mild without worry of high winds or anything that should take out the power.

Adding the new drives has brought to light my need for a proper case for my server.  At present, I’m using a 10? year old Antec tower.  It’s fantastic and roomy, but as I’m expanding my storage space, it’s becoming too small.  It feels odd to say that since it’s one of the largest cases I’ve ever owned.  So, now I’m looking at a new case.  The one that has caught my eye is the Norco RPC-4220. At 20 hot swappable ports, it has plenty of room to grow.  I’d be able to move my Myth recording array over and actually eliminate an always-on machine at the same time.

Before that though, I probably should get my UPS looked at.  I doubt that they’re meant to be user-serviceable, aside from replacing the batteries, but I’m going to give it a try.

More tweaks

•January 1, 2011 • Leave a Comment

There’s one last bit that’s bothering me about the ebuild, and that’s the version description.  If I clone the git repository directly and compile from there, I get a description along the lines of this:

Please attach all output as a file in bug reports.
MythTV Version   : v0.24-96-gf5e6f3d
MythTV Branch    : 0.24-fixes
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.7.1
Options compiled in:

This is different from what I’ve done.

Please attach all output as a file in bug reports.
MythTV Version   : 2f3a2f8-gentoo
MythTV Branch    : fixes/0.24
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.7.1
Options compiled in:

The branch string is cake to fix.  I just need to see if there is a way to pull the same version string out of the tarball.  We could manually enter that information in the ebuild, but that means more work for someone just looking for a quick bump.

Given the tar/zipball doesn’t include the .git directory that you get when you clone the repository, doing a “git describe –dirty” won’t work.

The info IS included as part of the forwarded URL.   i.e.


turns to


which in turn matches the provided version string.

Continue reading ‘More tweaks’