Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs
731 views
Skip to first unread message
rektide de la faye
Apr 18, 2018, 3:00:02 PM4/18/18
to
Package: libglib2.0-0
Version: 2.56.1-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
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.
Since installing, many many programs on my system refuse to start. Trying
to run nmcli, for example, returns:
nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
I also see like errors trying to run lightdm, urxvt, vi.
This file appears to be a symlink, pointing at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.
There is a .4200.0 in that directory. I tried symlinking to that, but got a different set of undefined
symbol errors keeping me from running things- g_option_group_unref.
This does appear to gravely reduce the functionality of my workstation.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (250, 'unstable'), (600, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/zsh
Versions of packages libglib2.0-0 depends on:
ii libc6 2.27-3
ii libffi6 3.2.1-4
ii libmount1 2.30.2-0.1
ii libpcre3 8.39-9
ii libselinux1 2.6-3+b1
ii zlib1g 2.8.dfsg-2+b1
Versions of packages libglib2.0-0 recommends:
ii libglib2.0-data 2.56.1-2
ii shared-mime-info 1.7-1
ii xdg-user-dirs 0.15-2
libglib2.0-0 suggests no packages.
-- no debconf information
Version: 2.56.1-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
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.
Since installing, many many programs on my system refuse to start. Trying
to run nmcli, for example, returns:
nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
I also see like errors trying to run lightdm, urxvt, vi.
This file appears to be a symlink, pointing at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.
There is a .4200.0 in that directory. I tried symlinking to that, but got a different set of undefined
symbol errors keeping me from running things- g_option_group_unref.
This does appear to gravely reduce the functionality of my workstation.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (250, 'unstable'), (600, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/zsh
Versions of packages libglib2.0-0 depends on:
ii libc6 2.27-3
ii libffi6 3.2.1-4
ii libmount1 2.30.2-0.1
ii libpcre3 8.39-9
ii libselinux1 2.6-3+b1
ii zlib1g 2.8.dfsg-2+b1
Versions of packages libglib2.0-0 recommends:
ii libglib2.0-data 2.56.1-2
ii shared-mime-info 1.7-1
ii xdg-user-dirs 0.15-2
libglib2.0-0 suggests no packages.
-- no debconf information
Vincent Lefevre
Apr 23, 2018, 7:10:03 AM4/23/18
to
On 2018-04-18 14:43:47 -0400, rektide de la faye wrote:
> Package: libglib2.0-0
> Version: 2.56.1-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> 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.
>
> Since installing, many many programs on my system refuse to start. Trying
> to run nmcli, for example, returns:
>
> nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
>
> I also see like errors trying to run lightdm, urxvt, vi.
I have upgraded one of my machines to 2.56.1-2 (in particular) and
> Package: libglib2.0-0
> Version: 2.56.1-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> 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.
>
> Since installing, many many programs on my system refuse to start. Trying
> to run nmcli, for example, returns:
>
> nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
>
> I also see like errors trying to run lightdm, urxvt, vi.
rebooted, and I have no such problems with lightdm, urxvt and vi.
> This file appears to be a symlink, pointing at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.
>
> There is a .4200.0 in that directory.
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Simon McVittie
Apr 23, 2018, 8:20:02 AM4/23/18
to
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.
...
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.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894763> was another
instance of the same bug.
Is there anything unusual about this system that might have caused this?
smcv
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.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894763> was another
instance of the same bug.
Is there anything unusual about this system that might have caused this?
smcv
Simon McVittie
Apr 24, 2018, 3:00:04 AM4/24/18
to
On Tue, 24 Apr 2018 at 01:33:02 -0400, rektide wrote:
> Hi sorry for the delay. Per request:
>
> $ ls -il {,/usr}/lib/x86_64-linux-gnu/libglib-2.0.so*
> 42488866 lrwxrwxrwx 1 root root 23 Mar 22 05:08 /lib/x86_64-linux-gnu/libglib-2.0.so.0 -> libglib-2.0.so.0.5600.0
> 3373718 -rw-r--r-- 1 root root 1107040 Oct 2 2014 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0
> 42488865 -rw-r--r-- 1 root root 1133872 Mar 22 05:08 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.0
> 3429235 lrwxrwxrwx 1 root root 38 Mar 22 05:08 /usr/lib/x86_64-linux-gnu/libglib-2.0.so -> /lib/x86_64-linux-gnu/libglib-2.0.so.0
>
> $ dpkg -S libglib-2.0.so
> libglib2.0-dev:amd64: /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.0-gdb.py
> libglib2.0-dev:amd64: /usr/lib/x86_64-linux-gnu/libglib-2.0.so
> libglib2.0-0:amd64: /lib/x86_64-linux-gnu/libglib-2.0.so.0
> libglib2.0-0:amd64: /lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.0
>
> That is rather old. The laptop in question was built from a Debian/testing base
> using debootstrap in early 2016. That's over two years after the timestamp of
> libglib-2.0.so.0.4200.0 (October 2014).
Did you install stable in early 2016 and then upgrade to testing, or did
you debootstrap testing and continue from there?
In early 2016, stable was Debian 8 'jessie' (now oldstable) and testing was
Debian 9 'stretch' (now stable).
libglib-2.0.so.0.4200.0 with a timestamp of October 2 2014 looks like
it could have come from glib2.0 2.42.0-2, but jessie was released with
glib2.0 2.42.1-1 (uploaded November 2014), so I'm not sure how you
got 2.42.0-2?
Do you have any other libraries not owned by a package? You could find out
with:
for x in {,/usr}/lib/x86_64-linux-gnu/*; do dpkg -S "$x" >/dev/null; done
You'll get a message on stderr like "dpkg-query: no path found
matching pattern /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0"
for each library that is like that. A few libraries are not provided
directly by packages because they use the alternatives system (like
/usr/lib/x86_64-linux-gnu/libblas.so.3) but most shouldn't produce
any output.
> I got my laptop operational again by installing snapshots. I'm currently
> using http://snapshot.debian.org/archive/debian/20180401/ , which gives me
> libglib2.0-0 version 2.56.0-4. I've been hesitant to switch back to 2.56.1-2
> (still the candidate) but should give the experiment a go, to see if it works
> or not after this downgrade to this snapshot restored my system.
If you move /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0 out of the way
(for instance create a /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0/bug896019
directory and move it there) then the upgrade back to 2.56.1-2 should work.
smcv
> Hi sorry for the delay. Per request:
>
> $ ls -il {,/usr}/lib/x86_64-linux-gnu/libglib-2.0.so*
> 42488866 lrwxrwxrwx 1 root root 23 Mar 22 05:08 /lib/x86_64-linux-gnu/libglib-2.0.so.0 -> libglib-2.0.so.0.5600.0
> 3373718 -rw-r--r-- 1 root root 1107040 Oct 2 2014 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0
> 42488865 -rw-r--r-- 1 root root 1133872 Mar 22 05:08 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.0
> 3429235 lrwxrwxrwx 1 root root 38 Mar 22 05:08 /usr/lib/x86_64-linux-gnu/libglib-2.0.so -> /lib/x86_64-linux-gnu/libglib-2.0.so.0
>
> $ dpkg -S libglib-2.0.so
> libglib2.0-dev:amd64: /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.0-gdb.py
> libglib2.0-dev:amd64: /usr/lib/x86_64-linux-gnu/libglib-2.0.so
> libglib2.0-0:amd64: /lib/x86_64-linux-gnu/libglib-2.0.so.0
> libglib2.0-0:amd64: /lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.0
>
> That is rather old. The laptop in question was built from a Debian/testing base
> using debootstrap in early 2016. That's over two years after the timestamp of
> libglib-2.0.so.0.4200.0 (October 2014).
Did you install stable in early 2016 and then upgrade to testing, or did
you debootstrap testing and continue from there?
In early 2016, stable was Debian 8 'jessie' (now oldstable) and testing was
Debian 9 'stretch' (now stable).
libglib-2.0.so.0.4200.0 with a timestamp of October 2 2014 looks like
it could have come from glib2.0 2.42.0-2, but jessie was released with
glib2.0 2.42.1-1 (uploaded November 2014), so I'm not sure how you
got 2.42.0-2?
Do you have any other libraries not owned by a package? You could find out
with:
for x in {,/usr}/lib/x86_64-linux-gnu/*; do dpkg -S "$x" >/dev/null; done
You'll get a message on stderr like "dpkg-query: no path found
matching pattern /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0"
for each library that is like that. A few libraries are not provided
directly by packages because they use the alternatives system (like
/usr/lib/x86_64-linux-gnu/libblas.so.3) but most shouldn't produce
any output.
> I got my laptop operational again by installing snapshots. I'm currently
> using http://snapshot.debian.org/archive/debian/20180401/ , which gives me
> libglib2.0-0 version 2.56.0-4. I've been hesitant to switch back to 2.56.1-2
> (still the candidate) but should give the experiment a go, to see if it works
> or not after this downgrade to this snapshot restored my system.
If you move /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0 out of the way
(for instance create a /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0/bug896019
directory and move it there) then the upgrade back to 2.56.1-2 should work.
smcv
Xilin Sun
Dec 3, 2018, 11:10:02 PM12/3/18
to
On Wed, 18 Apr 2018 14:43:47 -0400 rektide de la faye
<rek...@voodoowarez.com> wrote:
> Package: libglib2.0-0
> Version: 2.56.1-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> 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.
>
> Since installing, many many programs on my system refuse to start. Trying
> to run nmcli, for example, returns:
>
> nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
>
> I also see like errors trying to run lightdm, urxvt, vi.
> This file appears to be a symlink, pointing at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.
>
> There is a .4200.0 in that directory. I tried symlinking to that, but got a different set of undefined
> symbol errors keeping me from running things- g_option_group_unref.
>
> This does appear to gravely reduce the functionality of my workstation.
I recently ran into the same issue. libglib-2.0-0 was upgraded on my
<rek...@voodoowarez.com> wrote:
> Package: libglib2.0-0
> Version: 2.56.1-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> 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.
>
> Since installing, many many programs on my system refuse to start. Trying
> to run nmcli, for example, returns:
>
> nmcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
>
> I also see like errors trying to run lightdm, urxvt, vi.
> This file appears to be a symlink, pointing at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.1.
>
> There is a .4200.0 in that directory. I tried symlinking to that, but got a different set of undefined
> symbol errors keeping me from running things- g_option_group_unref.
>
> This does appear to gravely reduce the functionality of my workstation.
sid system. The current version is libglib2.0–0/unstable,now 2.58.1–2
amd64
During the next boot, I was unable to start lightdm. The error was
Dec 03 14:32:38 host lightdm[4829]: /usr/sbin/lightdm: symbol lookup
error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined
symbol: g_date_copy
I followed the discussion in this thread, and checked these files:
symbol: g_date_copy
my /lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1
my /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1
Now that GLib puts these files under /usr/lib/x86_64-linux-gnu/, my
/lib/x86_64-linux-gnu/libglib-2.0.so.* files from an old version of
glib should certainly have been deleted during the installation of the
new version, but somehow this didn't happen.
I suppose one way to reproduce this bug is to install the system with
libglib2.0–0 around version 2.48 and then do an upgrade to the latest
version.
Xilin Sun
Dec 3, 2018, 11:20:03 PM12/3/18
to
On Mon, 23 Apr 2018 17:47:56 +0100 Simon McVittie <sm...@debian.org> wrote:
> On Mon, 23 Apr 2018 at 17:11:11 +0200, Michael Biebl wrote:
> > @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.
>
> That's entirely possible.
By comparing the file lists of package libglib2.0-0 in stretch and
sid, I think the old copy of libglib in /lib/x86_64-linux was
introduced by the package itself, not 3rd party installers.
stretch: https://packages.debian.org/stretch/amd64/libglib2.0-0/filelist
/lib/x86_64-linux-gnu/libglib-2.0.so.0
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.3
...
sid: https://packages.debian.org/sid/amd64/libglib2.0-0/filelist
...
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1
...
> On Mon, 23 Apr 2018 at 17:11:11 +0200, Michael Biebl wrote:
> > @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.
>
> That's entirely possible.
By comparing the file lists of package libglib2.0-0 in stretch and
sid, I think the old copy of libglib in /lib/x86_64-linux was
introduced by the package itself, not 3rd party installers.
stretch: https://packages.debian.org/stretch/amd64/libglib2.0-0/filelist
/lib/x86_64-linux-gnu/libglib-2.0.so.0
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.3
...
sid: https://packages.debian.org/sid/amd64/libglib2.0-0/filelist
...
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1
...
Simon McVittie
Dec 30, 2018, 3:40:03 PM12/30/18
to
On Mon, 03 Dec 2018 at 19:57:39 -0800, Xilin Sun wrote:
> my /lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1
> my /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1
I wondered whether it was significant that GLib 2.48.0 was in
> my /lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1
> my /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1
jessie-backports, but your obsolete shared library looks like it came
from 2.48.1, so it's probably coincidence.
Please send the output of these to the bug address (some of them will
give error messages, that's fine; please send those too):
ls -il /lib/x86_64-linux-gnu/libglib-2.0.so.*
ls -il /lib/x86_64-linux-gnu/libgobject-2.0.so.*
dpkg-query -S /lib/x86_64-linux-gnu/libglib-2.0.so.*
dpkg-query -S /lib/x86_64-linux-gnu/libgobject-2.0.so.*
ls -il /usr/lib/x86_64-linux-gnu/libglib-2.0.so.*
ls -il /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.*
dpkg-query -S /usr/lib/x86_64-linux-gnu/libglib-2.0.so.*
dpkg-query -S /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.*
dpkg-query -S /lib/x86_64-linux-gnu/*.so.* > /dev/null
dpkg-query -S /usr/lib/x86_64-linux-gnu/*.so.* > /dev/null
Also please look in /var/log/apt for the upgrade history of your
libglib2.0-0 package (as far back as you can), tell us what the sequence
of versions was, and check whether the upgrade transactions involving
libglib2.0-0 logged any warnings or unusual messages in term.log.
What is the history of this machine? What version of Debian did you
originally install, and when did you switch the apt sources to take
packages from sid? (For instance the answer might be "installed wheezy,
upgraded to jessie, switched from jessie to sid in late 2016".)
> Now that GLib puts these files under /usr/lib/x86_64-linux-gnu/, my
> /lib/x86_64-linux-gnu/libglib-2.0.so.* files from an old version of
> glib should certainly have been deleted during the installation of the
> new version, but somehow this didn't happen.
> I suppose one way to reproduce this bug is to install the system with
> libglib2.0–0 around version 2.48 and then do an upgrade to the latest
> version.
bug report) and upgrading that, but my test VM doesn't have this bug
afterwards.
If it was that easy to reproduce, all Debian users with GLib installed
(including its maintainers) would have experienced this bug at the time
of the transition from GLib in /lib to GLib in /usr/lib, so there must
be some other factor involved. It's also noticeable that the stale GLib
versions are relatively old - probably not the most recently-installed.
On Mon, 03 Dec 2018 at 20:10:02 -0800, Xilin Sun wrote:
> By comparing the file lists of package libglib2.0-0 in stretch and
> sid, I think the old copy of libglib in /lib/x86_64-linux was
> introduced by the package itself, not 3rd party installers.
that something installed an older copy of GLib to the same path that
an old Debian package would have used. Do you use any third-party apt
sources, or do you have any third-party software installed that runs as
root?
Thanks,
smcv
Josef Kufner
Jul 15, 2019, 7:20:03 AM7/15/19
to
I hit this issue after yesterday upgrade from testing to the new stable
too. There was an old file libglib-2.0.so.0.4200.1 from April 2014. Once
I've removed it, mpd worked again.
I think that a simple consistency check about obsolete libraries might
be helpful.
So far I've used this to detect old libraries not managed by dpkg:
find /lib/x86_64-linux-gnu -type f \
| grep -v -x -F -f \
<(find '/var/lib/dpkg/info' -name '*.list' -print0 \
| xargs -0 grep -h '^/lib/x86_64-linux-gnu' \
| sort -u)
too. There was an old file libglib-2.0.so.0.4200.1 from April 2014. Once
I've removed it, mpd worked again.
I think that a simple consistency check about obsolete libraries might
be helpful.
So far I've used this to detect old libraries not managed by dpkg:
find /lib/x86_64-linux-gnu -type f \
| grep -v -x -F -f \
<(find '/var/lib/dpkg/info' -name '*.list' -print0 \
| xargs -0 grep -h '^/lib/x86_64-linux-gnu' \
| sort -u)
0 new messages