Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Simon McVittie]

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

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Simon McVittie]

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.

> @rektide: the time stamp of
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0 would be interesting.

I already asked for "ls -il" output which would tell us the timestamp
(as well as whether various files are hard-links to each other).

> Does that coincide wit the installation of a proprietary/non-Debian
> package or the use of "make install"?

Whether there's a correlation with some other event is also interesting
information, though.

smcv

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Michael Biebl]

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

Processed: Re: Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + moreinfo unreproducible
Bug #896019 [libglib2.0-0] libglib2.0-0: undefined symbol g_date_copy breaking 
many programs
Added tag(s) unreproducible and moreinfo.

-- 
896019: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896019
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[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.

 was another
instance of the same bug.

Is there anything unusual about this system that might have caused this?

smcv

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Vincent Lefevre]

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
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.

I don't have .4200.0 files for glib2.0 libraries.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[Michael Biebl]

Am 18.04.2018 um 20:43 schrieb rektide de la faye:
> 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.
> 


Where is that .4200.0 file coming from?
This looks pretty much like a duplicate of #894763


-- 
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

Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

[rektide de la faye]

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  libc62.27-3
ii  libffi6  3.2.1-4
ii  libmount12.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