This is a request, not to drop =net-print/hplip-3.11.10 as it is the only STABLE WORKING VERSION working with Sane/XSane! Using any version >net-print/hplip-3.11.10 causes XSane to segfault. =net-print/hplip-3.11.10 =media-gfx/sane-backends-1.0.22-r1 =media-gfx/sane-frontends-1.0.14 =media-gfx/xsane-0.998 Again. Do not drop the only working hplip version (=net-print/hplip-3.11.10.ebuild) unless this bug gets fixed! (This bug has been on going since early 2012.)
1) Please post your `emerge --info net-print/hplip' output in a comment. 2) Please post the command, its output, and a gdb backtrace of the crashed program.
=net-print/hplip-3.11.10 (X hpcups scanner snmp static-ppds -acl -doc -fax -hpijs -kde -libnotify -minimal -parport -policykit -qt4) =net-print/hplip-3.12.4 (X hpcups scanner snmp static-ppds -acl -doc -fax -hpijs -kde -libnotify -minimal -parport -policykit -qt4) =media-gfx/sane-backends-1.0.22-r1 (ipv6, all other USE flags omitted/negative) =media-gfx/sane-frontends-1.0.14 (gimp) =media-gfx/xsane-0.998 (gimp jpeg lcms nls png tiff -ocr) FYI: The hplip uses a binary blob for the scanner driver, so a gdb might not give any details except for maybe a library name. Whomever else tackles this, make sure you post both, gdb & strace output -- strace providing more details for debugging binary only bug. I am really really busy this Summer (if you can call a month or two of warm weather Summer here). If I do get a little time, be very very thankful that I can provide much more debugging info. HPLIP has a long track record of breaks/regressions. Best tactic is to just block this ebuild version from being yanked, until one of the the bug is worked out of hplip or xsane. It's very possible hplip was lately modifed to reply to an xsane request with unexpected values, causing xsane to break. I'll try to post gdb/strace info within two or three months -- or if lucky, in a week or two.
Created attachment 318854 [details] hplip-3.12.4-xsane-gdb.log
Created attachment 318856 [details] hplip-3.12.4-xsane-strace.log
Created attachment 318862 [details] hplip-3.12.4-xsane-strace-2.log Using "strace -s 200" to prevent clippings of lines. And, using this strace snippet, I think the bug should be easily located and fixed.
Created attachment 318866 [details] hplip-3.12.6-xsane-strace.log Here's another strace on the latest hplip, but not as clear as the strace on the previous hplip-3.12.4 version. gdb output breaks at the seeming same "0xb7c50800 in soapht_control_option () from /usr/lib/sane/libsane-hpaio.so.1" point
Can you scan with hp-scan? If yes this can also be a bug in sane not getting along with changes in hplip. If hp-scan fails as well can you please open a bug about this upstream at https://bugs.launchpad.net/hplip and report the bug number here?
Bingo. You're right about hp-scan failing in hplip version >3.11.10. Likely an upstream bug. I've attached "hp-scan-hplip-3.11.10.log" showing a successful scan and "hp-scan-hplip-3.12.6.log" showing failing at: Opening connection to device... warning: Invalid resolution. Using closest valid resolution of 300 dpi warning: Valid resolutions are dpi. Traceback (most recent call last): File "/usr/bin/hp-scan", line 636, in <module> res = valid_res[0] IndexError: list index out of range 1 :-(
Created attachment 319366 [details] hp-scan-hplip-3.11.10.log Successful scan using "hp-scan"
Created attachment 319368 [details] hp-scan-hplip-3.12.6.log Unsuccessful scan using "hpscan -i". ...snip... Opening connection to device... warning: Invalid resolution. Using closest valid resolution of 300 dpi warning: Valid resolutions are dpi. Traceback (most recent call last): File "/usr/bin/hp-scan", line 636, in <module> res = valid_res[0] IndexError: list index out of range 1 :-(
Okay can you please do as requested in comment #7 and open a bug about this issue upstream.
Per comment #11, done. http://bugs.launchpad.net/hplip/+bug/1031468
Thanks!
This bug is still persistent (=net-print/hplip-3.12.9-r1) with still no activity on the bug filed upstream. =net-print/hplip-3.12.9-r1 X hpcups scanner snmp static-ppds -doc -fax -hpijs -kde -libnotify -minimal -parport -policykit -qt4
Xsane and hp-scan work fine here with a HP Photosmart 6510 (no plugin needed). Can you try upgrading to the latest version of hplip-3.12.10a (do not forget to upgrade the binray plugin as well). Then restart cups, delete and re-configure all printer queues. Please report back if this fixes the problem. You can also try if a revdep-rebuild fixes the issue.
I have activity on this bug at launchpad.net 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. 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. 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. ;-)
Oh, and don't forget to "eselect python set (version 3)" after installing. Would be much easier if they'd just fix their +12 mos old bug. When the wiki.gentoo.org site gets back up, I'll try to document if somebody else doesn't get to it first.
(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 #17) > Oh, and don't forget to "eselect python set (version 3)" after installing. > > Would be much easier if they'd just fix their +12 mos old bug. When the > wiki.gentoo.org site gets back up, I'll try to document if somebody else > doesn't get to it first. I'd really appreciate a hplip wiki page. Please consider to wikify the hplip section of the gentoo printing guide as well. If I have the time I will stop by and add someting to it.
> The hplip ebuild does not care about the binary plugin ( ... snip ... ) Sounds reasonable. From my first couple of months using hplip, I found it more like a software package full of hacking versuses something releasable to the public. But I am thankful for something ... to say the least. But, probably Python maybe to blame for some of this due to it's debug output -- unlike that of Sh(ell)/Bash. > In your case I think rebuilding cups fixed the issue. I pressume you mean, uninstalling the printers and performing a hp-setup is the answer I was looking for, to verify my thoughts. Since I don't see "rebuilding cups" specifically aside from a revdep-rebuild, I will pressume this is what you meant. (Besides, I never did rebuild cups. ;-) > 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. I could, as well, devote time to create the ebuild routines for handling the binary plugin upgrade, but don't think it would be time well spent on binary black matter that will magically disappear. I fear to even think of the nightmare maintaining my ebuild script for instances such as if HP quietly moves the binary plugin folder installation. As soon as the wiki.gentoo.org page was active again early this morning, I documented this issue well within the Troubleshooting/Debugging section of the Gentoo Wiki HPLIP page. Users simply installing or Googling should easily find the resolution for the specied problems here. Maybe at least specifying the binary plugins are not > python 3 is not ready for use as main python interpreter. My bag on this one. Python 3 was released so long ago, I guess I just activated the version a year or so ago. As I followed Python, Python seems like another fine issue and only seems enjoyable to use on my newer plenty-of-resource 8x3.5Gz w/ 32GB RAM 64 bit system, but Gentoo seems to use it for everything -- however does what I need well. As python rolls into 3rd and 4th versions, hopefully they've learned they're lesson about stable API or functions calls between versions. Anyways, off-topic here. Again, all issues are documented on the specified wiki page for others. I still would suggest adding a minimal note/elog to the hplip.ebuild advising users "The hplip ebuild does not upgrade the binary plugins."
Just a quick FYI on this. I noticed =app-admin/hddtemp-0.3_beta15-r3 ebuild has a function for updating it's users' hddtemp.db database manually. Users do so by doing "emerge --config hddtemp", resulting in the system installed hddtemp.db file to be updated from the Internet. Since, command line hp-setup (hp-setup -i 192.168.1.27) does display the filename & http location, with likely only version number change, this may be possible to integrate more easily then I first thought with only the problem of finding the final destination and formatting/state (ie. unzipped) of the final file(s). On an additional note, it also looks like "hp-plugin -i 192.168.1.27" will do the same thing for users'. So, the previous mentioned ebuild probably doesn't need to be even integrated. (Shrugs as to why they didn't make mention of this on launchpad.net!) I'll make note of this last step on the Gentoo Wiki HPLIP page for sure, as well as, users should probably get an elog if they need the binary plugin(s).
(In reply to comment #20) > > In your case I think rebuilding cups fixed the issue. > > I pressume you mean, uninstalling the printers and performing a hp-setup is > the answer I was looking for, to verify my thoughts. Since I don't see > "rebuilding cups" specifically aside from a revdep-rebuild, I will pressume > this is what you meant. (Besides, I never did rebuild cups. ;-) Okay I thought you did rebuild cups. According the last line of the hplip section in the gentoo printing howto users are advised to to remove all printer queues and reconfigure them after upgrading hplip. > As soon as the wiki.gentoo.org page was active again early this morning, I > documented this issue well within the Troubleshooting/Debugging section of > the Gentoo Wiki HPLIP page. Users simply installing or Googling should > easily find the resolution for the specied problems here. I did not know there is already a wiki page for hplip. > I still would suggest adding a minimal note/elog to the hplip.ebuild > advising users "The hplip ebuild does not upgrade the binary plugins." This shouldn't be necessary if users are following the printing guide. I will also add these instructions to the wiki page including other modifications.
