help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: dana <dana@dana.is>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Posted zsh 5.9
Date: Sat, 14 May 2022 21:50:10 +0000	[thread overview]
Message-ID: <20220514215010.GI13508@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <25ece9e8-71fb-4cf4-adf1-1fbef7eda0a1@www.fastmail.com>

dana wrote on Sat, May 14, 2022 at 15:59:35 -0500:
> * creating-a-release doesn't explicitly say where to put the zsh-keyring
>   file for stable releases. (It's obvious for test releases since there's
>   only one place it could go.) I guess for that reason i did not upload it
>   to SF when i posted 5.8.1. This time i put it under zsh/ (and not
>   zsh-doc/). Is that the intention?

The intention is to have the public keys easily available to anyone who
downloads the artifacts themselves, particularly as «gpg --keyserver foo
--recv-key $fingerprint» isn't as reliable as it used to be.

For zsh.org there's little question where to put the keyring file, as
there's only one relevant directory.  Any reason not to upload
zsh-keyring.asc to zsh.org/pub?

For sf.net… we could simplify the directory there structure and make it
similar to zsh.org/pub/ while at it (no reason to have two different
directory structures), but for the time being, uploading the keyring to
/zsh/5.9/ seems reasonable.  It would be a little less obvious for
anyone downloading only the docs tarball, but it's not a major issue.

(Aside: zsh.org/pub/ has contained a pubring.pgp last modified in 1998.
I've just moved it to zsh.org/pub/old/ to prevent any confusion.)

> * The release-update-versions script in the web repo failed to complete
>   because, despite being passed the --content-disposition option, wget was
>   not fully respecting the attachment name for the files it downloaded from
>   SF, resulting in the addition of query-string parameters to the ends of
>   the file names. I hacked around this by making the script do a rename
>   pass after the wget, not sure if we want to come up with something nicer.
>   (`curl -LJO` names the files correctly, fwiw)

For me, «wget --content-disposition
DTRTs with both wget 1.20.1-1.1 and wget 1.21.3-1+b1 on Debian (buster
and sid respectively).

> * This has probably been discussed before, but is it deliberate that the
>   (roff-formatted) man pages are in the source archive and not in the doc
>   one? The Homebrew package maintainers don't seem to be aware of this (they
>   only pull the HTML files from the doc archive), and i wanted to confirm
>   that that's how it's meant to be before i submit a PR

I think the man pages are there so yodl won't be a build dependency?
I.e., so people who build from source but don't have yodl will still
have man pages to install?

I hope workers/43692 didn't break this…


  reply	other threads:[~2022-05-14 21:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-14 20:59 dana
2022-05-14 21:50 ` Daniel Shahaf [this message]
2022-05-14 21:58   ` Daniel Shahaf
2022-05-14 22:27   ` dana
2022-05-14 23:26     ` Daniel Shahaf
2022-05-14 23:28     ` Daniel Shahaf
2022-05-14 23:50       ` dana
2022-05-15 10:36         ` Daniel Shahaf
2022-05-15 21:43           ` dana
2022-05-16 23:57   ` Phil Pennock
2022-05-21  1:31     ` Daniel Shahaf
2022-05-14 22:11 ` Axel Beckert
2022-05-14 22:31   ` dana
2022-05-15  4:33     ` Bart Schaefer
2022-05-15  6:00       ` dana
2022-05-14 23:21   ` Daniel Shahaf
2022-05-14 23:35     ` Axel Beckert
2022-05-14 23:49       ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220514215010.GI13508@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=dana@dana.is \
    --cc=zsh-workers@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).