Re: ITA freedict
Steve Langasek <[EMAIL PROTECTED]> writes: . . . > LOCPATH=/tmp/usr/lib/locale dictfmt --locale > ($LOCALE_NAME).$(LOCALE_CHAR= SET) ought to have the desired effect. > All locale-related glibc functions should respect the value of LOCPATH Thanks, Steve. It works as advertised now. I had set the value of LOCPATH earlier in the rules file, but I didn't export it. PEBCAK! Regards, Bob -- _ |_) _ |_Robert D. Hilliard<[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL 34990 USA GPG Key ID: 390D6559
Re: ITA freedict
On Tue, Aug 26, 2003 at 06:48:07PM -0400, Bob Hilliard wrote: > Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > > If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to > > the name of the locale you generate, you should get what you want > > without being root. Something like this (mostly cut-n-paste from d-i > > build system): > > # The variables > > LOCALE_PATH=/tmp/usr/lib/locale > > LOCALE_NAME=en_IN > > LOCALE_CHARSET=UTF-8 > > # Generating the locale > > mkdir -p $LOCALE_PATH > > localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \ > > "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET" > > # Using the locale > > LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date > Steve Langasek <[EMAIL PROTECTED]> added: > > Looks like this needs to be localedef -i "$LOCALE_NAME" -f "$LOCALE_CHARSET" > > instead, but otherwise, I've confirmed that this works. > I need to use this locale as a command line argument to dictfmt > --locale. dictfmt calls this locale with setlocale(3). I have tried > --locale $(LOCALE_NAME).$(LOCALE_CHARSET) and --locale > $(LOCPATH)/$(LOCALE_NAME).$(LOCALE_CHARSET). Both return invalid > locale, which is the error message dictfmt emits when it cannot open > the specified locale file. The locale _is_ generated in > $LOCALE_PATH. > Is the environment variable LOCPATH used by setlocale(3)? > Can anyone suggest what I need to try to make this work? LOCPATH=/tmp/usr/lib/locale dictfmt --locale ($LOCALE_NAME).$(LOCALE_CHARSET) ought to have the desired effect. All locale-related glibc functions should respect the value of LOCPATH. -- Steve Langasek postmodern programmer pgp7hEo6aPWUK.pgp Description: PGP signature
Re: ITA freedict
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to > the name of the locale you generate, you should get what you want > without being root. Something like this (mostly cut-n-paste from d-i > build system): > > # The variables > LOCALE_PATH=/tmp/usr/lib/locale > LOCALE_NAME=en_IN > LOCALE_CHARSET=UTF-8 > > # Generating the locale > mkdir -p $LOCALE_PATH > localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \ > "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET" > > # Using the locale > LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date Steve Langasek <[EMAIL PROTECTED]> added: > Looks like this needs to be localedef -i "$LOCALE_NAME" -f "$LOCALE_CHARSET" > instead, but otherwise, I've confirmed that this works. I need to use this locale as a command line argument to dictfmt --locale. dictfmt calls this locale with setlocale(3). I have tried --locale $(LOCALE_NAME).$(LOCALE_CHARSET) and --locale $(LOCPATH)/$(LOCALE_NAME).$(LOCALE_CHARSET). Both return invalid locale, which is the error message dictfmt emits when it cannot open the specified locale file. The locale _is_ generated in $LOCALE_PATH. Is the environment variable LOCPATH used by setlocale(3)? Can anyone suggest what I need to try to make this work? Regards, Bob -- _ |_) _ |_Robert D. Hilliard<[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL 34990 USA GPG Key ID: 390D6559
Re: ITA freedict
On Sun, Aug 24, 2003 at 12:41:24AM +0200, Petter Reinholdtsen wrote: > [Bob Hilliard] > > This presents a problem for the dict-freedict package, in that a > > xx_YY.utf-8 locale must be available on the build machine. AFAIK > > there is no way to guarantee that a specific locale is available on > > the buildds. It would be possible for debian/rules to generate a > > xx_YY.utf-8 locale, but this would require rules to run as root, > > which is not permissible by policy. > Another idea, which I will contribute to the boot-floppies developers > and Martin Sjögren, is to generate the locales you need, and then set > LOCPATH to pointto its location. > If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to > the name of the locale you generate, you should get what you want > without being root. Something like this (mostly cut-n-paste from d-i > build system): > # The variables > LOCALE_PATH=/tmp/usr/lib/locale > LOCALE_NAME=en_IN > LOCALE_CHARSET=UTF-8 > # Generating the locale > mkdir -p $LOCALE_PATH > localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \ > "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET" > # Using the locale > LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date > This should work just fine as any user. Looks like this needs to be localedef -i "$LOCALE_NAME" -f "$LOCALE_CHARSET" instead, but otherwise, I've confirmed that this works. Cheers, -- Steve Langasek postmodern programmer pgpKczzpbaxgJ.pgp Description: PGP signature
Re: ITA freedict
On Sat, Aug 23, 2003 at 05:35:41PM -0500, Steve Langasek wrote: > On Sat, Aug 23, 2003 at 06:22:53PM -0400, Bob Hilliard wrote: > > The simplest approach would be to format the dictionaries on my > > machine, and include them in the source package. This would be > > similar to the previous dict-freedict packages. Would this be > > acceptable? > > By analogy with pre-generated output of lex, bison, and autoconf, I > think it would be acceptable to include the preformatted dictionaries in > the source package so long as the true source form of the dictionaries > is also included. Agreed. I'd include a debian/rules or Makefile target to regenerate them, too (although perhaps you were including this in "true source form"). -- Colin Watson [EMAIL PROTECTED]
Re: ITA freedict
[Bob Hilliard] > This presents a problem for the dict-freedict package, in that a > xx_YY.utf-8 locale must be available on the build machine. AFAIK > there is no way to guarantee that a specific locale is available on > the buildds. It would be possible for debian/rules to generate a > xx_YY.utf-8 locale, but this would require rules to run as root, > which is not permissible by policy. Another idea, which I will contribute to the boot-floppies developers and Martin Sjögren, is to generate the locales you need, and then set LOCPATH to pointto its location. If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to the name of the locale you generate, you should get what you want without being root. Something like this (mostly cut-n-paste from d-i build system): # The variables LOCALE_PATH=/tmp/usr/lib/locale LOCALE_NAME=en_IN LOCALE_CHARSET=UTF-8 # Generating the locale mkdir -p $LOCALE_PATH localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \ "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET" # Using the locale LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date This should work just fine as any user.
Re: ITA freedict
On Sat, Aug 23, 2003 at 06:22:53PM -0400, Bob Hilliard wrote: > I intend to adopt freedict, which was recently orphaned. > dict-freedict consists of 42 utf-8 encoded bi-lingual > dictionaries. In the past dict-freedict has included pre-formatted > dictionaries downloaded from www.freedict.de. However, these > pre-formatted dictionaries do not work with modern versions of dictd. > In the dict-* packages that I maintain, I have always formatted > the dictionary as part of the build process. This presents a problem > for the dict-freedict package, in that a xx_YY.utf-8 locale must be > available on the build machine. AFAIK there is no way to guarantee > that a specific locale is available on the buildds. It would be > possible for debian/rules to generate a xx_YY.utf-8 locale, but this > would require rules to run as root, which is not permissible by > policy. > The simplest approach would be to format the dictionaries on my > machine, and include them in the source package. This would be > similar to the previous dict-freedict packages. Would this be > acceptable? By analogy with pre-generated output of lex, bison, and autoconf, I think it would be acceptable to include the preformatted dictionaries in the source package so long as the true source form of the dictionaries is also included. -- Steve Langasek postmodern programmer pgpIWtoIYFBS2.pgp Description: PGP signature
ITA freedict
I sent the following message with the "X-Debbugs-CC: debian-devel@lists.debian.org" header, but apparently [EMAIL PROTECTED] doesn't recognize that header, so I am resending it. -- tags 206113 +ITA thanks I intend to adopt freedict, which was recently orphaned. dict-freedict consists of 42 utf-8 encoded bi-lingual dictionaries. In the past dict-freedict has included pre-formatted dictionaries downloaded from www.freedict.de. However, these pre-formatted dictionaries do not work with modern versions of dictd. In the dict-* packages that I maintain, I have always formatted the dictionary as part of the build process. This presents a problem for the dict-freedict package, in that a xx_YY.utf-8 locale must be available on the build machine. AFAIK there is no way to guarantee that a specific locale is available on the buildds. It would be possible for debian/rules to generate a xx_YY.utf-8 locale, but this would require rules to run as root, which is not permissible by policy. The simplest approach would be to format the dictionaries on my machine, and include them in the source package. This would be similar to the previous dict-freedict packages. Would this be acceptable? Regards, Bob -- _ |_) _ |_Robert D. Hilliard<[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL 34990 USA GPG Key ID: 390D6559
