Bug 1048015

help2man uses LD_PRELOAD to implement i18n. I (and others) consider this to be a security risk and therefore do not support it in Fedora.

(In reply to Ralf Corsepius from comment #1)
> help2man uses LD_PRELOAD to implement i18n. I (and others) consider this to
> be a security risk and therefore do not support it in Fedora.

OK. Then please fix the spec file header to make sure that users get a simple way to build their own package with i18n support.

(In reply to Mario Blättermann from comment #2)
> (In reply to Ralf Corsepius from comment #1)
> > help2man uses LD_PRELOAD to implement i18n. I (and others) consider this to
> > be a security risk and therefore do not support it in Fedora.
> 
> OK. Then please fix the spec file header to make sure that users get a
> simple way to build their own package with i18n support.

rpmbuild ... --with nls help2man.spec
rsp.
mock ... --with=nls help2man*.src.rpm

Are supposed to do what you are asking for.

BTW: i18n is disabled in Fedora ever since help2man packaged in Fedora. IIRC, you are the 2nd person to ask for i18n in all these years (almost 10).

(In reply to Ralf Corsepius from comment #3)
> rpmbuild ... --with nls help2man.spec
> rsp.
> mock ... --with=nls help2man*.src.rpm
> 
Yes, I know, but the spec file header says:
# --with nls ... build this package with --enable-nls
The --enable-nls option doesn't work for me, but "--with nls" does it well.

> 
> BTW: i18n is disabled in Fedora ever since help2man packaged in Fedora.
> IIRC, you are the 2nd person to ask for i18n in all these years (almost 10).

Doesn't bother me at all ;) Maybe I should tell what I like to do with help2man:
The Recutils project generates man pages at build time from the --help output as usual. With the -L option we could do this the same way for all supported languages without the need of a translator. But now I know this wouldn't work in Fedora, so we have to look for another tool, such as po4a or anything else.

(In reply to Mario Blättermann from comment #4)
> (In reply to Ralf Corsepius from comment #3)
> > rpmbuild ... --with nls help2man.spec
> > rsp.
> > mock ... --with=nls help2man*.src.rpm
> > 
> Yes, I know, but the spec file header says:
> # --with nls ... build this package with --enable-nls
> The --enable-nls option doesn't work for me, but "--with nls" does it well.

The configure script takes "--enable*", mock/rpmbuild however only accept "--with".

I.e. mock --with nls help2man*.src.rpm will append
--enable-nls to %configure.

> > 
> > BTW: i18n is disabled in Fedora ever since help2man packaged in Fedora.
> > IIRC, you are the 2nd person to ask for i18n in all these years (almost 10).
> 
> Doesn't bother me at all ;) Maybe I should tell what I like to do with
> help2man:
> The Recutils project generates man pages at build time from the --help
> output as usual.

This "usual" is a false assumption.

> With the -L option we could do this the same way for all
> supported languages without the need of a translator.

Alternatively you could generate them offline and bundle them with the sources.

It also avoids exposing your packages to the risks of generators producing 
broken/dysfunctional results.

> But now I know this
> wouldn't work in Fedora, so we have to look for another tool, such as po4a
> or anything else.
Feel free to do so. 

FWIW: po4a is a real mess. I would not use it anywhere.

(In reply to Ralf Corsepius from comment #5)
> > The Recutils project generates man pages at build time from the --help
> > output as usual.
> 
> This "usual" is a false assumption.
> 
"Usual" refers to what help2man usually does. Of course I know that the Recutils way is not common to most other projects. But in this case, it avoids handling a second *po file for the man pages because all of the strings are also available in the UI. 
> 
> FWIW: po4a is a real mess. I would not use it anywhere.

We use it in man-pages-de for creating translated versions. Works fine so far. But that's not the topic here.

(In reply to Ralf Corsepius from comment #5)
> (In reply to Mario Blättermann from comment #4)
> > (In reply to Ralf Corsepius from comment #3)
> > > rpmbuild ... --with nls help2man.spec
> > > rsp.
> > > mock ... --with=nls help2man*.src.rpm
> > > 
> > Yes, I know, but the spec file header says:
> > # --with nls ... build this package with --enable-nls
> > The --enable-nls option doesn't work for me, but "--with nls" does it well.
> 
> The configure script takes "--enable*", mock/rpmbuild however only accept
> "--with".
> 
> I.e. mock --with nls help2man*.src.rpm will append
> --enable-nls to %configure.
> 
Doesn't matter what rpmbuild or mock do internally. For rebuilding a package with an already defined condition users actually don't have to know what options the configure script gets additionally. Would it be possible to clarify that by removing the "--enable-nls" option from the spec file header or at least explaining that --enable-nls will be added internally as an option for %configure? In the current state it is confusing for me.

(In reply to Mario Blättermann from comment #6)
> (In reply to Ralf Corsepius from comment #5)
> > > The Recutils project generates man pages at build time from the --help
> > > output as usual.
> > 
> > This "usual" is a false assumption.
> > 
> "Usual" refers to what help2man usually does. Of course I know that the
> Recutils way is not common to most other projects. But in this case, it
> avoids handling a second *po file for the man pages because all of the
> strings are also available in the UI. 
> > 
> > FWIW: po4a is a real mess. I would not use it anywhere.
> 
> We use it in man-pages-de for creating translated versions. Works fine so
> far. But that's not the topic here.
I also co-maintain po4a in Fedora (Actually, I am the defacto primary maintainer, because the formal primary maintainer has gone AWOL) and I can not avoiding telling you that po4a is a true mess.

> (In reply to Ralf Corsepius from comment #5)
> > (In reply to Mario Blättermann from comment #4)
> > > (In reply to Ralf Corsepius from comment #3)
> > > > rpmbuild ... --with nls help2man.spec
> > > > rsp.
> > > > mock ... --with=nls help2man*.src.rpm
> > > > 
> > > Yes, I know, but the spec file header says:
> > > # --with nls ... build this package with --enable-nls
> > > The --enable-nls option doesn't work for me, but "--with nls" does it well.
> > 
> > The configure script takes "--enable*", mock/rpmbuild however only accept
> > "--with".
> > 
> > I.e. mock --with nls help2man*.src.rpm will append
> > --enable-nls to %configure.
> > 
> Doesn't matter what rpmbuild or mock do internally. For rebuilding a package
> with an already defined condition users actually don't have to know what
> options the configure script gets additionally. Would it be possible to
> clarify that by removing the "--enable-nls" option from the spec file header
> or at least explaining that --enable-nls will be added internally as an
> option for %configure? In the current state it is confusing for me.
Pardon, I do not share your views, and consider you to be nit-picking because of your personal stylish preferences.