Yet Another Waste of Space

I have a Sansa Fuze v2 digital audio player that I bought a few years back for peanuts. It’s been a great little device for listening to my music while on the go, and it doesn’t lock me in to vendor-specific applications for managing my music collection like some other players on the market. The Fuze also supports video playback, but I’ve never been much interested in that feature. For one thing, the screen is tiny. I prefer watching high quality video encodes on my TV or computer screen. However, it may be handy to be able to watch videos on the Fuze from time to time.

This is where the problems start. While managing music is as simple as copying files to the device (which shows up as a USB mass storage device), it has fairly draconian limitations on video playback. Sansa has a windows-only application called Sansa Media Converter which takes videos of varying formats as inputs and converts them to a format playable on the Fuze. Fortunately some enterprising people have determined exactly what is needed for videos to comply with the restrictions and have come up with solutions that work for non-Windows users (or Windows users who don’t want to use Sansa’s application).

Two new packages have been added: video4fuze is the front end to all of the pieces needed to transcode videos and fuzemux is a utility to convert AVI files to the proper format. (video4fuze uses fuzemux.)

These can be download from the packages website, or the build scripts can be downloaded from the SVN repo.

For whatever reason I had only been signing the CHECKSUMS.md5 file for my package repository, and not the packages themselves. Now I have implemented automatic signing of packages as they are added and updated in the repository. Now, a GPG signature file will exist along with the corresponding binary package. This will only be available for packages for 13.37 and on.

The repository is available from the searchable website or browsable via FTP. The GPG key used to sign the packages can be found on the Links page.

Wireshare 1.4.7 has been released. This is a bug fix and security release (more info). I have built a new package for Slackware64 13.37, and it is ready for download.

Generally I prefer a constant look and feel to the applications running on my computers, regardless of the window manager, desktop environment, widget toolkit, etc. that I happen to be using. QT 4 applications already behave quite nicely in a GTK+2 environment. However, I’ve been toying with the idea of moving back to KDE from Xfce. Because of this I looked for a way to get GTK apps to fit in with KDE apps. Enter oxygen-gtk. This is a GTK+2 theme engine that provides the default KDE theme, Oxygen, to GTK+2 apps.

A binary package has been added for Slackware64-13.37. It can be downloaded from my packages website, and the SlackBuild script can be downloaded from the SVN repo.

Only three weeks late this time around. All of the slackbuilds and binary packages for Slackware64 13.37 are ready to go. I still don’t have packages for both 32- and 64-bit architecture. Only the 64-bit binaries are ready to go. I do still intend to work out a fairly painless way for me to maintain both concurrently, but my time has been limited.

Binary packages can be downloaded directly from from the package browser website. People interested in the SlackBuild scripts for building their own packages can grab them from the SVN repo.

Changes from the Slackware 13.1 packages are listed below.

Additions:

atkmm (Needed for gtkmm)
drawtiming (Tool for generating timing diagrams)
kfilebox (Unofficial KDE Dropbox client)
libreoffice (Replaces openoffice)
sigrok (Open Source logic analyzer software)
jack-audio-connection-kit (Renamed from jack to match the source tarball name)
glib-networking (Needed for libsoup)
libgdata (Neede for libcamel and totem)
pywebkitgtk (Needed for Miro)
libcanberra (needed for Brasero)
libgsasl (Needed for pokerth)
sshfs-fuse
podofo (Needed for scribus)
scribus (Desktop publishing software)
lyx (WYSIWM layout software)
pdftk (The PDF toolkit)
pinta (Simple drawing/painting program)

Removals:

freetype (The bytecode interpreter is turned on by default in Slackware’s official freetype package now)
openoffice (Replaced by libreoffice)
libsndfile (Slackware includes a package for this now)
jack (renamed jack-audio-connection-kit)
pygtk (Slackware has suitably up to date package)
ktsuss (this may be a dead project)
gnome-python-extras (requires libgtkmozembed, which is no longer part of Seamonkey)
gstreamer (Slackware’s package is suitable up to date … for now)

Pat and crew recently released a new version of Slackware, 13.37. I am now starting the process of building my packages for this new release. A notice will be posted here when they are finished (or mostly finished minus a few stubborn packages).

One of the changes I will be making this time around is that my build scripts will (should) automatically detect the target architecture and build a proper package. If you’re building on x86, you’ll get a package for i686. If you’re building on x86_64, you’ll get an x86_64 package. No need to edit the build script to make this change (idea copied from the official Slackware build scripts). Also, package versions should be automatically determined by the tarball placed in the directory with the build script (idea copied from Slackbuilds.org).

I still plan on automating builds of my packages for both x86 and x86_64. That is something that will have to wait until time permits. In the meantime my packages will be built only for x86_64, and x86 users will need to build using my scripts.

Sure enough, just a few days after I piece together a working SlackBuild for LibreOffice, they release a new version. The good news is once a working build script is found it is mostly painless to build newer versions (unless they change too much upstream and their patches break again).

The Slackware64 13.1 package for LibreOffice 3.3.2.1 is available to download from the packages website. The build script can be found in the SVN repo.

I’m looking to get a toolchain setup on my computer(s) for development of software for a few embedded development boards. In preparation for that I have added the following packages for Slackware64-13.1:

crosstool-ng: A script inspired by the Linux kernel ‘make menuconfig’ interface aimed at simplifying the task of building a cross-development toolchain.

openocd: The Open On-Chip Debugger. Provides debugging and programming access to certain processors through JTAG.

libftdi: A library that provides access to FTDI USB devices which are often found on embedded development boards. Needed for openocd.

The binary packages for Slackware64-13.1 can be found on the packages website. Access to the build scripts is available through the SVN repository.

Updates with new packages have been fairly sporadic over the past few months. This is a big one, though. I have built a binary package of LibreOffice 3.3.1.2 for Slackware64 13.1. This package replaces OpenOffice. (For those who haven’t followed the drama, after Oracle purchased Sun they basically shoved the OpenOffice developers aside. LibreOffice is a fork of the previous OpenOffice code, being developed outside of Oracle’s influence.)

My time has been fairly well been dominated with school for a while now. Because LibreOffice takes so many hours to build (roughly four hours on my development machine) it can take quite a bit of time before I come up with a working SlackBuild. Basically I start the build process, go to (bed|work|school|dinner|whatever), wait for it to finish with or without errors, tweak the configuration, and start again. Sometimes an upstream patch doesn’t apply correctly. Other times a configuration option will cause the build to finish with an error. At any rate, it took about two weeks of off-and-on tweaking to get a functioning SlackBuild.

Those who want to move to LibreOffice on Slackware 13.1 can find it on my packages website. If anyone wants to build it with different options, or for a different architecture (such as x86, instead of x86_64) the SlackBuild can be found in my SVN repository as always.

Recently I’ve been creating a number of new OpenSSL certs and keys for an email server deployment I’m working on. My general method for doing this is creating a config file for OpenSSL, creating a CA, and using that CA to sign private certs, all using the ‘openssl’ command line tool. This works fine for email servers, as SMTP servers on the Internet will generally function fine using an anonymous TLS session. Paying for SSL certs for SMTP servers is usually not required.

It’s not always easy to remember all of the OpenSSL parameters, commands, functions, etc. that are to be used when creating a private CA and private certs. Thinking that a GUI frontend for OpenSSL may help me in the future, I set out looking for one. I remember using TinyCA years ago. However, development for that program seems to have ceased. Looking further I ran across XCA.

XCA is a Qt based OpenSSL frontend. I’ve built a package of it for Slackware64-13.1. Using it is easy enough. I’m not yet convinced using something like XCA will be any easier than managing certs and keys from the command line, but having options doesn’t hurt. If you’re interested, feel free to download the package here:

xca-0.9.0