Bug#849488: Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
Control: tags -1 + pending On Wed, 2016-12-28 at 18:36 +, Adam D. Barratt wrote: > [recipient list trimmed and sent to the release.d.o bug rather than the > e2fsprogs one] > > On Tue, 2016-12-27 at 19:56 +, Adam D. Barratt wrote: > [...] > > On Tue, 2016-12-27 at 12:31 -0500, Theodore Ts'o wrote: > [...] > > > Agreed, that seems to be the best way to handle things. So that means > > > we would need to do a binNMU for e2fsck-static/1.42.12-2 for the > > > following architectures: > > > > > > alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc > > > > > > I've reassigned this to the release team to see if the Stable Release > > > Managers agree (which hopefully they will). > > > > Only three of those architectures - amd64, i386 and powerpc - are in > > stable so are the only ones that are relevant as far as the release.d.o > > bug is concerned. I've scheduled binNMUs for those; you'll have to > > handle the others separately, or explain which Debian architectures you > > actually meant (for instance, "arm" hasn't been used as a Debian > > architecture name for several releases now). > > Are binNMUs for any other architectures in stable required? Answer came there none. However, I noticed that the libraries produced by e2fsprogs are multi-arch:same, so I scheduled binNMUs for all architectures in jessie, which have now been flagged for acceptance into p-u. Regards, Adam
Bug#849488: Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
[recipient list trimmed and sent to the release.d.o bug rather than the e2fsprogs one] On Tue, 2016-12-27 at 19:56 +, Adam D. Barratt wrote: [...] > On Tue, 2016-12-27 at 12:31 -0500, Theodore Ts'o wrote: [...] > > Agreed, that seems to be the best way to handle things. So that means > > we would need to do a binNMU for e2fsck-static/1.42.12-2 for the > > following architectures: > > > > alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc > > > > I've reassigned this to the release team to see if the Stable Release > > Managers agree (which hopefully they will). > > Only three of those architectures - amd64, i386 and powerpc - are in > stable so are the only ones that are relevant as far as the release.d.o > bug is concerned. I've scheduled binNMUs for those; you'll have to > handle the others separately, or explain which Debian architectures you > actually meant (for instance, "arm" hasn't been used as a Debian > architecture name for several releases now). Are binNMUs for any other architectures in stable required? Regards, Adam
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
On Tue, 2016-12-27 at 16:13 -0500, Theodore Ts'o wrote: > On Tue, Dec 27, 2016 at 07:56:36PM +, Adam D. Barratt wrote: > > Thankfully none of that worked. I say thankfully, because you'd have > > given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's > > certainly not so for release.d.o) and removed the original bug from > > where it belongs. (The binNMU doesn't resolve the fact that the original > > issue existed - and for some versions still exists - in e2fsprogs.) > > It only exists in the versions of e2fsprogs shipping in Jessie and > before. So unless the SRM's think that it's worth it to fix this > issue via a change to e2fsprogs going to proposed-updates for Jessie > (I'm not entirely convinced but if you want me to add the Built-Using > and ask for a update to Jessie stable, I can do that, and we can punt > on the binNMU for e2fsck-static since it will be obsoleted by the fix > of e2fsprogs in Debian stable.) I already scheduled the binNMUs for the handful of architectures that I could, in the cloned #849488. You may wish to check the architecture list there and confirm whether any of the others were typoes or if the three architectures mentioned are sufficient. Regards, Adam
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
On Tue, Dec 27, 2016 at 07:56:36PM +, Adam D. Barratt wrote: > Thankfully none of that worked. I say thankfully, because you'd have > given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's > certainly not so for release.d.o) and removed the original bug from > where it belongs. (The binNMU doesn't resolve the fact that the original > issue existed - and for some versions still exists - in e2fsprogs.) It only exists in the versions of e2fsprogs shipping in Jessie and before. So unless the SRM's think that it's worth it to fix this issue via a change to e2fsprogs going to proposed-updates for Jessie (I'm not entirely convinced but if you want me to add the Built-Using and ask for a update to Jessie stable, I can do that, and we can punt on the binNMU for e2fsck-static since it will be obsoleted by the fix of e2fsprogs in Debian stable.) Otherwise, I plan to close the e2fsprogs bugs since it's fixed in Debian Stretch, and with the decision not to try to address this in Jessie, a "wontfix" for older versions of e2fsprogs. Apologies for not adjusting the priority as part of my attempt to move this bug to release.debian.org, but the theory was that fixing this via a binNMU of e2fsck-static was sufficient, given how late we are in Jessie's life cycle, and it wasn't worth trying to fix this bug in stable. If I'm wrong in this, and the SRM's would support/prefer to fix this via an update to e2fsprogs in Jessie and spinning new binary debs for all architectures, I'll stand corrected and we can go down that route. Cheers, - Ted
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
Control: clone -1 -2 Control: close -1 Control: reassign -2 release.debian.org Control: severity -2 normal Control: retitle -2 nmu: e2fsck-static Control: tags -2 + jessie pending On Tue, 2016-12-27 at 12:31 -0500, Theodore Ts'o wrote: > retitle -1 release.debian.org: binNMU for e2fsck-static to rebuild against > latest dietlibc > reassign -1 release.debian.org > user release.debian@packages.debian.org > usertag -1 binnmu > thanks Thankfully none of that worked. I say thankfully, because you'd have given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's certainly not so for release.d.o) and removed the original bug from where it belongs. (The binNMU doesn't resolve the fact that the original issue existed - and for some versions still exists - in e2fsprogs.) > Agreed, that seems to be the best way to handle things. So that means > we would need to do a binNMU for e2fsck-static/1.42.12-2 for the > following architectures: > > alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc > > I've reassigned this to the release team to see if the Stable Release > Managers agree (which hopefully they will). Only three of those architectures - amd64, i386 and powerpc - are in stable so are the only ones that are relevant as far as the release.d.o bug is concerned. I've scheduled binNMUs for those; you'll have to handle the others separately, or explain which Debian architectures you actually meant (for instance, "arm" hasn't been used as a Debian architecture name for several releases now). Regards, Adam
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
retitle -1 release.debian.org: binNMU for e2fsck-static to rebuild against latest dietlibc reassign -1 release.debian.org user release.debian@packages.debian.org usertag -1 binnmu thanks On Tue, Dec 27, 2016 at 12:16:52PM +, Ben Hutchings wrote: > On Wed, 2016-12-21 at 22:49 -0500, Theodore Ts'o wrote: > > I noticed you reopened this and marked this as still being a problem > > in e2fsprogs/1.42.12-2 (it actually _is_ fixed in e2fsprogs/1.43.3-1). > > Is it worth trying to fix this in Debian Stable? Especially given > > that existence of snapshots.debian.org, the sources for dietlibc will > > always be available one way or another --- and that might be good > > enough for GPL compliance. > > I think that snapshot.debian.org should be sufficient to keep Debian > itself in compliance, but not any downstream commercial distributors. > So all GPL sources should be available in the same suite, and Built- > Using provides the information that dak needs to ensure that. > > As it is, e2fsck-static in jessie has been built with dietlibc > 0.33~cvs20120325-6, but dietlibc has had a security update since then > so that version is no longer present. (That issue didn't affect > e2fsck-static so it hasn't been binNMU'd.) > > I think this could be resolved in stable simply by binNMU'ing e2fsck- > static for the architectures where it uses dietlibc. Agreed, that seems to be the best way to handle things. So that means we would need to do a binNMU for e2fsck-static/1.42.12-2 for the following architectures: alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc I've reassigned this to the release team to see if the Stable Release Managers agree (which hopefully they will). Ted
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
On Wed, 2016-12-21 at 22:49 -0500, Theodore Ts'o wrote: > fixed 847575 1.43.3-1 > thanks > > On Wed, Dec 21, 2016 at 11:57:43PM +, Ben Hutchings wrote: > > > > > > I intended to prepare a patch but found that e2fsprogs no longer builds > > > the static binary using dietlibc as of 1.43~WIP.2016.05.12-1, so this > > > bug can be closed. > > > > Oops, sorry for the wrong version. > > I noticed you reopened this and marked this as still being a problem > in e2fsprogs/1.42.12-2 (it actually _is_ fixed in e2fsprogs/1.43.3-1). > Is it worth trying to fix this in Debian Stable? Especially given > that existence of snapshots.debian.org, the sources for dietlibc will > always be available one way or another --- and that might be good > enough for GPL compliance. I think that snapshot.debian.org should be sufficient to keep Debian itself in compliance, but not any downstream commercial distributors. So all GPL sources should be available in the same suite, and Built- Using provides the information that dak needs to ensure that. As it is, e2fsck-static in jessie has been built with dietlibc 0.33~cvs20120325-6, but dietlibc has had a security update since then so that version is no longer present. (That issue didn't affect e2fsck-static so it hasn't been binNMU'd.) I think this could be resolved in stable simply by binNMU'ing e2fsck- static for the architectures where it uses dietlibc. Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
fixed 847575 1.43.3-1 thanks On Wed, Dec 21, 2016 at 11:57:43PM +, Ben Hutchings wrote: > > > > I intended to prepare a patch but found that e2fsprogs no longer builds > > the static binary using dietlibc as of 1.43~WIP.2016.05.12-1, so this > > bug can be closed. > > Oops, sorry for the wrong version. I noticed you reopened this and marked this as still being a problem in e2fsprogs/1.42.12-2 (it actually _is_ fixed in e2fsprogs/1.43.3-1). Is it worth trying to fix this in Debian Stable? Especially given that existence of snapshots.debian.org, the sources for dietlibc will always be available one way or another --- and that might be good enough for GPL compliance. - Ted
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
Control: reopen -1 Control: found -1 1.42.12-2 Control: fixed -1 1.43~WIP.2016.05.12-1 Hilko Bergen wrote: > Hi, > > I intended to prepare a patch but found that e2fsprogs no longer builds > the static binary using dietlibc as of 1.43~WIP.2016.05.12-1, so this > bug can be closed. Oops, sorry for the wrong version. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
