[PATCH core-updates 0/3] Help2man updates

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Miguel Ángel Arruga Vivas
Owner
unassigned
Submitted by
Miguel Ángel Arruga Vivas
Severity
normal
M
M
Miguel Ángel Arruga Vivas wrote on 22 Dec 2020 14:01
(address . guix-patches@gnu.org)
875z4uyoz5.fsf@gmail.com
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
M
M
Miguel Ángel Arruga Vivas wrote on 11 Dec 2020 23:45
[PATCH core-updates 1/3] gnu: Add perl-gettext.
(address . 45368@debbugs.gnu.org)
871rfiyot1.fsf@gmail.com
* gnu/packages/perl.scm (perl-gettext): New module imported from CPAN.
---
gnu/packages/perl.scm | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

Toggle diff (34 lines)
diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 9c6530f1ff..06fe2fe7a7 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -4931,6 +4931,25 @@ vaguely inspired by John Ousterhout's Tk_ParseArgv.")
(home-page "https://metacpan.org/release/Getopt-Tabular")
(license (package-license perl))))
+(define-public perl-gettext
+ (package
+ (name "perl-gettext")
+ (version "1.07")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append "mirror://cpan/authors/id/P/PV/PVANDRY"
+ "/gettext-" version ".tar.gz"))
+ (sha256
+ (base32
+ "05cwqjxxary11di03gg3fm6j9lbvg1dr2wpr311c1rwp8salg7ch"))))
+ (build-system perl-build-system)
+ (home-page "https://metacpan.org/release/gettext")
+ (synopsis "Perl bindings for POSIX i18n gettext functions")
+ (description
+ "Locale::gettext provides an object oriented interface to the
+internationalization functions provided by the C library.")
+ (license license:perl-license)))
+
(define-public perl-graph
(package
(name "perl-graph")

base-commit: b50341dba9811c048bed852c0279b828c7ddba66
--
2.29.2
M
M
Miguel Ángel Arruga Vivas wrote on 11 Dec 2020 23:46
[PATCH core-updates 2/3] gnu: help2man: Add optional dependencies.
(address . 45368@debbugs.gnu.org)
87wnxaxa6a.fsf@gmail.com
* gnu/packages/man.scm (help2man)[inputs]: Add perl-gettext and
gettext-minimal to the inputs.
---
gnu/packages/man.scm | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)

Toggle diff (44 lines)
diff --git a/gnu/packages/man.scm b/gnu/packages/man.scm
index 0eadd9d153..62cbe49eec 100644
--- a/gnu/packages/man.scm
+++ b/gnu/packages/man.scm
@@ -34,6 +34,7 @@
#:use-module (gnu packages dbm)
#:use-module (gnu packages flex)
#:use-module (gnu packages gawk)
+ #:use-module (gnu packages gettext)
#:use-module (gnu packages groff)
#:use-module (gnu packages less)
#:use-module (gnu packages perl)
@@ -270,15 +271,23 @@ Linux kernel and C library interfaces employed by user-space programs.")
"08q5arxz4j4pyx5q4712c2rn7p7dw7as9xg38yvmsh1c3ynvpy5p"))))
(build-system gnu-build-system)
(arguments `(;; There's no `check' target.
- #:tests? #f))
+ #:tests? #f
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'patch-help2man-with-perl-gettext
+ (lambda* (#:key inputs #:allow-other-keys)
+ (let ((lib (assoc-ref inputs "perl-gettext"))
+ (fmt "use lib '~a/lib/perl5/site_perl';~%~a"))
+ (substitute* "help2man.PL"
+ (("^use Locale::gettext.*$" load)
+ (format #f fmt lib load))))
+ #t)))))
(inputs
`(("perl" ,perl)
- ;; TODO: Add these optional dependencies.
- ;; ("perl-LocaleGettext" ,perl-LocaleGettext)
- ;; ("gettext" ,gettext-minimal)
- ))
+ ("perl-gettext" ,perl-gettext)))
(native-inputs
- `(("perl" ,perl)))
+ `(("perl" ,perl)
+ ("gettext" ,gettext-minimal)))
(home-page "https://www.gnu.org/software/help2man/")
(synopsis "Automatically generate man pages from program --help")
(description
--
2.29.2
M
M
Miguel Ángel Arruga Vivas wrote on 11 Dec 2020 23:47
[PATCH core-updates 3/3] gnu: help2man: Update to 1.47.16.
(address . 45368@debbugs.gnu.org)
87sg7yxa53.fsf@gmail.com
* gnu/packages/man.scm (help2man): Update to version 1.47.16.
---
gnu/packages/man.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Toggle diff (24 lines)
diff --git a/gnu/packages/man.scm b/gnu/packages/man.scm
index 62cbe49eec..f16cc7bed6 100644
--- a/gnu/packages/man.scm
+++ b/gnu/packages/man.scm
@@ -260,7 +260,7 @@ Linux kernel and C library interfaces employed by user-space programs.")
(define-public help2man
(package
(name "help2man")
- (version "1.47.13")
+ (version "1.47.16")
(source
(origin
(method url-fetch)
@@ -268,7 +268,7 @@ Linux kernel and C library interfaces employed by user-space programs.")
version ".tar.xz"))
(sha256
(base32
- "08q5arxz4j4pyx5q4712c2rn7p7dw7as9xg38yvmsh1c3ynvpy5p"))))
+ "1x586h7wvripcay35kdh2kvydx84y8yy93ffjah2rqw6bc65iy1y"))))
(build-system gnu-build-system)
(arguments `(;; There's no `check' target.
#:tests? #f
--
2.29.2
L
L
Ludovic Courtès wrote on 3 Jan 2021 16:12
Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
(name . Miguel Ángel Arruga Vivas)(address . rosen644835@gmail.com)(address . 45368@debbugs.gnu.org)
877dou12cg.fsf@gnu.org
¡Hola!

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

Toggle quote (9 lines)
> 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.

Toggle quote (7 lines)
> 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.

Toggle quote (14 lines)
> - 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’.
M
M
Miguel Ángel Arruga Vivas wrote on 6 Jan 2021 17:45
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 45368@debbugs.gnu.org)
87r1my10bx.fsf@gmail.com
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:

Toggle quote (4 lines)
> 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...

Toggle quote (2 lines)
> 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.

Toggle quote (18 lines)
>> - 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.

Toggle quote (2 lines)
> Thanks!

Thank you. :-)

Happy hacking!
Miguel
L
L
Ludovic Courtès wrote on 7 Jan 2021 12:00
(name . Miguel Ángel Arruga Vivas)(address . rosen644835@gmail.com)(address . 45368@debbugs.gnu.org)
87a6tlhuzb.fsf@gnu.org
Hi!

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

Toggle quote (4 lines)
> 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.

Toggle quote (17 lines)
> 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.

Toggle quote (11 lines)
>> 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?!


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

Ludo’.
M
M
Miguel Ángel Arruga Vivas wrote on 7 Jan 2021 13:52
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 45368@debbugs.gnu.org)
87y2h4zz7n.fsf@gmail.com
Hi,

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

Toggle quote (22 lines)
> 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?

Toggle quote (19 lines)
>>> 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
L
L
Ludovic Courtès wrote on 21 Feb 2021 23:00
Re: bug#45368: [PATCH core-updates 0/3] Help2man updates
(name . Miguel Ángel Arruga Vivas)(address . rosen644835@gmail.com)(address . 45368@debbugs.gnu.org)
87blcdgjyb.fsf_-_@gnu.org
Hi,

Apologies for the laaaate reply!

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

Toggle quote (27 lines)
> 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?

Toggle quote (26 lines)
>>>> 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’.
M
M
Maxim Cournoyer wrote on 21 Oct 2023 21:45
Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
(name . Miguel Ángel Arruga Vivas)(address . rosen644835@gmail.com)
87il6zdak2.fsf@gmail.com
Hello,

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

Toggle quote (6 lines)
> 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.

Cool, closing.

--
Thanks,
Maxim
Closed
?