| 2019-01-17 14:54:14 |
Eric Desrochers |
bug |
|
|
added bug |
| 2019-01-17 14:56:47 |
Eric Desrochers |
bug |
|
|
added subscriber Łukasz Zemczak |
| 2019-01-17 14:59:02 |
Eric Desrochers |
tags |
|
sts |
|
| 2019-01-17 14:59:31 |
Eric Desrochers |
description |
[Rationale]
lvm2 suffers of a pvscan issue as describe in LP: #1573982
A fix[1] exist for that bug + a regression fix[2], but it has been made on top of a major activation code refactoring[3] which contains thousand lines of code and that is mandatory for the fix to work.
Since this is not suitable for a standard SRU and for such a package, after discussion with the SRU team vanguard[4] we thought that this would be more suitable for xenial-backports, despite the fact that we will leave lvm2 from xenial-updates with this bug.
We already have "2.02.176" packaged in bionic-updates containing all the necessary bit.
It may be less work to simply backport that package into xenial-backport ? as an avenue for those who want to fix that problem and don't mind diverting from xenial-updates for lvm2 package.
[1] - 15da467b5 pvscan: do activation when lvmetad is not running | Introduced: v2_02_157~4
[2] - f77fe436a pvscan: don't activate LVs when use_lvmetad=0 | Introduced: v2_02_157~2
[3] - 9b640c368 pvscan: use process_each_vg for autoactivate | Introduced: v2_02_155~48
[4] - Discussion w/ SRU team :
[08:57:45] <sil2100> This is a hard pickle
[08:58:16] <sil2100> Since 1k+ of code to fix one bug is unacceptable
[08:58:23] <sil2100> Especially for such a package
[08:59:38] <sil2100> I'd say backports is the only sane option, the other would be a new upstream release for the package as an SRU, but that also seems insane for this package
[09:00:23] <sil2100> The backporters team is malfunctioning, but maybe if you'd ping Laney directly with your backport and tell him your urgency, maybe it'd get reviewed in a timely fashion
[5] - rmadison:
lvm2 | 2.02.176-4.1ubuntu3 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
Regards,
Eric |
[Rationale]
lvm2 suffers of a pvscan issue as describe in LP: #1573982
A fix[1] exist for that bug + a regression fix[2], but it has been made on top of a major activation code refactoring[3] which contains thousand lines of code and that is mandatory for the fix to work.
Since this is not suitable for a standard SRU and for such a package, after discussion with the SRU team vanguard[4] we thought that this would be more suitable for xenial-backports, despite the fact that we will leave lvm2 from xenial-updates with this bug.
We already have "2.02.176" packaged in bionic-updates containing all the necessary bit.
It may be less work to simply backport that package into xenial-backport ? as an avenue for those who want to fix that problem and don't mind diverting from xenial-updates for lvm2 package.
[1] - 15da467b5 pvscan: do activation when lvmetad is not running
Introduced: v2_02_157~4
[2] - f77fe436a pvscan: don't activate LVs when use_lvmetad=0
Introduced: v2_02_157~2
[3] - 9b640c368 pvscan: use process_each_vg for autoactivate
Introduced: v2_02_155~48
[4] - Discussion w/ SRU team :
[08:57:45] <sil2100> This is a hard pickle
[08:58:16] <sil2100> Since 1k+ of code to fix one bug is unacceptable
[08:58:23] <sil2100> Especially for such a package
[08:59:38] <sil2100> I'd say backports is the only sane option, the other would be a new upstream release for the package as an SRU, but that also seems insane for this package
[09:00:23] <sil2100> The backporters team is malfunctioning, but maybe if you'd ping Laney directly with your backport and tell him your urgency, maybe it'd get reviewed in a timely fashion
[5] - rmadison:
lvm2 | 2.02.176-4.1ubuntu3 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
Regards,
Eric |
|
| 2019-01-17 15:01:44 |
Eric Desrochers |
description |
[Rationale]
lvm2 suffers of a pvscan issue as describe in LP: #1573982
A fix[1] exist for that bug + a regression fix[2], but it has been made on top of a major activation code refactoring[3] which contains thousand lines of code and that is mandatory for the fix to work.
Since this is not suitable for a standard SRU and for such a package, after discussion with the SRU team vanguard[4] we thought that this would be more suitable for xenial-backports, despite the fact that we will leave lvm2 from xenial-updates with this bug.
We already have "2.02.176" packaged in bionic-updates containing all the necessary bit.
It may be less work to simply backport that package into xenial-backport ? as an avenue for those who want to fix that problem and don't mind diverting from xenial-updates for lvm2 package.
[1] - 15da467b5 pvscan: do activation when lvmetad is not running
Introduced: v2_02_157~4
[2] - f77fe436a pvscan: don't activate LVs when use_lvmetad=0
Introduced: v2_02_157~2
[3] - 9b640c368 pvscan: use process_each_vg for autoactivate
Introduced: v2_02_155~48
[4] - Discussion w/ SRU team :
[08:57:45] <sil2100> This is a hard pickle
[08:58:16] <sil2100> Since 1k+ of code to fix one bug is unacceptable
[08:58:23] <sil2100> Especially for such a package
[08:59:38] <sil2100> I'd say backports is the only sane option, the other would be a new upstream release for the package as an SRU, but that also seems insane for this package
[09:00:23] <sil2100> The backporters team is malfunctioning, but maybe if you'd ping Laney directly with your backport and tell him your urgency, maybe it'd get reviewed in a timely fashion
[5] - rmadison:
lvm2 | 2.02.176-4.1ubuntu3 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
Regards,
Eric |
[Rationale]
lvm2 suffers of a pvscan issue as describe in LP: #1573982
A fix[1] exist for that bug + a regression fix[2], but it has been made on top of a major activation code refactoring[3] which contains thousand lines of code and that is mandatory for the fix to work.
Since this is not suitable for a standard SRU and for such a package, after discussion with the SRU team vanguard[4] we thought that this would be more suitable for xenial-backports, despite the fact that we will leave lvm2 from xenial-updates with this bug.
We already have "2.02.176" packaged in bionic-updates containing all the necessary bit.
It may be less work to simply backport that package into xenial-backport ? as an avenue for those who want to fix that problem and don't mind diverting from xenial-updates for lvm2 package.
[1] - 15da467b5 pvscan: do activation when lvmetad is not running
https://github.com/lvmteam/lvm2/commit/15da467b5
Introduced: v2_02_157~4
[2] - f77fe436a pvscan: don't activate LVs when use_lvmetad=0
https://github.com/lvmteam/lvm2/commit/f77fe436a
Introduced: v2_02_157~2
[3] - 9b640c368 pvscan: use process_each_vg for autoactivate
https://github.com/lvmteam/lvm2/commit/9b640c368
Introduced: v2_02_155~48
[4] - Discussion w/ SRU team :
[08:57:45] <sil2100> This is a hard pickle
[08:58:16] <sil2100> Since 1k+ of code to fix one bug is unacceptable
[08:58:23] <sil2100> Especially for such a package
[08:59:38] <sil2100> I'd say backports is the only sane option, the other would be a new upstream release for the package as an SRU, but that also seems insane for this package
[09:00:23] <sil2100> The backporters team is malfunctioning, but maybe if you'd ping Laney directly with your backport and tell him your urgency, maybe it'd get reviewed in a timely fashion
[5] - rmadison:
lvm2 | 2.02.176-4.1ubuntu3 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
Regards,
Eric |
|
| 2021-11-16 21:24:45 |
Dan Streetman |
xenial-backports: status |
New |
Won't Fix |
|
