A new version of Deluge is out. Version 0.5.8.3.

Change log;

• Fix remote exploit which could crash Deluge
• Fix high cpu spikes
• Fix torrent order between sessions
• Fix loading of BlocklistImport pluginDownload Deluge 0.5.8.3 here.

Source: Deluge

A new version Deluge is out. Version 0.5.8.2 promises to fix the crash issues faced by many users.

Changelog,

Deluge 0.5.8.2 (24 January 2008)

• Fix column width saving
• Option to download new blocklist after certain number of days - Patch from Mark Stahler
• Fix ui-locking when tracker responded in non-utf8 encoding
• Remove Extra Stats plugin
• Prevent Scheduler plugin from setting an invalid ‘max_active_torrents’

Download Deluge 0.5.8.2 here.

Source: Deluge

I’ve been hit by bug #345131 since updating to the latest xorg-server [7.2-143.9] security update on my openSUSE 10.3 installation. xorg-server version 7.2-143.6 to 7.2-143.9.

VLC, Filezilla and a few other applications stopped working. The bug has something to do with the X Window shared memory (MIT-SHM) overflowing.

My error,

The program ‘Filezilla’ received an X Window System error.
This probably reflects a bug in the program.
The error was ‘BadAlloc (insufficient resources for operation)’.
(Details: serial 1072 error_code 11 request_code 147 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the –sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Few hours of Googling and experimenting later I found my fix. 3  actually.

Continue Reading ->

Upgraded my Rails to 2.0.2 and RubyGems to 1.0.1.

1. gem –version to check your gems version.
2. sudo gem update –system to update your gems.
3. sudo gem install rails to update rails to the latest version.

See outputs on the next page…..
Continue Reading ->

Another issue that popped up tonight. The time on a payroll server seem to be slower then usual. Futher troubleshooting on the box revealed that it took 4 seconds to move 1 second on the server. This caused the payroll servers to stop communicating between each other as time sync was part of a security measure built into the payroll software we run here.

Some googling later it seem to be a BUG with the kernel. The fix, suggested to either update the kernel, recompile the kernel or add some kernel parameters in GRUB to fix the issue. I decided to go with the kernel parameters because this was a production server and the downtime window was very slim.

The fix,

1. vi /etc/boot/grub.conf
2. Add to the end of the kernel line. “clock=pit noapic nolapic”
3. reboot and check time. “watch date”

Continue Reading ->