This update includes several bug fixes from the upstream glibc release branch in addition to a performance improvement for getrandom, and improvements to packaging and testing at build-time.
This update has been submitted for testing by submachine.
The openQA test failures here are strange but seem solid and real. It looks like this, somehow, breaks the Python udev library's loading of the system udev library?
We get a traceback from anaconda that ends like this:
File "/usr/lib/python3.12/site-packages/pyudev/core.py", line 59, in __init__
self._libudev = load_ctypes_library("udev", SIGNATURES, ERROR_CHECKERS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/pyudev/_ctypeslib/utils.py", line 51, in load_ctypes_library
raise ImportError("No library named %s" % name)
ImportError: No library named udev
openQA has two tests that build traditional installer images, one that builds a netinst, one that builds an ostree installer image. For each of those, we run two 'downstream' tests that boot the image (one UEFI, one BIOS). Each test is retried once automatically if it fails. All four of those tests failed both tries, so eight failures in all. The same problem did not occur on other F40 update tests run before or after the tests for this update, indicating that the failure is really specific to this update.
I don't see anything in the system logs related to the problem, unfortunately :(
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
ugh, I retyped the traceback (as it doesn't seem to show up in any log files) and missed the positioning of the carets :D They're meant to be under the load_ctypes_library call.
cool. it would've been ideal to edit lorax into this update instead of submitting it separately, but once that goes stable, we can re-trigger the tests on this and they should pass.
openQA uses whatever is packaged in the distribution in question. If the lorax templates need changing, there needs to be an update to the F40 package that contains them and that update needs to be pushed stable (and then an updates push has to happen) before this will pass tests.
Thanks. I need to do another update anyway with a security fix (which this build here introduces into Fedora 40 for the first time). So I suppose we got lucky in some ways.
For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.
This update has been submitted for testing by submachine.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
The openQA test failures here are strange but seem solid and real. It looks like this, somehow, breaks the Python udev library's loading of the system udev library?
We get a traceback from anaconda that ends like this:
openQA has two tests that build traditional installer images, one that builds a netinst, one that builds an ostree installer image. For each of those, we run two 'downstream' tests that boot the image (one UEFI, one BIOS). Each test is retried once automatically if it fails. All four of those tests failed both tries, so eight failures in all. The same problem did not occur on other F40 update tests run before or after the tests for this update, indicating that the failure is really specific to this update.
I don't see anything in the system logs related to the problem, unfortunately :(
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
ugh, I retyped the traceback (as it doesn't seem to show up in any log files) and missed the positioning of the carets :D They're meant to be under the
load_ctypes_librarycall.This update has been pushed to testing.
This needs an update to the lorax templates. This change will have to be applied to f40: https://gitlab.com/redhat/centos-stream/rpms/lorax-templates-rhel/-/merge_requests/66
no regressions noted
The lorax update has been filed: FEDORA-2024-cf07f58ff7
cool. it would've been ideal to edit lorax into this update instead of submitting it separately, but once that goes stable, we can re-trigger the tests on this and they should pass.
Works
no issues in a daily desktop usage
Looks OK to me.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
Still not ready. The latest test probably used the old lorax templates: https://openqa.fedoraproject.org/tests/3081608 The ldconfig program was still deleted.
openQA uses whatever is packaged in the distribution in question. If the lorax templates need changing, there needs to be an update to the F40 package that contains them and that update needs to be pushed stable (and then an updates push has to happen) before this will pass tests.
Thanks. I need to do another update anyway with a security fix (which this build here introduces into Fedora 40 for the first time). So I suppose we got lucky in some ways.
The lorax update was auto-pushed to stable earlier today: FEDORA-2024-cf07f58ff7
This update has been unpushed.