* 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
* 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
* 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
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
¡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’.
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
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’.
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
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’.
Hello,
Miguel Ángel Arruga Vivas <rosen644835@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