KTorrent vs Anti-Cheater

After updating to SUSE 11.0 torrent client for KDE updated from KTorrent 2.2.1 to KTorrent 3.0.x. But on my favourite tracker I receive "Anti-Cheater: You cannot use this agent" as status message while using KTorrent 3. I installed KTorrent 3.1 - and get same message. But after installing back 2.2.x - everything works fine. So, problem is User-Agent string. It is not very hard to search over KTorrent sources and modify it a bit to change User-Agent string. I already mentioned great tutorial about rpm building, and this time it saved me again...

Get the source
Download the src.rpm file and unpack it. I am using mc to navigate into src.rpm and copy all files from there to /home/to_build/src/ktorrent folder.

Diff to change user-agent
You can add diff to any spec file to apply it before build. It is much better than modify and pack sources back. So, here is my diff to change KTorrent 3.1 User-Agent string from "KTorrent + version" to plain "KTorrent". Now just save it in same folder ("/home/to_build/src/ktorrent" for me).

Modify spec file
Now only few modifications to spec file and time to start building:
Add this lines:

Patch10: user-agent.diff
%patch10

It is easy enough to find where to insert it, there are already few patches applyed.

And now, to enable blocked by SUSE trackers, comment this two lines:

#Patch2: remove-links.diff
#%patch2

Now just build and use your favourite torrent-client with your favourite tracker!

SUSE 11.0 handmade

SUSE 11.0 released about a week ago. As few previous versions, there is lack of proprietary multimedia formats support. And there is few ways to resolve it. First, most common way - to add packman repository and install everything from there, and to find other repositories for freetype2 and few other packages. But I don't like this way. SUSE team did a great job with packages and integration, downloaded from other sources packages rarely have this level of integration. My way - to take official SUSE src.rpm packages from official source repositories, and build it with SUSE build tools.

Preparing:
There is a great tutorial about "build", it will introduce build procedure for you. It will prepare you for reading this article.
Also, there is some packages from internet repository you will need. I don't know why aren't they on DVD. You can store them to folder of provided packages, "/home/to_build/provided" for me. I got them from x86_64 repository, and videolan repository for libmad and libdvdcss.

avahi-lang-0.6.22-68.1.x86_64.rpm
flac-devel-1.2.1-43.1.x86_64.rpm
gconf2-lang-2.22.0-28.1.x86_64.rpm
gnome-vfs2-lang-2.22.0-33.1.x86_64.rpm
gstreamer-0_10-lang-0.10.19-16.1.x86_64.rpm
gstreamer-0_10-plugins-base-lang-0.10.19-24.1.x86_64.rpm
libbonobo-lang-2.22.0-21.1.x86_64.rpm
libcdio++0-0.80-3.1.x86_64.rpm
libcdio-devel-0.80-3.1.x86_64.rpm
libdvdcss-1.2.9-5.1.x86_64.rpm
libgnutls-devel-2.2.2-17.1.x86_64.rpm
libiso9660-5-0.80-3.1.x86_64.rpm
libmad-0.15.1b-5.1.x86_64.rpm
libmad-devel-0.15.1b-5.1.x86_64.rpm
libtheora-devel-1.0.beta2-3.1.x86_64.rpm
libudf0-0.80-3.1.x86_64.rpm
speex-devel-1.1.99.3-28.1.x86_64.rpm
vcdimager-0.7.23-132.1.x86_64.rpm
vcdimager-devel-0.7.23-132.1.x86_64.rpm

Step One - xine
The most important multimedia part of SUSE distro - xine engine. Let's build it first.
1. Download xine-lib-1.1.12-8.1.src.rpm from SUSE repositories and unpack it to some (target) folder.
2. Remove xine-lib-1.1.12-crippled.tar.bz2 from target folder.
3. Download xine-lib-1.1.12.tar.bz2 from official sourceforge website and save it to target folder.
4. Open xine-lib.spec with your favourite editor.
5. Change line like this:
from "%define BUILD_XINE %{?_with_internal:2}%{!?_with_internal:%build_xine_default}" to "%define BUILD_XINE 2".
6. Set Release to "Release: 8.1.1" - it will with pleasure override already installed xine.
7. Modify source declaration from crippled:
from:

Source: xine-lib-%version-crippled.tar.bz2
%if 0
Source: xine-lib-%version.tar.bz2
%endif

to:

Source: xine-lib-%version.tar.bz2

8. Find and comment each of lines to let sources be uncrippled:

Source99: precheckin_cripple_tarball.sh
Patch70: xine-lib-crippled-LOCAL.diff
%patch70

9. Also, change all "mad" and "mad-devel" dependencies to "libmad" and "libmad-devel".
10. just build it:
build --root /home/to_build/root --rpms /home/to_build/provided xine-lib.spec
11. Take your packages from "/home/to_build/root/usr/src/packages/RPMS/".

Step Two - Kaffeine
Kaffeine is best front-end for xine ever-made. Let's build it with DVD support!
1. Download kaffeine-0.8.6-54.1.src.rpm and unpack it.
2. Comment each of this lines:

Patch0: %name.diff
Patch2: messagebox-dvd.diff

3. Build it. I got small problem with some locale files, so you can just add locale files after icons packaging:
from:

/opt/kde3/share/appl*/*/*
/opt/kde3/share/apps/kaffeine
/opt/kde3/share/apps/konqueror
/opt/kde3/share/apps/profiles
/opt/kde3/share/icons/*
/opt/kde3/share/mimelnk/*/*.desktop

to:

/opt/kde3/share/appl*/*/*
/opt/kde3/share/apps/kaffeine
/opt/kde3/share/apps/konqueror
/opt/kde3/share/apps/profiles
/opt/kde3/share/icons/*
/opt/kde3/share/locale/*/*/*
/opt/kde3/share/mimelnk/*/*.desktop

Step Three - FreeType2
There is no subpixel font smoothing in SUSE, so it will be useful for LCD owners.
1. Download freetype2-2.3.5-62.1.src.rpm from SUSE repository and unpack it, for example into "/home/to_build/src/freetype".
2. Download full FreeType2 from official website into same folder ("/home/to_build/src/freetype"), replacing old one.
3. Change two blocks:
from

Source0: http://download.savannah.gnu.org/releases/freetype/freetype-%{version}.tar.bz2
Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.tar.bz2

to

Source0: freetype-%{version}.tar.bz2
Source1: freetype-doc-%{version}.tar.bz2

and from

%define enable_subpixel_rendering 0%{?opensuse_bs}

to

%define enable_subpixel_rendering 1

4. Just build it and install packages from same folder - "/home/to_build/root/usr/src/packages/RPMS/"

That is all! Now you have your SUSE good as new, without less integrated third-party packages and without crippled multimedia. It's time to install win32 codecs from packman and libdvdcss from videolan before first kaffeine launch, install amarok-xine and remove buggy amarok-yauap plugin.

SUSE 11.0 first impression

Yesterday I have installed new SUSE 11.0 linux at home. Impressions are very ambiguous...

1. Package manager works great! Starting from SUSE 10.0 it was slower and slower, scanning repositories for minutes, than hours, checking depencencies, updating indexes and doing lots of interesting, but totally unusable staff. New package manager in 11.0 is faster than light! Adding huge repositories takes less than second, depencency checks are done faster than you can even notice!
Second great improvement for package manager - much better dependencies lists. I hate mono, banshee and other dotnet staff, I totally disregard it. But in SUSE 10.1 and 10.2 I HAD TO install mono just because of some yast pattern. That time I even downloaded few distros to look for SUSE replacement. Why, the Hell, I need software patterns for package manager if there are plain dependencies with straight structure?! But now I am totally happy - no mono, no beagle, no banshee, no gtk-sharps and other crap in my fresh system.

2. Older SUSEs with first boot after installing loaded yast to configure different devices, network and graphics. This did not. It was very hard to read fonts with default screen resolution (1280x1024), while installer worked with 1024x768.

3. Selection of KDE version is very hard. KDE 4.0.4 is very interesting, giving great fast new desktop experience. While there are some leaks: 1) I am not extreme enough to use PIM from unstable 4.1 sources; 2) Alt+Tab hangs sometimes when you have few windows from other users; 3) there is no printer configuration in KDE control center now, and YaST module changed from 10.2 and can't configure it for some reason... So, clicking few hours in KDE4 is great, but I'll wait a month for 4.1 to arrive.

4. It is hard to choose all programs from one of KDE desktops. KTorrent is KDE4 by default, KGet in KDE4 is totally great. But Dolphin will never move Krusader away, K3b and Amarok still not ported to KDE4, Gwenview of KDE4 differs too much from original KDE3 version, and older is much more usable.

No horses for Nurgle forces

There are four major Chaos Gods in Warhammer. Each of them has it's own main idea. And each of them differs so much from others, that it's hard enough to put all of them to one army. But the most separated from others is Nurgle.

Khorne means rage, blood. It is not hard to give horses or other mounts to bloody berserkers. Tzeentch is hope - he is bad only because he is opposite to imperium or Emperor, so he can do everything. Slaanesh is pleasure - nothing evil, just pleasure. But Nurgle is decay. How many animals will accept decay? How many possibilities decay have? Medieval horses were scared by smell of camels, what can we say about Nurgle warriors? Griffins, dragons - who will take decayed champion close to himself? The only way to get horses or other mounts for Nurgle warriors - put decay deep in their minds and bodies. Small job for major Chaos God, but almost impossible for his cults. Only humanity is decayed enough to accept Nurgle without compromises. This guys far from "grean peace", in spite of being green to.

LookAndFeel chooser

You will not dispute that modern desktop application needs some theming, right? And, being Swing developer, few times you tried to solve this problem, didn't you?..

I have solution now: JLAFChooser.
Now, you can just put JLAFChooser component into your setting dialog, and it will make LookAndFeel chosing possible in runtime. Now you have no need to hardcode all the LookAndFeels you know into your classes or XML files, and user can just download few LookAndFeels and put it somewhere in classpath to make it available to JVM.

It has two main variants: when Apply is allowed and when not.

When Apply is allowed your user can choose something from list and check it at once, and may be choose something else.



When Apply IS NOT allowed you can just show list of possible LookAndFeels, and save somewhere to preferences user selection, to apply it next startup.


Usage is similar to JColorChooser, with few extensions - you can get LookAndFeel instance, it's name or it's class name. Methods to apply and restore LookAndFeel are public, you may use them for your controls.

PS: feel free to mail me for suggestions, bugs, or just to talk about Java, Swing, religion, fantasy or anything...

current KDE version determination

I have a problem. KDE4 is comming, and I need to determine current running version from Java application. Do you know how?

After some investigations I found few ways. KDE is setting it's own env variables. For KDE3:

KDE_FULL_SESSION=true
DESKTOP_SESSION=kde

For KDE4:

DESKTOP_SESSION=kde4
KDE_SESSION_VERSION=4
KDE_FULL_SESSION=true

But it works only for SUSE, Kubuntu have only KDE_SESSION_VERSION=4 and KDE_FULL_SESSION=true. And this is only for 8.04 KDE4 release of Kubuntu, there was no such flags in 8.04beta. So, determination is simple:

public static boolean isKDERunning() {
  return "true".equals(System.getenv("KDE_FULL_SESSION"));
}

public static boolean isKDE4Running() {
  if (!isKDERunning()) {
    throw new IllegalStateException("KDE is not running");
  }
  return "4".equals(System.getenv("KDE_SESSION_VERSION")) ||
    "kde4".equals(System.getenv("DESKTOP_SESSION"));
}

If you feel paranoid and want to get 100% result it will be better to run Konsole (konsole --version) and parse output. Output for different versions looks like this:

konsole --version
Qt: 3.3.8
KDE: 3.5.7 "release 72"
Konsole: 1.6.6

/usr/bin/konsole --version
Qt: 4.3.4
KDE: 4.0.3 (KDE 4.0.3) "release 9.1"
Konsole: 2.0

So, parsing code:

public static boolean isKDE4Version() throws Exception {
  Process process = Runtime.getRuntime().exec("konsole --version");
  InputStream in = process.getInputStream();
  byte[] buffer = new byte[32];
  ByteArrayOutputStream out = new ByteArrayOutputStream();
  int read = 0;
  while ((read = in.read(buffer)) >= 0) {
    out.write(buffer, 0, read);
  }
  String output = out.toString();
  int indexOfKde = output.indexOf("KDE:");
  if (indexOfKde >= 0) {
    char v = output.charAt(indexOfKde + 5);
    return '4' == v;
  }
  throw new IllegalStateException("KDE version information not found");
}

And don't fear performance issues - on my Athlon X2 6000+ this operation takes only 26 millis!

life before KDE 4.1

Lots of Linux distros will release major versions before KDE 4.1 will arrive. What for? May be better to still use KDE 3.5.x?

according to Wikipedia:

In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed.

again, according to Wikipedia:

KDE 4.0 was released on January 11, 2008. Despite being a stable release, it is intended for early adopters.[22] Users wanting a stable, "feature complete" desktop may wish to continue using KDE 3.5 for now.[23]

Kubuntu will be released this month with KDE 4.0, Mandriva was released with KDE 4.0.2, and SUSE will be released just few days before KDE 4.1 will arrive, with latest KDE 4.0.x on board.

I am not against releasing. I am just afraid of possible low quality of KDE 4.1 from update centers...

Do you like April 1?

Day of no-news. Every site see their duty to publish some "jokes". What for? Most of them are not funny nor interesting. Titles are the same as everyday yellow press. The only really interesting joke i noticed is this one.