Debian emacs21: can't bind umlaut keys
Hi, I am using a German keyboard, but usually write languages like "Perl" at least as often as "German" and with the standard German keyboard layout chars like "[]{}" are difficult to reach. Therefore, I had already long time ago written some ELisp code to switch the binding of the umlaut keys between different sets of keykbindings according to my current needs. Unfortunately, it is a little tricky to refer to those keys in emacs lisp (and the exact modalities changed a little since emacs 19). Now after migrating my systems from Suse to Debian (Etch), my key bindings don't work anymore and I can't figure out, what changed. Here a minimal code snippet to illustrate the problem: (defun latin1-to-emacs-char (char-code) (make-char 'latin-iso8859-1 (- char-code 128))) (setq c_ae (latin1-to-emacs-char 228)) (local-set-key (make-vector 1 c_ae) "ae") This should bind the key labeled "ä" to instead insert "ae". technically, it still works on emacs 21.4 in Etch ((current-local-map) indicates the change) but the key still produces "ä". Some side notes: - Emacs is running in unibyte mode - The X server or the console driver (the problem is not X-related, on the console it's the same) produce the expected key event: state 0x0, keycode 48 (keysym 0xe4, adiaeresis), same_screen YES, XLookupString gives 1 bytes: (e4) "ä" XmbLookupString gives 1 bytes: (e4) "ä" After an extended investigation, I know now, that this problem must be caused by some debian-specific change to emacs. I installed several other emacsens on the same system (including a shiny new emacs 22.1 compiled from the original source) and in all other installations, the code snippet above will redefine the "ä" key as expected. Since I am planning to use Debian on lots of machines, I would strongly prefer if there was some workaround for the emacs21 debian package instead of using a self-made emacs on all machines. Unfortunately, I can't figure out, which modification actually causes this and what to do about it. Any ideas? Regards, Peter Daum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meta-R key doesn't exist
Antonio Regidor García wrote: > I don't know if this is a bug, and where to report it, so I tried this list. > The problem is that > my keyboard map has a Meta-L (or Alt-L, or Alt-Left) key, but not a > corresponding Meta-R key, > both in X and the console, using Spanish or English keymaps. The key that > should be the Meta-R > key is mapped in X (according to xkbprint) to "ISO-Level3-Shift". I don't > know which key it is > mapped to in the console, but certainly it is not Meta-R. > Is this a feature of Debian or a bug? It happens with other keyboards? Chances are, that you also don't have a right "Alt" key on your keyboard, but one labeled "Alt Gr" instead, that is intended for entering non-ascii characters (see http://en.wikipedia.org/wiki/AltGr_key). If you don't need any of these (I am not familiar with the Spanish keyboard layout, but I assume there are some accented keys on it), you can simple redefine the AltGr key as Meta_R in your X server's keyboard layout (If you have a newer 105-keys, you can also use on of those "Menu" or "Windows" keys) > This problem makes Emacs very difficult to use without remapping the keyboard. ? Emacs shouldn't care about which Alt key you use Regards, Peter Daum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
apt-proxy: can't use more than 1 backend
I am trying to get apt-proxy to work on a test machine running lenny. Because hardly anything worked as expected, I stripped the configuration down more and more.but it seems that nothing involving more than 1 backend works. Here the scenario: server(lenny) has the following apt-proxy backends: [debian] backends = http://ftp.de.debian.org/debian [debian-security] backends = http://ftp.de.debian.org/debian-security client(etch) /etc/apt/sources.list: deb http://server:/debian etch main contrib non-free deb-src http://server:/debian etch main contrib non-free deb http://server:/debian-security etch/updates main contrib with this cfg, I can only access backend "debian", apt-get update reports: Failed to fetch http://server:/ debian-security/dists/etch/updates/main/binary-i386/Packages.gz when I disable the "debian-security" entry on the client, apt-get update is successful. The really funny part: when I change the backend order on the server so "debian-security" is the 1st backend and restart the apt-proxy, access to debian-security works, but "debian" doesn't. Any ideas? Generally, apt-proxy doesn't really look overly trustworthy (on every start there is a python warning about telnet being deprecated), but there doesn't seem to be any better alternative (I don't want to run a full-blown apache server). Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy: can't use more than 1 backend
Celejar wrote: On Fri, 25 Jul 2008 20:14:54 +0200 Gilles Mocellin <[EMAIL PROTECTED]> wrote: Le Friday 25 July 2008 18:34:17 Peter Daum, vous avez écrit : I am trying to get apt-proxy to work on a test machine running lenny. [...] Generally, apt-proxy doesn't really look overly trustworthy (on every start there is a python warning about telnet being deprecated), but there doesn't seem to be any better alternative (I don't want to run a full-blown apache server). Peter I switched last year to approx, far more stable for me. I, too. I used to have trouble with apt-proxy; I now use approx and I'm happy with it. ...so did I, meanwhile. It seems to have a little less configuration options, but it took ~5 minutes to replace the non-working apt-proxy configuration by approx and so far everything seems to work. one little problem, that I already had with apt-proxy, remains: When installing packages, I always get a warning that they "cannot be authenticated". I think, this only occurs with lenny, not with etch. The keyring is installed... Any ideas? Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
fortune not working
certainly not the most critical problem, but at least on my system (mainly Etch, I also tried the fortune package from Lenny) doesn't work. when I trace it, I can see that it reads a bunch of fortue data files but that is obviously just for its own pleasure - it just silently exits w/o any error. Any ideas? Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fortune not working
Mark Allums wrote: Peter Daum wrote: certainly not the most critical problem, but at least on my system (mainly Etch, I also tried the fortune package from Lenny) doesn't work. when I trace it, I can see that it reads a bunch of fortue data files but that is obviously just for its own pleasure - it just silently exits w/o any error. Any ideas? Peter I bet it is producing output *somewhere*, the question is *where*. That would be pretty amazing, because it isn't even trying to - as already said, when it strace what it does, I can see it opening and reading a whole bunch of date files, but it does not issue a single "write" syscall. There also should be al necessary packages installed (unless there is something essential missing in the dependencies): # dpkg -l fortune*|grep ii ii fortune-mod1.99.1-3.1 provides fortune cookies on demand ii fortunes 1.99.1-3.1 Data files containing fortune cookies ii fortunes-min 1.99.1-3.1 Data files containing fortune cookies -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fortune not working
s. keeling wrote: Peter Daum <[EMAIL PROTECTED]>: # dpkg -l fortune*|grep ii ii fortune-mod1.99.1-3.1 provides fortune cookies on demand ii fortunes 1.99.1-3.1 Data files containing fortune cookies ii fortunes-min 1.99.1-3.1 Data files containing fortune cookies (0) phreaque /home/keeling_ pkgs fortune | egrep '^i' i fortune-mod - provides fortune cookies on demand i fortunes- Data files containing fortune cookies i fortunes-min- Data files containing fortune cookies fwiw, also etch. I can only guess charset clash (ASCII/utf-8), and it knows not to bother opening anything as it knows it can't translate? Guess. I normally use ISO8859-1, but the locale setting doesn't make a difference. The installed data files only use ASCII anyway. Actually, I really can't see much potential for something as simple as "fortune" to go wrong ;-) I just tried an ages old fortune program that I still had around, which (after adjusting the path of the data files with a symlink) works fine with the Debian data files ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Howto exactly reproduce kernel source tree compatible with binary kernel deb
Hi, For a long time, I always used traditional "hand-made" kernels, so whenever I needed it (compiling modules from external sources, changing something in the kernel, ...), I naturally had the source tree and configuration matching the currently running kernel lying under "/usr/src/linux". Recently, I switched to Debian and also decided to try using the distribution kernel wherever possible. This still looks like a good idea to me, but it quickly turned out, that nevertheless, I need for many purposes the kernel sources. I searched the web (unfortunately, it seems like there were quite some changes in this area, so must recommendations I found were obviously outdated; btw., I am using "lenny") and tried several different ways, but could not really find something that works reliable. One plausible-looking attempt for example was, that I installed the package "linux-source-2.6.26", unpacked it and copied the configuration from the installed binary kernel package. Unfortunately, the modules compiled from this tree can't be loaded (I couldn't really understand, why; as far as I could tell, everything matched the running kernel ...). I also experimented with "kernel-package" (with similar results). For the most common case of compiling an external module, I found that the package "linux-headers-2.6.26-2-", symlinked to "/usr/src/linux" will do what I need. I am still looking for a way to get the complete kernel source/.config that corresponds to the binary kernel packages, preferably in a way, that it will get updated with every kernel updated and _exactly_ matching the binary kernel, so whatever I compile in this tree can be combined with the binary package. Is there any way to accomplish that? (first of all, "open source" is about source code ...) Any suggestions are appreciated Regards, Peter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Howto exactly reproduce kernel source tree compatible with binary kernel deb
as I meanwhile could figure out, compiling "linux-source-xxx" failed because of a mismatch in the gcc versions (gcc 4.3 is installed as the default C compiler, but the binary kernel packages have been compiled using gcc 4.1). I still would like to know, what is the "recommended" way to use the kernel source ... Regards, Peter For a long time, I always used traditional "hand-made" kernels, so whenever I needed it (compiling modules from external sources, changing something in the kernel, ...), I naturally had the source tree and configuration matching the currently running kernel lying under "/usr/src/linux". Recently, I switched to Debian and also decided to try using the distribution kernel wherever possible. This still looks like a good idea to me, but it quickly turned out, that nevertheless, I need for many purposes the kernel sources. I searched the web (unfortunately, it seems like there were quite some changes in this area, so must recommendations I found were obviously outdated; btw., I am using "lenny") and tried several different ways, but could not really find something that works reliable. One plausible-looking attempt for example was, that I installed the package "linux-source-2.6.26", unpacked it and copied the configuration from the installed binary kernel package. Unfortunately, the modules compiled from this tree can't be loaded (I couldn't really understand, why; as far as I could tell, everything matched the running kernel ...). I also experimented with "kernel-package" (with similar results). For the most common case of compiling an external module, I found that the package "linux-headers-2.6.26-2-", symlinked to "/usr/src/linux" will do what I need. I am still looking for a way to get the complete kernel source/.config that corresponds to the binary kernel packages, preferably in a way, that it will get updated with every kernel updated and _exactly_ matching the binary kernel, so whatever I compile in this tree can be combined with the binary package. Is there any way to accomplish that? (first of all, "open source" is about source code ...) Any suggestions are appreciated Regards, Peter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org