zsh-workers
 help / color / mirror / code / Atom feed
* Posted zsh 5.9
@ 2022-05-14 20:59 dana
  2022-05-14 21:50 ` Daniel Shahaf
  2022-05-14 22:11 ` Axel Beckert
  0 siblings, 2 replies; 18+ messages in thread
From: dana @ 2022-05-14 20:59 UTC (permalink / raw)
  To: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 20:59 Posted zsh 5.9 dana
@ 2022-05-14 21:50 ` Daniel Shahaf
  2022-05-14 21:58   ` Daniel Shahaf
                     ` (2 more replies)
  2022-05-14 22:11 ` Axel Beckert
  1 sibling, 3 replies; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-14 21:50 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 21:50 ` Daniel Shahaf
@ 2022-05-14 21:58   ` Daniel Shahaf
  2022-05-14 22:27   ` dana
  2022-05-16 23:57   ` Phil Pennock
  2 siblings, 0 replies; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-14 21:58 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 20:59 Posted zsh 5.9 dana
  2022-05-14 21:50 ` Daniel Shahaf
@ 2022-05-14 22:11 ` Axel Beckert
  2022-05-14 22:31   ` dana
  2022-05-14 23:21   ` Daniel Shahaf
  1 sibling, 2 replies; 18+ messages in thread
From: Axel Beckert @ 2022-05-14 22:11 UTC (permalink / raw)
  To: zsh-workers

[-- 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 --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 21:50 ` Daniel Shahaf
  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-16 23:57   ` Phil Pennock
  2 siblings, 2 replies; 18+ messages in thread
From: dana @ 2022-05-14 22:27 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 22:11 ` Axel Beckert
@ 2022-05-14 22:31   ` dana
  2022-05-15  4:33     ` Bart Schaefer
  2022-05-14 23:21   ` Daniel Shahaf
  1 sibling, 1 reply; 18+ messages in thread
From: dana @ 2022-05-14 22:31 UTC (permalink / raw)
  To: Axel Beckert; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 22:11 ` Axel Beckert
  2022-05-14 22:31   ` dana
@ 2022-05-14 23:21   ` Daniel Shahaf
  2022-05-14 23:35     ` Axel Beckert
  1 sibling, 1 reply; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-14 23:21 UTC (permalink / raw)
  To: Axel Beckert; +Cc: zsh-workers

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/




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 22:27   ` dana
@ 2022-05-14 23:26     ` Daniel Shahaf
  2022-05-14 23:28     ` Daniel Shahaf
  1 sibling, 0 replies; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-14 23:26 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  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
  1 sibling, 1 reply; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-14 23:28 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

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?


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 23:21   ` Daniel Shahaf
@ 2022-05-14 23:35     ` Axel Beckert
  2022-05-14 23:49       ` Daniel Shahaf
  0 siblings, 1 reply; 18+ messages in thread
From: Axel Beckert @ 2022-05-14 23:35 UTC (permalink / raw)
  To: zsh-workers

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/


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 23:35     ` Axel Beckert
@ 2022-05-14 23:49       ` Daniel Shahaf
  0 siblings, 0 replies; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-14 23:49 UTC (permalink / raw)
  To: Axel Beckert, zsh-workers

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 23:28     ` Daniel Shahaf
@ 2022-05-14 23:50       ` dana
  2022-05-15 10:36         ` Daniel Shahaf
  0 siblings, 1 reply; 18+ messages in thread
From: dana @ 2022-05-14 23:50 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 22:31   ` dana
@ 2022-05-15  4:33     ` Bart Schaefer
  2022-05-15  6:00       ` dana
  0 siblings, 1 reply; 18+ messages in thread
From: Bart Schaefer @ 2022-05-15  4:33 UTC (permalink / raw)
  To: dana; +Cc: Axel Beckert, Zsh hackers list

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.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-15  4:33     ` Bart Schaefer
@ 2022-05-15  6:00       ` dana
  0 siblings, 0 replies; 18+ messages in thread
From: dana @ 2022-05-15  6:00 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 23:50       ` dana
@ 2022-05-15 10:36         ` Daniel Shahaf
  2022-05-15 21:43           ` dana
  0 siblings, 1 reply; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-15 10:36 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-15 10:36         ` Daniel Shahaf
@ 2022-05-15 21:43           ` dana
  0 siblings, 0 replies; 18+ messages in thread
From: dana @ 2022-05-15 21:43 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-14 21:50 ` Daniel Shahaf
  2022-05-14 21:58   ` Daniel Shahaf
  2022-05-14 22:27   ` dana
@ 2022-05-16 23:57   ` Phil Pennock
  2022-05-21  1:31     ` Daniel Shahaf
  2 siblings, 1 reply; 18+ messages in thread
From: Phil Pennock @ 2022-05-16 23:57 UTC (permalink / raw)
  To: zsh-workers

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.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Posted zsh 5.9
  2022-05-16 23:57   ` Phil Pennock
@ 2022-05-21  1:31     ` Daniel Shahaf
  0 siblings, 0 replies; 18+ messages in thread
From: Daniel Shahaf @ 2022-05-21  1:31 UTC (permalink / raw)
  To: zsh-workers

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.


^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-05-21  1:31 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-14 20:59 Posted zsh 5.9 dana
2022-05-14 21:50 ` Daniel Shahaf
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

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

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).