On Sun, Dec 06, 2015 at 03:47:24PM -0800, Marc Shapiro wrote: > On 12/06/2015 03:14 PM, Selim T. Erdoğan wrote: > >On Sun, Dec 06, 2015 at 10:54:39AM -0800, Marc Shapiro wrote: > >>On 12/06/2015 04:41 AM, Selim T. Erdoğan wrote: > >>>On Sat, Dec 05, 2015 at 07:21:49PM -0800, Marc Shapiro wrote: > >>>>I recently upgraded to Jessie, using sysvint-core as my init and am having > >>>>some printer problems. > >>>> > >>>>I got the printer working. CUPS was apparently uninstalled during the > >>>>upgrade. I had noticed that some CUPS files were being removed, but it > >>>>looked like replacements for them were being installed. Anyway, I > >>>>installed > >>>>CUPS, found what driver it wanted (printer-driver-hpcups) and installed > >>>>it, > >>>printer-driver-hpcups is a dependency of hplip, so I would have expected > >>>it to be already installed. > >>> > >>> > >>>>No matter which tool I tried to run, with the exception of hp-check, I get > >>>>the following error: > >>>> > >>>># hp-setup > >>>>Traceback (most recent call last): > >>>> File "/usr/bin/hp-setup", line 45, in <module> > >>>> from base import device, utils, tui, models, module, services, > >>>> os_utils > >>>> File "/usr/share/hplip/base/device.py", line 42, in <module> > >>>> import status > >>>> File "/usr/share/hplip/base/status.py", line 59, in <module> > >>>> import hpmudext > >>>>ImportError: libnetsnmp.so.15: cannot open shared object file: No such > >>>>file > >>>>or directory > >>>This is strange. libsnmp15 was in wheezy and a dependency of hplip 3.12. > >>>In Jessie, hplip is 3.14 and depends on libsnmp30. You seem to have > >>>hplip 3.14, so why it's looking for the file above is a mystery. > >>This is the version of libhpmud0 that is currently installed on my system, > >>even after purging and reinstalling several times. That date seems rather > >>old. Almost half a year BEFORE the Jessie release: > >> > >>/var/cache/apt/archives$ ls libhp* > >>-rw-r--r-- 1 root root 170600 Nov 8 2014 libhpmud0_3.14.6-1+b2_amd64.deb > >That seems to be the correct version for jessie. > > > > > >>Is there a newer version that I should be getting? This version says that it > >>requires libsnmp30, and that is what it brings in, but then it actually > >>seems to try to use libsnmp15. Is this a bug? If so, how do I report it? > >Apparently, this has been reported already. > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794803 > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783296 > > > >It looks like this is not due to the current version of libhpmud trying > >to use old libnetsnmp15, but due to old hpmud-related files being left > >around. > > > > > >>Googling this error, it comes up all over the place. In multiple > >>distributions and years. I saw it as early as 2009 and just about every > >>year since then. I haven't had any trouble with this prior to Jessie, but > >>it certainly seems to have been a problem for others. Is this a problem with > >>dependencies in libhpmud0 not being kept up correctly? But that doesn't > >>explain why it would be a problem across multiple distributions. I'm > >>confused (obviously). Any further ideas? > >I found an Ubuntu bug report from mid-2014: > >https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1245010 > > > >It looks like you can run > > > >locate hpmudext.so > >locate libhpmud.so > > > >and after that, for each entry <file> resulting from these commands, > > > >ldd <file> | grep netsnmp > > > >If any snmp15 lines show up, then <file> might be the culprit, so you > >can try removing <file>. > > > >(If the snmp15 error goes away, but you still have problems, you might > >try reinstalling hplip and libhpmud0 again.) > > > This is the output that I am getting: > > $ locate libhpmud.so > /usr/lib/libhpmud.so.0 > /usr/lib/libhpmud.so.0.0.6 > /usr/lib/x86_64-linux-gnu/libhpmud.so > /usr/lib/x86_64-linux-gnu/libhpmud.so.0 > /usr/lib/x86_64-linux-gnu/libhpmud.so.0.0.6 > > only the version 0.0.6 listings are actual files. The others are soft links > to them. Hence, the matching results shown here: > > $ ldd /usr/lib/libhpmud.so.0 | grep netsnmp > libnetsnmp.so.30 => /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30 > (0x00007f9950fd8000) > $ ldd /usr/lib/libhpmud.so.0.0.6 | grep netsnmp > libnetsnmp.so.30 => /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30 > (0x00007f8b45ad8000) > $ ldd /usr/lib/x86_64-linux-gnu/libhpmud.so | grep netsnmp > libnetsnmp.so.15 => not found > $ ldd /usr/lib/x86_64-linux-gnu/libhpmud.so.0 | grep netsnmp > libnetsnmp.so.15 => not found > $ ldd /usr/lib/x86_64-linux-gnu/libhpmud.so.0.0.6 | grep netsnmp > libnetsnmp.so.15 => not found > > So, is this saying that the problem is in the 64 bit version of the library > only, and not the in the 32 bit version? If I delete the x86_64 version of > the file isn't that going to give me problems since I am running a 64 bit > machine?
The bug reports I found seemed to imply deleting such files fixed their problems, and didn't mention any other problems. The "good" file, /usr/lib/libhpmud.so.0.0.6, should also be 64-bit, since you got it from libhpmud0_3.14.6-1+b2_amd64.deb. If you want to be really safe, you can temporarily move the three "bad" files somewhere else, like your home directory, instead of really deleting them.
