Re: intermittent RPM metadata regression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

See https://bugzilla.redhat.com/show_bug.cgi?id=2302033. The source of the issue is that the Requires: environment(modules) in rpm-mpi-hooks (which is a BuildRequirement of openmpi/mpich) did not result in environment-modules getting installed, which broke the dependency generation by rpm-mpi-hooks. I've worked around this by explicitly specifying Requires: environment-modules in rpm-mpi-hooks, and have now rebuilt openmpi. This should solve the broken dependencies. I haven't investigated the failure in resolving "Requires: environment(modules)", which I suspect might be a dnf5 issue.

Sandro

On 31.07.24 16:30, Sandro via devel wrote:
Hi,

It seems something is going on with RPM metadata generation.

With the latest update of openmpi the generated metadata has changed:

$ rpm -q --provides -p openmpi-5.0.5-1.fc41.x86_64.rpm
config(openmpi) = 5.0.5-1.fc41
libmpi.so.40()(64bit)
libmpi_java.so.40()(64bit)
libmpi_mpifh.so.40()(64bit)
libmpi_usempi_ignore_tkr.so.40()(64bit)
libmpi_usempif08.so.40()(64bit)
liboshmem.so.40()(64bit)
mpi
openmpi = 5.0.5-1.fc41
openmpi(x86-64) = 5.0.5-1.fc41

The previous build (during mass rebuild) had:

$ rpm -q --provides -p openmpi-5.0.3-3.fc41.x86_64.rpm
config(openmpi) = 5.0.3-3.fc41
libmpi.so.40()(64bit)(openmpi-x86_64)
libmpi_java.so.40()(64bit)(openmpi-x86_64)
libmpi_mpifh.so.40()(64bit)(openmpi-x86_64)
libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64)
libmpi_usempif08.so.40()(64bit)(openmpi-x86_64)
liboshmem.so.40()(64bit)(openmpi-x86_64)
mpi
openmpi = 5.0.3-3.fc41
openmpi(x86-64) = 5.0.3-3.fc41

The `(openmpi-x86_64)` part has been dropped, causing packages depending on OpenMPI to go FTI with a message like:

can't install sandia-omega-h-openmpi:
  - nothing provides libmpi.so.40()(64bit)(openmpi-x86_64) needed by
sandia-omega-h-openmpi-9.34.13-7.fc41.x86_64

I quick glance didn't show any changes to the rpm package between the two builds, suggesting something else is causing the issue. I'm at a loss as to where this issue needs to be reported and fixed.

To make things even more complicated, my latest scratch build of 5.0.5-1 has the correct metadata just like the 5.0.3-3 build.

5.0.5-1 (broken): https://koji.fedoraproject.org/koji/buildinfo?buildID=2519082 5.0.3-3 (good): https://koji.fedoraproject.org/koji/buildinfo?buildID=2499148 5.0.5-1 (good): https://koji.fedoraproject.org/koji/taskinfo?taskID=121299407

Cheers,

--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux