search

Raku / docker

Docker files for Rakudo Star
Artistic License 2.0
34 stars 22 forks source link

Update to 2022.07 #50

Closed m-dango closed 2 years ago

m-dango commented 2 years ago

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

m-dango commented 2 years ago

Outside of the gpg stuff this is pretty much the same as the change made for the last update: https://github.com/Raku/docker/pull/46

patrickbkr commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

patrickbkr commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

m-dango commented 2 years ago

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

sorairolake commented 2 years ago

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

m-dango commented 2 years ago

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

patrickbkr commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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: https://github.com/Raku/docker/pull/50#issuecomment-1178917980 You are receiving this because you were mentioned.

Message ID: @.***>

patrickbkr commented 2 years ago

@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 commented 2 years ago

@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:

And is revision then:

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 commented 2 years ago

@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 https://github.com/rakudo/star/issues/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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

... Do you have a better idea?

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

m-dango commented 2 years ago

@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 commented 2 years ago

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.