I've just finished posting zsh 5.9. It should be available in the usual places: https://sourceforge.net/projects/zsh/files/ https://www.zsh.org/pub/ With the notes at: https://zsh.sourceforge.io/releases.html creating-a-release instructs us to wait a day before posting to -announce, which has always been followed a little loosely i think, at least by me... but i'll do that this time, unless someone wants me to go ahead now. Some things i noted this time around: * 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 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) * 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 dana
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 https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz/download» 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… Daniel
Daniel Shahaf wrote on Sat, 14 May 2022 21:50 +00:00:
> (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.)
Speaking of old files: Shouldn't we either remove /pub/FAQ, or run «make
-C Etc FAQ» and uploading the resulting file?
(I've tested this and it works, and the diff seems sane.)
META-FAQ and MD5SUM might need attention too.
Cheers,
Daniel
[-- Attachment #1: Type: text/plain, Size: 2395 bytes --] Hi, On Sat, May 14, 2022 at 03:59:35PM -0500, dana wrote: > I've just finished posting zsh 5.9. It should be available in the usual > places: […] > creating-a-release instructs us to wait a day before posting to -announce, > which has always been followed a little loosely i think, at least by me... > but i'll do that this time, unless someone wants me to go ahead now. I'll upload it to Debian unstable anyway, I as I assume there won't be any changes anymore until tomorrow. :-) Debian's package checker Lintian found two typos in the documentation. Not sure why I haven't noticed them with the release candiates. There was no lintian update since then. Anyway, I propose the following patch to fix these typos and would push it in git if there are no objections: diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo index 280f1d72a..641e46cf9 100644 --- a/Doc/Zsh/builtins.yo +++ b/Doc/Zsh/builtins.yo @@ -1936,7 +1936,7 @@ retain their special attributes when made local. For each var(name)tt(=)var(value) assignment, the parameter var(name) is set to var(value). If the assignment is omitted and var(name) -does em(not) refer to an existing parameter, a new parameter is intialized +does em(not) refer to an existing parameter, a new parameter is initialized to empty string, zero, or empty array (as appropriate), em(unless) the shell option tt(TYPESET_TO_UNSET) is set. When that option is set, the parameter attributes are recorded but the parameter remains unset. diff --git a/Doc/Zsh/options.yo b/Doc/Zsh/options.yo index 443676b78..5e673eb5c 100644 --- a/Doc/Zsh/options.yo +++ b/Doc/Zsh/options.yo @@ -1952,7 +1952,7 @@ pindex(NOTYPESETTOUNSET) item(tt(TYPESET_TO_UNSET) <K> <S>)( When declaring a new parameter with any of the `tt(typeset)' family of related commands, the parameter remains unset unless and until a -value is explicity assigned to it, either in the `tt(typeset)' command +value is explicitly assigned to it, either in the `tt(typeset)' command itself or as a later assignment statement. ) pindex(VERBOSE) Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe@noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > 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? That makes sense to me. I only didn't put it there because it wasn't there before (and again creating-a-release isn't quite explicit about it). I've added it now On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > For me, «wget --content-disposition > https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz/download» > DTRTs with both wget 1.20.1-1.1 and wget 1.21.3-1+b1 on Debian (buster > and sid respectively). That one works as expected for me as well, but try with https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz.asc/download instead. For that one, with wget 1.21.3 from Homebrew, i get: Saving to: ‘zsh-5.9.tar.xz.asc?viasf=1’ Even though the headers contain: content-disposition: attachment; filename="zsh-5.9.tar.xz.asc" On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > 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? Right. Just wondering if they should also be in the doc archive, in case someone wants to get all of the documentation in one place. I had actually misread what Homebrew is doing btw. They pull the HTML files from the doc archive *in addition to* installing the man pages from the source one when you're using the bottle (not installing with --HEAD). So there's no change needed for that. However, when using --HEAD, they disable *all* documentation due to not having yodl. If their policy allows it, they could pull at least the man files out of https://sourceforge.net/projects/zsh/files/latest/download. But if the doc archive additionally had the man and run-help files, they could use that one archive to install *all* of the documentation (even if it's a little outdated) even when building from source On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > I hope workers/43692 didn't break this… I checked the doc archive for 5.6.1, which was the last release before that change, and it looks like it contains basically the same files as it does now. And the man pages are still in the source archive as mentioned dana
On Sat 14 May 2022, at 17:11, Axel Beckert wrote: > I'll upload it to Debian unstable anyway, I as I assume there won't be > any changes anymore until tomorrow. :-) Hopefully not... On Sat 14 May 2022, at 17:11, Axel Beckert wrote: > Anyway, I propose the following patch to fix these typos and would > push it in git if there are no objections: Please do. I also found a typo in NEWS i think, which i'll fix later dana
Axel Beckert wrote on Sun, May 15, 2022 at 00:11:31 +0200: > Hi, > > On Sat, May 14, 2022 at 03:59:35PM -0500, dana wrote: > > I've just finished posting zsh 5.9. It should be available in the usual > > places: > […] > > creating-a-release instructs us to wait a day before posting to -announce, > > which has always been followed a little loosely i think, at least by me... > > but i'll do that this time, unless someone wants me to go ahead now. > > I'll upload it to Debian unstable anyway, I as I assume there won't be > any changes anymore until tomorrow. :-) I'd rather you didn't. Backwards compatibility promises don't kick in until a release is announced, even if it has been tagged. If we pull the tarball for any reason, your users will get to keep both pieces. Cf. https://dist.apache.org/repos/dist/dev/subversion/README.html. Daniel > Debian's package checker Lintian found two typos in the documentation. > Not sure why I haven't noticed them with the release candiates. There > was no lintian update since then. > > Anyway, I propose the following patch to fix these typos and would > push it in git if there are no objections: > > diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo > index 280f1d72a..641e46cf9 100644 > --- a/Doc/Zsh/builtins.yo > +++ b/Doc/Zsh/builtins.yo > @@ -1936,7 +1936,7 @@ retain their special attributes when made local. > > For each var(name)tt(=)var(value) assignment, the parameter > var(name) is set to var(value). If the assignment is omitted and var(name) > -does em(not) refer to an existing parameter, a new parameter is intialized > +does em(not) refer to an existing parameter, a new parameter is initialized > to empty string, zero, or empty array (as appropriate), em(unless) the > shell option tt(TYPESET_TO_UNSET) is set. When that option is set, > the parameter attributes are recorded but the parameter remains unset. > diff --git a/Doc/Zsh/options.yo b/Doc/Zsh/options.yo > index 443676b78..5e673eb5c 100644 > --- a/Doc/Zsh/options.yo > +++ b/Doc/Zsh/options.yo > @@ -1952,7 +1952,7 @@ pindex(NOTYPESETTOUNSET) > item(tt(TYPESET_TO_UNSET) <K> <S>)( > When declaring a new parameter with any of the `tt(typeset)' family of > related commands, the parameter remains unset unless and until a > -value is explicity assigned to it, either in the `tt(typeset)' command > +value is explicitly assigned to it, either in the `tt(typeset)' command > itself or as a later assignment statement. > ) > pindex(VERBOSE) > > Kind regards, Axel > -- > PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ > Mail: abe@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet > Mail+Jabber: abe@noone.org X > https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
dana wrote on Sat, May 14, 2022 at 17:27:26 -0500: > On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > > 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? > > That makes sense to me. I only didn't put it there because it wasn't there > before (and again creating-a-release isn't quite explicit about it). I've > added it now Thanks. ENOTIME to update the creating-a-release.txt, sorry. > On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > > For me, «wget --content-disposition > > https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz/download» > > DTRTs with both wget 1.20.1-1.1 and wget 1.21.3-1+b1 on Debian (buster > > and sid respectively). > > That one works as expected for me as well, but try with > https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz.asc/download > instead. For that one, with wget 1.21.3 from Homebrew, i get: > > Saving to: ‘zsh-5.9.tar.xz.asc?viasf=1’ > > Even though the headers contain: > > content-disposition: attachment; filename="zsh-5.9.tar.xz.asc" > I get "zsh-5.9.tar.xz.asc" with 1.20.1-1.1 (didn't test the other version this time). I passed -S to wget and I see «Content-Disposition: attachment; filename="zsh-5.9.tar.xz.asc"» in the second set of headers and «Content-Type: application/octet-stream» without any «Content-Disposition» in the third set of headers. > On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote: > > I hope workers/43692 didn't break this… > > I checked the doc archive for 5.6.1, which was the last release before that > change, and it looks like it contains basically the same files as it does > now. And the man pages are still in the source archive as mentioned Thanks, dana. Daniel
dana wrote on Sat, May 14, 2022 at 17:27:26 -0500:
> On Sat 14 May 2022, at 16:50, Daniel Shahaf wrote:
> > 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?
>
> Right. Just wondering if they should also be in the doc archive, in case
> someone wants to get all of the documentation in one place.
>
> I had actually misread what Homebrew is doing btw. They pull the HTML files
> from the doc archive *in addition to* installing the man pages from the
> source one when you're using the bottle (not installing with --HEAD). So
> there's no change needed for that.
>
> However, when using --HEAD, they disable *all* documentation due to not
> having yodl. If their policy allows it, they could pull at least the man
> files out of https://sourceforge.net/projects/zsh/files/latest/download.
> But if the doc archive additionally had the man and run-help files, they
> could use that one archive to install *all* of the documentation (even if
> it's a little outdated) even when building from source
Can't they install the man pages shipped in the source tarball in --HEAD
builds too?
Hi Daniel, On Sat, May 14, 2022 at 11:21:26PM +0000, Daniel Shahaf wrote: > Axel Beckert wrote on Sun, May 15, 2022 at 00:11:31 +0200: > > Hi, > > > > On Sat, May 14, 2022 at 03:59:35PM -0500, dana wrote: > > > I've just finished posting zsh 5.9. It should be available in the usual > > > places: > > […] > > > creating-a-release instructs us to wait a day before posting to -announce, > > > which has always been followed a little loosely i think, at least by me... > > > but i'll do that this time, unless someone wants me to go ahead now. > > > > I'll upload it to Debian unstable anyway, I as I assume there won't be > > any changes anymore until tomorrow. :-) > > I'd rather you didn't. Backwards compatibility promises don't kick in > until a release is announced, even if it has been tagged. IMHO having been uploaded is a bit more than just tagged. > If we pull the tarball for any reason, your users will get to keep > both pieces. If that happens, I'd expect that a 5.9.1 or 5.9a or something is released and 5.9 is never annouced. Like e.g. the ASF does with HTTPD releases. Not every 2.4.xy or 2.6.xy has been released (or at least not announced). The tar ball is btw. already imported and pushed to Debian's packaging git repo. I haven't uploaded though, so I'll postpone that until tomorrow (or rather later today depending on the timezone :-). > Cf. https://dist.apache.org/repos/dist/dev/subversion/README.html. That talks about release candidates, not about already publicly downloadable tar balls with the correct version. Our -test releases are the release candidates from my point of view. And yes, of course I fully agree with that. That's why I uploaded all packages of release candidates to Debian Experimental, not to Unstable. According to discusion in here, the reasons for the delay are also others. (I also remember from earlier discussions about the release process that SF's upload thingy is a bit fiddly and sometimes needs a few attempts to get their "newest upload" pointer right.) Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe@noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Axel Beckert wrote on Sat, 14 May 2022 23:35 +00:00: > On Sat, May 14, 2022 at 11:21:26PM +0000, Daniel Shahaf wrote: >> Axel Beckert wrote on Sun, May 15, 2022 at 00:11:31 +0200: >> > Hi, >> > >> > On Sat, May 14, 2022 at 03:59:35PM -0500, dana wrote: >> > > I've just finished posting zsh 5.9. It should be available in the usual >> > > places: >> > […] >> > > creating-a-release instructs us to wait a day before posting to -announce, >> > > which has always been followed a little loosely i think, at least by me... >> > > but i'll do that this time, unless someone wants me to go ahead now. >> > >> > I'll upload it to Debian unstable anyway, I as I assume there won't be >> > any changes anymore until tomorrow. :-) >> >> I'd rather you didn't. Backwards compatibility promises don't kick in >> until a release is announced, even if it has been tagged. > > IMHO having been uploaded is a bit more than just tagged. > Read "even if it has been tagged and uploaded", then. >> If we pull the tarball for any reason, your users will get to keep >> both pieces. > > If that happens, I'd expect that a 5.9.1 or 5.9a or something is > released and 5.9 is never annouced. Like e.g. the ASF does with HTTPD > releases. Not every 2.4.xy or 2.6.xy has been released (or at least > not announced). > In such a case we might do the same and re-tag as 5.9.1, yes, but that's not a reason to let users run 5.9 before it has been released (= announced). >> Cf. https://dist.apache.org/repos/dist/dev/subversion/README.html. > > That talks about release candidates, not about already publicly > downloadable tar balls with the correct version. I'm aware of that. I consider what that page describes to apply to releases-to-be that have not been announced. > Our -test releases are the release candidates from my point of view. > And yes, of course I fully agree with that. That's why I uploaded all > packages of release candidates to Debian Experimental, not to > Unstable. +1 > According to discusion in here, the reasons for the delay are also > others. (I also remember from earlier discussions about the release > process that SF's upload thingy is a bit fiddly and sometimes needs a > few attempts to get their "newest upload" pointer right.) Good night, Daniel
On Sat 14 May 2022, at 18:26, Daniel Shahaf wrote: > Thanks. ENOTIME to update the creating-a-release.txt, sorry. np, i'll do it tomorrow probably On Sat 14 May 2022, at 18:26, Daniel Shahaf wrote: > I get "zsh-5.9.tar.xz.asc" with 1.20.1-1.1 (didn't test the other > version this time). Not sure then. It seems repeatable with the asc files for me here On Sat 14 May 2022, at 18:28, Daniel Shahaf wrote: > Can't they install the man pages shipped in the source tarball in --HEAD > builds too? Yeah, that's what i was saying in the third paragraph you quoted. But that won't get them *all* the documentation like they have with bottles. They would have to pull both the source *and* doc archives to do that (since yodl is also needed to build the HTML files and those aren't included with the source). Which they might be fine with, idk; it would just be faster and more convenient if it was all in one place. I don't personally care about having local HTML documentation, though, and since SF only lets you have one 'latest' file (the source archive in our case) maybe adding man and run-help to the doc archive isn't that useful to Homebrew either. I'll just see if they can pull the man pages from the 'latest' file with --HEAD dana
On Sat, May 14, 2022 at 3:35 PM dana <dana@dana.is> wrote: > > Please do. I also found a typo in NEWS i think, which i'll fix later This one? diff --git a/NEWS b/NEWS index d7a817c1e..cdafd1ff5 100644 --- a/NEWS +++ b/NEWS @@ -49,7 +49,7 @@ negative numbers. The (*) expansion flag enables EXTENDED_GLOB for pattern matching. For example, ${(*)sample/(#b)*(pat)*/${match[1]}} uses backreferences even if EXTENDED_GLOB is not otherwise set. However, this does not -descend into nested exapansions, and doubling as (**) does not disable +descend into nested expansions, and doubling as (**) does not disable EXTENDED_GLOB. The compinit function learnt a -w option to explain why compdump runs.
On Sat 14 May 2022, at 23:33, Bart Schaefer wrote:
> This one?
> ...
> -descend into nested exapansions, and doubling as (**) does not disable
> +descend into nested expansions, and doubling as (**) does not disable
Yes, i do believe so
dana
dana wrote on Sat, May 14, 2022 at 18:50:13 -0500: > On Sat 14 May 2022, at 18:26, Daniel Shahaf wrote: > > I get "zsh-5.9.tar.xz.asc" with 1.20.1-1.1 (didn't test the other > > version this time). > > Not sure then. It seems repeatable with the asc files for me here > I can reproduce it now, both with the 1.20.1-1.1 I used yesterday and with 1.20.3-1ubuntu2 on a remote VM. I haven't changed anything on my end. As to workarounds, the committed one looks good, or we could specify the filename explicitly by doing, say, «wget -O ${URL:h:t} $URL». > On Sat 14 May 2022, at 18:28, Daniel Shahaf wrote: > > Can't they install the man pages shipped in the source tarball in --HEAD > > builds too? > > Yeah, that's what i was saying in the third paragraph you quoted. But that > won't get them *all* the documentation like they have with bottles. They > would have to pull both the source *and* doc archives to do that (since > yodl is also needed to build the HTML files and those aren't included with > the source). Which they might be fine with, idk; it would just be faster > and more convenient if it was all in one place. I don't understand the problem, since they'd _anyway_ have to get both archives if they want to have HTML/PDF/info docs in --HEAD builds… but more importantly, I think solving a problem before the user requirements have been nailed down is putting the cart before the horse. > I don't personally care about having local HTML documentation, though, and > since SF only lets you have one 'latest' file (the source archive in our > case) maybe adding man and run-help to the doc archive isn't that useful to > Homebrew either. If the lack of a single canonical URL to download the latest doc tarball is a problem, we can solve that in a number of ways. > I'll just see if they can pull the man pages from the 'latest' file > with --HEAD Sounds like a good next step. And they're welcome to file bug reports against the distribution scheme :) Cheers, Dainel
On Sun 15 May 2022, at 05:36, Daniel Shahaf wrote:
> I don't understand the problem, since they'd _anyway_ have to get both
> archives if they want to have HTML/PDF/info docs in --HEAD builds
As far as i understand it, at least in principle:
Bottle builds require both source and documentation archives because the
shell itself is built from the source archive. In --HEAD builds the shell
is built from VCS, so they would have no need for the source archive if
not for the fact that some of the documentation happens to exist only
there and not in the documentation one
In practice i think they might be downloading one or both of the archives
*anyway* just because they're defined in the formula. I'll look into it
more and come back here if needed once i know what i'm talking about
---
Anyway, i have posted the release announcement to -announce now. It's
awaiting moderation
dana
On 2022-05-14 at 21:50 +0000, Daniel Shahaf wrote: > 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? None that I can see. Keys can be put into many places, as long as the deployment workflow updates them all. IMO the "correct" approach for the future is federated lookups, aka WKD (in practice); this uses /.well-known/ to put keys into place in a schema which gpg (and various email clients) can use to retrieve the keys automatically with `--locate-keys`. This can be done on https://zsh.org/ or on https://openpgpkey.zsh.org/ Only works for keys with a UID in zsh.org. But means that email clients will automatically find the right keys without needing to go dig around in various websites. * https://wiki.gnupg.org/WKD walks through it * https://wiki.gnupg.org/WKDHosting explains setup on the web-server and of those, I'm obviously biased towards <https://github.com/PennockTech/openpgpkey-control>; that layout is what I use for some other domains, and `other/standalone-update-website` within the repo has been successfully used by at least a few people in updating contents as part of a general website build flow ... and is probably the right path for zsh.org. Feed it the keyring for `--keys-file` and a directory top for the serving root for `--output-dir` and it will write things into the right places. With that, `gpg --locate-keys pdp@zsh.org` would work, and similarly for any other key with a UID in zsh.org.
Phil Pennock wrote on Mon, May 16, 2022 at 19:57:19 -0400: > and of those, I'm obviously biased towards > <https://github.com/PennockTech/openpgpkey-control>; that layout is what > I use for some other domains, and `other/standalone-update-website` > within the repo has been successfully used by at least a few people in > updating contents as part of a general website build flow ... and is > probably the right path for zsh.org. FWIW, I use this script for my key and I'm happy with it. Cheers, Daniel > Feed it the keyring for > `--keys-file` and a directory top for the serving root for > `--output-dir` and it will write things into the right places. > > With that, `gpg --locate-keys pdp@zsh.org` would work, and similarly for > any other key with a UID in zsh.org.