Re: problem with console-data 1999.08.29-23 ?
Adam Di Carlo <[EMAIL PROTECTED]> writes: > Is this a problem in our loadkeys program or a problem in the > keymaps file? I note that the 'cent' keysym according to our > sources is actually called 'currency'. What sources? "currency" is the generic currency symbol only a few nerds recognize (¤, ISO Latin 1) which was replaced by the Euro symbol in ISO Latin 9 (aka Latin 0). See: http://czyborra.com/charsets/iso8859.html It includes images of all the glyphs. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#124386: french + euro keyboard is latin15, not latin0 (which naturally does not work).
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > [Sven Luther] > > as iso8859-1 is called latin1, i suppose it just makes sense to name > > iso8859-15 latin15 ? > > Not really. There is almost, but not quite, a direct mapping from > ISO-8859- to latin. If I recall correctly, at least > ISO-8859-11 is called latin9 for historical reasons, so you can not > assume a direct mapping. Here's the mapping for fans of trivia: ISO 8859-1 Latin1 ISO 8859-2 Latin2 ISO 8859-3 Latin3 ISO 8859-4 Latin4 ISO 8859-5 Cyrillic ISO 8859-6 Arabic ISO 8859-7 Greek ISO 8859-8 Hebrew ISO 8859-9 Latin5 ISO 8859-10 Latin6 ISO 8859-11 Thai ISO 8859-12 reserved ISO 8859-13 Latin7 ISO 8859-14 Latin8 ISO 8859-15 Latin9 (also nicknamed Latin0) Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Translation statistics
Claus Hindsgaul <[EMAIL PROTECTED]> writes: > You are completely right. It is more a convenience than a "must" for > Danes (and other Scandinavians) to have their very own > translations. The absence of a Danish (or Scandinavian) translation > should'nt disable many scandinavians from installing Debian. But it > would be easier for most native speakers and thus invite more to > actually do it. > And e.g. the Danish GNU-skole (GNU for Schools) find it very > important to have real Danish translations in order to introduce > Danish kids (and teachers) to Linux. We have a project called Skolelinux in Norway, we will be making our own CD and floppy images so that Norwegian (nynorsk and bokmål) and possibly Sami are the only available choices. Since our target is well defined, we can get rid of some questions (keyboard layout, timezone). Our dream is to have no more than three questions from bootup until working desktop :-) So far we've been concentrating on translating the desktop and surveying educational software, though. > If enough localisations of boot-floppies get up-to-date, we ought to > consider splitting up the international floppies into two with > different groups of locales built in. I think Achim Bohnet's idea of a small boot-cdrom is a good one, floppy drives are going away from consumer machines soon, anyway. If we can use a 2.88 MB root.bin, this problem goes away for most people. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Danish inclusion on the international disk
Philip Blundell <[EMAIL PROTECTED]> writes: > Well, the Linux Counter results aren't the only thing one has to > consider. According to > http://www.ethnologue.com/show_language.asp?code=JPN there are 126 > million Japanese speakers worldwide, against about 5.5 million for > Danish. Also, a large number of Danes, Swedes and Norwegians know English (or German/French) reasonably well, so it isn't that critical, IMHO. > Even here in Europe, it looks to me like Swedish might have a > stronger case for inclusion than Danish. Either Swedish or Danish is OK for Scandinavians. As a data point, Sun chose to support only Swedish with full documentation in Solaris. Kjetil T. (from Norway) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
Ethan Benson <[EMAIL PROTECTED]> writes: > On Tue, Nov 13, 2001 at 10:53:16PM +1300, Mark van Walraven wrote: > > partition_config::mount_partition() uses mode 01777 when creating /tmp > > as a mount-point, but doesn't for /target/var/tmp. A fix is: > > what good will this do? the permissions of the mount point > directory are irrelevant as they will be replaced by the permissions > of the root directory of the mounted filesystem. It enables the use of vi for non-root users even when /var/tmp isn't mounted ... uh ... No, actually, if you use tmpfs for /var/tmp, it will use the same permissions as the mount point, since there is no other place to store that persistent configuration. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: busybox still too bloated
Erik Andersen <[EMAIL PROTECTED]> writes: > expr can be replaced with posix shell expressions. This is not true in general, as there is no support for regular expressions in POSIX sh. $ expr "abcdef" : '[ab]*\(.\).*' c Most of the time you can rewrite the code to use parameter substitution or the arithmetic builtins, so this is not a serious objection, just a FYI. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#105364: installer allows user to insert underscores in the hostname
Matt Kraai <[EMAIL PROTECTED]> writes: > In order to implement this, I really need to know the answers to > the following questions: > > * What encoding is used for the host name input by the user? > > * What host name validation should be performed by dbootstrap? > > * What encoding should be used for writing the host name? > > The kernel treats the host name as any other character string, and > so doesn't appear to care about the encoding. I haven't been able > to find the libc source which deals with internationalized host > names, so I don't know what format it expects things in. IMHO, we should only enforce what has been standardised. * Only allow components matching the simple grammar in RFC 1034. (section 3.5) * Each name component is max 63 octets. * Total hostname length is max 255 octets. * No component can start with (not really in the standards, but pertinent anyway) When the process moves out of the draft process, implement whatever the RFC says. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#105364: installer allows user to insert underscores in the hostname
Matt Kraai <[EMAIL PROTECTED]> writes: > On Mon, Jul 23, 2001 at 12:54:31PM +0200, Kjetil Torgrim Homme wrote: > > It's very early, yet. But a few things are reasonably clear. They'll > > use Unicode, they just haven't decided on the encoding. That is, all > > characters which aren't US-ASCII will probably be added to the list of > > allowed characters. > > I don't think so. According to [1], Appendix F, there are quite a > few prohibited non-ASCII code points. > > 1. http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-04.txt You are right. (btw, it's now replaced by -05) > There are also some normalization rules. I'm not sure if the > normalizations should be performed in dbootstrap or in some lower > layer, however. Ugh. Do we really want to go there? > > The limit of 63 octets per name component probably won't change, > > but notice that the number of characters will be less, depending > > on the encoding. > > > > One thing: It would be good to disallow the use of ASCII Compatible > > Encoding-prefixes. They look like "xx--", where x is an arbitrary > > letter. > > I've never seen these before, this being my first foray into > internationalization. I'll keep this in mind, however. > > Will the input be encoded in UTF-8? No, that will break too many protocols. That's the reason for ASCII Compatible Encoding, using only characters "a-z0-9/-". Look at some of the examples (/^Exampl) in http://www.i-d-n.net/draft/draft-ietf-idn-amc-ace-w-00.txt Notice that UTF8 is inefficient for Hangeul and other scripts, even if it uses the full 8 bits instead of 5. (Personally, I hope something like http://www.i-d-n.net/draft/draft-ietf-idn-udns-02.txt passes. I'm not too optimistic, this reminds me of all the warts of MIME we probably never will be rid of.) Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#105364: installer allows user to insert underscores in the hostname
Matt Kraai <[EMAIL PROTECTED]> writes: > You mentioned a WIP which would allow non-ASCII characters in the > hostname. Can you please send me a pointer to this document so that > I can update the boot-floppies to comply with it? This is the website of the IETF WG: http://www.i-d-n.net/ This is a good summary of what they have set out to do: http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-08.txt It's very early, yet. But a few things are reasonably clear. They'll use Unicode, they just haven't decided on the encoding. That is, all characters which aren't US-ASCII will probably be added to the list of allowed characters. The limit of 63 octets per name component probably won't change, but notice that the number of characters will be less, depending on the encoding. One thing: It would be good to disallow the use of ASCII Compatible Encoding-prefixes. They look like "xx--", where x is an arbitrary letter. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
