Configuring a US keyboard with umlauts in sid (hal etc?)
Hi, I have a Thinkpad T43p which has a quite complete keyboard, and it comes with US layout. Which I like. However, I'd also like to be able to easily input german Umlauts. I don't like the compose approach, it needs too much keypressing for fast typing. Instead I want to use the AltGr key to turn AltGr+a to ä, AltGr+A to Ä and so forth. In lenny this worked fine. Now I have upgraded to unstable, and it stopped working. I'm writing here to get some help. I found out that there are two places that claim to be responsible for keyboard configuration now: One is /etc/default/keyboard, the other would be /etc/hal/fdi/policy. However, I can't figure out how to do it right. /etc/default/keyboard has keywords just like the old xorg.conf, but not quite. There, I have XKBMODEL, XKBLAYOUT, XKBVARIANT, and XKBOPTIONS in xorg.conf, I used this definition for my keyboard: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" # Option "XkbVariant""intl" Option "XkbModel" "thinkpad" Option "XkbOptions" "compose:caps,lv3:ralt_switch_multikey,eurosign:e" EndSection So I tried $ egrep -v '^#|^$' /etc/default/keyboard XKBMODEL="thinkpad" XKBLAYOUT="us" XKBOPTIONS="compose:caps,lv3:ralt_switch_multikey,eurosign:e" (and also with XKBVARIANT="intl" and "intl-altgr"), but that doesn't recover the old behavior. It seems those xorg options are simply not supported, as "dpkg-reconfigure keyboard-configuration" tells me. So I looked at the other way, but I can't find an example file that looks like it could contain settings like the ones above. Finally, I find /usr/share/hal/fdi/policy/20thirdparty/10-x11-evdev.fdi - which seems to delegate its configuration to evdev, which is documented as being configured in xorg.conf. Err. Any hints how I should proceed? Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: TeTeX 3 in experimental
Søren Christensen <[EMAIL PROTECTED]> wrote: >> Frank Küster (one of the main tetex developers for Debian) has put >> backported versions of the tetex 3 packages for sarge. See: >> >> http://people.debian.org/~frank/teTeX-3.0/ > > How does this integrate with the rest of the debian-sarge system? As good and as problematic as every collection of backports. The security problems are already described on that page. Furthermore, some packages from sarge cannot be used with teTeX-3.0, and I have included backports of (some of) these packages in the repository. I won't have time to follow the development of all of them, instead I just took the first version in sid that works with teTeX-3.0, and do not plan to update them regularly (only if there is a security issue). The only difference to "usual" backports is that they are provided by the maintainer of the package in sid, and that there is infrastructure in the source package itself to switch from sid as target distribution to a sarge backport. > Does everything (both the official debian-TeX and this backport) comply > with the official TeX Document Structure? Both are identical except for the library dependencies, and both follow the rather new TeX Directory Structure version 1.1 (while the packages in sarge follow version 1.0). > And will they work together > seamlessly (I recall that I once switched from the TeX-system, that was > suppplied with Suse or Mandrake to the official TeX-Live dist, and the > Linux-system kept complaining, that there was no TeX-system available) That is not surprising, since you TeX-live does not provide the tetex rpm's that other SuSE packages depend on. The same would happen with texlive on Debian, but since the backports do provide the same packages, there is no problem. But it seems to me that these questions show that you should rather learn more about what backports are and what benefits and disadvantages they bring. I can't see why you need to contact debian-tetex-maint for that. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler <[EMAIL PROTECTED]> schrieb: > Frank Küster writes: >> But this would have the consequence that all those files would have to be >> created by dpkg, and clutter /etc. > > No files would be created that were not subsequently filled in by a > maintainer script. I don't know where you get the idea that that any > files, empty or otherwise, would be created that are not created now. There are maintainer scripts that create different configuration files, or a different number of configuration files, depending on the existing settings on the installing computer - or depending on debconf answers. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dpkg / apt equivalent to 'rpm -qf'?
Kevin Mark <[EMAIL PROTECTED]> schrieb: > On Tue, Aug 24, 2004 at 06:00:47PM +0200, Frank Küster wrote: >> John Hasler <[EMAIL PROTECTED]> wrote: >> >> >> ...and having a lot of empty files in /etc is just pointless. >> > >> > Where would any empty files come from? >> >> How should a package tell dpkg to install an empty file, if it needs >> that? >> >> Regards, Frank > Hi Frank, > man touch Which does not help in this context. The question was: "How can files that are (perhaps) created by maintainer scripts be registered to dpkg?", and one answer was: "By including them in the deb as empty files". But this would have the consequence that all those files would have to be created by dpkg, and clutter /etc. I had understood from John's question that he wanted dpkg just to ignore empty files, except that it registers them for the package. But this would make it impossible for a package to ship an empty file. Indeed, it could create it in a maintainer script, but that's plain rubbish - change dpkg to do illogical things, and then work around this in maintainer scripts. Better find an other way to register those files (there have been proposals). Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler <[EMAIL PROTECTED]> wrote: >> ...and having a lot of empty files in /etc is just pointless. > > Where would any empty files come from? How should a package tell dpkg to install an empty file, if it needs that? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
