** Description changed: [impact] It is time to update glibc in Focal. This bug is a placeholder for the overall process and a place to link the individual bugs that are being targeted: bug #1928508 Performance regression on memcpy() calls for AMD Zen bug #1899800 Runtime deadlock: pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing bug #1892825 update-locale not perform correctly sanity checks bug #1918035 ld-2.31.so is not correctly packaged in libc6-dbg bug #1951032 AArch64: Backport memcpy improvements [test case] Each bug listed above has its own test case, of course. And glibc's own test case and the autopkgtests provide a good deal of assurance that things are working. But there are still some additional things we should test by hand. - 1. We should test upgrades interactively in a container and vm and make sure long running processes still function so you can still ssh in and a desktop session continues to operate as expected. - 2. We should build a core20 snap with the glibc from focal-proposed into a branch and test it with a variety of core20 snaps. + 1. We should test upgrades interactively in a container and vm and make sure long running processes still function so you can still ssh in and a desktop session continues to operate as expected, ideally on a variety of architectures. + 2. We should build a core20 snap with the glibc from focal-proposed into a branch and test it with a variety of core20 snaps, on a variety of architectures. + 3. For arm64 specifically, we should test that upgrades of machines that do and do not have libc6-lse from 2.31-0ubuntu9.2 installed go smoothly. + 4. We should create a system that has the problematic 2.31-0ubuntu9.3 installed, and check that the behaviour when the new version is available is sensible (the current plan is to refuse such upgrades but I think some more testing here is sensible -- it may be that such upgrades are actually OK). [regression potential] - Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising). The autopkgtests and the testing described above. + Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising). - The biggest source of problems recently has been around upgrades and - interactions between the old and new libcs, whether that is different - versions of libc6 in a snap and its base or when an long running process - has the older version mapped but interacts with artefacts from the newer - version on disk. The tests in this bug are designed to catch any of - these problems before it gets to updates. + glibc's own tests and the autopkgtests that will be run should catch any + regression in the new version of glibc itself. + + However, the biggest source of problems recently has been around + upgrades and interactions between the old and new libcs, whether that is + different versions of libc6 in a snap and its base or when an long + running process has the older version mapped but interacts with + artefacts from the newer version on disk. The tests in this bug are + aimed at catching any of these problems before it gets to updates.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1951033 Title: 20.04 SRU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1951033/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
