Bug 2008248

Summary: An overflowed 18446744073709551615 value in AppStream repository is breaking Koji rpm building system.
Product: Red Hat Enterprise Linux 8 Reporter: Chandan Chouhan <cchouhan>
Component: libmodulemdAssignee: Petr Pisar <ppisar>
Status: CLOSED DUPLICATE QA Contact: swm-qe
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.4CC: jligon, jnovy, lsm5, ppisar
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-27 17:32:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chandan Chouhan 2021-09-27 17:13:55 UTC
Description of problem:

Customer is unable to build RPMs using Koji build system and its failing because there is an 18446744073709551615 value in AppStream repository.

Cu comments:
-----
When we are trying to build repo for a build with RHEL 8 repos for the AppStream repo.
Executing the below command manually:
mergerepo_c -vvvvv --pkgorigins --all -a x86_64 -o
gives error: Critical error

We added debug option in 'mergerepo_c' and found the below error:
- Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 118 col 9]
-----


As per customer it's in the RHEL8 AppStream repo in b908341a8d8eecd1795f536be5031fe4b3ce861baab32ecffd1a3402358df71b-modules.yaml.gz file.

---
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]
---


For more information, see C#15 in https://bugzilla.redhat.com/show_bug.cgi?id=1984402

Comment 1 Jindrich Novy 2021-09-27 17:32:06 UTC
Seems that either libmodulemd/mergerepo_c or repodata has a type mismatch in the build_order tag - it is defined as -1 so that libslirp is built prior to slirp4netns within the module. If the metadata are broken, as noted in https://bugzilla.redhat.com/show_bug.cgi?id=1984402#c15 then it is nothing we can do, as package maintainers of container-tools.

Release engineering needs to untag the broken builds - I requested that in https://issues.redhat.com/browse/RHELDST-8196 - EXD should update https://bugzilla.redhat.com/show_bug.cgi?id=1984402 once they address the issue.

Thank you for reporting this issue.

Comment 4 Jindrich Novy 2021-09-29 09:14:15 UTC

*** This bug has been marked as a duplicate of bug 1984402 ***