Bug#340578: manpages-fr: French useradd documents nonexisting -n option
reassign 340578 passwd thanks On Thu, Nov 24, 2005 at 11:18:04AM +0100, Benoît Dejean wrote: Package: manpages-fr Version: 1.64.0-2 Severity: normal French i18n for useradd documents nonexisting -n option. Please remove that section. Not my bug ;) Several French speaking people are involved in maintaining the shadow package, so they can deal with this bug, but a patch would surely be very welcome. Thanks for your report. Denis
Bug#341686: xterm cannot be started in utf-8 mode by default
On Fri, Dec 02, 2005 at 02:23:32PM +0100, Sven Luther wrote: Notice that some locales have shifted to UTF-8 by default for etch (like french, but i think a couple other european languages too, i saw it in german too i think). Will xterm default to the right thing in this case ? I do not remember why exactly, but Branden decided to add a new wrapper called lxterm for this purpose, instead of modifying xterm and/or uxterm. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341808: xterm: does not respect charmap for some locales
reassign 341808 xlibs-data thanks On Sat, Dec 03, 2005 at 02:01:15PM +0400, Stepan Golosunov wrote: Package: xterm Version: 4.3.0.dfsg.1-14sarge1 Severity: normal When xterm is running in ru_RU locale (which uses ISO-8859-5), it shows characters as if they were KOI8-R encoded, giving garbage: This is because /usr/X11R6/lib/X11/locale/locale.alias contains ru_RU ru_RU.KOI8-R thus I reassign this bugreport to xlibs-data. [snip] P.S. ISO-8859-5 ru_RU locale is not widely used, but /usr/share/i18n/SUPPORTED contains ru_RU ISO-8859-5 line Yes, and this won't change because glibc developers refuse to modify encodings. So I believe that locale.alias should be fixed to follow glibc. It has been modified in the past to be closely bound to glibc, eg. some locales like Esperanto have been discarded. IMO this is not a good solution, because users may have additional locales, like ru_RU.CP1251 in your case. Of course this annoys me because additional locales provided by belocs-locales-data are not available to X users. The best solution is to have the same encoding as in the locales/belocs-locales-data packages, when it is defined there, keep existing ones when they are defined in X and not glibc, and add new locales when requested by users. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307844: xlibs: xkb int'l keyboard modifiers broken since last update
tags 307844 + unreproducible severity 307844 normal thanks On Thu, May 05, 2005 at 10:03:27PM +0200, Peter Koellner wrote: Package: xlibs Version: 4.3.0.dfsg.1-12 Severity: important since my last update of debian unstable the AltGr keyboard modification is broken. I tried for several days now to even pinpoint the problem, looking through related bug reports, trying different keyboard layout options, but nothing helps. The 'at' has vanished from AltGr-q, and the Eurosign is gone from AltGr-e. The best I can do is to do a setxkbmap -rules xfree86 -model pc105 latin+de basic complete I cannot reproduce your problem: $ setxkbmap -layout de,ru -variant basic,winkeys -option -option lv3:ralt_switch,grp:lwin_toggle and AltGr-q prints @, Russian keymap seems to work fine as well. According to your other posts, you had non-Debian packages installed. Could you please check that XKB works fine with pristine Debian packages? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307940: belocal-locales-data: please update Ukrainian locale
On Fri, May 06, 2005 at 07:13:58PM +0300, Eugeniy Meshcheryakov wrote: Package: belocs-locales-data Version: 2.3.4-12 Severity: wishlist Tags: l10n Please add updated version of Ukrainian locale from http://sources.redhat.com/bugzilla/show_bug.cgi?id=58 Indeed, I monitor these changes through the glibc-bugs mailing list, but this list is not Cc'ed for old bugreports :( Unfortunately this version does not compile: $ localedef -i ./uk_UA-2.1.10 -f UTF-8 /tmp/foo ./uk_UA-2.1.10:585: unterminated string ./uk_UA-2.1.10:585: LC_MESSAGES: unknown character in field `yesexpr' ./uk_UA-2.1.10:586: LC_MESSAGES: syntax error ./uk_UA-2.1.10:587: LC_MESSAGES: syntax error ./uk_UA-2.1.10:595: unterminated string [...] Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307940: belocal-locales-data: please update Ukrainian locale
On Tue, May 10, 2005 at 12:52:38PM +0300, Eugeniy Meshcheryakov wrote: 9 2005 23:48 +0200 Denis Barbier (-): [...] Unfortunately this version does not compile: $ localedef -i ./uk_UA-2.1.10 -f UTF-8 /tmp/foo ./uk_UA-2.1.10:585: unterminated string ./uk_UA-2.1.10:585: LC_MESSAGES: unknown character in field `yesexpr' ./uk_UA-2.1.10:586: LC_MESSAGES: syntax error ./uk_UA-2.1.10:587: LC_MESSAGES: syntax error ./uk_UA-2.1.10:595: unterminated string [...] It is in DOS format, try dos2unix. You are right, but there are other problems. E.g. some lines were encoded twice with U notation (see attached patch), some collation rules look strange (I would ignore U042C and U044C characters instead of defining all these collating-elements), LC_TIME defines am_pm but does use 24hr notation, etc. I will first discuss these issues on upstream Bugzilla before including this updated locale, but if there are some items which are really broken and need fixing, please let me know. Denis --- uk_UA-2.1.102005-05-10 19:39:11.657980744 +0200 +++ uk_UA 2005-05-10 19:41:30.365893936 +0200 @@ -425,13 +425,13 @@ U0453 CYR-GHE;CYR-GZHE;MIN;IGNORE % Mac. gje reorder-after U0414 -U0402 U003CU0043U0059U0052U002DU0044U0045U003EU003CU0043U0059U0052U002DU005AU0048U0045U003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU0043U0041U0050U003EU003CU0043U0041U0050U003E;IGNORE % CYR-DJE -U040F U003CU0043U0059U0052U002DU0044U0045U003EU003CU0043U0059U0052U002DU005AU0048U0045U003E;U003CU0043U0059U0052U002DU0044U0043U0048U0045U003EU003CU004CU0049U0047U003E;U003CU0043U0041U0050U003EU003CU0043U0041U0050U003E;IGNORE % CYR-DCHE -U0405 U003CU0043U0059U0052U002DU0044U0045U003EU003CU0043U0059U0052U002DU005AU0045U003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU0043U0041U0050U003EU003CU0043U0041U0050U003E;IGNORE % CYR-DZE +U0402 CYR-DECYR-ZHE;LIGLIG;CAPCAP;IGNORE % CYR-DJE +U040F CYR-DECYR-ZHE;CYR-DCHELIG;CAPCAP;IGNORE % CYR-DCHE +U0405 CYR-DECYR-ZE;LIGLIG;CAPCAP;IGNORE % CYR-DZE reorder-after U0434 -U0452 U003CU0043U0059U0052U002DU0044U0045U003EU003CU0043U0059U0052U002DU005AU0048U0045U003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU004DU0049U004EU003EU003CU004DU0049U004EU003E;IGNORE % CYR-DJE -U045F U003CU0043U0059U0052U002DU0044U0045U003EU003CU0043U0059U0052U002DU005AU0048U0045U003E;U003CU0043U0059U0052U002DU0044U0043U0048U0045U003EU003CU004CU0049U0047U003E;U003CU004DU0049U004EU003EU003CU004DU0049U004EU003E;IGNORE % CYR-DCHE -U0455 U003CU0043U0059U0052U002DU0044U0045U003EU003CU0043U0059U0052U002DU005AU0045U003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU004DU0049U004EU003EU003CU004DU0049U004EU003E;IGNORE % CYR-DZE +U0452 CYR-DECYR-ZHE;LIGLIG;MINMIN;IGNORE % CYR-DJE +U045F CYR-DECYR-ZHE;CYR-DCHELIG;MINMIN;IGNORE % CYR-DCHE +U0455 CYR-DECYR-ZE;LIGLIG;MINMIN;IGNORE % CYR-DZE reorder-after U0435 U0454 CYR-IE;UKR-IE;MIN;IGNORE @@ -448,9 +448,9 @@ U045C CYR-KA;CYR-KJE;MIN;IGNORE reorder-after U041D -U040A U003CU0043U0059U0052U002DU0045U004EU003EU003CU0043U0059U0052U002DU0053U0049U0047U004DU004FU0055U0049U004CU003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU0043U0041U0050U003EU003CU0043U0041U0050U003E;IGNORE % CYR-NJE +U040A CYR-ENCYR-SIGMOUIL;LIGLIG;CAPCAP;IGNORE % CYR-NJE reorder-after U043D -U045A U003CU0043U0059U0052U002DU0045U004EU003EU003CU0043U0059U0052U002DU0053U0049U0047U004DU004FU0055U0049U004CU003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU004DU0049U004EU003EU003CU004DU0049U004EU003E;IGNORE % CYR-NJE +U045A CYR-ENCYR-SIGMOUIL;LIGLIG;MINMIN;IGNORE % CYR-NJE reorder-after U0427 U040B CYR-CHE;CYR-TSHE;CAP;IGNORE @@ -458,9 +458,9 @@ U045B CYR-CHE;CYR-TSHE;MIN;IGNORE reorder-after U041B -U0409 U003CU0043U0059U0052U002DU0045U004CU003EU003CU0043U0059U0052U002DU0053U0049U0047U004DU004FU0055U0049U004CU003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU0043U0041U0050U003EU003CU0043U0041U0050U003E;IGNORE % CYR-LJE +U0409 CYR-ELCYR-SIGMOUIL;LIGLIG;CAPCAP;IGNORE % CYR-LJE reorder-after U043B -U0459 U003CU0043U0059U0052U002DU0045U004CU003EU003CU0043U0059U0052U002DU0053U0049U0047U004DU004FU0055U0049U004CU003E;U003CU004CU0049U0047U003EU003CU004CU0049U0047U003E;U003CU004DU0049U004EU003EU003CU004DU0049U004EU003E;IGNORE % CYR-LJE +U0459 CYR-ELCYR-SIGMOUIL;LIGLIG;MINMIN;IGNORE % CYR-LJE reorder-after U0423 U040E CYR-OU;CYR-OUBRE;CAP;IGNORE
Bug#308581: po-debconf: po2debconf should fail when short description translations have a hard return
On Wed, May 11, 2005 at 11:12:05AM +0200, Christian Perrier wrote: Package: po-debconf Version: 0.8.23 Severity: important I tag this as important because it may lead to packages being built but not installable. In #308548, apache-ssl became uninstallable because the Finnish debconf translation had a \n in one of the short descriptions translations. This caused the generated templates file to be incorrect. See the attached fi.po file. I also attach the templates file generated by po2debconf called from dh_installdebconf. For the record, I just checked whole archives: there are no broken packages in sarge, and sid only had apache-perl and apache-ssl, which are now fixed. I am not willing to push a fixed version into sarge, and will have no free time during coming days, so this bug will be fixed next week. As po2debconf obviously cannot fix translations, I hereby propose that it *fails* in such cases with an informative message. Some builds take a long time, so I do not feel comfortable with having a build rejected because of translation errors. Another possibility would be ignoring the \n as soon as they are in short descriptions (may be tricky). I am not sure if there is a clean solution, but at least linda/lintian checks would help. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308853: debconf: should honor LC_MESSAGES for displaying templates
On Thu, May 12, 2005 at 08:08:02PM +0200, Tomas Hoger wrote: Package: debconf Version: 1.4.30.13 Severity: minor Hi! I have following locale settings on my system: LANG=sk_SK LC_CTYPE=sk_SK LC_NUMERIC=sk_SK LC_TIME=C LC_COLLATE=C LC_MONETARY=sk_SK LC_MESSAGES=C LC_PAPER=sk_SK LC_NAME=sk_SK LC_ADDRESS=sk_SK LC_TELEPHONE=sk_SK LC_MEASUREMENT=sk_SK LC_IDENTIFICATION=sk_SK LC_ALL= Environment variables LANG, LC_TIME, LC_COLLATE and LC_MESSAGES are set. Despite of LC_MESSAGES settings, debconf displays slovak templates (if available). I cannot reproduce this behavior, I guess that you also set LANGUAGE to sk_SK. You can perform similar checks with 'cp --help', and normally you should see no differences between debconf and libc applications, which demonstrates that there is no bug in debconf. Can you please make these tests and report your conclusions? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308853: debconf: should honor LC_MESSAGES for displaying templates
tags 308853 + patch
thanks
On Mon, May 16, 2005 at 05:48:08PM +0200, Tomas Hoger wrote:
Hi Denis!
Thanks for your reply!
On Sun, May 15, 2005 at 06:42:21PM +0200, Denis Barbier wrote:
[...]
I cannot reproduce this behavior, I guess that you also set LANGUAGE to
sk_SK. You can perform similar checks with 'cp --help', and normally
you should see no differences between debconf and libc applications,
which demonstrates that there is no bug in debconf. Can you please
make these tests and report your conclusions?
Yes, this was good guess. I do have LANGUAGE set to sk_SK. After
unsetting LANGUAGE templates are displayed in English as expected.
Regarding that 'cp --help' tests, when I have locale variables set as
described in previous mail (LANG set to sk_SK; LC_TIME, LC_COLLATE and
LC_MESSAGES set to C) and aslo LANGUAGE set to sk_SK, 'cp --help' is
displayed in English. I get similar behavior for other programs (e.g. mc,
mutt, vim, ...).
Hmmm, you are right, LANGUAGE environment variable is ignored when
LC_MESSAGES is set to C. I usually perform tests with locales different
from C ;)
GNU libc has this comment in dcigettext.c:
/* Ignore LANGUAGE and its system-dependent analogon if the locale is set
to C because
1. C locale usually uses the ASCII encoding, and most international
messages use non-ASCII characters. These characters get displayed
as question marks (if using glibc's iconv()) or as invalid 8-bit
characters (because other iconv()s refuse to convert most non-ASCII
characters to ASCII). In any case, the output is ugly.
2. The precise output of some programs in the C locale is specified
by POSIX and should not depend on environment variables like
LANGUAGE or system-dependent information. We allow such programs
to use gettext(). */
if (strcmp (locale, C) == 0)
return locale;
The first item does not apply here because your LC_CTYPE is not ASCII,
and we do not care about standardized output. IMO there is no need for
debconf to implement this special casing, and my first intention was to
close this bug. Debconf maintainers, you can either close this bug
report or apply the attached patch to mimic glibc more closely.
I did few more tests with debconf. I've unset all LC_* variables and also
LANG and LANGUAGE to get clean environment. Then I tried following
commands:
LC_MESSAGES=sk_SK dpkg-reconfigure pkg
- Slovak window label and button labels, English template text
LC_MESSAGES=sk_SK LC_CTYPE=sk_SK dpkg-reconfigure pkg
- labels and template text in Slovak
I believe this test and its results should be easily reproducible. Hope I
haven't made any mistake now ;).
As you can see, there is not only difference in interpretation of locale
settings among debconf and other libc apps, but also among parts of
debconf.
See http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html
If different character sets are used by the locale categories, the
results achieved by an application utilising these categories are
undefined.
So yes, there are some discrepancies here, but these are not bugs.
You will run into trouble whenever you set LC_MESSAGES to a locale
with an encoding different from LC_CTYPE. On the other hand, setting
LC_CTYPE=sk_SK and LC_MESSAGES=C is safe because iso-8859-2 is a
superset of ASCII.
Denis
--- Debconf.orig/Template.pm2005-05-05 01:22:56.0 +0200
+++ Debconf/Template.pm 2005-05-16 21:38:08.704550568 +0200
@@ -408,7 +408,7 @@
my $language=setlocale(5); # LC_MESSAGES
my @langs = ();
# LANGUAGE has a higher precedence than LC_MESSAGES
- if (exists $ENV{LANGUAGE} $ENV{LANGUAGE} ne '') {
+ if ($language ne 'C' exists $ENV{LANGUAGE} $ENV{LANGUAGE} ne '') {
foreach (split(/:/, $ENV{LANGUAGE})) {
push (@langs, _getlocalelist($_));
}
Bug#309326: console-tools: CapsLock doesn't work properly for extended kmap keycode definitions
On Mon, May 16, 2005 at 02:37:31PM +0200, Pawe Konieczny wrote: Package: console-tools Version: 1:0.2.3dbs-56 Severity: normal The proper behavior of CapsLock is to shift small letters to caps and - when combined with Shift - to shift caps to small letters. According to documentation, this behavior is enabled when a key is defined in one of the following two ways in the kmap file: having just one plain ASCII letter or by adding the + sign before the symbol. Example: keycode 24 = o keycode 24 = +o +O However, the second form does not work, it still generates small o when CapsLock is enabled. Right, it seems that #263580 has been closed but not fixed. This bug makes it imposible to properly define any keymap with diacritical (non-ASCII) characters. For instance, to define , the following keycode definitions are needed: [...] All my consoles are in the unicode mode, non-framebuffer. The keymaps used to work in the past (maybe the problem is kernel related). This should work when #263580 is really fixed, but take care that because of kernel limitations, this '+' notation works in unicode mode only with iso-8859-1 characters. Denis
Bug#309332: INTL:vi
tags 309332 + pending thanks On Mon, May 16, 2005 at 11:19:38PM +0930, Clytie Siddall wrote: Package: belocs-locales-data Version: 2.3.4-12 Severity: minor Tags: l10n, patch The Vietnamese translation for debconf: belocs-locales-data Hi Clytie, I am going to upload a new version with your translation very soon. Please note that for now, these templates are copied from the locales package, so you should file another bugreport against this package with this same file (but after changing header contents). There are duplicates because I did not want to introduce new strings just before sarge release, these templates will change afterwards. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343082: ITP: netgen -- automatic 3d tetrahedral mesh generator
On Wed, Jan 04, 2006 at 05:47:43PM +0100, Christophe Prud'homme wrote: [ Monday 19 December 2005 18:40 ] | On Tue, Dec 13, 2005 at 08:28:19AM +0100, Christophe Prud'homme wrote: | FYI, netgen is part also of gmsh. | | are u planning to package netgen ? if not I can take netgen in charge. | | Hi Christophe, | | upstream netgen is a standalone application, with its UI, mesher and | solver. So yes, the Netgen/libsrc directory embedded in gmsh will | also be included in the netgen package. | In fact, I am primarily interested in shipping a libnetgen-dev package | containing a static library of this directory, because I need this | library at work. Denis, first things first: happy new year ! I have finished packaging netgen : netgen (gui), netgen-doc (pdf+tutorial) and libnetgen-dev (static libraries+headers) should I upload ? do u want to have a look ? Hi Christophe, happy new year too. I also worked on preliminary packages, but have no problem with your upload if you want to maintain netgen. Please also put them online somewhere until they enter Debian archives, I will surely need them very soon. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291853: xkbcomp warns about RALT having 2 symbols
On Sun, Jan 01, 2006 at 02:22:18PM +0100, Mario 'BitKoenig' Holbe wrote: Hello, On Sun, Jan 23, 2005 at 05:57:09PM +0100, Mario Holbe wrote: on xserver start I get the following warning: The XKEYBOARD keymap compiler (xkbcomp) reports: Warning: Type ONE_LEVEL has 1 levels, but RALT has 2 symbols Ignoring extra symbols This one is a warning without any effect. (==) Using config file: /etc/X11/xorg.conf expected keysym, got dead_diaresis: line 143 of pc/de But here is the actual error, it should certainly be dead_diaeresis. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337637: xlibs: (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap
On Sat, Nov 05, 2005 at 02:51:04PM +0100, Xavier Bestel wrote: Package: xlibs Version: 6.8.99.901.dfsg.1-2 Severity: normal When installing xlibs from experimental, my keyboard (french layout) doesn't work anymore. NB: this bug has been reported just after installing xlibs from unstable, so the included logs are probably wrong. Hi, Do you still have trouble with 6.9? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346307: xserver-xfree86 Xkb Keyboard Layout Switching Not Working in XF86Config-4
tags 346307 sarge
thanks
On Sat, Jan 07, 2006 at 12:09:44AM +0200, Victor Ivanov wrote:
Package: xserver-xfree86
Version: XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-14sarge1 20050901212727)
Hi,
I have the following options i my /etc/X11/XF86Config-4 config file:
Section InputDevice
Identifier Generic Keyboard
Driver keyboard
Option CoreKeyboard
Option AutoRepeat 500 30
Option XkbRules xfree86
Option XkbModel pc104
Option XkbLayout us,bg(phonetic)
Option XkbOptions grp:alt_shift_toggle
EndSection
I think it's some kind of an internal bug to the XFree86 server. Xorg has no
problems handling the same configuration for keyboard layout switching (of
course in xorg the Driver value is kbd and the XkbRules Option has a value
xorg).
I am using Debian GNU/Linux version 3.1 sarge
Kernel: Linux debian 2.6.8-2-k7 #1 Tue Aug 16 14:00:15 UTC 2005 i686 GNU/Linux
Hi,
there was indeed a bug in the bg layout, you have to remove the line
key RALT { [ Alt_R, Meta_R ]};
at the end of this file.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345454: xserver-xorg: Upgrade to 6.9.0 broke vt switching
On Sat, Dec 31, 2005 at 06:57:49PM +0200, Shai Berger wrote: Package: xserver-xorg Version: 6.9.0.dfsg.1-1 [...] The upgrade to this version broke console switching under X for normal users. That is, Ctrl-Alt-F(N) does not work under X, but it works perfectly in non-X virtual terminals. Hi, there had been some trouble with xlibs-data. Have you been able to fix it yourself? If not, please try apt-get -f install apt-get install xlibs xlibs-data Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345409: New upgrade breaks login as there is no multikey anymore
On Sat, Dec 31, 2005 at 10:25:18AM +0100, Klaus Ethgen wrote: So please, if you break the default behavior of X to use shift-ralt as multikey then just allow the sysadmin to fix this bug by config!!! This setting was insane, Shift+AltGr was different from AltGr+Shift which is very confusing, so it is good to see that upstream dropped it. Of course we could put ralt_switch_multikey back in Debian, but if your keyboard has some spare keys, adding a compose: option would be much better. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345409: New upgrade breaks login as there is no multikey anymore
On Sat, Jan 07, 2006 at 02:33:12PM +0100, Frans Pop wrote: On Saturday 07 January 2006 13:56, Denis Barbier wrote: On Sat, Dec 31, 2005 at 10:25:18AM +0100, Klaus Ethgen wrote: Of course we could put ralt_switch_multikey back in Debian, but if your keyboard has some spare keys, adding a compose: option would be much better. It could well be that I misunderstand the comment about ralt, but... Please leave support for ralt for composing characters. It is essential for Dutch users who normally have a keyboard with US layout but need to be able to easily type accented characters like é è ë ó ç. IMO ralt is by far the cleanest way to do that. My current keyboard settings are (in Sarge KDE): setxkbmap -option -option grp:switch,compose:ralt Hi Frans, this option is still supported, and there is no reason to drop it. The issue here is that historically Shift+AltGr was defined as a compose key, but this caused trouble, see #270235 for instance. Denis
Bug#310635: some programs segfault when run with belocs-locales-* installed
On Mon, Oct 03, 2005 at 01:01:41AM +0200, Denis Barbier wrote:
On Sat, Oct 01, 2005 at 01:29:10PM +0200, Denis Barbier wrote:
I was eventually able to test this patch. Eugeniy's test case still
segfaults, I will work on a better patch, strcoll_l.c needs to be
fixed too.
Here is a revised patch. It seems to work fine, but it has not been
fully tested yet. I send it in case someone is working on this bug
report, and will add the patch tag after more testing.
Upstream committed a better fix in strxfrm_l.c, so here is a revised
dpatch. It has been tested for weeks without trouble on my machine.
Denis
#! /bin/sh -e
# DP: Description: Fix segfault when strings contain a mix of forward
# and backward rules.
# DP: Related bugs: #310635 BZ645
# DP: Dpatch Author: Denis Barbier [EMAIL PROTECTED]
# DP: Patch Author: Denis Barbier
# DP: Upstream status: fix in strxfrm_l.c has been committed upstream
# DP: and strcoll_l.c has not been submitted yet.
# DP: Test case: the following command segfaults in en_US.UTF-8 locale
# DP:when BZ645 is fixed:
# DP:echo 2d d194 0a 2d d194 0a | xxd -r -p | sort
# DP: Date: 2005-11-01
if [ $# -ne 2 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch -d $2 -f --no-backup-if-mismatch -p1 $0;;
-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1 $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
esac
exit 0
--- libc/string/strxfrm_l.c 14 Mar 2004 20:52:47 - 1.4
+++ libc/string/strxfrm_l.c 15 Oct 2005 20:49:18 - 1.5
@@ -1,4 +1,4 @@
-/* Copyright (C) 1995,96,97,2002, 2004 Free Software Foundation, Inc.
+/* Copyright (C) 1995,96,97,2002, 2004, 2005 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Written by Ulrich Drepper [EMAIL PROTECTED], 1995.
@@ -210,8 +210,9 @@
/* Handle the pushed elements now. */
size_t backw;
- for (backw = idxcnt - 1; backw = backw_stop; --backw)
+ for (backw = idxcnt; backw backw_stop; )
{
+ --backw;
len = weights[idxarr[backw]++];
if (needed + len n)
@@ -293,8 +294,9 @@
/* Handle the pushed elements now. */
size_t backw;
- for (backw = idxcnt - 1; backw = backw_stop; --backw)
+ for (backw = idxcnt; backw backw_stop; )
{
+ --backw;
len = weights[idxarr[backw]++];
if (len != 0)
{
--- libc/string/strcoll_l.c 14 Mar 2004 20:52:47 - 1.4
+++ libc/string/strcoll_l.c 23 May 2005 22:35:59 -
@@ -370,7 +370,10 @@
/* The last pushed character was handled. Continue
with forward characters. */
if (idx1cnt idx1max)
- idx1now = idx1cnt;
+ {
+ idx1now = idx1cnt;
+ backw1_stop = ~0ul;
+ }
else
{
/* Nothing anymore. The backward sequence
Bug#236252: Please move all compose files in /etc
On Thu, Oct 13, 2005 at 06:08:59PM +0300, Anton Zinoviev wrote: Hi! I was just to report a new bug that the Compose files should be moved in /etc when I saw this bug about /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose Please move to /etc all Compose files, not only the cited in the bug report. Hi Anton, please have a look at http://www.xfree86.org/4.4.0/RELNOTES5.html#42 Sysadmins can override default settings by providing customized compose files, say /etc/X11/Compose: include %L # My own compose sequences Multi_key f o o : bar and tweak init scripts to set XCOMPOSEFILE=/etc/X11/Compose. IMO this solution is much better than having lots of conffiles. If this is a reasonable solution, maybe this bug can be closed? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347173: glibc: Romanian days are written with mixed case letters/Romanian alplhabet reordered
reassign 347173 locales thanks On Mon, Jan 09, 2006 at 09:29:40AM +0200, Eddy Petrişor wrote: Package: glibc Severity: wishlist Tags: patch Hello, The current glibc version contains several errors which are corrected by the attached patch: * locales/ro_RO: Correct the sorting order of the letters a circumflex and a with breve according to the Romanian alphabet. * locales/ro_RO: Do not use capital A with breve within day names * locales/ro_RO: Use Romanian post-92 writing rules within day and abday Please patch debian sources until upstream integrates it. Hi Eddy, could you please have a look at #119528? I do not know what to do with this bugreport. Denis
Bug#236252: Please move all compose files in /etc
On Wed, Jan 11, 2006 at 12:02:27AM +0200, Anton Zinoviev wrote: On Mon, Jan 09, 2006 at 11:55:57AM +0100, Denis Barbier wrote: IMO this solution is much better than having lots of conffiles. I agree. If this is a reasonable solution, maybe this bug can be closed? Yes. It would be nice to provide /etc/X11/Compose file and to set the XCOMPOSEFILE variable correspondingly. Otherwise the users will not know about this feature. My suggestion was that sysadmins do the work if they want to, but your proposal is much better. If there is no objection, I will implement it. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345641: libc6: libnss_dns-2.3.5.so incompatible with libc-2.3.5.so : version GLIBC_PRIVATE not defined
Package: libc6 Version: 2.3.5-8 Severity: grave Justification: renders package unusable not defined link time reference of GLIBC_PRIVATE in libc-2.3.5.so call from symbol __res_maybe_init of libnss_dns-2.3.5.so i.e. exact error message of webmin was: /usr/share/webmin-1.220/webmin/upgrade.cgi: relocation error: /lib/libnss_dns.so.2: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference Hi, does this bug still exist after restarting webmin? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347535: xkb-data: error message from GNOME about XKB configuration
On Wed, Jan 11, 2006 at 12:39:45PM +0100, Laurent Bonnaud wrote: Package: xkb-data Version: 0.6-2 Severity: normal Hi, I use KDE as my primary desktop. I also use GNOME applications. I start gnome-font-properties manually to activate my font size preferences and a keyboard customization: Compose action on the Menu key. After a xorg upgrade, I read confusing instructions about xfree86/xorg XkbRules and the xkb-data package. But did you have trouble with your keyboard configuration before? If not, you have no reason to install xkb-data ;) Anyway if you want to use xkb-data, note that a command-line flag needs to be added to X startup, see /usr/share/doc/xkb-data/README.Debian for details. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347531: /usr/X11R6/lib/X11/locale/compose.dir: compose not working if LC_CTYPE=cs_CZ.UTF-8
On Wed, Jan 11, 2006 at 01:27:46PM +0100, David Martínez Moreno wrote: tag 347531 + pending thanks for the fish El miércoles, 11 de enero de 2006 12:16, Marek Schmidt escribió: Compose is not working in Qt-based applications (and in GTK applications if input module set to xim) if LC_CTYPE=cs_CZ.UTF-8 I've noticed that /usr/X11R6/lib/X11/locale/compose.dir contains lines with cz_CZ.UTF-8: en_US.UTF-8/Compose cz_CZ.UTF-8 correct language code is cs, not cz for czech language, though. It works OK when I replace cz_CZ.UTF-8 with cs_CZ.UTF-8 in compose.dir This error seems to be introduced by patch in xorg-x11-6.9.0.dfsg.1/debian/patches/general/011a_recognize_glibc_2.3.2_loc ale_names.diff Hello, Marek. Well, this patch in fact removes the line: en_US.UTF-8/Compose: ca_ES.UTF-8 -en_US.UTF-8/Compose: cs_CZ.UTF-8 en_US.UTF-8/Compose: cy_GB.UTF-8 en_US.UTF-8/Compose: cz_CZ.UTF-8 en_US.UTF-8/Compose: da_DK.UTF-8 @@ -269,17 +333,28 @@ I am committing a fix for this, but I would prefer that Denis express his opinion about this issue. This removal was clearly an error, cz_CZ could have been dropped instead. But I see no reason to drop locales because they are not supported by glibc. They are sometimes legitimate (say Esperanto, for instance, or Cyrillic languages with CP1251 encoding), users have to generate their glibc locales by hand, and we make their lives even harder by removing entries from this file. We should only add entries or fix existing ones like in the s/iso/ISO/ case, not remove them. Denis
Bug#347496: xlibs: ca_enhanced keyboard doesn't work anymore with 6.9.0.dfsg
On Tue, Jan 10, 2006 at 11:06:21PM -0500, Felix-Antoine Bourbonnais wrote: Package: xlibs Version: 6.9.0.dfsg.1-2 Severity: normal Since I have upgraded my xlibs package to 6.9.0.dfsg, my French Canadian (ca_enhanced) keyboard doesn't work anymore in XOrg. I have an error about the xkb/symbols/pc/ca_enhanced file missing. If I try to copy xkb/ca_enhanced into xkb/pc/, the file is found but the keyboard still doesn't work correctly. In fact, I'm not able to type the @ (ALT+2), the ? and keys with the combination ALT+CTRL, such as ALT+CTRL+F1. This layout is obsolete, you can set instead Option XkbLayout ca Option XkbVariant fr Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347567: console-data: euro sign doesn't work on vt's
On Wed, Jan 11, 2006 at 04:23:35PM +0100, Christoph Anton Mitterer wrote: Package: console-data Version: 2002.12.04dbs-52 Severity: normal Hi. When I'm on a real virtual console (not an X emulation or so) the euro-sign doesn't appear when I press AltGr+e, but the sign that appears is (I thin) the international currency sign. Pressing AltGr+c leads to the cent-sign, which is correct. vt-is-UTF8 says that my vt is in UTF8 mode. kbd_mode says that my keyboard is in UTF8 mode, too. Type echo € | od -tx1 (of course you will not see the euro sign on your screen but the other symbol). If it displays 000 e2 82 ac 0a this means that your input is right but your font does not have this symbol, you have to select another font (like lat0-sun16) in /etc/console-tools/config. You can see my console-configuration below. As you can see, I'm using my own locale. I have it attaced at the end. btw: Can you point me to a good ressource where everything about locales/charsets/keyboardmodes/etc is explained. Please ask your questions on the debian-i18n mailing list http://lists.debian.org/debian-i18n/ Denis
Bug#347496: xlibs: ca_enhanced keyboard doesn't work anymore with 6.9.0.dfsg
On Wed, Jan 11, 2006 at 11:44:50AM -0500, Felix-Antoine Bourbonnais wrote: Ok It's better but it's still not perfect. Normally, to write è, I type ` + e. But with this configuration the è is done directly with one key. There is other things like the for which I usually use SHIFT+2 but now it's done by SHIT+. . You are right, the line $pcmodels ca = pc/pc(%m)+pc/ca(multi)+pc/ca(multi-2gr):2+group(rctrl_switch) in /etc/X11/xkb/rules/xorg prevents the fr variant to be loaded. You can check that with setxkbmap -print I will remove this line (and the next one) from /etc/X11/xkb/rules/xorg, as has been done in xkeyboard-config. Denis
Bug#347535: xkb-data: error message from GNOME about XKB configuration
On Wed, Jan 11, 2006 at 07:15:50PM +0100, Laurent Bonnaud wrote: But did you have trouble with your keyboard configuration before? Not really. I just wanted a Compose key. Using a GNOME tool under KDE is suboptimal, and this tool has been removed in recent GNOME versions, or I cannot find it. And I was looking for a solution that would allow me to enable it for all users. Ok, then you can edit /etc/X11/xorg.conf manually and add Option XkbOptions compose:menu Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347557: xlibs: [6.9 transition] XKB error upon GNOME startup
On Wed, Jan 11, 2006 at 04:12:19PM +0200, Martin-Éric Racine wrote: Package: xlibs Version: 6.9.0.dfsg.1-3 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After upgrading GNOME to the 2.12 packages in Unstable, I keep on getting the following message at every login: [...] layouts = [fi,ru phonetic] model = pc105 overrideSettings = false options = [grp grp:shift_toggle] [EMAIL PROTECTED]:/home/q-funk$ * This keymap combination used to work just fine with Experimental GNOME packages (what just entered Unstable is a rebuild of the same packages). The X.org changelog suggests trying xkb-data whenever bugs pop up, but this package is not available in Unstable. Hi Martin-Éric, it seems that grp:shift_toggle has been renamed into grp:shifts_toggle to be consistent with other *_toggle options. Your GNOME settings have to be updated; I do not know if this can be done automatically, but you can launch the keyboard layout switcher which should display this new option. Denis
Bug#347557: xlibs: [6.9 transition] XKB error upon GNOME startup
On Wed, Jan 11, 2006 at 11:35:39PM +0200, Martin-Éric Racine wrote: Anyhow, even after purging the packages and force-removing /etc/X11/xkb, then re-installing the packages, adding secondary keymaps via GNOME's keyboard preferences again made the error message appear. Does it work for some layouts, or always fail? Denis
Bug#347557: xlibs: [6.9 transition] XKB error upon GNOME startup
On Thu, Jan 12, 2006 at 12:24:14AM +0200, Martin-Éric Racine wrote: ke, 2006-01-11 kello 23:17 +0100, Denis Barbier kirjoitti: On Wed, Jan 11, 2006 at 11:35:39PM +0200, Martin-Éric Racine wrote: Anyhow, even after purging the packages and force-removing /etc/X11/xkb, then re-installing the packages, adding secondary keymaps via GNOME's keyboard preferences again made the error message appear. Does it work for some layouts, or always fail? Actually, it's not just layouts. As a test, I tried selecting another keyboard geometry than pc-105 in the GNOME keyboard capplet. This also made the error dialogue appear. In fact, any setting I played with on that layout preferences tab made the error dialogue reappear. Normally xbase-clients installs symlinks under /etc/X11/xkb, please check that they are there: /etc/X11/xkb/ compiled - /var/lib/xkb xkbcomp - /usr/X11R6/bin/xkbcomp Denis
Bug#347557: xlibs: [6.9 transition] XKB error upon GNOME startup
On Wed, Jan 11, 2006 at 04:12:19PM +0200, Martin-Éric Racine wrote: [...] (**) Option XkbRules xorg (**) Generic Keyboard: XkbRules: xorg (**) Option XkbModel pc105 (**) Generic Keyboard: XkbModel: pc105 (**) Option XkbLayout fi (**) Generic Keyboard: XkbLayout: fi Back to your original report, there is no error in your logs, so X configuration looks fine. Can you run setxkbmap -layout fi,ru -variant ,phonetic -option -option grp:shifts_toggle in a terminal? Denis
Bug#347557: xlibs: [6.9 transition] XKB error upon GNOME startup
On Thu, Jan 12, 2006 at 01:14:35AM +0200, Martin-Éric Racine wrote: Back to your original report, there is no error in your logs, so X configuration looks fine. Can you run setxkbmap -layout fi,ru -variant ,phonetic -option -option grp:shifts_toggle in a terminal? $ setxkbmap -v -layout fi,ru -variant ,phonetic -option -option grp:shifts_toggle Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Warning! Multiple definitions of layout variant Using command line, ignoring X server Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols: pc/pc(pc105)+pc/fi+pc/ru(phonetic):2+group(shifts_toggle)+group(shifts_toggle) geometry: pc(pc105) $ Ok, there is no error message, you can check that everything works fine. I already committed a patch so that options are not listed twice. I notice that the above says xfree86. Shouldn't this be xorg? No, you can see from /etc/X11/xkb/rules/xorg: ! model = keycodes macintosh_old = macintosh powerpcps2= powerpcps2 pc98 = xfree98(pc98) abnt2 = xfree86(abnt2) jp106 = xfree86(jp106) * = xfree86 Thus all models not listed explicitly (like pc105) get keycodes from /etc/X11/xkb/keycodes/xfree86, this is normal. I see nothing wrong, xlibs works just fine, maybe this is a GNOME problem? Denis
Bug#271549: Still waiting
On Thu, Jan 12, 2006 at 04:21:08PM +0300, Cyril Bouthors wrote: It's been 1.5 year now, any news? Hi Cyril, it has been committed few days ago and will appear with the next upload. Sorry for the delay. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324647: /etc/X11/xkb/symbols/pl: strange characters mapping with Polish keymap (pl)
On Thu, Jan 12, 2006 at 01:40:12PM +0100, Bartosz Fenski aka fEnIo wrote: On Thu, Aug 25, 2005 at 07:30:29PM +0200, Denis Barbier wrote: But I see no reason for such behaviour. It is annoying, cause we've got plenty of common used words that has -ów suffix. To get this suffix we have to push alt+o, then release alt and push w. Since alt+w gives as the same as alt+l it often happens that I see wrongly written words with -ół. That makes sense, I will forward your request to the xkeyboard-config mailing list. What's the current state of this bugreport? Did xkeyboard maintainers dismiss this change? If yes, then why? My bad, I forgot to get back to you, sorry. Could you please point me to the thread wrt this issue on their list? Please see http://listserv.bat.ru/xkb/Message/820.html http://listserv.bat.ru/xkb/Message/823.html http://listserv.bat.ru/xkb/Message/828.html http://listserv.bat.ru/xkb/Message/829.html and feel free to join this discussion. Denis
Bug#347557: xlibs: [6.9 transition] XKB error upon GNOME startup
On Thu, Jan 12, 2006 at 12:13:52PM +0200, Martin-Éric Racine wrote: to, 2006-01-12 kello 09:59 +0100, Michel Dänzer kirjoitti: reassign 347557 libxklavier10 kthxbye On Thu, 2006-01-12 at 02:00 +0200, Martin-Éric Racine wrote: I see nothing wrong, xlibs works just fine, maybe this is a GNOME problem? You're welcome to reassign to gnome-control-center (which provides gnome-keyboard-properties) if you think that this is appropriate. I've attached its dependency listing here just in case. Package: gnome-control-center Version: 1:2.12.2-1 Versions of packages gnome-control-center depends on: [...] ii libxklavier102.0-0.3 X Keyboard Extension high-level AP Downgrading libxklavier to 2.0-0.2 seems to fix things here. It didn't fix anything here; I still get that error dialogue. You may try the following: $ apt-get source libxklavier10 $ cd libxklavier-2.0 $ fakeroot ./debian/rules build $ ./tests/test_config -d 1000 -g This command could display some useful debug information. If everything looks fine, this bug may be reassigned to gnome-control-center? ;) Denis
Bug#347173: glibc: Romanian days are written with mixed case letters/Romanian alplhabet reordered
On Fri, Jan 13, 2006 at 09:41:10AM +0200, Eddy Petrişor wrote: Attached are the results of the tests. What I can say is that: - as one can easily see the default ro_RO locale is broken (not recognised) - the ro_RO.ISO-8859-16 is not recognised (I feel that I am doing something wrong here) I made the patching over the glibc with my patch and tested it. The ro_RO locale looks the same as in the tests for Ionel's patch. Apparently there is something that I don't understand in the gentoo system. (testing with Gentoo as I don't have an Internet connection at home and my appartment mate has gentoo installed). So I misjudged when I said that the ro_RO locale is broken. You can check with 'localedef --help' where locales are looked at; on Debian: System's directory for character maps : /usr/share/i18n/charmaps repertoire maps: /usr/share/i18n/repertoiremaps locale path: /usr/lib/locale:/usr/share/i18n The other important point is whether your system has a single archive file (/usr/lib/locale/locale-archive) or multiple directories (/usr/lib/locale/ro_RO.utf8, etc.). This is controlled by the --no-archive flag of localedef. You can generate both to make sure that you are overriding system locales: $ localedef -i /path/to/ro_RO -f UTF-8 ro_RO.UTF-8 $ localedef -i /path/to/ro_RO -f UTF-8 --no-archive ro_RO.UTF-8 Maybe gentoo modified the default behavior, and added an --archive flag instead? If an absolute path is not specified for the -i flag, locale source file is searched in . and $I18NPATH. You check then your changes by requesting some informations: $ locale -k charmap day abday mon abmon But if you want to compare your locale to the default one, a simpler alternative is to build your locale into a different location, for instance: $ export LOCPATH=$(mktemp -d) $ localedef -i /path/to/ro_RO -f UTF-8 $LOCPATH/ro_RO.UTF-8 $ locale -k charmap day abday mon abmon Compare with default settings $ unset LOCPATH $ locale -k charmap day abday mon abmon If you do not find your changes on output, you can run $ strace -e open locale -k charmap day abday mon abmon to check which files are read. Denis
Bug#345796: Acknowledgement (xlibs: typo in /etc/X11/xkb/symbols/compose)
On Fri, Jan 13, 2006 at 10:58:07AM +0100, David Martínez Moreno wrote: El martes, 3 de enero de 2006 16:24, Andreas Kroschel escribió: Sorry, this was an error. Maybe it's a typo, but it does *not* stop CAPS from working as compose key. Please change severity to minor or close this bug. Denis? It does not matter. This definition has not yet entered xorg but is in xkeyboard-config with the patch from this bugreport applied. So I modified 091_xkb_implement_compose:caps.diff too, it is likely that xorg CVS will be synced and we will then drop 091_xkb_implement_compose:caps.diff without having to wonder which changes need to be kept. Denis
Bug#340031: [tex-common] Italian translation not available
reopen 340031 thanks Hi, the file sent to this bugreport was named tex-common_0.10_it.po.gz but you renamed it to it.po without uncompressing it. Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343082: ITP: netgen -- automatic 3d tetrahedral mesh generator
Package: wnpp Severity: wishlist Owner: Denis Barbier [EMAIL PROTECTED] * Package name: netgen Version : 4.4 Upstream Author : Joachim Schoeberl * URL : http://www.hpfem.jku.at/netgen/ngs44.tar.gz * License : LGPL Description : automatic 3d tetrahedral mesh generator Netgen is an automatic mesh generation tool for two and three dimensions. Netgen generates triangular or quadrilateral meshes in 2D, and tetrahedral meshes in 3D. . The input for 2D is described by spline curves, and the input for 3D problems is either defined by constructive solid geometries, or by the standard STL file format. Netgen contains modules for mesh optimization and hierarchical mesh refinement. Curved elements are supported of arbitrary order. . Since version 4.4, Netgen also embeds NGSolve, which is a general purpose 3D finite element solver. Version 1.x supports scalar (heat flow), elasticity and magnetic field problems. NGSolve performs adaptive mesh refinement, the matrix equations are solved by optimal order multigrid methods. . Homepage: http://www.hpfem.jku.at/netgen/ Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343287: xkb-data: please add caps as a compose key
On Wed, Dec 14, 2005 at 09:12:31AM +0100, Andreas Kroschel wrote: Package: xkb-data Version: 0.6-1 Severity: wishlist Please add caps as a compose key, as it is already defined in the current xlibs package. Please have a look at /etc/X11/xkb-data/symbols/compose this definition already exists. Or did I miss something? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343287: xkb-data: please add caps as a compose key
tags 343287 pending thanks On Wed, Dec 14, 2005 at 01:42:12PM +0100, Andreas Kroschel wrote: * Denis Barbier: Please have a look at /etc/X11/xkb-data/symbols/compose this definition already exists. Or did I miss something? Sorry, I can't find it in a freshly downloaded xkb-data_0.6-1_all.deb. There are only definitions for ralt, rwin, menu and rctrl. You are right, my local copy of xkb-data_0.6-1_all.deb differs from the one I uploaded. Strange, it is likely that I made some changes locally and forgot to bump version number when testing. So the good news is that the requested change has already been fixed in my repository ;) By the way, the sclk_toggle definition in /etc/X11/xkb-data/symbols/group is gone too, compared to xlibs. It makes sense, I will add it too. Thanks for your report. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326637: Should /etc/X11/xkb/* be conffiles at all?
On Fri, Dec 16, 2005 at 02:03:25AM +, Daniel Stone wrote: On Thu, Dec 15, 2005 at 08:28:41PM +0100, Jerome Warnier wrote: I wonder if those files should really be conffiles at all, as it is asking for a lot of confirmations to override with new maintainer's version from anyone trying to upgrade from one version to another (for example Sarge to Etch), while those files have never been modified by the user. If they are not conffiles, they should not be in /etc either (they take 2.4M on my Sarge) by FHS. They are conffiles, yes. The question is whether these files should be conffiles at all. IMO this is a very good question, I had a look (not closely though) at your transition to xkeyboard-config and it seems to me that the fact that XKB files are conffiles made this transition more difficult. On the other hand, people sometimes want to modify such files (#236252 for instance) and do not want to lose their changes when upgrading. Maybe a solution is to have files installed by packages under a given directory $dir1 (under /usr?), sysadmins can add/customize files under /etc, and a magic command run after editing /etc files would merge /etc and $dir1 into $dir2 (under /var?). X clients and servers should then be modified to look for their files under $dir2:$dir1. Do you believe that this is feasible/desirable? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343595: shadow: [a-z] must be used in maintainer scripts only under C locale
Package: shadow
Severity: normal
Tags: patch
Hi,
[a-z] may not represent all 26 ASCII lowercase letters in regular
expressions, eg. Estonian collation sorts z between s and t:
$ echo rstuvwxyz | LC_ALL=en_US.UTF-8 sed -e 's/[a-z]//g'
$ echo rstuvwxyz | LC_ALL=et_EE.UTF-8 sed -e 's/[a-z]//g'
tuvwxy
As shown above, this applies to sed, but also awk, grep, expr
$ echo tuv | LC_ALL=et_EE.UTF-8 awk '/[a-z]/ {print}'
$ echo tuv | LC_ALL=et_EE.UTF-8 grep [a-z]
$ LC_ALL=et_EE.UTF-8 expr tuv : [a-z]
$
and many more.
On the other hand, some commands always work with C collation rules,
most notably tr:
$ echo 1rstuvwxyz2 | LC_ALL=et_EE.UTF-8 tr -d a-z
12
or perl and python if they are not told to switch to user's locale.
One must then switch to C locale to avoid those collation issues,
see attached patch. I also added switches to 'tr' even if it is not
needed for now because documentation tells that 'tr' may get fixed.
Thanks
Denis
diff -ur debian.orig/passwd.config debian/passwd.config
--- debian.orig/passwd.config 2005-12-16 13:10:49.0 +0100
+++ debian/passwd.config2005-12-16 13:19:56.0 +0100
@@ -225,11 +225,11 @@
userdefault=tbm
;;
*)
- userdefault=`echo $RET | sed 's/ .*//'
| tr A-Z a-z`
+ userdefault=`echo $RET | sed 's/ .*//'
| LC_ALL=C tr A-Z a-z`
;;
esac
if test -n $userdefault \
- expr $userdefault : '[a-z][-a-z0-9]*$'
/dev/null; then
+ LC_ALL=C expr $userdefault :
'[a-z][-a-z0-9]*$' /dev/null; then
db_set passwd/username $userdefault
fi
fi
@@ -243,7 +243,7 @@
# Verify the user name, loop with message if bad.
db_get passwd/username
USER=$RET
- if ! expr $USER : '[a-z][-a-z0-9]*$' /dev/null; then
+ if ! LC_ALL=C expr $USER : '[a-z][-a-z0-9]*$'
/dev/null; then
db_fset passwd/username seen false
db_fset passwd/username-bad seen false
db_input critical passwd/username-bad
Bug#343596: sysvinit: [a-z] must be used in maintainer scripts only under C locale
Package: sysvinit
Version: 2.86.ds1-6
Severity: normal
Tags: patch
Hi,
[a-z] may not represent all 26 ASCII lowercase letters in regular
expressions, eg. Estonian collation sorts z between s and t:
$ echo rstuvwxyz | LC_ALL=en_US.UTF-8 sed -e 's/[a-z]//g'
$ echo rstuvwxyz | LC_ALL=et_EE.UTF-8 sed -e 's/[a-z]//g'
tuvwxy
As shown above, this applies to sed, but also awk, grep, expr
$ echo tuv | LC_ALL=et_EE.UTF-8 awk '/[a-z]/ {print}'
$ echo tuv | LC_ALL=et_EE.UTF-8 grep [a-z]
$ LC_ALL=et_EE.UTF-8 expr tuv : [a-z]
$
and many more.
On the other hand, some commands always work with C collation rules,
most notably tr:
$ echo 1rstuvwxyz2 | LC_ALL=et_EE.UTF-8 tr -d a-z
12
or perl and python if they are not told to switch to user's locale.
One must then switch to C locale to avoid those collation issues,
see attached patch. In this particular case, it is very unlikely
that someone gets hit by this bug, but well, it is easy to fix.
Thanks
Denis
diff -ru debian.orig/initscripts/preinst debian/initscripts/preinst
--- debian.orig/initscripts/preinst 2005-12-16 13:31:48.0 +0100
+++ debian/initscripts/preinst 2005-12-16 13:33:34.0 +0100
@@ -29,7 +29,7 @@
echo Saving variables from /etc/init.d/boot ..
[ ! -d /etc/default ] mkdir /etc/default
rm -f /etc/default/rcS.sed
- grep '^[A-Z]*=' /etc/init.d/boot | (
+ LC_ALL=C grep '^[A-Z]*=' /etc/init.d/boot | (
while read line
do
var=`echo $line | sed 's/=.*$//'`
Bug#343597: [a-z] must be used in maintainer scripts only under C locale
Package: svgalib
Severity: normal
Tags: patch
Hi,
[a-z] may not represent all 26 ASCII lowercase letters in regular
expressions, eg. Estonian collation sorts z between s and t:
$ echo rstuvwxyz | LC_ALL=en_US.UTF-8 sed -e 's/[a-z]//g'
$ echo rstuvwxyz | LC_ALL=et_EE.UTF-8 sed -e 's/[a-z]//g'
tuvwxy
As shown above, this applies to sed, but also awk, grep, expr
$ echo tuv | LC_ALL=et_EE.UTF-8 awk '/[a-z]/ {print}'
$ echo tuv | LC_ALL=et_EE.UTF-8 grep [a-z]
$ LC_ALL=et_EE.UTF-8 expr tuv : [a-z]
$
and many more.
On the other hand, some commands always work with C collation rules,
most notably tr:
$ echo 1rstuvwxyz2 | LC_ALL=et_EE.UTF-8 tr -d a-z
12
or perl and python if they are not told to switch to user's locale.
One must then switch to C locale to avoid those collation issues,
see attached patch.
Thanks
Denis
diff -ru debian.orig/libsvga1.prerm debian/libsvga1.prerm
--- debian.orig/libsvga1.prerm 2005-12-16 13:35:07.0 +0100
+++ debian/libsvga1.prerm 2005-12-16 13:36:22.0 +0100
@@ -17,7 +17,7 @@
CONFFILE=/etc/vga/libvga.config
if [ -f $CONFFILE -a ! -f $MOUSEFILE ]
- MOUSELINE=`sed '/^mouse [A-Za-z0-9]*$/I!d;q' $CONFFILE`
+ MOUSELINE=`LC_ALL=C sed '/^mouse [A-Za-z0-9]*$/I!d;q' $CONFFILE`
[ $MOUSELINE != 'mouse unconfigured' ]; then
cat EOF $MOUSEFILE
# This file contains your mouse type setting, which is preserved
Bug#343601: udev: [a-z] must be used in maintainer scripts only under C locale
Package: udev
Version: 0.076-5
Severity: normal
Tags: patch
Hi,
[a-z] may not represent all 26 ASCII lowercase letters in regular
expressions, eg. Estonian collation sorts z between s and t:
$ echo rstuvwxyz | LC_ALL=en_US.UTF-8 sed -e 's/[a-z]//g'
$ echo rstuvwxyz | LC_ALL=et_EE.UTF-8 sed -e 's/[a-z]//g'
tuvwxy
As shown above, this applies to sed, but also awk, grep, expr
$ echo tuv | LC_ALL=et_EE.UTF-8 awk '/[a-z]/ {print}'
$ echo tuv | LC_ALL=et_EE.UTF-8 grep [a-z]
$ LC_ALL=et_EE.UTF-8 expr tuv : [a-z]
$
and many more.
One must then switch to C locale to avoid those collation issues,
see attached patch. It is very unlikely that someone gets hit by
this problem in udev.preinst, but who knows, maybe an Estonian guy
with more than 20 IDE disks on his machine will complain one day?
Thanks
Denis
diff -ru debian.orig/udev.preinst debian/udev.preinst
--- debian.orig/udev.preinst2005-12-16 13:34:58.0 +0100
+++ debian/udev.preinst 2005-12-16 13:37:32.0 +0100
@@ -97,7 +97,7 @@
fi
if dpkg --compare-versions $2 lt 0.046-5; then
CD_RE='^KERNEL=(hd[a-z]|sr[0-9]*|pcd[0-9]*),[[:space:]]*PROGRAM=/etc/udev/scripts/cdsymlinks.sh
%k'
-if grep --no-messages -q -E $CD_RE /etc/udev/rules.d/* \
+if LC_ALL=C grep --no-messages -q -E $CD_RE /etc/udev/rules.d/* \
[ ! -e /etc/udev/rules.d/cd-aliases.rules ]; then
ln -s ../cd-aliases.rules /etc/udev/rules.d/cd-aliases.rules
fi
Bug#343602: xserver-xorg: [a-z] must be used in maintainer scripts only under C locale
Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Severity: normal Tags: patch Hi, [a-z] may not represent all 26 ASCII lowercase letters in regular expressions, eg. Estonian collation sorts z between s and t: $ LC_ALL=et_EE.UTF-8 expr tuv : [a-z] 0 $ LC_ALL=C expr tuv : [a-z] 1 One must then switch to C locale to avoid those collation issues, see attached patch. Thanks Denis Index: debian/xserver-xorg.config.in === --- debian/xserver-xorg.config.in (révision 950) +++ debian/xserver-xorg.config.in (copie de travail) @@ -244,13 +244,13 @@ # # Accept any non-null sequence of lowercase letters followed by a # non-null sequence of decimal digits. This handles fbN and nameN. -expr $RET : SBUS:[a-z]\+[0-9]\+ /dev/null 21 break +LC_ALL=C expr $RET : SBUS:[a-z]\+[0-9]\+ /dev/null 21 break # Now for the PROM path. I am lazy; accept a slash followed a non-null # sequence of letters and commas, an at sign, a non-null sequence of # hexadecimal digits, a comma, and another non-null sequence of # hexadecimal digits. Furthermore, accept multiple occurences of this # entire sequence. Whew. -expr $RET : SBUS:\(/[A-Za-z,[EMAIL PROTECTED],[0-9A-Fa-f]\+\)\+$ \ +LC_ALL=C expr $RET : SBUS:\(/[A-Za-z,[EMAIL PROTECTED],[0-9A-Fa-f]\+\)\+$ \ /dev/null 21 break ;; [0-9])
Bug#343633: smb2www: please do not expose internal text to translators
Package: smb2www Severity: minor Tags: patch Hi, text which is not exposed to users does not need to get translated, please apply this patch and run debconf-updatepo to remove these strings from PO files. Thanks Denis --- debian.orig/templates 2005-12-16 19:37:27.0 +0100 +++ debian/templates2005-12-16 19:38:13.0 +0100 @@ -42,7 +42,7 @@ Template: smb2www/need_reconfigure Type: boolean Default: false -_Description: This is an internal option +Description: This is an internal option If you see this text while configuring the package, please file a bug report against smb2www.
Bug#343634: sympa: [po-debconf] please do not expose internal text to PO files
Package: sympa Severity: minor Tags: patch Hi, if text does not have to be translated in debconf templates, please remove the leading underscore so that this text does not appear in PO files. Please run debconf-updatepo after applying this patch so that this text is also removed from PO files. Thanks Denis diff -ur debian.orig/templates debian/templates --- debian.orig/templates 2005-12-16 19:43:14.0 +0100 +++ debian/templates2005-12-16 19:47:55.0 +0100 @@ -219,8 +219,7 @@ Template: sympa/wwsympa_configured Type: boolean Default: false -_Description: internal use only - This template is never shown to the user and does not require translation. +Description: internal use only Template: wwsympa/webserver_type Type: select
Bug#343082: ITP: netgen -- automatic 3d tetrahedral mesh generator
On Tue, Dec 13, 2005 at 08:28:19AM +0100, Christophe Prud'homme wrote: FYI, netgen is part also of gmsh. are u planning to package netgen ? if not I can take netgen in charge. Hi Christophe, upstream netgen is a standalone application, with its UI, mesher and solver. So yes, the Netgen/libsrc directory embedded in gmsh will also be included in the netgen package. In fact, I am primarily interested in shipping a libnetgen-dev package containing a static library of this directory, because I need this library at work. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320534: locales: fr_CA : wrong paper size and maybe wrong X keymap
tags 320534 - l10n severity 320534 minor reassign 320534 libpaper1 merge 288693 320534 thanks On Fri, Jul 29, 2005 at 10:33:19PM -0400, Pierre St-Laurent wrote: Package: locales Version: 2.3.2.ds1-22 Severity: normal Tags: l10n Hi! After a standard fr_CA Sarge install, I get a4 as the default /etc/papersize. If I'm correct as fr_CA means french Canadian, then the papersize should be letter. Paper in a4 format cannot be found in North America. Canadians use letter just like in United States. Libpaper1 sets the default value to a4 for all locales, thus reassigning this bugreport to libpaper1. Then about the X keymap, I get ca as the default keymap. It looks like that keymap behaves much like a Macintosh for the accents. As most people using Linux are MS Windows experienced, I believe ca_enhanced would be a better choice for the default X keymap. ca_enhanced mimics the éèêç keymap from MS Windows. Please file a seperate bugreport against the xlibs package if you have trouble with your X layout. Denis
Bug#334691: prefer_unicode variable not set
On Sat, Oct 29, 2005 at 05:25:00PM +0100, Martin Orr wrote:
First some observations about reproducing this bug. If
charset iso-8859-7
is added as the first line of the provided keymap, loadkeys accepts it.
This is why the gr-utf8 keymap in console-tools works - it has a
charset line at the top.
Now why the bug happens.
The 430_read_keymaps_fmt patch, added in 0.2.3dbs-57, introduces the
prefer_unicode variable in lib/ksyms.c. This variable is used instead
of checking whether the console is in UTF-8 mode; however it is never
set anywhere. If this variable is unconditionally set to 1, the keymap
supplied by the reporter is loaded correctly.
However setting prefer_unicode either to 1 or 0 unconditionally is
presumably not the correct behaviour. It should be 1 iff the console is
in UTF-8 mode or the user specified the -u flag. Since
kbdtools/loadkeys.c calls set_charset(unicode) in either of these
cases, set_charset would appear to be the place to set the
prefer_unicode variable.
The following patch does that:
diff -Naru2 console-tools-0.2.3.orig/lib/ksyms.c
console-tools-0.2.3/lib/ksyms.c
--- console-tools-0.2.3.orig/lib/ksyms.c2005-10-29
17:06:31.0 +0100
+++ console-tools-0.2.3/lib/ksyms.c 2005-10-29 17:07:45.0 +0100
@@ -1669,6 +1669,9 @@
int i;
- if (!strcasecmp(charset, unicode))
+ if (!strcasecmp(charset, unicode)) {
+ prefer_unicode = 1;
return 0;
+ }
+ prefer_unicode = 0;
for (i = 1; i sizeof(charsets)/sizeof(charsets[0]); i++) {
You are fully right. I applied a very similar patch for the kbd package,
but it looks like the 430_read_keymaps_fmt patch I sent to Alastair was
buggy (or maybe I fixed kbd after sending it, I do not remember).
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336510: ALT GR key not working - w/ workaround
On Sun, Oct 30, 2005 at 10:03:53PM +0100, Volker Jahns wrote: Package: xserver-xfree86 Version: 4.3.0.dfsg.1-1 The ALT GR key of deDE keyboard layout will not work in xserver-xfree8 4.3.0.dfsg.1-1. During startup the xserver murmurs -- The XKEYBOARD keymap compiler (xkbcomp) reports: Error: Can't find file pc/pc for symbols include Exiting Abandoning symbols file default Errors from xkbcomp are not fatal to the X server Error loading keymap /usr/X11R6/lib/X11/xkb/compiled/server-0.xkm -- The following cures the situation: setxkbmap -rules xfree86 -model pc105 -layout de This is most annoying as it has to done for each login. Please help all users, there is only a 80 million lot of Germans wanting to install Debian sarge ;-) Well, be assured that there would already be bug reports about this issue if all German people were affected ;) It seems that your /etc/X11/xkb directory is screwed up, in particular /etc/X11/xkb/symbols/pc/pc is missing. You can try the following commands to fix it: # rm -rf /etc/X11/xkb # apt-get install --reinstall xlibs # dpkg -i --force-confmiss /var/cache/apt/archives/xlibs*_all.deb # apt-get install --reinstall xbase-clients and restart your X server. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334691: prefer_unicode variable not set
On Wed, Nov 02, 2005 at 11:32:46PM +0100, Denis Barbier wrote:
[...]
--- console-tools-0.2.3.orig/lib/ksyms.c2005-10-29
17:06:31.0 +0100
+++ console-tools-0.2.3/lib/ksyms.c 2005-10-29 17:07:45.0 +0100
@@ -1669,6 +1669,9 @@
int i;
- if (!strcasecmp(charset, unicode))
+ if (!strcasecmp(charset, unicode)) {
+ prefer_unicode = 1;
return 0;
+ }
+ prefer_unicode = 0;
for (i = 1; i sizeof(charsets)/sizeof(charsets[0]); i++) {
You are fully right. I applied a very similar patch for the kbd package,
but it looks like the 430_read_keymaps_fmt patch I sent to Alastair was
buggy (or maybe I fixed kbd after sending it, I do not remember).
Correction: in kbd I did not set prefer_unicode = 0 after the strcasecmp
test (which is why I talked about a very similar patch). After more
thinking, I believe that this line should indeed be removed from your
patch so that loadkeys -u works as expected even if keyboard is in
ASCII mode.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203434: libc6: accessing thread-local storage causes SIGSEGV
[Daniel Jacobowitz] My understanding is that while GCC has to generate the right code, thread-local storage also requires support from the linker, run-time loader, and C library. I'm reporting this against libc6 on the assumption that either libc itself or the loader (/lib/ld-2.3.1.so) is at fault. It's possible, though, that the problem is elsewhere. For the record, I'm also using binutils 2.14.90.0.5-0.1 and gcc 3.3-2, all on Debian unstable. You are correct that our glibc has this support disabled. A future version will have it enabled. However, on some architectures, including i686, I believe that it also requires kernel support. Hmm, reading it again perhaps that's not true. It looks like this bug has been fixed in libc6 2.3.5, can it be closed? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345436: xlibs: Alt-GR key not working at all under X
On Mon, Jan 02, 2006 at 01:32:01PM +0100, Lukas Ruf wrote: Package: xlibs Version: 6.9.0.dfsg.1-1 Followup-For: Bug #345436 Dear all, after upgrading to latest x.org, the Alt-Gr key is not working anymore under X. I am using a Swiss German keyboard layout and kept the config settings as they were before: Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc101 Option XkbLayout de_CH Option XkbVariantnodeadkeys Try with Option XkbRules xorg Option XkbModel pc101 Option XkbLayout ch Option XkbVariantde_nodeadkeys Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345436: xlibs: Alt-GR key not working at all under X
On Mon, Jan 02, 2006 at 05:28:35PM +0100, David Martínez Moreno wrote: El lunes, 2 de enero de 2006 15:24, Lukas Ruf escribió: [...] [EMAIL PROTECTED]| :) -- exiting X and launching it again -- fixed the problem! Thanks for the help! No problem. We are glad to see you happy. :-) Thanks for your bug report. Denis, rest of XSF, should we do anything about this recurrent issue? Backward compatibility rules can be added, this is performed by xkeyboard-config. In this particular case, de_CH was a layout which could not be combined with other layouts, and was already obsolete in sarge. I do not know what can be done to force people to upgrade to newer layouts. Denis
Bug#345436: Can't switch virtual consoles with Ctrl+Alt+Function keys when XkbRules is set to 'base'
On Mon, Jan 02, 2006 at 09:27:47PM +, Sam Morris wrote: While investigating #336791 [0] I found that if I have XkbRules set to 'base', instead of the default 'xorg' [1], The Ctrl+Alt+Function key chord no longer switches between virtual consoles. And when it is set to xorg, does everything work fine? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331377: locales: Please add a locale file for Sanskrit/India
This locale file does not compile, here is a trivial patch and the fixed sa_IN locale file. Denis --- sa_IN.orig 2005-10-03 21:14:08.0 +0200 +++ sa_IN 2005-10-03 21:32:41.0 +0200 @@ -92,7 +92,7 @@ U0936U0928U093FU003A % % Full weekday names (%A) -ravivar,somvar,mangalvar,budhvar,guruvar,shukravar,shanivar +% ravivar,somvar,mangalvar,budhvar,guruvar,shukravar,shanivar day U0930U0935U093FU0935U093EU0930U003A;/ U0938U094BU092EU0935U093EU0930U003A;/ U092EU0902U0917U0932U0935U093EU0930U003A;/ comment_char% escape_char / % Sanskrit language locale for India. % Contributed by Vidya Ayer [EMAIL PROTECTED] % and Christian Perrier [EMAIL PROTECTED] LC_IDENTIFICATION title Sanskrit language locale for India source The Debian project address contactChristian Perrier email [EMAIL PROTECTED] tel fax language Sanskrit territory India revision 1.0 date 2005-09-25 % category sa_IN:2000;LC_IDENTIFICATION category sa_IN:2000;LC_CTYPE category sa_IN:2000;LC_COLLATE category sa_IN:2000;LC_TIME category sa_IN:2000;LC_NUMERIC category sa_IN:2000;LC_MONETARY category sa_IN:2000;LC_MESSAGES category sa_IN:2000;LC_PAPER category sa_IN:2000;LC_NAME category sa_IN:2000;LC_ADDRESS category sa_IN:2000;LC_TELEPHONE END LC_IDENTIFICATION LC_CTYPE copy i18n END LC_CTYPE LC_COLLATE % Copy the template from ISO/IEC 14651 copy iso14651_t1 END LC_COLLATE LC_MONETARY % This is the POSIX Locale definition the LC_MONETARY category. % These are generated based on XML base Locale difintion file % for IBM Class for Unicode/Java % int_curr_symbol U0049U004EU0052U0020 currency_symbol U0930U0942 mon_decimal_point U002E mon_thousands_sep U002C mon_grouping 3 positive_sign negative_sign U002D int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space1 n_cs_precedes 1 n_sep_by_space1 p_sign_posn 1 n_sign_posn 1 % END LC_MONETARY LC_NUMERIC % This is the POSIX Locale definition for the LC_NUMERIC category. % decimal_point U002E thousands_sep U002C grouping 3 % END LC_NUMERIC LC_TIME % This is the POSIX Locale definition for the LC_TIME category. % These are generated based on XML base Locale difintion file % for IBM Class for Unicode/Java % % Abbreviated weekday names (%a) % ravi,som,mangal,budh,guru,shukra,shani abday U0930U0935U093FU0069U003A;/ U0938U094BU092EU003A;/ U092EU0902U0917U0932U003A;/ U092CU0941U0927U003A;/ U0917U0941U0930U0942;/ U0936U0941U0915U094DU0930;/ U0936U0928U093FU003A % % Full weekday names (%A) % ravivar,somvar,mangalvar,budhvar,guruvar,shukravar,shanivar day U0930U0935U093FU0935U093EU0930U003A;/ U0938U094BU092EU0935U093EU0930U003A;/ U092EU0902U0917U0932U0935U093EU0930U003A;/ U092CU0941U0927U0935U093EU0930U003A;/ U0917U0941U0930U0942U0935U093EU0930;/ U0936U0941U0915U094DU0930U0935U093EU0930;/ U0936U0928U093FU0935U093EU0930U003A % % Abbreviated month names (%b) % Below comes from hi_IN. % Sanskrit uses a lunar calendar. When gregorian month names % are needed, the names are the same names than those used % by Hindi % names for gregorian month names: abmon U091CU0928U0935U0930U0940;/ U092BU093CU0930U0935U0930U0940;/ U092EU093EU0930U094DU091A;/ U0905U092AU094DU0930U0947U0932;/ U092EU0908;U091CU0942U0928;/ U091CU0941U0932U093EU0908;/ U0905U0917U0938U094DU0924;/ U0938U093FU0924U092EU094DU092CU0930;/ U0905U0915U094DU091FU0942U092CU0930;/ U0928U0935U092EU094DU092CU0930;/ U0926U093FU0938U092EU094DU092CU0930 % % Full month names (%B) % Sanskrit uses a lunar calendar. When gregorian month names % are needed, the names are the same names than those used % by Hindi % Lunar calendar month names: % Chaitra March 22 % Vaisakha April 29 % jyeshthah May 22 % ashadahJune 22 % shravanah July 23 % bhadrapadahAugust 23 % ashvinah September 23 % kartikah October 23 % agrahayanah November 22 % paushahDecember 22 % maghah January 29 % phalgunah February 20 % names for gregorian month names: mon U091CU0928U0935U0930U0940;/ U092BU093CU0930U0935U0930U0940;/ U092EU093EU0930U094DU091A;/ U0905U092AU094DU0930U0947U0932;/ U092EU0908;U091CU0942U0928;/ U091CU0941U0932U093EU0908;/ U0905U0917U0938U094DU0924;/ U0938U093FU0924U092EU094DU092CU0930;/ U0905U0915U094DU091FU0942U092CU0930;/ U0928U0935U092EU094DU092CU0930;/ U0926U093FU0938U092EU094DU092CU0930
Bug#331540: eperl: fails to work in nph mode
On Mon, Oct 03, 2005 at 04:53:38PM -0500, Carter Wiggins wrote: [...] gives only: DOCUMENT_ROOT=/var/www HTTP_ACCEPT=text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7 which is too little and renders my old eperl written pages unusable. Do you mean that this is a regression? Can you please tell which version worked? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331672: lintian: [po-debconf] dependency check on debconf is broken
Package: lintian
Version: 1.23.12
Severity: normal
Hi,
In order to prevent false positives, checks have been added to
checks/po-debconf to see if the package depends upon debconf.
This is done by parsing debian/control, but nowadays this
dependency is pulled in by ${misc:Depends}, so checks/po-debconf
stops before running its own checks, which makes checks/po-debconf
pretty useless.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324768: xserver-xorg: Add an XKBPATH environment variable to specify alternate XKB data location
On Thu, Oct 06, 2005 at 03:15:52AM +1000, Daniel Stone wrote: On Wed, Aug 24, 2005 at 12:13:19AM +0200, Denis Barbier wrote: In order to ease migration from xlibs to xkeyboard-config, an option is to install xkeyboard-config files under another directory, so that xlibs and xkeyboard-config can be installed simultaneously. The selection between xlibs and xkeyboard-config data files could be made when X starts by adding a new XKBPATH environment variable. Here is a patch implementing this feature; I am unable for now to test it due to lack of CPU and disk resources, and will be grateful if someone could test it. If you XSF guys decide eventually to replace xlibs by xkeyboard-config, this hack can be removed, but until then it would really help to install xkeyboard-config on Debian systems. To be honest, I'm somewhat concerned about this patch: the XKB code is, ah, how to put it -- not incredibly robust or auditable. Combined with XKBPATH, allowing anyone to use their own arbitrary files, and the X server being suid root, this is effectively a local root exploit if someone can manage to exploit the gaping holes all through the XKB code (if you don't believe me, ask me in private, and I can point you to the most horrific examples). Already I can think of one possible shell injection attack, as well as a couple of buffer overflows, that this might enable. One can already write any arbitrary evil.map file and run $ xkbcomp evil.map :0 to have it parsed by the X server, or run $ setxkbmap -I/path/to/evil/files so does this XKBPATH stuff really add new vulnerabilities? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332489: gmsh messes up background/foreground colors
Package: gmsh Version: 1.60.1-2 Severity: normal Hi, I prefer dark backgrounds, so my settings contain $ xrdb -merge - EOT *background:#00 *foreground:#ff EOT But then gmsh main menu is in black on black, and is thus unusable. Denis -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gmsh depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libfltk1.11.1.6-7Fast Light Toolkit shared librarie ii libgcc1 1:4.0.2-2 GCC support library ii libgsl0 1.7-2 GNU Scientific Library (GSL) -- li ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libpng12-01.2.8rel-5 PNG library - runtime ii libstdc++64.0.2-2The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar di xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g1:1.2.3-4 compression library - runtime gmsh recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332491: gmsh: UNV output is broken
Package: gmsh Version: 1.60.1-2 Severity: normal Hi again, given that I could not use its GUI, I ran some demos on the command line ;) $ gmsh -2 -o sphere.msh /usr/share/doc/gmsh/demos/sphere.geo works fine, but $ gmsh -2 -o sphere.unv -format unv /usr/share/doc/gmsh/demos/sphere.geo does not: the 2412 block is empty, which means that no triangles have not been written. Denis -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gmsh depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libfltk1.11.1.6-7Fast Light Toolkit shared librarie ii libgcc1 1:4.0.2-2 GCC support library ii libgsl0 1.7-2 GNU Scientific Library (GSL) -- li ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libpng12-01.2.8rel-5 PNG library - runtime ii libstdc++64.0.2-2The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar di xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g1:1.2.3-4 compression library - runtime gmsh recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331672: lintian: [po-debconf] dependency check on debconf is broken
On Tue, Oct 04, 2005 at 07:59:40PM +0200, Frank Lichtenheld wrote:
On Tue, Oct 04, 2005 at 03:50:34PM +0200, Denis Barbier wrote:
In order to prevent false positives, checks have been added to
checks/po-debconf to see if the package depends upon debconf.
This is done by parsing debian/control, but nowadays this
dependency is pulled in by ${misc:Depends}, so checks/po-debconf
stops before running its own checks, which makes checks/po-debconf
pretty useless.
Indeed. I see no simple solution that supports both purposes, though.
Neither do I. Maybe debhelper should not depend on po-debconf so
that maintainers have to add an explicit dependency on po-debconf.
Will try to come up with something but any suggestions welcome...
My only idea is to check for config scripts, something like :
In debfiles, if there is a file m/^(.+\.)?templates(\..+)?$/ and
there is also a file m/^(.+\.)?config(\..+)?$/ then $has_template=1
Please note that some templates and config file are preprocessed, thus
their name is templates.in, templates.master or config.in
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#224301: [Adduser-devel] Bug#224301: Some thoughts about this bug report
On Sat, Oct 22, 2005 at 09:02:28PM +0200, Marc Haber wrote:
Of course this comment may be improved ;)
You need to call xgettext with the -c flag so that comments are
inserted
into PO files.
that would be XGETTEXT = xgettext -c in po/Makefile, right? Done.
Hmmm, I prefer adding -c after $(XGETTEXT).
There is another glitch with po/Makefile:
adduser-3.76/po$ touch ../adduser
adduser-3.76/po$ make adduser.pot
xgettext -c -L Perl -kgtx -o adduser.pot ../adduser
Strings from deluser are then discarded. Patch attached.
Other minor i18n problems with your package:
* the gtx() function is useless and confuses xgettext
gtx was named _ previously and is obviously modeled after the _ macro
suggested in the gettext texinfo documentation. I'd like to keep it to
be able to disable i18n for testing and debugging purposes.
Unfortunately, it cannot be named _ as File::Find starts to behave
very strangely when a function called _ is in the namespace.
Is it possible to overload gettext with a no-op for testing purposes?
If so, your changes are acceptable. I'd like to have gettext in a
state where it can be disabled.
Can't xgettexts confusion be remedied by replacing -k_ with -kgtx in
the Makefile? I have tried this in the lastest upload to experimental,
please verify.
Yes, but xgettext still displays a warning.
In AdduserCommon.pm, you can replace
sub gtx {
return gettext( join , @_);
}
by
sub gtx {
return gettext(shift):
}
to remove this warning. Calling gtx with a list is wrong, because
only the first string is extracted into the POT file (see the attached
patch, the 2nd string from deluser is not in adduser.pot).
Here is a patch. I tested it, but of course it may introduce bugs,
please review it carefully ;)
I applied the changes, but left gtx intact. Please reconsider this
suggestion.
Frankly, I see no reason to keep this wrapper. If you do not want
localized messages, run your scripts with LC_ALL=C.
s_print (gtx(Backing up files to be removed to . $config{backup_to}.
...\n));
Doesn't this cause translation pain as well?
Absolutely, I missed this one.
I have changed it to
s_printf (gtx(Backing up files to be removed to %s
...\n),$config{backup_to});
Thanks.
Denis
diff -ur adduser-3.76.old/AdduserCommon.pm adduser-3.76/AdduserCommon.pm
--- adduser-3.76.old/AdduserCommon.pm 2005-10-18 16:20:00.0 +0200
+++ adduser-3.76/AdduserCommon.pm 2005-10-24 23:22:57.0 +0200
@@ -56,8 +56,8 @@
}
}
-sub gtx {
-return gettext( join , @_);
+sub gtx ($) {
+return gettext(shift);
}
sub dief {
diff -ur adduser-3.76.old/deluser adduser-3.76/deluser
--- adduser-3.76.old/deluser2005-10-22 20:54:53.0 +0200
+++ adduser-3.76/deluser2005-10-24 23:32:46.0 +0200
@@ -397,7 +397,7 @@
printf gtx(Copyright (C) 2000 Roland Bauerschmidt [EMAIL
PROTECTED]\n\n);
-printf gtx(deluser is based on adduser by Guy Maor [EMAIL PROTECTED],
Ian Murdock\n,
+printf gtx(deluser is based on adduser by Guy Maor [EMAIL PROTECTED],
Ian Murdock\n.
[EMAIL PROTECTED] and Ted Hajek [EMAIL PROTECTED]\n);
printf gtx(\nThis program is free software; you can redistribute it
and/or modify
diff -ur adduser-3.76.old/po/Makefile adduser-3.76/po/Makefile
--- adduser-3.76.old/po/Makefile2005-10-22 21:08:37.0 +0200
+++ adduser-3.76/po/Makefile2005-10-24 23:35:29.0 +0200
@@ -1,4 +1,4 @@
-XGETTEXT = xgettext -c
+XGETTEXT = xgettext
MSGFMT = msgfmt
MSGMERGE = msgmerge
@@ -12,6 +12,7 @@
PO = $(wildcard *.po)
LANG = $(basename $(PO))
MO = $(addsuffix .mo,$(LANG))
+SOURCES = ../adduser ../deluser ../AdduserCommon.pm
all: update $(MO)
update: adduser.pot
@@ -20,8 +21,8 @@
$(MSGMERGE) -U $$po adduser.pot; \
done;
-adduser.pot: ../adduser ../deluser ../AdduserCommon.pm
- $(XGETTEXT) -L Perl -kgtx -o $@ $?
+adduser.pot: $(SOURCES)
+ $(XGETTEXT) -c -L Perl -kgtx -o $@ $(SOURCES)
install: all
for i in $(MO) ; do \
Bug#224301: [Adduser-devel] Bug#224301: Some thoughts about this bug report
On Tue, Oct 25, 2005 at 07:21:59AM +0200, Marc Haber wrote:
Frankly, I see no reason to keep this wrapper. If you do not want
localized messages, run your scripts with LC_ALL=C.
It is consistent with the way gettext is used in C programs,
I tend to disagree, but that's really not important ;)
and it allows gettext to be disabled completely, which might be an
advantage on low memory systems.
I do not know how to perform reliable memory benchmarks, but am pretty
sure that disabling gettext has no noticeable impact because localized
messages are not used at all with LC_ALL=C:
$ strace -e open /usr/sbin/adduser --help 21 /dev/null | grep locale
...
open(/usr/share/locale/fr_FR/LC_MESSAGES/adduser.mo, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/share/locale/fr/LC_MESSAGES/adduser.mo, O_RDONLY) = 3
$ LC_ALL=C strace -e open /usr/sbin/adduser --help 21 /dev/null | grep
locale
$
In GNU libc, gettext() returns its argument in this case (and also when
no msgstr was found), so there is no string copy. If Locale::gettext
does the same (no idea whether this is true or not), gettext (with
LC_ALL=C) is very similar to
*gettext = sub { shift };
I have committed your changes and will upload 3.78 later today. Can
you then please take a new look at the package?
Sure. At the moment it did not yet reach my mirror, will look at it
later. Thanks for taking care.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336683: belocs-locales-data: [INTL:sv] Swedish debconf templates translation
On Mon, Oct 31, 2005 at 10:34:37PM +0100, Daniel Nylander wrote: Package: belocs-locales-data Severity: wishlist Tags: patch l10n Thanks for your translation, it has been committed into my repository and will be included into the next upload. But why is it different from #334864? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336864: manpages: problem with iconv manpage
reassign 336864 less thanks On Tue, Nov 01, 2005 at 07:43:46PM +0100, Thomas Petazzoni wrote: Package: libc6 Version: 2.3.5-7 Severity: minor Hi, In the manpage of iconv, all parts in bold are wrongly displayed. For example: N^HNA^HAM^HME^HE This doesn't happen with other manpages. I am reassigning this bugreport to less, for the reasons explained below. Please let us know if your default pager is different from less, you can check by running # update-alternatives --display pager This corrupted display appears with less 391-1 and 392-1, but neither with 382-1 (sarge version) nor with upstream beta 393. So it looks like a bug in less, which had been introduced in 391 and fixed recently. It may be a duplicate of #333475. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#235759: libc6: iconv's replacement for German quotes in UTF-8 to latin1
tags 235759 fixed-upstream thanks This bug has been fixed upstream, with a slightly different patch: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/localedata/locales/de_DE.diff?cvsroot=glibcr1=1.18r2=1.19 It has just been applied against CVS HEAD but not against 2.3 branch, so it may take a while before it gets included into official GNU libc tarballs. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332489: [Gmsh] Bug#332489: gmsh messes up background/foreground colors
On Mon, Oct 10, 2005 at 03:15:38PM -0400, Christophe Geuzaine wrote: I don't have access to a Unix machine to test this at the moment, but we don't specify any interface colors in Gmsh. Could this be an issue with all FLTK applications? (Denis: could you test this with another FLTK app?) Right, I installed xdiskusage on my Debian box, since it also depends on FLTK, and this application has the same problem, so it is certainly an FLTK issue. I will reassign it to FLTK then, thanks for your help. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332489: gmsh messes up background/foreground colors
reassign 332489 libfltk1.1 thanks On Thu, Oct 06, 2005 at 09:15:40PM +0200, Denis Barbier wrote: Package: gmsh Version: 1.60.1-2 Severity: normal Hi, I prefer dark backgrounds, so my settings contain $ xrdb -merge - EOT *background:#00 *foreground:#ff EOT But then gmsh main menu is in black on black, and is thus unusable. This also happens with xdiskusage. As suggested in #332489, this is certainly an FLTK issue, reassigning to libfltk1.1. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334762: locales: Please consider adding a locale for Khmer/Cambodia
tags 334762 fixed-upstream thanks On Wed, Oct 19, 2005 at 06:15:57PM +0200, Christian Perrier wrote: Package: locales Version: 2.3.5-7 Severity: wishlist Tags: patch The attached file is a Khmer/Cambodia locale contributed by members of the khmeros project (http://khmeros.info). Please consider adding it to your locale set and, possibly, forward it upstream (hmmm, well, I know.). This will certainly help supporting Khmer quicker in Debian. This locale has been committed into upstream CVS 3 weeks ago, with the old copyright notice. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#224301: [Adduser-devel] Bug#224301: Some thoughts about this bug report
On Fri, Oct 21, 2005 at 09:23:36AM +0200, Marc Haber wrote:
On Fri, Oct 21, 2005 at 08:36:10AM +0200, Christian Perrier wrote:
(Marc pinged me on IRC about this bug report in adduser)
Thanks for your help!
First of all, I think that adduser should probably make better use of
the locales information for this Yes/No answer.
I think that would be a good idea here.
I don't have the required skills to lead you to the solution, Marc,
but I think that Denis Barbier could.
Thanks for directly Ccing him, I hope that he can find the time to help.
This fr.po file for adduser is under work now and you should soon have
a new version anyway with these fixes among others.
OK, I'll wait for that before applying stuff. Better not mess with
things that I don't understand.
Hi,
There is very good documentation in libc.info, section Yes-or-No Questions,
but unfortunately it is not relevant here because adduser is a perl script.
So I had a look at perllocale(1), which has some nice tips, in particular
about I18N::Langinfo. But be warned that their example is not very
valuable under GNU/Linux, because glibc introduced YESSTR/NOSTR lately
and many locales do not provide them. On the other hand, they all
provide YESEXPR/NOEXPR, so you can run something like:
use I18N::Langinfo qw(langinfo YESEXPR);
my $yesexpr = langinfo(YESEXPR());
for (;;) {
systemcall('/usr/bin/chfn', $new_name);
# Translators: [y/N] has to be replaced by values defined in your
# locale. You can see by running locale yesexpr which regular
# expression will be checked to find positive answer.
print (gtx(Is the information correct? [y/N] ));
chop ($answer=STDIN);
last if ($answer =~ m/$yesexpr/o);
}
Of course this comment may be improved ;)
You need to call xgettext with the -c flag so that comments are inserted
into PO files.
Other minor i18n problems with your package:
* the gtx() function is useless and confuses xgettext
* Some msgid are concatenated to build a full sentence. This is bad.
and in this case only the first part was present in PO files.
Here is a patch. I tested it, but of course it may introduce bugs,
please review it carefully ;)
Denis
diff -ur adduser-3.74.orig/AdduserCommon.pm adduser-3.74/AdduserCommon.pm
--- adduser-3.74.orig/AdduserCommon.pm 2005-10-18 16:20:00.0 +0200
+++ adduser-3.74/AdduserCommon.pm 2005-10-21 23:49:30.0 +0200
@@ -10,7 +10,7 @@
# Ian A. Murdock [EMAIL PROTECTED]
#
[EMAIL PROTECTED] = qw(invalidate_nscd gtx dief warnf read_config
get_users_groups get_group_members s_print s_printf systemcall);
[EMAIL PROTECTED] = qw(invalidate_nscd dief warnf read_config get_users_groups
get_group_members s_print s_printf systemcall);
sub invalidate_nscd {
# Check if we need to do make -C /var/yp for NIS
@@ -56,10 +56,6 @@
}
}
-sub gtx {
-return gettext( join , @_);
-}
-
sub dief {
my ($form,@argu)[EMAIL PROTECTED];
printf STDERR $0: $form,@argu;
@@ -80,7 +76,7 @@
my ($var, $lcvar, $val);
if (! -f $conf_file) {
- printf gtx(%s: `%s' doesn't exist. Using defaults.\n),$0,$conf_file
if $verbose;
+ printf gettext(%s: `%s' doesn't exist. Using
defaults.\n),$0,$conf_file if $verbose;
return;
}
@@ -90,12 +86,12 @@
next if /^#/ || /^\s*$/;
if ((($var, $val) = /^\s*(\S+)\s*=\s*(.*)/) != 2) {
- warnf gtx(Couldn't parse `%s':%s.\n),$conf_file,$.;
+ warnf gettext(Couldn't parse `%s':%s.\n),$conf_file,$.;
next;
}
$lcvar = lc $var;
if (!defined($configref-{$lcvar})) {
- warnf gtx(Unknown variable `%s' at `%s':%s.\n),$var,$conf_file,$.;
+ warnf gettext(Unknown variable `%s' at
`%s':%s.\n),$var,$conf_file,$.;
next;
}
diff -ur adduser-3.74.orig/adduser adduser-3.74/adduser
--- adduser-3.74.orig/adduser 2005-10-19 15:09:09.0 +0200
+++ adduser-3.74/adduser2005-10-21 23:45:02.0 +0200
@@ -48,10 +48,19 @@
if ($@) {
*setlocale = sub { return 1 };
}
+eval {
+ require I18N::Langinfo;
+ import I18N::Langinfo qw(langinfo YESEXPR);
+};
+if ($@) {
+ *langinfo = sub { ^[yY] };
+ *YESEXPR = sub { 1 };
+}
}
setlocale(LC_MESSAGES, );
textdomain(adduser);
+my $yesexpr = langinfo(YESEXPR());
our $verbose = 1; # should we be verbose?
my $allow_badname = 0; # should we allow bad names?
@@ -86,7 +95,7 @@
debug = \$debugging );
# everyone can issue --help and --version, but only root can go on
-die ($0: ,gtx(Only root may add a user or group to the system.\n)) if ($
!= 0);
+die ($0: ,gettext(Only root may add a user or group to the system.\n)) if
($ != 0);
if( defined($configfile) ) { @defaults = ($configfile); }
@@ -106,30 +115,30 @@
while (defined($arg = shift(@ARGV))) {
if (defined($names[0]) $arg
Bug#338998: po2debconf: Please always run debconf-updatepo
On Mon, Nov 14, 2005 at 12:42:03PM +0100, Thomas Huriaux wrote: Package: po-debconf Severity: wishlist Hi, If a translation is newer (based on timestamps) than the templates.pot file, debconf-updatepo is not launched. But this is very often the case, as the translator usually translates the file after the new templates.pot has been regenerated. Even if the templates.pot file has not been modified during the translation, it's worth checking if the translated file is ok, so I think po2debconf should always run debconf-updatepo. In fact, debconf-updatepo needs to be run by the 'clean' target so that the .diff.gz file contains up-to-date strings. Unfortunately I have no idea on how to enforce this. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338998: po2debconf: Please always run debconf-updatepo
On Tue, Nov 15, 2005 at 11:39:43AM +0100, Thomas Huriaux wrote: I know that running debconf-updatepo every time po2debconf is called is too often, but I prefer too often than not enough. The problem is that templates.pot may still be outdated in the diff.gz file, so I am reluctant to add this call. IIRC newer lintian complains, so hopefully developers will notice this problem. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340207: gmsh not installable on i386
Package: gmsh Version: 1.60.1-2 Severity: serious Justification: Policy 2.2.1 Christophe, It looks like you have gcc 4.1 from experimental installed on your build system, and thus libgcc1 and libstdc++6 dependencies cannot be satisfied on i386/unstable. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385177: meld: FTBFS: msgfmt: found 1 fatal error
tags 385177 + patch thanks Here is a patch. Denis diff -u po.orig/hu.po po/hu.po --- po.orig/hu.po 2005-11-22 00:15:16.0 +0100 +++ po/hu.po2006-09-09 19:11:07.0 +0200 @@ -99,49 +99,42 @@ msgid %i second msgid_plural %i seconds msgstr[0] %i másodperc -msgstr[1] %i másodperc #: ../dirdiff.py:568 #, python-format msgid %i minute msgid_plural %i minutes msgstr[0] %i perc -msgstr[1] %i perc #: ../dirdiff.py:569 #, python-format msgid %i hour msgid_plural %i hours msgstr[0] %i óra -msgstr[1] %i óra #: ../dirdiff.py:570 #, python-format msgid %i day msgid_plural %i days msgstr[0] %i nap -msgstr[1] %i nap #: ../dirdiff.py:571 #, python-format msgid %i week msgid_plural %i weeks msgstr[0] %i hét -msgstr[1] %i hét #: ../dirdiff.py:572 #, python-format msgid %i month msgid_plural %i months msgstr[0] %i hónap -msgstr[1] %i hónap #: ../dirdiff.py:573 #, python-format msgid %i year msgid_plural %i years msgstr[0] %i év -msgstr[1] %i év #. Abbreviation for insert,overwrite so that it will fit in the status bar #: ../filediff.py:214 diff -u po.orig/ja.po po/ja.po --- po.orig/ja.po 2005-11-13 15:31:20.0 +0100 +++ po/ja.po2006-09-09 19:11:40.0 +0200 @@ -102,49 +102,42 @@ msgid %i second msgid_plural %i seconds msgstr[0] %i 秒 -msgstr[1] %i 秒 #: ../dirdiff.py:568 #, python-format msgid %i minute msgid_plural %i minutes msgstr[0] %i 分 -msgstr[1] %i 分 #: ../dirdiff.py:569 #, python-format msgid %i hour msgid_plural %i hours msgstr[0] %i 時間 -msgstr[1] %i 時間 #: ../dirdiff.py:570 #, python-format msgid %i day msgid_plural %i days msgstr[0] %i 日 -msgstr[1] %i 日 #: ../dirdiff.py:571 #, python-format msgid %i week msgid_plural %i weeks msgstr[0] %i 週間 -msgstr[1] %i 週間 #: ../dirdiff.py:572 #, python-format msgid %i month msgid_plural %i months msgstr[0] %i ヶ月 -msgstr[1] %i ヶ月 #: ../dirdiff.py:573 #, python-format msgid %i year msgid_plural %i years msgstr[0] %i 年 -msgstr[1] %i 年 #. Abbreviation for insert,overwrite so that it will fit in the status bar #: ../filediff.py:214 diff -u po.orig/ru.po po/ru.po --- po.orig/ru.po 2005-10-26 00:58:09.0 +0200 +++ po/ru.po2006-09-09 19:12:54.0 +0200 @@ -187,7 +187,7 @@ %s. #: ../dirdiff.py:570 -#, python-format +#, fuzzy, python-format msgid %i second msgid_plural %i seconds msgstr[0] секунда @@ -195,7 +195,7 @@ msgstr[2] секунд #: ../dirdiff.py:571 -#, python-format +#, fuzzy, python-format msgid %i minute msgid_plural %i minutes msgstr[0] минута @@ -203,7 +203,7 @@ msgstr[2] минут #: ../dirdiff.py:572 -#, python-format +#, fuzzy, python-format msgid %i hour msgid_plural %i hours msgstr[0] час @@ -211,7 +211,7 @@ msgstr[2] часов #: ../dirdiff.py:573 -#, python-format +#, fuzzy, python-format msgid %i day msgid_plural %i days msgstr[0] день @@ -219,7 +219,7 @@ msgstr[2] дней #: ../dirdiff.py:574 -#, python-format +#, fuzzy, python-format msgid %i week msgid_plural %i weeks msgstr[0] неделя @@ -227,7 +227,7 @@ msgstr[2] недель #: ../dirdiff.py:575 -#, python-format +#, fuzzy, python-format msgid %i month msgid_plural %i months msgstr[0] месяц @@ -235,7 +235,7 @@ msgstr[2] месяцев #: ../dirdiff.py:576 -#, python-format +#, fuzzy, python-format msgid %i year msgid_plural %i years msgstr[0] год
Bug#386405: xkb-data: Right-Option is no longer recognized
On Thu, Sep 07, 2006 at 11:47:11PM +0100, Rogerio Reis wrote: Section InputDevice Identifier Generic Keyboard Driver keyboard Option XkbKeycodes macintosh Option XkbSymbols macintosh/pt Option XkbGeometry macintosh Option XkbOptions ctrl:nocaps,lv3:lwin_switch OptionXkbRulesxorg Option XkbModelpowerbook Option LeftAlt Meta Option RightAltLWin Option XkbLayout pt EndSection It may have worked with xlibs, but not with any version of xkb-data. You should write instead Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbModelpowerbook Option XkbLayout pt Option XkbOptions ctrl:nocaps,lv3:lwin_switch EndSection With these options, does your right Option key work as expected? If not, what is it supposed to do? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384056: Bug#348585: Bug#384056: xkb-data 0.8-7 -- it isn't possible to load the czsk layout
On Sun, Sep 10, 2006 at 06:46:55PM +0200, [EMAIL PROTECTED] wrote:
You are right, czsk layout was a combination of 2 groups, and all such
layouts have been removed from xkeyboard-config. The reason is that
such layouts cannot be combined with other layouts, say for instance
$ setxkbmap -model pc104 -layout czsk,ru
You now have to explicitly select the two groups, maybe
$ setxkbmap -model pc104 -layout us,sk -option grp:shifts_toggle
is a good alternative? If not, please describe differences with the
former czsk layout.
Thanks
Denis
Perhaps, I don't understand right this, but I can't always load my layout
neither czsk layout (xkb-data 0.8-12). In my keyboard layout I have:
partial alphanumeric_keys
xkb_symbols basic {
include us(basic)
include czsk(us_cz_prog)
Ok, you did not mention how you load czsk. This layout does indeed no
more exist, you have to use 2 layouts instead of this czsk. You can try
to run
$ setxkbmap -model pc104 -layout us,sk -option grp:switch
and see if it fits your needs, or find better options/variants.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319069: console-data: Should we fix these bugs and, if so, how?
On Wed, Sep 06, 2006 at 06:39:07AM +0200, Christian Perrier wrote: These bug report with patches seems to be easy to fix and certainly all worth it. #319069 cannot be easily checked but maybe we can trust the bug submitter blindly It seems that both keycodes 43 and 66 are mapped to Delete for most Sun keymaps. sunt5-ja, sunt5-ru and sunt5-trqalt set 43=Delete and 66=Remove, as requested by the bug submitter, so it seems indeed that all other sunt5-* keymaps can be changed too. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386212: console-data: br-abnt2 CAPS LOCK not working in console
On Mon, Sep 11, 2006 at 09:58:01AM -0300, Felipe Massia Pereira wrote: 2006/9/7, Christian Perrier [EMAIL PROTECTED]: Hmmm, I just tried by myself on my laptop. While I agree for ç, I disagree for r and m. They perfectly work when I loadkeys br-abnt2 the ç case is pretty strange, yes. It gives Ç when used with Shift but not when Caps Lock is on. With UTF-8 locales, Caps Lock only works for ASCII characters, see #280022. About r and m, this may be a bug in console-tools, it works with kbd. Works for me with r and m.and console-tools..:-) Should the behaviour differ if arch == amd64? It's the case. Then this is a bug. Unfortunately I do not know how to debug it without access to a console on this arch. Can you please check with kbd and console-tools; if one is not buggy, it will help. Thanks Denis
Bug#386072: gnome-lokkit: Patch
On Wed, Sep 06, 2006 at 12:04:39AM -0300, Damián Viano wrote:
Package: gnome-lokkit
Version: 0.50.22-6
Followup-For: Bug #386072
I successfully built gnome-lokkit with the attached, minimum, patch.
diff -Nura gnome-lokkit-0.50.22/debian/rules
/home/des/.pbuilder/build/7052/home/des/gnome-lokkit-0.50.22/debian/rules
--- gnome-lokkit-0.50.22/debian/rules 2006-09-02 16:58:50.0 -0300
+++ /home/des/.pbuilder/build/7052/home/des/gnome-lokkit-0.50.22/debian/rules
2006-09-02 17:09:48.0 -0300
@@ -28,7 +28,7 @@
# Rebootstrap the package
aclocal -I macros
autopoint -f
- sed 's@/\*@/*|.*@' po/Makefile.in.in po/Makefile.in.bak
+ sed 's@/\*@/*|.*@;s/= @MKINSTALLDIRS@/= @install_sh@ -d/'
po/Makefile.in.in po/Makefile.in.bak
mv po/Makefile.in.bak po/Makefile.in.in
libtoolize -f -c
autoconf
As explained on debian-qa, I believe that this patch is wrong, since
aclocal fails before this command is run. Here is another patch.
Denis
diff -u gnome-lokkit-0.50.22/debian/changelog
gnome-lokkit-0.50.22/debian/changelog
--- gnome-lokkit-0.50.22/debian/changelog
+++ gnome-lokkit-0.50.22/debian/changelog
@@ -1,3 +1,10 @@
+gnome-lokkit (0.50.22-6.1) unstable; urgency=low
+
+ * Non maintainer upload
+ * Fix build failure with gettext 0.15. Closes: #386072
+
+ -- Denis Barbier [EMAIL PROTECTED] Tue, 12 Sep 2006 22:29:49 +0200
+
gnome-lokkit (0.50.22-6) unstable; urgency=low
* Rebuild with libnewt0.52.
diff -u gnome-lokkit-0.50.22/configure.in gnome-lokkit-0.50.22/configure.in
--- gnome-lokkit-0.50.22/configure.in
+++ gnome-lokkit-0.50.22/configure.in
@@ -20,7 +20,7 @@
ALL_LINGUAS=az ca da de el en_SE es fr gl hu it ja nl no pl pt pt_BR ro ru sk
sl sv tr uk zh_TW
AM_GNU_GETTEXT
-AM_GNU_GETTEXT_VERSION(0.10.40)
+AM_GNU_GETTEXT_VERSION(0.12.1)
AC_SUBST(CFLAGS)
AC_SUBST(CPPFLAGS)
diff -u gnome-lokkit-0.50.22/debian/rules gnome-lokkit-0.50.22/debian/rules
--- gnome-lokkit-0.50.22/debian/rules
+++ gnome-lokkit-0.50.22/debian/rules
@@ -26,14 +26,12 @@
dh_testdir
# Rebootstrap the package
- aclocal -I macros
autopoint -f
- sed 's@/\*@/*|.*@' po/Makefile.in.in po/Makefile.in.bak
- mv po/Makefile.in.bak po/Makefile.in.in
libtoolize -f -c
- autoconf
- automake -a -c
+ aclocal -I macros -I m4
autoheader
+ automake -a -c
+ autoconf
# Configure the package.
./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
--- gnome-lokkit-0.50.22.orig/po/Makevars
+++ gnome-lokkit-0.50.22/po/Makevars
@@ -0,0 +1,8 @@
+# Makefile variables for PO directory in any package using GNU gettext.
+
+# Usually the message domain is the same as the package name.
+DOMAIN = $(PACKAGE)
+
+# These two variables depend on the location of this directory.
+subdir = po
+top_builddir = ..
Bug#386487: FTBFS: aclocal: macro `AM_PROG_MKDIR_P' required but not defined
[Sent to 386487 instead of 386263, this is a gettext issue and not gnome-lokkit] On Wed, Sep 13, 2006 at 11:57:42AM +0200, Santiago Vila wrote: On Thu, 7 Sep 2006, Steve Langasek wrote: On Wed, Sep 06, 2006 at 11:33:17AM +, Martin Michlmayr wrote: # Rebootstrap the package aclocal -I macros aclocal: macro `AM_PROG_MKDIR_P' required but not defined aclocal: macro `AM_PROG_MKDIR_P' required but not defined So in addition to the gettext pseudobug (#385235), we seem to have an incompatibility between the latest gettext and automake 1.4/1.7. These versions are still in active use, which makes it impractical to include a gettext in etch that doesn't support them. Simple question: Is this the kind of bug that may be forwarded upstream and fixed? No, these bugs are not caused by gettext itself, but by bad practices. Let's look at all different cases: 1. aclocal is not called during package build: aclocal.m4 and po/Makefile.in.in come from upstream and are compatible. 2. aclocal is called during package build: 2.a. gettext.m4 is found in a local copy, usually under m4/ There is no problem, m4/gettext.m4 and po/Makefile.in.in come from upstream and are compatible 2.b. gettext.m4 is found in /usr/share/aclocal/ Here gettext.m4 may be incompatible with po/Makefile.in.in The only problem is with 2.b. In this case, developers should call autopoint before aclocal. Bruno Haible provided autopoint for this exact purpose. It can regenerate m4/gettext.m4 and po/Makefile.in.in for any previous version of gettext, this tool is really great. Since autopoint 0.11.3, one can for instance add AM_GNU_GETTEXT_VERSION([0.12.1]) just after AM_GNU_GETTEXT in configure.ac to request files from gettext 0.12.1. This is useful with packages which depend on automake 1.4, one can use more recent versions; ideally we should try to reproduce the exact same version as upstream to avoid problems. Caveats: * Packages have to Build-Depends: cvs because cvs is needed by autopoint. * As explained in gettext documentation, one may have to add AC_GNU_SOURCE into configure.ac Alternatively, if it helps, I could greate a gettext-0.14 package on which older packages could build-depend (the same way they already build-depend on an old automake). Santiago, I requested some help to rebuild packages on gettext to see how many packages are corrupted: http://lists.debian.org/debian-qa/2006/09/msg00018.html A more detailed analysis is available at http://lists.debian.org/debian-qa/2006/09/msg00029.html In short, 2 packages only have to be fixed now. IMO there is no need to add a gettext-0.14 package, especially thanks to autopoint. About the issue with plural forms, I checked almost all PO files in Debian. Most problems come from ja.po files, but they are not critical because packages ship MO files and do not compile PO files, so this is an upstream issue. There is only one package to fix in Debian, namely meld. I discussed about that with Kenshi Muto during our i18n meeting in Extremadura, and he contacted those Japanese translators, so these translations will be fixed upstream soon. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386487: FTBFS: aclocal: macro `AM_PROG_MKDIR_P' required but not defined
On Wed, Sep 13, 2006 at 01:07:22PM -0700, Steve Langasek wrote: [...] The only problem is with 2.b. In this case, developers should call autopoint before aclocal. Bruno Haible provided autopoint for this exact purpose. It can regenerate m4/gettext.m4 and po/Makefile.in.in for any previous version of gettext, this tool is really great. Since autopoint 0.11.3, one can for instance add AM_GNU_GETTEXT_VERSION([0.12.1]) just after AM_GNU_GETTEXT in configure.ac to request files from gettext 0.12.1. This is useful with packages which depend on automake 1.4, one can use more recent versions; ideally we should try to reproduce the exact same version as upstream to avoid problems. And this fixes the problem that the current version of gettext.m4 depends on AM_PROG_MKDIR_P, a macro introduced in automake 1.8? Yes, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386072;msg=28 In any case, I agree that there is no reason for a separate gettext-0.14 package, but I don't see how autopoint solves the problem of the undefined macro which has to do with compatibility of older versions of *automake*, not with older versions of *gettext*; in which case it would still be nice to have a solution for making a gettext.m4 available that's compatible with the automake-1.4 and automake-1.7 we still ship. (But indeed, no longer RC if all the packages build-depending on gettext have been fixed.) Hmmm, I do not get your point. Which build failure do you have in mind? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386487: FTBFS: aclocal: macro `AM_PROG_MKDIR_P' required but not defined
On Wed, Sep 13, 2006 at 02:21:13PM -0700, Steve Langasek wrote: Hmmm, I do not get your point. Which build failure do you have in mind? Well, the gnome-lokkit build failure is one such example. Can you show me a patch for this package that fixes the problem using autopoint, *not* using a dependency on a newer version of automake? This is exactly what is done in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386072;msg=28 I rearranged commands to call autopoint before aclocal, but the main point is to add AM_GNU_GETTEXT_VERSION(0.12.1) so that gettext.m4 comes from gettext 0.12.1 and does not require AM_PROG_MKDIR_P. I do not modify build dependency. You should give autopoint a try, this is really a magic command ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372509: xserver-xorg-input-kbd: Keyboard does not work properly for second X server
On Thu, Sep 14, 2006 at 12:04:37PM +0200, Benjamin Mesing wrote: [...] I have also logged one of the launches of startx using startx startx-log During the session I have launched xev, pressed some keys and killed the XServer using Ctrl+Alt+BS. Xev output indicates that the events are not propagated to the XServer. Also note, that there are some weird errors indicated in the log regarding the keyboard. This looks similar to #381884. Which version of xbase-clients is installed? Do your problems go away if you reinstall this package? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372509: xserver-xorg-input-kbd: Keyboard does not work properly for second X server
On Thu, Sep 14, 2006 at 09:20:20PM +0200, Benjamin Mesing wrote: I have purged and reinstalled xbase-clients (7.1.ds-3). The problem persists though and the output to the log look pretty much alike. I'll look into it again after a clean reboot though I do not expect any change (right now there is still another XSession running). Is XKBPATH environment variable defined? Is /usr/share/X11/xkb a directory, and contains XKB files? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387698: please reencode xserver-xorg.postinst.in in UTF-8
tags 387698 pending thanks On Sat, Sep 16, 2006 at 09:25:30AM +0200, Robert Millan wrote: Package: xserver-xorg Version: 1:7.0.23 Severity: minor Tags: patch l10n Please could you reencode the l10n part of xserver-xorg.postinst.in in UTF-8 ? These translations have been moved into PO files, thanks. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387917: xserver-xorg: xkb-data 0.8-12exp2 (experimental) crashes radeon ibook X server
On Sun, Sep 17, 2006 at 03:18:06PM +0200, Helge Kreutzmann wrote: Package: xserver-xorg Version: 1:7.0.22 Severity: normal Denis Barbier currently works on correcting the keymaps for Macintosh computers. I am one of the people testing his work. Previous versions worked as expected (modulo some key misassignements, which is the entire reason for testing, hence expected), but the current version 0.8-12exp2 kills my X server (see below for the output printed). To ease testing, the following procedure is used: a) The deb is extraced to a temporary directory with dpkg -x b) I run startx (as ordinary user), ssh to root and switch to the appropriate temporary directory ($tmp/usr/share/X11/xkb) You do not need to be root, normal users can change their keyboard settings. c) For some reason, root does not have a permission to write to the display (previously worked), hence I issue xhost + from my ordinary account and export DISPLAY=:0.0 from the root account d) To actually set the keyboard, I run as root setxkbmap -print | xkbcomp - :0.0 In previous versions the keyboard would be reconfigured and I could test the new layout. Now, every time I run d) X crashes. Pressing Ctrl-Z I get a console, pressing Ctrl-Left the machine does not respond to any keyboard input anymore (I have to ssh in from remote and reboot). When X crashes, it prints out the following lines: Please send the output of setxkbmap -print Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387917: xserver-xorg: xkb-data 0.8-12exp2 (experimental) crashes radeon ibook X server
On Mon, Sep 18, 2006 at 07:48:08PM +0200, Helge Kreutzmann wrote:
[...]
Please send the output of
setxkbmap -print
xkb_keymap {
xkb_keycodes { include macintosh+aliases(qwertz) };
xkb_types { include complete+numpad(mac) };
xkb_compat{ include complete };
xkb_symbols { include
pc(pc105)+macintosh_vndr/de(nodeadkeys)+inet(apple)+level3(lwin_switch)
};
xkb_geometry { include macintosh(macintosh) };
};
Unfortunately it does not crash here. Please run
xkbcomp :0
before running setxkbmap and send the server-0.xkb generated file,
normally I could then run setxkbmap in the same environment as yours.
You can also save the output above into a file my.xkb, and remove
components to determine what is causing the crash, by running
xkbcomp my.xkb :0
Or begin with a minimal input file, like
xkb_keymap {
xkb_keycodes { include macintosh };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include pc(pc105)+macintosh_vndr/de(nodeadkeys) };
xkb_geometry { include macintosh(macintosh) };
};
and add components until xkbcomp crashes.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387917: xserver-xorg: xkb-data 0.8-12exp2 (experimental) crashes radeon ibook X server
On Mon, Sep 18, 2006 at 10:19:35PM +0200, Helge Kreutzmann wrote:
Hello Denis,
I'll try that on Saturday, but I assume that this X crash is a
PowerPC/Radeon specific bug, so I don't know if you'll be able to
reproduce.
Ok, then you may put xkb-data on hold, because these patches have
been merged upstream and I am willing to upload into unstable very
soon to have broader testing.
This upload will be very similar to 0.8-12exp3 which is now in
experimental, but I doubt that your problem got fixed.
exp{1,2,3} are available at
http://people.debian.org/~barbier/tmp/
so that you can test with different versions.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360813: kbd: Add braille key names
On Tue, Nov 14, 2006 at 10:47:05PM +0100, Samuel Thibault wrote: Hi, Oh, I left this behind: Denis Barbier, le Tue 04 Apr 2006 23:21:37 +0200, a écrit : On Tue, Apr 04, 2006 at 10:42:52PM +0200, Samuel Thibault wrote: If this is ok, I'll additionally patch keymaps for mapping alt-altgr-[ASDFJKLM] to braille dots. Please do, keymaps are shipped in console-data. But note that we have not yet switched from console-tools to kbd, Alastair may want to wait for this switch before patching keymaps. I guess the switch has occurred since? No, but your patch has also been committed into console-tools, see #360864. (yes, I know, Etch is pending, I'm just wondering whether I can work as soon as now on kbd files). Denis
Bug#394060: xkb-data: Update broke Gnome 2.14 *again*
merge 394060 394061 severity 394060 normal thanks On Thu, Oct 19, 2006 at 08:13:18AM +0100, [EMAIL PROTECTED] wrote: Package: xkb-data Version: 0.9-3 Severity: grave Justification: renders package unusable *** Please type your report below this line *** Yet again xkb has been broken. The latest set of data updated this morning renders the package completely unusable. Keyboard switching through the Gnome applet is broken. The keyboard control panel cannot recognise any of the keyboard types that are defined in the data package. Defining the keyboard types and keyboard switching under Xorg.conf is broken. This has rendered this machine unusable in a multilingual production environment, which will cost me as many days' work as it takes until you get it going again. Please look into it. Am happy to provide any necessary debugging data. Hi, I am downgrading the severity because this package has been heavily tested, and you seem to be the only one having trouble. Can you please provide the following informations: * What was the previous version of xkb-data (can be found in /var/log/dpkg.log)? * Keyboard section of your xorg.conf * Output of the following 2 commands: $ xprop -root | grep XKB $ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394060: xkb-data: Update broke Gnome 2.14 *again*
severity 394060 critical thanks [Denis Barbier] I am downgrading the severity because this package has been heavily tested, and you seem to be the only one having trouble. Can you please provide the Resetting severity to its initial value, Christian Holm Christensen showed that there is indeed a bug in xkb-data. Denis
Bug#394139: Bug#394060: Bug#394139: kdebase misses most of keyboard layouts after upgrading
tags 394139 - l10n reassign 394139 xkb-data merge 394060 394139 tags 394060 + pending thanks On Fri, Oct 20, 2006 at 10:47:00AM -0700, Steve Langasek wrote: On Fri, Oct 20, 2006 at 03:03:26AM -0300, Adilson dos Santos Dantas wrote: After upgrading kdebase I cant use my keyboards dead keys (brazilian abnt2) with kde and qt applications. Other applications (gtk, motif, etc) are still working fine. So I checked the keyboard layout at kcontrol and there was a few layouts: af, al, ad, ara, am az, bd, by, be, ba, in and us. There's no Brazilian Layout and no deadkeys for use here(exept for non qt and non kde software). This bug is similar to #382988 but all workarounds has been failed. Please fix this bug. Is it possible that xkb-data was upgraded at the same time? Could this be related to bug #394060? KDE reads /usr/share/X11/xkb/rules/base.lst and not base.xml, but this file is also broken because of unescaped characters in po/sl.po; so indeed this is essentially the same bug, merging. Fixed in SVN. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392561: xterm tries to use /usr/lib/X11/locale/common/xiiimp.so.2
reassign 392561 libx11-data forcemerge 392567 392561 thanks On Thu, Oct 12, 2006 at 01:07:44PM +0200, Veres Lajos wrote: On Thu, 12 Oct 2006, Thomas Dickey wrote: On Thu, Oct 12, 2006 at 12:00:20PM +0200, Veres Lajos wrote: Package: xterm xterm doesn't contain any source related to this bug report. The problem lies in the configuration of the X libraries. Hello, Please forward then the bugreport to the releated place. Done, thanks for your report. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391052: xserver-xorg: Control-Alt-Keypad Plus/Minus not recognized
tags 391052 + pending thanks On Wed, Oct 04, 2006 at 05:41:06PM -0500, David Engel wrote: On Thu, Oct 05, 2006 at 12:04:44AM +0200, Denis Barbier wrote: Does other Ctrl-Alt combinations work, like Ctrl-Alt-F1 to switch to a console? Yes, all other Ctrl-Alt combinations appear to work including Ctrl-Alt-F# and Ctrl-Alt-Backspace. It's only Keypad-Plus and Minus that don't work. Check that, Ctrl-Alt-Keypad-Multiply and Divide appear dead to Xev also. Fixed in SVN, thanks for your report. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
