| 2020-07-14 07:40:59 |
Markus Schade |
bug |
|
|
added bug |
| 2020-07-14 07:43:00 |
Markus Schade |
description |
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c#diff-c8f550847b733f46aaf5cedfce0b6f90
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819#diff-c8f550847b733f46aaf5cedfce0b6f90 |
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
|
| 2020-07-19 01:21:55 |
Rafael David Tinoco |
nominated for series |
|
Ubuntu Focal |
|
| 2020-07-19 01:21:55 |
Rafael David Tinoco |
bug task added |
|
qemu (Ubuntu Focal) |
|
| 2020-07-19 01:22:03 |
Rafael David Tinoco |
qemu (Ubuntu Focal): status |
New |
Triaged |
|
| 2020-07-19 01:22:05 |
Rafael David Tinoco |
qemu (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2020-07-19 01:22:14 |
Rafael David Tinoco |
bug |
|
|
added subscriber Ubuntu Server |
| 2020-07-19 01:22:22 |
Rafael David Tinoco |
bug |
|
|
added subscriber Ubuntu Virtualisation team |
| 2020-07-19 01:29:20 |
Rafael David Tinoco |
qemu (Ubuntu): status |
New |
Triaged |
|
| 2020-07-19 01:29:24 |
Rafael David Tinoco |
qemu (Ubuntu): status |
Triaged |
Fix Released |
|
| 2020-07-19 01:29:36 |
Rafael David Tinoco |
qemu (Ubuntu Focal): importance |
Medium |
High |
|
| 2020-07-27 11:06:17 |
Christian Ehrhardt |
bug task added |
|
libvirt (Ubuntu) |
|
| 2020-07-27 11:07:33 |
Christian Ehrhardt |
libvirt (Ubuntu): status |
New |
Incomplete |
|
| 2020-07-27 11:07:35 |
Christian Ehrhardt |
libvirt (Ubuntu Focal): status |
New |
Incomplete |
|
| 2020-07-27 11:07:42 |
Christian Ehrhardt |
bug task added |
|
linux (Ubuntu) |
|
| 2020-07-27 11:09:44 |
Christian Ehrhardt |
linux (Ubuntu Focal): status |
New |
Confirmed |
|
| 2020-07-27 11:09:56 |
Christian Ehrhardt |
linux (Ubuntu): status |
New |
Confirmed |
|
| 2020-07-27 11:15:03 |
Christian Ehrhardt |
qemu (Ubuntu Focal): status |
Triaged |
Incomplete |
|
| 2020-08-03 06:32:09 |
Markus Schade |
attachment added |
|
Add-EPYC-ROME-x86-CPU-model https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/+attachment/5398119/+files/Add-EPYC-ROME-x86-CPU-model |
|
| 2020-09-16 15:24:52 |
Stefan Bader |
linux (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2020-09-16 15:26:15 |
Stefan Bader |
linux (Ubuntu): status |
Confirmed |
Invalid |
|
| 2020-09-17 13:47:33 |
William Breathitt Gray |
linux (Ubuntu Focal): status |
Confirmed |
Fix Committed |
|
| 2020-09-21 18:12:25 |
Ubuntu Kernel Bot |
tags |
|
verification-needed-focal |
|
| 2020-09-22 08:18:31 |
Markus Schade |
tags |
verification-needed-focal |
verification-done-focal |
|
| 2020-09-25 05:48:27 |
Christian Ehrhardt |
qemu (Ubuntu Focal): status |
Incomplete |
In Progress |
|
| 2020-09-25 06:06:03 |
Christian Ehrhardt |
description |
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
## Qemu SRU ##
[Impact]
* CPU definitions are added to qemu as these CPUs are known.
And due to that over time are missing in former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports two upstream fixes that just add definitions (no
control flow changes)
[Test Case]
* Probe qemu for the known CPU types (works on all HW)
$ qemu-system-x86_64 -cpu ? | grep EPYC
Focal without fix:
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
Focal with fix also adds:
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v3 AMD EPYC Processor
* Given such HW is available start a KVM guest using those new types
Since we don't have libvirt support (yet) do so directly in qemu
commandline like (bootloader is enough)
$ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm -nographic
$ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm -nographic
[Regression Potential]
* This adds new CPU types to the list of known CPUs defining their name
and features. Generally the changes are contained to those new types
and only active when selected - and usually only selectable on such new
machines. Therefore not a lot should change for other users.
One thing thou, if a user selected an unversioned type (which in this
case only can be "EPYC") by default it will pick the latest subversion
that applies. In this case the behavior will change and pick EPYC-v3
after the fix. But this is the whole purpose of versioned (stay as is)
and unversioned (move with updates) CPU types - so that should be ok.
The EPYC-Rome type didn't exist in Focal before, so it can't "change"
for users.
[Other Info]
* Depends on the new kernel 5.4.0-49 or later (Currently in
focal-proposed)
---
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
|
| 2020-09-25 06:07:46 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/391348 |
|
| 2020-09-29 12:59:30 |
Robie Basak |
qemu (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-09-29 12:59:32 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-09-29 12:59:33 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2020-09-29 12:59:36 |
Robie Basak |
tags |
verification-done-focal |
verification-needed verification-needed-focal |
|
| 2020-09-30 08:16:51 |
Christian Ehrhardt |
tags |
verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2020-10-02 09:12:26 |
Markus Schade |
attachment added |
|
Add-EPYC-ROME-x86-CPU-model.patch https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/+attachment/5416509/+files/Add-EPYC-ROME-x86-CPU-model.patch |
|
| 2020-10-08 06:09:00 |
Christian Ehrhardt |
description |
## Qemu SRU ##
[Impact]
* CPU definitions are added to qemu as these CPUs are known.
And due to that over time are missing in former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports two upstream fixes that just add definitions (no
control flow changes)
[Test Case]
* Probe qemu for the known CPU types (works on all HW)
$ qemu-system-x86_64 -cpu ? | grep EPYC
Focal without fix:
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
Focal with fix also adds:
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v3 AMD EPYC Processor
* Given such HW is available start a KVM guest using those new types
Since we don't have libvirt support (yet) do so directly in qemu
commandline like (bootloader is enough)
$ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm -nographic
$ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm -nographic
[Regression Potential]
* This adds new CPU types to the list of known CPUs defining their name
and features. Generally the changes are contained to those new types
and only active when selected - and usually only selectable on such new
machines. Therefore not a lot should change for other users.
One thing thou, if a user selected an unversioned type (which in this
case only can be "EPYC") by default it will pick the latest subversion
that applies. In this case the behavior will change and pick EPYC-v3
after the fix. But this is the whole purpose of versioned (stay as is)
and unversioned (move with updates) CPU types - so that should be ok.
The EPYC-Rome type didn't exist in Focal before, so it can't "change"
for users.
[Other Info]
* Depends on the new kernel 5.4.0-49 or later (Currently in
focal-proposed)
---
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
[Impact]
* CPU definitions are added to libvirt as these CPUs are known
and added to qemu for execution.
And due to that over time some are considered missing in
former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports three upstream fixes that just add definitions
(no control flow changes)
[Test Case]
* Check if it has an EPYC-Rome entry in
/usr/share/libvirt/cpu_map/index.xml and the file included
there exists.
* Define a guest like:
<cpu mode='custom' match='exact' check='partial'>
<model fallback='forbid'>EPYC-Rome</model>
</cpu>
You can only "really" start this on a system with the
matching HW. But even on others it will change from:
error: internal error: Unknown CPU model EPYC-Rome
to being unable to start for some features missing.
* libvirt probes a system if a named cpu can be used, after the
fix this should include EPYC-Rome
$ virsh domcapabilities | grep EPYC
<model usable='no'>EPYC-IBPB</model>
<model usable='no'>EPYC</model>
[Regression Potential]
* Usually these type additions are safe unless they add control flow
changes (e.g. to handle yet unknown types of registers or such) but
that isn't the case here.
A regression if any is to be expected on systems that are close to the
newly added type(s). Those will after the update be detected as such
if e.g. host-model is used. If then running on a mixed cluster of
updated/non-updated systems migrations will only work if the target is
updated as well.
[Other Info]
* This is the first build since glibc 2.32 arrived in groovy, hence we
need to revert the revert done for bug 1892826. It has to be checked
if the linking is fine afterwards. That adds two tests that shall be
done.
- check the linking to point to libtirpc instead of glibc
$ eu-readelf -a /usr/lib/libvirt/libvirt_lxc | grep xdr_uint64 | grep GLOBAL
- run the autopkgtest cases as the LXC tests would trigger an issue if
there is one
----
## Qemu SRU ##
[Impact]
* CPU definitions are added to qemu as these CPUs are known.
And due to that over time are missing in former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports two upstream fixes that just add definitions (no
control flow changes)
[Test Case]
* Probe qemu for the known CPU types (works on all HW)
$ qemu-system-x86_64 -cpu ? | grep EPYC
Focal without fix:
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
Focal with fix also adds:
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v3 AMD EPYC Processor
* Given such HW is available start a KVM guest using those new types
Since we don't have libvirt support (yet) do so directly in qemu
commandline like (bootloader is enough)
$ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm -nographic
$ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm -nographic
[Regression Potential]
* This adds new CPU types to the list of known CPUs defining their name
and features. Generally the changes are contained to those new types
and only active when selected - and usually only selectable on such new
machines. Therefore not a lot should change for other users.
One thing thou, if a user selected an unversioned type (which in this
case only can be "EPYC") by default it will pick the latest subversion
that applies. In this case the behavior will change and pick EPYC-v3
after the fix. But this is the whole purpose of versioned (stay as is)
and unversioned (move with updates) CPU types - so that should be ok.
The EPYC-Rome type didn't exist in Focal before, so it can't "change"
for users.
[Other Info]
* Depends on the new kernel 5.4.0-49 or later (Currently in
focal-proposed)
---
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
|
| 2020-10-08 06:09:18 |
Christian Ehrhardt |
summary |
Add/Backport EPYC-v3 and EPYC-Rome CPU model |
[FFe/SRU] Add/Backport EPYC-v3 and EPYC-Rome CPU model |
|
| 2020-10-08 06:09:31 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Release Team |
| 2020-10-08 06:09:51 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/391963 |
|
| 2020-10-08 06:10:13 |
Christian Ehrhardt |
removed subscriber Ubuntu Release Team |
|
|
|
| 2020-10-08 06:26:27 |
Christian Ehrhardt |
description |
[Impact]
* CPU definitions are added to libvirt as these CPUs are known
and added to qemu for execution.
And due to that over time some are considered missing in
former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports three upstream fixes that just add definitions
(no control flow changes)
[Test Case]
* Check if it has an EPYC-Rome entry in
/usr/share/libvirt/cpu_map/index.xml and the file included
there exists.
* Define a guest like:
<cpu mode='custom' match='exact' check='partial'>
<model fallback='forbid'>EPYC-Rome</model>
</cpu>
You can only "really" start this on a system with the
matching HW. But even on others it will change from:
error: internal error: Unknown CPU model EPYC-Rome
to being unable to start for some features missing.
* libvirt probes a system if a named cpu can be used, after the
fix this should include EPYC-Rome
$ virsh domcapabilities | grep EPYC
<model usable='no'>EPYC-IBPB</model>
<model usable='no'>EPYC</model>
[Regression Potential]
* Usually these type additions are safe unless they add control flow
changes (e.g. to handle yet unknown types of registers or such) but
that isn't the case here.
A regression if any is to be expected on systems that are close to the
newly added type(s). Those will after the update be detected as such
if e.g. host-model is used. If then running on a mixed cluster of
updated/non-updated systems migrations will only work if the target is
updated as well.
[Other Info]
* This is the first build since glibc 2.32 arrived in groovy, hence we
need to revert the revert done for bug 1892826. It has to be checked
if the linking is fine afterwards. That adds two tests that shall be
done.
- check the linking to point to libtirpc instead of glibc
$ eu-readelf -a /usr/lib/libvirt/libvirt_lxc | grep xdr_uint64 | grep GLOBAL
- run the autopkgtest cases as the LXC tests would trigger an issue if
there is one
----
## Qemu SRU ##
[Impact]
* CPU definitions are added to qemu as these CPUs are known.
And due to that over time are missing in former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports two upstream fixes that just add definitions (no
control flow changes)
[Test Case]
* Probe qemu for the known CPU types (works on all HW)
$ qemu-system-x86_64 -cpu ? | grep EPYC
Focal without fix:
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
Focal with fix also adds:
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v3 AMD EPYC Processor
* Given such HW is available start a KVM guest using those new types
Since we don't have libvirt support (yet) do so directly in qemu
commandline like (bootloader is enough)
$ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm -nographic
$ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm -nographic
[Regression Potential]
* This adds new CPU types to the list of known CPUs defining their name
and features. Generally the changes are contained to those new types
and only active when selected - and usually only selectable on such new
machines. Therefore not a lot should change for other users.
One thing thou, if a user selected an unversioned type (which in this
case only can be "EPYC") by default it will pick the latest subversion
that applies. In this case the behavior will change and pick EPYC-v3
after the fix. But this is the whole purpose of versioned (stay as is)
and unversioned (move with updates) CPU types - so that should be ok.
The EPYC-Rome type didn't exist in Focal before, so it can't "change"
for users.
[Other Info]
* Depends on the new kernel 5.4.0-49 or later (Currently in
focal-proposed)
---
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
[Impact]
* CPU definitions are added to libvirt as these CPUs are known
and added to qemu for execution.
And due to that over time some are considered missing in
former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports three upstream fixes that just add definitions
(no control flow changes)
[Test Case]
* Check if it has an EPYC-Rome entry in
/usr/share/libvirt/cpu_map/index.xml and the file included
there exists.
* Define a guest like:
<cpu mode='custom' match='exact' check='partial'>
<model fallback='forbid'>EPYC-Rome</model>
</cpu>
You can only "really" start this on a system with the
matching HW. But even on others it will change from:
error: internal error: Unknown CPU model EPYC-Rome
to being unable to start for some features missing.
* libvirt probes a system if a named cpu can be used, after the
fix this should include EPYC-Rome
$ virsh domcapabilities | grep EPYC
<model usable='no'>EPYC-IBPB</model>
<model usable='no'>EPYC</model>
[Regression Potential]
* Usually these type additions are safe unless they add control flow
changes (e.g. to handle yet unknown types of registers or such) but
that isn't the case here.
A regression if any is to be expected on systems that are close to the
newly added type(s). Those will after the update be detected as such
if e.g. host-model is used. If then running on a mixed cluster of
updated/non-updated systems migrations will only work if the target is
updated as well.
[Other Info]
* This is the first build since glibc 2.32 arrived in groovy, hence we
need to be careful of the fix done for bug 1892826.
It has to be checked if the linking is fine after the rebuild.
The workload still works in groovy despite 2.32 being present (I'd ahve
expected it doesn't), so we will keep the revert as-is for now.
To be sure that adds two tests that shall be done:
- check the linking to point to libtirpc instead of glibc
$ eu-readelf -a /usr/lib/libvirt/libvirt_lxc | grep xdr_uint64 | grep GLOBAL
Was pointing to glibc, does it still and if so does it work (see
below)?
- run the autopkgtest cases as the LXC tests would trigger an issue if
there is one
----
## Qemu SRU ##
[Impact]
* CPU definitions are added to qemu as these CPUs are known.
And due to that over time are missing in former releases.
* To really benefit from the new features of these chips
they have to be known, therefore new type additions done by
upstream should be backported if they generally apply and do
not depend on SRU-critical changes.
* This backports two upstream fixes that just add definitions (no
control flow changes)
[Test Case]
* Probe qemu for the known CPU types (works on all HW)
$ qemu-system-x86_64 -cpu ? | grep EPYC
Focal without fix:
x86 EPYC (alias configured by machine type)
x86 EPYC-IBPB (alias of EPYC-v2)
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
Focal with fix also adds:
x86 EPYC-Rome (alias configured by machine type)
x86 EPYC-Rome-v1 AMD EPYC-Rome Processor
x86 EPYC-v3 AMD EPYC Processor
* Given such HW is available start a KVM guest using those new types
Since we don't have libvirt support (yet) do so directly in qemu
commandline like (bootloader is enough)
$ qemu-system-x86_64 -cpu EPYC-Rome -machine pc-q35-focal,accel=kvm -nographic
$ qemu-system-x86_64 -cpu EPYC-v3 -machine pc-q35-focal,accel=kvm -nographic
[Regression Potential]
* This adds new CPU types to the list of known CPUs defining their name
and features. Generally the changes are contained to those new types
and only active when selected - and usually only selectable on such new
machines. Therefore not a lot should change for other users.
One thing thou, if a user selected an unversioned type (which in this
case only can be "EPYC") by default it will pick the latest subversion
that applies. In this case the behavior will change and pick EPYC-v3
after the fix. But this is the whole purpose of versioned (stay as is)
and unversioned (move with updates) CPU types - so that should be ok.
The EPYC-Rome type didn't exist in Focal before, so it can't "change"
for users.
[Other Info]
* Depends on the new kernel 5.4.0-49 or later (Currently in
focal-proposed)
---
Qemu in focal has already support for most (except amd-stibp) flags of this model.
Please backport the following patches:
https://github.com/qemu/qemu/commit/a16e8dbc043720abcb37fc7dca313e720b4e0f0c
https://github.com/qemu/qemu/commit/143c30d4d346831a09e59e9af45afdca0331e819 |
|
| 2020-10-12 09:44:42 |
Launchpad Janitor |
qemu (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-10-12 09:44:53 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-10-12 12:27:30 |
Ubuntu Foundations Team Bug Bot |
tags |
verification-done verification-done-focal |
patch verification-done verification-done-focal |
|
| 2020-10-12 12:27:36 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2020-10-12 14:15:29 |
Christian Ehrhardt |
libvirt (Ubuntu): status |
Incomplete |
In Progress |
|
| 2020-10-12 14:15:31 |
Christian Ehrhardt |
libvirt (Ubuntu Focal): status |
Incomplete |
Triaged |
|
| 2020-10-13 17:22:34 |
Launchpad Janitor |
libvirt (Ubuntu): status |
In Progress |
Fix Released |
|
| 2020-10-13 22:38:19 |
Launchpad Janitor |
linux (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-10-13 22:38:19 |
Launchpad Janitor |
cve linked |
|
2020-16119 |
|
| 2020-10-13 22:38:19 |
Launchpad Janitor |
cve linked |
|
2020-16120 |
|
| 2020-10-14 05:05:33 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/392204 |
|
| 2020-10-22 08:26:02 |
Christian Ehrhardt |
linux (Ubuntu): status |
Invalid |
Fix Released |
|
| 2020-10-27 21:26:18 |
Brian Murray |
libvirt (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2020-10-27 21:26:21 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-10-27 21:26:29 |
Brian Murray |
tags |
patch verification-done verification-done-focal |
patch verification-needed verification-needed-focal |
|
| 2020-10-28 07:20:39 |
Markus Schade |
tags |
patch verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2020-11-02 15:22:36 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/393189 |
|
| 2020-11-05 09:44:53 |
Launchpad Janitor |
libvirt (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-11-16 12:30:37 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/393189 |
|
|
