Re: [gentoo-user] Gtypist does not accept ru.typ
2016-01-09 13:43 GMT+02:00 Stroller : > >> On Fri, 8 January 2016, at 1:13 p.m., gevisz wrote: >> >> 2016-01-08 13:50 GMT+02:00 Stroller : >>> On Fri, 8 January 2016, at 12:32 a.m., gevisz wrote: Just of curiosity compiled gtypist with nls use flag. Now it accepts ru.typ! But it is a bug because nls flag is supposed to only switch on the translation of the corresponding menu and help messages. So, it should accept ru.typ even if compiled without the nls use flag! >>> >>> I'm glad you're sorted. You should let the gtypist devs know of this bug. >> >> Thank you for your help! >> >> However, before turning to the gtypist devs, I should clarify one more, >> may be stupid, question, namely: "Who is responsible for the correct >> `functioning' of the use flags?" Because I always thought that the use >> flags are a unique feature of the Gentoo distribution (and therefore, it >> is the the Gentoo devs who are responsible for them) but your advice >> above implies that it is not true. > > The ebuild is (mostly) just a wrapper for preceding software installation > tools, like make and gcc. > > In a previous message you showed us that the Gtypist devs had asked you "Can > you check whether this appears when running ./configure? Also, which > arguments are used for ./configure?" > > In the case of the nls USE flag, the ebuild is just calling configure with > certain arguments: > >src_configure() { >econf $(use_enable nls) >} > >src_install() { >emake DESTDIR="${D}" install >} > >Note the IUSE variable. This lists all (non-special) use flags that are >used by the ebuild. This is used for the emerge -pv output, amongst >other things. > >The package's ./configure script takes the usual --enable-nls or >--disable-nls argument. We use the use_enable utility function to >generate this automatically, depending on the user's USE flags (see >Query Functions Reference). > > This is a top google hit for use_enable: > https://devmanual.gentoo.org/quickstart/ > > Stroller. Ok. Thank you for all your help and explanation. P.S. I have read the document lead to by the link you provided in full and now communicate all this to the gtypist devs.
Re: [gentoo-user] Gtypist does not accept ru.typ
> On Fri, 8 January 2016, at 1:13 p.m., gevisz wrote: > > 2016-01-08 13:50 GMT+02:00 Stroller : >> >>> On Fri, 8 January 2016, at 12:32 a.m., gevisz wrote: >>> >>> Just of curiosity compiled gtypist with nls use flag. >>> Now it accepts ru.typ! But it is a bug because nls flag >>> is supposed to only switch on the translation of the >>> corresponding menu and help messages. So, it should >>> accept ru.typ even if compiled without the nls use flag! >> >> I'm glad you're sorted. You should let the gtypist devs know of this bug. > > Thank you for your help! > > However, before turning to the gtypist devs, I should clarify one more, > may be stupid, question, namely: "Who is responsible for the correct > `functioning' of the use flags?" Because I always thought that the use > flags are a unique feature of the Gentoo distribution (and therefore, it > is the the Gentoo devs who are responsible for them) but your advice > above implies that it is not true. The ebuild is (mostly) just a wrapper for preceding software installation tools, like make and gcc. In a previous message you showed us that the Gtypist devs had asked you "Can you check whether this appears when running ./configure? Also, which arguments are used for ./configure?" In the case of the nls USE flag, the ebuild is just calling configure with certain arguments: src_configure() { econf $(use_enable nls) } src_install() { emake DESTDIR="${D}" install } Note the IUSE variable. This lists all (non-special) use flags that are used by the ebuild. This is used for the emerge -pv output, amongst other things. The package's ./configure script takes the usual --enable-nls or --disable-nls argument. We use the use_enable utility function to generate this automatically, depending on the user's USE flags (see Query Functions Reference). This is a top google hit for use_enable: https://devmanual.gentoo.org/quickstart/ Stroller.
Re: [gentoo-user] Gtypist does not accept ru.typ
2016-01-08 13:50 GMT+02:00 Stroller : > >> On Fri, 8 January 2016, at 12:32 a.m., gevisz wrote: >> >> Just of curiosity compiled gtypist with nls use flag. >> Now it accepts ru.typ! But it is a bug because nls flag >> is supposed to only switch on the translation of the >> corresponding menu and help messages. So, it should >> accept ru.typ even if compiled without the nls use flag! > > I'm glad you're sorted. You should let the gtypist devs know of this bug. > > Stroller. Thank you for your help! However, before turning to the gtypist devs, I should clarify one more, may be stupid, question, namely: "Who is responsible for the correct `functioning' of the use flags?" Because I always thought that the use flags are a unique feature of the Gentoo distribution (and therefore, it is the the Gentoo devs who are responsible for them) but your advice above implies that it is not true.
Re: [gentoo-user] Gtypist does not accept ru.typ
> On Fri, 8 January 2016, at 12:32 a.m., gevisz wrote: > > Just of curiosity compiled gtypist with nls use flag. > Now it accepts ru.typ! But it a bug because nls flag > supposed to only switch on the translation of the > corresponding menu and help messages. So, it should > accept ru.typ even if compiled without the nls use flag! I'm glad you're sorted. You should let the gtypist devs know of this bug. Stroller.
Re: [gentoo-user] Gtypist does not accept ru.typ
Just of curiosity compiled gtypist with nls use flag. Now it accepts ru.typ! But it a bug because nls flag supposed to only switch on the translation of the corresponding menu and help messages. So, it should accept ru.typ even if compiled without the nls use flag!
Re: [gentoo-user] Gtypist does not accept ru.typ
Sorry for double-posting but I again forgot to sent it to the gentoo-user list. 2016-01-07 13:28 GMT+02:00 Stroller : > >> On Wed, 6 January 2016, at 8:58 p.m., gevisz wrote: >> ... >>> If you run `sudo ebuild /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild >>> unpack` >>> you should be able to find the file with that line. >> >> I did it, and the ebuild has been unpacked to >> /var/tmp/portage/app-misc/gtypist-2.9.5/work >> >>> The "/*" and "*/" make that line into a comment, so "uncomment" it [3] by >>> removing them. Save the file. >> >> Did it in the file >> /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c. >> >>> Now you should be able to run `sudo ebuild >>> /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild install` >>> to install gtypist with the modified code. >> >> Did it as well, though without understanding why this command should >> take into account the changes I had done in the file >> /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c > > To address where you say "without understanding" - when you emerge a package, > Portage downloads a tarball of the program's source code, unpacks the source > into > a temporary working directory (/var/tmp/portage/...) and, assuming the > program is > written in a compiled language like C or C++, runs `make` [1] before > compiling it > and copying the compiled executable(s) into the right place on the live > filesystem. > > Using `ebuild /path/to/some.ebuild command` breaks down this process into > stages. > So you have unpacked it (with `ebuild unpack`), modified the source code and > then > told emerge to continue the compilation process. Thank you for your explanation. >> There was nothing in the output from the uncommented line (/encoding >> finds nothing). > > In fact, I have just checked `man ebuild` and you need to run > `sudo ebuild /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild merge` > to complete the emerge process (by merging the changed package into > the live filesystem). I apologise - that is the command I should have told > you to finish with in the first place. I have unpacked the ebuild, uncommented the line printf("encoding is %s, UTF8=%d\n", locale_encoding, isUTF8Locale); in the /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c and merged it with the command you mentioned. Everything went smooth, except that the screen output contains no word "encoding" though it should. So, I am still puzzled.
Re: [gentoo-user] Gtypist does not accept ru.typ
A resend of this message of yesterday, so that it should now appear in the list archives. > On Fri, 1 January 2016, at 4:59 p.m., gevisz wrote: > > Below is the additional details of the second answer: > >> Since you build from source on gentoo: >> Can you check whether this appears when running ./configure? >> checking for nl_langinfo and CODESET… yes You should see this by re-emerging the package and watching the screen - there should be lots of "checking for" lines during the emerge output. You should be able to scroll back through it all when the package has finished emerging. >> Also, which arguments are used for ./configure? Look in the ebuild. [1] It looks like it's configured with --with-lispdir=/$path/$to/$directory if you have the USE=emacs. It looks like it applies an xemacs compatibility patch [2], but I doubt that makes a difference. Otherwise, as far as I can see, it uses the makefile's defaults. I'm not sure what's going on with "$(use_enable nls)" in the ebuild - perhaps someone else on this list could explain what USE=nls does for this package. >> /* printf("encoding is %s, UTF8=%d\n", locale_encoding, isUTF8Locale); */ >> >> If that doesn't help, can you enable to printf above and post the >> output? If you run `sudo ebuild /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild unpack` you should be able to find the file with that line. The "/*" and "*/" make that line into a comment, so "uncomment" it [3] by removing them. Save the file. Now you should be able to run `sudo ebuild /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild install` to install gtypist with the modified code. I haven't done this in a while, so hopefully someone will correct me if I've got anything wrong. My first instinct was to epatch, but I don't think that's necessary. HTH, Stroller. [1] https://gitweb.gentoo.org/repo/gentoo.git/plain/app-misc/gtypist/gtypist-2.9.5.ebuild [2] https://gitweb.gentoo.org/repo/gentoo.git/plain/app-misc/gtypist/files/gtypist-2.8.3-xemacs-compat.patch [3] http://english.stackexchange.com/questions/33483/
Re: [gentoo-user] Gtypist does not accept ru.typ
As an addition to the previous messages, below is given the full output of # emerge gtypist Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-misc/gtypist-2.9.5::gentoo * gtypist-2.9.5.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * colemak.typ SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking gtypist-2.9.5.tar.xz to >>> /var/tmp/portage/app-misc/gtypist-2.9.5/work >>> Source unpacked in /var/tmp/portage/app-misc/gtypist-2.9.5/work >>> Preparing source in >>> /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5 ... * Applying gtypist-2.8.3-xemacs-compat.patch ... [ ok ] >>> Source prepared. >>> Configuring source in >>> /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5 ... * econf: updating gtypist-2.9.5/config.sub with /usr/share/gnuconfig/config.sub * econf: updating gtypist-2.9.5/config.guess with /usr/share/gnuconfig/config.guess ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --disable-nls EMACS=no --with-lispdir= checking for a BSD-compatible install... /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for style of include used by make... GNU checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking whether x86_64-pc-linux-gnu-gcc understands -c and -o together... yes checking dependency style of x86_64-pc-linux-gnu-gcc... none checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for gawk... (cached) gawk checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc checking whether we are using the GNU C compiler... (cached) yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... (cached) yes checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... (cached) none needed checking whether x86_64-pc-linux-gnu-gcc understands -c and -o together... (cached) yes checking dependency style of x86_64-pc-linux-gnu-gcc... (cached) none checking for library containing strerror... none required checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib checking for bison... bison -y checking for ANSI C header files... (cached) yes checking for unistd.h... (cached) yes checking alloca.h usability... yes checking alloca.h presence... yes checking for alloca.h... yes checking argz.h usability... yes checking argz.h presence... yes checking for argz.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking stdio_ext.h usability... yes checking stdio_ext.h presence... yes checking for stdio_ext.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/param.h u
Re: [gentoo-user] Gtypist does not accept ru.typ
Sorry for double-posting, the previous copy of this message has been sent only to Stroller and not to the gentoo-user mailing list. 2016-01-04 12:47 GMT+02:00 Stroller : First of all, thank you for replying and excuse for the delay. > A resend of this message, which I posted yesterday. Is the list dropping my > mail? Probably, yes, as I have received only this one. > On Fri, 1 January 2016, at 4:59 p.m., gevisz wrote: >> >> Below is the additional details of the second answer: >> >>> Since you build from source on gentoo: >>> Can you check whether this appears when running ./configure? >>> checking for nl_langinfo and CODESET… yes > > You should see this by re-emerging the package and watching the screen > - there should be lots of "checking for" lines during the emerge output. > You should be able to scroll back through it all when the package has > finished emerging. > >>> Also, which arguments are used for ./configure? > > Look in the ebuild. [1] > > It looks like it's configured with --with-lispdir=/$path/$to/$directory if > you have the USE=emacs. No, I have emacs, nls and xemacs user flags all unset for this package: $ equery uses gtypist [ Legend : U - final flag setting for installation] [: I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for app-misc/gtypist-2.9.5: U I - - emacs : Add support for GNU Emacs - - nls: Add Native Language Support (using gettext - GNU locale utilities) - - xemacs : Add support for XEmacs > It looks like it applies an xemacs compatibility patch [2], but I doubt that > makes a difference. > > Otherwise, as far as I can see, it uses the makefile's defaults. > > I'm not sure what's going on with "$(use_enable nls)" in the ebuild > - perhaps someone else on this list could explain what USE=nls does for this > package. > >>> /* printf("encoding is %s, UTF8=%d\n", locale_encoding, isUTF8Locale); */ >>> >>> If that doesn't help, can you enable to printf above and post the output? > > If you run `sudo ebuild /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild > unpack` > you should be able to find the file with that line. I did it, and the ebuild has been unpacked to /var/tmp/portage/app-misc/gtypist-2.9.5/work > The "/*" and "*/" make that line into a comment, so "uncomment" it [3] by > removing them. Save the file. Did it in the file /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c. > Now you should be able to run `sudo ebuild > /usr/portage/app-misc/gtypist/gtypist-2.9.5.ebuild install` > to install gtypist with the modified code. Did it as well, though without understanding why this command should take into account the changes I had done in the file /var/tmp/portage/app-misc/gtypist-2.9.5/work/gtypist-2.9.5/src/gtypist.c There was nothing in the output from the uncommented line (/encoding finds nothing). Any further help would be appreciated. > I haven't done this in a while, so hopefully someone will correct me if I've > got anything wrong. > My first instinct was to epatch, but I don't think that's necessary. > > HTH, > > Stroller. > > [1] > https://gitweb.gentoo.org/repo/gentoo.git/plain/app-misc/gtypist/gtypist-2.9.5.ebuild > > [2] > https://gitweb.gentoo.org/repo/gentoo.git/plain/app-misc/gtypist/files/gtypist-2.8.3-xemacs-compat.patch > > [3] http://english.stackexchange.com/questions/33483/ > >
[gentoo-user] Gtypist does not accept ru.typ
About a week ago, I have installed gtypist and tried to run it with ru.typ that comes with it: $ gtypist ru.typ gtypist: line 34: iconv() failed on 'B: Добро пожаловать!': Invalid or incomplete multibyte or wide character You should probably use a UTF-8 locale for the selected lesson! : ? What can I do about it? My $ locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=C LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= I have already posted this question on gtypist mailing list and got the answers that 1. This doesn't happen on Debian stable with the same version of gtypist and the same locale. 2. In this case, iconv shouldn't be called at all as it is only used to convert UTF-8 lessons to an 8-bit locale (like russian-8bit). Below is the additional details of the second answer: iconv conversion is only used if no UTF-8 locale is detected. This is how it is detected: (http://git.savannah.gnu.org/gitweb/?p=gtypist.git;a=blob;f=src/gtypist.c;h=7328ac6262ae9f8c3cfe89a368bd585fcd59b7e6;hb=refs/heads/branch-2.9): #ifdef MINGW locale_encoding = "UTF-8"; #else locale_encoding = nl_langinfo(CODESET); #endif isUTF8Locale = strcasecmp(locale_encoding, "UTF-8") == 0 || strcasecmp(locale_encoding, "UTF8") == 0; /* printf("encoding is %s, UTF8=%d\n", locale_encoding, isUTF8Locale); */ Since you build from source on gentoo: Can you check whether this appears when running ./configure? checking for nl_langinfo and CODESET... yes Also, which arguments are used for ./configure? If that doesn't help, can you enable to printf above and post the output?