Add fedora 39 (not released yet).

[thaJeztah]

• carries / supersedes Add fedora 39 (not release yet). #315
• closesAdd fedora 39 (not release yet). #315

[thaJeztah]

Looks like some changes are needed;

 > [fedora-base 2/2] RUN dnf install -y rpm-build git dnf-plugins-core:
[173/173] libuuid-0:2.39.2-1.fc40.x86_6 100% | 236.8 KiB/s | 27.9 KiB | 00m00s
17.00 --------------------------------------------------------------------------------
17.00 [173/173] Total 100% | 6.8 MiB/s | 57.2 MiB | 00m08s
17.00 Running transaction
18.11 18.11 Transaction failed: Rpm transaction failed.
18.11 - file /etc/dnf/dnf.conf from install of dnf-data-4.16.2-4.fc40.noarch conflicts with file from package libdnf5-5.1.0-2.fc39.x86_64

[thaJeztah]

curious where the fc40 comes from here; does the image still contain some rawhide bits?

[thaJeztah]

Alright, so the Docker Hub image still points to "rawhide", so maybe we're just "too soon", although the release-branch was cut, so maybe docker hub's config needs to decouple Fedora 39 from rawhide (I'll check how that's usually done)

[thaJeztah]

Looks like it's still in some intermediate state;

docker run --rm fedora:39 cat /etc/os-release
NAME="Fedora Linux"
VERSION="39 (Container Image Prerelease)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Container Image Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
SUPPORT_END=2024-05-14
VARIANT="Container Image"
VARIANT_ID=container

[thaJeztah]

Good news, it looks like we have lift-off for Fedora 39 images; the Fedora maintainers published a new image today, and it's no longer "rawhide";

docker run --rm fedora:39 cat /etc/os-release
NAME="Fedora Linux"
VERSION="39 (Container Image Prerelease)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Container Image Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-05-14
VARIANT="Container Image"
VARIANT_ID=container

[thaJeztah]

It's green! /cc @neersighted

[Romain-Geissler-1A]

Cool, thank you for taking this one over.

In practice, only the docker/moby maintainer can submit these pull requests (because of the problem of the Jenkinsfile update not being taken into account for "untrusted" people like me with no write access to the repo). Will it stay like this for ever ? Because it seems to be a barrier to contribution (at least for this repo, where changing the Jenkinsfile is meant to happen often, contrary to other repositories).

[thaJeztah]

For Jenkins, yes, we unfortunately can't change that, but we want to ultimately move to GitHub actions; the blocker is currently that GitHub actions doesn't have arm64 (or any other architectures), but that's definitely something we continue looking at (we want to remove all the Jenkins infrastructure)

[neersighted]

Although to be clear, I doubt we'll shift to a policy of allowing anyone who is not employed at Docker Inc. to publish to the live download.docker.com.

[Romain-Geissler-1A]

Although to be clear, I doubt we'll shift to a policy of allowing anyone who is not employed at Docker Inc. to publish to the live download.docker.com.

I am not really a regular contributor, so it doesn't apply to me, but my own opinion is that ideally there should be "trusted people", and wether they work or don't work in Docker Inc. should matter, as this is normally an open source project. (FYI we deployed the very same rules internally in my company, and team A can now less easily contribute to the repo of team B, in the same company... and in the end people as a consequence just tend to stop contributing).

[neersighted]

Accepting contributions to the repository is separate from publishing the built artifacts to the live repositories. That's the distinction I'm trying to make -- e.g. after this merge, manual action will be required to push a set of packages live.

[Romain-Geissler-1A]

Ah yes sure, on the post merge actions I agree with you and have no concern ;)