Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
Le Mon, 11 Nov 2013 09:40:52 +0100,
Sven Hartge <sven@svenhartge.de> a écrit :
> On 11.11.2013 09:34, Laurent Bigonville wrote:
> > Le Mon, 11 Nov 2013 09:26:38 +0100,
> > Sven Hartge <sven@svenhartge.de> a écrit :
> >
> >> On 11.11.2013 09:22, Laurent Bigonville wrote:
> >>> Le Mon, 11 Nov 2013 09:13:46 +0100, Sven Hartge
> >>> <sven@svenhartge.de> a écrit :
> >>
> >>>> I see you reverted the fix you made and reassigned the bug to
> >>>> eglibc6 with the commend "affected software needs to be
> >>>> recompiled".
> >>
> >>>> I don't know if I like this "solution". What, if I am not able to
> >>>> recompile an affected program?
> >>
> >>> A binNMU for smartmontools has just been schedule.
> >>>
> >>> The new rebuilt version (6.2+svn3841-1+b1) of smartmontools should
> >>> arrive soon on the archive.
> >>
> >> All fine and dandy, but what if I have a software showing the same
> >> problem, where I am not able to recompile, because I don't have any
> >> source code for said software? (This is a hypotethical case.)
> >
> > Calling ldd /usr/sbin/smartctl was also triggering the same
> > assertion.
> >
> > I tired to run ldd on all the executables that are depending against
> > libselinux and only the executables from the smartmontools package
> > were showing this issue, so the other packages in the
> > archive /should/ be safe.
>
> Everything from the package pools of Debian may be safe, yes.
>
> But there are other programs from third party vendors, which may show
> the same problem, which cannot be rebuild, because they are
> proprietary software. What about them?
The only versions of libselinux that have been compiled against
libpthread are 2.1.13(all revisions) and 2.2-2 The version from wheezy
and even squeeze were not, so there is no regressions between stable
release here.
> The way I see it is that libselinux1 and/or libc6 changed in an
> binary-incompatible way and should be fixed in a way which does not
> require a rebuild of eventually affected software.
Well here it's not a simple ABI change, the loader itself is asserting,
that's why I've reassigned the bug to eglibc.
Cheers,
Laurent Bigonville
Reply to: