I suspect the package leaked from testing-farm-tag-repository, which is https://kojipkgs.fedoraproject.org/repos/rawhide/latest/

We need to prevent this. The glibc32 must not leak to the CI dnf install transaction.

For the Fedora composes, there is some sort of a pungi level mechanism in place preventing glibc32 from leaking to the Fedora compose, glibc developers say.

We need to do something about the presence of glibc32 in the testing-farm-tag-repository too.

well, testing-farm-tag-repository concept is anyway broken for modules (not such a problem for Fedora), maybe we should just drop it?

The only thing which can happen is that the latest deps will be available after they are pushed to stable, instead of available as they are built in koji

@martinpitt any worries about this?

FTR: Here is how glibc32 is filtered out in pungi for fedora:
https://pagure.io/pungi-fedora/blob/main/f/fedora.conf#_166

As @mcermak mentioned above, the mere presence of glibc32 in the tag repo is probably a bug that needs to be fixed. Not adding the tag repository from SUT would fix the original test run, but it would a) hide the actual issue, i.e. glibc32 being available and installable outside of Koji buildroot, and b) could affect the future test runs by not delivering the most up-to-date dependencies.

Would it be possible to ask dnf and yum to not install this package, never ever, until the tag repo gets fixed? Maybe via exclude?

I believe so, pls try to add exclude: glibc32 to prepare install step ...

https://tmt.readthedocs.io/en/stable/spec/plans.html#install

or maybe both ...

I believe so, pls try to add exclude: glibc32 to prepare install step ...

https://tmt.readthedocs.io/en/stable/spec/plans.html#install

Wouldn't it be better to make this exclude as a general rule, on the level of the CI system itself? It's impractical to annotate all tests to avoid an accidental installation of glibc32, as long as it's present, a test may pull it in like it happened now (and did not happen until now...).

The only thing which can happen is that the latest deps will be available after they are pushed to stable, instead of available as they are built in koji

stable seems too late to me -- couldn't this use updates-testing repo? Testing-from-koji indeed feels a little too early -- if it works, fine, but it seems ok to only gate on bodhi, to be able to test related package updates together.

Wouldn't it be better to make this exclude as a general rule, on the level of the CI system itself?

By all means yes -- littering these hacks across hundreds of packages is neither practical nor conceptually the right thing. It's really not ltrace or any other package's fault that glibc32 magically appears somewhere.

Thanks!

@happz

I believe so, pls try to add exclude: glibc32 to prepare install step ...
https://tmt.readthedocs.io/en/stable/spec/plans.html#install

Wouldn't it be better to make this exclude as a general rule, on the level of the CI system itself? It's impractical to annotate all tests to avoid an accidental installation of glibc32, as long as it's present, a test may pull it in like it happened now (and did not happen until now...).

Agreed, we can do it for now in Testing Farm, while not the right place, we cannot do better now, as we lack the support of passing additional excludes via the API.

@martinpitt thanks! yeah, updates-testing could be possible, and it is true that would this particular problem disappear ...

I guess I will need to discuss with Fedora CI folks

@msrb @jbair what do you think about ditching https://kojipkgs.fedoraproject.org/repos/rawhide/latest/ for updates-testing repo, does it make sense to ya?

IMHO this is fixed already per https://issues.redhat.com/browse/TFT-847

@mvadkert @vkadlcik Maybe we could close this out?

Closing