Update to 2022.07

[m-dango]

At the time of writing, the specified key is not available on a public keyserver.

[m-dango]

Outside of the gpg stuff this is pretty much the same as the change made for the last update: #46

[patrickbkr]

Earlier today I pushed this key to keys.openpgp.org. But it's doesn't have a verified email address associated yet. (Should happen in the coming days.)
Do you think using a keyserver is preferable to accessing the key on rakudo.org? If so this could be changed to use keys.openpgp.org.

[jonathanstowe]

Do you think using a keyserver is preferable to accessing the key on rakudo.org?

It would make it easier for people to sign the key if nothing else.

[m-dango]

I'm happy for either this to go ahead as is, or wait if there are any objections to the current key setup.

[patrickbkr]

@jonathanstowe Sadly keys.openpgp.org strips all signing info off of the keys. That's one of the reasons why I put the keys on rakudo.org as well (the keys there aren't stripped).

@m-dango If you verify the fingerprint by just hard-coding it (this PR doesn't anymore) then it doesn't matter if the key is loaded from rakudo.org or a keyserver. Can you make it so?

[m-dango]

@patrickbkr I wasn't quite sure what you meant, I've added a line which should error if the specified key has not been imported.

[patrickbkr]

@m-dango Yes, that should do it.
I was thinking about the scenario of an attacker changing both the file as well as the key on rakudo.org. Now that won't succeed anymore, because you have hard-coded the key fingerprint in the PR.

[patrickbkr]

Who usually merges PRs in this repo? Is there any procedure apart from pushing the "merge" button?

[tianon]

Doesn't this just verify that $keyfp is in the set of keys imported?
(I think this still leaves it open to an extra key getting injected into the file on the server which will then satisfy --batch --verify as long as the original key exists in the imported file too)

In cases like this previously I've suggested something like gpg --import ... && gpg --export FULL-FINGERPRINT > some-new-file && rm -rf GNUPGHOME && gpg --import some-new-file 🙈

[m-dango]

I'm on a mobile connection so can't test locally at the moment, bear with me…

[sorairolake]

Why use bookworm (testing) instead of bullseye (stable)?

[m-dango]

Just picked what I saw was latest, hadn't realised it wasn't a stable release!

[patrickbkr]

@AntonOks Do you know where the 2022.06.1 release came from? There is no 2022.06.1 Rakudo release and no such GitHub Star release. It's only present on rakudo.org and the files are older than those of 2022.06.

[AntonOks]

@patrickbkr Yes, that's a "hand made Star-only" release... made after your latest GPG / signing fixes there.

Remember, the GH workflows were not running for some time... so after our discussion, I rolled-back your changes, a GH workflow build was successfully done and a Star-2022.06 release was created and deployed.
Then you found some time to fix the signing thing, you re-undid my undo and the GH workflow was still / again successful.
As ppl may have had installed the previous 2020.06 Star already, the newest release Star had to have another name. So I adopted the latest release to "patch 1".

[patrickbkr]

@AntonOks OK. Then I understand. Are you aware of the build revision number in the release files (the `-01` thing in the filename)? The idea is to increment that number when doing a rebuild of the same underlying Rakudo release. Then there won't be a collision should Rakudo do a fixup release as well and it's obvious which version of Rakudo was used. (I think there actually was some discussion around a potential 2022.06.1 Rakudo release, but it luckily didn't materialize.) I think this time it's better to leave the star release 2022.06.1 up (instead of replacing it with a 2022.06-01).

On July 8, 2022 2:12:36 PM GMT+02:00, Anton Oks ***@***.***> wrote: >

***@***.*** Yes, that's a "hand made Star-only" release... made after your latest GPG / signing fixes there.

…

Remember, the GH workflows were not running for some time... so after our discussion, I rolled-back your changes, a GH workflow build was successfully done and a Star-2022.06 release was created and deployed. The you found some time to fix the signing thing, you re-undid my undo and the GH workflow was still / again successful. As ppl may have had installed the previous 2020.06 already, the newest release had to have another name. So I adopted the latest release to "patch 1". -- Reply to this email directly or view it on GitHub: #50 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[patrickbkr]

@m-dango Sorry to intervene once more. Can you change the PR to name the docker image 2022.06 (without the .1)? That will hopefully limit the confusion surrounding a non-existing 2022.06.1 Rakudo release.

@AntonOks I'm not sure about this. Will changing the version number to 2022.06 do the right thing?

[AntonOks]

@AntonOks OK. Then I understand. Are you aware of the build revision number in the release files (the -01 thing in the filename)? The idea is to increment that number when doing a rebuild of the same underlying Rakudo release. Then there won't be a collision should Rakudo do a fixup release as well and it's obvious which version of Rakudo was used.

Well, I'm aware of the description on https://rakudo.org/downloads in the "Binary Releases" => rakudo-[backend]-[version]-[build revision]-[OS]-[architecture]-[toolchain]. But what is version and what is build revision exactly?

Should version be anything like:

• YYYY.MM
• YYYY.MM.[1-9]

And is revision then:

• -[0-9][1-9]

And does this mean, version for the Binary Releases has always to be exactly the same as the Rakudo version, but the revision can be changed for the Windows, Linux and MacOS binary releases as desired / needed?

As you see, for me it's still not clear when to change which of those patch numbers. I was looking for a good docu / explanation months ago but didn't find something, which helped me to figure it out...

[AntonOks]

@AntonOks I'm not sure about this. Will changing the version number to 2022.06 do the right thing?

"do the right thing" where? Are you talking about this docker file / build / release? If so, I must admit, I have no idea how and where the docker magic happens today.

There is rakudo/star#171 and I looked at this one some time ago. But as said above, couldn't figure out why there seem to be different docker files / builds

1. https://github.com/rakudo/star/tree/master/lib/docker
2. https://github.com/Raku/docker (this here)
3. https://github.com/docker-library/official-images/blob/master/library/rakudo-star | https://github.com/docker-library/docs/tree/master/rakudo-star

and when which is used where....

Maybe you, or somebody else, can enlighten me?

[patrickbkr]

But what is version and what is build revision exactly?

The idea is: version is the Rakudo release number under control of the Rakudo release manager. build revision is a number under control of the packager (of a given package, e.g. binary releases on rakudo.org, the Star bundle or distro packages).

Should version be anything like:

* YYYY.MM

* YYYY.MM.[1-9]

And is revision then:

* -[0-9][1-9]

And does this mean, version for the Binary Releases has always to be exactly the same as the Rakudo version, but the revision can be changed for the Windows, Linux and MacOS binary releases as desired / needed?

That's it.

As you see, for me it's still not clear when to change which of those patch numbers. I was looking for a good docu / explanation months ago but didn't find something, which helped me to figure it out...

I'm sorry about that. Currently there is no documentation. The best place I can think of to put this would be /doc/release-guide-binary.md in the rakudo repo, even though it doesn't fit perfectly. Do you have a better idea?

[patrickbkr]

@AntonOks I'm not sure about this. Will changing the version number to 2022.06 do the right thing?

"do the right thing" where? Are you talking about this docker file / build / release? If so, I must admit, I have no idea how and where the docker magic happens today.

Yes, I'm talking about the downstream docker stuff. (Unsure what exactly that encompasses.)

There is rakudo/star#171 and I looked at this one some time ago. But as said above, couldn't figure out why there seem to be different docker files / builds

1. https://github.com/rakudo/star/tree/master/lib/docker

2. https://github.com/Raku/docker (this here)

3. https://github.com/docker-library/official-images/blob/master/library/rakudo-star | https://github.com/docker-library/docs/tree/master/rakudo-star

and when which is used where....

Maybe you, or somebody else, can enlighten me?

Looking at the commiters in https://github.com/docker-library/official-images/blob/master/library/rakudo-star. Ping @jmaslak, @m-dango.

[AntonOks]

... Do you have a better idea?

No. Any place would be good, I guess...

[m-dango]

@patrickbkr I'm not sure where the first link you have listed comes into play, I don't think I've seen that one before. docker-official uses this repository as the source for building the images present on https://hub.docker.com/_/rakudo-star

I'll likely bump this to 2022.07.

[patrickbkr]

docker-official uses this repository as the source for building the images present on https://hub.docker.com/_/rakudo-star

I guess this is good to go then.