acroread does not work anymore

English Applications
1

Updated to 20170529 and found that acroread does not work anymore. Tried to reinstall and got the message:

erlangen:~ # zypper in acroread
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides ISO8859-1.so needed by acroread-9.5.5-8.1.i586
 Solution 1: do not install acroread-9.5.5-8.1.i586
 Solution 2: break acroread-9.5.5-8.1.i586 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): 
erlangen:~ #

Solution #2 does not work. Any suggestions?

2

Yes, use Solution #1.

AK

3

Hi
Looks like glibc-locale doesn’t provide the ISO8859-1.so anymore…

4

Yes, for several years I checked out okular and everytime I noticed that even on modern hardware it took considerable time to display a single page. Thus I preferred acroread which was really fast. I checked again with okular-17.04.1-1.2.x86_64 and found displaying a page has become faster. But I think okular is still sluggish compared to acroread. Are there any other pdf readers available with better speed?

5

Likely dozens, qpdfview, xpdf, evince, ghostview come to (my) mind, for more you can do your own (re)search.

Using acroread for speed reasons (which I find funny as it always has been an ugly and giant blob) is certainly the worst idea as this piece of software has been unmaintained for several years now and is a huge security risk (not mentioning the non-security bugs).

AK

6

Hm, I searched and got

erlangen:~ # find / -xdev -name ISO8859-1.so
/usr/lib64/gconv/ISO8859-1.so
/usr/lib/gconv/ISO8859-1.so
erlangen:~ #

Does it need to be moved?

7

Hi
Run ldd against the acroread binary to see where/what it’s looking for… ahh it’s 32bit glibc-locale-32bit. You might need to create a softlink. But I would strongly suggest an alternative, if that’s not working as required create a bug report…

8 
rpm -qf /usr/lib*/gconv/ISO8859-1.so

gives?

AK

9

Hi
And to be a pedant… :wink: :wink:


zypper se --file-list /usr/lib*/gconv/ISO8859-1.so
10

The output looks quite reasonable:

erlangen:~ # rpm -qf /usr/lib*/gconv/ISO8859-1.so
glibc-locale-32bit-2.25-2.3.x86_64
glibc-locale-2.25-2.3.x86_64
erlangen:~ # zypper se --file-list /usr/lib*/gconv/ISO8859-1.so
Retrieving repository 'Packman Repository' metadata ...................................................................................................................................................................................[done]
Building repository 'Packman Repository' cache ........................................................................................................................................................................................[done]
Loading repository data...
Reading installed packages...

S  | Name               | Summary                            | Type   
---+--------------------+------------------------------------+--------
i+ | glibc-locale       | Locale Data for Localized Programs | package
i+ | glibc-locale-32bit | Locale Data for Localized Programs | package
erlangen:~ #
11

So the problem is not some missing/removed file but an obsolete “Requires” inside the acroread RPM which explicitly requires “ISO8859-1.so” instead of glibc-locale(x86-32).

Forget the bug report then (and get rid of that Adobe plague ASAP), acroread has been removed from official repos years ago, so most likely the maintainers of the official distro repos will not fix that.

AK

12

Checked that:

erlangen:~ # rpm --requires -q acroread-9.5.5-8.1.i586                       
ISO8859-1.so
UTF-16.so
coreutils
openldap2-client
/bin/sh
/bin/sh
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
/bin/sh
libACE.so
libACE.so(VERSION)
libAGM.so
libAGM.so(VERSION)
libAXE8SharedExpat.so
libAXE8SharedExpat.so(VERSION)
libAXSLE.so
libAXSLE.so(VERSION)
libAdobeXMP.so
libAdobeXMP.so(VERSION)
libBIB.so
libBIB.so(VERSION)
libBIBUtils.so
libBIBUtils.so(VERSION)
libCoolType.so
libCoolType.so(VERSION)
libGL.so.1
libGLU.so.1
libJP2K.so
libResAccess.so
libWRServices.so
libX11.so.6
libXext.so.6
libadobelinguistic.so
libatk-1.0.so.0
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.2)
libcrypto.so.0.9.8
libcurl.so.3
libdl.so.2
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libeggtrayicon.so
libextendscript.so
libfontconfig.so.1
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgcc_s.so.1(GLIBC_2.0)
libgdk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
libgdk_pixbuf_xlib-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgthread-2.0.so.0
libgtk-x11-2.0.so.0
libicudata.so.36
libicuuc.so.36
libidn.so.11
libm.so.6
libm.so.6(GLIBC_2.0)
libm.so.6(GLIBC_2.1)
libpango-1.0.so.0
libpangoft2-1.0.so.0
libpangox-1.0.so.0
libpangoxft-1.0.so.0
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
libpthread.so.0(GLIBC_2.1.1)
libpthread.so.0(GLIBC_2.2)
libpthread.so.0(GLIBC_2.3.2)
libresolv.so.2
libresolv.so.2(GLIBC_2.2)
librt.so.1
librt.so.1(GLIBC_2.2)
libsccore.so
libssl.so.0.9.8
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(CXXABI_1.3.1)
libstdc++.so.6(GLIBCXX_3.4)
libstdc++.so.6(GLIBCXX_3.4.5)
libxml2.so.2
libz.so.1
rpmlib(PayloadIsLzma) <= 4.4.6-1
erlangen:~ #

The whole package is indeed a terrible mess and I failed to identify the shared object executable. Perhaps I am better off giving up old habits. :slight_smile:

Anyway this morning’s monster update (2609 packages/1,6Gib) took 11 minutes to complete. It was great experience!

13

Indeed, and worst of it, a very old and non-maintained mess which nobody except Adobe could fix.

As you said in your first post, acroread did not start, you removed it and got that error from zypper when trying to reinstall.

However, as the file is there, it is quite likely the problem why acroread will not start any more lies somewhere else and has nothing to do with the (now) misplaced explicit requirement zypper complains about.

In this case, it certainly will be.

Just ran that update inside a VM and certainly zypper has become a lot faster when installing packages.

AK

14

I checked this morning:

erlangen:~ # time zypper dup --no-allow-vendor-change 
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 4 items are locked and will not be changed by any action:
 Available:
  qupzilla qupzilla-gnome-keyring qupzilla-kwallet vlc-codecs

The following application is going to be REMOVED:
  Desktop

No additional space will be used or freed after the operation.
Nothing to do.

real    0m1.597s
user    0m0.489s
sys     0m0.106s
erlangen:~ #

Zypper is fast when there is nothing to do and it was fast to figure out that 2609 packages needed to be installed. Actually I noticed no difference.