feat: use vendored sources

[mmartinv]

• fix: use official aws-nitro-enclaves-cose crate
• fix: do not generate vendor tarball in builds
• fix: lock clap_builder to 4.4 version
• feat: use patched vendored sources for builds.
• fix: update packit configuration

[packit-as-a-service[bot]]

Failed to load packit config file:

Cannot parse package config. ValidationError({'jobs': {0: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}, 1: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}, 2: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}})}, 3: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}}, 'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})})

For more info, please check out the documentation or contact the Packit team. You can also use our CLI command validate-config or our pre-commit hooks for validation of the configuration.

[packit-as-a-service[bot]]

Failed to load packit config file:

Cannot parse package config. ValidationError({'jobs': {0: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}, 1: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}, 2: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}})}, 3: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}}, 'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})})

For more info, please check out the documentation or contact the Packit team. You can also use our CLI command validate-config or our pre-commit hooks for validation of the configuration.

[packit-as-a-service[bot]]

Failed to load packit config file:

Cannot parse package config. ValidationError({'jobs': {0: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}, 1: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}, 2: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}})}, 3: {'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})}}, 'packages': defaultdict(<class 'dict'>, {'fido-device-onboard-fedora': {'value': {'actions': ['Field may not be null.']}}, 'fido-device-onboard-centos': {'value': {'actions': ['Field may not be null.']}}})})

For more info, please check out the documentation or contact the Packit team. You can also use our CLI command validate-config or our pre-commit hooks for validation of the configuration.

[7flying]

I think that we are trying to accomplish too many things with these PR when we don't really need all those things. Here are my thoughts and what I understand to be "true"

First of all, as I understand it, this project simply needs to check that things work in Fedora, thereby, as it was before, we only care about making copr builds in Fedora rawhide and the latest Fedora development, both for aarch64 and x86_64.

We don't need to test that packages are built in rhel/c9s because we vendor everything, and since we compile everything ourselves """It Just Works""". It would be nice to have a rhel/c9s CI but as I've understood the PR, it does not replicate the way that we need to build things for rhel/c9s, so if it does not replicate it I would rather save time in CI and I wouldn't run rhel/c9s packaging tests.

When things do not work in rhel/c9s we make specific patches for it in the specific c9s repo, but for "upstream-sake" we had the make-vendored-tarfile script over here too. Due to the way that packaging works in rhel/c9s we do not need a Makefile that spits out an RPM, we need a sprm and a separate tarball with the vendored dependencies. The only thing that I need is a better make-vendored-tarfile or X that filters the windows stuff better.

[mmartinv]

I think that we are trying to accomplish too many things with these PR when we don't really need all those things. Here are my thoughts and what I understand to be "true"

First of all, as I understand it, this project simply needs to check that things work in Fedora, thereby, as it was before, we only care about making copr builds in Fedora rawhide and the latest Fedora development, both for aarch64 and x86_64.

As we discussed in the refinement session we also need to enable CentOS Stream 9 builds at least.

We don't need to test that packages are built in rhel/c9s because we vendor everything, and since we compile everything ourselves """It Just Works""". It would be nice to have a rhel/c9s CI but as I've understood the PR, it does not replicate the way that we need to build things for rhel/c9s, so if it does not replicate it I would rather save time in CI and I wouldn't run rhel/c9s packaging tests.

We need to test the packaging itself and that the resulting RPMs work as expected. The way the RPMs are built in copr is basically the same as in dist-git I believe. Indeed, packit can propose downstream dist-git updates when a new version is released upstream so I think we could even automate some downstream work.

When things do not work in rhel/c9s we make specific patches for it in the specific c9s repo, but for "upstream-sake" we had the make-vendored-tarfile script over here too. Due to the way that packaging works in rhel/c9s we do not need a Makefile that spits out an RPM, we need a sprm and a separate tarball with the vendored dependencies. The only thing that I need is a better make-vendored-tarfile or X that filters the windows stuff better.

What's the difference compared to provide everything, the source code alongside the filtered and patched vendor files, in a single SRPM? Is there any problem I am not aware of? AFAIK osbuild guys already do that with osbuild-composer for example.