[sane-devel] Fwd: Ubuntu documentation

Tue Jun 25 13:21:05 BST 2019

Hi Steven,

Steven Santos writes:

> On Mon, Jun 24, 2019 at 9:04 AM Olaf Meeuwissen <paddy-hack at member.fsf.org>
> wrote:
>
>> That bug report has also been reported against our backends project.
>> See https://gitlab.com/sane-project/backends/issues/45
>>
>> BTW, a related Ubuntu bug reports is in
>>
>>   https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1707352 is
>>
>> I've only skimmed the first bug report (1728012) but it seems that a
>> large number of third-party backend supported scanners stopped working
>> when "artful" was released.  The bug reports starts with
>>
>>   Many scanners can no more be used since sane has changed something
>>
>> Fair enough, from zesty to artful, the SANE backends went from
>>
>>   zesty : libsane 1.0.25+git20150528-1ubuntu4
>>   artful: libsane1 1.0.27-1~experimental2ubuntu1
>
> The issue with libsane vs libsane1 seems to have been resolved.

My beef wasn't so much with the package name change but with the idea
that the SANE Project somehow had changed something that triggered the
breakage.

>> but we did *not* change any of those third-party backends.  More
>> importantly, the dll backend did not change how it finds and loads any
>> of the backends that are configured in dll.conf or dll.d/*.  Anyone can
>> "easily" confirm this by inspecting the output of
>>
>>   git log  RELEASE_1_0_25..RELEASE_1_0_27 -- backend/dll.*
>>   git diff RELEASE_1_0_25..RELEASE_1_0_27 -- backend/dll.*
>>
>> If third-party backends are no longer loaded by the dll backend (you can
>> check with
>>
>>   SANE_DEBUG_DLL=5 scanimage -L
>>
>> what backends are and are not loaded), then that is *not* something that
>> the sane-backends broke.
>
> 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.

Sorry, I must have missed that.

>> It has everything to do with the directories
>> where the dll backend looks but that is something that is configured by
>> the distribution.  If the distribution stops looking where third-party
>> backends have been installed for ages (that's called breaking backward
>> compatibility), then that's the distribution's prerogative but it is
>> also *their* task to sort out the resulting breakage that their users
>> experience.
>
> Well, I don't have control of that.  All I can do is write some
> documentation to try and help :/

I didn't mean to put the blame on you.  The blame is on distributions
and third-party backend providers for not listening to their users.

Apart from documenting work-arounds, you could try creating a patch for
the Ubuntu packages and get that applied upstream.  That's assuming eaon
is still affected.  Getting that patch into bionic would be great and
very welcome to quite a few Ubuntu users.  Come to think of it, there
may even be a patch floating around somewhere in one of the Ubuntu
derivatives.  Is Mint Linux also affected?

>> Of course, third-party also *should* follow the distributions they, eh,
>> "support" and update their packages accordingly.  Ideally, they'd even
>> reply to their users' support requests ...
>> # Eh, that's assuming they even have a place you can contact them :-/
>
> Brother updated brscan4 and 5, but not brscan, brscan1, brscan2 or
> brscan3.  For those we still need the simlink and udev tricks.

Those tricks can be made non-necessary by Ubuntu, if so inclined.  Many
of the people reported perfectly working devices with zesty (or xenial)
breaking with artful.

>> > On Sun, Jun 23, 2019 at 1:14 PM m. allan noah <kitno455 at gmail.com>
>> wrote:
>> >
>> >> I don't know of any reason that a sane backend would require the
>> >> firmware upload to be done as root. All of sane runs in user space.
>> >> Can you please elaborate?
>>
>> All of SANE runs in user space all right, but whatever process tries to
>> upload that firmware file still needs write privileges to wherever that
>> scanner is located at.  Our SANE backends don't do anything tricky that
>> I'm aware of and upload firmware from the same process as the frontend's
>> but if a third-party "outsources" the upload to a separate process that
>> might not have the required write privilege.
>>
>> It's a bit of a long shot, but I thought I'd mention it.
>
> 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.

Find someone on those issues with a firmware requiring device to check.
If it's an EPSON device, I may be able to help investigate what is going
on in the epkowa and/or utsushi backend if it uses that.

# Full disclosure, I've been intimately involved in the development of
# both until March, 2016 in a professional capacity.  Any investigation
# I can do will be based on the publicly available source code.  I no
# longer have (nor want!) access to the non-free plugin's source.

>> # I know that some of the third-party non-free EPSON plugins load the
>> # firmware from the plugin, which may be running in a separate process
>> # (depending on the plugin, I don't really remember all the details).
>>
>> Other than that, from the bug report mentioned it looks like printer
>> related udev rules may be clobbering third-party scanner rules (more
>> likely so for all-in-one type devices).  To complicate matters further,
>> the *distribution* *specific* sane-backends rules may clobber part of
>> those printer rules yet again.
>>
>> Hope this helps,
>
> Immensely!  Thank you!
>
> 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.
>
> I'll keep writing as I see new developments.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join