Re: [sane-devel] 1.0.25 is out, now what?

2015-10-28 Thread Johannes Meixner 


Hello

On Oct 28 20:18 Olaf Meeuwissen wrote (excerpt):

Johannes Meixner writes:

...

Suggestion for an additional goal for sane-backends-1.0.26:

- drop support for parallel port scanners


Low priority for 1.0.26 at best.


Also for me this is low priority because I have zero
issue reports regarding parallel port scanners.

I will report my experience when I have droped support
for parallel port scanners in openSUSE Tumbleweed.



But your suggestion made me think of
something more important:

- integrate distribution patches


The openSUSE patches are public available via the
openSUSE Build Service (OBS) development project "graphics"
therein the source package "sane-backends" at
https://build.opensuse.org/package/show/graphics/sane-backends

Currently the only patch which is of interest for
SANE upstream is dell1600n_net-fix-strncat.patch
which is already fixed at SANE upstream
https://alioth.debian.org/tracker/index.php?func=detail=315198_id=30186=410366

All others are only for SUSE-specific needs.



RFC for an additional goal for sane-backends-1.0.26:

- switch to group "lp" instead of "scanner"

...

I think it best to leave this to the individual distributions to decide.


My hope is that the individual distributions might even be able
to agree on a common default so that all Linux users could have
the same default base of operations.


What can be done fairly easily, however, is to make it easier for them
to override/customize the DEVMODE, DEVOWNER and DEVGROUP values in
tools/sane-desc.c.


Perhaps a configure option to specify that would be nice?


FYI, Debian has

 ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"


I like to understand the reson behind why Debian uses
the "scanner" group.

Is it that for Debian use of consumables (paper and ink/toner)
in a printer is more strictly controlled than scanners?

Regardless what the reason is, I also like to understand how
Debian deals with multifunction devices because - as far as
I understand it - there is the conflict that multifunction devices
would have to belong both to the "lp" and the "scanner" group.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)


--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] 1.0.25 is out, now what?

2015-10-28 Thread Olaf Meeuwissen 
Sorry for the belated response.

Johannes Meixner writes:

> Hello Olaf,
>
> first and foremost many thanks for all your
> "SANE Project Janitor" work.
>
> On Oct 19 22:20 Olaf Meeuwissen wrote (excerpt):
>>> ... unofficial ... goals for sane-backends-1.0.26.
>> Feedback and suggestions are welcome.
>
>
> Suggestion for an additional goal for sane-backends-1.0.26:
>
> - drop support for parallel port scanners

Low priority for 1.0.26 at best.  But your suggestion made me think of
something more important:

 - integrate distribution patches

I've updated the milestone[1] to reflect this.

 [1] https://gitlab.com/sane-project/backends/milestones/1

> My plan is to do this for sane-backends-1.0.25 for openSUSE Tumbleweed
> [...]

I'd like to hear about your experiences.

> RFC for an additional goal for sane-backends-1.0.26:
>
> - switch to group "lp" instead of "scanner"
>
> Currently SANE upstream creates udev rules with
> MODE="0664", GROUP="scanner".
>
> Hereby I ask for comments whether or not SANE upstream
> should switch to group "lp" instead of "scanner".

I think it best to leave this to the individual distributions to decide.
What can be done fairly easily, however, is to make it easier for them
to override/customize the DEVMODE, DEVOWNER and DEVGROUP values in
tools/sane-desc.c.

> [...]
> It is sufficiently secure and reasonable easy to use by default
> the same group "lp" for printers and scanners because both kind
> of devices usually require physical user access (to get the
> printed paper or to place a paper on the scanner) so that both
> kind of devices should usually require the same kind of security
> and for multifunction devices only one group can be set and
> then the "lp" group is the more reasonable default setting. 

Security is not the only issue at stake here.  Use of consumables
(i.e. paper and ink/toner) is another that may need to be more strictly
controlled for printers than scanners.

> I do not know how read/write access for USB scanners is done
> in other Linux distributions.

FYI, Debian has

  ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"

in its udev rules file.

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


-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] 1.0.25 is out, now what?

2015-10-28 Thread Olaf Meeuwissen 
Hi Johannes,

Johannes Meixner writes:

> Hello,
>
> On Oct 21 21:32 Olaf Meeuwissen wrote (excerpt):
>> Alessandro Zummo writes:
>>>  There's probably still some bug in the usb code. I have
>>>  intermittent results with some scanners on usb2
>>>  and with others on usb3. switching among the two usb
>>>  standards solves them all.
>>
>> I'm curious about USB related issues that other backends
>> are facing that might be solved by switching to libusb-1
>> as the default.
>
> At openSUSE we use libusb-1 since openSUSE 12.2
> (i.e. we use libusb-1 since about April 2012)
> via "configure --enable-libusb_1_0".
> I am not aware of issues because of this.

Thanks for the info.  So at least changing to libusb-1 is unlikely to
cause any trouble.

My original question however, was if doing so would fix any outstanding
libusb-0 issues that we may have.  I could go through the open tickets
but if someone knows of any off the top of their head ...

# The Alioth tracker's advanced query functionality still has me
# completely mistified.

> Regarding USB 3, see
> https://bugzilla.opensuse.org/show_bug.cgi?id=856794
>
> Summary:
> It seems one needs a very current kernel for USB 3.
> For me kernel 4.1.6 did not work with sane-backends-1.0.25.
> For me kernel-vanilla-4.3.rc5 works where it seems
> the xhci USB driver is now at least somewhat fixed.
> But I needed additionally the workarounds for
> the broken xhci driver in sane-backends-1.0.25
> i.e. sane-backends-1.0.24 did not work for me
> with kernel-vanilla-4.3.rc5, see
> https://bugzilla.opensuse.org/show_bug.cgi?id=856794#c28

USB 3 is known to be a bit of a "rough ride" and nobody seems to know
what the secret mix is to get things to work.

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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] 1.0.25 is out, now what?

2015-10-28 Thread Alessandro Zummo 
On Wed, 28 Oct 2015 18:01:25 +0900
Olaf Meeuwissen  wrote:

> I'm not thinking about just adding a frame type.  There are a number of
> things that can be improved (progress indication, batch scanning among
> others).  If we are to make changes, we may as well address those too.
> And when we do, there will be soversion bump so there will be nothing
> that needs to be checked for current frontends.

 I'd agree on the principle, but doing this way it will
 take more time and we'll end up with two versions of sane
 to handle, since you can't just drop the old one. 

-- 

 Best regards,

 Alessandro Zummo - CEO,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] New hardware / Fedora x86_64 / Canon LiDE 210: "invalid argument"

2015-10-28 Thread Philip Rhoades 

Richard,


On 2015-10-28 01:13, Richard Ryniker wrote:

And Fedora22 updated the sane packages to 1.0.25 yesterday!


Also Fedora 21.  Therefore, all supported versions of Fedora now use
1.0.25.



dnf is not updating to that version yet . . 23 should be available any 
day now - I think I will just fedup to that when it is available and see 
how I go then . .


Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au

--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] 1.0.25 is out, now what?

2015-10-28 Thread Olaf Meeuwissen 
Sorry for the late follow-up.

Alessandro Zummo writes:

> On Wed, 21 Oct 2015 21:32:37 +0900
> Olaf Meeuwissen  wrote:
> [...]
>> API change.  Given the schedule for 1.0.26, I don't think that is doable
>> within that time frame.  If we are going to change the API, there are
>> probably a *lot* of things we should work out before we can commit to
>
>  luckily we have only a few frontends to check for and most of
>  them will correctly bail out when given an unknown frame type.

I'm not thinking about just adding a frame type.  There are a number of
things that can be improved (progress indication, batch scanning among
others).  If we are to make changes, we may as well address those too.
And when we do, there will be soversion bump so there will be nothing
that needs to be checked for current frontends.

>  given that there are a very few users that would try it I do not
>  think we will be receiving a lot of reports of bad frontends.
>
>  once xsane, scanimage, gimp and a few others have been verified
>  to work we'd have covered the vast majority 
>
>> anything.  One of those things would be a clearly documented mechanism
>> for API changes so that backends *and* frontends can deal with them in a
>> graceful and sane manner (pun intended) and changes can be made in a

This is meant to allow for more gradual API changes without needing a
soversion bump, in case that was not clear.  Note though that I am not
sure that this is even possible but it is something to think about.

>  I haven't checked but I think that it's written somewhere that a frontend
>  should correctly behave when given an unknown frame type.

I cannot find anything.  I checked the sane_get_parameters() spec and
the Image Data Format sections.

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


-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org