Bruno Haible <br...@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
