Bug#56179: Why?
6598831484056680 Content-Type:html; charset="ISO-8859-1" B;uy meds for 8O% 1ess than in st0re Or;der H;ere http://www.pkabdfbudb.info/20/ But the silence was unbroken, and the stillness gave no token, Authors are partial to their Wit, 'tis true, 6598831484056680--
Bug#24192: i gtota kon.w..
73547480846494055253 Content-Type:html; charset="ISO-8859-1" B;uy meds for 8O% 1ess than in st0re Or;der H;ere http://www.pajabadjfh.info/20/ Who remembers that famous day and year. Unerring Nature, still divinely bright, 73547480846494055253--
X Strike Force XFree86 SVN commit: r1843 - in trunk/debian: . po
Author: ishikawa Date: 2004-09-21 20:22:37 -0500 (Tue, 21 Sep 2004) New Revision: 1843 Modified: trunk/debian/CHANGESETS trunk/debian/changelog trunk/debian/po/ja.po Log: Update Japanese debconf template translations (thanks, Kenshi Muto). Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-21 21:29:34 UTC (rev 1842) +++ trunk/debian/CHANGESETS 2004-09-22 01:22:37 UTC (rev 1843) @@ -59,4 +59,7 @@ Make minor expansions and corrections to the FAQ. 1841 +Update Japanese debconf template translations (thanks, Kenshi Muto). +1843 + vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-09-21 21:29:34 UTC (rev 1842) +++ trunk/debian/changelog 2004-09-22 01:22:37 UTC (rev 1843) @@ -45,7 +45,11 @@ * Create debian/tmp/usr/X11R6/lib/X11/doc when NOT_BUILDING_XFREE86_X_SERVER is defined. Fixes FTBFS on s390. + + Changes by ISHIKAWA Mutsumi: + * Update Japanese debconf template translations (thanks, Kenshi Muto). + -- Branden Robinson <[EMAIL PROTECTED]> Tue, 21 Sep 2004 15:49:27 -0500 xfree86 (4.3.0.dfsg.1-7) unstable; urgency=high Modified: trunk/debian/po/ja.po === --- trunk/debian/po/ja.po 2004-09-21 21:29:34 UTC (rev 1842) +++ trunk/debian/po/ja.po 2004-09-22 01:22:37 UTC (rev 1843) @@ -30,7 +30,7 @@ "Project-Id-Version: xfree86 4.3.0\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2004-08-30 07:42+\n" -"PO-Revision-Date: 2004-06-25 09:21+0900\n" +"PO-Revision-Date: 2004-09-18 15:41+0900\n" "Last-Translator: Kenshi Muto <[EMAIL PROTECTED]> and ISHIKAWA Mutsumi " "<[EMAIL PROTECTED]>\n" "Language-Team: Japanese \n" @@ -42,7 +42,7 @@ #. Description #: ../libx11-6.templates:4 msgid "Migrate XKB configuration directory?" -msgstr "" +msgstr "XKB �����ǥ��쥯�ȥ����ܹԤ��ޤ���?" #. Type: boolean #. Description @@ -51,7 +51,7 @@ "The directory where configuration information (including keyboard data) for " "the X KEYBOARD Extension (XKB) is stored has been changed from /usr/X11R6/" "lib/X11/xkb to /etc/X11/xkb." -msgstr "" +msgstr "X KEYBOARD Extension (XKB) ���������� (�����ܡ��ɤΥǡ������ޤ�) �γ�Ǽ�����Υǥ��쥯�ȥ��ϡ�/usr/X11R6/lib/X11/xkb ���� /etc/X11/xkb ���ѹ������ޤ�����" #. Type: boolean #. Description @@ -59,7 +59,7 @@ msgid "" "Your system is using the old location, and some programs, such as those from " "old or unofficial Debian packages, may continue to install files there." -msgstr "" +msgstr "���ʤ��Υ����ƥ��ϡ����θŤ������ȡ��Ť����뤤���������� Debian ï¿½Ñ¥Ã¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î¤è¤¦ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½Ä¤ï¿½ï¿½Î¥×¥í¥°ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È¤Ã¤Æ¤ï¿½ï¿½ê¡¢ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ò¤½¤ï¿½ï¿½Ë¥ï¿½ï¿½ó¥¹¥È¡ï¿½ï¿½ë¤·ï¿½ï¿½ï¿½Þ¤Þ¤Ë¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½Æ¤â¤«ï¿½Þ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½" #. Type: boolean #. Description @@ -70,13 +70,13 @@ "new location that have the same name will be backed up and replaced by the " "files from the old location. A symbolic link from the old location to the " "new one will be created to prevent legacy applications from breaking." -msgstr "" +msgstr "�����ƥ��� XKB �����ե���������ưŪ�˸Ť����꤫�鿷���������˰ܹԤ��ޤ���? �����������ˤ���Ʊ��̾�������Ĵ�¸�Υե������ϥХå����åפ��졢�Ť����꤫���Υե������ˤ��ä��֤����������ޤ��������Υ��ץꥱ�����������㳲�����ò¤±¤ë¤¿ï¿½á¡¢ï¿½Å¤ï¿½ï¿½ï¿½ï¿½ê¤«ï¿½é¿·ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ø¤Î¥ï¿½ï¿½ï¿½ï¿½Ü¥ï¿½ï¿½Ã¥ï¿½ï¿½ï¿½ï¿½ó¥¯¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½" #. Type: boolean #. Description #: ../libxt6.templates:4 msgid "Migrate Xt application defaults directory?" -msgstr "" +msgstr "Xft ���ץꥱ���������Υǥե����ȥǥ��쥯�ȥ����ܹԤ��ޤ���?" #. Type: boolean #. Description @@ -85,7 +85,7 @@ "The directory where application defaults for X Window System client programs " "based on the X Toolkit Intrinsics (Xt) are stored has been changed from /usr/" "X11R6/lib/X11/app-defaults to /etc/X11/app-defaults." -msgstr "" +msgstr "X Toolkit Intrinsics (Xt) �١����� X Window System ï¿½ï¿½ï¿½é¥¤ï¿½ï¿½ï¿½ï¿½ï¿½È¥×¥í¥°ï¿½ï¿½ï¿½ï¿½ï¿½Î¥ï¿½ï¿½×¥ê¥±ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î¥Ç¥Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î³ï¿½Ç¼ï¿½ï¿½ï¿½ï¿½ï¿½Î¥Ç¥ï¿½ï¿½ì¥¯ï¿½È¥ï¿½ï¿½Ï¡ï¿½/usr/X11R6/lib/X11/app-defaults �ï
Bug#271235: new nv driver that should fix Xv extensions: please test!
Fabio, Thanks for your continued work on this - I really appreciate it. The most recent drivers exhibit the same behavior - mplayer shows a grey window, xine works fine. This is with my nvidia GeForce2 MX 400. Thanks, Dave
Processed: severity of 272744 is important, merging 272744 237509
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.8.4 > severity 272744 important Bug#272744: libxft-dev: error on upgrade from 2.1.2-4 to 2.1.2-6 Severity set to `important'. > # and another one of these > merge 272744 237509 Bug#237509: libxft-dev: upgrading from libxft-dev 2.1.2-[1-5] doesn't work due to dpkg-divert being run before unpack Bug#272744: libxft-dev: error on upgrade from 2.1.2-4 to 2.1.2-6 Bug#237511: libxft-dev: upgrading from libxft-dev 2.1.2-[1-5] doesn't work due to dpkg-divert being run before unpack Bug#240302: libxft2-dev doesn't install Bug#241008: libxft-dev: error during upgrade Bug#246891: libxft-dev: problem upgrading from 2.1.2-5 Bug#247645: libxft-dev: apt-get upgrade reports unmet dependencies Merged 237509 237511 240302 241008 246891 247645 272744. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
X Strike Force XFree86 SVN commit: r1842 - in trunk/debian: . local
Author: branden Date: 2004-09-21 16:29:34 -0500 (Tue, 21 Sep 2004) New Revision: 1842 Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: (cosmetic) Fix typo. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-21 21:13:47 UTC (rev 1841) +++ trunk/debian/CHANGESETS 2004-09-21 21:29:34 UTC (rev 1842) @@ -9,7 +9,7 @@ files anywhere.) Miscellaneous cosmetic fixes. -1811, 1812, 1815, 1816, 1828, 1829, 1830 +1811, 1812, 1815, 1816, 1828, 1829, 1830, 1842 Update Danish debconf template translations (thanks, Claus Hindsgaul). 1806 Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-21 21:13:47 UTC (rev 1841) +++ trunk/debian/local/FAQ.xhtml2004-09-21 21:29:34 UTC (rev 1842) @@ -2886,7 +2886,7 @@ modular. A consequence is that fake keys have been introduced in XKB data files for Alt, Meta, Super and Hyper. (The fake keys are distinguished from real keys by not -being pair-oriented to the "left" or "right". Even keybords that have only one +being pair-oriented to the "left" or "right". Even keyboards that have only one of a pair of such keys — like laptop keyboards — report the keys they do have as being either left or right, for compatibility with full-size models.) By default, the modifiers mod1 and mod4 use
X Strike Force XFree86 SVN commit: r1841 - in trunk/debian: . local
Author: branden Date: 2004-09-21 16:13:47 -0500 (Tue, 21 Sep 2004) New Revision: 1841 Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: Make minor expansions and corrections to the FAQ. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-21 20:49:51 UTC (rev 1840) +++ trunk/debian/CHANGESETS 2004-09-21 21:13:47 UTC (rev 1841) @@ -56,4 +56,7 @@ Add FAQ entry: How does the keyboard work in the X Window System? 1840 +Make minor expansions and corrections to the FAQ. +1841 + vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-21 20:49:51 UTC (rev 1840) +++ trunk/debian/local/FAQ.xhtml2004-09-21 21:13:47 UTC (rev 1841) @@ -803,7 +803,9 @@ in software); for example, pressing Compose + A + E would produce the ae ligature (æ); valid compose sequences are defined in locale-specific data files such as /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose +class="filespec">/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose; the X +Window System's keysym for this key is +Multi_key dead key a key, typically engraved with an accent, diacritic, or other mark which produces no character by itself but instead modifies the character generated @@ -839,6 +841,18 @@ territorial specifics of a keyboard model; two given keyboards may have the same physical key arrangment but different engravings on the keys, each keyboard customized to a different region or territory + logo key +a platform- and trademark-independent term for keys typically engraved +with the logo of an operating system or its manufacturer; for example, these +keys are referred to as "Windows keys" on PCs and "Apple keys" or "command +keys" on Macintoshes (furthermore, some enterprising keyboard suppliers have +engraved these keys with Tux the penguin, the Linux mascot); since the X +Window System keysym list antedates these keyboards, these +keys are often mapped to one of the modifier keys (Meta, +Super, or Hyper) from the notorious http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?space-cadet+keyboard";>Symbolics +"Space Cadet" keyboard, which was no doubt popular at MIT at the time +the X Window System was developed model an XKB configuration parameter that identifies what physical model of a keyboard is in use; used to determine what @@ -2880,8 +2894,8 @@ fake keys, but some applications, like GNU Emacs, get confused and will not recognize your keys as modifiers. Until these applications are fixed, you can bind keys explicitly with altwin -XKB options; for example, Option "altwin:super_win" binds your logo -keys to Super modifiers. +XKB options; for example, Option "XkbOptions" "altwin:super_win" +binds your logo keys to Super modifiers. Acknowledgements
Re: X Strike Force XFree86 SVN commit: r1836 - in trunk/debian: . local
On Tue, Sep 21, 2004 at 01:09:36PM -0500, X Strike Force SVN Repository Admin wrote: > Author: branden > Date: 2004-09-21 13:09:32 -0500 (Tue, 21 Sep 2004) > New Revision: 1836 > > Modified: >trunk/debian/TODO >trunk/debian/changelog >trunk/debian/local/FAQ.xhtml > Log: > Update the "xkbnewlayout" FAQ entry based on clarifications from Denis > Barbier. > > Denis, please review this change and let me know if I have said anything > inaccurate or misleading. This is much easier to understand, thanks. But I am not comfortable with the first paragraph. It seems to imply that Mode_Switch has a similar effect than AltGr, but alternate group being locked. Since XFree86 4.3 this is no more true, groups are defined with at most 4 columns, AltGr displays glyphs of 3rd and 4th columns for the current group, but does not switch group. OTOH Mode_Switch switches group, but cannot display glyphs of 3rd and 4th columns. Since you give a detailed description of groups, you could mention that at most 4 groups can be used simultaneously. In the last paragraph about fake keys, some applications work better when setting altwin:super_win (if logo keys have to be bound to Super) but not GNU emacs, it has to be patched as explained in #255286. We could provide a debian:no_fake_keys to disable fake keys, let me know if you believe that it is a good idea. IMO it is, the more options are provded to users, the better. Denis
X Strike Force XFree86 SVN commit: r1840 - in trunk/debian: . local
Author: branden
Date: 2004-09-21 15:49:51 -0500 (Tue, 21 Sep 2004)
New Revision: 1840
Modified:
trunk/debian/CHANGESETS
trunk/debian/changelog
trunk/debian/local/FAQ.xhtml
Log:
Add FAQ entry: How does the keyboard work in the X Window System?
Modified: trunk/debian/CHANGESETS
===
--- trunk/debian/CHANGESETS 2004-09-21 18:21:04 UTC (rev 1839)
+++ trunk/debian/CHANGESETS 2004-09-21 20:49:51 UTC (rev 1840)
@@ -53,4 +53,7 @@
it messed up now? (Closes: #259740)
1823, 1832, 1835, 1836, 1838, 1839
+Add FAQ entry: How does the keyboard work in the X Window System?
+1840
+
vim:set ai et sts=4 sw=4 tw=80:
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2004-09-21 18:21:04 UTC (rev 1839)
+++ trunk/debian/changelog 2004-09-21 20:49:51 UTC (rev 1840)
@@ -39,12 +39,14 @@
* In the Xsession script, attempt to create a file of non-zero length in
/tmp; a full filesystem can cause mysterious X session failures.
+ * Add FAQ entry: How does the keyboard work in the X Window System?
+
Changes by Fabio M. Di Nitto:
* Create debian/tmp/usr/X11R6/lib/X11/doc when NOT_BUILDING_XFREE86_X_SERVER
is defined. Fixes FTBFS on s390.
- -- Branden Robinson <[EMAIL PROTECTED]> Tue, 21 Sep 2004 13:08:05 -0500
+ -- Branden Robinson <[EMAIL PROTECTED]> Tue, 21 Sep 2004 15:49:27 -0500
xfree86 (4.3.0.dfsg.1-7) unstable; urgency=high
Modified: trunk/debian/local/FAQ.xhtml
===
--- trunk/debian/local/FAQ.xhtml2004-09-21 18:21:04 UTC (rev 1839)
+++ trunk/debian/local/FAQ.xhtml2004-09-21 20:49:51 UTC (rev 1840)
@@ -59,6 +59,8 @@
What is window focus?
What are X resources?
What are app-defaults?
+How does the keyboard work in the X Window
+ System?
Specific Questions
@@ -782,6 +784,131 @@
default settings for a client. They work as if they were part of the client
binary itself.
+How does the keyboard work in the X Window
System?
+
+
+
+It will take some time to write a comprehensive entry on this subject,
+but in the meantime it is hoped that the following glossary is useful.
+
+
+ compose key
+a key which causes the next two keys pressed to be treated specially
+such that they cause a single character to be printed (this is implemented
+in software); for example, pressing Compose + A + E would
produce
+the ae ligature (æ); valid compose sequences are defined in
+locale-specific data files such as /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose
+ dead key
+a key, typically engraved with an accent, diacritic, or other mark
which
+produces no character by itself but instead modifies the character
generated
+by the next key pressed (this is implemented in software); for example, on
a
+keyboard with dead keys, pressing a key engraved with an acute accent
+(´) glyph followed by the A key would
+produce an "a" with an acute accent (á), whereas pressing the acute
+accent ("dead acute") key followed by a space would produce the acute
accent
+by itself (´); contrast with spacing key
+ engraving
+the visible marking(s) on a keycap, which indicate the
+key's behavior via a glyph (such as Q or
+\) or term describing a control function (such as
+Enter, Shift, or Scroll Lock)
+ keycap
+the surface of a key; the part of a key which is pressed and bears
+engravings
+ keycode
+a scan code after it has undergone translation (if
any)
+by the operating system and X server
+ keymap
+a complete description of a keyboard device which is used by the X
+server to translate keycodes into keysyms
+and modifier masks; when XKB is used, this includes
+compat, geometry,
+keycodes, symbols, and
+types information
+ keysym
+a symbolic name for a key, independent of the operating system and
+keyboard hardware, which identifies a key to X clients
+ layout
+an XKB configuration parameter that identifies the
+territorial specifics of a keyboard model; two given keyboards may have the
+same physical key arrangment but different engravings on
+the keys, each keyboard customized to a different region or territory
+ model
+an XKB configuration parameter that identifies what
+physical model of a keyboard is in use; used to determine what
+keycodes are supported by the model and what its
+geometry is
+ modifier
+a flag (up or down) which can influence how keycodes
+are translated to keysyms, and how X clients interpret key
+events
+ modifier mask
+a list of modifier states; these are
+bitwise-ORed together as the "state" value reported with key
+events by the xev command
+ options
+an XKB configuration parameter that permits the user
to
+customize aspects of keyboard behavior that are no
Bug#272756: xfree86 on VMWARE under win2K fails to start
Package: xserver-xfree86 Version: 4.1.0-16woody3 I have done a fresh install of debian3.0r1 using VMWARE on win2K. The install went well but gdm has failed to work due to the xserver crashing. I try to start it manually using xinit and it still crashes. I've attached the output from the log and my config for XF86. Steve Etzell XFree86.0.log Description: Binary data XF86Config-4 Description: Binary data
Bug#272744: libxft-dev: error on upgrade from 2.1.2-4 to 2.1.2-6
Package: libxft-dev Version: 2.1.2-4 Severity: grave Justification: renders package unusable apt-get -f install 134511 files and directories currently installed.) Preparing to replace libxft-dev 2.1.2-4 (using .../libxft-dev_2.1.2-6_i386.deb) ... diversion of /usr/X11R6/include/X11/Xft/Xft.h to /usr/X11R6/include/X11/Xft/Xft1.h by libxft-dev Removing `diversion of /usr/X11R6/include/X11/Xft/Xft.h to /usr/X11R6/include/X11/Xft/Xft1.h by libxft-dev' dpkg-divert: rename involves overwriting `/usr/X11R6/include/X11/Xft/Xft.h' with different file `/usr/X11R6/include/X11/Xft/Xft1.h', not allowed dpkg: error processing /var/cache/apt/archives/libxft-dev_2.1.2-6_i386.deb (--unpack): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/libxft-dev_2.1.2-6_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages libxft-dev depends on: ii libc6-dev [libc-dev] 2.3.2.ds1-16 GNU C Library: Development Librari ii libfontconfig1-dev2.2.3-1generic font configuration library ii libfreetype6-dev 2.1.7-2.2 FreeType 2 font engine, developmen ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxrender-dev0.8.3-4X Rendering Extension client libra ii pkg-config0.15.0-3 Manage compile and link flags for ii xlibs-dev 4.3.0.dfsg.1-1 X Window System client library dev ii zlib1g-dev [libz-dev] 1:1.2.1-3 compression library - development -- no debconf information
X Strike Force XFree86 SVN commit: r1839 - in trunk/debian: . local
Author: branden Date: 2004-09-21 13:21:04 -0500 (Tue, 21 Sep 2004) New Revision: 1839 Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: Fix missing phrase. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-21 18:17:42 UTC (rev 1838) +++ trunk/debian/CHANGESETS 2004-09-21 18:21:04 UTC (rev 1839) @@ -51,6 +51,6 @@ Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is it messed up now? (Closes: #259740) -1823, 1832, 1835, 1836, 1838 +1823, 1832, 1835, 1836, 1838, 1839 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-21 18:17:42 UTC (rev 1838) +++ trunk/debian/local/FAQ.xhtml2004-09-21 18:21:04 UTC (rev 1839) @@ -2685,18 +2685,18 @@ One or more of the keys on their keyboards are engraved with more than two glyphs. On a typical U.S. keyboard, there are at most two glyphs on each keycap — one is accessed with a Shift or Caps Lock key, -and one without. Many keyboards outside enable access to glyphs beyond the -third with modifier keys not found on most U.S. keyboards. One approach is with -an AltGr (alternate group) key, which is analogous to -Shift. The other approach is with a Mode Switch key, -which is analogous to Caps Lock. When either of these keys are -pressed, the X Window System needs to know to switch to an alternative key -layout — preferably one which corresponds to the engravings on the user's -keyboard. A U.S. keyboard, even if keys are remapped so that AltGr -and/or Mode Switch keys are available, does not acquire much -meaningful additional functionality unless and alternate group is defined in -software, so that "the keys know what to do" when the alternate group is -enabled. +and one without. Many keyboards outside the United States enable access to +glyphs beyond the third with modifier keys not found on most U.S. keyboards. +One approach is with an AltGr (alternate group) key, which is +analogous to Shift. The other approach is with a Mode +Switch key, which is analogous to Caps Lock. When either of +these keys are pressed, the X Window System needs to know to switch to an +alternative key layout — preferably one which corresponds to the +engravings on the user's keyboard. A U.S. keyboard, even if keys are remapped +so that AltGr and/or Mode Switch keys are available, +does not acquire much meaningful additional functionality unless and alternate +group is defined in software, so that "the keys know what to do" when the +alternate group is enabled. Sometimes a key layout for a given territory (such as gb for the United Kingdom or fr for France) defines what should be in the
X Strike Force XFree86 SVN commit: r1838 - in trunk/debian: . local
Author: branden Date: 2004-09-21 13:17:42 -0500 (Tue, 21 Sep 2004) New Revision: 1838 Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: Fix usage of nonexistent XHTML element "firstterm". My brain wandered off into DocBook-land, it appears. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-21 18:15:29 UTC (rev 1837) +++ trunk/debian/CHANGESETS 2004-09-21 18:17:42 UTC (rev 1838) @@ -51,6 +51,6 @@ Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is it messed up now? (Closes: #259740) -1823, 1832, 1835, 1836 +1823, 1832, 1835, 1836, 1838 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-21 18:15:29 UTC (rev 1837) +++ trunk/debian/local/FAQ.xhtml2004-09-21 18:17:42 UTC (rev 1838) @@ -2681,22 +2681,22 @@ Thanks to Denis Barbier for contributing much of this entry. Many users of the X Window System, particularly outside the United States, -find that they need support for multiple groups on their -keyboards. One or more of the keys on their keyboards are engraved with more -than two glyphs. On a typical U.S. keyboard, there are at most two glyphs on -each keycap — one is accessed with a Shift or Caps -Lock key, and one without. Many keyboards outside enable access to -glyphs beyond the third with modifier keys not found on most U.S. keyboards. -One approach is with an AltGr (alternate group) key, which is -analogous to Shift. The other approach is with a Mode -Switch key, which is analogous to Caps Lock. When either of -these keys are pressed, the X Window System needs to know to switch to an -alternative key layout — preferably one which corresponds to the -engravings on the user's keyboard. A U.S. keyboard, even if keys are remapped -so that AltGr and/or Mode Switch keys are available, -does not acquire much meaningful additional functionality unless and alternate -group is defined in software, so that "the keys know what to do" when the -alternate group is enabled. +find that they need support for multiple groups on their keyboards. +One or more of the keys on their keyboards are engraved with more than two +glyphs. On a typical U.S. keyboard, there are at most two glyphs on each keycap +— one is accessed with a Shift or Caps Lock key, +and one without. Many keyboards outside enable access to glyphs beyond the +third with modifier keys not found on most U.S. keyboards. One approach is with +an AltGr (alternate group) key, which is analogous to +Shift. The other approach is with a Mode Switch key, +which is analogous to Caps Lock. When either of these keys are +pressed, the X Window System needs to know to switch to an alternative key +layout — preferably one which corresponds to the engravings on the user's +keyboard. A U.S. keyboard, even if keys are remapped so that AltGr +and/or Mode Switch keys are available, does not acquire much +meaningful additional functionality unless and alternate group is defined in +software, so that "the keys know what to do" when the alternate group is +enabled. Sometimes a key layout for a given territory (such as gb for the United Kingdom or fr for France) defines what should be in the @@ -2709,11 +2709,11 @@ engraved with primary group and alternate group glyphs. Russian keyboards, for example, because they must support both the Latin and Cyrillic alphabets, often work this way. As a consequence, users of the X Window System -need a way to combine layouts. +need a way to combine layouts. Prior to XFree86 4.3, combining layouts was difficult because keyboard -symbols (keysyms) were defined to be specific to a given -group. For example, the us symbols file (in keysyms) were defined to be specific to a given group. For +example, the us symbols file (in /etc/X11/xkb/symbols/) defined the its keycode to keysym mappings specifically for group 1 — the primary group. The us_group2 and us_group3 files repeated these @@ -2723,10 +2723,10 @@ was consequently impossible without modifying the XKB data files directly — a skill most users do not possess. -XKB layouts have been revisited in XFree86 4.3, and new definitions can -now be used in arbitrary order so that us,ru and ru,us -use the same symbols files. The new definitions have been placed -in /etc/X11/xkb/symbols/pc/ while the old ones are +XKB layouts have been revisited in XFree86 4.3, and new definitions can now +be used in arbitrary order so that us,ru and ru,us use +the same symbols files. The new definitions have been placed in +/etc/X11/xkb/symbols/pc/ while the old ones are still available in their traditional location; that is, directly within the /etc/X11/xkb/symbols/ directory. @@ -2740,17 +2740,17 @@ Modifiers have also been affected by these changes to make the syste
X Strike Force XFree86 SVN commit: r1837 - trunk/debian
Author: branden Date: 2004-09-21 13:15:29 -0500 (Tue, 21 Sep 2004) New Revision: 1837 Modified: trunk/debian/CHANGESETS Log: Update entry. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-21 18:09:32 UTC (rev 1836) +++ trunk/debian/CHANGESETS 2004-09-21 18:15:29 UTC (rev 1837) @@ -51,6 +51,6 @@ Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is it messed up now? (Closes: #259740) -1823, 1832 +1823, 1832, 1835, 1836 vim:set ai et sts=4 sw=4 tw=80:
X Strike Force XFree86 SVN commit: r1836 - in trunk/debian: . local
Author: branden
Date: 2004-09-21 13:09:32 -0500 (Tue, 21 Sep 2004)
New Revision: 1836
Modified:
trunk/debian/TODO
trunk/debian/changelog
trunk/debian/local/FAQ.xhtml
Log:
Update the "xkbnewlayout" FAQ entry based on clarifications from Denis
Barbier.
Denis, please review this change and let me know if I have said anything
inaccurate or misleading.
Modified: trunk/debian/TODO
===
--- trunk/debian/TODO 2004-09-21 17:34:30 UTC (rev 1835)
+++ trunk/debian/TODO 2004-09-21 18:09:32 UTC (rev 1836)
@@ -19,7 +19,6 @@
* Fix Xpm library stack and integer overflow vulnerabilities. (#272493; woody
security update already in progress)
-* Address BR's confusion in the new "xkbnewlayout" FAQ question.
* Fix for the nv driver breakage, consider backporting the driver from
x.org.
See: #269025, #268759, #271235, #270228, #271071
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2004-09-21 17:34:30 UTC (rev 1835)
+++ trunk/debian/changelog 2004-09-21 18:09:32 UTC (rev 1836)
@@ -29,6 +29,8 @@
altwin:hyper_win. (Closes: #271259)
+ rules/xfree86.{lst,xml}: Synchronize these files.
+ Changes by Denis Barbier and Branden Robinson:
+
* Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is
it messed up now? (Closes: #259740)
@@ -42,7 +44,7 @@
* Create debian/tmp/usr/X11R6/lib/X11/doc when NOT_BUILDING_XFREE86_X_SERVER
is defined. Fixes FTBFS on s390.
- -- Branden Robinson <[EMAIL PROTECTED]> Sun, 12 Sep 2004 23:45:07 -0500
+ -- Branden Robinson <[EMAIL PROTECTED]> Tue, 21 Sep 2004 13:08:05 -0500
xfree86 (4.3.0.dfsg.1-7) unstable; urgency=high
Modified: trunk/debian/local/FAQ.xhtml
===
--- trunk/debian/local/FAQ.xhtml2004-09-21 17:34:30 UTC (rev 1835)
+++ trunk/debian/local/FAQ.xhtml2004-09-21 18:09:32 UTC (rev 1836)
@@ -2678,28 +2678,60 @@
My keyboard configuration worked with XFree86 4.2;
why is it messed up now?
-Thanks to Denis Barbier for contributing this entry.
+Thanks to Denis Barbier for contributing much of this entry.
-[TODO: This entry needs to be more careful with "keymap" versus "layout"
-terminology. Also, I don't understand the first paragraph or the first
sentence
-of the second paragraph. Do the mentioned "positions" have to do with shift
-levels? Also, what relationship do shift levels have with groups? —
-BR]
+Many users of the X Window System, particularly outside the United States,
+find that they need support for multiple groups on their
+keyboards. One or more of the keys on their keyboards are engraved with more
+than two glyphs. On a typical U.S. keyboard, there are at most two glyphs on
+each keycap — one is accessed with a Shift or Caps
+Lock key, and one without. Many keyboards outside enable access to
+glyphs beyond the third with modifier keys not found on most U.S. keyboards.
+One approach is with an AltGr (alternate group) key, which is
+analogous to Shift. The other approach is with a Mode
+Switch key, which is analogous to Caps Lock. When either
of
+these keys are pressed, the X Window System needs to know to switch to an
+alternative key layout — preferably one which corresponds to the
+engravings on the user's keyboard. A U.S. keyboard, even if keys are remapped
+so that AltGr and/or Mode Switch keys are available,
+does not acquire much meaningful additional functionality unless and alternate
+group is defined in software, so that "the keys know what to do" when the
+alternate group is enabled.
-In releases previous to XFree86 4.3, combining several layouts was difficult
-because keymaps had to be defined for each position. For example,
-us keymap was defined on first, second and third position, and
this
-should have been done for all keymaps.
+Sometimes a key layout for a given territory (such as gb for
the
+United Kingdom or fr for France) defines what should be in the
+alternate group. For example, on many European keyboards, one can press
+AltGr + E to produce the Euro sign (€). This approach is often
+taken when most keys don't need an symbol defined for the alternate group,
+because most keys are engraved with two or fewer glyphs.
-Keymap layouts have been revisited in XFree86 4.3, and new definitions can
+Other times, however, most or all of the printing keys on the keyboard are
+engraved with primary group and alternate group glyphs. Russian
+keyboards, for example, because they must support both the Latin and Cyrillic
+alphabets, often work this way. As a consequence, users of the X Window System
+need a way to combine layouts.
+
+Prior to XFree86 4.3, combining layouts was difficult because keyboard
+symbols (keysyms) were defined to be specific to a given
+group. For example, the us symbols file (in /etc/X11/xkb/symbols/) defined th
Bug#45291: Norton AntiVirus detected a virus in a message you sent. The inf ected attachment was deleted.
Recipient of the infected attachment: Lineadipartenza\Posta in arrivo Subject of the message: Re: Protected Mail System One or more attachments were deleted Attachment document.zip was Deleted for the following reasons: Virus [EMAIL PROTECTED] was found. Virus [EMAIL PROTECTED] was found in data.rtf .scr. <>
X Strike Force XFree86 SVN commit: r1835 - trunk/debian/local
Author: branden Date: 2004-09-21 12:34:30 -0500 (Tue, 21 Sep 2004) New Revision: 1835 Modified: trunk/debian/local/FAQ.xhtml Log: Fix XML validation error (missing slash in closing tag). Shame on me for not checking the document before committing. Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-21 16:01:14 UTC (rev 1834) +++ trunk/debian/local/FAQ.xhtml2004-09-21 17:34:30 UTC (rev 1835) @@ -2712,10 +2712,10 @@ pair-oriented to the "left" or "right". Even keybords that have only one of a pair of such keys — like laptop keyboards — report the keys they do have as being either left or right.) By default, the modifiers -mod1 and mod4 use these fake keys instead of real ones. -XKB-aware applications can handle those fake keys, but some applications, like -GNU Emacs, get confused and will not recognize your -keys as modifiers. Until these applications are fixed, you can bind keys +mod1 and mod4 use these fake keys instead of real +ones. XKB-aware applications can handle those fake keys, but some applications, +like GNU Emacs, get confused and will not recognize +your keys as modifiers. Until these applications are fixed, you can bind keys explicitly with altwin XKB options; for example, Option "altwin:super_win" binds your logo keys to Super modifiers.
X Strike Force XFree86 SVN commit: r1834 - trunk/debian
Author: branden Date: 2004-09-21 11:01:14 -0500 (Tue, 21 Sep 2004) New Revision: 1834 Modified: trunk/debian/TODO Log: Add item for -8 per (earlier) discussion with Fabio. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-20 21:10:27 UTC (rev 1833) +++ trunk/debian/TODO 2004-09-21 16:01:14 UTC (rev 1834) @@ -17,6 +17,8 @@ 4.3.0.dfsg.1-8 -- +* Fix Xpm library stack and integer overflow vulnerabilities. (#272493; woody + security update already in progress) * Address BR's confusion in the new "xkbnewlayout" FAQ question. * Fix for the nv driver breakage, consider backporting the driver from x.org.
Bug#272699: xserver-xfree86: "ctl+space" can invoke the input method
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-7 Severity: normal After I upgraded my debian sid. My input method can't be activated by "ctl+space". So I guess thay the latest xserver-xfree86 fail to response the event of pressing "ctl+space" correctly. Please have it checked. Thank you very much! -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 20 2004-05-07 11:48 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x 1 root root 1745484 2004-09-06 19:16 /usr/bin/X11/XFree86 Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev a4) /etc/X11/XF86Config-4 does not match checksum in /var/lib/xfree86/XF86Config-4.md5sum. XFree86 X server configuration file status: -rw-r--r-- 1 root root 3094 2004-07-21 23:34 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: # XF86Config-4 (XFree86 X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section "Files" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" #Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" #Load"dri" Load"extmod" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" Load"xtt" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/psaux" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Generic Video Card" Driver "nvidia" BusID "PCI:1:0:0" EndSection Section "Monitor" Identifier "Benq 77g" HorizSync 30-70 VertRefresh 50-160 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Benq 77g" DefaultDepth24 SubSection "Display" Depth 1 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 4 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 8 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 15 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 24
Visitalo http://saludable.web1000.com
c admonition incommunicable afire indisputable mcmahon fisherman matte men curriculum cloth investigate certitude waggle that'd heartfelt leaven is cessna graft carbide roar warden portrayal potomac excessive hansen immigrate archetype amount pappy chanson mirage castigate Atte, Adolfo Vaca
Bug#272661: xfree86-common: Xsession doesn't use UMASK settings from /etc/login.defs
Package: xfree86-common
Version: 4.3.0.dfsg.1-4
Severity: normal
In /etc/login.defs I set umask to 002, and that works for logging in on
the console or remote via ssh. However, if I use {g,x,k}dm I keep
getting an umask of 022, because Xsession is started by the display
manager which has a default umask of 022.
It seems that Xsession doesn't change the UMASK at all. I think it
should inherit the values from /etc/login.defs. But maybe this should be
done by the display manager, in which case this bug applies to {g,k,x}dm
and whatever other display managers Debian provides.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Versions of packages xfree86-common depends on:
ii debconf 1.4.30.5 Debian configuration management sy
ii debianutils 2.8.4 Miscellaneous utilities specific t
-- debconf information:
xfree86-common/experimental_packages:
Bug#216933: Compiling XFree86 4.3.0 with -O0 seems to be a workaround
Hi,
I have a laptop with a TM Crusoe TM5800 and ATi mobility M and have been
experiencing this same problem (albeit with Fedora Core 1 -- sorry for
posting here but i haven't found any other mention of it on the web and
thought the info might be handy to others)
I've compiled XFree86 4.3.0 with the following compiler flags,
-march=i386 -mcpu=i386 -O0 -fomit-frame-pointer -finline-functions,
and my system has now been running without a hitch for 19 days (i was
usually getting the "BadLength error" after only 2 to 4 hours after
every reboot when using the stock Fedora XF86 rpms).
NB: Around the code at line 241 of
XFree86-4.3.0/xc/extras/Mesa/src/glapi.c I had to comment out the
following in order to successfully compile with -O0 (gcc was complaining
about running out of registers):
/*
if (use_cmpxchg8b)
for (p = _gl_entrypoint_templ + 4; p < _gl_end_table; p += 4) {
__asm __volatile ("lock; cmpxchg8b %0"
: "=m" (p[0]), "=m" (p[1]), "=a" (tmp1), "=d" (tmp2)
: "m" (p[0]), "m" (p[1]), "a" (p[0]), "d" (p[1]),
"b" (_gl_entrypoint_templ[0]),
"c" (c | (p[1] & 0x))
: "cc");
}
*/
You can download my custom FC1 rpms from here:
http://tardis.ath.cx/misc/xf86_4.3.0_cust/
(i know this is of little relevance but at least it might help some
fedora newbies like me get their laptops working)
Regards,
Chris
Bug#272493: libxpm4 security problem
Branden Robinson wrote: > (In the future, please don't file bugs against unsupported or unreleased > versions of Debian packages. I have no idea what libxpm4 > "4.3.0-0pre1v5.49.200406160839" is. Whoever shipped that package is the > proper recipient of your bug report.) It's an internal versioning scheme, sorry for the confusion. I checked it against sid, although it has been sent off a machine running the above version. Cheers, Moritz
Bug#264557: xlibs-data: No composition sequences in japanese locale
tag 264557 + moreinfo upstream thanks On Mon, Aug 09, 2004 at 08:40:06PM +0900, Mike Hommey wrote: > Package: xlibs-data > Version: 4.3.0.dfsg.1-6 > Severity: wishlist > > Hi, > > First, I'm not quite sure if the bug belongs to xlibs-data, so please > reassign if I am wrong. > > All "basic" X applications using xlibs (tested with xedit and emacs) > fail to get composition sequences when using the ja_JP.UTF-8 locale. > Interestingly, I get some strange behaviours as well, which might be > related to gnome configurations but I'm not quite sure. Did the following change in 4.3.0.dfsg.1-7 resolve your problem? xfree86 (4.3.0.dfsg.1-7) unstable; urgency=high [...] * Grab from XFree86 CVS (no later than 2003-12-18) fixes to the ja_JP.UTF-8, ko_KR.UTF-8, and zh_TW.UTF-8 XLC_LOCALE files to prefer ISO 10646-1-encoded fonts less strongly. Add zh_CN.UTF-8 XLC_LOCALE file. Update MANIFEST and .install files accordingly. (Closes: #255701) [...] -- Fabio M. Di Nitto <[EMAIL PROTECTED]> Mon, 06 Sep 2004 09:54:18 +0200 If not, do you think you might be experiencing the same problem as: http://bugs.debian.org/267062 ? -- G. Branden Robinson|Half of being smart is knowing what Debian GNU/Linux |you're dumb at. [EMAIL PROTECTED] |-- David Gerrold http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#267231: xlibs-data: Plane 1 in Compose file damaged
Branden Robinson wrote: > retitle 267231 xlibs-data: [en_US.UTF-8/Compose] Unicode Plane 1 characters > damaged > tag 267231 + upstream > thanks > I'd welcome a patch to fix it. Patch enclosed Regards, Jan --- /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose 2004-09-06 13:10:40.0 +0200 +++ Compose 2004-08-21 13:13:08.0 +0200 @@ -5574,25 +5574,25 @@ : "ï" UFB4C # HEBREW LETTER BET WITH RAFE : "ï" UFB4D # HEBREW LETTER KAF WITH RAFE : "ï" UFB4E # HEBREW LETTER PE WITH RAFE -: "í " U1D15E # MUSICAL SYMBOL HALF NOTE -: "í " U1D15F # MUSICAL SYMBOL QUARTER NOTE -: "í " U1D160 # MUSICAL SYMBOL EIGHTH NOTE -: "í " U1D160 # MUSICAL SYMBOL EIGHTH NOTE -: "í ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE -: "í ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE -: "í ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE -: "í ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE -: "í £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE -: "í £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE -: "í ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE -: "í ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE -: "í»" U1D1BB # MUSICAL SYMBOL MINIMA -: "í¼" U1D1BC # MUSICAL SYMBOL MINIMA BLACK -: "í½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE -: "í½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE -: "í¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK -: "í¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK -: "í¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE -: "í¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE -: "í" U1D1C0 # MUSICAL SYMBOL FUSA BLACK -: "í" U1D1C0 # MUSICAL SYMBOL FUSA BLACK +: "ð " U1D15E # MUSICAL SYMBOL HALF NOTE +: "ð " U1D15F # MUSICAL SYMBOL QUARTER NOTE +: "ð " U1D160 # MUSICAL SYMBOL EIGHTH NOTE +: "ð " U1D160 # MUSICAL SYMBOL EIGHTH NOTE +: "ð ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE +: "ð ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE +: "ð ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE +: "ð ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE +: "ð £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE +: "ð £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE +: "ð ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE +: "ð ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE +: "ð»" U1D1BB # MUSICAL SYMBOL MINIMA +: "ð¼" U1D1BC # MUSICAL SYMBOL MINIMA BLACK +: "ð½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE +: "ð½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE +: "ð¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK +: "ð¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK +: "ð¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE +: "ð¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE +: "ð" U1D1C0 # MUSICAL SYMBOL FUSA BLACK +: "ð" U1D1C0 # MUSICAL SYMBOL FUSA BLACK
Reassign to xlibs
reassign 245371 xlibs reassign 270313 xlibs severity 270313 normal reassign 263561 xlibs reassign 269929 xlibs These bugs can hardly be fixed by keyboard switcher applications, thus choose the easy way. Denis
