Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

[Reuben Thomas]

On Mon, 31 Jan 2022 at 18:43, Reuben Thomas  wrote:
>
> Thanks! I'll make a new release.

I've released 2.12.

-- 
https://rrt.sc3d.org

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

[Reuben Thomas]

On Mon, 31 Jan 2022 at 18:37, Sergei Trofimovich  wrote:

> Your varian of atext-1 works on musl for me. Thank you!

Thanks! I'll make a new release.

-- 
https://rrt.sc3d.org

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

[Reuben Thomas]

Thanks very much for the analysis and suggested patch.

I don't think however that a code change is needed. Arguably, the
correct fix would be to check the return value of wprintf, but in fact
close_stdout() already checks if there was a previous error on the
stream. I think that arbitrarily setting a large buffer size is a bit
of a hack, to be honest.

So I think it's sufficient, at the cost of a slightly less nice error
message, to allow the code to proceed as at present, and instead to
change the test so that it does not specifically check for "No space
left on device", but instead just "write error".

I attach an updated version of tests/atexit-1; please could you check
that with it the test now passes with musl? (Also, of course let me
know if you disagree with my analysis!)

-- 
https://rrt.sc3d.org


atexit-1
Description: Binary data

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

[Reuben Thomas]

On Wed, 26 Jan 2022 at 12:59, Sergei Trofimovich  wrote:
>

Thanks for the report!

> From what I understand at
> 
> https://wiki.musl-libc.org/functional-differences-from-glibc.html#Character-sets-and-locale
> musl deliberately supports any char -> wchar_t (and back) conversion for
> any char in LC_CTYPE=C. And thus the multibyte-1 test will always fail
> there.

I also found this problem on macOS. I tried on my GNU/Linux system
using an ISO-8859 locale for the test, but the multibyte conversion
does not fail! (e.g. in en_GB.iso88591). I also tried with
ru_RU.KOI8-R, same result.

It seems then that it's not going to be possible in general to find a
locale that will fail. These results suggest that on some libc's,
conversion will always succeed.

Hence, I'm removing the test.

> Not sure why atexit-1 fails. It seems to rely on
> close_stdout_set_file_name() call in atexit(), but I don't see where in
> code it's registered to call.

Line 155 registers close_stdout. I can't see anything wrong with the
way this is done; I'd be very grateful if you could investigate
further.

-- 
https://rrt.sc3d.org

Re: Time for a new release of GNU hello?

[Reuben Thomas]

On Fri, 7 Jan 2022 at 20:45, Reuben Thomas  wrote:
>
> This is correct. I'm mid-flight in submitting my current GPG key to
> ftp-uplo...@gnu.org. Once I have completed the process I'll make a
> release and help Sami if he needs it.

I've released hello 2.11. Sami, if you need help with the procedure
for registering your current GPG key, I think you'll find
ftp-uplo...@gnu.org very helpful; they certainly helped me!

-- 
https://rrt.sc3d.org

Re: Time for a new release of GNU hello?

[Reuben Thomas]

On Fri, 7 Jan 2022 at 20:37, Bob Proulx  wrote:
>
> Surely GNU Hello releases are made to https://ftp.gnu.org/gnu/hello/
> not to Savannah.  That's handled by the FSF entirely.  Savannah is not
> involved in official GNU Project releases at all.

This is correct. I'm mid-flight in submitting my current GPG key to
ftp-uplo...@gnu.org. Once I have completed the process I'll make a
release and help Sami if he needs it.

-- 
https://rrt.sc3d.org

Time for a new release of GNU hello?

[Reuben Thomas]

The current release was in 2014, and is signed with a GPG key that has
since expired. Please could we have a new release? There have been
plenty of improvements since then.

-- 
https://rrt.sc3d.org

Re: Not a Big Thing But ...

[Reuben Thomas]

On Mon, 3 Jan 2022 at 20:27, Reuben Thomas  wrote:
>
> This particular one is my fault, I think: it's an old GPG key of mine. Not 
> sure why it would no longer be available though; I don't think I ever revoked 
> it. Any ideas? I'm very much at the "following HOWTOs and hoping" stage of 
> GPG use; for publishing I use gnulib's Makefile fragments.

The problem is precisely that I revoked this key.

The good news is that the most recent release (2.10) does not have this problem.

The bad news is that the most recent release was signed with a key
that has expired.

Re: [PATCH] README: fix installation instructions

[Reuben Thomas]

On 8 February 2018 at 16:57, Mathieu Lirzin  wrote:

> Hello,
>
> Christopher Diaz Riveros  writes:
>
> > Installation and building instructions point to INSTALL file, which is
> > ignored in .gitignore. Given the fact that Installation and building
> > process is already covered in README-dev, changing the instruction in
> > README seems more reasonable than creating an INSTALL file and removing
> > it from .gitignore.
>
> referencing INSTALL from README is part of GNU Coding Standards, so
> INSTALL should simply be checked in.  README-dev is for developpers not
> “regular” users.  Since GNU Hello is intended as an example package it
> shouldn't deviate from GCS.


INSTALL is a generated file (it comes from gnulib). It should not therefore
be checked into git unless there's a really good reason. Note that it
*should* be (and is!) distributed, so that when a user unpacks a
distribution tarball, it will be there, ready to refer to.​

​I suggest that README should make it more obvious that one needs to
consult README-dev if building from git.​ But that's really the only change
needed here.

-- 
https://rrt.sc3d.org

Re: GNU hello

[Reuben Thomas]

On 13 August 2017 at 06:51, Niklas Rosencrantz  wrote:
>
> On OpenBSD I had to manually set 2 environment variables: Automake and
> autonconf versions. Maybe a script could set those for the build.

Do the default versions not work? I see that hello requires autoconf
2.62 and automake 1.11.1, but these are both some years old.

> Could you specify which error my 2.7 build had?

Search the log for "error" (and ignore the mentions of "strerror"
etc.!). There is a make error.

> Is there a big difference between 2.10 and 2.7?

Yes, there are considerable changes, to the code and even more to the
build system.

Re: GNU hello

[Reuben Thomas]

On 12 August 2017 at 21:18, Niklas Rosencrantz  wrote:
> I tried both 2.7 and 2.10 and both with Ubuntu 16.04 and OpenBSD 6.1.
>
> Everything works but the manpage is empty or none.

Your build of 2.7 seems to have an error, but your 2.10 build looks OK.

I just built and installed current git on Ubuntu 16.04, and that worked fine.

Is hello.1 in your build directory OK? What happens if you run

man -l hello.1

on it?

What about the installed file, is it the same?

Re: [PATCH 2/2] hello: remove -h and -v short options

[Reuben Thomas]

On 4 January 2015 at 11:22, Sami Kerola kerol...@iki.fi wrote:


 Side lining a bit. Do you think hello package should be accompanied
 with bash completion example? I cannot see any harm with that,
 although I cannot remember any GNU package that would have completions


​I think standard support should rather be added to the bash-completions
package, i.e. hello should be added to the list of programs that get
normal bash-completion. Most standard GNU utilities are already thus
supported.​
​
I have filed a bug against bash-completion to that effect:

https://alioth.debian.org/tracker/index.php?func=detailaid=314920group_id=100114atid=413095
​

-- 
http://rrt.sc3d.org

Re: [PATCH 2/2] hello: remove -h and -v short options

[Reuben Thomas]

On 3 January 2015 at 14:06, Benno Schulenberg bensb...@justemail.net
wrote:


 On 2015-01-01 14:33, Sami Kerola wrote:
  * src/hello.c: Remove -h and -v options, and leave --help and --version
as they were.

 Maybe the GNU standards say nothing about short options
 ​​
 , but it
 is *so* much a custom for command-line tools to recognize -h and
 -V for --help and --version, that I don't think it is a good idea
 to show as an example-to-be-imitated these two long options without
 any corresponding short options.  You may wish to poke some GNU
 people about this directly.  Karl Berry?  Eric Blake?  Maybe
 mister Stallman himself?


​The reference is

https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html

​which does not mention short options, except to say that they should have
corresponding long options.


 Also, if you remove -h and -v, why not also remove -g and -t?


​Because often one wants short options, so hello illustrates them.

I think the reasoning for hello (and other programs) often eschewing short
options for --help and --version is that the letters -h and -v may often be
useful for other more frequently-used options, e.g. -v for --verbose.​

Long options are nice for scripts, for clarity, so commands don't
 need comments.  Short options are great (nearly essential) for
 typing things on the command line.


​Less so now that we have bash-completion.

​Also, given an unknown program, it's more likely that --version or --help
will succeed, so I wouldn't generally type that (until I discover that a
particular program only accepts short options, grr).

So, given the tendency of GNU programs not to have short equivalents for
these two options, I don't see why hello should have them. If you disagree,
then indeed it might be worth raising on gnu-prog-discuss; but I think
hello should reflect the GCS and general practice.

-- 
http://rrt.sc3d.org

Re: [PATCH 3/7] use gnulib to print --help and --version

[Reuben Thomas]

On 11 January 2014 11:38, Sami Kerola kerol...@iki.fi wrote:

 On 31 December 2013 23:49, Karl Berry k...@freefriends.org wrote:
   +#define PROGRAM_NAME hello
  
   Since in our case it's the same as the package name, can't you use
 that
   here, and avoid duplicating the string hello?
 
  I have feeling that might give wrong impression as an example.
 
  Anything in GNU hello is being implicitly recommended for general use.
  Normally, GNU packages have no need to deal with a special g-prefix.
  Therefore IMHO it is (much) better to omit the redundancy.

 Maybe the question is if the use of gnulib module version-etc-fsf
 should be recommended or not. If yes AUTHOR and PROGRAM_NAME are
 unavoidable. I am in favor recommending unified look  style of --help
 and --version outputs across commands, what this module tries to do.


Two points:

1. The only real problem was the duplication of the string hello, not the
use of PROGRAM_NAME. But given the progname module, which copes with the
program being installed under different names, I don't see the need for a
different way to get the name.

2. I don't see anything about AUTHOR or PROGRAM_NAME in version-etc{,-fsf}.
version-etc indeed has an array of AUTHORS, while the version_etc*
functions seem to take command_name and package arguments, which can come
presumably from program_name and PACKAGE_NAME, or whichever
autoconf-supplied macro is suitable, respectively.



 --
 Sami Kerola
 http://www.iki.fi/kerolasa/




-- 
http://rrt.sc3d.org

Re: [PATCH 3/7] use gnulib to print --help and --version

[Reuben Thomas]

On 11 January 2014 23:20, Karl Berry k...@freefriends.org wrote:

 Maybe the question is if the use of gnulib module version-etc-fsf
 should be recommended or not.

 FWIW, I don't use it, even though I maintain a FSF-copyrighted packages
 (Texinfo), because when I tried it wanted to force too much on me --
 sorry, don't recall specifics now.  That is why I didn't use it in
 Hello, either.

 Also, most (purely numerically speaking) GNU packages are not
 copyright FSF.

 I am in favor recommending unified look  style of --help

 Sure, but I am also in favor of not redundantly specifying program
 names.


(My point was that I don't think the version-etc-fsf module does force you
to be redundant.)

-- 
http://rrt.sc3d.org

Re: [PATCH 6/7] update gnulib

[Reuben Thomas]

Fine!


On 30 December 2013 11:58, Sami Kerola kerol...@iki.fi wrote:

 * gnulib: jump 293 commits a head
 ---
  gnulib | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/gnulib b/gnulib
 index 83d9dda..6b8f1dd 16
 --- a/gnulib
 +++ b/gnulib
 @@ -1 +1 @@
 -Subproject commit 83d9dda1f1623f8bbab011c6196c8a56690c1f6b
 +Subproject commit 6b8f1dd1a21ce49319795391e21adf645b64db3c
 --
 1.8.5.2





-- 
http://rrt.sc3d.org

Re: [PATCH 7/7] update NLS file sources

[Reuben Thomas]

Fine.


On 30 December 2013 11:58, Sami Kerola kerol...@iki.fi wrote:

 * .gitignore: ignore 'make po-check' files
 * Makefile.am: ignore gnulib/ directory contents when po-check'ing
 * po/POTFILES.in: add file po-check found not to be part of translations
 ---
  .gitignore | 2 ++
  Makefile.am| 2 +-
  po/POTFILES.in | 1 +
  3 files changed, 4 insertions(+), 1 deletion(-)

 diff --git a/.gitignore b/.gitignore
 index 50011b7..47409f7 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -33,6 +33,8 @@
  /Makefile
  /Makefile.in
  /man/hello.1
 +/po-check-1
 +/po-check-2
  /po/*.gmo
  /po/*.pot
  /po/.reference
 diff --git a/Makefile.am b/Makefile.am
 index 1487fdd..4210270 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -92,7 +92,7 @@ po-check:
   files=;   \
   for file in $$($(CVS_LIST_EXCEPT)) `find * -name '*.[ch]'`; do \
 case $$file in  \
 -   djgpp/* | man/*) continue;; \
 +   gnulib/* | man/*) continue;;\
 esac;   \
 case $$file in  \
 *.[ch]) \
 diff --git a/po/POTFILES.in b/po/POTFILES.in
 index 1b1ac82..6e94b34 100644
 --- a/po/POTFILES.in
 +++ b/po/POTFILES.in
 @@ -8,6 +8,7 @@

  # Package source files.
  src/hello.c
 +src/system.h

  # Gnulib source files.
  lib/closeout.c
 --
 1.8.5.2





-- 
http://rrt.sc3d.org

Re: [PATCH] fix new format when printing multiple lines

[Reuben Thomas]

On 23 December 2013 22:30, Reuben Thomas r...@sc3d.org wrote:


 I don't see a way around this; nor do I think Unicode should be thought of
 something that is a specific programming feature: multi-byte encodings
 are the commonest way of dealing with internationalised text, and treating
 them as a bolt-on extra automatically disenfranchises all the communities
 that need them for their languages, which these days, given the demise of
 8-bit encodings, is pretty much anything other than English.


There's a further advantage to showing how to deal with multi-byte
encodings in C, which is that it may scare some programmers into not using
C when they see how horrible it is. (As if the horrors of handling text in
C weren't enough!)

-- 
http://rrt.sc3d.org

Re: [PATCH] fix new format when printing multiple lines

[Reuben Thomas]

On 23 December 2013 22:32, Karl Berry k...@freefriends.org wrote:

 I guess we'll have to agree to disagree.  I gave up maintainership of
 hello, so do what you will.


Since hello is supposed to be an example within the GNU project, I'd rather
not simply impose my views; and I think this is a subject worth discussing.
To me, the use of i18n'ed text is absolutely basic, as otherwise, users of
most languages are excluded. GNU gettext is basic infrastructure, and it
seems reasonable that at some point in even a basic program that uses
internationalised text, it would have to do other than simply reproduce
that text. There are plenty of other specific programming features, such
as command-line parsing, that are of necessity showcased in GNU hello,
precisely because such features are required by almost all programs. If the
goal of hello were simply to showcase *build* infrastructure, then it could
be much simpler, and really ought to do nothing other than literally say
hello (still i18n'ed, of course!).

-- 
http://rrt.sc3d.org

Re: option -n ignored if used in conjunction with -g

[Reuben Thomas]

On 8 January 2013 14:13, Fabrizio Sebastiani fabri...@bzimage.it wrote:

 sebastiani@pcdiesis:~$ hello -n
 +---+
 | Hello, world! |
 +---+
 sebastiani@pcdiesis:~$ hello -g=ciaociao
 =ciaociao
 sebastiani@pcdiesis:~$ hello -g ciaociao
 ciaociao
 sebastiani@pcdiesis:~$ hello -g ciaociao -n
 +---+
 | Hello, world! |
 +---+
 sebastiani@pcdiesis:~$ hello -n -g ciaociao
 ciaociao
 sebastiani@pcdiesis:~$ hello -t -g ciaociao
 ciaociao
 sebastiani@pcdiesis:~$


This is not a bug, it's how it should work. However, I agree that the
documentation is confusing. Watch:

 $ hello -g ciaociao -n
++
| Hello, world! |
++

I will remove the word format from the documentation, so that it says:

-  -t, --traditional   use traditional greeting format\n\
-  -n, --next-generation   use next-generation greeting format\n\
+  -t, --traditional   use traditional greeting\n\
+  -n, --next-generation   use next-generation greeting\n\

-- 
http://rrt.sc3d.org

Re: Possible problem / misunderstanding in make manual

[Reuben Thomas]

Thanks for the explanation; good to have it on file, at the very least.

bzr conversion probably done

[Reuben Thomas]

I think I've done the conversion successfully using tailor. I am now
waiting for the bzr repo on Savannah to be erased so I can re-upload
the new repo.

-- 
http://rrt.sc3d.org