Bug#290187: www.debian.org: packages.debian.org recently got uglier in non-CSS browsers
On Tue, Jan 18, 2005 at 10:23:48AM +0100, Frank Lichtenheld wrote: > On Sun, Jan 02, 2005 at 01:42:28AM -0500, Brian Sammon wrote: > > This change has happened in the past week or two, as far as I can tell; I > > look at packages.debian.org at least once or twice a week. > > When I look at a package info page with my non-CSS browser, where it used to > > display a graphical bullet color-coded to the type of dependency, now it > > just displays [dep] or [sug] or [rec]. This makes it take me longer to scan > > the page to determine which dependencies I am interested in. > > > > You can see this if you use the "dillo" browser. > > Has a decision been made to only support CSS browsers? > > In this case I wouldn't have cared to actually add the [dep], would > I? ;) > > Seriously speaken it just didn't occur to me that one would think of that > as really harder to scan (and for the non-CSS text browsers it doesn't > makes a difference, anyway). But I see your point. > > What do you think about something like > http://packages.debian.net/unstable/graphics/scribus ? I replaced the > [dep] string with the image and put the [dep] into the alt attribute. > It doesn't look really nice because of the linebreak after the image > but I only can change that with CSS. Please note also that the new layout is less Lynx-friendly because it adds vertical space. Entries are now in the form: [dep] package namepackage description ... It may be replaced by [dep] package namepackage description ... where [dep] is rendered like now by an alt attribute or hidecss. This also applies for the download table, it is much longer than before and is pretty annoying. In order to be usable, rows and cols have to be swapped, i.e. display would look like ArchList of files SizeInstalled size alpha [list of files] 200 500 arm[list of files] 200 500 ... It is then readable with Lynx, but looks surely ugly with graphical browsers, so you may be reluctant to perform such a change. In this case, please at least move this table below Search for other versions of so that we do not have to scroll down to read useful information, or move it to a dedicated 'download' page. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290935: xlibs: us keyboard definition: improper use of 'hidden' attribute?
tags 290935 + pending thanks On Mon, Jan 17, 2005 at 09:42:58PM +0100, Frans Pop wrote: > Package: xlibs > Version: 4.3.0.dfsg.1-10 > Severity: minor > > > The us keyboard definition in /etc/X11/xkb/symbols/pc/us has three layouts: > basic, intl and alt-intl. > > In kde's keyboard configuration utility kxkb, only the intl and alt-intl > variants can be selected. The reason seems to be that for the 'basic' > variant, the 'hidden' attribute is set. > > Quoting the kxkb maintainer [1]: > There may be a problem with "hidden" attribute though, currently kxkb > HONOURS that attribute and does not show the variant in the list while > setxkbmap may still use it by default. > If the problem is with "hidden" attribute I'd connect with X.org people > and ask them why "hidden" variants are used by default - I thought they > should be used as an "abstract base classes" instead and their only > function is to have real variants inherit from them. > > So, is the 'hidden' attribute set incorrectly for the 'basic' layout? > > [1] http://bugs.kde.org/show_bug.cgi?id=96592 I asked on an XKB related mailing list http://listserv.bat.ru/xkb/Message/422.html and it seems that this attribute has indeed to be removed. A patch has just been committed into SVN, thanks for your report. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292112: en_US.UTF-8: command not found
reassign 292112 console-common
severity 292112 minor
merge 273590 292112
thanks
On Tue, Jan 25, 2005 at 07:37:21AM +0100, Bruno Dusausoy wrote:
> Package: console-data
> Version: 2002.12.04dbs-48
> Severity: normal
>
>
> When /etc/init.d/keymap.sh AND /etc/init.d/console-screen.sh are
> executed (at boot time for example), they display an error message:
>
> /etc/init.d/keymap.sh: line 46: en_US.UTF-8: command not found
>
> The lines responsible for this are, in both cases :
>
> for var in LANG LC_ALL LC_CTYPE; do
> value=$(egrep "^[^#]*${var}=" /etc/environment | cut -d= -f2)
> eval $var=$value
> done
>
> Here's the content of /etc/environment :
>
> ### BEGIN DEBCONF SECTION FOR localeconf
> # Do not edit within this region if you want your changes to be
> # preserved
> # by debconf. Instead, make changes before the "### BEGIN DEBCONF
> # SECTION
> # FOR localeconf" line, and/or after the "### END DEBCONF SECTION FOR
> # localeconf" line.
> LANG=en_US.UTF-8
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> ### END DEBCONF SECTION FOR localeconf
BTW you should remove localeconf, this package seems to be unmaintained
and sometimes breaks other programs. (Not that it is broken, but
as in this case, some programs are not robust and do not handle
/etc/environment file generated by localeconf)
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288532: po-debconf: Please use DEBEMAIL in podebconf-report-po
On Wed, Jan 05, 2005 at 10:22:09AM +0100, Fabio Tranchitella wrote: > Il giorno mar, 04-01-2005 alle 23:07 +0100, Denis Barbier ha scritto: > > Agreed for both suggestions, but this looks more difficult, so I will > > wait until Fabio provides a patch ;) > > Mm, interesting. Don't worry Denis, I'll provide a patch as > soon as possibile for all the features required by Christian. :) > > Talk to you later, Hi Fabio, I would like to fix these bugs. Will you have time soon to provide a patch? Otherwise I will work on them. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292472: podebconf-report-po does nothing ("No outdated files")
On Thu, Jan 27, 2005 at 11:40:46AM +0100, Fabio Tranchitella wrote: > Hi Drew, > > Il giorno gio, 27-01-2005 alle 20:48 +1100, Drew Parsons ha scritto: > > Here 'tis. > > Drew > > podebconf-report-po checks for fuzzy translations (which are marked as > "#, fuzzy" from debconf-updatepo. In your case there aren't fuzzy > translation, but there are some missing ones which podebconf-report-po > doesn't handle. I'm preparing a patch for podebconf-report-po to fix > this issue. Very good catch, many thanks. I applied Fabio's patch and will upload a fixed version in few minutes. Fabio, I will make some changes to your other patches, so they have not been included yet. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288532: po-debconf: Please use DEBEMAIL in podebconf-report-po
On Thu, Jan 27, 2005 at 11:51:45AM +0100, Fabio Tranchitella wrote:
> Il giorno mer, 26-01-2005 alle 22:01 +0100, Denis Barbier ha scritto:
> > Hi Fabio,
> > I would like to fix these bugs. Will you have time soon to provide a
> > patch? Otherwise I will work on them.
>
> Hi Denis,
> I've prepared the patch two weeks ago but I've missed to send it to
> the bts, sorry. Here there is a patch for #288532, #292472 and #288533.
Ok, I made many cosmetic changes to the code, I believe it is more
structured now.
> Now podebconf-report-po:
> - uses the DEBMAIL environment variable to override the submitter
>of the emails (if available).
> - allows the editing of mail headers (subject, from and whatever else),
> - allows to set the reply-to field to a bug report in BTS (--bts)
> - can send a bug against the package to warn the maintainer about
>the outdated translations of the package (--report, very useful
>in combination with --bts to track the replies of the translators)
I renamed --report into --submit. The other visible change is that
translation teams are no more Cc'ed but put in the To: field. The
reason is that I did not know what to do if a Cc header was also present
in mail comments.
Can you please test
http://people.debian.org/~barbier/tmp/po-debconf_0.8.19_all.deb
? Here is the podebconf-report-po script.
Denis
#!/usr/bin/perl -w
# podebconf-report-po, Send outdated debconf PO files to the last translator
# Copyright (C) 2004, 2005 Fabio Tranchitella <[EMAIL PROTECTED]>
# Denis Barbier <[EMAIL PROTECTED]>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Library General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
## Release information
my $PROGRAM = "podebconf-report-po";
my $VERSION = "0.06";
## Loaded modules, require libmail-sendmail-perl
use strict;
eval q{use Mail::Sendmail;};
die "$PROGRAM: This program requires the libmail-sendmail-perl package.\n".
"$PROGRAM: Aborting!\n" if $@;
use MIME::Base64;
use MIME::QuotedPrint;
use Getopt::Long;
use POSIX;
## Global variables
my $HELP_ARG = 0;
my $VERSION_ARG = 0;
my $VERBOSE_ARG = 0;
my $SUBMIT_ARG = 0;
my $FORCE_ARG = 0;
my $LANGUAGETEAM_ARG = 0;
my $SMTP_ARG = "";
my $TEMPLATE_ARG = "";
my $DEFAULT_ARG = 0;
my $PACKAGE_ARG = "";
my $FROM_ARG = (exists($ENV{'DEBEMAIL'}) ? $ENV{'DEBEMAIL'} : "");
my $BTS_ARG = "";
my $DEADLINE_ARG = "";
my $PODIR_ARG = "";
my @TOPDIRS = qw{../.. .. .};
my $PODIR = '';
my $EDITOR = '/usr/bin/sensible-editor';
## Default templates
my $comments = "# Lines beginning with a number sign are comments, they are
removed when
# sending mails. If a line is composed of a # followed by a 'Name: Value'
# pair, it is interpreted as a mail header field and is passed to your mail
# transport agent. You can edit/add/remove those header fields.";
my $SUBJECT_TRANSLATOR = "Please update debconf PO translation for the package
";
my $BODY_TRANSLATOR = $comments. "
#
# From:
# Subject:
# Reply-To:
#
# This mail will be sent to the following people:
Hi,
you are noted as the last translator of the debconf translation for
. The English template has been changed, and now some messages
are marked \"fuzzy\" in your translation or are missing.
I would be grateful if you could take the time and update it.
Thanks,
";
my $SUBJECT_SUBMIT = "debconf PO translations for the package are
outdated";
my $BODY_SUBMIT = $comments. "
#
# From:
# Subject:
Package:
Version: N/A
Severity: wishlist
Tags: l10n
The following debconf translations are outdated:
Translators, please send your translations to this bugreport.
Thanks,
";
my $SUBJECT = '';
my $BODY = '';
## Handle options
GetOptions
(
"help"=> \$HELP_ARG,
"version" => \$VERSION_ARG,
"v|verbose" => \$VERBOSE_ARG,
"f|force" => \$FORCE_ARG,
"podir=s" => \$PODIR_ARG,
"smtp=s" => \$SMTP_ARG,
"template=s" => \$TEMPLATE_ARG,
"default"
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#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 2>&1 && break +LC_ALL=C expr "$RET" : "SBUS:[a-z]\+[0-9]\+" >/dev/null 2>&1 && 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 2>&1 && 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#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#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#291853: xkbcomp warns about 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 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 { [ 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 : 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 > > 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#348030: Turkish Alt-Q layout support
On Sat, Jan 14, 2006 at 10:36:15AM +0200, Recai Oktaş wrote: > Package: console-data > Severity: wishlist > Tags: patch l10n > > Hi, > > Could you please review the patches attached which add d-i+debconf support > for Turkish Alt Q layout. I hope this change doesn't break the current > default selection (trqu) at the kbd-chooser menu[1]. hi Recai, We cannot support all layouts in d-i, so if this layout is only a convenience for programmers, it should not be added. Have a look at French kyboards for instance, we choose one amongst the many choices. (In your case having 2 layouts is perfectly fine) Users can select their preferred layout by reconfiguring console-data afterwards. Denis
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 "XkbVariant""nodeadkeys" Try with Option "XkbRules" "xorg" Option "XkbModel" "pc101" Option "XkbLayout" "ch" Option "XkbVariant""de_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#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#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 2>&1 > /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 2>&1 > /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#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#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#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#311259: error and omission in documentation of LANGUAGE
On Sat, Jun 04, 2005 at 05:17:48PM -0400, Daniel Jacobowitz wrote: > On Sat, Jun 04, 2005 at 10:43:41PM +0200, Denis Barbier wrote: > > On Fri, Jun 03, 2005 at 04:56:18PM -0400, Daniel Jacobowitz wrote: > > > Except that the problem is that (if everything but LANGUAGE is unset) > > > I would have expected LANGUAGE to set LC_MESSAGES, and it doesn't. > > > > This situation should not happen, this is a user configuration error. > > All non-ASCII characters are replaced by question marks if LC_CTYPE > > is unset, so these settings are not usable. > > Huh? I think we're talking past each other. Let me go back to > examples. > > [EMAIL PROTECTED]:~% env - LANG=de_DE cat -h > cat: Ungültige Option -- h > ,,cat --help" gibt weitere Informationen. > > With just LANG set, LC_MESSAGES and LC_CTYPE are inferred from LANG. Sure, this is the well established behavior documented in POSIX. > [EMAIL PROTECTED]:~% env - LANGUAGE=de_DE cat -h > cat: invalid option -- h > Try `cat --help' for more information. > > With just LANGUAGE set, LC_MESSAGES and LC_CTYPE are not inferred > from LANG, because of the choice I think we need to document. ^ Do you mean: from LANGUAGE? > They remain as C. Yes, LANGUAGE is only checked to select message catalogs, nothing else. > [EMAIL PROTECTED]:~% env - LANG=ja_JP LANGUAGE=de_DE cat -h > cat: Ung«ältige Option -- h > ,,cat --help¡È gibt weitere Informationen. > > With LANG set to anything other than C, LANGUAGE set, and nothing else, > LC_MESSAGES is inferred from C. ^^ Should be: from LANGUAGE? > Interestingly I appear to get LC_CTYPE from LANG, not from LANGUAGE. > This also is not clear from the documentation. You have the same result with $ env - LANG=ja_JP LC_MESSAGES=de_DE cat -h POSIX states that libc behavior is unspecified if LC_MESSAGES and LC_CTYPE do not share the same encoding, which is why this situation is a user error. Your example is quite similar, libc functions try to convert German strings from UTF-8 to EUC-JP, which is not possible. In order to have a working environment, one has to set LC_MESSAGES in accordance with LC_CTYPE, and LANGUAGE can then be used to give a list of message catalogs using the same encoding. Of course, setting LANG to a UTF-8 locale is the only choice when encodings are not compatible, as with your example: $ env - LANG=ja_JP.UTF-8 LANGUAGE=de_DE cat -h Denis
Bug#311259: error and omission in documentation of LANGUAGE
On Mon, Jun 06, 2005 at 08:24:34PM -0400, Daniel Jacobowitz wrote: [...] > > > They remain as C. > > > > Yes, LANGUAGE is only checked to select message catalogs, nothing else. > > This is also not documented. And it's surprising - to me anyway. The > documentation presents it as an extension to LANG. Basically the LANGUAGE variable is a GNU extension to allow displaying messages in several languages, so that untranslated messages for your favorite language can be displayed with other languages than English. This is not a replacement for LANG; your environment must be setup correctly to display translated messages (which means that LC_MESSAGES and LC_CTYPE must be set and have compatible values). E.g. debian-installer sets LANG=nn_NO LANGUAGE=nn_NO:nn:no_NO:no:nb_NO:nb:da:sv:en_GB:en when Norwegian Nynorsk is selected, because Norwegian translators believed that most Norwegian users will prefer Danish or Swedish over English. This is fine because all these locales have the same ISO-8859-1 encoding. Now compare $ env - LANG=ja_JP LANGUAGE=de_DE cat -h cat: Ung«ältige Option -- h ,,cat --help¡È gibt weitere Informationen. $ env - LANG=fr_FR LANGUAGE=de_DE cat -h cat: Ungültige Option -- h ,,cat --help" gibt weitere Informationen. The latter works as expected, but the former does not because of encoding mismatch. In order to avoid such problems, LANGUAGE variable should almost be set under UTF-8 locales only. You can check that the some command with LANG=ja_JP.UTF-8 works fine. When LC_MESSAGES and LC_CTYPE are correctly set, LANGUAGE can contain a list of locale components, and gettext will check in turn all these message catalogs and return the first translation of this msgid. In fact, the initial example could be shortened to LANGUAGE=nn_NO:no_NO:nb_NO:da:sv:en_GB because message catalogs are also searched in xx after xx_XX. Denis
Bug#312297: /usr/sbin/locale-gen: locale-gen fails to generate ja_JP.eucJP locale
On Tue, Jun 07, 2005 at 10:55:13AM +0300, Sami J. Laine wrote: > Package: locales > Version: 2.3.2.ds1-22 > Severity: normal > File: /usr/sbin/locale-gen > Tags: l10n > > locale-gen seems to be unable to generate ja_JP.eucJP locale when > instructed to do so. As I know less about locales than a common > cow about jet-engines, I'm utterly unable to describe this problem > much further (please see attached error messages). > > --- clip --- > Generating locales... > fi_FI.ISO-8859-1... done > [EMAIL PROTECTED] done > ja_JP.eucJP... > /usr/share/i18n/locales/ja_JP:14876: LC_MESSAGES: unknown character in field > `yesexpr' > /usr/share/i18n/locales/ja_JP:14878: LC_MESSAGES: unknown character in field > `noexpr' [...] It looks like you added ja_JP.eucJP eucJP instead of ja_JP.eucJP EUC-JP in your /etc/locale.gen. As told in locale.gen(5), you have to select charsets amongst those found under /usr/share/i18n/charmaps. Hmmm, wait a minute, there is a typo in this manual page, here is a patch. Denis Index: locale.gen.5 === --- locale.gen.5(revision 922) +++ locale.gen.5(working copy) @@ -28,7 +28,7 @@ where is one of the locales given in .B /usr/share/i18n/locales and is one of the character sets listed in -.B /usr/share/i18n/charsets +.B /usr/share/i18n/charmaps The .B locale-gen
Bug#311259: error and omission in documentation of LANGUAGE
On Tue, Jun 07, 2005 at 10:30:16PM +0200, I wrote: > Now compare > $ env - LANG=ja_JP LANGUAGE=de_DE cat -h > cat: Ung«ältige Option -- h > ,,cat --help¡È gibt weitere Informationen. > $ env - LANG=fr_FR LANGUAGE=de_DE cat -h > cat: Ungültige Option -- h > ,,cat --help" gibt weitere Informationen. > The latter works as expected, but the former does not because of encoding > mismatch. In order to avoid such problems, LANGUAGE variable should almost > be set under UTF-8 locales only. You can check that the some command > with LANG=ja_JP.UTF-8 works fine. Note also that this output may differ from LANG=de_DE. E.g. on my system, de_DE is patched to fix #235759, thus I get $ env - LANG=de_DE cat -h cat: Ungültige Option -- h »cat --help« gibt weitere Informationen. (The difference is in quotes on the last line) In this case, LC_CTYPE=de_DE whereas "LANG=fr_FR LANGUAGE=de_DE" implies LC_CTYPE=fr_FR and transliteration is different. This is another reason why (IMO) LANGUAGE should be used with UTF-8 locales in order to avoid such strange side effects. Denis
Bug#311259: error and omission in documentation of LANGUAGE
On Wed, Jun 08, 2005 at 03:02:28PM -0400, Daniel Jacobowitz wrote: [...] > Yes, I realize all this now. The bug is that I can't figure _any_ of > this out from the manual. Of course I have no problem with this manual being improved, and nobody will request my opinion anyway ;) My inability to have annoying or trivial bugs fixed upstream makes me feel sometimes bitter, sorry about that. At the moment BZ968/BTS310635 is getting on my nerves, any help to make me feel better is welcome ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312902: Missing UTF-8 locales
On Fri, Jun 10, 2005 at 06:26:33PM +0100, Roger Leigh wrote: > Package: locales > Version: 2.3.2.ds1-22 > Severity: normal > > Hi, > > The following locales exist in SUPPORTED, but lack a UTF-8 variant. > > aa_DJ > af_ZA > an_ES > br_FR > bs_BA > gd_GB > ka_GE > lg_UG > mi_NZ > oc_FR > om_KE > so_DJ > so_KE > so_SO > tg_TJ > tl_PH > uz_UZ > yi_US > zh_SG > > It would be great if all our locales support UTF-8 for etch. I'm > not familiar with glibc locale data, but if there's any grunt > work I can do to help with this, I'm very willing to assist. Hi, FWIW all locales except uz_UZ have been fixed upstream in CVS, but I did not check whether some of these locales are added by Debian. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313154: INTL:vi
On Sun, Jun 12, 2005 at 06:05:32PM +0930, Clytie Siddall wrote: > Package: belocs-locales-data > Version: 2.3.4-14 > Severity: minor > Tags: l10n, patch > > The Vietnamese translation for debconf: belocs-locales-data Hi Clytie, there are no content changes with the translation http://people.debian.org/~barbier/l10n/material/po/unstable/main/b/belocs-locales-data/debian/po/belocs-locales-data_2.3.4-14_vi.po.gz you provided at http://bugs.debian.org/309332 Is this intentional? If not, can I close this bug? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308676: manpages-fr: sendfile(2) : wrong return type
On Tue, Jun 14, 2005 at 10:01:15AM +0200, Benoît Dejean wrote: > Package: manpages-fr > Version: 1.58.1-3 > Followup-For: Bug #308676 > > senfile returns a ssize_t and not a size_t. The correct prototype is : > > ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); Hi Benoît, next time, please file a seperate bug report when you find typos in other man pages. Many thanks for your reports, I will make the requested changes and forward them to Christophe Blaess. Denis
Bug#314657: belocs-locales-data: FTBFS: Patch update_CVS.diff does not apply
On Fri, Jun 17, 2005 at 02:34:51PM -0400, Justin Pryzby wrote: > On Fri, Jun 17, 2005 at 07:42:00PM +0200, Andreas Jochens wrote: > > Package: belocs-locales-data > > Version: 2.3.4-15 > > Severity: serious > > > With the attached patch 'belocs-locales-data' can be compiled > > on amd64 using gcc-4.0. > Patch not attached. Right, but I can guess what it does look like. Thanks Andreas for your report, a new upload is coming very soon. Denis > Justin > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314717: [locales] Maintainer scripts may misbehave under et_EE locale
Package: locales
Version: 2.3.2.ds1-21
Severity: normal
Tags: patch
This patch prepends LC_ALL=C to locale-dependent commands.
With et_EE locale, z is sorted after s, so it is not the last letter:
$ echo pqrstuvwxyz | LC_ALL=C sed -e 's/[a-z]//g'
$ echo pqrstuvwxyz | LC_ALL=et_EE sed -e 's/[a-z]//g'
tuvwxy
Denis
Index: debhelper.in/locales.config
===
--- debhelper.in/locales.config (revision 932)
+++ debhelper.in/locales.config (working copy)
@@ -15,7 +15,7 @@
# With current implementation, this string has to be removed.
grep -q "Leave alone" $LG && sed -e '/^Leave alone/d' $LG > $LG.tmp && mv
$LG.tmp $LG
-SELECTED_LOCALES=$(sed -e '/^[a-zA-Z]/!d' $LG | tr '\n' ',' | sed -e
's/,/, /g' -e 's/, *$//')
+SELECTED_LOCALES=$(LC_ALL=C sed -e '/^[a-zA-Z]/!d' $LG | tr '\n' ',' | sed
-e 's/,/, /g' -e 's/, *$//')
db_set locales/locales_to_be_generated "${SELECTED_LOCALES}"
else
LG=/dev/null
@@ -29,7 +29,7 @@
# Add a newline in case /etc/locale.gen has no trailing newline at EOF
SUPPORTED_LOCALES="
__SUPPORTED_LOCALES__"
-SUPPORTED_LOCALES=$( (cat $LG && echo "$SUPPORTED_LOCALES") | sed -e
'/^[a-zA-Z]/!d' | sort -u | tr '\n' ',' | sed -e 's/,/, /g' -e 's/, *$//')
+SUPPORTED_LOCALES=$( (cat $LG && echo "$SUPPORTED_LOCALES") | LC_ALL=C sed -e
'/^[a-zA-Z]/!d' | LC_ALL=C sort -u | tr '\n' ',' | sed -e 's/,/, /g' -e 's/,
*$//')
db_subst locales/locales_to_be_generated locales "${SUPPORTED_LOCALES}"
STATE=1
Index: debhelper.in/locales.postinst
===
--- debhelper.in/locales.postinst (revision 932)
+++ debhelper.in/locales.postinst (working copy)
@@ -15,7 +15,7 @@
if [ -n "$SELECTED_LOCALES" ]; then
if [ -e $LG ]; then
# Comment previous defined locales
-sed -e 's/^[a-zA-Z]/#&/' $LG > $LG.tmp || true
+LC_ALL=C sed -e 's/^[a-zA-Z]/#&/' $LG > $LG.tmp || true
mv -f $LG.tmp $LG
last=`tail -n 1 "$LG"`
if test -n "$last"; then echo >> $LG; fi
@@ -45,7 +45,7 @@
IFS=$save_IFS
else
if [ -e $LG ]; then
-sed -e 's/^[a-zA-Z]/#&/' $LG > $LG.tmp || true
+LC_ALL=C sed -e 's/^[a-zA-Z]/#&/' $LG > $LG.tmp || true
mv -f $LG.tmp $LG
fi
fi
Bug#309850: belocs-locales-bin: new localedef.1 manual page
On Fri, May 20, 2005 at 02:33:20AM +0300, Lars Wirzenius wrote: > Package: belocs-locales-bin > Version: 2.3.4-8 > > See #309846. I updated the manual page for localedef.1. I suspect it is > relevant for belocs-locales-bin as well. If there are suggestions for > improvements, please send mail to #309846 so as to keep all the > information in the same place. Thanks. Many thanks, updating this man page was on my TODO list for a long time ;) I will review it and send comments to #309846, if any. BTW are you currently hacking localedef? Maybe we should coordinate in order to prevent duplication of work. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310588: some programs segfault when run with belocs-locales-* installed
clone 310588 -1
reassign -1 libc6
tags -1 + patch
thanks
On Tue, May 24, 2005 at 03:57:48PM +0300, Eugeniy Meshcheryakov wrote:
> Package: belocs-locales-bin
> Version: 2.3.4-8
> Severity: important
>
> Some programs segfault when run with belocs-locales-* packages
> installed. Examples include: gimp when run with Ukrainian locale (also
> Russian, Serbian, Japanese and others), mozilla-firefox with
> mozilla-firefox-locale-uk (crashes after selecting some menu entries),
> sort (see attached script, crashes when run in UTF-8 locale). These
> programs do not crash with locales package installed.
Many thanks to Eugeniy who spent hours during last week to help me
understand what's going wrong here.
The conclusion is that there is a bug in strxfrm_l.c. I just filed
BZ#968 upstream. The proposed patch is quite trivial, but I could
not test it. It can be reviewed without knowing strxfrm_l.c internals,
the issue is that the variable in a decremental loop is unsigned and
checked by backw >= backw_stop whereas backw_stop may be 0.
I would be glad if you glibc guys could review and apply this patch.
Thanks
Denis
Index: string/strxfrm_l.c
===
RCS file: /cvs/glibc/libc/string/strxfrm_l.c,v
retrieving revision 1.4
diff -u -r1.4 strxfrm_l.c
--- string/strxfrm_l.c 14 Mar 2004 20:52:47 - 1.4
+++ string/strxfrm_l.c 23 May 2005 22:35:59 -
@@ -210,18 +210,19 @@
/* Handle the pushed elements now. */
size_t backw;
- for (backw = idxcnt - 1; backw >= backw_stop; --backw)
+ /* Take care of integer overflow if backw_stop is 0. */
+ for (backw = idxcnt; backw > backw_stop; --backw)
{
- len = weights[idxarr[backw]++];
+ len = weights[idxarr[backw - 1]++];
if (needed + len < n)
while (len-- > 0)
- dest[needed++] = weights[idxarr[backw]++];
+ dest[needed++] = weights[idxarr[backw - 1]++];
else
{
/* No more characters fit into the buffer. */
needed += len;
- idxarr[backw] += len;
+ idxarr[backw - 1] += len;
}
}
@@ -293,9 +294,10 @@
/* Handle the pushed elements now. */
size_t backw;
- for (backw = idxcnt - 1; backw >= backw_stop; --backw)
+ /* Take care of integer overflow if backw_stop is 0. */
+ for (backw = idxcnt; backw > backw_stop; --backw)
{
- len = weights[idxarr[backw]++];
+ len = weights[idxarr[backw - 1]++];
if (len != 0)
{
#ifdef WIDE_CHAR_VERSION
@@ -304,7 +306,7 @@
dest[needed] = val;
for (i = 0; i < len; ++i)
dest[needed + 1 + i] =
- weights[idxarr[backw] + i];
+ weights[idxarr[backw - 1] + i];
}
needed += 1 + len;
#else
@@ -315,11 +317,11 @@
dest[needed + i] = buf[i];
for (i = 0; i < len; ++i)
dest[needed + buflen + i] =
- weights[idxarr[backw] + i];
+ weights[idxarr[backw - 1] + i];
}
needed += buflen + len;
#endif
- idxarr[backw] += len;
+ idxarr[backw - 1] += len;
val = 1;
}
else
Bug#311259: error and omission in documentation of LANGUAGE
On Mon, May 30, 2005 at 10:59:29AM +0200, Mirko Parthey wrote: > Package: glibc-doc > Version: 2.3.2.ds1-22 > > LANGUAGE seems to have no effect unless LANG is set to something other > than C. I would propose to document this behaviour in the libc reference > manual, where LANGUAGE is explained. This documentation states: At the program start the default domain is `messages', and the default locale is "C". The `setlocale' call sets the locale according to the user's environment variables; remember that correct functioning of `gettext' relies on the correct setting of the `LC_MESSAGES' locale (for looking up the message catalog) and of the `LC_CTYPE' locale (for the character set conversion). So basically you should not set LC_MESSAGES to C (either explicitly or through LANG or LC_ALL variables) if you want localized output. There are some discussions at http://bugs.debian.org/308853 Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311259: error and omission in documentation of LANGUAGE
On Fri, Jun 03, 2005 at 04:56:18PM -0400, Daniel Jacobowitz wrote: > > On Mon, May 30, 2005 at 10:59:29AM +0200, Mirko Parthey wrote: > > > Package: glibc-doc > > > Version: 2.3.2.ds1-22 > > > > > > LANGUAGE seems to have no effect unless LANG is set to something other > > > than C. I would propose to document this behaviour in the libc reference > > > manual, where LANGUAGE is explained. > > > > This documentation states: > > At the program start the default domain is `messages', and the > > default locale is "C". The `setlocale' call sets the locale according > > to the user's environment variables; remember that correct functioning > > of `gettext' relies on the correct setting of the `LC_MESSAGES' locale > > (for looking up the message catalog) and of the `LC_CTYPE' locale (for > > the character set conversion). > > > > So basically you should not set LC_MESSAGES to C (either explicitly or > > through LANG or LC_ALL variables) if you want localized output. There > > are some discussions at http://bugs.debian.org/308853 > > Except that the problem is that (if everything but LANGUAGE is unset) > I would have expected LANGUAGE to set LC_MESSAGES, and it doesn't. This situation should not happen, this is a user configuration error. All non-ASCII characters are replaced by question marks if LC_CTYPE is unset, so these settings are not usable. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304919: lg-issue111: wrongly formatted list in package description
Package: lg-issue111 Severity: minor Hi, lg-issue11[1-3] descriptions are broken, leading spaces in front of list items have wrongly been removed. See e.g. http://packages.debian.org/unstable/doc/lg-issue111 Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296719: xlibs-data: zh_TW.UTF-8/XLC_LOCALE is broken after upgrading 4.3.0.dfsg.1-6 to 4.3.0.dfsg.1-7
On Sun, Apr 03, 2005 at 01:21:03PM +0800, Tetralet wrote: [...] > The attached file is the correct > /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XLC_LOCALE. > It was extracted form xlibs-data_4.3.0.dfsg.1-6_all.deb. Hi Tetralet, according to the changelog, the offending change was performed to fix #255701, by grabbing upstream CVS changes which were performed because of http://bugzilla.xfree86.org/show_bug.cgi?id=544 Thus your solution will surely reopen #255701, or did I miss something? It seems that no committers have a good understanding of those CJK issues, so I am going to ask for help on debian-i18n. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#89703: more infos about Compose file
On Sun, Apr 17, 2005 at 03:38:41AM +0900, Changwoo Ryu wrote: > I finally found this ooold bug still open... > > I don't see which informations needed more. But let me try to explain > more: [...] I will seek for advice on debian-i18n and see with XFree86 maintainers if this change can be committed. BTW could you please also have a look at #296719? We obviously need help about CJK issues. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299108: Upgrade package console-tools
bugs 299108 unreproducible thanks On Fri, Mar 11, 2005 at 05:38:40PM -0300, Administrador do Sistema wrote: > Package: console-tools > Version: 1:0.2.3dbs-56 > Severity: important > > Sorry, i dont speak english. > > In portuguese: Quando atualizei o pacote console-tools ele removeu a > linha SCREEN_FONT=lat1-16 do arquivo /etc/console-tools/config... que > veio na instalação (não alterei o arquivo e o debconf perguntava se eu > queria atualizar o arquivo... respondi sim, e perdi a configuracao de > SCREEN_FONT). > > Resultado -> Os caracteres acentuados no console via mal formados. Steve Langasek provided a translation of this bugreport (thanks, Steve), but he is very busy, maybe someone from debian-l10n-portuguese could ease communication with bug submitter? The console-tools package does not change /etc/console-tools/config, so the submitter has to check on her system which other package is the culprit. Maybe $ grep -rl /etc/console-tools/config /var/lib/dpkg/info can be helpful? Denis
Bug#305685: manpages-fr: typo dans man last
tags 305685 + pending thanks On Thu, Apr 21, 2005 at 08:03:10AM -0400, Filipus Klutiero wrote: > Package: manpages-fr > Version: 1.58.1-1 > Severity: minor > Tags: l10n > > Dans la catégorie esthétique... > La partie NOTES de man last n'a pas d'accents sur "deja". C'est enregistré, et sera corrigé dès la prochaine version du paquet. Merci. Denis
Bug#296719: xlibs-data: Help needed with CJK issues
[Dropping #255701 which is archived] On Thu, Apr 21, 2005 at 02:14:57PM +0800, Tetralet wrote: > Hi, > > Sorry for my misunderstanding. > This problem was *NOT* fixed in xlibs-data 4.3.0.dfsg.1-12. > > We find that /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XLC_LOCALE and > /usr/X11R6/lib/X11/locale/zh_TW.UTF-8/XLC_LOCALE are still broken in > xlibs-data 4.3.0.dfsg.1-12. > The Attached files is updated > /usr/X11R6/lib/X11/locale/zh_TW.UTF-8/XLC_LOCALE and > /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XLC_LOCALE. My reading of http://bugzilla.xfree86.org/show_bug.cgi?id=544 is that upstream moved ISO10646 fonts at the bottom of the file because few fonts covered most glyphs. In your comment, you tell that unifont can be used for these languages. This package is part of Chinese tasks (from tasksel), but not Japanese ones. The latter contain several other font packages. Thus I am quite inclined to change zh_TW.UTF-8/XLC_LOCALE as requested, On the other hand, Japanese users will most likely have other fonts installed, so isn't it better to leave ISO10646 at the bottom of ja_JP.UTF-8/XLC_LOCALE? The patch provided by Akira TAGOH at http://bugzilla.xfree86.org/show_bug.cgi?id=544 is the opposite of the one proposed by Tatsuki Sugiura in http://bugs.debian.org/255701 thus I am quite puzzled. I believe that Mike Fabian does a great job with CJK for SuSE, and they ship a ja_JP.UTF-8/XLC_LOCALE file similar to Tetralet's one, but maybe they have other fonts installed? Tatsuki Sugiura, could you please check with other Japanese people what changes should be made to ja_JP.UTF-8/XLC_LOCALE under Debian? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306082: Correction to the Wolof locale wo_SN
tags 306082 + pending thanks On Sun, Apr 24, 2005 at 08:14:32AM +0200, Christian Perrier wrote: > Package: belocs-locales-data > Severity: normal > Tags: patch > > Please find attached a new wo_SN locale file, with changes to the days > of the week part, suggested by a native speaker, Mouhamadou Mamoune > Mbacke. Committed, thanks. I forgot to mention that the attached patch fix a warning when compiling this locale, here it is now. Denis --- wo_SN 2005-04-24 15:11:35.244610600 +0200 +++ wo_SN 2005-04-24 15:18:39.657090096 +0200 @@ -104,7 +104,7 @@ "";/ "";/ "";/ -"";/ +"" % Sanwiy'e, feebiry'e, mars, awiril, me, suwen, sulet, ut, sattumbar, % oktobar, nowambar, desambar. abmon "";"";/
Bug#296719: xlibs-data: Help needed with CJK issues
On Fri, Apr 22, 2005 at 06:59:10PM +0800, Tetralet wrote: [...] > >Thus I am quite inclined to change zh_TW.UTF-8/XLC_LOCALE as requested, > > > Thanks!! In the SVN repository, I just reverted zh_TW.UTF-8/XLC_LOCALE to the previous version, with the following changelog entry. Please let me know if this description is inaccurate: * Revert XLC_LOCALE/zh_TW.UTF-8 to the version shipped in 4.3.0.dfsg.1-6. Tetralet explained that Chinese users are likely to have the unifont package installed because it is part of Chinese tasks, and this font covers all needed glyphs. With this font, having ISO10646 listed first in this file is harmless, whereas GTK1.2 apps are unreadable when it is at the bottom of this file. (Closes: #296719) Japanese users, please speak up if ja_JP.UTF-8/XLC_LOCALE has also to be fixed, I am still reluctant to make changes in this file. Likewise for ko_KR.UTF-8 and zh_CN.UTF-8. Thanks 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 notation (see attached patch), some collation rules look strange (I would ignore and 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 @@ ;;;IGNORE % Mac. gje reorder-after - "";"";"";IGNORE % CYR-DJE - "";"";"";IGNORE % CYR-DCHE - "";"";"";IGNORE % CYR-DZE + "";"";"";IGNORE % CYR-DJE + "";"";"";IGNORE % CYR-DCHE + "";"";"";IGNORE % CYR-DZE reorder-after - "";"";"";IGNORE % CYR-DJE - "";"";"";IGNORE % CYR-DCHE - "";"";"";IGNORE % CYR-DZE + "";"";"";IGNORE % CYR-DJE + "";"";"";IGNORE % CYR-DCHE + "";"";"";IGNORE % CYR-DZE reorder-after ;;;IGNORE @@ -448,9 +448,9 @@ ;;;IGNORE reorder-after - "";"";"";IGNORE % CYR-NJE + "";"";"";IGNORE % CYR-NJE reorder-after - "";"";"";IGNORE % CYR-NJE + "";"";"";IGNORE % CYR-NJE reorder-after ;;;IGNORE @@ -458,9 +458,9 @@ ;;;IGNORE reorder-after - "";"";"";IGNORE % CYR-LJE + "";"";"";IGNORE % CYR-LJE reorder-after - "";"";"";IGNORE % CYR-LJE + "";"";"";IGNORE % CYR-LJE reorder-after ;;;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
> -> Slovak "window" label and button labels, English template text
>
> LC_MESSAGES=sk_SK LC_CTYPE=sk_SK dpkg-reconfigure
> -> 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#292988: gettext dependency on libgcj4 gives buildds the hives
On Wed, Feb 02, 2005 at 02:38:31AM +0100, Santiago Vila wrote: [...] > > debhelper -> po-debconf -> gettext -> libgcj4 > > > > [ snipped paragraph which talks about how bad this is ] > > Ok, this is my analysis of the above chain: > > Yes, I agree it's not nice (but not to the point of suggesting that > the old gettext package comes back). Let's see: The first "big" package > in the chain is gettext, which is already 4.7MB large. Clearly, po-debconf > should depend on it or in a similar package, since that's its main purpose. > The dependency of gettext on libgcj4 comes from dpkg-shlibdeps. You are running dpkg-shlibdeps not only against usr/bin/* but also usr/lib/gettext/*, and the dependency on libgcj4 comes from gnu.gettext.DumpResource and gnu.gettext.GetURL which are not required to run gettext tools: I did not have a close look at gnu.gettext.DumpResource, but gnu.gettext.GetURL (which triggered #244215) is only used by /usr/lib/gettext/urlget. Now have a look at gettext-tools/src/urlget.c and you will see that the fetch() command tries several scenarios to download a file from an URL. For all except gnu.gettext.GetURL, it first checks whether the tool seems to work (here nothing is sent do stdout or stderr), and then perform the download with normal stdout and stderr so that problems can be reported. So #244215 is due to the fact that gnu.gettext.GetURL is run without first checking whether it can run. A fix is to let gnu.gettext.GetURL.main handle a --version option, and treat gnu.gettext.GetURL like other alternatives in the fetch() function. I will provide a patch if you are willing to go this way. A quick and dirty hack would be to move gnu.gettext.DumpResource and gnu.gettext.GetURL into another directory not checked by dpkg-shlibdeps, and set GETTEXTJEXEDIR accordingly when building gettext. > The dependencty of debhelper on po-debconf. > > Such dependency was added in October 2002, but at that time, > gettext was *already* quite big. > > Considering that not everybody who uses debhelper uses po-debconf, > the logical thing to do here, IMHO, to preserve granularity, would > have been not to add such dependency, but instead require that > packages which need po-debconf (a minority of them) add it > to their build-depends. The same argument applies against msginit, so you can replace this dependency by Recommands: libgcj4 | wget | lynx | curl or even drop the first one. Adding a w3m alternative in urlget.c would also be nice since this package is now of standard priority. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292815: po-debconf: podebconf-report-po should encode 8-bit characters in mail headers
severity 292815 minor thanks On Sun, Jan 30, 2005 at 08:45:15AM +0100, Christian Perrier wrote: > Package: po-debconf > Version: 0.8.17 > Severity: normal > > This bug happens when a translator's name in Last-Translator contains 8-bit > characters. The mails are then sent as is which may get rejected by some MTA. > > Please see the attached bounce message I got from lists.debian.org when > warning the Polish translator for apt-listchanges, with the Polish l10n list > CC'ed. In 0.8.19, non-ASCII characters are replaced by question marks, so headers should now be valid. Of course encoding them is much better, which is why I keep this bug open until a solution is found. Any ideas? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292988: gettext dependency on libgcj4 gives buildds the hives
On Thu, Feb 03, 2005 at 12:09:20AM +0100, Santiago Vila wrote: [...] > As opposed to po-debconf in debhelper, I do not consider users of > msginit to be a minority among the users of gettext. The gettext > package is used by programmers (which I think are a minority) and > translators (which I think they are the big group of users). > As msginit is used by translators, I would much prefer a dependency on > "wget | lynx | curl" so that it always work. As a translator, I never used it and did not even remember of this tool ;) > So here is the current plan: > > * Drop gcj from build depends. > * Keep jikes-classpath in the build depends. > * Include gettext.jar in the gettext package. > * Remove the "first try" from urlget.c. > * Add a dependency on "curl | wget | lynx" to gettext. > (curl is 220Kb large, I think everybody will be happy to use this > instead of libgcj4). > * People who want to develop java applications which use gettext > should do so using a java virtual machine for gettext.jar to work. > I can add a note to README.Debian similar to the already existing > one for autopoint and cvs. > > Does this look good enough to consider this issue resolved? Sounds good to me, but IMO a Recommands is enough. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292988: gettext dependency on libgcj4 gives buildds the hives
On Thu, Feb 03, 2005 at 07:56:06AM +0100, Denis Barbier wrote: [...] > > Does this look good enough to consider this issue resolved? > > Sounds good to me, but IMO a Recommands is enough. I forgot some rationale, here they are. I tested msginit yesterday, and this program is aimed at filing in header fields when starting a new translation. This is already done by all text and PO editors. For this, it downloads URLs, but as a last resort it can get files locally from /usr/share/gettext/projects/ (this is what I guessed by reading urlget.c, but did not actually test it). This is why there is no strict dependency, it can work without downloading any file. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292988: gettext dependency on libgcj4 gives buildds the hives
On Thu, Feb 03, 2005 at 10:20:40AM +0100, Santiago Vila wrote: > On Thu, 3 Feb 2005, Denis Barbier wrote: > > As a translator, I never used it and did not even remember of this > > tool ;) > > Ok, assuming that the very first thing people do when something does > not work is to look at the Suggests and Recommends, I'll use a Recommends. > > In fact, I have never used that feature as a translator, either. Great, thanks a lot for your consideration! Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212881: Noninteractive patch for cdebconf
On Sat, Feb 05, 2005 at 12:43:14AM -0500, Alex Mohr wrote: > Package: cdebconf > Version: 0.74 > Followup-For: Bug #212881 > > I developed a patch to cdebconf that provides noninteractive support > for unattended installs. It automatically uses the default setting > for every question and is based on the text installer. I'll include > it below, but it's also available from > http://mnl.cs.sunysb.edu/~amohr/cdebconf-noninteractive-patch > > It's been tested with a few different configurations and doesn't > seem to have any problems. If this frontend does not display anything to the user, why should these templates be translated? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293795: xserver-xfree86: unable to switch to virtual consoles on SPARC
reassign 293795 xlibs severity 293795 important tags 293795 + pending merge 293795 287810 On Sat, Feb 05, 2005 at 08:49:17PM +0200, Baurjan Ismagulov wrote: > Package: xserver-xfree86 > Version: 4.3.0.dfsg.1-10 > Severity: normal > > Hello, > > I can't switch to the virtual consoles via Ctrl-Alt-Fn or Ctrl-Meta-Fn. This is a known bug, will be fixed by next upload. More informations are available from http://bugs.debian.org/287810 Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
