Linux

For quite some time we've had to use, the fairly brilliant Linux - Windows layer called Wine to get YuuGuu to run on our Linux boxes.

Well no more! YuuGuu have released a native Linux version, available for Ubuntu, Fedora and Suse flavours (which can probably be coaxed to work on other distributions as well). This works fine for i386 (32bit) CPUs but not on our machines with the 64bit ones.

After a bit of digging and playing about, we've found they've also got native 64bit versions in testing and that works well, so there's no more need for us to use Wine in order to run this very useful screen sharing application - life's a little less complicated now.

This cured things for blank windows with the Zend Studio IDE and Business Accountz both of which I use daily!

The only one minor thing it didn't quite pull off was getting the attached usb hard drive back in action - a quick unplug and replug later and it's sorted.

This is quite cool, however I'm just in the middle of downloading another kernel update and I hope that keeps the progress made with suspend and resume on this laptop.

So the simple solution is to get the VMware init script to check for and re-create the nodes as required:

Add the following just under the start) line in /etc/init.d/vmware

   start)
# Start insert
      if [ ! -e "/dev/vmmon" ]; then
         mknod /dev/vmmon c 10 165
         chmod 600 /dev/vmmon
      fi
      for a in `seq 0 9`; do
         if [ ! -e "/dev/vmnet$a" ]; then
            mknod /dev/vmnet$a c 119 $a
            chmod 600 /dev/vmnet$a
         fi
      done
# End insert
      if [ -e "$vmware_etc_dir"/not_configured ]; then

Which recreates the nodes that are required - just need VMware to pick that up for future versions. Remember, you'll still need to re-run vmware-config.pl after a kernel upgrade.

The other symptom I noticed was that dbus-monitor or anything else that connected to dbus session would fail with a 'connection refused' message.

After trawling round the net, I found a Redhat Bugzilla posting that resolved the issue - between FC4 and FC5 the location of dbus-daemon had moved from /usr/bin to /bin (and also dbus-cleanup-sockets). The yum upgrade for the dbus packages had not removed the FC4 versions from /usr/bin so a quick rm /usr/bin/dbus-daemon and rm /usr/bin/dbus-cleanup-sockets followed by a reboot sorted the problem altogether.

Perhaps that should be added to the Yum upgrade FAQ on Fedora wiki. Another small but annoying problem resolved

Firstly I checked with the bank - "At the moment, we can't transfer account information to popular accounting packages or spreadsheets. Although we haven't got a definite date for introducing this facility, it has been scheduled for inclusion in our Online service and we'll let you know as soon as it's available."

I'm not the sort of person to be foiled by that sort of response so embarked upon working out a reliable import routine - especially as the online statement is just an HTML table which can be imported into most spreadsheets with ease.

Grisbi supports the QIF format for importing data as well as a few others, so that was my target format. I came across a macro for Open Office Calc (there's also a similar macro for Excel) that exports to the QIF format. So I tried a simple save of the transaction history of my online statement as an html file. This I then opened into oocalc and the transactions were imported, a few row and column deletes later to clean up the un-needed elements and I was left with a list of transactions ready to export.

After a little playing about with the CALC2QIF macro, I was able to get the columns sorted to the order that Grisbi expected (I actually did this using a new sheet, pulling in the data I wanted from the online source). A quick save to qif format later and import into Gribsi and I soon had 2 years worth of banking history imported, acurately too - there were no missing transactions - Brilliant!

So just thought I'd share that to encourage others to circumvent the brick wall that is the bank and do it the underground (but reliable) way - link a few tools together - enjoy.

Same problem, anything to do with rpm resulted in a segfault. Oh dear, or similar sentiments thinks I, best check what's going on elsewhere on the system - all seemed fine as usual, still got web server, mail etc.

I tried digging around in yum, rpm and message logs - nothing of any interest, so I remembered that you can do a rpm rebuilddb as detailed on rpm's site however, that also failed with a segfault so it was obviously something a little more serious, but at least now I'd backed up the /var/lib/rpm directory which I'd need later.

This stumped me for a while, so I started looking at a lower level using 'strace -f rpm' to see where things failed - always at the same point just after loading /lib64/tls/libc.so.6 - so I uploaded, did I mention this machine is remote, a replacement copy of the underlying libc-2.3.4.so and rsync'd it into place - no change rpm still segfaulting. After pondering, googling, trawling and no enlightenment later, I headed over to the nice folks at #rpm on irc.freenode.net, who were initially equally puzzled. Then, jbj (I think), mentioned about using rpm2cpio.sh - a shell script to unpack an rpm file when rpm is not installed / working etc. - which I'd obviously not spotted before.

So here's how it was fixed - so I don't forget, and because it may be of some use to someone else : Continue reading "Segmentation fault using RPM"