Re: locale-related problems running 32-bit application directly
On Wed, Jul 20, 2005 at 11:39:30PM +, Max wrote: I18N: X Window System doesn't support locale C GLib: Cannot convert message: Conversion from character set 'UTF-8' to 'KOI8-R' is not supported Gdk-WARNING **: locale not supported by Xlib Gdk-WARNING **: cannot set locale modifiers Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported export XLOCALEDIR=$IA32_PATH/usr/X11R6/lib/X11/locale export GCONV_PATH=$IA32_PATH/usr/lib/gconv You may want to set other variables (GTK_EXE_PREFIX, GTK_IM_MODULE_FILE, GTK_PIXBUF_MODULE_FILE, PANGO_RC_FILE etc.) for GTK to be able to find its modules. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X.org and NVidia
On Wed, Jul 20, 2005 at 09:24:42AM -0400, Matthias Julius wrote: I think staying with testing is the best thing to do for non-developers anyways. Has the problem of security updates been solved for testing? If not, using testing is worse than using sid (breakage of a dependency may keep an important security update out of testing for a looong time). Esp. for non-developers who do not tend to know too much about security issues... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrading to current udev is disastrous if not on kernel 2.6.12
On Sat, Jul 16, 2005 at 05:22:34PM +1000, Hamish Moffatt wrote: I can't imagine how it's a good idea to upload a package which depends on a kernel not available for Debian yet. It was a _very_ good idea since my custom udev rules did not work with kernel 2.6.12 and udev 56, and my pendrive got mounted at the wrong place and with the wrong mount options. It can be argued whether udev 60 should have been uploaded to experimental instead of unstable, but that's the maintainer's choice. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrading to current udev is disastrous if not on kernel 2.6.12
On Sat, Jul 16, 2005 at 12:33:12PM +0200, Joerg Rossdeutscher wrote: Packages should not depend on any kernel, since many people run their own. However, I just don't understand why the package has been published at all, since even in experimental there is no 2.6.12. Because people already using 2.6.12 need it, since the previous udev (more precisely, libsysfs that udev uses) had a bug which was exposed by the 2.6.12 kernel. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev badness!
On Wed, Jul 13, 2005 at 08:20:44AM -0700, tony mancill wrote: This kind of misses the point. It's not the stability of the code, but whether or not the packaging system has sufficient information about dependencies for this package. It is perfectly normal for a package in unstable to have unsatisfiable dependencies. In fact this happens quite often ever since unstable exists. udev is special only in the sense that it does not depend on the actual kernel package (and it shouldn't) so apt/dpkg will not warn you. And btw, the latest udev will not even _install_ if you are not running a 2.6.12 kernel. You upgraded too early... When this version of udev migrates into testing it will still cause just as many problems (and for a much greater number of users). There is already an RC bug filed for udev, that will keep it out from testing. udev should probably declare a dependency on a kernel image of version 2.6.12 or later, which would have prevented it from being installed (due to unmet dependencies). No. udev should _not_ depend on any kernel pacakges. There are many users who build their own kernels and therefore do not have any kernel-image packages installed at all. udev must still work in this situation. I think there were way too few significant breakages in unstable lately and new people are not used to how unstable really works (especially at the beginning of a new release cycle). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gaim upgrade
On Wed, Jul 13, 2005 at 03:07:27PM +, Jean-Luc Coulon (f5ibh) wrote: cd to the pool directory i.e cd debian-amd64/debian-pure64/pool/main/g/gaim And get the old files: get gaim_1.3.1-2_amd64.deb get gaim-data_1.3.1-2_all.deb Somewhat cleaner if you have testing/stable URLs in /etc/apt/sources.list then you can do # apt-get install gaim/testing gaim-data/testing Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Fri, Jul 08, 2005 at 08:23:10PM +0200, Goswin von Brederlow wrote: $ apt-cache show liferea-mozilla [...] Depends: liferea (= 0.9.1-1), mozilla-browser, [...] Gabor Does that dlopen mozilla? Looking at the /proc/.../maps file it does. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Thu, Jul 07, 2005 at 05:32:45PM +0200, Thomas Steffen wrote: I wouldn't call that just fine. Setting the environment variables means that you break any 64bit process that Openoffice might want to spawn, which is a certain way to get really strange bugs. I bet that printing using kprinter does not work, for example. I do not have a printer, and I do not use KDE :-) The only remaining problem is a Locale not supported by the C library, falling back to C message that I could not track down so far. Does that mean you consider a system without localisation working? It turned out to be a version skew between the 32-bit and 64-bit glibc. glibc-2.3.2(i386) did not like the locale-archive from glibc-2.3.5(amd64). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-distro binary compatibilty
On Thu, Jul 07, 2005 at 04:56:31PM +0100, Adam Stiles wrote: As I've said before, binary compatibility is irrelevant. In fact, from a security point of view, binary _in_compatibility -- to the point where binaries compiled on one box would not run on any other box -- might be desirable, then there could never be such a thing as a virus. You're naive. Binary incompatibility won't stop macro viruses (and users _do_ want their shiny macros work when they move a document from one machine to an other). Also, AFAIK the world's first internet worm spread partly as C source code and compiled its bootstrap code on the target machine... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Official ATI Driver : problem build fglrx module
On Thu, Jul 07, 2005 at 05:01:37PM -0400, Lennart Sorensen wrote: Also the last I read a about a week or two ago was that the ati driver does not work with 2.6.12 at this time, so unless you have some other patches to apply you aren't likely to get it to work. It works for me using Flavio Stanchina's packaging. For 2.6.12 you have to edit the kernel module source and replace the dev-slot_name references with pci_name(dev) and you also have to fix the inter_module_get() thing (I just commented it out as it is not needed on my setup). Of course since you already have the ATI its too late to recomend staying away from ati and their lousy drivers in general. NVidia and Vmware also have regular problems with new kernels when the internal interfaces change. Actually I heard that the _design_ of the ATI driver is much better than NVidia because they try to use some of the existing kernel infrastructure instead of reinventing it completely. Of course the actual code may be worse. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Official ATI Driver : problem build fglrx module
On Fri, Jul 08, 2005 at 10:17:53AM -0400, Lennart Sorensen wrote: Well I am sure my boss would love if I could make the ati driver work on his Dell X610 which has some quite new ATI chip. I even told him to avoid the ones with an ATI chip in it. Laptops are a different thing. ATI tries to push driver support to the laptop makers (which has _some_ justification since ATI has no control over how its chip is being integrated, and laptop makers are known to do really weird things sometimes). Unfortunately laptop makers do not want to publish Linux drivers themselves. You can say the situation is improving since some years ago the ATI driver supported only the original Built by ATI cards and not the 3rd-party Powered by ATI ones (you had to hack the driver to make it work with a 3rd-party card). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 05:26:46PM +0200, Thomas Steffen wrote: No, for all practical purposes you do not have that. I could not get a single third part binary to work without a chroot. And recommending a chroot is just a different way of saying that it is not supported. Well, Vmware runs just fine without any kind of chroot. OOo also runs fine if you just _install_ it in a chroot but call it from the outside (well, you need to set a bunch of environment variables that point to the 32-bit gconv modules, 32-bit GTK theme, 32-bit GTK Pango modules etc., and some bind mounts for /etc/openoffice and /usr/lib/openoffice that cannot be relocated by environment variables). The only remaining problem is a Locale not supported by the C library, falling back to C message that I could not track down so far. So 32-bit apps seem to work without a chroot; you only need the chroot for package management. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote: Configure scripts have sometimes hardcoded paths to /usr/lib. And /usr/include. Don't forget that some packages install architecture-specific header files under /usr/include. Libtool adds rpath if libraries are not in default system paths and rpath means incompatibility to every other linux out there. Well, libtool can be taught that the new directories are also default system paths, then you only have to re-libtoolize everything. Quite some work but doable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: Also programs don't depend on something like galeon (i hope). $ apt-cache show liferea-mozilla [...] Depends: liferea (= 0.9.1-1), mozilla-browser, [...] Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
