The first problem comes from the X11 driver. See this error in the Xorg.0.log file:
X version mismatch - detected X.org 1.3.0.0, required X.org 7.1.0.0
The debian bug is
420379.
Kano (from Kanotix) brings a solution:
http://www.rage3d.com/board/showthread.php?t=33889029
The second problem is, as usual, the ugly packaging:
ati-driver-installer-8.36.5-x86.x86_64.run --extract /tmp/ati
cd /tmp/ati
Edit packages/Debian/ati-packager.sh and add exit just before the line
${PKG_BUILD_UTIL} ${PKG_BUILD_OPTIONS} > ${TmpPkgBuildOut} 2>&1. We will run dpkg-buildpackage manually:
packages/Debian/ati-packager.sh --buildpkg experimental
cd /tmp/fglrx.XXXX
Replace x-dev by x11proto-core-dev in debian/control. Replace PKG_control := fglrx-amdcccle by PKG_control := fglrx-control in debian/rules. Still in debian/rules, remove the rm usr opt line from the clean target.
Now the package sources are ready, so run dpkg-buildpackage as usual.
This bug happens when paravirtualisation is enable in the kernel:
To fix it just recompile your kernel with CONFIG_PARAVIRT disabled.
I had troubles to find the good append-to-version and revision parameters to create packages which match the official ones:
fakeroot make-kpkg --revision 2.6.20-3jerome1 --append-to-version -1-686 --subarch 686 --initrd binary-arch
Here is a script witch allow to use a 8/5 screen to see 4/3 TV programs. SECAM is a pattern extracted from the title of the windows showing the TV.
#! /bin/sh
xrandr -s 640x480
wmctrl -r SECAM -e 0,0,-48,640,576
Here is how to compile a debian way kernel using the apt-get source/dpkg-buildpackage way:
apt-get source linux-2.6-2.6.20
cd linux-2.6-2.6.20
vim debian/rules
change
$(MAKE) -f debian/rules.gen build-$(DEB_HOST_ARCH)
to
$(MAKE) -f debian/rules.gen build-i386-none-686-real
It will avoid to build for all architecture (486, k7, vserver …). Now create the package.
dch -i
fakeroot dpkg-buildpackage -d -b
To conclude I see no reason to use this method, make-kpkg is better.
Debian Sid now include glibc 2.5. Compiled programs on Debian Sid may or may not run on distro with older libc. If this command display something it means that the executable contains glibc 2.5 specific calls:
objdump -T myexec | grep GLIBC_2.5
To list 2.5 specific primitive just do:
objdump -T /lib/libc.so.6 | grep GLIBC_2.5
Note that libc 2.5 do not add many symbols. See the progression:
$ objdump -T /lib/libc.so.6 | grep GLIBC_2.0 | wc -l
1318
$ objdump -T /lib/libc.so.6 | grep GLIBC_2.1 | wc -l
409
$ objdump -T /lib/libc.so.6 | grep GLIBC_2.2 | wc -l
195
$ objdump -T /lib/libc.so.6 | grep GLIBC_2.3 | wc -l
160
$ objdump -T /lib/libc.so.6 | grep GLIBC_2.4 | wc -l
77
$ objdump -T /lib/libc.so.6 | grep GLIBC_2.5 | wc -l
18
Unfortunnatly debian package will require libc 2.5 even if 2.5 extension are not used. See this extract from #debian-glibc:
[me] [french sorry for my english] Does shlibdeps handle glibc symbol version ? For example if an executable only use GLIBC_2.0 symbols, will it required libc >= 2.5 or only lib >= 2.0 ?
[Clint] no, it's not that smart yet
[me] May be one day ? As it already been discussed ?
[Clint] it's been discussed, but people usually say that it's not worth the effort
[me] ok. Thanks !
[Clint] if you want to write a patch to do it though, that might be useful
[me] Hu ! I would glad to but I guess I would have to learn perl first :-/
