| 2021-11-15 23:57:46 |
Michael Hudson-Doyle |
bug |
|
|
added bug |
| 2021-11-24 22:50:09 |
Michael Hudson-Doyle |
description |
[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:
#1928508 Performance regression on memcpy() calls for AMD Zen
#1899800 Runtime deadlock: pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing
#1892825 update-locale not perform correctly sanity checks
#1918035 ld-2.31.so is not correctly packaged in libc6-dbg
#1951032 AArch64: Backport memcpy improvements
[test case]
TBD.
[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 |
[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.
[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.
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. |
|
| 2021-11-25 20:12:40 |
Michael Hudson-Doyle |
description |
[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.
[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.
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. |
[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, 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).
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. |
|
| 2021-11-25 22:15:14 |
Michael Hudson-Doyle |
description |
[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, 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).
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. |
[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, 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).
5. We should test graphical snaps with a variety of drivers (needs expansion!)
[regression potential]
Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising).
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. |
|
| 2021-12-13 06:03:59 |
Steve Langasek |
glibc (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2021-12-13 06:04:01 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-12-13 06:04:04 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2021-12-13 06:04:09 |
Steve Langasek |
tags |
|
verification-needed verification-needed-focal |
|
| 2021-12-14 03:13:09 |
Mathew Hodson |
glibc (Ubuntu): status |
New |
Fix Released |
|
| 2022-02-03 15:51:21 |
Łukasz Zemczak |
glibc (Ubuntu Focal): milestone |
|
ubuntu-20.04.4 |
|
| 2022-02-17 00:36:58 |
Brian Murray |
glibc (Ubuntu Focal): milestone |
ubuntu-20.04.4 |
focal-updates |
|
| 2022-02-17 09:24:11 |
Michael Hudson-Doyle |
description |
[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, 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).
5. We should test graphical snaps with a variety of drivers (needs expansion!)
[regression potential]
Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising).
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. |
[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, 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).
5. We should test graphical snaps with a variety of drivers (needs expansion!)
6. We should test that upgrades from 2.31-0ubuntu9.3 show a warning both on the command line and when upgrading via update-manager (and that upgrades from other versions do not).
[regression potential]
Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising).
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. |
|
| 2022-04-26 01:08:57 |
Michael Hudson-Doyle |
description |
[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, 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).
5. We should test graphical snaps with a variety of drivers (needs expansion!)
6. We should test that upgrades from 2.31-0ubuntu9.3 show a warning both on the command line and when upgrading via update-manager (and that upgrades from other versions do not).
[regression potential]
Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising).
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. |
[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, 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 test graphical snaps with a variety of drivers (needs expansion!)
[regression potential]
Rebuilding glibc is always a little risky (toolchain bugs and incompatibilities between the old and new versions can be surprising).
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. |
|
| 2022-04-27 20:50:30 |
Michael Hudson-Doyle |
bug task added |
|
cross-toolchain-base (Ubuntu) |
|
| 2022-04-27 20:50:39 |
Michael Hudson-Doyle |
cross-toolchain-base (Ubuntu): status |
New |
Fix Released |
|
| 2022-04-27 21:06:56 |
Michael Hudson-Doyle |
bug task deleted |
glibc (Ubuntu Focal) |
|
|
| 2022-04-27 21:07:07 |
Michael Hudson-Doyle |
nominated for series |
|
Ubuntu Focal |
|
| 2022-04-27 21:07:07 |
Michael Hudson-Doyle |
bug task added |
|
glibc (Ubuntu Focal) |
|
| 2022-04-27 21:07:07 |
Michael Hudson-Doyle |
bug task added |
|
cross-toolchain-base (Ubuntu Focal) |
|
| 2022-04-27 21:07:52 |
Michael Hudson-Doyle |
glibc (Ubuntu Focal): milestone |
|
focal-updates |
|
| 2022-04-27 21:07:56 |
Michael Hudson-Doyle |
cross-toolchain-base (Ubuntu Focal): milestone |
|
focal-updates |
|
| 2022-04-27 21:51:50 |
Brian Murray |
cross-toolchain-base (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2022-05-04 00:39:53 |
Michael Hudson-Doyle |
tags |
verification-needed verification-needed-focal |
verification-done-focal verification-needed |
|
| 2022-05-11 01:44:58 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-05-11 01:47:31 |
Launchpad Janitor |
glibc (Ubuntu Focal): status |
New |
Fix Released |
|
| 2022-05-11 02:20:18 |
Launchpad Janitor |
cross-toolchain-base (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
