Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd

[Aurelien Jarno <aurelien@aurel32.net>]

On Mon, Nov 11, 2013 at 10:23:25AM +0100, Laurent Bigonville wrote:
> 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.

It's possible to trigger the assertion in wheezy, so I don't think it's
a libc regression. It's more likely due to changes in libselinux, libpcre3
and/or smartmontools.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net