On Mon, Nov 11, 2013 at 10:23:25AM +0100, Laurent Bigonville wrote: > Le Mon, 11 Nov 2013 09:40:52 +0100, > Sven Hartge <s...@svenhartge.de> a écrit : > > > On 11.11.2013 09:34, Laurent Bigonville wrote: > > > Le Mon, 11 Nov 2013 09:26:38 +0100, > > > Sven Hartge <s...@svenhartge.de> a écrit : > > > > > >> On 11.11.2013 09:22, Laurent Bigonville wrote: > > >>> Le Mon, 11 Nov 2013 09:13:46 +0100, Sven Hartge > > >>> <s...@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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
