Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

[Axel Beckert]

Package: libglib2.0-0
Version: 2.56.0-5
Severity: grave
Control: affects -1 + emacs25

Dear Maintainers,

since very recently, emacs25 on armhf (but not on amd64) crashes for
me as follows:

emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

Since emacs25 itself was last uploaded in 2017, i.e. over three months
ago, I assumed the culprit is hidden in the very recently updated
libglib2.0-0 package. And indeed, downgrading libglib2.0-0 to 2.56.0-4
causes the issue to vanish.

Due to emacs crashing, this issue also causes the postinst of every
elpa-* package and probably also every *-mode package to fail.

Actually this is where I noticed the issue first:

Setting up mmm-mode (0.5.5-2) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package mmm-mode (--configure):
installed mmm-mode package post-installation script subprocess returned error exit status 1
Setting up elpa-gitattributes-mode (1.2.7-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-gitattributes-mode (--configure):
installed elpa-gitattributes-mode package post-installation script subprocess returned error exit status 1
Setting up elpa-no-littering (0.5.13-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-no-littering (--configure):
installed elpa-no-littering package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of elpa-git-modes:
elpa-git-modes depends on elpa-gitattributes-mode (= 1.2.7-1); however:
Package elpa-gitattributes-mode is not configured yet.

dpkg: error processing package elpa-git-modes (--configure):
dependency problems - leaving unconfigured
Setting up elpa-ps-ccrypt (1.10-6) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-ps-ccrypt (--configure):
installed elpa-ps-ccrypt package post-installation script subprocess returned error exit status 1
Setting up elpa-hl-todo (1.8.1-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-hl-todo (--configure):
installed elpa-hl-todo package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
mmm-mode
elpa-gitattributes-mode
elpa-no-littering
elpa-git-modes
elpa-ps-ccrypt
elpa-hl-todo

-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libglib2.0-0 depends on:
ii libc6 2.27-3
ii libffi6 3.2.1-8
ii libmount1 2.31.1-0.5
ii libpcre3 2:8.39-9
ii libselinux1 2.7-2+b2
ii zlib1g 1:1.2.8.dfsg-5

Versions of packages libglib2.0-0 recommends:
ii libglib2.0-data 2.56.0-5
ii shared-mime-info 1.9-2
pn xdg-user-dirs <none>

libglib2.0-0 suggests no packages.

-- no debconf information

[Simon McVittie]

Post by Axel Beckert
since very recently, emacs25 on armhf (but not on amd64) crashes for
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

I would normally ask: if you run `ldd emacs25`, what does it
say? But this is emacs, so the answer is quite possibly "too much".
`ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules` might give
a more concise answer that still contains the information I'm looking for.

In fact, running

LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules

and seeing whether it fails might also give interesting information.
(If successful, it should just print a usage message saying it requires
at least one <directory> parameter.)

Post by Axel Beckert
Since emacs25 itself was last uploaded in 2017, i.e. over three months
ago, I assumed the culprit is hidden in the very recently updated
libglib2.0-0 package. And indeed, downgrading libglib2.0-0 to 2.56.0-4
causes the issue to vanish.

There were no source code changes in upgrading libglib2.0-0 from 2.56.0-4
to 2.56.0-5, so it really shouldn't have lost any symbols; and if it did,
that should have caused FTBFS when it didn't match its .symbols file.

One major change in 2.56.0-5 is that libglib2.0.so.0 moved from
/lib/MULTIARCH to /usr/lib/MULTIARCH, which makes me wonder whether you
have an outdated version of GLib elsewhere in your library search path
or elsewhere in emacs25's RPATH or RUNPATH, such that the outdated version
was found after /lib/MULTIARCH but before /usr/lib/MULTIARCH?

Another possibility is that emacs25 might do something horrible during
its startup that makes it rely on absolute paths to libraries (I don't
use emacs myself, but I dimly remember rumours of it using a core dump
to optimize its own startup). But if it does that, then I would have
expected it to break equally badly whenever a library moves to the
multiarch directory?

smcv

[Axel Beckert]

Hi Simon,

Post by Simon McVittie

Post by Axel Beckert
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

[fast forward → TL;DR]

Post by Simon McVittie
In fact, running
LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
and seeing whether it fails might also give interesting information.

It fails in the same way as emacs fails:

~ → LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

Downgrading helps also here:

~ → LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
Usage: gio-querymodules <directory1> [<directory2> ...]
Will update giomodule.cache in the listed directories

For completeness, following is the remainder of the questions with the
long answers. ;-)

Post by Simon McVittie
I would normally ask: if you run `ldd emacs25`, what does it say?

Ah, right. Should have done that in the initial mail:

~ → emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy
~ → ldd =emacs25
libtiff.so.5 => /usr/lib/arm-linux-gnueabihf/libtiff.so.5 (0x76ec3000)
libjpeg.so.62 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 (0x76e8a000)
libpng16.so.16 => /usr/lib/arm-linux-gnueabihf/libpng16.so.16 (0x76e59000)
libgif.so.7 => /usr/lib/arm-linux-gnueabihf/libgif.so.7 (0x76e43000)
libXpm.so.4 => /usr/lib/arm-linux-gnueabihf/libXpm.so.4 (0x76e27000)
libXaw3d.so.6 => /usr/lib/arm-linux-gnueabihf/libXaw3d.so.6 (0x76dd3000)
libXmu.so.6 => /usr/lib/arm-linux-gnueabihf/libXmu.so.6 (0x76db3000)
libXt.so.6 => /usr/lib/arm-linux-gnueabihf/libXt.so.6 (0x76d68000)
libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x76d52000)
libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 (0x76d31000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0x76d16000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76c21000)
libX11-xcb.so.1 => /usr/lib/arm-linux-gnueabihf/libX11-xcb.so.1 (0x76c0f000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76be7000)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0x76bd0000)
libXft.so.2 => /usr/lib/arm-linux-gnueabihf/libXft.so.2 (0x76bb2000)
libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 (0x76afd000)
librsvg-2.so.2 => /usr/lib/arm-linux-gnueabihf/librsvg-2.so.2 (0x76ac9000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76a48000)
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0x7693a000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0x76910000)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x768c8000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x767ef000)
libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0x76731000)
libMagickWand-6.Q16.so.5 => /usr/lib/arm-linux-gnueabihf/libMagickWand-6.Q16.so.5 (0x7664b000)
libMagickCore-6.Q16.so.5 => /usr/lib/arm-linux-gnueabihf/libMagickCore-6.Q16.so.5 (0x7643b000)
libacl.so.1 => /lib/arm-linux-gnueabihf/libacl.so.1 (0x76425000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x7640f000)
libdbus-1.so.3 => /lib/arm-linux-gnueabihf/libdbus-1.so.3 (0x763ce000)
libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0x763b7000)
libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0x763a4000)
libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0x76390000)
libxml2.so.2 => /usr/lib/arm-linux-gnueabihf/libxml2.so.2 (0x7626d000)
libgpm.so.2 => /usr/lib/arm-linux-gnueabihf/libgpm.so.2 (0x76256000)
libtinfo.so.5 => /lib/arm-linux-gnueabihf/libtinfo.so.5 (0x7622b000)
libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x76201000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x76185000)
libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0x76146000)
libotf.so.0 => /usr/lib/arm-linux-gnueabihf/libotf.so.0 (0x76127000)
libm17n-core.so.0 => /usr/lib/arm-linux-gnueabihf/libm17n-core.so.0 (0x760fa000)
libm17n-flt.so.0 => /usr/lib/arm-linux-gnueabihf/libm17n-flt.so.0 (0x760e2000)
libgnutls.so.30 => /usr/lib/arm-linux-gnueabihf/libgnutls.so.30 (0x75fdf000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x75fba000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x75f98000)
libgomp.so.1 => /usr/lib/arm-linux-gnueabihf/libgomp.so.1 (0x75f68000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x75e70000)
/lib/ld-linux-armhf.so.3 (0x76f3d000)
liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0x75e46000)
libjbig.so.0 => /usr/lib/arm-linux-gnueabihf/libjbig.so.0 (0x75e2b000)
libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x75e15000)
libbsd.so.0 => /lib/arm-linux-gnueabihf/libbsd.so.0 (0x75df2000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x75ddf000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x75dcc000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x75db8000)
libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0x75d9f000)
libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0x75d7f000)
libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0x75d40000)
libcroco-0.6.so.3 => /usr/lib/arm-linux-gnueabihf/libcroco-0.6.so.3 (0x75d0b000)
libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x75cf8000)
libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0x75cd8000)
libmount.so.1 => /lib/arm-linux-gnueabihf/libmount.so.1 (0x75c8f000)
libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0x75c79000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x75c1c000)
libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0x75b94000)
libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0x75b81000)
libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0x75b66000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x75b3d000)
liblcms2.so.2 => /usr/lib/arm-linux-gnueabihf/liblcms2.so.2 (0x75af6000)
liblqr-1.so.0 => /usr/lib/arm-linux-gnueabihf/liblqr-1.so.0 (0x75add000)
libfftw3.so.3 => /usr/lib/arm-linux-gnueabihf/libfftw3.so.3 (0x75a01000)
libbz2.so.1.0 => /lib/arm-linux-gnueabihf/libbz2.so.1.0 (0x759e5000)
libltdl.so.7 => /usr/lib/arm-linux-gnueabihf/libltdl.so.7 (0x759ce000)
libattr.so.1 => /lib/arm-linux-gnueabihf/libattr.so.1 (0x759ba000)
libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0x75952000)
libicui18n.so.57 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.57 (0x757a7000)
libicuuc.so.57 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.57 (0x7567d000)
libicudata.so.57 => /usr/lib/arm-linux-gnueabihf/libicudata.so.57 (0x73df0000)
libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0x73dbe000)
libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0x73da7000)
libp11-kit.so.0 => /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 (0x73ce6000)
libidn2.so.0 => /usr/lib/arm-linux-gnueabihf/libidn2.so.0 (0x73cbb000)
libunistring.so.2 => /usr/lib/arm-linux-gnueabihf/libunistring.so.2 (0x73b4f000)
libtasn1.so.6 => /usr/lib/arm-linux-gnueabihf/libtasn1.so.6 (0x73b33000)
libnettle.so.6 => /usr/lib/arm-linux-gnueabihf/libnettle.so.6 (0x73af5000)
libhogweed.so.4 => /usr/lib/arm-linux-gnueabihf/libhogweed.so.4 (0x73abc000)
libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0x73a61000)
libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0x739de000)
libfribidi.so.0 => /usr/lib/arm-linux-gnueabihf/libfribidi.so.0 (0x739b9000)
libblkid.so.1 => /lib/arm-linux-gnueabihf/libblkid.so.1 (0x73977000)
liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0x7395b000)
libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x738a5000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x7379a000)
libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0x73786000)
libgraphite2.so.3 => /usr/lib/arm-linux-gnueabihf/libgraphite2.so.3 (0x73759000)
libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0x73738000)

(Yeah, too much. And it's actually "just" emacs25-nox, not the
full-blown variant. ;-)

Post by Simon McVittie
`ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules` might give
a more concise answer that still contains the information I'm looking for.

~ → ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0x76e3f000)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x76df7000)
libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x76de4000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x76d0d000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76c15000)
/lib/ld-linux-armhf.so.3 (0x76f72000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x76bf3000)
libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x76bc9000)
libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0x76ba9000)
libmount.so.1 => /lib/arm-linux-gnueabihf/libmount.so.1 (0x76b60000)
libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0x76b4a000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76b37000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x76ad8000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ab3000)
libblkid.so.1 => /lib/arm-linux-gnueabihf/libblkid.so.1 (0x76a71000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76a5b000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76a32000)
libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x76a1c000)

P.S.: Hardware is a Raspberry Pi 2, in case it makes any difference.

Regards, Axel

[Simon McVittie]

Post by Axel Beckert
...
~ → ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0x76e3f000)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x76df7000)
libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x76de4000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x76d0d000)
...

This looks like there is a libglib-2.0.so.0 in /lib/arm-linux-gnueabihf/
that shouldn't be there, and this takes precedence over the more recent
one from the Debian package that gets installed to /usr/lib.

My thoughts exactly. What's that doing there? I would have expected that
removing the old libglib2.0-0 package would delete that.

Please try:

ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so*
ls -il /usr/lib/arm-linux-gnueabihf/libglib-2.0.so*

Since you were seeing these symbol lookup errors while packages are
being configured, I wonder whether we're seeing something like this:

* new libglib2.0-0 is unpacked
- /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0 has been created
(it is hard-linked to
/usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0.dpkg-new or something)
- /lib/arm-linux-gnueabihf/libglib-2.0.so.0 has not yet been deleted
(it is hard-linked to
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.dpkg-old or something)
* assorted other packages are unpacked
* assorted other packages are configured
- in your situation, we fail here and never get further
* new libglib2.0-0 is configured
- /lib/arm-linux-gnueabihf/libglib-2.0.so.0 should be deleted here

If that guess is correct, then we're going to have difficulty whenever we
migrate a library from a higher-precedence directory (/lib/MULTIARCH) to
a lower-precedence directory (/usr/lib/MULTIARCH), and we'd have the same
issue moving a non-multiarch library from /lib to /usr/lib. The multiarch
directories (from ld.so.conf.d) are higher-precedence than the non-multiarch
directories (hard-coded), so we only coincidentally avoided this for the
migration from non-multiarch to multiarch.

GLib maintainers following testing/unstable wouldn't have seen this
failure mode, because we would be very likely to be upgrading from a
version that is recent enough that it already has all the same symbols as
the one in /lib; but it would be a problem for stretch -> buster upgrades.

smcv