<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 24, 2019 at 9:04 AM Olaf Meeuwissen <<a href="mailto:paddy-hack@member.fsf.org">paddy-hack@member.fsf.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That bug report has also been reported against our backends project.<br>
See <a href="https://gitlab.com/sane-project/backends/issues/45" rel="noreferrer" target="_blank">https://gitlab.com/sane-project/backends/issues/45</a><br>
<br>
BTW, a related Ubuntu bug reports is in<br>
<br>
  <a href="https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1707352" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1707352</a> is<br>
<br>
I've only skimmed the first bug report (1728012) but it seems that a<br>
large number of third-party backend supported scanners stopped working<br>
when "artful" was released.  The bug reports starts with<br>
<br>
  Many scanners can no more be used since sane has changed something<br>
<br>
Fair enough, from zesty to artful, the SANE backends went from<br>
<br>
  zesty : libsane 1.0.25+git20150528-1ubuntu4<br>
  artful: libsane1 1.0.27-1~experimental2ubuntu1<br></blockquote><div><br></div><div>The issue with libsane vs libsane1 seems to have been resolved. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
but we did *not* change any of those third-party backends.  More<br>
importantly, the dll backend did not change how it finds and loads any<br>
of the backends that are configured in dll.conf or dll.d/*.  Anyone can<br>
"easily" confirm this by inspecting the output of<br>
<br>
  git log  RELEASE_1_0_25..RELEASE_1_0_27 -- backend/dll.*<br>
  git diff RELEASE_1_0_25..RELEASE_1_0_27 -- backend/dll.*<br>
<br>
If third-party backends are no longer loaded by the dll backend (you can<br>
check with<br>
<br>
  SANE_DEBUG_DLL=5 scanimage -L<br>
<br>
what backends are and are not loaded), then that is *not* something that<br>
the sane-backends broke.  </blockquote><div><br></div><div>Let me be clear, we know other distros are using it without issue, so we know its a ubuntu issue.  I even put that in the docs I wrote. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It has everything to do with the directories<br>
where the dll backend looks but that is something that is configured by<br>
the distribution.  If the distribution stops looking where third-party<br>
backends have been installed for ages (that's called breaking backward<br>
compatibility), then that's the distribution's prerogative but it is<br>
also *their* task to sort out the resulting breakage that their users<br>
experience.<br></blockquote><div> </div><div>Well, I don't have control of that.  All I can do is write some documentation to try and help :/</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course, third-party also *should* follow the distributions they, eh,<br>
"support" and update their packages accordingly.  Ideally, they'd even<br>
reply to their users' support requests ...<br>
# Eh, that's assuming they even have a place you can contact them :-/<br></blockquote><div><br></div><div>Brother updated brscan4 and 5, but not brscan, brscan1, brscan2 or brscan3.  For those we still need the simlink and udev tricks. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Sun, Jun 23, 2019 at 1:14 PM m. allan noah <<a href="mailto:kitno455@gmail.com" target="_blank">kitno455@gmail.com</a>> wrote:<br>
><br>
>> I don't know of any reason that a sane backend would require the<br>
>> firmware upload to be done as root. All of sane runs in user space.<br>
>> Can you please elaborate?<br>
<br>
All of SANE runs in user space all right, but whatever process tries to<br>
upload that firmware file still needs write privileges to wherever that<br>
scanner is located at.  Our SANE backends don't do anything tricky that<br>
I'm aware of and upload firmware from the same process as the frontend's<br>
but if a third-party "outsources" the upload to a separate process that<br>
might not have the required write privilege.<br>
<br>
It's a bit of a long shot, but I thought I'd mention it.<br></blockquote><div> </div><div>You may well be on to something. As I down own an affected scanner, any idea how we can test this?  If this is the issue, it should be solvable with either a udev or a group membership change. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
# I know that some of the third-party non-free EPSON plugins load the<br>
# firmware from the plugin, which may be running in a separate process<br>
# (depending on the plugin, I don't really remember all the details).<br>
<br>
Other than that, from the bug report mentioned it looks like printer<br>
related udev rules may be clobbering third-party scanner rules (more<br>
likely so for all-in-one type devices).  To complicate matters further,<br>
the *distribution* *specific* sane-backends rules may clobber part of<br>
those printer rules yet again.<br>
<br>
Hope this helps,<br></blockquote><div><br></div><div>Immensely!  Thank you! </div><div><br></div><div>Quite a bit of this has ended up in the ubuntu sane docs already.   The SANE_DEBUG_DLL=5 scanimage -L command was also a great addition.</div><div><br></div><div>I'll keep writing as I see new developments.   </div><br></div></div>