Re: [gentoo-user] Gtypist does not accept ru.typ

2016-01-09 Thread 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.

Re: [gentoo-user] Gtypist does not accept ru.typ

2016-01-09 Thread gevisz 
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

2016-01-08 Thread 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 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

2016-01-08 Thread gevisz 
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

2016-01-07 Thread gevisz 
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

2016-01-07 Thread gevisz 
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

2016-01-07 Thread Stroller 
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

2016-01-06 Thread gevisz 
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

Re: [gentoo-user] Gtypist does not accept ru.typ

2016-01-06 Thread gevisz 
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/
>
>