after upgrading from hplip 1.6.10 to 1.6.12 the sane support seems broken. i used to be able to use the computer the printer (hp photosmart c5180) is connected to as a scan server (with hplip 1.6.10). i just started sane and all the computers on the subnet could use the scanner of the hp photosmart. with hplip 1.6.12 i can still scan locally, but the hpaio-sane backend doesn't seem to provide support for network-scanning using saned. now i can't downgrade to 1.6.10 any more, because the files have been removed. please fix this asap! Reproducible: Always Expected Results: provide network scanning capabilities for sane debug output of saned: [saned] check_host: access accepted from any host (`+') [saned] init: access granted [saned] init: access granted to saned-user@192.168.2.16 [saned] process_request: waiting for request [saned] process_request: got request 1 [saned] process_request: waiting for request [saned] process_request: got request 10 [saned] quit: exiting the computer i'm trying to connect to the photosmart can't find a scanner...
I don't know why, instead of simply add the new ebuild for 1.6.12, the ebuild maintainer has deleted the 1.6.10 ebuild at the same time of upgrade to 1.6.12. I created two bugs: one for upgrade to 1.6.12 ebuild and the second for stabilize 1.6.10, and the maintainer deleted the old. If he continues deleting old ebuilds with each version bump, then is very dificult that any new version gets stable status.
jean-jaques: The hplip ebuild is located in /usr/portage/net-print/hplip Try to add a portage overlay and add an ebuild for 1.6.10 version on it. Try using the 1.6.12 ebuild with the name changed to hplip-1.6.10.ebuild, and then compile it.
> Try to add a portage overlay and add an ebuild for 1.6.10 version on it. That's what I actually did in the first place. As I said, 1.6.10 works fine. But obviously this can not be an acceptable solution for this problem. I mean, new users won't be even able to find the old ebuild any more. For that reason I have created an attachment with the origina ebuild. It might me helpful for some users.
Created attachment 107194 [details] hplip-1.6.10.ebuild
*** Bug 164107 has been marked as a duplicate of this bug. ***
1.7.1 is out, but it does not fix the problem. Rolling back to 1.6.10 fixed the problem for me. I suggest putting 1.6.10 back in cvs and masking >=1.6.12 until this problem is fixed by upstream. Cheers, Marcelo
Done... I guess now we wait for upstream to release the fix.
Ok, seems to be fixed in 1.7.3. Please reopen if you still have the problem. Cheers, Marcelo
sorry, but the problem still exists - network-scanning still does not work. i've also posted this to the hplip mailing list and they told me that this is a gentoo issue...
Hmmm, I don't know what to say now. Our hplip is pretty much vanilla and nothing is really different between 1.6.10's ebuild and 1.7.3. :-(
Can you please find and attach a fix for this one if it truly is gentoos fault?
does it work from a manual build or is it the fault of another package in the Gentoo distribution?
It didn't work from a manual build (official source from sf.net), the problem seems to be either sane or some dependency. I have already reportet this issue to the hplip mailing list, Aron from the list wanted to check if he could reproduce this problem, but he didn't do it yet. Next week I'm gonna have some more time to look into this issue a little deeper, I'm gonna try if the described scenario works on a debian print server. Again: scanning works fine locally (and should be sufficient for normal users), but the sane network daemon refuses to use the "hpaio" backend.
I too can vouch for the fact that remote scanning doesn't work with hplip > 1.6.10, including net-print/hplip-1.7.4a-r1 which is now marked as stable and is required by cups 1.2.10. I had to mask both. I first noticed this when SaneTwain I was using from a windows box stopped working, and with further testing found that remote sane scanning from linux was broken as well. What's more it breaks quite silently with no errors in daemon.log.
OK, it seems that this is not a Gentoo related issue. I've tried several distributions, all with the same result. I've postet to the hplip mailing list, but they don't seem to be willing to help me. You might want to take a look at: http://www.mail-archive.com/hplip-help%40lists.sourceforge.net/msg02867.html I guess it is ok that 1.7.4 is marked as stable now, so "normal" users can use a newer version. But please leave 1.6.10 in the portrage tree until this problem is resolved. @Tom Dexter: You might want to post to the topic mentioned above in the hplip list. Maybe it would be good if they see that there is more than one user who has to face this problem ;) Dan
(In reply to comment #15) > please leave 1.6.10 in the portrage tree until this problem is resolved. Noted. I have cleaned up hplip ebuilds following the recent stabilization, but I have kept 1.6.10 until the bug is fixed upstream. Denis.
Please test the new 2.7.6 release on your system (see bug #183022). I'm closing this TEST-REQUEST. Feel free to reopen in case the issue still exists. In the meantime I'm not removing version 1.6.10 from the tree. Denis.
I just tested with the hplip-2.7.6 and can verify that the remote sane scanning is in fact NOT fixed in this version. I get the same results as I have with anything greater than net-print/hplip-1.6.10, and that is that the remote machine just gets "no available scanners found". The scary thing is that the messages in daemon.log on the server are virtually identical to those when it works correctly with 1.6.10. Here are the logs from a failed attempt: Jul 22 13:48:10 localhost saned[6128]: saned from sane-backends 1.0.18 ready Jul 22 13:48:10 localhost saned[6128]: check_host: access by remote host: 192.168.1.51 Jul 22 13:48:10 localhost saned[6128]: init: access granted to tom@192.168.1.51 Jul 22 13:48:10 localhost xinetd[6121]: START: sane-port pid=6128 from=192.168.1.51 Jul 22 13:48:10 localhost saned[6128]: quit: exiting Jul 22 13:48:10 localhost xinetd[6121]: EXIT: sane-port status=0 pid=6128 duration=0(sec) Aside from the "duration=0" caused by the failure, this is exactly how it looks when everything works correctly. Is upstream acknowledging this one at all? It doesn't appear that way.
(In reply to comment #18) > when everything works correctly. Is upstream acknowledging this one at all? Have you tried reporting it there ? Let's try and see if I can help you. Please, with version 2.7.6 unmasked and installed, do an 'emerge -vp hplip' and an 'hp-check' as root, and attach the result to this bug. Denis.
No I haven't reported it. Actually from Daniel Klaffenbach's post above I thought it had been. I'll try those tests and attach the results as soon as I can. One thing really confuses me however. The 2.7.6 version provides no /etc/init.d/hplip script at all. Is this correct?
Created attachment 125693 [details] hp-check results for 2.7.6
Here are the results of emerge -pv hplip: Calculating dependencies... done! [ebuild R ] net-print/hplip-2.7.6 USE="X scanner snmp -doc -fax -minimal -parport -ppds" 0 kB
Also note that, on the server the printer/scanner is not connected via USB. Like the original bug comment, the server is accessing this over the network with the hpaio protocol: scanimage -L device `hpaio:/net/Photosmart_C5100_series?ip=192.168.1.50' is a Hewlett-Packard Photosmart_C5100_series all-in-one Also note that scanning on the server works fine, but the remote sharing via sane is what's broken.
Sorry for the barrage of comments...I just discovered that someone on the devel list upstream has found something related to this: http://sourceforge.net/mailarchive/forum.php?thread_name=46A1257E.5060002%40cab.cnea.gov.ar&forum_name=hplip-devel
(In reply to comment #20) > One thing really confuses me however. The 2.7.6 version provides no > /etc/init.d/hplip script at all. Is this correct? Yes it's correct. The new version doesn't use a daemon anymore. (In reply to comment #24) > Sorry for the barrage of comments...I just discovered that someone on the > devel list upstream has found something related to this: Can you try the patch proposed there ? Actually you don't even need to patch, you can just manually replace the "!localOnly" by a "1" with a text editor. If you need assistance in doing this, please contact me in private. Please make sure it dooesn't have any adverse effect. I'd gladly test this, but my home network is made of a single athlon XP machine. If it works we'll have to check whether it's safe enough to include in the ebuild. By the way, please next time do not compress attachments to this bugzilla. It makes it a pain to access them in some cases. Denis.
I just tried the change by manually merging hplip-2.7.6 with the ebuild command, and making that change to the source between the unpack and compile steps. In my case it did in fact fix the remote scanning and caused no problems I can find. I can't help being leery about the intended purpose of that condition though. In this case it was blocking the network client -> saned -> hpaio scanner scenario. I can't help wondering if there's any sort situation (which I'd never be able to test even if I knew what it was), possibly with other shared printers/scanners, where this could cause some sort of really ugly network recursion or something. Hopefully someone on the hplip devel list will chime in with some insight on any potential pitfalls of that hack. Thanks for the help. I'll remember not to compress those attachments in the future.
I can confirm that the patch from the hplip-devel mailing list worked. I've tried it with the gentoo 1.7.4a ebuild and it now works perfectly. I hope it will be fixed pretty soon in a new hplip release.
(In reply to comment #27) > I can confirm that the patch from the hplip-devel mailing list worked. I've > tried it with the gentoo 1.7.4a ebuild and it now works perfectly. I hope it > will be fixed pretty soon in a new hplip release. We don't need to wait for a new release to add it. The real question is about it being harmful or not. I have started looking at the code, but it's going slow. If any of you has any insight of how the whole thing works, you're welcome to share your knowledge... At some point I may just add the patch conditioned by the presence of both the snmp and scanner USE flags. This would avoid the patch has any impact on anybody except you guys. Denis.
Actually I do not have the snmp USE-flag enabled, but that does not really matter at all. Wouldn't it make more sense to add a completely new USE-flag to the ebuild? Something like "netscan"?
Actually, I hadn't noticed I even had the snmp USE flag enabled. I'm not too familiar with snmp, and from looking at the Gentoo hplip wiki, it seems there's been a bunch of confusion over it. I haven't had much time to look into that code to any great extent, and I don't know where that localOnly variable is getting set...I'd guess however that this may be a much more complex design issue, and Denis is right to be cautious. I'll be interested to see what the hplip developers say on their devel list. Here's what may be going on here: It may well be that this is attempting to allow sharing of only "local" scanners. The problem may be in what it considers to be a "local" scanner. As far as I'm concerned, I'd consider a printer/scanner to be "local" as long as it's not a remote cups or smb printer or the like. From a usability standpoint, a printer/scanner connected via hpaio should be viewed as simply using the lan in place of a USB cable, and should absolutely support sharing via sane. At many offices I've worked at it's common to connect an hp printer to one machine over the lan using their drivers and share it via windows...no difference at all. If the existing design is limiting sane sharing to USB/Parport scanners, that would be absolutely awful. On the other hand, hot-wiring it with this hack may allow non-desirable things to happen. What if, on the same server that has the scanner connected via hpaio, I also have another cups printer/scanner on another server defined (say with smb:// or something else). It looks as though the loop in that condition would scan those. What happens in those cases? It may attempt to do something that simply won't work. On the other hand, it may allow the remote client (the one accessing _my_ server) to access a scanner to which only _my_ server was given access which arguably would be even worse. Tom
Good news, this issue is probably gonna be fixed in the next release of hplip: http://www.mail-archive.com/hplip-devel@lists.sourceforge.net/msg00457.html
(In reply to comment #31) > Good news, this issue is probably gonna be fixed in the next release of hplip: > http://www.mail-archive.com/hplip-devel@lists.sourceforge.net/msg00457.html Thanks for the info. If upstream says the fix is mostly harmless there's no need to wait for the next release. I have added the patch in the current 2.7.6 ebuild. You guys will need to re-emerge it but do check that the ebuild contains a reference to this bug in src_unpack (just in case your mirror didn't have the updated ebuild when you sync'ed). You don't need to unmask it anymore, as I took it out of package.mask this morning. Thanks to everybody for your help and cooperation on this bug. Denis.
This bug has officially been fixed in hplip 2.7.7
