Am 23.04.2018 um 14:12 schrieb Simon McVittie: > Control: tags -1 + moreinfo unreproducible > > On Mon, 23 Apr 2018 at 13:02:26 +0200, Vincent Lefevre wrote: >> On 2018-04-18 14:43:47 -0400, rektide de la faye wrote: >>> I recently updated a number of packages on my Debian/testing laptop, >>> via aptitude and included in that upgrade to satisfy dependencies >>> was libglib-2.0-0. > ... >>> nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: >>> undefined symbol: g_date_copy > > Please try: > > ls -il /lib/x86_64-linux-gnu/libglib-2.0.so* > ls -il /usr/lib/x86_64-linux-gnu/libglib-2.0.so* > dpkg -S libglib-2.0.so > > and send the results to this bug report. > > It seems that in some upgrade scenarios, users still have old versions > of GLib libraries alongside the new versions. As a result of packaging > changes in 2.56.x, those old versions are now found in preference to > the newer versions (which are now in a different directory), and that > causes these symbol lookup errors. It isn't clear why those old versions > still persist, but only for a few users: they should have been cleaned > up while upgrading to newer versions, and if that didn't work, I'd expect > all users to see these failures.
@smcv: Do you think this is a failure of dpkg/apt cleaning up old versions? My suspicion is rather, that there is some old copy of libglib lying around in /lib/x86_64-linux which was copied there by some 3rd party installer, possibly lying around for years there. It was simply undetected so far. @rektide: the time stamp of /lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0 would be interesting. Does that coincide wit the installation of a proprietary/non-Debian package or the use of "make install"? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature