mbox series

[bug#45368,core-updates,0/3] Help2man updates

Message ID 875z4uyoz5.fsf@gmail.com
Headers show
Series Help2man updates | expand

Message

Miguel Arruga Vivas Dec. 22, 2020, 1:01 p.m. UTC
Hi,

The following patches do some work on help2man, namely:
1. Allow the generation of localized manual pages.
2. Update the package to the latest version.

To perform the first objective, the library perl-gettext was imported
from CPAN.  Its path is encoded directly on the resulting binary to
ensure it is loaded, as perl and the library should be propagated to the
environment in order to achieve the same result with PERL5LIB.

Nonetheless, currently there are two open issues with this approach:

- The library used for a cross compilation could be different, but the
  generated version is used for its own documentation generation.  Are
  the inputs correctly placed?  Should it be patched on a later stage to
  the final input?

- The compilation tries to generate translated man pages and sets LC_ALL
  to values not available on glibc-utf8-locales, therefore only
  languages available there have their manual page properly translated,
  such as french.  You can see the following lines (and more) on the
  build log, which warn about this issue:
  --------------------------------8<-------------------------------- sh:
  warning: setlocale: LC_ALL: cannot change locale (uk_UA.UTF-8) sh:
  warning: setlocale: LC_ALL: cannot change locale (vi_VN.UTF-8)
  -------------------------------->8--------------------------------

IMHO, a change on gnu-build-system to allow the selection of the locales
used for the build could be the best way forward, but I haven't
implemented it yet.  WDYT?

Happy hacking!
Miguel

Comments

Ludovic Courtès Jan. 3, 2021, 3:12 p.m. UTC | #1
¡Hola!

Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:

> The following patches do some work on help2man, namely:
> 1. Allow the generation of localized manual pages.
> 2. Update the package to the latest version.
>
> To perform the first objective, the library perl-gettext was imported
> from CPAN.  Its path is encoded directly on the resulting binary to
> ensure it is loaded, as perl and the library should be propagated to the
> environment in order to achieve the same result with PERL5LIB.

Nice.

> Nonetheless, currently there are two open issues with this approach:
>
> - The library used for a cross compilation could be different, but the
>   generated version is used for its own documentation generation.  Are
>   the inputs correctly placed?  Should it be patched on a later stage to
>   the final input?

If the problem is just the generation of help2man’s own documentation
when cross-compiling, perhaps we need to add itself as a native input
when cross-compiling?

Anyhow that doesn’t sound like a showstopper to me.

> - The compilation tries to generate translated man pages and sets LC_ALL
>   to values not available on glibc-utf8-locales, therefore only
>   languages available there have their manual page properly translated,
>   such as french.  You can see the following lines (and more) on the
>   build log, which warn about this issue:
>   --------------------------------8<-------------------------------- sh:
>   warning: setlocale: LC_ALL: cannot change locale (uk_UA.UTF-8) sh:
>   warning: setlocale: LC_ALL: cannot change locale (vi_VN.UTF-8)
>   -------------------------------->8--------------------------------
>
> IMHO, a change on gnu-build-system to allow the selection of the locales
> used for the build could be the best way forward, but I haven't
> implemented it yet.  WDYT?

Yes, that’s a good idea.  There’s already a procedure to generate a
locale package IIRC.  We just have to make sure its result is properly
memoized so that performance doesn’t suffer.

Thanks!

Ludo’.
Miguel Arruga Vivas Jan. 6, 2021, 4:45 p.m. UTC | #2
Hi,

Sorry for the delay.  I've pushed these changes from 4343ca8ba5 to
cfe606572d, with an additional TODO comment on 378df42fc5 about the
not-so-translated manual pages.

Ludovic Courtès <ludo@gnu.org> writes:

> If the problem is just the generation of help2man’s own documentation
> when cross-compiling, perhaps we need to add itself as a native input
> when cross-compiling?

Yup, that sounds the cleanest solution.  Nonetheless...

> Anyhow that doesn’t sound like a showstopper to me.

It currently isn't at all, as it says as soon as I tried:

  [...] build system `perl' does not support cross builds

Also, they use a LD_PRELOAD library for the translation, which seems
suspicious too.

>> - The compilation tries to generate translated man pages and sets LC_ALL
>>   to values not available on glibc-utf8-locales, therefore only
>>   languages available there have their manual page properly translated,
>>   such as french.  You can see the following lines (and more) on the
>>   build log, which warn about this issue:
>>   --------------------------------8<-------------------------------- sh:
>>   warning: setlocale: LC_ALL: cannot change locale (uk_UA.UTF-8) sh:
>>   warning: setlocale: LC_ALL: cannot change locale (vi_VN.UTF-8)
>>   -------------------------------->8--------------------------------
>>
>> IMHO, a change on gnu-build-system to allow the selection of the locales
>> used for the build could be the best way forward, but I haven't
>> implemented it yet.  WDYT?
>
> Yes, that’s a good idea.  There’s already a procedure to generate a
> locale package IIRC.  We just have to make sure its result is properly
> memoized so that performance doesn’t suffer.

I was thinking about the implicit input "locales" and replacing it with
a package generated based on the arguments provided to the build system,
but I guess you're thinking about build-locale from (gnu build locale)
and its usage for the system locales on (gnu system locale).  Should it
be then another derivation at (guix build-system gnu) level?  Any
pointer about this is more than welcome.

> Thanks!

Thank you. :-)

Happy hacking!
Miguel
Ludovic Courtès Jan. 7, 2021, 11 a.m. UTC | #3
Hi!

Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:

> Sorry for the delay.  I've pushed these changes from 4343ca8ba5 to
> cfe606572d, with an additional TODO comment on 378df42fc5 about the
> not-so-translated manual pages.

Cool.

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> If the problem is just the generation of help2man’s own documentation
>> when cross-compiling, perhaps we need to add itself as a native input
>> when cross-compiling?
>
> Yup, that sounds the cleanest solution.  Nonetheless...
>
>> Anyhow that doesn’t sound like a showstopper to me.
>
> It currently isn't at all, as it says as soon as I tried:
>
>   [...] build system `perl' does not support cross builds
>
> Also, they use a LD_PRELOAD library for the translation, which seems
> suspicious too.

Hmm OK.

>> Yes, that’s a good idea.  There’s already a procedure to generate a
>> locale package IIRC.  We just have to make sure its result is properly
>> memoized so that performance doesn’t suffer.
>
> I was thinking about the implicit input "locales" and replacing it with
> a package generated based on the arguments provided to the build system,
> but I guess you're thinking about build-locale from (gnu build locale)
> and its usage for the system locales on (gnu system locale).  Should it
> be then another derivation at (guix build-system gnu) level?  Any
> pointer about this is more than welcome.

I was actually thinking about a variant of ‘make-glibc-utf8-locales’
that… never got committed?!

  https://issues.guix.gnu.org/44075#7

The patch you proposed there LGTM.  Looks like you forgot to commit it.
:-)

Ludo’.
Miguel Arruga Vivas Jan. 7, 2021, 12:52 p.m. UTC | #4
Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> If the problem is just the generation of help2man’s own documentation
>>> when cross-compiling, perhaps we need to add itself as a native input
>>> when cross-compiling?
>>
>> Yup, that sounds the cleanest solution.  Nonetheless...
>>
>>> Anyhow that doesn’t sound like a showstopper to me.
>>
>> It currently isn't at all, as it says as soon as I tried:
>>
>>   [...] build system `perl' does not support cross builds
>>
>> Also, they use a LD_PRELOAD library for the translation, which seems
>> suspicious too.
>
> Hmm OK.

Would it make sense to keep a help2man-minimal without nls support (or a
new help2man-with-nls variable) for bootstrapping purposes?

>>> Yes, that’s a good idea.  There’s already a procedure to generate a
>>> locale package IIRC.  We just have to make sure its result is properly
>>> memoized so that performance doesn’t suffer.
>>
>> I was thinking about the implicit input "locales" and replacing it with
>> a package generated based on the arguments provided to the build system,
>> but I guess you're thinking about build-locale from (gnu build locale)
>> and its usage for the system locales on (gnu system locale).  Should it
>> be then another derivation at (guix build-system gnu) level?  Any
>> pointer about this is more than welcome.
>
> I was actually thinking about a variant of ‘make-glibc-utf8-locales’
> that… never got committed?!
>
>   https://issues.guix.gnu.org/44075#7
>
> The patch you proposed there LGTM.  Looks like you forgot to commit it.
> :-)

And now you know why I wasn't getting it, I even forgot that it was
already there.  :-(

There's still a dependency chain between (gnu packages base) and (gnu
packages man)---I tried to use the full glibc-locales to do the test
before remembering this, so I need to spend a bit of time on this too.

Happy hacking,
Miguel
Ludovic Courtès Feb. 21, 2021, 10 p.m. UTC | #5
Hi,

Apologies for the laaaate reply!

Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> If the problem is just the generation of help2man’s own documentation
>>>> when cross-compiling, perhaps we need to add itself as a native input
>>>> when cross-compiling?
>>>
>>> Yup, that sounds the cleanest solution.  Nonetheless...
>>>
>>>> Anyhow that doesn’t sound like a showstopper to me.
>>>
>>> It currently isn't at all, as it says as soon as I tried:
>>>
>>>   [...] build system `perl' does not support cross builds
>>>
>>> Also, they use a LD_PRELOAD library for the translation, which seems
>>> suspicious too.
>>
>> Hmm OK.
>
> Would it make sense to keep a help2man-minimal without nls support (or a
> new help2man-with-nls variable) for bootstrapping purposes?

‘help2man-minimal’ sounds like a good idea, yes.

Would that solve the problem at hand?

>>>> Yes, that’s a good idea.  There’s already a procedure to generate a
>>>> locale package IIRC.  We just have to make sure its result is properly
>>>> memoized so that performance doesn’t suffer.
>>>
>>> I was thinking about the implicit input "locales" and replacing it with
>>> a package generated based on the arguments provided to the build system,
>>> but I guess you're thinking about build-locale from (gnu build locale)
>>> and its usage for the system locales on (gnu system locale).  Should it
>>> be then another derivation at (guix build-system gnu) level?  Any
>>> pointer about this is more than welcome.
>>
>> I was actually thinking about a variant of ‘make-glibc-utf8-locales’
>> that… never got committed?!
>>
>>   https://issues.guix.gnu.org/44075#7
>>
>> The patch you proposed there LGTM.  Looks like you forgot to commit it.
>> :-)
>
> And now you know why I wasn't getting it, I even forgot that it was
> already there.  :-(
>
> There's still a dependency chain between (gnu packages base) and (gnu
> packages man)---I tried to use the full glibc-locales to do the test
> before remembering this, so I need to spend a bit of time on this too.

OK.

Ludo’.