dusty / failed-composes

#1540 Fedora-28-updates-20190301.0 DOOMED
Opened by dustymabe. Modified

Open
Close Issue

pungi.global.log

[ERROR   ] [FAIL] Ostree (variant Everything, arch x86_64) failed, but going on anyway.
[ERROR   ] Runroot task failed: 33110464. See /mnt/koji/compose/updates/Fedora-28-updates-20190301.0/logs/x86_64/Everything/ostree-4/runroot.log for more details.

[ERROR   ] [FAIL] Ostree (variant Everything, arch ppc64le) failed, but going on anyway.
[ERROR   ] Runroot task failed: 33110463. See /mnt/koji/compose/updates/Fedora-28-updates-20190301.0/logs/ppc64le/Everything/ostree-2/runroot.log for more details.

[ERROR   ] [FAIL] Ostree (variant Everything, arch aarch64) failed, but going on anyway.
[ERROR   ] Runroot task failed: 33110462. See /mnt/koji/compose/updates/Fedora-28-updates-20190301.0/logs/aarch64/Everything/ostree-3/runroot.log for more details.
  • Compose run failed because: - 33110461
[ERROR   ] Compose run failed: Runroot task failed: 33110461. See /mnt/koji/compose/updates/Fedora-28-updates-20190301.0/logs/x86_64/Everything/ostree-1/runroot.log for more details.

nothing provides python3-libmodulemd needed by pungi-4.1.32-3.fc28.noarch

@sinnykumari can you look into this?

With the libmodulemd commit, we are no longer building 2.0 API for F28. This caused only to have python3-libmodulemd1- package in latest f28 libmodulemd build (which hit bodhi f28-updates pushes couple of hours back) . As a result, we now only have python3-libmodulemd1 package available in latest f28-updates repo. But, if we look at f28 pungi spec file it requires python3-libmodulemd for fedora <30.
@sgallagh I think we need to make necessary fixes either in pungi or libmoduledmd, whatever makes best sense.

This is incorrect. F28 never had the 2.0 API. It had the 1.0 API which owned the python3-libmodulemd name.

This update moved to rename the 1.0 API to python3-libmodulemd1 and should have had the correct Obsoletes/Provides so that other packages would pull it in instead.

It was also originally going to include the python3-libmodulemd package for the 2.0 API, but that caused issues with DNF, which had overspecified the dependency on libmodulemd.

I’ll look into this today.

Okay, I see the problem. I added the Obsoletes/Provides for the libmodulemd subpackage and apparently missed the python3-libmodulemd subpackage. Argh.

I’ll get a fix out ASAP.

We probably should also fix that dependency in Pungi though, since it really should just be Requires: python3-libmodulemd on F28+.

looks like this is attempted to be fixed in: https://src.fedoraproject.org/rpms/pungi/c/98b8c0ab917a8fc5f4e2d204bd9a4835be7b164d?branch=master and https://src.fedoraproject.org/rpms/pungi/c/69dd774d0d0891d758c908601415b4d5fec69da5?branch=master

I've also got fixes I'm working on for Fedora, but I'm hitting some issues with performance on armv7hl builders causing my tests to time out.

Libmodulemd update (F28): https://bodhi.fedoraproject.org/updates/FEDORA-2019-00404bae09
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.