On Thu, Feb 6, 2025 at 9:59 PM Jim Meyering <[email protected]> wrote:
>
> On Thu, Feb 6, 2025 at 3:06 PM Simon Josefsson via Gnulib discussion
> list <[email protected]> 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/software/libtasn1/
>
> So you prefer "software" in place of "s" and the addition of the "www."
> prefix?
> To be honest, I prefer neither, seeing the "www." prefix as unnecessary fluff
> and "software" as "obvious", so unnecessary to spell out. In all such
> messaging,
> keeping the text as concise as is reasonably possible feels like a good goal,
> but if you find enough value in using a canonical URL, I won't object.
Given it is an Apache server:
$ curl -D - www.gnu.org
HTTP/1.1 200 OK
Date: Fri, 07 Feb 2025 04:07:17 GMT
Server: Apache
...
A mod_rewrite rule in .htaccess should make changing s/ to software/
an easy task. Something like:
RewriteEngine on
RewriteRule ^s/?(.*)$ /software/$1 [L,QSA]
For the www part, it is generally handled in the virtual host config:
<VirtualHost *:80>
ServerName example.com
Redirect permanent / http://www.example.com/
</VirtualHost>
<VirtualHost *:80>
ServerName www.example.com
# real server configuration
</VirtualHost>
> > I can see the utility to shorten in some places, but I think the first
> > URL to the project in the announcements should use the canonical URL.
> > Any objections to changing this?
> >
> > README-release says:
> >
> > > * Wait a few minutes (maybe up to 30?) and then use the release URLs to
> > > download all tarball/signature pairs and use gpg --verify to ensure
> > > that they're all valid.
> >
> > I found today that this is problematic -- I waited for around 4 hours
> > until I gave up and changed the announcement to use
> > ftp.gnu.org/gnu/libtasn1/ URLs instead.
> >
> > There is mirror status available --
> > https://download.savannah.gnu.org/mirmon/allgnu/ -- and some sites are
> > up to 24 hours late.
> >
> > The https://ftpmirror.gnu.org redirector also does not seem to work very
> > well, it can pick a rather stale mirror or a currently offline mirror --
> > right now I get redirected to https://ftp.wayne.edu/gnu/ which is not
> > answering. And then you can't get redirected to another mirror if you
> > retry the ftpmirror.gnu.org URL again.
> >
> > I can live with manually doing
> > s,ftpmirror.gnu.org/PROJECT,ftp.gnu.org/gnu/PROJECT, while preparing
> > release notes, but I wonder if we should just give up on using
> > ftpmirrors.gnu.org URLs in the announcements?
>
> I've remedied that situation by configuring announcements to use the
> URLs that work promptly. E.g., for diffutils, it generated this:
>
> 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/gnu/diffutils/diffutils-3.11.tar.gz.sig
> https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.xz.sig
>
> Use a mirror for higher download bandwidth:
> https://www.gnu.org/order/ftp.html
>
> As you can imagine, I wouldn't mind making that the default.
> I set this in cfg.mk:
>
> # Use the direct link. This is guaranteed to work immediately,
> while
> # it can take a while for the faster mirror links to become usable.
> url_dir_list = https://ftp.gnu.org/gnu/$(PACKAGE)
Jeff
