Re: announce-gen usage feedback

[Simon Josefsson]

Bruno Haible <bruno@clisp.org> writes:

> Hi Simon,
>
> Two remarks regarding 'announce-gen':
>
> 1) I used the command
>    $ $GNULIB_SRCDIR/build-aux/announce-gen --release-type stable \
>        --package-name libunistring --previous-version 0.9.10 \
>        --current-version 1.0 --gpg-key-id F5BE8B267C6A406D \
>        --url-directory https://ftp.gnu.org/gnu/libunistring \
>        --gnulib-version=v0.1-5095-gb79766eae
>
> and got the error message:
>
>    announce-gen: when specifying gnulib as a tool, you must also specify
>    --gnulib-version=V, where V is the result of running git describe
>    in the gnulib source directory.
>    Try 'announce-gen --help' for more information.
>
> This was confusing, as I did gave --gnulib-version but no --bootstrap-tools
> option. To fix this error, I had to add a --bootstrap-tools=... option.
> The error message should better have been
>
>    announce-gen: when specifying --gnulib-version, you must also include
>    gnulib in the --bootstrap-tools option.
>    Try 'announce-gen --help' for more information.

Thanks for feedback -- I think this question should go to Jim though,
since I don't recognize that code path.  Changing the --help text and/or
the error message seems straight-forward, and I agree the wording makes
it difficult to understand how to fix the problem, but reading the code
makes this obvious.

Hmm.  However, why can't announce-gen use 'gnulib-tool --version' to
figure out the gnulib version?  It goes to some effort to actually try
to output something like git version string.  Probably it didn't do that
when announce-gen was written.  One reason against may be that
announce-gen is useful even if someone didn't use gnulib-tool.  So how
about announce-gen uses the same code as gnulib-tool contains to figure
out the gnulib version?  Then --gnulib-version can be optional, for
those situations where the default code cannot figure out the gnulib
version.

> 2) The proposed text contained these paragraphs:
>
>    
> ----------------------------------------------------------------------------
>    Here are the SHA1 and SHA256 checksums:
>
>    cd38e3850b2d08a55cce0380d3510e7df83c6306  libunistring-1.0.tar.gz
>    PAGEwOSS18IIzjHSXdHSxY8MPtbLvgMsWySM3a0xhUQ  libunistring-1.0.tar.gz
>    ebae3103346745bef3534910a5c5afbf72099b2a  libunistring-1.0.tar.xz
>    W6tVtJ91137SayV5l+kZtpPyn9ShvCLg5uAkwkbHJ0E  libunistring-1.0.tar.xz
>
>    The SHA256 checksum is base64 encoded, instead of the
>    hexadecimal encoding that most checksum tools default to.
>    
> ----------------------------------------------------------------------------
>
>    But since the 'sha256sum' command from coreutils does not have an option
>    to display the base64 encoded SHA256 sum, and no tool I know of provides
>    a way to convert between hexadecimal and base64 checksums, displaying
>    a base64 encoded SHA256 sum is next to useless.
>
>    I ended up rewriting these paragraphs as follows:
>
>    
> ----------------------------------------------------------------------------
>    Here are the SHA1 and SHA256 checksums:
>
>    File: libunistring-1.0.tar.gz
>    SHA1 sum:   cd38e3850b2d08a55cce0380d3510e7df83c6306
>    SHA256 sum: 
> 3c0184c0e492d7c208ce31d25dd1d2c58f0c3ed6cbbe032c5b248cddad318544
>
>    File: libunistring-1.0.tar.xz
>    SHA1 sum:   ebae3103346745bef3534910a5c5afbf72099b2a
>    SHA256 sum: 
> 5bab55b49f75d77ed26b257997e919b693f29fd4a1bc22e0e6e024c246c72741
>    
> ----------------------------------------------------------------------------
>
>    How about doing the same in the 'announce-gen' script?

Yeah...  following through after this change fell between the cracks.
The right thing to do is to implement this in coreutils.  Having hex
encoded sha256 checksums looks ugly in email, and going back to them now
seems like a move in the wrong direction.

/Simon

signature.asc
Description: PGP signature