Re: Bladr GTK theme for g-i ready for packaging
On Fri, Sep 22, 2006 at 04:10:09PM +0200, Frans Pop wrote: On Friday 22 September 2006 15:12, Attilio Fiandrotti wrote: I think we may want let icons PNGs in place because this would allow me to replace the special PNGs used for the error (error_icon.png) and warning (note_icon.png) questions with PNGs belonging to the current theme in use (e.g.: stock_cancel.png and stock_apply.png ). If denis could provide stock_apply.png, stock_cancel.png in HignContrastLargeInverse too, also the accessibility theme could have its own nice error and note icons. I'm not objecting to anything that is used, but please do not include _anything_ that is not used. It can always be added in later when it is needed. I concur, but for a slightly different reason. The primary goal of an accessibility theme is to be usable by disabled people which could not use g-i otherwise. This is not a cosmetic issue. The HignContrastLargePrintInverse theme is usable without those icons, so I hope that it can be enabled soon. We could make it fancier later, if we have some free space/memory, but honestly I much prefer having a not appealing HignContrastLargePrintInverse theme than no theme at all, this is a first step in the right direction. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please, word diff for fuzzied translatable strings
On Tue, Sep 19, 2006 at 12:58:54PM +0200, Frans Pop wrote: On Tuesday 19 September 2006 12:34, Tapio Lehtonen wrote: When sending a .po file to be translated, please include word diff for strings that are marked fuzzy. It is much easier to unfuzzy when I can see what has changed in the english text. Yes, that is a serious drawback of using PO files. Maintainers can send a diff if they want to help translators, see #353611. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accessibility theme for the graphical installer
On Sat, Sep 16, 2006 at 12:19:30AM +0200, Frans Pop wrote:
[...]
I've checked your changes in rootskel-gtk and I think the implementation
can be improved. I've not looked at how the theme looks, only at the
technical side of it.
I think I have mentioned before that I would like to be able to set themes
consistently with other parameters, i.e. using a debconf value like
debian-installer/theme (with a shortcut for the boot prompt theme=...)
instead of FRONTEND_BACKGROUND or whatever.
I have now implemented this in rootskel and preseed (see attached
patches). This works for both gtk and newt frontends.
Ok, but the accessibility theme is HighContrastLargePrintInverse,
this is why I wanted an alias ;)
The attached patch calls this theme 'dark', it has to be applied on
top of yours. I successfully tested it, theme and font size are
fine when theme=dark is passed on boot prompt.
There are some minor glitches at the beginning, error messages are
printed before g-i is launched, surely due to missing pixmaps.
This can be fixed later by customizing dark/gtk-2.0/gtkrc, at the
moment it is simply copied from
/usr/share/themes/HighContrastLargePrintInverse/gtk-2.0/gtkrc
Denis
--- rootskel-gtk/src/usr/share/Makefile
+++ rootskel-gtk/src/usr/share/Makefile
@@ -1,6 +1,7 @@
dir = usr/share
subdirs = \
- graphics
+ graphics \
+ themes
include ../../../Makefile.inc
--- /dev/null
+++ rootskel-gtk/src/usr/share/themes/Makefile
@@ -0,0 +1,18 @@
+dir = usr/share/themes
+
+files = \
+ dark/gtk-2.0/gtkrc
+
+# I should put Makefiles in all intermediate directories, let's get lazy
+build-recursive clean-recursive install-recursive:
+ -@:
+
+build clean:
+ -@:
+
+install:
+ for file in $(files); \
+ do \
+ mkdir -p `dirname $(DESTDIR)/$(dir)/$$file`; \
+ cp $$file $(DESTDIR)/$(dir)/$$file; \
+ done
--- /dev/null
+++ rootskel-gtk/src/usr/share/themes/dark/gtk-2.0/gtkrc
@@ -0,0 +1,251 @@
+# High-Contrast, Large Print, Inverse Video Theme v0.1
+# This is the whole basic theme, just this one gtkrc file.
+# It uses components of the standard theme engine
+# Written by Bill Haneman, based on Standard theme by T. Liebeck,
+# which was in turn based on lots of different gtkrc files but
+# primarily the one for the metal theme.
+# email: [EMAIL PROTECTED]
+
+pixmap_path /usr/share/themes/HighContrastLargePrintInverse/pixmaps
+
+gtk-icon-sizes =
mini-commander-icon=24,24:print-manager=64,64:panel-button=32,32:gtk-dnd=48,48:gtk-menu=32,32:panel-menu=48,48:gtk-large-toolbar=48,48:gtk-small-toolbar=32,32:gtk-button=32,32:gtk-dialog=64,64
+
+style default
+{
+ engine hcengine {}
+
+# For Java Desktop System
+ PanelMenu::stripe-gradient-top = #33
+ PanelMenu::stripe-gradient-bottom = #33
+
+ GtkWidget::focus-line-pattern = \10\2
+ GtkWidget::interior_focus = 1
+ GtkWidget::focus-padding = 0
+ GtkWidget::focus-line-width = 3
+# GtkWidget::cursor_aspect_ratio = 0.1
+
+ GtkHSV::focus-line-pattern = \0
+ GtkRange::slider_width = 20
+
+ GtkPaned::handle-size = 10
+
+ GtkEntry::cursor_color= #00
+ GtkEntry::cursor_aspect_ratio = 0.1
+
+ GtkTreeView::expander_size = 20
+
+ GtkTextView::cursor_aspect_ratio = 0.1
+ GtkTextView::cursor_color= #00
+
+ EelEditableLabel::cursor_color= #00
+ EelEditableLabel::cursor_aspect_ratio = 0.1
+
+ GtkCheckButton::indicator_size = 18
+ GtkCheckMenuItem::indicator_size = 18
+
+ NautilusIconContainer::frame_text = 1
+ GtkExpander::expander-size = 24
+ GtkExpander::expander-spacing = 8
+
+ PanelToplevel::arrow-size = 18
+
+ fg[NORMAL] = #ff
+ text[NORMAL] = #ff
+ bg[NORMAL] = #33
+ base[NORMAL]= #33
+
+ fg[INSENSITIVE] = #99
+ bg[INSENSITIVE] = #33
+ text[INSENSITIVE] = #99
+ base[INSENSITIVE] = #33
+
+ fg[PRELIGHT]= #00
+ text[PRELIGHT]= #00
+ bg[PRELIGHT]= #ff
+ base[PRELIGHT]= #ff
+
+ fg[ACTIVE] = #ff
+ text[ACTIVE] = #ff
+ bg[ACTIVE] = #99
+ base[ACTIVE] = #99
+
+ fg[SELECTED]= #33
+ text[SELECTED]= #33
+ bg[SELECTED]= #ff
+ base[SELECTED]= #ffccff
+
+
+
+ stock[gnome-stock-about] = {{ stock_about.png }}
+ stock[gnome-stock-volume] = {{ stock_volume.png }}
+ stock[gnome-stock-mic] = {{ stock_mic.png }}
+ stock[gnome-stock-line-in] = {{ stock_line-in.png }}
+ stock[gnome-stock-attach] = {{ stock_attach.png }}
+ stock[gnome-stock-book-blue] = {{ stock_book.png }}
+ stock[gnome-stock-book-green] = {{ stock_book.png }}
+ stock[gnome-stock-book-red] = {{ stock_book.png }}
+ stock[gnome-stock-book-yellow] = {{ stock_book.png }}
+
+ stock[gtk-dialog-info] = {{ stock_dialog_info.png }}
+ stock[gtk-dialog-question] = {{ stock_dialog_question.png }}
+ stock[gtk-dialog-error] = {{ stock_dialog_error.png }}
+ stock[gtk-dialog-warning] = {{ stock_dialog_warning.png }}
+
Re: Accessibility theme for the graphical installer
On Sat, Sep 16, 2006 at 11:12:14PM +0200, Frans Pop wrote: Nice. This implementation looks much better. On Saturday 16 September 2006 22:36, Denis Barbier wrote: Ok, but the accessibility theme is HighContrastLargePrintInverse, this is why I wanted an alias ;) Well, we could also use a 'case' statement in the gtk-set-theme script to translate from dark to HighContrastLargePrintInverse. Ok, I have no strong opinion, but since we are going to customize it, having a different name looks better to me. There are some minor glitches at the beginning, error messages are printed before g-i is launched, surely due to missing pixmaps. Will we need any of those PNGs? What would be their total size? Did you see Attilio's mail about the Bladr theme? Could we reuse PNGs included in that (e.g. by symlinking to them)? Or do you want to just fall back on the default (or no) icons? I have no idea, it is usable without any PNGs, I will add them to see if they appear on screen. This can be fixed later by customizing dark/gtk-2.0/gtkrc, at the moment it is simply copied from /usr/share/themes/HighContrastLargePrintInverse/gtk-2.0/gtkrc I should indeed like to see the theme trimmed. I doubt we'll ever need the media-icons section. There's also a lot of definitions for .png files we'll never use and that could be removed. I'd like to see that done (at least the bulk of it) before we upload. We can start by committing the full file though so we keep the history of customizations in SVN. Good idea. Could you provide a trimmed version that I can commit that after this patch? Ok, I will make tests. Please also provide the basic author and licencing info from the theme for inclusion in the rootskel-gtk copyright file (preferably as patch). Here it is. Denis Index: rootskel-gtk/debian/copyright === --- rootskel-gtk/debian/copyright (révision 40737) +++ rootskel-gtk/debian/copyright (copie de travail) @@ -13,3 +13,9 @@ The icons note_icon.png and warning_icon.png are copyright (c) 2005 by Eduardo Silva. These logos or a modified version may be used by anyone. + +The 'dark' theme is derived from the HighContrastLargePrintInverse GNOME +theme, downloaded from +http://ftp.gnome.org/pub/GNOME/sources/gnome-themes/2.14/gnome-themes-2.14.3.tar.bz2 +It is written by Bill Haneman, based on Standard theme by T. Liebeck, +and released under LGPL 2.1.
Re: Accessibility theme for the graphical installer
On Sat, Sep 16, 2006 at 11:41:38PM +0200, Denis Barbier wrote:
Will we need any of those PNGs? What would be their total size?
Did you see Attilio's mail about the Bladr theme? Could we reuse PNGs
included in that (e.g. by symlinking to them)?
Or do you want to just fall back on the default (or no) icons?
I have no idea, it is usable without any PNGs, I will add them to
see if they appear on screen.
Adding pixmaps did not make any difference, I then removed all icon
definitions from gtkrc, and there is still no difference. Here is
the trimmed down gtkrc file.
Denis
# High-Contrast, Large Print, Inverse Video Theme v0.1
# This is the whole basic theme, just this one gtkrc file.
# It uses components of the standard theme engine
# Written by Bill Haneman, based on Standard theme by T. Liebeck,
# which was in turn based on lots of different gtkrc files but
# primarily the one for the metal theme.
# email: [EMAIL PROTECTED]
style default
{
GtkWidget::focus-line-pattern = \10\2
GtkWidget::interior_focus = 1
GtkWidget::focus-padding = 0
GtkWidget::focus-line-width = 3
# GtkWidget::cursor_aspect_ratio = 0.1
GtkHSV::focus-line-pattern = \0
GtkRange::slider_width = 20
GtkPaned::handle-size = 10
GtkEntry::cursor_color= #00
GtkEntry::cursor_aspect_ratio = 0.1
GtkTreeView::expander_size = 20
GtkTextView::cursor_aspect_ratio = 0.1
GtkTextView::cursor_color= #00
EelEditableLabel::cursor_color= #00
EelEditableLabel::cursor_aspect_ratio = 0.1
GtkCheckButton::indicator_size = 18
GtkCheckMenuItem::indicator_size = 18
NautilusIconContainer::frame_text = 1
GtkExpander::expander-size = 24
GtkExpander::expander-spacing = 8
PanelToplevel::arrow-size = 18
fg[NORMAL] = #ff
text[NORMAL] = #ff
bg[NORMAL] = #33
base[NORMAL]= #33
fg[INSENSITIVE] = #99
bg[INSENSITIVE] = #33
text[INSENSITIVE] = #99
base[INSENSITIVE] = #33
fg[PRELIGHT]= #00
text[PRELIGHT]= #00
bg[PRELIGHT]= #ff
base[PRELIGHT]= #ff
fg[ACTIVE] = #ff
text[ACTIVE] = #ff
bg[ACTIVE] = #99
base[ACTIVE] = #99
fg[SELECTED]= #33
text[SELECTED]= #33
bg[SELECTED]= #ff
base[SELECTED]= #ffccff
}
class GtkWidget style default
Re: New cdebconf facility allowing simpler translated choices
On Fri, Sep 15, 2006 at 11:24:02AM +0200, Frans Pop wrote: On Friday 15 September 2006 10:56, Colin Watson wrote: It probably should be what is displayed in a C locale, at least in the installer. I think that's a bug. Do you agree? Hmm. If we are going to put codes or to quote you: identifiers that are convenient for use in code in choices-C then I would prefer to have the English translation displayed if the locale is C (provided of course that LANG=en). Is that indeed what happens currently? I do not know how it is displayed within d-i, but I made tests on cdebconf SVN, and this is indeed what happens, hence my comment. IIRC this feature had been requested years ago, and I objected; I do not remember exactly why and cannot find the bug report, IIRC it was for kbd-chooser, and my objection was that having 2 lists (codes and English text) was error prone. As there have been many errors with translations, it is indeed better to have a single point of failure ;) I agree with Frans that Choices should be displayed in English and C locales; Choices-C is an internal code, this is why I suggested to call it Choices-internal if this is possible without breaking too much things. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New cdebconf facility allowing simpler translated choices
On Mon, Sep 11, 2006 at 06:39:41PM +0100, Colin Watson wrote:
I've added this feature to cdebconf in trunk:
* Allow Choices-C to be listed separately from Choices (etc.) in templates
files. This lets you say Choices: ${CHOICES-TRANS} and Choices-C:
${CHOICES} to substitute reliably into translated and untranslated
templates without having to ensure that ${CHOICES-TRANS} is translated
to the same thing in every language.
This is really great, but I find that the -C suffix is confusing, because this
is not what is displayed in a C locale. Could it be replaced by -internal?
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accessibility theme for the graphical installer
Hi, With help from Eddy Petrişor, I copied the HighContrastLargePrintInverse theme (from gnome-accessibility-themes) into rootskel-gtk, you can find this package under people/barbier/rootskel-gtk in d-i subversion repository. This theme is currently enabled when the FRONTEND_BACKGROUND=dark boot argument is found. Is it okay to put this stuff into trunk? Do people on d-accessibility have an opinion on this theme and font size? An i386 so-called gtk_miniiso image is available at http://people.debian.org/~barbier/tmp/mini.iso Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379052: /etc/default/locale won't work as you expected, seems need more works
On Wed, Aug 30, 2006 at 11:44:10PM +0900, Kenshi Muto wrote: Hi, Denis suggested dropping /etc/environment and moving locale information to /etc/default/locale. I support this idea, but currently this change prevents the localized desktop environment. GDM is launched in local language using /etc/default/locale (called by /etc/init.d/gdm). But when user logins without any modifications, the desktop environment will be shown in only English. This is because LANG isn't defined (GDM_LANG is empty also). No startup routine care it at this time. Of course if user chooses language from GDM option and logins, .dmrc includes LANG information is created, then the desktop will be shown in choosed language... well, but I believe such manual doing is not smart. Although modifying GDM /etc/gdm/Xsession to include /etc/default/locale file is one of solutions, but I think it's better that providing a loader script to /etc/X11/Xsession.d/ and let it run faster. Hi, Your bug report seems to imply that a package reads /etc/environment and should be fixed to read /etc/default/locale too. I won't have time to work on this now, but will be glad to fix it during our i18n session. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379052: localechooser: Please do no more create /etc/environment
Package: localechooser Severity: normal Hi, when locale variables had been moved from /etc/environment into /etc/default/locale, Christian and I agreed on letting localechooser create both files until most programs have been modified in testing. I believe that this is done now, so localechooser can be modified to not create /etc/environment. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Tue, Jun 20, 2006 at 04:40:53PM +0200, Steinar H. Gunderson wrote: On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: After some discussion on IRC, here's the updated patch. One change is needed yet; the current code in debconf-copydb simply turns off i18n support (since the old code couldn't handle that properly, it seems, or perhaps it's even older). Just nuke the setenv() line from debconf-copydb.c and we should be okay. BTW, Joey: There _are_ lots of non-UTF-8 strings out there, it seems -- it's unfortunate, but we can't nuke the support from debconf just yet. :-/ In case this is of interest for someone, here are some figure: * There are 7 packages in unstable with Field-xx translated fields (i.e. without encoding): pool/main/a/amavis-ng/amavis-ng_0.1.6.9-1_all.deb pool/main/b/bottlerocket/bottlerocket_0.05b3-6.1_i386.deb pool/main/c/chdrv/chdrv_1.0.13p-2_i386.deb pool/main/f/filterproxy/filterproxy_0.30-6_all.deb pool/main/i/ifupdown/ifupdown_0.6.7_i386.deb pool/main/n/ndtpd/ndtpd_3.1.5-6.3_i386.deb pool/main/x/x-symbol/x-symbol_4.43-5_all.deb * There are 107 (180 in main + 5 in contrib + 2 in non-free) packages in unstable with non UTF-8 (and non utf-8 :)) Field-xx.encoding translated fields. Note that many packages need more than a simple rebuild because they implemented the hack described in http://lists.debian.org/debian-i18n/2003/07/msg00026.html to ease woody portability. * There is no package with Field-xx.utf8 translated field, so the applied fix looks safe. IIRC cdebconf does only support UTF-8 on output too, so it cannot replace debconf when run under a non UTF-8 locale. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: On Mon, Jun 19, 2006 at 01:42:53PM -0400, Joey Hess wrote: The easiest way would probably be to not track the information and store (and output) the field as utf-8 without doing any transcoding. This is not exactly what debconf does, but fields that do not define an encoding are basically using an undefined encoding and it's ok if cdebconf assumes it's really utf-8. If this causes a mojibake then the right way to fix it is to make the package define an encoding. After some discussion on IRC, here's the updated patch. --- cdebconf-0.102.orig/src/template.c2005-09-21 19:07:46.0 +0200 +++ cdebconf-0.102/src/template.c 2006-06-19 20:54:35.0 +0200 @@ -354,7 +354,7 @@ free(orig_field); return NULL; } -cp = strstr(altlang, .UTF-8); +cp = strcasestr(altlang, .UTF-8); I am not sure that this is desirable, next time you will encounter utf8 instances, and maybe other names too (except that I cannot find another one ;)) +/* Plain debconf supports undefined character sets, on the + form Description-nb_NO: , which is valid if the text is + ASCII (but debconf still uses that syntax regardless of + validity if the application does not specify a character + set). To avoid losing these fields, we simply read them + in as if they were UTF-8 fields, as valid ASCII is always + valid UTF-8 as well. Ditto, this is supported by debconf for compatibility reasons, but we should try hard to get rid of undefined encodings wherever possible. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-in-workers] Country names for Bengali
On Mon, Apr 03, 2006 at 04:18:36PM +0600, Jamil Ahmed wrote: [...] I wrote a first draft of collation rules, based on informations found in http://tdil.mit.gov.in/bangla.pdf http://www.unicode.org/cldr/data/common/collation/bn.xml http://developer.mimer.com/collations/charts/bengali.htm Could a native speaker please send a sorted list of words, say around 50, one word per line? I can then check that the file is not modified when passed to the sort command. Can a native Bengali speaker please provide this file, so that I can test collation rules? Please check the file, http://www.bengalinux.org/downloads/BN_country_list_sorted.txt.bz2 FYI, the file is created manually. So there might be some glitches. :) Thanks, I had a look, and my collation rules does not seem right, so more work is needed. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341596: Bug#341956: [PATCH] loadkeys -m shouldn't need console.
On Wed, Mar 29, 2006 at 03:43:18PM +1100, Peter Chubb wrote:
This bug really started to annoy me when I couldn't cross-compile ARM
kernels as a batch job...
As noticed by Frans, this post is about #341956 and not #341596, please
respect the Reply-To.
Peter, thanks for your patch. It is included here to reach #341956.
The problem is the unicode patch, 430_read_keymaps_fmt.patch
which unconditionally tries to work out if the current console is in
unicode mode. Appended is a patch that makes this conditional on not
-m.
diff -Nru ./console-tools-0.2.3/kbdtools/loadkeys.y
../build-tree.new/console-tools-0.2.3/kbdtools/loadkeys.y
--- ./console-tools-0.2.3/kbdtools/loadkeys.y 2006-03-29 15:24:20.0
+1100
+++ ../build-tree.new/console-tools-0.2.3/kbdtools/loadkeys.y 2006-03-29
15:23:42.0 +1100
@@ -408,17 +408,18 @@
}
}
- fd = get_console_fd(NULL);
- if (!optu) {
-if (ioctl(fd, KDGKBMODE, mode)) {
- perror(KDGKBMODE);
- fprintf(stderr, _(loadkeys: error reading keyboard mode\n));
- exit(1);
- }
-if (mode == K_UNICODE)
- set_charset(unicode);
-}
-
+ if (!optm) {
+fd = get_console_fd(NULL);
+if (!optu) {
+ if (ioctl(fd, KDGKBMODE, mode)) {
+perror(KDGKBMODE);
+fprintf(stderr, _(loadkeys: error reading keyboard mode\n));
+exit(1);
+ }
+ if (mode == K_UNICODE)
+set_charset(unicode);
+ }
+ }
args = argv + optind - 1;
/* set up the first input file, if any */
yywrap();
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-in-workers] Country names for Bengali
On Thu, Mar 09, 2006 at 10:10:50PM +0100, Denis Barbier wrote: On Sun, Feb 26, 2006 at 08:49:22AM +0100, Christian Perrier wrote: Christian already informed that the bn_BD locale has an issue, I will try to dig out. You can ask for help on debian-i18n, at least to be pointed at correct documentation about collation rules writing. Denis barbier gave a very interesting talk at last Debconf about this (which talk, dammit, I couldn't attend because I had a D-I talk immediately after it). Slides are available at http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf I wrote a first draft of collation rules, based on informations found in http://tdil.mit.gov.in/bangla.pdf http://www.unicode.org/cldr/data/common/collation/bn.xml http://developer.mimer.com/collations/charts/bengali.htm Could a native speaker please send a sorted list of words, say around 50, one word per line? I can then check that the file is not modified when passed to the sort command. Can a native Bengali speaker please provide this file, so that I can test collation rules? Thanks. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [G-I] progress in theming
On Wed, Mar 22, 2006 at 11:09:48AM +0100, [EMAIL PROTECTED] wrote: Luca Bruno wrote: Now, I'd like to work on visual-impaired theme. Attilio suggested me to work on HighContrastLargePrintInverse theme, available in gnome-themes. I remember HighContrastLargePrintInverse adoption for visua impaired people being suggested by Denis Barbier, but i cannot speak about this as i know just very little abot accessibility. My rationale is very simple: if the default theme has a bright background, the alternate theme should have a dark one. If the default theme had a dark background, I would vote for the HighContrastLarge theme. In fact, one can imagine that font size can be selected at boot time (maybe this is already the case, I did not check). But this is hardly true for colors, they need to be predefined, which is why different choices must be provided. Or an alternative could also be to have a reverse video option. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [G-I] progress in theming
On Wed, Mar 22, 2006 at 11:05:49PM +0100, Attilio Fiandrotti wrote: [...] By the way, are we going to package our two GTK themes into rootskel-gtk or into a new udeb? Note that gnome-accessibility-themes includes many themes and we need only one of theme, moreover stripped by unneded PNGs to save up space IMHO putting themes into rootskel-gtk is the easiest solution. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-in-workers] Country names for Bengali
On Sun, Feb 26, 2006 at 08:49:22AM +0100, Christian Perrier wrote: Christian already informed that the bn_BD locale has an issue, I will try to dig out. You can ask for help on debian-i18n, at least to be pointed at correct documentation about collation rules writing. Denis barbier gave a very interesting talk at last Debconf about this (which talk, dammit, I couldn't attend because I had a D-I talk immediately after it). Slides are available at http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf I wrote a first draft of collation rules, based on informations found in http://tdil.mit.gov.in/bangla.pdf http://www.unicode.org/cldr/data/common/collation/bn.xml http://developer.mimer.com/collations/charts/bengali.htm Could a native speaker please send a sorted list of words, say around 50, one word per line? I can then check that the file is not modified when passed to the sort command. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353380: If i would be clever
On Sat, Feb 18, 2006 at 08:14:58AM +0100, Christian Perrier wrote: reassign 353380 xserver-xorg retitle 353380 fr-latin9 layout does not work properly thanks (X people, this was initially an installation report for D-I. Benoît has problems with the fr-latin9 layout and Ctrl-Alt-Fx keys of Shift (Maj) key not working) In xorg 6.9, the fr-latin9 layout has been replaced by layout: fr variant: latin9 Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353380: If i would be clever
On Sat, Feb 18, 2006 at 02:40:43PM +0100, Christian Perrier wrote: Quoting Denis Barbier ([EMAIL PROTECTED]): On Sat, Feb 18, 2006 at 08:14:58AM +0100, Christian Perrier wrote: reassign 353380 xserver-xorg retitle 353380 fr-latin9 layout does not work properly thanks (X people, this was initially an installation report for D-I. Benoît has problems with the fr-latin9 layout and Ctrl-Alt-Fx keys of Shift (Maj) key not working) In xorg 6.9, the fr-latin9 layout has been replaced by layout: fr variant: latin9 Well, then we should probably close this bug ? Agreed, closing it now. Funnily, I have the following which works pretty well in my own xorg.conf, using sid: Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xorg Option XkbModel inspiron Option XkbLayout fr-latin9 EndSection Yes, this is another example why XKB files should not be under /etc. I hope that I will find time soon to move them back into /usr. When upgrading xlibs, /etc/X11/xkb/symbols/pc/fr-latin9 was a conffile and has not been removed from your disk even if it has been removed from this package. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
On Sun, Dec 19, 2004 at 09:30:12AM +0100, Christian Perrier wrote: [...] As soon as the user has a non US keyboard, (s)he configured it properly in the kbd-chooser part of d-i, but afterwards, when installing X (often through the desktop task of tasksel), the keyboard still used a us layout. This was mostly due to the kbd layout question being medium priority in X packages, so it was skipped during the install. We (d-i team) had tons of reports with users not understanding why they has a US layout in X while they did choose another layout during the install. localization-config tries to circumvent this by installing safe defaults based on the localisation environment. So, in Tapio's case, as the install was probably done in Finnish, the X keyboard layout was set to fi. The problem is that XkbVariant was set instead of XkbLayout. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286281: locales are not generated
[Christian Perrier] [EMAIL PROTECTED] LC_CTYPE=fr_FR LC_NUMERIC=fr_FR LC_TIME=fr_FR LC_COLLATE=fr_FR LC_MONETARY=fr_FR LC_MESSAGES=fr_FR LC_PAPER=fr_FR LC_NAME=fr_FR LC_ADDRESS=fr_FR LC_TELEPHONE=fr_FR LC_MEASUREMENT=fr_FR LC_IDENTIFICATION=fr_FR LC_ALL=fr_FR *this* is not what is shown by default French installs after running d-i rc2. I'm pretty sure that no d-i version except maybe some old daily builds have had any other behaviour. LANG as well as all LC_* variables should be set to [EMAIL PROTECTED], not fr_FR. The LC_* value comes from LANG, indeed. They are not set explicitely anywhere. LC_ALL is *not* set at all, of course. In 'locale' output, variables are quoted when they are not explicitly set, but get their values from other variables, in this case LC_ALL. So it looks like the bug submitter erroneously added LC_ALL=fr_FR into user's configuration file. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#282632: Automated Polish install hangs as well
Christian Perrier wrote: Quoting Joey Hess ([EMAIL PROTECTED]): Christian Perrier wrote: Today, I got the very same probelm I got with the automated Welsh install. It hangs while probing the APT mirrors. The preseed files are exactly the same. Attached is a debug log of base-config (system booted with DEBCONF_DEBUG=.). This time, no comma is missing in the Polish translation of base-config... From your log: debconf (developer): -- SET apt-setup/country enter information manually This does not seem to be the same as the Polish problem: debconf (developer): -- SET apt-setup/country rhoi gwybodaeth â llawAustralia Yes, the symptom is that same, but the origin doesn't seem to be the same. Your log contains debconf (developer): -- SUBST apt-setup/country countries wprowad 1/4 informacj? r?cznie, Australia, Austria, Belgia, Bia³oru¶, Brazylia... The first item is the translation of enter information manually but it is transcoded into ISO-8859-1, And indeed, po/pl.po sets its charset to ISO-8859-1 instead of ISO-8859-2, I do not know if setting the right charset will fix the problem, but at least log messages should be clearer. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#282582: Some functions in cdebconf improperly handle escaped commas
On Tue, Nov 23, 2004 at 07:06:34AM +0100, Christian Perrier wrote: Frans Pop suggested in #debian-boot [20:30:49] fjp bubulle: I think the program that causes the problems with comma's is cdebconf's strutl.c. The functions strgetargc and strchoicesplit (and maybe str(un)escape) don't know about escaped commas. It may be buggy, but there is definitely code to deal with escaped commas in these functions. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280135: #280135: Please consider supporting localization but with messages in EN (was: Re: Bug#276067: Reassigning this bug report)
On Sun, Nov 07, 2004 at 05:00:38PM +0100, Frans Pop wrote: On Sunday 07 November 2004 12:45, Morten Sickel wrote: [...] So, when selecting language, I selected UK English. On the next screen, I was presented with a list of 'reasonable countries' due to my selection of language, iirc, Denmark was among them, therefore I send a comment that you could maybe add Norway as well (I do not think there are any en_DK locale either...) Well, for some reason it seems there _is_ an en_DK locale. I can understand your request for adding Norway from that. However, personally I feel the en_DK locale should not really be there. I agree with Denis that adding en_XX locales for countries that don't have English as an official language is a bad idea. Google gives this valuable pointer: http://mail.gnome.org/archives/gnome-i18n/2004-March/msg00090.html Keld Jørn Simonsen wrote: ] Well, I am responsible for the en_DK locale (I wrote it and it is/was ] included it the ISO POSIX standard. ] ] The political reason was that English is the company language in a ] number of Danish firms. So even if you use English as the internal ] company language, then with the en_DK locale you can get the other ] danish settings, such as paper size. ] ] The unofficial reason is that this was a way to produce a locale that ] can be used as the standard - for other locales to build on. And this is ] how many locales then was written (they were also written by me). ] Basically the en_DK locale is better suited to build other locales, ] especially the sorting, where building on a Danish locale (which was the ] alternative for the ISO POSIX standard) is peculiar, with our special ] ordering of and and and and such. ] ] In TR 14652 it is replaced by the i18n locale. In short, en_DK is there only because it was a template for locale files a long time ago. Denis
Bug#279085: tasksel: Support executable .desc scripts
On Fri, Nov 05, 2004 at 11:27:11AM +0100, Free Ekanayaka wrote:
[...]
DB Out of curiosity, how do you manage translations when tasks are
DB dynamically created?
FE That's a problem I did not take into account. Is there any straight
FE solution?
Tasksel prints translated tasks with help from gettext, so they can
be displayed if translations have been previously written into
/usr/share/locale/LOCALE/LC_MESSAGES/debian-tasks.mo compiled files
('debian-tasks' textdomain is hardcoded, not sure if this is a good
thing).
This morning I got some light. My plan is to eventually write some
code for generating the task desc on the fly using the debtags
databse, whose tags do have support for translation.
/usr/share/doc/debtags/README.Debian.gz has some words about i18n,
but it seems that nothing has been implemented, so AFAICT translations
are not supported.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279085: tasksel: Support executable .desc scripts
Package: tasksel Version: 2.14 Followup-For: Bug #279085 You wrote: Here is a little patch to support executable .desc files. This way one can dynamically create the list of available tasks, for example consulting an alternative source of information (e.g. debtags). Out of curiosity, how do you manage translations when tasks are dynamically created? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278186: tasksel: Preseeding needs using the localized values of task names
On Wed, Oct 27, 2004 at 06:42:50AM +0200, Christian Perrier wrote: No, debconf is designed so that choices values are always in English. Hey, I knew that...:-) Hence the bug report. Preseeding the task list currently only works if the preseeding is made with localized values But the patch fixes this bug, or did I miss something? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278186: tasksel: Preseeding needs using the localized values of task names
Package: tasksel
Version: 2.14
Followup-For: Bug #278186
Christian Perrier wrote:
When preseeding tasksel, the value(s) preseeded in tasksel/first must
use the localized names.
For instance, if D-I was run in French and one wants to install the
Dektop tasks, tasksel/first must be preseeded with Environnement
graphique de bureau and not Desktop environment.
No, debconf is designed so that choices values are always in English.
Here is a (not fully tested) patch to build a rightfully localized
choices list. It can surely be improved, but the main point is to
build 2 lists (in English and another language) and perform 2 different
substitutions so that Choices and Choices-xx fields are expanded as if
they had been computed at build time by po2debconf.
Denis
Index: tasksel.pl
===
--- tasksel.pl (revision 816)
+++ tasksel.pl (working copy)
@@ -64,7 +64,8 @@
}
if (%data) {
$data{relevance}=5 unless exists $data{relevance};
- $data{shortdesc}=dgettext(debian-tasks,
$data{description}-[0]);
+ $data{shortdesc}=$data{description}-[0];
+ $data{shortdesctrans}=dgettext(debian-tasks,
$data{shortdesc});
push @ret, \%data;
}
}
@@ -252,8 +253,9 @@
# Converts a list of tasks into a debconf list of their short descriptions.
sub task_to_debconf {
+ my $field = shift;
join , , map {
- my $desc=$_-{shortdesc};
+ my $desc=$_-{$field};
if ($desc=~/, /) {
warning(task .$_-{task}. contains a comma in its short
description: \$desc\);
}
@@ -415,8 +417,10 @@
my @default = grep { $_-{_display} == 1 ($_-{_install} == 1 ||
$_-{_installed} == 1) } @tasks;
my $tmpfile=`tempfile`;
chomp $tmpfile;
- system($debconf_helper, $tmpfile, task_to_debconf(@list),
- task_to_debconf(@default),
+ system($debconf_helper, $tmpfile,
+ task_to_debconf(shortdesc, @list),
+ task_to_debconf(shortdesctrans, @list),
+ task_to_debconf(shortdesc, @default),
$question);
open(IN, $tmpfile);
my $ret=IN;
Index: debian/rules
===
--- debian/rules(revision 816)
+++ debian/rules(working copy)
@@ -51,6 +51,7 @@
dh_strip
dh_compress
dh_installdebconf
+ perl -pi -e 's/^Choices: \$${CHOICES}/Choices: \$${ORIGCHOICES}/'
debian/tasksel/DEBIAN/templates
dh_fixperms
dh_installdeb
dh_shlibdeps
Index: tasksel-debconf
===
--- tasksel-debconf (revision 816)
+++ tasksel-debconf (working copy)
@@ -5,11 +5,13 @@
tmpfile=$1
choices=$2
-defaults=$3
-question=$4
+choicestrans=$3
+defaults=$4
+question=$5
db_settitle tasksel/title
-db_subst $question CHOICES $choices
+db_subst $question ORIGCHOICES $choices
+db_subst $question CHOICES $choicestrans
# Allow tasksel/first to be preseeded. If it's marked as seen, then
# it must have been preseeded, and that overrides any defaults set by
Bug#276752: (no subject)
Eugeniy Meshcheryakov wrote: No. console-cyrillic is only used after reboot after second stage. It is installed by tasksel. I am not sure that charset lines are needed in keymap files - there is no symbolic names in files. And keymaps are in koi8-u and utf-8 not in iso-8859-5! This charset line (with the right charset, ie. koi8-u) is needed if you want to be able to load the same keymap both with koi8-u and UTF-8 encodings. The charset declaration tells console-tools how to perform conversions between Unicode codepoints, symbolic names and legacy encodings values. This is convenient on an installed system because keymaps does not have to be duplicated, but a charset line has to be declared. Recai spotted another problem in this bugreport, do you know if your keymap works fine after first reboot? -- Denis
Bug#276752: Urgent patch for kbd-chooser
Selon Eugeniy Meshcheryakov [EMAIL PROTECTED]: 19.10.2004 о 12:28 +0200 Denis Barbier написав: Eugeniy Meshcheryakov wrote: No. console-cyrillic is only used after reboot after second stage. It is installed by tasksel. I am not sure that charset lines are needed in keymap files - there is no symbolic names in files. And keymaps are in koi8-u and utf-8 not in iso-8859-5! This charset line (with the right charset, ie. koi8-u) is needed if you want to be able to load the same keymap both with koi8-u and UTF-8 encodings. If so, lines 'charset koi8-u' should be added to ua.kmap, ua-ws.kmap and uaw.kmap. Other Ukrainian keymaps are in UTF-8. If d-i works fine with Ukrainian keymaps, please do not change anything, these changes will take place after sarge. -- Denis
Bug#276752: Urgent patch for kbd-chooser
On Mon, Oct 18, 2004 at 08:48:57PM +0300, Recai Oktas wrote: [...] * The workaround I proposed should not affect the languages using iso-8859-1/15 and utf-8, because this workaround means to return temporarily back to the old behaviour (the one before applying the patch to fix the keyboard freezes). Nevertheless we should perform a test. Hence I CC'ed this mail to Christian (iso-8859-1/15) and Konstantinos (utf-8). Could you check the French and Greek keyboards _after the installation_ by first applying the patch attached to the /usr/lib/prebaseconfig.d/70kbd-chooser in d-i phase? Recai, the question is not to have a simple fix, but to make sure things are not broken. I agree that your patch does the right thing (except for UTF-8, I believe that it should not be applied then but did not make tests), but it is too invasive. Your initial patch looked much less dangerous, it had to be extended to few other countries, and that's all. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276752: Urgent patch for kbd-chooser
On Tue, Oct 19, 2004 at 12:45:36AM +0300, Recai Oktas wrote: * Alastair McKinstry [2004-10-18 22:37:21+0100] On Luan, 2004-10-18 at 23:41 +0300, Recai Oktas wrote: Small rearrangement of the patch. Tested successfully for Turkish and this time Latvian under Vmware. Sorry for my aesthetics obsessions :-) Patch looks good to me; Should work with Lithuanian, which was broke due to #275087, just fixed in console-data SVN. I've just submitted a grave bug report for the missing Lithuanian keymap without looking the bug database. Sorry for the duplication. BTW, I've tested Lithuanian a few minutes ago with this patch and it also passed the test. Now, all the keymaps suffered from the #276752 should now work. Hope I haven't missed any other keymap. There may be problems with Ukrainian, I do not remember if they use console-tools or console-cyrillic. IMO adding charset iso-8859-5 at the beginning of ua-*.kmap.gz files could help (untested). Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#276076: console-tools: Unable to see Hebrew in the console
reassign 276076 languagechooser thanks On Mon, Oct 11, 2004 at 11:47:25PM +0200, Lior Kaplan wrote: When using the he_IL encoding I can't see Hebrew chars in the console. Please set the default to /LatArCyrHeb-16.psf.gz and acm to iso08. I wish to get the same result as: consolechars -f LatArCyrHeb-16.psf.gz -m iso08 On Tue, Oct 12, 2004 at 08:32:21AM +0200, Denis Barbier wrote: On Tue, Oct 12, 2004 at 01:16:43AM +0200, Lior Kaplan wrote: Since that wouldn't solve the problem to other people. Especially people new to Debian which use d-i for the first installation. Then packages/languagechooser/languagelist has to be fixed, Hebrew;he_IL;he_IL;he;IL;he_IL:he:en_GB:en;kbd=LatArCyrHeb-16(iso08) might work (untested). Reassigning to languagechooser so that someone can take care of this change. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New d-i translation scheme, who is a D-i i18n coordinator?
On Sun, Aug 29, 2004 at 08:39:54AM +0200, Christian Perrier wrote: [...] The single file system for translations is currently mostly used by translators who work alone (except French, which is currently often used as a test lab for new work methods for teams). This single file system can hardly be seen as a work methods for teams, there is a single responsable for the PO file and proofreaders' work is much harder. This is the wrong way, large files are usually split into small pieces in order to be managed by several persons (like the installation manual). Most drawbacks against the old scheme were already fixed by http://lists.debian.org/debian-boot/2004/03/msg05834.html Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Future of console-tools (was Re: Why isn't console-cyrillic part of console-data?)
[Alastair McKinstry]
As there appears to be little interest in console-{tools,data}
development upstream, I'm working towards merging stuff back
to kbd.
FYI I am currently discussing with kbd maintainer and will
surely take it over very soon, but I will give it away if
you want to maintain it after sarge.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250789: Please fix this bug!
On Sat, Jul 24, 2004 at 07:46:51PM +0300, Recai Oktas wrote: [...] The only think we need termwrap for then is to wrap a UTF-8 frame buffer terminal around base-config for the languages with more then 512 glyphs. Agreed. Only the asian consoles should be treated differently. Agreed too. I suggest we patch languagechooser to update /etc/locale.gen and /etc/environment to set the default locale, and remove the locale generating code from termwrap. I also suggest we teach termwarp to look in the data file for console-tool (is this /etc/console-tool/config? The variables seem to be SCREEN_FONT and SCREEN_FONT_MAP), and tell it to use these values if available as the default instead of ISO-8859-1. This way the termwrap tool is still a generic wrapper to run programs with correct console font and locale, while the locale generating is moved to a more sensible place. No, instead of SCREEN_FONT_MAP, we should use APP_CHARSET_MAP (hence acm) which has already been changed in languagechooser. I do not follow you here, you state above that termwrap is not needed with console-tools. As base-config is run after reboot, console has then been configured, parsing /etc/console-tools/config is useless. If termwrap is needed outside of d-i, I suggest to have a minimal termwrap-di to deal with Asian locales, and nothing more. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final patch
[Cc-list trimmed down]
On Mon, Jul 05, 2004 at 10:16:30AM +0300, Recai Oktas wrote:
[...]
In fact there is no need for kbd-mode, kbd-chooser (or any other program
run early) should call ioctl to set keyboard in Unicode mode.
I added the kbd-mode because an early ioctl call in loadkeys_wrapper to
switch to unicode mode simply didn't work (still don't know why),
[...]
This is indeed very strange. Anyway having such a program might be
useful, packages/rootskel/src/lib/debian-installer.d/S[49]0utf8-linux
will then look very similar to unicode_st{art,op}. But kbd-mode should
be renamed to kbd_mode.
About unicode_start, didn't you file a bugreport weeks ago to request that
calls to kbd_mode and dumpkeys are swapped in this script? I cannot
find it.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final patch
On Sun, Jul 04, 2004 at 12:13:10PM +0300, Recai Oktas wrote:
Hi,
After getting success reports from Christian (French keyboard) and
Eugeniy (Ukrainian keyboard), I prepared a single patch which applies
cleanly to the current kbd-chooser. (This patch includes some minor
code cleanups. I've re-tested it here with the French, Ukrainian and
Turkish keymaps. Everything seems fine. [1]) Here is the changelog:
* Denis Barbier
- Make kbd-chooser work with keymaps containing unicode chars.
* Recai Oktas
- Set console mode to unicode. Closes: #251550.
- Prevent too many file descriptors referring to the console.
Could you apply the patch?
In fact there is no need for kbd-mode, kbd-chooser (or any other program
run early) should call ioctl to set keyboard in Unicode mode.
I did not notice that getfd() opens a new file descriptor each time it
is called, but this can be solved without changing current prototypes,
e.g. this (untested) patch should do the trick.
Denis
Index: packages/kbd-chooser/getfd.c
===
--- packages/kbd-chooser/getfd.c(revision 17443)
+++ packages/kbd-chooser/getfd.c(working copy)
@@ -45,7 +45,9 @@
}
int getfd() {
-int fd;
+static int fd = -1;
+if (fd = 0)
+ return fd;
fd = open_a_console(/dev/tty);
if (fd = 0)
Bug#256954: frees wrong memory
On Wed, Jun 30, 2004 at 05:42:33PM -0700, Matt Kraai wrote: [...] With the patch I submitted, if the item that is removed is not at the end of the list, the pointer to it will be changed to point to the item after it and it will then be deleted. Would you please explain why this won't work? I was wrong, sorry. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (forw) Bug#251550 acknowledged by developer
[Eugeniy Meshcheryakov]
This breaks keyboard handling: unicode keymaps (ua-utf,
consoel-cyrillic unicode keymaps) does not work (I can enter only
ASCII symbols).
My bad, here is a patch (it was tested against my patched kbd, and
should work as well against console-tools).
Denis
--- src/ksyms.c 2004-06-27 21:39:36.0 +0200
+++ src/ksyms.c 2004-07-01 22:05:37.0 +0200
@@ -1801,8 +1801,8 @@
return code;
ioctl(getfd(NULL), KDGKBMODE, kbd_mode);
if (kbd_mode == K_UNICODE KTYP(code) = syms_size) {
- if (KVAL(code ^ 0xf000) 0x80)
- return K(KT_LATIN, KVAL(code ^ 0xf000));
+ if ((code ^ 0xf000) 0x80)
+ return K(KT_LATIN, code ^ 0xf000);
else
return code;
}
Bug#257180: loses default answer to unseen question if it is fset seen
On Thu, Jul 01, 2004 at 02:49:23PM -0400, Joey Hess wrote:
After the fset, cdebconf incorrectly makes the stanza for this
question in config.dat have an empty value, like this:
Name: hw-detect/start_pcmcia
Template: hw-detect/start_pcmcia
Value:
Owners: d-i
Flags: seen
This plays havoc with stuff that expects to get a true/false from a
boolean. In this particular example, it utterly breaks pcmcia restarting
in d-i. It's out of spec for a boolean to have a value that is not true
or false.
The correct thing to do in this case is to either copy the Value from
the template, or not put in a Value field when the value is not set, and
inherit from the template still. debconf does the latter, which cdebconf
should do depends on its internal design, I suppose.
Here is a patch (untested).
Denis
Index: packages/cdebconf/src/modules/db/rfc822db/rfc822db.c
===
--- packages/cdebconf/src/modules/db/rfc822db/rfc822db.c(revision 17355)
+++ packages/cdebconf/src/modules/db/rfc822db/rfc822db.c(working copy)
@@ -438,8 +438,8 @@
INFO(INFO_VERBOSE, dumping question %s\n, (q)-tag);
fprintf(outf, Name: %s\n, escapestr((q)-tag));
fprintf(outf, Template: %s\n, escapestr((q)-template-tag));
-if (((q)-flags DC_QFLAG_SEEN) || (q)-value)
-fprintf(outf, Value: %s\n, ((q)-value ? escapestr((q)-value) : ));
+if ((q)-value)
+fprintf(outf, Value: %s\n, escapestr((q)-value));
if ((owner = (q)-owners))
{
Bug#256954: frees wrong memory
On Tue, Jun 29, 2004 at 09:38:13PM -0700, Matt Kraai wrote:
[...]
I think the read fails because the other end of the pipe closes
because cdebconf crashes because of a bug in
question_owner_delete: if the owner that it is trying to delete is
not last one in the list, it frees the owner field.
The attached, untested patch should fix it, but I'd appreciate a
review.
It seems that the question_owner_delete routine is intended to remove
an entry from a single chained list. AFAICT the current implementation
as well as your patch do not preserve links when the removed item is
not in list tail. Here is another patch, not tested.
Denis
Index: packages/cdebconf/src/question.c
===
--- packages/cdebconf/src/question.c(revision 17355)
+++ packages/cdebconf/src/question.c(working copy)
@@ -122,25 +122,22 @@
void question_owner_delete(struct question *q, const char *owner)
{
- struct questionowner **ownerp, *nextp;
+ struct questionowner *ownerp, *nextp, *prevp = NULL;
- for (ownerp = q-owners; *ownerp != 0; ownerp = (*ownerp)-next)
+ for (ownerp = q-owners; ownerp != NULL; ownerp = nextp)
{
- if (strcmp((*ownerp)-owner, owner) == 0)
+ nextp = ownerp-next;
+ if (strcmp(ownerp-owner, owner) == 0)
{
- nextp = (*ownerp)-next;
- if (nextp == 0)
- {
- nextp = *ownerp;
- *ownerp = 0;
- }
+ if (prevp != NULL)
+ prevp-next = nextp;
else
- {
- **ownerp = *nextp;
- }
- DELETE(nextp-owner);
- DELETE(nextp);
+ q-owners = nextp;
+ DELETE(ownerp-owner);
+ DELETE(ownerp);
}
+ else
+ prevp = ownerp;
}
}
Bug#251550: Keyboard freezes when typing non-ASCII letters
[Christian Perrier]
So, this bug should finally be assigned to console-data with the
request for creating Unicode keymaps for layouts which don't have
one (Recai mentions Turkish for instance)?
This is a solution. IMO a better one is to patch loadkeys as explained
in my previous post. Here is a first try, I patched kbd 1.12 instead
of console-tools because I do not know dpatch. Keymap files must
declare a charset so that conversion between Unicode, literal and
decimal notations can be performed.
What about kbd? You mentioned me in another mail this supposedly more
recent system for handling keyboard layouts
Not exactly, Turkish keymaps are better in console-data than in kbd,
but others are better in kbd. As I said months ago, I do not see the
point in maintaining console-tools when it is dead upstream, and am
quite upset to see that fr-latin0 was chosen as default for French
when it is obsolete and has been removed from kbd.
Should we start to build a fr-latin0u keyboard, german people a
Unicode german keyboard layout and so on?
It depends whether Alastair is willing to patch loadkeys or not.
Or could a switch to another keyboard handling system help?
No, kbd and console-tools are mostly similar, and kbd has the same
problem,
Denis
diff -ur kbd-1.12.orig/src/analyze.l kbd-1.12/src/analyze.l
--- kbd-1.12.orig/src/analyze.l 2004-01-16 22:51:44.0 +0100
+++ kbd-1.12/src/analyze.l 2004-06-24 21:28:14.0 +0200
@@ -77,7 +77,7 @@
\- {return(DASH);}
\, {return(COMMA);}
\+ {return(PLUS);}
-{Unicode} {yylval=strtol(yytext+1,NULL,16);return(UNUMBER);}
+{Unicode} {yylval=strtol(yytext+1,NULL,16) ^ 0xf000;return(UNUMBER);}
{Decimal}|{Octal}|{Hex}{yylval=strtol(yytext,NULL,0);return(NUMBER);}
RVALUE{Literal} {return((yylval=ksymtocode(yytext))==-1?ERROR:LITERAL);}
{Charset} {return(CHARSET);}
diff -ur kbd-1.12.orig/src/dumpkeys.c kbd-1.12/src/dumpkeys.c
--- kbd-1.12.orig/src/dumpkeys.c2004-01-16 20:45:31.0 +0100
+++ kbd-1.12/src/dumpkeys.c 2004-06-24 23:50:48.0 +0200
@@ -131,11 +131,10 @@
t = KTYP(code);
v = KVAL(code);
if (t = syms_size) {
- code = code ^ 0xf000;
- if (!numeric (p = unicodetoksym(code)) != NULL)
+ if (!numeric (p = codetoksym(code)) != NULL)
printf(%-16s, p);
else
- printf(U+%04x , code);
+ printf(U+%04x , code ^ 0xf000);
return;
}
if (t == KT_LETTER) {
diff -ur kbd-1.12.orig/src/ksyms.c kbd-1.12/src/ksyms.c
--- kbd-1.12.orig/src/ksyms.c 2004-01-16 20:45:31.0 +0100
+++ kbd-1.12/src/ksyms.c2004-06-25 01:14:42.0 +0200
@@ -1,7 +1,9 @@
+#include linux/kd.h
#include linux/keyboard.h
#include stdio.h
#include string.h
#include ksyms.h
+#include getfd.h
#include nls.h
/* Keysyms whose KTYP is KT_LATIN or KT_LETTER and whose KVAL is 0..127. */
@@ -1615,9 +1617,6 @@
/* Functions for both dumpkeys and loadkeys. */
-static int prefer_unicode = 0;
-static const char *chosen_charset = NULL;
-
void
list_charsets(FILE *f) {
int i,j,lth,ct;
@@ -1655,10 +1654,8 @@
sym *p;
int i;
- if (!strcasecmp(charset, unicode)) {
- prefer_unicode = 1;
+ if (!strcasecmp(charset, unicode))
return 0;
- }
for (i = 0; i sizeof(charsets)/sizeof(charsets[0]); i++) {
if (!strcasecmp(charsets[i].charset, charset)) {
@@ -1667,7 +1664,6 @@
if(p-name[0])
syms[0].table[i] = p-name;
}
- chosen_charset = charset;
return 0;
}
}
@@ -1677,10 +1673,15 @@
}
const char *
-unicodetoksym(int code) {
+codetoksym(int code) {
int i, j;
sym *p;
+ if (KTYP(code) == KT_META)
+ return NULL;
+ if (KTYP(code) syms_size)
+ return syms[KTYP(code)].table[KVAL(code)];
+ code = code ^ 0xf000;
if (code 0)
return NULL;
if (code 0x80)
@@ -1697,49 +1698,60 @@
/* Functions for loadkeys. */
-int unicode_used = 0;
-
int
ksymtocode(const char *s) {
int i;
- int j, jmax;
+ int j;
int keycode;
+ int fd;
+ int kbd_mode;
+ int syms_start = 0;
sym *p;
+ if (!s) {
+ fprintf(stderr, %s\n, _(null symbol found));
+ return -1;
+ }
+
+ fd = getfd(NULL);
+ ioctl(fd, KDGKBMODE, kbd_mode);
if (!strncmp(s, Meta_, 5)) {
+ /* Temporarily change kbd_mode to ensure that keycode is
+ right. */
+ ioctl(fd, KDSKBMODE, K_XLATE);
Bug#251550: Keyboard freezes when typing non-ASCII letters (was Re: Bug#251550: Bug#254630: LVM names)
On Sun, Jun 20, 2004 at 08:25:06AM +0200, Christian Perrier wrote: Quoting Eugeniy Meshcheryakov ([EMAIL PROTECTED]): Christian Perrier wrote: Currently unusable in cdebconf (seems to be a whiptail bug in Unicode environments). Just try to enter any non ASCII character in a dialog box..:-( #251550 I can enter cyrillic characters (that are not ASCII) used in Ukrainian in d-i. This looks more like problem with keymap files. H, so nothing to do with whiptail, then? I'm puzzled. Let's ask Alastair, he will maybe have some ideas Alastair, could you have a look at #251550? Basically, you just enter a non ASCII character in a dialog during Debian Installer 1st stage (when installing in French, German...and probably even English), for instance in the dialog asking for a host name or IP address. Then the display seems frozen : typing anything just does nothing. You have to hit Ctrl-A for having it working again. This is a serious problem because any input of such high ASCII character will freeze the installer, from the user point of view. This looks somewhat similar to 243373, output was truncated when illegal UTF-8 sequences were printed. Here input is broken when keyboard sends illegal UTF-8 sequences. Of course keyboard should send valid UTF-8 sequences, so one cannot blame whiptail too much. According to kbd_mode(1) Linux console keyboard driver has 4 modes, two of them are of interest for us, namely ASCII and UTF-8 modes. Internally Linux kernel uses Unicode; in UTF-8 mode, there is no conversion, characters are passed to the kernel (there seems to be a UTF-16 - UTF-8 conversion, but it can be ignored). In ASCII mode, characters are converted to Unicode by using the charset found when loadkeys was invoked. On the other hand keymaps(5) explains how to write keymap files. Characters can be defined numerically (decimal or octal value), litterally (e.g. eacute) or with their Unicode codepoints (eg. U+00E9). When loadkeys parses keymap files, numerical and litteral values are converted to 0-255 values (according to a charset) whereas Unicode values are stored as complement to 0xf000. A value is then (roughly) decoded by: * if value = 0x0c00, this is a Unicode character: value ^ 0xf000 * otherwise this character had a numerical or litteral notation, and its value in the current charset is the last significant byte. For reasons I do not understand, these 2 conversions (keyboard mode and input parsing) are mixed. Now consider this line from fr-latin1: keycode 3 = eacute two dead_tilde $ kbd_mode -a $ export LANG=fr_FR $ dumpkeys -n ... keycode 3 = 0x00e9 0x0032 0x0403 0x ... $ export LANG=fr_FR.UTF-8 $ unicode_start $ dumpkeys -n ... keycode 3 = 0x00e9 0x0032 0x0403 0x ... But now keyboard is in UTF-8 mode, so bytes are passed to the kernel without conversion, and 0x00 0xe9 is sent instead of its UTF-8 representation 0xc3 0xa9. If eacute is replaced by its Unicode notation U+00E9 in keymap file, everything works fine now. But this keymap cannot be used when keyboard is in ASCII mode, The only solution is to have two keymaps, one for ASCII mode and the other one for UTF-8 mode. This looks pretty crazy, loadkeys should automatically convert from numerical/litteral value to Unicode notation (and vice versa) depending on current keyboard mode. Denis
Re: (forw) Re: @euro support with new languagechooser (was: dropping tc1)
On Mon, Jun 21, 2004 at 05:46:25PM +0200, Christian Perrier wrote: (I announced a CC and forgot to really do it) - Forwarded message from Christian Perrier [EMAIL PROTECTED] - Date: Mon, 21 Jun 2004 17:45:21 +0200 From: Christian Perrier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: @euro support with new languagechooser (was: dropping tc1) Quoting Steve Langasek ([EMAIL PROTECTED]): (comparing fr_FR and [EMAIL PROTECTED] more generally all @euro variants of locales) So there's no difference in the actual charset that each is pointed to, the only difference is in a comment about the charset? Yes, as far as I understand. [EMAIL PROTECTED] only uses copy fr_FR everywhere But generated locales differ because different encodings are passed to localedef: $ LANG=fr_FR locale charmap ISO-8859-1 $ [EMAIL PROTECTED] locale charmap ISO-8859-15 Steve mentions in another message that switching fr_FR encoding to ISO-8859-15 cannot be done without discussion, but glibc upstream has a definitive position: encodings are never changed, period. (It recently surfaces again about et_EE) So this discussion is over before it begins ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorted debconf lists (was Re: r14631 - in trunk/packages/countrychooser: . debian)
On Tue, May 04, 2004 at 11:38:10PM +0200, Denis Barbier wrote: [...] I am testing the attached patch to sort short country list in countrychooser. It can be adapted to choose-mirror, but its drawback is that generation of many locales may take some time on autobuilders (which is not a problem with countrychooser which needs fewer locales and is Arch: all). Here is a sample script to show how choose-mirror could display sorted translated country names. This script has to be called after debian/choose-mirror/DEBIAN/templates has been built, it patches this file by adding some Indices-XX.UTF-8 lines, which tell cdebconf how to sort these lists. It is not finished yet (see the final comment) but the last bit is quite easy to implement. I won't be able to work on Debian stuff for several weeks, and so cannot finalize this script myself. The Bosnian translation is not sorted because this language has no UTF-8 variant defined in /usr/share/i18n/SUPPORTED, a bugreport against the locales package should be filed to add it. Denis sort-countries.sh Description: Bourne shell script
Re: [l10n] 1st-stage status page moving and pcmcia-cs
On Wed, May 19, 2004 at 11:44:27PM +0200, Dennis Stampfer wrote: Hey translators, 1st-stage translation status pages moved to http://people.debian.org/~seppy/d-i/1st-stage/ (updated every 4h) The old pages at http://people.debian.org/~barbier/d-i/l10n/ will stop in about 10 days. Please update your bookmarks/scripts. I was just told, that pcmcia-cs is now developed in SVN: svn co svn://svn.debian.org/pkg-pcmcia-cs/pcmcia-cs/trunk pcmcia-cs 2nd-stage status already uses SVN. Hi Dennis, I stopped all my cron jobs on gluck, thanks for taking care of these stats. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] anon svn templates
On Mon, May 17, 2004 at 12:30:20AM +0200, Nikolai Prokoschenko wrote: Hello! What's up with the repositories? I check out my templates co. from the normal svn with my alioth account and I get old templates - for example, base-installer's template is dated POT-Creation-Date: 2004-05-04 23:35-0400\n, whereas the one Denis Barbier has on his page is from 16th May. I assume he's using the anonymous SVN, so where's the difference between the two? Have there been any changes I've missed? This is explained in the listing output: Example: * debian-installer/tools/lilo-installer: 2t1f7u [Foo Bar] debian-installer/tools/netcfg: 9t19f33u [Foo Bar] ! debian-installer/tools/partconf: Invalid PO file On the first line, an asterisk tells that the file in the SVN repository is outdated, debconf-updatepo must be run first. Debconf-updatepo is run on the PO files on my pages, which is why they differ from pristine svn. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New languagechooser
On Sat, May 15, 2004 at 07:08:12AM +0200, Christian Perrier wrote: [...] I'm working on a Default=English with no locales entry in languagechooser which would skip the countrychooser step by leading to C values in debian-installer/language and debian-installer/locale and US in debian-installer/country. This entry could possibly be used as a general all defaults entry (keyboard=US for instance). This is nearly ready, I just need to sort out a minor glitch. BTW how will the @euro modifier be added for EU countries? Note also that el_GR.UTF-8 id the preferred locale for Greek. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249119: netcfg: A way to mark templates as unused would be nice
On Sat, May 15, 2004 at 12:17:47AM -0700, Joshua Kwan wrote: Package: netcfg Severity: wishlist Sometimes I wish to remove a template from my master templates file because it is no longer used or currently has no purpose. If I reconsider and add it back, this is no problem if the template is not translated at all. However, especially in the case of d-i, I do not want to lose the myriad translations that have been made to a given template, yet it is important to not have excess unused templates in udebs where space is at a premium. Therefore a method of marking templates as disabled or unused so that they are not included in the compiled templates file would allow one to save translations instead of having to delete them. This then saves space in the compiled deb. The flip side is that this probably would allow for a lot of bitrot to occur in source packages. When a msgid is no more used, it is commented in PO files. So unless translators or maintainers delete those commented translations manually (or via an evil tool), they will be back automatically if strings are added again. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: en is not a valid locale, but is added to locale.gen
On Thu, May 13, 2004 at 10:48:06PM -0700, Debian Bug Tracking System wrote: - Move the /etc/environment LANG code out of termwrap where it does not belong, have base-config only do it on new installs. Can you please explain what termwrap is for? I thought that base-config could be also run on an installed system, and termwrap is run only when performing a new installation, so I do not understand your comment above. FYI since console is now configured by languagechooser for ISO-8859-* and KOI8-* encodings, I am going to remove those try_load_charset from termwrap. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bosnian language
On Tue, May 11, 2004 at 02:04:46PM +0200, Safir Secerovic Linux Zagor wrote: What is the fuss about all this. Bosnian is the native language spoken in Bosnia and Herzegovina by those people who consider themselves Bosnians. It is officially recognized spoken language in the world!!! [...] Do you realize that your complaint is absolutely clueless? If something went wrong, please tell us so that it can get fixed. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Changes to languagechooser
On Mon, May 10, 2004 at 07:26:49AM +0200, Christian Perrier wrote: Following some sub-threads of the giant crossposted thread in -devel and -boot about the Taiwan issue, I made some changes to languagechooser. These changes are not related to the Taiwan issue, they are driven by some remarks several people made when the method currently used for choosing language/country is described. I am glad to see that you did not strictly follow ISO 639 for language names ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248206: BETA4 beginner installation
On Mon, May 10, 2004 at 08:15:29AM +0200, Christian Perrier wrote: Umlauts were not correctly displayed at the beginning when choosing the keyboard and he was confused by Tottasten. Those Tottasten/deadkeys are still confusing people. I don't know how we can solve this. Maybe add a note? This umlaute problem comes from inconsistency between console-data and kbd-chooser translations encodings. Currently, in both copies in SVN, the de.po file uses UTF-8 and is really UTF-8. So, the problem should go away with further releases This problem does not come from PO files, encoding does not matter as long as generated templates files are UTF-8 encoded. Here is a patch against console-data to fix German umlauts. Denis Index: debian/po/de.po === --- debian/po/de.po (revision 1) +++ debian/po/de.po (working copy) @@ -355,7 +355,7 @@ #: ../console-keymaps-atari.templates:4 ../console-keymaps-mac.templates:4 #: ../console-keymaps-sun.templates:4 ../console-keymaps-dec.templates:4 msgid Keymap to use: -msgstr WÀhlen Sie das Tastaturlayout fÃŒr die Tastatur aus: +msgstr Wählen Sie das Tastaturlayout für die Tastatur aus: #. Type: select #. choices
Re: Resignation
On Wed, May 05, 2004 at 08:07:55AM +1000, Herbert Xu wrote: So be it. Free software extremists I can live with. But this is too much. I will resign from this project in two weeks time. In the mean, please send me offers to maintain my packages in *private*. Any packages which are not claimed for in two weeks time will be orphaned and th usual rules shall apply. I proposed some changes to countrychooser before this discussion was moved to debian-devel and made an unofficial branch to seek for comments; a PO file is temporarily available at http://people.debian.org/~barbier/tmp/zh_CN.po Please tell us whether these strings are acceptable from your point of view, and if not which changes you would like to see. If you insist on leaving, I can not stop you. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anonymous access to the svn repository disabled
On Sun, May 09, 2004 at 09:48:14AM +0200, Bastian Blank wrote: [...] I do that to reduce the load on the repository, so please don't do that. Use a copy of the repository. Where is it? I found nothing suitable under http://d-i.alioth.debian.org/ Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation
On Fri, May 07, 2004 at 07:29:55AM +0200, Christian Perrier wrote: Quoting Denis Barbier ([EMAIL PROTECTED]): This is plain wrong, my opinion is that we do not have to get stuck to This is not plain wrong, Denis. This is a proof that we disagree..:-) You wrote in your previous mail: CP Finding an internationnaly recognised standard for these highly CP sensitive topics such as country names is *very* difficult. Up to now, CP I'm still convinced that the less bad list is iso-3166 (Denis Barbier CP proposal is also the use of iso-3166 as ICU codes are officially CP announced to use iso-3166). I feel enough qualified to tell that my proposal does not promote the use of ISO 3166, any list can be used instead if it better fits countrychooser needs. By the way, this is also a proof that though we disagree we appreciate each other's work anyway. a standard; maintainers are solely responsible to their packages, and if some people dislike these choices, they can fork it. So, if I hear you properly, you suggest that anyone disliking the current way Debian Installer deals with these issues forks its own version of d-i? Sure, how do you want to prevent that? But there is another option: one might also only fork countrychooser ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anonymous access to the svn repository disabled
On Fri, May 07, 2004 at 04:16:01PM +0200, Peter Mann wrote: On Fri, May 07, 2004 at 03:09:03PM +0200, Bastian Blank wrote: I removed the www-data acl from the svn repository db and effectively completely disabled anonymous access. At least 50 svnserve processes with owner www-data stucks in the lock and blocks any access to the repository. but stats are broken now: http://people.debian.org/~barbier/d-i/l10n/ Just fixed thanks to Joey's server. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation
On Thu, May 06, 2004 at 07:38:22AM +0200, Christian Perrier wrote: [...] Finding an internationnaly recognised standard for these highly sensitive topics such as country names is *very* difficult. Up to now, I'm still convinced that the less bad list is iso-3166 (Denis Barbier proposal is also the use of iso-3166 as ICU codes are officially announced to use iso-3166). This is plain wrong, my opinion is that we do not have to get stuck to a standard; maintainers are solely responsible to their packages, and if some people dislike these choices, they can fork it. So in my modified version of countrychooser, I gathered English names from ISO 3166, ICU or other sources, and did the same for the French translation. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243373: Processed: tags
On Tue, May 04, 2004 at 10:13:59PM +0100, Alastair McKinstry wrote: [...] Oops. That should be cdebconf-text-udeb. The fix is in two parts: (1) Fix partman to not print 0xa0 but UTF-8 version (2) Fix cdebconf-text-udeb to not print UTF-8 chars in non-UTF8 locales. The idea is that NBSP can be used in the debconf templates, but won't get printed on ASCII-only terminals, and to ensure that by translating non-ASCII chars to spaces. Okay, thanks for your explanations. I agree that this is a nice fix, but patching cdebconf-text-udeb does not seem trivial :( Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Definition of COUNTRY (Was: Resignation)
On Thu, May 06, 2004 at 03:44:12PM -0700, William Ballard wrote: On Thu, May 06, 2004 at 05:34:41PM -0500, Steve Langasek wrote: On Thu, May 06, 2004 at 11:03:29AM -0700, William Ballard wrote: How nutty would it be to have *both* options available and some sort of switch to Toggle between the two? Or at least a patchset or something. Very. Thanks for playing. Why? You're never going to make China happy by calling it Taiwan, or Taiwan happy by calling it Taiwan, Province of China. So use the same code zh_TW and let people call the display name whatever the hell they want to call it. http://www-306.ibm.com/software/globalization/topics/writing/references.jsp Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experimental countrychooser branch
[Sent to debian-boot only] On Mon, May 03, 2004 at 07:05:38AM +0200, Christian Perrier wrote: Quoting Denis Barbier ([EMAIL PROTECTED]): I made a branch to test some changes in countrychooser: svn+ssh://svn.debian.org/svn/d-i/people/barbier/countrychooser or svn://svn.debian.org/d-i/people/barbier/countrychooser The main goal is to get rid of iso-codes for English country names, and replace them by those found in ICU, which are much more neutral. I have already explained why I do not support this choice. ICU claim they use ISO-3166 AND ONLY IT as a reference.though they do not for TW *without explaining why*. So, I do not see it as more or less neutral than ISO-3166, but just less strict. No, as it was already mentioned, they claim using ISO 3166 *country codes*. The TW issue is becoming slowly a non issue as ways of translating the one and only name which is controversial in iso-3166 list arises. It is also an issue in French since we (well, you) are bound to official French names. The letter to ISO-3166 secretary will be soon sent as soon as I get approval from DPL. Depending on the answer we get, we may decide whether we deliberately choose to deviate from the standard for this very particular topic. It has already been answered here, Taiwanese government tells that ISO-3166 is using United Nations's official names and won't change them. But, if we do deviate, WE WILL EXPLAIN WHY.and do not do it silently just like ICU does. And because this will be a deviation from an accepted standard this will be validated by our Technical Comittee. I fail to see wy this is needed. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229325: Experimental countrychooser branch (was Re: Bug#229325: One msg still not fixed in beta4)
On Sat, May 01, 2004 at 08:57:34AM +0200, Christian Perrier wrote: Quoting Wang WenRui ([EMAIL PROTECTED]): Hi, There are two phrases choose country in the countrychooser need to be fixed(changed to Choose a country, territory or area). While only one of them is fixed in beta4. The left one is the main menu entry: #. Type: string #. Description #. Main menu entry #: ../templates-in:39 msgid Choose country msgstr Choisir le pays Please fixed that. Thanks. No, we won't. Menu entries need to be short. The possible size for menu entries is 54 characters, in ALL LANGUAGES. While using Choose a country, territory or area would fit in English, this would add an unnecessary verbosity to the main menu, which needs to be concise and clear. I made a branch to test some changes in countrychooser: svn+ssh://svn.debian.org/svn/d-i/people/barbier/countrychooser or svn://svn.debian.org/d-i/people/barbier/countrychooser The main goal is to get rid of iso-codes for English country names, and replace them by those found in ICU, which are much more neutral. Translations have not been fuzzied (but I could not refrain myself from editing fr.po). Only countries/regions part of a locale in /usr/share/i18n/SUPPORTED or which can be selected in choose-mirror are listed, which makes debian/templates half-size. The requested change in menu item has also been performed so that anyone can test if this is too verbose. I only checked that debian/templates is generated without trouble, latest stuff about short country list may break this package, I will test it tomorrow. When writing comments inrelated to this bugreport, please send them to [EMAIL PROTECTED] Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i10n] Installation Manual Updates
On Mon, May 03, 2004 at 01:02:24AM -0400, David Nusinow wrote: On Mon, May 03, 2004 at 06:46:06AM +0200, Giuseppe Sacco wrote: the Italian translation is about to be started, so it would be perfect if you send an email to [EMAIL PROTECTED] when you complete a chapter. Do you already have a list of chapters that you will not change at all? That's great to hear. I actually plan to change every section of every chapter, as I see a ton of work that needs to be done, although some sections obviously need less work than others. I suppose I can send a mail to each of the l10n lists when a chapter is complete. Please send such mails also to debian-i18n. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: German translation of the Sarge Installation Manual
On Sat, Apr 24, 2004 at 11:33:59PM +0200, Frans Pop wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 18 April 2004 23:41, Denis Barbier wrote: On Sun, Apr 18, 2004 at 11:15:39PM +0200, Frans Pop wrote: Also, I have seen the revision number of the en docs change without the content of documents changing (probably due to an reorganization or something), so it would be nice to also have an option to automagically update the revision numbers in translations if there are no real changes. Absolutely, the smart_change.pl script I wrote for webwml may be adapted here. Where can I find this script or could you send it to me? http://cvs.debian.org/webwml/smart_change.pl?cvsroot=webwml It uses modules found under http://cvs.debian.org/webwml/Perl/?cvsroot=webwml But after looking at the code, it seems that making it support SVN instead of CVS is not trivial, writing a new tool from scratch is certainly easier. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245624: cdebconf-text-udeb - display of default value in string templates is wrong
tags 245624 + pending thanks On Sat, Apr 24, 2004 at 10:50:56AM +0200, Bastian Blank wrote: Package: cdebconf-text-udeb Version: 0.53 Severity: important The default value in string templates is not shown: | Prompt: '?' for help, default=6027648 Both messages Prompt: '%c' for help, default=%d Prompt: '%c' for help, default=%s were bound to the same template debconf/text-prompt-default. I committed a fix, a workaround is to remove this debconf/text-prompt-default template when building isos, the right format will then be used. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243373: non-breaking spaces
reassign 243373 libnewt0.51 thanks On Wed, Apr 21, 2004 at 04:34:02PM -0400, Joey Hess wrote: Anton Zinoviev wrote: On 19.IV.2004 at 20:40 (-0400) Joey Hess wrote: Actually, the only way I can get it to work there is by setting LANG=C.UTF-8, and belive me, that looks very funky. I also reproduced this. It seams as if utf8 is hardcoded somehow in the newt frontend. The text frontend works fine. I'm going to put a hack in partman to work around this, and reassign the bug to cdebconf. I'll make partman use a instead of a NBSP, if the term is not bterm or xterm. I can reproduce the same bug with whiptail --yesno '0xa0 This is a question' 12 34 where 0xa0 is the NBSP character, so I reassign this bug to libnewt0.51. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Debian Installer translation status
On Thu, Apr 22, 2004 at 10:59:04AM +0300, Recai Oktas wrote: [...] These statistics were extracted from http://people.debian.org/~seppy/d-i/translation-status.html which contains many more useful informations for translators. FYI, though I performed a debconf-updatepo here, I couldn't confirm the given statistics of shadow-4.0.3/debian/po/tr.po: 16t10f0u, (it seems %100 here). When no access to SVN/CVS is provided, stats are computed on uploaded packages and does not take patches sent to BTS into account. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] debconf-updatepo, msgmerge and wrapping lines
On Wed, Apr 21, 2004 at 01:54:56AM +0200, Nikolai Prokoschenko wrote: Hello! I guess many of you fellow translators are having the same problem: after having sumbitted your translation it gets reformatted by debconf2po-update (internally through msgmerge) and the lines get wrapped. msgmerge is then stupid enough to break the line just in the middle of a path - an example is aboot-installer from d-i, where the path /etc/aboot.conf gets broken after the second slash (a quick grep shows many languages are affected). Any way to fix this? This is annoying and confusing the users. This reformatting does not alter display, msgstr foo bar is strictly identical to msgstr foo bar Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r14052 - in trunk/packages/mdcfg: . debian debian/po
On Tue, Apr 20, 2004 at 10:09:55PM -0400, Joey Hess wrote: [...] It's excellent to see this, and partman-md go in. I suppose that for the purposes of the string freeze, these packages do not exist. Can the stats be updated to skip them for now? Updated, partman-md and mdcfg are now skipped. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gallegan / Galician mailing list
On Wed, Apr 21, 2004 at 09:57:58AM +0200, Trorrr [Héctor Fernández] wrote: On Tue, Apr 20, 2004 at 12:16:36PM +0200, Trorrr [Héctor Fernández] wrote: Hi, i'm the translator for the Galician language. The automatic-generated gl.po for the first stage of the instalation says that Galician / Gallegan mailing list is Debian L10n Gallegan [EMAIL PROTECTED], [...] Which gl.po file? Please send an URL. The main gl.po file at http://people.debian.org/~barbier/d-i/l10n/gl/gl.po . You can ignore these files, they are only used to track down inconsistencies between translated strings. Header fields are filed up automatically by a script, and some values may be wrong. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r14052 - in trunk/packages/mdcfg: . debian debian/po
On Wed, Apr 21, 2004 at 09:27:58PM +0300, Eddy Petrisor wrote: Joey Hess wrote: Denis Barbier wrote: Updated, partman-md and mdcfg are now skipped. Hmm, the number of translations at 100% is halved from yesterday. Did another string change? apparently console-data is to blame and the lack of write acces for translators... I need it also... Fully right, it was mentioned for some time on http://people.debian.org/~seppy/d-i/translation-status.html that console-data (used by kbd-chooser) and iso-codes are part of 1st stage, but Dennis put them on his 2nd stage status pages because I did not take time to integrate them to my status pages. This is now done for console-data, I still need to integrate iso-codes, but I do not want to bloat stats with useless strings, so I need to find how to list only displayed countries/regions. Console-data project has currently 15 members, so you may send your translation here and someone will commit it. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r14052 - in trunk/packages/mdcfg: . debian debian/po
On Thu, Apr 22, 2004 at 12:04:44AM +0300, Eddy Petrisor wrote: Denis Barbier wrote: Console-data project has currently 15 members, so you may send your translation here and someone will commit it. I guessed that not bothering others to ci my chnges is a lot more productive... /me has a mail in the draft folder regarding the ci and some other things and suggestions, but as I see it right now, my suggestions are somehow overlapping your and seppy's scripts that centralise the pots and pos... Please discuss this issue on debian-i18n. see e.g. http://lists.debian.org/debian-i18n-0404/msg00012.html Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n]best translation for layouts - console-data
On Wed, Apr 21, 2004 at 11:03:49PM +0200, Bartosz Fenski aka fEnIo wrote: On Wed, Apr 21, 2004 at 11:54:39PM +0300, Eddy Petrisor wrote: 2 - Does everybody (Bob-user) know about type 3 / alternative layout ? I guess one of them is better known than the other, but which one? I would recomend _that_ variant for translation. To be honest _none_ of them is known for users. I'm talking in the name of Polish users. I suppose that someone who wish to find French layout he would check every possible and try to find the one which would be the most usable for him. Right. Note also that original keymap name should always be listed, so that one can run 'loadkeys mac-fr3' by hand after reading this message. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[l10n] Debian Installer translation status
Hi there, as you know we are in a string freeze for d-i beta4. Two new packages have been added to SVN repository (mdcfg and partman/partman-md) but their templates.pot are not considered because they won't be in beta4. Another change is about console-data, its stats have been moved from 2nd stage to 1st stage, because its templates are used by kbd-chooser. This change was planned for a long time, but I managed it only today, so this explains why many languages are at 99% whereas they were fully translated in beta3. 1st stage: all d-i packages plus console-data * 12 full translations Basque Brazilian Portuguese Czech Danish Dutch French German Hebrew Hungarian Portuguese Turkish Ukrainian * 19 nearly complete translations ( 90%) Albanian Catalan Chinese (Simplified) Chinese (Traditional) Finnish Galician Greek Indonesian Italian Japanese Korean Lithuanian Norwegian Bokmal Norwegian Nynorsk Polish Romanian Russian Slovakian Swedish * 5 translations in good shape ( 75%) Bosnian Bulgarian Slovenian Spanish Welsh We can then expect 36 fully translated languages in beta4, and even more if other languages work really very hard. When 1st stage is over, translators should focus on 2nd stage or installation manual (no statistics yet on this manual). 2nd stage: popularity-contest tasksel base-config console-common iso-codes[1] exim4 pcmcia-cs shadow newt [1] Should be listed in 1st stage * 11 nearly complete translations ( 90%) Chinese (Simplified) Czech Danish Dutch French German Greek Japanese Korean Portuguese Slovenian * 2 translations in good shape ( 75%) Ukrainian Polish * 8 partially translated ( 50%) Basque Brazilian Portuguese Finnish Hungarian Lithuanian Russian Spanish Turkish Galician, Indonesian and more especially Basque are very well ranked despite these are new translations, congratulations to all of you. And eventually, translators should definitely try to test beta4, this is the only way to make sure that translations are well suited for the given context. These statistics were extracted from http://people.debian.org/~seppy/d-i/translation-status.html which contains many more useful informations for translators. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] debconf-updatepo, msgmerge and wrapping lines
On Wed, Apr 21, 2004 at 11:11:18AM +0200, Nikolai Prokoschenko wrote: On Wed, Apr 21, 2004 at 10:42:15AM +0200, cobaco (aka Bart Cornelis) wrote: But this line would be split up while displaying it - couldn't the path get splitted up then? At which points in cdebconf are the line breaks allowed? cdebconf never sees the line breaks, only the gettext tools do I understand that. However, for longer strings, cdebconf would have to break them up, so they can appear on the monitor and fit into the available horizontal space. Could it happen that cdebconf breaks up a line somewhere in the middle of a path? I don't think so, path larger than screen width are certainly troublesome. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gallegan / Galician mailing list
On Tue, Apr 20, 2004 at 12:16:36PM +0200, Trorrr [Héctor Fernández] wrote: Hi, i'm the translator for the Galician language. The automatic-generated gl.po for the first stage of the instalation says that Galician / Gallegan mailing list is Debian L10n Gallegan [EMAIL PROTECTED], [...] Which gl.po file? Please send an URL. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#244886: kbd-chooser: can't select keymap on sparc64 netboot 20040411 image
On Tue, Apr 20, 2004 at 04:31:28PM +0100, Alastair McKinstry wrote: [...] Within kbd-chooser, it appears the fr.po entry in kbd-chooser has strange characters for sunkeymap. Could you please edit this, and try the kbd-chooser again: I am on holiday from tonight and will not have a chance to test this and fix it until Sunday, Here is a patch against console-data. The first 2 chunks are typo fixes, last one is due to a double latin1 - UTF-8 conversion. Denis fr.po.patch.gz Description: Binary data
Re: A General Resolution? [was: Standard Compliance in Country Names]
On Tue, Apr 20, 2004 at 08:40:34PM +, Chuan-kai Lin wrote: [...] A more interesting question would be asking them if they consider the country names listed in ISO 3166 also part of the standard. If they respond that the country names are only used to make it clear to which country/region/whatever each of the alpha-2 codes refer, then the original standard compliance bug Christian bug filed is bogus, and we naturally revert to the original status quo of calling Taiwan Taiwan. If they respond that the country names are also part of the standard and changing them violates ISO 3166, they should offer an explanation on how ISO (or UN for that matter) could act as an authoritative source of country names given that: (1) the names do not originate from either ISO or UN, and (2) countries decide their own names without seeking (or needing) permission from ISO or UN. In other words, they need to come up with a reasonable explanation on when and how did international organizations (ISO or UN) get into the business of naming countries. One simply has to realize that country names in English and French are written using imaginary en_UN and fr_UN locales, and can be translated to any language (including common English and French, for those who do not speak *_UN variants). Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated xkb/kde/fonts configuration after install
On Thu, Apr 15, 2004 at 09:40:54AM +0100, Alastair McKinstry wrote: On Thursday 15 April 2004 02:54, Denis Barbier wrote: As you chose el_GR.UTF-8 as the default locale, you have to find a way to provide a working UTF-8 console. If jfbterm works for 2nd stage, it could also be used when installation is over, couldn't it? I thought about it, but IIRC I read in this list that we might change from console-* packages to a kbd-based solution, which is supposedly more UTF-8 compliant. All UTF-8 patches to kbd since been applied to console-* ; remaining UTF-8 issues are due to the kernel. To be a little bit more verbose, Linux kernel can only cope with 512-glyph console fonts, this is why console is unsuitable for some Asian languages. Greek is not hit by this problem, so one might think that el_GR.UTF-8 is fine. And indeed console-tools and kbd should be able to display UTF-8 text without problem. But AFAICT the other issues Alastair is talking about is that one cannot enter UTF-8 encoded text on console due to another kernel limitation. To summarize, UTf-8 console should work fine unless you have to type multibyte characters. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: German translation of the Sarge Installation Manual
On Sun, Apr 18, 2004 at 09:06:29PM +0200, Frans Pop wrote: [...] If you like, I can create a 'de' subdirectory containing the current English documents (and add an 'install.de.xml' document in the build directory); you can then replace these one doc at a time with German translations. You will have be alert for changes in the original English documents to keep the German translation in sync with the English version (this is fairly easy with SVN). [...] Previous installer (a.k.a boot-floppies) had utilities to track down outdated translations, which have been adapted to SVN. $ cd debian-installer/installer/doc/manual $ ./doc-check fr en/partitioning/device-names.xml : 11648 - 12766 en/preparing/backup.xml : 11648 - 12756 en/preparing/preparing.xml : 11648 - 12756 en/preparing/install-overview.xml : 11648 - 11573 [...] You only have to write a special comment in your translated XML files: !-- original version: SVN_revision -- where SVN_revision is of course the SVN revision of the English file being translated. See for instance French translation. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: German translation of the Sarge Installation Manual
On Sun, Apr 18, 2004 at 11:15:39PM +0200, Frans Pop wrote: On Sunday 18 April 2004 22:20, Denis Barbier wrote: Previous installer (a.k.a boot-floppies) had utilities to track down outdated translations, which have been adapted to SVN. $ cd debian-installer/installer/doc/manual $ ./doc-check fr en/partitioning/device-names.xml : 11648 - 12766 en/preparing/backup.xml : 11648 - 12756 en/preparing/preparing.xml : 11648 - 12756 en/preparing/install-overview.xml : 11648 - 11573 [...] Hmmm. The adaptation to SVN has not been very complete... If I look at that script, I see: my $s = cvs diff -b -u -r $plrev -r $enrev $enfname; ^^^ This error only occured with the -d flag to display diffs, I never run it. and checkdiff(install.$lang.xml, install.en.xml); currently gives an error; it should probably be checkdiff(build/install.$lang.xml, build/install.en.xml); Both are now fixed, thanks. Also, I have seen the revision number of the en docs change without the content of documents changing (probably due to an reorganization or something), so it would be nice to also have an option to automagically update the revision numbers in translations if there are no real changes. Absolutely, the smart_change.pl script I wrote for webwml may be adapted here. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: German translation of the Sarge Installation Manual
On Sun, Apr 18, 2004 at 06:52:46PM -0400, Joey Hess wrote: Is the cvs repository of the installation manual still being used for anything at all, or can I turn it off and archive it at last? IMO you can archive it and make this repository available online so that translators can download it if needed. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: entering the string freeze
On Sun, Apr 18, 2004 at 09:54:59PM -0400, Joey Hess wrote: [...] Any code changes that are in subversion trunk but are not yet uploaded to the debian archive need to be uploaded if they're known good, and if they're not, may need to be moved to a branch so we can upload updated translations. This includes autopartkit, base-installer, kbd-chooser, languagechooser, netcfg, nobootloader, partitioner, prebaseconfig. Please be conservative, we need to stablise the installer this week, and avoid breaking anything. About languagechooser, all unreleased changes are safe, except maybe the ones by Petter, I did not have a look on them. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A General Resolution? [was: Standard Compliance in Country Names]
On Fri, Apr 16, 2004 at 07:18:21AM +0200, Christian Perrier wrote: Quoting Anton Zinoviev ([EMAIL PROTECTED]): 4. ISO 3166 is not politically independent standard. Moreover it has *This* is a political statement..:-) On this topic, I have started writing a formal mail to the ISO-3166 secretary asking about an official statement from ISO-3166 about their use of the controversial wording for TW. [...] In the meantime, are you going to replace galician by galleghan in languagelist to follow ISO 639? This would be logical, and make more people understand why blindly following ISO codes is not optimal ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A General Resolution? [was: Standard Compliance in Country Names]
On Fri, Apr 16, 2004 at 03:11:30PM +0200, Christian Perrier wrote: Quoting Denis Barbier ([EMAIL PROTECTED]): In the meantime, are you going to replace galician by galleghan in languagelist to follow ISO 639? This would be logical, and make more Well, sounds logical to me, yes. This just needs someone reporting the bug to iso-codes.I'm not the maintainer. Iso-codes has the language name defined in ISO 639, not languagelist. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated xkb/kde/fonts configuration after install
On Thu, Apr 15, 2004 at 05:33:19PM +0300, Eugeniy Meshcheryakov wrote: [...] Well, yes it doesn't show the borders in tasksel. But when I use the fonty to select the font and enable unicode with unicode_start then it does show the graphical characters... So, may be better change languagechooser in order to use fonts from the fonty package and install it in prebaseconfig for Greek? It seems unfortunately that no font is suitable in console-data, I have no idea why console-data does not ship all the fonts found in kbd. So you can either ask Alastair to add more fonts to console-data (e.g. iso07u-16.psfu) or use fonty. In the latter case, it may be simpler not to configure fonty and tell console-tools to use the right font, please tell us which one you want. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243658: partman: improper use of progress bar
Package: partman Severity: normal Progress bars are useful to let users know that installation is not frozen, but there is no reason to mix progress bars and normal questions. This induces some display glitches with the text frontend which cannot easily be fixed, and similar problems will certainly arise with other frontends. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243034: languagechooser: console-cyrillic support
On Tue, Apr 13, 2004 at 05:37:51PM +0300, Eugeniy Meshcheryakov wrote: Nikita V. Youshchenko wrote: Maybe it is better to handle all cyrillic languages in termwrap in the same way? Or does not use termwrap at all for languages that have kbd or cyr entries in languagechooser's prebaseconfig? Absolutely, termwrap has 2 drawbacks for console-tools: * Only the first console is configured. (Can be fixed, but it has never been) * Consoles are no more configured when rebooting after 2nd stage is over. For these reasons, having a working /etc/console-tools/config file at the end of the 1st stage is the best solution. I believe that the 2nd point also applies to cyr. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Standard Compliance in Country Names
On Wed, Apr 14, 2004 at 10:39:29PM +, Chuan-kai Lin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Perrier [EMAIL PROTECTED] wrote: As Martin wrote privately to me about this issue (I guess I could quote him completely about this but I didn't receive his explicit permission for that), we are not in the business of deciding which name is correct. Following official standards is our only possibility and, as he wrote, If people disagree with the standard, they should take it up with the standards body, which I perfectly agree with. [...] Let's go back to issue of standard compliance. You quote ISO 3166 as the official standard on country names and intend to follow it to the letter. This is a decision I have problems with: ISO 3166 should not be treated as an a priori authoritative source of country names in the same sense that IANA is an authority on internet IP addresses. The distinction should be clear: ISO does not assign names to countries in the way IANA assigns IP addresses to RIRs. The only designations created by ISO are the alpha-2 two-character code elements, and I don't think anyone has problems with that. Absolutely. This standard only assigns codes to countries and regions, but there is no reason to consider their names as immutable. There is a very similar case, you can see on http://www.debian.org/intl/l10n/po-debconf/index.en.html that 'gl' language is Gallegan. A translator changed this name to Galician and told that he did not even know that Gallegan was the English name for his language, since nobody uses this term. But as ISO 639 tells that gl is Gallegan, *I* reverted this change to follow the standard. After some days on a sunny sandbeach, I must admit that this is a silly behavior, people should be able to use the names which are best suited for their needs. (But changing this language name is not that easy and will take several days) So Christian, take some rest without net access and when you are back we will see if you change your mind about this issue ;) There is another problem about iso-codes, POT files have been submitted to the Free Translation Project: http://www2.iro.umontreal.ca/translation/registry.cgi?domain=iso_639 http://www2.iro.umontreal.ca/translation/registry.cgi?domain=iso_4217 http://www2.iro.umontreal.ca/translation/registry.cgi?domain=iso_3166 http://www2.iro.umontreal.ca/translation/registry.cgi?domain=iso_3166_1 http://www2.iro.umontreal.ca/translation/registry.cgi?domain=iso_3166_2 http://www2.iro.umontreal.ca/translation/registry.cgi?domain=iso_3166_3 but AFAICT they are now out-of-date, which means that Debian translators hijack these translations. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated xkb/kde/fonts configuration after install
On Thu, Apr 15, 2004 at 12:29:23AM +0300, Konstantinos Margaritis wrote: Hi, I have successfully installed Debian totally localized in the Greek language. I just selected 'greek' task and everything went smoothly. There are some visual artifacts in the console, mainly because of UTF-8 mode, but these are getting fewer and tasksel is still 1.47 in the last netinst cd (and as I understand 1.48 has the UTF-8 fixes). Now, the installation went ok and I managed to boot into a totally localized KDE system but I had to do some extra steps that I believe could be automated as well. These are: * setting up the fonty debconf value to ISO-8859-7 (for greek in console) As you chose el_GR.UTF-8 as the default locale, you have to find a way to provide a working UTF-8 console. If jfbterm works for 2nd stage, it could also be used when installation is over, couldn't it? Anyway you may have a look at packages/languagechooser/languagelist packages/languagechooser/prebaseconfig there have been recent changes about console configuration. * setting up the X keyboard debconf value to 'us,el' and the XkbOptions to 'grp:alt_shift_toggle' so that keymap switching is possible instantly. This is not trivial, I guess that X configuration should be modified to load d-i values when they are available. Is there a way to know that we are currently configuring a package from within the debian-installer? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243034: languagechooser: console-cyrillic support
tags 243034 + pending thanks On Sat, Apr 10, 2004 at 04:54:26PM +0300, Eugeniy Meshcheryakov wrote: Package: languagechooser Version: svn Severity: wishlist Tags: patch l10n d-i Attached patch adds console-cyrillic support for languagechooser prebaseconfig (similar to console-tools). Prebaseconfig expects information about cyrillic keyboard in form: cyr=style,size,encoding,layout(options) Example for Ukrainian: cyr=uni,16,koi8-u,ua_ms(ctrl_shift_toggle) Looks good, committed. Could someone please update the Russian entry in languagelist? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243085: back button looks out of place
On Sat, Apr 10, 2004 at 05:03:40PM -0400, Joey Hess wrote: Package: cdebconf Severity: normal Tags: d-i Without a continue button displayed any more, the back button looks out of place on the left hand side of select and string input dialog boxes. It made sense to put the back button on the left when the continue was on the right, to imply a left/right movement between pages. Without the continue button, this placement does not make sense. It looks awkward. I think it would be better to still display the continue button if the back button is displayed. Only if there is no back button, the continue button can also be left off. IIRC, that addresses the original problem that led to the removal of the continue buttons -- that a continue button looked awkward at the bottom of a select list, if it was the only button displayed. I had #220478 in mind, several bugreports claim that a Continue button is misleading when a select list has a 'Finish' choice. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243085: back button looks out of place
On Mon, Apr 12, 2004 at 06:28:53PM -0400, Joey Hess wrote: Denis Barbier wrote: I had #220478 in mind, several bugreports claim that a Continue button is misleading when a select list has a 'Finish' choice. Mm, right. I don't know what to do about it then, perhaps only I will find the current back button placement ugly.. It can easily be centered, if you prefer. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#242787: termwrap: [INTL:uk] patch for KOU8-U support in text mode console
On Fri, Apr 09, 2004 at 04:14:09PM +0300, Eugeniy Meshcheryakov wrote: Nikita V. Youshchenko wrote: Nikita V. Youshchenko wrote: Isn't it better to support uk locale similar to ru locale - using console-cyrillic ? Why do this? console-tools and console-data are always available, and console-cyrillic is not. AFAIK console-cyrillic is the recommended way to set up cyrillic console. It configures everything, not only screen fonts, and does it's job well. What do it? Sets up fonts and keyboard? console-tools does it too. d-i installs console-cyrillic for russiab locale. Probably it should install it for all cyrillic locales. It is installed as part of the 'cyrillic' task. No, it is also installed by base-installer when language is Russian. (BTW shouldn't apt-install be run from languagechooser/prebaseconfig instead?) Please have a look at languagechooser/languagelist, I just added a field for console configuration. Only console-tools is currently supported, but it can be easily extended to cyr and jfbterm. Then all the locale configuration will be performed by languagechooser prebaseconfig, and termwrap will become much lighter (and maybe useless?). Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242689: rebuilding the package loses translations of http/mirrors countries
On Thu, Apr 08, 2004 at 01:25:36AM -0400, Joey Hess wrote: Package: choose-mirror Severity: normal Version: 0.040 Tags: d-i, l10n If I build this package from source, the mirror/http/countries does not get any localisations in its Choices field. The mirror/ftp/countries template, with a very similar set of strings, still gets all the translations. This is not due to fuzzy translations. It is, http list has 2 new country codes (CO and MA) which are currently only translated into Japanese, so all other translations are discarded. I keep this bug open at the moment, something has to be done so that it does not happen as soon as a mirror is added. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242689: rebuilding the package loses translations of http/mirrors countries
On Thu, Apr 08, 2004 at 01:07:57AM -0700, Matt Kraai wrote: [...] Well, we could make mirror updates manual, and add error checking. That would unfortunalty mean we'd have to remmeber to do them though. Any better ideas? Would using the intltool-merge and po2debconf scripts from countrychooser fix the problem? Not entirely. As Christian explained, choose-mirror should mimic countrychooser and retrieve translated country names from iso-codes. I will try to do something about it tonight. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242787: termwrap: [INTL:uk] patch for KOU8-U support in text mode console
tags 242787 + pending thanks On Thu, Apr 08, 2004 at 09:39:32PM +0300, Eugeniy Meshcheryakov wrote: Package: base-config Version: 2.17 Severity: wishlist Tags: patch l10n Attached patch adds support for KOI8-U to termwrap. There is no need to use fbterm for koi8-u. [...] Committed, I slightly modified the last chunk. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [USABILITY] Usability test of Debian Installer beta 3
On Wed, Apr 07, 2004 at 08:57:46PM +0200, Frans Pop wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 07 April 2004 20:06, Fabian Fagerholm wrote: I'm concentrating on users who have never installed an operating system before. If you're going to use complete newbies for testing, I think you should be fair and provide them with relevant information that is freely available. At least provide them with a version of the manual which _does_ explain about scrolling and the sequence of the installation, common problems and how to solve them. [...] No, help screens have to be improved, but unfortunately this will be done very late. Current d-i developers are working on other tasks, so anyone interested in providing a better installer can help, the only prerequisite is to have tested the debian-installer. For instance a help line can be added at the bottom to explain available keystrokes, and I will be glad to incorporate it if there are suggestions. Another useful help would be to test current daily images and see if criticisms expressed in http://www.thiesen.org/d-i/ have been dealt with, and file individual bugs if this has not already been done. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
