HPLIP

Bug #1031468
Comment #22

Comment 22 for bug 1031468

Revision history for this message

In Gentoo Bugzilla #423599, Billie-gentoo (billie-gentoo) wrote on 2012-11-18:

#22

(In reply to comment #16)
> I have activity on this bug at launchpad.net

I know. I am there as well

> Three final notes/bugs here:
>
> 1) The hplip ebuild is likely not upgrading the binary plugin when hplip
> ebuilds are upgraded on the the users' systems. After manually deleting all
> printers within CUPS, emerging/compiling hplip with default USE Flags (X
> hpcups libnotify policykit qt4 scanner snmp -doc -fax -hpijs -kde -libusb0
> -minimal -parport -static-ppds") or (+qt4 -static-ppds) and doing "hp-setup
> -i 192.168.1.27", XSane now works. I think the recompiling with default USE
> flags was over-kill, but I did anyways as it was the easiest method. I'm
> pretty sure now, hplip is not upgrading the binary plugin and am just
> awaiting confirmation.

The hplip ebuild does not care about the binary plugin. The binary plugin should be a separate package. I am not going to create an ebuild for it and integrate the plugin with the hplip ebuild as I do not need a binary plugin and thus can not do any testing. As long as there is no other developer who wants to take care of this you are out of luck. There is bug #352439 but there is not much progress. Problem is hplip installs tools who are trying to do some stuff automatically which includes plugin handling. This causes me a lot of trouble because of bugs like this, and this is not the only one.

In your case I think rebuilding cups fixed the issue.

> This bug should likely be renamed to "hplip doesn't upgrade binary scanner
> plugin on upgrades".
>
> 2) hplip requires Python 2 and not Python 3 for using hp-setup. See
> https://bugs.launchpad.net/hplip/+bug/891080. The hplip ebuild should, at
> the very least, notify users to "eselect python set (version 2)" before
> attempting to use hp-setup. (Possibly only when they're installing for a
> device using this binary scanner plugin.) Archlinux appears to have
> submitted a bug and/or it is filed on launchpad (2011-11-16) also without
> any fixes as of yet. Another place for documenting would be
> wiki.gentoo.org/hplip, but the site seems to be down currently.

eselect news read 12 (2010-03-25 Python 3.1)
python 3 is not ready for use as main python interpreter.

> This is likely an easy thing to do without having to open a new bug.
>
> 3) hp-uninstall should likely be removed from hplip as it removes itself,
> overriding the Gentoo Portage package manager! In other words, who knows
> what it removes (ie. rm -rf) when uninstalling! There's also an hp-upgrade
> script, but I'm unsure what this does. Personally, think this package is
> getting to be a package maintainer's worse nightmare. ;-)

You are correct, it more and more becomes a nightmare. I will open a bug at launchpad requesting a distribution build option which does not install all the tools overriding the package manager. Which means hp-uninstall, hp-upgrade probably as well the udev rules which try to automatically configure the printer and install the plugin.

I am closing this bug for now as binary plug-ins are not supported currently. Sorry but I do not have the time to maintain something I can not really test.

(In reply to comment #16)
> I have activity on this bug at launchpad.net

I know. I am there as well

> Three final notes/bugs here:
> 
> 1) The hplip ebuild is likely not upgrading the binary plugin when hplip
> ebuilds are upgraded on the the users' systems.  After manually deleting all
> printers within CUPS, emerging/compiling hplip with default USE Flags (X
> hpcups libnotify policykit qt4 scanner snmp -doc -fax -hpijs -kde -libusb0
> -minimal -parport -static-ppds") or (+qt4 -static-ppds) and doing "hp-setup
> -i 192.168.1.27", XSane now works.  I think the recompiling with default USE
> flags was over-kill, but I did anyways as it was the easiest method.  I'm
> pretty sure now, hplip is not upgrading the binary plugin and am just
> awaiting confirmation.

In your case I think rebuilding cups fixed the issue.

> This bug should likely be renamed to "hplip doesn't upgrade binary scanner
> plugin on upgrades".
> 
> 2) hplip requires Python 2 and not Python 3 for using hp-setup.  See
> https://bugs.launchpad.net/hplip/+bug/891080.  The hplip ebuild should, at
> the very least, notify users to "eselect python set (version 2)" before
> attempting to use hp-setup. (Possibly only when they're installing for a
> device using this binary scanner plugin.)  Archlinux appears to have
> submitted a bug and/or it is filed on launchpad (2011-11-16) also without
> any fixes as of yet.  Another place for documenting would be
> wiki.gentoo.org/hplip, but the site seems to be down currently.

eselect news read 12 (2010-03-25  Python 3.1)
python 3 is not ready for use as main python interpreter.

> This is likely an easy thing to do without having to open a new bug.
> 
> 3) hp-uninstall should likely be removed from hplip as it removes itself,
> overriding the Gentoo Portage package manager!  In other words, who knows
> what it removes (ie. rm -rf) when uninstalling!  There's also an hp-upgrade
> script, but I'm unsure what this does.  Personally, think this package is
> getting to be a package maintainer's worse nightmare. ;-)

I am closing this bug for now as binary plug-ins are not supported currently. Sorry but I do not have the time to maintain something I can not really test.