#703 Fedora-28-updates-20180828.0 DOOMED
Opened 5 years ago by dustymabe. Modified 5 years ago

pungi.global.log

[INFO    ] [FAIL] Ostree (variant Everything, arch x86_64) failed, but going on anyway.
[INFO    ] Runroot task failed: 29347059. See /mnt/koji/compose/updates/Fedora-28-updates-20180828.0/logs/x86_64/Everything/ostree-4/runroot.log for more details.
[INFO    ] [FAIL] Ostree (variant Everything, arch aarch64) failed, but going on anyway.
[INFO    ] Runroot task failed: 29347056. See /mnt/koji/compose/updates/Fedora-28-updates-20180828.0/logs/aarch64/Everything/ostree-3/runroot.log for more details.
[INFO    ] [FAIL] Ostree (variant Everything, arch ppc64le) failed, but going on anyway.
[INFO    ] Runroot task failed: 29347057. See /mnt/koji/compose/updates/Fedora-28-updates-20180828.0/logs/ppc64le/Everything/ostree-2/runroot.log for more details.
  • Compose run failed because: - 29347058
[ERROR   ] Compose run failed: Runroot task failed: 29347058. See /mnt/koji/compose/updates/Fedora-28-updates-20180828.0/logs/x86_64/Everything/ostree-1/runroot.log for more details.

hmm the ostree composes are failing with: rpm-ostree: symbol lookup error: /lib64/librpmostree-1.so.1: undefined symbol: rpmtsSetVfyLevel. might need a buildroot override

The rpm-ostree update depends on https://bodhi.fedoraproject.org/updates/FEDORA-2018-16c78b3d92 (but Bodhi has no way to express this).

I can at least manually add a versioned runtime dependency on librpm.

I am a little bit confused though about this since that's an updates compose and not updates-testing? I thought bodhi used the same root for the task (since neither are in updates the newer one shouldn't be used?)

That said I don't think it's really been worth the pain involved in making things circular here (rpm-ostree version used to compose is same as shipped in update).

Ohh wait I see the problem, the rpm-ostree update was submitted for stable before the rpm one. So we probably need to move it back to testing.

Ohh wait I see the problem, the rpm-ostree update was submitted for stable before the rpm one. So we probably need to move it back to testing.

right. so our options here are

  1. throw away this compose and move the rpm-ostree update back to testing
  2. throw away this compose and submit the rpm bodhi update for stable (it's got plenty of karma already)
  3. push this update through using a buildroot override of rpm knowing the next compose will get the fix.

I think I'm in favor of option #2

I can at least manually add a versioned runtime dependency on librpm

I do think we should do this too for the next rpm-ostree update at least. In cases where people just download the fedora:28 container and dnf install rpm-ostree they would get bit I think.

Option 4 - delete the rpm-ostree update and add its contents to the RPM one.

2 throw away this compose and submit the rpm bodhi update for stable (it's got plenty of karma already)

@pmatilai can we submit https://bodhi.fedoraproject.org/updates/FEDORA-2018-16c78b3d92 for stable?

Option 4 - delete the rpm-ostree update and add its contents to the RPM one.

yeah, that's an option but I think it would reset the karma on both, whereas currently they both have enough karma to go in

"The rpm-ostree update depends on https://bodhi.fedoraproject.org/updates/FEDORA-2018-16c78b3d92 (but Bodhi has no way to express this)."

Just for the record, it is actually Fedora policy that in this case the packages should be in the same update:

"When one updated package requires another (or more than one other), the packages should be submitted together as a single update."

It's unfortunate that this gets awkward fast due to permission problems and you can't 'fix' it if two separate updates have already been submitted without the intervention of someone with Bodhi superpowers or doing a superfluous bump-and-rebuild of one of the packages, but...it is the policy. Specifically to avoid situations like this.

opened a ticket to have rpm-ostree removed from this bodhi run, also pinged the rpm team to get the rpm update submitted for stable so the next run should be good

No, I don't want the rpm update in stable yet. It needs time and breadth of testing from wider use more than positive karma. If nothing bad comes up by end of next week, I'll probably push it to stable but don't count on it.

thanks @pmatilai - we'll add the rpm-ostree update to the rpm update then so they can go in together.

Log in to comment on this ticket.

Metadata