Do you've example for the problematic repo? It looks to me more like some bug in createrepo_c/mergerepo_c as either the first creates problematic repo or second can't merge correct repo? Last option is that problem is in libmodulemd. But I need to see the repos first. In any case I don't think it can/should be fixed in koji.

Hi @tkopecek,

Do you've example for the problematic repo?

It's in the RHEL8 AppStream repo in b908341a8d8eecd1795f536be5031fe4b3ce861baab32ecffd1a3402358df71b-modules.yaml.gz

      libslirp:
        rationale: Primary component of this module
        ref: stream-container-tools-rhel8-rhel-8.3.0
        buildorder: 18446744073709551615
        arches: [aarch64, i686, ppc64le, s390x, x86_64]

@ppisar It looks to me like two problems:
1) Should really libmodulemd fail on such number?
2) Such value should never been there (I'll look how it got created). @mikem could it be some MBS issue/overflow?

@ppisar Ah, found that in source yaml is literally "-1", so is libmodulemd converting it to unsigned number and now it can't parse what it produced earlier?

Hi @tkopecek,

2) Such value should never been there (I'll look how it got created)

Thanks for looking into this.

For the record I pushed two PRs in createrepo_c - The first improves mergerepo_c error log that got merged and second to exit with status code 1 when mergerepo_c can't load the metadata.

I know about this issue and libmodulemd's upstream has already a workaround https://github.com/fedora-modularity/libmodulemd/commit/37a688cc12d7fbab67fda95c47a4605405d7a154 for it. That workaround is a new build-time option which enables accepting the invalid, overflowed 18446744073709551615 value.

The workaround is enabled in RHEL libmodulemd builds because the only place where these invalid values exist is RHEL. With the same reason the workaround has not been applied to Fedora. If you really need to process RHEL repository metadata with Fedora's libmodulemd, I can apply and enable the workaround in Fedora. But I'm not happy with it. I'd rather see either fixing the invalid value on import from RHEL, or if you process RHEL repository for RHEL compose, using RHEL libmodulemd.

Now answers to your questions:

1) The value is out of specification. Thus it is correctly rejected.
2) It was a bug in an old libmodulemd which produced these invalid modulemd files and which were shipped to RHEL mirrors. See that linked commit for more details.

So my question is: Do I really have to enable the workaround in Fedora?

Hmm, understood.
@bukich - I'm not sure what environment is manifesting this problem. If it is Fedora I would file a ticket in https://pagure.io/releng/ to repeat Petr's question if Fedora's relengs are willing to handle it this way. If it is some other environment I would suggest to carry on Petr's patch in given libmodule's package.

Anyway, it is out of koji's playground. /I'll close ticket here/

Hi @ppisar,

So my question is: Do I really have to enable the workaround in Fedora?

We would like to have it fixed in Fedora as our Koji instance is installed on Fedora and we need to build packages for RHEL8.

Or alternatively just fix the AppStream repo to not contain this invalid buildorder.

I'll cut a new release of createrepo_c now, though I cannot release into Fedora.

I've released createrepo_c-0.17.5: https://github.com/rpm-software-management/createrepo_c/releases/tag/0.17.5

@dmach, @pkratoch: Could we please get this released into Fedora today?

Hi @tkopecek

@bukich - I'm not sure what environment is manifesting this problem.

It's a custom Koji instance running on Fedora 34.

If it is Fedora I would file a ticket in https://pagure.io/releng/ to repeat Petr's question if Fedora's relengs are willing to handle it this way.

It's not related to Fedora.

If it is some other environment I would suggest to carry on Petr's patch in given libmodule's package.

I would like to see this fixed in the Fedora's libmodulemd package as I would like to keep updating our instance with all the latest versions and I don't want to keep rebuilding packages with custom modifications. Alternatively I'm OK if RedHat fix the AppStream repo (I don't know where to report this)

I will apply the workaround to Fedora's libmodulemd because it's simple. But be warned that Fedora does not guarantee a compatibility with RHEL. It's actually probable that Fedora will evolve somewhere else pretty quickly.

You can file a ticket at Red Hat support https://access.redhat.com/support for correcting the invalid data in AppStream repository.

Here https://bodhi.fedoraproject.org/updates/FEDORA-2021-e385a5fa58 is the libmodulemd update for Fedora 34.

@ngompa I've released createrepo_c-0.17.5 to Fedora. Here is update for Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f010ab5758