Useful RPM commands in Mandriva

Mandriva provides some very nice commands which wrap rpm and allow you to install/remove packages directly from the repositories and query package information. Heres a short list of some the more useful commands....

urpmi blahblah
Install package blahblah.

urpme blahblah
Remove package blahblah.

urpme --auto-orphans
Remove all orphaned packages (I believe this is a recent addition).

urpmi --auto-update
Update all packages which have update available from one of the update repositories.

urpmi --clean
Clean the package cache on the local harddrive. Useful if a package gets corrupted during download and you cannot install it. Each successive attempt to repeat the install will use the cached version - gotta clean that cache first.

urpmi --test blahblah
Tests the install of a package without actually installing anything.

urpmq --summary blahblah
Display summary information about package blahblah.

urpmf regex
List all packages which contain a file whose name matches the regular expression regex. regex can therefore be the full filename, a partial filename or a more complex regular expression.

urpmf -f regex
Lists all packages as before and also displays the full package version and architecture information.

urpmq regex
Find if a package exists which has a name exactly matching regex. The parameter regex can be a Perl like regular expression.

urpmq -i regex
Display detailed information about a package.

urpmq -a regex
List all packages whose name fully or partially matches the regular expression regex. Useful when you don't know the full name of a package.

urpmq -f regex
Display the package name, version and architecture of matching package.

urpmq -l regex
List all files in matching package.

rpm -q blahblah
Check if package blahblah is installed.

The raw rpm command does allow you to query package information however the package must already be installed.

rpm -qa
List all installed packages.

rpm -ql blahblah
List the files in installed package blahblah

rpm -qi blahblah
Display detailed information about the installed package blahblah.

rpm -qR blahblah
List the packages which package blahblah depends on.

Payment Processing for the ISV

I've recently completed a review of the services available for Independent Software Vendors who distribute their products over the internet. Here is a brief list of the various companies I came across during the review. I haven't gone into the details of pricing and features as these change over time, however this list should help you encounter the key service providers.

Digital River is a large US company which provides e-commerce solutions to software vendors. They offer sales, licensing and payment processing services to large vendors such as Symmantec and Kaspersky. They also provide these services to smaller vendors, shareware providers etc., marketing their platform through a range of websites. Their sites include RegNow, RegSoft, esellerate and Share-IT.

E-Junkie provide order processing, license key distribution, downloads but do not provide payment processing. Their platform integrates with PayPal, Google Checkout and other payment processors. For this reason, they charge a flat monthly fee and the payment processors percentage fee is charged independently. E-Junkie are based in Arizona.

FastSpring provides payment processing and distribution to software vendors. They are based in California.

Kagi also provide payment processing and software distribution services.Yes, they are also based in California.

There are several issues you should have in mind when choosing a company which provides these services:

• Exclusivity. Are you free to sell your software product through other channels concurrently or do their terms and conditions restrict you to selling through their website?
• Fraud Prevention. How good is their fraud prevention? You don't want a high proportion of your sales to consist of providing the license key or software download and then a couple of days later being informed that the payment was canceled because the purchaser's credit card was fraudulently used.
• Chargebacks. If a user complains to the credit card company about not receiving the product or the product not being fit for purpose - how does the payment processor communicate with you and the customer?
• Fees. How do their percentage fees compare to other providers? What is the minimum charge? Are you charged per download or for storage space?
• Taxes. How does the service provider handle sales tax rates or EU VAT rates?
• Funds Transfer. How do you get your funds from the service provider? Must you pay a fee for funds transfers? How frequently does the vendor receive their funds - monthly, bi-weekly, daily?

Bug Tracking for the Lone Developer

Recently, I was looking for an bug and issue tracking application which I could install on my workstation. I need it to manage the issues associated with a fairly large and complex project but I'm not sharing development with anyone on this project so no support for multiple users or remote access is required. There are only a few open source issue tracking applications available which are mature enough to support a large project.
Some time ago I started using Trac. Trac is a web application, written in Python, which requires a web server and database server to be installed. It provides Ticket management and Subversion integration. Tickets can be organised into a pseudo-schedule using Milestones. Unfortunately, most of Trac's configuration is achieved on the command line - there is no administrator interface. This is OK for a very rudimentary project, however, it gets very tedious once the number of tickets starts to grow. (On a side note, I was able to find a Mylyn plug-in for Trac which allowed integration with Eclipse which is a bonus.) So, its goodbye to Trac, largely due to its poor administration interface.
Bugzilla sets the standard for Bug tracking applications. It allows a lot of customisation and is very mature at this stage. The only problem with Bugzilla, as with most web applications, is that to install it on your workstation it will require the installation of a lot of dependencies. Bugzilla will require the install of Apache, a mail transfer agent such as Sendmail and some extra Perl modules. Now I for one, don't feel comfortable having a full web server running on my machine just so I can track issues. Its an extra security risk and another application which requires updates. A safer option is to install Bugzilla within a virtual machine using Xen, VirtualBox or VMWare.
So that's the option I went for but, unfortunately, Bugzilla is a dog to install. Getting Bugzilla to play nicely with Apache is not easy. The standard packages (3.2) for both Ubuntu Server 8.10 and Debian 4.0 do not run OK after install. The forums are full of 'help' on which Apache and Bugzilla config files need to be updated. I won't get bogged down in the details - lets just say I wasted way too much time on this. (I haven't tested the install on Mandriva,CentOS or Fedora.) So its goodbye Bugzilla - life is too short.
The next application I looked at is Mantis. Its like a simplified version of Bugzilla. As with the others its a web app and requires Apache and MySQL. The install is less troublesome and it provides all the basic issue and bug tracking functionality required. It still has the downside of needing Apache etc. installed so the virtual machine route seemed a good move.
Then I remembered BitNami! BitNami provide open source application stacks which are self-contained. You can install the stack any place on your machine i.e. you are not installing an rpm with root privileges. Not only do they provide the basic LAMP stack, they also provide a large range of packaged applications. And yes, they package Mantis. The stack installer is excellent and the stack's directory can be moved around on your machine with no problems. To run the web server, there are start-up and shutdown scripts provided.
The advantage of BitNami is that everything: Apache, MySQL, PHPMyAdmin and Mantis, is contained within that one directory. Apache runs with the standard user's privileges and you can add links to the start-up and shutdown scripts to KDE's start and shutdown directories. Hey Presto - you have a locally installed version of Mantis with nearly zero configuration required.
BitNami seems like a great solution to me for developers who want LAMP based applications installed locally on their machine for testing and development. Its great advantage is that each install directory is self contained - you can install and run multiple stacks and configurations and it requires less maintenance than a VM.

Creative Zen with Mandriva 2008.0

Recently got a Creative Zen 8GB and wanted to manage its music using Amarok. The PC runs Mandriva 2008.0 which comes with Amarok 1.4.8. The Creative Zen does not provide a standard USB mass storage interface so you can't just plug it into the USB port of your PC and start copying files. Creative devices use their own proprietary Media Transport Protocol so Amarok uses libmtp to access the device.
Unfortunately, the version of libmtp which comes with Mandriva 2008.0 is 0.2.1 which does not recognise the 8GB Zen (USB vid:0x41e pid:0x4157) so Amarok cannot connect to the Zen. However, the latest version of the libmtp code does recognise this Zen so the only solution was to rebuild Amarok using the latest libmtp.
Users who want to use their shiny new iPod may also face a similar issue. Mandriva 2008.0 comes with version 0.5.2 of libgpod, whereas the latest version of the code which supports new iPods such as the 80GB Classic is 0.6.0. You'll need a version of Amarok or gtkPod built against version 0.6 if you want to use a newer iPod.
I couldn't find adequate versions of these libraries on a site such as the PLF. Luckily the Mandiva wiki has quiet a good description of how to go about the whole process of rebuilding your packages see Mandriva RPM HowTo. I'm not going into the full details but heres an overview of the steps required:

Create an rpm directory in your home directory and create the required sub-directories as described in the HOWTO.

$ cd rpm
$ ls
BUILD/ RPMS/ SOURCES/ SPECS/ SRPMS/ tmp/

Rather than using the raw library source code to create the new rpms, a faster solution was to find more up-to-date rpms for a later version of Mandriva i.e. 2008.1 or Cooker and use these to build the new rpms for 2008.0. This is done by extracting the spec file and zipped source from the rpm and putting them in SPEC and SOURCES. Edit the spec file to build for 2008.0. When building, it will be built against the -devel libraries you have installed on your machine. Each rpm will have several dependencies so you'll have to install several -devel rpms before the new rpm is build successfully. These will include KDE devel libs, curl-devel, openssl-devel, musicbrainz-devel and many others.
Once all the new rpms are built, remove the old amarok, libmtp, libgpod etc. rpms and install your new rpms. I can confirm that the 8GB Zen works fine with libmtp version 0.2.5.

RPMS which I had to build:

$ cd SPECS
$ ls
amarok.spec gtkpod.spec gnomad2.spec libgpod.spec libmtp.spec

I can also confirm that the iPod Classic 80GB works with libgpod 0.6.0. Just remember that you must edit a text file on the actual iPod to get around Apple's stupid hash. README.sysinfo which comes with libgpod describes the process.