Comments

2210 Comments
karma

This bumps the soname without rebuild any of the dependencies, which is why it failed tests. That's not how you should do things any more. You should build re2 on a side tag, ask for maintainers of the dependencies to rebuild them on the side tag (or, if the maintainers don't respond, get a provenpackager to do it), then create a combined update.

This fails tests for the same reason as the F39 update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-097eb22907#comment-3421192 . Waiting to hear from @nfrayer before deciding what to do.

ah, to be fair, it looks like you waited for those to go stable, then submitted this. the tests failed because no compose happened between those going stable and this being submitted. for rawhide update tests openQA configures the koji buildroot repository so it gets things that go stable as soon as they go stable; we don't currently do this for branched before the point where branched updates require karma or time-in-testing to go stable, but maybe we should. for now I'll have to add them as 'workarounds' to make the tests pass without waiting for the next compose.

So, the reason this failed tests is a bit unique. They're failing on a sanity check in the openQA tests: it checks whether the test actually has a newer version of the package installed than is present in the update under test, and if so, it flags that as a problem. Usually what that means is that, somehow, a newer package already got pushed stable, and pushing the update-under-test stable would move the package backwards, but that's not how it is in this case.

In this case, the openQA server base image is actually hacked up to use a grub2 build from a side repo (https://adamwill.fedorapeople.org/grubxfs-repo/ ), which I rather arbitrarily versioned grub2-2.06-118.fc39. So it's higher-versioned than the one in this update, so it triggers the failure.

The reason why I'm doing that is https://bugzilla.redhat.com/show_bug.cgi?id=2259266 (which current affects F39). If I let the openQA server base image use the current stable grub2 package, it doesn't boot because of that bug.

So...it would make things much easier if this update fixed that bug, is what I'm saying. :P Otherwise I'll have to do a hack like disabling the check just for this update so it can go through.

I thought that bug was supposed to be getting fixed last week; what's the current status, @nfrayer ?

This should have been grouped in a single update with perl-Compress-Raw-Zlib and perl-Compress-Raw-Bzip2 , which it depends on. They have now gone stable, so I'll re-run the tests and they should hopefully pass.

negative karma. there's a threshold where, if it's reached, the update is automatically unpushed, which bodhi sometimes calls "obsoleted" (it's not quite the same thing as a package being "obsoleted", as in nothing needs to "obsolete it", it can be intransitive). the default value is -3 and almost nobody ever changes it.

I looked into what the problem was here and I'm sending a fix.

This has a dependency issue:

Problem 1: cannot install the best update candidate for package f39-backgrounds-kde-39.0.4-1.fc39.noarch
  - nothing provides kde4-filesystem needed by f39-backgrounds-kde-39.0.5-1.fc39.noarch from advisory

That is, there's no launcher in the favorites bar at the bottom. Sorry to be unclear.

So we've fixed most of the issues with this now, but one remains: there's no Firefox launcher in the overview.

karma

This seems to have dependency issues:

Problem 1: package qt5-qtdeclarative-5.15.11-2.fc38.x86_64 from @System requires qt5-qtbase(x86-64) = 5.15.11, but none of the providers can be installed
  - cannot install both qt5-qtbase-5.15.12-5.fc38.x86_64 from advisory and qt5-qtbase-5.15.11-7.fc38.x86_64 from @System
  - cannot install both qt5-qtbase-5.15.11-7.fc38.x86_64 from updates and qt5-qtbase-5.15.12-5.fc38.x86_64 from advisory
  - cannot install the best update candidate for package qt5-qtdeclarative-5.15.11-2.fc38.x86_64
  - cannot install the best update candidate for package qt5-qtbase-5.15.11-7.fc38.x86_64
 Problem 2: package qt5-qtxmlpatterns-5.15.11-1.fc38.x86_64 from @System requires qt5-qtbase(x86-64) = 5.15.11, but none of the providers can be installed
  - package qt5-qtbase-5.15.11-7.fc38.x86_64 from @System requires qt5-qtbase-common = 5.15.11-7.fc38, but none of the providers can be installed
  - package qt5-qtbase-5.15.11-7.fc38.x86_64 from updates requires qt5-qtbase-common = 5.15.11-7.fc38, but none of the providers can be installed
  - cannot install both qt5-qtbase-common-5.15.12-5.fc38.noarch from advisory and qt5-qtbase-common-5.15.11-7.fc38.noarch from @System
  - cannot install both qt5-qtbase-common-5.15.11-7.fc38.noarch from updates and qt5-qtbase-common-5.15.12-5.fc38.noarch from advisory
  - cannot install the best update candidate for package qt5-qtxmlpatterns-5.15.11-1.fc38.x86_64
  - cannot install the best update candidate for package qt5-qtbase-common-5.15.11-7.fc38.noarch
 Problem 3: package qt5-qtx11extras-5.15.11-1.fc38.x86_64 from @System requires qt5-qtbase(x86-64) = 5.15.11, but none of the providers can be installed
  - cannot install both qt5-qtbase-5.15.12-5.fc38.x86_64 from advisory and qt5-qtbase-5.15.11-7.fc38.x86_64 from @System
  - cannot install both qt5-qtbase-5.15.11-7.fc38.x86_64 from updates and qt5-qtbase-5.15.12-5.fc38.x86_64 from advisory
  - package qt5-qtbase-gui-5.15.12-5.fc38.x86_64 from advisory requires qt5-qtbase(x86-64) = 5.15.12-5.fc38, but none of the providers can be installed
  - cannot install the best update candidate for package qt5-qtx11extras-5.15.11-1.fc38.x86_64
  - cannot install the best update candidate for package qt5-qtbase-gui-5.15.11-7.fc38.x86_64
 Problem 4: package qt5-qtwebview-5.15.11-1.fc38.x86_64 from @System requires qt5-qtbase(x86-64) = 5.15.11, but none of the providers can be installed
  - cannot install both qt5-qtbase-5.15.12-5.fc38.x86_64 from advisory and qt5-qtbase-5.15.11-7.fc38.x86_64 from @System
  - cannot install both qt5-qtbase-5.15.11-7.fc38.x86_64 from updates and qt5-qtbase-5.15.12-5.fc38.x86_64 from advisory
  - package qt5-qtbase-mysql-5.15.12-5.fc38.x86_64 from advisory requires qt5-qtbase(x86-64) = 5.15.12-5.fc38, but none of the providers can be installed
  - cannot install the best update candidate for package qt5-qtwebview-5.15.11-1.fc38.x86_64
  - cannot install the best update candidate for package qt5-qtbase-mysql-5.15.11-7.fc38.x86_64

It seems qt5-qtbase-5.15.11-7.fc38 is the current stable for F38, so this is actually version bump, which perhaps is inappropriate? Should the CVE fix instead be backported to 5.15.11? For F39, there was a megaupdate to bump to 5.15.12, but that did not happen for F38.

the CI functional test failed because:

# Failed to cache image registry.fedoraproject.org/fedora-toolbox:40 to /tmp/bats-run-YNradM/image-cache/fedora-toolbox-40
# time="2024-02-15T12:18:28Z" level=fatal msg="copying system image from manifest list: writing blob: write /tmp/bats-run-YNradM/image-cache/fedora-toolbox-40/dir-put-blob2317408516: no space left on device"

maybe let's just retrigger...

We have untagged this update to prevent the lack of a webkitgtk rebuild breaking Rawhide composes.

We'll have to figure out how to get it landed once webkitgtk is buildable, but for now keeping Rawhide composing and working takes priority. See https://pagure.io/releng/issue/11952

oh, hmm, thinking it through a bit, we probably are running into branching weirdness here, because the effect of this update is to kinda make the SUT think it's rawhide after branching - it thinks it's "F41" to some extent (because the "f40" base images for openQA are, of course, Rawhide images, at present). that's probably messing things up a bit. we'll probably need to get a branched compose through in order to be able to straighten things out - so we can build 'f40' base images for openQA that are really branched-f40, not rawhide. This is a chicken-and-egg situation we typically run into with branching nowadays. We will probably have to waive this.

so the installer build test is failing in an awkward way. lorax just logs this:

2024-02-13 12:23:55,453 ERROR pylorax.ltmpl: The transaction process has ended abruptly: 
2024-02-13 12:23:55,480 ERROR pylorax.ltmpl: template command error in runtime-install.tmpl:
2024-02-13 12:23:55,484 ERROR pylorax.ltmpl:   run_pkg_transaction
2024-02-13 12:23:55,487 ERROR pylorax.ltmpl:   RuntimeError
2024-02-13 12:23:55,488 DEBUG pylorax.ltmpl:   Traceback (most recent call last):
2024-02-13 12:23:55,488 DEBUG pylorax.ltmpl:     File "/usr/lib/python3.12/site-packages/pylorax/ltmpl.py", line 829, in run_pkg_transaction
2024-02-13 12:23:55,488 DEBUG pylorax.ltmpl:       raise RuntimeError(err)
2024-02-13 12:23:55,488 DEBUG pylorax.ltmpl:   RuntimeError

what I think that really translates to is "we constructed a dnf5 transaction then called transaction.run() on it, the result was not dnf5.base.Transaction.TransactionRunResult_SUCCESS, but calling transaction.get_transaction_problems() returned an empty iterable" (because lorax constructs the err for RuntimeError by using get_transaction_problems()). We'd have to do more digging to figure out what's actually going wrong. Not sure if this is just transient branching weirdness or actually a real problem that's going to persist.

Ah, I believe that's the experimental image built by osbuild - https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder . We don't run that one through openQA yet, though we probably should, I just need to get around to implementing it. It's not the "Official" image yet, though. It would be worth reporting...somewhere...that it's not doing the right thing with SELinux, I guess.

for the record, this was "stuck" because its fedora-ci.koji-build./plans/public.functional test failed. The failure looks a bit odd to me, but the mechanism is working appropriately: that test is configured as a gating test for rrdtool. jskarvad has now waived the failure, though I don't know whether or not that was appropriate.

looks like the test this was waiting on ran for several hours and eventually blew up due to a db outage. I'll see if CI folks can retrigger it.

should the passwd package be retired now? that does not seem to have happened.