GNU bug report logs - #45368
[PATCH core-updates 0/3] Help2man updates

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45368 in the body.
You can then email your comments to 45368 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: guix-patches <at> gnu.org
Subject: [PATCH core-updates 0/3] Help2man updates
Date: Tue, 22 Dec 2020 14:01:02 +0100

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

Message #8 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: 45368 <at> debbugs.gnu.org
Subject: [PATCH core-updates 1/3] gnu: Add perl-gettext.
Date: Fri, 11 Dec 2020 23:45:26 +0100

* gnu/packages/perl.scm (perl-gettext): New module imported from CPAN.
---
 gnu/packages/perl.scm | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

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

Message #11 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: 45368 <at> debbugs.gnu.org
Subject: [PATCH core-updates 2/3] gnu: help2man: Add optional dependencies.
Date: Fri, 11 Dec 2020 23:46:58 +0100

* 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(-)

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

Message #14 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: 45368 <at> debbugs.gnu.org
Subject: [PATCH core-updates 3/3] gnu: help2man: Update to 1.47.16.
Date: Fri, 11 Dec 2020 23:47:47 +0100

* gnu/packages/man.scm (help2man): Update to version 1.47.16.
---
 gnu/packages/man.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

Message #17 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
Cc: 45368 <at> debbugs.gnu.org
Subject: Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
Date: Sun, 03 Jan 2021 16:12:31 +0100

¡Hola!

Miguel Ángel Arruga Vivas <rosen644835 <at> 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’.

Message #20 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 45368 <at> debbugs.gnu.org
Subject: Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
Date: Wed, 06 Jan 2021 17:45:06 +0100

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 <at> 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

Message #23 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
Cc: 45368 <at> debbugs.gnu.org
Subject: Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
Date: Thu, 07 Jan 2021 12:00:56 +0100

Hi!

Miguel Ángel Arruga Vivas <rosen644835 <at> 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 <at> 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’.

Message #26 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 45368 <at> debbugs.gnu.org
Subject: Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
Date: Thu, 07 Jan 2021 13:52:12 +0100

Hi,

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

> Hi!
>
> Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com> skribis:
>> Ludovic Courtès <ludo <at> 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

Message #29 received at 45368 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
Cc: 45368 <at> debbugs.gnu.org
Subject: Re: bug#45368: [PATCH core-updates 0/3] Help2man updates
Date: Sun, 21 Feb 2021 23:00:28 +0100

Hi,

Apologies for the laaaate reply!

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

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi!
>>
>> Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com> skribis:
>>> Ludovic Courtès <ludo <at> 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’.

Message #34 received at 45368-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Miguel Ángel Arruga Vivas <rosen644835 <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 45368-done <at> debbugs.gnu.org
Subject: Re: [bug#45368] [PATCH core-updates 0/3] Help2man updates
Date: Sat, 21 Oct 2023 15:45:17 -0400

Hello,

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

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.