bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] pod2man --utf8 -> wget build failure


From: Tim Ruehsen
Subject: Re: [Bug-wget] pod2man --utf8 -> wget build failure
Date: Tue, 24 May 2016 12:55:50 +0200
User-agent: KMail/4.14.10 (Linux/4.5.0-2-amd64; KDE/4.14.20; x86_64; ; )

Hi Karl,

thanks for pointing out those issue(s).

> Perl... Exactly which version does not matter.

It matters. AFAICS, Perl 5.8 introduced UTF-8 in 2002.
So perhaps your system is even older !?
(Just out of curiosity, what is it ?)

That lets me ask why are you sticking around with old software *and* at the 
same time you try to build latest software (at least wget).

I wish I had the resources and the time to support such requests, really.
But reality is that we (the maintainers / contributors) have our dev systems 
plus a handful of VMs to test on. There is also CI where we cover not-so-
recent GNU/Linux and MacOSX.

While we could now come with some patches to satisfy you, we are not able to 
test them in your environment.

The solution is that you simply come up with a patch (or set of patches) that 
works for you - and we will see if that works for us. If we reject a patch as 
a WONTFIX, you still have the possibility to keep it as private patch that 
fits your needs.


BTW, 7-bit ASCII f*cks up my family name (Rühsen). How do you like to display 
it in your docs, 'ruhsen' or 'ruehsen' ? Both not correct, (almost) insulting 
and heavily ignoring the fact that there are other character sets than 
english/US. Not using UTF-8 is not an option for me.
Just my general point of view - not meant personally.

Tim

On Monday 23 May 2016 20:56:19 Karl Berry wrote:
> Hi Giuseppe (and anyone),
> 
> wget's doc/Makefile.am assumes that --utf8 is supported:
> 
> $(MAN): wget.pod
>       $(POD2MAN) --center [...] --utf8 $? > $@
> 
> (It's also assuming GNU make with the $? and $@, I believe, but never
> mind, that's a different issue.)
> 
> Unfortunately, not all pod2man's have --utf8.  It was introduced in a
> somewhat recent version of Perl.  Exactly which version does not matter.
> 
> Thus, the main bug: as far as I can see, the standard build process
> (configure && make install) should not invoke pod2man at all, any more
> than it should invoke makeinfo, and for all the same reasons.  That is,
> the tarball should ship with the pod2man-generated file, just as it
> ships with the makeinfo-generated file.
> 
> Alternatives:
> 
> - configure could check if pod2man supports --utf8 and avoid using it if
> unsupported.
> 
> - not that I expect you to change it, but the conversion of the Texinfo
> manual to POD seems baroque and unnecessary to me.  You could have a
> minimal man page created with help2man instead, like most GNU programs.
> 
> - I have even less expectation of you changing this, but the usage of
> @documentencoding UTF-8 (when unnecessary) in Texinfo is unfriendly to
> non-UTF-8 programmers.  UTF-8 quotes appear as binary
> garbage in the C locale, thus the manual becomes unusable, since quotes
> are so pervasive in Texinfo output.  (I'll spare you the reasons why I
> use LC_ALL=C, but will ask you to believe me, I don't do it lightly.)
> 
> At any rate, I don't see that UTF-8 actually gains anything here
> (http://git.savannah.gnu.org/cgit/wget.git/commit/?id=8d4bb928b921b7620f1b3d
> 61f04ed848138c3d7c). As far as I can see, the names can be represented
> perfectly well using Texinfo -- a 7-bit ASCII input file using Texinfo
> commands and no
> @documentencoding command should work fine.  (If there are some
> diacritics unsupported by Texinfo, we can change that.)  The HTML/PDF
> output will be correct and have the accents, and the plain text output
> will do as well as it can.
> 
> What's unnecessary, indeed undesirable, are the @iftex conditionals that
> you removed.  If the @iftex branches were restored over the direct
> UTF-8 input, all the problems would go away ... --best, karl.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]