Debian Bug report logs - #1011166
pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0

serious

[Message part 1 (text/plain, inline)]
Source: pidgin, chatty
Control: found -1 pidgin/2.14.9-2
Control: found -1 chatty/0.6.3-1
Severity: serious
Tags: sid bookworm
User: debian-ci@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of pidgin the autopkgtest of chatty fails in 
testing when that autopkgtest is run with the binary packages of pidgin 
from unstable. It passes when run with only packages from testing. In 
tabular form:

                       pass            fail
pidgin                 from testing    2.14.9-2
chatty                 from testing    0.6.3-1
all others             from testing    from testing

I copied some of the output at the bottom of this report. I note that 
the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to 
/usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0. Naively I would 
have expected it to be picked up, but maybe the /purple-2 in the middle 
of the path is preventing that.

Currently this regression is blocking the migration of pidgin to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
pidgin/2.14.9-2. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=pidgin

https://ci.debian.net/data/autopkgtest/testing/amd64/c/chatty/21821951/log.gz

/usr/bin/chatty: error while loading shared libraries: libjabber.so.0: 
cannot open shared object file: No such file or directory
autopkgtest [19:11:11]: test command1

[OpenPGP_signature (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Control: notfound 1011166 pidgin/2.14.9-2
Control: tags 1011166 patch

On 5/17/22 15:34, Paul Gevers wrote:
> I note that 
> the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to 
> /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.

I converted from an ancient compat version to modern debhelper. This 
brought in multiarch support. Rather than fight it, I just went with 
that, since the problem looked tractable.

> Naively I would 
> have expected it to be picked up, but maybe the /purple-2 in the middle 
> of the path is preventing that.

-- BEGIN RED HERRING --

I would expect it to be picked up.

libpurple/plugin.c sets up the search path for that purple-2 directory 
(which is where all libpurple plugins are installed):
    purple_plugins_add_search_path(LIBDIR);

In libpurple/Makefile.am, AM_CPPFLAGS has:
    -DLIBDIR=\"$(libdir)/purple-$(PURPLE_MAJOR_VERSION)/\"

This should cause us to find libxmpp.so, the protocol plugin. It then 
needs to bring in libjabber.so, an internal library. It should be 
finding this with RUNPATH, I believe:

$ readelf -a /usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so  | grep -i path
 0x000000000000001d (RUNPATH)            Library runpath: 
[/usr/lib/x86_64-linux-gnu/purple-2]

If I run: LD_DEBUG=libs pidgin -n

That is indeed what happens:
     43864:     find library=libjabber.so.0 [0]; searching
     43864:      search 
path=/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell:/usr/lib/x86_64-linux-gnu/purple-2/tls/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls:/usr/lib/x86_64-linux-gnu/purple-2/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/haswell:/usr/lib/x86_64-linux-gnu/purple-2/x86_64:/usr/lib/x86_64-linux-gnu/purple-2 
           (RUNPATH from file 
/usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so)

If I run: LD_DEBUG=libs chatty

It fails:

     43926:	find library=libjabber.so.0 [0]; searching
     43926:	 search path=/usr/lib/purple-2		(RUNPATH from file chatty)
     43926:	  trying file=/usr/lib/purple-2/libjabber.so.0
     43926:	 search cache=/etc/ld.so.cache
     43926:	 search 
path=/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/glibc-hwcaps/x86-64-v3:/lib/glibc-hwcaps/x86-64-v2:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/glibc-hwcaps/x86-64-v3:/usr/lib/glibc-hwcaps/x86-64-v2:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib 
	(system search path)

At first glance, it felt like the RUNPATH from chatty was winning over 
that from libxmpp.so.

-- END RED HERRING --

Upon further investigation, the real issue is that chatty is directly 
linking to libjabber.so, and they're setting a RUNPATH to do it.

chatty's src/meson.build has:
executable('chatty', chatty_sources, resources,
  include_directories: src_inc,
  dependencies: chatty_deps,
  link_with: libchatty.get_static_lib(),
  install: true,
  install_rpath: purple_plugdir,
)

Note the install_rpath.

and src/purple/meson.build has (manual wrapping added for email):

purple_plugdir = purple_dep.get_pkgconfig_variable('plugindir')
jabber = meson.get_compiler('c').find_library(
    'jabber', dirs: purple_plugdir)

In terms of "Who is at fault?", I blame chatty for explicitly linking to 
an internal library. However, in fairness, I understand that they have 
their reasons and a better solution was never found with upstream (at 
least in part because no significant changes are going to go into purple 
2 at this point):
https://source.puri.sm/Librem5/chatty/-/issues/266

The good news here is that a rebuild of chatty is all that's necessary. 
A binNMU should be sufficient to fix the bug. I've submitted a request 
for one, but this was my first time, so I might have done something wrong.

To fix it fully correctly, though, I think we want a versioned 
Build-Depends to ensure it cannot be built against an old libpurple0 
(not that such a thing should happen). And a lintian override needs 
updating. Here is a MR for that:
https://salsa.debian.org/DebianOnMobile-team/chatty/-/merge_requests/21

-- 
Richard

[OpenPGP_signature (application/pgp-signature, attachment)]
Hi,

On Wed, 2022-05-18 at 03:04 -0500, Richard Laager wrote:
> Control: notfound 1011166 pidgin/2.14.9-2
> Control: tags 1011166 patch
> 
> On 5/17/22 15:34, Paul Gevers wrote:
> > I note that 
> > the library moved location from /usr/lib/purple-
> > 2/libjabber.so.0.0.0 to 
> > /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.
> 
> I converted from an ancient compat version to modern debhelper. This 
> brought in multiarch support. Rather than fight it, I just went with 
> that, since the problem looked tractable.
> 
> > Naively I would 
> > have expected it to be picked up, but maybe the /purple-2 in the
> > middle 
> > of the path is preventing that.
> 
> -- BEGIN RED HERRING --
> 
> I would expect it to be picked up.
> 
> libpurple/plugin.c sets up the search path for that purple-2
> directory 
> (which is where all libpurple plugins are installed):
>      purple_plugins_add_search_path(LIBDIR);
> 
> In libpurple/Makefile.am, AM_CPPFLAGS has:
>      -DLIBDIR=\"$(libdir)/purple-$(PURPLE_MAJOR_VERSION)/\"
> 
> This should cause us to find libxmpp.so, the protocol plugin. It then
> needs to bring in libjabber.so, an internal library. It should be 
> finding this with RUNPATH, I believe:
> 
> $ readelf -a /usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so  | grep -i
> path
>   0x000000000000001d (RUNPATH)            Library runpath: 
> [/usr/lib/x86_64-linux-gnu/purple-2]
> 
> If I run: LD_DEBUG=libs pidgin -n
> 
> That is indeed what happens:
>       43864:     find library=libjabber.so.0 [0]; searching
>       43864:      search 
> path=/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-
> v3:/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-
> v2:/usr/lib/x86_64-linux-gnu/purple-
> 2/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-
> 2/tls/haswell:/usr/lib/x86_64-linux-gnu/purple-
> 2/tls/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls:/usr/lib/x86_64-
> linux-gnu/purple-2/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-
> 2/haswell:/usr/lib/x86_64-linux-gnu/purple-2/x86_64:/usr/lib/x86_64-
> linux-gnu/purple-2 
>             (RUNPATH from file 
> /usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so)
> 
> If I run: LD_DEBUG=libs chatty
> 
> It fails:
> 
>       43926:    find library=libjabber.so.0 [0]; searching
>       43926:     search path=/usr/lib/purple-2          (RUNPATH from
> file chatty)
>       43926:      trying file=/usr/lib/purple-2/libjabber.so.0
>       43926:     search cache=/etc/ld.so.cache
>       43926:     search 
> path=/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/lib/x86_64-linux-
> gnu/glibc-hwcaps/x86-64-v2:/lib/x86_64-linux-
> gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-
> linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-
> gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-
> gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/glibc-
> hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-
> v2:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-
> linux-gnu/tls/haswell:/usr/lib/x86_64-linux-
> gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-
> gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-
> linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/glibc-hwcaps/x86-64-
> v3:/lib/glibc-hwcaps/x86-64-
> v2:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:
> /lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/glibc-
> hwcaps/x86-64-v3:/usr/lib/glibc-hwcaps/x86-64-
> v2:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_
> 64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86
> _64:/usr/lib 
>         (system search path)
> 
> At first glance, it felt like the RUNPATH from chatty was winning
> over 
> that from libxmpp.so.
> 
> -- END RED HERRING --
> 
> Upon further investigation, the real issue is that chatty is directly
> linking to libjabber.so, and they're setting a RUNPATH to do it.
> 
> chatty's src/meson.build has:
> executable('chatty', chatty_sources, resources,
>    include_directories: src_inc,
>    dependencies: chatty_deps,
>    link_with: libchatty.get_static_lib(),
>    install: true,
>    install_rpath: purple_plugdir,
> )
> 
> Note the install_rpath.
> 
> and src/purple/meson.build has (manual wrapping added for email):
> 
> purple_plugdir = purple_dep.get_pkgconfig_variable('plugindir')
> jabber = meson.get_compiler('c').find_library(
>      'jabber', dirs: purple_plugdir)
> 
> In terms of "Who is at fault?", I blame chatty for explicitly linking
> to 
> an internal library. However, in fairness, I understand that they
> have 
> their reasons and a better solution was never found with upstream (at
> least in part because no significant changes are going to go into
> purple 
> 2 at this point):
> https://source.puri.sm/Librem5/chatty/-/issues/266
> 

thanks for the thorough analysis!

> The good news here is that a rebuild of chatty is all that's
> necessary. 

Indeed. I noticed this while preparing the upgrade to the latest
version.

> A binNMU should be sufficient to fix the bug. I've submitted a
> request 
> for one, but this was my first time, so I might have done something
> wrong.
> 
> To fix it fully correctly, though, I think we want a versioned 
> Build-Depends to ensure it cannot be built against an old libpurple0 
> (not that such a thing should happen). And a lintian override needs 
> updating. Here is a MR for that:
> https://salsa.debian.org/DebianOnMobile-team/chatty/-/merge_requests/21

Thanks for the patch! I'll upload a fixed version soon.

Evangelos

> 
> -- 
> Richard
> _______________________________________________
> Debian-on-mobile-maintainers mailing list
> Debian-on-mobile-maintainers@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

[Message part 1 (text/plain, inline)]
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
> Thanks for the patch! I'll upload a fixed version soon.

If you upload a new version, you (or I) can then close the binNMU 
request, bug #1011201.

-- 
Richard

[OpenPGP_signature (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Hi, 
On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote:
> On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
> > Thanks for the patch! I'll upload a fixed version soon.
> 
> If you upload a new version, you (or I) can then close the binNMU 
> request, bug #1011201.

I have prepared an update on salsa [0].
I was wondering one thing though: The packaging used to have 

override dh_shlibdeps:
  dh_shlibdeps -l/usr/lib/purple-2

which I stripped, because 
a) the path is now wrong
b) it doesn't seem to get used at all, judging by compairing packages
built with an updated path and without the override

Since I'm not 100% sure if this was ever actually needed, I was curious
if you could potentially shed some light ;)

[0]
https://salsa.debian.org/DebianOnMobile-team/chatty/-/merge_requests/22

Cheers
-- 
Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On 5/20/22 01:56, Evangelos Ribeiro Tzaras wrote:
> Hi,
> On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote:
>> On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
>>> Thanks for the patch! I'll upload a fixed version soon.
>>
>> If you upload a new version, you (or I) can then close the binNMU
>> request, bug #1011201.
> 
> I have prepared an update on salsa [0].
> I was wondering one thing though: The packaging used to have
> 
> override dh_shlibdeps:
>    dh_shlibdeps -l/usr/lib/purple-2
> 
> which I stripped, because
> a) the path is now wrong
> b) it doesn't seem to get used at all, judging by compairing packages
> built with an updated path and without the override
> 
> Since I'm not 100% sure if this was ever actually needed, I was curious
> if you could potentially shed some light ;)

No idea. Judging from the description in the man page, it's probably not 
necessary. And your testing seemingly confirms that. I think you're 
right to strip it.

-- 
Richard

[OpenPGP_signature (application/pgp-signature, attachment)]
Source: chatty
Source-Version: 0.6.4-1
Done: Evangelos Ribeiro Tzaras <devrtz-debian@fortysixandtwo.eu>

We believe that the bug you reported is fixed in the latest version of
chatty, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1011166@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Evangelos Ribeiro Tzaras <devrtz-debian@fortysixandtwo.eu> (supplier of updated chatty package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 19 May 2022 23:58:49 +0200
Source: chatty
Architecture: source
Version: 0.6.4-1
Distribution: unstable
Urgency: medium
Maintainer: DebianOnMobile Maintainers <debian-on-mobile-maintainers@alioth-lists.debian.net>
Changed-By: Evangelos Ribeiro Tzaras <devrtz-debian@fortysixandtwo.eu>
Closes: 1011166
Changes:
 chatty (0.6.4-1) unstable; urgency=medium
 .
   [ Richard Laager ]
   * Update for multiarch libpurple0 2.14.9-1 (Closes: 1011166)
     Thanks to Paul Gevers
 .
   [ Evangelos Ribeiro Tzaras ]
   * New upstream version 0.6.4
   * Declare compliance with Debian Policy 4.6.1
   * Remove unneeded dh_shlibdeps override
Checksums-Sha1:
 e6ee635683ca9bfa540b2bc0eb58705d4deeab6d 2491 chatty_0.6.4-1.dsc
 0e85c932d0ce35b87ebf88801f9b87899c349d43 450508 chatty_0.6.4.orig.tar.xz
 69da37c27a9bc8c301e1f68230b1ad1a9e2bcb92 11380 chatty_0.6.4-1.debian.tar.xz
 0646aae5181e88e96267c9bfb411169b507003ff 22232 chatty_0.6.4-1_source.buildinfo
Checksums-Sha256:
 9f499949e03b826db4dc93adc42cea3ffacaf95dc9e92d742c66039afa217843 2491 chatty_0.6.4-1.dsc
 2ea321a5a84fd628e27964e06b7d210d6c421a81c7876bc0c1c26cbca3fab071 450508 chatty_0.6.4.orig.tar.xz
 e6db423c738454ae8d0b6237b93913391ee6805fbac73bf49e3348481915e8a6 11380 chatty_0.6.4-1.debian.tar.xz
 a4a40b3a4f05ff9de34a9b16654c230034960e0d3b8f7a0ddda3a97ffa15e2c8 22232 chatty_0.6.4-1_source.buildinfo
Files:
 e02f3c6c19a10c377f90537aba24a603 2491 net optional chatty_0.6.4-1.dsc
 4cfc73b0aa9aea821a39f882d9f04be2 450508 net optional chatty_0.6.4.orig.tar.xz
 ed80de6bd76d527c0a0a392dfc0ce6b8 11380 net optional chatty_0.6.4-1.debian.tar.xz
 3d1fab078aaff625884a183fe3f1f37a 22232 net optional chatty_0.6.4-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJUBAEBCgA+FiEEuThlVLfdJmvLjimpkPDJsYprShkFAmKHuUsgHGRldnJ0ei1k
ZWJpYW5AZm9ydHlzaXhhbmR0d28uZXUACgkQkPDJsYprShlTEhAAiHiDgHHLnHiw
cOx7iK0MmPvFhmdN+GXdFNAWlVvg+YnAT0f93nu3E5aUgGVLsRiXIxkoHCGBkgks
uqp569g78ZexJ9RPWLMFAUgSP1uU8mWsay7tpdako73HfrKK/Hacuip6jJg71bP6
1OIwLF7VretkypA2LLo0+qVwiaqE8i7EAc+qWKjplgTYAmFQzDuGSCKdBn9q7G4T
gUFo9hluiFk+/ik7QZQZnoGkz4sWKEHyDDQUyKSz7czSRFztzPU7lHkP7aQ0xhJ1
A2UPozPeHVR8soLgnnGAsbbiiY3oVlJfNDUh1lExkFFYDgoU+zVi/WYXCiuRQcCd
XDVhm8PvLeQlS0ppFQ2+SV5Tepil++XWHSP4/ALEhpNQY/YytHGQEWfrtcqQo/RB
MBjiB2dp4mVe4AXKCOwS8+XN5l3JJf6sH1XUgdjct7vf5J8UlF14LheHnCNdF6P8
fGBce7gqARRPdr159ojPfZ9FomlBIO4bpDsLYJhwIinuBF/Q2WQfkE5qWrkNsYKf
mWka2tTz4oDsKVVCz110mEMsmWFkSMwL/s65MDY+G8eMflpoFpmTpbkrAXxLsX/i
Q1ivUJd2+k8V3HFYq5vTjzLauc/paEeWg06MWvPG7HgKneY4yqla3P0gG9xd179i
EA7t487bNOFf4+G4YydVAg3lHgaLV5w=
=eulB
-----END PGP SIGNATURE-----

[Message part 1 (text/plain, inline)]
Hi,
On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote:
> On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
> > Thanks for the patch! I'll upload a fixed version soon.
> 
> If you upload a new version, you (or I) can then close the binNMU 
> request, bug #1011201.

just uploaded, and closing #1011201, thanks again!

Cheers,
Evangelos

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/html, inline)]
[Message part 1 (text/plain, inline)]
Hi,

On Sun, 22 May 2022 02:06:31 +0200 (CEST) Julien <gouessej@orange.fr>
wrote:
> Sorry for my silly question but why does Chatty still fail to start?
My pinephone is my daily driver, can you tell me what still needs to be
fixed? Do I have to use &#34;ln -s&#34; in the meantime?
> 

it should migrate to testing in ~4 days, in the meantime you could grab
it from unstable or add a suitable LD_LIBRARY_PATH, f.e. on amd64

$ LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/purple-2 chatty

Cheers

[signature.asc (application/pgp-signature, inline)]

Debian Bug report logs - #1011166 pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0

Debian Bug report logs - #1011166
pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0