[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hplip and scanning not working on Jessie



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.


Reply to: