Bug#955331: After upgrading to buster, libgobject-2.0.so.0 give error "undefined symbol: g_variant_dict_ref"

[Simon McVittie]

On Tue, 31 Mar 2020 at 01:27:44 +0100, Becka wrote:
> > Do you have an old version of libglib-2.0.so.0 in /lib/i386-linux-gnu?
> 
> Yes.  And I feel like I have wasted your time now, as this was the problem.

You've provided information that we didn't have before, which is never a
waste of time when trying to fix a bug without knowing why it happens...

> > Is there anything unusual about this machine that might have resulted
> > in it being one of the unlucky ones
> 
> It is ordinary Debian stable originally installed from an image, I
> think that was squeeze, and updated through apt-get.  The one slightly odd
> thing about my setup is that my root is on a small USB stick

Hmm. I wonder whether that's significant: one of the other bug reports
with this failure mode was on a Raspberry Pi SD card, and neither USB
sticks nor SD cards are really designed for heavy/long-term use, so
they're probably more prone to corruption than a conventional HDD/SSD.

> > You will probably also have old versions of libgio-2.0.so.0,
> > libgmodule-2.0.so.0, libgthread-2.0.so.0 in /usr/lib/i386-linux-gnu. It's
> > probably best if you remove those too.
> 
> That worked!  Thank you.  And yes, the other files did exist.

If they also existed, that's at least consistent... which is maybe
evidence that this *wasn't* caused by filesystem corruption?

> My oldest history.log file under /var/log/apt has the timestamp of
> Nov 29, 2015, and the below log entries are the start of the file as it
> attempts to upgrade the library from 2.33.12+really2.32.4-5 to 2.42.1-1.

Interesting. That means that to have ever had 2.36.x installed, at some
point you must have upgraded to unstable or testing, and then downgraded
back to stable at some later time?

That isn't a supported action (we officially don't support downgrades),
but it also isn't meant to leave stray files lying around like this.

> > The output of these commands would also be useful information:
> > 
> > for lib in /lib/i386-linux-gnu/*.so.*; do dpkg -S "$lib" >/dev/null || echo "$lib is not owned by a package"; done
> > for lib in /usr/lib/i386-linux-gnu/*.so.*; do dpkg -S "$lib" >/dev/null || echo "$lib is not owned by a package"; done
> 
> Neither command produced any output.

That is itself useful information: it tells me that GLib was the only
(32-bit) library for which this happened to you.

That suggests that there might be something special about GLib, beyond
"has moved from /lib to /usr/lib" (which is consistent with the fact
that we keep getting these bug reports that other library maintainers
mostly don't) - but I have no idea what.

    smcv