Nb. this build was triggered by this Packit configuration 🤷

provide test case for this please 🙏

Direct SRPM upload isn't affected: https://copr.fedorainfracloud.org/coprs/g/copr/copr-dev/build/8583971/

Tito build isn't affected either: https://copr.fedorainfracloud.org/coprs/g/copr/copr-dev/build/8583976/

@mfocko considering we use https://github.com/release-engineering/dist-git/blob/main/.packit.yaml#L40-L44, do you think Packit explicitly selects also epel-7 (if enabled in given copr)?

The latest build: release-engineering/dist-git@9f0bfee
This appears to be a problem in Packit. First, the .packit.yaml config doesn't seem to be respected, then the chroot_denylist is also ignored.

@mfocko considering we use https://github.com/release-engineering/dist-git/blob/main/.packit.yaml#L40-L44, do you think Packit explicitly selects also epel-7 (if enabled in given copr)?

Could you try dropping the metadata section? I can't imagine what the YAML produces off top of my head 👀 If the metadata subdictionary from the trigger: commit overwrites the one from the pull_request we take the targets from the Copr project itself then…

The issue with differentiating the chroots based on the packages (as you've shown in the screenshot above) would not be an easy task to resolve I'm afraid…

Edit: yq seems to agree:

"jobs": [
    {
      "job": "copr_build",
      "packages": [
        "dist-git",
        "dist-git-client"
      ],
      "trigger": "pull_request",
      "metadata": {
        "targets": [
          "fedora-all-x86_64",
          "epel-8-x86_64",
          "epel-9-x86_64",
          "epel-10-x86_64"
        ]
      }
    },
    {
      "job": "copr_build",
      "packages": [
        "dist-git",
        "dist-git-client"
      ],
      "trigger": "commit",
      "metadata": {
        "owner": "@copr",
        "project": "copr-dev",
        "branch": "main"
      }
    }
  ]