Re: announce-gen project link and mirrors

Simon Josefsson via Gnulib discussion list writes: >> Here are the compressed sources: >> https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.gz (3.3MB) >> https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.xz (1.9MB) >> >> Here are the GPG detached signatures: >> https://ftp.gnu.org

Re: announce-gen project link and mirrors

Simon Josefsson wrote: > Announce-gen generate this snippet: > > > Here is the GNU libtasn1 home page: > > https://gnu.org/s/libtasn1/ > > Why? Shouldn't we use the canonical URL in the announcement? I think > the above just looks ugly when the real URL is: > > https://www.gnu.org/softwa

Re: announce-gen project link and mirrors

Jim Meyering writes: > On Thu, Feb 6, 2025 at 3:06 PM Simon Josefsson via Gnulib discussion > list wrote: >> Announce-gen generate this snippet: >> >> > Here is the GNU libtasn1 home page: >> > https://gnu.org/s/libtasn1/ >> >> Why? Shouldn't we use the canonical URL in the announcement? I

Re: announce-gen project link and mirrors

On Thu, Feb 6, 2025 at 9:59 PM Jim Meyering wrote: > > On Thu, Feb 6, 2025 at 3:06 PM Simon Josefsson via Gnulib discussion > list wrote: > > Announce-gen generate this snippet: > > > > > Here is the GNU libtasn1 home page: > > > https://gnu.org/s/libtasn1/ > > > > Why? Shouldn't we use the

Re: announce-gen project link and mirrors

On Thu, Feb 6, 2025 at 3:06 PM Simon Josefsson via Gnulib discussion list wrote: > Announce-gen generate this snippet: > > > Here is the GNU libtasn1 home page: > > https://gnu.org/s/libtasn1/ > > Why? Shouldn't we use the canonical URL in the announcement? I think > the above just looks ugl

Re: announce-gen: Show an SHA256 sum that can be verified more easily

Bruno Haible via Gnulib discussion list writes: > OK, clearly there are different preferences. So, let me restore the > previous behaviour through a command-line option: --cksum-checksums. Thank you! I pushed the attached patch to make it possible to use it from cfg.mk like this: announce_gen_

Re: announce-gen: Show an SHA256 sum that can be verified more easily

On 02/12/2024 21:11, Jeffrey Walton wrote: It turns out that Base64 is malleable. All tools do not produce the same results. Also see . Whether Base64 malleability leads to a vulnerability is another question. This might be an issue for non canonicity, particu

Re: announce-gen: Show an SHA256 sum that can be verified more easily

On Sun, Dec 1, 2024 at 9:04 AM Simon Josefsson via Gnulib discussion list wrote: > > Bruno Haible via Gnulib discussion list writes: > > > The 'announce-gen' script shows SHA256 sums in a way that are hard to verify > > and understand for the users: > > - Verifying requires a special command th

Re: announce-gen: Show an SHA256 sum that can be verified more easily

Collin Funk wrote: > I've attached a patch, but I haven't pushed yet in case anyone > disagrees. Thanks for proposing that patch, Collin. Even though the patch does not find my agreement (and also lacks a modification in the --help output), it helped me save time, because Perl is unfamiliar to me.

Re: announce-gen: Show an SHA256 sum that can be verified more easily

Jim Meyering wrote: > > I think we should encourage people to use 'cksum' rather than > > 'sha256sum' since the latter is a bad pattern that leads to an explosion > > of tools when new hash algorithms are introduced. > > I too prefer the shorter checksums and would like to encourage the use > of t

Re: announce-gen: Show an SHA256 sum that can be verified more easily

Jim Meyering writes: > I too prefer the shorter checksums and would like to encourage the use > of the more compact representation by making that the default. Not > just to keep line lengths under 80 columns, but just generally to > minimize the noise of checksums in announcements. I think both

Re: announce-gen: Show an SHA256 sum that can be verified more easily

On Sun, Dec 1, 2024 at 6:04 AM Simon Josefsson via Gnulib discussion list wrote: > Bruno Haible via Gnulib discussion list writes: > > > The 'announce-gen' script shows SHA256 sums in a way that are hard to verify > > and understand for the users: > > - Verifying requires a special command that

Re: announce-gen: Show an SHA256 sum that can be verified more easily

Bruno Haible via Gnulib discussion list writes: > The 'announce-gen' script shows SHA256 sums in a way that are hard to verify > and understand for the users: > - Verifying requires a special command that is not easy to remember. > - Verifying requires special tools that do not exist on all s

Re: announce-gen: Fix copyright year in --version output.

Bruno Haible writes: > How about deriving the --version output from the copyright notice, for > those programs that consist of a single file and that are not written in C? [...] > + # Extract the last year from this file's copyright notice. > + sed_extract_last_year='s/^.*\([0-9]\{4\}\)[^0-9]*$

Re: announce-gen: Fix copyright year in --version output.

Collin Funk wrote: > The announce-gen and useless-if-before-free scripts have had changes > since their copyright date was updated: How about deriving the --version output from the copyright notice, for those programs that consist of a single file and that are not written in C? Like this: diff -

Re: announce-gen: Fix copyright year in --version output.

Hi Simon, > > The GNU Maintainers Guide and the GNU Coding Standards have different > > sections > > - about the copyright notice in source files > > https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html > > - about the --version output of programs > > https://www.gnu.org

Re: announce-gen: Fix copyright year in --version output.

Bruno Haible writes: > Simon Josefsson wrote: >> > Maybe, I am misreading but I think using $VERSION makes more sense >> > according to the GNU Coding Standards [1]: >> > >> > This copyright notice only needs to mention the most recent year in >> > which changes were made—there’s no need

Re: announce-gen: Fix copyright year in --version output.

Simon Josefsson wrote: > > Maybe, I am misreading but I think using $VERSION makes more sense > > according to the GNU Coding Standards [1]: > > > > This copyright notice only needs to mention the most recent year in > > which changes were made—there’s no need to list the years for previous

Re: announce-gen: Fix copyright year in --version output.

Collin Funk writes: > Hi Simon, > > Simon Josefsson writes: > >> That's better, but doesn't all this just hides the problem that 'make >> update-copyright' doesn't bump the copyright for these two files? I >> think the policy is to bump copyright year to 2025 as soon as possible >> after 2025-0

Re: announce-gen: Fix copyright year in --version output.

Hi Simon, Simon Josefsson writes: > That's better, but doesn't all this just hides the problem that 'make > update-copyright' doesn't bump the copyright for these two files? I > think the policy is to bump copyright year to 2025 as soon as possible > after 2025-01-01 even if there are no other

Re: announce-gen: Fix copyright year in --version output.

Collin Funk writes: > Hi Bruno, > > Bruno Haible writes: > >> Can this be rewritten in a simpler way, that does not use idioms >> from perl's bag of tricks? Something like >> >> my $copyright_year = ; >> >> like one would do it in every other programming language? > > Not sure. I'm not the mos

Re: announce-gen: Fix copyright year in --version output.

Hi Bruno, Bruno Haible writes: > Can this be rewritten in a simpler way, that does not use idioms > from perl's bag of tricks? Something like > > my $copyright_year = ; > > like one would do it in every other programming language? Not sure. I'm not the most knowledgeable perl programmer. Mayb

Re: announce-gen: Fix copyright year in --version output.

Hi Collin, > I've pushed the two attached patches to derive the copyright year from > the time-stamp string. > +(my $copyright_year = $VERSION) =~ s/^(\d*)-.*$/$1/; Can this be rewritten in a simpler way, that does not use idioms from perl's bag of tricks? Something like my $copyright_year =

Re: announce-gen usage feedback

On Sat, Jul 9, 2022 at 6:29 AM Simon Josefsson via Gnulib discussion list wrote: > > Bruno Haible writes: > > > Hi Simon, > > > > Two remarks regarding 'announce-gen': > > > > 1) I used the command > >$ $GNULIB_SRCDIR/build-aux/announce-gen --release-type stable \ > >--package-name li

Re: announce-gen usage feedback

Bruno Haible 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 \

Re: announce-gen and OpenPGP key servers

tis 2021-08-03 klockan 16:51 -0700 skrev Jim Meyering: > On Tue, Aug 3, 2021 at 12:25 PM Paul Eggert > wrote: > > On 8/3/21 12:20 PM, Simon Josefsson via Gnulib discussion list > > wrote: > > > +  print "\nThe SHA256 checksum is base64 encoded and not > > > hexadecimal,\n"; > > > +  print "which i

Re: announce-gen and OpenPGP key servers

On Tue, Aug 3, 2021 at 12:25 PM Paul Eggert wrote: > On 8/3/21 12:20 PM, Simon Josefsson via Gnulib discussion list wrote: > > + print "\nThe SHA256 checksum is base64 encoded and not hexadecimal,\n"; > > + print "which is the default for most checksum tools.\n\n"; > > Perhaps this? > >print

Re: announce-gen and OpenPGP key servers

On 8/3/21 12:20 PM, Simon Josefsson via Gnulib discussion list wrote: + print "\nThe SHA256 checksum is base64 encoded and not hexadecimal,\n"; + print "which is the default for most checksum tools.\n\n"; Perhaps this? print "\nThe SHA256 checksum is base64 encoded, instead of the\n"; pr

Re: announce-gen and OpenPGP key servers

Jim Meyering writes: > Thanks, Simon! I too am all for B64-formatted checksums. Good, it is a trade-off between output readability and code complexity. Aligning 'sha*sum' with OpenBSD's 'sha*' tools would be nice, and base64 support is one missing piece. > You may want to coordinate with Pádrai

Re: announce-gen and OpenPGP key servers

On Tue, Aug 3, 2021 at 8:40 AM Simon Josefsson wrote: > Jim Meyering writes: > > > Feel free to make the script generate a full fingerprint and even > > (though it feels a little like giving up) add a checksum or two. > > I think checksums still serve a purpose. > > Many announcement e-mails are

Re: announce-gen and OpenPGP key servers

Jim Meyering writes: > Feel free to make the script generate a full fingerprint and even > (though it feels a little like giving up) add a checksum or two. I think checksums still serve a purpose. Many announcement e-mails are OpenPGP signed (and sometimes with a different key than the release

Re: announce-gen and OpenPGP key servers

sön 2021-08-01 klockan 17:47 +0200 skrev Bernhard Voelker: > On 7/27/21 11:38 AM, Simon Josefsson via Gnulib discussion list > wrote: > > Let's discuss and see what we can do. > Isn't this what the "release GPG keys" on Savannah are for? > > Each project maintainer can set them up correctly under

Re: announce-gen and OpenPGP key servers

On 7/27/21 11:38 AM, Simon Josefsson via Gnulib discussion list wrote: > Let's discuss and see what we can do. Isn't this what the "release GPG keys" on Savannah are for? Each project maintainer can set them up correctly under "Edit public info": "https://savannah.gnu.org/project/admin/editgroup

Re: announce-gen and OpenPGP key servers

On Tue, Jul 27, 2021 at 2:38 AM Simon Josefsson via Gnulib discussion list wrote: > Hi. Our announce-gen contains: > > If that command fails because you don't have the required public key, > then run this command to import it: > gpg --keyserver keys.gnupg.net --recv-keys $gpg_key_id > > Giv

Re: announce-gen and OpenPGP key servers

I agree that the current situation is bad and that your suggestions would be improvement. Particularly the part about involving the ftp-upload people. My impression is that they're quite conservative about changing things (and rightly so) but we really need a more-reliable distribution mechani

Re: announce-gen: minor issues

Akim Demaille wrote: > Hi Jim! > > Le 23 mai 2012 à 10:34, Jim Meyering a écrit : > * build-aux/announce-gen: When parsing command line options, prefer "announce-gen: option --release-type requires an argument" to "Option release-type requires an argument". >> >> This is an improvem

Re: announce-gen: minor issues

Hi Jim! Le 23 mai 2012 à 10:34, Jim Meyering a écrit : >>> * build-aux/announce-gen: When parsing command line options, >>> prefer "announce-gen: option --release-type requires an argument" >>> to "Option release-type requires an argument". > > This is an improvement, but for the fact that then

Re: announce-gen: minor issues

Akim Demaille wrote: > Le 23 mai 2012 à 10:02, Akim Demaille a écrit : > >> The two attached patches provide minor improvements to >> announce-gen. The first one was prompted by the fact >> that I had an error message whose origin was unclear. Hi Akim, Thanks for the patches! >> * build-aux/anno

Re: announce-gen: minor issues

Le 23 mai 2012 à 10:02, Akim Demaille a écrit : > The two attached patches provide minor improvements to > announce-gen. The first one was prompted by the fact > that I had an error message whose origin was unclear. > > * build-aux/announce-gen: When parsing command line options, > prefer "anno

Re: announce-gen

Reuben Thomas wrote: > On 29 April 2011 21:48, Jim Meyering wrote: >> >> Please make that a separate change. > > Attached a patch made with vc-dwim :) ... > Subject: [PATCH] announce-gen: cosmetic improvement > > * build-aux/announce-gen: strip any leading ./ from the NEWS file. Thanks. Pushed w

Re: announce-gen

If no one else feels strongly enough about this to speak up, I'm willing to drop the "-", I don't feel strongly about it either way, but FWIW, the majority of Subject: lines in the info-gnu archives for this month use the real package name and a space. So, as long as we're talking "coreu

Re: announce-gen

On 29 April 2011 21:48, Jim Meyering wrote: > > Please make that a separate change. Attached a patch made with vc-dwim :) > If no one else feels strongly enough about this to > speak up, I'm willing to drop the "-", but let's defer > that change until README-release is in gnulib, so that > you c

Re: announce-gen

Reuben Thomas wrote: > On 29 April 2011 21:21, Jim Meyering wrote: >> Reuben Thomas wrote: >>> I'm trying to prepare a small cosmetic patch to fix up a couple of >>> things I find myself manually fixing up: >>> >>> 1. "./NEWS". I considered replacing this with the basename of the NEWS >>> file, bu

Re: announce-gen

On 29 April 2011 21:21, Jim Meyering wrote: > Reuben Thomas wrote: >> I'm trying to prepare a small cosmetic patch to fix up a couple of >> things I find myself manually fixing up: >> >> 1. "./NEWS". I considered replacing this with the basename of the NEWS >> file, but in fact it seems to me it's

Re: announce-gen

Reuben Thomas wrote: > I'm trying to prepare a small cosmetic patch to fix up a couple of > things I find myself manually fixing up: > > 1. "./NEWS". I considered replacing this with the basename of the NEWS > file, but in fact it seems to me it's better to use the literal "NEWS" > since that makes

Re: announce-gen

Jim Meyering wrote: > Eric Blake wrote: >> On 04/29/2011 01:51 PM, Reuben Thomas wrote: >>> I'm trying to prepare a small cosmetic patch to fix up a couple of >>> things I find myself manually fixing up: >>> >>> 1. "./NEWS". I considered replacing this with the basename of the NEWS >>> file, but in

Re: announce-gen

On 04/29/2011 02:02 PM, Jim Meyering wrote: > Hmm... vc-list-files has the same problem, > though in its case I'll convert only the leading TABs, > since some are used to align backslashes, and I have > a slight preference for TABs there. Leading tab indentation is different than mid-line tab usag

Re: announce-gen

Eric Blake wrote: > On 04/29/2011 01:51 PM, Reuben Thomas wrote: >> I'm trying to prepare a small cosmetic patch to fix up a couple of >> things I find myself manually fixing up: >> >> 1. "./NEWS". I considered replacing this with the basename of the NEWS >> file, but in fact it seems to me it's be

Re: announce-gen

On 04/29/2011 01:51 PM, Reuben Thomas wrote: > I'm trying to prepare a small cosmetic patch to fix up a couple of > things I find myself manually fixing up: > > 1. "./NEWS". I considered replacing this with the basename of the NEWS > file, but in fact it seems to me it's better to use the literal

Re: announce-gen -- not flexible enough

- avoid breaking the announcement-generating code: Once you move the "$(MAKE) -s announcement release_typ...@..." command into another rule, "$@" is no longer valid. Instead, rely on RELEASE_TYPE being set in the environment. Ah, yeah, I had fixed that in a different c

Re: announce-gen -- not flexible enough

> +# Override this in cfg.mk if you have different post-release procedures. > +post-release-hook ?= default-post-release-administrivia > + > # Prevent programs like 'sort' from considering distinct strings to be equal. > # Doing it here saves us from having to set LC_ALL elsewhere in this file. >

Re: announce-gen -- not flexible enough

Ping? >From 00c33e8b07ae06d2c09394c3cf2892063f0c2fc6 Mon Sep 17 00:00:00 2001 From: Alfred M. Szmidt Date: Sat, 5 Dec 2009 20:44:20 +0100 Subject: [PATCH] Allow for per-project post-release administrative tasks. --- ChangeLog|8 top/maint.mk | 10 +- 2 files changed,

Re: announce-gen -- not flexible enough

I.e., initialize "require_news=true" or to false, then run the "command": if $require_news; then ... fi By reversing the sense of the name, you make it so the three added tests are not all negated. That's more readable. Good idea; but there is a better way to

Re: announce-gen -- not flexible enough

* Alfred M. Szmidt wrote on Sat, Dec 05, 2009 at 06:26:23PM CET: > +if [ $opt_skip_news == "false" ]; then FWIW, test aka [ with `==' is a bashism, please use `=' instead. Cheers, Ralf

Re: announce-gen -- not flexible enough

Alfred M. Szmidt wrote: >You said you would not be changing announce-gen, so isn't it moot? > > I said that I did not have enough knowledge to hack announce-gen since > it is written in perl; I cannot do something when I don't know how to > do it. > >I pointed out that yet another script pa

Re: announce-gen -- not flexible enough

You said you would not be changing announce-gen, so isn't it moot? I said that I did not have enough knowledge to hack announce-gen since it is written in perl; I cannot do something when I don't know how to do it. I pointed out that yet another script parses (and rewrites) NEWS and woul

Re: announce-gen -- not flexible enough

Alfred M. Szmidt wrote: >Alfred M. Szmidt wrote: >> announce-gen is lovley, but it is very inflexible if you use a >> different format for NEWS. >> >> In inetutils, we use something like: >> >> | December 27, 2008 >> | Version 1.6: >> | >> | * Fixed FOO in B

Re: announce-gen -- not flexible enough

Alfred M. Szmidt wrote: > announce-gen is lovley, but it is very inflexible if you use a > different format for NEWS. > > In inetutils, we use something like: > > | December 27, 2008 > | Version 1.6: > | > | * Fixed FOO in BAR. > | > | * Added BAZ. > |  >

Re: announce-gen -- not flexible enough

Alfred M. Szmidt wrote: > announce-gen is lovley, but it is very inflexible if you use a > different format for NEWS. > > In inetutils, we use something like: > > | December 27, 2008 > | Version 1.6: > | > | * Fixed FOO in BAR. > | > | * Added BAZ. > |  > | October 21, 2006 > | Version 1.5: > | >

Re: announce-gen

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Announce-gen assumes that there are *.tar.bz2 and xdelta files, libidn > doesn't use either. This patch disables printing information for > those files, when the files doesn't exist. An alternate solution > would be to warn instead, but I think it is n