RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1984402 - Support RPM demodularization
Summary: Support RPM demodularization
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libmodulemd
Version: 8.5
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: beta
: ---
Assignee: Petr Pisar
QA Contact: Jan Blazek
Mariya Pershina
URL:
Whiteboard:
: 2008248 (view as bug list)
Depends On: 1984403
Blocks: 1805260
TreeView+ depends on / blocked
 
Reported: 2021-07-21 11:28 UTC by Petr Pisar
Modified: 2021-11-10 08:15 UTC (History)
4 users (show)

Fixed In Version: libmodulemd-2.13.0-1.el8
Doc Type: Enhancement
Doc Text:
.`libmodulemd` rebased to version 2.13.0 The `libmodulemd` packages have been rebased to version 2.13.0, which provides the following notable changes over the previous version: * Added support for delisting demodularized packages from a module. * Added support for validating `modulemd-packager-v3` documents with a new `--type` option of the `modulemd-validator` tool. * Fortified parsing integers. * Fixed various `modulemd-validator` issues.
Clone Of:
: 1984403 (view as bug list)
Environment:
Last Closed: 2021-11-09 19:40:51 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2021:4405 0 None None None 2021-11-09 19:40:58 UTC

Description Petr Pisar 2021-07-21 11:28:12 UTC 
There is a request (bug #1805260) to support hiding old modular packages which where removed from recent module versions.

DNF team proposed adding /data/demodularized/rpms section to modulemd-v2
modular metadata to enable packagers to delist the removed packages.

This feature was implemented in libmodulemd-2.13.0.

I proposed rebasing libmodulemd to 2.13.0. It is fully compatible to 2.12.1
version found in the current RHEL.
Comment 2 Petr Pisar 2021-07-21 14:48:43 UTC 
2.13.0 fixed a bug in parsing buildorder value. This version now complains on loading RHEL-8 repository:

# dnf module list --repoid pulp-appstream
Last metadata expiration check: 3:59:10 ago on Wed 21 Jul 2021 12:38:00 PM CEST.
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 118 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 118 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 107 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 114 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 118 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 118 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 107 col 9]
Module yaml error: Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 114 col 9]
AppStream from Pulp
Name                 Stream          Profiles                      Summary
389-ds               1.4                                           389 Directory Server (base)
[...]

This is because these 4 builds:

container-tools:rhel8:8020120200601155013:ffd2803a:x86_64
container-tools:rhel8:8030020200923153805:2a301c24:x86_64
container-tools:rhel8:8030020201124131330:830d479e:x86_64
container-tools:rhel8:8030120210208205200:c127ee91:x86_64

contain an invalid value there. The affected buildorder looks like this:

      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]

Sources shows there was -1 value. A build system (MBS, libmodulemd?) misparsed the value and stored a bad one. This propagated to mirrors.

A good point is that we already have newer builds, e.g. container-tools:rhel8:8040020210407081426:59631bd5:x86_64, which correctly read -1.
So it effectively does not affect users. Those are historical builds superseded by newer ones.

A bad point is that the warning will annoy the users.

I will look if we can hide the warning by DNF. Or selectively ignore the error. If we cannot, I will revert the parser fix for
RHEL 8 to preserve the invalid, but silent behavior.
Comment 3 Petr Pisar 2021-07-23 13:15:54 UTC 
I resolved the DNF warnings by relaxing the parser. No warnings anymore, the old broken module builds can be processed again. I updated the merge request to apply a patch with the relaxation.
Comment 5 Petr Pisar 2021-08-10 06:57:57 UTC 
A package version in RHEL 8 should not be higher than in RHEL 9. Therefore this upgrade can be pushed into RHEL 8 only after pushing to RHEL 9 (bug #1984403) which has not yet happened.
Comment 6 Petr Pisar 2021-08-12 15:32:07 UTC 
Fixed in:

commit 93951985e28c28d784bbb8b084bae6e428148e35 (HEAD -> rhel-8.5.0, ppisar/rhel-8.5.0-bug1984402, origin/rhel-8.5.0)
Author: Petr Písař <ppisar>
Date:   Wed Jul 21 15:39:19 2021 +0200

    Resolves: #1984402 - 2.13.0 bump
Comment 18 Jindrich Novy 2021-09-29 09:14:15 UTC 
*** Bug 2008248 has been marked as a duplicate of this bug. ***
Comment 21 errata-xmlrpc 2021-11-09 19:40:51 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libmodulemd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:4405
Note You need to log in before you can comment on or make changes to this bug.